ALCATEL Parameters

FDD eNodeB LTE Parameters User Guide (LPUG)
Document number: FDD eNodeB LTE Parameters User Guide

System Release: LR13.x
Document issue: V09.05
Document status: Standard 13.1 , Preliminary 13.3
Date: 27-Sep-2013
Copyright 2013 Alcatel-Lucent, All Rights Reserved
UNCONTROLLED COPY: The master of this document is stored on an electronic database and is “write
protected”; it may be altered only by authorized persons. While copies may be printed, it is not recommended.
Viewing of the master electronically ensures access to the current issue. Any hardcopies taken must be
regarded as uncontrolled copies.
ALCATEL-LUCENT CONFIDENTIAL: The information contained in this document is the property of Alcatel-
Lucent. Except as expressly authorized in writing by Alcatel-Lucent, the holder shall keep all information
contained herein confidential, shall disclose the information only to its employees with a need to know, and
shall protect the information from disclosure and dissemination to third parties. Except as expressly
authorized in writing by Alcatel-Lucent, the holder is granted no rights to use the information contained
herein. If you have received this document in error, please notify the sender and destroy it immediately.
CONTENTS
VOLUME 1 INTRODUCTION
VOLUME 2 MISCELLANEOUS FEATURES AND PARAMETERS
VOLUME 3 LTE AIR INTERFACE
VOLUME 4 RADIO RESOURCE MANAGEMENT
VOLUME 5 CALL MANAGEMENT
VOLUME 6 MOBILITY
LTE PARAMETERS USER GUIDE
VOLUME 1 INTRODUCTION
FDD eNodeB LTE Parameters User Guide 09.05/EN 27-Sep 2013
LTE/DCL/APP/031078 EXTERNAL Standard 13.1, Preliminary 13.3
Volume 1 : Introduction
Contents
1 INTRODUCTION ............................................................................................................................... 3
1.1 OBJECT ..................................................................................................................................... 3
1.2 SCOPE OF THIS DOCUMENT......................................................................................................... 3
2 RELATED DOCUMENTS .................................................................................................................. 6

2.1 LPUG VOLUMES ........................................................................................................................ 6
2.2 REFERENCE DOCUMENTS ........................................................................................................... 6
3 CONFIGURATION MANAGEMENT OVERVIEW ............................................................................. 7

3.1 CONFIGURATION MANAGEMENT COMPONENTS ............................................................................ 7
3.2 ENB CONFIGURATION MODEL .................................................................................................... 8
3.3 RDNID AND CONFIGURATION ID PARAMETERS ............................................................................ 9
4 LPUG TERMINOLOGY ................................................................................................................... 10
5 ANNEXES ........................................................................................................................................ 17
5.1 ABBREVIATIONS ....................................................................................................................... 17
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 1
Figures
Figure 1: eUTRAN Configuration Management Data Flows ............................................................... 7
Figure 2: Configuration Model Terminology ........................................................................................ 9
Figure 3: Example Object Model for DedicatedConf Object ............................................................. 10
Tables
Table 1 : LTE Parameter Groups ...................................................................................................... 14
Table 2 : Source Field Definitions ..................................................................................................... 15
Table 3 : Mapping of Previous LPUG Category to Source Field Value ............................................ 15
P UBLICATION HIS TORY

8-Ma rc h , 2013
Is s u e 09.01/EN Dra ft fo r re vie w
S c o p e : LR13.1 Dra ft fo r FOA
29-Ma rc h , 2013
Is s u e 09.03/EN Ap p ro ve d -P re lim in a ry
S c o p e : LR13.1 FOA Ve rs io n
26-J u ly, 2013

Is s u e 09.04/EN Dra ft
S c o p e : LR13.1 FOA a n d LR13.3 Dra ft fo r re vie w
27-S e p , 2013
Is s u e 09.05/EN S ta n d a rd ve rs io n fo r LR 13.1 a n d P re lim in a ry ve rs io n fo r 13.3
a fte r re vie w
Page 2
1 INTRODUCTION
1.1 OBJECT
The LTE Parameters User Guide (LPUG) document provides parameter setting
recommendations from Alcatel-Lucent’s experience, coming from studies,
simulations and experimentation. It gives the rationale for these settings by
describing the LTE system from an engineering point of view. It also gives
engineering rules related to parameter settings.
The parameters described in this document are mainly configuration parameters
accessible by the customer (operator) via the Operations and Maintenance Center
(OMC) or Network Element Manager (NEM). Note that the 5620 Service Aware
Manager or SAM is used as the OMC with the LTE eNB products. Nevertheless,
some manufacturer configuration parameters are also covered when they are
required to understand the different LTE mechanisms.
1.2 SCOPE OF THIS DOCUMENT

This document provides configuration information for LTE eNodeB products in
Releases LR13.1 and LR13.3 for the Frequency Division Duplex (FDD)
implementation. Information that is added in this edition to support Releases
LR13.1 and LR13.3 are colored with a gray background as illustrated by this
paragraph.
References to LA0.x, LA1.0, LA1.1, LA2.0, LA3.0, LA4.0, LA5.0 and LA6.0 in this
volume refer to features that became available in those releases.
For information concerning parameters for an LTE release earlier than LR13.1,
please refer to the LPUG Edition that supports that release.
Inter-Release Delta: LPUG Volumes
Substantial changes have been made in LPUG structure and content for Release
LR13.1 with the objective of reducing the document size and improving the
readability of the document. A summary of the most important changes are:
• The content of Volume 1 has been reduced. The listing of features per
Volume and the summary descriptions of features have been deleted.
Each individual volume contains a list of features that are described in that
volume. In addition, the listings of new, modified, and deleted parameters,
and parameters that are not described in LPUG have been deleted from
the Appendices. The material related to feature licensing has been moved
to new Volume 2 (see below).
• Previous issues of LPUG included Volume 2 (LTE Overview). This
material has been deleted from the current issue
• A new Volume 2 (Miscellaneous Features and Parameters) has been
added. This volume incorporates some of the material that was previously
found in Volume 1 (Feature Licensing), Volume 7 (Hardware oriented
Page 3
parameters), and Volume 8.

• Material that describes the LTE channels has been moved from Volume 4
(RRM) to Volume 3 (LTE Air Interface)
• Material concerning Location Based Services that was previously included

in Volume 8 has been moved to Volume 5 (Call Management)
• Volume 6 (Mobility) has been restructured to improve readability
• Volume 7 (Hardware) has been discontinued, and the hardware

configuration material is now covered in the Product Engineering Guide
(PEG). The remaining material has been re-distributed to other LPUG
Volumes as described above.
• Volume 8 (OA&M) has been discontinued. Most of the material has been
moved to the new Volume 2 (Miscellaneous Features and Parameters).
Some of the detailed material about test related parameters has been
deleted.
Engineering Recommendation: Parameter Values
Parameter values provided in this version of the LPUG document reflect the
best information available at the time of publication.
If a newer Template delivery becomes available, then the Template is

authoritative as to parameter values
Engineering Recommendation: Feature Status
LPUG is written with the assumption that features that are scheduled for an
LR13.x delivery release become available as initially planned.
Please check the current release notes for latest Feature Status.
Engineering Recommendation: Modem Type in LR13.x
Note that three types of modem are available in in LR13.x: the eCEM, the bCEM,
and the MET3C1 for Metro. Some features are modem-type specific and/or their
delivery date may be modem-type dependent. This is specified in the document
whenever that is necessary.
Restriction: Time Division Duplex (TDD) System
Support for the Time Division Duplex (TDD) implementation is provided in a

separate document.
Page 4
Restriction: eNodeB equipment types covered
The Femto eNodeB or Home eNodeB products are out of scope of this document,
though coexistence with these types of equipment is supported.
All engineering information, algorithms description and parameters values

provided in this document are strictly related to “standard” Alcatel-Lucent eNodeB
products, including Macro and Metro eNodeB, unless explicitly mentioned.
Inter-Release Delta: Transport Parameters
For LPUG editions supporting release LA4.0 and later releases, the transport related
parameters that were previously described in LPUG Volume 7 were moved to the
Transport Engineering Guide (TEG) [R02]. Please refer to that document for
information on transport-related parameters.
Page 5
2 RELATED DOCUMENTS
2.1 LPUG VOLUMES

[Vol. 1] Introduction
[Vol. 2] Miscellaneous Features and Parametersw
[Vol. 3] LTE Air Interface
[Vol. 4] Radio Resource Management
[Vol. 5] Call Management
[Vol. 6] Mobility
2.2 REFERENCE DOCUMENTS

[R01] LTE Transport Engineering Guide, LTE/DCL/APP/034072
[R02] 3GPP TS 36.300 E-UTRAN Overall Description
Page 6
3 CONFIGURATION MANAGEMENT OVERVIEW
3.1 CONFIGURATION MANAGEMENT COMPONENTS

The principal components of the eUTRAN Configuration Management system are shown in Figure
1.
WPS Configuration Tool
eUTRAN Configuration
Snapshot File
OAM Network - IP
eUTRAN Configuration
Work Order File
SAM – LTE
Backhaul Network - IP
eNodeB Configuration
Modification Request
NEM
eNodeB
Figure 1: eUTRAN Configuration Management Data Flows
The principal configuration management physical components are:
 IP Networks – Used to transport data among the OAM Configuration

Management components.
 eNodeB – The radio base station provides the radio cells, terminates the
air interface associations with the UEs, supports backhaul to the evolved
Packet Core Network. The eNodeB also accepts configuration information
from the SAM and provides other OAM services.
 Service Aware Manager (SAM) – The 5620 SAM is a system that is
designed to manage Alcatel-Lucent network elements, or NEs, such as
Page 7
routers and switches. In Release LA3.0, the 5620 SAM also supports the
management of eNBs, and replaces the eXterded Management System
(XMS) that was used to manage the eNBs in earlier LTE releases. In the
management of eNBs, the 5620 SAM serves as a system for sending
updates of configuration data, capture of configuration change requests,
fault management, etc. This function is a part of the Operations and
Management Center (OMC).
 Wireless Provisioning System (WPS) – A system that supports capture of
network element configuration data, and is used by the operations team
for off-line preparation of configuration changes
 Network Element Manager (NEM) – An application that can run on a
laptop and can create and load an object/parameter file into the eNodeB.
The file is used to set the initial value of LTE I&C parameters. NEM can be
used at the eNodeB location, and it can also update some parameters
remotely.
As indicated in Figure 1, configuration management snapshots of the eUTRAN can
be imported from the 5620 SAM into the WPS system. Configuration changes can
be indicated in the WPS system, and then a configuration management work order
file can be exported from WPS to the 5620 SAMS system. Configuration changes
are then sent from SAM to affected eNodeBs.
3.2 ENB CONFIGURATION MODEL

This section provides an introduction to the LTE eNB Configuration Model (CM),
and provides a description of the terminology and notation that is used with this
model.
The object oriented approach of the CM is used to complement the LTE software
architecture.
The model consists of objects that have associated parameters and may contain
other objects. An example can be seen in Section 3.3. The basic notation used in
the model is described in Figure 2.
Page 8
From zero to three instances

One and only one instance Containing (rdnids) permitted, per
permitted, per containing object Object containing object instance.
instance.
1 1 0..3
Containing Another Another

Object Contained Contained
Object Object
1 Object from eslewhere in

containment hierarchy.
Contained
Object
Some
Other
Object
Containing Node within the CM

Object tree “Source” object has association /
reference (i.e., a confid), that
identifies the instance of the
object pointed to.
Contained Leaf within the CM

Object tree
Figure 2: Configuration Model Terminology
3.3 RDNID AND CONFIGURATION ID PARAMETERS

This section provides an overview of the use of the rdnid and confid parameters in
the LTE configuration model. The rdnid and configuration ID parameters (confid
parameters) are not listed in LPUG, because the same principles that are described
in this section are used for each of them.
Multiple instances are possible for many of the objects
 An rdnid parameter uniquely identifies the instance of an object. For
example, rdnid = 0 identifies the first instance of the object, rdnid = 1
identifies the second instance of the object, etc.
 A configuration ID parameter assigns an instance of another object to the

object that it is an attribute of. For example, consider the model
depiction of object DedicatedConf that is shown in Figure 3.
Page 9
Figure 3: Example Object Model for DedicatedConf Object
Each of the up to 32 instances of object TrafficRadioBearerConf has four ConfId

parameters (eNB/UE, UL/DL) that identify instances of LogicalChannelConf,
PdcpConf, and RlcConf that the current instance points to.
For example, if parameter rlcConfId is set to “BTSEquipment/0 Enb/1
DedicatedConf/0 RlcConf/2”, then the current instance of TrafficRadioBearerConf
points to the 3rd instance of object RlcConf (for the eNodeB in the Downlink).
Note also that in addition to an rdnid parameter, some objects also have
associated uniqueName parameters. The uniqueName parameters provide a
”friendly name” that is used to identify the object/instance to the operator.
4 LPUG TERMINOLOGY
• The parameter names are written in bold italic.
• The object names are written in bold.
• Protocol messages are written in CAPITAL LETTERS (e.g., INIT message)
The parameter properties are summarized in a table as follows:
Page 10
Parameter The Name of the parameter is provided here

Object The path for the object with which the parameter is associated
Range & Unit The range and unit of the parameter.
Class/ The Class and the Source of the parameter (see descriptive text
Source later in this section)
Value The default or recommended value of the parameter
Feature Feature the parameter is directly associated with (if applicable)
Additional information is provided below about the entries in the tables that
describe the parameter properties.
• Class – Each parameter is assigned to a class according to the impact that

results when the parameter value is modified (or created/deleted for an
associated object). Three parameter classes are defined. Each class
corresponds to a parameter update rule.
o Class A. The modification/creation/deletion of these parameters
requires a full eNodeB reset before the change will take effect. This is a
software reboot with most processes in the eNB having their value
reinitialized then restarted without power on/off. The externally visible
effects of a full eNodeB reset are:
The eNB resets external resources to avoid triggering defense

mechanisms at the MME(s) and neighboring eNBs:
• The eNB sends S1 reset message(s) to request MME(s) to
release all contexts for all the calls supported by the eNB.
• The eNB sends an X2 reset toward each neighboring eNB, to
request the neighboring eNBs to release contexts of UEs for
which a handover was in progress toward the eNB which is
going to restart.
• The eNB releases all UE calls and mobility involving this eNb
is not possible.
The eNodeB disables S1 links with EPC and X2 links with other eNBs
eNB management from SAM is lost during the reset period.
Neighboring eNBs may have to employ defense mechanisms due to
mobility failure.
Next, all the internal eNB software and hardware is reset.
• The eNodeB initiates a reset followed by a software setup
that takes into account corresponding objects with new Class
A parameter values.
The eNB restarts from the cards discovery stage, which is faster than a
power up restart.
Page 11
o Class B. The modification/creation/deletion requires internal resource
unavailability in the eNB, which leads to service impact. The eNB
OA&M interfaces remain available. The precise service impact can
vary between parameters as outlined below. In general for Class B
changes, the object whose parameter value is to be changed will be
reset when the modified data is downloaded to the eNB. The following
additional detail is provided for each parameter:
 B--Modems+Cells-of-NE: Reset of all Modems of the eNodeB
+ their cells.
 B--Modem+Cell(s): Reset of associated Modem + all its cells.

 B--Cells-of-NE: Disable and re-enable of all cells of the
eNodeB.
 B--Cell(s)-of-Modem: Disable and re-enable of all cells of the

associated Modem.
 B--Cell+RF(s): Disable and re-enable of the single associated
cell and all of its RF paths
 B--Cell: Disable and re-enable of the single associated cell..
 B-- Transport-Layers: Reset of the eNodeB's transport network
layers. Implies reset of the SCTP, S1 and X2 layer instance(s)
that are mapped to the transport layers.
 B--X2-interface: Reset of associated SCTP & X2 interface.
 B--S1-interface: Reset of associated SCTP & S1 interface.
Also note that in Release LR13.1 as in previous releases, each eCEM
modem supports one and only one cell, but the bCEM modem unit can
support up to three cells.
Modem reset is a hardware reboot of the modem with most processes
in the modem card having their value reinitialized then restarted without
power on/off. When performing a modem reset, first the eNodeB
releases the following external resources:
1. UE contexts at MME level
To release the UE contexts at MME level, an S1 AP RESET
message is sent to the MME to request the MME to release all the
contexts for the calls associated with the cell(s) to be reset. The
eNB explicitly indicates all of the contexts to be released by the
MME in the S1 reset message.
2. X2 resources that are associated with the cells to be reset
3. Affected Bearer(s) at modem level (layer 1/layer 2)
After external resources are released, the system releases UE call
contexts, and then performs a hardware reset of the modem unit. The
modem unit then restarts, cells are reinitialized, and traffic resumes.
The interface with SAM continues to be available during modem reset,
because this interface is associated with the controller, not the modem
unit.
Page 12
Cell reset is a cell software reboot with all cell processes having their
value reinitialized then restarted without power on/off. The externally
visible effects of the cell reset are:
The eNodeB releases external resources:
1. UE contexts at MME level
To release the UE contexts at MME level, an S1 AP RESET
message is sent to the MME requesting the MME to release all
the contexts for the calls associated with the cell to be reset.
The eNB explicitly indicates all the contexts to be released by
the MME in the S1 reset message.
2. Affected Bearer(s) at modem level (layer 1/layer 2)
UEs will not receive an RRC disconnect but will lose their
physical synchronization because the L1 Downlink channel will
power off. Thus each UE interprets this as a link failure.
Consequently the UE will try to perform a re-establishment
toward another cell of the same eNodeB. This reestablishment
request on the same eNodeB will be rejected due to missing
UE context, and the UE will then go to Idle Mode.
Subsequently, the UE will perform a cell reselection in order to
camp on a neighbor cell. This reselected cell may belong to
the same eNB or to a neighbor eNB).
The cell is then reinitialized with the modified Class B parameter

values, and resumes handling traffic. The interface with SAM continues
to be available during cell reset, because this interface associated with
the controller, not the cell.
o Class C The modification/creation/deletion is taken into account by the
eNB without any impact on services. Two sub-categories are also
defined:
 C--Immediate-propagation: No temporary service impact. But
any update that, in principle, reconfigures any existing
established activities that are supervised by the eNodeB will be
cascaded immediately to all those activities.
 C--New-set-ups: No temporary service impact. In general, the
new parameter value will take effect only for new established
activities. However, a parameter that affects any information
that is broadcast by the eNodeB may be cascaded immediately
via the appropriate broadcast mechanism.
o N.A.: Not applicable - either the parameter is not an eNB configuration
parameter (e.g., it is used by SAM and has no eNB impact), or the
parameter does not configure any activity that is supervised by the
eNodeB.
Page 13
Restriction: Metro reset behavior
All of the parameters using category “Cells-of-NE” or “Cell+RF(s)” will have the
reset behavior on Metro of “Modems+Cells-of-NE”.
All of the parameters using category “Cell(s)-of-Modem” or “Cell” will have the
reset behavior on Metro of “Modem+Cell(s)”.
The expected behavior is not different from the macro behavior, except a longer
reset time when updating these parameters.
Inter-Release Delta:
In some earlier releases the Class values were shown as 0, 2, and 3. These class
values may still be visible in the WPS system. A simple conversion is possible:
 Class A ↔ Class 0
 Class B ↔ Class 2
 Class C ↔ Class 3
LTE parameters can be divided into five parameter groups, the fifth group being
the most meaningful and important from the perspective of LPUG.
Group Comments
• Mostly not covered in LPUG
• Source and Classes do not apply
READ ONLY parameters • Used to provide system information
(for example, state and status
parameters, inventory parameters, and
additional information parameters)
• Source and/or classes do not apply
rdnId parameters
• See Section 3.3 for more information
• Source and/or classes do not apply
xConfId parameters
• See Section 3.3 for more information
uniqueName parameters • Source and/or classes do not apply
Others • Source and Classes apply.
Table 1 : LTE Parameter Groups
In previous issues of LPUG a category field was provided in the parameter

table. Beginning in release LR13.1, the category field will be replaced by a
“Source” field. The Source field is intended to indicate the source of the
parameter value that is to be used. The brief definitions that are used are as
follows:
Page 14
Source Field Value Definition

system_reserved Object or attribute that has not been assigned one
of the categories below.
system_restricted Object or attribute that is not to be changed on live
networks.
customer_init Attribute that is set (or approved) by the customer.
The attribute is included in the CIQ to allow the
provisioning of the miscellaneous eNodeBs with the
appropriate site dependent information. The value
is <unset> in the templates.
Customer Settable Object or attribute that can be set by the customer
for which ALU provides a default value.
eng_tunable Optimization attribute: This attribute is set by ALU
engineering teams or the customer's engineering
teams or both engineering teams.
Table 2 : Source Field Definitions
In general, the following mapping has been used in converting the previous
“Category” field to the new “Source” field.
LPUG Category Source Value

Optimization eng_tunable
I&C customer_init
O.D. customer_settable
Fixed system_restricted
Table 3 : Mapping of Previous LPUG Category to Source Field Value
Note that in some cases, the concept of source does not apply. In other cases,
the way a parameter is provisioned may depend on customer strategy (type of
coverage/service/behavior the customer wants for their network). The
parameter source is then typically filled with ”System Reserved”.
Two other points are worth mentioning for Engineering Tunable (optimization)
parameters:
o Even though a “default” value may be provided by ALU, the parameters

are set by the customer.
o The value may sometimes be the same for all cells with the same radio
environment (for example: hotspot, dense urban, urban, suburban,
rural, isolated). In this case, the value changes from one radio
environment to another (i.e. there is no systematic change from cell to
cell).
• Parameter Value. This will normally be the default or latest recommended value
for the parameter. Some parameter values include an admonition in red text
that the value should not be changed by the operator.
Note that some parameter values cannot be provided in this document. In this
case, the value field is filled with one of the following terms:
o N.S.: Not Significant
o O.D.: Operator Dependent (depends on operator network specific
configuration. For example, addressing parameters).
Page 15
• Feature Number. When possible, a reference is provided to the LTE feature
number that caused the parameter to be added or that altered the parameter’s
use. When a parameter is related to several features, multiple feature numbers
may be indicated. Some parameters are not associated with a specific feature,
and, in the case of these parameters, the feature number entry will be blank.
• The datafill rules are presented as follows:
Rule:
• The system restrictions are presented as follows:
Restriction:
• The engineering recommendations for parameter value are presented as

follows:
Engineering Recommendation:
• The differences between the current release and the previous release are
presented as shown below. These are major changes that may lead to a
change in system behavior.
Inter-Release Delta:
Page 16
5 ANNEXES
5.1 ABBREVIATIONS
ACK Acknowledgement
AM Acknowledge Mode
ARQ Automatic Repeat Request
AS Access Stratum
BCCH Broadcast Control Channel
BCH Broadcast Channel
CM Configuration Model
CP Cyclic Prefix
CRC Cyclic Redundancy Check
DCCH Dedicated Control Channel
DL Downlink
DFTS DFT Spread OFDM
eNB E-UTRAN NodeB
EPC Evolved Packet Core
EPS Evolved Packet System
FDD Frequency Division Duplex
GP Guard Period
HARQ Hybrid ARQ
LMT Local Maintenance Terminal
LTE Long Term Evolution
MAC Medium Access Control
MBSFN Multimedia Broadcast multicast service Single Frequency Network
MCCH Multicast Control Channel
MCH Multicast Channel
MCS Modulation and Coding Scheme
MIM Management Information Model
MIMO Multiple Input Multiple Output
MME Mobility Management Entity
NACK Negative Acknowledgement
NEM Network Element Manager
NS Not Significant
OMC Operations and Maintenance Center
OFDM Orthogonal Frequency Division Multiplexing
OFDMA Orthogonal Frequency Division Multiple Access
PAPR Peak-to-Average Power Ratio
PBCH Physical Broadcast Channel
PCCH Paging Control Channel
PCFICH Physical Control Format Indicator Channel
PCH Paging Channel
PDCCH Physical Downlink Control Channel
PDSCH Physical Downlink Shared Channel
PDU Protocol Data Unit
PHICH Physical Hybrid ARQ Indicator Channel
PHY Physical layer
Page 17
PMCH Physical Multicast Channel
PRACH Physical Random Access Channel
PRB Physical Resource Block
PUCCH Physical Uplink Control Channel
PUSCH Physical Uplink Shared Channel
QAM Quadrature Amplitude Modulation
RF Radio Frequency
RLC Radio Link Control
RNTI Radio Network Temporary Identifier
ROHC Robust Header Compression
RRC Radio Resource Control
RRM Radio Resource Management
SAM Service Aware Manager
SC-FDMA Single Carrier – Frequency Division Multiple Access
TB Transport Block
TCP Transmission Control Protocol
TDD Time Division Duplex
TTI Transmission Time Interval
UE User Equipment
UL Uplink
UM Unacknowledged Mode
UMTS Universal Mobile Telecommunication System
UTRA Universal Terrestrial Radio Access
UTRAN Universal Terrestrial Radio Access Network
VRB Virtual Resource Block
Page 18
 END OF VOLUME 
Page 19
VOLUME 2 MISCELLANEOUS FEATURES AND

PARAMETERS
FDD eNodeB LTE Parameters User Guide 09.05/EN 27-Sep-2013
LTE/DCL/APP/031078 EXTERNAL Standard 13.1 , Preliminary 13.3
Volume 2: Miscellaneous Features and Parameters
CONTENTS AND PARAMETER GUIDE

1 INTRODUCTION.............................................................................................................................. 13
1.1 OBJECTIVE............................................................................................................................... 13
1.2 SCOPE OF THIS DOCUMENT ....................................................................................................... 13
1.3 RELATED FEATURES ................................................................................................................. 15
2 RELATED DOCUMENTS AND PREREQUISITES ......................................................................... 20

2.1 LPUG VOLUMES ...................................................................................................................... 20
2.2 REFERENCE DOCUMENTS ......................................................................................................... 20
2.3 PREREQUISITES FOR READING THIS VOLUME ............................................................................. 21
3 FEATURE AND CAPACITY LICENSING ....................................................................................... 22

3.1 FEATURE AND CAPACITY LICENSING – HIGH LEVEL DESCRIPTION ............................................... 22
3.2 LICENSING CONFIGURATION PRINCIPLES .................................................................................... 31
4 ENHANCED NODE B (ENB) HARDWARE .................................................................................... 34

4.1 ECCM2 INTRODUCTION L115850 ............................................................................................. 34
ENBEquipment::expectedControllerType ........................................................35
4.2 BCEM INTRODUCTION L105587 ................................................................................................ 35
ENBEquipment::expectedModemType ............................................................36
4.3 9412 – COMPACT MULTI-BAND/DUAL-FREQUENCIES .................................................... 38
4.3.1 9412 – COMPACT DUAL-BAND eNodeB L132037......................................................... 38
ActivationService::isDualCarrierEnabled ........................................................41
4.3.2 COMPACT DUAL-CARRIER SUPPORT ON ONE BAND L115938 ................................ 41
4.3.3 TRI CARRIER BBU L115808 ........................................................................................... 42
ActivationService::isTriCarrierEnabled ...........................................................43
LteCell::dedicatedConfId ...................................................................................43
LteCell::enbRadioConfId ...................................................................................44
LteCell::enbVoipConfId .....................................................................................44
FrequencyAndBandwidthFDD::multiCarrierPriority .......................................44
4.3.4 NINE CELLS (ONE FREQUENCY) ON THREE MODEMS L115401 .............................. 45
ActivationService::isIncrementalSectorEnabled.............................................46
4.4 ENODEB CONFIGURATION ........................................................................................................ 47
4.4.1 AISG 2.0 support (TMA&RET) L156783 .......................................................................... 47

ActivationService::isAisgAllowed ....................................................................48
CpriRadioEquipment:: isRfmAisgEnabled ......................................................48
4.4.1.1 Overview ...................................................................................................................... 49
4.4.1.2 TMA & RET in LR13 ..................................................................................................... 53
4.4.1.3 Three sectors configuration with TMA and RET per RRH ........................................... 54
4.4.1.4 DUAL BAND and TMAs CONFIGURATION- L156783................................................ 59
4.4.1.4.1 Configuration where there is one BBU per band at the site ...............59
4.4.1.4.2 Configuration where the BBU support two bands using a single
controller 59
4.4.1.5 ALD Bus INITIALIZATION and ALD Data Entry .......................................................... 61
4.4.1.6 ADJUSTING RFM RECEIVE PATH GAIN ................................................................... 62
4.4.2 Distributed Antenna System (DAS) Configuration l92811.1 ............................................. 65
CellActivationService::isDasDelayEnabled .....................................................67
4.4.3 Feature L100622 - Support Fiber delay (or any delay between modem and RF head)
in LTE 71
Page 1/308
CellActivationService::isFiberDelayAllowed ...................................................72
4.4.4 Receive Diversity Expansion Module (RDEM) L106226 - eNodeB 4xReceive
Diversity L115562 - single Transmit Scheme Antenna L84815 ........................................................ 72
4.4.4.1 AWS RDEM Configuration L106226 ............................................................................ 72
4.4.4.2 4x Receive diversity paths L115562 ............................................................................ 74
LteCell::numberOfULAntennas.........................................................................76
4.4.4.3 single Transmit Scheme Antenna L84815 ................................................................... 77
LteCellFDD::numberOfDLAntennas .................................................................78
4.4.4.4 OAM IMPACTS ............................................................................................................ 80
4.4.5 Carrier aggregation (160847) ........................................................................................... 81
4.4.5.1 Feature activation ......................................................................................................... 81
eNB::cellMappingOverBoardMode ...................................................................81
LteCell::carrierAggregationCellGroup .............................................................82
ActivationService::isCarrierAggregationEnabled ...........................................83
4.4.5.2 “Temporary non-CA mode”: Cell remapping in case of modem failure ....................... 83
eNB::isCellRemappingForCoverageRecoveryEnabled ..................................84
eNB::isCellRemappingForCarrierAggregationRecoveryEnabled ..................84
4.5 MULTITECHNO CONFIGURATIONS .............................................................................................. 84
4.6 CABLING DELAYS ...................................................................................................................... 85
4.6.1 Antenna Path Delay determination ................................................................................... 86
4.6.2 CPRI Delay Determination ............................................................................................... 87
4.6.3 TOTAL Cabling Delay Determination ............................................................................... 87
5 INSTALLATION AND COMMISSIONING PARAMETERS ............................................................ 88

5.1 CPRI RADIO EQUIPMENT PARAMETERS ..................................................................................... 89
CpriRadioEquipment::rfmControlMode ...........................................................90
CpriRadioEquipment::cpriPort .........................................................................90
CpriRadioEquipment::fruId ...............................................................................90
CpriRadioEquipment:: localCellPowerLimit ....................................................91
CpriRadioEquipment::remoteControllerId .......................................................91
CpriRadioEquipment::locationIdentifier ..........................................................92
CpriRadioEquipment::dbu.................................................................................92
LteCell::diversityImbalanceThreshold .............................................................93
5.2 ANTENNA PORT&CELL ANTENNA PORT PARAMETERS ................................................................ 94
5.2.1 AntennaPort Association Parameters............................................................................... 95
AntennaPort::SectorID ......................................................................................95
AntennaPort::assignedTransceiverPort ..........................................................96
5.2.2 Antenna Port association parameters with cross connection ........................................... 98
5.2.3 CELLANTENNA PORT ASSOCIATION PARAMETERS WITH BAND CLASS 25
(PCS) L115295 ............................................................................................................................... 100
ENBEquipment::xConnectEnable...................................................................100
5.2.3.1 L171049 - Antenna Cross Connect (ACC) on Dual Band eNB configuration –
Mixed Mode................................................................................................................................... 101
5.2.4 Antenna Port Association Parameters WITH Band Class 25 (PCS) L115295 ............... 104
CellAntennaPort::antennaPortId.....................................................................104
CellAntennaPort::rxPath .................................................................................105
CellAntennaPort::txPath ..................................................................................105
5.2.5 Antenna Information Parameters.................................................................................... 106
AntennaPort::antennaLabel ............................................................................106
AntennaPort::antennaPortLabel .....................................................................107
AntennaPort::horizontalBeamwidth ...............................................................108
AntennaPort::verticalBeamwidth....................................................................108
AntennaPort::Azimuth .....................................................................................109
5.2.6 Downlink Parameters...................................................................................................... 109
Page 2/308
AntennaPort::antennaPathDelayDL ...............................................................109
AntennaPort::txUsed .......................................................................................111
AntennaPort::antennaPathAttenuationDL .....................................................112
AntennaPort::jumperLossDl ...........................................................................113
5.2.7 Uplink Parameters .......................................................................................................... 113
AntennaPort::antennaPathDelayUL ...............................................................113
AntennaPort::rxUsed .......................................................................................115
AntennaPort::antennaPathAttenuationUL .....................................................116
AntennaPort::jumperLossUl ...........................................................................117
CellAntennaPort::ulAntennaGain ...................................................................117
5.2.8 Antenna Test Parameters ............................................................................................... 117
AntennaPort::vswrWarningThreshold ...........................................................118
AntennaPort::vswrUrgentThreshold ..............................................................118
5.2.9 RET AND TMA Parameters ............................................................................................ 119
5.2.9.1 RET AND TMA IDENTIFICATION Parameters ......................................................... 119
RetSubunit::retSubunitNumber ......................................................................120
TmaSubunit::tmaSubunitNumber ...................................................................121
Ret::retAldUniqueName ...................................................................................122
Ret::retAssociatedEnodebFriendlyName ......................................................122
Ret::retFriendlyName .......................................................................................122
RetSubunit:: labelAssociatedENB ..................................................................123
RetSubunit:: labelSectorId ..............................................................................123
RetSubunit:: retSubunitAssociatedeNodeB ..................................................123
Tma::tmaAldUniqueName ...............................................................................125
Tma::tmaAssociatedEnodebFriendlyName ...................................................125
Tma::tmaAssociatedRfmFriendlyName .........................................................126
Tma::tmaFriendlyName ...................................................................................126
5.2.9.2 RET AND TMA Main Configuration Parameters ........................................................ 126
AntennaPort::ttlnaEquipped ...........................................................................126
AntennaPort::ttlnaAntennaGain .....................................................................127
Tma::tmaSelfTest .............................................................................................129
Tma::tmaSoftwareFilename ............................................................................129
TmaSubunit::bypassMode ..............................................................................129
Ret::mechanicalTilt ..........................................................................................130
Ret::retSelfTest ................................................................................................130
Ret::retSoftwareFilename ................................................................................130
RetSubunit::antennaBandClass .....................................................................131
RetSubunit::antennaCalibrate.........................................................................131
RetSubunit::antennaConfigFile ......................................................................131
RetSubunit::antennaElectricalTilt...................................................................132
RetSubunit::maxElectricalTilt .........................................................................132
RetSubunit::minElectricalTilt ..........................................................................132
RetSubunit::mechanicalTilt .............................................................................133
AntennaPort::retSubunitId ..............................................................................133
AntennaPort::tmaSubunitId ............................................................................133
5.3 SECTOR RELATED PARAMETERS ............................................................................................. 133
5.3.1 LTECell Sector Number Parameter ................................................................................ 134
LteCell::sectorNumber ....................................................................................135
5.4 ENB PARAMETERS ................................................................................................................ 135
ENBEquipment::equipmentKind.....................................................................136
Enb::autoResetTimer .......................................................................................136
ENBEquipment::maxTransportFiberDelayLengthCategory .........................137
5.5 SELF-COMISSIONING PARAMETERS ......................................................................................... 139
OAMInterface::provisionedEnbIdentifier .......................................................139
5.5.1 L115970 eNB Self Commissioning Improvements ......................................................... 139
Page 3/308
OamTransportConf::emsFqdn ........................................................................140
ProvisionedEmsAddressData:: emsIpv4Address .........................................141
ProvisionedEmsAddressData:: emsIpv6Address .........................................141
ProvisionedEmsAddressData:: emsOamLinkInitPort ...................................141
6 AIR INTERFACE CLOCK SYNCHRONIZATION ......................................................................... 142

ClockSync::clockSyncSourcePriorityList ......................................................143
ClockSync::gpsClockEnable...........................................................................144
ClockSync::ptpClientEnable ...........................................................................144
ClockSync::syncEClockEnable ......................................................................144
6.1 GPS SYNCHRONIZATION SOURCE CONFIGURATION .................................................................. 144
ClockSync::gpsModeSelect ............................................................................145
ClockSync::sfnSyncOption .............................................................................146
7 ENB AND SOFTWARE CONFIGURATION CONTROL PARAMETERS .................................... 147

7.1 ENB EQUIPMENT RELATED PARAMETERS .................................................................... 147
ENBEquipment::aliasName .............................................................................147
ENBEquipment::userSpecificInfo ...................................................................147
ENBEquipment::templateVersion ...................................................................148
7.2 SOFTWARE AND CONFIGURATION CONTROL PARAMETERS ....................................................... 148
ActivationService::isEnbSelfConfigAllowed .................................................150
Enb::timerToWaitForFallbackToPreviousSWversion ...................................151
Enb:: doEnbResetAfterConfiguration ............................................................152
8 OVERLOAD CONTROL ................................................................................................................ 153

OverloadControl::minorThresholdForPO ......................................................155
OverloadControl::minorOutThresholdForPO ................................................155
OverloadControl::majorThresholdForPO ......................................................156
OverloadControl::majorOutThresholdForPO ................................................156
ActivationService:: isEnhancedOverloadControlEnabled ...........................157
9 STATE AND STATUS PARAMETERS (ADMINISTRATIVESTATE, AVAILABILITYSTATUS

AND OPERATIONALSTATE) ............................................................................................................. 158
10 SPARE PARAMETERS................................................................................................................. 162

10.1 LA6.X SPARE PARAMETERS ................................................................................................... 162
10.2 LR13.X SPARE PARAMETERS ................................................................................................. 179
Enb:: Spare4 .....................................................................................................191
Enb:: Spare9 .....................................................................................................192
Enb:: Spare15 ...................................................................................................193
LTECell:: Spare4 ..............................................................................................194
LTECell:: Spare5 ..............................................................................................195
LTECell:: Spare6 ..............................................................................................196
LTECell:: Spare7 ..............................................................................................197
LTECell:: Spare9 ..............................................................................................197
11 UE POSITION LOCATION SUPPORT.......................................................................................... 198

11.1 SIMPLIFIED LOCATION ARCHITECTURE..................................................................................... 198
11.2 FEATURE L114572/L114572.1 - ENB SYNCHRONIZATION SUPPORT FOR OTDOA FOR
COMMERCIAL DEPLOYMENT ................................................................................................................... 199
ActivationService::isGeoLocPhaseSyncAllowed..........................................201
11.3 FEATURES L101821/L101821.1– USER PLANE AND CONTROL PLANE OTDOA WITH
HEARABILITY SUPPORT FOR COMMERCIAL DEPLOYMENT ......................................................................... 202
Page 4/308
ActivationService::isOtdoaHearabilityEnhancementAllowed ......................203
11.4 OBSERVED TIME DIFFERENCE OF ARRIVAL (OTDOA) .............................................................. 204
11.5 POSITIONING SYSTEM PARAMETERS [L103896] AND RELATED FEATURES ................................. 205
11.5.1 PoSITIONING OF ENB COMPONENTS........................................................................ 205
11.5.1.1 GPS antenna position per ENB.................................................................................. 206
PositioningSystem::gpsAntennaPositionLongitude ....................................206
PositioningSystem::gpsAntennaPositionLatitude ........................................206
PositioningSystem::gpsAntennaPositionAltitude ........................................206
11.5.1.2 RF antenna position per cell ...................................................................................... 207
LteCell::mainAntennaPositionLongitude .......................................................207
LteCell::mainAntennaPositionLatitude ..........................................................208
LteCell::mainAntennaPositionAltitude ...........................................................208
11.5.1.3 BBU position per eNodeB .......................................................................................... 209
ENBEquipment::bbuPositionLongitude .........................................................209
ENBEquipment::bbuPositionLatitude ............................................................209
ENBEquipment::bbuPositionAltitude .............................................................210
11.5.1.4 Configured or Computed, 2 different sources: ........................................................... 210
ENBEquipment::bbuConfiguredPositionLongitude ......................................211
ENBEquipment::bbuConfiguredPositionLatitude .........................................211
ENBEquipment::bbuConfiguredPositionAltitude..........................................211
LteCell::mainAntennaConfiguredPositionLongitude ....................................212
LteCell::mainAntennaConfiguredPositionLatitude .......................................212
LteCell::mainAntennaConfiguredPositionAltitude ........................................212
LteCell::mainAntennaPositionDeltaX .............................................................213
LteCell::mainAntennaPositionDeltaY .............................................................213
LteCell::mainAntennaPositionDeltaZ .............................................................213
ENBEquipment::bbuPositionDeltaX ...............................................................214
ENBEquipment::bbuPositionDeltaY ...............................................................214
ENBEquipment::bbuPositionDeltaZ ...............................................................214
11.6 ENHANCED CELL IDENTIFICATION (ECID) LOCATION METHOD AND LPP/LPPA LOCATION
CONTROL PLANE PROTOCOL SUPPORT ................................................................................................... 216
11.6.1 enhanced cell ID (ECID) LOCATION Feature [L103895.1] & LPP/LPPa LOCATION
CONTROL PLANE [L103896, L103896.1]...................................................................................... 218
ActivationService::isEcidSupportAllowed .....................................................218
ActivationService::isLPPaInterfaceAllowed ..................................................218
11.6.2 Overview ......................................................................................................................... 218
11.6.3 Proposed Network Architecture ...................................................................................... 220
11.6.4 SYSTEM CALL FLOWS ................................................................................................. 221
11.6.5 PARAMETERS for L103896 ........................................................................................... 222
LteCell::cellKind ...............................................................................................222
LteCell::cellhorizontalBeamwidth...................................................................223
LteCell::cellverticalBeamwidth .......................................................................223
LteCell::mainAntennaPositionConfidence.....................................................224
LteCell::mainAntennaPositionOrientationOfMajorAxis ................................225
LteCell::mainAntennaPositionUncertaintyAltitude .......................................225
LteCell:: mainAntennaPositionUncertaintySemiMajor .................................226
LteCell:: mainAntennaPositionUncertaintySemiMinor .................................226
LteCell::cellAzimuth.........................................................................................227
11.6.6 eNB Provide Correction of Tadv Type 1 to SAM ............................................................ 227
12 SUBSCRIBER AND EQUIPMENT TRACES ................................................................................ 228

12.1 TRACE CONCEPTS.................................................................................................................. 228
12.1.1 Management Based Trace Overview ............................................................................. 228
12.1.2 Signaling Based Trace Overview ................................................................................... 229
12.1.3 Comparison of Management Based Trace and Signaling Based Trace ........................ 230
12.1.4 Trace Session ................................................................................................................. 231
12.1.5 Trace Recording Session ............................................................................................... 232
Page 5/308
12.1.6 Subscriber and Equipment Traces 3GPP Compatibility ................................................. 233

12.1.7 Architecture of Subscriber and Equipment Trace ........................................................... 234
12.1.7.1 High Level Overview .................................................................................................. 234
12.1.7.2 eNB Internal Functional Blocks and Interfaces .......................................................... 234
12.2 MANAGEMENT BASED TRACE .................................................................................................. 235
12.2.1 TRACE CONFIGURATION PARAMETERS .................................................................. 235
12.2.1.1 Parameter for Activating a Management Based Trace .............................................. 236
CTg::isTraceActive ..........................................................................................236
12.2.1.2 Trace Reference......................................................................................................... 236
CTg::traceId ......................................................................................................237
12.2.1.3 Trace Session Name .................................................................................................. 237
CTg::callTraceSessionName ...........................................................................237
12.2.1.4 Trace Recording Session Reference ......................................................................... 237
12.2.1.5 List of Cells to be Traced for Management Based Trace........................................... 238
CTg::listOfTracedCells ....................................................................................238
12.2.1.6 Trace Depth................................................................................................................ 239
CTg::traceDepth ...............................................................................................240
12.2.1.7 Interfaces to Be traced ............................................................................................... 240
CTg::isS1MMETraced ......................................................................................241
CTg::isX2Traced...............................................................................................241
CTg::isRRCTraced ...........................................................................................241
12.2.1.8 IP Address of Trace Collection Entity......................................................................... 242
SubscAndEquipmentTraces::tceIpAddress ..................................................242
SubscAndEquipmentTraces::tceIpAddressv6 ..............................................243
SubscAndEquipmentTraces::tceUdpPort ......................................................243
12.2.1.9 Triggering Events for Event Based Trace .................................................................. 243
12.2.1.10 Effect of Overload on Management Based Call Trace............................................... 243
OverloadControl::ovLevelForCTInhibition ....................................................244
12.2.2 Running a Management Based Call Trace..................................................................... 244
12.2.3 Management Based Call Trace – Additional Detail ........................................................ 244
12.2.3.1 Event-Based Trace..................................................................................................... 247
CTg::trafficThreshold ......................................................................................248
CTg::rrcReestablishmentThreshold ...............................................................249
CTg::iratHOThreshold .....................................................................................250
12.2.4 Handling Management Based Trace Recording Session during Handover ................... 250
12.3 SIGNALING BASED CALL TRACE .............................................................................................. 251
12.3.1 Overview ......................................................................................................................... 251
12.3.2 Running a Signaling Based Trace from the ALU 9471 MME ......................................... 253
12.3.2.1 Start a Trace from the MME CLI ................................................................................ 254
12.3.2.2 Stop a Signaling Based Trace from the MME CLI ..................................................... 254
12.3.2.3 Querying Active Signaling Based Traces from the MME CLI .................................... 255
12.3.3 Signaling Based Trace Additional Detail ........................................................................ 255
SubscAndEquipmentTraces::isSignBasedCTEnabled .................................255
OverloadControl::ovLevelForS1TraceStartAction ........................................256
12.3.3.1 Handling Signaling Based Trace Recording Session during Handover..................... 257
12.4 INTERACTIONS BETWEEN MANAGEMENT BASED TRACE AND SIGNALING BASED TRACE ............. 257
12.5 CALL TRACE DATA ................................................................................................................. 258
12.5.1 RRC Interface Messages................................................................................................ 261
12.5.2 X2 Messages .................................................................................................................. 262
12.5.3 S1-AP Messages ............................................................................................................ 263
12.5.4 Additional Trace File Content ......................................................................................... 267
12.5.5 Post Processing of Call Trace Data................................................................................ 268
12.5.6 eNodeB snapshots and debug traces (dynamic) ........................................................... 269
OverloadControl:: ovLevelForDDTInhibition .................................................269
OverloadControl:: ovLevelForDTInhibition....................................................269
13 PER CALL MEASUREMENT DATA (PCMD) ............................................................................... 271

Page 6/308
13.1 PCMD AT THE MME .............................................................................................................. 273

13.2 PCMD AT THE ENB ................................................................................................................ 273
ActivationService::isPCMDEnabled ...............................................................274
OverloadControl::ovLevelForPCMDInhibition ...............................................274
ActivationService:: isPCMDorTraceMREnabled............................................275
13.2.1 PCMD Start Collection Triggers ..................................................................................... 276
13.2.2 PCMD Send Data Triggers ............................................................................................. 276
13.2.3 PCMD PARAMETERS ................................................................................................... 276
Enb::pcmdMode ...............................................................................................278
13.2.4 171159 PCMD enhancement - step2 ............................................................................. 278
14 PERFORMANCE MONITORING PARAMETERS ........................................................................ 282
Page 7/308
ENBEquipment::pmcGranularityPeriod .........................................................282
PerformanceManagement::csfbTo1XRttReported ........................................284
PerformanceManagement:: carrierAggregationReported ............................285
PerformanceManagement::customerSpare1Reported .................................285
PerformanceManagement::daisyChainingReported .....................................287
PerformanceManagement::eCICabsGenerationReported ............................287
PerformanceManagement::enhancedAnrReported ......................................287
PerformanceManagement::geranOrUtranReported ......................................288
PerformanceManagement::highPriorityAccessUserMgmtReported ...........288
PerformanceManagement::hRPDor1xRTTReported .....................................289
PerformanceManagement::inactivityBasedDrxReported .............................289
PerformanceManagement::interFreqEutraOtherFrameStructureMobility
Reported ...........................................................................................................290
PerformanceManagement::intraFreqMobilityToOpenMetroCellMobilityT
oHeNBReported ...............................................................................................290
PerformanceManagement::intraFreqMobilityToOpenMetroCellReported ..290
PerformanceManagement::ipFilteringReported ............................................291
PerformanceManagement::mbmsReported ...................................................291
PerformanceManagement::mceReported ......................................................292
PerformanceManagement::mobilityFailureReported ....................................292
PerformanceManagement:: mobilityFromHetNetCell ...................................292
PerformanceManagement::mobilityToHeNBReported .................................293
PerformanceManagement:: mobilityToHetNetCell ........................................293
PerformanceManagement::mobilityToUtranCsgSmallCellReported ...........293
PerformanceManagement::mobilityToUtranOpenSmallCellReported .........294
PerformanceManagement::mroIntraFreqReported .......................................294
PerformanceManagement::nonGbrMinRateReported ..................................294
PerformanceManagement::pDVReported ......................................................295
PerformanceManagement::perPRBMeasurementReported .........................295
PerformanceManagement::pMCounterEnhancementReported ...................295
PerformanceManagement::portRedundancyReported .................................296
PerformanceManagement::qam64Reported ..................................................296
PerformanceManagement::qciArpOnLineModificationReported.................296
PerformanceManagement::rrcConnectionReported .....................................297
PerformanceManagement::s1UsageOptimizationReported .........................297
PerformanceManagement::serviceFailureReported .....................................298
PerformanceManagement::spare1Reported ..................................................298
PerformanceManagement::speedDependentMobilityHomeCellsMobility
Reported ...........................................................................................................300
PerformanceManagement::speedDependentMobilityReported ...................300
PerformanceManagement::spsConfigReported ............................................301
PerformanceManagement::srvccToGeranReported .....................................301
PerformanceManagement::trafficShapingReported .....................................301
PerformanceManagement::transportPacketSizeCountersReported ...........302
PerformanceManagement::tTIBundlingReported .........................................302
PerformanceManagement::uEContextReported ...........................................303
PerformanceManagement::ulMIMOReported ................................................303
PerformanceManagement::uLNoiseReported ...............................................304
PerformanceManagement::utraLoadBalancingReported .............................304
PerformanceManagement::vlanReported ......................................................305
14.1 TIMER TO DETERMINE INACTIVE E-RAB ................................................................................... 305
Page 8/308
15 ANNEX – ABBREVIATIONS ......................................................................................................... 306
Page 9/308
TABLES
Table 1 : Licensed Features in Releases Prior to LR13.1 .....................................................................28
Table 2 : Licensed Features Added in LR13.1 ....................................................................................29
Table 3 : Licensed Features Added in LR13.3 ....................................................................................30
Table 4 : bCEM Only Features ..................................................................................................................38
Table 5: RET Subunit User Defined record in LA6.0.1 .....................................................................51
Table 6: RRH-1 Cross-connected failure with Transceiver Antenna Ports states in LA6.0 .............52
Table 7: Part of ALD table regarding retSubunitNumber and tmaSubunitNumber ..................55
Table 8: Part of ALD table regarding RET Log.Number and TMA Log.Number ......................... 57
Table 9: New eNodeB Alarms L156783 in LA6.0.1 .............................................................................60
Table 10: MIM/MIB Parameters Related to Receive Path Gain Compensation .......................... 62
Table 11: Configuring RFM Receive Path Gain Compensation .....................................................64
Table 12: Delay Compensation Capability Summary with DAS .....................................................69
Table 13: Sum-up of possible HW and SW configurations in LA6.0.0 tbc ...................................75
Table 14: Antenna Port Table for Configuration with 2x RRHs...................................................... 97
Table 15: Antenna Port Table for Redundancy ..................................................................................99
Table 16: cellAntennaPort Configurations for Band 1 ACC and Band 2 Non-ACC ................ 104
Table 17: Example of setting for eNodeB with 3 RRH, 1RET per RRH .......................................121
Table 18: Example of setting for eNodeB with 3 RRH, 1 dual TMA per RRH ............................ 124
Table 19: Usage of parameter aldScanEnable ................................................................................. 128
Table 20 : Feature L115241 Parameters for Minor and Major Overload Conditions ...................... 154
Table 21 : Features that are affected by Feature L115241 and the Associated Parameters ........154
Table 22 : Parameters introduced by feature L115805 .......................................................................155
Table 23 : State and Status Parameters for Maintenance Objects .................................................... 161
Table 24 : LA6.X Spare Parameter Usage ............................................................................................ 179
Table 25 : LR13.X Spare Parameter Usage.......................................................................................... 191
Table 26 : Comparison of Trace Types ..................................................................................................230
Table 27 : Subscriber and Equipment Traces 3GPP Compatibility ................................................... 233
Table 28 : E-UTRAN Trace Record Content ......................................................................................... 259
Table 29 : Traced Messages for Minimum Trace Depth .....................................................................261
Table 30 : RRC Traced Messages.......................................................................................................... 262
Table 31 : X2 Traced Messages ............................................................................................................. 263
Table 32 : S1-AP Traced Messages .......................................................................................................266
Table 33 : Non-Signaling Data Included in File for Subscriber and Equipment Trace .................... 267
Table 34 : Additional Data Included in File for Subscriber and Equipment Trace ........................... 268
Page 10/308
FIGURES
Figure 1: Capacity and Feature Licensing Overview .............................................................................23
Figure 2: Portion of RAN License Manager Report Screen ..................................................................32
Figure 3: Dual Band configuration ............................................................................................................38
Figure 4: Sector, Cell relation using AntennaPort & CellAntennaPort.................................................39
Figure 5: Dual Band Configuration with multi carrier RRHs ..................................................................41
Figure 6: Generic Tri Carrier configuration .............................................................................................. 45
Figure 7: Up to nine cells (one frequency) topologies............................................................................46
Figure 8: AISG entities overview ...............................................................................................................50
Figure 9: Usage of multiple ALDs on one RRH ...................................................................................... 53
Figure 10: Overview of the usage of TMA and RET (600-05-17, 600-05-12, L115287)...................54
Figure 11: Daisy-chaining over multiple RRHs on one eNB ( 600-05-07, L115297)......................... 56
Figure 12: Example configuration of a remotely managed ALD ........................................................... 58
Figure 13: Configuration with 3 ALD Type RET+TMA in Series with 3RE .........................................58
Figure 14: Dual Band with single BBU .....................................................................................................59
Figure 15: ALD Bus Initialization ...............................................................................................................62
Figure 16: Path Gain budget on RRH ......................................................................................................64
Figure 17: Path Gain budget on TRDU ....................................................................................................65
Figure 18: Antenna without and with DAS ............................................................................................... 66
Figure 19: Delay Budget with DAS (SISO example) ..............................................................................68
Figure 20: Delay Budget management with bCEM ................................................................................71
Figure 21: Functional block diagram of RRH with RDEM for 4-Rx Diversity ......................................73
Figure 22: Typical RDEM Mounted on the Side of a Remote Radio Head .........................................74
Figure 23: Simplified view of RRH-based Hardware and associated delays when DAS is not used
(cell view, case of 1 transmit antenna per antenna node) ............................................................. 85
Figure 24: Simplified view of RRH-based Hardware when DAS is used (cell view, case of 1
transmit antenna per coverage area) ............................................................................................... 85
Figure 25: Simplified view of TRDU-based Hardware when DAS is not used (cell view, case of 1
Figure 26: Simplified view of TRDU-based Hardware when DAS is used (cell view, case of 1
Figure 27: NEM Commissioning Screen for RFM Location ..................................................................89
Figure 28: Algorithm for OAM Diversity Imbalance Alarm .....................................................................94
Figure 29: NEM Commissioning Screen for Entering Sector Number ................................................95
Figure 30 : NEM Commissioning Screen for looking at the Port Number matching with
assignedPortNumber .......................................................................................................................... 96
Figure 31 : Three Sector Configuration with ‘2x’RRHs ..........................................................................97
Figure 32: NEM Commissioning Screen for Antenna Cross Connect .................................................98
Figure 33: NEM Commissioning Screen for looking at the Port Number matching with
assignedPortNumber, in case Antenna Cross Connect ................................................................ 98
Figure 34: Three Sector Configuration with RRH redundancy ............................................................. 99
Figure 35: Three Sector Configuration with RRH redundancy with parameters .............................. 100
Figure 36: Physical Antenna Connection for Dual Band in Mixed ACC ............................................ 102
Figure 37: NEM Commissioning Screen for Entering Antenna Labels.............................................. 106
Figure 38: NEM Commissioning Screen for Entering Antenna Port Label Values .......................... 107
Figure 39: NEM Commissioning Screen for Entering DL Antenna Path Delay................................ 111
Figure 40: NEM Commissioning Screen for Entering TX and RX Used Parameter Values on the 8
Ports .................................................................................................................................................... 112
Figure 41: NEM Commissioning Screen for Entering Uplink Antenna Path Delay Value .............. 115
Figure 42 : NEM Commissioning Screen for Entering VSWR Parameters.......................................119
Figure 43 : NEM Commissioning Screen for Entering RET Log.Number Parameters.................... 120
Figure 44 : NEM Commissioning Screen for Entering retSubunitNumber Parameters .................. 120
Figure 45 : NEM Commissioning Screen for TMA Log.Number Parameters ...................................124
Figure 46: Illustration of Typical Sector Arrangements for an eNodeB ............................................. 134
Figure 47: sectorNumber value with 6 sectors (2 modems) ............................................................... 135
Figure 48 : NEM Commissioning Screen for Entering maxTransportFiberDelayLengthCategory
Parameters .........................................................................................................................................137
Page 11/308
Figure 49 : Principal Elements for UE Position Location Support ...................................................... 198

Figure 50 : Illustration of UE measuring the SFNs synched among eNBs .......................................200
Figure 51 : External Delays to be compensated for OTDOA Synchronization.................................200
Figure 52 : Illustration of UE measuring RSs that are synchronized among eNBs ......................... 204
Figure 53 : eNB architecture to support OTDOA & ECID. In red are the feature tasks. .........221
Figure 54 : Call flow for emergency call in Control Plane. ............................................................ 222
Figure 55 : Illustration of providing CorrectionForTadvType1 to support geolocation .........227
Figure 56 : Trace Session (TS32.421) ...................................................................................................231
Figure 57: Trace Recording Session (TS32.421) ................................................................................. 232
Figure 58: eNB Subscriber and Equipment Trace High Level Diagram ............................................ 234
Figure 59: eNB Call Trace Functional Diagram .................................................................................... 235
Figure 60: Management Based Call Trace ............................................................................................ 245
Figure 61: Signaling Based Activation/Deactivation (TS32.421) ........................................................ 252
Figure 62: Signaling Based Trace Activation in LTE ............................................................................ 253
Figure 63: PCMD Data Collection Diagram ........................................................................................... 272
Figure 64: MME GUI for PCMD............................................................................................................... 273
Figure 65: PCMD Record Formation and Content ............................................................................... 277
Figure 66: SAM Performance Management Screen showing pmcGranularityPeriod Parameter
Value (15 minutes) ............................................................................................................................ 282
Page 12/308
1 INTRODUCTION
1.1 OBJECTIVE
The objective of this volume is to describe from an engineering point of view the
Miscellaneous Features and related parameters.
This includes a system description, configuration aspects, and engineering
recommendations.
1.2 SCOPE OF THIS DOCUMENT

Releases LR13.1 and LR13.3 for the Frequency Division Duplex (FDD)
implementation. Information that is added in this edition to support Releases
LR13.1 and LR13.3 are colored with a gray background as illustrated by this
paragraph
References to LA0.x, LA1.0, LA1.1, LA2.0, LA3.0, LA4.0, LA5.0 and LA6.0 in this
For information concerning parameters for an LTE release earlier than LR13.x,
Volume and the summary descriptions of features have been deleted.
Each individual volume contains a list of features that are described in
that volume. In addition, the listings of new, modified, deleted parameters
and parameters that are not described in LPUG have been deleted from
the Appendices. The material related to feature licensing has been
moved to new Volume 2 (see below).
• Previous issues of LPUG included Volume 2 (LTE Overview). This
material has been deleted from the current issue
added. This volume incorporates some of the material that was
previously found in Volume 1 (Feature Licensing), Volume 7 (Hardware
oriented parameters), and Volume 8.
• Material that describes the LTE channels has been moved from Volume
4 (RRM) to Volume 3 (LTE Air Interface)
• Material concerning Location Based Services that was previously
Page 13/308
included in Volume 8 has been moved to Volume 5 (Call Management)

deleted.


LPUG is written with the assumption that features that are scheduled for the
LR13.x delivery release become available as initially planned.
Engineering Recommendation: Modem Type in LR13.x
Note that three types of modem are available in LR13.x: the eCEM, bCEM, and
the MET3C1 for Metro. Some features are modem-type specific and/or their

separate document.
Page 14/308
The Femto eNodeB or Home eNodeB products are out of scope of this
document, though coexistence with these types of equipment is supported.
All engineering information, algorithms description and parameters values
provided in this document are strictly related to “standard” Alcatel-Lucent eNodeB
products, including Macro and Metro eNodeB, unless explicitly mentioned.
For LPUG editions supporting release LA4.0 and later releases, the transport
related parameters that were previously described in LPUG Volume 7 were
moved to the Transport Engineering Guide (TEG). Please refer to that document
for information on transport-related parameters.
1.3 RELATED FEATURES

The system aspects described in this volume are related to the following features:
LA1.1
Feature
Feature Title
Number
L78706 eNB Platform OA&M
L90210 Lower 700MHz RRH solution configurations
LA2.0
Feature LA 2.0
Feature Title
Number Drop
L90211 RRH2x40-07(upper) HW Requirements 2.0.0
LTE band XIII (Upper 700MHz) RRH
L92846 2.0.0
configurations for LA2.0
LTE band VII (2600MHz) eNodeB configurations
L98482 2.0.0
in LA2.0
LTE band XIII (Upper 700MHz) eNodeB Indoor
L98483 2.0.0
and Outdoor solution configurations in LA 2.0
L92129 20 MHz bandwidth support on eNodeB 2.0.2
2.0.2
L100895 LTE R-OCM support configuration in LA2.0
L108271 VSWR Testing Support 2.0.2
LA3.0
Page 15/308
Feature
Feature Title LA3.0 Drop
Number
LTE band VII (2600MHz) eNodeB configurations in
L106114 3.0.2
LA3.0
L106120 LTE 800 MHz EDD eNodeB configurations in LA3.0 3.0.2
LTE band IV (AWS) eNodeB RRH2x configurations 3.0.0
L106125
in LA3.0
LTE band XII (Upper 700 MHz) eNodeB 3.0.2
L106227
Configurations in LA3.0
LTE band XVII (Lower 700MHz) eNodeB 3.0.0
L109437
configurations
L106343 Supported BBU configurations 3.0.0
L106909 D2UV5 introduction 3.0.1
L96043 LTE-FDD/W-CDMA eCEM-U 3.0.0
L106223 AISG 2.0 Support (TMA&RET) for LA3.0 3.0.0
L92812 LTE Antenna Cross Connect capability in LA3.0 3.0.2
RRH 2x40W Band VII (RRH2x40W-26) 3.0.2
L106126
Requirements
LA4.0
Feature LA4.0
Feature Title
Number Drop
L106228 PCS Band Dual Tech RRH4x40 HW Requirements LA4.0.0
L114561 PCS Band Distributed eNB configurations LA4.0.0
L114665 LTE band VII (2600MHz) eNodeB configurations LA4.0.0
L 114788 LTE 800MHz EDD eNodeB configurations LA4.0.0
LTE band XVII (Lower 700MHz) eNodeB LA4.0.0
L114811.1
configurations
L114812.1 LTE band IV (AWS) eNodeB RRH2x configurations LA4.0.0
L114839 LTE PCS Band ROCM configurations LA4.0.0
L114840 LTE AWS Band ROCM configurations LA4.0.0
L115105.1 Supported BBU configurations - LA4.0.1/TLA4.0 LA4.0.0
LTE band XII (Lower 700MHz) eNodeB LA4.0.0
L115121
configurations
L114792.1 eNodeB OAM Enhancements LA4.0.0
L114909.1 AISG2.0 support LA4.0.0
Compatibility check between configuration and LA4.0.0
L115410.1
modem card
L115461 LTE / CDMA Dual Technology OAM support LA4.0.0
LTE RRH Antenna Cross Connect Capability LA4.0.1
L115158
Support in LA4.0.1
LTE Band XIII (Upper 700 MHz) eNodeB LA4.0.1
L114813.1
Configurations
LTE Band XIV (700MHz Upper D block and PS) LA4.0.1
L114815
eNodeB configurations
L102998 Integration of LTE BBU in Legacy 2G/3G Cabinets LA4.0.1
LTE (TRDU Based) in MBI/MBO Cabinet for 800 LA4.0.1
L115265
and 2600MHz
L115863 Customer wants to mount 2 eNB compact outdoor LA4.0.1
Page 16/308
cells in one dual high floor stand

TRDU2x40 Band 14 (Public Safety and D Block) LA4.0.1
L104834
HW Requirements
Low Power 700MHz eNB /DAS Support LA4.0.2
L92811.1
Configuration
Support Fiber delay (or any delay between modem LA4.0.2
L100622
and RF head) in LTE
LTE band VII (2600MHz) eNodeB configurations in LA4.0.2
L114665
LA4.0
L103895.1 ECID and LPP protocol support (trial) LA4.0.2
Solution Level FID for 1900Mhz support of LTE for LA4.0.2
L115695
Sprint
L97084.1 eNB Synchronization support for OTDOA (Trial) LA4.0.2
Tunable Antenna Path Delay between Radio LA4.0.2
L115670
(RRH/TRDU) and DAS
eNB support of OTDOA Hearability Enhancement LA4.0.2
L115435.1
(Trial )
L106226 AWS RDEM HW LA4.0.2
L114790 LTE/GSM Dual Technology OA&M using MC-TRX LA4.0.3
LTE band III (1800MHz) eNodeB configurations in LA4.0.3
L114789
LA4.0 - MC-TRX MSR only
L92853 LTE Requirements for MC-TRX 1800MHz LA4.0.3
L113600 1800MHz MC-RRH in LTE only mode LA4.0.3
L114791 TRDU2x60-26 Requirements LA4.0.3
OAM to support 1800MHz MC-RRH In LTE Only LA4.0.3
L115283
Mode
LA5.0
LA5.0
Feature Number Feature Title
Drop
LTE RRH Antenna Cross Connect 5.0.0
L115158.1
Capability Support in LA4.0.1
Support for SAM Provisioning of Beta 5.0.0
L115221
Parameters
L115248 BBU Configurations in LA5.0 5.0.0
Band 12 & 17 (Lower 700 MHz) LTE 5.0.0
L115287
eNodeB Configurations in LA5.0
Band 13 (Upper 700 MHz) LTE eNodeB 5.0.0
L115288
Band 14 (Upper 700MHz Public Safety & D 5.0.0
L115289
Block) LTE eNodeB Configurations in LA5.0
Band 4 (AWS) ROCM LTE eNodeB 5.0.0
L115294
4Rx Receive Diversity over 5MHz BW FDD 5.0.0
L115562.1
(Tracking FID for eCEM)
Band 2 (PCS) ROCM LTE eNodeB 5.0.0
L115614
Band 3 (1800MHz) LTE eNodeB 5.0.0
L115292
Band Class 25 (PCS) LTE eNodeB 5.0.1
L115295
Page 17/308
LTE HW Requirements for RRH4x40 – 5.0.1

L115512
19(PCS) 65Mhz (Band 25)
Compatibility check between configuration 5.0.0
L115657
and modem card
Compatibility check between configuration 5.0.0
L115657.1
and modem card
Support for dual-band eNodeB with two
L115616 5.0.2
modems TBC
Single antenna transmit scheme (bCEM 5.0.2
L84815.0
parity)
Support for SAM Provisioning of Beta 5.0.2
L115221.1
Parameters (L115221 on eCEM)
Support Fiber delay (or any delay between
L100622.0 5.0.2
modem and RF head) in LTE
ECID location method and LPP/LPPa
L103896/L103896.1 location control plane protocol support for 5.0.2
Commercial Deployment
LA6.0
Feature
Number
Band 25 (PCS+G) LTE eNodeB Configurations in LA6.0.0
134310
LA6.0
157468 lightRadio Cabinet LTE LA 5.0.2/6.0 LA6.0.0
Bands 12 and 17 (Lower 700 MHz) LTE eNodeB LA6.0.0
L115298
159276 Support for RRH2x60-850 (LTE Only) LA6.0.0
Band 5 (850) LTE-only eNodeB Configurations in LA6.0.0
159277
LA6.0
L115235 BBU Configuration for T/LA6.0 LA6.0.0
Band 13 (Upper 700 MHz) LTE eNodeB LA6.0.0
L115299
Band 14 (Upper 700MHz Public Safety & D Block) LA6.0.0
L115300
LTE eNodeB Configurations in LA6.0
Band 20 (800MHz EDD) LTE eNodeB LA6.0.1
L115301
configurations in LA6.0
Band 4 (AWS) LTE eNodeB Configurations in LA6.0.0
L115304
LA6.0
Band 4 (AWS) ROCM LTE eNodeB Configurations LA6.0.0
L115305
in LA6.0
Band 2 (PCS) ROCM LTE eNodeB Configurations LA6.0.0
L115306
in LA6.0
Band 7 (2600MHz) LTE eNodeB configurations in LA6.0.0
L115309
LA6.0
159253 MRO Metro Radio Outdoor Hardware LA6.0.0
159254 MRO Metro Radio Outdoor Software LA6.0.0
159255 MRO Metro Radio Outdoor Configuration 700 LA6.0.0
L115307 Band 2 (PCS) LTE eNodeB Configurations in LA6.0 LA6.0.1
156783 TMA/RET with AISG 2.0 Enhancements in LA/TLA6 LA6.0.1
L115868 1800MHz MC-TRDU in LTE Only Mode LA6.0.1
132037 LTE Multiband Configurations for LA6 LA6.0.1CL1
L115303 Band 3 (1800MHz) LTE eNodeB Configurations in LA6.0.1CL1
Page 18/308
LA6.0
L115938 Dual-Carrier Support on one band LA6.0.1CL1
LA13.1 HW Related
Feature LA13.1
Feature Title
Number Drop
163455 eCEM support in LA7-DECP LR13.1
L115850 eCCM2-controlled introduction in FDD LR13.1
Antenna Cross Connect (ACC) on Dual Band eNB
171049 Configuration - Mixed Mode LR13.1
LA13.3 HW Related
Feature LA13.3
Feature Title
Number Drop
166877 eCCM2 for FD-LTE LR13.3
L115808 Tri-Carrier BBU LR13.3
Nine cells (one frequency) support on three
L115401
modems LR13.3
168155 Factory, Commissioning, 3GPP 36.104/141
Conformance, and Customer Acceptance Test
Support for Macro Cells (LR13.3) LR13.3
LA13.3
Feature LA13.3
Feature Title
Number Drop
Neighbor cell classification and mobility counters for
170745
HetNet LR13.3
171159 PCMD enhancement - step2 LR13.3
160847 Commercial CA LR13.3
170733 Support of ECID and OTDOA by 9764 MCO v1 and
OTDOA PRS Interference avoidance for MRO LR13.3
173501 Mobility measurements range extension for
Emergency Calls LR13.3
In general these hardware arrangement features do not cause the addition of any
new parameters, so the feature numbers are not associated with any parameter.
Whenever possible and/or necessary, a reference is given to the feature in the
parameter tables.
Page 19/308
2 RELATED DOCUMENTS AND PREREQUISITES

2.1 LPUG VOLUMES
[Vol. 1] LPUG Introduction
[Vol. 2] Miscellaneous Features and Parameters
[Vol. 6] Mobility

[R01] ITU-T X.731, CCITT, “Systems Management – State Management
Function”, January, 1992
[R02] GPS Receiver/CT-5510 Application Note 1 PPS Features
http://www.icdistribution.net/download/AN07CT55100-020.pdf
[R03] Common Public Radio Interface (CPRI); Interface Specification, V4.1,
2009-02-18
http://www.cpri.info/downloads/CPRI_v_4_1_2009-02-18.pdf
[R04] LTE/DCL/APP/034072 LTE Transport Engineering Guide
[R05] MGR/CID/LR/DD 9768 Metro Radio Outdoor – B13 700MHz – Product
Description
[R06] RCD Release Configuration Document
[R07] PEG Product Engineering Guide
[R08] UMTS/BTS/DD/035750 eCCM2 Hardware Design Specification

[R09] 5620 SAM LTE RAN User Guide, 3HE 06506 AAAC TQZZA
[R10] 3GPP TS 32.422 Release 9 V9.2.0 (2010-09) – Trace control and
configuration management
[R11] 3GPP TS 32.423 Release 9.1.0 (2010-03) Trace data definition and
management
[R12] 3GPP TS 36.413: “Evolved Universal Terrestrial Radio Access (E-UTRA);
S1 Application Protocol (S1AP)”. V9.6.1 (2011-05)
[R13] 3GPP TS 36.423: “X2 Application Protocol Release 8” V9.6.0 (2011-04)
[R14] 9471 Mobility Management Entity, Operations, Administration, and
Maintenance, 418-111-2010
[R15] 3GPP TS 32.421 Release 9 V9.1.0 (2010-03) - Trace concepts and
requirements
Page 20/308
[R16] Per Call Measurement Data Reference Guide, Release 418-111-009

[R17] 9412 eNodeB Counters Reference Guide, 418-000-035
User Equipment (UE) radio transmission and reception”. ( 2010-09 )
2.3 PREREQUISITES FOR READING THIS VOLUME

Before reading this volume, the reader should read the Introduction (Volume 1).
Volume 1 provides an explanation of the presentation and conventions that are
used throughout the document (common to all volumes).
Page 21/308
3 FEATURE AND CAPACITY LICENSING

RAN-based Licensing provides two capabilities that can be used to tailor an ALU
supplied RAN to a specific operator’s needs:
o Feature Licensing allows an LTE operator to order (and pay for)
only the specific optional features that they want.
o Capacity Licensing allows an LTE operator to order eNB
hardware components with a reduced activated capacity. The
operator can subsequently purchase licenses to add capacity
under software control (with no hardware change) as the LTE
network grows.
The optional feature and the software capacity licenses that can be activated are
ordered in the form of Tokens (also called RTUs = Right To Use Licenses). The
quantity of Tokens that is used for each feature or capacity unit is:
o incremented as each feature or capacity unit is enabled for an

eNB (or cell for features or capacity units that are activated on a
per-cell basis) or
o decremented as each feature or capacity unit is disabled for an

eNB (or cell).
When the number of available Tokens for a feature or increment of capacity
reaches zero, no further activations are allowed.
3.1 FEATURE AND CAPACITY LICENSING – HIGH LEVEL

DESCRIPTION
Following feature or capacity purchase (Purchase Order) for a specific number of
eNB or cell optional features or capacity resources, licenses are created for each
feature or capacity unit with the ALU Licensing tool (also called LKDI). The
Licenses are available through an encrypted file, protected by a digital signature.
The license (file) is installed into SAM using an application called RAN License
Manager (also referred to as RAN-LM in this document). This license file creates
at SAM a pool of Tokens (RTUs) that are available for all eNBs managed by SAM.
The operator can then distribute the pool of available optional feature or capacity
tokens among all eNB(s) via specific OAM parameters (also called Licensing
Parameters). This process is illustrated in Figure 1.
Page 22/308
SAM/RAN-
Capacity or Feature License file created and

Tokens (RTUs) entered into SAM/RAN-LM
purchased by operator
eNB(s) feature activation and

capacity are controlled via
specific licensing parameters
eNode eNode eNode eNode
Figure 1: Capacity and Feature Licensing Overview
These Licensing parameters are checked for each licensed resource by SAM
(RAN-LM) anytime a change is made so that the global license capacity provided
by the License file is not exceeded
If the above mentioned SAM check fails for one of the licensed resources, the
configuration of that specific optional feature or capacity element is blocked, the
configuration work-order is rejected, and no changes covered by that work order
will be activated for any eNB. No activations of the optional feature or capacity
element will be allowed until the number of available tokens exceeds the number
of activations.
The following eNB capacity elements are managed by Capacity Licensing:
• Transmission Power (per cell)
• Number of Active users per eNB
• Allocated Operating Bandwidth (per cell)
Additional detail about Capacity Licensing and its implementation can be found in
Volume 4.
Page 23/308
The optional features that are managed in earlier releases by Feature Licensing
are shown in Table 1, and the features that are added in LR13.1 are indicated in
Table 2.
WPS eNB License

Associated Feature LPUG Volume
Activation Parameter
Feature(s) Number and Notes
Parameter Name
Automatic
Neighbor
Relation L81872
Configuration and Volume 6
lteIntraFrequ
Optimization
encyAnrEna LTEanrEnable One license
Automatic
bled covers all
Configuration of L81873
features listed
Physical Cell ID
Full support of
L108172
Intra-LTE ANR
Volume 5
eNB Based PCI
isSonPciAllo
LTEisSonPciAll Allocation,
cationEnabl L108258 Requires
ocationEnabled Conflict Detection
ed 108172 ANR
and Correction
feature.
Per Call
isPCMDEna LTEisPCMDEna
Measurement L92646 Volume 2
bled bled
Data
Volume 2
Without license,
the operator
must manually
upgrade the SW
isEnbSelfCo LTEisENBselfC Self Configuration
L96759 and then update
nfigAllowed onfigAllowed of eNB Phase2
eNB
configuration
without
automatic
sequence from
XMS
isInterFreqE Intra-LTE Inter-
LTEisInterFreqE
utraSameFr Frequency
utraSameFrame
ameStructur Mobility for L103792 Volume 6
StructureMobilit
eMobilityAllo FDD<>FDD and
yAllowed
wed TDD<>TDD
Common Mobility
isServiceBa
LTEisServiceBa Management
sedTrafficSe
sedTrafficSegm Framework L106136 Volume 6
gmentationA
entationAllowed (eMCTA -Phase
llowed
1)
LTE-to-HRPD Volume 6
isMobilityTo LTEisMobilityTo Mobility -- cell
L82728
HrpdAllowed HrpdAllowed reselection and One license
redirection with covers both
Page 24/308
WPS eNB License

Parameter Name
no eHRPD features
measurement
Enhancement of
LTE-to-HRPD
Mobility -
L84876
redirection with
eHRPD
measurement
EUTRAN-to-
UTRAN Inter-
RAT Mobility -- L76498 Volume 6
isMobilityTo Cell reselection
LTEisMobilityTo
UtranAllowe and Redirection One license
UtranAllowed
d EUTRAN-to- covers both
UTRAN Inter- features
L96372
RAT Mobility --
PS Handover
EUTRA-to-
GERAN Inter-
RAT Mobility -- L84807 Volume 6
isMobilityTo Cell Reselection
LTEisMobilityTo
GeranAllow and Redirection One license
GeranAllowed
ed EUTRA-to- covers both
GERAN Inter- features
L96371
RAT Mobility --
NACC
Volume 6
isCsFallback LTEisCsFallbac CS Fallback to
Requires
ToUtraAllow kToUtraFDDAllo UTRA for Voice L92025
support of
ed wed Calls
76498, 96372
and 106136.
Volume 6
isCsFallback LTEisCsFallbac CS Fallback to
Requires
ToGeranAllo kToGeranAllow GERAN for voice L92026
support of
wed ed calls
84807, 96371
and 106136.
Enhanced Volume 6
isCsfbEnhan LTEisCsfbEnha
Redirection
cedRedirecti ncedRedirection L116051
based CSFB to Requires
onEnabled Enabled
UTRAN Feature 92025
Transport IPsec Transport
L92078
with IKE v2 Engineering
Security Support Guide [R04]
isIPsecEnab LTEisIpsecEnab
of IPsec
led led
enhancement L101808 One license
above Ipv4 and covers both
Ipv6 features
Page 25/308
WPS eNB License

Parameter Name
CS Fallback to
1XRTT for Voice
isCsfbTo1x LTEisCsfbTo1x
Calls-- Dual
RttForDRxU RttForDRxUEall L92024.1 Volume 6
receiver UE
Eallowed owed
Standard based
solution
Commercial
isCmasEnab LTEisCmasEna Mobile Alert
L92127.1 Volume 5
led bled System (CMAS)
support
maxNbOfDa Up to 4, 8
LTE is 4, 5, 6, 7, 98840
taBearersPe Simultaneous Volume 4
8 z Bearers 92483
rUe Bearers per User
eNB
Synchronization L97084.1
support for L101821
isGeoLocPh
LTEisGeoLocPh OTDOA
aseSyncAllo Volume 4
aseSyncAllowed eNB support of
wed
OTDOA L115435.
Hearability 1
Enhancement
Support Fiber
delay (or any Volume 2
isFiberDelay LTEisFiberDela
delay between L100622 Licensed Per
Allowed yAllowed
modem and RF Cell
head) in LTE
Service, and load
isOffLoadUp
LTEisOffLoadU based handover
onReactiveL L103892.
ponReactiveLoa behavior support Volume 6
oadControlA 1
dControlAllowed (eMCTA -Phase
llowed
2)
ECID and LPP
isEcidSuppo LTEisEcidSupp L103895.
protocol support Volume 2
rtAllowed ortAllowed 1
(trial)
LTE max 2, 3, 4, eUTRAN Sharing
maxNbPlmn L104835
5, 6 basics: MOCN Volume 5, 6,
ForMocnLic L104836
PlmnForMocnLi with shared LTE and TEG
ense L115680
cense spectrum
ANR Support for
utraAnrEnab LTEutraAnrEna Inter RAT L108084.
Volume 6
led bled Neighbors 1
(UTRAN)
Volume 3
If
isRohcAllowed=
True, then
RoHC v1 Support
LicenseMngtSy
for VoIP,
isRohcAllow LTEisRohcAllow L110547. stem::isVoIPEn
Voice over LTE
ed ed 1 abled = True.
for Commercial
If
Launches
isRohcAllowed=
False, then
LicenseMngtSy
stem::isVoIPEn
Page 26/308
WPS eNB License

Parameter Name
abled= False.
CSFB
Volume 6
isCsfbEnhan LTEisCsfbEnha enhancement to
Requires
cedRedirecti ncedRedirection UTRAN/GERAN-- L114190.
Feature 92025
onAndPsHo AndPsHoAllowe enhanced 1
or 92026 or
Allowed d Redirection and
both
PSHO
Volume 4
L115239.
isSpsConfig LTEisSpsConfig Commercial Requires
1
Allowed Allowed VoLTE with SPS 110547.1
162790
Trial Only
lteInterFrequ
LTElteInterFreq
encyAnrFor
uencyAnrEnable Inter-Freq ANR L115546 Volume 6
UETestEnab
d
led
Tunable Antenna
Path Delay Volume 2
isDasDelay LTEisDasDelay
between Radio L115670 Licensed Per
Enabled Enabled
(RRH/TRDU) and Cell
DAS
L106223
isAisgAllowe LTEisAisgAllow L116501
AISG2.0 support Volume 2
d ed L114909.
1
Volume 4
transmission LTEis1Antenna Single antenna
L84815 Licensed Per
Mode=tm1 TransmitMode transmit scheme
Cell
isIncomingH
LTEisIncomingH
oToReserve
oToReservedCe L115458 on
dCellBased L115458 Volume 6
llBasedOnSpidA eCEM
OnSpidAllo
llowed
wed
RLF monitoring
isRlfMonitori LTEisRlfMonitori and recovery
L115361 Volume 6
ngAllowed ngAllowed improvement
(Step 1)
Enhanced
isEnhanced LTEisEnhanced
measurement
Measureme MeasurementPa
parameter L115204 Volume 6
ntParameter rametersEnable
support for
sEnabled d
mobility
isInterFreqL
LTEisInterFreqL
oadBalancin Inter-freq Load L115223-
oadBalancingFe Volume 6
gFeatureEn Balancing 1
atureEnabled
abled
isTransport LTEisTransport
Transport CAC L115372 TEG
CacAllowed CacAllowed
isCertificate LTEisCertificate Security IPsec

L101812 TEG
Enabled Enabled with Certificates
Page 27/308
WPS eNB License

Parameter Name
Support for dual-
Volume 5 and
band eNodeB L115616
Volume 2
isDualCarrie LTEisDualCarrie with two modems
rEnabled rEnabled Dual carrier
support on one L115938 Volume 5
band
isSIB3Resel
LTEisSIB3Resel
ectionAutom Load based Idle
ectionAutomatio L115203 Volume 6
ationEnable Mode mobility
nEnabled
d
SRVCC Support
isSrvccToUt LTEisSrvccToUt
to UTRAN- L92126 Volume 6
raAllowed raAllowed
FDD/TDD
eUTRAN Sharing
LTEisXGwcnMo
maxNbPlmn in GWCN
bileNetworks L115244
ForGwcnLic architecture - up Volume 5
Where X=2, 3, L115680
ense to X PLMN
4, 5, 6
Where X=2, 3, 4
Table 1 : Licensed Features in Releases Prior to LR13.1
WPS eNB
License Optional Feature Feature LPUG Volume
Activation
Parameter Name Name Number and Notes
Parameter
MAC DRx State
isInactivityB
LTEisInactivityBas Mgt under
asedDrxEn L101843
edDrxEnabled Inactivity
abled
Conditions
Volume 6
One license
Intra LTE
enables both
FDD/TDD L101815
isInterFreqE HO and
LTEisInterFreqEut Handover
utraOtherFr Reselection
raOtherFrameStru features
ameStructur
ctureMobilityEnabl
eMobilityEn
ed Intra- LTE Inter
abled
Band Cell
L103790
Reselection for
TDD<->FDD
isIpFiltering LTEisIpFilteringEn Security DoS

L114382 TEG
Enabled abled Attack Protections
Page 28/308
WPS eNB
Activation
Parameter
eMBMS
isMceDistrib
LTEisMceDistribut Commercial with
utedModeE 158990
edModeEnabled distributed MCE
nabled
(integrated in eNB
isNonGbrMi Minimum bitrate

LTEisNonGbrMin
nRateEnabl enforcement for L115698
RateEnabled
ed non-GBR
isQciArpOn Bearer
LTEisQciArpOnLi
LineModific Characteristics
neModificationEna L115644
ationEnable online
bled
d modifications
isRel8CsfbT
LTEisRel8CsfbTo Enhanced CSFB
o1XRttEnab 134791
1XRttEnabled to 1xRTT
led
Target cell load
isUtraLoad
LTEisUtraLoadBal consideration for
BalancingE 155912
ancingEnabled IRAT mobility to
nabled
WCDMA
isMroIntraFr LTEisMroIntraFre Licensed Per
MRO Counters L103177
eqEnabled qEnabled Cell
isNarrowba
LTEisNarrowband Generalized OP- Licensed Per
ndSRSuseE L114492
SRSuseEnabled PUCCH Cell
nabled
RACH
Improvements -
pRACHPre LTEpRACHPream
RACH burst Licensed Per
ambleForm bleFormat3Enable L115767
format 3 support Cell
at d
(up to 70 km
radius)
Table 2 : Licensed Features Added in LR13.1
WPS eNB
Activation
Parameter
isEnhanced
Overload Control -
OverloadCo isEnhancedOverlo
Outdated RRC 156132
ntrolEnable adControlEnabled
messages
d
Nine cells (one

isIncrement
isIncrementalSect frequency)
alSectorEna L115401
orEnabled support on three
bled
modems
Page 29/308
WPS eNB
Activation
Parameter
isPCMDorT PCMD
isPCMDorTraceM
raceMREna enhancement - 171159
REnabled
bled step2
isTriCarrier isTriCarrierEnable
Tri-carrier BBU L115808
Enabled d
Table 3 : Licensed Features Added in LR13.3
Rule: eNB Feature Licensing
All features are licensed on a per-eNB basis unless otherwise noted in

Table 2 and Table 3. The features that are licensed on a per cell basis are
noted as “Licensed Per Cell” in the “LPUG Volume and Notes” column.
Page 30/308
3.2 LICENSING CONFIGURATION PRINCIPLES

Licensing works in a different manner for optional feature licenses and capacity
licenses.
For optional features, there is an activation parameter that is used to enable each
optional feature (typically on a per-eNB basis), and the number of activations for
each feature is counted across all eNBs by SAM. Activation for each feature is
allowed as long as licenses (Tokens) are available for that feature. Activation for
each feature is on a per-eNB basis or a per-cell basis, so activating the licensed
feature on an eNB or a cell consumes one token.
For capacity licensed resources, the licensing configuration is based on

• a conversion of configuration parameters for each licensed resource to
resource increments;
• the required resource increments are then decremented from the

available tokens for each capacity licensed resource in the licensing
system.
Configuration parameters are eNB parameters that directly configure the

maximum number of the resource elementary units that will be accepted by or
used by the eNB. These parameters are configurable per resource and
associated a NE (eNB or Cell). Configuration parameters are used by the eNB for
the resources admission/configuration control.
For example, the maximum number of simultaneous active users for an eNB is
specified as an integer between 0 and 6000. However, capacity licenses for the
maximum number of simultaneous users (maxNbOfCallCapacityLicensing) are
offered in increments of 8 users – so each token allows an increment of 8 users.
When a new eNB is added, then internally within SAM, the value of parameter
maxNumberOfCallPerEnodeB for that eNB is divided by 8, rounded up, and
then the resulting number of resource increments is decremented from the
available pool of tokens (licenses) for the maximum number of simultaneous
users.
Specific SAM checks are implemented to ensure alignment between
Configuration Parameters and the number of available tokens for each feature or
capacity resource.
As each optional feature or each increment of capacity is enabled or disabled for
an eNB, a token counter in SAM is either incremented or decremented for each
license that is used or returned.
Licenses can have an expiration date, and a license file can be replaced with a
different license file. Expiration of a license or replacement of a license file can
lead to violations of a license (more activations than available tokens). When this
occurs, the licensed features with violations will continue to work on eNBs where
they were previously activated. However, no additional activations of those
features will be allowed on any eNB as long as the fault exists, and configuration
changes will not be allowed on the eNBs where the features with violations are
active.
Page 31/308
An illustration of the SAM RAN License Manager screen can be seen in Figure 2.
Although the relevant columns are not shown in Figure 2, the full RAN License
Manager Report screen shows the number of licenses that have been purchased,
the number of licenses that have been consumed, and the number of licenses
that are available, along with other information about the expiration of dated
licenses.
Figure 2: Portion of RAN License Manager Report Screen

Page 32/308
From LR13.1 onwards, with the introduction of MCO/MCI, new license selectors
are supported to allow the eNB to check the equipmentKind to identify the HW
configuration requesting license tokens. The objective is to enforce the pricing
strategy according to the HW equipment. When there is no license selector, a
global license applies i.e. there is no enforcement on the equipmentKind. The
licensed feature may or may not be delivered on MCO/MCI platform; the reader
shall refer to the Release Notes for licensed features status on MCO/MCI.
Restriction: MCO/MCI – feature parity (including licensed features)

Please refer to Release Notes for feature status on MCO/MCI
Page 33/308
4 ENHANCED NODE B (ENB) HARDWARE

This document is not intended to describe eNodeB configurations. Present
Volume details parameters related to eNodeB HW configuration and related
configurations if needed.
Detailed list of available eNodeB HW configurations can be found on documents:

• RCD (Release Configuration Document) [R6]
• PEG (Product Engineering Guide)[R7]
4.1 ECCM2 INTRODUCTION L115850
This feature introduces new controller board eCCM2 that can be inserted in a
controller of a D2U or D4U rack. It has the same form factor as eCCM-U.
This new board updates the areas that created bottlenecks on eCCM-U, it
increases CPRI connectivity capacity and provides larger capacity.
Please refer to eCCM2 Hardware Design Specification [R08]for any detail and
latest information.
The eCCM2 provides the following:

• Higher capacity for Call Processing (CallP): 2x to 6x versus eCCM
• Higher capacity for backhaul traffic: 2.5x versus eCCM
• Increased CPRI connectivity: 9 rate 5 ports versus 6 rate 3 ports
eCCM2 is introduced in LR13.1 to allow validation in a customer environment.

Commercial introduction on LR13.3. Despite increase of capabilities compared to
eCCM, capacity in LR13.1 is aligned to that for eCCM (therefore in terms of
maximum number of users for LR13.1 still 1200 Active Users and 1200
Connected Users – but with much lower CPU load).
Capacity figures, supported configurations and features with eCCM2 increase in
LR13.3. (Details available on PEG and Capacity documents)
Only six CPRI ports (at rate 3) are used at introduction in LR13.1 – corresponding
to a max of 6 cells supported for eCCM2 on this release. Nine CPRI ports (at 3/5
rate) are supported in LR13.3. Tri-carrier eNB (L115808) or Carrier Aggregation
(160847) features are available in LR13.3 when eCCM2 and bCEM boards are
provisioned.
eCCM2 is not requested to work with eCEM-U in LTE.
This parameter specifies the controller type that the operator is expecting to equip
the eNodeB (eCCM, eCCM2).
Page 34/308
ENBEquipment::expectedControllerType
Parameter expectedControllerType
Object ENBEquipment
Range & Unit Enumerate
eCCM(1), eCCM2(2)
Class/Source C--Immediate-propagation /customer_settable
Value Default = eCCM
Feature L115804
As part of this feature, WPS checks that capacity is limited on eCCM or eCCM2. If
mismatch, error is raised. The OAM performs the same controls as WPS but uses
the detected modem type instead of the configured modem type. Alarms are
triggered and capacity is limited.
Unauthorized capacity triggers an error in WPS and SAM.
When introduced in LR13 ECCM2 is iso feature with eCCMU: no feature that
could only run on eCCM2 is added.
So that current checks are only related to number of Cpri ports and to forbid
eCEM/eCCM2 mixity. Previous eCCM checks also apply to eCCM2.
Name: ENodeB_Cpri_0004
Description: If a CpriRadioEquipment.cpriPort value is more than 6, the
expectedControllerType is eCCM2.
Action: Update the CpriRadioEquipment.cpriPort to an existing eCCM CPRI port
number [1 to 6].
Name: ENodeB_Equipment_0001
Description: Controller and Modem type consistency. expectedControllerType is
an eCCM2 and expectedModemType is not a bCEM. Only bCEM modems are
supported with an eCCM2 controller.
Action: Update expectedControllerType or expectedModemType.
No new parameters due to eCCM2 but change of limits on some ones:

• associatedCpriPassivePort value increased to 9
ENBEquipment.CpriRadioEquipment.
associatedCpriPassivePort (TDD related parameter)
• cpriPort max value increased to 9
ENBEquipment.CpriRadioEquipment.cpriPort
• maxNumberOfCallPerEnodeB increased to 6000
ENBEquipment.Enb.RrmServices.RadioCacEnb.
maxNumberOfCallPerEnodeB (please refer to [Vol. 4])
4.2 BCEM INTRODUCTION L105587
This feature introduces the bCEM to the eNodeB configuration. The bCEM
provides the following:
• eNodeB will be able to configure the bCEM with eCEM cell configuration
when replacing up to 3 eCEMs
Page 35/308
• In LA5.0 only one bCEM is supported in the eNodeB, per band. If dual-
band configuration, two bCEM must be installed, supported in LA6. 3
bCEM modems are supported from 13.3.
• bCEM will not support different types of cells, if Carrier Aggregation
feature is not activated, within an eNodeB. In bCEM all cells will be
configured the same (I.e. same bandwidth and carrier)
• When Carrier Aggregation feature (160847) is active, bCEM will handle

both cells on same sector.
• bCEM requires the high speed fan for cooling if not already equipped
• eNodeB will be able to check the fan tray when bCEM is installed and
report if the fan tray is not correct.
• bCEM will report on a per cell basis
The bCEM modem has the ability to be configured for all 3 cells on the eNodeB.
By doing so it allows the eNodeB to have fewer units within its framework. Having
fewer units in the eNodeB frees up existing space for future use, such as
redundant modem or redundant controller and allowance for 6 sector support by
using 2 bCEMs.
bCEM to support same bandwidths as eCEM, plus additional bandwidth. Note:

On the rack side, bCEM can be introduced in the d2uV5.
This parameter specifies the modem type that the operator is expecting to equip
the eNodeB (bCEM, eCEM and MET3C1).
ENBEquipment::expectedModemType
Parameter expectedModemType
Object ENBEquipment
eCEM(1), bCEM(2), sBBU(3), MET3C1(4)
Class/Source C--Immediate-propagation / customer_settable
Value Default = bCEM
Feature 159488, L115804
Note: sBBU value of parameter is still in the MIM, but this equipment has been
cancelled from the roadmap. MET3C1 is set on Metro Cells equipment’s.
Rule: Parameter expectedModemType
The WPS checks are mandatory.

WPS checks for features whose activation is limited on bCEM, sBBU, eCEM or
Metro. If mismatch, a feature is not allowed to activate on mismatched modem
type. MIM Parameters related to modem capacity will also be checked against
bCEM, sBBU, eCEM and Metro capabilities.
Page 36/308
Resulting of this feature, WPS checks that features whose activation is limited on
bCEM or eCEM are properly set. If mismatch, a feature is not allowed to activate
on mismatched modem type. MIM Parameters related to modem capacity will also
be checked against bCEM & eCEM capabilities.
The OAM performs the same controls as WPS but uses the detected modem type
instead of the configured modem type. It forces activation flags to false and
process to defense actions so features not compatible with eCEM are disabled.
And alarm is sent when not compatible feature has been activated and the
effective modem inserted is eCEM.
Feature ID Feature Name

L84815 Single antenna transmit scheme (bCEM parity)
L114492 Generalized OP-PUCCH
L114531.1 VoLTE Solution for Field Trial Applications
L114536.1 Support of TTI Bundling for VoIP
L115239 Voice Over LTE for Commercial Launches
eMBMS trial support (eMBMS services configured by OAM
L115527 command)
L115616 Support for dual-band eNodeB with two modems
L115686 Scheduler improvements for VoLTE capacity
L115820 Half Duplex FDD for Cassidian band
L101815 Intra LTE FDD/TDD Handover
L101843 MAC DRx State Mgt under Inactivity Conditions
L103790 Intra- LTE Inter Band Cell Reselection for TDD<->FDD
L114538 Enhanced Load Balancing criteria
L115393 LTE to UTRAN (FDD) small cell mobility support
L115401 Nine cells (one frequency) support on three modems
L115644 Bearer Characteristics online modifications
L115680 eUTRAN Sharing - Multi-carriers support (test only)
L115698 Minimum bitrate enforcement for non-GBR
RACH Improvements - RACH burst format 3 support (up to 70 km
L115767 radius)
L115805 Overload Control Phase 3
L115807 TTI Bundling phase 2
L115808 Tri-carrier BBU
L115860 High Priority Access Admission Control
L116365 UE Category 4 Support
134689 Macro/Metro to HeNB cell mobility
134791 enhanced CSFB to 1xRTT
155912 Target cell load consideration for IRAT mobility to WCDMA
L159300 Enhanced Load Balancing criteria (DECP dependency)
159538159538 eICIC with Semi-Static ABS (FDD, Macro Cell)
L160846 Carrier Aggregation (Lab)
Page 37/308
160847 Commercial CA
162790 Commercial VoLTE with SPS
L162880 Commercial VoLTE with SPS (DECP dependency)
Table 4 : bCEM Only Features
4.3 9412 – COMPACT MULTI-BAND/DUAL-FREQUENCIES
4.3.1 9412 – COMPACT DUAL-BAND ENODEB L132037
LA 5.0.3 L132037 (Predecessor: L115616) is Support for dual-band eNodeB with

two modems. This feature details the configurations based on two bands inside
the same BBU, with two modems. Finally we can say that on each modem we
could configure 1 band with 1 carrier and 1 bandwidth.
The eNB must support the configuration of up to six sectors. Three of the sectors
and cells will be associated with one bCEM, and the other three sectors and cells
will be associated with the other bCEM.
The general case is presented in the following figure:
bCEM #1 CCM
Bandwidth #1
Carrier #1
RRH
Band #1 Band #1
Bandwidth #1
Carrier #1
RRH
Band #2
Bandwidth #1
Carrier #1
RRH
Band #1
RRH
bCEM #2 Band #1
Bandwidth #2 RRH
Carrier #2 Band #2
Band #2 RRH
Bandwidth #2 Band #2
Carrier #2
Bandwidth #2
Carrier #2
Figure 3: Dual Band configuration
This feature enables operators to collocate different carriers on different LTE

bands within a single eNB, when spectrum available in one band is not sufficient.
It is requested to have 2 modems every one with 3 RRH.
The rule retained for this FTS is to impose one carrier per modem i.e. implicitly to
allow, when we have two bCEM modems, having two different carriers.
The usage of two carriers implies that EnbRadioConf MO which is shared by all
cells must be checked (and modified if needed) against the usage of specific
carrier related parameters.
The BBU (in d2UV5 rack) must be able to configure and manage 6 sectors.
Page 38/308
It was agreed that a sector is characterized by:

a. Geographical area and
b. Band
The intra eNB with inter frequency (carriers) mobility is mandatory
Rule: Dual band eNB and the Antenna Cross connect feature
If the following three conditions are met:

The dual band eNB feature (L115158.1) is enabled (parameter
isDualCarrierEnabled = True), and
Separate antennas are used for the two bands, and The antenna cross connect
feature is enabled, Then the antennas for both bands must be configured for the
cross connect feature.
Note: With these two types of configuration the sectorId attribute (Figure 2) must
be carefully defined to express the difference between possible presented
configurations. This attribute is used in different CallP algorithms and actually it
designated only geographical characteristic of the sector
OAM is able to map two cells per sector. Mainly the OAM allows the mapping
between sectors/carrier (physical view) and cells (logical view). This functionality
is spread over different subsystems and now it must be able to map two cells to
one sector. Check on FrequencyandBandwidthFDD MO associated to LteCell MO
to determine if the dual carrier is related to L115938 or L132037 (Dual band).
ENBEquipment
eNB
LteCell
Sector CpriRadioEquipment
- uniqueName
- sectorNumber
- ...
LteCellFDD CellAntennaPort AntennaPort

CellAntennaPort AntennaPort
- numberOfDLAntennas CellAntennaPort
- antennaPortId AntennaPort
- antennaPortIndex
- antennaPortId - antennaPortIndex
- numberOfULAntennas - antennaPortId
- rxPath - antennaPortIndex
- sectorId
- rxPath - sectorId
- cellCapability2x2Mimo - rxPath
- txPath - sectorId
- assignedTransceiverPort
- txPath - assignedTransceiverPort
- cellCapability4x4Mimo - ...- txPath - assignedTransceiverPort
- rxUsed
- ... - rxUsed
- ... - ... - rxUsed
- txUsed
- txUsed
- ...- txUsed
- ...
- ...
Figure 4: Sector, Cell relation using AntennaPort & CellAntennaPort
Page 39/308
Restriction: Configuration LA6.0

Any mixture of TRDUs, MC-TRX and RRHs linked with the same bCEM is not
allowed.
No HW mixture inside one eNodeB band.
Note: With the Dual Band configurations appearing in LA6, we can have now one
band (3 sectors) with TRDUs, and a second band (3 sectors) with RRHs.
The 3 TRDUs connected to one bCEM, and the 3 RRHs connected to a second
bCEM.
Some characteristics of the dual band features include:
1. The eNB must configure and manage up to 6 sectors (as defined

above).
2. Two bCEMs will be used to support the features
3. The two frequencies that are supported may be in the same band or
in different bands (depending on the specific feature that is used)
4. Support for intra-eNB, inter-frequency handover is mandatory. See
[Vol. 6] for additional detail.
5. Specific bands and bandwidths are supported. Check the feature
description to determine the specific configurations that are
supported.
6. PCI allocation, conflict detection, and correction are not affected,
since the two carriers operate on different frequencies. Note,
however, that the PCI algorithm must be run separately for the cells
that operate on different frequencies.
7. X2 Dynamic Configuration and ANR are impacted because of
presence of two frequencies and a new necessary Inter Frequency
Service to be considered for Intra eNB neighbors must be detected
and supported, load balancing, etc.
8. The use of dual carrier is a licensed feature that is controlled by the

value of parameter isDualCarrierEnabled. Sufficient tokens must be
available to support each eNB on which the feature is activated. See
[Vol. 1] for additional information about Feature Licensing.
isDualCarrierEnabled - parameter activates or deactivates the capability to

configure two carriers when two different bCEMs are used.
Page 40/308
ActivationService::isDualCarrierEnabled
Parameter isDualCarrierEnabled
Object ENBEquipment/Enb/ActivationService
Range & Unit Boolean
False, True
Class/Source C--Immediate-propagation / system_reserved
Value Default = False
Feature L115616
Note: the parameter that is used to enable the dual band feature (L115616) is
parameter, isDualCarrierEnabled.
Note: This same parameter is also used to enable Feature L115938, DUAL-
CARRIER SUPPORT ON ONE BAND.
4.3.2 COMPACT DUAL-CARRIER SUPPORT ON ONE

BAND L115938
Feature was introduced on LA6.0.1, and only supports two 5MHz cells in the
same band (PCS).
This feature supports the use of two bCEMs that operate in the same band, but
on different frequencies. All of the considerations above apply to this
feature.
HW arrangement for this configuration: PCS only, two bCEMS, eCCM, one RRH
per sector with both carriers, single Rate3 CPRI link to each RRH.
L115938 allows configurations where two technologies (especially CDMA and
LTE) share the same RRHs and also the case where the RRHs could serve the 2
carriers which imply 3 RRH for six cells in configuration maximum.
bCEM #1 CCM
Bandwidth #1
Carrier #1
Band #1 RRH
Bandwidth #1 Carrier #1
Carrier #1 Carrier #2
Bandwidth #1
Carrier #1
RRH
Carrier #1
bCEM #2 Carrier #2
Bandwidth #1
Carrier #2
RRH
Band #1 Carrier #1
Carrier #2
Bandwidth #1
Carrier #2
Figure 5: Dual Band Configuration with multi carrier RRHs

Page 41/308
4.3.3 TRI CARRIER BBU L115808

This feature introduces the configurations based on three carriers inside the same
BBU, with three modems. The cells using the same carrier will have also the
same bandwidth. The three carriers could belong to two or three bands.
This feature supports:
• Bi-band case: 6 sectors-9 cells configuration
• Tri-band case: 9 sectors-9 cells configuration
• All bandwidth combinations are supported, the cells using the same
carrier must have the same bandwidth. All supported bands are also
supported in the scope of the Tri carrier configurations. However only a
subset of band/bandwidth combinations is tested.
• Antenna Cross Connect configurations are supported at carrier level. This
means, in Tri Carrier configuration, some of the carrier can be with
Antenna Cross Connected and others with antennas in standard
configuration (non ACC). However, it is not possible to use the same
RRH with two carriers and ACC in the same time.
• RRH and TRDU mixture is supported at eNB level (not at carrier level).
The feature mandates to have the following Hardware:
• Rack: d2uV5
• Modem: three bCEMs, every bCEM supporting one carrier. This feature
does not allow mapping cells with different carriers or bandwidths on the
same bCEM.
• Controller: eCCM2 controller

• CPRI rate must be 3 (at minimum; some Tri carrier configurations
requires a CPRI rate 5).
It is under Licensing, controlled by the parameter isTriCarrierEnabled:

isTriCarrierEnabled - This parameter activates or deactivates the capability to
configure up to nine cells three carriers and three bandwidths when three different
bCEM are used.
Page 42/308
ActivationService::isTriCarrierEnabled
Parameter isTriCarrierEnabled
False, True
Class/Source 3 / customer_settable
Feature L115808
Note that the parameter isDualCarrierEnabled must be False when

isTriCarrierEnabled is True.
Note that this feature and the features “Carrier Aggregation” are mutually
exclusive.
As for the Dual Carrier and Dual Band features, the Tri Carrier feature imposes to
properly configure all required parameters for inter-frequency intra-eNodeB
mobility and load balancing.
In order to give flexibility in the way to configure the three carriers, the following
objects can be multi-instantiated (up to three instances):
1. EnbRadioConf MO
2. DedicatedConf MO
3. EnbVoipConf MO
The LteCell object references the corresponding instances through three
parameters: dedicatedConfId, enbRadioConfId, enbVoipConfId.
LteCell::dedicatedConfId
Parameter dedicatedConfId
Object ENBEquipment/Enb/LteCell
Range & Unit Link
DedicatedConf
Value Default DedicatedConf/0
Feature L115808
Page 43/308
LteCell::enbRadioConfId
Parameter enbRadioConfId
Range & Unit Link
EnbRadioConf
Value Default EnbRadioConf/0
Feature L115808
LteCell::enbVoipConfId
Parameter enbVoipConfId
Range & Unit Link
EnbVoipConf
Value Default EnbVoipConf/0
Feature L115808
We can define a priority for each carrier with the parameter multiCarrierPriority.
If a bCEM is removed or locked (so implicitly a carrier is lost) an automatic
reconfiguration could be executed, based on the carrier priority, such that the
carrier with highest priority, if it was lost, is recovered on the remaining bCEM
running the lowest priority carrier, through an automatic bCEM reset and restart. It
is not imposed that the carriers have different priorities. The highest priority is 0;
the lowest is 9.
FrequencyAndBandwidthFDD::multiCarrierPriority
Parameter multiCarrierPriority
Object ENBEquipment/Enb/LteCell/FrequencyAndBandwidthFDD
Range & Unit Integer
0..9
Class/Source 0 / eng_tunable
Value Default 9
Feature L115808
Page 44/308
CCM
bCEM #1
Bandwidth #1
Carrier #1
Bandwidth #1
Carrier #1
Bandwidth #1 RRH
Carrier #1 Carrier #1
RRH
Carrier #3
bCEM #2 RRH
Carrier #2
RRH
Carrier #2 RRH
Carrier #1
RRH
Bandwidth #2
Carrier #3
Carrier #2
RRH
Carrier #2
RRH
Carrier #2
bCEM #3 RRH
Carrier #3
Bandwidth #3
Carrier #3
Bandwidth #3
Carrier #3
Figure 6: Generic Tri Carrier configuration
4.3.4 NINE CELLS (ONE FREQUENCY) ON THREE

MODEMS L115401
This feature introduces the support of up to 9 Cells (same band, same frequency)
on one eNB, with the usage of up to 3 modems.
This solution addresses hot spots, stadiums where huge capacity is required to
be deployed in a short time.
This solution provides an increased capacity, is cost effective and is less time
consuming than the usual approach of adding new eNB.
The topologies supported with this feature are:
With 2 bCEMs (up to 6 cells), 1 eCCM (or 1 eCCM2):

• 6 sectors – 1 site
• 6 sectors – 2 sites
With 3 bCEMs (up to 9 cells), 1 eCCM2:

Page 45/308
These topologies are pictured below:
With 2 bCEM
6 sectors - one site 6 sectors – two sites
With 3 bCEM
9 sectors – two sites 9 sectors – three sites 9 sectors – nine sites
Figure 7: Up to nine cells (one frequency) topologies
The feature mandates to have the following Hardware:

• Rack: d2uV5
• Modem: up to three bCEMs, every bCEM supporting up to 3 cells
• Controller: for 3 bCEMs configurations, eCCM2 controller is mandatory,

else eCCM is enough
This feature is under Licensing, controlled by the parameter

isIncrementalSectorEnabled:
isIncrementalSectorEnabled – This parameter activates or deactivates the
capability to configure up to nine cells same carrier and bandwidth when up to
three different bCEM are used.
ActivationService::isIncrementalSectorEnabled
Parameter isIncrementalSectorEnabled
False, True
Feature L115401
Page 46/308
Note that the feature “Nine Cells (one Frequency) on three modems L115401” is
mutually exclusive with “Dual Carrier” (L115938), “Dual Band” (L132037), “Tri
Carrier” (L115808) and “Carrier Aggregation” (165592 and 160847).
The way to determine the Prach-ConfigIndex and the RootSequenceIndex,

usually based on the sectorNumber, is not suitable for the topologies introduced
by L115401 and requires a new algorithm to be used.
The parameter pRachIndexAlgorithm specifies which algorithm is used. When
L115401 is activated, pRachIndexAlgorithm must be set to modem_based: it is
the algorithm based on local allocation at CallP level, which is mandatory to
manage the topologies introduced by this feature.
The support of up to nine cells per sector requires an evolution of the automatic
PCI allocation process. This is covered by the feature L115340 “Support of Auto
PCI for up to 9 cells per eNB and up to 6 sectors per site configurations”. Please
refer to [Vol. 5] for the description of this feature.
It is also required to have unlimited PRB, and AISG activated.
All these pre-requisites are listed in the following rule.
Rule: Pre-requisites for the activation of “Nine Cell (One Frequency) on Three
Modems”
When isIncrementalSectorEnabled is TRUE, we must have

• isAisgAllowed = TRUE
• isUnlimitedPRBLicenseAllowed = TRUE
• isDualCarrierEnabled = FALSE
• isTriCarrierEnabled = FALSE
• isCarrierAggregationEnabled is FALSE.
4.4 ENODEB CONFIGURATION
4.4.1 AISG 2.0 SUPPORT (TMA&RET) L156783
With the Antenna Interface Standards Group 2.0 (AISG 2.0) control function, the
eNodeB will be capable of controlling Tower Mounted Amplifier
(TMA) and/or Remote Electrical Tilt (RET) devices via the OAM system (SAM)
without any additional HW
This feature allows the operator to read the status of, and control Antenna Line
Devices (ALDs) from the SAM or NEM via a control bus hosted by one of the
eNodeb’s RF Modules (RFM).
Page 47/308
isAisgAllowed controls whether the AISG feature is activated for this eNodeB.
Note that this feature is controlled by feature licensing, and a licensed is required
before the feature can be activated. See [Vol. 1] for additional information about
feature licensing.
If True, then this causes the AISG busses to be powered and scans performed
for AISG devices.
If False, the busses remain unpowered (note: Any present TMAs will not have
power and will not provide RF gain) and no AISG devices will be detected or
controlled.
ActivationService::isAisgAllowed
Parameter isAisgAllowed
Object ENBEquipment/ Enb/ ActivationService
True, False
Class/Source C--Immediate Propagation / customer_settable
Feature L114909.1
Note: In LA6.0 like in LA5.0 all RRHs and TRDUs support the AISG feature. But
No AISG on MC-TRX.
Since LA6.0.1, AISG is supported for a Dual Band BBU Configuration that uses
Dual Band TMAs
Parameter isRfmAisgEnabled allows to enable AISG per RRH/TRDU. If set to

False, associated RRH/TRDU should not have the AISG function enabled. When
OAM receives this parameter set to False and the eNodeB MIB parameter
isAisgAllowed was set to enable, OAM will not send a command to the
RRH/TRDU to initiate the AISG Scan function. . The default value is True, but the
end user can set it to False for a configuration that does not require the
RRH/TRDU to turn on the aisg function.
CpriRadioEquipment:: isRfmAisgEnabled
Parameter isRfmAisgEnabled
Object ENBEquipment/ CpriRadioEquipment
True, False
Class/Source B- affects NE / customer_settable
Value Default = True
Feature L114909.1
Page 48/308
4.4.1.1 OVERVIEW
There are four AISG entities:

User Interface- The SAM and NEM provide user interfaces to allow the operator
to read ALD status and to configure ALDs or request ALD actions.
ALD Manager- An eNodeB may host several ALD busses, each with their own
ALD Controller. The ALD Manager function serves to switch application
messages between the user interface (SAM/NEM) and the appropriate ALD
controller. The ALD Manager also oversees the download of software images
and antenna configuration files (RET only) to the ALD. The ALD Manager is a
function within the OAM Equipment Manager.
ALD Controller- this is a software object that serves as a master of the ALD bus,
exchanging HDLC frames with the ALDs on the bus and application messages
with the eNodeB controller software. The ALD controller implements the bus scan
and bus polling procedures and resides on the RFM.
Each RFM provides its own ALD Controller for its own AISG bus.
ALD- zero or more ALDs may be associated with an eNodeB. ALDs receive
application layer commands over an HDLC link layer and produce the requested
action (antenna tilt, receive path gain, etc.) at the antenna location. One ALD
corresponds to one addressed station on the AISG HDLC bus.
Page 49/308
XMS/NEM
User
Interface
OAM Backhaul Network
eNodeB
ALD
Manager
CPRI Interface
ALD RRH/ RRH/

Controller TRDU TRDU
RS-485 Interface
(HDLC bus)
AISG AISG
ALD
Device Device
Figure 8: AISG entities overview
From Installation to operation:
• ALD Installation – ALDs are physically installed at the eNodeB site and
data describing the installed units is recorded for later entry into the
eNodeB database. Note: XMS is now replaced by SAM.
• ALD Bus Initialization and ALD Data Entry – The ALD controller for each
bus (the eNodeB may have one bus per RFM) executes a bus scan
procedure to detect attached units. RRH&TRDU 700L/L156783:It will
scan all three ports (Tx/Rx Por1, Tx/Rx Por2, AISG RS-485 connector)
and report to OAM the ALDs (RETs and/or TMAs) that were detected on
each of these ports.
• The user must provide the ALD installation data corresponding to each
discovered ALD before that device can be used.
• ALD Initialization and Configuration – Several interactions between the
eNodeB controller, the ALD controller, and the ALD are needed to place
the ALD into a state where it is ready to accept commands.
• RRH&TRDU 700L/L156783: HRAL will create Resource Objects (RO) for

each of these ALDs regardless of the AISG where they reside. It is
anticipated that the RRH will manage HDLC addresses assigned to each
of these ALD regardless of the AISG port where they resides.
• It is expected that HRAL will use the current procedure to catalog each of
these ALDs and to retrieve from each of these ALDs their properties (i.e.
Unique Identifier, serial number, RET type, Number of subunits)
Page 50/308
• Once in this state the ALD Manager verifies the ALD is correctly initialized
and configured. Static configuration values stored within the eNodeB
database are passed to the unit if necessary.
• ALD Operation – Once the ALD is in service it responds to operator

requests initiated from the NEM or SAM
RRH&TRDU 700L/L156783: OAM (with help from the NEM) will implement a
procedure to write to RET and/or RET Subunit User Defined record defined in the
following table:
Table 5: RET Subunit User Defined record in LA6.0.1

The eNodeB OAM will perform appropriate conversion of the data sent by the
NEM application to store the values in RET/RET Subunit User Defined Data using
the appropriate format for each of the above fields:
• The RET Subunit attribute: Band Class will be stored in Field 0x03 or field
0X08
• The RET Subunit parameter: Associated eNodeB will be stored in Field
0x23
• The RET Subunit parameter: Sector Id will be stored in Field 0x24

• The RET parameter: Mechanical Tilt will be stored in Field 0x26
• The Wizard screen in the NEM will support retrieving the values for the
above table from the RET and/or the RET Subunit table GUI screen and
to send the values to OAM using SNMP or NETCONF interface.
Page 51/308
SAM/NEM Corresponding ALD

Comments
Procedure Procedure
General Procedures
View Inventory Use existing ALD Bus Scan results are used to
Data inventory reporting populate inventory data
mechanism
View ALD Use cached data ALD Read Device Data, Get Tilt,
Descriptive TMAGetMode, TMAGetGain, etc.
Information procedures executed at ALD
initialization and data cached to
populate user view. No ALD
procedure is executed at time of
viewing.
View Alarm Status Use existing alarm RFM generates ALD alarm indications
reporting mechanism on change of ALD alarm state.
Reset ALD Reset Software User-requested reset of ALD
Execute ALD Self Self Test ALD verifies that it is still working
Test properly.
ALD application download is controlled by
Download ALD Download Start eNodeB.
Software
Download Application (Support for software download of
ALDs is added with feature L114909
Download End in LA4.0.1)
RET Procedures
Calibrate RET Calibrate Drives RET actuator through full
adjustment range. Used when first
installed or following download of
ACF, and then perhaps annually to
verify mechanical operation.
Set RET Tilt Set Tilt Sets new tilt angle
Download ACF Send Antenna (Support for download of Antenna
Configuration File Configuration Data is added with
feature L114909 in LA4.0.1)
Display Number of Antenna Get Number Number of Antennas is read by
Antennas/Actuators Of Antennas eNodeB at ALD initialization and
cached for later reporting to
SAM/NEM. No user operation
directly triggers this procedure.
TMA Procedures (All TMA procedures reference TMA LUN and Subunit)
Set TMA Mode TMASetMode Sets TMA to bypass (when supported
by device)
Table 6: RRH-1 Cross-connected failure with Transceiver Antenna Ports states in LA6.0
Page 52/308
4.4.1.2 TMA & RET IN LR13
Supported ALDs since LA6.0 release include Tower Mounted Amplifiers (TMA)
and Remote Electrical Tilt (RET) units, other unit types may be added in the
future. One ALD unit is a RET unit or a TMA unit or a RET+TMA.
In LA6.0 like in LA5, dual RETs and quad TMA units can also be supported.
The Figure 9 shows the Daisy-Chaining capability of the ALD.
There are several types of TMA.
The RF signals are amplified in the uplink direction, from the antennas to the
RRH. OOK signal on the RF cable is able to manage RS-485 signal, this one is
now supported since LA4.0. The OOK signal at the antenna panel is retrieved
from the RF cable using a Smart Bias-T (L114665)
Tilts for Antenna1 and

Antenna2
Simple
RET
Rf cable
in
RF In/Out to Antenna
TMA RS-485
out
Tx/Rx in
Port
Rf cable
RS-485
RRH
Figure 9: Usage of multiple ALDs on one RRH
Note: OOK signal on RF Cable is now supported since LA4.0, so RS 485 is

optional for TMA implementation with LA4.0 L114665 and with LA5.0
Besides multiple read-only ALD parameters, there are also some settable
attributes.
The settable ALD parameters are described in section 5.2.9
Page 53/308
4.4.1.3 THREE SECTORS CONFIGURATION WITH TMA

AND RET PER RRH
The communication to the TMA will be supported using the OOK signal on one
of the RF cable while communication to the RET is via an RS-485 connection
from the TMA. OOK is the modulated AISG signals over the RF cable, this one
now supported since LA4.0.0.L114665
The TMA must have an additional RS-485 connector to support the daisy
chaining of the two units.
We can assume a maximum of four TMAs (for a 4-branch receive unit, we

assume four dual-TMAs for an 8-branch unit) and two RETs (two dual antenna
panels) per RFM.
Up to 6 ALDs can be used on the same RFM, two different ALDs on each RRH
are shown in this figure below
α β γ
RET RET RET
RS-485
TMA TMA TMA
RF cable
RRH RRH RRH
CPRI
Backhaul
BBU
Backhaul
Figure 10: Overview of the usage of TMA and RET (600-05-17, 600-05-12, L115287)
The interconnection between the ALDs uses a Daisy-Chaining capability of the

ALD.
Page 54/308
The RETs used in LA6.0 like in LA5.0 can be dual actuator elements. These
elements can only perform one physical movement at a time, but can be
connected to an antenna panel consisting of multiple antennas.
Since LA4.0 quad TMAs can be supported in addition to the dual TMAs that were
previously supported. These quad TMAs, meaning that this equipment consists
of four subunits which are able to amplify four antenna receive paths.
Note: OOK signal on RF Cable is now supported since LA4.0, so RS 485 is

optional for TMA implementation with LA5.0
MIM Parameter Remarks MIB Parameter Remarks

This parameter contains the
identify the RET Subunit number of actuators in the RET
Number or Id that support the unit associated with this station.
Antenna Port (Value is Equivalent to 3GPP
retNumberActu
RetSubunit::retSubunitNumber always 1 in LA6.0). In NumberOfAntennas or TMA
ators
"Antenna Ports", named RET subunit. Always 1 or 2 in LA6.0.
Actuator Id. in the NEM tool, Also named RET Actuator Id.
from "RetSubUnitTable". from "RetAldTable" in the NEM
tool.
Number (to count) of TMAs
specify the TMA subunit that
subunits associated in a given
supports this antenna port
TMA of this station. Always 1 or 2
(Value is always 1or 2 in
tmaNumberSu in LA6.0. Named
TmaSubunit::tmaSubunitNumber LA6.0). In "Antenna Ports",
bunits tmaNumberSubunits from
named tma SubUnit Index in
"TmaAldTable" and seen in the
the NEM tool, from
NEM tool with the name "TMA
"TmaSubUnitTable".
Subunits".
Table 7: Part of ALD table regarding retSubunitNumber and tmaSubunitNumber
See section 5.2.9 for definition of these parameters.
Restriction: RET in LA6.0 like in LA5

If the RET unit reported to OAM that it has 2 actuators, a value 2 is placed in
the parameter RetNumberActuators. In this case there should be two subunits
for RET: subunit 1 and subunit 2. In LA6.0 like in LA5 there would be no
subunit 2, but if it shown on the list subunits that can be assigned to an
antenna port, OAM would not be able to manage that unit.
Rule: Parameter LteCell::numberOfULAntennas
If the value of parameter is to be changed, then the modem should be reset to

achieve changing. RRH will need to be reset by ENB OAM (RESET_REQ
action is sent to RFM RO managed by HRAL) so that the new configuration is
taken into account.
Be careful: RetSubunit::retSubunitNumber is a numerical identifier to identify

the RET in the antenna chain. retNumberActuators count the number of RET in
the antenna chain. retNumberActuators holds the number of actuator supported
by the RET. The value for this parameter is read from the RET unit and place in
this parameter via NEM tool.
The same for TmaSubunit::tmaSubunitNumber and tmaNumberSubunits:
TmaSubunit::tmaSubunitNumber is a numerical identifier to specify the TMA in
Page 55/308
the antenna chain. tmaNumberSubunits count the number of TMA in the antenna
chain. tmaNumberSubunits holds the number of TMA subunits in the TMA unit.
The value is read from the TMA unit and place in this parameter via NEM tool.
It is also possible to increase the number of Daisy-Chained network elements by

connecting multiple ALDs, serving different RRHs
α β γ
ALD ALD ALD
RS-485
RF cable
RRH1 RRH2 RRH3
CPRI
Backhaul
BBU
Backhaul
Figure 11: Daisy-chaining over multiple RRHs on one eNB ( 600-05-07, L115297)
For daisy chaining the maximum configuration is one TMA with 8 chained
RETs per sector. Tbc LA6
Note: OOK signal on RF Cable is now supported since LA4.0 L114665 and
manage also daisy chaining configuration via the Smart Bias-T. With this
configuration RS-485 is not used. The OOK signal at the antenna panel is
retrieved from the RF cable using an internal Smart Bias-T. The RET that
supports this “main” sector connects to the Smart Bias-T AISG port. The RETs
that support the other sectors are daisy chained to this first “main” RET.
While using multiple ALDs in Daisy-Chaining mode, every RRH holds a

reference of only the ALDs that influence its own antennas. Daisy-Chained
ALDs’ references are owned by the corresponding RFM, even if there is no
direct physical control connection. Furthermore, every ALD needs to hold a
reference of the RRH that passes through the information from the eNB and vice
versa. This RFM is called the host RFM.
Note: L115562 Note that the eNodeB will supports TMA with multiple subunits.
Each subunit in the TMA supports one RF path. When the RRH/TRDU is using
only 2 RF paths, TMAs with two subunits are used. If the RRH/TRDU supports 4
RF paths, then the TMA will have 4 subunits. This will reduce the number of
TMAs per eNodeB.
Page 56/308
Parameter Remarks MIB Parameter Remarks
RET Log.Number in Antenna User-visible identifier for this
specify the logical number of
Ports in the NEM tool, from retLogicalNum RET. Named RET Log.Number
the RET that is associated
“RetAldTable”.(previouse ber in “RetAldTable”, in the NEM
with this antenna port.
AntennaPort::retLogicalNumber) tool.
User-visible identifier for this

TMA Log.Number in Antenna
specify the logical number of TMA, 1 to n. Named TMA
Ports in the NEM tool, from tmaLogicalNu
the TMA associated with this Log.Number in “TmaAldTable”,
“TmaAldTable”. (previouse mber
antenna port. and is seen in the NEM tool with
AntennaPort::tmaLogicalNumber)
the name"TMA Log. Number".
Table 8: Part of ALD table regarding RET Log.Number and TMA Log.Number
See section 5.2.9 for definition of these parameters.
The ALD configuration parameter must be done during the eNodeB

commissioning since there is no way to detect the sector ID and the RF path (1
or 2 on the sector) that is supported by the ALDS unit.
Both values of these parameters are found during the OAM phases of “ALD Bus
Initialization” and “ALD Initialization and Configuration”.
One disadvantage of the daisy chain configuration is that we can only
communicate to the ALD units via host RRH 1 If RRH 1 is out of service, we
cannot communicate with any of the ALD units
Even if the RFM lost communication to the ALD device, the ALD unit will still
supports its function as long as the RRH can supplies the necessary DC voltage.
If the loss of communication was due to a failure of the ALD unit, then there might
be some impact to their functions:
- If this was a TMA unit, there could be a loss of gain in the Rx

Path.
- If this was a RET, the eNodeB antenna would be operational, but
the technician lost the ability to change the antenna tilt
Through the daisy chaining capability of ALD devices, it may also be possible to
add an ALD to the bus, which serves a different eNodeB but is managed by the
local eNodeB.
Page 57/308
α β
ALD ALD
RF cable
RS-485
Local Remote
RRH RRH
CPRI CPRI
Backhaul
BBU Backhaul
BBU
Backhaul Backhaul
Figure 12: Example configuration of a remotely managed ALD
Note: The amplification of the remote TMA is lost while the local RRH reboots.
Next releases try to solve this limitation.
If the communication is lost to an ALD, the TMA is set to bypass mode and the
amplification is lost. If the communication is lost to an RET, the RET holds on to
the last angle it was set.
α β γ α β γ
RS-485 RS-485
ALD ALD ALD RET RET RET

RF cable
with OOK
Tx/Rx Simple
signal
RF cable
DC-Bias-T RRH1 RRH2 RRH3 RRH1 RRH2 RRH3
CPRI CPRI
Backhaul
BBU eNodeB-1 LTE or WCDMA BBU eNB2
Backhaul
Backhaul Backhaul
Figure 13: Configuration with 3 ALD Type RET+TMA in Series with 3RE
T unit in remote (600-04-07, 600-04-20, TBC)
The above configuration shows the control of six RET units via RRH-1 in
eNodeB-1. The RET units that belong to eNodeB-2 or to the WCDMA NodeB are
only visible from eNodeB-1 GUI on the NEM/SAM. The NEM/SAM application will
have a GUI that shows all the RET and TMA units that resides in the AISG Bus
that is controlled by one of the RRHs in eNodeB-1.
Page 58/308
4.4.1.4 DUAL BAND AND TMAS CONFIGURATION-

L156783
4.4.1.4.1 CONFIGURATION WHERE THERE IS ONE BBU PER BAND

AT THE SITE
For this type of configuration, setting for which OAM can only report when there is
a failure of the TMA Subunit that support the band for the other BBU at the site is
not recommended because there would be no notification to the RRH that was
affected by this failure.
4.4.1.4.2 CONFIGURATION WHERE THE BBU SUPPORT TWO BANDS

USING A SINGLE CONTROLLER
For this configuration OAM will be able to manage the TMA subunit for each of
the band. Failure of any of the two Subunits will trigger a message to the RRH
associated with the Subunit that failed so that the RRH Rx Gain can be adjusted
for the loss of the TMA Subunit. This is illustrated in figure below.
Figure 14: Dual Band with single BBU
Page 59/308
New Wizard GUI screen to allow the user to write to a RET/TMA or RET
subunit/TMA Subunit the following attributes:
- Band Class supported by the RET or the RET subunit or the TMA
Subunit
- The Sector Id supported by the RET or the RET subunit or the TMA
Subunit
- The Name of the eNodeB associated with the RET or RET subunit or the
TMA Subunit
- The Mechanical Tilt of the RET unit (not applicable to the TMA)
The first 3 bullets are attributes of the RET Subunit and can be retrieved by the
NEM application from that RET Subunit table. The values in these attributes are
populated by the technician who performs the eNodeB commissioning.
The last bullet item is an attribute of the RET MO and can be retrieved from the
RET ALD table. In LA5.0 the value on this field is retrieved from the RET unit if
there was value stored by the personnel who did the antenna panel installation. If
this field is blank, a value was populated during the eNodeB commissioning.
The NEM GUI screen will provide an action button for the user to send the data to
the eNodeB OAM for writing to the RET and/or RET subunit.
New alarms related to the use of AISG internal bias on Tx/Rx port 1, Tx/Rx Port
2, and the RS-485 AISG Port are implemented.
RFM TXPORT1 OVERCURRENT DC-Bias Current for AISG Devices was exceeded on Tx Port 1
RFM TXPORT2 OVERCURRENT DC-Bias Current for AISG Devices was exceeded on Tx Port 2
RFM AISG PORT OVERCURRENT DC-Bias Current for AISG Devices was exceeded on RS-485 Port
RFM DC-BIAS OVERCURRENT DC-Bias Current Source in the RFM exceeded the maximum threshold.
RET SUBUNIT 3 MOTOR JAM This alarm indicates that the RET Subunit 3 motor cannot move.
This alarm indicates that an actuator jam has been detected in Subunit 3. No movement of the actuator,
RET SUBUNIT 3 ACTUATOR JAM
but movement of the motor was detected.
This alarm indicates that the subunit 3 has not completed a calibration operation, or calibration has been
RET SUBUNIT 3 NOT CALIBRATED
lost
RET SUBUNIT 3 NOT CONFIGURED This alarm indicates that the actuator antenna configuration file is missing for subunit 3
RET SUBUNIT 4 MOTOR JAM This alarm indicates that the RET Subunit 4 motor cannot move.
This alarm indicates that an actuator jam has been detected in Subunit 4. No movement of the actuator,
RET SUBUNIT 4 ACTUATOR JAM
but movement of the motor was detected.
This alarm indicates that the subunit 4 has not completed a calibration operation, or calibration has been
RET SUBUNIT 4 NOT CALIBRATED
lost
RET SUBUNIT 4 NOT CONFIGURED This alarm indicates that the actuator antenna configuration file is missing for subunit 4
Table 9: New eNodeB Alarms L156783 in LA6.0.1
Page 60/308
4.4.1.5 ALD BUS INITIALIZATION AND ALD DATA ENTRY
During ALD bus initialization the ALD Controller is commanded to execute a bus
scan to detect all ALDs residing on the bus.
Upon receipt of the command the ALD Controller turns on the DC power supply to
the bus 1 and pauses for 5 seconds to allow any ALDs to initialize, then begins to
scan for connected devices.
OAM-C requests this scan only when the MIB (aldScanEnable field) indicates
that ALDs are present.
This command is added as a default step in the RFM initialization sequence. but
for LA3.0/TLA2.1 it is included only when initializing the following units:
• Alcatel-Lucent Band IV (AWS) 2x40W RRH (HWRef 0x730),
• Alcatel-Lucent Band XII / XVII 2x40W RRH (HWRef 0x731).
No other RFM supports the ALD controller function in LA3.0/TLA2.1.

In LA6.0 like in LA5.0 all units (except ROCM) are assumed to support ALDs
During the procedure the Controller learns the ALD Unique Identity of each ALD
on the bus and assigns each ALD a local ALD bus address. This bus address
plus the RFM identifier together serve as the ALD Physical Unit Destination, and
provides sufficient information to locate the ALD within the eNodeB.
A list of detected ALDs is returned to the RFM RO, which creates TMA or RET
ROs for each detected unit, depending on the unit type read from the ALD. OA&M
is notified of the RO creation and creates a corresponding TMA or RET Managed
Object (MO) for each RO. The user can then provide the installation data (sector,
antenna number, etc.) for each ALD, and OA&M can use the Unique Identifier to
match the ALD Logical Unit Number (the main identifier at the user interface) to
the ALD Physical Unit Destination provided by HRAL.
Figure 15 below summarizes the bus initialization operation.
1
DC power is normally off to prevent unnecessary current drain and to avoid damage to current-sensitive
units that may be attached in certain configurations.
Page 61/308
ALD Bus Initialization
TMA/RET
OAM RFM ROs RFMs
Initiate AISG ROs
1 Bus Scan (ALU
AWS RRH
2 only) Start Bus Scan Action:ALDSCAN
Start Bus Scan Action:ALDSCAN
Start Bus Scan Action:ALDSCAN
RFMs scan
bus to detect
attached ALDs
3
Create RO ALDSCAN list

4 notify
notify
Create MOs for notify
5 discovered
ROs
Figure 15: ALD Bus Initialization
4.4.1.6 ADJUSTING RFM RECEIVE PATH GAIN

Three parameters are needed to properly calculate the portion of receive path
gain/loss external to the RFM itself:
1. Antenna cable loss from the TMA BTS connector to the RFM antenna port.
This is read from the antennaPathAttenuationUL and hard coded parameter
antennaPortInternalLoss (jumper cable loss) parameters, see Table below.
2. Nominal gain of the TMA from its antenna connector to its BTS connector. This
is read from the ttlnaAntennaGain (previous LA4.0 AntennaGain) parameter,
See Table below.
3. TMA bypass loss, which indicates the path loss when the TMA is bypassing the
uplink signal around the failed receive amplifiers. A fixed bypass loss of 1.5 dB is
assumed (no MIB parameter).
Parameter Object Description
MIM Parameters
antennaPortTable:
antennaGain TMA gain
antennaPortEntry
antennaPortTable: cable loss from antenna to

antennaPathAttenuationUL
antennaPortEntry RFM/cabinet port
antennaPortTable: jumper cable loss (cabinet port to

antennaPortInternalLoss
antennaPortEntry TRDU port)
Table 10: MIM/MIB Parameters Related to Receive Path Gain Compensation
These parameters are used by the RFM as follows:
Page 62/308
1. When the TMA is not present then only the antenna cable loss (including any
internal jumper cable loss) is considered in the receive path gain calculation.
2. When the TMA is present and enabled then the antenna cable loss is summed
with the TMA nominal gain to determine the RFM-external receive path gain. For
Remote TMAs the gain is assumed to be always enabled.
3. When the TMA is present but disabled then the antenna cable loss is summed
with the TMA bypass loss to determine the RFM-external receive path gain (or
loss in this case).
The RFM is configured with the receive path information and TMA current status
using the TTLNADATA attribute. The specific data fields used are summarized in
Table below. The RFM acts on these settings as follows:
1. GAINn: This is the gain (when active) of the TMA itself. In LA6.0.0 like in LA5.0
the TMA gain is fixed so this is just the gain value read from the TMA itself, or the
ttlnaAntennaGain value provided by the operator for the remote TMA.
2. CABLEn: This is the antenna cable loss between TMA and RFM antenna port
and the cable loss between TMA and the antenna panel (tbc). GAINn minus
CABLEn gives the net gain between RFM and antenna, and represents the
additional attenuation that should be configured by the RFM while the TMA is
active.
3. COMPn: This is the gain compensation to be factored in when the TMA fails or
goes into bypass. This may differ from GAINn by the additional loss provided by
the bypass circuitry of the TMA (typically about 1.5 dB).
4. STATEn: This parameter tells the RFM which values to consider when
determining external path gain/loss. STATEn values and their handling include:
• NONE- There is no TMA (either remote or locally-controlled) so RFM assumes
no external path loss/gain.
• DISABLE- A TMA is present but currently failed or in bypass. External path loss
is GAINn minus CABLEn minus COMPn.
• EXTERNAL- A TMA is present and active. External path gain is GAINn minus
CABLEn. The RFM does not monitor DC current levels on the TTLNA DC current
supply.
• ENABLE- Not used in this configuration. ENABLE is defined for use when the
RFM supplies DC current to the TTLNA and is expected to monitor the current
level for alarm status. However this option is not used in the AISG TMA or remote
TMA configurations.
Note that TTLNADATA settings are acted on by the RFM upon receipt and also
stored into RFM non-volatile memory. Following RFM reset or power cycle these
settings are applied again until the RFM receives another TTLNADATA attribute
that may change them.
Page 63/308
Datafield Description Value
TTLNADATA
GAIN1
RF gain of the TMA on RFM antenna Set to antennaGain for assignedPortNumber=
port 1 or 2 1 or 2
GAIN2
CABLE1 Set to antennaPathAttenuationUL (plus

Cable loss from antenna to RFM ports
antennaPortInternalLoss if populated) for
1 or 2
CABLE2 assignedPortNumber= 1 or 2
COMP1 Amount of Rx attenuation to add to

Set to antennaGain for assignedPortNumber=
path 1 or 2 when the TMA is
1 or 2 minus TMA Bypass Loss (1.5 dB)
COMP2 disabled.
STATE1 Set to EXTERNAL when AISG TMA is not in

bypass, or when Remote TMA is present.
Indicates whether the TMA is
currently active Set to DISABLE when ALDs are present and the
AISG TMA is in bypass due to failure or being
STATE2
configured to bypass.
Table 11: Configuring RFM Receive Path Gain Compensation
CABLEn :antenna cable loss

between TMA and RFM & Antenna
and TMA:
antennaP athAttenuationUL GAINn :the gain (when active) of
TMA
the TMA itself:
ttlnaAntennaGain
RF cable
RS-485
RRH1
α β γ
CPRI
Backhaul
BBU
Backhaul
Figure 16: Path Gain budget on RRH
Page 64/308
CABLEn :antenna cable loss

between TMA and RFM & Antenna
and TMA (feeders): GAINn :the gain (when active)
antennaP athAttenuationUL TMA of the TMA itself: ttlnaAntennaGain
RF cable
RS-485
α β γ
antennaPortInternalLoss :
(jumper) (hardcoded
TRDU α
TRDU β
param.)
BBU
CPRI
Backhaul
Backhaul
Figure 17: Path Gain budget on TRDU
Note: The OAM will be able to perform path delay calculation for each of the RF
paths and perform compensation on the pair of paths of each of the Ltecell they
support.
4.4.2 DISTRIBUTED ANTENNA SYSTEM (DAS)

CONFIGURATION L92811.1
As illustrated in the Figure 18, the idea is to split the transmitted signal among
several antenna sites, separated in space so as to provide coverage over the
same area as a single antenna but with reduced total power and improved
reliability. A single antenna radiating at high power (a) is replaced by a group of
low-power antennas to cover the same area (b). Some of the other advantages
of DAS include the ability to provide service for multiple wireless carriers (e.g., T-
Mobile, AT&T Wireless and Sprint/Nextel) without the need to have separate
antenna sites for each carrier at each location and the ability to place the
antennas on existing vertical structures such as light or utility poles.
The DAS antennas are typically mounted 20-40 feet above the ground. The DAS
antennas are designed to send the vast majority of the RF energy straight out
from the antenna, (i.e., parallel with the ground), with only a small fraction of the
energy emitted down towards the ground or up towards the sky.
Page 65/308
Figure 18: Antenna without and with DAS
DAS is supported for following bands: band XIII with 10MHz, AWS band IV with 5
and 10 MHz, lower 700 MHz band XII and band XVII with 5 and 10 MHz, upper
700MHz band XIV with 5 MHz.
DAS eNodeB support configurations from 1 up to 3 RF sectors, support 2x2
downlink MIMO, support -48VDC power supply (with -48V BBU and -48V
TRDU2x/RRH2x), support +24VDC power supply (with +24V BBU and +24V
TRDU2x), support both RACH 0 and RACH formats and according maximum
distance for fiber separation, support connection with external DAS interface unit
to provide external attenuation (Active DAS) and Splitting/Combining (Single Tx/
Single Rx)
Active DAS :eNodeB will support RF Output Power at the Equipment Antenna
Connector configurable to 1W per transmit path for Active DAS configuration.
Passive DAS :DAS eNodeB support RF Output Power at the Equipment Antenna
Connector configurable in the dynamic range of 1W to 40W per transmit path for
Passive DAS configuration.
Restriction: Active and Passive DAS in LA6.0.0
Active and Passive DAS simultaneous support are considered as separate

instances. ALU does not support the two as existing in one configuration.
The DAS eNB shall support distances between the d2U LTE Module and the
DAS antenna adding up to a maximum of 15 km. This may require Fiber delay
compensation feature (L100622) for eNB, UL & DL delays to be configured
independently.
Note: This distance includes distance of the CPRI link between the BBU and the
RF Module and the distance of the RF path of the DAS system.
Engineering tasks shall take into account the geographical topology and the
delays introduced by the optical fibers
Page 66/308
isDasDelayEnabled - parameter enables the provisioning of

"antennaPathDelayUL" and "antennaPathDelayDL" (see 5.2.6 and 5.2.7)
values that are larger than 2100ns, in support of DAS systems. The parameter
values are as follows:
• True: Path Delay values larger than 2100ns may be provisioned.
• False: maximum permitted Path Delay value is 2100ns.
This parameter is feature licensed parameter (L115670)
L115670: licenses the capability of the eNB software to compensate for delays
introduced due to a fiber link between the radio (RRH/TRDU) and DAS antenna
CellActivationService::isDasDelayEnabled
Parameter isDasDelayEnabled
Object ENBEquipment/CellActivationService
True, False
Class/Source B--Cell / customer_settable
Feature L115670
If isDasDelayEnabledis set to False, the parameter will be limited to a maximum
of 2.1 us (500m) between radio (RRH/TRDU) and DAS antenna like in LA3.0. In
this case eNB raise an alarm if the BBU-Radio link exceeds 500 m.
For diagram and table below, we consider 3 following definitions and

assumptions:
L1: Fiber optic link distance between BBU and RRH (can be measured by
platform S/W)
L2: Delay between RRH and DAS antenna (configures via OAM with
antennaPathDelayULandantennaPathDelayDL)
L3: Over The Air (OTA) distance between DAS antenna and UE (compensated
via timing advance sent in RACH Msg2). Limited by RACH format (format 0
=>limit is 14 km, format2=> limit is 30 km) Optional L100622
L2 Determination:
There are two options for getting the info to populate these two parameters. There
are described in decreasing order of accuracy.
Better delay parameter accuracy will give better UE position accuracy.
• Use a time domain analyzer to directly measure the cable delay (requires
disconnecting the antenna cable from the RF head). Most accurate
method.
Page 67/308
• Measure length of the antenna cable in meters

cable_delay in ns = (cable_length_in_meters)*(propagation delay in ns/m)
If velocity factor (VF) from specs of the specific cable in use are known
then propagation delay in ns/m = 1/(velocity factor)*(speed of light) =
10/(3*VF).
So cable_delay in ns = (cable_length_in_meters)*10/(3*VF)
If specs for specific cable are not known, use 5ns/m as rule-of-thumb
propagation delay.
So cable_delay in ns = (cable_length_in_meters)*5
In LA3.0, eNB-DAS Antenna delay (L2) directly reduces Over-The-Air radius (L3)
if this delay was greater than 2100ns (0, 4 Km) because range of parameters
antennaPathDelayUL and antennaPathDelayDL was limited to 2100ns.
α DAS
α
AntennaPort [1..8]::
α
antennaPathDelayUL
L3 UE
antennaPathDelayDL CellRadius
L2
Splitter
RF cable
Auto-compensation RRH1
[FRS 100622] L1
α β γ
CPRI
Backhaul
BBU
Backhaul
Figure 19: Delay Budget with DAS (SISO example)
eNodeB will display an alarm and indicate the total delay if the required delay
compensation budget (200us RTD) is exceeded.
L1 L2 L3 constraints
Page 68/308
Max BBU-RRH
Distance : Auto- Max RRH-Antenna L1+L2
compensation Delay Max Cell Radius constraints
L3km=(48us+2, 1us-
400m (2, 1us) L2us)/ L1+L2 ≤ 10km
LA3.0 10km OAM Compensation 3, 3us/km 50us
15km fiber
equivalent
LA5.0 75us
and 15km (75us) OAM compensation 14km(RACHFmt0) L1+L2 ≤ 15km
onwards L100622 L115670 30km(RACH Fmt2) 75us
Table 12: Delay Compensation Capability Summary with DAS
Delay between modem and radio (licensed by L100622) is optional because it

does not apply when modem and radio are co-located.
In LA5 and onwards, eNodeB support a total distance from BBU to Antenna tip
(BBU to Radio + Radio to Antenna tip) of up to 15 km without impacting the
maximum over-the-air cell radius.
Note: RACH Format-2 FID L92639 can be combined with this Feature without
being impacted (i.e. 15 km Fiber + 30 km cell-radius)
L100622 enables the eNodeB to adjust its PRACH search window to compensate
for total round trip delays up to and including 200us between the channel unit and
antenna tip, which corresponds to eNodeB hardware plus a total of 15 km of fiber.
L100622 is designed to be required for BBU hoteling applications where BBU and
RRH are relatively far apart, but to not be required for same-building applications
where BBU and RRH are relatively close together (for example, BBU in the
basement, RRH on the rooftop).
Note: Although the L100622 feature adds support for the total round trip delay, the
license for L100622 only applies to L1. This permits L100622 and L115670 to be
sold independently.
The two features can be used together, subject to the total round trip delay. These
features are related to TA estimation at PRACH (the first TA value available at
PCMD), which is related to the PCMD geolocation trial. Getting accurate TA from
PRACH will be helpful for PCMD geolocation.
In LA5.0, L100622 is available for bCEm.
Rule: Fiber Delay Compensation with bCEM
With bCEM, all cells served on the same eNB need to use fiber lengths which
are covered by exactly one of the following two ranges:
All fiber lengths within 0-10 km, using a modem timing scheme with maximum
total RTT of 170 us
Configured fiber lengths 5-15 km, using a modem timing scheme with maximum
Page 69/308
total RTT of 200 us
If the spread of RTT values is too large, the way to fix this is to insert a longer
fiber on cell with delay <100000ns so that it's at least 100000ns prior to
upgrading to bCEM.
The above restrictions are due to the fact that CPRI rate 5 has half the buffer
as that of CPRI rate 3 and hence can allow a differential of only up to 10 km
between the fiber lengths of different cells controlled by a single bCEM.
Note that CPRI rate 3 can cover the full range 0 .. 15 km as it has a larger
buffer.
eCCM measures Round Trip Delay (modem to radio EAC) and adds
antennaPathDelayUL and antennaPathDelayDL to get totalRTT; eCCM adds
artificial delay if needed to meet the target twoWaysEnodebHwDelay needed by
the bCEM (170 us or 200 us):
totalRTT + artificial delay = twoWaysEnodebHwDelay
Support on bCEM require adding the following additional parameter:

ENBEquipment::maxTransportFiberDelayLengthCategory (refer to section
5.4 )
Additional requirement:
For all cells of the eNodeB, either each cell’s total fiber length must be 0-10 km
inclusive, or each cell’s total fiber length must be 5-15 km inclusive, where total
fiber length is the sum of BBU-RRH fiber length and the fiber length
corresponding to the 1-way antenna path delay (regardless of whether the real
antenna feeder is fiber or not).
1-way antenna path delay is the average of antennaPathDelayUL and
antennaPathDelayDL
Page 70/308
On the figure below use the following legend:

• maxCat (maxTransportFiberDelayLengthCategory)
• twoWayDelay (twoWaysEnodbHwDelay)
Figure 20: Delay Budget management with bCEM
4.4.3 FEATURE L100622 - SUPPORT FIBER DELAY (OR ANY

DELAY BETWEEN MODEM AND RF HEAD) IN LTE
The fiber connection between LTE modem and RRH adds delay to eNB timing.
This delay impact PRACH processing due to the round trip delay that will skew
the RACH preamble arrival time at the eNB. eNB must adjust the center of its
search window so that the search window range of eNB can be used fully for cell
range. In addition, there may be other digital delay within the eNB and other
external delay after ALU's RRH/TRDU such as fiber to a DAS (Distributed
Antenna System) system or use of repeaters. The external delay can also be
accounted for in this feature as long as the total delay of ALU equipment and
external delay is within the compensation range. If Feature L100622 is activated,
distance between Baseband and RF Cabinet can be up to 15 Km.
Parameter that is added to support Feature L100622 is: isFiberDelayAllowed.
This parameter enables or disables support for large delay between modem and
RF head or to the antenna.
This parameter is feature licensed parameter (L100622: Support Fiber delay (or
any delay between modem and RF head) in LTE)
Page 71/308
CellActivationService::isFiberDelayAllowed
Parameter isFiberDelayAllowed
Object ENBEquipment/CellActivationService
[True, False]
Class/Category B--Modem+Cell(s) / customer_settable
Feature L100622
4.4.4 RECEIVE DIVERSITY EXPANSION MODULE

(RDEM) L106226 - ENODEB 4XRECEIVE DIVERSITY
L115562 - SINGLE TRANSMIT SCHEME ANTENNA
L84815
4.4.4.1 AWS RDEM CONFIGURATION L106226
Receiver Diversity Expansion Module (RDEM) adds the RF Front End for 2
Receivers in order to increase the total number of Receive Paths of an RRH2x
from 2 to 4. The main LTE application of the RDEM is to support 4-way Rx
diversity however it can also be used to support 2 sector configurations in Single
Tx Dual Rx mode using a single RRH2x with the RDEM
The RDEM is blind mate connected to the RRH. The RDEM is designed in a way
that allows the installation together with the RRH.
In LA6.0.0 like in LA5, the only RFMs that are supported for the 4x RX feature
are:
• The PCS one (Panasonic RRH that supports CPRI rate 2 maximum).
• The 2.6 GHz one.
• The AWS one.
Nevertheless, the 4x Rx feature should not be implemented specifically to this

frequency band; this is more likely a test restriction.
Page 72/308
Figure 21: Functional block diagram of RRH with RDEM for 4-Rx Diversity
The RDEM defined for feature L106226 is intended to support four branch receive
diversity for AWS NG2 RRH. It provides filtering and gain to RRH radio for
branches 3 and 4.
The AWS NG2 RRH is a two transmit LTE module, capable of supporting 40 W
per transmit port.
The RRH supports application code for RRH + RDEM self-test and calibration at
boot-up.
The differential delay between the two diversity paths within the RDEM shall
be no more than 30ns
The RDEM supports calibration and self-test using the test path and switches that
are shown in Figure 21. The calibration data supports RSSI check (for
connectivity), Rx path gain test, and Rx VSWR. As well, it helps validate absolute
delay.
Figure 22 shows a typical RDEM installation on the side of an RRH.
Page 73/308
Figure 22: Typical RDEM Mounted on the Side of a Remote Radio Head
4.4.4.2 4X RECEIVE DIVERSITY PATHS L115562
Restriction: L115562.1 in LA6.0.0

In LA6.0.0 like in LA5.0.0, only eCEM part of the feature is concerned.
L115562.1
Feature 115562 enables the support of 4x Receive diversity paths on the

eNodeB. The 4x receive diversity feature aims to reduce the link budget gap
between the spectrums, thus match the LTE coverage with the customer existing
2G/3G system. The feature can also be used by customer to increase the cell
throughput for a given cell radius via different SINR target configurations.
Page 74/308
Feature 115562 is able to support 4Rx per 5MHz carrier (up to 2 carriers per
RRH) as per L115512.Both carriers (total of 6 sector carriers) will be supported on
a single bCEM.
Restriction: L115562 in LA6.0 like in LA5.0

In LA6.0 like in LA5.0, in general 4x Rx diversity is not supported for
bandwidth larger than 10Mhz due to the maximum rate of 2, 4 GHz (rate 3)
being supported on CPRI and HSIQ links.
In LA6.0 like in LA5.0 there is no configuration supported with 10Mhz
bandwidth.
• One sector 5Mhz carrier per eCEMu board (3 boards max thus 3 sectors
max).
• Three sectors 5Mhz carrier per bCEM board (1 board max thus 3 sectors
max).
But for band II (PCS), as Panasonic RRH support CPRI rate 2 maximum,
meaning that 4x Rx diversity won’t be supported for bandwidth larger than
5MHz with this RRH.
sectorNumber
LTE Cell
OfRxAntennas Number of
FDD. RRH +
(computed Is cell Rx antennas
use case Number RDEM Rx any alarm raised ?
based on setup ? the cell is
Of UL paths
AntennaPort setup with
antennas
table)
Nominal 2 Rx config 2 2 2 yes 2 no
RDEM is installed, no
2 2 4 yes 2 no
config change yet
RDEM is installed,
Antenna port table
2 4 4 yes 2 no
updated, LTE Cell not
yet
4 Rx config 4 4 4 yes 4 no
Antenna port table is

not consistent with HW
yes, to state that
capabilities. Maybe
2 4 2 yes 2 antenna config does not
some RDEM
match the HW
installation on site
pending
LTE cell is updated to 4
Rx but the HW does yes, LTE cell config is
not support it. Maybe 4 2 2 yes 2 not consistent with the
some provisioning error HW
(wrong LTE cell?)
LTE cell has been
updated to 4x Rx, and yes, to state that cell
the HW does support it; config matches the HW
4 2 4 yes 2
Maybe some antenna but not the antenna
port table update config
pending?
LTE cell has been yes, to state that the cell
updated to 4x Rx, and config is not supported
4 4 2 yes 2
the HW does not by the HW (RRH without
support it RDEM)
Table 13: Sum-up of possible HW and SW configurations in LA6.0.0 tbc
Page 75/308
numberOfULAntennas specifies the number of UL antenna configured and used

for the cell. Supported values are {1, 2, 4}.
numberOfULAntennas is used to enable the licensed features Single Rx Mode
and 4x Receive Diversity. When numberOfULAntennas is set to ulAntenna1,
then Single Rx Mode is enabled. When numberOfULAntennas is set to
ulAntenna4, then 4x Receive Diversity is enabled.
LteCell::numberOfULAntennas
Parameter numberOfULAntennas
ulAntenna1(0), ulAntenna2(1), ulAntenna4(2)
Class/Source B--Cell+RF(s) / customer_settable

Value Default: ulAntenna2
Feature 159168, 161001
After each configuration change eNodeB software checks all relevant aspects of
an operator-provided configuration against the available hardware. These checks
may discover hardware capability deficits falling into 2 categories:
• structural deficits (e.g. missing antenna ports) are alarmed and prevent
operation
o Cells won’t go into service and an alarm will be raised.
• capacity deficits (e.g. insufficient RFM power, insufficient controller or
modem capacity) are alarmed and downgraded
o Cells will go into service and a warning alarm will be raised.
Rule: Parameter LteCell::numberOfULAntennas
If the Hardware capability reported by the RFM is lower than the required one
(e.g. RFM reports only 2 Rx antennas whereas the cell to be configured on this
RFM is defined as using 4 Rx), an alarm must be raised by ENB to the
supervision system.
The check to be executed:
• LTEcellFDD.numberOfULAntennas <=
Sector.SectorNumberOfReceiveAntennas
According to the feature requirements it’s stated that the 2 additional Rx paths
provided will not be used until the antenna port table is updated accordingly.
This means that the number of antenna ports with the “RxUsed” flag set to true
can be lower than or equal to the number of receive paths reported by the RRH.
Page 76/308
Restriction: mismatching on some 4Rx configurations may lead to cell

outage
On some configurations, applying a 4 Rx Diversity Antennas

configuration on a Cell when only 2 Physical Antennas are
present may cause the cell to remain disabled and an alarm to be
raised.
4.4.4.3 SINGLE TRANSMIT SCHEME ANTENNA L84815
For a configuration with two antennas and when the diversity is allowed, the
Primary and Secondary Synchronization Signals are transmitting over both
antennas. If not, the PSS and SSS are transmitting over only one antenna.
Refer to [Vol. 4] for the parameter
CellActivationService::isSyncSignalsDiversityAllowed
When “isSyncSignalsDiversityAllowed” is set to true, the modem transmits the

PSS and SSS on both antennas. Then, the power configured by the operator
through the attributes under “PowerOffsetConfiguration” object
(referenceSignalPower, “primarySyncSignalPowerOffset” and
“secondarySyncSignalPowerOffset”) shall be shared on both antennas
statically.
When “isSyncSignalsDiversityAllowed” is set to false, the modem transmits the
PSS and SSS on the antenna port 0. Then the whole power configured by the
operator through the attributes under “PowerOffsetConfiguration” object
(referenseSignalPower, “primarySyncSignalPowerOffset” and
“secondarySyncSignalPowerOffset”) shall set to the antenna port 0.
Another related parameters:
LteCellFDD :: transmissionMode (see [Vol. 4]) can be set to tm1 or tm2

LteCellFDD::numberOfDLAntennas can be equal to 1 or 2
numberOfDLAntennas specifies the number of DL antennas configured for the

cell. The supported values are {1, 2, 4, 8}.
WARNING: This parameter is mapped into the licensing system. Therefore, no
change in the definition of this parameter can be made without the agreement of
the OMC licensing subsystem team.
Page 77/308
LteCellFDD::numberOfDLAntennas
Parameter numberOfDLAntennas
Object ENBEquipment/Enb/LteCell/LteCellFDD
1, 2 step=1
Class/Source B--Cell+RF(s) / customer_settable
Value Default: 2
Feature L84815
Note: From a configuration check perspective, before setting up the cell, eNB
OAM should check that:
LTE cell FDD.numberOfDLAntennas come from hard coded parameter
Sector.SectorNumberOfTransmitAntennas
Rule: Parameter LteCellFDD::numberOfDLAntennas
If the value of parameter is to be changed, then the modem should be reset to

achieve changing. RRH will need to be reset by ENB OAM (RESET_REQ
action is sent to RFM RO managed by HRAL) so that the new configuration is
taken into account.
For MIMO configuration, set this parameter value to 2.

For SIMO configuration, set this parameter value to 1.
Restriction: L84815 in LA6.0.0 like in LA5.0.0
The Synchronization Channels Diversity feature is in restriction. It corresponds

to the isSyncSignalsDiversityAllowed MIM parameter in
CellActivationServicesMO.
This means that no interaction is to be considered in this document between
Single Transmit Scheme Antenna feature and Synchronization Channels
Diversity feature for LA6.0 TBC
There is no specific hardware configuration check to be implemented for this

feature; it is supported on eCEMu, bCEM, legacy controller and on any RRH or
TRDU.
Since all configurations parameters are setup at SAM and/or WPS, there is no
specific check to be done at ENodeB level.
Moreover, since 1 Tx antenna is indeed the minimum configuration supported by

the hardware, there is no check “logical configuration” over the “physical
configuration” to check if the required configuration can be supported.
Note that for some configurations using the ROCM (Reverse OneBTS CPRI
Module) we have to support using either of the two available Tx/Rx paths on the
configuration of the ltecell.
Page 78/308
• Configuration using 2 transmit antennas:

The transmissionMode and the numberOfDLantennas are sent to the modem
as part of the cell setup.
If there are 2 Tx antennas configured on the LTE cell, it means that the modem
will transmit the PSS and the SSS on the first transmit path (the Main one).
Then if the main transmit path fails, ENB OAM needs to disconnect the modem
“antenna path 2 (div)” (the RRH transmit path that is still up, the diversity one) and
then connect the modem “antenna path 1 (main)” on it.
Doing that, we ensure that these channels are still transmitted, keeping the cell
alive and usable for UEs. The cell then behaves as a “Single Transmit” one since
the second transmit path is not operational. When the second Tx path becomes
operational back, the modem “antenna path 2 (div)” is connected to the again
available RRH path.
If the cell has been setup with 2 transmit antennas and one fails, there is no
automatic reconfiguration (at modem level, done by ENB OAM) to change the
transmissionMode or the numberOfDlAntennas. The configuration sent to the
modem is the one from the MIM and is not modified by the SW. These
parameters can only be changed thanks to some on-line commands from SAM
(and/or NEM).
If the cell has been setup with 2 transmit antennas and one fails, ENB OAM is
notified by the RRH that there is a Tx path failure. This is reported thru HRAL SW
to ENB OAM and ENB OAM does not need to take any modem “reconfiguration”
defense action. Since there is no more than 2 Transmit paths available on each
RFM as of now, in case of Tx path failure, there is no reconfiguration (using a
spare) possible. ENB OAM still needs to report the failure to the supervision and
to compute the RFM, the sector and the cell operational state. If there is still one
Tx Path that is enabled on the RFM, the RFM should remain enabled, degraded.
The Sector and the LTE cell operational state and availability status should also
be updated accordingly.
• Configuration using 1 single transmit antenna:

This Single Transmit configuration can be used either to save cost or to interface
a DAS (Distributed Antenna System).
If the LTE cell is configured in Single Transmit scheme (numberOfDlAntennas =
1), it may mean that this cell uses only one Tx antenna out of the 2 available on
the RRH. If this is the case, the second Tx path on the RRH can be considered as
a spare one, if not used by any other cell.
If the LTE cell is configured in Single Transmit scheme and if the used transmit
path fails, ENB OAM will be notified by the RRH thanks to the HRAL SW. Then
ENB OAM should check whether there is a redundant Transmit path for this cell,
and if there is, ENB OAM should:
Page 79/308
• Reconfigure the RRH to transmit using this spare path instead of the
failed one
• Reconfigure the data routing on the controller between the modem and
the RRH
• Report the fault to the supervision system and compute the impact on the
service
If this happens, when the failed transmit path is back operational, it becomes a
spare one. There is no further reconfiguration or defense action to be done.
4.4.4.4 OAM IMPACTS
ENB OAM needs to implement the configuration checks as defined for the 4x Rx
feature and the 4x Rx paths configuration in the eNodeB (includes the RRH, the
controller IQ data switch, delay compensation).
ENB OAM also needs to take into account the defense actions:
• to reconfigure the cell on the RRH if one Rx path fails and there is a
spare one available, and update the modem UlAntennaGain table
accordingly
• to reconfigure the cell on the RRH if one Tx path fails and there is a
spare one available
• to switch the modem “antenna path 1 (main)” to the remaining spare Tx
path if the Tx path that bears “antenna path 1 (main)” fails and there is a
spare Tx path available (numberOfDLAntennas parameter bigger than
1).
ENB OAM has to report the RDEM inventory information to the supervision
system (NEM and/or SAM) thru the SNMP remoteInventoryTable.
ENB OAM needs to support the on-line parameter change scenario for the Class
C parameters (UlAntennaGain) and class B-cell (logical cell reset) on eCEMu
and bCEM.
The CellActivationService::IsSyncSignalsDiversityAllowed flag describes the
following modem behavior:
If the Modem does not support placing the LteCell control channels on both
Transceiver Ports on the RRHs, then IsSyncSignalsDiversityAllowed = false is
set and eNB OAM must try to switch the control channel path in case of a Tx path
failure.
If the Modem supports placing the LteCell control channels on both Transceiver
Ports on the RRHs, then IsSyncSignalsDiversityAllowed = true is set and eNB
OAM must not switch the control channel path in case of a Tx path failure.
In case of SIMO configuration with 2 Transceiver Ports on the RFM, OAM must
reconfigure the faulty Tx path to the available spare Tx path.
Page 80/308
4.4.5 CARRIER AGGREGATION (160847)

4.4.5.1 FEATURE ACTIVATION
LR13.3 introduces DL carrier aggregation with up to 2 serving cells (feature

160847). Carrier aggregation is only supported on bCEM boards, there can be 1,
2 or 3 bCEM per eNB. The Primary Cell (PCell) that provides the RRC
connection, NAS mobility information (e.g. TAI) and security and the Seconday
Cell (SCell) that is aggregated with the PCell for increased bandwidth have to be
mapped into the same bCEM (carrier aggregation across different bCEM boards
would require complex inter bCEM communication). One bCEM is dedicated to
the cells within the same sector and three bCEMs are needed to cover the 3
sectors of a site, 2 carriers aggregated within each sector (the sector shall be
configured with 2Tx & 2Rx).
The mapping of cells on bCEM board is controlled by the parameter
eNB::cellMappingOverBoard. By default in LR13.3.L, this parameter is set to
value “modeNonCA”, where cells of a given sector are configured on different
bCEM board, and shall not be changed by customers that are not planning to
activate CA Feature in LR13.3.L. For customers with 3 bCEM boards, and willing
to activate CA feature in LR13.3.L, it is mandated to change the eNodeB
parameter “cellMappingOverBoardMode” and set it to “modeCA”. The entire
eNodeB must then be reset to enable this mapping to be put in place.
eNB::cellMappingOverBoardMode
Parameter cellMappingOverBoardMode
Object ENBEquipment/Enb
modeNonCA, modeCA
Class/Source A / Customer_settable
Value Default = modeNonCA
Feature 160847
Pre-requisite before mapping cells to the same bCEM board:

1) Check that Dual Carrier Feature is activated;
ActivationService::isDualCarrierEnabled == TRUE
2) Check through the eNodeB inventory that 1 bCEM or 3 bCEMs are present in
the eNodeB.
3) Check that eNB::cellMappingOverBoardMode = ‘modeNonCA’
4) Check that 2 “LteCell” MOs are provisioned within the “Enb” MO if 1 bCEM is
present. Check that 6 “LteCell” MOs are provisioned within the “Enb” MO if 3
bCEMs are present
5) Check the eNodeB configuration database is validated by WIPS
Page 81/308
6) Check that the 2 “LteCell” MOs are configured with the same
LteCell::carrierAggregationCellGroup if 1 bCEM. Check that each couple of
“LteCell” MOs belonging to the same sector are configured with the same
LteCell::carrierAggregationCellGroup if 3 bCEMs.
7) Check that each couple of “LteCell” MOs with the same
LteCell::carrierAggregationCellGroup is configured with
FrequencyAndBandwidthFDD::dlEARFCN (see [Vol. 3]) in the supported bands
combination: B4+B17; B2+B17
8) Check that the each couple of “LteCell” MOs with the same
LteCell::carrierAggregationCellGroup is configured with
FrequencyAndBandwidthFDD::dlBandwidth (see [Vol. 3]) in the supported
bandwidths combination: 10+10; 10+5
9) Check that the 2 cells of each sector are covering the same geographical area
(i.e. azimuths, longitude and latitude should be close). This implies the fiber
between D2U & the RRH supporting the 2 cells of the sector must be of similar
length. The following parameters could be analyzed to check this:
LteCell::mainAntennaConfiguredPositionLatitude
LteCell::mainAntennaConfiguredPositionLongitude
AntennaPort::azimuth
LteCell::carrierAggregationCellGroup
Parameter carrierAggregationCellGroup
Range & Unit
Integer 0, 2
Class/Source A / Customer_init
Value NA
Feature 160847
Carrier aggregation is activated by setting parameter to

ActivationService::isCarrierAggregationEnabled “True”:
Page 82/308
ActivationService::isCarrierAggregationEnabled
Parameter isCarrierAggregationEnabled
Range & Unit
Boolean True, False
Class/Source C--New-set-ups / Customer_settable

Feature 160847
4.4.5.2 “TEMPORARY NON-CA MODE”: CELL

REMAPPING IN CASE OF MODEM FAILURE
The target of the cell re-mapping is to recover LTE service in all sectors upon
permanent modem failures. In this case cells with the same frequency are
assigned to the same modem. The eNB is put in temporary non-CA mode. CA is
not applicable in this mode anymore since the cells belonging to the same CA cell
group are assigned to different modems (no inter-bCEM CA supported).
If a failed modem becomes operational again and the number of modems is
sufficient to support CA, eNB OAM re-assigns the modem resources to enable the
use of CA again.
The autonomous cell re-mapping is controlled by two MIM flags:
Enb::isCellRemappingForCoverageRecoveryEnabled
True: Cell re-mapping from CA mode to temporary non-CA mode is allowed.
False: eNB remains in CA mode. At least one sector is out of service. Manual
recovery is possible by setting Enb.cellMappingOverBoardMode = ModeNonCA
during low traffic times.
Enb::isCellRemappingForCarrierAggregationRecoveryEnabled
True: Cell re-mapping from temporary non-CA to mode CA mode is allowed.
False: eNB remains in temporary non-CA mode. Manual recovery to CA mode
possible by resetting eNB during low traffic times.
Page 83/308
eNB::isCellRemappingForCoverageRecoveryEnabled
Parameter isCellRemappingForCoverageRecoveryEnabled
True, False
Class/Source C--Immediate-propagation / Eng_tunable
Value Default = true
Feature 160847
eNB::isCellRemappingForCarrierAggregationRecoveryEnabled
Parameter isCellRemappingForCarrierAggregationRecoveryEnabled
True, False
Class/Source C--Immediate-propagation / Eng_tunable
Value Default = true
Feature 160847
4.5 Multitechno Configurations

Two technologies are supported in given configurations. LTE eNB can share
either MC-RRH or MC-TRX with either GSM BTS or WCDMA NodeB. Detailed
description of available configurations can be found on PEG document. Present
document is only focused on related configuration parameter.
Each technology continues to use its own installation tool.
Inter-working with parameter: CpriRadioEquipment::rfmControlModePrimary
Controller, Secondary Controller, Standalone (i.e., this RE is not shared with
another technology)
This parameter specifies the type of management the eNodeB OAM provides for
the RFM when the unit may be shared with another BTS. Values are –Standalone
Controller (default value), Primary Controller, Secondary Controller.
The MIM is modified to add a parameter (rfmControlMode) within the
cpriRadioEquipment MO to indicate whether the eNodeB is to act as a
Primary(GSM) or Secondary (LTE) controller for a multistandard RE, or if the RE
is Standalone, i.e. supporting LTE only. (REs that serve only GSM/WCDMA do
not appear in the LTE database). It is expected that this parameter is set primarily
by the SAM to allow the operator to change the multistandard RE mode, however
the NEM must also be able to set this parameter locally.
Page 84/308
Note: In GSM/LTE configurations LTE is always configured as the Secondary

REC for the multistandard RE.
MSRE operations differ depending on whether the unit is shared.
4.6 Cabling delays

Figure 23, Figure 24, Figure 25 and Figure 26 show simplified representations of
cabling delays.
Note that the cabling delay does not include the BBU and/or RFM processing
delays. However, it does include processing delay(s) associated with any
additional HW between RFM and antenna (such as the DAS optical host).
Also note that these illustrations focus on delay aspects and show one cell, with 1
antenna per antenna node (one transmit antenna scheme perspective).
BBU
CPRI Link (Fiber) Feeder (Coaxial Cable)
Modem RRH
CPRI Delay
Antenna Path Delay
(BBU-measured)
Figure 23: Simplified view of RRH-based Hardware and associated delays when
DAS is not used (cell view, case of 1 transmit antenna per antenna node)
BBU
DAS
Feeder DAS Fiber Remote
CPRI Link (Fiber) (Coaxial Cable) DAS
Modem RRH Optical DAS Fiber
Unit DAS
Remote
Host Unit
CPRI Delay Feeder
(BBU-measured) Delay DAS Delay
Antenna Path Delay
Figure 24: Simplified view of RRH-based Hardware when DAS is used (cell view,
case of 1 transmit antenna per coverage area)
9412 Compact eNodeB

BBU
CPRI Link Feeder (Coaxial Cable)

Modem TRDU
CPRI Delay
(BBU-measured)
Antenna Path Delay
Figure 25: Simplified view of TRDU-based Hardware when DAS is not used (cell
view, case of 1 transmit antenna per coverage area)
Page 85/308
9412 Compact eNodeB

BBU
DAS
Feeder DAS DAS Fiber Remote
CPRI Link (Coaxial Cable)
Optical Unit DAS
Modem TRDU Host
DAS Fiber Remote
Unit
CPRI Delay Feeder
Antenna Path Delay
Figure 26: Simplified view of TRDU-based Hardware when DAS is used (cell
4.6.1 ANTENNA PATH DELAY DETERMINATION

The antenna path delay represents the delay between the antenna connector (on
the RFM) and the antenna tip. Therefore,
• If DAS HW is not used, the antenna path delay equates to the feeder
(coaxial cable) delay, which is obtained by multiplying the feeder length
by the delay per unit length of the feeder (provided in the feeder technical
characteristics). Typical value is Feeder Length(km)/270ns (assuming 0.9
× C coaxial propagation velocity, where C=3×108m/s is the propagation
speed in free space). Propagation speed approximation is typically 5ns/m.
• If DAS HW is used, the antenna path delay equates to “the feeder
(coaxial cable) delay + the DAS delay”.
The DAS delay is the one associated with the longest fiber delay. The DAS HW
must compensate for the delay spread across the DAS fiber links leading to
different antenna nodes where the configured value is set within 125ns of the
actual value (+/- 125ns equivalent to ~25m of fiber).
The Antenna Path Delay (RF cable) is required to be accurate to within +/-
125ns.
However, if OTDOA (geolocation feature) is used or is planned to be used in the

future, the accuracy of the Antennas Path Delay must be tightened:
For GPS: configured value must be within 20ns of the actual value which is ~4m
error.
For RF: configured value must be within 50ns of the actual value which is ~10m
error.
Please refer to Chapter 11 UE Position Location Support for description of

OTDOA geolocation.
For DAS HW, the DAS installer is responsible for providing the Antenna Path
Delay to this precision.
Page 86/308
4.6.2 CPRI DELAY DETERMINATION

The CPRI delay is the delay between the Modem and the RFM. The CPRI delay
is measured internally by the system and is not entered by the operator. It is
obtained by multiplying the CPRI fiber length by the delay per unit length of the
CPRI fiber (provided in the CPRI fiber technical characteristics). Typical value is
CPRI Fiber Length(km) / 200ns (assuming 2/3 × C fiber propagation velocity).
Note that in the case of TRDU, the BBU (thus the modem) and the TRDU are
packaged-together (in the 9412 compact eNodeB) and the CPRI delay is
negligible.
4.6.3 TOTAL CABLING DELAY DETERMINATION

The (total) cabling delay is equal to the sum of the CPRI delay and the antenna
path delay.
The Antenna Path Delay is input to the system in the
antennaPathDelayUL/antennaPathDelayDL parameters (see sections 5.2.6 and
5.2.7).
In LR13 and since LA5.0, the modem can compensate for up to 75000ns of
cabling delay. Therefore,
• The maximum supported CPRI delay is 75000ns.

• The maximum supported value for
antennaPathDelayUL/antennaPathDelayDL is (75000-CPRI delay(ns))
and if the actual antenna path delay exceeds (75000-CPRI delay(ns)), i.e.
if the cabling delay exceeds 75000ns, then
antennaPathDelayUL/antennaPathDelayDL should be provisioned with
the maximum supported value, i.e. “75000-CPRI delay(ns)”.
Page 87/308
5 INSTALLATION AND COMMISSIONING

PARAMETERS
Note that several Installation and Commissioning parameters that are entered
with the NEM are shown in TEG. This is done to keep all of the IP-related
parameters together. These parameters include the following parameters that are
associated with the Enb object:
• dHcpEnable
• eNodeBoamIpAddress
• eNodeBoamSubNetMask
• eNodeBoamVlanId
Configuration parameters are classified in :
• Alpha parameters are the transport OAM related parameters needed to
set up the backhaul and establish OAM link between the eNB and SAM
(e.g. OAM Vlan).
• Beta parameters are eNodeB hardware and site specific parameters (e.g.
Antenna and RF configuration, Clock configuration, Topology data, RF
Module Information, BTS location, Alarm configuration, NTP Server IP
Addresses).
• Gamma parameters are the telecom related parameters (e.g. S1 and X2
Telecom IP, VLAN and IPsec parameters)
Alpha and Gamma parameters are configured using Netconf

L115221 From LA5.0, Beta parameters are moved from SNMP to Netconf.
This allows the operator to configure the eNB, using the EMS, with a single
configuration file including NetConf alpha, NetConf beta and Netconf gamma
parameters.
L115221 Support for SAM Provisioning of Beta Parameters for bCEM

L115221.1 Support for SAM Provisioning of Beta Parameters for eCEM
However It is possible to use the NEM to modify NetConf alpha and NetConf beta
Parameters
Page 88/308
5.1 CPRI RADIO EQUIPMENT PARAMETERS

The CpriRadioEquipment object represents an RF Module (or RFM - either an
RRH, a TRDU, or an R-OCM – all of which were described briefly in Section 3).
This section describes the parameters that are associated with the RF Module.
Note, the values of all of the CpriRadioEquipment object parameters are set
using the NEM or WIPS as part of Installation and Commissioning.
An indication of the physical location of the RF Module (an RRH, R-OCM, or a

TRDU) can also be stored in the eNodeB during Installation or during eNodeB
assembly. The value of this parameter provides a human-friendly name for the
location of the RFM.
The rfmLocationIdentifier can be set from one of the NEM Commissioning

Wizard screens as shown in Figure 27. Note that on the NEM screen, this
parameter is called the “RFM Location”.
rfmLocationIdentifier is not a MIM parameter in LR13.
Figure 27: NEM Commissioning Screen for RFM Location
rfmControlMode specifies the type of management the eNodeB OAM provides

for the RFM when the unit may be shared with another BTS (for example
L114790). Values are
-Standalone Controller (default value),
-Primary Controller,
-Secondary Controller.
In GSM/LTE configurations the GSM controller is always the primary REC and
the LTE controller is the secondary REC.
Page 89/308
CpriRadioEquipment::rfmControlMode
Parameter rfmControlMode
Object ENBEquipment/CpriRadioEquipment
Standalone, Primary, Secondary
Class/Source A--full-NE-reset / customer_init
Value Default: Standalone
Feature 159488
cpriPort identifies the CPRI port, on the controller, to which the

CpriRadioEquipment is connected.
CpriRadioEquipment::cpriPort
Parameter cpriPort
1..9 step=1
Class/Source N.A. / customer_settable
Value Default=N.A.
Feature 159488, L115850
Rule: Parameter CpriRadioEquipment::cpriPort
When ENBEquipment::expectedModemType is set to MET3C1, then WPS will

check that cpriPort is set to 1
fruId identifies the RFM supporting this CpriRadioEquipment. It maps to the

ritNumber of the related Removable Item (RIT) represented by the FRU.
CpriRadioEquipment::fruId
Parameter fruId
1..65535 step=1
Class/Source N.A. / customer_init
Value Default=N.A.
Feature L115221
Page 90/308
localCellPowerLimit establishes a maximum allowed downlink power for any

cell assigned to this RFM, per certain European requirements. The default is
that no power limit is applied (50dBm maximum cell power allowed).
Warning: The parameter value should be updated only with extreme caution.
CpriRadioEquipment:: localCellPowerLimit
Parameter localCellPowerLimit
Range & Unit Float, dBm
0..50 step=0, 1
Class/Source B--Cells-of-NE / system_restricted
Value Default=50
Feature L115221
Note: A check is performed to ensure the downlink maximum power for any cell
assigned to this RFM is less than or equal to the configured cell power limit. (Cell
association to RFM is determined through the LteCell::CellAntennaPort
objects).
remoteControllerId is a user-friendly identification of the remote controller. It is

used in case of a shared Multi-TechnologyCpriRadioEquipment. If the eNodeB
is of the Metro Cell Outdoor type, then this parameter must not be set.
CpriRadioEquipment::remoteControllerId
Parameter remoteControllerId
Range & Unit String
0..255
Value OD
Feature 159488
remoteControllerId is a text string provided by the operator to describe the

general location of the RFM, or to otherwise identify the RFM.
Page 91/308
CpriRadioEquipment::locationIdentifier
Parameter locationIdentifier
Range & Unit String
0..255
Value OD
Feature L115221
dbu specifies the controller in a multi-controller eNodeB configuration.
CpriRadioEquipment::dbu
Parameter dbu
1..2
Class/Source NA (write at creation) / customer_settable
Value 1
Feature L115158.1
Feature L114792.1 introduces the following capabilities (uses eCEM):
• Ability to request on demand VSWR, RSSI and Tx power levels per

antenna
• This ability is available either at the SAM or NEM GUI.
• RSSI values are calculated via the modem. For this feature eCEM will do
the calculation.
• VSWR and Tx power are performed at the RFM
o VSWR is reported in Return Loss dB range 0.5 to 20dB

o VSWR alarms and thresholds were provided by another feature
in LA2.1 (refer to section 5.2.8)
• Performance Monitor Counters for RSSI and Tx power
o PM counters are per Rx or Tx antenna
o These counters provide min, max and average values for the
granularity period
o Measurements are made every 1 second and at the end of the
period all measurements are averaged. In addition the min and
max for the period are also collected. Uses same method as on
demand for RSSI (modem calculation) and Tx power (RFM
measurement)
Page 92/308
o The PM counter period is set at the SAM.

• Ability to define and set polarity of RRH user alarms
o Up to 6 user alarms are provided
o Definitions strings and polarity can be entered at the NEM.

 Definitions are set by the technician and can be tower
light failure, fire, etc.
o Polarity can be Open on alarm or Closed on alarm
• Ability to set Diversity Imbalance thresholds
o Previously the thresholds were hardcoded and did not allow
flexibility
o Diversity Imbalance uses RSSI values measured by the modem
to determine imbalance. This method allows Antenna Cross
Connect to have diversity imbalance
o Value of 0 disable Diversity Imbalance monitoring for
corresponding cell
diversityImbalanceThreshold specifies the Diversity Imbalance Threshold.
LteCell::diversityImbalanceThreshold
Parameter diversityImbalanceThreshold
Range & Unit Float, dB
0, 20 step=0.1
Value Default=5
Feature L114792
Note: This function is “disable” when the modem supports the ltecell(s) in SISO
(1TX/1RX) mode.
diversityImbalanceThreshold must give the maximum possible difference

between the average RSSI of one Rx path antenna and average RSSI of another
Rx path antenna.
It will be taken into account only the result of 20measures in 20 seconds

For every measure received from RRH, it will be determined the maximum RSSI
∆(RSSI) between antenna >diversityImbalanceThreshold => antenna seen like

unused => diversity Imbalance Alarm is raised. This Alarm indicates that the lower
RSSI path is failed and is raised when the difference is greater than the
diversityImbalanceThreshold.
With a good setting of parameter: LteCell::diversityImbalanceThreshold
diversity feature is working in cross-connected mode.
Page 93/308
If the difference between the averages of two ports exceeds the threshold, the
alarm is generated and have severity of Major.
Figure 28 shown algorithm for OAM Diversity Imbalance Alarm
If (GblDICounter[i] >= M=20s)
& (GblDIAlarmState[i] == OFF) GblDIAlarmState[i] = ON

•YES
NO
Raise DI alarm for antenna i
(GblDICounter[i] < M=20s)
& (GblDIAlarmState[i] == ON)
YES GblDIAlarmState[i] = OFF
and Clear DI alarm for antenna i
Figure 28: Algorithm for OAM Diversity Imbalance Alarm
• M is hardcoded parameter and fixed to 20 seconds which means 20 averages of

measures.
• when all RSSI averaged over 20 sec for all ports – antennas are bellow -95dBm the
values are considered too low and are not taken into account=>no change in alarm status
5.2 ANTENNA PORT&CELL ANTENNA PORT PARAMETERS

Instances of the AntennaPort object and the associated parameter values are
created using the NEM. The AntennaPort object does not appear in the WPS
system.
Instances of the AntennaPort object and their associated parameters are used to
build an “Antenna Port Table” that is maintained in the eNodeB software. Each
AntennaPort instance can be visualized as creating a row in the table, and the
parameter values for that AntennaPort instance are entered in the corresponding
column of the table.
Each instance of the AntennaPort object represents a physical antenna port on
the eNodeB, and provides data about the connection between the eNB’s RF
hardware and the antenna. A maximum of six AntennaPort instances is
supported in LR13. Each AntennaPort instance is associated with an FRU object
that represents an RFM (RRH, TRDU, or R-OCM), and the RFM hardware
typically has two antenna ports.
Page 94/308
5.2.1 ANTENNAPORT ASSOCIATION PARAMETERS

The AntennaPort assignment parameters are used to associate the
AntennaPort object with an RFM and with a Sector.
The SectorID parameter associates the RFM and its antenna ports to a specific
geographical Sector on which the associated antenna is emitting.
AntennaPort::SectorID
Parameter SectorID
Object ENBEquipment/CpriRadioEquipment/AntennaPort
1…9, Step = 1
Class/Source B--Modem+Cell(s) / customer_init
Value O.D.
Feature L115158.1, L114909.1, L115808
In LR13 NEM Commissioning Wizard, two antenna ports are associated with the
RF Module (RFM), and the sector assignment is actually made to the RFM (which
associates the sector with the RFM, and, thus, with the RFM’s two antenna ports).
This is illustrated in the screen capture shown in Figure 29.
Figure 29: NEM Commissioning Screen for Entering Sector Number
AntennaPort::assignedTransceiverPort - parameter identifies the transceiver

port that is connected to the RFM antenna port. The possible values are as
follows. In LA2.0 there was a fixed relationship between the RFM antenna port
number and the Antenna Port Entry. This fixed relationship must be taken out of
the code in LA5.0, like in LA4.0:
0 <=> not connected;
Page 95/308
1 <=> transceiver port number 1;

2 <=> transceiver port number 2 .
If supporting 8 antenna RRH, then the port number range can be 0..8 (TDD only):
0 <=> not connected;

1 <=> transceiver port number 1; …
8 <=> transceiver port number 8.
AntennaPort::assignedTransceiverPort
Parameter assignedTransceiverPort
0…8, Step = 1
Value O.D.
Feature N.A.
Figure 30 : NEM Commissioning Screen for looking at the Port Number matching with
assignedPortNumber
Engineering Recommendation: AntennaPort::assignedTransceiverPort
In the case of CPRI activation for 4Rx, we recommended the following setting
(aligning with MIM Templates)
ENBEquipment/X assignedTransceiverPort 1
CpriRadioEquipment/X
AntennaPort/1
AntennaPort/2
AntennaPort/3
Page 96/308
AntennaPort/4
Sector- 1 Ant 1
Digital
2100
BaseBandUnit RRH 1 B Ant 2
( D2U
Main Street A
or
D1U)
Sector 2
Ant 3
3100 A Ant 4
RRH 2
East Road B
Sector- 3 Ant 5
4100 RRH 3 A Ant 6
West Road
B
Figure 31 : Three Sector Configuration with ‘2x’RRHs
Corresponding Antenna Port Table is provided in Table 14: Antenna Port Table
for Configuration with 2x RRHs
.
Note: Data indicated in blue are set by operator during commissioning
antenna assigned assigned assigned antenna antenna antenna

Port Sector RFM Port Port Label Location
Table Number Number Label Id (from rfm-
Index (optional Table) as
entry, shown by
no NEM
alarm if (not part of
missing) APT in MIB)
1 1 2100 1 B Ant-1 Main Street
2 1 2100 2 A Ant-2 Main Street
3 2 3100 1 A Ant-3 East Road
4 2 3100 2 B Ant-4 East Road
5 3 4100 1 A Ant-5 West Road
6 3 4100 2 B Ant-6 West Road
Table 14: Antenna Port Table for Configuration with 2x RRHs

Note: The Antenna Port Table Index can vary dependent from the order of
discovery of RFMs. The indexes in the table are examples.
Page 97/308
5.2.2 ANTENNA PORT ASSOCIATION PARAMETERS

WITH CROSS CONNECTION
In case of commissioning with cross connection, you must select the appropriate
Sector Allocation
Figure 32: NEM Commissioning Screen for Antenna Cross Connect
NOTE: When the pre-defined Antenna Cross Connect configuration is

selected, NEM will set “Antenna Port Table” automatically for RRH
redundancy configuration:
• • Sector 1 to RFM 1100 and Port 1

On the left panel of NEM window, click on Antenna Ports.

Verify the Antenna Cross Connect Antenna Port Table (APT) populated under
Antenna Ports tab on the right panel of NEM.
Antenna Sector
Port Label
Antenna Number Number RFM Name RFM Location Port Number
1 Port 1 1 1(α) RRH 2-0-0 Cell1 1
2 Port 2 2 2(β) RRH 2-0-0 Cell2 2
3 Port 1 3 2(β) RRH 3-0-0 Cell2 1
4 Port 2 4 3(γ) RRH 3-0-0 Cell3 2
5 Port 1 5 3(γ) RRH 4-0-0 Cell3 1
6 Port 2 6 1(α) RRH 4-0-0 Cell1 2
Figure 33: NEM Commissioning Screen for looking at the Port Number matching with
assignedPortNumber, in case Antenna Cross Connect
Page 98/308
4100
RRH 3 2 Ant 2
Digital BaseBand
Unit
Sector 1 Ant 1
( D2U
2100 1 2
or
D1U ) RRH 1
2 Ant 4
Sector 2
Ant 3
3100 1 2
RRH 22
RRH
- 2 Ant 6
Sector 3
Ant 5
4100
RRH 3
1
Figure 34: Three Sector Configuration with RRH redundancy
antenna assigned assigned assigned antenna antenna antenna txUsed rxUsed

Port Sector RFM Port Port Label Location
Table Number Number Label Id (from rfm-
Index (optional Table) as
entry, shown by
no NEM (not
alarm if part of APT
missing) in MIB)
1 1 1100 1 1 Ant-1 Main Street yes yes
2 2 1100 2 2 Ant-4 East Road yes yes
3 2 2100 1 1 Ant-3 East Road yes yes
4 3 2100 2 2 Ant-6 West Road yes yes
5 3 3100 1 1 Ant-5 West Road yes yes
6 1 3100 2 2 Ant-2 Main Street yes yes
Table 15: Antenna Port Table for Redundancy
Page 99/308
Figure 35: Three Sector Configuration with RRH redundancy with parameters
5.2.3 CELLANTENNA PORT ASSOCIATION

PARAMETERS WITH BAND CLASS 25 (PCS)
L115295
xConnectEnable indicates to the operator whether or not the eNodeB is

configured with the antennas cross connected. The default value is not initially
indicated, but it is automatically changed by OAM if the antenna port entries
indicate that one RFM is supporting two sectors.
ENBEquipment::xConnectEnable
Parameter xConnectEnable
Object ENBEquipment
True, False
Feature L115158.1
Page 100/308
L115158.1 (LA5.0.0 feature) benefit:

• The eNodeB availability time is improved.
• The eNodeB will continue to support traffic on all three sectors if there is a single RRH
failure.
• The Customer will be notified when Ltecells are operating in degraded mode due to an
RRH failure
5.2.3.1 L171049 - ANTENNA CROSS CONNECT (ACC) ON

DUAL BAND ENB CONFIGURATION – MIXED
MODE
This feature is required to address a customer requirement that was overlooked in

LA6.0 for dual band configurations with antenna cross connected. The dual band
feature in LA6.0 only support antenna cross connected for both bands. The
customer expectation was that one of the bands can be with Antenna Cross
Connected and the second band with antennas in standard configuration (non
ACC).
An examination of the original ACC feature only support both frequency bands in
ACC mode, but not a mixture of one frequency band in ACC and the other band
Non ACC.
The current parameter that is used to indicate that the eNodeB is using antenna
cross connected (i.e. xConnectEnable – describe further on this Vol) will
continue to be used until a future release when it would become obsolete.
In LR13.1, the parameter, xConnectEnable is set to true to indicate any or both
bands are using ACC, that at least two ltecells are using antenna cross connected
or all of the ltecells in the eNodeB are using antenna cross connected.
In LR13.1 we cannot support a new parameter to indicate which of the ltecells are
using antenna cross connected. This parameter would be introduced in LR13.3,
the name for this new ltecell parameter is antennaCrossConnected.
To be able to use ACC on one band but not on another, proper set of antenna
port table configuration must be used. Cross connect is set by means of antenna
port table configuration.
Page 101/308
Sector 1
Port1
Ant1 Ant2
CPRI Data cell0 & cell1
RRH
Switch Matrix Band 1 1
Port2
L700
Sector 2
M Por t1
o CPRI Data cell1& cell2
RRH
d 2 Ant4
e L700
Ant3
m
Sector 3
1
CPRI Data cell2 & cell0
Port 1
RRH
3
Ant5 Ant6
L700
Port2
Sector 4
Switch Matrix Band 2
CPRI Data ltecell 3 Port1
Ant7 Ant8
RRH
4 Port2
AWS/
PCS
M Sector 5
o CPRI Data ltecell 4
d Por t1
e RRH
m 5 Ant9
Ant10
AWS/
2 PCS Sector 6
CPRI Data ltecell 5
Port 1
RRH
6 Ant12
Ant11
Dual Band BBU AWS/
PCS
Port2
Figure 36: Physical Antenna Connection for Dual Band in Mixed ACC
Page 102/308
Next table illustrates how the cellAntennaPort instances of each LteCell should be
mapped to CpriRadioEq:AntennaPort are created for 3 sectors 2 freq eNodeB.
The information in this table becomes part of the Work Order to be created. Note
that CpriRadioEquipments are crossed on LteCells of Band 1 but not on LteCells
of Band 2. (Two Antennas per LteCell)
rdnI Description txPath rxPath CpriRadioEquipment antennaPortId

d
LteCell 0 (Band 1)
0 First Rx path False True CpriRadioEquipment_0/AntennaPort_1
1 First Tx path True False CpriRadioEquipment_0/AntennaPort_1
2 Second Rx path False True CpriRadioEquipment_2/AntennaPort_2
3 Second Tx path True False CpriRadioEquipment_2/AntennaPort_2
LteCell 1 (Band 1)
LteCell 2 (Band 1)
LteCell 3 (Band 2)
LteCell 4 (Band 2)
LteCell 5 (Band 2)
Page 103/308
Parameters of CellAntennaPort
LteCel AntennaPortId
CellAntennaPort Tx Rx Band
l CpriRadioE AntennaPor
Use Use
q t
1 True Tru 0 1 1
0 e
2 True Tru 0 2 1
0 e
2 True Tru 1 1 1
1 e
3 True Tru 1 2 1
0 e
3 True Tru 2 1 1
1 e
1 True Tru 2 2 1
1 e
4 True Tru 3 1 2
0 e
4 True Tru 3 2 2
1 e
5 True Tru 4 1 2
0 e
5 True Tru 4 2 2
1 e
6 True Tru 5 1 2
0 e
6 True Tru 5 2 2
1 e
Table 16: cellAntennaPort Configurations for Band 1 ACC and Band 2 Non-ACC
5.2.4 ANTENNA PORT ASSOCIATION PARAMETERS

WITH BAND CLASS 25 (PCS) L115295
antennaPortId is a service link to associate the cell transmit or receive
path/stream with one AntennaPort instance within a CpriRadioEquipment MO.
CellAntennaPort::antennaPortId
Parameter antennaPortId
Object ENBEquipment/Enb/LteCell/CellAntennaPort
Range & Unit ServiceLink
CpriRadioEquipment_x/AntennaPort/n
Class/Source B--Modem+Cell(s) / customer_settable
Value O.D.
Feature L115295
rxPathparameter specifies whether or not the specified antenna port is to be
used as a cell receive path.
Page 104/308
CellAntennaPort::rxPath
Parameter rxPath
False; True
Class/Source B--Cell / customer_init
Value Default: True
Feature L115295
Rule: Parameter CellAntennaPort::rxPath
1. The number of CellAntennaPort instances with rxPath set to True must be

equal to or greater than LteCell::numberofULAntennas.
2. For each CellAntennaPort instance either rxPath must be True or txPath
must be True, or both True.
3. If rxPath is True then the value of rxUsed in the associated AntennaPort

instance must be True.
Note: Read only parameter CellAntennaPort::rxUsageState reports whether or

not a cell receive (uplink) branch is currently active on the specified antenna port.
txPath parameter specifies whether or not the specified antenna port is to be
used as a cell transmit path.
CellAntennaPort::txPath
Parameter txPath
False; True
Value False
Feature L115295
Rule: Parameter CellAntennaPort::txPath
1. The number of CellAntennaPort instances with txPath set to True must be

equal to or greater than LteCellFDD::numberofDLAntennas.
2. For each CellAntennaPort instance either rxPath must be True or txPath
must be True, or both True.
3. If txPath is True then the value of txUsed in the associated AntennaPort
instance must be True.
Note: Read only parameter CellAntennaPort::txUsageState reports whether or

not a cell transmit (downlink) branch is currently active on the specified antenna
port.
Page 105/308
5.2.5 ANTENNA INFORMATION PARAMETERS

The operator can utilize the antennaLabel parameter to provide a user friendly
name that can be used to refer to this antenna/antenna port.
AntennaPort::antennaLabel
Parameter antennaLabel
Range & Unit String
0 to 255 Characters
Value Default = Null String
Feature L115158.1, L114909.1
An example of the NEM Commissioning Wizard screen for entering the

antennaLabel values is provided in Figure 37.
.
Figure 37: NEM Commissioning Screen for Entering Antenna Labels
Note: A maximum of 8 antenna ports is supported in LA5.0 but it’s for TDD
configuration.(TDD support RRH with 8 Tx/Rx Ports)
The antennaPortLabel parameter is an optional parameter. If a value is entered,
it must be unique (not repeated for another AntennaPort object on this eNB). No
alarm is generated if a value is not entered for this parameter but we do prohibit
the same entries for 1 single RIT. antennaPortLabel attaches an identification
label to the antenna port object instance.
Page 106/308
AntennaPort::antennaPortLabel
Parameter antennaPortLabel
Range & Unit String
0 to 255 Characters
Value Default = Null String
Feature L115158.1, L114909.1
Rule: antennaPortLabel
Usage is optional, if nothing is entered, there is no alarm but we do prohibit the

same entries for 1 single RIT
The NEM screen that is used for entering values for the antennaPortLabel
parameter is shown in Figure 38.
.
Figure 38: NEM Commissioning Screen for Entering Antenna Port Label Values
Note: A maximum of 8 antenna ports is supported in LA5.0 but it’s for TDD
configuration.(TDD support RRH with 8 Tx/Rx Ports).
The antennaPortInternalLoss Old read only MIM parameter L115158.1,
L114909.1 hard coded parameter reports the internal loss on the Tx path from
the transmitter to the antenna port. The internal loss depends on the internal
feeder loss and the loss of the internal modules. Changes in the value of this
parameter do not increment the equipment LastChangeCounter.
Page 107/308
horizontalBeamwidth specifies the angular distance between the 3db

attenuation point of the FR lobe transmitted from the antenna, measured in the
plane that is horizontal to the ground.
Note: A value of 0 indicates no beamwidth has been provided, a value of 360 is

used when an Omni antenna or Distributed Antenna System (DAS) is in use.
AntennaPort::horizontalBeamwidth
Parameter horizontalBeamwidth
Range & Unit Float, deg
0..360 step = 0, 1
Class/Source B--Cell(s)-of-Modem / customer_settable
Value 0
Feature L115221
verticalBeamwidth specifies the angular distance between the 3db attenuation

point of the RF radiation pattern transmitted from the antenna, measured in the
plane perpendicular to the ground.
Note: A value of 359 indicates Omni directional cell and 0 no beamwidth has
been provided.
AntennaPort::verticalBeamwidth
Parameter verticalBeamwidth
0..180 step = 0, 1
Value 0
Feature L115221
AntennaPort::Azimuth provides the orientation of the cell in degrees based on

a "True North" system, meaning:
North = 0 degrees
East = 90 degrees
South = 180 degrees

West = 270 degrees.
Page 108/308
AntennaPort::Azimuth
Parameter Azimuth
0..360 Step = 0, 001
Class/Source B--Cell(s)-of-Modem / customer_init
Value OD
Feature L103896
5.2.6 DOWNLINK PARAMETERS

antennaPathDelayDL - parameter indicates total external Downlink propagation
delay (feeder DL delay plus diplexer/combiner) from eNodeB RF output to
antenna in units of nsec. Includes also a potential contribution of a tower mounted
amplifier TMA, if equipped. A value of 0 means that no feeder delay value is
available.
AntennaPort::antennaPathDelayDL
Parameter antennaPathDelayDL
Range & Unit Integer, nanoseconds
0..100000* Step = 1
Value Default = 0, See Engineering Recommendation
Feature L115158.1, L114909.1
Note: Path delay measurements have accuracy of 50nsns.

Note: The Highest value supported in LR13 is 75000. Inter working with
CellActivationService::isDasDelayEnabled which implements higher values
between 2100 and 75000.
If CellActivationService::isDasDelayEnabled = False, an critical alarm will be
raised if the cell’s antennaPathDelayDL and/or antennaPathDelayUL parameter
value is greater than 2100ns.
Assume fiber delay is 1.5 times Over The Air delay. (please refer to 4.4.2 for
diagram)
Note: If OTDOA feature is used (isGeoLocPhaseSyncAllowed =True) then these

parameters (AntennaPort::antennaPathDelayDL and
Page 109/308
AntennaPort::antennaPathDelayUL) must be accurate to +/-50ns (~10 meters),

meaning the configured value must be within 50ns of the actual value.
Options for getting the info to populate these in decreasing order of accuracy are
as follows. Better delay parameter accuracy will give better UE position accuracy.
1. use a time domain analyzer to directly measure the cable delay (requires
disconnecting the antenna cable from the RF head). Most accurate method.
2. measure length of the antenna cable in meters:
• cable_delay in ns = (cable_length_in_meters) * (propagation delay in
ns/m)
If velocity factor (VF) from specs of the specific cable in use are known then
propagation delay in ns/m = 1/[(velocity factor)*(speed of light)] = 10/(3*VF).
Therefore, cable_delay in ns = (cable_length_in_meters)*10/(3*VF)
If specs for specific cable are not known, use 5ns/m as rule-of-thumb propagation
delay. So cable_delay in ns = (cable_length_in_meters)*5
This parameter should include also a potential (delay) contribution of a tower

mounted amplifier TMA, if equipped. A value of 0 means that no feeder delay
value is available.
Engineering Recommendation: antennaPathDelayDL and Range(*)
If CellActivationService::isDasDelayEnabled= True,
Must be set like total external Downlink propagation delay
If total external Downlink propagation delay is beyond 75000 nanoseconds
Set antennaPathDelayDL to 75000
Increase LteCell::CellRadius by 1, 5*( Lcabling(km) -15km)
Note: Please refer to Volume 5 section 4.1.4.1.1 for more information related to
LteCell::CellRadius
Note: Please consider inter-working with cyclic shift index : to see [Vol. 4] section
4.2.5
The NEM Commissioning Screen for entering antennaPathDelayDL is illustrated
in Figure 39.
Page 110/308
Figure 39: NEM Commissioning Screen for Entering DL Antenna Path Delay
txUsed, is included to support transmit diversity configurations.

This parameter allows in the configuration the Tx usage on this antenna port
when it is set to true.
This flag indicates whether the antenna port is used for transmitting (txUsed =
true) or not used to transmit (txUsed = false).
AntennaPort::txUsed
Parameter txUsed
True/False
Value Default = True (to see engineering recommendation)
Feature L115158.1 L114909.1
Engineering Recommendation (setting for SIMO usage): AntennaPort::txUsed
In SIMO configuration, Second Tx paths is for spare usage, operator can

choose to use it or not. If this is not used we recommend setting
AntennaPort::txUsed of the secondary antenna port to “false”.
There is an accompanying parameter (rxUsed – see Section 5.2.7) for the uplink.
The values of both the txUsed and rxUsed parameters are set on the same NEM
Commissioning screen as shown in Figure 40.
Page 111/308
Figure 40: NEM Commissioning Screen for Entering TX and RX Used Parameter Values on the 8
Ports
antennaPathAttenuationDL - parameter advises the eNodeB of the total

external downlink RF loss (feeder plus Diplexer/Combiner) from cabinet antenna
connector to antenna, or to BTS port of TMA if present. This value does not
include the hard coded parameter antennaPortInternalLoss Old read only MIM
parameter L115158.1, L114909.1 contribution between TRDU RF port and
cabinet antenna connector. The value 0 means that no feeder loss estimate is
available.
AntennaPort::antennaPathAttenuationDL
Parameter antennaPathAttenuationDL
Range & Unit Integer, units of 0.1dB
0..40, step= 1, units of 0.1dB
Value Default = 0
Feature L115158.1, L114909.1
Restriction: antennaPathAttenuationDL parameter
Parameter antennaPathAttenuationDL is not currently used by the eNB. Its value

should be left at “0” so that it will have no effect if a future software load uses the
parameter value.
Note: There are two parameters in the Antenna Port Table to compensate for
path delay on each RF paths supported by the radio due to difference in the
antenna cables that connect the RRH antenna port and the antenna panel:
antennaPathAttenuationDL , antennaPathAttenuationUL.
Page 112/308
jumperLossDl specifies the RF loss in the downlink (transmit) direction for the
jumper cable between RFM and cabinet antenna connector.
AntennaPort::jumperLossDl
Parameter jumperLossDl
0..10, step= 0, 1 dB
Value Default = 0
Feature 159488
Inter-Release Delta: jumperLossDL Parameter
In previous releases the value of this parameter was ignored by the eNB, and a
fixed value of 0.3 dB was assumed. Beginning in release LR13.1, the value of
this parameter will be used by both TRDU and RRH to compensate for the
jumper losses between the RF Module and the cabinet antenna connector.
5.2.7 UPLINK PARAMETERS

antennaPathDelayUL - parameter indicates total external Uplink propagation
delay (feeder UL delay plus diplexer/combiner) from antenna to the eNodeB RF
input(RRH or TRDU) in units of nsec. Includes also a potential contribution of a
tower mounted amplifier TMA, if equipped. A value of 0 means that no feeder
delay value is available.
AntennaPort::antennaPathDelayUL
Parameter antennaPathDelayUL
Range & Unit Integer, nanoseconds
0..100000* Step = 1
Value Default = 0
Feature L115158.1, L114909.1
Note: Path delay measurements have accuracy of 50nsec.
Note: The Highest value supported in LA6.0.0 like inLA5.0 is 75000. Inter working
with CellActivationService::isDasDelayEnabled which implements higher
values between 2100 and 75000.
Page 113/308
If CellActivationService::isDasDelayEnabled = False, then an critical alarm will be

raised if the cell’s antennaPathDelayDL and/or antennaPathDelayUL parameter
value is greater than 2100ns.
Assume fiber delay is 1.5 times Over The Air delay. (Please refer to 4.4.2 for
diagram).
Note: If OTDOA feature is used (isGeoLocPhaseSyncAllowed =True) then these

parameters (AntennaPort::antennaPathDelayDL and
AntennaPort::antennaPathDelayUL) must be accurate to +/-50ns (~10 meters),
meaning the configured value must be within 50ns of the actual value.
Options for getting the info to populate these in decreasing order of accuracy are
as follows. Better delay parameter accuracy will give better UE position accuracy.
1. use a time domain analyzer to directly measure the cable delay (requires
disconnecting the antenna cable from the RF head). Most accurate method.
2. measure length of the antenna cable in meters cable_delay in ns =
(cable_length_in_meters)*(propagation delay in ns/m)
If velocity factor (VF) from specs of the specific cable in use are known then
propagation delay in ns/m = 1/[(velocity factor)*(speed of light)] = 10/(3*VF). So
cable_delay in ns = (cable_length_in_meters)*10/(3*VF)
If specs for specific cable are not known, use 5ns/m as rule-of-thumb propagation
delay. So cable_delay in ns = (cable_length_in_meters)*5
Engineering Recommendation: antennaPathDelayUL and Range(*)
If CellActivationService::isDasDelayEnabled =True,
Must be set like total external Uplink propagation delay
If total external Uplink propagation delay is beyond 75000 nanoseconds
Set antennaPathDelayUL to 75000
Increase LteCell::CellRadius by 1, 5*( Lcabling(km) -15km)
Note: Please refer to Volume 5 section 4.1.4.1.1 for more information related to
LteCell::CellRadius
Note: Please consider inter-working with cyclic shift index : to see [Vol. 4] section
4.2.5
The NEM Commissioning screen for entering the uplink antenna path delay
values is illustrated in Figure 41.
.
Page 114/308
Figure 41: NEM Commissioning Screen for Entering Uplink Antenna Path Delay Value
A parameter, rxUsed, is included to support receive diversity configurations. This

flag indicates whether the antenna port is used for receiving (rxUsed = true) or
not used to receive (rxUsed = false).
AntennaPort::rxUsed
Parameter rxUsed
True/False
Feature L115158.1, L114909.1
The value of the rxUsed parameter is entered using the NEM Commissioning
screen that is illustrated in Figure 40.
antennaPathAttenuationUL - parameter advises the eNodeB of the total

external uplink RF loss (feeder plus Diplexer/Combiner) from cabinet antenna
connector to antenna, or to BTS port of TMA if present. This value does not
include the hard coded parameter antennaPortInternalLossOld read only MIM
parameter L115158.1, L114909.1 contribution between TRDU RF port and
cabinet antenna connector. The value 0 means that no feeder loss estimate is
available.
This parameter is intended to cover the attenuation due to the RF cable length.
Page 115/308
AntennaPort::antennaPathAttenuationUL
Parameter antennaPathAttenuationUL
Range & Unit Integer, units of 0.1dB*
0..40, step= 1,
Value Default = 0 see Engineering Recommendation
Feature L115158.1, L114909.1
Rule: antennaPathAttenuationUL
*Note: The field will accept a value = 31 to represents 3.1 dB
Restriction: antennaPathAttenuationUL parameter
If the value of parameter ttlnaEquipped = False and there is no TMA/TMA

Subunit assigned to the antennaPort, then the value of this parameter is ignored.
If the value of parameter ttlnaEquipped = True and there is a TMA/TMA Subunit
assigned to the antennaPort, then the value of this parameter is taken into
account by the RF module as part of the computation of total gain/loss between
the antenna panel and the RF module.
Note: There are two parameters in the Antenna Port Table to compensate for
path delay on each RF paths supported by the radio due to difference in the
antenna cables that connect the RRH antenna port and the antenna panel:
antennaPathAttenuationDL , antennaPathAttenuationUL.
Engineering Recommendation: antennaPathAttenuationUL
We recommend that the value of this parameter be set to 10 (1dB) if a TMA is

present in the UL path.
Regarding Metro eNB use 0dB configuration.
jumperLossUl - parameter specifies the RF loss in the uplink (receive) direction

for the jumper cable between RFM and cabinet antenna connector.
Page 116/308
AntennaPort::jumperLossUl
Parameter jumperLossUl
0..10, step= 0, 1 dB
Value Default = 0
Feature 159488
ulAntennaGain reports the eNodeB-determined RF gain for each active uplink
(receive) path.
CellAntennaPort::ulAntennaGain
Parameter ulAntennaGain
Object ENBEquipment//Enb/LteCell/CellAntennaPort
-50..150, Step = 0.1
Value N.A.
Feature L115221
5.2.8 ANTENNA TEST PARAMETERS

Antenna test was added by LA2.0.2 Feature L108271. Antenna tests are run
periodically, and provide an alarm if the impedance match between the antenna
cable and the antenna is outside of a fixed limit. Voltage Standing Wave Ratio
(VSWR) thresholds are used to define the success or failure of these tests. The
VSWR is the voltage ratio of the maximum and the minimum voltage amplitudes
of the standing wave that is created between the incident and reflected power in
the transmission line connecting the RRH or TRDU to the antenna. Since the
VSWR is the ratio of two voltages, it is a unitless quantity.
The system allows two VSWR values to be entered:

• The value of the vswrWarningThreshold parameter provides a threshold
for a warning of degradation (a warning alarm) in the connection of the
antenna port to the antenna. The associated alarm string is expected to
be displayed as RFM TXn VSWR THRESH1, where n is the associated
transmit port number.
• The value of the vswrUrgentThreshold parameter provides a threshold to
indicate failure (an urgent alarm) of the connection of the antenna port to
Page 117/308
the antenna. The associated alarm string is expected to be displayed as

RFM TXn VSWR THRESH2, where n is the associated transmit port
number.
If either threshold is set to 0, then the associated alarm is disabled.

Note that the values of the VSWR thresholds are represented internally as shown
in the following two tables. However, the values are entered by the user on NEM
screens as VSWR ratios as shown in Figure 42 on page 119.
AntennaPort::vswrWarningThreshold
Parameter vswrWarningThreshold
Range & Unit Integer in units of 10*ratio (a VSWR of 1.9:1 would be entered
using the NEM as 1.9 and internally represented as “19”)
0 to 100, Step = 1
Value Default = 19 (ratio of 1.9:1)
Feature L108271, L78706
AntennaPort::vswrUrgentThreshold
Parameter vswrUrgentThreshold
Range & Unit Integer in units of 10*ratio (a VSWR of 3.0:1 would be entered
as 3.0 using the NEM and internally represented as “30”)
0 to 100, Step = 1
Value Default = 30 (ratio of 3.0:1)
Feature L108271, L78706
Engineering Recommendation: vswrWarningThreshold and

vswrUrgentThreshold
The user must insure that a higher(or equal) value is entered for the
vswrUrgentThreshold parameter than for the vswrWarningThreshold
parameter in order for the alarms to have the proper relationship to each other.
Entering a value of 0 for both thresholds disables the VSWR test.
Although values of 0 to 10.0 can be entered using the NEM, only values of 0
and 1.3 to 10.0 (VSWR range of 1.3:1 to 10:1) will actually be used by the
system. If a value of 0.1 to 1.2 is entered, it will be rejected by the system (by
eNB OAM).The possibility of entering values from 10.1 to 25.5 has been
eliminated by the change in the upper limit of the range. Tbc
Page 118/308
The NEM screen that is used for entering VSWR parameters in release LA5.0
TBC is reproduced in Figure 42. Note that the VSWR values are entered directly
on the screen and converted by the system to the internal representation
described above (in units of 10 times the VSWR).
Figure 42 : NEM Commissioning Screen for Entering VSWR Parameters
5.2.9 RET AND TMA PARAMETERS
5.2.9.1 RET AND TMA IDENTIFICATION PARAMETERS
To get the value of RET Log.Number retLogicalNumber old MIM parameter, 0

to 6, Step = 1 L106223of the RET that is associated with this antenna port, we
used the RET Log.Number parameter. The value of this parameter is assigned
by the user and it should be based on the logical number assigned to the RET
that support this antenna port.
The number assigned by the user must be already assigned to one of the RET
units that supports the eNodeB. See section 4.4.1 for more explanation
regarding AISG feature and configuration.
retSubunitNumber - parameter associates the containing instance of RetSubUnit

with the related SNMP retSubUnitTable entry. It's the one having a
retActuatorNumber set to the same value as defined by this attribute and having
the same retAldRitNumber as defined for the parent object RET.
Page 119/308
RetSubunit::retSubunitNumber
Parameter retSubunitNumber
Object ENBEquipment/Ret/RetSubunit
0 .. 4 step = 1
Value Default=1
Feature L115221
Figure 43 : NEM Commissioning Screen for Entering RET Log.Number Parameters
Figure 44 : NEM Commissioning Screen for Entering retSubunitNumber Parameters
Page 120/308
Use case:
antennaLabel antennaPortLabel retLogicalNumber retActuatorNumber

RRH1 Port1 1 1
RRH1 Port2 1 1
RRH2 Port1 2 1
RRH2 Port2 2 1
RRH3 Port1 3 1
RRH3 Port2 3 1
Table 17: Example of setting for eNodeB with 3 RRH, 1RET per RRH
The NEM reads the identified RRHs to the installer, and the installer then
specifies a location for the RFM, and a sector (antenna) for the RFM. The installer
then assigns the names to the antennaLabel and the antennaPortLabel
(arbitrary names).
The antennaLabel parameter just provides a user friendly name for the ports on
the physical antenna, and the antennaPortLabel provides a user friendly name
for the ports on the RFM
RET Log.Number is a parameter that can be used by the technician to assign a

logical number (0 .. 6) to each of the RET units that are managed by the eNodeB.
The number assigned to each RET should be unique (i.e. not used for another
RET). This parameter is only used like a reference only. The same apply to the
TMA logical Number parameter.
To Assign a RET to an antenna port, the NEM provide to the installer a list of RET
Unique Identifiers numbers.
tmaSubunitNumber - parameter associates the containing instance of

TmaSubUnit with the related SNMP tmaSubUnitTable entry. It's the one having a
tmaSubunitNumber set to the same value as defined by this attribute and having
the same tmaAldRitNumber as defined for the parent object TMA.
TmaSubunit::tmaSubunitNumber
Parameter tmaSubunitNumber
Object ENBEquipment/Tma/TmaSubunit
1 .. 4 step = 1
Value Default = 1
Feature L115221
retAldUniqueName is a text string comprised of the AISG-assigned RET vendor

code (2 characters) appended with the unit's serial number (max 17 characters),
Page 121/308
and serves as a unique identifier for the unit. This is matched with the unique
identity value read from the RET.
Ret::retAldUniqueName
Parameter retAldUniqueName
Object ENBEquipment/Ret
Range & Unit String
0 to 20 Characters

Value OD
Feature L114909.1
retAssociatedEnodebFriendlyName is usually used when the eNodeB serves

as host of a RET associated with another eNodeB or non-LTE BTS. This text
string describes that other BTS.
Ret::retAssociatedEnodebFriendlyName
Parameter retAssociatedEnodebFriendlyName
Range & Unit String
0 to 255 Characters

Value OD
Feature L114909.1
retFriendlyName is a text string provided by the operator to describe the location

or use of the RET.
Ret::retFriendlyName
Parameter retFriendlyName
Range & Unit String
0 to 255 Characters

Value OD
Feature L114909.1
labelAssociatedENB This parameter is set by OAM when the unit was first
created and a value is read from the unit or by the end user at a later time. The
parameter registers the identity of another eNodeB that shares the antenna tower
with the eNodeB that manages this RETSubunit
Page 122/308
RetSubunit:: labelAssociatedENB
Parameter labelAssociatedENB
Range & Unit String
0 to 255 Characters
Class/Source C--Immediate-propagation / customer_init

Value OD
Feature L114909.3
labelSectorId This parameter is set by OAM at creation or it can be set by the

end user at a later time. The parameter registers the identity of the sector of the
eNodeB that shares the antenna panel with the eNodeB that manages this
subunit if such data was previously set on this unit by the antenna panel installer.
RetSubunit:: labelSectorId
Parameter labelSectorId
Range & Unit String
0 to 255 Characters

Value OD
Feature L114909.3
retSubunitAssociatedeNodeB This parameter is set by the operator during the

eNodeB commissioning or it can be set later on by the operator after the eNodeB
connects with the OMC. The parameter identifies the eNodeB that shares the
antenna panel with the eNodeB that manages this Subunit or the name of the
Managing eNodeB. When a RET supports more than one Subunit, then an
individual Subunit may be associated with a eNodeB other than the local eNodeB.
The associated eNodeB must be one which shares the antenna panel that
contains the multi-antennas RET.
RetSubunit:: retSubunitAssociatedeNodeB
Parameter retSubunitAssociatedeNodeB
Range & Unit String
0 to 255 Characters

Value OD
Feature L114909.3
Page 123/308
tmaLogiacalNumber is a parameters that can be used by the technician to

assign a logical number (0 .. 6) to each of the TMA units that are managed by the
eNodeB. The number assigned to each TMA should be unique (i.e. not used on
another TMA). This parameter is only used like a reference only. The same apply
to the RET logical Number parameter.
To Assign a TMA to an antenna port, the NEM provide to the installer a list of
TMA Unique Identifiers numbers.
See section 4.4.1 for more explanation regarding AISG feature and configuration.
To specify the TMA subunit Number that supports thisTmaSubunit (previous

antenna port), we used to the parameter tmaSubunitNumber.
The number assigned by the user must be one of the Subunit numbers reported
by the TMA when the TMA was discovered. The subunit number is unique in the
ATP entries.
See section 4.4.1 for more explanation regarding AISG feature and configuration.
Figure 45 : NEM Commissioning Screen for TMA Log.Number Parameters
Use case:
antennaLabel antennaPortLabel tmaLogicalNumber tmaSubunitNumber

RRH1 Port1 1 1
RRH1 Port2 1 2
RRH2 Port1 2 1
RRH2 Port2 2 2
RRH3 Port1 3 1
RRH3 Port2 3 2
Table 18: Example of setting for eNodeB with 3 RRH, 1 dual TMA per RRH
Page 124/308
tmaAldUniqueName is a text string comprised of the AISG-assigned TMA

vendor code appended with the unit's serial number, and serves as a unique
identifier for the unit. This is matched with the unique identity value read from the
TMA.
Tma::tmaAldUniqueName
Parameter tmaAldUniqueName
Object ENBEquipment/Tma
Range & Unit String
0 to 20 Characters

Value OD
Feature L115221, L114909.1
tmaAssociatedEnodebFriendlyName is usually used when the eNodeB serves as

host of a TMA associated with another eNodeB or non-LTE BTS. This text string
describes that other BTS.
Tma::tmaAssociatedEnodebFriendlyName
Parameter tmaAssociatedEnodebFriendlyName
Range & Unit String
0 to 255 Characters

Value OD
Feature L115221, L114909.1
tmaAssociatedRfmFriendlyName is an operator-provided text string identifying

the RF unit served by this TMA physical unit. This RF unit may be part of this
eNodeB or another eNodeB or non-LTE BTS.
Page 125/308
Tma::tmaAssociatedRfmFriendlyName
Parameter tmaAssociatedRfmFriendlyName
Range & Unit String
0 to 255 Characters

Value OD
Feature L115221, L114909.1
tmaFriendlyName - parameter is a text string provided by the operator to

describe the location or use of the TMA.
Tma::tmaFriendlyName
Parameter tmaFriendlyName
Range & Unit String
0 to 255 Characters

Value OD
Feature L115221, L114909.1
5.2.9.2 RET AND TMA MAIN CONFIGURATION

PARAMETERS
ttlnaEquipped, if set to "True", signals to the system that the antenna port has an
external TTLNA attached that is not connected to an AISG bus or that there is a
TMA which is connected to an AISG bus that is controlled by another eNodeB.
AntennaPort::ttlnaEquipped
Parameter ttlnaEquipped
True/False
Feature 159488
Note: This parameter can now be set to Unset when it is determined by the other
controller for a shared RF unit, LR13.1 features 128301, 128430)
The gain of the antenna that is associated with this antenna port is also expected
to be needed to support calculations that are performed within the system. This
gain is entered using the ttlnaAntennaGain parameter. The ttlnaAntennaGain
Page 126/308
parameter is used in LA6.0 like in LA5.0, and it is available on the NEM screens.
(To see Figure ) .
ttlnaAntennaGain specifies the gain of a TTLNA in this port. The RFM is
instructed to adjust its RF gain by this value.
AntennaPort::ttlnaAntennaGain
Parameter ttlnaAntennaGain
Range & Unit Integer in units of 0.1 dB (16.5 dB would be entered as “165”)
90 .. 350, Step = 1
Value Default = 90
Feature L115158.1, L114909.1
Note: This parameter indicates to the eNodeB the gain of the antenna that is
attached to the antenna port, to enter the gain of a TTLNA which does not resides
on the AISG bus.
Usage of this attribute needs appropriate setting of the 'aldScanEnable' flag.
Rule: ttlnaAntennaGain
If "ttlnaEquipped" is "True",
Then
this parameter must be set.
Else
this parameter must be unset.
If the value of parameter ttlnaEquipped is "False", then the value of parameter

ttlnaAntennaGain parameter is not used.
ALD can be managed by another eNodeB. This feature will include support for
eNodeBs that are configured to use ALD units that are managed by other
eNodeB in the network. These eNodeBs will be configured using an existing MIB
attribute in the antenna port table (ttlnaAntennaGain) and the new attribute that
was added to the eNodeB MO (aldScanEnable). To support TTLNAs that are
managed by other entity, the eNodeB have to use a parameter to configure the
radio to use TTLNA (i.e. to adjust its Rx Gain to compensate for the presence of
the TTLNAs); this would not be the same as when the eNodeB OAM manages
the TTLNA. Since these TTLNAs are managed by other entity, the LTE eNodeB
OAM will not receive any alarms from these units. If the TTLNA failed, the radio
will continue to operate as if the TTLNA is still providing the extra RF gain in the
Rx path.
TTLNA = tower mounted amplifier that is not controlled by RRH, and RRH does
not receive notification or take recovery action if it fails
With TTLNA, the controller cannot read the gain from the unit, so it uses the input
for the ttlnaAntennaGain parameter and reduces the gain of the receive path by
this much.
Page 127/308
TMA = tower mounted amplifier that is controlled by RRH, and RRH receives
notification of TMA failure and takes recovery action (increases receive path gain
to compensate for loss of TMA)
With TMA, the controller can normally read the gain from the unit, and it ignores
anything input for ttlnaAntennaGain parameter for the associated antenna ports
The eNodeB OAM support a configuration where the TTLNAs in the Rx paths of
each of the RRH/TRDU are managed by other entity, or configuration where the
TMAs in the Rx Path of each RRH/TRDU that are using the AISG bus managed
by one of the TRDU/RRHs in the eNodeB. The eNodeB OAM will recognize the
following configurations:
TTLNA or TMA
ttlnaAntennaGain aldScanEnable RRH behavior
or None
Normal (no Rx Gain
0 No None
Adjustment)
Adjust RRH Rx gain by fixed
No (because
antennaGain value (Risk :
amplifier is not
Non Zero (i.e. 12) TTLNA TTLNA failure not detected; so
controlled by the
RRH cannot adjust its gain for
RRH)
the loss of the TTLNA gain)
Adjust RRH Rx gain by TMA
0 Yes TMA reported gain (AntennaGain
parameter is inhibited)
Table 19: Usage of parameter aldScanEnable
Note: Since these TTLNAs are managed by other entity, failure of the TTLNA
cannot be detected and the RRH/TRDU will continue to work with less Rx gain in
that path.
Note: In the case aldScanEnable=No and TTLNA implemented, the value of
ttlnaAntennaGain is not hardcoded, but most of the TTLNAs that are used with
the ALU eNodeBs and NBs have a fixed gain of 12 dB. The attribute value must
be set by the user during the eNodeB commissioning since we cannot read the
value from the TTLNA.
Note: In the case aldScanEnable =Yes and TMA configured in front of RRH, the
MIM parameter ttlnaAntennaGain is not used (and not implemented) because
gain is reported via the AISG scan which is operational. In this case the default
value is recommended.
tmaSelfTest causes the TMA physical unit to perform a self-test.
Page 128/308
Tma::tmaSelfTest
Parameter tmaSelfTest
True, False
Feature L115221
tmaSoftwareFilename specifies the filename for the application software to be

downloaded to the TMA.
Tma::tmaSoftwareFilename
Parameter tmaSoftwareFilename
Range & Unit String
0 to 255 Characters

Value OD
Feature L115221
bypassMode reports the by-pass status of the TMA sub-unit.

The value True indicates that the TMA sub-unit is in by-pass mode owing to a
fault condition. It is not providing gain to the receive RF signal.
The value False indicates that the sub-unit is operating normally, providing gain to
the receive RF signal.
TmaSubunit::bypassMode
Parameter bypassMode
Object ENBEquipment/Tma/TmaSubunit
True, False
Feature L115221
mechanicalTilt is the operator-provided value for the antenna panel fixed

mechanical tilt set at antenna installation time. 0 is horizontal, positive values
indicate tilt down from horizontal.
Page 129/308
Ret::mechanicalTilt
Parameter mechanicalTilt
-90 .. 90, Step = 0, 1
Value Default = 0, 1
Feature L114909.1
retSelfTest causes the RET physical unit to perform a self-test.
Ret::retSelfTest
Parameter retSelfTest
True, False
Feature L115221
retSoftwareFilename specifies the target filename for the application software to

be downloaded to the RET. The string shall also include the CD-ROM drive unit
and/or a directory where the file resides.
Ret::retSoftwareFilename
Parameter retSoftwareFilename
Range & Unit String
0 to 255 Characters

Value OD
Feature L115221
antennaBandClass captures the band class of the antenna supported by the

RET Subunit. The value will be determined either by the technician during the
eNodeB commissioning or during the eNodeB auto-configuration.
Page 130/308
RetSubunit::antennaBandClass
Parameter antennaBandClass
Range & Unit String
0 to 20 Characters

Value OD
Feature L115221, L114909.3
antennaCalibrate causes the RET subunit to perform an antenna calibration

procedure, swinging the antenna through its full tilt range.
RetSubunit::antennaCalibrate
Parameter antennaCalibrate
True, False
Value Default=False
Feature L115221
antennaConfigFile specifies the path and filename to an Antenna

Configuration File to be passed down to the RET. Each RET subunit may
support a different antenna panel and so this is specified on a per-subunit basis.
The name might also include a CD-ROM drive and/or a directory where the
file is located.
RetSubunit::antennaConfigFile
Parameter antennaConfigFile
Range & Unit String
0 to 255 Characters

Value OD
Feature L115221
antennaElectricalTilt - parameter specifies the electrical tilt of the actuator

(motor) for this subunit.
Page 131/308
RetSubunit::antennaElectricalTilt
Parameter antennaElectricalTilt
-90 .. 90, step=0, 1
Value OD
Feature L115221, L114909.3
Note: The antennaTilt must be greater than or equal to minTilt for this subunit,
and less than or equal to maxTilt for this subunit.
maxElectricalTilt - parameter reports the maximum supported electrical tilt of the

actuator (motor) for this subunit, as read from the unit itself.
RetSubunit::maxElectricalTilt
Parameter maxElectricalTilt
-90 .. 90, step=0, 1
Value N.A.
Feature L115221, L114909.3
minElectricalTilt - parameter reports the minimum supported electrical tilt of the

actuator (motor) for this subunit, as read from the unit itself.
RetSubunit::minElectricalTilt
Parameter minElectricalTilt
-90 .. 90, step=0, 1
Value N.A.
Feature L115221, L114909.3
Page 132/308
mechanicalTilt - parameter is set by the operator at commissioning or when the

antenna panel was installed. The parameter displays value for the fixed
mechanical antenna panel that was set at antenna installation time. 0 is
horizontal, positive values indicate tilt down from horizontal.
RetSubunit::mechanicalTilt
Parameter mechanicalTilt
-90 .. 90, step=0, 1
Value OD
Feature L115221, L114909.3
retSubunitId identifies the specific RET subunit associated with this antenna port.
The parameter should be unset when no RET serves the antenna port.
AntennaPort::retSubunitId
Parameter retSubunitId
Range & Unit
ServiceLink

Value OD
Feature L114909.3
tmaSubunitId identifies the specific TMA subunit associated with this antenna
port. The parameter should be unset when no TMA serves the antenna port.
AntennaPort::tmaSubunitId
Parameter tmaSubunitId
Range & Unit
ServiceLink

Value OD
Feature L114909.3
5.3 SECTOR RELATED PARAMETERS
Page 133/308
5.3.1 LTECELL SECTOR NUMBER PARAMETER

The sectorNumber parameter defines the logical number of the sector in
accordance with a geographical area of radio frequency (RF) coverage,
As indicated in Section 5.2.1, an RFM and its antenna ports are assigned to a
sector by use of the NEM.
Typically a base station (eNodeB) supports multiple LTECells, and each LTECell
is associated with a geographical sector. Two arrangements are currently
supported:
• Omni – effectively a one sector base station that supports one LTE cell
and emits RF in an omnidirectional pattern around the antenna
• Three sectors – the area around the base station is divided into three 120
degree sectors. In this case, three LTE Cells would be supported, one per
sector.
These typical arrangements are illustrated in Figure 46. Example values for the
sectorNumber parameter are shown for each of the arrangements.
1 1 3
Omni Three Sector
Figure 46: Illustration of Typical Sector Arrangements for an eNodeB
In Figure 46, the circular area represents the area of RF coverage of the base
station. The area that contains the number represents the sector (and the value of
the sectorNumber parameter and this area directly corresponds to the
geographical area of coverage of an LteCell.
The sectorNumber parameter defines the logical number of the sector. For
historical reasons, sectors are often referred to by the Greek letters α, β, and γ. If
this notation is used, then the correspondence is
Sector 1 <-> Sector α
Sector 2 <-> Sector β
Sector 3 <-> Sector γ
Each instance of the LteCell object is provided with a sectorNumber parameter

that is used to indicate the logical sector number that supports the instance of the
LteCell object. sectorNumber is a Read Only parameter.
Page 134/308
LteCell::sectorNumber
Parameter sectorNumber
1…3, Step = 1
Value O.D.
Feature L115808
Algorithm determine sectorNumber value based on

LteCell::cellHorizontalBeamwidth value, and LteCell::cellAzimuth value:
6 1
sectorNumber 2
1
sectorNumber 1
2
sectorNumber 1 sectorNumber 2 3
5 2 4
5
sectorNumber 3
sectorNumber 1 6
4 3
Figure 47: sectorNumber value with 6 sectors (2 modems)

Note: In the diagram above, cellAzimuth value (30 deg) is for example.
5.4 ENB PARAMETERS

New parameter has been added so operator is able to classify the type of the
eNodeB (existing and forecasted). This parameter permits to the operator to sort
eNodeB equipment snapshots or reports per type: Macro (MACRO), eNB Metro
Cell Outdoor (MCO), Metro Cell Indoor (MCI), LTE Enterprise Cell (EC), Home
eFemto (HeNB) or Metro Radio Outdoor (MRO).
Page 135/308
ENBEquipment::equipmentKind
Parameter equipmentKind
Object ENBEquipment
Range & Unit
Enumerate
MACRO(0), MCO(1), MCI(2), EC(3), HeNB(4), MRO(5)
Class/Source C / system_restricted
Value Macro (0)
Feature
The eNodeB has an auto reset timer that is started when the eNodeB does not
have communication with a management system. If the timer expires, then the
eNodeB reboots. The duration of the timer is determined by the value of the
autoResetTimer parameter. By performing an reboot of the eNodeB, it may be
possible to restore communication with the OMC and, thus, avoid a visit to the site
to reboot the eNodeB.
autoResetTimer : time lapse (in minutes) the eNodeB waits before self reset if
not connected to any external interface (S1, EMS, X2, …)
Enb::autoResetTimer
Parameter autoResetTimer
Range & Unit
Integers
20..1440 step = 1 minutes
Class/Source C--New-set-ups / system_restricted

Value 60
Feature
The length of the fiber that connects the Cpri to the BBU is specified by the
maxTransportFiberDelayLengthCategory parameter.
This parameter provides a predefined maximum value for supported fiber delay
even before accurate dynamic delay measurement result is available after
multiple cell setup's.
maxTransportFiberDelayLengthCategory represents a category for the length
of fiber between the base unit and the radio unit plus the length of the antenna
cable from the radio unit to the antenna.
For each cell of the eNodeB, Fiber length = (1-way fiber length between base
unit and radio unit) + (1-way antenna path delay)*(1km / 5 us) must be in the
range specified by the transport fiber delay length category.
The values are:
Page 136/308
- tenKm: fiber length = 0..10 km

- fifteenKm: fiber length = 5..15 km.
ENBEquipment::maxTransportFiberDelayLengthCategory
Parameter maxTransportFiberDelayLengthCategory
Object ENBEquipment
Range & Unit Enumerate in km
tenKm (1), fifteenKm(2)
Class/Source B--Modems+Cells-of-NE / customer_settable

Value Default: tenKm
Feature L100622, L114909.1, L115158.1
The NEM screen that is used for entering

maxTransportFiberDelayLengthCategory parameters is reproduced in Figure
48. Note that the maxTransportFiberDelayLengthCategory values are entered
directly on the screen and converted by the system
fifteenKm
Figure 48 : NEM Commissioning Screen for Entering

maxTransportFiberDelayLengthCategory Parameters
Rule: maxTransportFiberDelayLengthCategory with bCEM
bCEM requires maxTransportFiberDelayLengthCategory to be set correctly.

This parameter is per eNB. There are two ranges below that can be used:
"tenKm" 0 - 10km (This supports RTT up to 170000ns, which includes modem
Page 137/308
delay)
"fifteenKm" 5 - 15km (This supports RTT up to 200000ns, which includes
modem delay)
With bCEM, all cells on the same eNB need to use fiber delays in the same
range, and the range has to be specified in the eNB configuration parameter
maxTransportFiberDelayLengthCategory. Fiber delay is the total 1-way of
CPRI fiber delay and DAS fiber delay configured in the antennaPathDelayUL
and antennaPathDelayDL parameters.
For example with DAS, 15km fiber corresponds to antennaPathDelayUL =

antennaPathDelayDL = 75000ns.
NOTE: There are system guard bands around the
maxTransportFiberDelayLengthCategory ranges that will allow exceptions to
the range rules. Cells must be designed in one of the defined ranges; cells
outside the ranges will adversely affect the effectiveness of the guard bands.
The guard bands are designed to allow variance of eNB internal delay due to
hardware, band and bandwidth. When all cells are within the selected range,
predictable eNB maintenance and optimal UE service can be achieved.
When maxTransportFiberDelayLengthCategory is tenKm, eNB can handle

delay up to 1700000ns. But delay of the eNB HW varies with hardware, band
and bandwidth resulting on it being higher or lower. If total delay is higher than
170000, the cell will be alarmed (Delay Compensation Failure) and will not be
accessible.
DAS systems that require more that 15km can be achieved by adjusting the size
of the cell radius (Refer to LPUG instructions for PRACH apparent Cell Radius).
This configuration can provide predictable eNB maintenance and optimal UE
service as long prudence is used in the DAS design to not exceed the 200000nS
limit under any circumstances (ex. Change of hardware).
Rules associated with maxTransportFiberDelayLengthCategory setting
(applicable to eNB with bCEM):
Set the maxTransportFiberDelayLengthCategory to match the longest cell

delay of all cells on the eNB
All the cells of the eNB have delay values in the selected range.
Example: If the range is “fifteenKm” and one cell has delay less than 5km, the
way to fix this is to insert a longer fiber on the short cell so that it's at least 5km.
Support up to 15 km (combination of CPRI fiber delay and DAS fiber delay)
See Table 12: Delay Compensation Capability Summary with DAS.

For maxTransportFiberDelayLengthCategory = tenKm, all fibers must be in
the range 0-10 km. For a system with eCEM (prior to upgrade) all cells must
have NEM RTT <= 170000ns.
For maxTransportFiberDelayLengthCategory = fifteenKm, all cells of the eNB
must be in the range 5-15 km (use when at least one fiber lengths is above
10km). For a system with eCEM (prior to upgrade) all cells must have NEM
Page 138/308
RTT between 100000ns and 200000ns.

If the spread of RTT values is too large, the way to fix this is to insert a longer
fiber on cell with delay <100000ns so that it's at least 100000ns prior to
upgrading to bCEM.
Restriction: maxTransportFiberDelayLengthCategory combination

The following combination is not allowed:
expectedModemType = bCEM
isFiberDelayAllowed = False
isDasDelayEnabled = False
maxTransportFiberDelayLengthCategory = fifteenKm
5.5 SELF-COMISSIONING PARAMETERS

provisionedEnbIdentifier - The parameter is used to identify the eNB during the
self commissioning phase. If this parameter is set, all the other OAMInterface
parameters, used for identifying the eNB, are ignored. The value of the parameter
is compared to the identifiers discovered from the eNB (ex: eNB serial number). If
one of them matches, the eNB will be self-commissioned.
This parameter can be unset.
OAMInterface::provisionedEnbIdentifier
Parameter provisionedEnbIdentifier
Object OAMInterface
Range & Unit
String
0 to 255 characters
Class/Source B--Modems+Cells-of-NE / customer_init

Value Default: N.A.
Feature L115970
5.5.1 L115970 ENB SELF COMMISSIONING

IMPROVEMENTS
The purpose of this feature is to further improve the eNB self configuration
capability. The major improvement in LR13 is that it is now possible to achieve full
plug-n-play, with no on-site commissioning of a newly installed eNB with IPsec
Page 139/308
enabled for the OAM interface and without having to pre-provision the eNB OAM
IP address or Security Gateway (SeGW) information.
With L115970 Self Commissioning Improvements, there is no need to pre-
provision the OAM IP address in order to identify the eNB during initial OAM link
establishment. This feature provides a new capability to use eNB serial number to
identify an eNB.
In addition, feature L115970 allows the operator to re-assign an eNB to a different
managing EMS without service impact to the eNB and without requiring the eNB
configuration to be pre-provisioned on the new Managing EMS.
This feature helps to speed up the OAM link establishment between eNB and
EMS because the eNB establishes the connection as soon as it is able rather
than waiting for EMS to periodically poll the eNB to set up connection. To do so,
the following MIB parameters are added to support L115970 (parameter can be
unset):
emsFqdn - configurable-factory parameter
This parameter specifies the fully qualified domain name (FQDN) of EMS to use
during OAM Link Establishment. The EMS FQDN is used during eNB automatic
Plug-n-Play procedures to obtain EMS IP addresses when operator uses the DNS
option.
OamTransportConf::emsFqdn
Parameter emsFqdn
Object ENBEquipment/Enb/EnbTransportConf/OamTransportConf
Range & Unit String
1..64
Class/Source C / system_reserved
Value OD
Feature L115970
New MIM Object is added: ProvisionedEmsAddressData

A child of OamTransportConf. This object holds Candidate EMS IP address
information provisioned by the operator. Up to 10 Candidate EMS IP addresses
may be provisioned. eNB contacts these EMS IP addresses to establish the OAM
connection when no Managing EMS is registered in the eNB. Note that a mix of
Ipv4 and Ipv6 addresses is not supported. All 10 EMS IP addresses are either
Ipv4 or Ipv6.
ProvisionedEmsAddressData.emsIpv4Address
This parameter specifies an EMS IPv4 address provisioned by the operator. Up to
10 EMS IPv4 addresses may be provisioned by the operator. eNB contacts these
EMS IP addresses to establish the OAM connection. This parameter is only used
when IPv4 is used for the OAM interface and no Managing EMS is registered in
the eNB.
Page 140/308
ProvisionedEmsAddressData:: emsIpv4Address
Parameter emsIpv4Address
ENBEquipment/Enb/EnbTransportConf/OamTransportConf
Object
/ ProvisionedEmsAddressData
Range & Unit IP4Address
Class/Source C / customer_init
Value -
Feature L115970
ProvisionedEmsAddressData.emsIpv6Address
This parameter specifies an EMS IPv6 address provisioned by the operator. Up to
10 EMS IPv6 addresses may be provisioned by the operator. eNB contacts these
EMS IP addresses to establish the OAM connection. This parameter is only used
when IPv6 is used for the OAM interface and no Managing EMS is registered in
the eNB.
ProvisionedEmsAddressData:: emsIpv6Address
Parameter emsIpv6Address
Object
Range & Unit IP6Address
Value -
Feature L115970
ProvisionedEmsAddressData.emsOamLinkInitPort
This parameter specifies the port on the EMS where eNB sends "Hello" message
during OAM Link Establishment.
ProvisionedEmsAddressData:: emsOamLinkInitPort
Parameter emsOamLinkInitPort
Object
1..65535
Value OD
Feature L115970
Page 141/308
6 AIR INTERFACE CLOCK SYNCHRONIZATION

There are multiple mechanisms for delivering synchronization, and these are
discussed below. Loss of synchronization causes revenue loss and maintenance
cost for when the eNB is forced into holdover, the service can only be maintained
for a finite period before the internal oscillator can no longer be guaranteed to
maintain the eNB frequency in specification.
In order to deliver a highly accurate reference clock driving the air interface the
following synchronization methods can be used:
• Free-running internal-oscillator. (for holdover during failures)
• GPS synchronization.
• SyncE (externally-synchronized).
• 1588 PTP (externally synchronized).

• External clock (externally-synchronized).
In LR13.1, only the first 4 synchronization methods are supported.
The backhaul transport network is not used with GPS synchronization. The eNB
has a dedicated GPS functionality allowing it to use the received satellite signal as
a reference clock for both frequency and phase.
The transport backhaul network is used to support Synchronous Ethernet and

IEEE1588v2 precision timing packet synchronization technologies. For more
information about Synchronous Ethernet and 1588 synchronization, see the
Transport Engineering Guide (TEG).
The operator can configure the list of synchronization methods ranked by

preference order (from highest to lowest) through parameter
clockSyncSourcePriorityList.
Page 142/308
ClockSync::clockSyncSourcePriorityList
Parameter clockSyncSourcePriorityList
Object ENBEquipment/Enb/ClockSync
Range & Unit

List of 2 to 6 values enumerated from the set
{free-running-internal-oscillator,
gps-synchronized-gps,
externally-synchronized-mode-1-synce,
externally-synchronized-mode-2-ptp1588,
externally-synchronized-mode-3-ext-clock,
externally-synchronized-mode-4-satellite,
clock-master-bs,
externally-synchronised-mode-5-1PPSAndTOD,
externally-synchronised-mode-6-synceAndptp1588}
O.D. (ALU Default: gps-synchronized-gps, free-running-

Value
internal-oscillator)
Feature L92073, L114546
Restriction: clockSyncSourcePriorityList parameter
In Release LR13, only the following values are supported for the
clockSyncSourcePriorityList parameter:
free-running-internal-oscillator
gps-synchronized-gps
externally-synchronized-mode-1-synce
externally-synchronized-mode-2-ptp1588
Rule: Parameter clockSyncSourcePriorityList
The last entry in the list must be “free-running-internal-oscillator”.
Parameters gpsClockEnable, ptpClientEnable and syncEClockEnable enable

the GPS, 1588 PTP and syncE clock sources, respectively. Note that these
parameters do NOT define the corresponding clock source (i.e. GPS, 1588 PTP
and syncE as the primary clock source), but only as a valid clock source.
The eNB configures all the possible enabled sources to be active. Upon failure of
one reference, the next reference to be used is initialized already so that the
switch to the new reference occurs immediately.
Page 143/308
ClockSync::gpsClockEnable
Parameter gpsClockEnable

True/False
Class/Source A--full-NE-Reset / customer_settable
Value Default: True

Feature L97084.1
ClockSync::ptpClientEnable
Parameter ptpClientEnable

True/False
Value Default: False

Feature L92076
ClockSync::syncEClockEnable
Parameter syncEClockEnable

True/False

Feature L92073
6.1 GPS SYNCHRONIZATION SOURCE CONFIGURATION

For the GPS source, it is possible to choose between an internal GPS receiver
and an external GPS receiver.
Since LA2.0 the GPS receiver is on-board eCCM-U.
It is also possible to configure the eNB (the CCM board more precisely) to
process the data link signal (in addition to the PPS (pulse per second) signal it
uses for synchronization: needed to get a frequency synchronization) which
contains the location and time-of-day information. This is possible using
parameter gpsModeSelect:
Page 144/308
ClockSync::gpsModeSelect
Parameter gpsModeSelect

{ Unmanaged Internal GPS receiver,
Unmanaged External GPS receiver,
Managed Internal GPS receiver,
Managed External GPS receiver}
Class/Source A--Full-NE-Reset / customer_init
Value O.D. (ALU default: Unmanaged Internal GPS receiver)

Feature L97926, L115435, L97084.1
Note: Since the eCCM-U with internal GPS always supports Managed mode,
there is no need to have internal GPS in Unmanaged mode as an option.
Note:
internal GPS receiver - means the selection is for the GPS receiver integrated
on the eCCM - the interface will be the GPS RF coax connector to the antenna
cable
external GPS receiver - means a separate GPS receiver outside the eNB, the
interface will be the RS422 supporting connector
With the following mapping:
gpsModeSelect GPS mode
Unmanaged Internal GPS eNB uses internal GPS receiver and does not
receiver process the data link signal. eNB supports the
PPS signal only
Unmanaged External GPS eNB uses external GPS receiver and does not
receiver process the data link signal. eNB supports the
PPS signal only
Managed Internal GPS receiver eNB uses internal GPS receiver and
processes the data link signal
Managed External GPS receiver eNB uses external GPS receiver and
processes the data link signal
Rule: Parameter gpsModeSelect
If the value of parameter isGeoLocPhaseSyncAllowed value is True, then the

value of parameter ClockSync::gpsModeSelect must be either Managed
Internal GPS receiver (means on board of eCCM), or Managed External GPS
receiver
Page 145/308
Also, besides frequency synchronization, phase synchronization is also possible

with GPS. In this case (i.e. when GPS is used), parameter sfnSyncOption
determines whether the eNB is frequency locked or frequency and phase locked
or frequency and phase and TimeofDay locked. This parameter is ignored if
another synchronization option is used (that is, if 1588 PTP is used or if syncE is
used).
ClockSync::sfnSyncOption
Parameter sfnSyncOption
Range & Unit

Enumerate
{FreqSyncOnly(0), FreqAndPhaseSyncEnabled(1),
FreqAndPhaseAndTimeOfDaySyncEnabled(2) }
Class/Source A--full-NE-reset / customer_settable
Value Default: freqSyncOnly

Feature L115435
Rule: Parameter ClockSync:: sfnSyncOption

If the value of parameter isSyncCdmaSystemTimeAllowed = "True" the value of
sfnSyncOption parameter must be either
FreqAndPhaseSyncEnabledorFreqAndPhaseAndTimeOfDaySyncEnabled.
If the value of parameter isGeoLocPhaseSyncAllowed = "True" the value of

sfnSyncOption parameter must be
FreqAndPhaseAndTimeOfDaySyncEnabled
If the value of parameter isMBMSBroadcastModeAllowed = "True" the value of

sfnSyncOption parameter must be equal to
FreqAndPhaseAndTimeOfDaySyncEnabled
If the value of parameters isSyncCdmaSystemTimeAllowed and

isGeoLocPhaseSyncAllowed and isMBMSBroadcastModeAllowed are all
equal to "False”) then parameter sfnSyncOption value must be equal to
“freqSyncOnly”
Restriction: Parameter sfnSyncOption
If the value of parameter isGeoLocPhaseSyncAllowed value is True, then

the value of the sfnSyncOption parameter must be either
FreqAndPhaseSyncEnabled or FreqAndPhaseAndTimeOfDaySyncEnabled.
Page 146/308
7 ENB AND SOFTWARE CONFIGURATION

CONTROL PARAMETERS
7.1 ENB EQUIPMENT RELATED PARAMETERS
This section contains parameters that are associated with the ENBEquipment
object.
aliasName - parameter provides a user-defined alias for identification of the ENB.
It is local to the OMC and is not transmitted to the eNB.
ENBEquipment::aliasName
Parameter aliasName
Object ENBEquipment
Unicode String
Range & Unit
0 to 255 characters
Class/Source N.A. 2 / customer_settable
Value O.D.
Feature L78706
Restriction: aliasName parameter
The character \ is not allowed in the aliasName parameter value
userSpecificInfo This is an information field that is reserved for the user. No

specific treatment on this field is performed by the system.
ENBEquipment::userSpecificInfo
Parameter userSpecificInfo
Object ENBEquipment
Range & Unit String
0 to 128 characters
N.A. Default value: LA13.1_MIM_40.1-
Value
CPRI_40W_10MHz_ed03
Feature L78706
2
Class does not apply to an OMC parameter such as this that is not transmitted to the eNB.
Page 147/308
Restriction: userSpecificInfo parameter
The character \ is not allowed in the userSpecificInfo parameter value
templateVersion - parameter identifies the version of the template package

applied to the configuration. The parameter value is provided by the template
package. It is not recommended for the operator to modify the parameter value.
Normally, the parameter is absent if no template package has been applied.
ENBEquipment::templateVersion
Parameter templateVersion
Object ENBEquipment
Range & Unit String of up to 128 Characters
Class/Source N.A. / system_restricted
Value O.D.
Feature
7.2 SOFTWARE AND CONFIGURATION CONTROL

PARAMETERS
In some earlier releases, several flags were used by the XMS system and by
SAM to control software upgrade and downloading of configuration files. The
Service Aware Manager (SAM) system uses SAM policy files to control eNB
upgrade and downloading of configuration files as described in Reference [R09].
Further information concerning software upgrade and online/offline configuration

from the 5620 SAM can be found in Reference[R09].
Rule: SAM Identification of an eNB
For the purpose of identifying the eNB, Reference [R09] refers to the “ID value
of the ENBEquipment Object”. This identifying string for the eNB is actually the
value of the uniqueName parameter for the ENBEquipment object that is
assigned when the ENBEquipment object is created.
Feature L96759 (Self Configuration of eNB Phase2) provides several capabilities

that reduce the manual effort that is required for the installation of an eNB.
The capabilities provided by this feature are:
• The eNB factory software load allows the eNB to establish an OAM
connection to SAM using default values. This requires that a Dynamic
Host Control Protocol (DHCP) server be setup to provide the eNB OAM
IP address – see [R04] for additional detail on this capability.
Page 148/308
• SAM can remotely trigger an upgrade of the eNB software load to a

current load that is specified by the operator.
• On site provisioning of eNB parameters with the Network Element
Manager (NEM) is not necessary. They can be downloaded remotely
from the SAM location.
• A configuration file can be prepared off-line using the WPS system, and
the file can be downloaded to the eNB after the software upgrade is
completed.
• The operator can establish a mediation policy for the eNB that provides
checkpoints for each of the steps listed above so the process can be
paused and restarted at the end of each step. Alternatively, the process
can be setup to continue automatically.
A typical scenario for the installation and self-configuration of a new eNB using
WPS/SAM would be as follows:
• The user creates a workorder containing the full eNB configuration for
one or more eNBs.
• The user deploys the workorder in the SAM network. Even though the
eNB(s) are not managed and the IP addresses may be unknown, SAM
automatically creates pre-provisioned NE profiles (templates matching the
workorder contents) to match. The PPNE profile is a "shadow" NE, simply
a set of eNB parameter objects without a node. The profile contains
identifying information, such as HW serial numbers and the eNB
uniqueName.
• The user creates a self-configuration policy that determines which steps
are followed when an eNB for self-configuration is discovered. This
includes rules for software upgrade, workorder deployment, and
administrative enable.
• The user creates a discovery rule and associates the self-config policy
with it. The discovery rule contains the IP addresses of the eNBs to be
discovered.
• When the discovery rule is activated, SAM discovers the eNBs according
to the specified IP addresses and can now match the real nodes with the
PPNE profiles based on eNB name and HW serials.
• SAM follows the self-configuration policy, which, when fully automated,
will upgrade the eNB SW load, deploy the parameters, and try to set the
node administrative state to enabled. If all goes according to plan, the
eNBs are operational with the intended configuration.
Engineering Recommendation: Software Download
The recommended method for controlling software download is through the

use of a SAM policy file. See Reference[R09].
Page 149/308
The eNB self configuration feature is controlled by the isEnbSelfConfigAllowed

parameter that can be set using the WPS interface.
isEnbSelfConfigAllowed - parameter controls whether eNB self-configuration is
allowed, and it is used for feature licensing. Please refer to rule below in order to
feature activation specifications.
The eNB self-configuration optional feature is managed by Feature Licensing
(refer to LPUG [Vol. 1] for details). This parameter (isEnbSelfConfigAllowed)
can be set to 'True' only if licensing (Tokens) are available for the feature. The
total number of activations for each feature is counted across all eNBs by SAM.
ActivationService::isEnbSelfConfigAllowed
Parameter isEnbSelfConfigAllowed
True, False
Class/Source C--Immediate-propagation / system_restricted
Value O.D (Default: False)
Feature L96759
Rule: isEnbSelfConfigAllowed
If enableAutomaticConfiguration is set to true,

this parameter must be set to true.
If enableAutomaticUpgrade is set to true,
this parameter must be set to true.
SAM can determine whether the feature is activated (i.e. allowed to be used) on a
particular eNodeB by checking the configuration parameter
isENBselfConfigAllowed.
If isENBselfConfigAllowed is set to TRUE, the eNB self-configuration feature is

activated. If isENBselfConfigAllowed is set to FALSE, the feature is
deactivated.
If the feature is activated, the operator can configure SAM policy files that will
allow eNB automatic upgrade and automatic configuration.
If the feature is deactivated, then the operator must manually perform SW

upgrade and configure the gamma parameters on a new eNodeB.
Remote provisioning of the beta parameters is allowed whether the self-

configuration feature is activated or not. Netconf parameter provisioning from a
local NEM is allowed whether the self-configuration feature is activated or not.
Feature L108514 (eNB Software Replacement Improvements) introduced several

capabilities that make software upgrade and fallback simpler. As part of this
Page 150/308
feature, a Software Activation Fallback timer is implemented that initiates

switchover to the passive partition and passive database (the previous SW
version and configuration database) if the eNB cannot establish communication
with a management system after a software upgrade (or downgrade). This
provides a safety net in case of critical errors in the new SW version.
The duration of the Software Activation Fallback timer is determined by the value
of the timerToWaitForFallbackToPreviousSWversion parameter. A timer value
of 0 indicates that automatic SW fallback is turned off. If the timer value is greater
than 0, the eNB will start the SW Activation Timer after a SW Activation is
successfully completed and will stop the SW Activation Timer when one of the
following happens:
• SAM or the NEM reads the value of a specific internal system variable
from the eNB (indicating that communication has been reestablished with
a management system)
• eNB receives a SW Accept command
o eNB receives a SW Reject command.
If the SW Activation Timer expires, the eNB attempts to boot using the previous
SW version and configuration database.
Enb::timerToWaitForFallbackToPreviousSWversion
Parameter timerToWaitForFallbackToPreviousSWversion
0 and 30 to 120 minutes, step 1
Class/Source C--New-set-ups / customer_init
Value 30 Minutes
Feature L108514
Note that a similar timer is implemented to support fallback when the eNB IP
configuration is changed. See [R04] for additional details about this capability.
eNB can also be forced to reset by modifying parameter
doEnbResetAfterConfiguration (for instance incremented) through a Work
Order. The eNB is reset following the processing of the Work Order (as a MIM
Class A parameter, eNB is reset each time parameter is modified).
Page 151/308
Enb:: doEnbResetAfterConfiguration
Parameter doEnbResetAfterConfiguration
0 to 65335
Class/Source A (0) / customer_settable
Value 0
Feature 168155
168155 This feature allows Factory, Commissioning, 3GPP 36.104/141

Conformance, and Customer Acceptance Test Support in LR13.3 for the Macro
configurations. It provides a way for Factory to automate their testing and a way
for the Hardware Integration Group to perform 3GPP TS 36.104/141 testing
without having to be connected to an OMC. This feature shall support all existing
carrier frequency band and carrier bandwidth in LR13.3.
The eNodeB shall reset when it receives a configuration file with the parameter
doEnbResetAfterConfiguration of the eNB object set to a new integer value.
Page 152/308
8 OVERLOAD CONTROL
This section describes several features and the associated parameters that affect
the eNB handling of calls during overload conditions.
Feature L115241.1 (Overload Control Evolutions & QoS Differentiation on eNB

Backplane) provides an evolution of the capabilities introduced by feature L97930
(Overload Control). The objective of Overload Control is to avoid performance
degradation and outages when the eNB is subjected to traffic that exceeds its
processing capacity. Feature L115241 adds support for this feature for the bCEM
modem card.
The capabilities that are added by Feature L115241.1/L115241 include:
• eNB capability to monitor processor occupancy and RAM usage for its
processors, to record and report processor occupancy using counters,
and to report event occurrence when operator-defined major and minor
overload threshold levels3 are crossed.
• Ability to detect panic overload based on message queues and buffer
pools (list to be defined) and discard internal messages based on a
priority field.
• Ability to spread load based on individual board/instance overload
conditions
• Ability to prohibit preemption (except for emergency calls) as soon as
Minor overload is detected
• Ability to limit the number of parallel emergency calls to avoid an
emergency call related overload situation
• Allow the operator to configure ratios for rejecting some procedures (e.g.,
reject 1 out of 5 new RRC connection requests).
The remainder of this section will refer to the capabilities of Features L115241.1
and L115241 as just L115241, and will focus on the capabilities that are affected
by configuration parameters that can be modified by the operator.
Table 20 provides an overview of the parameters that are associated with major
and minor overload conditions for Feature L115241. All of the parameters are
associated with the OverloadControl object. Table 20 also provides a reference
to the LPUG volume in which the use of the parameter is covered in more detail.
LPUG
Subject Minor OL Control Threshold Major OL Control Threshold
Volume
Threshold for entering minorThresholdForPO majorThresholdForPO 2
3
Note that a critical threshold is also defined internal to the system, but the associated PO level is not under
operator control.
Page 153/308
overload condition
Threshold for leaving

minorOutThresholdForPO majorOutThresholdForPO 2
overload condition
intraEnbHoReqRejectRateMi intraEnbHoReqRejectRateM
Intra-eNB handover 6
nor ajor
RRC Connection Re- rrcCnxReestabRejectRateMi rrcCnxReestabRejectRateM

5
Establishment nor ajor
rrcCnxReestabRejectRateM
RRC Connection rrcCnxReqRejectRateMinor 5
ajor
Request
rrcCnxReqWaitTimeMinor rrcCnxReqWaitTimeMajor 5
S1 HO s1HoReqRejectRateMinor s1HoReqRejectRateMajor 6
S1 Paging s1PagingIgnoreRateMinor s1PagingIgnoreRateMajor 5
s1RabModifyReqRejectRate s1RabModifyReqRejectRate
5
S1 RAB Setup and Minor Major
Modify s1RabSetupReqRejectRate s1RabSetupReqRejectRate
5
Minor Major
X2 HO x2HoReqRejectRateMinor x2HoReqRejectRateMajor 6
Table 20 : Feature L115241 Parameters for Minor and Major Overload Conditions
Table 21 provides an listing of features that are affected by Feature L115241, and
the parameters that are used to disable those features during an overload
condition. All of these parameters are also associated with the OverloadControl
object. A reference is also provided to the LPUG volume in which the use of the
parameter is covered in more detail.
Feature Parameter LPUG Volume
ANR ovLevelForANRInhibition 6
Call Trace ovLevelForCTInhibition 2
Per Call Measurement Data ovLevelForPCMDInhibition 2
Signaling Based Trace ovLevelForS1TraceStartAction 2
Dynamic Debug Trace ovLevelForDDTInhibition 2
Debug Snapshot ovLevelForDTInhibition 2
X2 Configuration Update ovLevelForX2ENBConfUpdAction 5
X2 Setup ovLevelForX2SetupReqAction 5
X2 Resource Report ovLevelForX2ENBResourceReportAction 5
Table 21 : Features that are affected by Feature L115241 and the Associated Parameters
Page 154/308
Table 22 provides a list of parameters introduced by Feature L115805 to control

behavior in overload situation. A reference is also provided to affected kind of
calls and the LPUG volume in which the use of the parameter is covered in more
detail.
Parameter Kind of calls LPUG Volume
s1PagingPriorityIndicationHandling S1 MPS Messages 5
accessClassBarringDefense Non emergency MO Sig/Data 5
ecHighPriorityCallsFilteringCriticalOverload Emergency Calls 5
mtAccessRrcCnxReqFilteredInOverload Mt-access RRC Request 5
Table 22 : Parameters introduced by feature L115805
minorThresholdForPO - parameter specifies the processor occupancy (PO)

threshold at which Minor Overload is declared.
OverloadControl::minorThresholdForPO
Parameter minorThresholdForPO
Object ENBEquipment/Enb/OverloadControl
50 to 100%, step 1%
Value 81%
Feature L115241
minorOutThresholdForPO - parameter specifies the processor occupancy (PO)

threshold at which the eNB comes out of Minor Overload.
OverloadControl::minorOutThresholdForPO
Parameter minorOutThresholdForPO
50 to 100%, step 1%
Value 76%
Feature L115241
Page 155/308
Inter-Release Delta: minorThresholdForPO and minorOutThresholdForPO

parameter
The value assigned to parameter minorOutThresholdForPO must be less than the
value assigned to parameter minorThresholdForPO.
The recommended values for the minor thresholds have been changed to allow the
processor occupancy to go up to 80% as a normal condition (with the average traffic
model).
majorThresholdForPO - parameter specifies the processor occupancy (PO)

threshold at which Major Overload is declared.
majorThresholdForPO - parameter specifies the processor occupancy (PO)
threshold at which Major Overload is declared.
OverloadControl::majorThresholdForPO
Parameter majorThresholdForPO
50 to 100%, step 1%
Value 88%
Feature L115241
majorOutThresholdForPO - parameter specifies the processor occupancy (PO)

threshold at which the eNB comes out of Major Overload.
OverloadControl::majorOutThresholdForPO
Parameter majorOutThresholdForPO
50 to 100%, step 1%
Value 83%
Feature L115241
Page 156/308
Rule: majorThresholdForPO and majorOutThresholdForPO parameters
The value assigned to parameter majorOutThresholdForPO must be less than

the value assigned to parameter majorThresholdForPO.
isEnhancedOverloadControlEnabled - This parameter enables or disables

Enhanced Overload Control in the eNodeB, allowing the discarding of stale RRC
Connection and Re-establishment requests, enhancing feature L115241.
ActivationService:: isEnhancedOverloadControlEnabled
Parameter isEnhancedOverloadControlEnabled
Class/Source C--Immediate-propagation / Customer_settable
Value False
Feature 156132
Page 157/308
9 STATE AND STATUS PARAMETERS

(ADMINISTRATIVESTATE,
AVAILABILITYSTATUS AND
OPERATIONALSTATE)
ITU-T standard X.731 defines three attributes that are related to the state and
status of an LTE object. Several LTE objects utilize these parameters to indicate
the object’s status or to allow the operator to control it. These attributes
(parameters) are discussed in this section.
availabilityStatus: This parameter is a read only parameter that is controlled by
the system. The potential values for this parameter are extracted from
X.731[R01]:
• inTest - The resource is undergoing a test procedure.

• failed - The resource has an internal fault that prevents it from operating.
The operational state is disabled.
• powerOff - The resource requires power to be applied and is not powered
on. For example, a fuse or other protection device is known to have
removed power or a low voltage condition has been detected. The
operational state is disabled.
• offline - The resource requires a routine operation to be performed to
place it online and make it available for use. The operation may be
manual or automatic, or both. The operational state is disabled.
• offDuty - The resource has been made inactive by an internal control
process in accordance with a predetermined time schedule. Under normal
conditions the control process can be expected to reactivate the resource
at some scheduled time, and it is therefore considered to be optional. The
operational state is enabled or disabled.
• dependency - The resource cannot operate because some other resource
on which it depends is (i.e. a resource not represented by the same
managed object) unavailable. For example, a device is not accessible
because its controller is powered off. The operational state is disabled.
• degraded - The service available from the resource is degraded in some
respect, such as in speed or operating capacity. Failure of a test or an
unacceptable performance measurement has established that some or all
services are not functional or are degraded due to the presence of a
defect. However, the resource remains available for service, either
because some services are satisfactory or because degraded service is
preferable to no service at all. The operational state is enabled
• notInstalled - The resource represented by the managed object is not
present, or is incomplete. For example, a plug-in module is missing, a
Page 158/308
cable is disconnected or a software module is not loaded. The operational

state is disabled.
• logFull - This indicates a log full condition the semantics of which are
defined in ITU-T Rec. X.735
operationalState: This read only parameter is also defined in X.731, and

describes the “operability” of a resource. Its value is controlled by the system. The
operationalState parameter has two potential values:
• enabled - the resource is operational
• disabled - the resource is not able to perform functions
administrativeState: The value of this parameter is used by the operator from

the OMC to control whether the associated object can be used to provide service.
It is also defined in X.731, and there are three potential values for this parameter.
• locked - The associated object is administratively prohibited from
performing services for its users.
• unlocked - The resource is administratively permitted to perform services
for its users. This is independent of its inherent operability.
Table 23 provides a listing of objects that have state and status parameters that
are associated with them. Note that the default value of the administrativeState
parameters varies for different objects, so the default value is listed for the
administrativeState parameter. Also note that some objects do not have
administrativeState parameters associated with them, because they cannot be
locked/unlocked.
AntennaPort::administrativeState
AntennaPort::availabilityStatus
AntennaPort::operationalState
BscAccess::administrativeState
CdmaPhaseSync::availabilityStatus
CdmaPhaseSync::operationalState
FRU::availabilityStatus
FRU::operationalState
FRU::administrativeState
GeoLocPhaseSync::availabilityStatus
GeoLocPhaseSync::operationalState
GPSTime::availabilityStatus
Page 159/308
GPSTime::operationalState
LteCell::availabilityStatus
LteCell::operationalState
LteCell::administrativeState
MmeAccess::availabilityStatus
MmeAccess::operationalState
MmeAccess::administrativeState
MmeTransportLayerAccess::availabilityStatus
MmeTransportLayerAccess::operationalState
RncAccess::administrativeState
Sector::availabilityStatus
Sector::operationalState
Sector::administrativeState
X2Access::availabilityStatus
X2Access::operationalState
X2Access::administrativeState
X2TransportLayerAccess::availabilityStatus
X2TransportLayerAccess::operationalState
Page 160/308
availability operational administrative administrativeState

Object Name
Status State State Default Value 4
AntennaPort X X X unlocked
BscAccess X locked
CdmaPhaseSync X X
EnbEquipment X X X unlocked
FRU X X X unlocked
GeoLocPhaseSync X X
GpsTime X X
LteCell X X X locked
M3MmeAccess X X X unlocked
M3MmeTransportLay
X X
erAccess
MbmsPhaseSync X X
MmeAccess X X X unlocked
MmeTransportLayer
X X
Access
RncAccess X locked
Sector X X
X2Access X X X unlocked
X2TransportLayerAc
X X
cess
Table 23 : State and Status Parameters for Maintenance Objects
4
The "default value" for these objects indicates the state in which the object is created. If the
default administrativeState value is "locked", this means that the operator must perform a
manual operation to unlock the object to make it available.
Page 161/308
10 SPARE PARAMETERS
Spare parameters are included in each release, and can be used to provide:
• the ability to test certain variables in a controlled laboratory environment
using the production software (these uses are not documented in LPUG
and should not be used in a field environment without specific instructions
from ALU)
• the ability to provide additional parameters when the need is discovered
late in the development process. In these cases, the use of the spare
parameters is documented in LPUG.
In general the use of the spare parameters are temporary in nature, and any
specific use in subsequent releases should result in a separate MIM parameter or
in deletion of the parameter from the future release.
Each spare parameter provides 32 bits, and it is possible to utilize specific bits for
each temporary use. Each stringSpare parameter provides space for 0 to 40
characters, and is defaulted to a value of “Null String”.
10.1 LA6.X SPARE PARAMETERS
Spare Parameters Class - Impact of

Object LPUG Volume and Use
Available Update
booleanSpare00 C - New-set-ups
ENBEquipment/Enb booleanSpare02 C - New-set-ups
spare0 A--full-NE-reset
B--Cells-of-
ENBEquipment/Enb spare2 NEModems+Cells-
of-NE
B--Cells-of-
spare3 NEModems+Cells-
of-NE
Page 162/308

Available Update
B--Cells-of-NE Bits 0-1: This parameter
specifies the number of the
PRB zones that are
blocked from being
scheduled by ULS for any
PUSCH transmissions:
00: no blocking - the
function is effectively
disabled.
spare4 01: 1 PRB zone that is
blocked.
02: 2 separate PRB zones
are blocked.
03: not used
For more information
regarding this spare
parameter please refer to
[Vol. 4]
spare5 B--Cells-of-NE
B--Cells-of-NE
spare6
Page 163/308

Available Update
B--Cells-of-NE
For more information on
this spare parameter
please refer to [Vol. 4]
Bits 0-7: Controls the

threshold in terms of per-
20ms TB size associated
with a call’s VoIP bearer(s).
If the call's TB size is lower
the threshold then
Optimized Segmentation is
not activated on the call. –
Moved on LR13.X to
CellL2ULConf::minTBsizeF
orOptSeg
Bit 8: Controls whether
optimized segmentation is
applied irrespective of the
uplink VoIP buffer
occupancy estimate (when
set to false) or not.
spare7 Parameter created LR13.1
- CellL2ULConf::
bOcheckForOptSeg
Bit 9: Allows to enforce
32kbps/PRB min floor in
the Spectral Efficiency
conversion. Boolean: 0 =
Disabled (default) and 1=
Enabled
Bit 12: Controls errors in
LA6.0 - Send RRC release
msg if call establishment
fails because msg5 is not
received
Bit 15..16: Capping of
PUCCH power control
increase:
00 --> capping not activated
01 --> capping at +2dB
Page 164/308

Available Update
B--Cells-of-NE Bit 7: Enable / Disable AGC
1 --> AGC enabled -->
bit9-8 ignored
0 --> AGC disabled (bit9-8

= 0 means no shift, bit9-8 =
1|2|3 means constant shift)
spare8
Bit 8..9: bit9-8 ignored (if

bit7 = 1 --> AGC enabled)
bit9-8 = 0 means no shift,

bit9-8 = 1|2|3 means
constant shift (if bit7 = 0 -->
AGC disabled)
B--Cells-of-NE For more information
[Vol. 4]
bit 0..2 - This parameter

controls the value of
minNbrPRBForULDSVoIP.
Range: 0/1/2/3/4. Setting it
to 0 effectively disables the
PRB override. Support of
(nominal LA6) feature,
160815, via LA5.0.2.
spare9 Parameter created on to
CellL2ULConf::minNbrPRB
ForULDSVoIP
bit 19..21 - This parameter
controls the value of
overrideOptSegActivationTi
mer. Range 0/1/2/3/4
*100ms. Setting the value
to 0 effectively disables the
timer mechanism. Support
of (nominal LA6) feature,
160815, via LA5.0.2.
Parameter created on to
CellL2ULConf::overrideOpt
SegActivationTimer
Page 165/308

Available Update
bit 23 - This parameter

controls the overall
activation of the Optimized
Segmentation feature
L160815 for VoIP calls.
Value 0 corresponds to
disabled. Support of
(nominal LA6) feature,
160815, via LA5.0.2.
ActivationService::isOptimiz
edSegmentationEnabled
bit 31 - This parameter
controls the value of the
isVoIpSegmentationHandlin
gEnabled flag in the uplink
scheduler. When this flag is
set to true, the user priority
is kept high in the uplink
scheduler until all segments
of the speech frame have
been scheduled. This is an
enhancement to improve
VoIP packets delay
statistics. MIM parameter is
missing from LA5.0 MIM.
CellL2ULConf::isVoIpSegm
entationHandlingEnabled
C--Immediate-
spare10
propagation
Bit1:
isTurningRadioOffOnS1Fail
ureEnabled If the bit is set
to 1, when the last S1 link
fails, the eNB will
C--Immediate- deconfigure its cells in
spare11
propagation order to stop any radio
transmission. This implies a
CEM
Bit 2..7:
radioOffHysteresisTimer
This parameter specifies
Page 166/308

Available Update
the time to wait (in

seconds) before eNodeB
cuts the radio off following
a failure of all S1-MME
links.
To get the value, spare11
must be right-shifted by 2
bits and then AND with
0x3F to get the 6-bits
quantity.
If the value is 0, eNB-OAM
will use timer value greater
than
Enb::cellBarringHysteresisT
imer based on a default
rule
Bit 8
This parameter enable
/disable inter-verdor inter-
freq load balancing. 0:
Disable/1; Enable.
The default value is "0",
indicating deactivated.
Bit 9
This parameter
enables/disables the
PUCCH/SRS configuation
alignment with MAC DRX
OnDuration for VoLTE call.
Default ="0", indicating
deactivated.
Bit 1
isAdditionalTransportCount
ersEnabled This parameter
enables or disables the
spare12 C--New-set-ups eNodeB feature for
additional Performance
Management counters in
the Transport domain.
The value 0 disables the
Page 167/308

Available Update
feature; value 1 enables it.

Bit 2:
isEnhancedOverloadContro
lEnabled This parameter
enables or disables
Enhanced Overload Control
in the eNodeB, allowing the
discarding of stale RRC
Connection & Re-
establishment requests.
The value 0 disables the
feature; value 1 enables it.
Bit 3
isA2CAhandlingDuringAnrA
llowed This flag specifies
whether a A2_CA
measurement report
received from the UE while
it has ANR measurement
configured has to be
handled (bit = 1) or not (bit
= 0).
Bit 4:
isPrbCacSkippingForNonG
brEnabled This flag allows
skipping PRB-based CAC
for non-GBR bearers and
SRB when set to 1. If set to
0, PRB-based CAC will be
done for all bearers.
Bit 5:
changeCauseInUeCtxRlsR
eqRetry This parameter
specifies whether eNB
changes the cause code
from “User Inactivity” to
“Release due to EUtran
Generated Reason” when
retrying UE Context
Release Request sent to
MME upon time-out waiting
for a response from MME.
Value “0” disables the
Page 168/308

Available Update
change of cause code on

the retry.
Value “1” enables the
change of cause code.
Bit 6:
complianceTo3GPPcrGP12
1108 This parameter
controls the activation of a
non-backwards compatible
fix on the
encoding/decoding of the
RIM Routing Information
and Reporting Cell
Identifier IEs of RIM
Messages following a
3GPP Standard clarification
brought in GERAN#55 by
CR GP-121108.
Value “0” maintains the old
non-compliant encoding.
Value “1” enables the new
3GPP-compliant encoding.
The default value should be
“0”.
Bit 7:
correctCodingOfuTRANcellI
DforRIM "This parameter
controls the activation of a
non-backwards compatible
fix on the
encoding/decoding of the
uTRANcellID in the RAN
Information Request.
Value “0” maintains the old
non-compliant encoding.
Value “1” enables the new
3GPP-compliant encoding.
The default value should be
“0”.
Bit 8..19:
spare13 C--New-set-ups rrcConnSetupCompleteTim
er The spare bits specify
Page 169/308

Available Update
the guard timer for RRC

Connection Setup
Complete to address CR
#540555. The range is (50,
3000) in unit of ms after
right-shfiting the field by 8
bits, consistent with the
range of
rrcProcedureDefenseTimer.
A value outside the range is
treated by CallP as the
default value.
Bit 0..31 rabInactivityTimer

the duration of the timer
used to determine whether
an established E-RAB is
inactive. This information is
used to peg counter 12635
in case a bearer is dropped
Spare14 C--New-set-ups while its inactivity time is
above the value of this
parameter.
The unit is 1 millisecond.
The logical range is 0 to
10000.
The recommended timer
value is 150 milliseconds.
Bit 0
Activate/deactivate
L114538 - Enhanced Load
Balancing criteria - blind
preventive offloading, i.e.
preventive offloading
without load information on
spare15 C--New-set-ups the neighbor cell. If set to 1
(True), preventive offload
without any neighbor cell
load info is allowed.
Bit 1
Page 170/308

Available Update
This parameter
enables/disables FDD<-
>TDD redirection (L101815
- Intra LTE FDD/TDD
Handover) when a UE
which does not support
FDD<->TDD HO receives
an inter-freq measurement
report due to radio
coverage.
The value 0 implies
disabled; the value 1
implies enabled.
Default: 0;
Bit 2
This parameter controls the
activation of autonomous
gaps (134689 -
Macro/Metro to HeNB cell
mobility) in the UE when
ReportCGI measurement is
configured for the purpose
of mobility towards HeNB.
- If the value is equal to '1',
autonomous gaps are
activated when the UE
supports them.
autonomous gaps are
never activated, even if the
UE supports them.
Default: 0;
Bit 9:
intraFreqAnrMeasurement
Only If the bit is set to 0
then ANR is allowed to add
an intra-frequency neighbor
relation when a mobility
measurement is received
and the best neighbor is
unknown. If the spare bit is
Page 171/308

Available Update
set to 1 then ANR is not

allowed to add a neighbor
relation in this case, but is
still allowed to add
neighbors when ANR
measurement reports are
received.
Bit 10:
interFreqAnrMeasurement
Only If the bit is set to 0
then ANR is allowed to add
an inter-frequency neighbor
relation when a mobility
measurement is received
and the best neighbor is
unknown. If the spare bit is
set to 1 then ANR is not
allowed to add a neighbor
relation in this case, but is
still allowed to add
neighbors when ANR
measurement reports are
received.
Bit 18…22:
maxAveragePrbPerKbps
These 5 bits control the
maximum allowed average
PRB cost per kbps to be
used by evaluate PRB
consumption. When the
average cost corresponding
to the last PRB
measurement period is
above this threshold, it is
not taken into account. It is
used for both UL & DL, and
for all types of bearers. 32
values are possible (0 to 31
PRB/s/kbps), and when
value 0 is configured, this
enhancement is disabled.
Bit 23:
isNewBearerAveragePrbPe
rKbpsConfigured This flag
controls whether the
Page 172/308

Available Update
average PRB cost per kbps

to be used for new bearers
is based on configuration
data or not. When set to
true, the
averagePrbPerKbps is
based on configuration
data. When set to False,
the averagePrbPerKbps is
calculated by the eNB. It is
used for all types of bearers
(VoIP, GBR, non-GBR and
SRB).
stringSpare00 A--full-NE-reset
B--Modems+Cells-
stringSpare04
of-NE
ENBEquipment/Enb
B-- Modems+Cells-
stringSpare05
of-NE
stringSpare06 B--Cells-of-NE
B--Transport-
stringSpare08
Layers
B--Transport-
stringSpare09
Layers
Page 173/308

Available Update
This parameter is used to

set the Brazil time zone
In LR14.1 the existing
C--Immediate-
stringSpare10 "timeZoneName" parameter
propagation
of the MIM will be reworked
so as to align with this
usage.
C--Immediate-
stringSpare11
propagation
stringSpare12 C--New-set-ups
ENBEquipment/Enb/Lte
Cell
spare0 B--Modems+Cells
B--Cell(s)-of-
spare2
Modem
B--Cell(s)-of-
spare3
Modem
Cell For more information
spare4 B--Cell
[Vol. 4]

spare5 B--Cell
[Vol. 4]
Page 174/308

Available Update
Bit 0..4: This parameter is

requested to support MRO
(ONLY applies to MRO
does not apply to MCO or
Macro) uplink gain. (The
spare parameter is defined
as 5-bit signed values, from
-16 to +15 with the
mapping.
Attenuation = 16 dB +
spare6[4…0], where
spare6[4…0] is a signed
number). spare = 00000
means 16 db for MRO
(default value)-16 to +15
with the mapping
Bits 23 and 24 – controls

whether
SsacBarringForVoiceMMT
EL is included in SIB2 or
C--Immediate-
spare6 not.
propagation
Default spare = 0. Included
in SIB2.
Bits 31 – assiged for HO
performance test in
contention free HO/RA.
Set to 1 for HO
performance test in
contention free HO / RA
using half LUT. Because
half LUT is used, the the
maximum number of UE
will be half (<=15 for
uplinkControlChannelLUTin
dex = 1, <=50 for
dex = 0)
set to 0 for other case.The
normal LUT is used.
This spare can be set to 1

Page 175/308

Available Update
only when uplinkControl

ChannelLUTindex = 1 / 0.
Set default to 0, set to 1 by
tester if needed.
C--Immediate-
spare7
propagation
Bit 0..31: This parameter is,

in effect, read-only from the
operator perspective.The
parameter reports the
integer part of the time
when SFN=0 at the
downlink antenna, in
seconds relative to
00:00:00 on 1 January
1900 (calculated as
continuous time without
leap seconds and traceable
to a common time
reference). The fractional
spare8 C--New-set-ups
part is reported by
"ENBEquipment/Enb/LteCe
ll spare9"
This parameter is used by a
Location Server for OTDOA
position computation
method.
In LR13.1 MIM, LteCell
spare8 and LteCell spare9
are replaced by MIM
parameter
LteCell::sfnInitializationTim
e.
Page 176/308

Available Update
This parameter is, in effect,

read-only from the operator
perspective.
The parameter reports the
fractional part of the time
when SFN=0 at the
downlink antenna, in
seconds relative to
00:00:00 on 1 January
1900 (calculated as
continuous time without
leap seconds and traceable
to a common time
reference). The fraction
part is expressed with a
Spare9 C--New-set-ups granularity of 1 /2**32
second.
The integer part is reported
by
"ENBEquipment/Enb/LteCe
ll spare8"
This parameter is used by a
Location Server for OTDOA
position computation
method.
In LR13.1 MIM, LteCell
spare8 and LteEell spare9
are replaced by MIM
parameter
LteCell::sfnInitializationTim
e.
Spare10 C--New-set-ups
Page 177/308

Available Update
173501 uses 2 spares:

Bits 0 – 15 –
rsrpOffsetOnServingCellFor
EmergencyCall in LR14 -
Sets an rsrp offset on
"good" radio level threshold
requested in the serving
cell, which puts the UE
involved in an EC in alarm
state
e.g. value 107 in MIM
(without mediation) gives
97 at RRC level (max
possible RRC value) even if
115204 VoIP correction
Spare11 C--New-set-ups (RrcMeasurementConf :
[TtiB]VoIPCalls) adds (-10)
Bits 16 – 31 –
rsrqOffsetOnServingCellFor
EmergencyCall in LR14
Same for rsrq
(RrcMeasurementConf :
B--Modems+Cells-
spare0 Spare 6: Bit 0…6: This
of-NE
B--Modems+Cells- parameter specifies the UE
spare1 inactivity timer for SRB2,
of-NE
ENBEquipment/Enb/De B--Cells-of-NE while the existing MIM
spare2
dicatedConf/LogicalCha B--Cells-of-NE parameter
spare3
nnelConf B--Cells-of-NE TrafficBasedReleaseConf-
spare4
B--Cells-of-NE >timeToTrigger is for TRB
spare5
(Traffic RB).
C--New-set-ups
spare6 The value ranges from 0 to
Page 178/308

Available Update
C--New-set-ups 100, with step size "1" and
spare7
unit "100ms".
spare8 C--New-set-ups -0: "disabled", meaning the
C--New-set-ups UE inactivity monitoring on
SRB2 is disabled (i.e.,
SRB2 traffic is not counted
as UE activity). It is the
default value.
-1 to 100: valid values,
ranging from 0.1sec to
spare9 10sec.
-101 to 127: any value in
this range is reset to 10sec
.
Table 24 : LA6.X Spare Parameter Usage
10.2 LR13.X SPARE PARAMETERS
After summary table of spare parameters, detailed information of main ones can be found on this section.

Available Update
ENBEquipment/Enb booleanSpare02 C - New-set-ups
spare2 B--Cells-of-
ENBEquipment/Enb
NEModems+Cells-
B--Cells-of-
spare3 NEModems+Cells-
of-NE
Page 179/308

Available Update
B--Cells-of-NE
Bits 0-1: This parameter

specifies the number of the
PRB zones that are
blocked from being
scheduled by ULS for any
PUSCH transmissions:
00: no blocking - the
function is effectively
disabled.
01: 1 PRB zone that is
blocked.
spare4
02: 2 separate PRB zones
are blocked.
03: not used

[Vol. 4]
Parameter description
further on this document.
B--Cells-of-NE
spare6
Page 180/308

Available Update
B--Cells-of-NE
Bit 14: Block TPC 3dB Up

Step when IoT > 10dB
Bit 15..16: Capping of
PUCCH power control
spare7 increase:
00 --> capping not activated
B--Cells-of-NE Bits 7: Enable / Disable

AGC:
• Set to 1 --> AGC enabled
--> bit9-8 ignored
spare8 • Set to 0 --> AGC disabled
Bits 8-9:
• Set to 0 .- means no shift
• Set to 1|2|3 means
constant shift)
B--Cells-of-NE For more information
spare9 [Vol. 4]
Parameter description
further on this document.
C--Immediate-
spare10
propagation
Bit 8
This parameter enable
/disable inter-verdor inter-
freq load balancing. 0:
Disable/1; Enable.
C--Immediate- The default value is "0",
spare11
propagation indicating deactivated.
Bit 9
This parameter
enables/disables the
PUCCH/SRS configuation
alignment with MAC DRX
Page 181/308

Available Update
OnDuration for VoLTE call.

Default ="0", indicating
deactivated.
Bit 0
Activate/deactivate
L114538 - Enhanced Load
Balancing criteria - blind
preventive offloading, i.e.
preventive offloading
without load information on
the neighbor cell. If set to 1
(True), preventive offload
without any neighbor cell
load info is allowed.
Bit 1
This parameter
enables/disables FDD<-
spare15 C--New-set-ups >TDD redirection (L101815
- Intra LTE FDD/TDD
Handover) when a UE
which does not support
FDD<->TDD HO receives
an inter-freq measurement
report due to radio
coverage.
The value 0 implies
disabled; the value 1
implies enabled.
Default: 0;
Bit 2
activation of autonomous
gaps (134689 -
Macro/Metro to HeNB cell
mobility) in the UE when
Page 182/308

Available Update
ReportCGI measurement is
configured for the purpose
of mobility towards HeNB.
autonomous gaps are
activated when the UE
supports them.
autonomous gaps are
never activated, even if the
UE supports them.
Default: 0;
Bit 3:
use of a hardcoded 1Mbps
cap for QCI1 GBR bearers
and the deactivation
SPS/ROHC for a GBR
value equal or above a
specific value, both
introduced by LR13.1
feature 172164.
If the value is equal to 1,
the eNB will assume that
the maximum GBR value
for QCI1 bearers is 1Mbps
and SPS/ROHC are
deactivated if GBR value
equal or higher than GBR
indicated by eNB Spare 15
bits 4-5.
If the value is equal to 0,
the eNB will use
parameters
maxGBRforVoIPServiceDl
&
maxGBRforVoIPServiceUl
to determine the maximum
GBR value for QCI1
bearers and will not
deactivate SPS/ROHC
based on GBR (as in
previous releases)
Page 183/308

Available Update
Bit 4-5
GBR value above which
both SPS & ROHC will be
disabled upon call / bearer
setup for QCI1.
Possible values are
bit5bit4=
• 00 (25 kbps);
• 01 (50 kbps):
• 10 (75 kbps) and
• 11 (100 kbps).
Bit 6 (only available in

LR13.1):
the length of CDMA2000
1XRTT RAND IE sent on
S1AP interface. When set
to 0, IE length is 7 bytes,
when set to 1, IE length is 4
bytes
Bit 18..22:
This parameter control the
maximum allowed average
PRB cost per kbps to be
used when evaluating PRB
consumption. When the
average cost corresponding
to the last PRB
measurement period is
above this threshold, it is
not taken into account. It is
used for both UL & DL, and
for all types of bearers.
32 values are possible (0 to
31 PRB/s/kbps), and when
value 0 is configured, this
enhancement is disabled."
Bit 23:
This flag controls whether
Page 184/308

Available Update
the average PRB cost per

kbps to be used for new
bearers is based on
configuration data or not.
When set to true, the
averagePrbPerKbps is
based on configuration
data. When set to False,
the averagePrbPerKbps is
calculated by the eNB. It is
used for all types of bearers
(VoIP, GBR, non-GBR and
SRB).
Bit 24: More information

about this bit24 on [Vol. 6].
Rel9 eCSFB:
0: not activated - can be
performed
1: activated - cannot be
performed
Spare description further on

this document.
ENBEquipment/Enb
B--Modems+Cells-
stringSpare04
of-NE
B-- Modems+Cells-
stringSpare05
of-NE
Page 185/308

Available Update
B--Transport-
stringSpare08
Layers
B--Transport-
stringSpare09
Layers
C--Immediate-
stringSpare10
propagation
C--Immediate-
stringSpare11
propagation
Cell
B--Cell(s)-of-
spare2
ENBEquipment/Enb/Lte Modem
Cell B--Cell(s)-of-
spare3
Modem

spare4 B--Cell regarding this spare
Page 186/308

Available Update
[Vol. 4] or further in this

document the summary.

spare5 B--Cell parameter please refer to
[Vol. 4] or further in this
document the summary.
Bits 23 and 24 – controls

whether
SsacBarringForVoiceMMT
EL is included in SIB2 or
not.
Default spare = 0. Included
in SIB2.
Bits 31 – assiged for HO
performance test in
contention free HO/RA.
Set to 1 for HO
performance test in
contention free HO / RA
using half LUT. Because
half LUT is used, the the
maximum number of UE
C--Immediate-
spare6 will be half (<=15 for
propagation
dex = 1, <=50 for
dex = 0) - set to 0 for other
case.The normal LUT is
used.
This spare can be set to 1

only when uplinkControl
ChannelLUTindex = 1 / 0.
Set default to 0, set to 1 by
tester if needed.
Further in this document

the summary of this spare.
C--Immediate- Bit 22 - This parameter

spare7
propagation enables the MCO Metro
Page 187/308

Available Update
eNodeB to be excluded
from participation in
OTDOA (Observed Time
Difference Of Arrival)
position location. When
Enabled, the eNodeB is
made compatible with
OTDOA position location
enabled on other eNodeBs
in the vicinity by modifying
downlink scheduling in this
eNodeB to not interfere
with Positioning Reference
Signals (PRS)
transmissions of nearby
cells (assuming all are
configured with the same
PRS configuration).
0: Disabled (default)
1: Enabled
Bits 16 – 20 - This
parameter specifies the
BAND_CLASS included in
RRC
CSFBParametersResponse
CDMA2000 message for
power-up registration
determination. Possible
values are 0-21(Dec)
corresponding to BC0-
BC21 (defined in TS
36.331) and 31(Dec)
corresponding to
BC31(wildcard band class)
defined in 3GPP2 C.S0057-
E v1.0.
Page 188/308

Available Update

[Vol. 4]
Bit 0…6 -
uplinkLinkBudgetFilterInitV
alueForCA - Is the initial
value used in the IIR filter
of the Uplink Link Budget
Spare10 C--New-set-ups metric which controls
Carrier Aggregation
activation for a call.
Bit 7…9
(uplinkLinkBudgetFilterForg
ettingFactorForCA) -
Forgetting factor of the IIR
filter of the Uplink Link
Budget metric which
controls Carrier
Aggregation activation for a
Page 189/308

Available Update
173501 uses 2 spares:

Bits 0 – 15 –
EmergencyCall in LR14 -
Sets an rsrp offset on
"good" radio level threshold
requested in the serving
cell, which puts the UE
involved in an EC in alarm
state
Spare11 C--New-set-ups (RrcMeasurementConf :
Bits 16 – 31 –
EmergencyCall in LR14
Same for rsrq
(RrcMeasurementConf :
B--Modems+Cells-
spare0
of-NE
B--Modems+Cells-
spare1
of-NE
ENBEquipment/Enb/De B--Cells-of-NE
spare2
dicatedConf/LogicalCha B--Cells-of-NE
spare3
nnelConf B--Cells-of-NE
spare4
C--New-set-ups
spare6
Page 190/308

Available Update
C--New-set-ups
spare7
C--New-set-ups
spare9
Table 25 : LR13.X Spare Parameter Usage
Other than the uses shown in Table 25, the spare parameter values should be set to all
zeros
Enb:: Spare4
Parameter Spare4
Class/Source B--Cells-of-NE / eng_tunable
Value Default=0000 0000 0000 0000 0000 0000 0000 0000 (0)
0..1: nbrOfBlockedULPRBZones
This parameter specifies the number of the PRB zones that are
blocked from being scheduled by ULS for any PUSCH
transmissions:
00: no blocking - the function is effectively disabled. (Default)
01: 1 PRB zone that is blocked.
02: 2 separate PRB zones are blocked.
03: not used
2..8: startPRBofFirstBlockedULPRBzone
This parameter specifies the start PRB of the second UL PRB
zone that is to be blocked.
Note it must be a valid PRB number allowed in the carrier BW.
Bit Meaning If not, the PRB zone is regarded as invalid and code will ignore
it (first PRB zone = no PRB)
Default – 0
9..15: endPRBofFirstBlockedULPRBzone
This parameter specifies the end PRB of the first UL PRB zone
that is to be blocked.
Note it must be a valid PRB number allowed in the carrier BW,
and it shall not be smaller than the
startPRBofFirstBlockedULPRBzone. If the constraints are not
satisified, the PRB zone is regarded as invalid and code will
ignores it. (first PRB zone = no PRB)
Default – 0
16..22: startPRBofSecondBlockedULPRBzone
Page 191/308
This parameter specifies the start PRB of the second UL PRB

Note it must be a valid PRB number allowed in the carrier BW.
If not, the PRB zone is regarded as invalid and code will ignore
it (first PRB zone = no PRB)
Default – 0
23..29: endPRBofSecondBlockedULPRBzone
This parameter specifies the end PRB of the second UL PRB
Note it must be a valid PRB number allowed in the carrier BW,
and it shall not be smaller than the
startPRBofSecondBlockedULPRBzone. If the constraints are
not satisified, the PRB zone is regarded as invalid and code will
ignores it. (first PRB zone = no PRB)
Default – 0
30: forceMsg3StartingFromPRB8
This parameter determines whether the eNodeB forces msg3
to be located in PRB8. If this bit is set to 0, then the eNodeB
uses the MIM parameter rachMessage3StartingPRBIndex. If
this bit is set to 1, then it enforces message3 starting from
PRB8.
Default – 0
Feature N/A
Enb:: Spare9
Parameter Spare9
Value Default=0000 0000 0000 0010 1000 0000 1010 1111 (164015)
0..1: minPuschTBsizeForRelease8and9UE
This parameter controls the minimum PUSCH TB size that can
be assigned to a release 8 or 9 UE. The 2bytes setting
corresponds to no restriction (i.e.(1PRB, MCS0) is allowed).
See 3GPP R2-120802 for the reason of enforcing a minimum
TB size on PUSCH.
mapping is 0--> 2bytes, 1-->4 bytes, 2-->7bytes, 3-->9bytes
Default: 3
2..3: minPuschTBsizeForRelease10UEs
Bit Meaning This parameter controls the minimum PUSCH TB size that can
be assigned to a release 10 UE. The 2bytes setting
corresponds to no restriction (i.e.(1PRB, MCS0) is allowed).
See 3GPP R2-120802 for the reason of enforcing a minimum
TB size on PUSCH.
mapping is 0--> 2bytes, 1-->4 bytes, 2-->7bytes, 3-->9bytes
Default: 3
4: isInterSectorIoTcontrolEnabled
This parameter controls the activation of the intra-EnB inter-
Sector IoT control functionality.
Page 192/308
Default – 0
5..7: interSectorIoTcontrolPeriod
This parameter controls the reporting period of the intra-EnB
inter-Sector IoT control function.
0-->200, 5--> 1000ms step 200ms
default: 1000ms
8..14: interSectorIoTcontrolminCellLoadThr
This parameter controls the minimum traffic load on the cell.
Below that level, all IoT reports sent to other sectors is forced
to the thermal noise level
0, 100 with a step of 1%
Default – 0
Feature N/A
Enb:: Spare15
Parameter Spare15
Class/Source C – New Setups / customer_settable
Value Default=0000 0000 0000 0000 0000 0000 0000 0000 (0)
0: blindPreventiveOffload
This parameter is used to activate/deactivate blind preventive
offloading, i.e. preventive offloading without load information on
the neighbor cell. If set to 1 (True), preventive offload without
any neighbor cell load info is allowed.
The default value is 0, indicating deactivated.
1: isFddTddRedirectionInCoverageMobilityEnabled
This parameter enables/disables FDD<->TDD redirection when
a UE which does not support FDD<->TDD HO receives an
inter-freq measurement report due to radio coverage.
The value 0 implies disabled; the value 1 implies enabled.
The default value is zero.
2: isAutonomousGapsActivationAllowed
This parameter controls the activation of autonomous gaps in
Bit Meaning the UE when ReportCGI measurement is configured for the
purpose of mobility towards HeNB.
- If the value is equal to 1, autnomous gaps are activated when
the UE supports them.
- If the value is equal to 0, autonomous gaps are never
activated, even if the UE supports them.
The default value is 0.
3: isVoIPGBRCapIncreaseEnabled
This parameter controls the use of a hardcoded 1Mbps cap for
QCI1 GBR bearers and the deactivation SPS/ROHC for a GBR
value equal or above a specific value, both introduced by
LR13.1 churn in feature 172164.
If the value is equal to 1, the eNB will assume that the
maximum GBR value for QCI1 bearers is 1Mbps and
SPS/ROHC are deactivated if GBR value equal or higher than
Page 193/308
GBR indicated by eNB Spare 15 bits 4-5.

If the value is equal to 0, the eNB will use parameters
maxGBRforVoIPServiceDl & maxGBRforVoIPServiceUl to
determine the maximum GBR value for QCI1 bearers and will
not deactivate SPS/ROHC based on GBR (as in previous
releases)
4..5: voipGbrThresholdRoHCSpsActivation
This parameter controls the GBR value above which both SPS
& ROHC will be disabled upon call / bearer setup for QCI1.
Possible values are bit5bit4= 00 (25 kbps), 01 (50 kbps), 10 (75
kbps) and 11 (100 kbps).
Bit 24: Rel9 eCSFB:
0: not activated - can be performed
1: activated - cannot be performed
More information about this bit on [Vol. 6].
Feature N/A
LTECell:: Spare4
Parameter Spare4
Value Default=0110 1111 0000 0000 0000 (454656)
11: isMimoStateMachineEnhancementEnabled
This bit controls the activation of MIMO State Machine
Enhancement- This spare is introduced only for upgrade
reasons, to ensure iso-behaviour after the upgrade, expected
to disappear.
Default Value is 0.
12: dlBlerConvergenceImprovementEnabled
This bit controls the activation of DL BLER convergence
improvement
Value 0 implies deactivated; value 1 implies activated.
13: cqiErasureHandlingImprovementEnabled
Bit Meaning
This bit controls the activation of CQI erasure handling
improvement in DLS.
Value 0 implies deactivated; value 1 implies activated.
14..16: lowSECorrThresh
The low SECorr threshold below which the PRB grant size start
to reduce if MCS=0 already, when
spare5:ulLinkAdaptationForMCS0Enabled is set to 1.
The parameter is a 3-bit spare with the logical range of -8, -1dB
and step of 1dB.
The (logical) default value is: -3dB, represented as 5.
17..19: highSECorrThresh
Page 194/308
The high SECorr threshold below which the PRB grant size
starts to recover if MCS remains at 0, when
spare5:ulLinkAdaptationForMCS0Enabled is set to 1.
The parameter is a 3-bit spare with range of 0, 7dB of step of
1dB.
The default value is 1 (dB) represented as 1.
Feature N/A
LTECell:: Spare5
Parameter Spare5
Default=0000 0001 0001 1000 0000 0001 1100 0000
Value
(18350528)
0: isRBAllocationForPCHEnabled
This parameter controls the activation of RB Allocation Type 0
for PCH transmissions on PDSCH (new in LR13).
0 - Disabled (Default); 1- Enabled
1: isRBAllocationForSRB1_2Enabled
for SIB1 and SIB2 transmissions on PDSCH (new in LR13).
2: isRBAllocationForSRB0Enabled
for SIB0 transmissions on PDSCH (new in LR13).
3: isRBAllocationForDBCHEnabled
for D-BCH transmissions on PDSCH (new in LR13).
Bit Meaning 0 - Disabled (Default); 1- Enabled
4: isRBAllocationForTAEnabled
for TA PDSCH transmissions (new in LR13).
5: isSPSReleaseAllocationOnMBSFNAllowed
This parameter controls if SPS release grants are allowed to be
issued on TTI declared as MBSFN (new in LR13). 0 - Disabled
(Default); 1- Enabled
6..8: timeToReleaseDueToEmbmsCollision
This controls the timer that triggers the SPS release in case
pending MBMS configuration is to use the TTI currently booked
for DL SPS (new in LR13).
000 - 0msec, 111 - 140msec (Default), in steps of 20msec
14: isSeCorrUpdateuponHARQFailureEnabled
Enables the Spectral Efficiency Correction to be always
updated in case of HARQ failure in UL
Page 195/308
Boolean: 0 = Disabled and 1= Enabled and Default = 0.

15: forceNkToZeroUponEmptyBOEnabled
Allows to reset GBR token counter to 0 in case of Buffer
Occupancy being zero.
Boolean: 0 = Disabled and 1= Enabled and Default = 0.
22..24: pRBReductionStep
The UL grant size reduction step size triggered by bad SECorr
in MCS=0, when linkAdaptationForMCS0Enabled=1.
The parameter is a 3-bit spare with the logical range 0.2, 1.6
and step size 0.2.
The (logical) default value is: 1.0, represented as 4.
25..27: pRBRecoverStep
The UL grant size recover step size triggered by recovered
SECorr in MCS=0 or recovered MCS, when
linkAdaptationForMCS0Enabled=1.
The parameter is a 3-bit spare with the logical range 0.2, 1.6
and step size of 0.2.
The (logical) default value is: 0.2, represented as 0.
28: linkAdaptationForMCS0Enabled
The activation flag for the enhancement use SE correction to
adjust PRB grant size in MCS0 case.
Value 0 implies disabled; 1 implies enabled.
Feature N/A
LTECell:: Spare6
Parameter Spare6
Class/Source C—Inmmmediate Propagation / system_restricted
Default=0000 0000 0001 0000 0000 0000 0000 0000
Value
(1048576)
23: ssacBarringVoiceStatus
This parameter controls whether SsacBarringForVoiceMMTEL
is included in SIB2 or not.
24: ssacBarringVideoStatus
This parameter controls whether SsacBarringForVideoMMTEL
is included in SIB2 or not.
Bit Meaning 0 - Disabled (Default); 1- Enabled
31: isHOperformanceTestInContentionFree
assiged for HO pefermance test in contention free HO/RA.
Set to 1 for HO performance test in contention free HO/RA
using half LUT. Because half LUT is used, the the maximum
number of UE will be half (<=15 for
uplinkControlChannelLUTindex = 1, <=50 for
uplinkControlChannelLUTindex = 0)
set to 0 for other case.The normal LUT is used.
Page 196/308
This spare can be set to 1 only when

uplinkControlChannelLUTindex = 1/0.
set default to 0, set to 1 by tester if needed.
Feature N/A
LTECell:: Spare7
Parameter Spare7
Default=0000 0111 0000 0000 0000 1000 0000 0000
Value
(117442560)
22: isOtdoaCompatibleNeighborWithoutPrs
This parameter enables the MCO Metro eNodeB to be
excluded from participation in OTDOA (Observed Time
Difference Of Arrival) position location. When Enabled, the
eNodeB is made compatible with OTDOA position location
enabled on other eNodeBs in the vicinity by modifying downlink
Bit Meaning scheduling in this eNodeB to not interfere with Positioning
Reference Signals (PRS) transmissions of nearby cells
(assuming all are configured with the same PRS configuration).
0: Disabled (default – restriction to be set to false on macro
eNB)
1: Enabled
Feature N/A
LTECell:: Spare9
Parameter Spare9
Value Default=0000 0000 0000 0000 0010 0100 0000 0000 (9216)
16..20: OneXRttMobilityParameters- bandClass:
This parameter specifies the BAND_CLASS included in RRC
CSFBParametersResponseCDMA2000 message for power-up
Bit Meaning registration determination. Possible values are 0-21(Dec)
corresponding to BC0-BC21 (defined in TS 36.331) and
31(Dec) corresponding to BC31(wildcard band class) defined in
3GPP2 C.S0057-E v1.0.
Feature N/A
Page 197/308
11 UE POSITION LOCATION SUPPORT

The strongest driver for determining UE position is a regulatory requirement for
position location for VoIP calls to emergency numbers (E911) in the United
States. In the following text, the location techniques will be described, and then
the features that support UE position location will be summarized in a later
section.
Two different location techniques are supported – Observed Time Difference of

Arrival (OTDOA) and Enhanced Cell Identification (ECID). These two different
techniques are described in the following sections. Note that both Control Plane
and User Plane are supported. Both LPP (LTE Positioning Protocol) and LPPa
interfaces are supported.
Restriction: UE Position Location Support
If a Distributed Antenna System (DAS) is used in which multiple antennas are

distributed across a geographic area, then the OTDOA and ECID methods
cannot be used to properly determine a UE location (because of uncertainty
about the actual delay to the antenna and about position of the antenna). The
location server should not use UE measurements of a cell that utilizes multiple
distributed antennas.
Parameter settings that should be used with a DAS are described in this volume.
11.1 SIMPLIFIED LOCATION ARCHITECTURE
The principal elements for UE position location support are illustrated in Figure
49.
Serving MME
eNB
LPP
LPPa
Integrated eSMLC/SLP
(Location Server)
SAM
Base Station
Almanac (BSA) Data
Figure 49 : Principal Elements for UE Position Location Support
Page 198/308
The LPP messages between the UE and the location server pass transparently
through the eNB and the MME. Support for carrying LPPa messages between the
eNB and the eSMLC is also provided.
Base Station Almanac (BSA) data (discussed later) may be provided to the
location server from SAM. Data provided by the UE and BSA data provided by
SAM are used by the location server to estimate the UE position.
11.2 FEATURE L114572/L114572.1 - ENB SYNCHRONIZATION

SUPPORT FOR OTDOA FOR COMMERCIAL DEPLOYMENT
This feature allows all eNBs within the eUTRAN to be synchronized to within 100
nanoseconds of GPS time, so that transmission frames from all cells are
synchronized at their respective transmit antennas in phase, time, and System
Frame Number (SFN). The synchronized signals are required to support the
Observed Time Difference of Arrival (OTDOA) method of UE location. When this
feature is enabled, the cell is capable of supporting OTDOA using the Positioning
Reference Signal (PRS) added by feature L101821/L101821.1.
OTDOA depends on the characteristics of synchronized (at the respective

antennas) positioning reference signals (PRS) that a UE receives from multiple
eNodeBs Figure 50 illustrates the concept of a UE that measures the OTDOA of
downlink PRSs from multiple eNBs. These measurements are known as RSTD
(Reference Signal Time Difference). Feature L115435.1 provide the usage of
PRS (Positioning Reference Signals). Use of PRS is expected to provide much
more effective performance. Using the OTDOA measurements, a set of hyperbola
equations can be formulated at the location server, and the UE’s position can be
estimated by finding the area of intersection of the hyperbolas.
The major factors that will affect OTDOA accuracy are as follows:
• The eNode B synchronization error. The eNodeB clocks are all
synchronized with GPS such that all eNB are referenced to the same
global timing. However, there will still be errors among different eNBs due
to delays caused by components between the GPS antenna and the
radio antenna (see Figure 51 for a high level view). Those delays are not
constant across eNBs due to varying cable lengths and additional
external antenna equipment. Consequently, the total delay between the
GPS antenna and the radio antenna must be compensated by adjusting
the System Frame Number (SFN) start at the cell modem.
• Accuracy of cell antenna position information at the location server:
Location server uses cell antenna positions (latitude, longitude, altitude)
to calculate the hyperbolas.
• Multi-path effect. This will cause a timing-offset in measuring the
OTDOA at the UE. Unlike CDMA where Rake receivers are used to
detect the first arrival of a significant multipath component, the detection
of OFDMA symbols does not involve differentiation of multipath
components. Consequently, the arrival time of the Downlink (DL) RS is
dependent on the detection algorithm implemented by the UE.
• Sensitivity of UE. The HW/SW design at the UE governs the sensitivity,
which is critical to detect weak signals with low SINR.
Page 199/308
• Other factors include measurement-reporting-resolution Ts, which is

32ns for 20 MHz BW, and UE clock error. Both of which are considered
as minor errors compared to the other errors that have been described.
Figure 50 : Illustration of UE measuring the SFNs synched among eNBs
Multipath effects and UE sensitivity are challenges at the UE receiver side and
therefore must be handled by UE vendors. However, the eNB synchronization is a
challenge at the transmitter side to be handled by the ALU eNB. The approach
taken by feature L114572/L114572.1 to eNB synchronization is to synchronize the
System Frame Number (SFN) boundary across eNBs such that a UE can
measure the OTDOA directly (without calibration). This approach implies that the
total delay between the GPS antenna and the RF antenna, as illustrated in Figure
51, will be compensated by adjusting the SFN start at the cell modem. Note that
GPS timing must be used with the OTDOA location method – 1588 timing and
Synchronous Ethernet timing do not provide sufficient accuracy for the OTDOA
location method to work.
RF Antenna
GPS Antenna Ant Eqpt,

e.g., TMA 3
2
Modem RRH
BBU
Figure 51 : External Delays to be compensated for OTDOA Synchronization
Page 200/308
In Figure 51 it is represented the different delays and compensations of the

default configuration. Correspondent items 1 and 3 need to be manually
calibrated by operator (Item 1- positioningSystemAntennaCableDelay and item
3 both AntennaPort::antennaPathDelayDL and
AntennaPort::antennaPathDelayUL), whereas item 2 is automatically calibrated
by the eNB.
The principal objectives of Feature L114572/L114572.1 are to

• achieve 100ns sync accuracy to GPS, including compensation for the
total delay at the cell modem by adjusting the System Frame Number
(SFN) start time,
• to slave the SFN boundary to the Global Positioning System (GPS) timing
at eNB initialization,
• to track phase-synchronization during normal operation,
• to re-gain phase-synchronization after loss of and reacquiring GPS
signals,
• to provide configuration parameters that allow manual calibration of cable
delays, and to turn off PRS and raise an alarm when GPS timing required
for OTDOA is lost.
Feature L114572/L114572.1, eNB Synchronization support for OTDOA is

activated by setting the value of parameter isGeoLocPhaseSyncAllowed to
True.
This optional feature is managed by Feature Licensing (refer to LPUG [Vol. 1] for
details). This parameter can be set to 'True' only if licensing (Tokens) are
available for the feature. The total number of activations for each feature is
counted across all eNBs by SAM.
ActivationService::isGeoLocPhaseSyncAllowed
Parameter isGeoLocPhaseSyncAllowed
True/False
Class/Category A--full-eNB-reset / system_restricted
Feature L114572
Page 201/308
Rule: isGeoLocPhaseSyncAllowed Parameter
If the value of the isGeoLocPhaseSyncAllowed parameter is set equal to True,

then the following parameter settings must also be used:
• clockSyncSourcePriorityList first entry must be gps-synchronized-gps
• gpsClockEnable equals True
• gpsModeSelect equals either Managed Internal GPS receiver, or

Managed External GPS receiver
• sfnSyncOption equals FreqAndPhaseAndTimeOfDaySyncEnabled
• PositioningSystem and GeoLocPhaseSync objects must be created
Refer to Vol 2 paragraph 6 for more details
In addition, when the isGeoLocPhaseSyncAllowed parameter is set equal to
True, then the following parameter values must be set accurately to allow the
proper timing relationships to be determined among the GPS antenna, the cell’s
modem unit, and the cell’s RF antennas:
 antennaPathDelayDL;
 antennaPathDelayUL;
 positioningSystemAntennaCableDelay.
Refer to Vol 2 paragraph 4 for more details
Finally, when the isGeoLocPhaseSyncAllowed parameter is set equal to True,
and if the cell antenna position data is to be supplied to SAM for availability to a
location server, then the mainAntennaPosition parameters must also be
properly populated using the parameters that are described in that Section.
11.3 FEATURES L101821/L101821.1– USER PLANE AND

CONTROL PLANE OTDOA WITH HEARABILITY SUPPORT
FOR COMMERCIAL DEPLOYMENT
Features L101821(for the bCEM hardware) and L101821.1 (for the eCEM
hardware) – User plane and control plane OTDOA with hearability support for
Commercial deployment build on the LA4.0 capability provided by Feature
L115435.1 (eNB support of OTDOA Hearability Enhancement (Trial )).
Features L101821 and L101821.1implements Position Reference Signal which is

needed for OTDOA location method to be effective. The capabilities provided by
this feature are:
• Support of Positioning Reference Signal (PRS) and its Downlink
scheduling.
• Support OAM configuration of PRS in terms of on/off, periodicity, width
and length.
• Support transmission of PRS configuration via LPPa on request by
eSMLC
• Extend BSA data to include PRS configuration information and support
sending it via SAM to eSMLC.
Page 202/308
Feature L115435.1 provides support for the addition of Position Reference

Signals (PRS) to the LTE cell downlink. The presence of these signals in the
downlink improves the ability of the UE to collect timing information from multiple
cells and to determine the differences in frame arrival times from multiple cells.
Enabling this feature significantly improves the likelihood that the OTDOA location
technique will work. Features L101821 and L101821.1 improve these capabilities
and add the capability to communicate OTDOA-related information between the
eNB and the location server. PRS enables better hearability of cells for OTDOA,
which requires the UE to hear a minimum of 3 cells up to 6 cells.
Note that the OTDOA geolocation feature (both basic and with hearability
support) requires knowledge of antenna node position and of the antenna-to-
modem delay. Therefore:
• If DAS HW is used to distribute the coverage of a cell to smaller coverage
areas, OTDOA should not be used for the cell (i.e. the location server
should not use OTDOA data from UEs that are served by the cell),
because it is not possible to define one antenna (node) position (since
there are several of them).
• If DAS HW is used as fiber transport with fiber delay exceeding 75000ns,
OTDOA should not be used (i.e. the feature should be deactivated) as
the actual antenna path delay is not known.
• If DAS HW is used as a fiber transport with cabling delay not exceeding
75000ns or if DAS HW is not used and the cabling delay does not exceed
75000ns, OTDOA can be used.
Note if OTDOA is used or is planned to be used in the future, the Antenna Path
Delay should be entered with an accuracy of +/-50ns as opposed to +/-125ns.
ActivationService::isOtdoaHearabilityEnhancementAllowed, This parameter

enables OTDOA hearability enhancement, by transmission of Positioning
Reference Signals in the cells.
ActivationService::isOtdoaHearabilityEnhancementAllowed
Parameter isOtdoaHearabilityEnhancementAllowed
True/False
Class/Category C--Immediate-propagation / customer_settable
Value O.D. (ALU Default: False)
Feature L115435
The use of the OTDOA with Hearability Support capability is a licensed feature
and is linked to PRS scheduling (see [Vol. 4] for additional detail.
Page 203/308
11.4 OBSERVED TIME DIFFERENCE OF ARRIVAL (OTDOA)

OTDOA depends on the characteristics of synchronized DL reference signals
(RS) that a UE receives from multiple eNodeBs. Figure 1 illustrates the concept of
a UE that measures the OTDOA of downlink RSs from multiple eNBs. Using the
OTDOA measurements, a set of hyperbola equations can be formulated in the
location server, and the UE’s position can be estimated by finding the area of
intersection of the hyperbolas. Position Reference Signals (PRS) is used for UE
measurements, See [Vol. 4] for additional information concerning PRS.
Note that with OTDOA, the UE measurements are transmitted to the location
server using the LPP (described later) that passes through the eNB and the
MME, but is transparent to them.
Important capabilities for the eUTRAN to support for this location method include:
• Cell downlink transmissions are synchronized across cells at their
respective antennas
• RF antenna positions are accurately known
• Path is available to carry UE measured data to the location server
(eNB supports transport of LPP messages between UE and location
server)
• Reference Signal configuration is known by the location server
Figure 52 : Illustration of UE measuring RSs that are synchronized among

eNBs
Page 204/308
LR13.3L OTDOA is supported on Metro Cell Outdoor (MCO)
Via feature 170733 intoduces in LR13.3, OTDOA is supported on MCO Metro.

This feature provides parity on the MCO Metro with the macro ENB.
OTDOA is not supported on MRO in this release. To avoid causing PRS
interference to neighboring MCOs or macro cells, feature 170733 provides
OTDOA PRS interference avoidance on MRO (Metro Radio Outdoor). This
feature is activated by enabling OTDOA and setting prsPowerOffset to a large
negative value.
11.5 POSITIONING SYSTEM PARAMETERS [L103896] AND

RELATED FEATURES
The eNodeB position can be entered manually or can be read from a Global
Positioning System receiver that is intenal to the eNodeB.
The positioning system location uses units of the World Geodetic System 84
(WGS84) standard, which is used in cartography and navigation. WGS84
comprises a standard coordinate frame for the Earth, a standard spheroidal
reference surface (the datum or reference ellipsoid) for raw altitude data, and a
gravitational equipotential surface (the geoid) that defines the nominal sea level.
This is the same coordinate system that is used by the Global Positioning System
(GPS), and the latitude and longitude values that are read from a GPS will be
referenced to the WGS84 standard.
11.5.1 POSITIONING OF ENB COMPONENTS

In the following paragraph we will describe parameters involved in the positioning
of three ENB components:
• GPS antenna position per ENB

• RF antenna position per cell
• BBU position per eNodeB
Page 205/308
11.5.1.1 GPS ANTENNA POSITION PER ENB
Following parameters refer to GPS position per each eNB.
PositioningSystem::gpsAntennaPositionLongitude
Parameter gpsAntennaPositionLongitude
Object PositioningSystem
Range & Unit Float, degree
[-180…+180], step = 0.00001 deg
Class/Category N.A.
Value Default = 0
Feature L103896
This parameter provides the longitude of the GPS antenna in the WGS84
reference frame. Its value is automatically generated by the eNodeB. Encoding is
defined as follows: < 0: west prime meridian; = 0: at prime meridian; > 0: east of
prime meridian.
PositioningSystem::gpsAntennaPositionLatitude
Parameter gpsAntennaPositionLatitude
[-90…+90], step = 0.00001 deg
Class/Category N.A.
Value Default = 0
Feature L103896
This parameter provides the latitude of the GPS antenna in the WGS84 reference
frame. Its value is automatically generated by the eNodeB.
Encoding is defined as follows: < 0: south of the equator; = 0: at the equator; > 0:
north of the equator.
PositioningSystem::gpsAntennaPositionAltitude
Parameter gpsAntennaPositionAltitude
Range & Unit Integer, meter
[-1000…+1000], step = 1 meter
Class/Category N.A.
Value Default = 0
Feature L103896
Page 206/308
This parameter provides the altitude of the GPS antenna in the WGS84 reference
frame. Its value is automatically generated by the eNodeB.
Encoding is defined as follows: < 0: below sea level; = 0: at sea level; > 0: above
sea level.
Rule: gpsAntennaPosition
The value is interpreted as unset if {gpsAntennaPositionLatitude,

gpsAntennaPositionLongitude, gpsAntennaPositionAltitude} = {0,0,0}.
11.5.1.2 RF ANTENNA POSITION PER CELL
The following parameters represent LTE cell (RRH) position and correspond to
LPPa Access Point Position. The position is derived from computed or configured
position.
This parameter is part of Base Station Almanac information and is sent to User
Plane location server to assist OTDOA/ECID positioning.
LteCell::mainAntennaPositionLongitude
Parameter mainAntennaPositionLongitude
[-180 ... +180], step = 0.00001 deg
Value N.A.
Feature L103896
This parameter reports the altitude of the main antenna in a cell in the WGS84
reference frame. Refer to mainAntennaPositionSource for source of the value.
Encoding is defined as follows:
< 0: west prime meridian; = 0: at prime meridian; > 0: east of prime meridian.
Page 207/308
LteCell::mainAntennaPositionLatitude
Parameter mainAntennaPositionLatitude
[-90 ... +90], step = 0.00001 deg
Value N.A.
Feature L103896
< 0 - Indicates below sea level; = 0 - Indicates at sea level; > 0 - Indicates above
sea level.
LteCell::mainAntennaPositionAltitude
Parameter mainAntennaPositionAltitude
[-1000…+1000], step = 1 meter
Value N.A.
Feature L103896

sea level.
Rule:
When there are multiple antennas in a cell, the coordinates are those of the
main antenna (which transmits CRS/PRS)
Rule: mainAntennaPosition
The set of values {mainAntennaPositionLatitude,

mainAntennaPositionLongitude, mainAntennaPositionAltitude} = {0,0,0}
means the position is invalid.
Page 208/308
11.5.1.3 BBU POSITION PER ENODEB
The following parameters are used for administrative purpose and they are not
used for OTDOA/ECID.
The position is derived from computed or configured position.
ENBEquipment::bbuPositionLongitude
Parameter bbuPositionLongitude
Object ENBEquipment
[-180 ... +180], step = 0.00001 deg
Class/Category N.A.
Value N.A.
Feature L103896
reference frame. Refer to bbuPositionSource for source of the value.

< 0: west prime meridian; = 0: at prime meridian; > 0: east of prime meridian.
ENBEquipment::bbuPositionLatitude
Parameter bbuPositionLatitude
Object ENBEquipment
[-90 ... +90], step = 0.00001 deg
Class/Category N.A.
Value N.A.
Feature L103896
sea level.
Page 209/308
ENBEquipment::bbuPositionAltitude
Parameter bbuPositionAltitude
Object ENBEquipment
[-1000…+1000], step = 1 meter
Class/Category N.A.
Value N.A.
Feature L103896
sea level.
Rule: bbuPosition
The set of values {bbuPositionLatitude, bbuPositionLongitude,

bbuPositionAltitude} = {0,0,0} means the position is invalid.
11.5.1.4 CONFIGURED OR COMPUTED, 2 DIFFERENT

SOURCES:
As defined previously, Cell RF antenna and BBU coordinates are determined from
one of 2 possible sources: Configured or Computed.
BBU/MainAntenna
Position Delta
Compute
BBU/MainAntenna
GPS Antenna Position
Position mainAntennaPositionSource/
bbuPositionSource = Computed
Use Computed for
BBU/MainAntenna
Externally
N MainAntenna/BBU Position
Position
Configured?
Externally OSS
Configured
Y
mainAntennaPositionSource/
bbuPositionSource = Configured
Use Configured for
BBU/MainAntenna Position
Page 210/308
Configured: operator directly enters BBU/cell RF antenna position

(bbuConfiguredPosition/mainAntennaConfiguredPosition)
• This is the best option when GPS antenna and BBU/cell RF antenna are
not co-located
• Cell RF antenna position should be accurate to within 10m in the
horizontal plane (lat/long)
ENBEquipment::bbuConfiguredPositionLongitude
Parameter bbuConfiguredPositionLongitude
Object ENBEquipment
[-180 ... +180], step = 0.00001 deg
Value N.A.
Feature L103896
ENBEquipment::bbuConfiguredPositionLatitude
Parameter bbuConfiguredPositionLatitude
Object ENBEquipment
[-90 ... +90], step = 0.00001 deg
Class/Category N.A.
Value N.A.
Feature L103896
ENBEquipment::bbuConfiguredPositionAltitude
Parameter bbuConfiguredPositionAltitude
Object ENBEquipment
[-1000…+1000], step = 1 meter
Class/Category N.A.
Value N.A.
Feature L103896
Rule: bbuConfiguredPosition
Parameters are entered by a field operator.

The set of values {bbuConfiguredPositionLatitude,
bbuConfiguredPositionLongitude, bbuConfiguredPositionAltitude} = {0,0,0}
mean the position is invalid (no value entered by the operator).
Page 211/308
LteCell::mainAntennaConfiguredPositionLongitude
Parameter mainAntennaConfiguredPositionLongitude
[-180 ... +180], step = 0.00001 deg
Class/Category N.A.
Value N.A.
Feature L103896
LteCell::mainAntennaConfiguredPositionLatitude
Parameter mainAntennaConfiguredPositionLatitude
[-90 ... +90], step = 0.00001 deg
Class/Category N.A. / customer_settable
Value N.A.
Feature L103896
LteCell::mainAntennaConfiguredPositionAltitude
Parameter mainAntennaConfiguredPositionAltitude
[-1000…+1000], step = 1 meter
Class/Category N.A.
Value N.A.
Feature L103896
Rule: mainAntennaConfiguredPosition
Parameters are entered by a field operator.

The set of values {mainAntennaConfiguredPositionLatitude,
mainAntennaConfiguredPositionLongitude,
mainAntennaConfiguredPositionAltitude} = {0,0,0} mean the position is
invalid (no value entered by the operator).
Computed from eNodeB’s GPS: operator enters offset between GPS antenna
and BBU/cell RF antenna (bbuPositionDeltaX, bbuPositionDeltaY,
Page 212/308
bbuPositionDeltaZ / mainAntennaPositionDeltaX, mainAntennaPositionDeltaY,

mainAntennaPositionDeltaZ)
• This is the best option when GPS antenna and BBU/cell RF antenna are
co-located (no delta)
• GPS must be equipped in order to use automatically computed positions
for RF antennas and BBU
•
LteCell::mainAntennaPositionDeltaX
Parameter mainAntennaPositionDeltaX
[-1000…+10000], step = 1 meter
Value Default = 0
Feature L103896
LteCell::mainAntennaPositionDeltaY
Parameter mainAntennaPositionDeltaY
[-1000…+10000], step = 1 meter
Value Default = 0
Feature L103896
LteCell::mainAntennaPositionDeltaZ
Parameter mainAntennaPositionDeltaZ
[-1000…+10000], step = 1 meter
Value Default = 0
Feature L103896
Page 213/308
ENBEquipment::bbuPositionDeltaX
Parameter bbuPositionDeltaX
Object ENBEquipment
[-1000…+10000], step = 1 meter
Value Default = 0
Feature L103896
ENBEquipment::bbuPositionDeltaY
Parameter bbuPositionDeltaY
Object ENBEquipment
[-1000…+10000], step = 1 meter
Value Default = 0
Feature L103896
ENBEquipment::bbuPositionDeltaZ
Parameter bbuPositionDeltaZ
Object ENBEquipment
[-1000…+10000], step = 1 meter
Value Default = 0
Feature L103896
For computed BBU / Access Point Position, Position Delta defines the difference
between GPS antenna position and main antenna position so eNodeB can
compute the cell’s position. If not corrected, difference introduces error in UE
position calculation.
Customer responsible for entering Position Delta
• mainAntennaPositionDeltaX,
• mainAntennaPositionDeltaY,
• mainAntennaPositionDeltaZ
• bbuPositionDeltaX,
• bbuPositionDeltaY,
• bbuPositionDeltaZ
Page 214/308
To avoid this complication and not compromise OTDOA/ECID accuracy,

don’t use computed position if the distance from GPS antenna to cell
antenna is more than 9 meters. Instead,
enter configured position with an accuracy of 10 meters in the horizontal
plane.
Rule:
These parameters (DeltaX, DeltaY, DeltaZ) use Earth Centered, Earth Fixed
(ECEF) absolute coordinate system.
From center of the earth: X, Y define the equatorial plane, X axis points to
longitude=0, Y axis points to longitude=90, Z axis points to the north pole.
These thresholds bbuPositionErrorThreshold and

mainAntennaPositionErrorThreshold are used to check BBU position and RF
antenna position. They are preformed upon eNodeB reset, gpsAntennaPosition
received from Platform, and any Delta or ConfiguredPosition values changed.
ENBEquipment::bbuPositionErrorThreshold indicates the threshold used to

compare the automatically generated coordinates for the BBU versus the
coordinates entered by a field operator with an external GPS device.
Parameter bbuPositionErrorThreshold
Object ENBEquipment
[0…30], step = 1 meter
Value Default = 20
Feature L103896
LteCell::mainAntennaPositionErrorThreshold indicates the threshold used to

compare the automatically generated coordinates for the main RF antenna
coordinates entered by a field operator with an external GPS device.
Page 215/308
Parameter mainAntennaPositionErrorThreshold
[0…30], step = 1 meter
Value Default = 10
Feature L103896
Rule: bbuPositionErrorThreshold and mainAntennaPositionErrorThreshold
A warning is raised if:

• Difference between computed position and configured position exceeds
threshold
• Difference between old position and new position exceeds threshold
• Position is removed (changed to 0,0,0)
11.6 ENHANCED CELL IDENTIFICATION (ECID) LOCATION

METHOD AND LPP/LPPA LOCATION CONTROL PLANE
PROTOCOL SUPPORT
With the ECID method of location, the UE measures round trip delay (RTD) to the
serving cell and to neighbor cells. The UE provides the resulting data to the
location server which uses the data to compute UE location.
Important eUTRAN capabilities to support this location method include:

• RF antenna positions are accurately known
• Path is available to carry UE measured data to the location server
(eNB supports transport of LPP messages between UE and location
server)
• RF antenna orientation known to location server
• Delay between the antenna and the modem card within the eNB is
known to the location server, since it must be subtracted from the UE-
reported RTD to determine distance from the antenna to the UE.
Features L103896 (bCEM hardware support) and L103896.1 (eCEM hardware

support), ECID location method and LPP/LPPa location control plane protocol
support for Commercial Deployment, build on the LA4.0 capability to support the
transparent transport through the eNB of LTE Positioning Protocol (LPP)
messages that pass between the UE and the location server.
The eCEM modem also supports transport of LPPa messages to enable reporting
of Timing Advance Type 1 to the eSMLC location server (see TS 36.455).
Equivalent support for the bCEM modem is added in a later release.
Page 216/308
The Enhanced Cell Identification (ECID) location method is also supported. As

part of the ECID support, the eUTRAN provides:
• Ability to provide accurate location (latitude, longitude, altitude) for
each cell’s antenna. GPS antenna location and BBU location are also
provided by the feature, but are not used in the ECID location method.
• Correction factor to remove modem to antenna delays (value of the
correctionForTadvType1 parameter). This correction factor is
provided to the evolved Serving Mobile Location Center (eSMLC) so it
can use UE-provided data to derive Over-The-Air (OTA) Round-Trip-
Delay (RTD).
• Calibrated Timing Advance (i.e., not including eNB hardware delays)
recorded by PCMD at call beginning and call end for use by Network
Performance Optimizer
In general, ECID is considered to be a supplementary capability to be used when

OTDOA or AGPS (Assisted GPS, a UE based capability) results are not
available, because of a harsh RAN RF environment.
The ECID capability is a licensed feature. Additional information throughout this

volume.
To support the ECID capability (but not part ot the RAN features), SAM also
provides data to the location server concerning each eNB and cell. This data is
called the Base Station Almanac, and includes:
Enb::macroEnbId
LteCell::relativeCellIdentity
CpriRadioEquipment::mainAntennaPositionLatitude
CpriRadioEquipment::mainAntennaPositionLongitude
CpriRadioEquipment::mainAntennaPositionAltitude
CpriRadioEquipment::mainAntennaPositionSource
LteCell::azimuth
LteCell::cellRadius
LteCell::correctionForTadvType1
Note that the ECID geolocation feature requires knowledge of antenna node
position and of the antenna-to-modem delay. Therefore,
areas, ECID should not be used for the cell (i.e. the location server
should not use OTDOA data from UEs that are served by the cell),
because it is not possible to define one antenna (node) position (since
there are several of them).
• If DAS HW is used as fiber transport with fiber delay exceeding 75000ns,
ECID should not be used (i.e. the feature should be deactivated) as the
actual antenna path delay is not known.
• If DAS HW is used as a fiber transport with cabling delay not exceeding
75000ns or if DAS HW is not used and the cabling delay does not exceed
75000ns, ECID can be used.
Features L103896 and L103896.1 provide support for the LPPa interface. The
LPPa interface is used to pass the ECID measurements and a subset of the full
eNB BSA data to the location server (eSMLC) in the Control Plane. In addition,
the eNB uses RRC signaling (to get UE measurements) and internally estimates
the round trip delay defined in TS36.214, TadvType1 = (eNB Rx-Tx time
difference) + (UE Rx-Tx time difference). LPPa only supports transfer of RF
antenna coordinates and PRS (Position Reference Signal) configuration
information. The LPPa interface is activated using a configuration parameter. If
the LPPa interface is activated, then it will be used to supply the subset of BSA
data listed above to the location server. Otherwise the BSA data will be extracted
from SAM and provided to the location server using a proprietary interface.
Page 217/308
Note that the LPPa interface can be enabled to support either OTDOA, or ECID,
or both capabilities, and the use of the LPPa interface itself does not require a
separate license. The ability to use the LPPa interface is included in the license
for the OTDOA capability or the ECID capability.
11.6.1 ENHANCED CELL ID (ECID) LOCATION FEATURE

[L103895.1] & LPP/LPPA LOCATION CONTROL
PLANE [L103896, L103896.1]
isEcidSupportAllowed : This flag enables or disables the feature for ECID
support at the level of eNB.
ActivationService::isEcidSupportAllowed
Parameter isEcidSupportAllowed
[False,True]
Feature L103895.1
isLPPaInterfaceAllowed enables or disables the LPPa support in the eNB.
In order to allow service providers to choose either OAM approach or LPPa

approach for transferring of BSA data, a control flag for LPPa is introduced.[
isLPPaInterfaceAllowed ] In other words, the OAM approach is the default and
the LPPa approach is an option.
ActivationService::isLPPaInterfaceAllowed
Parameter isLPPaInterfaceAllowed
[False,True]
Feature L103896
11.6.2 OVERVIEW
[L103895.1]
The main input to ECID are RSRP/RSRQ reported by UE and the round trip
delay value, termed timing advance (TA) in LTE. The latter is to be used to
calculate the distance between the UE and the radio antenna. Consequently
the over-the-air delay needs to be derived from the TA value by removing the
transmitting/receiving (Tx/Rx) delays at eNB and the Rx/Tx delays at UE. The
Page 218/308
resulting TA value, termed TADV type 1 in TS36.214, will be provided by this

feature.
In order to calculate UE’s position by ECID, the coordinates of the radio
antenna have to be provided. Additionally, the number of sectors in an eNB, the
beam orientations and the transmitting powers can also be used to improve the
positioning accuracy. Those eNB related parameters are termed “Base Station
Almanac”. This feature will make base station almanac available to OAM such
that a location server can extract the data. The feature will also send
coordinates of the radio antenna to eSMLC via LPPa (L103896 ) according to
TS36.455, once the GPS automatically reported its coordinates and the internal
SW (to be developed at OAM) corrected offset (between the GPS antenna and
the radio antennas) entered by field engineer through configuration parameters.
Note that TS36.455 LPPa only support “pulling” part of the base station almanac
data defined in the OAM requirements.
LPP is a protocol between eSMLC and UE to allow exchange assistance data and
measurements for UE positioning. It is transparent to eNB. Lppa is a protocol
between eSMLC and eNB to allow eNB to provide TADV, coordinates of radio
antenna. LPPa also supports OTDOA Information Exchange, including certain
configuration parameters of position reference signal (PRS), which is to be
implemented by L115435, a trial feature in LA4.0.
[L103896]
This feature provides enhancement of eNB’s support of ECID, required by all
service providers in NAR to be a supplementary location technology to AGPS and
OTDOA when none of the two are working in a harsh environment. ECID is not
only used in emergency service but also in commercial location based services
(LBS).
This feature is an enabler of Location Based Service. It allows ECID to be
supported in Control Plane over LPP, Control Plane over LPPa, and User
Plane over LPP. Although ECID does not provide high positioning accuracy as
AGPS, normally < 20m in open field, and DL OTDOA, expected to be 100m –
300m, it is a positioning technology that always works, as long as a UE can make
a connection to the network.
ECID can also be used to obtain position information from all active UEs. Unlike
AGPS and DL OTDOA, it is possible for eNB to get all the information needed to
do ECID position calculation.
This feature adds ECID in Control Plane over LPPa where LPPa interface is used
to pass the ECID measurements and eNB BSA data to the location server eSMLC
in Control Plane. Additionally, this feature will add RRC signaling (to get UE
measurements) and callP-modem interaction to estimate the round trip delay
defined in TS36.214, TadvType1 = (eNB Rx-Tx time difference) + (UE Rx-Tx time
difference). It should be noted that current IEs in LPPa only allow transfer of RF
antenna coordinates and PRS (Position Reference Signal) configuration
information.
Page 219/308
Due to the customer request, this feature will enhance the ECID in User Plane by
making available the extended BSA data via OAM to SLP. If SLP and eSMLC are
on an integrated platform, the extended BSA data can be used by both User
Plane and Control Plane geolocation solutions. In order to allow service
providers to choose either OAM approach or LPPa approach for
transferring of BSA data, a control flag for LPPa is introduced.[
isLPPaInterfaceAllowed ] In other words, the OAM approach is the default and
the LPPa approach is an option.
eSMLC (Serving Mobile Location Center) => Control Plane
SLP (SUPL Location Platform) => User Plane
11.6.3 PROPOSED NETWORK ARCHITECTURE

This feature will impact modem, CallP and OAM. To support ECID calculation at
eSMLC, CallP needs to obtain measurements from modem as well as from UE in
order to get an estimate of over-the-air round trip delay, and then send the
estimate to eSMLC over LPPa interface.
– CallP: Support procedures and relevant IEs specified in LPPa (TS36.455).

– CallP: Handle ECID measurement request (on demand); inform via a specific
cause when the request cannot be processed due to e.g. non-supported eNB
capability, interaction with mobility, and so forth.
– Modem: Provide (eNB Rx-Tx time difference) to CallP
– CallP: Obtain (UE Rx-Tx time difference) on serving cell and RSRQ/RSRP of
measured neighbour cells from UE by RRC MeasResults field, described in
TS36.331, and process both eNB and UE measurements to get TADV Type 1
specified in TS36.214 as follows:
TADV Type 1 = (eNB Rx-Tx time difference) + (UE Rx-Tx time difference)
– OAM : to provide extended base station almanac (BSA) to SAM to satisfy

request a major customer for User Plane and/or Control Plane E911/LBS.
Page 220/308
CallP/Geolocation
-Handles LPPa - Provide phase-sync
-Collection of (UE Rx-Tx TD) from UE - PRS coding and config
and (eNB Rx-Tx TD) from modem, - Modem provides (eNB Rx-Tx
- Provide extended BSA data then Calculates TadvType1 TD) to CallP/Geolocation
to support User Plane
geolocation GPS Sync
SAM
- RRC obtain (UE Rx-Tx TD) - Support PRS scheduling and
from UE eNB transmission for hearability
OAM enhancement for OTDOA
Modem
•UE•
DL- eSMLC
• CallP Geolocation Scheduler
LPPa
- CallP/Geolocation provide
-Provide transmitting delay measurement and assistance
inside of eNB for phase-sync Platform data for ECID/OTDOA
– Provide transmitting delay calculation at eSMLC
and receiving delay for
calibratition of TA value
Figure 53 : eNB architecture to support OTDOA & ECID. In red are the feature
tasks.
Note for diagram above: The text in red indicates the tasks to be fulfilled in
the feature L103896.
This feature provides support for following multiple tasks:

– E-SMLC getting ECID measurements as well as defined BSA data (mainly RF
antenna coordinates) from eNB through LPPa interface.
– E-SMLC getting OTDOA assistance data from eNB, which is to be covered
by L101821 in LA5.0.
– E-SMLC getting AGPS measurements as well as OTDOA measurements
from UE over LPP, and at the same time provides AGPS/OTDOA assistance data
to UE. Note that LPP is between eSMLC and UE, which is transparent to eNB.
11.6.4 SYSTEM CALL FLOWS

The following call flow shows end to end call flow for location determination in
Control Plane. Although there are many network elements involved in this call
flow, only eNB, its OAM and the LPPa interface between the eNB and an eSMLC
are relevant to the feature L103896.
Page 221/308
UE eNB MME SGW PGW P-CSCF E-CSCF e-SMLC GMLC SLP LRF MGC/MGCP PSAP
0. Base Station Almanac data sent to eSMLC via OAM and/or LPPa
1. Emergency VoIP call established with PSAP

•2. Location Request
•3. Loc. Request

•4. Loc. Request
•5. Loc. Request
•6. LPPa: E-CID MEASUREMENT INITIATION REQUEST
•7. LPPa: E-CID MEASUREMENT INITIATION RESPONSE
•8. Loc. Response (loc. Data))

•9. Loc. Response (loc. Data))
•10. Loc. Response (loc. Data)
•11. Location Response (loc. Data)
•12. LPP: Capability Transfer
•13. LPP: Assistance Data Transfer:
•14. LPP: Location Information Transfer:
•15. Loc. Response Update (loc. Data))

•18. Location Response Update (loc. Data)
Figure 54 : Call flow for emergency call in Control Plane.
Note that Step 0, step 6 and 7 are relevant to the feature L103896, and the
sequence numbers are for reference only which does not represent necessarilly
the time sequence in implementation.
11.6.5 PARAMETERS FOR L103896

The following two MIM parameters, cellKind and cellHorizontalBeamwidth will
be introduced to be part of the extended BSA (Base Station Almanac) data, which
are requested by a main customer in NAR to support E911/LBS:
cellKind is part of the Base Station Almanac, requested by the location server
through OAM to indicate if the cell is macro, metro, pico, or home. The
parameter should be set if it is needed by the location server.
LteCell::cellKind
Parameter cellKind
[Macro, Metro, Pico, Home]
Value OD
Feature L103896, L115705
Inter-Release Delta: cellKind parameter
Page 222/308
The cellKind parameter was renamed in Release LR13.1. In previous releases, it

was referred to as the cellType parameter.
Restriction: cellKind parameter
Only the values of Macro and Metro are supported in LR13.1.
cellhorizontalBeamwidth indicates the horizontal beam width of the cell. A value

of 359 indicates omni cell. Its value is automatically derived by the eNodeB
from the applicable AntennaPort::horizontalBeamwidth parameters. This
parameter is part of the Base Station Almanac (BSA) information used by the
Location Server.
LteCell::cellhorizontalBeamwidth
Parameter cellhorizontalBeamwidth
Range & Unit Integer, deg
[0..359] step = 0,1
Class/Source Read Only / customer_init
Value OD
Feature L103896
cellverticalBeamwidth represents the vertical beam width of the cell. Its value is
automatically derived by the eNodeB from the applicable
AntennaPort::verticalBeamwidth parameters
Note: A value of 359 indicates omni directional cell and 0 no beamwidth has been
provided.
LteCell::cellverticalBeamwidth
Parameter cellverticalBeamwidth
[0..180] step = 0,1
Class/Source Read Only / NA
Value OD
Feature L103896
The following five Read Only MIM parameters will be introduced that specify the
uncertainty of the WGS84 coordinates of the main antenna, required by the E-
UTRAN Access Point Position IE in TS36.455 LPPa to support ECID as well as
OTDOA.
Page 223/308
- LteCell::mainAntennaPositionUncertaintySemiMajor,
- LteCell::mainAntennaPositionUncertaintySemiMinor,
- LteCell::mainAntennaPositionOrientationOfMajorAxis,
- LteCell::mainAntennaPositionUncertaintyAltitude,
- LteCell::mainAntennaPositionConfidence.
mainAntennaPositionConfidence represents the confidence by which the main

antenna position is known to be within the uncertainty ellipsoid, expressed as a
percentage.
It is not meaningful if {mainAntennaPositionLatitude,
mainAntennaPositionLongitude, mainAntennaPositionAltitude} = {0,0,0}.
A value of 0 indicates 'no information'. See TS 36.455 E-UTRAN Access Point
Position.
LteCell::mainAntennaPositionConfidence
Parameter mainAntennaPositionConfidence
[0..100] step = 1
Class/Source N.A.
Value Default = 0
Feature L103896
mainAntennaPositionOrientationOfMajorAxis corresponds to the Orientation

of Major Axis of the uncertainty ellipsoid for the main antenna position. It is not
meaningful if {mainAntennaPositionLatitude,
When
mainAntennaPositionUncertaintySemiMajor=mainAntennaPositionUncertain
tySemiMinor, the uncertainty ellipsoid collapses to an uncertainty circle, making
the orientation of major axis of no significance.
This parameter represents the Offset and the Included angle which are encoded
in increments of 1 using an 8 bit binary coded number N in the range 0 to 179.
The relation between the number N and the range offset (ao) and included (ai) of
angles (in degrees) it encodes is described by the following equations:
Offset angle (ao)
2 N <= ao < 2 (N+1) Accepted values for ao are within the range from 0 to
359,9...9 degrees.
Included angle (ai)
2 N < ai <= 2 (N+1) Accepted values for ai are within the range from 0,0...1 to 360
degrees.
See TS 36.455 E-UTRAN Access Point Position.
Page 224/308
LteCell::mainAntennaPositionOrientationOfMajorAxis
Parameter mainAntennaPositionOrientationOfMajorAxis
[0..179] step = 1
Value Default = 0
Feature L103896
mainAntennaPositionUncertaintyAltitude corresponds to the uncertainty

altitude for the main antenna position. {mainAntennaPositionLatitude,
mainAntennaPositionLongitude, mainAntennaPositionAltitude} = {0,0,0}. It is
set to the value K mapped from the uncertainty in altitude, h, expressed in meters
according to the following formula:
h=C((1+x)^K-1) with C = 45 and x = 0.025.
This corresponds to a range between 0 and 990 meters for the uncertainty
altitude. See TS 36.455 E-UTRAN Access Point Position.
LteCell::mainAntennaPositionUncertaintyAltitude
Parameter mainAntennaPositionUncertaintyAltitude
[0..127] step = 1
Value Default = 9
Feature L103896
mainAntennaPositionUncertaintySemiMajor corresponds to the semi-minor

axis of the uncertainty ellipsoid associated with the main antenna position and is
not meaningful if {mainAntennaPositionLatitude,
It is set to the value K mapped from the uncertainty r expressed in meters

r=C((1+x)^K-1) with C = 10 and x = 0.1.
This corresponds to a range between 0 and 1800 kilometers for the uncertainty.
Page 225/308
LteCell:: mainAntennaPositionUncertaintySemiMajor
Parameter mainAntennaPositionUncertaintySemiMajor
[0..127] step = 1
Value Default = 7
Feature L103896
mainAntennaPositionUncertaintySemiMinor corresponds to the semi-minor

axis of the uncertainty ellipsoid associated with the main antenna position and is
not meaningful if {mainAntennaPositionLatitude,
It is set to the value K mapped from the uncertainty r expressed in meters
r=C((1+x)^K-1) with C = 10 and x = 0.1.
This corresponds to a range between 0 and 1800 kilometers for the uncertainty.
LteCell:: mainAntennaPositionUncertaintySemiMinor
Parameter mainAntennaPositionUncertaintySemiMinor
[0..127] step = 1
Value Default = 7
Feature L103896
cellAzimuth provides the orientation of the cell in degrees based on

a "True North" system, meaning:
North = 0 degrees
East = 90 degrees
South = 180 degrees
West = 270 degrees.
Page 226/308
Its value is automatically derived by the eNodeB from the applicable

AntennaPort::azimuth parameters.
LteCell::cellAzimuth
Parameter cellAzimuth
[0..360] Step = 0,001
Value OD
Feature L103896
11.6.6 ENB PROVIDE CORRECTION OF TADV TYPE 1 TO

SAM
Modem provides
OAM sends CorrectionForTadvType1
CorrectionFor
SAM depending on cases of eCEM,
TadvType1 to bCEM or 20KM fiber per cell.
SAM with
other BSA
data
OAM Modem
DSP
Cell Config Resp DSP Init Req
Modem expects
callP to provides
UL frame offset/DL
CallP GeoSubsystem Interface
frame offset/GPS
Message Manager frame offset/RTT
DL- UTDOA
ECID
OTDOA
Figure 55 : Illustration of providing CorrectionForTadvType1 to support

geolocation
Page 227/308
12 SUBSCRIBER AND EQUIPMENT TRACES

The eUTRAN Call Trace features (L76923 and L92645) provide an efficient
means for monitoring network performance on per UE level that are compliant
with the 3GPP standards for Call Trace. The features enable the operator to:
• Respond to mobile users’ QoS claims
• Identify and troubleshoot problems either at the system level or at the
user level
• Perform studies to optimize network operation during feature introduction
and commercial operation
These features provide the eNB support and the activation and data collection
mechanisms for the call trace functions specified in TS32.422 [R10] and
TS32.423 [R11]for both Management Based Trace and Signaling Based Trace.
The eNB Subscriber and Equipment Trace feature supports two types Trace
Sessions: Management Based Trace and Signaling Based Trace as specified in
TS32.422 [R11]. On each eNB only one type of Trace Session can be active at
any given time, either Management Based Trace or Signaling Based Trace but
not both.
The eNB Subscriber and Equipment Trace feature supports two types Trace
Sessions: Management Based Trace and Signaling Based Trace as specified in
TS32.422[R10]. On each eNB only one type of Trace Session can be active at
any given time, either Management Based Trace or Signaling Based Trace but
not both.
12.1 TRACE CONCEPTS
12.1.1 MANAGEMENT BASED TRACE OVERVIEW

Management based trace is activated from the 5620 SAM on a per-eNB basis,
and collects data from one or more of the eNB interfaces (RRC, X1, S2
interfaces). Management Based Trace is further divided into two subcategories:
Cell Traffic Trace is compliant with the scope specified in TS32.422 [R10]. For
Cell Traffic Trace, once activated, the eNodeB starts a Trace Recording Session
whenever a call is started in the monitored cell(s).
Event-Based Trace is also cell-based tracing. Event-Based Trace allows the
operator to configure thresholds for pre-defined events. The eNB starts a Trace
Recording Session whenever any of the configured threshold conditions is met in
the monitored cell(s). The potential triggers (which occur over a one minute
window) to start a trace recording are:
• Traffic Based – the percentage traffic load is lower than a threshold value
• RRC Reestablishments – the number of RRC reestablishment attempts
exceeds a threshold value
Page 228/308
• IRAT Handovers – the number of Inter Radio Access Technology (IRAT)

handovers exceeds a threshold value
Once Event Based trace is triggered (by crossing one of the thresholds), any UE
call that is started on the monitored cell(s) will be traced.
When activating Management Based Trace, the operator can either enable Cell
Traffic Trace or Event-Based Trace on the eNB but not both at the same time.
12.1.2 SIGNALING BASED TRACE OVERVIEW

Signaling Based Trace is activated/deactivated from the LTE Core Network. This
LPUG description focuses primarily on Signaling Based Trace from an eNB
perspective. The eNB will always receive the trace command either from the MME
or from another eNB (as a part of handover). Signaling based trace applies to a
specific UE, and is enabled from the MME based on the IMSI of the UE.
Signaling Based Trace is always originated from the EPC or MME. However, the
following SAM configuration parameters are applicable to Signaling Based Trace:
• isSignBasedCTEnabled (see Section 12.3.2). If the value of this
parameter is set to “false”, then Signaling Based Trace cannot be enabled
for the eNB. If the value of this parameter is set to “True”, then Signaling
Based Trace is activated and one or more specified UEs can be traced on
the cells of the eNB under control of the MME.
• tceIpAddress (see Section 12.2.1.8). The eNB sends signaling based
trace records to this address regardless of the setting of the comparable
field in the Trace Activation command.
• tceUdpPort (see Section 12.2.1.8). This port is used to send the trace
records to the SAM.
For Signaling Based Trace, eNB starts tracing as soon as it receives the Trace
Activation command from the MME or another eNB when the specified UE is
active on a call. The eNB accepts all the valid Trace Control and Configuration
parameters in the Trace Activation command except the following:
• TCE IP address: eNB will send trace data to SAM regardless what TCE
IP address is specified in the Trace Activation IE
• Trace Depth: eNB supports Minimum and Maximum trace depth

regardless what Trace Depth value is specified in the Trace Activation IE.
Rule: TCE IP Address and UDP port number
eNB uses the TCE IP Address and UDP port number configured by SAM.
Page 229/308
12.1.3 COMPARISON OF MANAGEMENT BASED TRACE

AND SIGNALING BASED TRACE
Table 26 provides a comparison among the types of call trace that are currently
supported.
Management Based Trace Signaling Based

Cell Traffic Trace Event Based Trace Trace
For eNB, only calls

instructed by the MME
All calls for specified
will be traced. For a
All calls for specified eNB/cell(s) when
What is Traced given UE, MME sends
eNB/cell(s) event threshold value
Trace Activation to
is triggered
eNB for each call
separately.
Controlled From SAM MME
Interfaces (uU, S1, Specified in command

Specified in SAM GUI
X2) line
ePC, MME, eNB

Scope eNB interfaces interfaces (NE
specified in command)
Up to 40 UEs traced
simultaneously per
MME. Each eNB may
connect to multiple
MMEs and the trace
limit on each eNB is
determined by a
For Maximum Trace Depth, up to 100 UEs counter value with a
traced simultaneously per eNB maximum value of
Capacity 200:
For Minimum Trace Depth, up to 200 UEs
traced simultaneously per eNB each UE with
maximum trace depth
increments counter by
2
each UE with
minimum trace depth
increments counter by
1
Table 26 : Comparison of Trace Types
Page 230/308
12.1.4 TRACE SESSION

A Trace Session is defined as the time interval between the Trace Session
Activation and the Trace Session Deactivation for that specific Trace Session.
Figure 56 illustrates the concept of a Trace Session interval.
Activation Deactivation
• IMSI or IMEI (SV) (or none for • Trace Reference
eNB Management Based trace)
• Trace Reference
Time
Trace Session
Figure 56 : Trace Session (TS32.421)
For a given eNB, only one of the following types of Trace Sessions can be active
at a time:
• Cell Traffic Trace
• Event Based Trace

• Signaling Based Trace
Page 231/308
12.1.5 TRACE RECORDING SESSION

As illustrated in Figure 57, a Trace Recording Session refers to the time interval
within a Trace Session while trace records are generated for a specific
Subscriber/UE that is being traced.
Trace
Trace Recording
Recording Session
Session Reference
Reference #2
#1
Call/Session #2
Call/Session #1
Time
Start Stop Start Stop
trigger trigger trigger trigger
event event event event
Trace Session
Figure 57: Trace Recording Session (TS32.421)
The eNB allocates a unique Trace Recording Session Reference to capture all
the traced messages for a particular UE in a Trace Session.
Note that overlapping calls/sessions are possible in the above figure for Trace
Session. Triggering Events are covered in later section of this document.
Page 232/308
12.1.6 SUBSCRIBER AND EQUIPMENT TRACES 3GPP

COMPATIBILITY
The eNB Subscriber and Equipment Trace feature (L92645) will support identified
Trace functions that are specified in the March 09 3GPP standards documents:
TS32.421, TS32.422 and TS32.423. For traceable messages, the feature will
support messages specified in the March 09 standard documents for S1-MME, X2
and RRC interfaces as indicated in the Reference section.
For convenience, these documents are summarized in Table 27.
3GPP
Version
Document Document Name
Supported
#
TS32.421 Trace concepts and requirements 8.5.0
TS32.422 Trace control and 8.5.0

configuration
management
TS32.423 Trace data definition and management 8.1.0
TS36.413 S1 Application Protocol 8.6.1
TS36.423 X2 application protocol 8.6.0
TS36.331 Radio Resource Control 8.6.0

Protocol specification
Table 27 : Subscriber and Equipment Traces 3GPP Compatibility
Page 233/308
12.1.7 ARCHITECTURE OF SUBSCRIBER AND

EQUIPMENT TRACE
12.1.7.1 HIGH LEVEL OVERVIEW
Figure 58 shows high level diagram for the eNB Subscriber and Equipment Trace
feature activation and Trace data collection architecture.
SAM
Generated Trace Operator

Trace files Configuration
(3GPP Interface
compliant)
Trace Collection
Entity NETCONF
Management
Based Trace
UDP
SNMP XML Trace Config
Streaming Event
Notif. parameters
eNodeB
Trace Record Trace Activation
Transmission configuration / Deactivation
and activation MME
Trace
Collection
Signaling
Based Trace
Figure 58: eNB Subscriber and Equipment Trace High Level Diagram
12.1.7.2 ENB INTERNAL FUNCTIONAL BLOCKS AND

INTERFACES
When Call Trace is activated, the eNB uses the existing infrastructure
implemented for LA1.1 to collect trace data. Trace points are provided for all the
traceable RRC, S1-MME, and X2 messages as specified by 3GPP in [R12],
[R13]and [R14]. The eNB combines the collected trace data and some additional
parameters into a binary format that it periodically sends to SAM via UDP
streams. Traceable messages on the RRC, S1-MME and X2 interfaces are
specified in Section 12.5.
Figure 59 shows the interactions of impacted functional blocks at the eNB.
Page 234/308
Binary
UDP
Port Trace Data
Trace
UPOS
CallP
SAM
XMS Call Trace
Configure OAM
Activate/
Deactivate Activate/
Trace Deactivate
Parameters Trace
Parameters
eNB
Figure 59: eNB Call Trace Functional Diagram
12.2 MANAGEMENT BASED TRACE

Management Based Trace is described in this section. The following topics are
covered:
• Section 12.2.1 describes the TRACE CONFIGURATION PARAMETERS

that can be configured either from WPS or from a SAM GUI.
• Section 12.2.3 provides a more detailed description of the Management
Based Trace operation, and
• Section 12.2.3.1 provides a detailed description of the parameters that
are used for Event Based Trace and defines how the values are used by
the system to trigger traces.
12.2.1 TRACE CONFIGURATION PARAMETERS

The Alcatel-Lucent implementation of TS32.422 [R10] requires the configuration
parameters that are indicated below. These parameter values can be set from the
WPS system (after creating the Ctg object) or from a SAM GUI.
• Trace Activation Parameter
• Trace Reference
• Trace Name
• List of Cells to be Traced
• Trace Depth –can be a value of “Minimum” or “Maximum”

• Interfaces to be traced
Page 235/308
• IP Address of Trace Collection Entity (TCE) – configured from WPS

• UDP Port of TCE – configured from WPS
• Overload level at which Management Based Trace is stopped
This section will focus on these parameters and other parameters that are
necessary for the proper functioning of the call trace. The triggering events for
Event-Based Trace are described in Section 12.2.3.1.
Use of a SAM GUI for starting and ending a call trace is described in Reference
[R09].
12.2.1.1 PARAMETER FOR ACTIVATING A
MANAGEMENT BASED TRACE
From an eNB perspective, Management Based Trace recording is started by
setting the isTraceActive
parameter value to “True”. Conversely, Management Based Trace recording is
stopped by setting the isTraceActive parameter value to “False”.
isTraceActive: Indicates if the trace is active (i.e. Recording) or not (i.e. stop
recording)
CTg::isTraceActive
Parameter isTraceActive
Object ENBEquipment/Enb/SubscAndEquipmentTraces/CTg
False; True
Value O.D. Default = False
Feature L92645
12.2.1.2 TRACE REFERENCE

Trace Reference identifies a specific Trace Session. It is used by the Trace Post
Processing system to correlate the trace records generated by various NEs.
TS32.422 [R10] specifies that the Trace Reference parameter must be globally
unique and composed as:
MCC+MNC+Trace ID
Where:
MCC = Mobile Country Code (See [Vol. 5])
MNC = Mobile Network Code (See [Vol. 5])
For Management Based Trace the Trace ID (traceID) is specified by the 5620
SAM (or WPS) and sent to the eNB. The eNB combines the traceID with MCC
and MNC to form the complete Trace Reference.
For Signaling Based Trace, the Trace Reference is contained in the Trace
Activation IE and is passed from the MME via the S1AP messages or from
another eNB via X2 message depending on the Trace Activation scenarios. When
allocating the Trace Reference, an Alcatel-Lucent MME will ensure the
Page 236/308
uniqueness across all the MMEs in the same MME pool by assigning the MMEC
value as the most significant of the three octets of the traceID field.
traceId: The trace Id is part of the Trace Reference defined in (3GPP TS 32.421)
as : "A globally unique ID shall be generated for each Trace Session to identify
the Trace Session. The method for achieving this is to divide the Trace reference
into Country, Operator, and trace Id."
CTg::traceId
Parameter traceId
1..16777215 Step = 1
Value O.D.
Feature L92645
12.2.1.3 TRACE SESSION NAME
The callTraceSessionName parameter provides a user-friendly name that can

be used to refer to the call trace session.
CTg::callTraceSessionName
Parameter callTraceSessionName
Range & Unit String
0 to 32 characters
Class/Source N.A. / Test Parameter 5
Value O.D.
Feature L104487
12.2.1.4 TRACE RECORDING SESSION REFERENCE
The Trace Recording Session Reference identifies each Trace Recording Session
within a given Trace Session, thus it must be unique within the scope of each
Trace Reference. The eNB uses a unique Trace Recording Session Reference to
capture all messages associated with a Trace Reference for a particular UE.
For Management Based Trace, the Trace Recording Session Reference is

generated by the eNB and is unique within the Trace Session.
For Signaling Based Trace, the Trace Recording Session Reference is
determined by the MME, and is provided in the Trace Activation IE that is passed
from the MME via the S1AP messages or from another eNB via X2 message
5
Class is not defined for a parameter that is not transmitted to the eNB. The usual categories
defined in this document do not apply, since this is a test parameter that is set only when needed.
Page 237/308
depending on the scenarios. Trace Reference and Trace Recording Session

Reference are passed to the eNB that is to trace the UE in the same message.
12.2.1.5 LIST OF CELLS TO BE TRACED FOR

MANAGEMENT BASED TRACE
The cells within the eNodeB to be traced are defined by the listOfTracedCells
parameter. This is a comma separated list that is enclosed within parentheses
(…)
listOfTracedCells - parameter refers to the list of the cells which are traced. This
list should point to one or more cells of the eNB. The max size of the list
corresponds the maximum number of LteCell objects that can be created for an
eNB (Currently, this is three cells).
CTg::listOfTracedCells
Parameter listOfTracedCells
listSizeMin = 1
listSizeMax = 6
Value O.D.
Feature T115606, L115938, L115808
Page 238/308
12.2.1.6 TRACE DEPTH

The Trace Depth, specified at the Trace Session activation, is used to choose
the level of details to be provided in the Trace output. TS32.422 specifies 6 levels
of Trace Depth:
Trace Depth Meaning

Recording of some IEs in the signaling
Minimum messages plus any vendor specific extensions
to this definition, in decoded format.
messages together with the radio
Medium measurement IEs plus any vendor specific
extensions to this definition, in decoded
format.
Recording entire signaling messages plus any
Maximum vendor specific extensions to this definition, in
encoded format.
MinimumWithoutVendorSpecificExtension
messages in decoded format.
MediumWithoutVendorSpecificExtension messages together with the radio
measurement IEs in decoded format.
Recording entire signaling messages in
MaximumWithoutVendorSpecifcExtension
encoded format.
The eNB Subscriber and Equipment Trace feature only supports Minimum and
Maximum trace depth.
For Management Based Trace, Trace Depth is configured from SAM via
traceDepth parameter.
For Signaling Based Trace, Trace Depth is specified in the Trace Activation IE
and is passed from the MME via the S1AP messages or from another eNB via X2
message depending on the Trace Activation scenarios.
traceDepth: Trace depth represents the level of details of Trace data. TS32.422
[R10] and defines the levels of Trace Depth. The trace depth for the eNodeB is
one of the trace configuration parameters specified in TS32.422.
Page 239/308
CTg::traceDepth
Parameter traceDepth
Minimum; Medium; Maximum;
MinimumWithoutVendorSpecificExtension;
MediumWithoutVendorSpecificExtension;
WithoutVendorSpecificExtension
Value O.D. Only Minimum and Maximum are supported. Default
= Maximum
Feature L92645
Restriction: traceDepth parameter
Only values of Minimum and Maximum are supported. If the trace depth is not
specified, the Minimum depth will be used. Messages recorded in either the
Minimum or Maximum trace depth will be recorded in an encoded format
(messages will not be decoded).
12.2.1.7 INTERFACES TO BE TRACED

List of Interface(s) parameter defines the interfaces to be traced and recorded in
the Network Element’s trace data.
TS32.422[R10] specifies the following interfaces for eUTRAN:
• S1-MME
• X2
• Uu: RRC
For Management Based Trace the list of interface(s) is configured from SAM via
three separate parameters:
• isS1MMETraced
• isX2Traced
• isRRCTraced
• isS1MMETraced: Indicates if the S1-MME interface is traced. If the value

of this parameter is set to “True” as part of call trace activation, then
signaling messages on the S1 interface will be recorded as part of the
Trace Session. Otherwise, signaling messages on this interface will not
be recorded.
Page 240/308
CTg::isS1MMETraced
Parameter isS1MMETraced
False; True
Value False
Feature L92645
• isX2Traced: Indicates if the X2 interface is traced. If the value of this

parameter is set to “True” as part of call trace activation, then signaling
messages on the X2 interface will be recorded as part of the Trace
Session. Otherwise, signaling messages on this interface will not be
recorded.
CTg::isX2Traced
Parameter isX2Traced
False; True
Value False
Feature L92645
• isRRCTraced: Indicates if the RRC (Uu) interface is traced. If the value

of this parameter is set to “True” as part of call trace activation, then
signaling messages on the RRC (user or uU) interface will be recorded as
part of the Trace Session. Otherwise, signaling messages on this
interface will not be recorded.
CTg::isRRCTraced
Parameter isRRCTraced
False; True
Value False
Feature L92645
Page 241/308
12.2.1.8 IP ADDRESS OF TRACE COLLECTION ENTITY
The TCE IP Address identifies the IP Address to which the trace data should be
sent.
For Management Based Trace this parameter is configured from SAM via
tceIpAddressand tceUdpPort. This address should be specified as the 5620
SAM IP address. For Signaling Based Trace this parameter is passed from the
MME or another eNB as part of the Trace Activation IE, but only the configuration
parameter that is received from SAM will be used.
Rule: tceIpAddress+tceUdpPort
The eNB Subscriber and Equipment Trace will send its trace data to the
tceIpAddress+tceUdpPort configured by SAM regardless of what TCE IP
Address is passed from the Trace Activation message for Signaling Based
Trace. The ALU MME OAM Guide [R14] indicates that the TCE IP address
specified from the MME CLI should be the same one that is specified in the 5620
SAM configuration file. In any case, the eNB will first save the TCE IP address
for later use, and then ignore the TCE IP address that was provided by the
MME. No notification is sent to SAM to avoid generating too many notifications
due to the fact that the IP address associated with each Signaling Trace
Activation from MME will be ignored.
• tceIpAddress: IP address of the Trace Collection Entity. The TCE can be

any properly equipped server, however, SAM will normally be used for the
call trace data collection. In this case, the IP address will be the 5620
SAM OAM_NE IP address – the IP address that SAM uses to
communicate with network elements (such as the eNB).
SubscAndEquipmentTraces::tceIpAddress
Parameter tceIpAddress
Object ENBEquipment/Enb/SubscAndEquipmentTraces
Range & Unit IPV4Address
Value N.A.
Feature L92645
• tceIpAddressv6 - parameter defines the IPv6 address of the Trace

Collection Entity (by default, it is the OMC IP address) - for call traces
only. Similar to the IPV4 address described above, but used when IPV6
address is used for reporting call trace data.
Page 242/308
SubscAndEquipmentTraces::tceIpAddressv6
Parameter tceIpAddressv6
Range & Unit IPV6Address
Value N.A.
Feature L108879
• tceUdpPort: Port on the Trace Collection entity (TCE) to receive the Call
trace UDP stream
SubscAndEquipmentTraces::tceUdpPort
Parameter tceUdpPort
1024…65535 Step = 1
Value Default = 57074
Feature L92645
Rule: Trace Collection Entity IP address and UDP Port
The values of the tceIpAddress parameter or the tceIpAddressV6 parameter,

whichever is appropriate, and the tceUdpPort parameter will be set
automatically by the OMC (SAM) if a signaling-based trace or a management-
based call-trace is activated - that is, if either "isSignBasedCTEnabled" or
"CTg::isTraceActive" is set to "True".
12.2.1.9 TRIGGERING EVENTS FOR EVENT BASED

TRACE
For Event Based Trace, configuration parameters are provided that can be used
to set trigger levels. These parameters are described in Section 12.2.3.1. If the
threshold values are all zero or are not entered on the command line, then Cell
Traffic Trace is performed. If a value is entered for one or more of the triggering
events, then Event Based Trace is performed.
12.2.1.10 EFFECT OF OVERLOAD ON MANAGEMENT
BASED CALL TRACE
A parameter, ovLevelForCTInhibition, controls the overload level (minor, major,

or critical) at which Management Based Call Trace is inhibited for the duration of
Page 243/308
the overload condition. See Section 8 of this volume for additional information
about overload control.
OverloadControl::ovLevelForCTInhibition
Parameter ovLevelForCTInhibition
Major, Minor, Critical
Value minor
Feature L115241
12.2.2 RUNNING A MANAGEMENT BASED CALL TRACE

Two methods are available for starting and stopping a Management Based Call
Trace:
• WPS entries for the parameter values specified in Section 12.2.1. This
approach is clumsy for a test capability like call trace.
• SAM GUI. - The relevant SAM GUI is described in [R09] in the section
titled, “Call Trace”.
If WPS is used to control parameter values, then the CTg object must be created
under the SubscriberAndEquipmentTraces object before parameter values can
be set.
12.2.3 MANAGEMENT BASED CALL TRACE –

ADDITIONAL DETAIL
In E-UTRAN the Management Based Trace is activated from SAM and will be
performed as either the E-UTRAN Cell Traffic trace or Event Based trace
functionality, depending on the configuration parameter values. In either case the
Trace Session Activation is configured (by the configuration parameters) for one
or a more E-UTRAN cells within one eNodeB on identified interfaces, where the
Trace Session is activated.
When the eNodeB receives Trace Session Activation from SAM for a given or a
list of E-UTRAN cell(s) the eNodeB starts a Trace Session for the given or list of
E-UTRAN cell(s).
Figure 60 illustrates the control and message flows for Management Based Call
Trace specified in TS32.422.
Page 244/308
SAM eNodeB UE MME
Trace Session Activation

(activate trace ind,
cell list,
trace depth,
interfaces,
thresholds (opt))
Allocate Trace Session
Reference
Starting Trace Session
NAS Service Request
Starting Trace Recording

Session and allocation Trace
Recording Session Reference
Call Setup
S1AP: Cell Traffic Trace
Trace Reference
, Reference
Trace Recording Session
Call Ends
Trace Recording
Session Stops
eNB periodically UPOS Trace

~
sends collected
Trace data to the
Data stream
(binary)
~
SAM
Trace Session Deactivation
Stopping Trace Session
Figure 60: Management Based Call Trace
Page 245/308
For Management Based Trace, eNB receives the following Call Trace parameters
from the SAM:
• Trace Activation / Deactivation Indication (isTraceActive)
• List of Cell(s) where the Trace is to be started (listOfTracedCells)

• Trace depth (traceDepth)
• Traced interface(s) where the Trace data is to be collected
(isRRCTraced, isS1MMETraced, isX2Traced)
• Optional Event Threshold values for Traffic Threshold, RRC Re-
establishment Threshold, and/or IRAT Handover Threshold
(trafficThreshold, rrcReestablishmentThreshold, iratHOThreshold)
• Trace Collection Entity (TCE) IP Address (TCEIpAddress)
• UDP Port Number at TCE (TCEUdpPort)
• Trace ID (traceID)
When eNB receives modified call trace parameter values from the SAM, the eNB
does the following:
• The eNB first determines if Management Based Trace is enabled at the
eNB using the isTraceActive parameter. If the isTraceActive parameter
value is “False”, then an error indication is provided to the SAM. If the
isTraceActive parameter value is “True”, then the trace continues as
described below.
• If Management Based Trace is enabled the eNB next determines whether
the Trace Type is Cell Traffic Trace or Event Based Trace:
o Read the trafficThreshold, rrcReestablishmentThreshold and
iratHOThreshold values.
o If any of the threshold values is not zero, then Event Based Trace
is to be performed. eNB then records the threshold values for
Event Based Trace.
o If all of the threshold values are zero then Cell Traffic Trace is
performed.
• The eNB activates the Trace Session and associates it with the Trace
Reference.
• The eNB then reads the other trace parameters: ListOfTracedCells,
traceDepth, isRRCTraced, isS1MMETraced, isX2Traced, TCEIpAddress
and TCEUdpPort.
• For Cell Traffic Trace, the eNB starts Trace Recording Session when any
of the following events occurs on a traced interface:
o Receive RRC Connection Request from UE on Uu interface
o Receive Handover Request message from the MME on S1-MME
interface (S1 Handover)
o Receive Handover Request message from another eNB on X2
interface (X2 Handover)
o The eNB allocates a unique Trace Recording Session Reference
for each UE call being traced.
• For Event-Based Trace, the eNB starts a Trace Recording Session when
all of the following conditions are met on the monitored cell(s):
• A new call begins on a traced interface in the monitored cell(s)
• At least one of the threshold conditions (see Section 12.2.3.1) is met
• When a Trace Recording Session starts, the eNB sends S1 Cell Traffic
Trace to the MME with the following information:
Page 246/308
o E-UTRAN Trace ID
o E-UTRAN CGI
o Trace Collection Entity IP Address (the TCE port number is not
included)
• When the UE moves to another cell in the same eNB, if the target cell is
also under trace then the eNB does not send another S1 Cell Traffic
Trace message to the MME.
o Note: Even though E-UTRAN CGI identifies an eNB cell, to avoid
additional traffic on the S1 interface due to eNB tracing activities,
only one S1 Cell Traffic Trace message will be sent by the eNB
for each traced call while the UE moves among traced cells within
the same eNB.
• The eNB continues collecting Trace data and periodically streams the
collected data to the tceIpAddress+tceUdpPort (SAM) in binary format.
The trace information is converted to 3GPP format at the SAM.
• The eNB stops the Trace Recording Session, for either Cell Traffic Trace
or Event Based Trace:
o When the call ends, or
o When the call is handed over to another cell that’s not traced in
the same eNB
o When the call is handed over to another eNB, or
o When the call is handed over to another network
• When the Trace Session is stopped at the SAM, the eNB will receive
Notification from the SAM. As a result, the eNB stops the Trace Session
and all the Trace Recording Sessions associated with the Trace.
• If the eNB receives a Management Based Trace Activation from the OAM
while the Management Based Trace Session is already active, the
notification is considered as a new Trace Activation. As a result, the eNB
will stop the existing Management Based Trace Session and start a new
Management Based Trace Session using the updated parameters
received from the OAM.
In release LM4.0, the MME will not process the CELLTRAFFICTRACE message
mentioned in step 7, above. It is expected that in a future release, the MME will
retrieve and store the UE’s IMSI and IMEI along with the Trace Recording
Session Reference and Trace Reference. A post processing tool can then
retrieve the data and correlate the eNB call trace data with the IMSI and IMEI
information
12.2.3.1 EVENT-BASED TRACE
For Event Based Trace, eNB keeps track of the configured Threshold values and
starts a Trace Recording Session only when at least one of the threshold
conditions is met on the monitored cell(s).
Traffic Threshold:
Page 247/308
trafficThreshold : Specific traffic threshold value (connected UE percentage)
CTg::trafficThreshold
Parameter trafficThreshold
0..100 Step = 1
Class/Source C--Immediate-propagation / eng_tunable
Value 0
Feature L92645
Note: The trace session is started when the percentage of RRC Connected UE
within the last 1-min sampling interval in the monitored cell is lower than the
configured threshold.
The trafficThreshold value defines number of Connected UE ratio/percentage for
the monitored eNB cell. The definition of Connected UE percentage is:
Connected UE Percentage on a cell
= (# of RRC Connected UEs / RadioCacCell::MaxNbrOfUsers) * 100
Parameter MaxNbrOfUsers is described in LPUG [Vol. 4].
If Event Based Trace is activated for traffic threshold, the eNB monitors the
number of RRC Connected UEs using a one minute sampling interval. At the end
of each one minute sampling interval, eNB does the following:
• Calculate the Connected UE Percentage on a cell using the formula

specified above for each of the monitored cells.
• Compare the calculated Connected UE Percentage on a cell with the
configured trafficThreshold value for each monitored cell.
If the calculated value for a monitored cell is lower than the configured
trafficThreshold value then eNB starts collecting trace data on the monitored
interface(s) whenever a UE starts a call in the traced cell.
RRC Connection Re-establishment Threshold:
• rrcReestablishmentThreshold : Specific RRC threshold value (number

of RRC connection reestablishment attempts)
Page 248/308
CTg::rrcReestablishmentThreshold
Parameter rrcReestablishmentThreshold
0..300000 Step = 1
Value 0
Feature L92645
Note: The Trace Session is started when the number of RRC connection re-
establishment Requests within the last 1-min sampling interval in the monitored
cell exceeds the configured threshold.
The rrcReestablishmentThreshold value defines the number of RRC

Connection Re-establishment Attempts eNB received from UEs for the monitored
cell.
If Event Based Trace is activated for
RRCConnectionReestablishmentRequests, the eNB monitors the number of
RRC Connection Reestablishment Requests received based on a one minute
sampling interval.
At the end of each one minute interval the eNB shall does the following:
• Compare the value for Number of
RrcConnectionReestablishmentRequest received with the configured
rrcReestablishmentThreshold value.
• If the value for Number of RrcConnectionReestablishmentRequest
received for a monitored cell is greater than the
RrcReestablishmentThreshold value then eNB will start collecting trace
data on the monitored interface(s) whenever a UE starts a call in the
traced cell.
IRAT Handover Threshold:
• iratHOThreshold: Specific IRAT HO threshold value (number of

outgoing IRAT HO attempts)
Page 249/308
CTg::iratHOThreshold
Parameter iratHOThreshold
0..300000 Step = 1
Value 0
Feature L92645
Note: The Trace Session is started when the number of outgoing IRAT HO
attempts within the last 1-min sampling interval in the cell exceeds the configured
threshold.
The iratHOThreshold value defines number of outgoing Inter-RAT Handover

Redirection Attempts eNB sent to UEs for the monitored cell. eNB keeps track of
the following values based on 1 min sampling interval:
A. Number of Non-optimized Redirections to HRPD via Event A2
B. Total number of Redirections to UTRA FDD or GERAN

= Number of Redirections to UTRA FDD via Event A2 + Number of Blind
Redirections to UTRA FDD via Event B2 + Number of Redirections to GERAN via
Event A2 + Number of Blind Redirections to GERAN via Event A2
If Event Based Trace based on inter-RAT mobility is enabled, then at the end of
each one minute sampling interval the eNB does the following:
• Compare the configured iratHOThreshold value with the values specified
in formula A and formula B above for each monitored cell.
• If any of the calculated values from formula A or formula B for a

monitored cell is greater than the iratHOThreshold value then eNB starts
collecting trace data on the monitored interface(s) whenever a UE starts a
call in the traced cell.
12.2.4 HANDLING MANAGEMENT BASED TRACE

RECORDING SESSION DURING HANDOVER
The concepts provided in this section apply to both the Cell Traffic Trace and
Event Based Trace variants of Management Based Trace.
Page 250/308
Management Based Call Trace is activated or deactivated on per eNB, per cell
basis.
Trace data is only collected for those cell(s) that are configured to be
traced/monitored as specified in the ListOfTracedCells parameter received from
SAM.
When a UE handover procedure occurs while the Management Based Trace is

active on the source eNB cell, tracing of UE may continue at the target after the
handover or the trace recording session may not continue at the target eNB/cell
as specified below.
• Intra-cell, intra-eNB Handover (for example, an intra-cell handover

associated with security feature L92638)
o The call will continue being traced after the handover procedure
since the call stays on the same traced cell.
• Inter-cell, intra-eNB Handover
o The call will continue being traced at the target cell in the same
eNB after the handover procedure if the target cell is also under
trace. In this case, the same Trace Recording Session Reference
will be used.
o The call will not be traced at the target cell in the same eNB after
the handover procedure if the target cell is not under trace. In this
case, eNB will stop the Trace Recording Session for that UE.
• Inter-eNB X2 Handover
o If a Management Based Trace Session is active at the target
eNB, then the target eNB will start tracing the UE and create a
new Trace Recording Session when it receives the X2 Handover
Request from the source eNB. If a Management Based Trace
Session is not active at the target eNB, then the UE will not be
traced at the target eNB. The source eNB will stop tracing the UE
once the handover is complete.
• Inter-eNBS1Handover
o If a Management Based Trace Session is active at the target
eNB, then the target eNB will start tracing the UE and create a
new Trace Recording Session when it receives the S1 Handover
Request from the MME. If a Management Based Trace Session
is not active at the target eNB, then the UE will not be traced at
the target eNB. The source eNB will stop tracing the UE once the
handover is complete
12.3 SIGNALING BASED CALL TRACE
12.3.1 OVERVIEW
In Signaling Based Trace, the Trace Activation is directed from the Core Network.
The Signaling Trace Activation message from the CN carries the trace
parameters (including the Trace Reference) and the activation propagates to
each recipient NE. Each Trace participating NE will use the same Trace
Reference that is specified in the Trace Activation message. With this approach,
a post processing tool can correlate trace data collected from different NEs by
using the Trace Reference. Note that Signaling Based Trace is done for a specific
UE and is based on the UE’s IMSI.
Up to 40 UEs, identified by IMSI, can be traced using Signaling Based Trace per
MME. As mentioned previously, any individual eNB can support tracing for up to
100 UEs simultaneously. Note that an eNB configuration parameter must be
Page 251/308
enabled in order for the eNB for it to participate in Signaling Based Trace. See
Section 12.3.3 for additional information.
Figure 61 depicts the Signaling Based Trace Activation and Trace parameter
propagation.
Element
Manager
1
Trace Parameter Configuration
Network Network Network

Element Element Element
1 0 ... * 1 0 ... *
Trace Parameter Propagation
Figure 61: Signaling Based Activation/Deactivation (TS32.421)
Alcatel-Lucent’s call trace solution follows the approach that is defined in

TS32.421 [R15]and TS32.422 [R10]. Figure 62 shows the Trace Activation
method used in the LTE network:
Page 252/308
SAM
MME
SGW
eNB
PGW
Figure 62: Signaling Based Trace Activation in LTE
The Signaling Based Trace can also be initiated from the MME CLI.
12.3.2 RUNNING A SIGNALING BASED TRACE FROM THE

ALU 9471 MME
This section will provide a brief summary of the ALU 9471 MME commands that
are used for managing Signaling Based Trace from the MME. Official
documentation is provided in[R14].
Signaling Based Call Trace is activated from the MME for individual UEs based
on IMSI. All signaling messages for each specified UE are monitored on the NEs
where Signaling Based Call Trace is activated. The discussion that follows is
focused on an eNB view of Signaling Based Trace and will not discuss the tracing
that is done at the MME or the ePC.
Similar to Management Based Trace operations at the SAM, Signaling Based
Trace operations from the MME provide commands to support the following
operations:
• Start a trace
• Stop a trace
• Query traces that are currently running
Page 253/308
12.3.2.1 START A TRACE FROM THE MME CLI
Before the trace is started from the MME CLI, the following information is needed:
• List of UE IMSIs to be traced
• List of eNBs on which trace is to run
• Trace Collection Entity IP address as previously defined in the eNB

configuration file from the WPS (see Section 12.2.1.8). The address
supplied here is mandatory and must agree with the address already
configured at the eNB.
The syntax of the MME CLI command is:
calltrc_cli –o start -i <imsi> -ne <network element> -t <interface types> -d
<trace depth> -cipaddr <collection host IP address>
Note that only RAN-related values and options are shown. See[R14] for the
complete specifications of the input values.
Where:
<imsi> is a mandatory input. This is an up to 15 digit field that specifies the UE to
be traced
<network element> is a mandatory field and defines the eNB that is to support the
trace
<interface types>optional field that specifies the interfaces to be traced. If no

interface(s) are specified, then all interfaces are traced. If multiple interfaces are
specified, then a space delimiter should be used between them. From a RAN
perspective, the interfaces that can be traced are:
• enb_s1mme - eNB interface with MME (LM2.0)
• x2 - eNB interface with another eNB (LM2.0)
• uu - eNB interface with UE (LM2.0)

<trace depth> should be set to minimum or maximum trace depth (these are
currently the only supported values for the eNB)
<collection host IP address> is a mandatory field when an eNB is specified. The
value supplied must match the TCE IP address for the SAM that is described in
Section 12.2.1.8 and has already been configured on the eNB.
12.3.2.2 STOP A SIGNALING BASED TRACE FROM THE
MME CLI
The command for stopping a Signaling Based Call Trace from the MME is:
calltrc_cli –o stop -i <imsi>
Where: <imsi> is the IMSI of the UE whose trace is to be stopped on all active
NEs
Page 254/308
12.3.2.3 QUERYING ACTIVE SIGNALING BASED

TRACES FROM THE MME CLI
The following command can be used to view active Signaling Based Traces that
are in progress or pending:
calltrc_cli –o query -i <imsi> -s <call trace state>
Where:
<imsi> is an optional field to indicate a specific UE trace. If this field is not
supplied, then all active IMSI traces are reported
<call trace state> is an optional field to indicate traces that are in a specific state.
If this field is not specified, both possible states are provided in the output. States
are:
started indicates traces that are currently running
pending indicates traces that have been requested, but the specified UE is not
currently active
12.3.3 SIGNALING BASED TRACE ADDITIONAL DETAIL

Signaling Based Trace must be activated on a per eNB basis before it can be
enabled from the MME. This is done using the following parameter.
isSignBasedCTEnabled: If the value is “True”, then Signaling Based Trace is
activated for the eNB, and Signaling Based Trace can be enabled on a per-UE
(based on IMSI) basis for this eNB. If the value is “False”, the eNodeB will
deactivate all the signaling based traces on all of the eNB’s cells.
SubscAndEquipmentTraces::isSignBasedCTEnabled
Parameter isSignBasedCTEnabled
False; True
Value False
Feature L92645
During overload conditions, signaling based call trace can be inhibited. A

parameter, ovLevelForS1TraceStartAction, controls the overload level (minor,
major, or critical) at which Signaling Based Call Trace is inhibited for the duration
of the overload condition. See Section 8 of this volume for additional information
about overload control.
ovLevelForS1TraceStartAction - parameter specifies the level of overload at

which the Signaling-Based Call Trace function will be inhibited.
Page 255/308
OverloadControl::ovLevelForS1TraceStartAction
Parameter ovLevelForS1TraceStartAction
Value Minor
Feature L115241
The Signaling Based Trace Activation command may be carried to the eNB via
any of the following messages:
• S1AP: TRACE START
• S1AP: INITIAL CONTEXT SETUP REQUEST

• S1AP: HANDOVER REQUEST
• X2: HANDOVER REQUEST
The eNB starts tracing the monitored UE as soon as it receives any of the above
messages with a Trace Activation IE. The eNB accepts and stores the Trace
Parameters specified in the Trace Activation IE except the following:
o Trace Collection Entity IP AddressThe eNB sends its trace data

to the tceIpAddress+tceUdpPort (see Section 12.2.1.8)
configured by the SAM. If the received TCE IP Address is not the
same as that supplied by SAM file, the eNB will ignore it.
• Any Trace Depth value other than Maximum or Minimum
If the received Trace Depth is not Maximum or Minimum and other Trace
Parameters are valid, eNB will start the Trace Session Activation with Minimum
Trace Depth. If any of the Trace Parameters other than the tceIpAddress and
the Trace Depth are not valid, then the eNB will indicate an error and not start the
trace.
If the eNB receives a Signaling Based Trace Activation (together with Trace
Recording Session Start) via one of the Trace Activation messages while another
Signaling Based Trace Session (and Trace Recording Session) is active, then
the:
• eNB will determine if the Trace Reference is the same as any of the
existing active Trace Sessions.
• If it is the same, the eNB will reject the newly received Signaling Trace
Activation and continue the existing tracing activity.
• If the Trace Reference does not exist in the eNB, the eNB will accept the
new Signaling Based Trace Activation.
Page 256/308
12.3.3.1 HANDLING SIGNALING BASED TRACE

RECORDING SESSION DURING HANDOVER
The discussion that follows assumes that the value of the

isSignBasedCTEnabled parameter is equal to “True” at both the source eNB
and the target eNB. If the value of the parameter is equal to “False” for an eNB,
then no Signaling Based Trace will be performed for any cell associated with the
eNB.
Rule: Feature L92645

Signaling Based Call Trace activation or deactivation is controlled by the
MME.
In general, the call trace should continue at the target eNB after the
handover procedure for Signaling Based Call Trace.
Intra-cell, intra-eNB Handover (for example, an intra-cell handover
associated with security feature L92638)
The call continues being traced after the handover procedure since the call
stays on the same traced cell.
Inter-cell, intra-eNB Handover

The call continues being traced at the target cell in the same eNB after the
handover procedure. The same Trace Recording Session Reference that
was received in the Trace Activation message continues to be used.
Inter-eNB X2 Handover
When the source eNB sends the X2 Handover Request to the target it
includes the Trace Parameters in the Trace Activation IE of the X2
HANDOVER REQUEST message. The target eNB starts tracing the UE
using the received Trace Parameters as soon as it receives the X2
Handover Request message.
Inter-eNB S1 Handover
For Handover via the S1 interface, the MME propagates the Trace Activation
either to the target eNB via the S1 HANDOVER REQUEST message or to
the target MME via S10 FORWARD RELOCATION REQUEST message as
part of the inter-MME handover procedure. The source eNB stops the Trace
Recording Session when the handover procedure ends at the source eNB.
Note that if signaling based trace is started on the source eNB while a handover is
in progress, then the activation may fail with an appropriate cause. The MME will
attempt to restart the Call trace on the target eNB after the HO is completed.
12.4 INTERACTIONS BETWEEN MANAGEMENT BASED TRACE

AND SIGNALING BASED TRACE
Given that SAM may not be aware of Signaling Based Trace activities at the eNB,
SAM will allow the SAM operator to activate the Management Based Trace for the
Page 257/308
eNB while one or more Signaling Based Trace(s) are active. Similarly, EPC EMS
users may activate Signaling Based Trace by accident or simply not knowing the
Management Based Trace is active at the eNB. Thus, Trace Session
management is needed at the eNB software to handle the above scenarios.
In principle, Management Based Trace takes precedence over the Signaling
Based Trace, because Management Based Trace will activate traces for all the
UEs that are accessing the specified cells of the eNB. There is no need for
Signaling Based Trace to start if received afterward. In the event that a Signaling
Based Trace is already active when a Management Based Trace activation is
received from the SAM, eNB will stop the Signaling Based Trace Session(s) first
then accept the Management Based Trace activation.
At most one type of Trace Session can be activated at eNB. A couple of different
scenarios may occur when receiving Trace activation while there is already one
active at the eNB:
1. eNB receives a Signaling Based Trace Activation (together with Trace
Recording Session Start) from the MME while the Management Based
Trace Session is active:
• eNB will reject the Signaling Based Trace Activation and
continue the Management Based Trace Session.
2. eNB receives a Management Based Trace Activation from the OAM while
at least one Signaling Based Trace Session is active:
• eNB will accept the Management Based Trace Activation if the
Trace Parameters are valid and stop the Signaling Based Trace
Session.
12.5 CALL TRACE DATA

The data to be collected by the Management Based Trace and the Signaling
Based Trace functions is specified in TS 32.423[R11]. Table 28 is extracted from
[R13], and illustrates the mandatory and optional data to be collected for different
variants of the call trace. Only the maximum and minimum depth columns are
supported, so only those columns are applicable. The cells that are highlighted in
Table 28 represent the capabilities that are currently supported. Note that the
color coding is added and is not included in[R11].
Interface (specific Level of details
Format Description
messages) Min Med Max
M M O Message name
O O O Record extensions
Decoded M M X eNBID of traced eNB
RRC (without rrc
Dedicated IE extracted from RRC messages between the
dedicated M M X
traced eNB and the UE. A subset of IEs. is provided.
measurements)
Raw Uu Messages: RRC messages between the traced
ASN.1 X X M eNB and the UE. The encoded content of the message is
provided
M M O Message name
eNBID of traced eNB
M M X
Decoded MME ID of the connected MME
E-RabId + Dedicated IE extracted from S1AP messages
S1
M M X between the traced eNB and Core Network. A subset of
IEs. is provided.
Raw S1 Messages S1AP: messages between the traced
ASN.1 X X M eNB and Core Network The encoded content of the
message is provided
Page 258/308
M M O Message name
eNBID of traced eNB
M M X
Decoded eNBID of neighboring eNB
Dedicated IE extracted from X2AP messages between the
X2
M M X traced eNB and the neighboring eNB. A subset of IEs.is
provided
Raw X2 Messages:X2AP messages between the traced
ASN.1 X X M eNB and the neighboring eNB. The encoded content of the
message is provided
RRC (only dedicated Decoded X M X Uu IEs from RRC measurement reports messages
measurements) ASN.1 X X M RRC measurement reports messages
Table 28 : E-UTRAN Trace Record Content 6

Definitions:
eNBID of traced eNB: The id of the eNB traced, e.g. the eNB which handles the
connection of the traced MS, during the Trace Recording Session.
eNBID of neighboring eNB: The ids of all Neighboring eNB involved in the X2
procedures during the Trace Recording Session.
cell Id: The cell Ids of the cells involved in the X2 procedures during the Trace
Recording Session. The cell Ids is provided with each X2AP message for which
the cId is relevant.
E-RABId: Specific recorded IE that contains the E-RAB identifier.
Message name: Name of the protocol message

Record extensions: A set of manufacturer specific extensions to the record
Decoded: Some IEs are decoded
ASN.1: Messages in encoded format
If maximum trace depth is specified, then all messages on a traced interface are
recorded. If minimum trace depth is specified, then the messages listed in Table
29 are recorded (see Reference [R11]).
Interface Prot.
IE name Message name(s) Notes
name name
TS
Cs fallback indicator MOBILITY FROM EUTRA COMMAND
36.331
TS
CN domain PAGING
36.331
TS
S-TMSI PAGING
36.331
RRC CONNECTION REESTABLISHMENT TS
Uu RRC ReestablishmentCause
REQUEST 36.331
TS
Wait time RRC CONNECTION REJECT
36.331
TS
Release Cause RRC CONNECTION RELEASE
36.331
TS
Redirection Information RRC CONNECTION RELEASE
36.331
6
This table is duplicated from TS 36.423 [R05], Table 4.13.1
Page 259/308
TS
Establishment Cause RRC CONNECTION REQUEST
36.331
TS
Selected PLMN-Identity RRC CONNECTION SETUP COMPLETE
36.331
TS
RegisteredMME RRC CONNECTION SETUP COMPLETE
36.331
TS
Rat-Type UE CAPABILITY INFORMATION
36.331
HANDOVER FROM EUTRA PREPARATION
REQUEST TS
CDMA2000-Type
UL HANDOVER PREPARATION TRANSFER 36.331
UL INFORMATION TRANSFER
TS
Target RAT Type MOBILITY FROM EUTRA COMMAND
36.331
TS
E-RAB ID All messages where it is present
36.413
E-RAB SETUP REQUEST
TS
E-RAB Level QoS Parameters E-RAB MODIFY REQUEST
36.413
INITIAL CONTEXT SETUP REQUEST
INITIAL CONTEXT SETUP FAILURE
UE CONTEXT RELEASE REQUEST
UE CONTEXT RELEASE COMMAND
UE CONTEXT MODIFICATION FAILURE
HANDOVER REQUIRED
TS
Cause HANDOVER PREPARATION FAILURE
36.413
HANDOVER REQUEST
HANDOVER FAILURE
HANDOVER CANCEL
PATH SWITCH REQUEST FAILURE
NAS NON DELIVERY INDICATION
HANDOVER REQUIRED
TS
Handover Type HANDOVER COMMAND
36.413
HANDOVER REQUEST
S1 S1AP
HANDOVER NOTIFY
PATH SWITCH REQUEST TS
E-UTRAN CGI
INITIAL UE MESSAGE 36.413
UPLINK NAS TRANSPORT
HANDOVER NOTIFY
TS
TAI PATH SWITCH REQUEST
36.413
UPLINK NAS TRANSPORT
TS
Target ID HANDOVER REQUIRED
36.413
TS
CDMA2000 HO Status DOWNLINK S1 CDMA2000 TUNNELING
36.413
DOWNLINK S1 CDMA2000 TUNNELING TS
CDMA2000 RAT Type
UPLINK S1 CDMA2000 TUNNELING 36.413
TS
CDMA2000 Sector ID UPLINK S1 CDMA2000 TUNNELING
36.413
CDMA2000 HO Required TS
UPLINK S1 CDMA2000 TUNNELING
Indication 36.413
TS
E-RAB id All messages where it is present
36.423
TS
E-RAB Level QoS HANDOVER REQUEST
36.423
X2 X2AP HANDOVER REQUEST
TS
Cause HANDOVER PREPARATION FAILURE
36.423
HANDOVER CANCEL
TS
Target Cell ID HANDOVER REQUEST
36.423
Page 260/308
TS
GUMMEI HANDOVER REQUEST
36.423
TS
UE History Information HANDOVER REQUEST
36.423
Table 29 : Traced Messages for Minimum Trace Depth 7
12.5.1 RRC INTERFACE MESSAGES

All the RRC messages that are call related and UE associated as specified in TS
36.331 are supported by the Subscriber and Equipment Trace feature when
maximum trace depth is specified.
The RRC messages that are traced when the traceDepth parameter value is
“Maximum” are provided in Table 30. Note that some messages are not currently
supported for call trace. The subset of messages that are traced when the
traceDepth parameter value is “Minimum” are highlighted in blue and marked
with an “*”.
Message Name Relevant IE information
CSFBParametersRequestCDMA2000 (This message is not supported for LA6.0)
CSFBParametersResponseCDMA2000 RAND-CDMA2000
MobilityParametersCDMA2000
(This message is not currently supported)
CounterCheck (This message is not currently supported)
CounterCheckResponse (This message is not currently supported)
DLInformationTransfer
HandoverFromEUTRAPreparationRequest CDMA2000-Type
(CDMA2000)*
MeasurementReport MeasurementResult
MobilityFromEUTRACommand* Cs fallback indicator
Target RAT Type
ProximityIndication (This message is not currently supported)
RRCConnectionReconfiguration
RRCConnectionReconfigurationComplete
RRCConnectionReestablishment
RRCConnectionReestablishmentComplete
RRCConnectionReestablishmentReject Cause
RRCConnectionReestablishmentRequest* ReestablishmentCause
RRCConnectionReject* Wait time
RRCConnectionRelease* Release Cause
redirectionInformation
7
Table 28 is adapted from Reference [R01]a.[R18].
Page 261/308

RRCConnectionRequest* Establishment Cause
RRCConnectionSetup
RRCConnectionSetupComplete*
SecurityModeCommand
SecurityModeComplete
SecurityModeFailure Cause
UECapabilityEnquiry UE-CapabilityRequest
UECapabilityInformation* CapabilityRAT-ContainerList
UEInformationRequest (This message is not currently supported)
UEInformationResponse (This message is not currently supported)
ULHandoverPreparationTransfer (CDMA2000)* CDMA2000-Type
ULInformationTransfer* CDMA2000-Type
Table 30 : RRC Traced Messages
12.5.2 X2 MESSAGES
All the X2 messages that are call related and UE associated as specified in TS
36.423 are supported by the Subscriber and Equipment Trace feature when
maximum trace depth is specified.
The X2 messages that are traced when the traceDepth parameter value is
“Maximum” are provided in Table 31. Note that some messages are not currently
with an “*”.Note that Cause information is supplied when the traceDepth is
minimum, rather than Criticality Diagnostics.
Messages for Basic Mobility Procedures
HANDOVER REQUEST* Cause
E-RABs To Be Setup List
E-RAB Level QoS
GUMMEI
Target Cell ID
EU History Information
HANDOVER REQUEST ACKNOWLEDGE* E-RABs Admitted List
E-RABs Not Admitted List
Criticality Diagnostics
HANDOVER PREPARATION FAILURE* Cause
Page 262/308

SN STATUS TRANSFER* E-RABs Subject To Status Transfer List
UE CONTEXT RELEASE
HANDOVER CANCEL* Cause
Messages for Global Procedures
ERROR INDICATION Cause
(This message will be traced only for UE
related signaling.)
RLF INDICATION Failure cell PCI
Re-establishment cell ECGI
C-RNTI
HANDOVER REPORT Handover Cause
Source cell ECGI
Failure cell ECGI
Re-establishment cell ECGI
Table 31 : X2 Traced Messages
12.5.3 S1-AP MESSAGES

All the S1-AP messages that are call related and UE associated as specified in
TS 36.413 are supported by the Subscriber and Equipment Trace feature when
maximum trace depth is specified..
The S1AP messages that are traced when the traceDepth parameter value is
“Maximum” are provided in Table 32. Note that some messages are currently not
with an “*”.Note that Cause information is supplied when the traceDepth is
minimum, rather than Criticality Diagnostics.
E-RAB Management Messages

E-RAB SETUP REQUEST* UE Aggregate Maximum Bit Rate
E-RAB to be Setup List
E-RAB Level QoS Parameters
E-RAB SETUP RESPONSE* E-RAB Setup List
E-RAB Failed to Setup List
Page 263/308
E-RAB MODIFY REQUEST* E-RAB to be Modified List

E-RAB MODIFY RESPONSE* E-RAB Modify List
E-RAB Failed to Modify List
E-RAB RELEASE COMMAND* E-RAB to be Released List
UE Aggregate Maximum Bit Rate
NAS PDU
E-RAB RELEASE RESPONSE* E-RAB Release List
E-RAB Failed to Release List
E-RAB RELEASE INDICATION* E-RAB Released List
Context Management Messages
INITIAL CONTEXT SETUP REQUEST* Trace Activation
NAS-PDU
UE Radio Capability
E-RAB Level QoS Parameters
INITIAL CONTEXT SETUP RESPONSE* E-RAB Setup List
INITIAL CONTEXT SETUP FAILURE* Criticality Diagnostics
UE CONTEXT RELEASE REQUEST* Cause

UE CONTEXT RELEASE COMMAND* Cause
UE CONTEXT RELEASE COMPLETE Criticality Diagnostics
UE CONTEXT MODIFICATION REQUEST Security Key
CS Fallback Indicator
Subscriber Profile ID for RAT/Frequency
priority
UE CONTEXT MODIFICATION RESPONSE Criticality Diagnostics
UE CONTEXT MODIFICATION FAILURE* Cause
NAS Transport Messages
INITIAL UE MESSAGE* S-TMSI
E-UTRAN CGI
DOWNLINK NAS TRANSPORT
UPLINK NAS TRANSPORT* E-UTRAN CGI
NAS NON DELIVERY INDICATION* Cause
Page 264/308
Management messages
ERROR INDICATION MME UE S1AP ID
eNB UE S1AP ID
Cause
(This message shall be traced only for UE-
associated signaling)
S1 CDMA2000 Tunneling Messages
DOWNLINK S1 CDMA2000 TUNNELING* E-RABs Subject to Forwarding List
CDMA2000 HO Status
CDMA2000 RAT Type
(This message is not currently
supported)
UPLINK S1 CDMA2000 TUNNELING* CDMA2000 RAT Type
CDMA2000 Sector ID
CDMA2000 HO Required Indication
CDMA2000 1xRTT SRVCC Info
CDMA2000 1xRTT RAND
(This message is not currently
supported)
UE Capability Info Indication
UE CAPABILITY INFO INDICATION
Handover Signaling Messages

HANDOVER REQUIRED* Cause
Handover Type
Target ID
Direct Forwarding Path Availability
HANDOVER COMMAND* E-RABs Subject to Forwarding List
E-RAB to Release List
Handover Type
HANDOVER PREPARATION FAILURE* Criticality Diagnostics
HANDOVER REQUEST* Trace Activation
Cause
Handover Type
HANDOVER REQUEST ACKNOWLEDGE* E-RAB Admitted List
Page 265/308
HANDOVER FAILURE* Criticality Diagnostics

HANDOVER NOTIFY* E-UTRAN CGI
TAI
PATH SWITCH REQUEST* E-RABs to be Switched in Downlink List
E-UTRAN CGI
TAI
PATH SWITCH REQUEST ACKNOWLEDGE* UE Aggregate Maximum Bit Rate
E-RABs to be Switched in Uplink List
E-RAB to be Released List
PATH SWITCH REQUEST FAILURE* Criticality Diagnostics
HANDOVER CANCEL* Cause
HANDOVER CANCEL ACKNOWLEDGE Criticality Diagnostics
eNB STATUS TRANSFER
MME STATUS TRANSFER
Trace Messages
TRACE START Trace Activation
TRACE FAILURE INDICATION E-UTRAN Trace ID
Cause
DEACTIVATE TRACE E-UTRAN Trace ID
CELL TRAFFIC TRACE Trace Reference
Trace Recording Session Reference
Trace Collection Entity IP Address
Location Reporting Messages
LOCATION REPORTING CONTROL (This message is not currently supported)
LOCATION REPORT FAILURE INDICATION (This message is not currently supported)
LOCATION REPORT (This message is not currently supported)
LPPa Transport Messages
DOWNLINK UE ASSOCIATED LPPA Added by feature L103896 (ECID)

TRANSPORT
UPLINK UE ASSOCIATED LPPA Added by feature L103896 (ECID)
TRANSPORT
DOWNLINK NON UE ASSOCIATED LPPA Added by feature L101821 (OTDOA
TRANSPORT Hearability)
UPLINK NON UE ASSOCIATED LPPA Added by feature L101821 (OTDOA

TRANSPORT Hearability)
Table 32 : S1-AP Traced Messages

Page 266/308
12.5.4 ADDITIONAL TRACE FILE CONTENT

In addition to the messages that are listed in the previous sections, the eNB will
include additional data in the trace file so that a 3GPP compliant file can be
produced at the SAM. This data is shown in Table 33.
XML element / XML attribute specification
traceCollecFile
fileHeader fileFormatVersion
fileHeader vendorName
fileHeader
fileSender elementType
traceCollec beginTime
traceRecSession dnPrefix
traceRecSession traceSessionRef
traceRecSession
traceRecSessionRef
traceRecSession stime
ue idType
Ue
ue idValue
Msg function
Msg changeTime
Msg
traceRecSession
vendorSpecific
Msg name
Initiator initiator type
Msg Target target type
rawMsg
rawMsg protocol
rawMsg version
ieGroup name
ieGroup
ieGroup value
Ie ie name
Table 33 : Non-Signaling Data Included in File for Subscriber and Equipment Trace
To support the above XML file attributes, in addition to the traced messages (msg
name) the eNB will also include the parameters shown in Table 34 in the binary
stream that is sent to the SAM.
Page 267/308
Attribute/Parameter Name Description Note
Trace Reference MCC+MNC(3 octets eNB will combine the

total)+TRACE_ID(3 octets) received Trace ID from SAM
(for management trace) with
MCC and MNC as the Trace
Reference. For signaling
based trace, Trace
Reference is received in the
Trace Activation IE.
Trace Recording Session Unique ID within a given Trace

Reference Session (2 octets)
SenderName eNB UniqueName
rawMsgprotocol Message Protocol, e.g. S1AP, eNB will provide message

X2AP, or RRC protocol information for each
traced message.
rawMsgversion Attribute specification that eNB will provide message

provides the protocol version. protocol version for each
traced message.
Protocol version is the last 3
digits of the protocol
specification used by 3GPP
for S1AP, X2AP and RRC,
e.g. report “860” for X2AP
V8.6.0.
msgfunction Attribute specification that eNB will provide the

provides the function name message function (interface
associated to the traced name: S1-MME, X2, Uu) for
message. each traced message.
msg changeTime Attribute specification that Currently the value for

provides the time difference changeTime will always be
with attribute specification
"traceCollecbeginTime". It is zero.
expressed in number of
seconds and milliseconds
(nbsec.ms).
Table 34 : Additional Data Included in File for Subscriber and Equipment Trace
12.5.5 POST PROCESSING OF CALL TRACE DATA

Call trace data is collected on both SAM and the MME in 3GPP standardized
format. Typically a post processing tool is used to pull the data from the individual
servers where it is stored and to analyze the data. Since the data format is
standardized, data analysis tools are potentially available from several vendors.
ALU offers a version of the eDAT (Enhanced Data Analysis Tool) that can be
Page 268/308
used for this analysis. The post processing tools are beyond the scope of this
document.
12.5.6 ENODEB SNAPSHOTS AND DEBUG TRACES

(DYNAMIC)
Feature L108879 (eNb snapshots and debug traces) allows “On-demand”
snapshot and debug traces activation. It is an OMC feature which allows better
eNb investigation in case of failure. An eNB on-demand snapshot is a human-
readable file useful for the customer punctual investigation of the failure of a
telecom (call or cell related) service outage (partial or total). The eNB transmit the
Dynamic debug trace automatically when generated, using same collection
mechanism for Dynamic debug trace than call trace
Both processes are automatically inhibited in case of overload. Thresholds are set
by following parameters:
ovLevelForDDTInhibition- This parameter specifies the level of overload at
which the Dynamic Debug Trace function will be inhibited.
OverloadControl:: ovLevelForDDTInhibition
Parameter ovLevelForDDTInhibition
Enumerate
Range & Unit Minor(0), Major(1), Critical(2)
Value Minor
Feature L115241
ovLevelForDTInhibition- This parameter specifies the level of overload at which

the Debug Snapshot function will be inhibited.
OverloadControl:: ovLevelForDTInhibition
Parameter ovLevelForDTInhibition
Enumerate
Range & Unit Minor(0), Major(1), Critical(2)
Value Minor
Feature L115241
Page 269/308
Page 270/308
13 PER CALL MEASUREMENT DATA (PCMD)

Alcatel-Lucent provides a proprietary PCMD solution for LTE. With the ALU
solution, the PCMD feature is controlled from the MME and data is collected both
at the MME and each of the eNBs that are associated with the MME. Since this
solution is proprietary, only ALU MMEs and eNBs support the PCMD feature. The
PCMD description provided here is a summary, primarily from a RAN perspective.
A much more extensive treatment of the PCMD feature can be found in [R16].
When PCMD is enabled at an MME, data is collected (a PCMD record is created)
for each call that involves that MME. Examples of triggering events include
Attach, Service Request, S1 Release, Handover, Detach, etc.
Each PCMD record captures the following:
• Signaling performance on per UE, per bearer level by indicating the
procedure disposition codes (Final Class, Final Class Qualifiers)
• User experience such as, data throughput and procedure setup duration
• eNB internal data such as, MIMO decision, SINR, Buffer Size, and
normalized power headroom
• UE Measurements
PCMD can be enabled at the MME via an EMS or Provisioning CLI/GUI
command.
PCMD must be enabled for an eNB by an activation parameter (See Section
13.2) that is controlled by the SAM.
To collect PCMD data at both an MME and the associated eNBs, the PCMD
feature has to be enabled at both the MME and the associated eNBs. When the
eNB activation parameter is enabled, the eNB informs each MME with which it is
associated that it is PCMD-capable and the MME adds the PCMD capable eNB
to its PCMD contact list.
When a PCMD job is started at the MME, the MME informs all PCMD capable
eNBs with which it has an association that the eNB should also start PCMD
collection. The Alcatel-Lucent eNB notes which MMEs send this notification, and
thereby identifies the Alcatel-Lucent MMEs for which the eNB is to collect PCMD.
Likewise, when PCMD is stopped at an MME, the MME notifies the associated
PCMD capable eNBs to stop PCMD collection.
If PCMD is active at an eNB (that is, the eNB is collecting PCMD data for one or
more MMEs), then when a “send-record” trigger occurs at the Alcatel-Lucent eNB
for a UE that is handled by an Alcatel-Lucent MME, the Alcatel-Lucent eNB sends
its collected data to the associated MME. The eNB uses a Private message in the
S1-MME interface for this transmission, and the MME integrates the eNB PCMD
data into the record being kept at the MME.
When a send-trigger occurs at the MME, the UE PCMD record, including the eNB
information (if received from the eNB), is saved on a local disk.
The files saved on the MME can be pulled by a remote PCMD Collector Host
(either in near real time or later) using a secure protocol, so the files can be
retained for a long period of time by the remote PCMD Collector Host. A post-
processing PCMD analysis program can then access all records pertaining to
each supported LTE procedure performed by the UE. Each PCMD record
Page 271/308
contains data collected by the MME and data collected by the eNB (if eNB
collection is enabled), so there is no need for the post-processing tool to do
additional work to correlate eNB and MME records!
Figure 63 gives a high level overview of the processes that are described above.
XMS/Netconf eNB MME

SAM/Netconf
PCMD Feature enabled

IsPCMDenabled = True
PCMD-Capable
PCMD-Start
eNB PCMD-start trigger occurs
eNB starts collecting

PCMD data
MME integrates eNB

PCMD data into PCMD
eNB PCMD-send trigger occurs
record
PCMD_data
PCMD
Collection
Host
MME PCMD-send trigger occurs
MME writes PCMD record

to disk and/or realtime port
PCMD files are pulled by

the remote PCMD Collector
Host.
PCMD-Stop
eNB stops collecting

PCMD data
Figure 63: PCMD Data Collection Diagram
Page 272/308
13.1 PCMD AT THE MME

At the MME, PCMD can be enabled from the PCMD GUI as described in
Reference [R14]. A sample of the GUI from that reference is included in below
figured.
Figure 64: MME GUI for PCMD
From this screen, the user can provide a unique PCMD job name and can enable
or disable PCMD.
In addition, if the “Enable CM Report” box is checked when the PCMD Enable box
is checked, then UE Measurement Report data will be recorded from all
associated eNBs for which PCMD is enabled (by configuration data received from
SAM). If the “Enable CM Report” box is unchecked when PCMD is enabled, then
the UE Measurement Report data will be collected from the associated eNBs for
which PCMD is enabled, but it will be discarded and will not be included in the
PCMD data file.
13.2 PCMD AT THE ENB

PCMD is enabled for the eNB by setting the value of parameter isPCMDEnabled
equal to “True” from SAM.
Page 273/308
ActivationService::isPCMDEnabled
Parameter isPCMDEnabled
False; True
Value False
Feature L111447
This PCMD optional feature is managed by Feature Licensing (refer to LPUG

[Vol. 1]for details). This parameter can be set to 'True' only if licensing (Tokens)
are available for the feature. The total number of activations for each feature is
counted across all eNBs by SAM.
If the isPCMDEnabled parameter value is “True”, then the eNB PCMD status is
“pcmd capable”. If the value of parameter isPCDMEnabled is “False”, then the
eNB PCMD status is “pcmd incapable”. The eNB sends its PCMD status (either
“pcmd-capable” or “pcmd-incapable”) to the MME when the value of this
parameter is changed by the SAM, and it resends its PCMD status whenever it
needs to re-setup the S1 connection with an MME. This might occur, for example,
if the eNB is re-initialized for any reason.
Note: The purpose of this operation is to insure that the PCMD status is
consistent between the eNB-and the MME.
The overload level of the eNB can also affect PCMD data collection. A parameter,
ovLevelForPCMDInhibition, controls the overload level (minor, major, or critical)
at which the PCMD function is inhibited for the duration of the overload condition.
See Section 8 of this volume for additional information about overload control.
OverloadControl::ovLevelForPCMDInhibition
Parameter ovLevelForPCMDInhibition
Class/Source C--Immediate-propagation /
system_restricted
Value Critical
Feature L115241
Each eNB can have an S1 connection with multiple MMEs simultaneously. If the
eNB PCMD feature is activated by SAM (isPCMDEnabled= “True”), then:
• The eNB constructs a “PCMD-Participating” MME list to keep track of the
MMEs to which it is to send collected PCMD data.
Page 274/308
• The eNB informs all the MMEs with which it has an S1 association that it
is either “pcmd-capable” (or “pcmd-Incapable” if the parameter value was
set to “False”) via S1-AP PrivateMessage. The “pcmd-capable” or “pcmd-
Incapable” PrivateMessage will be sent following each S1 Setup
procedure.
• When the eNB receives an S1 PrivateMessage from an MME that
indicates that PCMD data collection is to start, then a PCMD capable eNB
will add the MME from which it received that indication to its “PCMD-
Participating” MMEs (S1 connections) list.
If the eNB is PCMD capable, and the MME starts PCMD collection, then the eNB
will start collecting PCMD data:
• Whenever any of the PCMD Start Collection triggers occurs (see Section
13.2 for details)
• Only for those UEs that are handled by the MMEs that are in the “PCMD-
Participating” MME list. The eNB will not collect PCMD data for any other
UEs.
If a “pcmd incapable” eNB receives a message from an MME to start PCMD data
collection, it will respond to the MME with a message indicating that it is “PCMD
incapable”. This is done to synchronize the eNB PCMD status with the MME.
When the eNB receives an indication to stop PCMD data collection from an MME,
it removes that MME from its list of participating MMEs, stops collecting data for
UEs that are associated with that MME, and discards any unsent data that has
been collected for those UEs.
New activation flag is added in LR13.3 to activate feature 171159 (PCMD
enhancement - step2)
ActivationService:: isPCMDorTraceMREnabled
Parameter isPCMDorTraceMREnabled
Class/Source C--Immediate-propagation /
system_reserved
Value False
Feature 171159
This parameter enables A4 event trigger for measurement reports for PCMD or
CT/DDT traces. New measurement report configuration will be requested when
the UE connects to the cell for A4 Measurement Reports (RSRQ, RSRP).
PCMD or CT or DDT must be enabled before isPCMDorTraceMREnabled can be

set to “true”.
Page 275/308
13.2.1 PCMD START COLLECTION TRIGGERS

PCMD data are collected on each eNB cell for the UEs that are controlled a
“participating MME” (an MME from which the eNB has received a “pcmd-start”
indication). The eNB cell starts collecting each UE’s PCMD data whenever any of
the following PCMD Start collection triggers occur:
• Initial UE context is setup
• RRC connection reconfiguration is complete
• RRC connection reestablishment request
13.2.2 PCMD SEND DATA TRIGGERS

The eNB cell sends collected PCMD data to the MME that controls the UE
session whenever any of the following PCMD Send triggers occurs:
• UE Context Release Complete

• Inter-Cell handover on same eNB
• Inter-eNB handover. The PCMD request is forwarded, and the data that
has been collected is sent to the MME.
Even though the UE Context Release Complete message is a PCMD-send
trigger, the PCMD data is sent prior to sending the UE Context Release Complete
message to MME.
13.2.3 PCMD PARAMETERS

PCMD parameters that are reported by the eNB are divided into the following
categories:
• Per UE Connection or Context Parameters
These parameters are reported for each UE connection and there is only one
instance of this type of parameters in each eNB PCMD record to be sent to the
MME.
• Per Bearer Parameters
o These parameters are reported for each UE bearer. This means
each bearer record will contain only one instances of this type of
parameters. There may be multiple instances of this type of
parameters in each eNB PCMD record (at least one).
• UE Measurements
o Up to two sets of UE Measurements are collected in each PCMD
record. One is at the beginning of the call (when UE is accessing
the eNB) and the other one is collected when the UE session is
ended or handed over to another eNB.
Page 276/308
• Call Final Class / Call Final Class Qualifier / Secondary Call Final Class
Qualifier
o CFC / CFCQ / SCFCQs are UE Context disposition and they are
provided by the eNB at the end of the call or before sending
eNB’s PCMD record to the MME. There is only 1 set of (CFC,
CFCQ, SCFCQ) in each eNB PCMD record.
• Figure 65 shows the eNB PCMD record content and how data from the
eNB and the MME are interleaved.
Figure 65: PCMD Record Formation and Content
Not all the parameters defined are measured /collected during each PCMD
collection interval. For those parameters that are not collected eNB does not send
the data to MME, and MME will report null in the PCMD output file.
Note: The UE measurement parameters are optional parameters. The operator

can configure to include or not include these parameters in the final PCMD record
by checking or unchecking the “Enable CM Report” box on the MME PCMD
Configuration Screen (see Section 13.1). However, the eNB will always report
these parameters to the MME then the MME determines whether to include these
parameters in the record based on the operator’s input.
UE Measurements are the measurement results received from the UE via RRC
MeasurementReport message. There can be 0 or more MeasurementReport
messages received during the PCMD collection interval. Only the measurement
results reported in the first and last MeasurementReport message are included in
the PCMD data. Each MeasurementReport message may contain measurement
results for 1 to 8 cells.
Currently, only measurement results for intra-frequency Measurement Report are

recorded in the PCMD data.
Page 277/308
The mode for PCMD data delivery can be set using parameter pcmdMode.
Enb::pcmdMode
Parameter pcmdMode
None(0), Traditional-PCMD(1), CallTrace-
based-PCMD(2)
Value False
Feature L111447
This parameter cannot be set to Traditional-PCMD or CallTrace-based-PCMD

unless ActivationService.isPCMDenabled is set to True.
When set, the call trace mechanism utilizing a UDP stream of UPOS messages
will be used to transport the eNB PCMD data to the trace collection entity in
standards based call trace message with proprietary extensions. Operators will be
able to enable call trace to include data collected for PCMD. eNB PCMD data that
is transported via CT will not be correlated with MME PCMD data
A detailed treatment of the individual parameters that are recorded in the PCMD
files is beyond the scope of LPUG. The interested reader is referred to [R16].
Restriction: PCMD round trip delay data
For any cell that is associated with a Distributed Antenna System (DAS), PCMD
over-the-air (OTA) round trip delay (RTD) data is not reliable if there are
antennas distributed over a geographic area or if the total fiber length exceeds
15 km. This is because of the uncertainty of the antenna position.
13.2.4 171159 PCMD ENHANCEMENT - STEP2

This feature provides enhancements to the PCMD functionality delivered in earlier
releases. The goal is to drive towards delivering those requirements that were
deferred from earlier releases plus adding additional functionality to increase the
value and usability of PCMD for the customer.
Feature 171159 provides the following improvements:

• Reporting additional L1/L2 parameters
• Adding new PCMD parameters to aid in the detection and debugging of
radio link failures (RLF)
• Enhancing the ability to more accurately calculate UE location by
providing more accurate RTD by updating the unit (Ts) and accuracy (+-
2Ts) of existing RTD parameters. In addition, a new measurement report
configuration will be requested when the UE connects to the cell for A4
Measurement Reports (RSRQ, RSRP).
Page 278/308
• Adding parameters to provide PRB usage

• Adding new Buffer size related PCMD records for VoIP-GBR to aid in
debugging of VoLTE issues.
The enhancements to the PCMD functionality provides additional means by which

operators can troubleshoot network issues including UE performance based on
the information received.
PCMD:
• enables operators to quickly respond to customer trouble tickets and
support the reduction of drive testing significantly reducing RF
Optimization and engineering costs.
• Enhances the ability to pinpoint UE location when debugging call drops or
HO failures
• Enhances ability to troubleshoot RLF and HO issues.
Alcatel-Lucent PCMD functionality depends on the ALU MME having the PCMD
feature enabled. In addition, for some new PCMD fields, the following features
must be activated for the data to be available in PCMD.
Feature/Parameter Name Available Metrics Parameters

L115361 RLF Indication
ActivationService:: ECGI of Re-establishment cell
sRlfMonitoringAllowed
162790 badInitialDlMacPduSps
ActivationService:: badResidualDlMacPduSps
isSpsConfigAllowed badInitialUlMacPduSps
badResidualUlMacPduSps
maxDlInitialMacBLERSps
maxDlResidualMacBLERSps
maxUlInitialMacBLERSps
maxUlResidualMacBLERSps
aveMcsMaxDlResidualBlerSpsReached)
162790 aggrBufferSizeVoIPGBR
RadioCacCell:: isKbytesBufferSizeVoIPGBR
maxNbrOfVoip > 0 numSamplesVoIPGBRLCG
Restriction: Support of SPS related metrics and setting of

isSpsConfigAllowed
Described metrics in above table related with 162790 are in restriction for
LR13.X and therefore shouldn’t be taken in account.
For more information regarding this parameter and feature refer to [Vol. 4].
Page 279/308
Parameter Name Description

Radio Link Failure Indication
RLFindication Format: Integer (0..255), Size: 1 bytes, Unit: n/a
ReestablishmentC Cell ID of re-establishment cell in the Target eNB
ellID Format: EUTRAN CGI, Size: 7 bytes, Unit: n/a
badInitialDlMacPd Bad Initial DL Initial MAC PDU for the Dynamic Scheduler
uDs Format: integer (0-65535), Size: 2 bytes, Unit: PDU
badResidualDlMa Bad Residual DL Initial MAC PDU for the Dynamic Scheduler
cPduDs Format: integer (0-65535), Size: 2bytes, Unit: PDU
Bad Initial UL Initial MAC PDU for the Semi-Persistent
badInitialUlMacPd Scheduler
uSps Format: integer (0-65535), Size: 2 bytes, Unit: PDU
Bad Residual UL Initial MAC PDU for the Semi-Persistent
badResidualUlMa Schedule
cPduSps Format: integer (0-65535), Size: 2 bytes, Unit: PDU
Bad Initial DL Initial MAC PDU for the Semi-Persistent
badInitialDlMacPd Scheduler
uSps Format: integer (0-65535), Size: 2 bytes, Unit: PDU
Bad Residual DL Initial MAC PDU for the Semi-Persistent
badResidualDlMa Scheduler
cPduSps Format: integer (0-65535), Size: 2 bytes, Unit: PDU
Maximum DL Initial MAC BLER Semi-Persistent Scheduler
maxDlInitialMacB Format: integer (0..10000), Size: 2 bytes, Unit: percentage *
LERSps 100
Maximum DL Residual MAC BLER Semi-Persistent
Scheduler
maxDlResidualMa Format: integer (0..10000), Size: 2 bytes, Unit: percentage *
cBLERSps 100
Maximum UL Initial MAC BLER Dynamic Scheduler
maxUlInitialMacB Format: integer (0..10000), Size: 2 bytes, Unit: percentage *
LERSps 100
Maximum UL Residual MAC BLER Semi-Persistent
Scheduler
maxUlResidualMa Format: integer (0..10000), Size: 2 bytes, Unit: percentage *
cBLERSps 100
Average MCS for the last transmissions scheduled by SPS
aveMcsMaxDlRes that failed
didualMacBLERS Format: integer (0..10000), Size: 2 bytes, Unit: percentage *
ps 100
Total DL PRBs consumed by the user Including
retransmissions
totalDlPRBsUsed Format: Integer (0 – 2^32-1), Size: 4 bytes, Unit: PRBs
Total UL PRBs consumed by the user Including
retransmissions
totalUlPRBsUsed Format: Integer (0 – 2^32-1), Size: 4 bytes, Unit: PRBs
Total UL TTIs Scheduled for the UE including
totalULTTIsUeSch retransmissions
ed Format: Integer (0 – 2^32-1), Size: 4 bytes, Unit: TTIs
First RTD calculated with SRS/PUSCH timing adjustments
Format: Integer (0 .. 65535), Size: 2 bytes, Unit: Ts,
firstRTDPUSCH Accuracy: +-2Ts
This parameter indicates the aggregate value of buffer size
reported
by the UE for VoIP GBR Logical Channel Group (LCG).
aggrBufferSizeVoI Format: Integer, INTEGER (0 .. 4294967295) Unit: byte or
PGBR kbyte
Page 280/308
This parameter indicates whether the aggregate buffer size

value
isKbytesBufferSiz is in Kbytes for VoIP GBR Logical Channel Group (LCG).
eVoIPGBR Format: Integer (enumeration), Size: 1 byte, Unit: n/a
This parameter indicates total number of samples included in
the
numSamplesVoIP aggregate VoIP GBR LCG Buffer Size calculation
GBRLCG Format: Integer, INTEGER (0 .. 4294967295)Unit: n/a
Page 281/308
14 PERFORMANCE MONITORING PARAMETERS

Performance monitoring data (counters) are periodically generated by each
eNodeB and can then be retrieved by the PM Server. The period at which the
eNodeB generates the counter values file is controlled by the
pmcGranularityPeriod parameter.
pmcGranularityPeriod parameter gives the period with which the eNodeB
generates Performance Management (PM) files that can be retrieved by the PM
Server.
ENBEquipment::pmcGranularityPeriod
Parameter pmcGranularityPeriod
Object ENBEquipment
Enumerate
Range & Unit
5minutes, 15minutes, 30minutes, 60minutes
Class/Source N.A. 8 / eng_tunable
Value 15 minutes
Feature
Figure 66: SAM Performance Management Screen showing

pmcGranularityPeriod Parameter Value (15 minutes)
Typically all eNBs in an area will have the same value for pmcGranularityPeriod
parameter. During periods of troubleshooting or other testing, the value of this
parameter for specific eNBs may be changed to facilitate the testing efforts.
8
This parameter is not a configuration parameter in the usual sense, and changes in value are sent to the
eNB using a different mechanism than the one that is normally used for configuration parameters. Thus, the
usual definition of Class does not apply to this parameter. The value of this parameter can be modified
without requiring an eNB reset.
Page 282/308
Feature L115220 adds the capability to provide a standardized timeZoneName

parameter value for each eNodeB. The timeZoneName parameter is described in
[Vol. 5]. The value of this parameter can be used to convert the UTC time used
within the eNB to local time and the local time can then be used in is described in
[Vol. 5]. The value of this parameter can be used to convert the UTC time used
within the eNB to local time and the local time can then be used in defining
performance monitoring file names. Note that in Release LA6.0, Feature 131966
(eNB Time Zone Management for FM Files) also allows the eNB to report alarms,
events, and state changes with eNB local based on the value of the
timeZoneName parameter.
With each new release additional performance monitoring counters are added. In
order to manage the increasing number of counters, Feature L103175/L103175.1
(Performance Counter Management Support on eNB) provides the operator with
the ability to allow or suppress including groups of parameters in the report that is
periodically sent to SAM. A base group of counters is always reported, but
currently the following groups of counters can be included in the report or
suppressed (based on the setting of parameter values as described later):
• customerSpare1
• customerSpare2
• geranOrUtran
• hRPDor1xRTT
• MBMS
• mobilityFailure
• pDV
• per PRB Measurements
• rrcConnection
• serviceFailure
• spare1
• spare2
• specificFDD
• trafficShaping
• uEContext
• uLNoise
Refer to reference [R17] for information concerning which specific counters are
included in each report group. The reporting or not reporting of each report group
is controlled by a series of parameter values as described in the following
sections.
The report groups can be divided into three sections for determination of how they
are handled.
Page 283/308
Section 1 – Individual operator determines if the report group is to be reported.

These report groups are:
• mobilityFailure
• pDV
• per PRB Measurements
• rrcConnection
• uEContext
• uLNoise
• customerSpare1
• customerSpare2
• spare1
Section 2 – A WPS check determines if the report group is to be reported based

on the activation of optional features, and sets the appropriate parameter value.
These report groups are:
• geranOrUtran
• hRPDor1xRTT
• MBMS
• serviceFailure
• spare2
• specificFDD
• trafficShaping
csfbTo1XRttReported - parameter specifies whether, or not, the group of

counters related to CsfbTo1XRtt is selected to be reported.
PerformanceManagement::csfbTo1XRttReported
Parameter csfbTo1XRttReported
Object ENBEquipment/Enb/PerformanceManagement
Boolean
Range & Unit True, False
Value False
Feature 134791
Page 284/308
carrierAggregationReported- This parameter specifies whether, or not, the

group of counters related to Carrier Aggregation is selected to be reported.
PerformanceManagement:: carrierAggregationReported
Parameter carrierAggregationReported
Boolean
Value False
Feature 160847
customerSpare1Reported - parameter specifies whether, or not, the group of

counters related to customerSpare1 is selected to be reported.
PerformanceManagement::customerSpare1Reported
Parameter customerSpare1Reported
Boolean
Value False
Feature L103175.1

counters related to CustomerSpare2 is selected to be reported.
Boolean
Value False
Feature L103175.1

counters related to spare3Reported is selected to be reported.
Page 285/308
Boolean
Value False
Feature N/A

Boolean
Value False
Feature N/A

Boolean
Value False
Feature N/A
daisyChainingReported - parameter specifies whether, or not, the group of

counters related to DaisyChaining is selected to be reported.
Page 286/308
PerformanceManagement::daisyChainingReported
Parameter daisyChainingReported
Boolean
Class/Source C--Immediate-propagation / system_ restricted
Value False
Feature L92072
eCICabsGenerationReported - parameter specifies whether, or not, the group of

counters related to ECICabsGeneration is selected to be reported.
PerformanceManagement::eCICabsGenerationReported
Parameter eCICabsGenerationReported
Boolean
Value False
Feature 159538
enhancedAnrReported - parameter specifies whether, or not, the group of

counters related to EnhancedAnr is selected to be reported.
PerformanceManagement::enhancedAnrReported
Parameter enhancedAnrReported
Boolean
Value False
Feature f
Note: Reporting of enhancedAnrReported counters can only be executed if and
only if ActivationService::lteIntraFrequencyAnrEnabled = TRUE
geranOrUtranReported - parameter specifies whether, or not, the group of

counters related to GeranOrUtran is selected to be reported.
Page 287/308
PerformanceManagement::geranOrUtranReported
Parameter geranOrUtranReported
Boolean
False ALU recommends that the operator not change this
Value value
Feature L103175.1
Rule: geranOrUtranReported parameter
If the value of either of these parameters:

• isMobilityToGeranAllowed
• isMobilityToUtranAllowed
is equal to “True”, then the system will set the value of the
geranOrUtranReported parameter equal to “True” and report the associated
counters.
highPriorityAccessUserMgmtReported - parameter specifies whether, or not,

the group of counters related to HighPriorityAccessUserMgmtis selected to be
reported.
PerformanceManagement::highPriorityAccessUserMgmtReported
Parameter highPriorityAccessUserMgmtReported
Boolean
Value False
Feature L115860
hRPDor1xRTTReported - parameter specifies whether, or not, the group of

counters related to HRPDor1xRTT is selected to be reported.
Page 288/308
PerformanceManagement::hRPDor1xRTTReported
Parameter hRPDor1xRTTReported
Boolean
Value value
Feature L103175.1
Rule: hRPDor1xRTTReported parameter
If the value of either of these parameters:

• isMobilityToHrpdAllowed
• isCsfbTo1xRttForDRxUEallowed
is equal to “True”, then the system will set the value of the
hRPDor1xRTTReported parameter equal to “True” and report the associated
counters.
inactivityBasedDrxReported - parameter specifies whether, or not, the group of

counters related to InactivityBasedDrx is selected to be reported.
PerformanceManagement::inactivityBasedDrxReported
Parameter inactivityBasedDrxReported
Boolean
Value False
Feature L101843
interFreqEutraOtherFrameStructureMobilityReported - parameter specifies

whether, or not, the group of counters related to
InterFreqEutraOtherFrameStructureMobility is selected to be reported.
Page 289/308
PerformanceManagement::interFreqEutraOtherFrameStructureMobilityRepo
rted
Parameter interFreqEutraOtherFrameStructureMobilityReported
Boolean
Value False
Feature L101815
intraFreqMobilityToOpenMetroCellMobilityToHeNBReported - parameter
specifies whether, or not, the group of counters related to
SpeedDependentMobilityHomeCellsMobility is selected to be reported.
PerformanceManagement::intraFreqMobilityToOpenMetroCellMobilityToHeN
BReported
Parameter intraFreqMobilityToOpenMetroCellMobilityToHeNBReported
Boolean
Value False
Feature L115705
intraFreqMobilityToOpenMetroCellReported - parameter specifies whether, or

not, the group of counters related to SpeedDependentMobility is selected to be
reported.
PerformanceManagement::intraFreqMobilityToOpenMetroCellReported
Parameter intraFreqMobilityToOpenMetroCellReported
Boolean
Value False
Feature L115705
ipFilteringReported - parameter specifies whether, or not, the group of counters

related to IpFiltering is selected to be reported.
Page 290/308
PerformanceManagement::ipFilteringReported
Parameter ipFilteringReported
Boolean
Value False
Feature L114382
mbmsReported parameter specifies whether, or not, the group of counters

related to MBMS is selected to be reported.
PerformanceManagement::mbmsReported
Parameter mbmsReported
Boolean
Value value
Feature L103175.1, L115691
Rule: mbmsReported parameter
If the value of the isMbmsBroadcastModeAllowed parameter is equal to

“True”, then the system will set the value of the mbmsReported parameter
equal to “True” and report the associated counters.
In order for the mbmsReported to be reported:
• isMbmsBroadcastAllowedmust be true.
• isMbmsBearerServiceCountingAllowedmust be set for a single cell.
• isMbmsBearerServiceCountingEnabled must be set for a single
MBSFN area.
mceReported - parameter specifies whether, or not, the group of counters related

to Mce is selected to be reported.
Page 291/308
PerformanceManagement::mceReported
Parameter mceReported
Boolean
Value False
Feature L115262
mobilityFailureReported - parameter specifies whether, or not, the group of

counters related to MobilityFailure is selected to be reported.
PerformanceManagement::mobilityFailureReported
Parameter mobilityFailureReported
Boolean
Value O.D.
Feature L103175.1
mobilityFromHetNetCell- This parameter specifies whether, or not, the group of

counters related to MobilityFromHetNetCell is selected to be reported.
PerformanceManagement:: mobilityFromHetNetCell
Parameter mobilityFromHetNetCell
Boolean
Value False
Feature 170745
mobilityToHeNBReported - parameter specifies whether, or not, the group of

counters related to HomeCellsMobility is selected to be reported.
Page 292/308
PerformanceManagement::mobilityToHeNBReported
Parameter mobilityToHeNBReported
Boolean
Value False
Feature 134689
mobilityToHetNetCell- This parameter specifies whether, or not, the group of

counters related to MobilityFromHetNetCell is selected to be reported.
PerformanceManagement:: mobilityToHetNetCell
Parameter mobilityToHetNetCell
Boolean
Value False
Feature 170745
mobilityToUtranCsgSmallCellReported - parameter specifies whether, or not,

the group of counters related to mobilityToUtranCsgSmallCell is selected to be
reported.
PerformanceManagement::mobilityToUtranCsgSmallCellReported
Parameter mobilityToUtranCsgSmallCellReported
Boolean
Value False
Feature L115393
mobilityToUtranOpenSmallCellReported - parameter specifies whether, or not,

the group of counters related to mobilityToUtranOpenSmallCell is selected to
be reported.
Page 293/308
PerformanceManagement::mobilityToUtranOpenSmallCellReported
Parameter mobilityToUtranOpenSmallCellReported
Boolean
Value False
Feature L115393
mroIntraFreqReported - parameter specifies whether, or not, the group of

counters related to MroIntraFreq is selected to be reported.
PerformanceManagement::mroIntraFreqReported
Parameter mroIntraFreqReported
Boolean
Value False
Feature L103177
nonGbrMinRateReported - parameter specifies whether, or not, the group of

counters related to NonGbrMinRate is selected to be reported.
PerformanceManagement::nonGbrMinRateReported
Parameter nonGbrMinRateReported
Boolean
Value False
Feature L115698
pDVReported - parameter specifies whether, or not, the counter Report Group

PDV is selected to be reported. These counters are related to Precision Time
Protocol (PTP) synchronization, and, more specifically, Packet Delay Variation
(PDV). See TEG [R04] for more information about PTP.
Page 294/308
PerformanceManagement::pDVReported
Parameter pDVReported
Boolean
Value O.D.
Feature L103175.1
perPRBMeasurementReported - parameter specifies whether, or not, the group

of counters related to perPRBMeasurement is selected to be reported.
PerformanceManagement::perPRBMeasurementReported
Parameter perPRBMeasurementReported
Boolean
Value O.D.
Feature L103175.1
pMCounterEnhancementReported - parameter specifies whether, or not, the
group of counters related to PMCounterEnhancement is selected to be reported.
PerformanceManagement::pMCounterEnhancementReported
Parameter pMCounterEnhancementReported
Boolean
Value False
Feature 162426
portRedundancyReported - parameter specifies whether, or not, the group of

counters related to PortRedundancy is selected to be reported.
Page 295/308
PerformanceManagement::portRedundancyReported
Parameter portRedundancyReported
Boolean
Value False
Feature L112785
qam64Reported - parameter specifies whether, or not, the group of counters

related to 64QAMis selected to be reported.
PerformanceManagement::qam64Reported
Parameter qam64Reported
Boolean
Value False
Feature L103175.1
qciArpOnLineModificationReported - parameter specifies whether, or not, the

group of counters related to QciArpOnLineModification is selected to be
reported.
PerformanceManagement::qciArpOnLineModificationReported
Parameter qciArpOnLineModificationReported
Boolean
Value False
Feature L115644
rrcConnectionReported - parameter specifies whether, or not, the group of

counters related to RrcConnection is selected to be reported.
Page 296/308
PerformanceManagement::rrcConnectionReported
Parameter rrcConnectionReported
Boolean
Value O.D.
Feature L103175.1
Rule: rrcConnectionReportedparameter
"If ((rRCConnectionReported == TRUE) OR (spare1Reported == TRUE))

Then
rRCConnectionReported = TRUE
Else
rRCConnectionReported = FALSE"
s1UsageOptimizationReported - parameter specifies whether, or not, the group

of counters related to S1UsageOptimizationis selected to be reported.
PerformanceManagement::s1UsageOptimizationReported
Parameter s1UsageOptimizationReported
Boolean
Value False
Feature 158785
serviceFailureReported - parameter specifies whether, or not, the counters

related to ServiceFailure group is selected to be reported.
Page 297/308
PerformanceManagement::serviceFailureReported
Parameter serviceFailureReported
Boolean
Value
value
Feature L103175.1
spare1Reported - parameter specifies whether, or not, the group of counters

related to Spare1 is selected to be reported.
PerformanceManagement::spare1Reported
Parameter spare1Reported
Boolean
Value O.D.
Feature L103175.1

related to Spare2 is selected to be reported.
Boolean
Value
value
Feature L103175.1
Rule: spare2Reported parameter
If the value of the Enb::spare12, bit 1 parameter = “1”, then a WPS check will
set the value of the spare2Reported parameter equal to “True” and report the
associated counters. These parameters are related to transport feature
L112791, which provides additional transport-related performance management
Page 298/308
counters.

related to spare3Reportedis selected to be reported.
Boolean
Value False
Feature N/A

Boolean
Value False
Feature N/A

Boolean
Value False
Feature N/A
Page 299/308
speedDependentMobilityHomeCellsMobilityReported - parameter specifies

whether, or not, the group of counters related to
SpeedDependentMobilityHomeCellsMobility is selected to be reported.
PerformanceManagement::speedDependentMobilityHomeCellsMobilityRepo
rted
Parameter speedDependentMobilityHomeCellsMobilityReported
Boolean
Value False
Feature L115705
speedDependentMobilityReported - parameter specifies whether, or not, the

group of counters related to SpeedDependentMobility is selected to be reported.
PerformanceManagement::speedDependentMobilityReported
Parameter speedDependentMobilityReported
Boolean
Value False
Feature L115705
spsConfigReported - parameter specifies whether, or not, the group of counters

related to SpsConfig is selected to be reported.
Page 300/308
PerformanceManagement::spsConfigReported
Parameter spsConfigReported
Boolean
Value False
Feature 162790
srvccToGeranReported - parameter specifies whether, or not, the group of

counters related to SrvccToGeran is selected to be reported.
PerformanceManagement::srvccToGeranReported
Parameter srvccToGeranReported
Boolean
Value False
Feature L101819
trafficShapingReported - parameter specifies whether, or not, the group of

counters related to uplink Traffic Shaping is selected to be reported.
PerformanceManagement::trafficShapingReported
Parameter trafficShapingReported
Boolean
Value value
Feature L103175.1
Inter-Release Delta: trafficShapingReported parameter
In the LA4.0 release, this parameter was named trafficShaping.
Page 301/308
Rule: trafficShapingReported parameter
If the value of either parameter:

isUlTrafficShapingEnabled = TRUE,
then the system will set the value of the trafficShapingReported parameter
equal to “True” and report the associated counters.
transportPacketSizeCountersReported - parameter specifies whether, or not,

the group of counters related to TransportPacketSizeCounters is selected to be
reported.
PerformanceManagement::transportPacketSizeCountersReported
Parameter transportPacketSizeCountersReported
Boolean
Value False
Feature 160816
tTIBundlingReported - parameter specifies whether, or not, the group of

counters related to TTIBundling is selected to be reported.
PerformanceManagement::tTIBundlingReported
Parameter tTIBundlingReported
Boolean
Value False
Feature L115807
uEContextReported - parameter specifies whether, or not, the group of counters

related to UEContext is selected to be reported.
Page 302/308
PerformanceManagement::uEContextReported
Parameter uEContextReported
Boolean
Value O.D.
Feature L103175.1
ulMIMOReported - parameter specifies whether, or not, the group of counters

related to ulMIMO is selected to be reported.
PerformanceManagement::ulMIMOReported
Parameter ulMIMOReported
Boolean
Value False
Feature 162426, L114538
Page 303/308
Rule: ulMIMOReportedparameter
ulMIMO counters are reported:
if and only if there is at least once active Cell with isulMIMOenabled = TRUE
uLNoiseReported - parameter specifies whether, or not, the group of counters

related to ULNoise is selected to be reported.
PerformanceManagement::uLNoiseReported
Parameter uLNoiseReported
Boolean
Value O.D.
Feature L103175.1
utraLoadBalancingReported - parameter specifies whether, or not, the group of

counters related to UtraLoadBalancing is selected to be reported.
PerformanceManagement::utraLoadBalancingReported
Parameter utraLoadBalancingReported
Boolean
Value False
Feature 155912
vlanReported - parameter specifies whether, or not, the group of counters related

to Vlan is selected to be reported.
Page 304/308
PerformanceManagement::vlanReported
Parameter vlanReported
Boolean
Value False
Feature L112791
Rule: vlanReported parameter
vlanReported should be set according to source

14.1 TIMER TO DETERMINE INACTIVE E-RAB

The value of parameter rabInactivityTimer (more information on [Vol. 4]) is used
to determine the duration of a timer, and the timer is used to determine if counter
number 12635 (see below) should be pegged when a bearer is dropped. If the
timer has not expired (i.e., the E-RAB is regarded as active), and the bearer is
dropped, then the counter is pegged. If the timer has expired (due to inactivity),
and the bearer is dropped, then the counter is not pegged.
Note: Counter 12635 provides a count of the “Number of abnormally released

active SAE bearers”. This counter provides the number of E-RABs that were
abnormally released and were active at the time of release. E-RAB activity is
determined in the following way: - a timer is started as soon as no activity occurs
for the E-RAB on a given TTI (neither in downlink nor in uplink) - If the timer value
at the time of release is lower than the configured value, the bearer is considered
active, if not it is considered not active. The measurement is split into sub
counters per QCI. Several screenings may be pegged simultaneously, or one
screening can be pegged several times. This counter is incremented when an
established E-RAB is abnormally released and the E-RAB is considered active.
Triggers for abnormal release are AbnormalERABReleasePerQCI and
ERABReleasedDueToRadioLinkFailurePerQCI.
Page 305/308
15 ANNEX – ABBREVIATIONS
Abbreviations that are specific to this volume are provided here. Abbreviations
that are common to multiple LPUG volumes are provided in [Vol. 1].
AISG Antenna Interface Standards Group

ALD Antenna Line Device (RET and/or TMA)
AN Antenna Network
BBU Base Band Unit
CPRI Common Public Radio Interface
DAS Distributed Antenna System
DBU Database Unit
DL Downlink
eNB E-UTRAN NodeB
eAM Extended Alarm Module
FRU Field Replaceable Unit
FTS Feature Technical Specification
GPS Global Positioning System
GSM Groupe Spéciale Mobile
MBI Multi-standard Base station Indoor
MBO Multi-standard Base station Outdoor
MC-RRH Multi-Carrier Remote Radio Head
MC-TRX Multi-Carrier Transceiver
MSRE Multi-Standard Radio Equipment
NEM Network Element Manager
N.S Not Significant
OAM Operations, Administration, and Maintenance
OAM-C OAM-Control
O.D Operator Dependent (depends on operator network specific configuration)
OOK On-Off-Keying: Special Kind of 2 ASK (Amplitude Shift Keying) where one
modulation symbol is zero
OTDOA Observed Time Difference of Arrival
PRS Positioning Reference Signal
RDEM Receive Diversity Expansion Module
RE Radio Equipment
REC Radio Equipment Controller
RET Remote Electrical Tilt
RF Radio Frequency
RFM Radio Frequency Module (generic name for an RRH or TRDU)
R-OCM Reverse – Optical Communications Module
RRH Remote Radio Head
RS Reference Signal
RTD Round Trip Delay
SFN System Frame Number
SISO Single Input Single Output
TMA Tower Mounted Amplifier
TRDU Transmit/Receive/Duplexer Unit
TTLNA Tower Top Low Noise Amplifier
UE User Equipment
UL Uplink
VSWR Voltage Standing Wave Ratio
Page 306/308
Page 307/308
VOLUME 3 LTE AIR INTERFACE

FDD eNodeB LTE Parameters User Guide 09.05/EN 27-September 2013
Volume 3 : LTE Air Interface

1 INTRODUCTION ..............................................................................................................................10
1.1 OBJECTIVE ...............................................................................................................................10
1.2 SCOPE OF THIS VOLUME ...........................................................................................................10
1.3 LIST OF RELATED FEATURES .....................................................................................................12
2 RELATED DOCUMENTS AND PREREQUISITES .........................................................................15

2.1 LPUG VOLUMES ......................................................................................................................15
2.2 REFERENCE DOCUMENTS .........................................................................................................15
2.3 PREREQUISITE FOR READING THIS VOLUME ...............................................................................16
3 LTE AIR INTERFACE OVERVIEW .................................................................................................17
4 THE PHYSICAL LAYER (L1) ..........................................................................................................23

4.1 LTE MULTIPLE ACCESS.......................................................................................................23
4.1.1 OFDM transmission ..........................................................................................................23
4.1.2 DFTS OFDM transmission ................................................................................................27
4.1.3 OFDMA and SC-FDMA.....................................................................................................29
4.2 MULTIPLE ANTENNA TECHNIQUES ..............................................................................................30
4.2.1 Basic Multiple antenna techniques ...................................................................................31
4.2.1.1 Time diversity ...............................................................................................................31
4.2.1.1.1 Cyclic Delay Diversity .............................................................................................31
4.2.1.1.2 Space-Frequency time Coding ...............................................................................32
4.2.1.2 Beamforming ................................................................................................................32
4.2.1.3 Spatial multiplexing ......................................................................................................33
4.2.1.4 Precoder-based spatial multiplexing ............................................................................35
4.2.2 Multiple antenna techniques support in LTE ....................................................................36
4.3 LTE FRAME STRUCTURE ...........................................................................................................37
Enb::modeConf ..................................................................................................37
FrequencyAndBandwidthFDD::dlBandwidth .................................................. 40
FrequencyAndBandwidthFDD::ulBandwidth .................................................. 41
LteCell::gpsFrameOffset ................................................................................... 42
LteCellFDD::duplexMode .................................................................................. 43
4.3.1 Downlink Resource grid ....................................................................................................44
4.3.2 Uplink Resource grid.........................................................................................................46
4.4 PHYSICAL LAYER PROCESSING ..................................................................................................47
4.4.1 Channel Coding ................................................................................................................47
4.4.2 Physical channels .............................................................................................................48
4.4.3 Physical signals ................................................................................................................50
4.4.4 Downlink baseband signal generation ..............................................................................50
4.4.4.1 Downlink physical channels processing ......................................................................51
4.4.4.1.1 Layer mapping ........................................................................................................52
4.4.4.1.1.1 Layer mapping for single antenna transmission..................................................... 52
4.4.4.1.1.2 Layer mapping for Spatial multiplexing.................................................................... 52
4.4.4.1.1.3 Layer mapping for transmit diversity ........................................................................ 53
4.4.4.1.2 Precoding ................................................................................................................53
4.4.4.1.2.1 Precoding for transmission on a single antenna port ............................................ 54
4.4.4.1.2.2 Precoding for spatial multiplexing............................................................................. 54
4.4.4.1.2.3 Precoding for transmit diversity ................................................................................ 55
Page 1/222
4.4.4.2 Downlink physical signals processing..........................................................................56

4.4.4.3 Mapping to Resource Elements and OFDM signal generation ...................................56
4.4.5 Uplink baseband signal generation...................................................................................57
4.4.5.1 Uplink Physical channels processing...........................................................................57
4.4.5.1.1 PUSCH processing .................................................................................................57
4.4.5.1.2 PUCCH processing.................................................................................................57
4.4.5.2 Uplink Physical signals processing ..............................................................................58
4.4.5.3 Mapping to Resource Elements and SC-FDMA signal generation..............................58
4.4.6 Signal Upconversion .........................................................................................................59
FrequencyAndBandwidthFDD::dlEARFCN ...................................................... 64
FrequencyAndBandwidthFDD::ulEARFCN ...................................................... 64
5 LAYER 2 ..........................................................................................................................................65
5.1 THE MEDIUM ACCESS CONTROL SUBLAYER ...............................................................................66
5.1.1 Services and functions ......................................................................................................66
5.1.2 Configuration of Downlink Physical Channels and Signals ..............................................66
5.1.2.1 Reference Signals........................................................................................................66
5.1.2.2 Positioning Reference Signals .....................................................................................69
5.1.2.3 Synchronization signals ...............................................................................................69
CellActivationService::isSyncSignalsDiversityAllowed ................................. 70
5.1.2.4 The Physical Broadcast Channel (PBCH) ...................................................................70
5.1.2.5 Physical layer control channels ...................................................................................71
CellL1L2ControlChannelsConf::dynamicCFIEnabled .................................... 73
CellL1L2ControlChannelsConf::cFI ................................................................. 73
MbsfnArea::sib13NonMBSFNregionLength .................................................... 73
CellL1L2ControlChannelsConf::cFIThreshold1 .............................................. 74
CellL1L2ControlChannelsConf::cFIThreshold2 .............................................. 74
CellL1L2ControlChannelsConf::cFI1Allowed .................................................. 75
CellL1L2ControlChannelsConf::cFIIncreaseTimer ......................................... 76
5.1.2.5.1 The Physical Control Format Indicator Channel (PCFICH) ....................................76
5.1.2.5.2 The Physical HARQ Indicator Channel (PHICH) ....................................................76
PowerOffsetConfiguration::phichResource .................................................... 77
5.1.2.5.3 The Physical Downlink Control Channel (PDCCH) ................................................78
CellL1L2ControlChannelsConf::pdcchAggregationLevelForUESearchSpace80
CellL1L2ControlChannelsConf::pdcchAggregationLevelForCRNTIGrantsInC
ommonSearchSpace......................................................................................... 84
CellL1L2ControlChannelsConf::pdcchAggregationLevelForNonCRNTIGrant
sInCommonSearchSpace ................................................................................. 84
CellRadioConf::uLCCEspaceMaxOverbookingFactor .................................... 85
5.1.2.6 The Physical Downlink Shared Channel (PDSCH) .....................................................85
5.1.2.7 The Physical Multicast Channel (PMCH).....................................................................85
5.1.3 Configuration of Uplink Physical Channels and Signals ...................................................86
5.1.3.1 Reference Signals........................................................................................................86
5.1.3.1.1 Demodulation Reference Signal ............................................................................86
ActivationService::groupHoppingEnabled ...................................................... 87
CellL1ULConf::groupAssignmentPUSCH ........................................................ 87
CellL1ULConf::ulRSCyclicShift ........................................................................ 89
5.1.3.1.2 Sounding Reference Signal ....................................................................................89
LteCell::srsEnabled ........................................................................................... 89
CellL1ULConf::srsBandwidthConfiguration .................................................... 90
CellActivationService::isNarrowbandSRSuseEnabled ................................... 90
CellL1ULConfFDD::dedicatedSrsBandwidth ................................................... 91
CellL1ULConf::srsFrequencyDomainPosition ................................................ 94
5.1.3.2 Physical Uplink Control Channel (PUCCH) .................................................................94
CellL1ULConf::srProhibitTimer ........................................................................ 96
CellL1ULConf::dsrTransMax............................................................................. 97
5.1.3.3 Physical Uplink Shared Channel (PUSCH) .................................................................98
5.1.3.4 PUCCH/PUSCH in the 700MHz Upper C Block band .................................................98
5.1.3.5 PUCCH/SRS configuration ..........................................................................................99
Page 2/222
CellL1ULConf::initPUCCHSRSConfigProfile ................................................. 100

CellL1ULConf::minPucchConfigLifeTime ...................................................... 100
CellL1ULConf::pucchReconfigPaceTimer ..................................................... 101
CellL1ULConf::pucchSrsConfStepDownLoadingThreshold ........................ 101
CellL1ULConf::pucchSrsConfStepUpLoadingThreshold ............................. 102
CellL1ULConf::worstPucchSrsConfigAllowed .............................................. 102
5.1.3.6 Physical Random Access Channel (PRACH) ............................................................102
5.1.3.6.1 PRACH formats ....................................................................................................102
CellActivationService::pRACHPreambleFormat ........................................... 103
5.1.3.6.2 Random Access preambles sequence generation ...............................................106
CellL1ULConfFDD::cellRtdAdjust .................................................................. 111
CellRachConf::highSpeedFlag ....................................................................... 114
CellRachConf::rootSequenceIndex ................................................................ 114
CellRachConf:: autoRSIConfigEnabled ......................................................... 115
CellRachConf::pRACHDetectFalseAlarmProb .............................................. 117
CellRachConf:: rachPfaTolerance .................................................................. 117
CellRachConf:: rachThresholdAdjScaleFactor ............................................. 118
CellRachConf:: rachThresholdMaxControl.................................................... 119
5.1.3.6.3 PRACH time/frequency configuration ...................................................................119
CellRachConfFDD::rachPeriodicity ................................................................ 120
CellRachConf::prachFrequencyOffset ........................................................... 121
Enb::pRachIndexAlgorithm............................................................................. 123
5.1.4 MAC procedures .............................................................................................................123
5.1.4.1 HARQ operation .........................................................................................................123
5.1.4.1.1 Downlink HARQ ....................................................................................................125
5.1.4.1.2 Uplink HARQ ........................................................................................................125
5.1.4.2 Random Access procedure........................................................................................126
CellRachConf::contentionFreeRACHenabled ............................................... 127
5.1.4.2.1 Contention based Random Access procedure .....................................................127
CellRachConf::numberOfRAPreambles ......................................................... 129
CellRachConfFDD::maxHARQmsg3Tx........................................................... 130
CellRachConf::maximumNumberOfDLTransmisionsRACHMessage4........ 130
CellRachConf::macContentionResolutionTimer ........................................... 130
CellRachConf::raResponseWindowSize ........................................................ 131
CellRachConf::nbrOfRARsPerRACHCycle .................................................... 133
CellRachConf:: rachDetectionThresholdScalingForMultiplePreambles ..... 133
CellRachConf::rABackoff ................................................................................ 134
5.1.4.2.2 Non-Contention based Random Access procedure .............................................135
5.1.4.2.3 Random Access failure .........................................................................................135
CellRachConf::preambleTransMax ................................................................ 136
5.1.4.2.4 RACH access load control ....................................................................................136
CellRachConf::raLoadingThresholdForBackoff ............................................ 137
5.1.4.3 Timing Advance procedure ........................................................................................137
CellL2ULConf::timeAlignmentTimerCommon ............................................... 138
CellL2ULConf::timeAlignmentTimerDedicated ............................................. 139
CellRadioConf::tAFailureTimer ....................................................................... 140
5.1.4.4 Buffer Status Reporting..............................................................................................140
CellL2ULConf::periodicBSRtimer ................................................................... 141
CellL2ULConf::retxBSRtimer .......................................................................... 141
5.1.4.5 Power Headroom Reporting ......................................................................................141
CellL2ULConf::periodicPHRtimer ................................................................... 142
CellL2ULConf::prohibitPHRtimer ................................................................... 142
CellL2ULConf::dlPathlossChangeForPHRreporting ..................................... 142
5.1.5 MAC scheduler ...............................................................................................................143
5.2 THE RADIO LINK CONTROL SUBLAYER .....................................................................................143
5.2.1 Services and functions ....................................................................................................143
5.2.2 RLC-PDCP Flow Control ................................................................................................144
TrafficRadioBearerConf:: rlcPdcpFlowControlEnabled ............................... 146
5.2.2.1 RLC flow control and timer-based discard .................................................................146
5.2.2.1.1 RLC Adaptive Buffer Dimensioning ......................................................................147
5.2.2.2 RLC flow control and timer-based discard parameters .............................................148
Page 3/222
TrafficRadioBearerConf::rlcSduBufferLowerThreshold ............................... 148

TrafficRadioBearerConf::rlcSduBufferHigherThreshold .............................. 149
TrafficRadioBearerConf:: rlcDiscardTimerEnb ............................................. 150
TrafficRadioBearerConf::rlcSduBufferCoefficients ...................................... 151
5.2.3 RLC Unacknowledged mode (UM) .................................................................................152
5.2.3.1 RLC UM state variables, constants and timers .........................................................152
5.2.3.1.1 RLC UM State variables .......................................................................................152
5.2.3.1.2 RLC UM Constants ...............................................................................................152
5.2.3.1.3 RLC UM Timers ....................................................................................................152
RlcUmConf::timerTreorderingDownlink ........................................................ 153
RlcUmConf::timerTreorderingUplink ............................................................. 153
5.2.3.2 RLC UM PDU format .................................................................................................153
RlcUmConf::sNfieldLengthDownlink ............................................................. 154
RlcUmConf::sNfieldLengthUplink .................................................................. 154
5.2.3.3 RLC UM Transmit operations ....................................................................................155
5.2.3.4 RLC UM Receive operations .....................................................................................155
5.2.3.5 RLC UM Parameter Values .......................................................................................156
5.2.4 RLC Acknowledged mode (RLC AM) .............................................................................157
5.2.4.1 RLC AM PDU .............................................................................................................157
5.2.4.2 RLC AM State variables, constants and timers .........................................................158
5.2.4.2.1 RLC AM State variables .......................................................................................158
5.2.4.2.2 RLC AM Constants ...............................................................................................159
RlcAmConf::pollPDUDownlink ....................................................................... 159
RlcAmConf::pollPDUUplink ............................................................................ 160
RlcAmConf::PollByteDownlink ....................................................................... 160
RlcAmConf::PollByteUplink ............................................................................ 160
5.2.4.2.3 RLC AM Timers ....................................................................................................160
RlcAmConf::timerTpollRetransmitDownlink ................................................. 161
RlcAmConf::timerTpollRetransmitUplink ...................................................... 161
RlcAmConf::timerTreorderingDownlink ........................................................ 162
RlcAmConf::timerTreorderingUplink ............................................................. 162
RlcAmConf::timerStatusProhibitUplink ......................................................... 163
RlcAmConf::timerStatusProhibitDownlink .................................................... 163
5.2.4.3 Transmit operations ...................................................................................................163
5.2.4.4 Receive operations ....................................................................................................164
5.2.4.5 ARQ procedures ........................................................................................................165
5.2.4.5.1 Retransmission .....................................................................................................165
RlcAmConf::maxRetxThresholddownlink ..................................................... 166
RlcAmConf:: maxRetxThresholduplink ......................................................... 166
5.2.4.5.2 Polling ...................................................................................................................166
RlcAmConf::pollTriggerTpollRetransmitDownlink ....................................... 167
RlcAmConf::unansweredDownlinkPollCountMax ........................................ 167
5.2.4.5.3 Status reporting ....................................................................................................168
5.2.4.6 MBMS Impact on RLC Layer .....................................................................................168
5.2.5 Use of ALU RLC Templates for Custom Quality of Service Classes .............................170
5.3 THE PACKET DATA CONVERGENCE PROTOCOL SUBLAYER .......................................................171
5.3.1 Services and functions ....................................................................................................171
5.3.2 Packet data Convergence Protocol ................................................................................171
5.3.2.1 PDCP architecture .....................................................................................................172
5.3.2.1.1 Confidentiality and Integrity Protection .................................................................173
5.3.2.1.2 Configuring the PDCP Layer ................................................................................174
5.3.2.2 PDCP PDU ................................................................................................................174
5.3.2.2.1 PDCP data PDU ...................................................................................................174
5.3.2.2.1.1 U-Plane PDCP data PDU ........................................................................................ 174
PdcpConf::pdcpPduSnSize............................................................................. 175
5.3.2.2.1.2 C-Plane PDCP data PDU ........................................................................................ 176
5.3.2.2.2 PDCP control PDU ...............................................................................................176
5.3.2.2.3 PDCP SDU discard timer parameter ....................................................................176
PdcpConf::pdcpDiscardTimer ........................................................................ 178
5.3.2.2.4 PDCP SDU Size ...................................................................................................178
5.3.2.2.5 Handover-related PDCP parameters....................................................................178
Page 4/222
PdcpConf::pdcpStatusReportEnable ............................................................. 179

PdcpConf::pdcpUlDuplicateDetectionWindow ............................................. 179
TrafficRadioBearerConf::pdcpUlTargetS1BufferCoefficients ...................... 180
5.3.2.2.6 PDCP Parameters Engineering Recommendations.............................................181
5.3.2.2.7 Lossless Handover and PDCP Data Forwarding .................................................181
TrafficRadioBearerConf:: pdcpDlLosslessBufferCoefficients ..................... 183
PdcpConf::pdcpDlLosslessBufferLife ........................................................... 184
TrafficRadioBearerConf::pdcpDlSourceS1BufferCoefficients..................... 184
TrafficRadioBearerConf::pdcpDlTargetS1BufferCoefficients ...................... 185
TrafficRadioBearerConf::pdcpDlTargetDataForwardingBufferCoefficients186
PdcpConf::timerRlcEndMarker ....................................................................... 187
5.3.2.3 PDCP Downlink Duplicate Avoidance for Over The Air Transmission ......................187
PdcpConf::dlPdcpDuplicateAvoidanceEnabled ............................................ 188
PdcpConf::timerPdcpStatusReportWait ........................................................ 189
5.3.2.4 RLC-PDCP flow control .............................................................................................189
5.3.2.5 PDCP reaction to RLC congestion ............................................................................191
PdcpConf::pdcpFlowControlTimerTp ............................................................ 191
5.3.2.6 PDCP flow control ......................................................................................................192
TrafficRadioBearerConf::pdcpLosslessBufferHigherThreshold ................. 193
TrafficRadioBearerConf::pdcpLosslessBufferLowerThreshold .................. 193
PdcpConf::pdcpLosslessBufferCongestionEventTriggerProhibitTimer .... 193
5.3.2.7 Ciphering and Deciphering ........................................................................................193
5.3.2.8 Verification and protection .........................................................................................194
5.3.2.8.1 AS Security Feature Activation and Deactivation .................................................195
5.3.2.8.2 Ciphering and Integrity Protection Parameters ....................................................195
PlmnIdentity::allowedCipheringAlgorithmList .............................................. 195
PlmnIdentity::allowedIntegrityProtectionAlgorithmList ............................... 196
5.3.3 Robust Header Compression .........................................................................................197
ActivationService::isRohcAllowed ................................................................. 199
TrafficRadioBearerConf::rohcMaxCid ............................................................ 199
TrafficRadioBearerConf::rohcProfiles ........................................................... 200
5.3.3.1 RoHC Modes .............................................................................................................200
RohcConf::rohcPreferredMode ...................................................................... 202
5.3.3.2 RoHC States ..............................................................................................................202
5.3.3.2.1 Compressor States ...............................................................................................202
RohcConf::rohcIrRepeat ................................................................................. 204
RohcConf::rohcFoRepeat ............................................................................... 204
RohcConf::rohcIrLimit ..................................................................................... 204
RohcConf::rohcSoLimit................................................................................... 205
5.3.3.2.2 DeCompressor States ..........................................................................................205
RohcConf::rohcStateControlK1 ...................................................................... 206
RohcConf::rohcStateControlN1 ...................................................................... 207
RohcConf::rohcStateControlK2 ...................................................................... 207
RohcConf::rohcStateControlN2 ...................................................................... 208
5.3.3.3 RoHC PACKETS .......................................................................................................208
RohcConf::rohcStandaloneFeedbackTimeout .............................................. 209
RohcConf::rohcRtpTimestampBasedCompression ..................................... 209
RohcConf::rohcSlidingWindowSize ............................................................... 210
5.4 SYNC LAYER (MBMS)...........................................................................................................210
MbmsBearerService::syncPeriodOffset......................................................... 212
MbmsBearerService::syncPeriodDuration .................................................... 213
LteCell::mbmsExcessDataThrHigh ................................................................ 214
LteCell::mbmsExcessDataThrLow ................................................................. 215
LteCell::mbmsPacketLossThrHigh ................................................................ 215
LteCell::mbmsPacketLossThrLow ................................................................. 216
6 THE RADIO RESOURCE CONTROL LAYER ..............................................................................216

6.1 RRC SERVICES AND FUNCTIONS .............................................................................................216
6.2 RRC STATES .........................................................................................................................217
6.3 SYSTEM INFORMATION ............................................................................................................217
Page 5/222
7 ANNEX – ABBREVIATIONS .........................................................................................................219
Page 6/222
TABLES
Table 1: Mapping between channel bandwidth and transmission bandwidth ....................................... 40
Table 2: Channel coding scheme for Transport Blocks ........................................................................ 48
Table 3: Channel coding scheme for physical layer control information ............................................... 48
Table 4: Modulation schemes used for transmission over downlink physical channels ....................... 51
Table 5: Codeword-to-layer mapping for spatial multiplexing [R04] ..................................................... 53
Table 6: Codeword-to-layer mapping for transmit diversity [R04] ......................................................... 53
Table 7: PUCCH modulation schemes.................................................................................................. 58
Table 8: E-UTRA FDD frequency bands ............................................................................................... 61
Table 9: EARFCN related frequencies .................................................................................................. 63
Table 10: Number of PDCCH candidates per search space................................................................. 79
(1)
Table 11: Mapping of the cyclic shift field value broadcast in the cell and n DMRS ................................ 88
( 2)
Table 12: Mapping of the cyclic shift field value broadcast in the cell and n DMRS ................................ 88
Table 13: m(C SRS , b) and N b , b = 0,1,2,3 , values for the uplink bandwidth of 6 ≤ N RB
UL
≤ 40 ............... 92
Table 14: m(C SRS , b) and N b , b = 0,1,2,3 , values for the uplink bandwidth of 40 < N RB
UL
≤ 60 .............. 93
UL
≤ 80 ............... 93
Table 16: m(C SRS , b) and N b , b = 0,1,2,3 , values for the uplink bandwidth of 80 < N RB UL
≤ 110 ............. 93
Table 17: PUCCH formats ..................................................................................................................... 95
Table 18: PUCCH CQI/PMI reporting modes ........................................................................................ 95
Table 19: PUCCH PRB size in LR13.1 ................................................................................................. 96
Table 20: Random Access preamble formats for FDD ....................................................................... 103
Table 21: Maximum OTA Cell Radius when the cabling delay exceeds 75000ns (on eCEM and on
bCEM when maxTransportFiberDelayLengthCategory is set to “fifteenKm”) .............................. 106
Table 22: Root sequence logical index-to-physical index mapping .................................................... 109
Table 23: N CS determination based on Cell Radius, in low speed cells (unrestricted set) ................ 110
Table 24: N CS determination based on Cell Radius, in high speed cells (restricted set) ................... 110
Table 25: PRACH time configuration .................................................................................................. 120
Table 26 : Mapping of rABackoff Parameter Value (Index) to Backoff Time ...................................... 134
Table 27. Engineering Recommendation for RLC UM Parameter Values for Traffic Radio Bearer QCI
values ........................................................................................................................................... 157
Table 28 : Standard QCI to RLC Configuration Mapping .................................................................... 171
Table 29: 3GPP QCI Table.................................................................................................................. 177
Table 30 : PCDP Parameter Values for Traffic Radio Bearer QCIs .................................................... 181
Page 7/222
FIGURES
Figure 1: LTE U-Plane Air Interface protocol stack ............................................................................... 17
Figure 2: LTE C-Plane Air Interface protocol stack ............................................................................... 17
Figure 3: Mapping between downlink logical channels and downlink transport channels .................... 20
Figure 4: Mapping between uplink logical channels and uplink transport channels ............................. 20
Figure 5: Mapping between downlink transport channels and downlink physical channel ................... 21
Figure 6 : Mapping between uplink transport channels and uplink physical channels ......................... 22
Figure 7: OFDM subcarrier spacing ...................................................................................................... 23
Figure 8: OFDM time-frequency grid ..................................................................................................... 24
Figure 9: OFDM modulation .................................................................................................................. 24
Figure 10: OFDM demodulation ............................................................................................................ 25
Figure 11: Time dispersion and corresponding received signal ............................................................ 25
Figure 12: Cyclic Prefix insertion ........................................................................................................... 26
Figure 13: Frequency domain model of OFDM transmission reception ................................................ 26
Figure 14: DFTS OFDM signal generation ............................................................................................ 28
Figure 15: DFTS OFDM demodulation.................................................................................................. 29
Figure 16: (DFTS) OFDM as a multiple access technique.................................................................... 29
Figure 17: Distributed allocation in (DFTS) OFDM-based Multiple Access techniques ........................ 30
Figure 18: Two-antenna delay diversity ................................................................................................ 31
Figure 19: Four-antenna Cyclic Delay Diversity with OFDM transmission ........................................... 32
Figure 20: Space Frequency time diversity with two transmit antennas ............................................... 32
Figure 21: Beamforming using 4 transmit antennas ............................................................................. 33
Figure 22: 2×2 antenna configuration ................................................................................................... 34
Figure 23: MIMO System Model ............................................................................................................ 34
Figure 24: Precoder-based Spatial Multiplexing.................................................................................... 35
Figure 25: Frame structure type 1 ......................................................................................................... 38
Figure 26: (DFTS) OFDM signal ........................................................................................................... 39
Figure 27: Downlink resource grid ......................................................................................................... 45
Figure 28: Uplink resource grid ............................................................................................................. 47
Figure 29: Precoding for Transmit Diversity with 2 antennas................................................................ 55
Figure 30: Precoding for Transmit Diversity with 4 antennas................................................................ 56
Figure 31: Downlink Signal upconversion ............................................................................................. 59
Figure 32: Uplink Signal Upconversion ................................................................................................. 60
Figure 33: Layer 2 structure in the downlink ......................................................................................... 65
Figure 34: Layer 2 structure in the uplink .............................................................................................. 65
Figure 35 : Reference Signal configuration for 1 antenna case ............................................................ 67
Figure 36 : Reference Signal configuration for 2 antennas case .......................................................... 67
Figure 37: Reference Signal Configuration for M subframe with port 0 in non-MBSFN region and port 4
in MBSFN region, CFI=2 case ....................................................................................................... 68
Figure 38: Reference Signal Configuration for M subframe with port 0 & 1 in non-MBSFN region and
port 4 in MBSFN region, CFI=2 ...................................................................................................... 68
Figure 39: Frequency allocation in the 700 MHz Upper C block band in LR13.1 ................................. 98
Figure 40 : Random access preamble format ..................................................................................... 102
Figure 41: Simplified view of RRH-based Hardware and associated delays when DAS is not used (cell
view, case of 1 transmit antenna per antenna node) ................................................................... 105
Figure 42: Simplified view of RRH-based Hardware when DAS is used (cell view, case of 1 transmit
antenna per coverage area) ......................................................................................................... 105
Figure 43: Simplified view of TRDU-based Hardware when DAS is not used (cell view, case of 1
transmit antenna per coverage area) ........................................................................................... 105
Figure 44: Simplified view of TRDU-based Hardware when DAS is used (cell view, case of 1 transmit
antenna per coverage area) ......................................................................................................... 105
Figure 45: HARQ processing............................................................................................................... 124
Figure 46 : Contention based Random Access Procedure ................................................................. 127
Figure 47 : Non-Contention based Random Access Procedure ......................................................... 135
Figure 48: Overview model of the RLC layer ...................................................................................... 144
Figure 49: UM PDU with a 5-bit SN field and no header extension .................................................... 154
Page 8/222
Figure 50: UM PDU with a 10-bit SN field and no header extension .................................................. 155
Figure 51 : RLC AM PDU with No Header Extension ......................................................................... 157
Figure 52 : WPS Screenshot showing Pre-Defined RLC Configurations............................................ 170
Figure 53: PDCP sublayer architecture and functional elements ....................................................... 173
Figure 54 : U-Plane PDCP data PDU format with a 7-bit SN .............................................................. 175
Figure 55 : U-Plane PDCP data PDU format with a 12-bit SN ............................................................ 175
Figure 56 : C-Plane PDCP data PDU format ...................................................................................... 176
Figure 57 : PDCP deciphering failure due to RLC buffer overflow ...................................................... 190
Figure 58: VoIP Frame when RoHC is used ....................................................................................... 197
Figure 59 : RoHC Architecture ............................................................................................................ 198
Figure 60 – RoHC Compressor Modes and Mode Transitions ........................................................... 201
Figure 61 – RoHC Decompressor Modes and Mode Transitions ....................................................... 202
Figure 62 – Compressor State Transitions in U-Mode ........................................................................ 203
Figure 63 – Compressor State Transitions in O-Mode........................................................................ 203
Figure 64 – Compressor State Transitions in R-Mode ........................................................................ 203
Figure 65 – Decompressor State Transitions ...................................................................................... 206
Figure 66: SYNC protocol layer in the MBMS architecture ................................................................ 210
Figure 67: Transmission of Sync Sequences ...................................................................................... 212
Page 9/222
1 INTRODUCTION
1.1 OBJECTIVE
The objective of this volume is to describe from an engineering point of view the LTE
Air Interface parameters.
recommendations.
1.2 SCOPE OF THIS VOLUME

releases LR13.1 and LR13.3 for the Frequency Division Duplex (FDD)
implementation. Information that is added in this edition to support Releases LR13.1
and LR13.3 is colored with a grey background as illustrated by this paragraph.
References to LA0.x, LA1.0, LA1.1, LA2.0, LA3.0, LA4.0, LA5.0, and LA6.0 in this
Volume and the summary descriptions of features have been deleted. Each
individual volume contains a list of features that are described in that
volume. In addition, the listings of new, modified, deleted parameters and
parameters that are not described in LPUG have been deleted from the
Appendices. The material related to feature licensing has been moved to
new Volume 2 (see below).
• Previous issues of LPUG included Volume 2 (LTE Overview). This material

has been deleted from the current issue
Page 10/222

deleted.

LR13.1 delivery release become available as initially planned.
Engineering Recommendation: Modem Type in LR13.1
Note that three types of modem are available in LR13.1: the eCEM, the bCEM,

separate document.
Page 11/222
All engineering information, algorithms description and parameters values provided
in this document are strictly related to “standard” Alcatel-Lucent eNodeB products,
including Macro and Metro eNodeB, unless explicitly mentioned.
related parameters that were previously described in LPUG Volume 7 were moved
to the Transport Engineering Guide (TEG). Please refer to that document for
1.3 LIST OF RELATED FEATURES

LA1.0:
Feature
Feature Title
Number
L76432 Scheduling Evolutions
L76501 3GPP Standard Compliance
Buffered PDCP packet
forwarding over X2 interface on
L76500
top of LA0.2 Seamless Intra-
LTE Mobility solution
LA2.0:
Feature
Number
Ciphering & Integrity Protection Integrity Protection – LA2.0.1

L92638
For Radio Interface Ciphering – LA2.0 2
L97014 RLC-PDCP Flow Control LA2.0.2
Support for 20MHz bandwidth
L92129 LA2.0.2
on 2.6 GHz eNodeB
LA3.0:
Page 12/222
Feature
Number
eNB KPI Objectives (C-plane, LA3.0.2
L109433
U-plane) for LA3.0
LA4.0:
Feature
Number
EUTRAN Standard Alignment LA4.0.0
L114644.1
on 3GPP Rel’9
L110547.1 RoHC v1 Support for VoIP LA4.0.1
Single Antenna Transmit LA4.0.1
L84815
Scheme
eNB IMS VoIP Emergency Call LA4.0.2
L103897.1
Support (trial)
Symmetrical 3MHz FDD LA4.0.3
L92805
Bandwidth Management
LA5.0:
Feature
Number
eNB Class Parameter Change LA5.0.0
L115217
Improvements
Symmetrical 1.4MHz FDD LA5.0.1
L92801
BdW Mgt
eMBMS trial support (eMBMS LA5.0.1
L115527 services configured by OAM
command)
L115233 eNB SW Capacity Targets LA5.0.1
Half Duplex FDD for Cassidian LA5.0.1
L115820
band
Extended CP Support for LA5.0.1
L92080
eMBMS FDD trial
LA6.0:
Feature
Number
Band 25 (PCS+G) LTE eNodeB LA6.0.0
L134310
Band 5 (850) LTE-only eNodeB LA6.0.0
L159277
L106226 AWS RDEM HW LA6.0.0
Bands 12 and 17 (Lower 700 LA6.0.0
L115298
MHz) LTE eNodeB
Page 13/222
Band 13 (Upper 700 MHz) LTE LA6.0.0

L115299 eNodeB Configurations in
LA6.0
Band 14 (Upper 700MHz LA6.0.0
Public Safety & D Block) LTE
L115300
eNodeB Configurations in
LA6.0
Band 20 (800MHz EDD) LTE LA6.0.0
L115301 eNodeB configurations in
LA6.0
Band 4 (AWS) LTE eNodeB LA6.0.0
L115304
Band 4 (AWS) ROCM LTE LA6.0.0
LA6.0
Band 2 (PCS) ROCM LTE LA6.0.0
LA6.0
Band 7 (2600MHz) LTE LA6.0.0
L115309 eNodeB configurations in
LA6.0
Dual-carrier support on one LA6.0.1
L115938
band
LR13.1:
Feature
Feature Title LR13.1 Drop
Number
Support of 15MHz LTE LR131.
L114640
symmetric carrier
RACH Improvements - RACH LR13.1
L115767 burst format 3 support (up to
70 km radius)
4Rx Receive Diversity over LR13.1
L98565
10MHz BW FDD
L162787 Band 26 (800MHz IDEN) LR13.1
LR13.3:
Feature
Number
Nine cells (one frequency)
L115401
support in three mode
Enb Software Capacity
166802 Configuration in LR13.3 (only
RACH improvement part is in
Page 14/222
this Volume)
bCEM-eCEM parity for 1.4MHz

L115954
and 3MHz
Whenever possible and/or necessary, a reference is given to the feature number in

the parameter tables.
2 RELATED DOCUMENTS AND

PREREQUISITES
2.1 LPUG VOLUMES

[Vol. 6] Mobility

[R02] LTE/DCL/APP/031106 FDD eNodeB Product Engineering Guide
Base Station (BS) radio transmission and reception” .(Rel-9 2010-09)
[R04] 3GPP TS 36.211: "Evolved Universal Terrestrial Radio Access (E-UTRA);
Physical channels and modulation". (Rel-9 2010-09)
Multiplexing and channel coding". (Rel-9 2010-09)
Physical layer procedures". (Rel-9 2010-09)
[R07] 3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA)
and Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Overall
description Stage 2". (Rel-9 2010-09)
Packet Data Convergence Protocol (PDCP) specification”. (Rel-9 2010-09)
Page 15/222
[R09] 3GPP TS 36.321: “Evolved Universal Terrestrial Radio Access Network (E-
UTRAN; Medium Access Control (MAC) R9” (Rel-9 2010-09)
UTRAN; Radio Link Control (RLC) R9” (Rel-9 2010-09)
[R11] RFC3095: RObust Header Compression (ROHC): Framework and four
profiles: RTP, UDP, ESP, and uncompressed.
User Equipment (UE) radio transmission and reception (Rel-9, 2010-09)”
http://www.3gpp.org/ftp/Specs/archive/36_series/
[R13] 3GPP TS 23.203: “Policy and charging control architecture (Rel-9, 2010-09)”
[R14] 3GPP TS 25.446: “MBMS synchronization protocol (SYNC) (Rel-9 2010-12)”
[R15] 3GPP TS 36.331 “Radio Resource Control (RRC) (Rel-9 2010-09)”
2.3 PREREQUISITE FOR READING THIS VOLUME

Before reading this volume, the reader should read the introduction (Volume 1).
Volume 1 provides an explanation of the presentation and conventions that are used
throughout the document (i.e., common to all volumes).
Page 16/222
3 LTE AIR INTERFACE OVERVIEW

The LTE Air interface protocol stack is illustrated in Figure 1 and Figure 2 for the U-
Plane and the C-Plane, respectively.
Figure 1: LTE U-Plane Air Interface protocol stack
Figure 2: LTE C-Plane Air Interface protocol stack
As can be seen, RRC is present only in the C-Plane and is part of L3. PDCP, RLC
and MAC are the 3 sublayers of L2 whereas L1 is the physical layer.
A given (sub)layer has access to another (sub)layer through Service Access Points
(SAPs). The SAPs between the RLC (sub)layer and the MAC (sub)layer provide the
logical channels. The SAPs between the MAC (sub)layer and the physical layer
provide the transport channels.
The physical layer sends the MAC PDUs, also known as Transport Blocks (TBs), on
physical channels.
Logical channels
A logical channel is defined by what type of information is transferred.
A general classification of logical channels is into two groups:
• Control Channels: for the transfer of control plane information.
• Traffic Channels: for the transfer of user plane information.
Page 17/222
The control channels offered by MAC are:

• Broadcast Control Channel (BCCH): Downlink channel for broadcasting
system control information.
• Paging Control Channel (PCCH): Downlink channel that transfers paging
information and system information change notifications. This channel is
used for paging when the network does not know the location cell of the UE.
• Common Control Channel (CCCH): Channel for transmitting control
information between UEs and network. This channel is used for UEs having
no RRC connection with the network.
• Dedicated Control Channel (DCCH): Point-to-point bi-directional channel that
transmits dedicated control information between a UE and the network. Used
by UEs having an RRC connection.
• Multicast Control Channel (MCCH): Point-to-multipoint downlink channel
used for transmitting MBMS control information from the network to the UE,
for one or several MTCHs. This channel is supported by the eNB with bCEM
for FDD beginning in release LR13.1 for 10 MHz system only and is only
used by UEs that receive MBMS.
RRC control plane information is passed to the PDCP layer through Signaling Radio
Bearers (SRBs), which represent the SAPs between the RRC layer and the PDCP
(sub)layer. SRB0 is mapped to the CCCH channel, whereas SRB1 and SRB2 are
mapped to the DCCH channel (with priority to SRB1).
The traffic channels offered by MAC are:
• Dedicated Traffic Channel (DTCH): Point-to-point channel, dedicated to one

UE, for the transfer of user information. A DTCH can exist in both uplink and
downlink.
• Multicast Traffic Channel (MTCH): Point-to-multipoint downlink channel for

transmitting traffic data from the network to the UE. This channel is
supported by the eNB with bCEM for FDD beginning in release LR13.1 for
10 MHz system only and is only used by UEs that receive MBMS.
IP (Service Data Flow) user plane information is passed to the PDCP layer through
Data Radio Bearers (DRBs), which represent the SAPs between the IP layer and the
PDCP (sub)layer. They are mapped to the DTCH and the MTCH logical channels.
Transport channels
A transport channel is defined by how the information is transferred, i.e. by its
transport format, specifying the physical layer processing (channel coding,
interleaving, HARQ processing, multiple antenna technique scheme…) applied to the
corresponding Transport Blocks, as well as the characteristics (link adaptation, type
of scheduling …) with which these TBs are transferred over the air interface.
Page 18/222
Transport channels are:

• The Broadcast Channel (BCH): DL channel characterized by:
o Fixed, pre-defined transport format.
o Broadcast in the entire coverage area of the cell.
• The Downlink Shared Channel (DL-SCH): DL channel characterized by:
o Support for HARQ.
o Support for dynamic link adaptation by varying the modulation,
coding and transmit power.
o Possibility to use beamforming.
o Support for both dynamic and semi-static resource allocation.
o Support for UE discontinuous reception (DRX) to enable UE power
saving.
• The Paging Channel (PCH): DL channel characterized by:
o Support for UE discontinuous reception (DRX) to enable UE power
saving (DRX cycle is indicated by the network to the UE).

o Mapped to physical resources which can be used dynamically also
for traffic/other control channels.
• The Multicast Channel (MCH): DL channel characterized by:
o Support for MBSFN combining of MBMS transmission on multiple
cells.
o Support for semi-static resource allocation e.g. with a time frame of a
long cyclic prefix.
o This channel is supported by the eNB with bCEM for FDD beginning
in release LR13.1 for 10 MHz system only.
• The Uplink Shared Channel (UL-SCH): UL channel characterized by:
o Possibility to use beamforming.
o Support for dynamic link adaptation by varying the transmit power
and potentially modulation and coding.
o Support for HARQ.

o Support for both dynamic and semi-static resource allocation.
• The Random Access Channel(s) (RACH): UL channel characterized by:
o Limited control information.
o Collision risk.
Page 19/222
The mapping between logical channels and transport channels is depicted in Figure
3 for the downlink and in Figure 4 for the uplink:
Figure 3: Mapping between downlink logical channels and downlink

transport channels
Figure 4: Mapping between uplink logical channels and uplink transport

channels
Physical channels
A physical channel is defined by a set of physical resources used to transmit either
Transport Blocks (physical channels to which are mapped transport channels) and at
times physical layer level control information or solely physical layer level control
information (physical channels to which no transport channel is mapped).
The data transmitted on a given physical channel go through the same physical layer
processing (see section 4.4.4.1 for the downlink and section 4.4.5.1 for the uplink)
prior to the transmission of the signal(s) on the antenna(s).
Page 20/222
Physical channels to which are mapped transport channels (i.e. physical channels
the resources of which carry Transport Blocks and sometimes physical layer level
control information) are:
• In the downlink
o The Physical Broadcast Channel (PBCH).
o The Physical Downlink Shared Channel (PDSCH).
o The Physical Multicast Channel (PMCH). This channel is supported
by the eNB with bCEM for FDD beginning in release LR13.1 for 10
MHz system only.
• In the uplink
o The Physical Uplink Shared Channel (PUSCH).
o The Physical Random Access Channel (PRACH).
Physical channels to which no transport channel is mapped (i.e. physical channels

the resources of which carry physical layer level control information) are:
• In the downlink
o The Physical Control Format Indicator Channel (PCFICH).

o The Physical Downlink Control Channel (PDCCH).
o The Physical Hybrid ARQ Indicator Channel (PHICH).
• In the uplink
o The Physical Uplink Control Channel (PUCCH).
These channels are described in more detail in Section 4.4.2.
The mapping between transport channels and physical channels is depicted in

Figure 5 for the downlink and in Figure 6 for the uplink:
BCH MCH PCH DL-SCH

Downlink
Transport channels
Downlink
Physical channels
PBCH PMCH PDSCH PDCCH
Figure 5: Mapping between downlink transport channels and downlink

physical channel
Page 21/222
Figure 6 : Mapping between uplink transport channels and uplink physical

channels
Page 22/222
4 THE PHYSICAL LAYER (L1)
4.1 LTE MULTIPLE ACCESS
4.1.1 OFDM TRANSMISSION

Orthogonal Frequency Division Multiplexing (OFDM) is a multicarrier transmission
technique that has been adopted as the downlink transmission scheme for the 3GPP
Long-Term Evolution (LTE) and is also used for several other radio technologies,
e.g. WiMAX and the DVB broadcast technologies.
It is characterized by a tight frequency-domain packing of the subcarriers with a
subcarrier spacing Δf = 1 / Tu , where Tu is the per-subcarrier modulation-symbol
time. See Figure 7.
OFDM transmission is block-based. During each OFDM symbol interval, N
modulation symbols are transmitted in parallel. The modulation symbols can be from
any modulation alphabet, such as QPSK, 16QAM, or 64QAM.
For 3GPP LTE, the basic subcarrier spacing equals 15 kHz. On the other hand, the
number of subcarriers depends on the transmission bandwidth, with in the order of
600 subcarriers in case of operation in a 10MHz spectrum allocation and
correspondingly fewer/more subcarriers in case of smaller/larger overall transmission
bandwidths.
Figure 7: OFDM subcarrier spacing

The physical resource in case of OFDM transmission is often illustrated as a time–
frequency grid where a column corresponds to one OFDM symbol (time) and a row
corresponds to one OFDM subcarrier, as illustrated in Figure 8.
In the ideal case, despite the fact that the spectrum of neighbor subcarriers do
overlap, the OFDM subcarriers do not cause any interference to each other after
demodulation due to the specific choice of a subcarrier spacing Δf equal to the
modulation symbol rate.
Page 23/222
Figure 8: OFDM time-frequency grid
An OFDM signal sampled at a rate f s = N × Δf is the size-N Inverse Discrete Fourier

Transform (IDFT) of the block of modulation symbols a 0 , a1 , K , a N −1 . Thus, OFDM
modulation can be implemented by means of IDFT processing followed by digital-to-
analog conversion (see Figure 9). In practice, the OFDM modulation can be
implemented by means of Inverse Fast Fourier Transform (IFFT) easy and fast
processing, by selecting the IDFT size N equal to 2 m for some integer m . At the
receiver, by sampling the received signal at the rate f s = N × Δf , efficient FFT
processing is used to achieve OFDM demodulation and retrieve the block of
modulation symbols a 0 , a1 , K , a N −1 (see Figure 10).
Figure 9: OFDM modulation
Page 24/222
Figure 10: OFDM demodulation
Cyclic prefix insertion
As mentioned above, an uncorrupted OFDM signal can be demodulated without any

interference between subcarriers. However, in case of a time-dispersive channel
(such as multipath radio channels), the orthogonality between the subcarriers is lost,
causing Inter Symbol Interference (ISI). The reason for this is that the demodulator
correlation interval for one path will overlap with the symbol boundary of a different
path (see Figure 11).
Figure 11: Time dispersion and corresponding received signal
To deal with this problem and make an OFDM signal truly insensitive to time
dispersion on the radio channel, so-called Cyclic Prefix insertion is typically used in
case of OFDM transmission. As illustrated in Figure 12, cyclic-prefix insertion implies
that the last part of the OFDM symbol (the last N cp symbols) is copied and inserted
at the beginning of the OFDM block, increasing thus the length of the OFDM symbol
from Tu to Tu + Tcp , where Tcp = N cp Tu is the length of the cyclic prefix. The OFDM
symbol rate as is reduced as a consequence. Thus, subcarrier orthogonality is

preserved in case of a time-dispersive channel, as long as the span of the time
dispersion is shorter than the cyclic-prefix length.
Page 25/222
Figure 12: Cyclic Prefix insertion
The drawback of cyclic-prefix insertion is that it implies a corresponding loss in terms

of throughput as the OFDM symbol rate is reduced without a corresponding
reduction in the overall signal bandwidth.
The combination of OFDM modulation (IFFT processing), a (time-dispersive) radio
channel, and OFDM demodulation (FFT processing) can then be seen as a
frequency-domain channel as illustrated in Figure 13, where during each OFDM
symbol time period, N different modulation symbols are transmitted, each on a given
subcarrier over the corresponding sub-band, in contrast to single wideband carrier
systems, such as a WCDMA where each modulation symbol is transmitted over the
entire bandwidth.
Figure 13: Frequency domain model of OFDM transmission reception
On frequency channel k , modulation symbol a k is scaled and phase rotated by the

complex (frequency-domain) channel coefficient H k . At the receiver side, to allow
Page 26/222
for proper decoding of the transmitted information after demodulation, the receiver
needs an estimate of the frequency-domain channel taps H 0 , H 1 , K , H N −1 . This can
be done by inserting known reference symbols, sometimes also referred to as pilot
symbols or pilots, at regular intervals within the OFDM time/frequency grid. Using
knowledge about the reference symbols, the receiver can estimate the (frequency-
domain) channel taps necessary for the decoding.
3GPP has defined two cyclic prefix formats as follows:
Normal-CP: length of 4.7µs where ~1.4km path length delay spread can be
tolerated. Normal-CP is the default CP-length that is used by the eNB.
Extended-CP: length of 16.7µs where ~5km path length delay spread can be
tolerated. This format has additional overhead compared to Normal-CP due to
lesser time per subframe for OFDM data symbols. Extended-CP is used only for
transmission of PMCH symbols to support MBMS operation (bCEM only), where
multiple cells transmit the same modulated symbols with very tight time
synchronization, but a UE may receive the signals with a large delay spread.
OFDM signal bandwidth
The basic bandwidth of an OFDM signal equals N × Δf , i.e. the number of

subcarriers multiplied by the subcarrier spacing. On the other hand, by setting the
symbols to be transmitted on a group of side contiguous subcarriers to zero, the
basic bandwidth is reduced to N c × Δf where N c is the number of non-null
subcarriers. However, the spectrum of an OFDM signal falls off slowly outside the
basic OFDM bandwidth and especially much slower than for a WCDMA signal. Thus,
in practice, typically in the order of 10% guard-band is needed for an OFDM signal,
implying that, as an example, in a spectrum allocation of 5 MHz, the basic OFDM
bandwidth N c × Δf could be in the order of 4.5 MHz. Assuming, for example, a
subcarrier spacing of 15 kHz as selected for LTE, this corresponds to 300
subcarriers in 5 MHz.
4.1.2 DFTS OFDM TRANSMISSION

Discrete Fourier Transform Spread OFDM (DFTS-OFDM) is a transmission scheme
that has been selected as the uplink transmission scheme for LTE. The basic
principle of DFTS-OFDM transmission is illustrated in Figure 14. Similar to OFDM
modulation, DFTS-OFDM relies on block-based signal generation. In case of DFTS-
OFDM, a block of M modulation symbols from some modulation alphabet, e.g.
QPSK or 16QAM, is first applied to a size- M DFT. The output of the DFT is then
applied to consecutive inputs of a size- N inverse DFT where N > M and where the
( N − M ) unused inputs of the IDFT are set to zero. Also similar to OFDM, a cyclic
prefix is inserted for each transmitted block.
Page 27/222
Figure 14: DFTS OFDM signal generation
Comparing Figure 14 with the IFFT-based implementation of OFDM modulation, it is

obvious that DFTS-OFDM can alternatively be seen as OFDM modulation preceded
by a DFT operation.
If the DFT size M equals the IDFT size N , the cascaded DFT and IDFT blocks of
Figure 14 will completely cancel out each other. However, if M is smaller than N
and the remaining inputs to the IDFT are set to zero, the output of the IDFT will be a
signal with low power variations, similar to a single-carrier signal. Besides, by varying
the block size M the instantaneous bandwidth of the transmitted signal can be
varied, allowing for flexible-bandwidth assignment.
The main benefit of DFTS-OFDM, compared to a multi-carrier transmission scheme

such as OFDM, is reduced variations in the instantaneous transmit power, implying
the possibility for increased power-amplifier efficiency. The power variations are
generally measured by the Peak-to-Average-Power Ratio (PAPR), defined as the
peak power within one OFDM symbol normalized by the average signal power. The
PAPR is significantly lower for DFTS-OFDM, compared to OFDM, making thus this
transmission technique very useful in the uplink considering the transmit power
capabilities of the mobile terminal.
The basic principle of DFTS-OFDM signal demodulation is illustrated in Figure 15.
The operations are basically the reverse of those for the DFTS-OFDM signal
generation of Figure 15, i.e. size- N DFT (FFT) processing, removal of the frequency
samples not corresponding to the signal to be received, and size- M Inverse DFT
processing.
Page 28/222
Figure 15: DFTS OFDM demodulation
4.1.3 OFDMA AND SC-FDMA

So far, we have (implicitly) assumed that all OFDM subcarriers were used by the
transmitter to transmit data to a certain receiver, i.e. downlink transmission to a
single mobile terminal and uplink transmission of all subcarriers from a single mobile
terminal. However, (DFTS) OFDM can also be used as a Multiple Access scheme,
allowing for simultaneous frequency-separated transmissions to or from multiple
mobile terminals (see Figure 16) i.e. different subsets of the overall set of available
subcarriers are used for transmission to (downlink) or from (uplink) different mobile
terminals. This Multiple Access technique is known as Orthogonal Frequency
Division Multiple Access (OFDMA) when based on OFDM transmission and Single
Carrier Frequency Division Multiple Access (SC-FDMA) when based on DFTS
OFDM. In LTE, OFDMA is used in the downlink (Figure 16a) and SC-FDMA is used
in the uplink (Figure 16b). The DFT size (for SC-FDMA) is given by the number of
subcarriers allocated to the mobile terminal.
Figure 16: (DFTS) OFDM as a multiple access technique
Note that in Figure 16, it is assumed that consecutive subcarriers are used for
transmission (to or from a given mobile terminal). However, distributing subcarriers in
the frequency domain is also possible as illustrated in Figure 17. The benefit of such
distributed allocation is a possibility for additional frequency diversity as each
transmission is spread over a wider bandwidth. As indicated in Figure 17, the
Page 29/222
technique of not using consecutive subcarriers is used in the downlink, but this
technique is not used for the uplink (because of potentially poor performance).
Figure 17: Distributed allocation in (DFTS) OFDM-based Multiple Access techniques
In the uplink, it is critical that the transmissions from the different mobile terminals
arrive approximately time aligned at the base station. Indeed, due to the differences
in distance to the base station for different mobile terminals and the corresponding
differences in the propagation time, it is necessary to control the uplink transmission
timing of each mobile terminal. Such transmit-timing control should adjust the
transmit timing of each mobile terminal to ensure that uplink transmissions arrive
approximately time aligned at the base station, and adapt as the mobile terminal
moves and the propagation time changes.
Further, subcarrier orthogonality may be lost (due to imperfect transmit-timing control
or Doppler shift), and given that in the uplink, the propagation distance and thus the
path loss of the different UE transmissions may differ significantly, this may imply a
potentially significant interference from the stronger signal to the weaker signal
(imperfect transmit-timing control, frequency errors). To avoid this, some degree of
uplink transmit-power control may need to be applied, reducing the transmit power of
user terminals close to the base station and ensuring that all received signals will be
of approximately the same power.
4.2 MULTIPLE ANTENNA TECHNIQUES

Multiple antenna techniques can be seen as a joint name for a set of techniques with
the common theme that they rely on the use of multiple antennas at the receiver
and/or the transmitter, in combination with some signal processing. Multi-antenna
techniques can be used to achieve improved system performance (improved system
capacity) and/or improved service provisioning (e.g. higher data rates).
Page 30/222
The availability of multiple antennas may be used to provide diversity against fading
on the radio channel, to shape the overall antenna beam in a certain way, known as
Beamforming, or to create what can be seen as multiple parallel communication
channels over the radio interface, known as Spatial Multiplexing.
Section 4.2.1 provides a general overview of different multiple antenna techniques
whereas section 4.2.2 briefly describes their use in LTE.
4.2.1 BASIC MULTIPLE ANTENNA TECHNIQUES
4.2.1.1 TIME DIVERSITY
4.2.1.1.1 CYCLIC DELAY DIVERSITY

A radio channel subject to time dispersion, with the transmitted signal propagating to
the receiver via multiple paths with different delays, provides the possibility for multi-
path diversity. Thus multi-path propagation is actually beneficial in terms of radio-link
performance, assuming that the transmission scheme includes tools to counteract
signal corruption due to multipath, for example, by means of OFDM transmission.
If the channel in itself is not time dispersive, the availability of multiple transmit
antennas can be used to create artificial time dispersion by transmitting identical
signals with different relative delays from the different antennas. This kind of Delay
Diversity is illustrated in Figure 18 for the special case of two transmit antennas.
Figure 18: Two-antenna delay diversity
Delay diversity is invisible to the mobile terminal, which will simply see a single radio-
channel subject to additional time dispersion.
LTE supports Cyclic-Delay Diversity (CDD), which is similar to the delay diversity
with the main difference that CDD is used on OFDM based transmission schemes
(such as pure OFDM and DFTS-OFDM) and applies cyclic shifts: a cyclic shift of the
time-domain signal corresponds to a complex-exponential frequency phase shift
(before OFDM modulation) the effect of which is repeated cyclically modulo the block
size (see Figure 19).
Page 31/222
Figure 19: Four-antenna Cyclic Delay Diversity with OFDM transmission
4.2.1.1.2 SPACE-FREQUENCY TIME CODING

Space-Frequency Block Coding (SFBC) is applicable to OFDM and other ‘frequency-
domain’ transmission schemes. It is illustrated in Figure 20. As can be seen, the
block of (frequency-domain) modulation symbols a 0 , a1 , a 2 , a 3 , K . is directly mapped
to OFDM carriers of the first antenna, while the block of symbols a 0* , a1* , a 2* , a 3* , K is
mapped to the corresponding subcarriers of the second antenna. Extension to more
than 2 antennas is only possible with a rate reduction.
Figure 20: Space Frequency time diversity with two transmit antennas
4.2.1.2 BEAMFORMING
If some knowledge of the downlink channels of the different transmit antennas, (more
specifically some knowledge of the relative channel phases) is available at the
transmitter side, multiple transmit antennas can be used to shape the overall
antenna beam in the direction of a target receiver. In general, such beamforming can
increase the signal-strength at the receiver in proportion to the number of transmit
antennas.
Page 32/222
The overall transmission beam can be adjusted in different directions by applying

different phase shifts to the signals to be transmitted on the different antennas, as
shown in Figure 21. The adjustments are generally based on estimates of the
direction to the target mobile terminal derived from feedback measurements.
Figure 21: Beamforming using 4 transmit antennas
Applying different phase shifts to the signals to be transmitted on the different

antennas can be expressed, in vector notation, as applying a size N T × 1 precoding
vector V to the signal to be transmitted.
If there is no radio channel time dispersion or if the effects of a time dispersive
channel are compensated for (by using OFDM for instance), the precoding consists
in rotating the transmitted signals to compensate for the instantaneous channel
phase and ensure that the signals received on the different receive antennas are
phase aligned.
4.2.1.3 SPATIAL MULTIPLEXING
In case of multiple antennas at both the transmitter and the receiver there is the
possibility for creating many parallel channels, allowing for (more efficient utilization
of high signal-to-noise and interference ratios and) significantly higher data rates
over the radio interface. This is referred to as Spatial Multiplexing. The term Multiple
Input Multiple Output (MIMO) antenna processing is also used. When the channel
conditions are rather good, the channel capacity can be made to grow essentially
linearly with the number of antennas.
Figure 22 illustrates an 2 × 2 antenna configuration (two transmit antennas and two
receive antennas).
Page 33/222
Figure 22: 2×2 antenna configuration
If there is no radio channel time dispersion or if the effects of such a channel are
compensated for (by using OFDM for instance), the received signals will be linear
combinations and the effect of the radio channel can be represented by a
matrix H (Figure 23) . At the receiver, the transmitted signals can easily be recovered
by linear combinations of the signals received on the different antennas. These
(reverse) linear combinations can be represented by another matrix, which is nothing
but the inverse matrix of H .
Figure 23: MIMO System Model
When the channel conditions on some antennas are bad, there is no use in using
them for Spatial Multiplexing (since Spatial Multiplexing is efficient in rather good
conditions), they should be used for beamforming (to improve the signal-to-noise
ratio) instead. Such combined beamforming and spatial multiplexing can be achieved
by means of precoder-based spatial multiplexing, as discussed below.
Page 34/222
4.2.1.4 PRECODER-BASED SPATIAL MULTIPLEXING
In the general case, a multiple-antenna configuration will consist of N T transmit

antennas and N R receive antennas. In such a case, the number of parallel signals
that can be spatially multiplexed is, at least in practice, upper limited by
N L = min (N T , N R ) (no more than N T different signals can be transmitted and no
more than N R spatially multiplexed signals can be separated).
Actually, the number of spatially multiplexed signals, or the order of the spatial
multiplexing should be determined based on the properties of the size N R × N T
channel matrix H .
Precoding in case of spatial multiplexing implies that linear processing by means of a
size N T × N L precoding matrix is applied at the transmitter side as illustrated in
Figure 24 where N L signals are spatially multiplexed and transmitted using N T
transmit antennas.
Figure 24: Precoder-based Spatial Multiplexing
The precoding is used to ‘orthogonalize’ (isolate) the parallel transmissions

(channels), and the precoding matrix V is determined based on the size
N R × N T channel matrix H . Theoretically, one can determine the matrices V and W
that perfectly match the channel matrix H (in the sense that no interference
between the spatially multiplexed signals will be present at the receiver) and the
transmission rate can be improved by a factor equal to the order of the multiplexing
(i.e. N L ). However, in practice, the channel matrix cannot be perfectly estimated.
Besides, the mobile terminal can only select a precoding matrix from a set of
available precoding matrices (the precoder codebook). As a consequence, there will
always be some residual interference between the spatially multiplexed signals, and
consequently, the achieved rate is improved by a factor less than the order of the
multiplexing. The closer the used precoding matrix is to the perfectly matched one,
the lower will be the interference (between the multiplexed signals) and the closer
the (rate) upgrade factor will be to N L .
It should be noted that when the number of signals to be spatially multiplexed is less
than the number of transmit antennas ( N L < N T ), precoding-based spatial
multiplexing combines spatial multiplexing with beamforming, just as though N L
antennas were used for spatial multiplexing and ( N T − N L ) antennas were used for
Page 35/222
beamforming with the difference that both effects are achieved by the precoding step
rather than by two separate operations.
From the discussion above, it is clear that to determine the matrices V and W ,
knowledge about the channel matrix H is needed. A common approach is to have
the receiver estimate the channel and decide on a suitable precoding matrix from the
precoder codebook. The receiver then reports this information to the transmitter. This
procedure is used in LTE.
4.2.2 MULTIPLE ANTENNA TECHNIQUES SUPPORT IN LTE

The use of multiple antennas is the key technology to reach the aggressive LTE
performance targets. However, the use of multi-antenna techniques is not mandatory
in the sense that LTE also supports single antenna transmission.
In general, the different multi-antenna techniques are beneficial in different

scenarios. As an example, at relatively low SINR, such as at high load or at the cell
edge, spatial multiplexing provides relatively limited benefits. Instead, in such
scenarios, multiple antennas at the transmitter side should be used to raise the SINR
by means of beam-forming. On the other hand, in scenarios where there already is a
relatively high SINR, raising the signal quality further provides relatively minor gains.
In such scenarios, spatial multiplexing should be used instead in order to fully exploit
the good channel conditions and increase the rate. The multi-antenna scheme used
is under control of the eNB, which therefore can select a suitable scheme for each
transmission.
On the other hand, in LTE, three types of transmissions are defined:
• The Single Antenna transmission technique.
• The Transmit Diversity (multiple antennas) technique.

• The Spatial Multiplexing (multiple antennas) technique.
The Spatial Multiplexing technique regroups (pure) beamforming and precoding-

based spatial multiplexing discussed earlier. Also, Cyclic Delay Diversity is used in
conjunction with the Spatial Multiplexing technique, and the Transmit Diversity
technique refers to the SFBC technique discussed earlier. Finally, note that the
Spatial Multiplexing technique is used only for transmission over the PMCH and the
PDSCH channels.
For simplicity, the UE may use several receive antennas but only uses one transmit
antenna. As a result, a single user is necessary to achieve MIMO and other multiple
antenna techniques in the downlink whereas multiple users are necessary to achieve
MIMO in the uplink. Thus, downlink MIMO is known as Single User MIMO (SU-
MIMO) whereas uplink MIMO is known as Multi-User MIMO (MU-MIMO).
Refer to Volume 2 for antenna configuration parameters.
Page 36/222
4.3 LTE FRAME STRUCTURE

As mentioned earlier, LTE is based on OFDM in the downlink and on DFTS OFDM in
the uplink.
The subcarrier spacing is Δf = 15kHz and is generated with a size-2048 IFFT
( N = 2048 ).
Below, the size of various fields in the time domain is expressed as a number of time
units T s = 1 (15000 × 2048) seconds.
Downlink and uplink transmissions are organized into radio frames with
Tf = 307200 ⋅ T s = 10ms duration. Two radio frame structures are defined in 3GPP:
• Type 1, applicable to Frequency Division Duplex (FDD),
• Type 2, applicable to Time Division Duplex (TDD).
Whether the eNodeB operates in FDD or TDD mode is indicated by the value of
parameter modeConf.
Enb::modeConf
Parameter modeConf
{ FDD,TDD }
Class/Source A--full-eNB-reset / system_restricted
Value FDD
Feature
Note that TDD is not relevant to this document. Consequently, only frame structure
type 1 is described below.
Each radio frame consists of 20 slots of length Tslot = 15360 ⋅ Ts = 0.5ms ,
numbered from 0 to 19. A subframe is defined as two consecutive slots where

subframe i consists of slots 2i and 2i + 1 .
The 10 subframes are available for both downlink and uplink transmissions. Uplink
and downlink transmissions are separated in the frequency domain.
Page 37/222
Figure 25: Frame structure type 1
DL
There are N symb = 7 OFDM symbols in a DL slot and N symb
UL
= 7 SC-FDMA symbols
in an UL slot.
As explained in section 4.1.3, different subsets of the overall set of available

subcarriers are used for transmission to different UEs. In LTE, the smallest
allocation unit is known as a Resource Block (RB).
DL
In the downlink, an RB is defined as N symb = 7 consecutive OFDM symbols in the
time domain and N scRB = 12 consecutive subcarriers in the frequency domain,

corresponding to one DL slot in the time domain and 180 kHz in the frequency
domain.
UL
In the uplink, an RB is defined as N symb = 7 consecutive SC-FDMA symbols in the
time domain and N scRB = 12 consecutive subcarriers in the frequency domain,
corresponding to one UL slot in the time domain and 180 kHz in the frequency
domain.
As explained earlier, the spectrum of a (DFTS) OFDM signal falls off slowly outside
the basic (DFTS) OFDM bandwidth and typically a guard-band is needed, implying
that, as an example, with a 10% guard-band used in LTE and a bandwidth of 5 MHz,
Page 38/222
the transmission bandwidth is in the order of 4.5 MHz, which corresponds to 300
subcarriers (with the 15 kHz subcarrier spacing used in LTE).
Figure 26 illustrates the difference between the channel bandwidth and the
transmission bandwidth. The channel edges FDL_low and FDL_high are defined as the
lowest and highest frequencies of the carrier separated by the channel bandwidth,
i.e. at fC+/-BWChannel/2.
Channel Bandwidth
Transmission Bandwidth Configuration
… …
15 kHz Center subcarrier (corresponds to DC

in baseband)
Figure 26: (DFTS) OFDM signal
DL
The DL transmission bandwidth is N RB × 180 kHz where N RB
DL
corresponds to the
total number of RBs in the DL during one slot.
RB × 180 kHz where N RB corresponds to the

The UL transmission bandwidth is N UL UL
total number of RBs in the UL during one slot.
The mapping between the channel bandwidth BWChannel and the transmission
bandwidth expressed in units of 180kHz ( N RB ) is the following
Page 39/222
BWChannel [MHz] 1.4 3 5 10 15 20

DL
N RB ( N RB for the
6 15 25 50 75 100
downlink and N UL
RB for the
uplink)
Table 1: Mapping between channel bandwidth and transmission
bandwidth
The downlink and uplink (channel and transmission) bandwidths are configured by
parameters dlBandwidth and ulBandwidth, respectively.
FrequencyAndBandwidthFDD::dlBandwidth
Parameter dlBandwidth
{ n6-1_4MHz, n15-3MHz, n25-5MHz, n50-10MHz, n75-15MHz,
n100-20MHz }
Value O.D. (See the Rule box below)
Feature L76501
With the following mapping
DL transmission bandwidth
dlBandwidth DL channel bandwidth DL
in units of 180 kHz ( N RB )
n6-1_4MHz 1.4 MHz 6
n15-3MHz 3 MHz 15
n25-5MHz 5 MHz 25
n50-10MHz 10 MHz 50
n75-15MHz 15 MHz 75
n100-20MHz 20 MHz 100
Page 40/222
FrequencyAndBandwidthFDD::ulBandwidth
Parameter ulBandwidth
{ n6-1_4MHz, n15-3MHz, n25-5MHz, n50-10MHz, n75-15MHz,
n100-20MHz }
Value O.D. (See the Rule box below)
Feature L76501
UL transmission bandwidth
ulBandwidth UL channel bandwidth
in units of 180 kHz ( N UL
RB )
n6-1_4MHz 1.4 MHz 6
n15-3MHz 3 MHz 15
n25-5MHz 5 MHz 25
n50-10MHz 10 MHz 50
n75-15MHz 15 MHz 75
n100-20MHz 20 MHz 100
Rule: Parameters dlBandwidth and ulBandwidth
In LR13.1, the UL bandwidth must be the same as the DL bandwidth for a given
cell. (Parameters ulBandwidth and dlBandwidth must be set to the same value as
a consequence).
If ulBandwidth is <unset>, then the UL bandwidth is considered to be equal to the
DL bandwidth.
Restriction: 15MHz dlBandwidth and ulBandwidth
15 MHz UL and DL bandwidth is only supported on bCEM.
In addition, the following features are restricted with 15 MHz bandwidth:

4Rx Diversity, Single Antenna Transmit, RACH Format 2, Fiber-Delay
Compensation, DAS Configuration, VoLTE.
Page 41/222
Restriction: 1.4 MHz and 3 MHz dlBandwidth and ulBandwidth
In LR13.1, 1.4 MHz and 3 MHz UL and DL bandwidth are only supported on
eCEM.
This restriction is removed in LR13.3 due to 1.4 MHz and 3 MHz UL and DL
bandwidth being supported on both eCEM and bCEM.
Restriction: dlBandwidth and ulBandwidth for Metro
Metro eNB supports only 5 and 10 MHz UL and DL bandwidth.

In addition, since it is a low power, integrated 2-antenna solution, the following
features are restricted with Metro:
4Rx Diversity, RACH Format 2 and TTI bundling.
The gpsFrameOffset parameter specifies the offset between the GPS one pulse per
second pulse and the start of the air interface radio frame. It is given in units of Tc
(260.4167ns). It indicates how many Tc units after the GPS pulse the next air
interface frame will start.
LteCell::gpsFrameOffset
Parameter gpsFrameOffset
[0…38399] step = 1 Tc
Class/Source B--Modem+Cell(s) / system_restricted
Value 0 ALU recommends that the operator not change this value
Feature
Restriction: gpsFrameOffset
FDD currently does not support the gpsFrameOffset parameter (not used for
FDD). Therefore, this parameter should always be set to 0.
Half-Duplex
With the eCEM, an FDD cell can be configured in Half-Duplex Mode. This mode is
only used in some specific trials.
In this mode, all UEs in the cell operate in Half-Duplex.
In Half-Duplex FDD operation, the UE cannot transmit and receive at the same time.
This is ensured by the UL and DL schedulers.
Page 42/222
Parameter duplexMode configures the duplex mode the cell operates in, with 3
possible values:
• “FddFullDuplex”: all UEs are in Full-Duplex mode.

• “FddHalfDuplex”: all UEs are in Half-Duplex mode.
• “FDDMixedDuplex”: all UEs are Half-Duplex at setup, and can be identified
later as Full-Duplex. (not supported in LR13.1).
LteCellFDD::duplexMode
Parameter duplexMode
{FddFullDuplex, FddHalfDuplex, FddMixedDuplex}

Class/Source B--Cell / system_restricted
Value FddFullDuplex
Feature L115820
Restriction: FDD Half Duplex mode
FDD Mixed Duplex mode and the associated “FddMixedDuplex” value are not
supported. Therefore, parameter duplexMode must not be set to
“FddMixedDuplex”.
Page 43/222
Restriction: Half duplex mode restrictions
In LR13.1, the restrictions apply in the half duplex mode (i.e. when duplexMode
is set to “FddHalfDuplex”):
• Bandwidths 10MHz, 15MHz and 20MHz are not supported.
• eMBMS (described Vol. 5) is not supported.

• SPS (described in Vol. 4) is not supported.
• VoIP is not supported.
• Fractional Power Control (described in Vol. 4).

• CS Fall Back (described in Vol. 6) is not supported.
• RoHC (described in section 5.3.3 ) is not supported.
• Group Hopping (described in Vol. 4) is not supported.

• Intra LTE Inter-frequency and Inter-RAT frequency (described in Vol. 6)
Handovers are not supported.
• Intra LTE Intra-frequency S1 HO (described in Vol. 6) is not supported.

• PRB licensing (see Vol. 4) is not supported.
• eUTRAN sharing (see Vol. 4 and Vol. 5) is not supported.
• IPv6 is not supported.
• SON features ANR (described in Vol. 4) and auto PCI (described in Vol.
5) are not supported.
4.3.1 DOWNLINK RESOURCE GRID

The transmitted signal in each slot is described by a resource grid (see Figure 27) of
DL RB DL
N RB N sc subcarriers and N symb OFDM symbols.
The smallest time-frequency unit for downlink transmission is a resource element. A

downlink resource element corresponds to one subcarrier for the duration of one
OFDM symbol and represents the resource grid identified by the index pair (k, l ) in a
slot where k = 0,..., N RB N sc − 1 and l = 0,..., N symb

DL RB DL
− 1 are the indices in the frequency
and time domains, respectively. A complex value is transmitted over each resource
element. Resource element (k, l ) on antenna port p corresponds to the complex
value ak( ,pl) . Quantities ak ,l corresponding to resource elements not used for
transmission in a slot are set to zero.
Page 44/222
DL
A physical resource block thus consists of N symb × N scRB resource elements. Physical
DL
resource blocks are numbered from 0 to N RB − 1 in the frequency domain. The
relation between the physical resource block number n PRB in the frequency domain
and resource elements (k , l ) in a slot is given by
⎢ k ⎥
n PRB = ⎢ RB ⎥
⎣⎢ N sc ⎦⎥
Tslot
DL
N symb
k = N RB N sc − 1
DL RB
DL
N symb × N scRB
subcarrier
subcarrier
s
(k , l )
× N scRB
s
N scRB
DL
N RB
k =0
l=0 l= DL
N symb −1
Figure 27: Downlink resource grid
Page 45/222
4.3.2 UPLINK RESOURCE GRID

The transmitted signal in each slot is described by a resource grid (see Figure 28) of
N UL RB UL
RB N sc subcarriers and N symb SC-FDMA symbols.
The smallest time-frequency unit for uplink transmission is a resource element. An

uplink resource element corresponds to one subcarrier for the duration of one SC-
FDMA symbol and represents the resource grid identified by the index pair (k , l ) in a
RB N sc − 1 and l = 0,..., N symb − 1 are the indices in the frequency

slot where k = 0,..., N UL RB UL
and time domains, respectively. A complex value is transmitted over each resource
element. Resource element (k , l ) corresponds to the complex value ak ,l . Quantities
ak ,l corresponding to resource elements not used for transmission in a slot are set to
zero.
UL
A physical resource block thus consists of N symb × N scRB resource elements. A
Resource Block consists of N scRB subcarriers during 1 time slot (which consists of
UL
N symb SC-FDMA symbols per subcarrier).
N UL
RB represents the total number of (Physical) Resource Blocks in the uplink and
depends on the uplink transmission bandwidth configured in the cell.
The relation between the physical resource block number n PRB in the frequency
domain and resource elements (k , l ) in a slot is given by
⎢ k ⎥
n PRB = ⎢ RB ⎥
⎣⎢ N sc ⎦⎥
Page 46/222
Tslot
UL
N symb
k = N RB N sc − 1
UL RB
UL
N symb × N scRB
(k , l )
× N scRB
N scRB
UL
N RB
k =0
l=0 l= UL
N symb −1
Figure 28: Uplink resource grid
4.4 PHYSICAL LAYER PROCESSING
4.4.1 CHANNEL CODING

Transport Blocks and/or physical layer control information is encoded at the physical
layer prior to modulation, layer mapping and OFDM/SC-FDMA signal generation.
The channel coding scheme is a combination of error detection (CRC based), error
correcting, rate matching and interleaving.
The error correction scheme applied to Transport Block is based on either a rate 1/3
turbo coder or a rate 1/3 convolutional coder.
Page 47/222
The error correction scheme applied to physical layer control information is based on
either a rate 1/3 convolutional coder or a rate 1/16 block code or a rate 1/3 repetition
code or a (20, A) block code, where A represents the number of UCI channel quality
bits (when transmitted on the PUCCH channel), and varies between 1 and 4.
The different error correcting coding schemes applied to transport channels and
physical layer control information is shown in Table 2 and Table 3, respectively.
Transport Channel Coding scheme Coding rate

UL-SCH
DL-SCH
Turbo coding 1/3
PCH
MCH
Convolutional
BCH 1/3
coding
Table 2: Channel coding scheme for Transport Blocks
Control Information Coding scheme Coding rate

Tail biting
DCI convolutional 1/3
coding
CFI Block code 1/16
HI Repetition code 1/3
UCI Block code variable
Table 3: Channel coding scheme for physical layer control information
The convolutional coder is a [133, 171, 165] (octal) whereas the turbo coder is a
Parallel Concatenated Convolutional Code (PCCC) using two 8-state constituent
encoders with transfer functions g0(D) = 1 + D2 + D3 and g1(D) = 1 + D + D3.
4.4.2 PHYSICAL CHANNELS

A physical channel is defined by a set of physical resources used to transmit either
Transport Blocks (physical channels to which are mapped transport channels) and
sometimes physical layer level control information or solely physical layer level
control information (physical channels to which no transport channel is mapped).
Page 48/222
Physical channels to which are mapped transport channels (i.e. physical channels
the resources of which carry Transport Blocks and sometimes physical layer level
control information) are:
• The Physical Broadcast Channel (PBCH): Represents the DL time/frequency
resources that carry BCH Transport Blocks, a BCH TB being transmitted
over a 4 subframes in a 40 ms interval.
• The Physical Multicast Channel (PMCH): Represents the DL time/frequency
resources that carry MCH Transport Blocks.
• The Physical Downlink Shared Channel (PDSCH): Represents the DL
time/frequency resources that carry DL-SCH and PCH Transport Blocks.
• The Physical Uplink Shared Channel (PUSCH): Represents the UL

time/frequency resources that carry UL-SCH Transport Blocks and at times
Uplink Control Information (UCI). UCI consists of:
o HARQ ACK/NACKs in response to downlink transmissions.

o Scheduling Requests (SRs).
o UE CQI/PMI/RI measurement reports.
• Physical Random Access Channel (PRACH): Represents the UL

time/frequency resources that carry the Random Access Preamble.
Physical channels to which no transport channel is mapped (i.e. physical channels

the resources of which carry physical layer level control information) are:
• The Physical Control Format Indicator Channel (PCFICH): Represents the

DL time/frequency resources that carry the Control Format Indicator (CFI),
i.e. the duration of PDCCH in terms of number of OFDM symbols. The CFI is
transmitted in every DL subframe.
• The Physical Downlink Control Channel (PDCCH): Represents the DL
time/frequency resources that carry the Downlink Control Information (DCI),
i.e.
o The transport format and resource allocation related to DL-SCH and
PCH (transport blocks transmitted over PDSCH).
o The transport format and resource allocation related to UL-SCH (i.e.
transport blocks transmitted over PUSCH).
o HARQ information related to UL-SCH.
• The Physical Hybrid ARQ Indicator Channel (PHICH): Represents the DL

time/frequency resources that carry the HARQ Indicator (HI), i.e. HARQ
ACK/NACKs in response to uplink transmissions.
• The Physical Uplink Control Channel (PUCCH): Represents the UL

time/frequency resources that carry the Uplink Control Information (UCI), i.e.
o HARQ ACK/NACKs in response to downlink transmissions.
Page 49/222
o Scheduling Requests (SRs).

o UE CQI/PMI/RI measurement reports.
4.4.3 PHYSICAL SIGNALS

Physical signals consist of a set of complex-valued symbols. They do not carry
binary information.
The downlink physical signals are:
• The Reference Signal (RS): Used for channel estimation and handover. One
reference signal is transmitted per antenna port.
• The primary synchronization signal: Used for slot synchronization. For a
given cell, the primary synchronization is one of 3 sequences.
• The secondary synchronization signal: Used for frame synchronization. For a
given cell, it is one of 168 sequences.
There are 168 × 3 = 504 different combinations of primary and secondary

synchronization signals. Each combination uniquely identifies a physical cell identity
(defined by parameter pci) within a cluster of up to 504 cells. The secondary
synchronization signal identifies the physical layer cell identity group (0 to 167) which
is defined by Int(pci/3), while the primary synchronization signal identifies the cell
within the group (0 to 2) which is derived by mod(pci/3) . Refer to Volume 5 for the
description of parameter pci.
The uplink physical signals are:

• The Demodulation Reference Signal (DM RS): Associated with transmission
of PUSCH or PUCCH.
• The Sounding Reference Signal (SRS): Not associated with transmission of

PUSCH or PUCCH.
Both DM RS and SRS are used for channel estimation for coherent demodulation.
Also, the same set of base sequences is used for DM RS and SRS.
4.4.4 DOWNLINK BASEBAND SIGNAL GENERATION

The number of antennas used for signal transmission over a given physical channel
is denoted by P and in case of Spatial Multiplexing, the number of layers (one layer
representing one spatially multiplexed channel) used is denoted by υ .
Page 50/222
4.4.4.1 DOWNLINK PHYSICAL CHANNELS PROCESSING
The processing of a downlink physical channel is defined in terms of the following

steps:
• Scrambling of coded bits in each of the code words to be transmitted on the
physical channel.
• Modulation of scrambled bits to generate complex-valued modulation

symbols.
• Mapping of the complex-valued modulation symbols onto one or several
transmission layers.
• Precoding of the complex-valued modulation symbols on each layer for
transmission on the antenna ports.
(q)
For each codeword q , the block of bits b ( q ) (0),..., b ( q ) ( M bit − 1) (where M bit
(q)
is the
number of bits in codeword q transmitted on the physical channel in one subframe),

is scrambled prior to modulation, resulting in a block of scrambled bits
~ ~ (q)
b ( q ) (0),..., b ( q ) ( M bit − 1) .
Up to two codewords can be transmitted in one subframe (i.e. q ∈ {0,1}). In the case
of single codeword transmission, q is equal to zero.
~ ~ (q)
For each codeword q , the block of scrambled bits b ( q ) (0),..., b ( q ) ( M bit − 1) is
modulated using BPSK, QPSK, 16 QAM or 64 QAM (see Table 4) resulting in a

(q)
block of complex-valued modulation symbols d ( q ) (0),..., d ( q ) ( M symb − 1) .
Physical channel Modulation schemes

PDSCH QPSK, 16QAM, 64QAM
PMCH QPSK, 16QAM, 64QAM
PBCH QPSK
PCFICH QPSK
PDCCH QPSK
PHICH BPSK
Table 4: Modulation schemes used for transmission over downlink physical
channels
Note that each downlink physical channel has specificities (such as the supported
modulation) but the description provided in the rest of this section is general and
holds for all the downlink physical channels.
Page 51/222
4.4.4.1.1 LAYER MAPPING

The complex-valued modulation symbols for each of the codewords to be transmitted
are mapped onto one or several layers. Complex-valued modulation symbols
(q)
d ( q ) (0),..., d ( q ) ( M symb − 1) for code word q ∈ {0,1} shall be mapped onto the layers
[ ]
x(i ) = x ( 0) (i ) ... x (υ −1) (i ) , i = 0,1,..., M symb
T layer
− 1 where M symb
layer
is the number of
modulation symbols per layer.
(0)
Let M symb be the number of modulation symbols codeword 0 is mapped onto
(1)
(number of symbols in d ( 0) ) and let M symb be the number of modulation symbols
codeword 1 is mapped onto (number of symbols in d (1) ).
4.4.4.1.1.1 LAYER MAPPING FOR SINGLE ANTENNA TRANSMISSION
For transmission on a single antenna port, a single layer is used, i.e. υ = 1 , and the
mapping is defined by
x ( 0) (i ) = d ( 0) (i ) , i = 0,1,..., M symb
layer
−1
layer
with M symb = M symb
(0)
.
4.4.4.1.1.2 LAYER MAPPING FOR SPATIAL MULTIPLEXING
For spatial multiplexing, the layer mapping is done according to Table 5. The number
of layers υ is less than or equal to the number of antenna ports P used for
transmission of the physical channel. The case of a single codeword mapped to two
layers is only applicable when the number of antenna ports is 4. Also, recall that only
2 transmit antennas can be used ( υ ∈ {1,2} ).
Page 52/222
Number of Number of codewords Codeword-to-layer mapping

layers i = 0,1,..., M symb
layer
−1
1 1 x ( 0) (i ) = d ( 0) (i )
layer
M symb = M symb
( 0)
x ( 0) (i ) = d ( 0) (i )
2 2
layer
M symb = M symb
( 0)
= M symb
(1)
x (i ) = d
(1) (1)
(i )
x (i ) = d (2i )
(0) ( 0)
2 1
layer
M symb = M symb
(0)
2
x (1) (i ) = d ( 0) (2i + 1)
x ( 0) (i ) = d ( 0) (i )
3 2 x (1) (i ) = d (1) (2i )
layer
M symb = M symb
( 0)
= M symb
(1)
2
x ( 2) (i ) = d (1) (2i + 1)
x ( 0) (i ) = d ( 0) (2i)
x (1) (i ) = d ( 0) (2i + 1) layer
M symb = M symb
( 0)
2 = M symb
(1)
2
4 2
x ( 2) (i ) = d (1) (2i )
x (3) (i ) = d (1) (2i + 1)
Table 5: Codeword-to-layer mapping for spatial multiplexing [R04]
4.4.4.1.1.3 LAYER MAPPING FOR TRANSMIT DIVERSITY
For transmit diversity, the layer mapping is done according to Table 6. There is only
one codeword.
Number of Number of Codeword-to-layer mapping

layers codewords i = 0,1,..., M symb
layer
−1
x ( 0) (i ) = d ( 0) (2i ) layer
M symb = M symb
( 0)
2
2 1 x (1) (i ) = d ( 0) (2i + 1)
x ( 0) (i ) = d ( 0) (4i )
x (1) (i ) = d ( 0) (4i + 1) layer
M symb = M symb
( 0)
4
4 1 x ( 2) (i ) = d ( 0) (4i + 2)
x (3) (i ) = d ( 0) (4i + 3)
Table 6: Codeword-to-layer mapping for transmit diversity [R04]
4.4.4.1.2 PRECODING
The precoder takes as input a block of vectors [ ]
x(i ) = x (0) (i ) ... x (υ −1) (i ) ,
T
i = 0,1,..., M symb
layer
−1 from the layer mapping and generates a block of
Page 53/222
[ ]T
vectors y (i ) = ... y ( p ) (i ) ... , i = 0,1,..., M symb
ap
− 1 to be transmitted on each of the
ap
antenna ports, where y ( p ) (i ) represents the signal for antenna port p and M symb is
the number of modulation symbols per antenna port.
4.4.4.1.2.1 PRECODING FOR TRANSMISSION ON A SINGLE ANTENNA

PORT
For transmission on a single antenna port, precoding is defined by
y ( p ) (i ) = x ( 0) (i )
with i = 0,1,..., M symb

ap
− 1 and M symb
ap
= M symb
layer
.
Also, p ∈ {0,4,5} (the single antenna port used can be port 0 or port 4 or port 5) for
transmission over the PDSCH channel and the PMCH channel. For transmission
over the PHICH, PBCH and PCFICH channels, p = 0 (the antenna port used is port
0).
4.4.4.1.2.2 PRECODING FOR SPATIAL MULTIPLEXING
Spatial multiplexing supports two or four antenna ports (i.e. P ∈ {2,4} ) and the set of
antenna ports used simultaneously is p ∈ {0,1} or p ∈ {0,1,2,3} , respectively. The
number of layers (order of multiplexing in this case) υ is less than or equal to P .
Precoding without CDD

Without cyclic delay diversity (CDD), precoding for spatial multiplexing is defined by
⎡ y ( 0) (i ) ⎤ ⎡ x ( 0) (i ) ⎤
⎢ ⎥ ⎢ ⎥
⎢ M ⎥ = W (i ) ⎢ M ⎥
⎢ y ( P −1) (i )⎥ ⎢ x (υ −1) (i )⎥
⎣ ⎦ ⎣ ⎦
where the precoding matrix W (i ) is of size P ×υ , i = 0,1,..., M symb

ap
− 1 and
ap
M symb = M symb
layer
.
For Spatial Multiplexing, the values of W (i ) shall be selected among the precoder
elements in the codebook configured in the eNodeB and the UE.
Precoding with CDD
With CDD, precoding for spatial multiplexing is defined by
⎡ y ( 0) (i ) ⎤ ⎡ x ( 0) (i ) ⎤
⎢ ⎥ ⎢ ⎥
⎢ M ⎥ = W (i ) D(i )U ⎢ M ⎥
⎢ y ( P −1) (i )⎥ ⎢ x (υ −1) (i )⎥
⎣ ⎦ ⎣ ⎦
Page 54/222
where the precoding matrix W (i ) is of size P × υ and i = 0,1,..., M symb

ap
−1
ap
and M symb = M symb
layer
. The diagonal size- υ × υ matrix D (i ) supporting cyclic delay
diversity and the size- υ × υ matrix U are both given by a table in the standard for
different numbers of layers υ .
The values of the precoding matrix W (i ) shall be selected among the precoder
elements in the codebook configured in the eNodeB and the UE.
Note that in both cases (with or without CDD), when υ = 1 the precoding matrix is a
(precoding) vector that multiplies each modulation symbol and results in a vector of
shifted symbols, each of which is transmitted on a separate antenna port. In this
case, the precoding achieves nothing but pure beamforming using P antennas.
When 1 < υ ≤ P , this operation achieves the precoding of a precoder-based Spatial
Multiplexing as defined in section 0.
4.4.4.1.2.3 PRECODING FOR TRANSMIT DIVERSITY

The precoding operation for transmit diversity is defined for two and four antenna
ports (i.e. P ∈ {2,4} ) and the set of antenna ports used simultaneously is
p ∈ {0,1} or p ∈ {0,1,2,3} , respectively. The number of layers (the diversity order in this
case) υ is equal to P .
In LR13.1, we have the following restrictions
• P = 2 and p ∈ {0,1} . The number of layers (the diversity order in this case) υ
is equal to P .
• The number of layers is equal to the number of codewords.
For transmission on two antenna ports, p ∈ {0,1} , the output y (i ) = y ( 0) (i ) [ ]

T
y (1) (i ) ,
i = 0,1,..., M symb
ap
− 1 of the precoding operation is illustrated in Figure 29 with
(0)
i = 0,1,..., M symb
layer
− 1 and M symb
ap
= 2M symb
layer
. Note that x (i) is the complex conjugate of
x(0)(i).
x ( 0) (i ) x ( 0) (i ) x (1) (i )
Precoding
x (1) (i ) − x (1) (i ) x ( 0) (i )
Figure 29: Precoding for Transmit Diversity with 2 antennas
Page 55/222
For transmission on four antenna ports, p ∈ {0,1,2,3} , the output
[
y (i ) = y (0) (i ) y (1) (i ) y ( 2) (i ) ]
T
y (3) (i ) , i = 0,1,..., M symb
ap
− 1 of the precoding operation
is illustrated in Figure 30 with i = 0,1,..., M symb

layer
− 1 and M symb
ap
= 4M symb
layer
.
x(0)(i) x(0)(i) x(1)(i) 0 0
x(1)(i) 0 0 x(2)(i) x(3)(i)

Precoding
x(2)(i) -x(1)(i) x(0)(i) 0 0
x(3)(i) 0 0 -x(3)(i) x(2)(i)
Figure 30: Precoding for Transmit Diversity with 4 antennas
4.4.4.2 DOWNLINK PHYSICAL SIGNALS PROCESSING
A physical signal transmitted in a subframe consists of a complex-valued sequence

that is mapped to the associated predefined resource elements.
4.4.4.3 MAPPING TO RESOURCE ELEMENTS AND OFDM

SIGNAL GENERATION
For each of the antenna ports used for transmission of a given physical channel, the
ap
block of complex-valued symbols y ( p ) (0),..., y ( p ) ( M symb − 1) is mapped in sequence
starting with y ( p ) (0) to the resource elements assigned for the transmission (in units
of resource blocks) by the MAC DL scheduler (see [Vol. 4]).
The mapping to resource elements (for all the downlink physical channels and
signals) represents the first step for the generation of the OFDM baseband signal
s l( p ) (t ) (where l is the index of the OFDM symbol and p is the port number), as
illustrated in Figure 9.
Page 56/222
4.4.5 UPLINK BASEBAND SIGNAL GENERATION
4.4.5.1 UPLINK PHYSICAL CHANNELS PROCESSING
Let b(0),..., b( M bit − 1) be the block of bits to be transmitted on the uplink physical
channel in a given subframe.
4.4.5.1.1 PUSCH PROCESSING

The processing of the PUSCH channel is defined in terms of the following steps:
• Scrambling
• Modulation of scrambled bits.

• Transform precoding.
The block of bits b(0),..., b( M bit − 1) , is scrambled with a UE-specific scrambling

sequence prior to modulation, resulting in a block of scrambled bits
~ ~
b (0),..., b ( M bit − 1) .
~ ~
The block of scrambled bits b (0),..., b ( M bit − 1) is directly mapped to a sequence of
complex-valued modulation symbols.
PUSCH uses QPSK, 16-QAM or 64-QAM.
Let M scPUSCH be the number of subcarriers allocated for transmission over the
PUSCH channel. The block of complex-valued symbols d (0),..., d ( M symb − 1) is
divided into M symb M scPUSCH sets, each corresponding to one SC-FDMA symbol.
Each block of M scPUSCH symbols is then transformed using a DFT, resulting in a block
of complex-valued symbols z (0),..., z ( M symb − 1) .
4.4.5.1.2 PUCCH PROCESSING

The PUCCH supports multiple formats. The processing of the PUCCH channel is
defined in terms of the following steps:
Page 57/222
• Scrambling (only with formats 2, 2a and 2b).
• Modulation of scrambled bits.

• Multiplication by cyclically shifted sequences.
With formats 1, 1a and 1b, the block of bits b(0),..., b( M bit − 1) is directly mapped onto
complex-valued modulation symbols d (0),..., d ( M symb − 1) (no scrambling).
With formats 2, 2a and 2b, the block of bits b(0),..., b( M bit − 1) , is first scrambled,
~ ~
resulting in a block of scrambled bits b (0),..., b ( M bit − 1) , then mapped onto complex-
valued modulation symbols d (0),..., d ( M symb − 1) .
Table 7 specifies the modulation schemes applicable for the PUCCH channel. Note
that formats 2a and 2b are only supported with normal cyclic prefix.
PUCCH format Modulation schemes

1a BPSK
1b QPSK
2 QPSK
2a QPSK + BPSK
2b QPSK + QPSK
Table 7: PUCCH modulation schemes
After modulation mapping, the modulation symbols d (0),..., d ( M symb − 1) are multiplied
by cyclically shifted sequences yielding complex-valued symbols z (0),..., z ( M symb − 1) ,
which are mapped onto resource elements.
4.4.5.2 UPLINK PHYSICAL SIGNALS PROCESSING
A physical signal transmitted in a subframe consists of a complex-valued sequence

that is mapped to the associated predefined resource elements.
4.4.5.3 MAPPING TO RESOURCE ELEMENTS AND SC-FDMA

SIGNAL GENERATION
The block of complex-valued symbols z (0),..., z ( M symb − 1) is mapped in sequence
starting with z(0) to the resource elements assigned for the transmission (in units of
resource blocks) by the MAC UL scheduler (see [Vol. 4]).
Page 58/222
The mapping to resource elements (for all the uplink physical channels and signals,
except PRACH) represents the first step for the generation of the SC-FDMA
baseband signal s l (t ) (where l is the index of the SC-FDMA symbol), as illustrated in
Figure 14.
Note that PUCCH is never transmitted simultaneously with the PUSCH from the
same UE.
4.4.6 SIGNAL UPCONVERSION
The baseband (OFDM) downlink signal s l( p ) (t ) is upconverted to carrier frequency
f 0 according to Figure 31:
cos (2πf 0 t )
{ }
Re sl( p ) (t )
sl( p ) (t )
{
Im sl( p ) (t ) }
− sin (2πf 0t )
Figure 31: Downlink Signal upconversion
The baseband (SC-FDMA) uplink signal s l (t ) is upconverted to carrier frequency f 0
according to Figure 32:
Page 59/222
cos (2πf 0 t )
Re {sl (t )}
sl (t )
Im{sl (t )}
− sin (2πf 0 t )
Figure 32: Uplink Signal Upconversion
The FDD LTE system is designed to operate in the frequency bands defined in Table
8. The whole signal must fit into the band in which the cell is operating.
Page 60/222
Uplink (UL) Downlink (DL) Duplex Supported in

Band Comments
FUL_low – FUL_high FDL_low – FDL_high Mode LR13.1
1 1920 MHz - 1980 MHz 2110 MHz – 2170 MHz FDD 2100 MHz Band
US PCS 1900 √
2 1850 MHz - 1910 MHz 1930 MHz – 1990 MHz FDD
MHz Band
3 1710 MHz - 1785 MHz 1805 MHz – 1880 MHz FDD 1800 MHz Band √
4 1710 MHz - 1755 MHz 2110 MHz – 2155 MHz FDD US AWS Band √
3GPP TS 36.101
indicates that
6 830 MHz - 840 MHz 875 MHz – 885 MHz FDD
this band is “not
applicable”
8 880 MHz – 915 MHz 925 MHz - 960 MHz FDD 900 MHz Band
1749.9 MHz – 1784. 1844.9 MHz – 1879.9
9 FDD 1700 MHz Band
MHz9 MHz
10 1710 MHz – 1770 MHz 2110 MHz – 2170 MHz FDD Extended AWS
1427.9 MHz – 1452.9 1475.9 MHz – 1500.9
11 FDD
MHz MHz
Lower 700 MHz √
12 698 MHz – 716 MHz 728 MHz – 746 MHz FDD
(A+B+C)
Upper 700 MHz √
(Upper C Band)
14 788 MHz – 798 MHz 758 MHz - 768 MHz FDD Public Safety √
17 704 MHz – 716 MHz 734 MHz – 746 MHz FDD Lower 700 MHz √
20 832 MHz – 862 MHz 791 MHz – 821 MHz FDD 800 MHz EDD √
1447.9 MHz – 1462.9 1495.9 MHz – 1510.9 FDD
21 1500 MHz Band
MHz MHz
3410 MHz – 3490 3510 MHz – 3590 FDD
22 3500 MHz Band
MHz MHz
2000 MHz – 2020 2180 MHz – 2200 FDD
23 S Band
MHz MHz
1626.5 MHz – 1660.5 1525 MHz – 1559 FDD √
24 L Band
MHz MHz
1850 MHz – 1915 1930 MHz – 1995 FDD √
25 PCS+ G block
MHz MHz
26 814 MHz – 849 MHz 859 MHz – 894 MHz FDD 800 MHz iDEN √
Table 8: E-UTRA FDD frequency bands
Page 61/222
Restriction: E-UTRA FDD frequency bands for Metro
In LR13.1, Metro eNB can only operate in bands 4, 13 and 25 (HW dependent).
The carrier frequency f 0 in the uplink ( f 0,UL ) and downlink ( f 0, DL ) is designated by

the E-UTRA Absolute Radio Frequency Channel Number (EARFCN).
The relation between EARFCN and the downlink carrier frequency f 0, DL (in MHz) is
given by the following equation, where FDL_low and NOffs-DL are given in Table 9 and
dlEARFCN is the parameter that configures the downlink EARFCN.
f 0, DL = FDL_low + 0.1(dlEARFCN – NOffs-DL) ….. (1)
The relation between EARFCN and the uplink carrier frequency f 0,UL (in MHz) for
the uplink is given by the following equation where FUL_low and NOffs-UL are given in
Table 9 and ulEARFCN is the parameter that configures the uplink EARFCN.
f 0,UL = FUL_low + 0.1(ulEARFCN – NOffs-UL) ….. (2)
Equations (1) and (2) are solved for the EARFCN values to yield:
dlEARFCN = 10 × ( f 0, DL - FDL_low ) + NOffs-DL
ulEARFCN = 10 × ( f 0,UL - FUL_low ) + NOffs-UL
For example, assume that the cell is operating in frequency band 13 with a downlink
carrier center frequency of 751 MHz and an uplink carrier center frequency of 782
MHz. Using the relationships provided above, the dlEARFCN is set to 5230, and the
ulEARFCN is set to 23230.
Page 62/222
Downlink Uplink
E-UTRA FDL_low [MHz] NOffs-DL Range of DL FUL_low [MHz] NOffs-UL Range of UL
Band EARFCN EARFCN
1 2110 0 0 – 599 1920 18000 18000 – 18599
2 1930 600 600 − 1199 1850 18600 18600 – 19199
3 1805 1200 1200 – 1949 1710 19200 19200 – 19949
4 2110 1950 1950 – 2399 1710 19950 19950 – 20399
5 869 2400 2400 – 2649 824 20400 20400 – 20649
6 875 2650 2650 – 2749 830 20650 20650 – 20749
7 2620 2750 2750 – 3449 2500 20750 20750 – 21449
8 925 3450 3450 – 3799 880 21450 21450 – 21799
9 1844.9 3800 3800 – 4149 1749.9 21800 21800 – 22149
10 2110 4150 4150 – 4749 1710 22150 22150 – 22749
11 1475.9 4750 4750 – 4999 1427.9 22750 22750 – 22999
12 728 5000 5000 – 5179 698 23000 23000 - 23179
13 746 5180 5180 – 5279 777 23180 23180 – 23279
14 758 5280 5280 – 5379 788 23280 23280 – 23379
17 734 5730 5730 - 5849 704 23730 23730 - 23849
18 860 5850 5850 – 5899 815 23850 23850 – 23999
19 875 6000 6000 - 6149 830 24000 24000 – 24149
20 791 6150 6150 – 6449 832 24150 24150 - 24449
21 1495.9 6450 6450 - 6599 1447.9 24450 24450 - 24599
22 3510 6600 6600 - 7399 3410 24600 24600 - 25399
23 2180 7500 7500 - 7699 2000 25500 25500 - 25699
24 1525 7700 7700 - 8039 1626.5 25700 25700 - 26039
25 1930 8040 8040 - 8689 1850 26040 26040 - 26689
26 859 8690 8690 - 9030 814 26040 26690 - 27039
Table 9: EARFCN related frequencies
The eNodeB supports the configuration of two different carrier frequencies when two
bCEMs are used. This feature is activated when isDualCarrierEnabled = true.
Refer to Volume 2 for further information. When this feature is activated, an eNodeB
must be configured with two instances of FrequencyAndBandwidthFDD::dlEARFCN
and two instances of FrequencyAndBandwidthFDD::ulEARFCN to configure each of
the two different carrier frequencies in the DL and UL, respectively. The two carrier’s
center frequencies must be spaced by a minimum of 30 MHz.
Page 63/222
FrequencyAndBandwidthFDD::dlEARFCN
Parameter dlEARFCN
[0..61999], Step = 1
Class/Source A--full-eNB-reset / customer_init
Value O.D.
Feature
Valid range of this parameter is 0-39649 or 60000-61999.
Restriction: dlEARFCN
In LR13.1: In only values in the range 0-39649 should be used. Values in the
range 60000-61999 are only used for specific trial purposes.
FrequencyAndBandwidthFDD::ulEARFCN
Parameter ulEARFCN
[18000..65535], Step = 1
Class/Source B—Cell+RF(s) / customer_init
Value O.D.
Feature
Valid range of this parameter is 18000-39649 or 62000-65535.
If this parameter is <unset>, then the value determined from the default TX-RX
frequency separation, defined in [R12] Table 5.7.3-1 and also shown in Table 9 of
this volume, will be used.
Restriction: ulEARFCN
In LR13.1, only values in the range 18000-39649 should be used. Values in the
range 62000-65535 are only used for specific trial purposes.
If ulEARFCN is <unset>, UL EARFCIN is determined from the default TX-RX
frequency separation defined in TS 36.101 [42, table 5.7.3-1].
Page 64/222
5 LAYER 2
Layer 2 is split in the following sublayers: Medium Access Control (MAC), Radio Link
Control (RLC) and Packet Data Convergence Protocol (PDCP).
This section gives a description of the three sublayers. Figure 33 and Figure 34
depict the PDCP/RLC/MAC architecture in the downlink and in the uplink,
respectively.
Figure 33: Layer 2 structure in the downlink
Figure 34: Layer 2 structure in the uplink
Page 65/222
The multiplexing of several logical channels on the same transport channel (i.e.
Transport Block) is performed by the MAC layer. In both uplink and downlink, only
one Transport Block is generated per TTI (subframe).
5.1 THE MEDIUM ACCESS CONTROL SUBLAYER
5.1.1 SERVICES AND FUNCTIONS

The main services and functions of the MAC (sub)layer are:
• Mapping between logical channels and transport channels.

• Multiplexing/demultiplexing of MAC SDUs belonging to one or different
logical channels into/from transport blocks (TB) delivered to/from the
physical layer on transport channels.
• Error correction through HARQ.
• Priority handling between logical channels of one UE and priority handling
between several UEs.
• Transport format selection.
5.1.2 CONFIGURATION OF DOWNLINK PHYSICAL

CHANNELS AND SIGNALS
5.1.2.1 REFERENCE SIGNALS
One downlink cell-specific Reference Signal is transmitted per downlink antenna port
(port 0 in case of 1 transmit antenna and ports 0 and 1 in case of 2 transmit
antennas).
In an M subframe (when MBSFN is activated), reference signals also occupy port 4.
Figure 35 and Figure 36 and respectively show the mapping of Cell Reference
Signals (complex-valued symbols) to REs with 1 and 2 transmit antenna
configurations. This mapping is permanent.
Figure 37 and Figure 38 show the reference signal occupation of REs in an M

subframe. Note that an M subframe consists of 12 OFDM subframes which are
distributed between a non-MBSFN region (using normal Cyclic Prefix) and an
MBSFN region (using extended Cyclic Prefix) corresponding to the first CFI OFDM
symbols and the remaining (12-CFI) OFDM symbols, respectively. Please refer to
section 5.1.2.5 for more details on CFI.
The MBSFN RS are transmitted on port4.
Page 66/222
st nd
Frequencies RB – 1 slot RB – 2 slot
RE for RS on
1 0 1 0 antenna 1 &
unused on
antenna 0
0 1 0 1
RE for RS on
antenna 0 &
unused on
1 0 1 0 antenna 1
15 KHz 0 1 0 1
0.5 ms Time
Figure 35 : Reference Signal configuration for 1 antenna case
st nd
Frequencies RB – 1 slot RB – 2 slot
RE for RS on
1 0 1 0 antenna 1 &
unused on
antenna 0
0 1 0 1
RE for RS on
antenna 0 &
unused on
1 0 1 0 antenna 1
15 KHz 0 1 0 1
0.5 ms Time
Figure 36 : Reference Signal configuration for 2 antennas case
Page 67/222
Figure 37: Reference Signal Configuration for M subframe with port 0 in non-MBSFN
region and port 4 in MBSFN region, CFI=2 case
Figure 38: Reference Signal Configuration for M subframe with port 0 & 1 in non-
MBSFN region and port 4 in MBSFN region, CFI=2
Page 68/222
5.1.2.2 POSITIONING REFERENCE SIGNALS
Positioning Reference Signals (PRS) are used to enhance UE geolocation as

compared to the case when only cell-specific Reference Signals (RS) are used They
are generated in PDSCH and transmitted on Antenna port 6.
The RBs that carry PRS information symbols do not carry traffic in order to enhance
PRS hearability by UEs.
Please refer to section [Vol. 4] for details on the time/frequency resources occupied
by PRS.
5.1.2.3 SYNCHRONIZATION SIGNALS
The synchronization signals are transmitted on 2 × 1 × 72 = 144 REs (72 subcarriers

of the same OFDM symbol are used in 2 of the 10 subframes) each:
• In the frequency domain: The 72 central subcarriers, i.e. if subcarriers used
by Reference Signals are not counted:
o Subcarriers 0 to 71 in case of a 1.4 MHz bandwidth.

o Subcarriers 54 to 125 in case of a 3 MHz bandwidth.
o Subcarriers 414 to 485 in case of a 15 MHz bandwidth
• In the time domain:

o OFDM symbol 6 (last OFDM symbol of the first slot) of subframes 0
and 5 for the primary synchronization signal.
o OFDM symbol 5 (second to last OFDM symbol of the first slot) of
subframes 0 and 5 for the secondary synchronization signal.
• A single antenna port is used, with no possible switching to another antenna
port.
• [In the “antenna domain”, if the eNB is configured to use 2 transmit
antennas, i.e. if transmissionMode is set to “tm2”, “tm3” or “tm4”, then
o If parameter isSyncSignalsDiversityAllowed is set to “True”, both
antennas will be used for the transmission offering diversity at the
reception for the UE.
Page 69/222
o If parameter isSyncSignalsDiversityAllowed is set to “False”,

antenna port 0 is used by default. In case of transmit path failure on
antenna port 0, the synchronization signals are switched to antenna
port1 (i.e. the remaining antenna).
This is not supported in LR13.1, only antenna port 0 is used as mentioned
just above.
Note that the REs used for the transmission of synchronization signals are located in:
• RBs 0-5 in case of a 1.4 MHz bandwidth.
• RBs 4-10 in case of a 3 MHz bandwidth.

CellActivationService::isSyncSignalsDiversityAllowed
Parameter isSyncSignalsDiversityAllowed
Object ENBEquipment/Enb/LteCell/CellActivationService
True/False
Value false
Feature L84815(.0)
5.1.2.4 THE PHYSICAL BROADCAST CHANNEL (PBCH)
The PBCH consists of 1 × 4 × 72 = 288 REs (72 subcarriers of 4 consecutive OFDM

symbols in 1 subframe):
Page 70/222
• In the frequency domain, the 72 central subcarriers, i.e. if subcarriers used

by Reference Signals are not counted:
o Subcarriers 0 to 71 in case of a 1.4 MHz bandwidth.
o Subcarriers 414 to 485 in case of a 15 MHz bandwidth
• In the time domain, OFDM symbols 7-10 (first 4 OFDM symbols of the
second slot) of subframe 0.
Note that the REs used for PBCH are located in:
• RBs 0-5 in case of a 1.4 MHz bandwidth.

5.1.2.5 PHYSICAL LAYER CONTROL CHANNELS
Physical layer control channels (PCFICH, PHICH and PDCCH) occupy the entire
bandwidth in the first (1+CFI) OFDM symbols in 1.4 MHz-BW systems and in the first
CFI OFDM symbols in other system bandwidths.
In a unicast subframe, CFI can take one of the 3 values in the set {1, 2, 3}. Note that
in 1.4 MHz-BW systems, if Positioning Reference Signals (PRS) are enabled (i.e. if
isOtdoaHearabilityEnhancementAllowed is set to “True”), then only CFI=1 and
CFI=2 are possible in unicast subframes.
In a Multicast subframe or M subframe (when MBSFN is activated), CFI can only
take value 1 or 2. In LR13.1, only CFI=2 is supported.
The REs of this time/frequency area are grouped into Resource Element Groups
(REGs) that consist of 4 REs each. Note that REGs do not contain RS REs.
For M subframes, the CFI is statically configured by parameter
sib13NonMBSFNregionLength.
Page 71/222
For unicast subframes, the CFI is either determined statically from parameter cFI or
by a dynamic algorithm if dynamicCFIEnabled is set to “True” (in which case
parameter cFI is ignored).
The dynamic CFI selection allows the number of OFDM symbols used for PDCCH by
the DL scheduler to be adjusted according to the PDCCH usage. The PDCCH
usage is based on the number of UE contexts in the cell (i.e. RRC Connected UEs).
In LR13.1 if dynamic configuration of CFI is enabled by parameter

dynamicCFIEnabled, then a CFI value is determined whenever a UE context is
added or removed by comparing the number of UE contexts with predefined
thresholds provided by configurable OAM parameters, as follows:
If numberOfUEContexts > cFIThreshold2
o if cFI3Allowed = True, then the CFI is set to 3
o else if cFI2Allowed = True, then the CFI is set to 2
o else if cFI1Allowed = True, the CFI is set to 1
If cFIThreshold1 < numberOfUEContexts ≤ cFIThreshold2
o if cFI2Allowed = True, then the CFI is set to 2

o else if cFI3Allowed = true, then the CFI is set to 3
If numberOfUEContexts ≤ cFIThreshold1
o if cFI1Allowed = true, then the CFI is set to 1
where:
• numberOfUEContexts is the number of UE contexts in the cell
• cFIThreshold1, cFIThreshold2 are OAM parameters which control the
choice of CFI based on the number of UE contexts in the cell.
• cFI1Allowed, cFI2Allowed, and cFI3Allowed are OAM parameters which
enable the selection of each of the possible CFI values (1, 2 and 3,
respectively).
If the new CFI is larger than the current CFI, then the DL scheduler is notified in
advance to select a more robust MCS due to the decreased number of OFDM
symbols available for PDSCH. A configurable timer is started, equivalent to the
number of subframes set by parameter cFIIncreaseTimer. The new larger CFI
value is applied when this timer expires. This delay is implemented to avoid the CFI
to increase between HARQ retransmissions, as the MCS that was used for the 1st
HARQ transmission (prior to the CFI increase) may not be supported for a
retransmission on fewer OFDM symbols.
While cFIIncreaseTimer is running:
Page 72/222
o Further increases of CFI are ignored.

o If the CFI becomes less than or equal to the current CFI, this timer is
stopped and the DL scheduler is notified of the cancelled increase of CFI.
CellL1L2ControlChannelsConf::dynamicCFIEnabled
Parameter dynamicCFIEnabled
Object ENBEquipment/Enb/LteCell/CellL1L2ControlChannelsConf
True/False
Value See Engineering Recommendation
Feature L84872
CellL1L2ControlChannelsConf::cFI
Parameter cFI
[1..3]
Value See section 5.1.2.5.3
Feature
MbsfnArea::sib13NonMBSFNregionLength
Parameter sib13NonMBSFNregionLength
Object ENBEquipment/Enb/LteCell/MbsfnCellConf/MbsfnArea
{ s1, s2 }
Class/Source B--Cells-of-eNB / system_restricted
Value s2 ALU recommends that the operator not change this value
Feature L115527
Page 73/222
sib13NonMBSFNregionLength Number of OFDM symbols in the

non-MBSFN area of an M subframe
s1 1
s2 2
Rule: Regarding parameter sib13NonMBSFNregionLength
In LR13.1, this parameter must be set to “s2”, as per the restriction below.
Restriction: Parameter sib13NonMBSFNregionLength
In LR13.1, only value “s2” is supported for this parameter.
CellL1L2ControlChannelsConf::cFIThreshold1
Parameter cFIThreshold1
[1..500]
Value 1
Feature L84872
CellL1L2ControlChannelsConf::cFIThreshold2
Parameter cFIThreshold2
[1..500]
Value 3
Feature L84872
Page 74/222
CellL1L2ControlChannelsConf::cFI1Allowed
Parameter cFI1Allowed
[True/False]
Feature L84872
[True/False]
Feature L84872
True/False
Feature L84872
Page 75/222
Rule: Regarding parameters cFI1Allowed, cFI2Allowed, cFI3Allowed
WPS checks are implemented to ensure that at least one of these parameters is
set to “True”.
CellL1L2ControlChannelsConf::cFIIncreaseTimer
Parameter cFIIncreaseTimer
[1..10000]
Value 40
Feature L84872
5.1.2.5.1 THE PHYSICAL CONTROL FORMAT INDICATOR

CHANNEL (PCFICH)
The Physical Control Format Indicator Channel is located in the first OFDM symbol
of each subframe and spans over 4 REGs uniformly distributed over the system
bandwidth. It carries the CFI.
5.1.2.5.2 THE PHYSICAL HARQ INDICATOR CHANNEL (PHICH)

PHICH channels are grouped in PHICH groups. Each PHICH group consists of 8
PHICH channels (hence conveys 8 ACK/NACKs) that use the same resources,
PHICH channels of a same group being separated by orthogonal sequences.
In FDD, the number of PHICH groups in a subframe is:
group
N PHICH ⎡ (
= N g N RB
DL
8 )⎤
Page 76/222
where:
• N g ∈ {1 6 , 1 2 , 1, 2} and is configured by parameter phichResource.
DL
• N RB is the total number of RBs in the downlink and is configured by
parameter dlBandwidth (see section 4.3).
A PHICH group consists of 3 REGs over either 1 or 3 OFDM symbols, depending on

the value of parameter phich-Duration (“normal” or “extended”). This parameter can
only be set to “extended” if the CFI is equal to 3.
Rule: Parameter phich-Duration
In LR13.1, this parameter is hardcoded to “normal”. Hence PHICH is always

located in the first OFDM symbol of each subframe.
Parameter phichResource is a key RF parameter. Higher values allow for more UL

HARQ feedbacks, but leave fewer resources to PDCCH and hence a reduced
PDCCH robustness and/or fewer users served (reduced capacity).
PowerOffsetConfiguration::phichResource
Parameter phichResource
ENBEquipment/Enb/LteCell/TxDivOrMimoResources/PowerOff
Object
setConfiguration
{oneSixth , half , one , two }
Class/Source B--Cell / eng_tunable
Value one (See Restriction below)

Feature
Restriction: Parameter phichResource
In LR13.1, the only supported value for parameter phichResource is “one”. As a

result, the total number of PHICH groups is:
• 1 in a 1.4MHz-Bandwidth system.
• 2 in a 3MHz-Bandwidth system.
• 10 in a 15MHz-Bandwidth system
Page 77/222
5.1.2.5.3 THE PHYSICAL DOWNLINK CONTROL CHANNEL

(PDCCH)
PDCCH consists of the resources in the first CFI OFDM symbols that are occupied
neither by PCFICH nor by PHICH.
For PDCCH, the REGs are grouped into CCEs, one CCE being composed of 9
REGs, i.e. 1 CCE is composed of 9 × 4 = 36 REs.
Let N REG be the number of Resource Element Groups assigned neither to PCFICH
nor to PHICH. The PDCCH CCEs available are numbered from 0 to N CCE − 1 , where
N CCE = ⎣N REG / 9⎦ , meaning that the remaining N CCE − 9 × ⎣N REG / 9⎦ REGs that are
not enough to form a CCE are not used.
The number of PDCCH CCEs N CCE depends on the CFI and number of PHICH
groups, as illustrated in the tables just below:
N CCE
CFI phichResource 1.4MHz 3MHz 5MHz 10MHz 15MHz 20MHz
1 oneSixth 2 2 4 10 15 20
1 half 2 2 4 9 14 19
1 one 2 2 3 8 12 17
1 two 2 1 2 6 9 13
2 oneSixth 4 7 13 26 40 54
2 half 4 7 12 26 39 52
2 one 4 7 12 25 37 50
2 two 4 6 11 23 34 46
3 oneSixth 6 12 21 43 65 87
3 half 6 12 21 42 64 86
3 one 6 12 20 41 62 84
3 two 6 11 19 39 59 80
Number of PDCCH CCEs in different BW systems
Recall that only phichResource = “one” is supported in LR13.1.
Page 78/222
The PDCCH area contains search spaces. A search space consists of a set of
PDCCH candidates. A PDCCH candidate is an aggregate of L CCEs (i.e. consists
of L CCEs).
There is a search space specific to each connected UE and a search space common
to all UEs.
Each UE monitors the common search space and its specific UE search space for
possible a DCI (PDCCH message containing a grant and/or UL power control
commands).
At aggregation level L , the total number of PDCCH candidates M ( L ) per search
space is given by Table 10:
Search space type Aggregation level Number of PDCCH Search Space Size
(L )
L candidates M in (in CCEs)
the Search Space
UE Specific 1 6 6
2 6 12
4 2 8
8 2 16
Common 4 4 16
8 2 16
Table 10: Number of PDCCH candidates per search space
When the PDCCH message is sent in the UE-specific Search Space, the
aggregation level L is directly given by parameter
pdcchAggregationLevelForUESearchSpace.
When the PDCCH message is sent in the Common Search Space, the aggregation
level L is
• given by parameter
pdcchAggregationLevelForCRNTIGrantsInCommonSearchSpace when
the DCI message is associated with a dedicated channel. Note, however,
that in LR13.1, UL PDCCH messages sent in the common search space use
Aggregation Level 4.
• derived from parameter
pdcchAggregationLevelForNonCRNTIGrantsInCommonSearchSpace
and some other internal parameters, when the DCI message is associated
with a common channel (DL SRB0, PCCH and D-BCH).
The common search space occupies the first 16 CCEs in the PDCCH region.
The UE-specific search space is identified by the UE’s C-RNTI; PDCCH candidate
m of UE-specific search space S(C-RNTI) in subframe k occupies the L consecutive
CCEs starting at CCE number
Page 79/222
L.{(Yk (C − RNTI ) + m) mod ⎣N CCE UE - specific search space aggregatio n level ⎦}
m = 0, L , M ( L ) − 1
where Yk (C − RNTI ) is defined by the recurrence relationship

Yk (C − RNTI ) = ( A ⋅ Yk −1 (C − RNTI ) ) mod D with Y−1 (C − RNTI ) = n RNTI ≠ 0 , A = 39827
and D = 65537 .
Note that the common and UE-specific search spaces may overlap.
CellL1L2ControlChannelsConf::pdcchAggregationLevelForUESearchSpace
Parameter pdcchAggregationLevelForUESearchSpace
{1, 2, 4, 8, adaptive}
Feature
Restriction: Parameter pdcchAggregationLevelForUESearchSpace
In LR13.1, only values 2 and 4 are supported:
dlBandwidth pdcchAggregationLevelForUESearchSpace
n6-1_4MHz The only supported value is 2
n15-3MHz The only supported value is 2
n50-10MHz Only values 2 and 4 are supported
n75-15MHz Only values 2 and 4 are supported
Page 80/222
Engineering Recommendation: Parameter

pdcchAggregationLevelForUESearchSpace
The setting of parameter pdcchAggregationLevelForUESearchSpace is

defaulted as follows:
n6-1_4MHz 2 (only supported value)
n15-3MHz 2 (only supported value)
n50-10MHz 4
n75-15MHz 4
Page 81/222
Restriction: Supported CFI values and setting of parameter cFI
CFI=1 is only supported in 10 MHz, 15MHz and 20MHz system bandwidths.

Regarding 10MHz CFI=1 support please refer to engineering recommendation
below.
More specifically, CFI values supported per aggregation level are the following:
CFI supported
values
n6-1_4MHz 2 (only supported value) 3

n15-3MHz 2 (only supported value) 3
n25-5MHz 2 (only supported value) 2, 3
n50-10MHz 2 1, 2, 3
n50-10MHz 4 2, 3
n75-15MHz 2 1, 2, 3
n75-15MHz 4 1, 2, 3
n100-20MHz 4 (only supported value) 1, 2, 3
In case of static CFI setting (i.e. if dynamicCFIEnabled is set to “False”),

parameter cFI must be set to one of the supported values as per the above.
Engineering Recommendation: Regarding parameters cFI1Allowed,

cFI1Allowed and cFI3Allowed
Parameter cFI1Allowed should be set to “False” if CFI=1 is not supported in

the (dlBandwidth, pdcchAggregationLevelForUESearchSpace)
configuration in question.
Similarly, cFI2Allowed (resp. cFI3Allowed) should be set to “False” if CFI=2
(resp. CFI=3) is not supported in the (dlBandwidth,
pdcchAggregationLevelForUESearchSpace) configuration in question.
Engineering Recommendation: Regarding cFI=1 and dlBandwidth=n50-

10MHz
Configuration cFI=1 and dlBandwidth=n50-10MHz although it is supported

it’s not part of any defined commercial configuration. It shouldn’t be forced to
be used as currently it results in degraded performance.
Page 82/222
Engineering Recommendation: Regarding parameters

pdcchAggregationLevelForUESearchSpace, dynamicCFIEnabled and cFI
It is recommended to set dynamicCFIEnabled to “True” so that the CFI is

dynamically adjusted to use the lowest value needed for PDCCH usage. This
makes more OFDM symbols available to PDSCH when PDCCH usage is low
(fewer users), resulting in higher throughputs. In this case (dynamicCFIEnabled
set to “True), parameter cFI is ignored.
If dynamicCFIEnabled is set to “False”, the CFI is static and derived from
parameter cFI. The latter should be set as per the restriction just above and
keeping in mind that higher values of CFI allow for more PDCCH robustness
and/or more users served per TTI, but at the expense of throughput (fewer
resources for PDSCH).
Parameter dynamicCFIEnabled is currently defaulted to “True”.
dlBandwidth dynamicCFIEnabled
n6-1_4MHz False
n15-3MHz True
n25-5MHz True
n50-10MHz True
n75-15MHz True
n100-20MHz True
Parameters pdcchAggregationLevelForUESearchSpace and cFI are currently

defaulted as follows:
dlBandwidth pdcchAggregationLevelForUESearchSpace cFI
n6-1_4MHz 2 (only supported value) 3 (only

supported
value)
n15-3MHz 2 (only supported value) 3 (only

supported
value)
n50-10MHz 4 3
n75-15MHz 4 3
Page 83/222
CellL1L2ControlChannelsConf::pdcchAggregationLevelForCRNTIGrantsInCommonS
earchSpace
pdcchAggregationLevelForCRNTIGrantsInCommonSearchSpac
Parameter
e
{4, 8}
Value 4
Feature
CellL1L2ControlChannelsConf::pdcchAggregationLevelForNonCRNTIGrantsInComm
onSearchSpace
pdcchAggregationLevelForNonCRNTIGrantsInCommonSearchS
Parameter
pace
{4, 8}
Value 4
Feature L84872
During the process of allocation of UL resources a preselection is executed in order

to limit the maximum number of UEs that compete to get resources. This procedure
is carried out at each TTI, right before resource allocation, according to the following
steps:
• A prefiltering stage.
• A PDCCH resource constraints enforcement stage
• A preselection stage.
PDCCH resource constraints enforcement stage

In this stage, the UL scheduler checks if there is at least one PDCCH candidate
available in the common search space. If there isn’t and CCE overbooking is not
allowed, i.e. parameter uLCCEspaceMaxOverbookingFactor is set to 1 (rather than
to 2 or 3), then the scheduler removes from the list of remaining UEs which there
aren’t enough granting CCEs in the UE-specific search space.
Preselection stage
Page 84/222
This stage is carried out only if the number of UEs remaining after the prefiltering and
the PDCCH resource constraints enforcement stages is greater than the maximum
number of eligible UEs defined. After the prefiltering, a preselection metric is
computed for each of the remaining UEs (based on the QoS weight and the
wideband spectrum efficiency metric of the UE). The remaining UEs are then ranked
in decreasing order of preselection metric.
The preselection algorithm is then run starting from the top of the ranked list. It
consists, for each considered UE, in booking or overbooking CCEs (starting by the
UE specific search space) and preselecting the UE whenever that is possible. Note
that if uLCCEspaceMaxOverbookingFactor is set to 2, 2 layers of CCEs are
considered and if uLCCEspaceMaxOverbookingFactor is set to 3, 3 layers of CCEs
are considered.
If for a given UE, no CCE can be booked (in the first layer of CCEs) or overbooked
(in the second or third layer, depending on the setting of parameter
uLCCEspaceMaxOverbookingFactor) the UE is dropped i.e. is not preselected
CellRadioConf::uLCCEspaceMaxOverbookingFactor
Parameter uLCCEspaceMaxOverbookingFactor
Object ENBEquipment/Enb/LteCell/CellRadioConf
[0..3]

Value Default value = 1; Value 0 reserved for TDD – disables
functionality
Feature L108271
uLCCEspaceMaxOverbookingFactor - specifies the maximum CCE search space

overbooking factor allowed at the UL scheduling pre-selection stage. Value 0 is for
TDD only, to disable the functionality.
5.1.2.6 THE PHYSICAL DOWNLINK SHARED CHANNEL

(PDSCH)
PDSCH consists of the resources that are occupied neither by synchronization

signals, nor by PBCH nor by control channels (PCFICH, PHICH, PDCCH), in a
unicast subframe.
PDSCH is transmitted in TxDiv or MIMO (2-layer OL-MIMO, 2-layer CL-MIMO or 1-
Layer CL-MIMO) as explained in [Vol. 4].
5.1.2.7 THE PHYSICAL MULTICAST CHANNEL (PMCH)
PMCH consists of the resources that are occupied neither by synchronization

signals, nor by control channels (PCFICH, PHICH, PDCCH), in an M subframe
Page 85/222
(when MBMS is activated). A variable number of subframes in the set {sf1, sf2, sf3,
sf6, sf7, s8} can be M-subframes. Note that subframes 0, 4, 5 and 9 cannot be M
subframes.
PMCH is only transmitted on antenna port 4 that maps to one of the two eNB
physical antenna ports
Restriction: MBMS and PMCH
In LR13.1, MBMS and PMCH are supported in 10MHz and 20MHz-BW systems.
The subframe allocation pattern for eMBMS is determined by semi-statically by

eMBMS conrtol plane (features L115262, 158990 with MCE introduction – refer to
[Vol. 5] Section 10).
MBSFN subframes are semi-statically allocated by the MCE depending on the
number of started eMBMS sessions and their Qos parameters (essentially the GBR).
Note that when isMbmsBroadcastModeAllowed is set to “True”, the MBSFN

subframes are reused to unicast by MCE, if they are not assigned for MBMS traffic,
regardless of whether isMbmsTrafficAllowed is set to “True” or “False”.
5.1.3 CONFIGURATION OF UPLINK PHYSICAL CHANNELS

AND SIGNALS
5.1.3.1 REFERENCE SIGNALS
Two types of reference signals are used in the uplink.

• The Demodulation Reference Signal (DM RS), associated with PUSCH or
PUCCH.
• The Sounding Reference Signal (SRS), associated with PUSCH.
5.1.3.1.1 DEMODULATION REFERENCE SIGNAL

The DM RS is sent with each uplink transmission in the center SC-FDMA symbol of
slot 1 (i.e. the 4th SC-FDMA symbol of the subframe) and in the center SC-FDMA
symbol of slot 2 (i.e. the 11th SC-FDMA symbol of the subframe).
The sequence-group number u in slot ns is defined by a group hopping pattern

f gh (ns ) and a sequence-shift pattern f ss according to
Page 86/222
( )
u = f gh(n s ) + f ss mod 30
There are 17 different hopping patterns and 30 different sequence-shift patterns.

Sequence-group hopping can be enabled or disabled by means of parameter
groupHoppingEnabled. PUCCH and PUSCH have the same hopping pattern but
may have different sequence-shift patterns.
The difference between the sequence-shift pattern for PUCCH f ssPUCCH and the
sequence-shift pattern for PUSCH f ssPUSCH modulo 30 is configured by parameter
groupAssignmentPUSCH:
(
f ssPUSCH = f ssPUCCH + groupAssignmentPUSCH mod 30 )
ActivationService::groupHoppingEnabled
Parameter groupHoppingEnabled
True/False
Value True
Feature L84816
CellL1ULConf::groupAssignmentPUSCH
Parameter groupAssignmentPUSCH
Object ENBEquipment/Enb/LteCell/CellL1ULConf
[0..29]
Value 0
Feature L76501
In LR13.1, one base sequence number and 12 cyclic shift values are used to
generate the DM RS sequence for all UEs in the cell.
Page 87/222
(1) ( 2)
The cyclic shift value is determined from parameters n DMRS , n DMRS and generated
from a pseudo-random sequence:
• (1)
n DMRS is obtained from the cyclic shift field broadcasted in the cell inside the
UL-Reference SignalsPUSCH IE (see Table 11) and configured by
parameter ulRSCyclicShift.
• ( 2)
n DMRS is obtained from the cyclic shift field broadcast inside the UL grant
(see Table 12).
Cyclic Shift Field broadcasted

(1)
inside the UL-Reference n DMRS
SignalsPUSCH IE
000 0
001 2
010 3
011 4
100 6
101 8
110 9
111 10
(1)
Table 11: Mapping of the cyclic shift field value broadcast in the cell and n DMRS
Cyclic Shift Field in ( 2)

DCI format 0
n DMRS
000 0
001 6
010 3
011 4
100 2
101 8
110 10
111 9
( 2)
Table 12: Mapping of the cyclic shift field value broadcast in the cell and n DMRS
Page 88/222
CellL1ULConf::ulRSCyclicShift
Parameter ulRSCyclicShift
[0..7]
Value 0
Feature L76501
5.1.3.1.2 SOUNDING REFERENCE SIGNAL

The Sounding Reference Signal (SRS) is enabled/disabled by parameter
srsEnabled. It is transmitted on the last SC-FDMA symbol of the subframe (i.e. the
14th SC-FDMA symbol of the subframe).
LteCell::srsEnabled
Parameter srsEnabled
True/False
Class/Source C--Immediate-Propagation / system_restricted
Value True ALU recommends that the operator not change this value
Feature L76501
Restriction: Parameter srsEnabled
In LR13.1, SRS cannot be disabled as the UL scheduling and Power Control is

based on the SRS. Therefore, srsEnabled must not be set to “False”.
Up to 8 SRSs can be multiplexed per subframe, 4 per transmission comb.

Different SRS periods are supported for different UEs on the same cell.
The SRS bandwidth BWSRS (C SRS , BSRS ) is defined by:
Page 89/222
• Cell-specific parameter “SRS bandwidth configuration” C SRS , sent in
SoundingRsUl-ConfigCommon IE and configured by parameter

srsBandwidthConfiguration.
• UE-specific parameter “SRS bandwidth” BSRS ∈ {0,1,2,3} , sent in
SoundingRsUl-ConfigDedicated IE. A larger B SRS value results in an equal-

width or a narrower SRS bandwidth for the same “SRS bandwidth
configuration” C SRS .
In LR13.1, UE-specific parameter “SRS bandwidth” is set as follows:
• When isNarrowbandSRSuseEnabled is set to “False”, the UE-specific “SRS

bandwidth” is hardcoded to 0.
• When isNarrowbandSRSuseEnabled is set to “True”, the UE-specific “SRS

bandwidth” is set to the value configured by parameter
dedicatedSrsBandwidth, thus allowing to narrow the bandwidth for the same
“SRS bandwidth configuration” C SRS (srsBandwidthConfiguration), which is
used to stop the UE from applying AMPR reduction to the SRS. This is because
lower SRS power impacts UL sync detection performance at cell edge.
CellL1ULConf::srsBandwidthConfiguration
Parameter srsBandwidthConfiguration
{ bw0, bw1, bw2, bw3, bw4, bw5, bw6, bw7 }

Class/Source B / system_restricted

Feature L76501
CellActivationService::isNarrowbandSRSuseEnabled
Parameter isNarrowbandSRSuseEnabled
True/False
Value False
Feature L114492
Page 90/222
Restriction: Support of Narrow Band SRS
Narrow Band SRS is only supported with a 10MHz bandwidth,

FrequencyDiverseOnly and on Band 13. Therefore,
isNarrowbandSRSuseEnabled can only be set to “True” if ulBandwidth is set to
“n50-10MHz”, ulSchedulerMode = “FrequencyDiverseOnly” and
ul700MHzUpperCBlockEnabled = “True”.
CellL1ULConfFDD::dedicatedSrsBandwidth
Parameter dedicatedSrsBandwidth
Object ENBEquipment/Enb/LteCell/CellL1ULConf/CellL1ULConfFDD
{ bw0, bw1, bw2, bw3 }


Feature L114492
Engineering Recommendation: Parameter srsBandwidthConfiguration
When CellActivationService::isNarrowbandSRSuseEnabled is set to “false”, only

supported values of parameter srsBandwidthConfiguration are as follows:
ulBandwidth srsBandwidthConfiguration= SRS bandwidth in PRBs when

C SRS isNarrowbandSRSuseEnabled
is set to “False” =
BWSRS (C SRS ,0)
n6-1.4MHz bw7 4
n15-3MHz bw5 12
n25-5MHz bw2 24
n50-10MHz bw0 48
n75-15MHz bw0 72
n100-20MHz bw0 96
Page 91/222
Engineering Recommendation: Parameter dedicatedSrsBandwidth
Recall that when isNarrowbandSRSuseEnabled is set to “False”, BSRS is

hardcoded to “0” and parameter dedicatedSrsBandwidth is ignored.
When isNarrowbandSRSuseEnabled is set to “True”, the only configuration

supported in LR13.1 is:
• srsBandwidthConfiguration = C SRS = bw1.
• dedicatedSrsBandwidth = BSRS =bw1
This corresponds to an SRS bandwidth of BWSRS (CSRS , BSRS ) = 16 PRBs and starting
PRB index [1 + 16 ( ⎣srsFrequencyDomainPosition / 4⎦ mod3)].
Considering the fact that the only supported value for

srsFrequencyDomainPosition in is 8, the starting PRB index is 33 and the SRS
occupies PRBs 16-48.
With BW SRS (C SRS , BSRS ) = m(C SRS , b = B SRS ) where m(C SRS , b) is given, along with the
parameter “ N b ”, by Table 13 to Table 16 for each UL bandwidth “ N UL

RB ”.
SRS b=0 b =1 b=2 b=3

bandwidth m (C SRS , b) Nb m (C SRS , b) Nb m (C SRS , b) Nb m (C SRS , b) Nb
configuration
CSRS
0 36 1 12 3 4 3 4 1
1 32 1 16 2 8 2 4 2
2 24 1 4 6 4 1 4 1
3 20 1 4 5 4 1 4 1
4 16 1 4 4 4 1 4 1
5 12 1 4 3 4 1 4 1
6 8 1 4 2 4 1 4 1
7 4 1 4 1 4 1 4 1
Table 13: m(C SRS , b) and N b , b = 0,1,2,3 , values for the uplink bandwidth of 6 ≤ N RB
UL
≤ 40
Page 92/222
SRS b=0 b =1 b=2 b=3

configuration
CSRS
0 48 1 24 2 12 2 4 3
1 48 1 16 3 8 2 4 2
2 40 1 20 2 4 5 4 1
3 36 1 12 3 4 3 4 1
4 32 1 16 2 8 2 4 2
5 24 1 4 6 4 1 4 1
6 20 1 4 5 4 1 4 1
7 16 1 4 4 4 1 4 1
UL
≤ 60
SRS b=0 b =1 b=2 b=3

configuration
CSRS
0 72 1 24 3 12 2 4 3
1 64 1 32 2 16 2 4 4
2 60 1 20 3 4 5 4 1
3 48 1 24 2 12 2 4 3
4 48 1 16 3 8 2 4 2
5 40 1 20 2 4 5 4 1
6 36 1 12 3 4 3 4 1
7 32 1 16 2 8 2 4 2
UL
≤ 80
SRS b=0 b =1 b=2 b=3

configuration
CSRS
0 96 1 48 2 24 2 4 6
1 96 1 32 3 16 2 4 4
2 80 1 40 2 20 2 4 5
3 72 1 24 3 12 2 4 3
4 64 1 32 2 16 2 4 4
5 60 1 20 3 4 5 4 1
6 48 1 24 2 12 2 4 3
7 48 1 16 3 8 2 4 2
UL
≤ 110
The starting PRB of the SRS is given by
B SRS
S 0 = S 0' + ∑ BW
b =0
SRS (C SRS , BSRS ) (⎣4nRRC / BWSRS (CSRS , BSRS )⎦ mod N b )
with S 0' = N UL⎣ ⎦
RB / 2 − BWSRS (C SRS ,0) / 2 and C SRS = srsBandwidthConfiguation
Page 93/222
In LR13.1, the frequency domain parameter n RRC is set as follows:
• When isNarrowbandSRSuseEnabled is set to “False”, the frequency

domain parameter n RRC is hardcoded to 0.
When isNarrowbandSRSuseEnabled is set to “True”, the frequency domain
parameter n RRC is configured by parameter srsFrequencyDomainPosition.
Note that if isNarrowbandSRSuseEnabled is set to “True”, symmetrical SRS
bandwidth configuration is used.
CellL1ULConf::srsFrequencyDomainPosition
Parameter srsFrequencyDomainPosition
Object ENBEquipment/Enb/LteCell/CellL1ULConf/CellL1ULConf
[0..23]
Feature L114492
Restriction: Parameter srsFrequencyDomainPosition
In LR13.1, the only supported value for srsFrequencyDomainPosition is “8”.
5.1.3.2 PHYSICAL UPLINK CONTROL CHANNEL (PUCCH)
Table 17 lists the different PUCCH formats.

Note, however, that the support of formats 2a/2b is optional in the UE, indicated,
together with several other functions, by bit number 2 in IE featureGroupIndicators in
the IE UE-EUTRA-Capability in the UECapabilityInformation message.
PUCCH format Modulation scheme Content

1 N.A. SR
Page 94/222
• ACK/NACK only
1a BPSK
• ACK/NACK + SR
• ACK/NACK only
1b QPSK
• ACK/NACK + SR
2 QPSK P-CQI
2a QPSK+BPSK P-CQI + ACK/NACK
2b QPSK+QPSK P-CQI + ACK/NACK
Table 17: PUCCH formats
Table 18 shows lists the different PUCCH CQI/PMI reporting modes.
PMI Feedback Type

No PMI Single PMI
Feedback Type
Wideband
PUCCH CQI
Mode 1-0 Mode 1-1

(wideband CQI)
UE Selected
Mode 2-0 Mode 2-1
(subband CQI)
Table 18: PUCCH CQI/PMI reporting modes
Restriction: PUCCH CQI/PMI reporting modes
Only modes 1-0 and 1-1 are supported in LR13.1.
Note that mode 1-1 provides PMI feedback, only necessary for CL-MIMO, and is
therefore used in transmission mode 4 (i.e. when transmissionMode is set to
“tm4”).
Mode 1-0, on the other hand, provides no PMI feedback and is therefore used when
in transmission modes 2 or 3 (i.e. when is set to “TM2” or to “tm3”).
In LR13.1, PUCCH occupies pucchPRBsize = 2 or 4 or 6 PRBs, depending on the

system bandwidth (see Table 19). If the system is operating in the 700 MHz upper C
band, PUCCH PRBs are located around the 20 central PRBs (see section 5.1.3.4),
otherwise PUCCH PRBs are located at both edges of the spectrum, i.e. PRBs
[0…pucchPRBsize/2-1] and [ N UL UL
RB - pucchPRBsize/2 ... N RB -1].
Page 95/222
ulBandwidth N UL
RB pucchPRBsize
n6-1_4MHz 6 2
n15-3MHz 15 2
n25-5MHz 25 4
n50-10MHz 50 4
n75-15MHz 75 6
n100-20MHz 100 6
Table 19: PUCCH PRB size in LR13.1
Note that in 1.4MHz-BW systems, there is no PUCCH in the PRACH subframe since
the entire bandwidth consists of 6 PRBs and PRACH occupies 6 PRBs (see section
5.1.3.6.3).
SR parameters
Parameter dsrTransMax configures the maximum number of unanswered

Scheduling Requests (SR) before notifying RRC of the SR release, initiating a
Random Access procedure and cancelling all pending SRs.
Parameter srProhibitTimer controls the minimum separation in time between

consecutive Scheduling Request transmissions by the UE, as per 3GPP TS 36.321
section 5.4.4). It can be used to prevent unwanted repetitions of SRs. The parameter
is expressed in number of SR periods. srProhibitTimer = 0 means no minimum
interval, i.e. SRs can be sent according to the SR period (at every opportunity).
It is sent to the UE in the RRC IE sr-ProhibitTimer-r9. It applies to Rel9 UEs.
CellL1ULConf::srProhibitTimer
Parameter srProhibitTimer
[0..7] ms
Feature L114644
Page 96/222
CellL1ULConf::dsrTransMax
Parameter dsrTransMax
{ n4, n8, n16, n32, n64 }

Value n64
Feature L76501
The mapping between enumerate values and the actual values is as follows
Enumerate value Actual value
n4 4
n8 8
n16 16
n32 32
n64 64
CQI/PMI/RI configuration
Interaction with TTI bundling: As per 3GPP, the UE discards P-CQI/P-RI in case it
collides with a TTI-bundling transmission.
Therefore, a special algorithm is introduced to align the configurations between MG

and P-CQI/P-RI so that P-CQI/P-RI do not get dropped in case of collision with TTI-
bundling transmissions. This algorithm is only applied when the MG Feature is
enabled and TTI-bundling is activated and consists into forcing the P-CQI/P-RI
period to 80ms and adjusting the MG offset as a function of the P-CQI offset so that
• MG start position modulo 20 is not at subframe number [0, 5] to avoid any
collision with SIBx (which is in subframes from 0 to 5 every 20ms).
• P-CQI-MG offset is {1,2,3,4,10,11,12,13} TTIs in order to maximize the
number of TTIs where it is possible to issue a grant for a first TTI Bundling
HARQ transmission.
Page 97/222
5.1.3.3 PHYSICAL UPLINK SHARED CHANNEL (PUSCH)

In each subframe, PUSCH occupies the resources that are not occupied by PUCCH
or PRACH.
5.1.3.4 PUCCH/PUSCH IN THE 700MHZ UPPER C BLOCK

BAND
The frequency resource allocation in the 700 MHz Upper C block band is shown in
Figure 39:
• PUCCH is allocated symmetrically around the 20 central PRBs and occupies
the 14th, 15th, 36th and 37th PRBs. This is achieved by over-provisioning
PUCCH CQI resource with 50-20-pucchPRBsize=26 PRBs (using standard
parameter nRBCQI) and then recycling the 50-20-pucchPRBsize=26 PRBs into
PUSCH (see Figure 39). Recall that standard parameter nRBCQI configures
the number of PRBs available for PUCCH Formats 2/2a/2b (i.e. the number
of PRBs available for periodic CQI).
• PUSCH occupies the remaining frequency resources.
o PUSCH is split into 3 frequency zones (Zone A, Zone B, Zone C)

o In Zone A, a lower PSD is used to avoid interference to devices
operating in adjacent public safety systems.
13 PRB P 20 PRB P 13 PRB

U U
(Low power) C C
C PUSCH C PUSCH
PUSCH
H H
Zone A Zone B Zone C
PUCCH resource PUCCH resource
recycled into PUSCH 2 2 recycled into PUSCH
resource PRB PRB resource
Figure 39: Frequency allocation in the 700 MHz Upper C block band in LR13.1
Page 98/222
5.1.3.5 PUCCH/SRS CONFIGURATION
On eCEM, PUCCH/SRS configuration is derived from a static Lookup Table.
On bCEM, PUCCH/SRS configuration is dynamically managed. This is to adapt the

PUCCH/SRS configuration to the varying number of connected UEs.
Note that each cell managed by a bCEM runs an independent PUCCH/SRS
configuration algorithm.
The individual user PUCCH/SRS configuration is assigned at (Initial) RRC
Connection Setup, or at RRC Connection Re-establishment or at (incoming)
handover.
Four PUCCH/SRS configuration profiles are defined:
• The premium profile with 20ms P-CQI period, 10ms SR period and 20ms
SRS period.
• The normal profile, with 40ms PCQI period, 20ms SR period and 20ms SRS
period.
• The base profile, with 80ms P-CQI period, 40ms SR period and 80ms SRS
period.
• The minimum profile, with 160ms P-CQI period, 80ms SR period and 80ms
SRS period, with some UEs using 160ms SRS period.
The initial profile, which is also the highest profile that will be assigned, is determined
by parameter initPUCCHSRSConfigProfile.
The PUCCH/SRS configuration of the cell is at best revised every
pucchReconfigPaceTimer sec.
The PUCCH/SRS configuration of a given user is at best revised every
minPucchConfigLifeTime sec.
Page 99/222
CellL1ULConf::initPUCCHSRSConfigProfile
Parameter initPUCCHSRSConfigProfile
{ Basic, Normal, Premium, Super }

Value Premium
Feature L115233
LR13.1 – LA6.0 Delta: parameter initPUCCHSRSConfigProfile
In LR13.1, value “Super” has been added to the enumerate. This value is
reserved for specific trial purposes only.
CellL1ULConf::minPucchConfigLifeTime
Parameter minPucchConfigLifeTime
Range & Unit Float
[0.0..10.0] step = 0.1s

Value 3.0
Feature L115233
Page 100/222
CellL1ULConf::pucchReconfigPaceTimer
Parameter pucchReconfigPaceTimer
Range & Unit Float
[0.0..10.0] step = 0.1s

Value 1.0
Feature L115233
In LR13.3, FRS166802 allows to configure the thresholds for PUCCH/SRS profile

down-switch and up-switch, through the parameters
pucchSrsConfStepDownLoadingThreshold and
pucchSrsConfStepUpLoadingThreshold. These thresholds are given as a
percentage of the internal resources in use.
pucchSrsConfStepDownLoadingThreshold: is a 3-entry list, indicating the
PUCCH/SRS loading thresholds to assign a lower UE configuration profile. The first
entry corresponds to Super->Premium, second entry corresponds to Premium-
>Normal, the third entry corresponds to Normal->Base switching point.
pucchSrsConfStepUpLoadingThreshold: is a 3-entry list, indicating the

PUCCH/SRS loading thresholds to assign a higher UE configuration profile. The first
entry corresponds to Premium->Super, the 2nd entry corresponds to Normal-
>Premium, the 3rd entry correspondsto Base->Normal switching point.
In addition, the worst PUCCH/SRS configuration profile that can be selected is
configurable through the parameter worstPucchSrsConfigAllowed.
The PUCCH/SRS profile downgrade procedure is done with RRC connection

reconfiguration procedure (it was done with intra-cell Handover before this feature).
CellL1ULConf::pucchSrsConfStepDownLoadingThreshold
Parameter pucchSrsConfStepDownLoadingThreshold
Range & Unit List of three Integer
[0..100]
Value 30, 40, 60 (Default)

Feature 166802
Page 101/222
CellL1ULConf::pucchSrsConfStepUpLoadingThreshold
Parameter pucchSrsConfStepUpLoadingThreshold
Range & Unit List of three Integer
[0..100]
Value 20, 30, 50 (Default)
Feature 166802
CellL1ULConf::worstPucchSrsConfigAllowed
Parameter worstPucchSrsConfigAllowed
[Super, Premium, Normal, Basic]

Value Basic (Default)

Feature 166802
5.1.3.6 PHYSICAL RANDOM ACCESS CHANNEL (PRACH)
5.1.3.6.1 PRACH FORMATS

The random access preamble, illustrated in Figure 40, consists of a cyclic prefix of
length (i.e. duration) TCP and a sequence part of length TSEQ . Values of TCP and
TSEQ depend on the preamble format.
TCP TSEQ
Figure 40 : Random access preamble format
Page 102/222
Preamble TCP TSEQ Preamble Maximum cell

format transmission radius
window duration
0 3168 ⋅ Ts 24576 ⋅ Ts 1 subframe 14.5 km
1 21024 ⋅ Ts 24576 ⋅ Ts 2 subframes 77 km
2 6240 ⋅ Ts 2 ⋅ 24576 ⋅ Ts 2 subframes 30 km
3 21024 ⋅ Ts 2 ⋅ 24576 ⋅ Ts 3 subframes 100 km
Table 20: Random Access preamble formats for FDD
Restriction: Random Access preamble format
- Only format-0,format-2 and format-3 are supported by eNB.
- The eNB supports a maximum radius of 70 km for format-3.
- format-3 is supported on bCEM only.
- format-3 is not supported on 1.4 MHz and 3 MHz in LR13.1. This restriction is
removed in LR13.3 due to 1.4 MHz and 3 MHz BW being supported on bCEM.
- maxNbrOfUsers is limited to 400 for format-3.
CellActivationService::pRACHPreambleFormat
Parameter pRACHPreambleFormat
{format0, format2, format3, format4}

Value format0 (default)

Feature L115767
Page 103/222
LR13.1 – LA6.0 Delta: parameter pRACHPreambleFormat
In LA6.0, only format-0 and format-2 were supported. Parameter

pRACHPreambleFormat2Enabled was used to select format-0 (if “False”) or
format-2 (if “True).
In LR13.1, pRACHPreambleFormat2Enabled is replaced by

pRACHPreambleFormat with enumerated values to select any supported RACH
format. Each cell on a bCEM may be configured with a different format. That is, a
mix of RACH format (0, 2, or 3) is supported in a single bCEM.
Selection of format 3 requires a feature license.
Note that format4 is not applicable to FDD.
Rule: Migration Rule Parameter pRACHPreambleFormat
IF
CellActivationService::pRACHPreambleFormat2Enabled == True
THEN
CellActivationService::pRACHPreambleFormat = format2
ELSE
CellActivationService::pRACHPreambleFormat = format0
Figure 41, Figure 42, Figure 43 and Figure 44 show simplified representations of
Hardware configurations and associated cabling delays.
The cabling delay is equal to the sum of the CPRI delay and the antenna path delay.
Please refer to [Vol. 2]for details on the computation of (total) cabling delay.
Note that the cabling delay does not include the BBU and/or RFM processing delays.
However, it does include processing delay(s) associated with any additional HW
between RFM and antenna (such as the DAS optical host).
Also note that these illustrations focus on delay aspects and show one cell, with 1
antenna per antenna node (one transmit antenna scheme perspective).
Page 104/222
BBU
CPRI Link (Fiber) Feeder (Coaxial Cable)
Modem RRH
CPRI Delay
Antenna Path Delay
(BBU-measured)
Figure 41: Simplified view of RRH-based Hardware and associated delays when
DAS is not used (cell view, case of 1 transmit antenna per antenna node)
BBU
DAS
Feeder DAS Fiber Remote
CPRI Link (Fiber) (Coaxial Cable) DAS
Modem RRH Optical DAS Fiber
Unit DAS
Remote
Host Unit
CPRI Delay Feeder
Antenna Path Delay
Figure 42: Simplified view of RRH-based Hardware when DAS is used (cell view,
9412 Compact eNodeB

BBU
CPRI Link Feeder (Coaxial Cable)

Modem TRDU
CPRI Delay
(BBU-measured)
Antenna Path Delay
Figure 43: Simplified view of TRDU-based Hardware when DAS is not used (cell
9412 Compact eNodeB

BBU
DAS
Feeder DAS DAS Fiber Remote
CPRI Link (Coaxial Cable)
Optical Unit DAS
Modem TRDU Host
DAS Fiber Remote
Unit
CPRI Delay Feeder
Antenna Path Delay
Figure 44: Simplified view of TRDU-based Hardware when DAS is used (cell view,
In LR13.1, TotalRTT0 = 200μs (on eCEM and on bCEM when

maxTransportFiberDelayLengthCategory is set to “fifteenKm”) and TotalRTT0 =
170μs on bCEM when maxTransportFiberDelayLengthCategory is set to “tenKm”,
and Tprocessing is assumed to be equal to 50 μs (the processing delay varies
depending on the Hardware used). Therefore, T0, cabling is assumed to be equal to
75 μs=75000 ns (on eCEM and on bCEM when
Page 105/222
maxTransportFiberDelayLengthCategory is set to “fifteenKm”) and to be equal to

60 μs=60000 ns on bCEM when maxTransportFiberDelayLengthCategory is set
to “tenKm”. Therefore, the modem can compensate for 75000ns of cabling on eCEM
and on bCEM when maxTransportFiberDelayLengthCategory is set to “fifteenKm”
and can compensate for 60000ns of cabling on bCEM when
maxTransportFiberDelayLengthCategory is set to “tenKm”, i.e. the maximum OTA
cell radius given by Table 20 is maintained if the cabling delay is less than 75000ns
on eCEM and on bCEM when maxTransportFiberDelayLengthCategory is set to
“fifteenKm” and if the cabling delay is less than 60000ns on bCEM when
maxTransportFiberDelayLengthCategory is set to “tenKm”. If the cabling delay
exceeds 75000ns (or 60000ns according to the case), then the non-compensated
delay eats in the OTA cell radius, resulting in a reduction of the maximum OTA Cell
Radius given by Table 20 in the amount [3×Extra Delay (ns)/10000] km where Extra
Delay is the one-way non-compensated cabling delay and is equal to “Cabling Delay
(ns) – 75000 ns”.
Preamble Format Maximum OTA Cell Radius

0 14.5 - [3×(Cabling Delay (ns) – 75000)/10000] km
2 30 km - [3×(Cabling Delay (ns) – 75000)/10000] km
Table 21: Maximum OTA Cell Radius when the cabling delay exceeds 75000ns (on eCEM
and on bCEM when maxTransportFiberDelayLengthCategory is set to “fifteenKm”)
Preamble Format Maximum OTA Cell Radius

0 14.5 - [3×(Cabling Delay (ns) – 60000)/10000] km
Maximum OTA Cell Radius when the cabling delay exceeds 60000ns (on bCEM
when maxTransportFiberDelayLengthCategory is set to “tenKm”)
5.1.3.6.2 RANDOM ACCESS PREAMBLES SEQUENCE

GENERATION
The random access preambles are generated from Zadoff-Chu sequences with zero
correlation zone, generated from one or several root Zadoff-Chu sequences.
There are 838 root Zadoff-Chu sequences. The u th root Zadoff-Chu sequence is
defined by
πun ( n +1)
−j
x u (n ) = e N ZC
, 0 ≤ n ≤ N ZC − 1
where 0 ≤ u ≤ 837 is the physical index of the root sequence and N ZC = 839 is the
length of the Zadoff-Chu sequence.
Page 106/222
A root sequence also has a logical index 0 ≤ v ≤ 837 . The mapping of the logical
index v to the physical index u is given by Table 22.
Page 107/222
Logical Physical root sequence u

root
sequence
index v
0–23 129, 710, 140, 699, 120, 719, 210, 629, 168, 671, 84, 755, 105, 734, 93, 746,
70, 769, 60, 779
2, 837, 1, 838
24–29 56, 783, 112, 727, 148, 691
30–35 80, 759, 42, 797, 40, 799
36–41 35, 804, 73, 766, 146, 693
42–51 31, 808, 28, 811, 30, 809, 27, 812, 29, 810
52–63 24, 815, 48, 791, 68, 771, 74, 765, 178, 661, 136, 703
64–75 86, 753, 78, 761, 43, 796, 39, 800, 20, 819, 21, 818
76–89 95, 744, 202, 637, 190, 649, 181, 658, 137, 702, 125, 714, 151, 688
90–115 217, 622, 128, 711, 142, 697, 122, 717, 203, 636, 118, 721, 110, 729, 89,
750, 103, 736, 61, 778, 55, 784, 15, 824, 14, 825
116–135 12, 827, 23, 816, 34, 805, 37, 802, 46, 793, 207, 632, 179, 660, 145, 694,
130, 709, 223, 616
136–167 228, 611, 227, 612, 132, 707, 133, 706, 143, 696, 135, 704, 161, 678, 201,
638, 173, 666, 106, 733, 83, 756, 91, 748, 66, 773, 53, 786, 10, 829, 9, 830
168–203 7, 832, 8, 831, 16, 823, 47, 792, 64, 775, 57, 782, 104, 735, 101, 738, 108,
731, 208, 631, 184, 655, 197, 642, 191, 648, 121, 718, 141, 698, 149, 690,
216, 623, 218, 621
204–263 152, 687, 144, 695, 134, 705, 138, 701, 199, 640, 162, 677, 176, 663, 119,
720, 158, 681, 164, 675, 174, 665, 171, 668, 170, 669, 87, 752, 169, 670, 88,
751, 107, 732, 81, 758, 82, 757, 100, 739, 98, 741, 71, 768, 59, 780, 65, 774,
50, 789, 49, 790, 26, 813, 17, 822, 13, 826, 6, 833
264–327 5, 834, 33, 806, 51, 788, 75, 764, 99, 740, 96, 743, 97, 742, 166, 673, 172,
667, 175, 664, 187, 652, 163, 676, 185, 654, 200, 639, 114, 725, 189, 650,
115, 724, 194, 645, 195, 644, 192, 647, 182, 657, 157, 682, 156, 683, 211,
628, 154, 685, 123, 716, 139, 700, 212, 627, 153, 686, 213, 626, 215, 624,
150, 689
328–383 225, 614, 224, 615, 221, 618, 220, 619, 127, 712, 147, 692, 124, 715, 193,
646, 205, 634, 206, 633, 116, 723, 160, 679, 186, 653, 167, 672, 79, 760, 85,
754, 77, 762, 92, 747, 58, 781, 62, 777, 69, 770, 54, 785, 36, 803, 32, 807,
25, 814, 18, 821, 11, 828, 4, 835
384–455 3, 836, 19, 820, 22, 817, 41, 798, 38, 801, 44, 795, 52, 787, 45, 794, 63, 776,
67, 772, 72
767, 76, 763, 94, 745, 102, 737, 90, 749, 109, 730, 165, 674, 111, 728, 209,
630, 204, 635, 117, 722, 188, 651, 159, 680, 198, 641, 113, 726, 183, 656,
180, 659, 177, 662, 196, 643, 155, 684, 214, 625, 126, 713, 131, 708, 219,
620, 222, 617, 226, 613
456–513 230, 609, 232, 607, 262, 577, 252, 587, 418, 421, 416, 423, 413, 426, 411,
428, 376, 463, 395, 444, 283, 556, 285, 554, 379, 460, 390, 449, 363, 476,
384, 455, 388, 451, 386, 453, 361, 478, 387, 452, 360, 479, 310, 529, 354,
485, 328, 511, 315, 524, 337, 502, 349, 490, 335, 504, 324, 515
514–561 323, 516, 320, 519, 334, 505, 359, 480, 295, 544, 385, 454, 292, 547, 291,
548, 381, 458, 399, 440, 380, 459, 397, 442, 369, 470, 377, 462, 410, 429,
407, 432, 281, 558, 414, 425, 247, 592, 277, 562, 271, 568, 272, 567, 264,
575, 259, 580
562–629 237, 602, 239, 600, 244, 595, 243, 596, 275, 564, 278, 561, 250, 589, 246,
593, 417, 422, 248, 591, 394, 445, 393, 446, 370, 469, 365, 474, 300, 539,
299, 540, 364, 475, 362, 477, 298, 541, 312, 527, 313, 526, 314, 525, 353,
486, 352, 487, 343, 496, 327, 512, 350, 489, 326, 513, 319, 520, 332, 507,
333, 506, 348, 491, 347, 492, 322, 517
630–659 330, 509, 338, 501, 341, 498, 340, 499, 342, 497, 301, 538, 366, 473, 401,
438, 371, 468, 408, 431, 375, 464, 249, 590, 269, 570, 238, 601, 234, 605
660–707 257, 582, 273, 566, 255, 584, 254, 585, 245, 594, 251, 588, 412, 427, 372,
467, 282, 557, 403, 436, 396, 443, 392, 447, 391, 448, 382, 457, 389, 450,
294, 545, 297, 542, 311, 528, 344, 495, 345, 494, 318, 521, 331, 508, 325,
514, 321, 518
708–729 346, 493, 339, 500, 351, 488, 306, 533, 289, 550, 400, 439, 378, 461, 374,
465, 415, 424, 270, 569, 241, 598
730–751 231, 608, 260, 579, 268, 571, 276, 563, 409, 430, 398, 441, 290, 549, 304,
Page 108/222
535, 308, 531, 358, 481, 316, 523

752–765 293, 546, 288, 551, 284, 555, 368, 471, 253, 586, 256, 583, 263, 576
766–777 242, 597, 274, 565, 402, 437, 383, 456, 357, 482, 329, 510
778–789 317, 522, 307, 532, 286, 553, 287, 552, 266, 573, 261, 578
790–795 236, 603, 303, 536, 356, 483
796–803 355, 484, 405, 434, 404, 435, 406, 433
804–809 235, 604, 267, 572, 302, 537
810–815 309, 530, 265, 574, 233, 606
816–819 367, 472, 296, 543
820–837 336, 503, 305, 534, 373, 466, 280, 559, 279, 560, 419, 420, 240, 599, 258,
581, 229, 610
Table 22: Root sequence logical index-to-physical index mapping
There are 64 preambles available in each cell. The set of 64 preamble sequences in
a cell is found by including first, in the order of increasing cyclic shift, all the available
cyclic shifts of a root Zadoff-Chu sequence with the logical index v =
rootSequenceIndex. This index is (input in OAM through parameter rootSequenceIndex)
and broadcast as part of System Information.
From the u th root Zadoff-Chu sequence, random access preambles with zero
correlation zones of length N CS − 1 are defined by cyclic shifts according to
xu ,v (n) = xu ((n + Cv ) mod N ZC )
where the cyclic shift is given by

⎧vN CS v = 0,1,..., ⎣⎢ N ZC N CS ⎦⎥ − 1, N CS ≠ 0 for unrestricted sets
⎪⎪
Cv = ⎨0 N CS = 0 for unrestricted sets
⎪
⎪⎩dstart ⎢⎣v nshift ⎥⎦ + (v mod nshift ) N CS v = 0,1,..., n +n −1
RA RA RA RA RA
n
shift group shift for restricted sets
The restricted set is necessary for high speed cells. In this set, the minimum
difference between two cyclic shifts is N CS but the cyclic shifts are not necessarily
multiples of N CS . Parameter highSpeedFlag determines if the current cell is a high
speed cell (in which case the restricted set will be used) or not (in which case the
unrestricted set will be used).
A high speed cell is a cell involving high speed UEs (e.g. a cell covering a high way).
The cyclic shift index is derived internally from the high speed flag (highSpeedFlag)
and cell radius information provisioned by the Cell Radius derived from parameter
cellRadius (that is covered in [Vol. 5]) as per Table 23 and Table 24.
Page 109/222
It is possible to artificially increase the Cell Radius information that is used to derive
N CS using Table 23 and Table 24 (Cell Radius = cellRadius + 0.15× cellRtdAdjust).
This can be done by provisioning a non-zero value for parameter cellRtdAdjust.
Cell Radius (km) N CS index N CS

]0, 1.0] 1 13
- 2 15
]1.0, 1.5] 3 18
]1.5 , 2.0] 4 22
]2.0, 2.5] 5 26
]2.5, 3.5] 6 32
]3.5, 4.5] 7 38
]4.5, 5.5] 8 46
]5.5, 7.5] 9 59
]7.5, 10.0] 10 76
]10.0, 12.5] 11 93
]12.5, 16.0] 12 119
]16.0, 23.0] 13 167
]23.0, 30.0] 14 279
> 30 0 0*
Table 23: N CS determination based on Cell Radius, in low speed cells (unrestricted set)
*Ncs = 0 means that one root sequence corresponds one preamble sequence.
Cell Radius (km) N CS index N CS

]0, 1.0] 0 15
]1.0, 1.5] 1 18
]1.5, 2.0] 2 22
]2.0, 2.5] 3 26
]2.5, 3.5] 4 32
]3.5, 4.5] 5 38
]4.5, 5.5] 6 46
]5.5, 7.0] 7 55
]7.0, 8.5] 8 68
]8.5, 10.5] 9 82
]10.5, 13.5] 10 100
]13.5, 17.5] 11 128
]17.5, 21.5] 12 158
]21.5, 28.0] 13 202
]28.0, 30.0] 14 237
- 15 N/A
Table 24: N CS determination based on Cell Radius, in high speed cells (restricted set)
Page 110/222
CellL1ULConfFDD::cellRtdAdjust
Parameter cellRtdAdjust
Range & Unit Float
0..100 step 0.5 us

Value 0 (default)
Feature L100622
LR13.1 – LA6.0 Delta: parameter cellRtdAdjust
This is a new parameter in LR13.1 which is a replacement for LA6.0

LteCell::spare4 bits 25-31.
Note that if TotalRTT exceeds TotalRTT0 (i.e. Tcabling exceeds T0,cabling) then the round-
trip extra delay (TotalRTT - TotalRTT0)=2(Tcabling -T0, cabling) that the modem cannot
compensate for adds to the Over-The-Air delay. Therefore, the equivalent distance of
this delay (OTA delay + non-compensated cabling delay) must be accounted for in
the N CS determination (and the RACH2 Timing Advance computation).
In LR13.1, the cell radius parameter being used to provision this distance, this is
done by provisioning, instead of the Over-The-Air cell radius (OTA cell radius), the
PRACH apparent Cell Radius = [OTA Cell Radius + 3×Extra Delay (ns)/10000] (km)
in the cellRadius parameter, where Extra Delay (ns) is the one-way non-
compensated cabling delay and is equal to “Cabling Delay (ns) – 75000 ns”.
It is worth emphasizing that if the centralized automatic PCI allocation algorithm is

used to generate the PCIs (of the cells that are managed by the SAM server in
question), it is highly recommended to proceed as follows:
1. Provision the OTA Cell Radius in the cellRadius parameter.
2. Run the centralized Automatic PCI allocation algorithm (offline).
3. Overwrite the OTA Cell Radius value with the PRACH apparent Cell Radius
= [OTA Cell Radius + 3×Extra Delay (ns)/10000] (km) value for the cells with
the cabling delay exceeding 75000 ns.
4. Proceed with the workorder generation/upload and the setup of the cells
managed by the SAM server in question.
This is to avoid running the centralized automatic PCI allocation algorithm with
biased Cell Radius inputs.
Page 111/222
If the centralized automatic PCI allocation algorithm is not used (i.e. if the PCIs are
provisioned manually) then one can proceed as follows:
1. Provision the OTA Cell Radius for the cells with cabling delay ≤ 75000ns and the
PRACH apparent Cell Radius for the cells with cabling length > 75000ns, in the
cellRadius parameter.
2. Proceed with the workorder generation/upload and the setup of the cells
managed by the SAM server in question.
Please refer to [Vol. 5] for more details on the (centralized) automatic PCI allocation
algorithm and the cellRadius parameter, and to [R02] for more details on the
Hardware configurations.
Page 112/222
In case 64 preambles cannot be generated from root Zadoff-Chu sequence with

logical index v alone, additional preamble sequences are generated from the root
sequences with the consecutive logical indexes (i.e. for v = rootSequenceIndex +1, v =
rootSequenceIndex +2, …) until all the 64 sequences are found.
Parameter rootSequenceIndex configures rootSequenceIndex.
In LR13, rootSequenceIndex (or RSI) derivation is based on parameter
autoRSIConfigEnabled. When set to false it is derived from rootSequenceIndex
parameter. When set to true the RSI is derived automatically as follows:
Cell Type : Macro:

RSI = C1 + mod(floor(PCI/3)×N, C2), in LR13.1
RSI = C1 + mod(floor(PCI)×N, C2), in LR13.3
Cell Type : Metro or Pico:
RSI = C1 + mod(floor(PCI)×N, C2)
where:
ceiling [64/floor(839/Ncs)] Ncs ≠ 0, low-speed
ceiling [64/floor(Ncs/3)] Ncs ≠ 0, high-speed

• N=
64, Ncs = 0, low-speed
22, Ncs = 0, high-speed
• C1=0, C2=456 for Macro cell (i.e., when LteCell.cellType (covered in [Vol.
5]) is set to “Macro”).
• C1=520, C2=838-520=318 for Metro or Pico (i.e., when LteCell.cellType is

set to “metro” or “pico”).
[C1, C1+ C2] is the pool of RSI values used by the cell type in question.
Enough margin is left so that there is no root overlapping between macro and metro
pools.
Note that metro/pico cells have (very) small cell radius, and therefore, only 1 or 2
roots are needed.
Also note that if auto RSI is used (i.e. bit 0 of bit 24 of CellRachConf::
autoRSIConfigEnabled is set to ‘TRUE’), parameter rootSequenceIndex will not
be synched up with the actual RSI value. The RSI value can be retrieved offline
using the above algorithm. Note that when N CS changes (i.e. when cellRadius is
changed), the RSI is updated and does not get synched up with parameter
rootSequenceIndex either.
Page 113/222
CellRachConf::highSpeedFlag
Parameter highSpeedFlag
Object ENBEquipment/Enb/LteCell/CellRachConf
True/False
Value False (See Restriction Below)

Feature
Restriction: Cell RACH High Speed Flag
In LR13.1, parameter highSpeedFlag can only be set to “False”.
CellRachConf::rootSequenceIndex
Parameter rootSequenceIndex
[0..837]
Value O.D. (ALU Default: 1)
Feature
autoRSIConfigEnabled - "This parameter is used to control whether customer

configures RSI or eNB calculates RSI. When set to true, RSI (Root Sequence Index)
is auto-configured by eNB/CallP. The MIM parameter
CellRachConf:.rootSequenceIndex is ignored by eNB.
Page 114/222
When set to false, RSI is configured by customer using

CellRachConf::rootSequenceIndex
CellRachConf:: autoRSIConfigEnabled
Parameter autoRSIConfigEnabled
True/False
Value False (See Rule Below)

Feature
Rule: Migration rule Parameter autoRSIConfigEnabled
IF
LteCell::spare4 bit 24 = 1
THEN
set to true
ELSE
set to false
PRACH False Alarm rate control and preamble detection threshold

After Cyclic Prefix removal, the PRACH detector computes the Correlation factor
between the received signal and the different preamble sequences used by the cell.
The correlation factor is divided by the noise level, which provides a unitless (or
normalized) metric that is compared to the Preamble Detector Threshold. If the
threshold is exceeded, the corresponding preamble is deemed detected, which
prompts the eNB to send RACH message 2 as an answer to the detected preamble.
LR13.1 – LA6.0 Delta: Preamble detection and False Alarm probability control
mechansim
In LA6.0,the Preamble detection and False Alarm probability control mechanism

was defined by bits 29 and 30 of LteCell::spare5.
In LR13.1, only Dynamic PRACH Detection Adaptation is supported (previously
Page 115/222
defined as LteCell::spare5 bits 29 and 30 set to “11”.
In LR13.1, Dynamic PRACH Detection Adaptation is used, whereby the RACH

detection threshold is adjusted dynamically so that the actual false alarm probability
is controlled near the target False Alarm probability configured by
pRACHDetectFalseAlarmProb. In this case, bits 16-31 of LteCell::spare7 were
replaced in LR13.1 like follows.
o rachPfaTolerance are used to configure the Sinc (Sinc =

rachPfaTolerance), which controls the trigger of threshold auto up-
adjustment. Specifically, when the measured PFA > (Sinc ×
pRACHDetectFalseAlarmProb), then the up-adjustment is
triggered. The range of Sinc is [2, 64], with a step size 2.
o rachThresholdAdjScaleFactor configure ScaleFactor (ScaleFactor =

rachThresholdAdjScaleFactor), i.e. the scaling factor used to
control the speed of threshold auto up-adjustment. The range of
ScaleFactor is [1/16, 1] with a step size of 1/16.
o rachThresholdMaxControl configure R (R =
rachThresholdMaxControl), which is used to determine the max
allowed threshold (Tmax). Specifically, Tmax = min(0xFFFF,
Tlow*rachThresholdMaxControl) where Tlow is calculated internally.
The range of R is [1, 16] with a step size of 1.
o Bits 29-31 are not used.
Parameter pRACHPreambleDetectorThreshold is removed. The RACH Detector

Threshold is derived internally based on N CS , the PRACH format and the target
probability of False Alarm. The latter is configured by parameter
pRACHDetectFalseAlarmProb (with 3 values to choose from: 10 , 10 and 10-2). -4 -3
Page 116/222
CellRachConf::pRACHDetectFalseAlarmProb
Parameter pRACHDetectFalseAlarmProb
{0dot01, 0dot1, 1} %
Class/Source B--Cell/ system_restricted
Value 0dot1
Feature L98565
With the following mapping between enumerate values and actual values
pRACHDetectFalseAlarmProb False Alarm

Probability
0dot01 10-4
0dot1 10-3
1 10-2
rachPfaTolerance - This parameter specifies how much tolerance can be allowed

beyond the configured false alarm probability (pRACHDetectFalseAlarmProb).
CellRachConf:: rachPfaTolerance
Parameter rachPfaTolerance
[2..64] Step = 2
Value 10
Feature L98565
Note: this parameter replaces the spare configuration Sinc (in the lteCell->spare7-
>pRACHfalseAlarmControlDetail).
Restriction: rachPfaTolerance in LR13.x
Only values of 2 to 30 should be entered for this parameter value.
Page 117/222
Rule: Migration rule Parameter rachPfaTolerance
IF
lteCell.spare7 bits [16..20] < 2 OR the value is odd
THEN
set to default value =10
ELSE
set to lteCell.spare7 bits [16..20]
rachThresholdAdjScaleFactor - This parameter specifies the scaling factor to

control the speed of threshold auto up-adjustment. Note that the unit corresponds to
the granularity of 1/16 within the [1/16, 1] range.
CellRachConf:: rachThresholdAdjScaleFactor
Parameter rachThresholdAdjScaleFactor
[1..16] Step = 1

Value 8
Feature L98565
Note: this parameter replaces the spare configuration ScaleFactor (in the lteCell-
>spare7->pRACHfalseAlarmControlDetail).
Rule: Migration rule Parameter rachThresholdAdjScaleFactor
IF
lteCell.spare7 bits [21..24] < 1 OR the value is out of range
THEN
set to default value (8)
ELSE
Page 118/222
rachThresholdMaxControl - This parameter specifies the max allowed threshold,

which is min (0xFFFF, Tlow*rachThresholdMaxControl), where Tlow is calculated
internally..
CellRachConf:: rachThresholdMaxControl
Parameter rachThresholdMaxControl
[1..16] Step = 1
Value 8
Feature L98565
Note: this parameter replaces the spare configuration R (in the lteCell->spare7-
>pRACHfalseAlarmControlDetail).
Rule: Migration rule Parameter rachThresholdMaxControl
IF
lteCell.spare7 bits [25..28] < 1 OR the value is out of range
THEN
set to default value (8)
ELSE
5.1.3.6.3 PRACH TIME/FREQUENCY CONFIGURATION

The RACH periodicity is defined through parameter rachPeriodicity.
The starting subframe number for PRACH RACHMsg1SubFrameNumber is derived
from parameter sectorNumber (described in [Vol. 2]).
rachPeriodicity pRACHPreamble sectorNumber prach-ConfigurationIndex RACHMsg1SubFrameNumber

Format
10ms format0 1 3 1
10ms format0 2 4 4
10ms format0 3 5 7
Page 119/222
10ms format2 1 35 1
10ms format2 2 36 4
10ms format2 3 37 7
10ms format3 1 51 1
10ms format3 2 52 4
10ms format3 3 53 7
20ms format0 1 0 1
20ms format0 2 1 4
20ms format0 3 2 7
20ms format2 1 33 1
20ms format2 2 34 4
20ms format2 3 35 7
Table 25: PRACH time configuration
In LR13.1, sectorNumber is either configured by parameter sectorNumber (when

bit31 of LteCell::spare5 is set to “0”) or derived by CallP based upon antenna
configuration (when bit31 of LteCell::spare5 is set to “1”), as explained in [Vol. 2].
In the frequency domain, PRACH occupies 6 PRBs starting from the PRB configured
by parameter prachFrequencyOffset.
In 1.4MHz-BW systems, parameter prachFrequencyOffset must be set to “0” since
the entire bandwidth consists of 6 PRBs and PRACH occupies 6 PRBs.
CellRachConfFDD::rachPeriodicity
Parameter rachPeriodicity
Object ENBEquipment/Enb/LteCell/CellRachConf/CellRachConfFDD
{10ms, 20ms}
Value 10ms
Feature L92801(.1)
Page 120/222
Restriction: Rach Periodicity
The LR13.1 supported RACH periodicities are as follows:
ulBandwidth supported RACH periodicities
n6-1_4MHz 20ms
n15-3MHz 10ms
n25-5MHz 10ms
n50-10MHz 10ms
n75-15MHz 10ms
n100-20MHz 10ms
Therefore, the setting of rachPeriodicity should be as follows:
ulBandwidth rachPeriodicity
n6-1_4MHz 20ms
n15-3MHz 10ms
n25-5MHz 10ms
n50-10MHz 10ms
n75-15MHz 10ms
n100-20MHz 10ms
CellRachConf::prachFrequencyOffset
Parameter prachFrequencyOffset
[0..94] PRBs

Feature L76501
Page 121/222
Engineering Recommendation: Parameter prachFrequencyOffset setting

If the system is operating in the 700 MHz upper C band (i.e. if
ul700MHzUpperCBlockEnabled is set to “True”) parameter
prachFrequencyOffset must be set to N UL
RB - 6 = 50 - 6 = 44 (PRACH can only be
at the upper end of Zone C).
If the system is not operating in the 700 MHz upper C band (i.e. if
ul700MHzUpperCBlockEnabled is set to “False”), parameter
prachFrequencyOffset must be set so that PRACH resources do not overlap with
PUCCH resources, i.e. prachFrequencyOffset must be set in the range
[pucchPRBsize/2… N UL
RB - pucchPRBsize/2- 6] where the 6 accounts for the number of
PRBs of PRACH.
In LR13.1, the WPS enforced setting is prachFrequencyOffset = pucchPRBsize/2

except for 1.4MHz-BW where prachFrequencyOffset has to be set to “0”:
ulbandwidth ul700MHzUpperCBlockEnabled prachFrequencyOffset
n6-1_4MHz False 0
n15-3MHz False 1
n25-5MHz False 2
n50-10MHz False 2
n75-15MHz False 3
n100-20MHz False 3
In LR13.3, for the support of configurations with more than three cells and up to nine
cells same carrier and bandwidth (FRS L115401 Nine Cells (One Frequency) on
three modems), the pRach-Configuration Index legacy algorithm, based on
geographical area or sector number, is not suitable. Another algorithm, modem
based, is now available. The parameter pRachIndexAlgorithm designates the
algorithm to be used by the eNodeB at cell setup. Note that FRS L115401 is
discussed in [Vol. 2].
Page 122/222
Enb::pRachIndexAlgorithm
Parameter pRachIndexAlgorithm
{legacy_based, modem_based}
Value Default legacy_based
Feature L115401
Rule: pRachIndexAlgorithm
For the configurations defined in FRS L115401 (configurations with more than three
cells and up to nine cells same carrier and bandwidth), the algorithm to be used by
the eNodeB to determine pRachConfigIndex must be modem based.
This can be written as follows:
IF isIncrementalSectorEnabled = TRUE
THEN
pRachIndexAlgorithm must be set to modem_based.
ELSE
pRachIndexAlgorithm may be absent,
or if present, must be set to legacy_based.
5.1.4 MAC PROCEDURES
5.1.4.1 HARQ OPERATION
Fast hybrid ARQ with soft combining is used in LTE to allow the terminal to rapidly
request retransmissions of erroneously received transport blocks and to provide a
tool for implicit rate adaptation. Retransmissions can be rapidly requested after each
packet transmission, thereby minimizing the impact on end-user performance from
erroneously received packets. Incremental redundancy is used as the soft combining
strategy and the receiver buffers the soft bits to be able to do soft combining
between transmission attempts. The underlying protocol is that of a multiple parallel
stop-and-wait hybrid ARQ processes (see Figure 45 ).
The Hybrid ARQ protocol is part of the MAC layer, while the soft-combining operation
is handled by the physical layer.
Page 123/222
Upon reception of a transport block, the receiver makes an attempt to decode the
transport block and informs the transmitter about the outcome of the decoding
operation through a single ACK/NACK bit indicating whether the decoding was
successful or if a retransmission of the transport block is required.
Figure 45: HARQ processing
To minimize the overhead, a single ACK/NACK bit is used. Clearly, the receiver must
know to which Hybrid ARQ process a received ACK/NACK bit is associated. This is
solved using the timing of the ACK/NACK used to associate the ACK/NACK with a
certain Hybrid ARQ process.
However, although the MAC-based Hybrid ARQ mechanism is capable of correcting

most transmission errors, the Hybrid ARQ may occasionally fail to deliver error-free
data blocks to the RLC, causing a gap in the sequence of error-free data blocks
delivered to the RLC, and since TCP views all packet errors as being due to
congestion it triggers the TCP congestion–avoidance mechanism, with a
corresponding decrease in data rate.
The HARQ residual rate is on the order of 1% due to erroneous feedback signaling,
(for example, a NACK incorrectly interpreted as an ACK by the transmitter) or
persisting decoding failure combined with limitations on the number of transmissions.
The Maximum number of HARQ transmissions is configured by RRC. When the
maximum number of transmissions is reached, the HARQ process flushes the HARQ
buffer.
On the other hand, since HARQ may fail to deliver error-free data blocks, the RLC is
also enabled to request retransmissions via the (pure) ARQ protocol, which serves
the important purpose of ensuring (almost) error-free data delivery to TCP and
maintaining thus good performance at high data rates.
When the maximum number of HARQ transmissions is reached and the last HARQ
feedback is a NACK, the HARQ process notifies the relevant ARQ entities in the
Page 124/222
upper layer that the transmission of the corresponding RLC PDU(s) failed by
immediately transmitting an RLC status report (RLC feedback) instead of waiting for
transmission of a periodic status report, which results in a faster RLC retransmission
of the missing PDU(s). Note that this is possible thanks to the fact that MAC (hence
HARQ) and RLC (hence ARQ) are located in the same node (i.e. the eNodeB) and
tight interaction between the two is possible. Thus, to some degree, the combination
of (MAC) HARQ and (RLC) ARQ can be seen as one retransmission mechanism
with two feedback mechanisms.
The ARQ mechanism of RLC is described in section 5.2.4.
5.1.4.1.1 DOWNLINK HARQ

In the downlink, the ACK/NACK is received on the PUCCH assigned to the UE for a
transmission on the PDSCH.
There is one HARQ entity at the UE which maintains a number of parallel HARQ
processes. Each HARQ process is associated with a HARQ process identifier. The
maximum number of DL HARQ processes is 8 for FDD and 4, 6, 7, 9, 10, 12 or 15
for TDD depending on the UL/DL configuration.
The HARQ entity directs HARQ information and associated TBs received on the DL-
SCH to the corresponding HARQ processes.
When the physical layer is configured for spatial multiplexing, one or two Transport
Blocks are expected per subframe. Otherwise, one Transport Block is expected per
subframe.
5.1.4.1.2 UPLINK HARQ

In the uplink, the ACK/NACK is received on the PHICH for a transmission on the
PUSCH.
There is one HARQ entity at the UE, which maintains a number of parallel HARQ
processes. The maximum number of UL HARQ processes is 8 for FDD and 1, 2, 3,
4, 6 or 7 for TDD depending on the UL/DL configuration.
Each HARQ process is associated with a HARQ buffer. Each HARQ process
maintains a state variable which indicates the number of transmissions that have
taken place for the MAC PDU currently in the buffer. This variable is initialized to 0
when a new transmission is requested and incremented with each retransmission.
The sequence of redundancy versions is 0, 2, 3, 1. The corresponding variable is set
to 0 when a new transmission is initialized and updated modulo 4 with each
retransmission.
For a new transmission, the HARQ process delivers the MAC PDU, the uplink grant
and the HARQ information to the identified HARQ process, and then instructs the
identified HARQ process to trigger a new transmission. There is one HARQ entity in
the UE as well as the eNB per UE context.
Page 125/222
For a retransmission, the HARQ process delivers the uplink grant and the HARQ
information (redundancy version) to the identified HARQ process, and then instructs
the identified HARQ process to generate a retransmission.
Note that HARQ is a key functionality of the MAC layer. It is used by the scheduler,
along with the other MAC layer functionalities, as described in detail in [Vol. 4]..
5.1.4.2 RANDOM ACCESS PROCEDURE
The random access procedure is performed for the following five events:
• Initial access from RRC_IDLE (see section 6.2).
• RRC Connection Re-establishment procedure (after radio link failure).
• After handover, in the target cell.
• DL data arrival during RRC_CONNECTED (see section 6.2) requiring
random access procedure, e.g. when UL synchronization status is “non-
synchronized”..
• UL data arrival during RRC_CONNECTED requiring random access

procedure, e.g. when UL synchronization status is "non-synchronized" or
when there are no PUCCH resources for Scheduling Request available.
Note that for the last 3 events the UE already has a Cell-Radio Network Temporary
Identifier (C-RNTI) while in the first 2 events the UE does not already have a C-RNTI.
In the case of the handover event, the C-RNTI of the UE is allocated to it in the
Handover Command.
Furthermore, the random access procedure takes two distinct forms:

• Contention based, applicable to all five events.
• Non-contention based, applicable only to handover and DL data arrival. Note
that both events, the UE already has a C-RNTI.
Parameter contentionFreeRACHenabled enables/disables the contention free

random access procedure.
Page 126/222
CellRachConf::contentionFreeRACHenabled
Parameter contentionFreeRACHenabled
True/False
Value True
Feature
5.1.4.2.1 CONTENTION BASED RANDOM ACCESS PROCEDURE

The contention-based random access procedure is illustrated in Figure 46:
UE eNB
1 Random Access Preamble
Random Access Response 2
3 Scheduled Transmission
Contention Resolution 4
Figure 46 : Contention based Random Access Procedure
The four steps of the contention based random access procedure are:
• Message 1: This message contains the random access preamble.
It is randomly selected from a set of Random Access Preambles the number

of which is configured by parameter numberOfRAPreambles.
Parameter preambleTransMax configures the maximum number of attempts

for this message.
In LR13.3, in order to sustain the increased connected users capacity (FRS

166802), the cell with bandwidth 5MHz or above is able to detect up to 2
Page 127/222
preambles transmitted. The parameter nbrOfRARsPerRACHCycle when set

to 2, enables the 2 RACH preambles detection per RACH opportunity. The
parameter rachDetectionThresholdScalingForMultiplePreambles
indicates the scaling factor multiplied on top of the (n-1) RACH detection
threshold to detect the nth preamble in the same RACH cycle. In LR13.3, n is
up to 2.
Once message 1 is transmitted, the UE starts monitoring the PDCCH for

Random Access Response (message 2) identified by the RA-RNTI.
• Message 2 (Random Access Response): This message is generated by

MAC on DL-SCH and intended for a variable number of UEs.
It conveys a Random Access preamble identifier, assignment of Temporary
C-RNTI, as well as timing advance information and initial grant for the
transmission of message 3.
It is addressed to RA-RNTI on PDCCH and does not use HARQ.
RACH message 2 is sent to the UE within a time window (named the RA
Response window and configured by parameter raResponseWindowSize)
after the transmission of RACH message1. This time window starts at
subfame (N + 3) where N is the subframe where the end of the preamble
transmission occured.
In LR13.3 FRS166802 introduces the ability to send RACH msg2

transmission containing up to 2 RARs, in order to sustain increased
connected users capacity. This is activated when the parameter
nbrOfRARsPerRACHCycle is set to 2).
If no Random Access Response is received within the RA Response
window, or if none of all received Random Access Responses contains a
Random Access Preamble identifier corresponding to the transmitted
Random Access Preamble, the Random Access Response reception is
considered not successful.
• Message 3 (First scheduled UL transmission on UL-SCH):

For users that already have a C-RNTI, this message conveys, among other
information elements, the C-RNTI of the UE and the RRC Handover Confirm
(in case the RACH procedure is performed after handover) which is
transmitted via DCCH.
For users that do not already have a C-RNTI, this message conveys either
the RRC Connection Request (for initial access from RRC_IDLE) or the RRC
Connection Re-establishment Request (after radio link failure). Both these
messages are transmitted via the CCCH logical channel.
This message uses HARQ. Parameter maxHARQmsg3Tx configures the

maximum number of attempts for this message.
After the first transmission of message 3, the UE starts the mac-contention
resolution timer. This timer is restarted after each HARQ retransmission of
message 3.
Page 128/222
After the (re)transmission of message 3, the UE monitors the PDCCH for a

PDCCH transmission (message 4), identified by either C-RNTI (for UEs that
already have a C-RNTI) or Temporary C-RNTI (for UEs that do not already
have a C-RNTI).
• Message 4 (Contention Resolution on DL-SCH): This message contains a

UE Contention Resolution identity.
It is addressed on PDCCH either to the C-RNTI (for UEs that already have
one) or to the Temporary C-RNTI (for UEs that do not already have a C-
RNTI).
This message uses HARQ. Parameter
maximumNumberOfDLTransmisionsRACHMessage4 configures the
maximum number of attempts for this message.
If message 4 is successfully received and the UE contention resolution
identity contained in the message matches the content of message 3 (RRC
connection request or RRC Connection Re-establishment Request) for UEs
that do not already have a C-RNTI), the Contention Resolution is considered
successful and:
o The mac-contention resolution timer is stopped.
o The UEs that already have a C-RNTI resume using it.
o The UEs that do not already have a C-RNTI promote their

Temporary C-RNTI to a C-RNTI.
If the mac-contention resolution timer expires, the contention resolution is
considered not successful.
Parameter macContentionResolutionTimer configures the mac-contention
resolution timer.
CellRachConf::numberOfRAPreambles
Parameter numberOfRAPreambles
[56..64] step = 4
Value 56
Feature
Page 129/222
CellRachConfFDD::maxHARQmsg3Tx
Parameter maxHARQmsg3Tx
[1..5]
Value 3
Feature
CellRachConf::maximumNumberOfDLTransmisionsRACHMessage4
Parameter maximumNumberOfDLTransmisionsRACHMessage4
[1..8]
Class/Source C—Immediate-propagation / system_restricted
Value 2
Feature
CellRachConf::macContentionResolutionTimer
Parameter macContentionResolutionTimer
{ sf8, sf16, sf24, sf32, sf40, sf48 sf56 sf64 }
Value sf64
Feature
Page 130/222
CellRachConf::raResponseWindowSize
Parameter raResponseWindowSize
{ sf2, sf3, sf4, sf5, sf6, sf7, sf8, sf10 }

Feature L115113.1, L115436
The mapping of parameter values to subframe numbers is as follows
raResponseWindowSize RACH Msg1-Msg2 window size

value:
sf2 2 subframes
sf3 3 subframes
sf4 4 subframes
sf5 5 subframes
sf6 6 subframes
sf7 7 subframes
sf8 8 subframes
sf10 10 subframes
Page 131/222
Engineering Recommendation: Parameter raResponseWindowSize
This parameter should be set as follows:
dlBandwidth isMbmsBro pRACHPrea raResponseWindowSize

adcastMod mbleFormat
eAllowed
n6-1_4MHz False format0, eCEM: sf10
format2 bCEM: N.A. (Config. not supported)
N6-1_4MHz False format3 bCEM: N.A. (LR13.1)
bCEM: sf10 (LR13.3)
n6-1_4MHz True format0, N.A. (Config. not supported)
format2,
format3
n15-3MHz, n50- False format0 sf5

10MHz , n25-
5MHz, n75-
15MHz, n100-
20MHz
n15-3MHz, n50- False format2 sf4 (eCEM)

10MHz , n25-
sf6 (bCEM)
5MHz, n75-
15MHz, n100-
20MHz
N15-3MHz False format3 bCEM: N.A. (LR13.1)
bCEM: sf6 (LR13.3)
n25-5MHz, n50- False format3 eCEM: N.A. (Config. not supported)

10MHz , n75-
bCEM: sf6
15MHz, n100-
20MHz
n15-3MHz, n25- True format0, N.A. (Config. not supported)

5MHz, n75-
format2,
15MHz, n100-
20MHz format3
n50-10MHz True format0 eCEM: N.A. (Config. not supported)
bCEM: sf8
n50-10MHz True format2, eCEM: N.A. (Config. not supported)
format3 bCEM: sf10
Page 132/222
Restriction: Parameter raResponseWindowSize
In LR13.1 only the following values are supported:
isMbmsBroadcastM pRACHPreambleFo raResponseWindo

odeAllowed rmat wSize
False format0 ≥ sf5
False format2, format3 ≥ sf6
True format0 ≥ sf8
True format2, format3 sf10
Note that a value of “sf9” is not valid according to [R15].
CellRachConf::nbrOfRARsPerRACHCycle
Parameter nbrOfRARsPerRACHCycle
[1..2]
Class/Source C--Cell / system_restricted
Value Default 1
Feature 166802
CellRachConf:: rachDetectionThresholdScalingForMultiplePreambles
Parameter rachDetectionThresholdScalingForMultiplePreambles
Range & Unit Decimal
[1.00..2.00] step 0.01

Value Default 1.25
Feature 166802
Page 133/222
Random Access Failure

If the Random Access Response or the Contention Resolution fails, the UE makes
an immediate reattempt.
The backoff capability described in the remainder of this section is optional and is not
currently implemented. With the optional (future) capability, the UE backs off for a
certain period of time selected randomly in the range [0, rABackoff], then restarts
the procedure.
CellRachConf::rABackoff
Parameter rABackoff
[0..12]
Class/Source C-- Immediate-propagation / system_restricted
Value N.S. This capability is not currently implemented

Feature
The mapping of the rABackoff value from Table 7.2-1 in Reference [R09] is shown in
Table 26.
Index Backoff Parameter value (ms)
0 0
1 10
2 20
3 30
4 40
5 60
6 80
7 120
8 160
9 240
10 320
11 480
12 960
Table 26 : Mapping of rABackoff Parameter Value (Index) to Backoff Time
Based on the Backoff Parameter value from Table 26, the UE selects a random
backoff time according to a uniform distribution between 0 and the Backoff
Parameter Value. When that time expires, and delays the subsequent RACH attempt
by the backoff time.
Page 134/222
5.1.4.2.2 NON-CONTENTION BASED RANDOM ACCESS

PROCEDURE
The non-contention-based random access procedure is illustrated in Figure 47:
UE eNB
0 RA Preamble assignment
Random Access Preamble 1
2 Random Access Response
Figure 47 : Non-Contention based Random Access Procedure
1) Message 0 (Random Access Preamble assignment): The eNB assigns a non-

contention Random Access Preamble (not within the set broadcast on BCH). It is
signaled either via a Handover Command generated by the target eNB and sent via
source eNB (in case of handover) or via PDCCH in (case of data arrival).
2) Message 1: The UE sends the non-contention Random Access Preamble
assigned in Message 0, via RACH.
3) Message 2: This message is generated by MAC on DL-SCH. It is intended for one
or multiple UEs in one DL-SCH message.
It conveys an RA-preamble identifier, either timing advance and initial UL grant (in
case the procedure is used in a handover scenario) or just timing advance (in case it
is used for DL data arrival).
The number of Random Access Preambles available for the non-contention based
Random Access procedure is (64 - numberOfRAPreambles) since the total number
of Random Access Preambles is 64.
5.1.4.2.3 RANDOM ACCESS FAILURE

After a certain number of attempts (configured by parameter preambleTransMax)
the MAC layer declares the Random Access procedure as failed, and notifies higher
layers of the failure.
Page 135/222
CellRachConf::preambleTransMax
Parameter preambleTransMax
{ n3, n4, n5, n6, n7, n8, n10, n20, n50, n100, n200 }
Value n3
Feature
5.1.4.2.4 RACH ACCESS LOAD CONTROL
In order to improve the RACH performance when there’re short-term bursts of

access overload, a backoff indicator is sent over a certain RA-RNTI (along with RAR)
to notify accessing UEs that a random backoff should be applied for subsequent
RACH activities.
This approach intends to smooth out access traffic in case of short-term access
loading surge. It does not aim to relieve a long-term persistent access overload –
which needs to be addressed by access class barring control.
When the eNB observes the access loading increase approaching the RACH
capacity, it inserts the backoff parameter into the RACH msg2 transmitted.
The cell observes the total RACH load by counting the decoded number of msg3
within a monitoring window.
If the loading, defined as RACH load / RACH capacity, goes beyond a certain
threshold configured with the parameter raLoadingThresholdForBackoff, a backoff
subheader is added into any msg2 sent by the eNB. The backoff value depends on
the observed RACH load in the previous monitoring window. The possible values are
standardized in [R09].
Page 136/222
CellRachConf::raLoadingThresholdForBackoff
Parameter raLoadingThresholdForBackoff
[0..100] %
Value Default 50
Feature 166802
5.1.4.3 TIMING ADVANCE PROCEDURE
The timing advance is sent by the eNB to the UEs so that each UE advances/delays
its UL transmission(s) in order to compensate for the propagation delay and thus
time-align the transmissions from different UEs.
Uplink timing synchronization is very important. No uplink transmission can be
performed without it, except for the transmission of the RACH preamble. That is why
the eNB sends a timing advance to the UE in RACH message 2, i.e. right after the
RACH preamble is detected. Afterwards, the eNodeB continues to send updates of
the timing advance regularly. The values sent then are differential (represent the
difference between the new value and the latest one sent).
On the eNB side, at UE creation, a timer timingAlignmentCommandTimer is started.

When this timer expires, a Timing Advance (TA) command is sent and the timer is
restarted. This also happens when L1 UL indicates to DL MAC that the timing
advance has changed and requests a TA command be sent to the UE.
If a periodic TA command PDU is not successfully transmitted after max number of

HARQ transmissions (which is hardcoded to 8), another TA command PDU will be
rescheduled for transmission TTI (k+2). This goes on until a HARQ ACK is received,
or until 4 consecutive TA command PDUs have been unsuccessfully transmitted
whichever comes first in which case the TA command transmission is considered
failed.
Note that L1 TA command PDUs are only transmitted once with a max number of
HARQ attempts hardcoded to 8.
Also note that only one TA command is managed at a time for a given user. Any
incoming TA command will pre-empt the on-going TA transmission (the on-going TA
command is dropped and the incoming TA-command takes over the HARQ process).
Page 137/222
On the UE side, a configurable Time Alignment Timer is maintained. The Time

Alignment Timer is valid only in the cell for which it was configured and started.
Upon receipt of a Timing Advance Command, the UE applies the Timing Advance
Command and (re)starts the Time Alignment Timer.
If the Alignment Timer expires, the UE
flushes all HARQ buffers;
notifies RRC to release PUCCH/SRS;

clears any configured downlink assignments and uplink grants.
uses the Random Access procedure to obtain Uplink Time Alignment
again.
Parameter timeAlignmentTimerCommon configures the time alignment timer value

broadcast on SIB2 and used by the UE, in terms of subframes.
CellL2ULConf::timeAlignmentTimerCommon
Parameter timeAlignmentTimerCommon
{ sf500, sf750, sf1280, sf1920, sf2560, sf5120, sf10240, infinity }
Class/Source C—New-set-ups / system_restricted
Value sf2560
Feature L76501
Parameter timeAlignmentTimerDedicated configures the time alignment timer

value sent over dedicated RRC signaling and used by the UE, in terms of subframes.
Page 138/222
CellL2ULConf::timeAlignmentTimerDedicated
Parameter timeAlignmentTimerDedicated
{ sf500, sf750, sf1280, sf1920, sf2560, sf5120, sf10240, infinity }

Value sf2560
Feature L76501
Note that if the Timing Advance Command was received inside a Random Access
Response Message and the contention resolution is not successful, the Time
Alignment Timer is stopped.
timingAlignmentCommandTimer is no longer configurable starting from LA5.0. Instead,

it is calculated based on the UE timeAlignmentTimer as follows.
timingAlignmentCommandTimer = round down (timeAlignmentTimer/2.5), in the unit of

msec.
Note that if the UE TA timer configuration is “infinity”, then the periodic TA command
is no longer transmitted.
The DL scheduler considers that the UE is out of sync with the eNB (DL
OUT_SYNC) in case of TA Failure or in case it is notified by the UL scheduler of an
UL OUT_SYNC RLF.
UL_OUT_SYNC RLF (ulSyncTimer timer expiry) is described in Vol. 4.
TA failure occurs if timer TAFailureTimer (which is restarted upon receipt of a TA

PDU HARQ ACK or UE RACH-back notification from the UL scheduler) expires.
Note that if the UE is in DL_OUT_SYNC and a RACH message 3 receipt notification

is received from the UL scheduler, then the DL scheduler transitions the UE back to
DL_IN_SYNC state.
When the UE is in DL_OUT_SYNC, the DL scheduler stops scheduling the user,

including all DRBs, stand-alone TA and DRX/TA commands. However, SRB1 and
SRB2 are still considered for scheduling to allow RRC signaling messages (such as
Page 139/222
RRC Connection Release or RRC Connection Re-establishment messages) to be

transmitted.
CellRadioConf::tAFailureTimer
Parameter tAFailureTimer
Range & Unit Float
[0.0..12.0] step = 0.1s

3.0 The function associated with this parameter is considered
to be proprietary, and is thus not described here. The value of
Value
the parameter should only be modified by qualified ALU
personnel.
Feature L115233(.1)
The value "0" is used to disable the timer.
5.1.4.4 BUFFER STATUS REPORTING
The Buffer Status reporting procedure is used to provide the serving eNB with
information about the amount of data available for transmission in the UL buffers of
the UE.
A Buffer Status Report (BSR) is sent periodically. The reporting period is configured
by parameter periodicBSRtimer (in terms of subframes).
The UE also maintains another timer configured by parameter retxBSRtimer (in
terms of subframes). Each time this timer expires and the UE has data available for
transmission, a BSR is sent (regular BSR). If the UE has UL resources allocated for
new transmission for this TTI, then these timers are (re)started each time a BSR is
sent (Regular or Periodic).
Page 140/222
CellL2ULConf::periodicBSRtimer
Parameter periodicBSRtimer
{ sf5, sf10, sf16, sf20, sf32, sf40, sf64, sf80, sf128, sf160, sf320,
sf640, sf1280, sf2560, infinity }

Value sf5
Feature L76501
CellL2ULConf::retxBSRtimer
Parameter retxBSRtimer
{ sf320, sf640, sf1280, sf2560, sf5120, sf10240 }

Value sf320
Feature L76501
5.1.4.5 POWER HEADROOM REPORTING
The Power Headroom reporting procedure is used to provide the serving eNB with
information about the difference between the nominal UE maximum transmit power
and the estimated power for UL-SCH transmission.
A Power Headroom Report (PHR) is sent periodically. The reporting period is
configured by parameter periodicPHRtimer (in terms of subframes).
The UE also maintains another timer configured by parameter prohibitPHRtimer (in

terms of subframes). Each time this timer expires and the path loss has changed
more than dlPathlossChangeForPHRreporting dB (since the last PHR) a PHR is
sent.
If the UE has UL resources allocated for new transmission for this TTI, then these
timers are (re)started each time a PHR is sent (Periodic or not).
Page 141/222
CellL2ULConf::periodicPHRtimer
Parameter periodicPHRtimer
{ sf10, sf20, sf50, sf100, sf200, sf500,sf1000, infinity }

Feature L76501
Engineering Recommendation: Regarding parameter periodicPHRtimer

If activation flag isSPSConfigAllowed is set to True, then periodicPHRtimer
should be set to ‘sf100’.
The default value is ‘sf200’.
CellL2ULConf::prohibitPHRtimer
Parameter prohibitPHRtimer
{ sf0, sf10, sf20, sf50, sf100, sf200, sf500, sf1000 }
Value sf0
Feature L76501
CellL2ULConf::dlPathlossChangeForPHRreporting
Parameter dlPathlossChangeForPHRreporting
{ dB1, dB3, dB6, infinity }

Value dB1
Feature L76501
Page 142/222
5.1.5 MAC SCHEDULER

In order to efficiently utilize the physical layer resources, a scheduling function is
used in the MAC layer of the eNB.
Different schedulers operate for the uplink and the downlink. The uplink and downlink
schedulers assign resources based on
• The QoS requirements of the UE’s bearers requirements.
• The radio conditions of the UEs identified through measurements made at

the eNB (in the uplink) or reported by the UE (in the downlink).
• The amount of data to transmit per UE and per bearer.
Resource assignment consists of Physical Resource Block (PRB) and Modulation

Coding Scheme (MCS).
The uplink and downlink schedulers are described in detail in [Vol. 4], along with the
associated parameters.
5.2 THE RADIO LINK CONTROL SUBLAYER

The main services and functions of the RLC sublayer include:
• Error detection and correction through ARQ (in the Acknowledged Mode).
• Concatenation, segmentation and reassembly of RLC SDUs (in the
Acknowledged Mode and the Unacknowledged Mode).
Functions of the RLC (sub)layer are performed by RLC entities. For an RLC entity
configured at the eNB, there is a peer RLC entity configured at the UE and vice
versa.
An RLC entity can be configured to perform data transfer in one of the following three
modes: Transparent Mode (TM), Unacknowledged Mode (UM) and Acknowledged
Mode (AM). Consequently, an RLC entity is categorized as a TM RLC entity, an UM
RLC entity or an AM RLC entity depending on the mode of data transfer the RLC
entity is configured to work in.
MBMS is using the RLC layer in UM mode for the MTCH and the MCCH channels.
In addition, the MCH Scheduling Information (MSI) is handled as a specific logical
channel in TM mode. Refer to section 5.2.4.6 for MBMS impacts on RLC.
Page 143/222
Figure 48 illustrates the overview model of the RLC (sub)layer.
Figure 48: Overview model of the RLC layer
A TM RLC entity can be configured to deliver/receive RLC PDUs through the BCCH,
DL/UL CCCH and PCCH logical channels.
An UM RLC entity can be configured to deliver/receive RLC PDUs through the
DL/UL DTCH, and MTCH / MCCH (for MBMS) logical channels.
An AM RLC entity can be configured to deliver/receive RLC PDUs through the DL/UL
DCCH or DL/UL DTCH logical channels.
RLC/PDCP Flow Control supports PDCP ciphering and verification. The RLC/PDCP
Flow Control feature also improves bearer performance by eliminating RLC buffer
overflow.
The following sections describe RLC flow control, RLC Unacknowledged Mode, and
RLC Acknowledged Mode in more detail.
5.2.2 RLC-PDCP FLOW CONTROL
The RLC-PDCP flow control feature (FRS 97014) operates between the RLC and
PDCP processing entities in the downlink (DL) only. The RLC signals buffer
congestion to the PDCP layer directly in the data path (rather than in the control
plane) to reduce the flow control latency. The RLC-PDCP Flow Control feature is
enabled by an activation parameter (see the parameter description later in this
section). If the RLC-PCDP Flow Control feature is not enabled, then no flow control
is performed between the RLC and PDCP layers, and the remainder of this section
does not apply.
Page 144/222
In the eNB DL User Plane processing, traffic data is buffered in an RLC buffer. The
RLC buffer is required to hold the DL PDCP PDUs waiting for the transmission
scheduling opportunity that MAC layer signals.
To accomplish RLC Flow Control, the RLC layer sends buffer state indication
packets to the PDCP layer on the UPlane. These packets are compatible with the
format used for RLC end marker.
The RLC-PDCP flow control feature is enabled or disabled by setting the value for
parameter rlcPdcpFlowControlEnabled. When the value of this parameter is set to
“True”, then both RLC and PDCP flow control is enabled. When the value of this
parameter is set to “False”, then the RLC and PDCP do not perform any flow control
and buffer management actions.
Page 145/222
TrafficRadioBearerConf:: rlcPdcpFlowControlEnabled
Parameter rlcPdcpFlowControlEnabled
Object ENBEquipment/Enb/DedicatedConf/TrafficRadioBearerConf
True/False
Value See Engineering Recommendation below
Feature L97014
Engineering Recommendation: rlcPdcpFlowControlEnabled
When the RLC-PDCP Flow Control feature is released, the following values are
recommended for various QCI values (TrafficRadioBearerConf::qCI values)
QCI Value Recommended

rlcPdcpFlowControlEnabled
Parameter Value
GBR-1 False
GBR-2 False
GBR-3 False
GBR-4 True
NonGBR-5 True
NonGBR-6 True
NonGBR-7 True
NonGBR-8 True
NonGBR-9 True
5.2.2.1 RLC FLOW CONTROL AND TIMER-BASED DISCARD
If RLC Flow Control is enabled (see Section 5.2.2), then three flow control states are
enabled for the RLC downlink buffer. If RLC Flow Control is not enabled, then flow
control does not apply, the buffer is stateless, and the buffer can overflow.
RLC buffer management is accomplished by utilizing three states and two thresholds
that are set by user input (see Section 5.2.2.2). The RLC buffer can be in any of the
following three states:
Page 146/222
BL state: Buffer occupancy is less than the lower threshold (TL), including
zero buffer occupancy
BM state: Buffer occupancy is between the TL threshold and the high
threshold (TH)
BH state: Buffer occupancy is higher than TH, including buffer overflow
When the RLC buffer enters the BH state or the BL state, then the PDCP layer is
notified to stop (when entering the BH state) or re-start (when entering the BL state)
sending RB data to the RLC layer. The notification to the PDCP layer includes:
UL First Missing Sequence (FMS)
o For AM RBs, the RLC records the UL FMS (next in-sequence PDCP
data PDU SN that is expected to be received from the UE) and
updates it constantly.
o For UM RBs, the UL FMS is just set to all zeros
DL FMS
o For AM RBs, the DL FMS points to the first PDCP PDU that has not
been ACKed by the UE. This value is updated each time the RLC
receives an RLC Status PDU that contains the UE ACK status.
o For UM RBs, the DL FMS points to the first DL PDCP data PDU in
the RLC SDU buffer that is still waiting for DL transmission.
DL bitmap – This applies only to AM RBs. The RLC records the positions of
all the ACKed PDCP data PDUs after the DL FMS PDU. The bitmap only
indicates PDUs up to the last PDU that has been ACKed by the UE.
RLC timer based discard will be used in a future release to perform QoS based
discard. This capability is not implemented in LR13.1. In general the timer is
configured by CP when the RB is set up, and is system_restricted for the life of this
RB. Discard is only applied to TRBs (AM or UM), and not to SRBs or PDCP control
PDUs. A different timer value is typically used for each type of RB (see Section
5.2.2.2).
Only PDCP data PDUs that have not been assigned an RLC sequence number,
have not been segmented, and have not been submitted to the MAC layer may be
discarded.
RLC will not discard more than half of the maximum PDCP SN consecutive PDCP
PDUs in order to prevent hyperframe desynchronization.
5.2.2.1.1 RLC ADAPTIVE BUFFER DIMENSIONING

The buffer sizes are calculated based on each RB’s perceived rate (GBR or
Aggregated Maximum Bit Rate (AMBR) for non-GBR RBs), and QoS weighting.
Some of the principles used in establishing the buffer lengths are:
A minimum packet life time may be used as a base input

For GBR RB, the base buffer size is the GBR times the packet life time
Page 147/222
For Non-GBR RB, the base buffer size is based on AMBR, life, and QoS
weighting
A maximum ceiling and a minimum floor may be set for all buffers.
The following equations are used by the system to determine the RLC AM and RLC
UM buffer lengths in terms of bytes:
For GBR Radio Bearers:
Buffer size = Min[(SF + GBR * T * WQ)/8000, SC]
For Non-GBR Radio Bearers:

Buffer size = Min[(SF + AMBR * T * WQ)/8000, SC]
Where:
SF = The base size (floor or minimum size of the buffer)
SC = The ceiling size for the buffer (maximum capped size)
WQ = The QoS weighting factor (0 to 100%). For GBR RBs, this normally should
be set to 100%. Note that this value is entered as an integer in the range 0 – 100,
and is then divided by 100 by the system for use in the formula.
T = The buffering time
The GBR and AMBR use units of kbps and they are signaled by the core network
when the E-RAB is established. The parameter list that is used to establish the RLC
buffer length is described in Section 5.2.2.2.
5.2.2.2 RLC FLOW CONTROL AND TIMER-BASED DISCARD

PARAMETERS
The low threshold (TL) value is set by parameter rlcSduBufferLowerThreshold.
TrafficRadioBearerConf::rlcSduBufferLowerThreshold
Parameter rlcSduBufferLowerThreshold
Range & Unit Percentage
0 to 100%, step 1%
Value See the Engineering Recommendation provided below
Feature L97014
Page 148/222
The high threshold (TH) value is set by parameter rlcSduBufferHigherThreshold.
TrafficRadioBearerConf::rlcSduBufferHigherThreshold
Parameter rlcSduBufferHigherThreshold
0 to 100%, step 1%
Feature L97014
The Engineering Recommendation provided below indicates the recommended

values for various types of RBs.
Engineering Recommendation: TrafficRadioBearerConf::

rlcSduBufferLower Threshold, rlcSduBufferHigherThreshold
QCI Value rlcSduBuffer rlcSduBuffer

LowerThreshold HigherThreshold
GBR-1 40% 80%
GBR-2 40% 80%
GBR-3 40% 80%
GBR-4 30% 70%
nonGBR-5 30% 70%
nonGBR-6 30% 70%
nonGBR-7 30% 70%
nonGBR-8 30% 70%
nonGBR-9 30% 70%
ALU recommends that the operator not change these values
The parameter rlcDiscardTimerEnb is visible in WPS and has values provided in

the templates, but is not implemented in the current release.
Page 149/222
TrafficRadioBearerConf:: rlcDiscardTimerEnb
Parameter rlcDiscardTimerEnb
{50ms, 100ms, 150ms, 300ms, 500ms, 750ms, 1500ms,
infinity}
Feature L97014

Engineering Recommendation: rlcDiscardTimerEnb parameter
QCI Value rlcDiscardTimerEnb
GBR-1 100 msec
GBR-2 150 msec
GBR-3 50 msec
GBR-4 300 msec
nonGBR-5 1500 msec
nonGBR-6 infinity
nonGBR-7 infinity
nonGBR-8 infinity
nonGBR-9 infinity
These timer values are not used in LR13.1, but are expected to be used in a
future release. As a result, the timer values should be left at their default
settings.
Page 150/222
The RLC SDU buffer size is set based on the list of values provided by the
rlcSduBufferCoefficients parameter. Note that this parameter is associated with the
TrafficRadioBearerConf object, and an instance of this object is provided for each
QCI value (type of RB).
TrafficRadioBearerConf::rlcSduBufferCoefficients
Parameter rlcSduBufferCoefficients
Range & Unit List of the following values:
SF = The base size (floor or minimum size of the buffer in
Kbytes)
SC = The ceiling size for the buffer (maximum capped size in
Kbytes)
T = The buffering time (in msec)
WQ = The QoS weighting factor (0 to 100%). For GBR RBs,
this normally should be set to 100%. Note that this value
is entered as an integer in the range 0 – 100, and is then
divided by 100 by the system for use in the formula.

Feature L97014

TrafficRadioBearerConf::rlcSduBufferCoefficients
QCI Value SF SC T WQ
GBR-1 1 16 3000 100
GBR-2 1 256 2000 100
GBR-3 1 256 1000 100
GBR-4 1 2048 3000 100
nonGBR-5 1 256 3000 100
nonGBR-6 1 2048 3000 100
nonGBR-7 1 2048 3000 100
nonGBR-8 1 2048 3000 80
nonGBR-9 1 2048 3000 60
Page 151/222
5.2.3 RLC UNACKNOWLEDGED MODE (UM)
5.2.3.1 RLC UM STATE VARIABLES, CONSTANTS AND TIMERS
5.2.3.1.1 RLC UM STATE VARIABLES

Each transmitting UM RLC entity maintains state variable VT(US) that holds the
value of the SN to be assigned for the next newly generated UMD PDU. It is initially
set to 0, and is updated whenever the UM RLC entity delivers an UMD PDU with SN
= VT(US).
Each receiving UM RLC entity maintains the following state variables:
• VR(UR) – UM receive state variable: This state variable holds the value of
the SN of the earliest UMD PDU that is still considered for reordering. It is
initially set to 0.
• VR(UX) – UM t_Reordering state variable: This state variable holds the value
of the SN following the SN of the UMD PDU which triggered t_Reordering. It
is initially set to NULL.
• VR(UH) – UM highest received state variable: This state variable holds the
value of the SN following the SN of the UMD PDU with the highest SN
among received UMD PDUs. It is initially set to 0.
5.2.3.1.2 RLC UM CONSTANTS

• UM_Window_Size: This constant is used by the receiving UM RLC entity to
calculate VR(UMR) from VR(UR). UM_Window_Size = 16 when a 5-bit SN is
configured and UM_Window_Size = 512 when a 10-bit SN is configured (see
Section 5.2.3.2.
5.2.3.1.3 RLC UM TIMERS

• t_Reordering: This timer is used by the receiving side of the UM RLC entity
in order to detect the loss of RLC PDUs at the MAC layer (see Section
5.2.3.3) and thus HARQ reordering. If t_Reordering is running, another
t_Reordering cannot be started, i.e. only one t_Reordering can be running at
a given time. Parameters timerTreorderingDownlink and
timerTreorderingUplink configure the value of t_Reordering UM timer for
the downlink and the uplink, respectively.
Page 152/222
RlcUmConf::timerTreorderingDownlink
Parameter timerTreorderingDownlink
Object ENBEquipment/Enb/DedicatedConf/RlcConf/RlcUmConf
[ms0, ms5, ms10, ms15, ms20, ms25, ms30, ms35, ms40,
ms45, ms50, ms55, ms60, ms65, ms70, ms75, ms80, , ms90,
ms95, ms100, ms110, ms120, ms130, ms140, ms150, ms160,
ms170, ms180, ms190, ms200]
Value See Engineering Recommendation in Table 27
Feature L76501
RlcUmConf::timerTreorderingUplink
Parameter timerTreorderingUplink
ms45, ms50, ms55, ms60, ms65, ms70, ms75, ms80, ms85,
ms160, ms170, ms180, ms190, ms200]
Feature L76501
5.2.3.2 RLC UM PDU FORMAT
The UM PDU consists of a header part and a data part. The PDU header consists of
a system_restricted part (fields that are present for every UM PDU) and an extension
part (fields that are present for an UM PDU when necessary).
The system_restricted part of the UM PDU header contains a Sequence Number
(SN) field. The UM RLC entity is configured to use either a 5 bit SN or a 10 bit SN
using parameters sNfieldLengthDownlink and sNfieldLengthUplink for the
downlink and the uplink, respectively.
Page 153/222
RlcUmConf::sNfieldLengthDownlink
Parameter sNfieldLengthDownlink
[size5, size10]
Feature L76501
RlcUmConf::sNfieldLengthUplink
Parameter sNfieldLengthUplink
Enumerate
Range & Unit
[size5, size10]
Feature L76501
When the 5-bit SN is configured, the UM PDU header’s system_restricted part length
is one byte. It consists of a 2-bit Framing Information (FI) field, a 1-bit Extension (E)
field and the 5-bit SN field (see Figure 49).
Figure 49: UM PDU with a 5-bit SN field and no header extension
When the 10-bit SN is configured, the UM PDU header’s system_restricted part

length is 2 bytes. It consists of a 2-bit Framing Information (FI) field, a 1-bit Extension
(E) field, the 5-bit SN field and 3 R1 fields (see Figure 49). Note that an R1 field is a
1-bit reserved field set to 0 by the transmitting entity and ignored by the receiving
entity.
Page 154/222
Figure 50: UM PDU with a 10-bit SN field and no header extension
5.2.3.3 RLC UM TRANSMIT OPERATIONS
When delivering a new UM PDU to the lower layer, the transmitting UM RLC entity
sets the SN of the UM PDU to VT(US), and then increments VT(US) by one.
5.2.3.4 RLC UM RECEIVE OPERATIONS
The receiving UM RLC entity maintains a reordering window according to state

variable VR(UH) as follows:
An SN falls within the reordering window if (VR(UH) – UM_Window_Size) ≤ SN <

VR(UH) and outside of the reordering window otherwise.
When an UM PDU that falls within the reordering window is received from lower
layer, it is placed in the reception buffer if it has not been received yet, otherwise it is
discarded by the RLC entity.
When an UM PDU with SN = x is placed in the reception buffer, the receiving UM

RLC entity proceeds as follows:
• if x falls outside of the reordering window:
o It updates VR(UH) to x + 1.
o It reassembles RLC SDUs from any UM PDUs with SN that falls
outside of the reordering window, removes RLC headers when doing
so and delivers the reassembled RLC SDUs to the upper layer in
sequence.
o If VR(UR) falls outside of the reordering window, it sets VR(UR) to
(VR(UH) – UM_Window_Size).
• If the reception buffer contains an UM PDU with SN = VR(UR)
o It updates VR(UR) to the SN of the first UMD PDU with SN >
current VR(UR) that has not been received.
Page 155/222
o It reassembles RLC SDUs from any UMD PDUs with SN <

updated VR(UR), removes RLC headers when doing so and delivers
the reassembled RLC SDUs to the upper layer in sequence.
• If t_Reordering is running, then if VR(UX) ≤ VR(UR) or if VR(UX) falls
outside of the reordering window
o It stops and resets t_Reordering.
o It sets VR(UX) to NULL.
• If t_Reordering is not running (includes the case when t_Reordering is

stopped due to actions above), then if VR(UH) > VR(UR)
o It starts t_Reordering.
o It sets VR(UX) to VR(UH).
When t_Reordering expires, the receiving UM RLC entity proceeds as follows:
• It updates VR(UR) to the SN of the first UM PDU with SN ≥ VR(UX) that has
not been received.
• It reassembles RLC SDUs from any UMD PDUs with SN < updated VR(UR),
removes RLC headers when doing so and delivers the reassembled RLC
SDUs to the upper layer in sequence.
• If VR(UH) > VR(UR),
o It sets VR(UX) to VR(UH).
5.2.3.5 RLC UM PARAMETER VALUES
Values are provided in Table 27 for the Radio Bearers that use the RLC UM mode,
along with an indication of the Radio Bearer QCI. A radio bearer object is created for
each QCI.
Page 156/222
Engineering Recommendation: Parameters LabelID, snFieldLengthDownlink, snFieldLengthUplink,

timerTReorderingDownlink, and timerTReorderingUplink
TrafficRadioBearer:: snFieldLength snFieldLength timerTReordering timerTReordering

QCI Downlink Uplink Downlink Uplink
GBR-1 size5 size5 ms20 ms35
nGBR-7 size10 size10 ms45 ms35
Table 27. Engineering Recommendation for RLC UM Parameter Values for Traffic Radio Bearer QCI
values
5.2.4 RLC ACKNOWLEDGED MODE (RLC AM)

The QCI values that are not listed in Table 27 (GBR-4, nGBR-5, nGBR-6, nGBR-8,
and nGBR-9) utilize the RLC Acknowledged Mode, which is described in this section.
5.2.4.1 RLC AM PDU
An RLC AM Data (AMD) PDU consists of a Data field and an AMD PDU header. The
AMD PDU header consists of a system_restricted part (fields that are present in
every AMD PDU), and an extension part (fields that are present for an AMD PDU
when necessary). The basic AMD PDU appears as shown in Figure 51 : RLC AM
PDU.
D/C RF P FI E SN Oct 1
SN Oct 2
Data Oct 3
Oct N
Figure 51 : RLC AM PDU with No Header Extension

The fields are as follows:
D/C – Data/Control field. Indicates whether this is an RLC data PDU or an RLC
control PDU
Page 157/222
RF - Re-Segmentation Flag field. Indicates whether this is an AMD PDU or an

AMD PDU segment
P – Polling bit field. Indicates whether a status report is or is not requested.
FI – Framing Info field – a two bit indicator that indicates whether:
• the first byte of the data field corresponds to the first byte of the RLC
SDU (case 1)
• the last byte of the data field corresponds to the last byte of the RLC
SDU (case 2)
• both case 1 and case 2 are true
• neither case 1 nor case 2 is true
• E – Extension bit. Indicates whether a data field follows the system_restricted

part of the PDU or a set of extension and length indicator fields follow.
• SN – Sequence Number. RLC-AM always uses the 10 bit sequence number.
5.2.4.2 RLC AM STATE VARIABLES, CONSTANTS AND

TIMERS
5.2.4.2.1 RLC AM STATE VARIABLES

The transmitting side of each AM RLC entity maintains the following state variables:
• VT(A) – Acknowledgement state variable: This state variable holds the value
of the SN of the next AM PDU for which a positive acknowledgment is to be
received in-sequence. It also serves as the lower edge of the transmitting
window and the STATUS receiving window. It is initially set to 0, and is
updated whenever the AM RLC entity receives a positive acknowledgment
for an AM PDU with SN = VT(A).
• VT(MS) – Maximum send state variable: This state variable equals VT(A) +
AM_Window_Size. It also serves as the higher edge of the transmitting
window.
• VT(S) – Send state variable: This state variable holds the value of the SN to
be assigned for the next newly generated AM PDU. It also serves as the
higher edge of the STATUS receiving window. It is initially set to 0, and is
updated whenever the AM RLC entity delivers an AM PDU with SN = VT(S).
The receiving side of each AM RLC entity maintains the following state variables:
• VR(R) – Receive state variable: This state variable holds the value of the SN
following the last in-sequence completely received AM PDU. It also serves
as the lower edge of the receiving window. It is initially set to 0, then updated
whenever the AM RLC entity receives an AM PDU with SN = VR(R).
Page 158/222
• VR(MR) – Maximum acceptable receive state variable: This state variable

equals VR(R) + AM_Window_Size. It holds the value of the SN of the first
AMD PDU that is beyond the receiving window.
• VR(X) – t_Reordering state variable: This state variable holds the value of
the SN following the SN of the RLC data PDU which triggered t_Reordering.
It is initially set to NULL.
• VR(MS) – Maximum STATUS transmit state variable: This state variable
holds the value of the SN to be indicated by “ACK_SN” when a STATUS
PDU needs to be constructed. It is initially set to 0.
• VR(H) – Highest received state variable: This state variable holds the value
of the SN following the SN of the RLC data PDU with the highest SN among
received RLC data PDUs. It is initially set to 0.
5.2.4.2.2 RLC AM CONSTANTS

• AM_Window_Size: This constant is used by both the transmitting side and
the receiving side of each AM RLC entity to calculate VT(MS) from VT(A),
and VR(MR) from VR(R). AM_Window_Size = 512.
• pollPDU: This constant is used by the transmitting side of each AM RLC
entity for which the polling trigger “Every pollPDU PDUs” has been
configured (see Section 5.2.4.3). It represents the interval between polls, in
PDUs. Parameters PollPDUDownlink and PollPDUUplink configure the
value of pollPDU in the downlink and in the uplink, respectively.
• pollByte: This constant is used by the transmitting side of each AM RLC
entity for which the polling trigger “Every pollByte bytes” has been configured
(see Section 5.2.4.3). It represents the interval between polls in terms of
number of transmitted bytes. Parameters PollByteDownlink and
PollByteUplink configure the value of pollByte in the downlink and in the
uplink, respectively.
RlcAmConf::pollPDUDownlink
Parameter pollPDUDownlink
Object ENBEquipment/Enb/DedicatedConf/RlcConf/RlcAmConf
[ p4, p8, p16, p32, p64, p128, p256, pInfinity ] PDUs

Value p32
Feature L76501
Page 159/222
RlcAmConf::pollPDUUplink
Parameter pollPDUUplink
[ 4, 8, 16, 32, 64, 128, 256, Infinity ] PDU

Value p32 PDUs
Feature L76501
RlcAmConf::PollByteDownlink
Parameter PollByteDownlink
[ kb25, kb50, kb75, kb100, kb125, kb250, kb375, kb500,
kb750, kb1000, kb1250, kb1500, kb2000, kb3000, kbinfinity ]
Kbytes
Value kbinfinity
Feature L76501
RlcAmConf::PollByteUplink
Parameter PollByteUplink
[kb25, kb50, kb75, kb100, kb125, kb250, kb375, kb500,
kb750, kb1000, kb1250, kb1500, kb2000, kb3000, kbinfinity
Kbytes]
Value kbinfinity
Feature L76501
5.2.4.2.3 RLC AM TIMERS
• PollRetransmit: This timer is used by the transmitting side of an AM RLC

entity in order to retransmit a poll (see section 5.2.4.5.2). Parameters
Page 160/222
timerTpollRetransmitDownlink and timerTpollRetransmitUplink

configure PollRetransmit in the downlink and the uplink, respectively.
RlcAmConf::timerTpollRetransmitDownlink
Parameter timerTpollRetransmitDownlink
ms250, ms300, ms350, ms400, ms450, ms500
Value ms60 msec
Feature L76501
RlcAmConf::timerTpollRetransmitUplink
Parameter timerTpollRetransmitUplink
ms250, ms300, ms350, ms400, ms450, ms500
Value ms60 msec
Feature L76501
• t_Reordering: This timer is used by the receiving side of an AM RLC entity in

order to detect the loss of RLC PDUs at the MAC layer (see sections 5.2.3.4
and 5.2.4.4) and thus HARQ reordering. If t_Reordering is running, another
t_Reordering cannot be started, i.e. only one t_Reordering can be running at
a given time. Parameters timerTreorderingDownlink and
timerReorderingUplink configure the value of t_Reordering AM timer for
the downlink and the uplink, respectively.
Page 161/222
RlcAmConf::timerTreorderingDownlink
Parameter timerTreorderingDownlink
ms160, ms170, ms180, ms190, ms200] milliseconds
Value ms45
Feature L76501
RlcAmConf::timerTreorderingUplink
Parameter timerTreorderingUplink
ms160, ms170, ms180, ms190, ms200] milliseconds
Value ms45
Feature L76501
• t-StatusProhibit: This timer is used by the receiving side of an AM RLC entity

in order to prohibit the transmission of a STATUS PDU (see section
5.2.4.5.3). This timer is used to prohibit the receiving side of an AM RLC
entity from sending consecutive acknowledgement status reports.
Parameters timerStatusProhibitDownlink and
timerStatusProhibitDownlink configure the value of t-StatusProhibit.
Page 162/222
RlcAmConf::timerStatusProhibitUplink
Parameter timerStatusProhibitUplink
ms250, ms300, ms350, ms400, ms450, ms500] milliseconds
Value ms10
Feature L76501
RlcAmConf::timerStatusProhibitDownlink
Parameter timerStatusProhibitDownlink
ms250, ms300, ms350, ms400, ms450, ms500] milliseconds
Value ms10
Feature L76501
5.2.4.3 TRANSMIT OPERATIONS
The transmitting side of an AM RLC entity maintains a transmitting window according

to state variables VT(A) and VT(MS) as follows:
A SN falls within the transmitting window if VT(A) ≤ SN < VT(MS) and outside of the
transmitting window otherwise. The transmitting side of an AM RLC entity does not
deliver to the lower layer any RLC data PDU whose SN falls outside of the
transmitting window.
The transmitting side of an AM RLC entity also maintains a STATUS receiving
window according to state variables VT(A) and VT(S) as follows:
• An SN falls within the STATUS receiving window if VT(A) ≤ SN < VT(S).
Page 163/222
• An SN falls outside of the STATUS receiving window otherwise.
When delivering a new AM PDU to the lower layer, the transmitting side of an AM
RLC entity sets the SN of the AM PDU to VT(S) and then increments VT(S) by one.
The transmitting side of an AM RLC entity receives positive acknowledgements for

AM RLC PDUs (confirmation of successful reception) from its peer AM RLC entity
inside the STATUS PDU.
Upon reception of a positive acknowledgement for an AM PDU with SN = VT(A), the
transmitting side of an AM RLC entity proceeds as follows
• If positive acknowledgements have been received for all other AM PDUs
whose SN fall within the STATUS receiving window, it sets VT(A) equal to
VT(S).
• Else, it sets VT(A) equal to the SN of the AM PDU with the smallest SN
whose SN falls within the STATUS receiving window and for which a positive
acknowledgment has not been received yet.
5.2.4.4 RECEIVE OPERATIONS
The receiving side of an AM RLC entity maintains a receiving window according to

state variables VR(R) and VR(MR) as follows:
An SN falls within the receiving window if VR(R) ≤ SN < VR(MR) and outside of the
receiving window otherwise.
When an RLC data PDU with SN=x and byte segment numbers y to z is received
from lower layer, the RLC AM entity proceeds as follows:
• If x falls outside of the receiving window or if byte segment numbers y to z of

the AM PDU with SN = x have been received before, the RLC AM entity
discards the received RLC data PDU.
• Else, the RLC AM entity places the received RLC data PDU in the reception
buffer. If, besides, some byte segments of the AM PDU contained in the
PDU have been received before, the duplicate byte segments are discarded.
When a RLC data PDU with SN = x is placed in the reception buffer, the receiving
side of an AM RLC entity proceeds as follows:
• If all byte segments of the PDU are received, it updates VR(MS) to the SN of
the first PDU with SN > current VR(MS) for which not all byte segments
have been received.
• If x = VR(R), it reassembles RLC SDUs from any byte segments of PDUs

with an SN that falls outside of the receiving window and in-sequence byte
segments of the PDU with SN = VR(R). It removes RLC headers when doing
so and delivers the reassembled RLC SDUs to the upper layer in sequence if
Page 164/222
it was not delivered before. If, besides, all byte segments of the PDU with SN
= VR(R) are received:
o It updates VR(R) to the SN of the first AMD PDU with SN > current
VR(R) for which not all byte segments have been received.
o It updates VR(MR) to the updated VR(R) + AM_Window_Size.
• If x ≥ VR(H), it updates VR(H) to x+1.
• If t_Reordering is running, and VR(X) = VR(R) or VR(X) falls outside of the

receiving window:
o It stops and resets t_Reordering.
o It sets VR(X) to NULL.
• If t_Reordering is not running (includes the case when t_Reordering is

stopped due to actions above) and if the VR (H) > VR(R):
o It sets VR(X) to VR(H).
When t_Reordering expires, the receiving side of an AM RLC entity proceeds as

follows:
• It updates VR(MS) to the SN of the first PDU with SN ≥ VR(X) for which not
all byte segments have been received.
• If VR(H) > VR(MS)
o It sets VR(X) to VR(H);
5.2.4.5 ARQ PROCEDURES
5.2.4.5.1 RETRANSMISSION
The transmitting side of an AM RLC entity can receive a negative acknowledgement
(notification of reception failure by its peer AM RLC entity) for an AM PDU or a
portion of an AM PDU by the following:
• STATUS PDU from its peer AM RLC entity.

• HARQ delivery failure from the transmitting MAC entity.
When a negative acknowledgement is received and the SN of the corresponding AM

PDU falls within the STATUS receiving window, the AM PDU (or the portion of the
AM PDU) for which the negative acknowledgement was received, is retransmitted.
Page 165/222
When retransmitting an AM PDU, the transmitting side of an AM RLC entity proceeds

as follows:
• If the AM PDU can entirely fit into the TB of the particular transmission
opportunity, it delivers the AM PDU as it is.
• Else, it segments the AM PDU and forms a new AM PDU segment which fits
into the TB of the particular transmission opportunity.
Parameters maxRetxThresholddownlink and maxRetxThresholduplink configure

the maximum number of ARQ retransmissions allowed in the downlink and the
uplink, respectively. When the number of retransmissions exceeds this threshold, the
RLC notifies the CallP that RLC re-establishment is required.
RlcAmConf::maxRetxThresholddownlink
Parameter maxRetxThresholddownlink
[t1,t2,t3,t4,t6,t8,t16,t32] retransmissions
Value t32
Feature L76501
RlcAmConf:: maxRetxThresholduplink
Parameter maxRetxThresholduplink
[t1,t2,t3,t4,t6,t8,t16,t32] retransmissions
Value t16
Feature L76501
5.2.4.5.2 POLLING
An AM RLC entity can poll its peer AM RLC entity in order to trigger STATUS
reporting at the peer AM RLC entity. The 1-bit P field of the RLC PDU indicates
whether or not the transmitting side of the AM RLC entity requests a STATUS report
from its peer AM RLC entity for the PDU in question.
Page 166/222
Triggers to initiate polling include:

Transmission of last data in the buffer, i.e. if both the transmission buffer and
the retransmission buffer become empty (excluding transmitted RLC data
PDU awaiting for acknowledgements) after the transmission of the RLC
PDU. This event (the transmission of the last PDU in the buffer) triggers a
STATUS report
• Expiry of timer t-PollRetransmit. This event triggers a STATUS reporting

when parameter pollTriggerTpollRetransmitDownlink is set to TRUE, in
which case the transmitting side of an AM RLC entity starts t-
PollRetransmit each time it sends a PDU with the P field set to "1", which
happens each time another t-PollRetransmit expires (i.e. the polls are
triggered periodically and the period is given by t-PollRetransmit).
RlcAmConf::pollTriggerTpollRetransmitDownlink
Parameter pollTriggerTpollRetransmitDownlink
TRUE/FALSE
Value TRUE
Feature
Parameter unansweredDownlinkPollCountMax configures the maximum

number of consecutive unanswered DL polls allowed. When the number of
consecutive unanswered DL polls exceeds this threshold, RLC notifies the CallP
that RLC re-establishment is required.
RlcAmConf::unansweredDownlinkPollCountMax
Parameter unansweredDownlinkPollCountMax
[1..63]
Value 63
Feature
Page 167/222
5.2.4.5.3 STATUS REPORTING

An AM RLC entity sends STATUS PDUs to its peer AM RLC entity in order to
provide positive and/or negative acknowledgements of RLC PDUs (or portions of
them).
Triggers to initiate STATUS reporting include
• The reception of an RLC data PDU with the P field set to "1".
• The expiry of t_Reordering. This also triggers VR(MS) to be updated.
When STATUS reporting has been triggered, the receiving side of an AM RLC entity
proceeds as follows:
• If the t-StatusProhibit is not running, it constructs and delivers a STATUS
PDU to the MAC layer at the first transmission opportunity indicated by the
lower layer.
• Else, it constructs and delivers a STATUS PDU to the MAC layer at the first
transmission opportunity indicated by the lower layer after t-StatusProhibit
expires.
When a STATUS PDU has been delivered to the lower layer, the receiving side of an
AM RLC starts t-StatusProhibit.
When constructing a STATUS PDU, the AM RLC proceeds as follows:

• It sets ACK_SN to VR(MS).
• For each AM PDU with an SN such that VR(R) ≤ SN < VR(MS) that has not
been completely received yet:
o If no byte segments have been received yet for an AM PDU, it
includes, in the STATUS PDU, a NACK_SN set to the SN of the AM
PDU.
o Else, it includes, in the STATUS PDU, a set of NACK_SN, SOstart
and SOend for each consecutive byte segments of the AM PDU that
has not been received yet. Note that SOstart is a 15-bit field
(together with the 15-bit SOend field) indicates the portion of the
AMD PDU with SN = NACK_SN (the NACK_SN for which the
SOstart is related to) that has been detected as lost at the receiving
side of the AM RLC entity.
5.2.4.6 MBMS IMPACT ON RLC LAYER

Before entering the RLC layer, the MBMS IP packets are first processed by a
synchronization entity, the SYNC Layer (described in section 5.4), that controls the
ordering and timing of the incoming packets received over the M1 interface from the
Page 168/222
BM-SC at the core network. The packets coming from the M1 interface are not
processed at all by the PDCP layer.
For eMBMS, the RLC entities are:
• One TM entity is configured for the MSI.
• One UM entity is configured per MCCH. MCCH is the point-to-multipoint

downlink channel used for transmitting eMBMS control information to UEs.
There is one MCCH per MBSFN area.
• One UM entity per MTCH. MTCH is the point-to-multipoint downlink channel

used to transmit u-plane eMBMS traffic to the UE. The eMBMS u-plane
packets received by L2 are first processed by the SYNC entity and then
delivered to the RLC layer.
There is no flow control with PDCP because the PDCP layer is not used for MBMS.
Page 169/222
5.2.5 USE OF ALU RLC TEMPLATES FOR CUSTOM

QUALITY OF SERVICE CLASSES
The Feature “QCI and QCI Parameters for Advanced Scheduling Decisions”
(Feature Number 92095) introduces the opportunity to provide customized Quality of
Service classes (see Volume 4 for additional detail). If desired, these non-standard
Quality of Service classes can utilize Radio Bearer Configurations that are pre-
defined in the eNB templates. As indicated in Table 29, the individual standardized
QCIs support specific target Packet Loss Error Rates. These supported Packet Error
Loss Rates can be used with non-standard CQIs by using the pre-defined RLC
configurations that are defined in the ALU WPS templates. For example, Figure 52
provides a WPS screenshot that shows the three pre-defined RLC Configurations.
Figure 52 : WPS Screenshot showing Pre-Defined RLC Configurations

Note that the template provides two pre-defined RLC-UM configurations, and one
pre-defined RLC-AM configuration. The custom QCI classes should also use these
RLC configurations, depending on the required PELR. As indicated in Table 28, RLC
RlcConf/2 RlcUmConf/0 should be used for a PELR of 10-2 , RlcConf/1 RlcUmConf/0
for a PELR of 10-3 and RlcConf/0 RlcAmConf/0 for a PELR of 10-6.
Page 170/222
The standardized QCI values, target Packet Error Loss Rate values, and the
associated pre-defined RLC Configuration Template configurations are shown in
Table 28.
Packet Error
QCI RLC Configuration
Loss Rate
1 10-2 RlcConf/2 RlcUmConf/0

-3
2 10 RlcConf/1 RlcUmConf/0
4 10-6 RlcConf/0 RlcAmConf/0
Table 28 : Standard QCI to RLC Configuration Mapping

The TrafficRadioBearer::rlcConfId parameter is used to indicate the RLC
configuration that is to be used for a standard or custom QCI.
5.3 THE PACKET DATA CONVERGENCE PROTOCOL

SUBLAYER

The main services and functions of the PDCP sublayer in the user plane are:
• Header compression and decompression.
• Retransmission of PDCP SDUs at handover for RLC AM.
• Ciphering and deciphering.
• Timer-based SDU discard in the uplink.
The main service of the PDCP sublayer in the control plane is ciphering and integrity
protection.
5.3.2 PACKET DATA CONVERGENCE PROTOCOL

PDCP (Packet Data Convergence Protocol) is a sublayer of LTE eUTRAN layer 2
protocols. On the User-Plane, it provides the IP data transfer service to the NAS
layer at the UE, and IP packets relay service at the eNB between S1/X2 GTP-U and
Page 171/222
air interface RLC links. On the Control-Plane, it provides a data transfer service to
the RRC layer for RRC messages. PDCP is specified in 3GPP TS 36.323.
The eNB PDCP entity performs the following functions:
• Header compression and decompression of user IP data flows, using the

Robust Header Compression (RoHC) at the transmitting and receiving entity
respectively.
• Transfer of data (user plane or RRC data).

• Maintenance of PDCP sequence numbers for radio bearers mapped on RLC
AM mode.
• In-sequence delivery of upper layer PDUs at HO.

• Elimination of duplicate lower layer SDUs at HO for radio bearers mapped on
RLC AM mode.
• Ciphering and deciphering of user plane and control plane data.

• Integrity protection of control plane data.
PDCP uses the services provided by the Radio Link Control (RLC) (sub)layer. The
RLC layer may use UM and AM modes for data transfer.
Note that in this section, the terms "in-order" and "in-sequence" are used as per the
following definitions:
In-order: A sender delivers PDUs in ascending order according to Sequence

Number (SN). There may or may not be SN gaps. The sender does reordering if
required, but does not care about the gap.
In-sequence: A sender delivers PDUs in ascending order according to SN, with
no SN gaps. The sender does reordering if required.
Note that RoHC is part of PDCP but it is discussed separately in Section 5.3.3, along
with the associated parameters.
5.3.2.1 PDCP ARCHITECTURE
Figure 53 depicts the PDCP (sub)layer architecture. As illustrated, the User-Plane

and the Control-Plane have different structures. Note that the PDCP buffer is not
shown.
Page 172/222
Uplane RBs Cplane SRBs

PDCP Entities
PDCP
PDCP-SAP PDCP SDU PDCP-SAP Sublayer
C-SAP
... SDU Numbering SDU Numbering ...

ROHC Packets associated
to a PDCP SDU
to a PDCP SDU
Packets not
associated
to a PDCP SDU
Packets not
associated
Packets associated
to a PDCP SDU Integrity Protection
Ciphering/Deciphering Ciphering/Deciphering
PDCP PDU
RLC SDU RLC

Sublayer
RLC UM/AM SAP RLC UM/AM SAP
Figure 53: PDCP sublayer architecture and functional elements
On the C-Plane, each Signaling Radio Bearer (SRB) is associated to a PDCP entity.
On the U-Plane, each Data Radio Bearer (DRB) is associated to a PDCP entity.
Each PDCP entity is associated to one or two RLC entities depending on the radio
bearer (1 for a unidirectional bearer and 2 for a bidirectional bearer).
Hence, each radio bearer is associated to a logical channel DTCH. Also, every SRB
in eUTRAN RRC is associated to a logical channel (DCCH, CCCH, BCCH or PCCH).
Note that SRBs mapped on CCCH, PCCH and BCCH are not associated to PDCP
entities.
Also, each PDCP entity uses at most one instance of each header compression
protocol. A UE may have several PDCP entities using the same or different sets of
header compression protocols.
5.3.2.1.1 CONFIDENTIALITY AND INTEGRITY PROTECTION

Feature FRS 92638 supports Confidentiality and Integrity Protection. The
Confidentiality and Integrity Protection feature operates at the PDCP layer, but
affects other layers and higher layer entities because of the need to distribute keys
that are used for the ciphering and integrity operations. The location of the ciphering
and integrity protection modules in the PDCP sublayer is illustrated in Figure 53.
Page 173/222
Together the ciphering and integrity protection services are called Access Stratum
(AS) security. AS stratum security is required in the RRC_CONNECTED state and is
maintained in the case of UE mobility (handover) and RRC Connection re-
establishment. AS security is based on security key derivation and security key
algorithms that are run (based on the security keys) in both the eNB and the UE. The
security features and procedures are specified in 3GPP TS 33.401.
Additional description of the AS security feature can be found in the following
sections:
5.3.2.7 – Ciphering and Deciphering
5.3.2.8 – Verification and Protection
5.3.2.8.1 – AS Security Feature Activation and Deactivation
5.3.2.8.2 – Ciphering and Integrity Protection Parameters
5.3.2.1.2 CONFIGURING THE PDCP LAYER

The PDCP sublayer is configured by the upper layer (CallP process) through the
PDCP-C-SAP interface.
On the C-Plane, the interface between PDCP and RRC is PDCP-SAP (SRBs). On
the U-Plane, at the UE, the interface between PDCP and IP (at the UE) is PDCP-
SAP (radio bearers). On the U-Plane, at the eNB, there is a simple relay between
PDCP and GTP-U.
The interface between PDCP and lower layer RLC is RLC-SAP. Depending on the
RLC mode (TM, UM or AM), there are TM RLC SAPs, UM RLC SAPs and AM RLC
SAPs. For U-Plane traffic, only UM and AM RLC SAPs are used. For C-Plane RRC
messages, only TM and AM RLC modes are used.
5.3.2.2 PDCP PDU
There are two types of PDCP PDUs: PDCP data PDUs and PDCP control PDUs.
5.3.2.2.1 PDCP DATA PDU

A PDCP data PDU is associated to a PDCP SDU (upper layer PDU). It consists of
the PDCP SDU (i.e., user U-Plane IP packet or C-Plane RRC message) and a PDCP
header and trailer (only for control data SDU).
5.3.2.2.1.1 U-PLANE PDCP DATA PDU
A U-Plane PDCP data PDU carries a user (possibly header-compressed) IP packet.

In this case, the PDCP header appended contains a Sequence Number field. There
are two lengths of the PDU sequence number: 7 bits and 12 bits.
Page 174/222
Figure 54 and Figure 55 illustrate the PDU formats with a 7-bit SN and a 12-bit SN,
respectively.
D/C PDCP Sequence Number Oct 1
Data Oct 2
...
Figure 54 : U-Plane PDCP data PDU format with a 7-bit SN
PDCP Sequence
D/C R R R Oct 1
Number
PDCP Sequence Number (cont.) Oct 2
Data Oct 3
...
Figure 55 : U-Plane PDCP data PDU format with a 12-bit SN
Note that the 1-bit D/C field is present in both cases and indicates whether it’s a data
PDU (D) or a control PDU(C). It is set to 1 in the case of a data PDU.
In the case of a 12-bit SN, 3 reserved bit fields (set to 0 at the transmitter and
ignored by the receiver) complete the PDU header.
PDUs mapped onto an RLC AM entity use a 12-bit SN.
On the other hand, PDUs mapped onto an RLC UM entity use either a 12-bit SN or a
7-bit SN. Parameter pdcpPduSnSize configures the size of the SN (and thus the
PDU format) used for U-Plane PDCP data PDUs mapped onto an RLC UM entity.
PdcpConf::pdcpPduSnSize
Parameter pdcpPduSnSize
Object ENBEquipment/Enb/DedicatedConf/PdcpConf
{auto, 7, 12} bits
Value See Table 30 in Section 5.3.2.2.6
Feature L34309
Page 175/222
5.3.2.2.1.2 C-PLANE PDCP DATA PDU
A C-Plane PDCP PDU is mapped on an SRB and carries an RRC signaling

message. The appended header consists of 3 1-bit reserved fields and a 5-bit SN. A
trailer field MAC-I (Message Authentication Code) is also appended to support RRC
message integrity protection.
Figure 56 shows the C-Plane PDCP data PDU format. Information on the use of the
MAC-I octets can be found in Section 5.3.2.8.
R R R PDCP Sequence Number Oct 1
Data Oct 2
...
MAC-I Oct N-3
MAC-I (cont.) Oct N-2
MAC-I (cont.) Oct N-1
MAC-I (cont.) Oct N
Figure 56 : C-Plane PDCP data PDU format
5.3.2.2.2 PDCP CONTROL PDU

A PDCP control PDU is not associated to an SDU. It is either a RoHC control packet
or a PDCP status report packet.
The RoHC control PDU carries the interspersed RoHC feedback packets to the peer
RoHC entity for the purpose of RoHC control.
The status report PDU is used to report the status of the PDCP SDUs received
during Handover (HO).
5.3.2.2.3 PDCP SDU DISCARD TIMER PARAMETER

The following table gives the QoS Class Index (QCI) values that are standardized by
3GPP. Each index specifies the standard combination of priority, (layer 2) Packet
Delay Budget and Packet Error Loss Rate. This reduces the number of profiles that
the eNB must support.
Page 176/222
Packet Packet
Resource Delay Error Loss
QCI Priority Example Services
Type Budget Rate
(NOTE 1) (NOTE 2)
1 -2
2 100 ms 10 Conversational Voice
(NOTE 3)
2 -3
4 150 ms 10 Conversational Video (Live Streaming)
(NOTE 3)
GBR
3 -3
3 50 ms 10 Real Time Gaming
(NOTE 3)
4 -6
5 300 ms 10 Non-Conversational Video (Buffered Streaming)
(NOTE 3)
5 -6
1 100 ms 10 IMS Signaling
(NOTE 3)
Video (Buffered Streaming)
6 -6
6 300 ms 10 TCP-based (e.g., www, e-mail, chat, ftp, p2p file
(NOTE 4)
sharing, progressive video, etc.)
Voice,
7 Non-GBR -3
7 100 ms 10 Video (Live Streaming)
(NOTE 3)
Interactive Gaming
8 -6 Video (Buffered Streaming)
8 300 ms 10
(NOTE 5) TCP-based (e.g., www, e-mail, chat, ftp, p2p file
9
9 sharing, progressive video, etc.)
(NOTE 6)
NOTE 1: A delay of 20 ms for the delay between a PCEF and a radio base station should be subtracted from a given PDB
to derive the packet delay budget that applies to the radio interface. This delay is the average between the case
where the PCEF is located "close" to the radio base station (roughly 10 ms) and the case where the PCEF is
located "far" from the radio base station, e.g. in case of roaming with home routed traffic (the one-way packet
delay between Europe and the US west coast is roughly 50 ms). The average takes into account that roaming is a
less typical scenario. It is expected that subtracting this average delay of 20 ms from a given PDB will lead to
desired end-to-end performance in most typical cases. Also, note that the PDB defines an upper bound. Actual
packet delays - in particular for GBR traffic - should typically be lower than the PDB specified for a QCI as long as
the UE has sufficient radio channel quality.
NOTE 2: The rate of non-congestion related packet losses that may occur between a radio base station and a PCEF should
be regarded to be negligible. A PELR value specified for a standardized QCI therefore applies completely to the
radio interface between a UE and radio base station.
NOTE 3: This QCI is typically associated with an operator controlled service, i.e., a service where the SDF aggregate's
uplink / downlink packet filters are known at the point in time when the SDF aggregate is authorized. In case of E-
UTRAN this is the point in time when a corresponding dedicated EPS bearer is established / modified.
NOTE 4: This QCI could be used for prioritization of specific services according to operator configuration.
NOTE 5: This QCI could be used for a dedicated "premium bearer" (e.g. associated with premium content) for any
subscriber / subscriber group. Also in this case, the SDF aggregate's uplink / downlink packet filters are known at
the point in time when the SDF aggregate is authorized. Alternatively, this QCI could be used for the default
bearer of a UE/PDN for "premium subscribers".
NOTE 6: This QCI is typically used for the default bearer of a UE/PDN for non-privileged subscribers. Note that AMBR can
be used as a "tool" to provide subscriber differentiation between subscriber groups connected to the same PDN
with the same QCI on the default bearer.
Table 29: 3GPP QCI Table

This table is extracted from [R13].
In the UL, when a PDCP Service Data Unit (SDU) (upper layer packet) is received,
the PDCP layer buffers it and starts a timer while waiting for a transmission
opportunity on the air interface. When the timer expires, the SDU is discarded so that
the Packet Delay Budget is met.
pdcpDiscardTimer: This parameter configures the UE’s PDCP discard timer when
setting up DRBs. If the value is set to “infinity,” the UE does not perform PDCP
discard.
Page 177/222
PdcpConf::pdcpDiscardTimer
Parameter pdcpDiscardTimer
[ 50ms, 100ms, 150ms, 300ms, 500ms, 750ms, 1500ms,
infinity ] milliseconds
Value O.D., See Engineering Recommendation in Table 30
Feature
5.3.2.2.4 PDCP SDU SIZE

In earlier releases, a PDCP SDU size of 2 kilobytes has been supported. In the
March, 2009, 3GPP standard, a maximum size of 8 kilobytes (8192 bytes) is
specified. This maximum SDU size capability is permanently supported by all
aspects of the system (i.e., PDCP, RLC, and transport) for both user plane and
control plane SDUs.
5.3.2.2.5 HANDOVER-RELATED PDCP PARAMETERS

Define the following variables:
Next_PDCP_TX_SN: This variable indicates the next expected PDCP PDU
sequence number by the transmitter for a given PDCP entity. At establishment of the
PDCP entity the Next_PDCP_TX_SN is set to 0, or to a specific number in case of
HO.
Next_PDCP_RX_SN: This variable indicates the next expected PDCP PDU

sequence number by the receiver for a given PDCP entity. At establishment of the
PDCP entity the Next_PDCP_RX_SN is set to 0, or to a specific number in case of
HO.
During handover, there may be duplicated PDCP SDUs at the target eNB in the
uplink. Indeed, when the target eNB is configured not to send the DL PDCP status
report, the UE may retransmit the SDUs that have SNs less than the Last In
Sequence (LIS) sent from the source eNB. Also, even if the target eNB is configured
to send the DL status report, there is no guarantee that the UE will not do so or that
the status report will not be lost. Whether or not the status report is enabled is
determined by the setting of the pdcpStatusReportEnable parameter.
Page 178/222
PdcpConf::pdcpStatusReportEnable
Parameter pdcpStatusReportEnable
TRUE, FALSE
Value O.D., See Engineering Recommendation in Table 30
Feature L76500
Therefore, duplication detection is needed in the target eNB UL to eliminate such

PDUs. For this purpose, radio bearers mapped on RLC AM mode use a Window for
UL duplicate detection. The window ends at SN=Next_PDCP_RX_SN-1. So, any
PDCP PDU with an SN that falls into this window, i.e. prior to the next expected SN,
is considered as duplicate.
The size of this window is configured by parameter
pdcpUlDuplicateDetectionWindow.
PdcpConf::pdcpUlDuplicateDetectionWindow
Parameter pdcpUlDuplicateDetectionWindow
[0..4095]
Feature L76500
When it is ready to support handover, the target eNB sends a “Handover Request
ACK” message to the source eNB. If uplink Protocol Data Units (PDUs) arrive before
the X2 status message with the expected next uplink message serial number, then
the uplink PDUs are buffered.
The size of this buffer is defined by the pdcpUlTargetS1BufferCoefficients

parameter.
Page 179/222
TrafficRadioBearerConf::pdcpUlTargetS1BufferCoefficients
Parameter pdcpUlTargetS1BufferCoefficients
Kbytes)
SC = The ceiling of the buffer (maximum capped size), in
terms of number of packets
AP = Average packet (PDCP SDU) size, in terms of bytes

See the Engineering Recommendation provided below ALU
Value
recommends that the operator not change these values
Feature L97014

TrafficRadioBearerConf::pdcpUlTargetS1BufferCoefficients
Traffic Radio SF SC T WQ AP
Bearer QCI
GBR-1 10 80 1000 100 72
GBR-2 20 500 1000 100 500
GBR-3 50 1000 1000 100 300
GBR-4 20 800 1000 100 500
NonGBR-5 20 800 1000 100 500
NonGBR-6 20 800 1000 100 500
NonGBR-7 20 800 1000 100 500
NonGBR-8 20 800 1000 80 500
NonGBR-9 20 800 1000 60 500
Page 180/222
5.3.2.2.6 PDCP PARAMETERS ENGINEERING RECOMMENDATIONS

The recommended value of PDCP parameters that require different values for
different radio bearers are indicated in this section.
Engineering Recommendation: Parameters QCI, pdcpDiscardTimer,

pdcpStatusReportEnable and pdcpPduSnSize setting
Parameter
Traffic Radio pdcpDiscard pdcpStatus
Bearer QCI Timer ReportEnable pdcpPduSnSize
GBR-1 100 TRUE 7
GBR-2 150 TRUE 12
GBR-3 50 TRUE 12
GBR-4 300 TRUE 12
nGBR-5 Infinity TRUE 12
Table 30 : PCDP Parameter Values for Traffic Radio Bearer QCIs
5.3.2.2.7 LOSSLESS HANDOVER AND PDCP DATA FORWARDING

In an LTE network, only hard handover is supported. There is no UMTS-like soft
handover so the UE will experience a hard session interruption during mobility. To
minimize data loss during HO, LTE introduced the data forwarding function, where
the source cell forwards the user data to the target cell during the HO period.
For intra-eNB HO, the data forwarding is done inside the eNB. For inter-eNB HO, the
data forwarding is done over the X2 interface. So the X2 U-Plane is exclusively used
for the X2 data forwarding purpose.
Data forwarding is optional. It can be supported for either DL or UL or both. In the
current ALU implementation, only DL data forwarding is supported.
Data forwarding is performed in the PDCP layer. To achieve lossless forwarding
without duplication of PDCP PDU retransmission over the air interface, the PDCP
layer has introduced PDCP control PDUs to support the SN status report.
Page 181/222
Data forwarding is configured by CallP. It can be configured per Radio Bearer (RB)
so data forwarding can be enabled or disabled per individual RB. Note that the UE is
not aware whether the eNB supports data forwarding or not.
Finally note that lossless data forwarding only applies to RLC AM RBs. For RLC UM
RBs, data forwarding is still performed for the DL, but the data forwarding is not
lossless.
In order to support lossless downlink data forwarding, buffers are established in the
source eNB and the target eNB.
As discussed in Section 5.2.2.1.1, an adaptive buffer dimensioning approach allows
each PDCP buffer to have a buffer length that is appropriate to the specific RB and
bit rate. Instead of the system_restricted length buffer that was used for each RB in
earlier releases, the buffer length is configured based on each RB’s perceived data
rate and QoS weighting when the RB is established. The calculations used are as
follows:
The buffer size = Min [(SF + SA), SC]
Where:
SF = The base size (floor or minimum size of the buffer in Kbytes)

SC = The ceiling of the buffer (maximum capped size), in terms of number of
packets
SA = The adaptive buffer size (in number of packets) given by the following
formulas:
For GBR bearers: SA = Ceil [(GBR*T* WQ)/(8*AP)]
For Non-GBR bearers: SA = Ceil [(AMBR*T* WQ)/(8*AP)]

The Ceil function means round up to the nearest integer
GBR or AMBR = The RB’s data rate in units of kbps.
WQ = The QoS weighting factor (0 to 100%). For GBR RBs, this normally
should be set to 100%. Note that this value is entered as an integer in
the range 0 – 100, and is then divided by 100 by the system for use in
the formula.
AP = The average packet size in bytes
Configuration parameters are provided to define the length of the source eNB buffers
with parameters pdcpDlLosslessBufferCoefficients and
pdcpDlSourceS1BufferCoefficients, and the length of time that a packet can
remain in the buffer with parameter pdcpDlLosslessBufferLife. In addition, buffers
are provided at the target eNB for S1 and X2 packets, so they can be properly
sequenced. The lengths of these buffers are calculated from parameters
pdcpDlTargetS1BufferCoefficients and
pdcpDlTargetDataForwardingBufferCoefficients.
Page 182/222
TrafficRadioBearerConf:: pdcpDlLosslessBufferCoefficients
Parameter pdcpDlLosslessBufferCoefficients

Kbytes)
SC = 4096 Packets
See the Engineering Recommendation provided below ALU

Value
recommends that the operator not change these values
Feature L97014

TrafficRadioBearerConf::pdcpDlLosslessBufferCoefficients
QCI Value SF T WQ AP
GBR-1 10 2000 100 72
GBR-2 100 2000 100 500
GBR-3 100 1000 100 300
GBR-4 100 3000 100 500
nonGBR-5 100 3000 100 500
nonGBR-6 100 3000 100 500
nonGBR-7 100 3000 100 300
nonGBR-8 100 3000 80 500
nonGBR-9 100 3000 60 500
Page 183/222
PdcpConf::pdcpDlLosslessBufferLife
Parameter pdcpDlLosslessBufferLife
[0..15000] milliseconds, step 10
Feature L76500
TrafficRadioBearerConf::pdcpDlSourceS1BufferCoefficients
Parameter pdcpDlSourceS1BufferCoefficients
Kbytes)

See the Engineering Recommendation provided below
Value
Feature L97014
Page 184/222

TrafficRadioBearerConf::pdcpDlSourceS1BufferCoefficients
QCI Value SF SC T WQ AP
GBR-1 10 200 3000 100 72
GBR-2 20 1000 2000 100 500
GBR-3 50 1000 1000 100 300
GBR-4 20 1000 3000 100 500
nonGBR-5 20 1000 3000 100 500
nonGBR-6 100 1000 3000 100 500
nonGBR-7 100 1000 3000 100 300
nonGBR-8 100 1000 3000 80 500
nonGBR-9 100 1000 3000 80 500
TrafficRadioBearerConf::pdcpDlTargetS1BufferCoefficients
Parameter pdcpDlTargetS1BufferCoefficients
Kbytes)

Value
Feature L97014
Page 185/222

TrafficRadioBearerConf::pdcpDlTargetS1BufferCoefficients
Radio Bearer SF SC T WQ AP
LabelID
GBR-1 10 200 3000 100 72
GBR-2 20 1000 2000 100 500
GBR-3 50 1000 1000 100 300
GBR-4 20 2000 3000 100 500
NonGBR-5 20 2000 3000 100 500
NonGBR-6 100 5000 3000 100 500
NonGBR-7 100 3000 3000 100 300
NonGBR-8 100 5000 3000 80 500
NonGBR-9 100 4000 3000 60 500
TrafficRadioBearerConf::pdcpDlTargetDataForwardingBufferCoefficients
Parameter pdcpDlTargetDataForwardingBufferCoefficients
Kbytes)

Value
Feature L97014
Page 186/222

TrafficRadioBearerConf::
pdcpDlTargetDataForwardingBufferCoefficients
Radio Bearer SF SC T WQ AP
QCI
GBR-1 10 200 3000 100 72
GBR-2 20 1000 2000 100 500
GBR-3 50 1000 1000 100 300
GBR-4 20 2000 3000 100 500
NonGBR-5 20 2000 3000 100 500
NonGBR-6 100 5000 3000 100 500
NonGBR-7 100 3000 3000 100 300
NonGBR-8 100 5000 3000 80 500
NonGBR-9 100 4000 3000 60 500
When the source eNB receives an X2-AP message “Handover Request ACK” from
the target eNB, then the source eNB triggers its RLC layer to send an internal RLC
end marker packet along the data path to the PDCP layer. The RLC end marker
packet indicates the downlink packets that were successfully acknowledged by the
UE. When this request is made, “timerRLCEndMarker” is started. If the RLC end
marker packet is received before the timer expires, then acknowledged packets are
removed from the source eNB lossless buffer, and the remaining packets are
transferred over the X2 interface to the target eNB. The duration of the
“timerRLCEndMarker” is controlled by the timerRlcEndMarker parameter.
PdcpConf::timerRlcEndMarker
Parameter timerRlcEndMarker
[1.. 100] milliseconds, step 1
Feature L76500
5.3.2.3 PDCP DOWNLINK DUPLICATE AVOIDANCE FOR OVER THE

AIR TRANSMISSION
An optional capability is provided that adds the option of waiting for a PDCP status
report before the target cell/eNB begins transmitting, to avoid duplicated
Page 187/222
transmissions Over the Air (OTA). This capability only applies to PDCP instances
that are mapped on RLC-AM DRBs, and the UE must be configured to provide status
reports. The capability applies to all types of handover – intra-eNB and inter-eNB and
X2 or S1 based.
The PDCP Downlink Duplicate Avoidance for OTA Transmission capability is
enabled by setting the value of the dlPdcpDuplicateAvoidanceEnabled parameter
equal to True and enabling PDCP status reports. Although this capability is only used
for PdcpConf instances that are mapped on RLC-AM DRBs, it is ignored for
PdcpConf instances for which status reports are not enabled (e.g., PdcpConf
instances that are mapped to RLC-UM DRBs). As a result, it can just be set equal to
True for all PdcpConf instances unless it is desired to disable the capability for RLC-
AM DRBs.
PdcpConf::dlPdcpDuplicateAvoidanceEnabled
Parameter dlPdcpDuplicateAvoidanceEnabled
True or False
Value True
Feature L109433
If the PDCP Downlink Duplicate Avoidance for OTA Transmission capability is

enabled, then when a Handover Complete message (RRC connection
reconfiguration message) is received at the target cell, a timer is started and runs
until the PDCP status report is received from the UE or until the timer expires –
whichever occurs first. The duration of the timer is determined by the value of the
timerPdcpStatusReportWait parameter.
If the status report is received from the UE before the timer expires, the
timer is cancelled and PDCP transmits the remaining (unacknowledged)
packets to RLC.
If the timer expires, the PDCP layer immediately transmits the data it is
holding to RLC.
Page 188/222
PdcpConf::timerPdcpStatusReportWait
Parameter timerPdcpStatusReportWait
Range & Unit Integer, Milliseconds
1 to 1500, Step 1
Value 50 ms
Feature L109433
5.3.2.4 RLC-PDCP FLOW CONTROL
The RLC-PDCP flow control feature (FRS 97014) operates between the RLC and
PDCP processing entities in the DL only. The PDCP mechanism for detecting RLC
congestion is implemented directly in the data path (rather than in the control plane)
to reduce the flow control latency. The RLC portion of the RLC-PDCP Flow Control
feature is described in Section 5.2.2 and is enabled by an activation parameter (also
described in Section 5.2.2).
When this feature is enabled, then in the eNB DL User Plane processing, traffic data
normally is buffered in two places: a PDCP buffer and an RLC buffer. As described in
Section 5.3.2.2.7, the PDCP buffer is required to support handover, and it holds the
packets that have been processed by PDCP and transmitted to RLC to prepare for
the data forwarding from either source cell to target cell, or from source eNB to the
target eNB. The RLC buffer is required to hold the DL PDCP PDUs waiting for the
transmission scheduling opportunity that MAC layer signals.
Prior to the introduction of the RLC-PDCP Flow Control feature, and when the
feature is not enabled, when lossless handover is not in progress the PDCP layer
processes the SDUs “On-The-Fly” without any delay or buffering. All the PDCP
PDUs are buffered in the RLC SDU buffers waiting to be scheduled. If the DL data
injection rate has a large burst or is constantly high (e.g., UDP flow) and the data
rate exceeds the air link sustained rate, the RLC buffer may overflow very quickly
and constantly, causing a large loss of PDCP PDUs. For TCP applications, a large
loss of data can also occur if there are long periods of air link congestion and a large
TCP window (long round trip time) is used.
When ciphering is enabled between the PDCP sender and receiver (see Section
5.3.2.7), there is a restriction on the maximum number of consecutive lost PDCP
data PDUs which is half of the PDCP Hyper Frame size (see the pdcpPduSnSize
parameter in Section 5.3.2.2.1.1). Each hyper frame is identified by a Hyper Frame
Number (HFN). The frame size is 128 when the PDCP sequence number is 7 bits,
and 4096 when the PDCP sequence number is 12 bits (this is set for each RB
according to Table 30 in Section 5.3.2.2.6. If lost PDUs are more than half of the
hyper frame maximum number, the HFN will be desynchronized between UE and
Page 189/222
eNB, causing deciphering failure (deciphering requires the same HFN being used by
UE and eNB). Figure 57 illustrates this RLC flow overload problem.
PDCP SDU To UE Apps PDCP SDU From S1U GTP -U

PDCP decipher needs the
same SN and HFN
PDCP
SDU buffer
PDCP processing
(detach SN, PDCP cipher input
recover HFN, includes SN and HFN
PDCP processing
deciphering etc.) (attach SN, ciphering etc.)
PDCP Data PDU PDCP Data PDU
If RLC discards > ½ (Max SN)

consecutive PDCP data PDUs, UE
will fail to recover HFN, hence fail
RLC SDU RLC SDU
For SN = 7, this would be > 64
RLC SDU buffer packets
RLC SDU buffer X
(Reordering) For SN = 12, this would be > 2048 Buffer overflow
RLC processing RLC processing
MAC/L1 scheduling/processing
UE eNB
Figure 57 : PDCP deciphering failure due to RLC buffer overflow
HFN desynchronization is detrimental, because once it occurs the radio bearer (RB)
will stop working and may not recover. RLC UM TRBs may recover after HO or RRC
connection re-establishment since the HFN/SN will be reset. However RLC AM
TRBs cannot recover since the HFN/SN continues in both ends until the RB is
released. To combat this, RLC-PDCP flow control is needed to stop PDCP
processing and transmitting when the RLC buffer is in danger of overflowing, and to
resume when the RLC buffer congestion clears.
On the U-Plane, the RLC layer sends buffer State Indication Packets (SIP), which
are compatible with the format for the RLC end marker packets. This SIP not only
provides the RLC congestion or buffer state indication, but also provides the precise
PDCP SN status in the RLC layer with indication of which PDUs have been
successfully received by the UE with combined UL and DL information. So when the
PDCP layer receives this packet, it can not only take flow control action, but it can
also perform PDCP buffer selective discard, which (before introduction of the flow
control capability) it only performed at handover.
Performing RLC-PDCP flow control in both RLC and PDCP layers benefits from a
“double-buffering” effect, in that when the air interface is congested, both RLC and
Page 190/222
PDCP buffers can be used for buffering to effectively double the available buffer
space. This improves the packet loss performance during traffic bursts.
This feature is implemented and it operates internal to eNB only - there is no impact
outside the eNB (UE, Uu, EPC).
The introduction of the RLC/PDCP Flow Control feature requires changes in both the
RLC and PDCP layers. The RLC changes are described in Section 5.2.2, and should
be reviewed before continuing with the details of PDCP flow control in the following
section.
5.3.2.5 PDCP REACTION TO RLC CONGESTION
PDCP flow control is enabled when the value of parameter

rlcPdcpFlowControlEnabled (see Section 5.2.2) is set equal to “true”. In this case,
the DL source S1 buffers are allocated for both AM and UM TRBs. In addition, for
AM TRBs, DL lossless buffers are also allocated. The sizes of these buffers are
determined using the calculations that are described in Section 5.3.2.2.6.
When a congestion indication is received from RLC (in a SIP), then PDCP stops
processing DL SDUs, freezes the lossless buffer for AM TRBs, and accumulates all
new DL PDCP SDUs in the Source S1 Buffer (S1 Fresh Buffer). This is referred to as
the “PDCP Pause” state. Note that accumulating the DL PDCP SDUs in the Source
S1 Buffer is similar to the handover process at the source cell for AM TRBs, but is a
new capability for UM TRBs.
When PDCP enters the pause state, it starts the PDCP pause timer (TP). The
duration of this timer is determined by the value of parameter
pdcpFlowControlTimerTp. If timer TP expires, then PDCP forces RLC to provide a
SIP that indicates its current flow control status.
When PDCP is in the Pause state and receives a SIP that indicates that congestion
has cleared, then it returns to the normal state and resumes processing SDUs in the
Source S1 Buffer first, then new S1 SDUs. The packet life timer is restarted for all
AM SDUs in the lossless buffer and for the just processed AM SDUs from the Source
S1 buffer that are entering the lossless buffer.
PdcpConf::pdcpFlowControlTimerTp
Parameter pdcpFlowControlTimerTp
10 to 30000 msec, Step 10 msec
Feature L97014
Page 191/222
5.3.2.6 PDCP FLOW CONTROL
PDCP flow control is performed on the DL Lossless Buffer when the buffer
occupancy exceeds a high threshold (pdcpLosslessBufferHigherThreshold).
Recall that the DL Lossless Buffer applies only to AM TRBs. When this high
threshold is exceeded:
The PDCP controller is notified of the congestion, and it prompts RLC to
provide a SIP with its current congestion status.
A congestion event trigger prohibit timer is started. The duration of this
timer is determined by the value of parameter
pdcpLosslessBufferCongestionEventTriggerProhibitTimer. While
this timer is running, another lossless buffer congestion event will not be
raised to the PDCP controller.
DL PDCP processing continues normally (including DL Lossless Buffer
maintenance)
If the packet life timer expires, then the associated packets will be
discarded.
If DL Lossless Buffer overflow occurs, then a First In, First Out (FIFO)
discard strategy is used.
When DL Lossless buffer occupancy falls below the high threshold value,
then the congestion event trigger prohibit timer is stopped, and normal
PDCP operation resumes.
If the congestion event trigger prohibit timer expires, another congestion
indication is sent to the PDCP controller, and the timer is restarted.
When PDCP receives a SIP from RLC for an AM RB, the SIP includes the First
Missing Sequence (FMS) and bitmap information. If the PDCP Lossless Buffer
occupancy is greater than the lower threshold
(pdcpLosslessBufferLowerThreshold), then the FMS and bitmap information is
used to perform selective discard of acknowledged PDCP packets from the
associated DL PDCP Lossless Buffer. Using this strategy helps to reduce the
probability of Lossless Buffer congestion and/or overflow.
DL PDCP Lossless Buffer congestion is expected to be a rare occurrence if the RLC

buffer size is much larger than the PDCP DL Lossless Buffer size.
Page 192/222
TrafficRadioBearerConf::pdcpLosslessBufferHigherThreshold
Parameter pdcpLosslessBufferHigherThreshold
0 to 100%
Value 80% ALU recommends that the operator not change this value
Feature L97014
TrafficRadioBearerConf::pdcpLosslessBufferLowerThreshold
Parameter pdcpLosslessBufferLowerThreshold
0 to 100%
Value 30% ALU recommends that the operator not change this value
Feature L97014
PdcpConf::pdcpLosslessBufferCongestionEventTriggerProhibitTimer
Parameter pdcpLosslessBufferCongestionEventTriggerProhibitTimer
1 to 3000 msec
Feature L97014
5.3.2.7 CIPHERING AND DECIPHERING
The purpose of ciphering is to protect user data and signaling data confidentiality
across the radio channels. If ciphering is selected, then it protects Radio Resource
Control (RRC) signaling, NAS signaling and User Plane (UP) packets. Ciphering is
an option for RRC signaling and for UP packets.
Page 193/222
Once ciphering is enabled, all UP packets on Data Radio Bearers (DRBs) and all
RRC messages on SRB1 and SRB2 are ciphered.
Three encryption algorithms are supported for NAS, RRC, and UP ciphering. They
are:
EEA0 Null ciphering algorithm
128-EEA1 SNOW 3G (works with a 128 bit input key)
128-EEA2 AES (works with a 128 bit input key)
UEs and eNBs implement the three encryption algorithms for both RRC signaling
and UP ciphering. Confidentiality protection is performed by the PDCP sublayer
based on the configuration provided by the upper layers: PDCP runs the encryption
algorithm selected by Layer 3 using the ciphering key that was also provided by
Layer 3.
UEs and MMEs implement the three encryption algorithms for NAS signaling
ciphering, and the ciphering is performed between these two entities.
The priority order of the ciphering algorithms is provided by a list that is specified by
the parameter SecurityConf::allowedCipheringAlgorithmList (see Section
5.3.2.8.2). Ciphering/deciphering can be disabled by only specifying EEA0 in the
parameter value.
5.3.2.8 VERIFICATION AND PROTECTION
The integrity protection function protects the integrity of signaling messages (not user
data) between the UE and the network. Integrity protection is performed by the
PDCP sublayer based on configuration information provided by Layer 3 (selection of
the algorithm to be run and derivation of keys to be used).
Two algorithms are supported for integrity protection:
128-EIA1 SNOW 3G
128-EIA2 AES
UEs and eNBs implement the two encryption algorithms for RRC signaling integrity
protection. Integrity protection is performed by the PDCP sublayer based on the
configuration provided by the upper layers: PDCP runs the encryption algorithm
selected by Layer 3 using the integrity protection key that was also derived by Layer
3.
UEs and MMEs implement the two integrity protection algorithms for NAS signaling
integrity protection, and the integrity protection function is performed between these
two entities.
The integrity protection algorithm computes a Message Authentication Code for
Integrity (MAC-I) based on the original data (prior to ciphering) and several input
parameters. The resulting MAC-I field is then appended to the Layer 2 PDCP PDU
before transmission as shown in Figure 56 in Section 5.3.2.2.1.2.
Page 194/222
At the receiving side, a comparable computation is performed on the received

message, and the computed value (XMAC-I) is compared to the MAC-1 field value in
the received message. If the two values agree, then the integrity of the received
signaling message is verified.
5.3.2.8.1 AS SECURITY FEATURE ACTIVATION AND DEACTIVATION

Access Stratum integrity protection is a mandatory capability as defined by 3GPP.
AS Confidentiality protection (ciphering) is an operator option. This capability can be
activated or deactivated by the selection of the encryption algorithm to be used
(selection of the Null ciphering algorithm deactivates the feature, while selection of
either the SNOW 3G algorithm or the AES algorithm activates AS Confidentiality
protection).
AS integrity protection and confidentiality protection must be implemented
simultaneously by UEs and multiple network elements.
5.3.2.8.2 CIPHERING AND INTEGRITY PROTECTION PARAMETERS

A parameter is provided to specify the list of ciphering algorithms that are allowed in
the eNB. The list is ordered from the highest priority to the lowest priority. If the list
only contains the eea0 algorithm (“null”), then ciphering is deactivated.
PlmnIdentity::allowedCipheringAlgorithmList
Parameter allowedCipheringAlgorithmList
Object ENBEquipment/Enb/PlmnIdentity
Range & Unit Enumerated List with 1 to 4 entries
[ eea0, 128-eea1, 128-eea2, 128-eea3]
Value 128-eea2, 128-eea1, eea0
Feature L92638
where:
EEA0 Æ Null ciphering algorithm

128-EEA1 Æ SNOW 3G (works with a 128 bit input key)
128-EEA2 Æ AES (works with a 128 bit input key)
128-EEA3 Æ ZUC (not supported for FDD)
Page 195/222
Engineering Recommendation: allowedCipheringAlgorithmList
If ciphering is to be disabled, then set this parameter value equal to eea0.

If ciphering is to be enabled, then set this parameter value equal to 128-eea2, 128-eea1, eea0
A parameter is provided to specify the list of integrity protection algorithms that are
allowed in the eNB. The list is ordered from the highest priority to the lowest priority
(with the exception of EIA0 as explained in the Engineering Recommendation).
PlmnIdentity::allowedIntegrityProtectionAlgorithmList
Parameter allowedIntegrityProtectionAlgorithmList
Range & Unit Enumerated List with 1 to 4 entries
[eia0, 128-eia1, 128-eia2, 128-eia3]
Value 128-eia2, 128-eia1
Feature L92638
Where:
EIA0 Æ Null Integrity Protection Algorithm
128-EIA1 Æ SNOW 3G
128-EIA2 Æ AES
128-EIA3 Æ ZUC (not supported for FDD)
Rule: Parameter allowedIntegrityProtectionAlgorithmList
At least one integrity protection algorithm must be specified.

In addition, EIA0 can be configured in the
allowedIntegrityProtectionAlgorithmList only when parameter
isIMSEmergencyCallAllowed is set to ‘True’, which enables IMS VoIP emergency
call support introduced by feature L103897.1.
Page 196/222
Engineering Recommendation: allowedIntegrityProtectionAlgorithmList
Inclusion of EIA0 in the allowedIntegrityProtectionAlgorithmList enables

unauthenticated UEs to make IMS VoIP emergency calls.
If parameter isIMSEmergencyCallAllowed is set to ‘True’ and the operator has a
regulatory requirement to support unauthenticated IMS VoIP emergency calls, then
‘eia0’ should be one of the configured algorithms in the list.
EIA0 can have any position in the list because unauthenticated UEs will only use
EIA0 and no other calls will use EIA0.
5.3.3 ROBUST HEADER COMPRESSION

Robust Header Compression (RoHC) is implemented at the PDCP layer as shown in
the PDCP architecture diagram in Figure 53. RoHC is used to improve VoIP capacity
by reducing the header size of VoIP packets as shown in Figure 58 below.
Figure 58: VoIP Frame when RoHC is used
When RoHC is used, IP packet streams flow from the Compressor to the
Decompressor inside a RoHC channel. One VoIP TRB is mapped to one RoHC UL
and one RoHC DL channel. In the eNB, the Compressor is used to compress the DL
data packet headers transmitted to the UE, while the Decompressor is used to
decompress the UL data packet headers received from the UE.
Page 197/222
Each RoHC channel may multiplex different IP packet streams, each of which is
compressed using a different RoHC profile. These different streams are each
identified with a different Context ID (CID). Each context is associated with a
different RoHC profile and compression algorithm corresponding to that profile.
RoHC profiles are defined in [R09], from which a subset has been adopted by 3GPP
for use in LTE networks. One VoIP TRB is mapped to one RoHC UL channel and
one RoHC DL channel. There are three different types of RoHC packets: data,
control, and feedback. These are explained in section 5.3.3.3.
Figure 59 illustrates the RoHC architecture.
As of LR13.1, the eNodeB supports the following subset of version 1 of 3GPP Rel. 8
RoHC profiles for VoIP:
0x0000 No compression, complaint with RFC 4995 or RFC3095/RFC4815
0x0001 RTP/UDP/IP, complaint with RFC 3095, RFC 4815
0x0002 UDP/IP RFC 3095, RFC 4815
Both IPv4 and IPv6 are supported for all of the above profiles.
Figure 59 : RoHC Architecture

When parameter isRohcAllowed is set to true, then RoHC is enabled. Otherwise,
RoHC is disabled. This parameter requires a licensing token managed by Feature
Licensing. It can be set to 'true' only if licensing tokens are available for feature
FRS110547.1 (refer to LPUG Volume 1 for details).
Page 198/222
ActivationService::isRohcAllowed
Parameter isRohcAllowed
True or False
Class/Source A--full-eNB-reset / system_restricted
Value True
Feature L110547.1
Parameter rohcMaxCid specifies the maximum CID number that can be used for an
RoHC channel. Up to ‘rohcMaxCid + 1’ CIDs (contexts) can be created per TRB
that has RoHC activated. This parameter does not dictate the actual maxCID used,
but sets the upper limit. The number of CIDs actually used by the eNB and UE (set
in RRC IE PDCP-Config::maxCID) may be less than the ‘rohcMaxCID + 1’ limit.
TrafficRadioBearerConf::rohcMaxCid
Parameter rohcMaxCid
[1..8191]
Value 15
Feature L110547.1
Engineering Recommendation: rohcMaxCid
In LR13.1, RoHC is supported for VoIP only. A small CID with value <= 15 is
recommended for VoIP TRBs to minimize the RoHC overhead.
Parameter rohcProfiles selects the RoHC profiles enabled for eNB. It is used for the
input of PDCP RoHC profile configuration, as well as eNB input for RRC RoHC
profile configuration which also takes into account the UE capability.
This parameter is presented in a bit string format with a length of 9, with each bit
representing one of the 9 profiles defined in 3GPP [R06]. Profile 0x0000 is
compulsory when RoHC is enabled so it is not included in the bitmap. The
rohcProfiles bitmap also aligns with the RRC PDCP-configuration format as follows:
Bit 1: profile 0x0001 RTP/UDP/IP
Bit 2: profile 0x0002 UDP/IP
Bit 3: profile 0x0003 ESP/IP
Bit 4: profile 0x0004 IP
Bit 5: profile 0x0006 TCP/IP
Page 199/222
Bit 6: profile 0x0101 RTP/UDP/IP v2

Bit 7: profile 0x0102 UDP/IP v2
Bit 8: profile 0x0103 ESP/IP v2
Bit 9: profile 0x0104 IP v2
A bit set to "1" means that particular profile is enabled. A bit set to “0” disables the
profile. If RoHC profiles have been set to 0 for all bits, RoHC will be disabled for that
bearer.
TrafficRadioBearerConf::rohcProfiles
Parameter rohcProfiles
Range & Unit BitString
stringLength = 9
Feature L110547.1
Restriction: rohcProfiles
In LR13.1, only profiles 0x0000, 0x0001, and 0x0002, used for VoIP, are
supported. In addition, a WPS constraint requires that:
- For VoIP TRBs, this parameter must be set to 110000000. This setting enables
profiles 0x0001 and 0x0002, but the actual profiles in use are based on the
individual data streams created for the TRB.
- For other TRBs (non-VoIP), this parameter should be set to 000000000.
5.3.3.1 ROHC MODES
Each RoHC entity (Compressor or Decompressor) has three different modes:

1. U-mode (Unidirectional) - RoHC packets flow only in one direction from
Compressor to Decompressor. This mode is used under the following
circumstances: RoHC initialization, no feedback channel is available, the
Decompressor wishes to stay in U-mode, or non point-to-point RoHC
channels (broadcast/multicast, such as MBMS).
2. O-mode (Bidirectional Optimistic) - uses the feedback channel very sparsely

so RoHC control/feedback overhead is small. This mode is used when the
RoHC channel has good quality, so less packet loss/error and less feedback
are needed. This mode has the highest efficiency.
3. R-mode (Bidirectional Reliable) - uses the feedback channel more
extensively. It also operates a more robust RoHC context synchronization
mechanism between the Compressor and Decompressor to handle high
error rates. This mode is used when the RoHC channel is not of good
Page 200/222
quality, so frequent packet loss/error and frequent feedback is needed to

improve the reliability of RoHC operation.
Depending on the channel condition, the RoHC entities can transition between the
three modes. The transition is always triggered by the Decompressor via the
feedback packets, in which it indicates which mode the Decompressor and the
Compressor should stay in. Once the transition is done, the Compressor and
Decompressor stay in the same mode.
Figure 60 and Figure 61 show the mode transitions for the Compressor and
Decompressor, respectively.
Compressor
initialisation
U-Mode States
IR FO SO
Feedback (O) Feedback (U)
Feedback (U) Feedback (R)
O-Mode States Feedback (O) R-Mode States
IR FO SO IR FO SO
Feedback (R)
Figure 60 – RoHC Compressor Modes and Mode Transitions
Decompressor
initialisation
NC SC FC
Feedback (O) Feedback (U)
Feedback (U) Feedback (R)
O-Mode States Feedback (O) R-Mode States
NC SC FC NC SC FC
Feedback (R)
Page 201/222
Figure 61 – RoHC Decompressor Modes and Mode Transitions
Parameter rohcPreferredMode sets the preferred mode of the Decompressor.
RohcConf::rohcPreferredMode
Parameter rohcPreferredMode
Object ENBEquipment/Enb/DedicatedConf/RohcConf
{U-mode, O-mode, R-mode}
O-mode ALU recommends that the operator not change this
Value
value
Feature L110547.1
5.3.3.2 ROHC STATES
The RoHC states control how the RoHC mechanism operates on the RoHC flows.
The states for Compressor and Decompressor are different. They have no mapping
to each other. Each end operates independently in one of the three states, which is
determined by the RoHC flow characteristics, feedback and RoHC control logic.
5.3.3.2.1 COMPRESSOR STATES

The three Compressor states are:
IR (Initialization and Refresh) – initial state where complete header context is
sent to the decompressor in order to establish the RoHC context.
FO (First Order) - intermediate state to handle a dynamically changing RoHC
flow.
SO (Second Order) – desired state where the RoHC flow has a constant and
predictable pattern, and when the decompressor has completely established
the context.
The state transitions of the Compressor are based on the RoHC Mode. The state
machines for the U-mode, O-mode, and R-mode and are shown in Figure 62, Figure
63, and Figure 64, respectively.
Page 202/222
Compressor Compressor state

initialisation transitions in U-mode
IR state
n
sio
ci
de
St
Op
ate
ic
ut
ist
tim
eo
tim
im
tim
ist
pt
eo
O
ic
ut
ate
de
St
cis
ion
State timeout or update
FO state SO state
Optimistic decision
Figure 62 – Compressor State Transitions in U-Mode

Compressor state
IR state transitions in O-mode
CK
Op
rA
tim
no
Sta
ist
io
tic
K
cis
ic
AC
NA
de
de
cN
cis
ic
CK
ist
ati
ion
tim
St
or
Op
AC
K
NACK or update
ACK
FO state SO state
Optimistic decision or ACK
Figure 63 – Compressor State Transitions in O-Mode

Compressor state
IR state transitions in R-mode
Sta
tic
K
K
AC
AC
NA
AC
cN
CK
K
ati
St
NACK or update
ACK
FO state SO state
ACK
Figure 64 – Compressor State Transitions in R-Mode
Page 203/222
The following parameters are only applicable to Compressor states in U-Mode:

Parameter rohcIrRepeat specifies the maximum number of IR packets to send (in IR
state) in the U-mode. After these number of IR packets, the compressor will move to
higher states. The larger the number, the more conservative the compressor is.
RohcConf::rohcIrRepeat
Parameter rohcIrRepeat
[0..50]
Feature L110547.1
Parameter rohcFoRepeat specifies the maximum number of compressed packets to

send (in FO state) in the U-mode, before moving to SO state. The larger the number,
the more conservative the compressor is.
RohcConf::rohcFoRepeat
Parameter rohcFoRepeat
[0..50]
Feature L110547.1
Parameter rohcIrLimit specifies the maximum number of non-IR packets to send in

U-mode. After these number of non-IR packets, the compressor will move back to
the IR state. The larger the number, the greater the compression in U-mode
RohcConf::rohcIrLimit
Parameter rohcIrLimit
[0..5000] Step 10
Feature L110547.1
Page 204/222
Parameter rohcSoLimit specifies the maximum number of compressed packets to

send in SO state in U-mode. After this maximum number of packets, the compressor
will move down to FO state.
RohcConf::rohcSoLimit
Parameter rohcSoLimit
[0..5000] Step 10
Feature L110547.1
5.3.3.2.2 DECOMPRESSOR STATES
The three Decompressor states are:

NC (No Context) – initial state when the context is getting established, or
when the Decompressor has encountered K2 out of N2 decompression
failures, meaning decompression failure is severe. K2 and N2 are
configurable by data parameters rohcStateControlK2 and
rohcStateControlN2, respectively.
SC (Static Context) – intermediate state when the static (but not dynamic)
part of the context is established. This state is also entered when the
Decompressor has encountered K1 out of N1 decompression failures and
sends feedback to the Compressor to repair the context. K1 and N1 are
configurable data parameters rohcStateControlK1 and
rohcStateControlN1, respectively.
FC (Full Context) – desired state where the Decompressor has established
the full context of the RoHC flow. Normally the Decompressor should remain
in this state for most of the RoHC flow to reach optimum RoHC operation.
A RoHC entity transitions among its three states according to RoHC flow dynamics
and channel conditions. Modes and states operate independently. RoHC states
have no mapping to RoHC modes. Any mode supports all three states.
The state transitions of the Decompressor are shown in Figure 65
Page 205/222
No static Context
Decompressor state
transitions (for all
Decompressor
NC state U/O/R modes)
initialisation
De
co
e
ur
mp
ail
r
2f
es
fN
sio
to
n
su
ou
cc
K2
es
s
K1 out of N1 failure
SC state FC state
Decompression Success
No dynamic Context Decompression Success
Figure 65 – Decompressor State Transitions
The following parameters are only applicable to Decompressor states:
Parameter rohcStateControlK1 specifies the K1 value in FC to SC state transition.

When there are K1 decompression failures out of N1 total received data packets, the
decompressor shall move from FC to SC state. The values must meet the condition
of K1 <= N1.
RohcConf::rohcStateControlK1
Parameter rohcStateControlK1
[0..10]
Feature L110547.1
Parameter rohcStateControlN1 specifies the N1 value in FC to SC state transition.

When there are K1 decompression failures out of n1 total received data packets, the
decompressor shall move from FC to SC state. The values must meet the condition
of K1 <= N1.
Page 206/222
RohcConf::rohcStateControlN1
Parameter rohcStateControlN1
[0..10]
Feature L110547.1
Rule: Parameters rohcStateControlK1 and rohcStateControlN1
The value of parameter rohcStateControlK1 must be less than or equal to the

value of parameter rohcStateControlN1, such that K1 ≤ N1.
Parameter rohcStateControlK2 specifies the K2 value in SC to NC state transition.

decompressor shall move from SC to NC state. The values must meet the condition
of K2 <= N2.
RohcConf::rohcStateControlK2
Parameter rohcStateControlK2
[0..10]
Feature L110547.1
Parameter rohcStateControlN2 specifies the n2 value in SC to NC state transition.

decompressor shall move from SC to NC state. The values must meet the condition
of K2 <= N2.
Page 207/222
RohcConf::rohcStateControlN2
Parameter rohcStateControlN2
[0..10]
Feature L110547.1
Rule: Parameters rohcStateControlK2 and rohcStateControlN2
The value of parameter rohcStateControlK2 must be less than or equal to the

value of parameter rohcStateControlN2, such that K2 ≤ N2.
5.3.3.3 ROHC PACKETS
Inside a RoHC channel, any packet is a RoHC packet. In general these packets can
be classified into three types: data, control, and feedback.
1. Data: user IP data packet with the relevant header being compressed or
non-compressed, plus the RoHC protocol overhead. These packets form the
main part of the RoHC packet streams. The type of data packet depends on
the Profile, as well as the RoHC Mode and State.
2. Control: used to manage a RoHC context/session. These packets are
generated by the Compressor and transmitted to the Decompressor.
3. Feedback: used to handle the RoHC packet loss and error. These packets
are generated by the Decompressor and transmitted to the Compressor in
the RoHC feedback channel. Feedback packets can be sent as separate
standalone RoHC packets to the compressor, or piggybacked onto the
RoHC data packets sent in that direction. Both standalone and piggybacking
of feedback packets can be mixed depending on whether a data packet is
available.
Parameter rohcStandaloneFeedbackTimeout is used for the Compressor only.

When the Compressor receives a feedback packet from the associated
Decompressor, it waits for this timer to expire and then sends the feedback packet
as a standalone. Otherwise it piggybacks the feedback to a data packet if one is
available before this timeout.
Page 208/222
RohcConf::rohcStandaloneFeedbackTimeout
Parameter rohcStandaloneFeedbackTimeout
[0..500] ms
Feature L110547.1
The following parameters configure additional RFC 3095 characteristics of the RoHC
packets:
Parameter rohcRtpTimestampBasedCompression is used only for the
Compressor. Setting this parameter to ‘True’ enables RTP timestamp-based
compression as specified in RFC3095 [R09].
RohcConf::rohcRtpTimestampBasedCompression
Parameter rohcRtpTimestampBasedCompression
Object ENBEquipment/Enb/ DedicatedConf/RohcConf
True or False
Value
value
Feature L110547.1
Page 209/222
Parameter rohcSlidingWindowSize sets the sliding window size, in terms of

number of packets, for the Compressor for the Window-based Least Significant Bit
(W-LSB) encoding of compressible fields as specified in RFC3095 [R09].
RohcConf::rohcSlidingWindowSize
Parameter rohcSlidingWindowSize
[4..2048] Step 4
Feature L110547.1
5.4 SYNC LAYER (MBMS)

The SYNC protocol layer, defined by 3GPP in [R14], is used for MBMS user plane
management. It interfaces with the BM-SC in the core network over the M1 interface
to ensure that radio frames of a MBSFN are transmitted at exactly the same time.
The BM-SC provides a SYNC header for every packet it sends, which includes a
timestamp used by eNBs for packet scheduling as well as data for packet loss
detection. The role of the SYNC layer in the eNB is to process the SYNC header of
the incoming PDUs from the BM-SC and to map the MBMS bearer service flow to a
radio bearer and RLC logical channel ID. Refer to Volume 5 for the overview of
MBMS and Volume 4 for additional information on MBMS scheduling on MCH.
Figure 66 shows the SYNC protocol layer in the MBMS architecture.
UE eNB BM-SC
MBMS
Gateway
MBMS MBMS
packet packet
SYNC SYNC
RLC RLC
TNL TNL TNL
MAC MAC
PHY PHY M1
SYNC: Protocol to synchronise

data used to generate a certain
radio frame
Figure 66: SYNC protocol layer in the MBMS architecture

Page 210/222
Key concepts of the SYNC protocol are:
Sync sequence: a sequence of numbered packets for one MBMS bearer service to
be scheduled for transmission at the same SFN. The SFN at which the packets are
scheduled is derived from the BM-SC Timestamp, which is contained in the SYNC
header and may have a value between 0 and 60000-1 in unit multiples of 10 msec.
The BM-SC Timestamp should already take into account factors such as maximum
transmission delay from the BM-SC to the eNBs and the eNB processing time.
However, if there is an observed timing mismatch between the BM-SC and eNBs for
a particular bearer, parameter syncPeriodOffset is used to make a correction on
Timestamps.
Sync period: the period of time beginning with transmission of packets in the first
sync sequence (first timestamp) and ending with transmission of packets in the last
sync sequence (last timestamp). A synchronization period is defined per MBMS
bearer service. It is specified by parameter syncPeriodDuration. In LR13.1, this
parameter is system_restricted to 4096.
Sync PDU: supported types are:
Type 0: contains control information without a data payload. It contains the total
packet and octet count used for packet loss detection and signifies the end of an
individual sync sequence.
Type 1: contains service data and control information with uncompressed header.
Type 3: same as Type 0 PDU with the addition of the octet count of every packet
in the current sync sequence used for packet loss detection. It follows the Type 0
PDU at the end of an individual sync sequence. This PDU is optionally sent, as
determined by the implementation of the BM-SC.
Type 2 Sync PDU is not used by LTE.
Page 211/222
time time time

stamp stamp stamp time time
BM-SC
“first” “first+1”
... “n”
... stamp
“last–1”
stamp
“last”
transmission
eNB
... ...
transmission
func(timestamp, Sync sequences
syncPeriodOffset)
syncPeriodDuration = 4096 frames
Packet Number 2
PDU Type 1
Packet Number 1
PDU Type 1
Packet Number k
PDU Type 1
PDU Type 0
PDU Type 3
...... ......
Sync sequence for timestamp “n”
Figure 67: Transmission of Sync Sequences
MbmsBearerService::syncPeriodOffset
Parameter syncPeriodOffset
ENBEquipment/Enb/Mbms/MbmsServiceArea/MbmsBearerSe
Object
rvice
[0..4096] 10ms frames
Feature L115227
Page 212/222
Rule: Parameter syncPeriodOffset
All the eNBs must have the same value of syncPeriodOffset for a given bearer
service.
Engineering Recommendation: syncPeriodOffset
This parameter should be set to 0 unless the eNBs are unsynchronized with
one or several BM-SC, in which case this parameter is used to make a
correction on BM-SC Timestamps. When this parameter is changed for one
bearer on one cell, it must be changed on all the eNBs and all the cells that
are broadcasting this bearer.
Rule: Parameter syncPeriodOffset
When this parameter is changed for one bearer on one cell, it must be changed
on all the eNBs and all the cells that are broadcasting this bearer.
MbmsBearerService::syncPeriodDuration
Parameter syncPeriodDuration
ENBEquipment/Enb/Mbms/MbmsServiceArea/MbmsBearerSe
Object
rvice
[4096..4096] frames
Value 4096
Feature L115227
Based on the parameters in the SYNC Header (e.g. Timestamp, Packet Number,
Elapsed Octet Counter), the eNB is able to derive the timing for downlink radio
transmission and notice if any SYNC packets are lost during transmission from the
BM-SC to the eNB. The eNB is also able to know the size of the lost SYNC packet in
case a single SYNC packet is lost. Furthermore, the eNB may also be able to know
the sizes of each lost SYNC packet if multiple consecutive SYNC packets are lost.
Additionally the eNB is able to reorder the PDUs before passing them to RLC
processing, if needed.
At the end of each synchronization sequence, the BM-SC sends to the eNBs a user
data frame, which contains counter information including 'Total Number Of Packet
Counter' and 'Total Number Of Octet' without MBMS payload (transmitted in the
Page 213/222
Type 0 Sync PDU). This Total Counter frame implicitly marks the end-of-
sync.sequence. The Total Counter frame without payload may be repeated in order
to improve the reliability of the delivery to the eNBs.
In case the SYNC protocol delivers more data to the scheduler for an MCH than the
air interface can transport, the eNB must drop a packet, using the following
procedure:
• select the last bearer according to the order in the MCCH list with a SYNC
SDU available for dropping;
• for the selected bearer, drop the available SYNC SDU with the highest
Packet Number among the SYNC SDUs with the latest Timestamp.
A SYNC SDU is considered available for dropping when the eNB knows its size and
it has not been already dropped by the eNB.
Metrics are computed to determine the average percentage of lost packets and
excess packets per MTCH. An MBMS service alarm will be raised if either of the
following thresholds is exceeded for at least one bearer in the cell:
Percentage of lost packets ≥ mbmsPacketLossThrHigh
OR
Percentage of excess packets ≥ mbmsExcessDataThrHigh
This alarm will be cleared only if metrics fall below the following thresholds for all
bearers in the cell:
Percentage of lost packets < mbmsPacketLossThrLow
AND
Percentage of excess packets < mbmsExcessDataThrLow
LteCell::mbmsExcessDataThrHigh
Parameter mbmsExcessDataThrHigh
[0..100] %
Value 50
Feature L115227
Page 214/222
LteCell::mbmsExcessDataThrLow
Parameter mbmsExcessDataThrLow
[0..100] %
Value 25
Feature L115227
mbmsExcessDataThrLow is the alarm clearing threshold for the excess data ratio.
When all bearers are under this excess ratio threshold and have loss rates lower or
equal to mbmsPacketLossThrLow, the MBMS failure alarm is cleared.
Rule: Parameters mbmsExcessDataThrHigh, mbmsExcessDataThrLow
mbmsExcessDataThrHigh must be greater than mbmsExcessDataThrLow.
LteCell::mbmsPacketLossThrHigh
Parameter mbmsPacketLossThrHigh
[1..100] %
Value 5
Feature L115227
Page 215/222
LteCell::mbmsPacketLossThrLow
Parameter mbmsPacketLossThrLow
[0..99] %
Value 1
Feature L115227
Rule: Parameters mbmsPacketLossThrHigh, mbmsPacketLossThrLow
mbmsPacketLossThrHigh must be greater than mbmsPacketLossThrLow.
6 THE RADIO RESOURCE CONTROL LAYER

The RRC layer constitutes the layer 3 of the air interface in the C-Plane. It is
described very briefly in this section. More details can be found in [Vol. 5] for Call
Processing related aspects of the RRC layer, [Vol. 4] for Radio Call Admission
Control functionality of the RRC layer, and [Vol. 6] for Mobility aspects of the RRC
layer.
6.1 RRC SERVICES AND FUNCTIONS

The main services and functions of RRC are:
• Broadcast of System Information related to the non-access stratum (NAS).
• Broadcast of System Information related to the access stratum (AS).
• Paging.
• Establishment, maintenance and release of an RRC connection between the
UE and E-UTRAN including:
o Allocation of temporary identifiers between UE and E-UTRAN.
o Configuration of signaling radio bearer(s) for RRC connection.
• Security functions including key management.

• Establishment, configuration, maintenance and release of point to point
Radio Bearers.
• Mobility functions including:

Page 216/222
o UE measurement reporting.
o Handover.
o UE cell selection and reselection and control of cell selection and
reselection.
o Context transfer at handover.
• QoS management functions.
• UE measurement reporting and control of the reporting.
• NAS direct message transfer to/from MME from/to UE.
6.2 RRC STATES

RRC uses the following two states for the UE:
• The RRC_IDLE state, characterized by:
o No RRC context stored in the eNB.

o The UE has been allocated an id which uniquely identifies it in a
tracking area.
o Broadcast of system information.

o Paging.
o Cell re-selection mobility.
• RRC_Connected state, characterized by:

o UE has an E-UTRAN-RRC connection.
o UE has context in E-UTRAN.
o E-UTRAN knows the cell the UE belongs to.
o The Network can transmit and/or receive data to/from UE.
o Neighbor cell measurements.
Also, the Access Stratum (AS) provides reliable in-sequence delivery of NAS
messages in a cell. In eUTRAN, NAS messages are either concatenated with RRC
messages or carried in RRC without concatenation.
6.3 SYSTEM INFORMATION

System Information (SI) is divided into the MasterInformationBlock (MIB) and a
number of SystemInformationBlocks (SIBs):
Page 217/222
- MasterInformationBlock defines the most essential physical layer information of the

cell required to receive further system information.
- SystemInformationBlockType1 contains information relevant when evaluating if a
UE is allowed to access a cell and defines the scheduling of other system
information blocks.
- SystemInformationBlockType2 contains common and shared channel information.
- SystemInformationBlockType3 contains cell re-selection information, mainly related
to the serving cell.
- SystemInformationBlockType4 contains information about the serving frequency
and intra-frequency neighboring cells relevant for cell re-selection (including cell re-
selection parameters common for a frequency as well as cell specific re-selection
parameters).
- SystemInformationBlockType5 contains information about other E-UTRA
frequencies and inter-frequency neighboring cells relevant for cell re-selection
(including cell re-selection parameters common for a frequency as well as cell
specific re-selection parameters).
- SystemInformationBlockType6 contains information about UTRA frequencies and
UTRA neighboring cells relevant for cell re-selection (including cell re-selection
parameters common for a frequency as well as cell specific re-selection parameters).
- SystemInformationBlockType7 contains information about GERAN frequencies
relevant for cell re-selection (including cell re-selection parameters for each
frequency).
- SystemInformationBlockType8 contains information about CDMA2000 frequencies
and CDMA2000 neighboring cells relevant for cell re-selection (including cell re-
selection parameters common for a frequency as well as cell specific reselection
parameters).
- SystemInformationBlockType9 contains a home eNB identifier (HNBID).
- SystemInformationBlockType10 contains an ETWS primary notification.
- SystemInformationBlockType11 contains an ETWS secondary notification.
The MIB is mapped on the BCCH and carried on BCH while all other SI messages
are mapped on the BCCH and dynamically carried on DL-SCH where they can be
identified through the SI-RNTI (System Information RNTI). Both the MIB and
SystemInformationBlockType1 use a system_restricted schedule with a periodicity of
40 and 80 ms respectively while the scheduling of other SI messages is flexible and
indicated by SystemInformationBlockType1.
Note that regardless of their RRC state, the UEs are informed about a system
information change using a paging message. System Information may also be
provided to the UE by means of dedicated signaling e.g. upon handover.
Page 218/222
7 ANNEX – ABBREVIATIONS
Abbreviations that are specific to this volume are provided here. Abbreviations that
are common to multiple LPUG volumes are provided in Volume 1.
ACK Acknowledgement
AM Acknowledged Mode
AS Access Stratum
BTS Base Transceiver Station
CDD Cyclic Delay Diversity
C-RNTI Cell-Radio Network Temporary Identifier
DL Downlink
DRB Data Radio Bearer
DTCH Dedicated Traffic Channel
eNB E-UTRAN NodeB
FMS First Missing Sequence
GBR Guaranteed Bit Rate
GTP GPRS Tunneling Protocol
HARQ Hybrid ARQ
HFN HyperFrame Number
IP Internet Protocol
MAC-I Message Authentication Code for Integrity
MBMS Multimedia Broadcast/Multicast Service
MME Mobility Management Element
MTCH Multicast Traffic CHannel
MU-MIMO Multi-User MIMO
NA Not Applicable
NAS Non-Access Stratum
OD Operator Dependent
PDB Packet Delay Budget
PDCP Packet Data Convergence Protocol
Page 219/222

RFC Request for Comments
QCI QoS Class Identifier
QoS Quality of Service
RB Radio Bearer
RoHC Robust Header Compression
SAP Service Access Point
SDU Service Data Unit
SFBC Space Frequency Block Coding
SINR Signal to Interference plus Noise Ratio
SIP (RLC) State Indication Packet
SN Sequence Number
SU-MIMO Single User MIMO
TB Transport Block
TRB Traffic Radio Bearer
UDP User Datagram Protocol
UE User Equipment
UL Uplink
UP User Plane
Page 220/222
Z END OF VOLUME Y
Page 221/222
VOLUME 4 RADIO RESOURCE MANAGEMENT

FDD eNB LTE Parameters User Guide 09.05/EN 27-Sep-2013
LTE/DCL/APP/031078 EXTERNAL Preliminary 13.3, Standard 13.1
Volume 4 : Radio Resource Management

1 INTRODUCTION ..............................................................................................................................20
1.1 OBJECT ...................................................................................................................................20
1.2 SCOPE OF THIS VOLUME ...........................................................................................................20
1.3 RELATED FEATURES .................................................................................................................22

2.1 LPUG VOLUMES ......................................................................................................................28
2.3 PREREQUISITE FOR READING THIS VOLUME ...................................................................29
3 RADIO RESOURCE MANAGEMENT FUNCTIONS .......................................................................30

3.1 QUALITY OF SERVICE................................................................................................................30
3.1.1 LTE QoS architecture .......................................................................................................30
3.1.1.1 QoS management for CA activated UE .......................................................................31
3.1.2 QoS parameters................................................................................................................31
EnbRadioConf::enforceAMBRvalues.....................................................33
TrafficRadioBearerConf::qCI ..................................................................34
TrafficRadioBearerConf::qciGroup ........................................................34
TrafficRadioBearerConf::trafficRadioBearerConfName ......................34
TrafficRadioBearerConf::packetDelayBudget.......................................35
CarrierAggregationSecondaryConf::packetDelayBudget ...................35
TrafficRadioBearerConf::logicalChannelPriorityDL .............................35
CarrierAggregationSecondaryConf::logicalChannelPriorityDL ..........35
MbmsBearerService::qCI ........................................................................37
MbmsBearerService::guaranteedBitRate ..............................................38
3.1.2.1 Optimized segmentation for VoIP calls and MCS override..........................................38
ActivationService::isOptimizedSegmentationEnabled ........................38
CellL2ULConf::minNbrPRBForULDSVoIP .............................................40
CellL2ULConf::minTBsizeForOptSeg ....................................................43
CellL2ULConf::OptSegPuschSinrThresh ..............................................43
CellL2ULConf::bOcheckForOptSeg .......................................................43
CellL2ULConf::OverrideOptSegActivationTimer ..................................44
3.1.2.2 Bearer Characteristics online modifications.................................................................45
3.2 RRM FUNCTIONS .....................................................................................................................46
4 DYNAMIC RESOURCE ALLOCATION AND PACKET SCHEDULING.........................................47

4.1 UE CATEGORY 4 ......................................................................................................................49
ActivationService::isUeCategory4Allowed ...........................................51
4.2 FORCED DRX MANAGEMENT ..................................................................................................51
CellL1ULConf::cqiMaskR9 ......................................................................53
4.2.1 DRX Configuration and DRX mode Activation .................................................................54
4.2.2 DRX mode deactivation ....................................................................................................55
4.3 INACTIVITY BASED DRX MANAGEMENT ...........................................................................56
Page 1/472
ActivationService::isInactivityBasedDrxEnabled .................................59
InactivityBasedDrxConf::drxInactivityTimer .........................................59
InactivityBasedDrxConf::longDRXCycle ...............................................60
InactivityBasedDrxConf::onDurationTimer ...........................................60
InactivityBasedDrxConf::shortDRXCycle ..............................................60
InactivityBasedDrxConf::drxShortCycleTimer......................................61
InactivityBasedDrxConf::drxRetransmissionTimer .............................61
InactivityBasedDrxConf::trafficBasedContextReleaseTimer ..............61
InactivityBasedDrxConf::dlOnDurationPriorityBoost ..........................62
CarrierAggregationSecondaryConf::dlOnDurationPriorityBoostForCA
Bearer ................................................................................62
TrafficRadioBearerConf::isInactivityBasedDrxConfigured .................62
CellL1ULConf::srsSINRThresholdForReliableDetection .....................63
4.3.1 inactivity based DRX Configuration and DRX mode Activation ........................................64
4.3.2 DRX mode deactivation ....................................................................................................64
4.4 MEASUREMENT GAPS ...............................................................................................................65
4.5 DOWNLINK SCHEDULER .............................................................................................................67
DownlinkSemiPersistentSchedulingConf::spsInitialMCSIndexForBear
erSetupDl ...........................................................................70
DownlinkSemiPersistentSchedulingConf::numberOfConfSPSProcess
esDl ....................................................................................71
DownlinkSemiPersistentSchedulingConf::macHARQMaxNumberOfTr
ansmissionWithSPSDl .....................................................71
DownlinkSemiPersistentSchedulingConf::macHARQMaxTimerWithS
PSDl ...................................................................................72
DownlinkSemiPersistentSchedulingConf::spsLinkAdaptationSINROff
setDl ...................................................................................72
DownlinkSemiPersistentSchedulingConf::activityPeriodForSPSActiv
ationDl ................................................................................73
SignalingRadioBearerConf::sRBIdentity ...............................................73
SignalingRadioBearerConf::signalingRadioBearerConfName ...........73
TrafficRadioBearerConf::macInitialMCSIndexForBearerSetupDl .......74
SignalingRadioBearerConf::macInitialMCSIndexForBearerSetupDl ..74
TrafficRadioBearerConf::macMIMOModeDl ..........................................74
CarrierAggregationSecondaryConf::macMIMOModeDl .......................75
SignalingRadioBearerConf::macMIMOModeDl .....................................75
TrafficRadioBearerConf::macHARQMaxNumberOfTransmissionDl ..75
CarrierAggregationSecondaryConf::macHARQMaxNumberOfTransmi
ssionDl ...............................................................................76
SignalingRadioBearerConf::macHARQMaxNumberOfTransmissionDl76
TrafficRadioBearerConf::macHARQMaxTimerDl ..................................76
CarrierAggregationSecondaryConf::macHARQMaxTimerDl...............76
SignalingRadioBearerConf::macHARQMaxTimerDl ............................77
ActivationService::isSpsConfigAllowed................................................81
Enb::isUeRel8EligibleToSps ...................................................................82
FrequencyAndBandwidthFDD::resourceBlockPersistentAreaStart ...85
Page 2/472
FrequencyAndBandwidthFDD::resourceBlockPersistentAreaEnd ....85
4.5.1 Static Scheduler ................................................................................................................86
4.5.2 Semi-Static and Semi-Persistent Scheduler .....................................................................87
4.5.2.1 D-BCH scheduling .......................................................................................................87
4.5.2.1.1 SIB1,…, SIB8 scheduling .......................................................................................88
4.5.2.1.2 SIB1,…, SIB8 and SIB12 scheduling .....................................................................88
SysInfoConf::sib1TargetMCS .................................................................89
SysInfoConf::sibClass1TargetMCS ........................................................90
CellL2DLConf::resourceBlockShift ........................................................92
SysInfoConf::numberRBnotForSIB ........................................................92
4.5.2.2 RACH message 2 scheduling ......................................................................................93
CellRachConf::rachMsg2ForceMCSmin ................................................95
CellRachConf::rachMsg2StartRB ...........................................................95
CellRachConf::rachMsg2NumberOfRB .................................................96
CellRachConf::rachMsg2SpectralEfficiency .........................................97
4.5.2.3 PCCH scheduling.........................................................................................................97
CellL2DLConf::pagingForceMCSmin .....................................................98
CellL2DLConf::numberRBnotForPaging ...............................................98
4.5.2.4 SPS VoIP DTCH scheduling ........................................................................................99
DownlinkSemiPersistentSchedulingConf::spsActivationProhibitTime
UponCallSetupWithoutROHCDl ....................................100
UponCallSetupWithROHCDl ..........................................100
CellL2DLConf::maxResourceBlocksPerTTIToLimitSPSAllocation ..101
DownlinkSemiPersistentSchedulingConf::spsHARQProcessReuseFo
rDSWhenSPSReleased ..................................................102
DownlinkSemiPersistentSchedulingConf::spsAllocationType1Activati
on .....................................................................................103
DownlinkSemiPersistentSchedulingConf::spsAllocationType2Distrib
utedActivation .................................................................103
DownlinkSemiPersistentSchedulingConf::spsPdschPowerControlAct
ivation ..............................................................................103
DownlinkSemiPersistentSchedulingConf::spsPerPRBAllocationActiv
ation .................................................................................104
DownlinkSemiPersistentSchedulingConf::spsVoIPDataRateMonitorin
gActivation ......................................................................104
4.5.2.4.1 SPS activation ......................................................................................................104
DownlinkSemiPersistentSchedulingConf::maxSPSActivationAttempt
sDl ....................................................................................106
UponSPSFailureDl ..........................................................106
DownlinkSemiPersistentSchedulingConf::spsMACMultiplexingAllowe
d ........................................................................................107
DownlinkSemiPersistentSchedulingConf::spsHARQProcessReuseFo
rDSWhenSPSActivated ..................................................107
4.5.2.4.2 SPS Release ........................................................................................................107
Page 3/472
DownlinkSemiPersistentSchedulingConf::blerMaxVariationForSPSDl109
DownlinkSemiPersistentSchedulingConf::inactivityPeriodForSPSRel
easeDl ..............................................................................109
DownlinkSemiPersistentSchedulingConf::sinrMaxVariationforSPSDl110
CellL2DLConf::maxDopplerShiftForSPSDl .........................................110
CellL2DLConf::minSINRForSPSDl .......................................................110
DownlinkSemiPersistentSchedulingConf::maxSPSReleaseAttemptsD
l .........................................................................................111
UponSPSAbnormalReleaseDl .......................................111
4.5.2.5 Positioning Reference Signals scheduling.................................................................111
ActivationService::isOtdoaHearabilityEnhancementAllowed ...........113
PositioningReferenceSignals::prsNumSubframes ............................114
PositioningReferenceSignals::prsBandwidth .....................................114
PositioningReferenceSignals::prsConfigurationIndex ......................114
PositioningReferenceSignals::prsMutingPeriodicity .........................115
PositioningReferenceSignals::prsMutingSequence ..........................115
CellL2DLConf::isOtdoaCompatibleNeighborWithoutPrs ...................116
4.5.2.6 MCH scheduling .........................................................................................................116
MbsfnSubframeAllocationPattern::radioFrameAllocationPeriod .....118
MbsfnSubframeAllocationPattern::radioFrameAllocationOffset ......118
MbsfnSubframeAllocationPattern::oneFrame ....................................119
4.5.3 Dynamic Scheduler .........................................................................................................119
4.5.3.1 Transmission mode configuration ..............................................................................119
LteCellFDD::transmissionMode ...........................................................120
DownlinkCAConf::transmissionModeR10 ...........................................120
4.5.3.2 Downlink Dynamic scheduler operation mode determination....................................121
CellL2DLConf::maximumFSSUsers .....................................................122
CellL2DLConf::fDSOnly .........................................................................122
CellL2DLConf::minimumCQIForFSS ....................................................123
4.5.3.3 DL A-CQI list users Measurements processing .........................................................123
CellL1ULConfFDD::cqiReportingModeAperiodic ...............................124
CellRadioConf::aperiodicCQIrankAveragingCoefficient ...................128
CellRadioConf::periodicRIrankAveragingCoefficient ........................129
CodebookSubsetRestriction::n2TxAntennaTm4OneLayerCodebook0130
CodebookSubsetRestriction::n2TxAntennaTm4TwoLayersCodebook
1 ........................................................................................131
CodebookSubsetRestriction::n2TxAntennaTm4TwoLayersCodebook
2 ........................................................................................132
DownlinkMimo::dlMIMODefaultCodeBook ..........................................132
4.5.3.4 DL FD users Measurements processing ...................................................................132
4.5.3.4.1 CQI erasure and drop handling ............................................................................134
CellL2DLConf::dlPCQIValidityWindow ................................................135
CellL2DLConf::dlSINRDecayUponPCQIErasure .................................135
Page 4/472
4.5.3.5 Transmission Mode 3.................................................................................................135

DownlinkMimo::dlSinrThresholdBetweenOLMimoAndTxDiv ...........136
4.5.3.6 Transmission Mode 4.................................................................................................136
DownlinkMimo::dlSinrThresholdBetweenCLMimoTwoLayersAndOne
Layer ................................................................................138
DownlinkMimo::dlSinrThresholdBetweenCLMimoOneLayerAndTxDiv138
4.5.3.7 HARQ retransmissions scheduling ............................................................................138
4.5.3.8 Initial HARQ transmissions Scheduling .....................................................................139
CellL2DLConf::alphaFairnessFactor ....................................................140
4.5.3.8.1 QoS weight computation.......................................................................................140
TrafficRadioBearerConf::dlQCISchedulingWeight .............................140
CarrierAggregationSecondaryConf::dlCABearerSchedulingWeight141
ActivationService::isNonGBRMinRateEnabled ..................................144
TrafficRadioBearerConf::dlMinThroughputTarget .............................144
CarrierAggregationSecondaryConf::dlMinThroughputTarget ..........145
TrafficRadioBearerConf::dlQoSMetricType ........................................145
CarrierAggregationSecondaryConf::dlQoSMetricType .....................145
EnbRadioConf::dlNonGBRClippingFactor ..........................................146
EnbRadioConf::dlCABearerClippingFactor ........................................146
EnbRadioConf::dlActiveThroughputAverageCoefficient ..................146
EnbRadioConf:: dlActiveThroughputAverageCoefficientForCABearer147
EnbRadioConf::rabInactivityTimer .......................................................147
EnbRadioConf::caBearerInactivityTimer .............................................147
EnbRadioConf::marginForNonGbrMinRateEnforcement ..................148
EnbRadioConf::marginForCABearerMinRateEnforcement ...............148
4.5.3.8.2 RESOURCE BLOCK and Resource Block GROUP ALLOCATION ....................148
CellL2DLConf::fdsAllocationType1Activation ....................................151
CellL2DLConf::fdsAllocationType2DistributedActivation .................151
CellL2DLConf::fdsPerPRBAllocationActivation .................................152
CellL2DLConf::voIPAllocationType1Activation ..................................152
CellL2DLConf::voIPAllocationType2DistributedActivation ...............152
CellL2DLConf::voIPPerPRBAllocationActivation ...............................153
4.5.3.9 MCS allocation ...........................................................................................................153
CellRachConf::rachMsg4ForceMCSmin ..............................................154
TrafficRadioBearerConf::macOuterLoopBlerControlTargetBlerDl ...154
CarrierAggregationSecondaryConf::macOuterLoopBlerControlTarget
BlerDl ...............................................................................154
SignalingRadioBearerConf::macOuterLoopBlerControlTargetBlerDl155
CellRadioConf::cQIToSINRLookUpTable ............................................156
TrafficRadioBearerConf::macSINROffsetForLinkAdaptationDl ........156
CarrierAggregationSecondaryConf::macSINROffsetForLinkAdaptatio
nDl ....................................................................................156
SignalingRadioBearerConf::macSINROffsetForLinkAdaptationDl ...156
CellRadioConf::dlMCSTransitionTable ................................................157
4.5.3.10 SPS MCS and PRB allocation size determination .....................................................158
4.5.3.10.1 Determination of the MCS used for PRB allocation size determination MCSSPS .158
EnbVoipConf::overrideS1GBRinfoForVoIP .........................................162
Page 5/472
DownlinkSemiPersistentSchedulingConf::defaultCodecforVoIPServic
eDl ....................................................................................162
DownlinkSemiPersistentSchedulingConf::macRLCOverheadDl ......163
DownlinkSemiPersistentSchedulingConf::tBScombinationMethodSP
SDl ....................................................................................163
DownlinkSemiPersistentSchedulingConf::spsLinkAdaptationImprove
mentActivation ................................................................163
4.5.3.10.2 MCS Capping .......................................................................................................164
4.5.3.11 Carrier Aggregation....................................................................................................164
4.5.3.11.1 DL Dynamic Scheduler re-architecture.................................................................164
4.5.3.11.2 Link and rank adaptation on PCell and SCell .......................................................165
DownlinkCAConf::cqiReportAperiodicR10Enabled ...........................165
CarrierAggregationPrimaryConf::nbMaxCAConfiguredUePerPcell .166
DownlinkCAConf::aperiodicCSITriggerR10Trigger1 ..........................167
CarrierAggregationSecondaryConf::aperiodicCSIRankAveragingCoef
ficientForSCell ................................................................167
CarrierAggregationSecondaryConf::aperiodicCSISINRAveragingCoef
ficientForSCell ................................................................167
4.5.3.11.3 UL criterion for CA configuration and deconfiguration..........................................168
LteCell::spare10 .....................................................................................168
LteCell::spare10 .....................................................................................168
UplinkCAConf::uplinkLinkBudgetAlarmTriggerThresholdForCA.....169
UplinkCAConf::uplinkLinkBudgetAlarmClearanceThresholdForCA 169
UplinkCAConf::uplinkLinkBudgetAlarmTimeToClearForCA.............169
UplinkCAConf::uplinkLinkBudgetAlarmTimeToTriggerForCA .........170
UplinkCAConf::uplinkCAtriggerNotificationRepetitionTimer............170
4.5.3.11.4 Out of coverage detection on SCell ......................................................................170
DownlinkCAConf::numberOfCQI0ForSCellForOutOfCoverageDetectio
n ........................................................................................171
DownlinkCAConf::sCellDeactivationTimerR10 ...................................171
4.5.3.11.5 DL Dynamic UE Scheduling .................................................................................171
CarrierAggregationSecondaryConf::carrierCompensationFactor....172
CarrierAggregationSecondaryConf::maxNumberOfUEPreSelectedper
TTI ....................................................................................172
DownlinkCAConf::minTBSForSchedulingInSecondary .....................173
CarrierAggregationSecondaryConf::maxNumberOfUEScheduledPerT
TI .......................................................................................173
4.5.4 OCNS ..............................................................................................................................174
4.5.4.1 PDSCH OCNS ...........................................................................................................174
LteCell::loadTargetForOCNSonPDSCH ...............................................175
4.5.4.2 PDCCH OCNS ...........................................................................................................175
LteCell::loadTargetForOCNSonPDCCH ...............................................176
4.6 UPLINK SCHEDULER ...............................................................................................................176
4.6.1 Interference Coordination ...............................................................................................178
4.6.1.1 Fractional Frequency Reuse ......................................................................................179
4.6.1.2 Soft Fractional Frequency Reuse ..............................................................................180
4.6.1.3 PRB EXClusion in PUSCH Dynamic scheduling and wideband SRS/Noise
calculations 180
4.6.2 RACH Region avoidance ................................................................................................181
Page 6/472
CellL2ULConf::puschSinrBackoffOnRachRegion ..............................182
4.6.3 L1 measurements processing .........................................................................................182
EnbRadioConf::energyMetricSelect .....................................................182
EnbRadioConf::noiseVarianceMetricSelect ........................................183
L1MeasurementConf::L1NoiseAveragingCoefficient .........................183
L1MeasurementConf::l1SpeedCFOandSignalPowerAveragingCoeffici
ent ....................................................................................184
L1MeasurementConf::l1TimingAdvanceAveragingCoefficient .........184
EnbRadioConf::noisePowerAveragingCoefficientForULMIMO.........185
4.6.3.1 Processing of PUSCH reports ...................................................................................185
4.6.3.2 Processing of PUCCH reports ...................................................................................185
CellRadioConf::pUCCHFormat1xDMRSpowerAveragingCoefficient185
CellRadioConf::pUCCHFormat2xDMRSpowerAveragingCoefficient186
4.6.3.3 Processing of Sounding Reference Signal reports ............................................................186
CellRadioConf::pathLossAveragingCoefficient..................................186
4.6.3.3.1 Update of the SINR metric used for Uplink Sync detection ..................................186
CellRadioConf::sRSpowerForULSyncAveragingCoefficient.............187
4.6.3.3.2 Update of the SINR metric used for PUSCH power control .................................187
CellRadioConf::pUSCHsinrAveragingCoefForDSpowerCtrl .............187
CellRadioConf::pUSCHsinrAveragingCoefForSPSpowerCtrl ...........188
ULPowerControlConf::isPUSCHSinrConvergenceSpeedUpEnabled188
ULPowerControlConf::puschSinrConvergenceSpeedUpThresh ......188
4.6.4 Uplink synchronization monitoring ..................................................................................189
CellRadioConf::ulSyncSINRsyncToOOSThreshold ...........................189
CellRadioConf::ulSyncSINROOStoSyncThreshold ............................189
4.6.5 Static scheduler ..............................................................................................................190
CellRachConfFDD::rACHMessage3NumberOfPRBs ..........................191
CellRachConf::rACHMessage3StartingPRBIndex ..............................191
CellRachConf::rACHMessage3MCSIndex ...........................................192
CellRachConfFDD::cfRACHMessage3NumberOfPRBs .....................193
4.6.6 Semi-Persistent Scheduler .............................................................................................193
EnbVoipConf::defaultCodecforVoIPServiceUl ....................................194
EnbVoipConf::activeToInactiveSpeechThresholdUl ..........................194
EnbVoipConf::speechActivityObservationWindow ...........................195
EnbVoipConf::inactiveToActiveSpeechthresholdUl ..........................195
EnbVoipConf::inactiveToActiveSpeechBSRthresholdUl...................196
EnbVoipConf::sIDframeDetectionThresholdUl ...................................196
4.6.6.1 Determination of Uplink SPS grant MCS and TBS ..........................................................196
CellL2ULConf::nominalMCSforSPSgrantsUl ......................................196
EnbVoiPConf::tBScombinationMethodUl............................................197
CellL2ULConf::isOnePRBMCS6forUplinkSPSgrantsAllowed ...........197
CellL2ULConf::onePRBMCS6forUplinkSPSgrantsminTBsize...........197
4.6.6.2 Uplink SPS activation ...................................................................................................198
UplinkSemiPersistentSchedulingConf::maxSPSgrantActivationQueue
SizeUl ...............................................................................198
UplinkSemiPersistentSchedulingConf::maxSPSgrantTxCountUL ...198
UplinkSemiPersistentSchedulingConf::maxVoIPdataRateForSPSactiv
ationUl ..............................................................................199
Page 7/472
CellL2ULConf::onePRBMCS6forUplinkSPSgrantsSINRthreshold....199
4.6.6.3 Uplink SPS Release ......................................................................................................199
UplinkSemiPersistentSchedulingConf::sPSactivationProhibitTimeUp
onSPSfailureUl ................................................................200
4.6.6.4 SPS grant activation / SPS grant release (Re)transmission scheduling ...............................200
CellL2ULConf::isDynamicManagementOfSPSresourceEnabled ......201
CellL2ULConf::sPSprioMetricTableMaskStartPositionUl ..................201
CellL2ULConf::sPSprioMetricTableMaskStopPositionUl ..................202
CellL2ULConf::sPSprioMetricTableMaskThresholdUL ......................202
CellL2ULConf::sPSprioMetricTableMaskThresholdUL ......................203
4.6.7 Dynamic scheduler .........................................................................................................204
CellL2ULConf::ulSchedPropFairAlphaFactor .....................................205
CellL2ULConf::doNotForceVoIPusersToLowerBler ...........................207
CellRadioConf::uEFailureReportRepetitionTimer ..............................207
4.6.7.1 TTI Bundling for VoIP.................................................................................................207
ActivationService::isTTIBundlingForVoIPEnabled.............................208
TTIBundlingConf::maxHARQtxTTIbundling ........................................208
TTIBundlingConf::uplinkLinkBudgetAlarmTriggerThreshold ...........210
TTIBundlingConf::uplinkLinkBudgetAlarmTimeToTrigger ...............210
TTIBundlingConf::ttiBundlingActivationBLERthresh ........................211
TTIBundlingConf::ttiBundlingBLERmeasurementPoints ..................212
TTIBundlingConf::ttiBundlingBLERwindowSize ................................212
TTIBundlingConf::maxULVoIPdataRateForTTIBundling ...................213
TTIBundlingConf::maxNbrOfTTIbundlingUsers .................................213
TTIBundlingConf::ttiBundlingActivationLoadThresh ........................214
TTIBundlingConf::gBRUlPrbConsumptionPerKbps ..........................214
TTIBundlingConf::isPRBMeasurementForTTIBundlingAllowed .......214
TTIBundlingConf::ttiBundlingPRBpriorityOrder.................................215
TTIBundlingConf::uplinkLinkBudgetAlarmClearanceThreshold ......216
TTIBundlingConf::uplinkLinkBudgetAlarmTimeToClear ...................217
TTIBundlingConf::ttiBundlingDeactivationBLERthresh ....................217
TTIBundlingConf::ttiBundlingPRBdropThresh ...................................218
TTIBundlingConf::ttiBundlingPRBdropTimer .....................................218
TTIBundlingConf::prbGrantSizeForTTIBundling ................................219
TTIBundlingConf::ttiBundlingMinMCSforDS ......................................219
TTIBundlingConf::ttiBundlingMaxMCSforDS......................................220
TTIBundlingConf::ttiBundlingMinMCSforSPS ....................................220
TTIBundlingConf::ttiBundlingMaxMCSforSPS ...................................220
TTIBundlingConf::maxNbrOfPreselectedTTIBundlingUsers.............221
TTIBundlingConf::minimumSINRForTTIBundlingSEComputation ...222
TTIBundlingConf::ttiBundlingSegmentationBLERthresh..................222
TTIBundlingConf::ttiBundlingNoSegmentationBLERthresh .............223
CellRadioConf::minHARQtxWithoutMGcollisionForTTIbundling .....223
TTIBundlingConf::isContentionFreeRACHForTTIBundlingAllowed.224
TTIBundlingConf::isPUSCHType2HoppingOverTTIBundlingEnabled224
TTIBundlingConf::isSPSoverTTIBundlingEnabled.............................225
Page 8/472
TTIBundlingConf::ttiBundlingSPSactivationBLERthresh .................225
TTIBundlingConf::ttiBundlingSPSDeactivationBLERthresh .............226
TTIBundlingConf::tTIbundlingNotificationRepetitionTimer ..............226
CellL1ULConf::betaOffsetACKIndexForTTIbundling .........................227
CellL1L2ControlChannelsConf::extraDCI0powerOffsetForTTIBundlin
g ........................................................................................227
4.6.7.2 Uplink Dynamic scheduler operation mode determination ........................................227
CellL2ULConf::nbrUserThrFDS ............................................................228
CellL2ULConf::deltaNbrUserThrFDS ...................................................229
CellL2ULConf::sinrThrFSS....................................................................229
CellL2ULConf::deltaSinrThrFSS ...........................................................229
CellRadioConf::lowMobilityDopplerUplinkThr ....................................230
CellRadioConf::highMobilityDopplerUplinkThr ..................................230
CellL2ULConf::maxNbrULFSUsers ......................................................230
CellL2ULConf::ulSchedulerMode .........................................................232
4.6.7.3 Buffer estimation ........................................................................................................232
SignalingRadioBearerConf::logicalChannelGroupUL .......................233
TrafficRadioBearerConf::logicalChannelGroupUL .............................233
SignalingRadioBearerConf::logicalChannelSRMask .........................235
TrafficRadioBearerConf::logicalChannelSRMask ..............................235
4.6.7.3.1 Buffer Occupancy estimate periodic increase ......................................................235
SignalingRadioBearerConf::macBOperiodicIncreaseEnabledUl ......236
TrafficRadioBearerConf::macBOperiodicIncreaseEnabledUl ...........236
SignalingRadioBearerConf::macBOPeriodicIncreasePeriodUl ........238
TrafficRadioBearerConf::macBOPeriodicIncreasePeriodUl..............238
TrafficRadioBearerConf::mACBOminimumPeriodicIncreaseValue..239
SignalingRadioBearerConf::mACBOminimumPeriodicIncreaseValue240
EnbVoipConf::disableVoIPbearerPeriodicBOincreaseDuringSpeechIn
activityUl ..........................................................................240
4.6.7.4 QoS priority weight calculation ..................................................................................240
EnbRadioConf::uplinkSeFloor ..............................................................241
CellL2ULConf::isVoIpSegmentationHandlingEnabled .......................242
4.6.7.4.1 OVerall QoS weight ..............................................................................................242
ActivationService::isQCIWeightEnabled .............................................242
TrafficRadioBearerConf::ulQCISchedulingWeight .............................243
ActivationService::isNonGBRMinRateEnabled ..................................245
TrafficRadioBearerConf::ulMinThroughputTarget .............................245
EnbRadioConf::ulActiveThroughputAverageCoefficient ..................247
EnbRadioConf::marginForNonGbrMinRateEnforcement ..................248
EnbRadioConf::ulMaxNonGbrQosWeight ...........................................248
4.6.7.5 Uplink channel estimates update ...............................................................................249
4.6.7.6 Spectrum Efficiency correction ..................................................................................249
4.6.7.7 Scheduling stage .......................................................................................................249
4.6.7.7.1 Management of HARQ retransmissions ...............................................................249
CellL2ULConf::maxHARQtx ..................................................................250
4.6.7.7.2 Management of HARQ 1st transmissions .............................................................250
EnbRadioConf::maxNumberOfMPEiterations .....................................251
Page 9/472
EnbRadioConf::minGrantSizeForCQIreporting ..................................252
EnbRadioConf::minMCSwithPCQI .......................................................253
EnbRadioConf::minMCSwithACQI .......................................................254
CellL2ULConf::maxExtendedSRGrantSize..........................................255
4.6.7.7.3 Management of Power Headroom reports ...........................................................255
LteCell::additionalSpectrumEmission .................................................256
EnbRadioConf::aMPRappliedToSRS ...................................................256
LteCell::ul700MHzUpperCBlockEnabled .............................................258
EnbRadioConf::PHRthresholdFor700MHzZoneA ...............................258
EnbRadioConf::PHRthresholdFor700MHzZoneB1 .............................258
EnbRadioConf::PHRthresholdFor700MHzZoneB2 .............................259
EnbRadioConf::PHRthresholdFor700MHzZoneC ...............................259
4.6.7.8 MCS allocation ...........................................................................................................259
CellRadioConf::ulMCSTransitionTableForLargePUSCHGrants ........260
CellRadioConf::ulMCSTransitionTableForSmallPUSCHGrants ........260
CellRadioConf::ulMCSTransitionTablePRBsizeThreshold ................261
CellRadioConf::mCScorrectionForACQIinHigherBLERcase.............263
CellRadioConf::mCScorrectionForACQIinLowerBLERcase .............263
CellRadioConf::mCScorrectionForPCQIinHigherBLERcase .............263
CellRadioConf::mCScorrectionForPCQIinLowerBLERcase..............264
CellRadioConf::mCScorrectionForGrantsBeforeRachMsg1or3ForHig
herBLERSetpoint ............................................................264
CellRadioConf::mCScorrectionForGrantsBeforeRachMsg1or3ForLow
erBLERSetpoint ..............................................................264
CellRadioConf::smallPktPuschPRBThr ...............................................265
CellRadioConf::smallPktHPuschPowerMargin ...................................265
CellRadioConf::mCScorrectionForSmallULPackets ..........................265
CellL2ULConf::sinrBackoffForSRGrant ...............................................265
CellL2ULConf::minMCSForULDSVoIP .................................................266
4.6.7.9 Override of grant decisions to enforce UE category constraints ...............................266
4.6.7.10 Override decisions to Avoid grants with no useful payload .......................................268
4.6.7.11 One shot CSI scheduling for Carrier Aggregation .....................................................269
CarrierAggregationPrimaryConf::oneShotACSIMaxDelay ................269
4.6.8 MIMO scheduler..............................................................................................................269
CellActivationService::isulMIMOenabled ............................................270
4.6.9 Bearer multiplexing .........................................................................................................270
SignalingRadioBearerConf::logicalChannelPriorityUL ......................272
TrafficRadioBearerConf::logicalChannelPriorityUL ...........................272
SignalingRadioBearerConf::logicalChannelPrioritizedBitRateUL ....272
TrafficRadioBearerConf::logicalChannelPrioritizedBitRateUL .........273
SignalingRadioBearerConf::logicalChannelbucketSizeDurationUL.273
TrafficRadioBearerConf::logicalChannelbucketSizeDurationUL ......274
5 CONGESTION, RADIO ADMISSION CONTROL AND ENB CAPACITY ....................................277

5.1 CONGESTION AND RADIO ADMISSION CONTROL .......................................................................277
ActivationService::isIMSEmergencyCallAllowed ...............................278
PlmnIdentity::arpPriorityEmergency ...................................................278
Page 10/472
ActivationService::isHighPriorityAccessUserMgmtEnabled ............279
PlmnIdentity::arpPriorityHighPriorityAccess......................................279
ReactiveLoadControlActionForBearerAdmission::plmnId................282
5.1.1 Number of Connected (active) Users .............................................................................284
5.1.1.1 Per eNB......................................................................................................................284
RadioCacEnb::maxNumberOfCallPerEnodeB ....................................285
RadioCacEnb::maxNbrOfRRCConnectedUsersPerEnb.....................285
RadioCacEnb::nbrOfContextsReservedForEcAndHpaCalls .............285
5.1.1.2 Per Cell ......................................................................................................................285
RadioCacCell::maxNbrOfUsers ............................................................287
RadioCacCell::maxNbrOfActiveUsersPerCell .....................................287
RadioCacCell::nbOfContextsReservedForEcAndHpaCalls...............289
5.1.1.3 Per PLMN Per Cell.....................................................................................................290
RadioCacCellPerPlmn::reservedNbrOfUsers......................................291
5.1.2 Number of Established Data Bearers .............................................................................292
5.1.2.1 priority classes ...........................................................................................................292
ActivationService::isFourLevelPrbCacEnabled..................................294
RadioCacEnb::lowArpPriorityStart ......................................................295
RadioCacEnb:: mediumArpPriorityStart .............................................295
RadioCacEnb:: highArpPriorityStart ....................................................295
RadioCacCell::dlAdmissionThresholdOnPrb .....................................296
RadioCacCell::ulAdmissionThresholdOnPrb .....................................296
RadioCacCell::deltaAdmissionThresholdOnPrbForHighPrioReq ....297
RadioCacCell::deltaAdmissionThresholdOnPrbForMediumPrioReq297
RadioCacCell::deltaAdmissionThresholdOnPrbForTopPrioReq ......297
RadioCacCell::deltaAdmissionThresholdOnPrbForExisting ............298
5.1.2.2 Per Cell ......................................................................................................................298
RadioCacEnb::maxNbOfDataBearersPerEnodeB ..............................300
RadioCacCell::maxNbOfDataBearersPerCell ......................................301
RadioCacCell::maxNbrOfDataBearersPerQciGroup ..........................301
RadioCacCell::maxNbrOfVoip ..............................................................301
RadioCacCell::qCIforVoipRtpRtcp .......................................................305
RadioCacCell::maxGBRforVoIPserviceDl ...........................................305
RadioCacCell::maxGBRforVoIPserviceUl ...........................................305
RadioCacCell::admissionThresholdOnNbrOfDBs ..............................306
RadioCacCell::deltaAdmissionThresholdOnNbrOfDBsForHighPrioRe
q ........................................................................................306
RadioCacEnb::maxNbOfDataBearersPerUe........................................307
5.1.2.3 Per PLMN Per Cell.....................................................................................................308
RadioCacCellPerPlmn::reservedNbOfDataBearers ............................309
RadioCacCellPerPlmn::reservedNbrOfDataBearersPerQciGroup ....309
5.1.2.4 Modem Measurements ..............................................................................................310
RadioCacCell::periodMeasForPRBConsumption ...............................311
RadioCacCell::periodMeasForUeRadioCondition ..............................311
RadioCacCell::overheadForUeInBadRadioCondition ........................311
RadioCacCell::badUeSinrThreshold ....................................................311
RadioCacCell::goodUeSinrThreshold..................................................312
Page 11/472
5.1.3 PRB Consumption ..........................................................................................................312

5.1.3.1 PRB Consumption Calculation ..................................................................................313
ActivationService::isBearerTypeBasedPrbEstimationPreferred ......314
RadioCacCell::dlOverheadConsumption ............................................314
RadioCacCell::ulOverheadConsumption ............................................314
RadioCacEnb::cchSelfLearningCoef ...................................................315
RadioCacCell::dlSigConsumption .......................................................315
RadioCacCell::ulSigConsumption .......................................................316
RadioCacCell::dlPRBconsumptionPerKbps .......................................316
RadioCacCell::ulPRBconsumptionPerKbps .......................................316
RadioCacCell::dlMinBitRateForBE .......................................................317
RadioCacCell::ulMinBitRateForBE .......................................................317
RadioCacCell::isNonGbrPrbCacEnabled ............................................317
5.1.3.2 MBMS multicast PRB consumption ...........................................................................319
5.1.3.3 Admission Decision....................................................................................................319
TrafficRadioBearerConf::prbReservationFactor.................................321
5.1.3.3.1 Admission with eUTRAN SHARING (Per PLMN Per Cell Admission) .................322
RadioCacCellPerPlmn::reservedDlPrbPercentage .............................322
RadioCacCellPerPlmn::reservedUlPrbPercentage .............................322
5.1.4 Reactive Load Control ....................................................................................................323
ActivationService::isReactiveLoadControlAllowed ...........................325
RadioCacEnb::maxNbrOfUsersImpactedByReactiveLoadControl ...325
ReactiveLoadControlActionForBearerAdmission::action .................326
PlmnIdentity::reactiveLoadControlActionForEcAndHpaAdmission 326
ReactiveLoadControlActionForBearerAdmission::plmnId................327
5.1.5 Preventive Load Control .................................................................................................327
ActivationService::isInterFreqPreventiveLoadControlEnabled ........333
ActivationService::isUtraPreventiveLoadControlEnabled ................333
ActivationService::isStaticPrbBasedPreventiveLoadControlEnabled333
ActivationService::isQosBasedPreventiveLoadControlEnabled ......334
RadioCacCell::isPerNeighborCarrierLoadControlEnabled ...............334
LteNeighboringFreqConf::preventiveOffloadLink ..............................335
UtraFddNeighboringFreqConf::preventiveOffloadLink .....................335
ActivationService::isNumUeBasedPreventiveLoadControlEnabled 335
RadioCacCell::isVoipOffloadEnabled ..................................................336
RadioCacCell::dlPreventiveLoadControlThresholdOnStaticPrb ......336
RadioCacCell::ulPreventiveLoadControlThresholdOnStaticPrb ......337
RadioCacEnb::preventiveLoadControlHysteresisTimer....................337
RadioCacEnb::arpThresholdForPreventiveLoadControl...................338
RadioCacEnb::maxNbrOfUsersImpactedByPreventiveLoadControl338
RadioCacEnb::ueTimerNoOffload ........................................................338
PreventiveOffload::cellNbrOfUsersLoadControlThreshold...............339
RadioCacEnb::enbNbrOfUsersLoadControlThreshold ......................339
QciConfForOffload::qCI.........................................................................340
RadioCacCell::preventiveLoadControlThresholdNbrOfActiveUsers340
RadioCacEnb::averagingPeriodForNbrActiveUsersPreventiveOffload341
RadioCacCell::ulPreventiveLoadControlThresholdOnRealPrb ........341
Page 12/472
RadioCacCell::dlPreventiveLoadControlThresholdOnRealPrb ........341
TrafficRadioBearerConf::dlBitRateThresholdForPreventiveLoadContr
ol .......................................................................................342
RadioCacEnb::nbrOfUsersImpactedByQosBasedPreventiveOffload342
RadioCacEnb::extraMarginNbUeSelectedPreventiveOffload............343
RadioCacEnb::inactivityTimeForPreventiveOffload ..........................343
RadioCacEnb::filteringCoefficientForQosBasedPreventiveOffload .343
5.1.5.1 Load equalization .......................................................................................................344
RadioCacCell::loadEqualizationDeltaThreshold.................................344
RadioCacEnb::ThresholdRelativePreventiveOffload .........................345
ActivationService::isFddTddRedirectionForPreventiveOffloadEnable
d ........................................................................................345
5.1.5.2 Connection Loading Reduction ..................................................................................346
RadioCacEnb::cuLoadingThreshForEarlyOOTRelease .....................346
RadioCacEnb::minInactiveTimeForEarlyOOTRelease .......................347
RadioCacEnb::pacingTimerForEarlyOOTRelease ..............................347
5.2 CAPACITY LICENSING..............................................................................................................347
5.2.1 Capacity Licensing High Level description .....................................................................347
5.2.2 Licensing Parameters vs. configuration parameters ......................................................349
5.2.2.1 Transmission Power ..................................................................................................350
5.2.2.2 Number of Active Users .............................................................................................352
5.2.2.3 Allocated Bandwidth ..................................................................................................353
5.2.3 “E2E” Licensing configuration example ..........................................................................354
6 TRANSMIT POWER ......................................................................................................................357

6.1 DOWNLINK TRANSMIT POWER .................................................................................................357
6.1.1 Power settings ................................................................................................................357
6.1.1.1 Cell Downlink Total power .........................................................................................357
LteCell::cellDLTotalPower.....................................................................358
6.1.1.2 Reference Signal power setting .................................................................................359
PowerOffsetConfiguration::referenceSignalPower ............................360
TxPowerDynamicRange::maxRefSigPower ........................................363
TxPowerDynamicRange::minRefSigPower .........................................366
6.1.1.3 Positioning Reference Signal power setting ..............................................................369
PowerOffsetConfiguration::prsPowerOffset .......................................369
6.1.1.4 Synchronization signals power setting.......................................................................370
PowerOffsetConfiguration::primarySyncSignalPowerOffset ............371
PowerOffsetConfiguration::secondarySyncSignalPowerOffset .......371
6.1.1.5 Antenna Port4 (MBSFN RS and PMCH) power setting .............................................376
PowerOffsetConfiguration::port4PowerOffset....................................376
6.1.1.6 PBCH Power Setting..................................................................................................376
PowerOffsetConfiguration::pBCHPowerOffset...................................377
6.1.1.7 PCFICH Power Setting ..............................................................................................377
PowerOffsetConfiguration::pCFICHPowerOffset ...............................378
6.1.1.8 PHICH Power Setting ................................................................................................381
PowerOffsetConfiguration::pHICHPowerOffset..................................381
6.1.1.9 PDCCH Power Setting ...............................................................................................384
CellL2DLConf::pDCCHPowerControlActivation .................................384
PowerOffsetConfiguration::pDCCHPowerOffsetSymbol1 .................385
Page 13/472
PowerOffsetConfiguration::pDCCHPowerOffsetSymbol2and3 ........385
6.1.1.10 PDSCH Power Setting ...............................................................................................390
PowerOffsetConfiguration::paOffsetPdsch ........................................391
PowerOffsetConfiguration::pbOffsetPdsch ........................................392
CellL2DLConf::nomPdschRsEpreOffset .............................................395
DownlinkCAConf::cqiReportConfigR10NomPdschRsEpreOffset ....395
6.1.2 PDCCH Power Control ...................................................................................................395
CellL1L2ControlChannelsConf::extraDCI0powerOffsetForTTIBundlin
g ........................................................................................396
CellL1L2ControlChannelsConf::dlTargetSINRTableForPDCCH .......397
CellL2DLConf::pDCCHPowerControlType ..........................................398
CellL2DLConf::pDCCHPowerControlMaxPowerIncrease ..................398
CellL2DLConf::pDCCHPowerControlMaxPowerDecrease.................398
CellL1L2ControlChannelsConf::powerOffsetForCriticalCRNTIGrants399
CellL1L2ControlChannelsConf::powerOffsetForNonCRNTIGrantsInCo
mmonSearchSpace ........................................................399
CellL1L2ControlChannelsConf::powerOffsetForDCI3 .......................399
6.1.3 Downlink Power Budget ..................................................................................................399
6.2 UPLINK POWER CONTROL .......................................................................................................414
6.2.1 PUCCH Power Control ...................................................................................................415
ULPowerControlConf::deltaFPUCCHFormat1 ....................................417
ULPowerControlConf::deltaFPUCCHFormat1b ..................................418
UplinkCAConf::deltaFPUCCHFormat1bCSR10 ....................................418
ULPowerControlConf::deltaFPUCCHFormat2 ....................................419
ULPowerControlConf::deltaFPUCCHFormat2a ..................................419
ULPowerControlConf::deltaFPUCCHFormat2b ..................................420
ULPowerControlConf::p0NominalPUCCH ...........................................420
ULPowerControlConf::p0uePUCCH .....................................................421
ULPowerControlConf::sIRTargetforReferencePUCCHFormat ..........421
6.2.2 PUSCH Power Control....................................................................................................422
ULPowerControlConf::p0NominalPUSCH ...........................................424
LogicalChannelConf::p0UePUSCH ......................................................424
ULPowerControlConf::isP0PersistentFieldPresent ...........................425
ULPowerControlConf::p0NominalPUSCHPersistent .........................425
ULPowerControlConf::p0UEPUSCHPersistent ...................................426
ULPowerControlConf::filterCoefficient ................................................426
ULPowerControlConf::pUSCHPowerControlAlphaFactor .................427
6.2.2.1 Fractional Power Control ...........................................................................................427
6.2.2.2 CQI assisted UL SINR target adjustment ..................................................................428
ULPowerControlConf::isCQIbasedPushPowerCtrlEnabled ..............429
ULPowerControlConf::dlSinrToUlSinrTargetConversionFactor .......429
ULPowerControlConf::dlSinrToUlSinrTargetConversionThresh......429
6.2.2.3 PUSCH power control adjustment state ....................................................................430
ULPowerControlConf::accumulationEnabled .....................................431
6.2.2.4 SINR target computation............................................................................................431
ULPowerControlConf::SIRtargetSPSCorrectionTable .......................434
ULPowerControlConf::maxSIRtargetSPSCorrectionValue................434
Page 14/472
ULPowerControlConf::minSIRtargetSPSCorrectionValue ................434
UplinkSemiPersistentSchedulingConf::sIRtargetSPSCorrectionReset
ValueUl.............................................................................435
UplinkSemiPersistentSchedulingConf::sIRtargetSPSCorrectionThres
holdForSPSreleaseUl .....................................................435
ULPowerControlConf::pathLossNominal ............................................435
CellRadioConf::uplinkSIRtargetValueForDynamicPUSCHscheduling436
ULPowerControlConf::maxSIRtargetForFractionalPowerCtrl...........437
ULPowerControlConf::minSIRtargetForFractionalPowerCtrl ...........437
ULPowerControlConf::maxNoisePlusInterferenceLevelUL...............438
ULPowerControlConf::minNoisePlusInterferenceLevelUL ...............438
6.2.2.5 PUSCH power control procedure ..............................................................................439
CellRadioConf::numberofULmeasurementsNeededForSendingValidT
PCCommandForPUSCHdynamicMode ........................440
CellRadioConf::numberofULmeasurementsNeededForSendingValidT
PCCommandForPUSCHspsMode .................................440
ULPowerControlConf::tpcPeriodForPUSCHtpcOverDCI3 .................440
6.2.2.6 Uplink Interference Control ........................................................................................441
6.2.2.6.1 Generic algorithm .................................................................................................441
ULPowerControlConf::pUSCHioTControlActivationFlag ..................441
ULPowerControlConf::pUSCHioTControlCoefAboveThr1 ................441
ULPowerControlConf::pUSCHioTControlCoefBelowThr1 .................442
ULPowerControlConf::pUSCHioTControlMinTargetCorrAboveThr1442
ULPowerControlConf::pUSCHioTControlMinTargetCorrBelowThr1 442
ULPowerControlConf::pUSCHioTControlThermalNoiseCorr ............443
ULPowerControlConf::pUSCHioTControlThresh1 .............................443
ULPowerControlConf::pUSCHioTControlThresh2 .............................443
6.2.2.7 intra-enb INTER-SECTOR IOT CONTROL ...............................................................444
ULPowerControlConf::isInterSectorIoTcontrolEnabled ....................445
ULPowerControlConf::interSectorIoTcontrolPeriod ..........................445
ULPowerControlConf::interSectorIoTcontrolminCellLoadThr ..........445
6.2.2.8 IOT Aware PRB Assignment for FDS ........................................................................445
CellL2ULConf::iotAwareFDSEnabled ..................................................446
6.2.3 Sounding Reference Signal Power Control ....................................................................446
ULPowerControlConf::pSRSOffset ......................................................447
6.2.4 RACH power control .......................................................................................................447
6.2.4.1 Power allocation for RA preamble .............................................................................447
CellRachConf::preambleInitialReceivedTargetPower ........................448
CellRachConf::preambleTransmitPowerStepSize ..............................448
6.2.4.2 Power allocation for RACH Message 3 .....................................................................449
ULPowerControlConf::deltaPreambleMsg3 ........................................449
CellRachConf::tPCRACHMsg3 .............................................................450
7 ANNEX: MODULATION AND CODING SCHEMES AND TBS DETERMINATION.....................452

7.1 DOWNLINK MODULATION AND CODING SCHEMES AND TBS DETERMINATION ..............................452
7.2 PUSCH MODULATION AND CODING SCHEMES AND TBS DETERMINATION .................................453
CellL1ULConf::betaOffsetCQIIndex .....................................................457
Page 15/472
CellL1ULConf::betaOffsetRIIndex ........................................................457
CellL1ULConf::betaOffsetACKIndex ....................................................457
CellL1ULConf::betaOffsetACKIndexForTTIbundling .........................458
UplinkCAConf::betaOffsetACKIndexForFourBitsAckNack ...............458
7.3 3GPP TRANSPORT BLOCK SIZE TABLE ....................................................................................459
8 ANNEX: ABBREVIATIONS ...........................................................................................................467
Page 16/472
TABLES
Table 1: Standardized QoS Classes ............................................................................................................... 32
Table 2: Downlink UE category characteristics ............................................................................................. 49
Table 3: Uplink UE category characteristics .................................................................................................. 49
Table 4: Gap Pattern configurations ................................................................................................................ 65
Table 5: RBG groups in resource allocation type 0....................................................................................... 83
Table 6: Dependencies between dlBandwidth and resourceBlockPersistentAreaStart and
resourceBlockPersistentAreaEnd ............................................................................................................ 86
Table 7: RACH1-RACH2 time offset RACHMessage1toMessage2Offset values ........................................... 94
Table 8: Positioning Reference Signal subframe configuration ................................................................ 112
Table 9: PRS bandwidth.................................................................................................................................. 113
Table 10: Offset levels for Differential CQI ................................................................................................... 125
Table 11: Subband index with a 3 MHz bandwidth ..................................................................................... 125
Table 12: Subband index with a 5 MHz bandwidth ..................................................................................... 126
Table 13: Subband index with a 10 MHz bandwidth ................................................................................... 126
Table 16: Precoding matrix as a function of the codebook index and the rank ...................................... 129
Table 17: PUCCH CQI/PMI reporting modes............................................................................................... 133
Table 18: Mapping of the 3-bit differential CQI value reported for the second codeword (when rank = 2
in mode 1-1) to CQI_Offset. ..................................................................................................................... 134
Table 19: VoIP codec-to-IP packet size mapping when RoHC is used ................................................... 160
Table 20: VoIP codec-to-IP packet size mapping when RoHC is not used ............................................. 161
Table 21: Counters for monitoring number of HPA bearers ...................................................................... 280
Table 22: Summary of call admission checks which detect Congestion or Load Balancing thresholds.
.................................................................................................................................................................... 284
Table 23: Total DL and UL Resource Count for a cell ................................................................................ 320
Table 24 : eNB Resources controlled by Capacity Licensing in LA4.0 .................................................... 349
Table 25 : Example of Power_Token_Cell for different cellDlTotalPower values and
numberOfDLAntennas = 2. ..................................................................................................................... 351
Table 26: Split between OFDM symbols with RS and OFDM symbols without RS ............................... 391
Table 27: (transmissionMode=tm1, dlBandwidth=n6-1_4MHz, CFI=3, phichResource=one) RE
distribution in slot 0 of subframe 0 ......................................................................................................... 403
Table 28: (transmissionMode=tm1, dlBandwidth=n6-1_4MHz, CFI=3, phichResource=one) RE
Table 29: (transmissionMode=tm1, dlBandwidth=n15-3MHz, CFI=3, phichResource=one) RE
distribution in slot 0 of subframe 0. ........................................................................................................ 406
Table 39: (transmissionMode=tm2/3/4, dlBandwidth=n6-1_4MHz, CFI=3, phichResource=one) RE
Page 17/472
Table 40: (transmissionMode=tm2/3/4, dlBandwidth=n6-1_4MHz, CFI=3, phichResource=one) RE

Table 41: (transmissionMode=tm2/3/4, dlBandwidth=n15-3MHz, CFI=3, phichResource=one) RE
Table 51: (dlBandwidth=n50-10MHz, CFI=2, phichResource=one) RE distribution in slot 0 of an M-
subframe .................................................................................................................................................... 413
Table 52: (dlBandwidth=n50-10MHz, CFI=2, phichResource=one) RE distribution in slot 1 of an M-
subframe .................................................................................................................................................... 414
Table 53: Mapping of TPC command Field in DCI format 1/1A/2/2A to δ PUCCH .................................... 417
Table 54: Mapping of TPC Command Field in DCI format 0 to δ PUSCH values. ..................................... 431
Table 55: Modulation TBS index for Downlink Modulation and Coding Schemes ................................. 452
Table 56: Modulation and TBS index for PUSCH Modulation and Coding Schemes ............................ 454
Table 57: Maximum grant size (in PRBs) for a category 1 UE .................................................................. 455
Table 58: Maximum grant size (in PRBs) for a category 2 UE .................................................................. 456
Table 59: 3GPP Transport Block Size table ................................................................................................. 467
Page 18/472
FIGURES
Figure 1: QoS layered architecture in LTE ................................................................................................... 30
Figure 2 : QoS parameters.............................................................................................................................. 32
Figure 3 : Illustration of delay buildup due to excessive VoIP packet segmentation.............................. 39
Figure 6: Dynamic Resource Allocation and Packet Scheduling overview ............................................. 47
Figure 7: Long DRX cycle and associated parameters .............................................................................. 52
Figure 8: Mapping between downlink logical channels and downlink transport channels..................... 82
Figure 9: Mapping between downlink transport channels and downlink physical channel ................... 82
Figure 10: Layer 2 structure in the downlink ................................................................................................ 83
Figure 11: Time-Frequency resource occupation matrix ............................................................................ 84
Figure 12: Periodic PMCH resource distribution between the different MCHs configured in the
MBSFN area ............................................................................................................................................ 117
Figure 13 : RBG allocation main loop and RB Allocation zone loop ....................................................... 150
Figure 14 DL Carrier Scheduler for CA operation ..................................................................................... 165
Figure 15: Mapping between uplink logical channels and uplink transport channels .......................... 177
Figure 16 : Mapping between uplink transport channels and uplink physical channels ...................... 177
Figure 17 : The (1,3) frequency reuse pattern (a) Frequency reuse over the cells (b) Sub-band
allocation pattern .................................................................................................................................... 179
Figure 18 : Fractional (1,3) frequency reuse scheme ............................................................................... 180
Figure 19: UL Scheduler view of data burst for minRate QoS throughput metric evaluation ............. 247
Figure 20: Radio CAC Overview .................................................................................................................. 283
Figure 21: PRB Consumption in a Cell ....................................................................................................... 312
Figure 22: Example of PRB Consumption per PLMN (cell shared by 2 operators: plmnId=1 and
plmnId=2) ................................................................................................................................................. 313
Figure 23: Thresholds for Preventive and Reactive Load Control .......................................................... 332
Figure 24: Capacity Licensing Principle ...................................................................................................... 348
Figure 25: Transmission Power Licensing .................................................................................................. 351
Figure 26: Number of Active Users Licensing ............................................................................................ 352
Figure 27: Bandwidth licensing example with 10 MHz for all the cells ................................................... 354
Figure 28: Capacity Licensing configuration example .............................................................................. 356
Figure 29 : Principle of fractional power control ......................................................................................... 428
Figure 30: Power Control Parameters ......................................................................................................... 432
Page 19/472
1 INTRODUCTION
1.1 OBJECT
The objective of this volume is to describe from an engineering point of view the LTE
parameters that are related to eNodeB Radio Resource Management aspects.
recommendations.

and LR13.3 is colored with a gray background as illustrated by this paragraph.
• In previous releases an internal version and an external version of LPUG
have been published. Starting with Release LR13.1, only an external
version will be published.
individual volume contains a list of features that are described in that
volume. In addition, the listings of new, modified, and deleted parameters,
and parameters that are not described in LPUG have been deleted from the
Page 20/472

deleted.
Parameter values provided in this version of the LPUG document reflect the best
information available at the time of publication.

LR13.1 delivery release become available as initially planned.
Note that three types of modem are available in LR13.1: the eCEM, the bCEM,

separate document.
Page 21/472
Transport related parameters are described in the Transport Engineering Guide

(TEG). Please refer to that document for information on transport-related
parameters.
1.3 RELATED FEATURES

LA1.x
Feature
Feature Title
Number
FRS 76432 Scheduling Evolutions
FRS 76434 Layer 1 Evolutions
FRS 76494 Radio Load Noise Simulator
FRS 76501 LR1.0 3GPP Standard Compliance
FRS 76511 Bearer Management and Applications
FRS 79358 LA1.0 eNB System Capacity
FRS 80279 Downlink Transmit Schemes
FRS 85004 UE Emission Control in 700 MHz Upper C Block
Page 22/472
LA2.0
Feature
Number
EUTRAN Alignment on 3GPP Rel'8 June09
FRS 103773 LA 2.0.0
specifications
FRS 92129 Support for 20MHz bandwidth on 2.6 GHz eNodeB LA 2.0.2
Up to 4 simultaneous bearers per User(and AMBR

FRS 98840 LA 2.0.2
handling)
FRS 92038 Enhanced eNB 9326 LA2.0 Sw Capacity LA 2.0.2
FRS 96293 Support OCNS on PDCCH LA 2.0.2
FRS 84816 Support Group Hopping on PUSCH and PUCCH LA 2.0.2
FRS 97919 Fractional Power Control Integration LA 2.0.2
FRS 91652 LTE Capacity Licensing LA 2.0.2
FRS 92633 Capacity Licensing Impact in eNB LA 2.0.2
LA3.0
Feature
Feature Title
Number
FRS 92079 EUTRAN Standard Alignment on 3GPP Rel'8 Dec09
FRS 93270 Measurement Gaps Management
FRS 92025 CS Fallback to UTRA(WCDMA) for Voice Calls
FRS 92026 CS Fallback to GERAN for Voice Calls

FRS 92095 QCI & QCI parameters for enhanced scheduling
decisions
FRS 108958 Sys-Info Scheduling Improvements
FRS 92091 Call Admission Evolutions
DL control channels optimization (PDCCH, PHICH,

FRS 84872 PCFICH)
FRS 84873 UL control channels optimization (PUCCH & SRS)
FRS 92641 Configurable CQI reporting rate
FRS 101841 VoIP in dynamic scheduler
FRS 90853 Frequency Diverse Scheduling
FRS 103163 eNB SW capacity configurations
Page 23/472
Feature
Feature Title
Number
FRS 92483 Up to 8 concurrent data bearers per user
FRS 111577 eNB KPI objective improvements for LA3.0
FRS 104823 OP PUCCH enhancement
LA4.0
Feature
Feature Title
Number
FRS 114644 EUTRAN Standard Alignment on 3GPP Rel'9
FRS 114531 VoLTE Solution for Field Trial Applications
FRS 115647 VoLTE Friendly User Trial solution
FRS 115113 LA4.0 KPI targets
FRS 115114 LA4.0 eNB SW Capacity Targets
FRS 92127 Commercial Mobile Alert System (CMAS) support
FRS 114539 Congestion Management at Call Admission
FRS 84815 Single Antenna Transmit Scheme

eNB support of OTDOA Hearability Enhancement
FRS 115435
(trial)
FRS 108084 ANR support for inter RAT neighbors (UTRAN)
FRS 115436 RACH format 2 (phase I)
FRS 103897 eNB IMS VoIP emergency call support (trial)

Tunable Antenna Path Delay between (RRH/TRDU)
FRS 115670
DAS
Support Fiber delay (or any delay between modem
FRS 100622
and RF head) in LTE
FRS 115562 4Rx Receive Diversity over 5MHz BW FDD
FRS 92805 Symmetrical 3MHz FDD BdW Mgt
FRS 114791 TRDU2x60-26 Requirements
Page 24/472
LA5.0
Feature
Feature Title
Number
FRS 115232.1 KPI targets
FRS 115239 Voice over LTE for commercial launches
FRS 115239.1 Voice over LTE for commercial launches
FRS 115227.1 EUTRAN Standard Alignment
FRS 115217.1 eNB Class Parameter Change Improvements
FRS 115223.1 Inter-freq Load Balancing
FRS 115685.1 Mobility Enhancement for VoIP Service
FRS 115222.1 VoIP Emergency call for commercial deployment
FRS 115242 eUTRAN Sharing: Enhanced MOCN
FRS 115527 eMBMS Trial Support
FRS 114640 Support of 15MHz LTE symmetric carrier

Symmetrical 1.4MHz FDD Bandwidth
FRS 92801.1
Management
FRS 115686 Scheduler Improvements for VoLTE capacity
User plane and control plane OTDOA with
FRS 101821
hearability support for Commercial deployment
User plane and control plane OTDOA with
FRS 101821.1
hearability support for Commercial deployment
FRS 114536.1 Support of TTI bundling for VoIP
LA6.0.0
Feature
Feature Title
Number
FRS 160815 Optimized segmentation (MCS override)
FRS 166046 PUSCH improvements
Page 25/472
LA6.0.1
Feature
Feature Title
Number
FRS 160636 Non-GBR prioritization
FRS 114492 Generalized OP PUCCH
FRS 92639 RACH format 2 support
FRS 115938 Dual-carrier support on one band
LR13.1:
Feature
Number
FRS 101843 MAC DRx State Mgt under Inactivity Conditions CL1
FRS 115807 TTI Bundling phase 2 CL1
FRS 115644 Bearer Characteristics online modifications CL1
FRS 128460 Minimum bitrate enforcement for non-GBR CL1
FRS 162790 Semi-Persistent Scheduling (SPS) for VoLTE CL2
FRS 172164 QCI1 GBR Cap Removal CL2
FRS 114538 Enhanced Load Balancing Criteria CL1
FRS 161003 eNB SW Capacity Configurations CL1
Target Cell Load Consideration for IRAT Mobility
FRS 115912
to WCDMA
MCO LTE software platform in LA6.0 - macro- CL1
FRS 159488
metro software parity phase 1.1
MCO LTE software platform macro-metro software CL1
FRS 159468
parity phase 1.2
LR13.3:
Feature
Feature Title
Number
FRS 171232 nGBR QoS Based Load Balancing
FRS 115860 High Priority Access Admission Control
FRS 166802 SoftWare Capacity Configuration in LR13.3
Whenever possible and/or necessary, a reference is given to the feature in question

(parameter tables) or to (one of) its requirements.
Page 26/472
Page 27/472

2.1 LPUG VOLUMES

[Vol. 6] Mobility
related parameters that were previously described in LPUG Volume 7 were moved
to the Transport Engineering Guide (TEG) [R01]. Please refer to that document for

[R02] 3GPP TS 36.101 v9.6.0: "User Equipment (UE) radio transmission and
reception".
[R03] 3GPP TS 36.133 v9.6.0: "Requirements for Support of Radio Resource

Management".
[R04] 3GPP TS 36.211 v9.1.0: "Evolved Universal Terrestrial Radio Access (E-
UTRA); Physical channels and modulation".
UTRA); Multiplexing and channel coding".
UTRA); Physical layer procedures".
[R07] 3GPP TS 36.321 v9.3.0: “Evolved Universal Terrestrial Radio Access
Network (E-UTRAN; Medium Access Control (MAC) R9”.
[R08] 3GPP TS 36.331 v9.7.0: Radio Resource Control (RRC) protocol
Specification.
[R09] 3GPP TS 23.203 v9.8.0: Policy and charging control architecture.
Page 28/472

Before reading this volume, the reader should read the introduction (Volume 1) and
the Air Interface Volume (Volume 3). Volume 1 provides an explanation of the
presentation and conventions that are used throughout the document (i.e., common
to all volumes) whereas Volume 3 contains a description of the MAC procedures as
well as physical layer and other important Air Interface concepts.
Page 29/472
3 RADIO RESOURCE MANAGEMENT FUNCTIONS

The purpose of radio resource management (RRM) is to ensure the efficient use of
the available radio (time/frequency and power) resources.
The establishment, maintenance and release of Radio Bearers involve the
configuration of radio resources associated with them. When setting up a radio
bearer for a service, RRM takes into account the overall resource situation in E-
UTRAN, the QoS requirements of in-progress sessions and the QoS requirements
for the new service.
3.1 QUALITY OF SERVICE
3.1.1 LTE QOS ARCHITECTURE

LTE uses a QoS layered architecture illustrated in Figure 1.
E-UTRAN EPC Internet
UE eNB S-GW P-GW Peer

Entity
End-to-end Service
EPS Bearer External Bearer
E-RAB S5/S8 Bearer
Radio Bearer S1 Bearer
Radio S1 S5/S8 Gi
Figure 1: QoS layered architecture in LTE
An EPS bearer/E-RAB is the level of granularity for bearer level QoS control in the
EPC/E-UTRAN. That is, Service Data Flows (SDFs) mapped to the same EPS
bearer receive the same packet treatment.
One EPS bearer/E-RAB is established when the UE connects to a PDN, and that
remains established throughout the lifetime of the PDN connection to provide the UE
with always-on IP connectivity to that PDN. That bearer is referred to as the default
bearer. Any additional EPS bearer/E-RAB that is established to the same PDN is
referred to as a dedicated bearer.
A dedicated bearer can either be a GBR or a Non-GBR bearer while a default bearer
is a Non-GBR bearer.
Note that RRM only manages the radio QoS (i.e. the QoS on the radio interface).
Page 30/472
3.1.1.1 QOS MANAGEMENT FOR CA ACTIVATED UE
In LR13.3, Carrier Aggregation with 2 DL carriers is supported. The scheduler in the

PCell supports for CA activated UE all existing QoS related features (except for
VoIP) offered to non-CA UE, and additionally takes into account metrics from SCell.
Meanwhile, on the SCell, only a single QoS policy for CA bearers can be applied i.e.
QoS parameters are set uniquely for all CA bearers in SCell, no matter what QoS
class is configured in the PCell. QoS enforcement for CA bearer in SCell is
configured via MO CarrierAggregrationSecondaryConf and new parameters in MO
EnbRadioConf.
3.1.2 QOS PARAMETERS

An SAE bearer is a logical aggregate of one or more Service Data Flows (SDFs)
running between a UE and a PDN Gateway. These SDFs share the same QoS
treatment and performance characteristics for that bearer. SDFs with different QoS
requirements need the establishment of another bearer.
The service level (i.e., per SDF or per SDF aggregate) QoS parameters are QCI,
ARP, GBR, and MBR.
Each SAE bearer is either a GBR or a Non-GBR bearer.

Each GBR bearer has an associated GBR (Guaranteed Bit Rate) and MBR
(Maximum Bit Rate) value.
A Non-GBR bearer does not have an associated GBR but may have an associated
MBR.
Each UE is associated with an Aggregated Maximum Bit Rate (AMBR), which is the
upper limit of the sum of the rates of all the Non-GBR bearers for this UE. The UE
AMBR is ignored if parameter enforceAMBRvalues is set to “False”.
Each bearer QoS Class Identifier (QCI) is a set of 3 parameters (Priority, L2 Packet
Delay Budget and L2 Packet Loss Rate) that control bearer level packet forwarding
treatment (e.g. scheduling weights, admission thresholds, queue management
thresholds, link layer protocol configuration such as ARQ and HARQ parameters,
etc.).
The Packet Delay Budget represents the upper bound for the time that a packet
spends between the UE and the Packet Data Network – Gateway (PDN-GW) with a
confidence level of 98%.
The Priority is used to differentiate between SDF aggregates of the same UE, and it
is used to differentiate between SDF aggregates from different UEs. Scheduling
between different SDF aggregates is primarily based on the PDB. If the target set by
the PDB can no longer be met for one or more SDF aggregate(s) across all UEs then
the Priority is used (i.e. the scheduler meets the PDB of SDF aggregates on Priority
level N in preference to meeting the PDB of SDF aggregates on Priority level N+1).
Page 31/472
The Packet Error Loss Rate (PELR) defines an upper bound for the rate of RLC
SDUs that have not been received by the receiver PDCP layer. Thus, the PELR
defines an upper bound for a rate of non-congestion related packet losses.
QCI Bearer Type Priority Packet Delay Budget Packet Loss Rate
1 GBR 2 100 ms 10 −2
2 GBR 4 150 ms 10 −3
3 GBR 3 50 ms 10 −3
4 GBR 5 300 ms 10 −6
5 Non-GBR 1 100 ms 10 −6
6 Non-GBR 6 300 ms 10 −6
7 Non-GBR 7 100 ms 10 −3
8 Non-GBR 8 300 ms 10 −6
9 Non-GBR 9 300 ms 10 −6
Table 1: Standardized QoS Classes
Figure 2 summarizes the different elements of QoS.
SAE Bearer QoS
LABEL ARP
Bearer Delay Loss

Type Budget Tolerance
GBR Non-GBR
GBR AMBR
MBR
Figure 2 : QoS parameters
As per [R09], 9 QoS classes are standardized. A given QoS Class ensures that
applications/services mapped to that QoS Class receive the minimum level of QoS
associated to it (see Table 1). Note, however, that up to 255 different QoS Classes
can be configured, i.e. up to 246 additional QCIs can be defined (besides the 9
standardized QCIs 1-9). This is achieved by generating as many instances of object
Page 32/472
TrafficRadioBearerConf as needed (a minimum of 9 for the standardized QCIs plus

up to 246 customized QCIs). Each instance of object TrafficRadioBearerConf is
identified by parameter TrafficRadioBearerConf::qCI and is associated, among
others, with a Packet Delay Budget configured by parameter
TrafficRadioBearerConf::packetDelayBudget
(CarrierAggregationSecondaryConf::packetDelayBudget for CA bearer in SCell)
and a priority level configured by parameter
TrafficRadioBearerConf::logicalChannelPriorityDL
(CarrierAggregationSecondaryConf::logicalChannelPriorityDL for CA bearer in
SCell). The latter represents the priority with which, for the bearer in question, a
packet whose waiting time has reached (or exceeded) the associated QCI’s PDB is
scheduled (see section 4.5.3.8).
Note that a user friendly-name of the QCI can be defined using the optional
parameter TrafficRadioBearerConf::trafficRadioBearerConfName.
Each QCI is associated with a QCI Group. The QCI Group a given QCI belongs to is
defined by parameter TrafficRadioBearerConf::qciGroup.
The QCI of a data bearer associated with an MBMS service (identified, in the PLMN
in question, by MbmsBearerService::serviceId in the associated instance of object
MbmsBearerService) is defined by parameter MbmsBearerService::qCI. Its GBR
is defined by parameter MbmsBearerService::guaranteedBitRate. Note that in
LA6.0, all bearers associated with MBMS services are GBR bearers.
Please refer to [Vol. 5] for more information on MbmsBearerService::serviceId and
MBMS PLMN parameters (MbmsBearerService::plmnMobileCountryCode and
MbmsBearerService::plmnMobileNetworkCode) and for other parameters in
MbmsBearerService (i.e. other MBMS service parameters).
EnbRadioConf::enforceAMBRvalues
Parameter enforceAMBRvalues
Object ENBEquipment/Enb/EnbRadioConf
True/False
Value True ALU recommends the operator to not change this setting
Feature FRS 98840
Page 33/472
TrafficRadioBearerConf::qCI
Parameter qCI
[1..255]
Feature
TrafficRadioBearerConf::qciGroup
Parameter qciGroup
[1..32]
Value Optional parameter (current default is “unset” for all DRBs)
Feature FRS 114539
TrafficRadioBearerConf::trafficRadioBearerConfName
Parameter trafficRadioBearerConfName
Range & Unit String of up to 64 characters

Feature
Page 34/472
TrafficRadioBearerConf::packetDelayBudget
Parameter packetDelayBudget
[30..10000] step = 10 ms
Feature FRS 92095, 160847
CarrierAggregationSecondaryConf::packetDelayBudget
Parameter packetDelayBudget
ENBEquipment/Enb/LteCell/CarrierAggregationConf/CarrierAg
Object
gregationSecondaryConf
[30..10000] step = 10 ms
Parameter logicalChannelPriorityDL
[1..255]
CarrierAggregationSecondaryConf::logicalChannelPriorityDL
Parameter logicalChannelPriorityDL
Object
[1..255]
Page 35/472
Engineering Recommendation: Parameters TrafficRadioBearerConf::qCI ,

TrafficRadioBearerConf::packetDelayBudget and
CarrierAggregationSecondaryConf::packetDelayBudget and
CarrierAggregationSecondaryConf::logicalChannelPriorityDL for CA bearer
in SCell
As explained above, an instance of object TrafficRadioBearerConf needs to be

generated for each QCI. Up to 255 instances can be generated, 9 of which are
mandatory and correspond to the standardized QCIs (i.e. QCIs 1-9). Up to 246
additional instances can be generated by the operator to define customized QCIs
(adapted to their own services if none of the standardized QCIs meets the PDB
requirement(s) of the service(s) in question).
In ALU templates, only 9 instances corresponding to the standardized QCIs are
generated:
qCI trafficRadioBearer TrafficRadioBearerCon TrafficRadioBearerConf

ConfName f::logicalChannelPriorit ::packetDelayBudget
yDL
1 VOIP 2 80
2 GBR 4 130
3 GBR 3 30
4 GBR 5 280
5 nGBR 1 80
6 nGBR 6 280
7 nGBR 7 80
8 nGBR 8 280
9 nGBR 9 280
In case of Carrier Aggregation, the current recommended setting for parameters

CarrierAggregationSecondaryConf::logicalChannelPriorityDL and
CarrierAggregationSecondaryConf::packetDelayBudget applicable to all CA
bearers in the SCell is respectively 1 and 80.
The Packet Delay Budget (PDB) is defined in 3GPP (see Table 1 for standardized
QCI PDBs) as an end-to-end delay, i.e. it corresponds to the delay between the
UE and the Packet Data Network – Gateway (PDN-GW).
The values provided in the table above were derived by subtracting 20 ms to the
end-to-end delay so as to obtain the radio interface packet delay budget (i.e. delay
between eNB and UE). This delay is the average between the case when the
PDN-GW is located "close" to the eNB (roughly 10 ms) and the case when the
PDN-GW is located "far" from the eNB, e.g. in case of roaming with home routed
Page 36/472
traffic (the one-way packet delay between Europe and the US west coast is
roughly 50 ms). Note that the 20 ms average is a weighted average, meaning that
it takes into account the fact that roaming is not a typical scenario. Subtracting this
20ms average delay to the end-to-end PDB will lead to the desired performance in
most cases.
Restriction: VoLTE optimization with MAC DRX feature activation

When MAC DRX improvement feature is activated, QCI5 and QCI1 priorities
(logicalChannelPriorityDL) must be reversed inside MIM template to enable
feature activation:
QCI1 DL, UL priorities should be set to 1, 4 respectively instead of 2, 4.
MbmsBearerService::qCI
Parameter qCI
ENBEquipment/Enb/Mbms/MbmsServiceArea/MbmsBearerServ
Object
ice
[1..255]
Class/Source N.A. (See Engineering Recommendation) / system_restricted
O.D. (see Engineering Recommendation for
Value
TrafficRadioBearerConf::qCI)
Feature FRS 115527
Engineering Recommendation: Parameter MbmsBearerService::qCI
This parameter is set per MBMS service. For each MBMS service, an instance of
object MbmsBearerService needs to be generated.
This parameter is a write at (object) creation parameter meaning that the
parameter can only be set upon creation of an MbmsBearerService instance.
Page 37/472
MbmsBearerService::guaranteedBitRate
Parameter guaranteedBitRate
ENBEquipment/Enb/Mbms/MbmsServiceArea/MbmsBearerServ
Object
ice
[1..65535] Kbits/s
Class/Source N.A. (See Engineering Recommendation) / system_restricted
Value O.D.
Feature FRS 115527

MbmsBearerService::guaranteedBitRate
This parameter is set per MBMS service. For each MBMS service, an instance of
object MbmsBearerService needs to be generated.
This parameter is a write at (object) creation parameter meaning that the

parameter can only be set upon creation of an MbmsBearerService instance.
3.1.2.1 OPTIMIZED SEGMENTATION FOR VOIP CALLS AND MCS

OVERRIDE
Optimized segmentation for VoIP calls is introduced in LA6.0.0 by feature L160815.

The aim of this feature is to enhance the uplink coverage for the VoLTE service. It is
activated by setting isOptimizedSegmentationEnabled to ‘True’.
ActivationService::isOptimizedSegmentationEnabled
Parameter isOptimizedSegmentationEnabled
True/False
Class/Source B--Cells-of-NE / system_reserved
Value False
Feature FRS 160815
Page 38/472
Restriction: Optim ised segm entation of VoI P and M CS override for Metro Cell
in LR13.1
This capability is not supported on Metro Cell in release LR13.1.
ActivationService::isOptimizedSegmentationEnabled can not be set to TRUE for
Metro Cell
It addresses issues occurring in poor radio coverage scenarios, when the uplink
scheduler struggles to maintain its target initial BLER. In this scenario, the typical
behavior of the uplink scheduler is to start segmenting the packets to allow the use of
more robust MCSs for the transmission of each individual packet. The issue is that
packet segmentation introduces delay to the transmission of the packet and may
cause packet delay to build up.
The figure below illustrates this phenomenon. In the illustrated case, the scheduler
breaks up a voice packet into 5 segments. If the segment labeled “s5-N” requires 3
or more transmissions, then a new voice packet (which arrives every 20ms) will
experience a delay in scheduling.
Figure 3 : Illustration of delay buildup due to excessive VoIP packet segmentation
It can be seen that by limiting the minimum size of the payload appropriately such
that the number of segments is limited (to say 4) then collisions with new incoming
voice packets can be minimized and delay build-up can be limited.
This size limitation is performed by enforcing a minimum PRB size (as per section
4.6.7.7.6) or minimum MCS (as per section 4.6.7.8, see parameter
minMCSForULDSVoiP) to the grant assigned to the UE when there is a VoIP bearer
configured on the call.
The minimum PRB size is configured by minNbrPRBForULDSVoIP.
Page 39/472
CellL2ULConf::minNbrPRBForULDSVoIP
Parameter minNbrPRBForULDSVoIP
[1..4]
Value 2
Feature FRS 160815
This protection against delay build up is done at the expense of the initial BLER
performance but the conversational services only put a constraint on residual BLER.
The solution is based on the assumption that 12.65 kbps AMBR-WB codec is used
and that RoHC is enabled. This limitation is planned to be removed in a later release
by the introduction of a functionality computing the optimal parameters to provide an
optimal segmentation.
Example of system tuning for a 12.65kbps AMR-WB codec

If we have to enforce a maximum of 4 RLC segments per 20ms speech frame for a
12.65 AMR-WB codec used in combination with RoHC compression, Optimized
Segmentation has to be tuned as per the following analysis:
If we split this payload in 4 segments the MAC and RLC overhead is the following:
For the first segment:
• 4 bytes PDCP/RohC header
• MAC header: 3 bytes (i.e. 1 byte for VoIP LCID indication + 2 bytes for short
BSR or PHR reporting)
• RLC header: 3 bytes, hence 6 bytes RLC/MAC header size.
For the subsequent segments:

• MAC header: 1 byte (for VoIP LCID indication)
• RLC header: 3 bytes, hence 4 bytes RLC/MAC header size.
The 12.65kbps AMR-WB codec delivers a 32 byte speech frame every 20ms,
consequently the total payload to be transported over 4 segments is:
Page 40/472
4 bytes ROHC header/PDCP header + 6 bytes for 1st RLC segment RLC/MAC
header size + 3 x (4 bytes for subsequent RLC segments RLC/MAC header size) +
32 bytes useful payload = 176 bit header + 256 bits useful payload = 432 bits
Consequently the minimum transport block size per segment (if we do not want to
have more than 4 segments per VoIP frame) is 432/4 = 108 bits
Page 41/472
If we now look at the Transport Block Size table defined in 3GPP.
IMCS
TB size (in bits) 10
0 1 2 3 4 5 6 7 8 9 or
11
1 16 24 32 40 56 72 328 104 120 136 144
2 32 56 72 104 120 144 176 224 256 296 328
3 56 88 144 176 208 224 256 328 392 456 504

NPRB
4
88 144 176 208 256 328 392 472 536 616 680
5
120 176 208 256 328 424 504 584 680 776 872
Therefore, the following rules enforce a maximum of 4 segments per speech frames
on a 12.65kbps speech codec with RoHC enabled:
• If the PUSCH grant size is 1 PRB  min MCS = 8

Optimized Segmentation is activated at UE level when the following conditions are

met:
• The feature is activated.
• The TBS of at least one of the VoIP bearers of that UE is greater than the
threshold minTBsizeForOptSeg.
• The achievable SINR is less than the threshold OptSegPuschSinrThresh.
• If bOcheckForOptSeg is set to ‘True’, the VoIP buffer is not empty (i.e. the
corresponding buffer occupancy is non null).
Page 42/472
CellL2ULConf::minTBsizeForOptSeg
Parameter minTBsizeForOptSeg
[0..255]
Value 25
Feature FRS 160815
CellL2ULConf::OptSegPuschSinrThresh
Parameter OptSegPuschSinrThresh
Range & Unit Float
[-10..40] with step = 0.5 dB
Value 10.0
Feature FRS 160815
CellL2ULConf::bOcheckForOptSeg
Parameter bOcheckForOptSeg
True/false
Value False
Feature FRS 160815
Note the achievable SINR represents the PUSCH SINR that would be achieved if the
UE were transmitting over 1 PRB at its maximum power (typically, 23dBm).
Upon handover, if the optimized segmentation is on for that user, then the uplink
scheduler deactivates optimized segmentation for that user and starts the
OverrideOptSegActivationTimer timer at the expiry of which optimized
segmentation can be activated again. This is to increase the chances of success for
handovers, if any.
Also, upon detection of SRB activity (via Buffer Status Reporting, as per section
4.6.7.3), if the optimized segmentation is on for that user, then the uplink scheduler
Page 43/472
deactivates optimized segmentation for that user and starts the

OverrideOptSegActivationTimer timer at the expiry of which optimized
segmentation can be activated again. This is to keep the same transmission
robustness level for SRBs.
CellL2ULConf::OverrideOptSegActivationTimer
Parameter OverrideOptSegActivationTimer
[0..400] with step = 100 ms
Value 0
Feature FRS 160815
Rule: Regarding Optimized Segmentation (MCS Override) parameters in LA6.0
In LA6.0, all the parameters directly belonging to the Opimized Segmentation

feature are implemented under spare parameters Enb::spare7 and Enb::spare9.
And while the recommended settings are exactly the same as in LR13.x, some
parameter values are slightly different from LR13.x due to a couple of subtleties in
value mapping for some of these parameters in LA6.0.
Namely, in LA6.0, the following parameters should be set as follows:

- optSegPuschSinrThresh = “40”, which maps to 10dB
(the parameter is configured by bits 24-30 of Enb::spare9; the range of
OptSegPuschSinrThresh is [-10, +40] dB with a step size of 0.5dB).
- minMCSForULDSVoIP = {1, 2, 4, 8}
(the parameter is configured by bits 3-18 of Enb::spare9, covering
4/3/2/1 PRB cases, and with the range [0,10] for each MCS value in the
table).
Regarding the other LA6.0 parameter values, they are similar to the ones in
LR13.x:
o isOptimizedSegmentationEnabled (configured by bit 23 of
Enb::spare9) = “true”, to activate the feature.
o minNbrPRBForULDSVoIP (configured by bits 0-2 of Enb::spare9 within
the range [0,4]) = 2.
o minTBsizeForOptSeg (configured by bits 0-7 of Enb::spare7 within the
range [0,255]) = 25.
o bOcheckForOptSeg (configured by bit 8 of Enb::spare7) = “false”
o OverrideOptSegActivationTimer (configured by bits 19-21 of
Enb::spare9, with a step of 100ms) = 0
So in LA6.0, assuming Enb::spare7 and Enb::spare9 are not used for anything
Page 44/472
else than the Optimized Segmentation feature (Caution: this might not necessarily
be the case!), in this case the LA6 current recommended values for the
parameters directly belonging to the feature can be summarized as:
o Enb::spare7 = 25
o Enb::spare9 = 679514690
3.1.2.2 BEARER CHARACTERISTICS ONLINE MODIFICATIONS

Feature 115644 defines the necessary change to support online modification of ARP
and QCI values for an already established bearer.
Sometimes the operator needs to change priority of a user. This feature supports
ARP and QCI modification of established E-RAB. This feature supports all
combinations of parameters modifications authorized by 3GPP. Refer to [Vol. 5] for
the overall description of this feature.
Each time a QCI is changed by an E-RAB Modify Request message, the eNB
performs an intra cell handover that induces the UE and modem L1, L2 configuration
update of allowed parameters.
A new flag ActivationService::isQciArpOnLineModificationEnabled is introduced to
enable/disable this function per eNodeB. The flag is not a license and is disabled by
default. Refer to [Vol. 5] for this parameter.
Page 45/472
3.2 RRM FUNCTIONS

The main RRM functions are the following:
• Radio Admission Control (RAC): The task of Radio Admission Control or
Radio CAC (Call Admission Control) is to admit or reject the establishment
requests for new radio bearers. In order to do this, it takes into account the
overall resource situation in E-UTRAN, the QoS requirements, the priority
levels and QoS of in-progress sessions as well as the QoS requirement of
the new radio bearer request. The aim is to ensure high radio resource
utilization (by accepting radio bearer requests as long as enough radio
resources are available to accommodate them) and at the same time to
ensure proper QoS for in-progress sessions (by rejecting radio bearer
requests when they cannot be accommodated).
• Dynamic Resource Allocation (DRA) – Packet Scheduling (PS): The task of
dynamic resource allocation (DRA) or packet scheduling (PS) is to allocate
resources to user and control plane packets and manage the power levels. It
takes into account the QoS requirements associated with the radio bearers
as well as the channel quality and buffer status information its gets from
associated reports.
• Inter-Cell Interference Coordination (ICIC): Inter-cell interference
coordination has the task to manage radio resources (resource blocks and
power) such that inter-cell interference is kept under control. ICIC is
inherently a multi-cell RRM function that needs to take into account
information from multiple cells.
Page 46/472
4 DYNAMIC RESOURCE ALLOCATION AND

PACKET SCHEDULING
The task of Dynamic Resource Allocation & Packet Scheduling (DRA&PS) is to
allocate radio resources to user and control plane packets. It takes into account the
QoS requirements associated with the radio bearers, the channel quality information
for UEs, buffer status, etc.
RLC
s
RRM ICIC eue
Freq Qu s
uenc
ies/P UL Packet RLC Statu
RB
Scheduler
RRM CAC Adm
UL/DL intra-eNB
itted
UEs
scheduler info
HARQ
Sta tus, CQ
I, Rank
& PMI
Power Phys. Channe
ls Power L1
Settings
DL Packet C on
C om
Scheduler figur mon Cha
eters ation n
aram (BCH nels
oS p ; PC
S1 Q H; …)
CallP
Cell/RRM
Scheduled UEs
PRB Assignment per UE
SISO-TxDiv/SIMO/MIMO scheme
MCS
Figure 4: Dynamic Resource Allocation and Packet Scheduling overview
The DL (resp UL) scheduler manages a UE context for each user in the RRC
connected state and a bearer context for each bearer of each UE in the RRC
connected state.
If a request for the creation of a UE context is accepted (see section 5) CallP creates
the UE context inside the downlink scheduler and the uplink scheduler (after the
reception of RACH Message 3 from the UE and before the transmission of RACH
Message 4).
If a request for the creation of a data bearer is accepted (see section 5), CallP
creates the bearer context inside the uplink and downlink contexts of the UE that
made the request.
SRB1 + SRB2 + up to 8 data radio bearers combinations are possible.
The maximum number of data radio bearers that can be supported by a given UE is
determined by the combination of 2 factors:
Page 47/472
1. Feature Group Indicator bit 7 from the UE Capabilities; bit 7 of IE

featureGroupIndicators = 0 indicates that RLC UM mode is not supported by the UE.
2. Feature Group Indicator bit 20 from the UE Capabilities; bit 20 of IE
featureGroupIndicators provides information on the support of Radio Bearer
combinations. It is checked together with bit 7.
The maximum Radio Bearer combinations depending on both bit 7 and bit 20 of IE
featureGroupIndicators can be summarized as follows:
UE support
AM UM
Bit 7 Bit 20
SRB SRB
1 2 DRB DRB DRB DRB DRB DRB DRB DRB DRB DRB DRB
1 2 3 4 5 6 7 8 1 2 3
0 0 X X X X X X
0 1 X X X X X X X X X X
1 0 X X X X X X X
X X X X X X X X X X
1 1
X X X X X X X X X X
For a given supported combination, the UE also supports all the subsets of radio
bearer combinations. For instance, if bit 7 = 1 and bit 20 = 1, the combination 2×AM
+ 3×UM is supported.
If IE featureGroupIndicators is not sent by the UE, the eNB assumes that all the radio
bearer combinations are supported (equivalent to both bit 7 and bit 20 in IE
featureGroupIndicators set to 1).
When more than 1 UM is supported, up to 2 VoIP bearers can be established.
When SPS is configured for a given UE, the eNB sends an RRC Connection
Reconfiguration message.
When this feature is deactivated (i.e. when isSpsConfigAllowed is set to “False”)

and 2 VoIP bearers are established, both bearers are managed by the dynamic
scheduler.
Note that requested combinations not supported by the UE are rejected.
Page 48/472
Restriction: Support of VoIP LR13.x
In LR13.1, VoIP is not supported in both 1.4MHz and 3MHz bandwidth systems.
Restriction: UE Categories
In LR13.x, only UE categories 2, 3 and 4 as defined in 3GPP are supported on

their maximum capabilities. UE categories 5 are also supported but not on their
maximum capabilities, meaning that UEs of category 5 are accepted but managed
internally as category 4 UEs.
UE Category TBS_Max_2_Codewords TBS_Max_1_Codeword

Category 2 51024 51024
Category 3 102048 75376
Category 4 150752 75376
Table 2: Downlink UE category characteristics
UE Category TBS_Max Total layer 2 buffer sizes

Category 2 25456 700 000
Category 3 51024 1 400 000
Category 4 51024 1 900 000
Table 3: Uplink UE category characteristics
Note that in LR13.1, only UL MCSs 1-22 are supported, which imposes limits on the
number of PRBs that can be allocated to a given UE (see section 7 for more details).
The list of RRC Connected users is further referred to as the RRCConnectedUserList

whereas the list of bearers per connected user is further referred to as the
UEbearerList.
Note that in the RRCConnectedUserList , a UE context is identified by its C-RNTI.
4.1 UE CATEGORY 4
In LA6.0, eNB fully supports UE Category 2 and 3, but does not reject UE Category 4
and 5 (but with no extra performance gain compared to UE Category 3).
Page 49/472
Starting LR13.1 (CL4?), feature L116365 adds FULL support of UE Category 4. UE

Category 5 will then be handled as UE Category 4.
Downlink performance expectation for single UE Category 4 test is:
o DL Peak radio bit rate for one UE: 150.8 Mbps (per TTI DL peak rate for
20MHz, 2x2 MIMO when a category 4 (or category 5) UE is under very good
RF condition, when CFI=1 is allowed by MIM configuration).
o DL Peak radio bit rate per cell: 150.8 Mbps.
o DL Maximum Transport Block Size is unchanged: 75376 bits per layer (for 2
Codewords: 150752 bits).
Support of UE category 4 is enabled via the activation flag:
ActivationService::isUeCategory4Allowed.
Table below shows downlink physical layer parameter values set by the field UE
Category as per 3GPP (highlighted in different colors are differences between
categories 3 and 4; again, only categories 2, 3 and 4 are supported on their
maximum capabilities):
And table below shows uplink physical layer parameter values set by the field UE
Category as per 3GPP (there is no change in UL between Category 3 and Category
4 UEs):
Page 50/472
The table for total Layer2 buffer sizes set by the field UE Category is:
ActivationService::isUeCategory4Allowed
Parameter isUeCategory4Allowed
True/False
Feature L116365
4.2 FORCED DRX MANAGEMENT

Forced DRX is used for:
• Intra LTE ANR (LTE neighbor cell ECGI reporting)
• CSFB (inter-RAT measurement)
• Inter RAT UTRA ANR (UTRA neighbor cell CGI reporting).
Note that short DRX is not supported in LR13.1.

When configured with DRX, the UE can get into DRX mode either due to the
expiration of its DRX inactivity timer (which is restarted every time a grant for a new
UL or DL transmission is received by the UE) or due to eNB DRX MAC command
(forced DRX mode).
Page 51/472
When the UE enters the DRX mode, it monitors the PDCCH discontinuously (see
Figure 7).
[(SFN * 10) + subframe number] modulo (Long DRX Cycle) = DRX Start Offset
On Duration DRX Off
UE monitors PDCCH
DRX Cycle
OnDuration Timer LongDRxCycle

Range = 1 to 200ms Range = 10 to 2560 ms
Figure 5: Long DRX cycle and associated parameters
Note, however, that the UE does monitor PDCCH when in DRX off state for HARQ
retransmissions (when needed).
The UE can be configured to acquire the CGI (Cell Global Identification) information
of a UTRA Cell. For the UE to be able to do that, enough idle periods must be
created so that the UE can retune its receiver and read the information from the
UTRA cell. The reportCGI procedure can take several seconds, given that the
required information (LAC, RAC, list of PLMNs, CellId) is transmitted in SIBs with
repetition periods ranging up to several hundred milliseconds.
The maximum delay is limited by a supervision timer (T321). When T321 expires and
the UE has not yet sent a Measurement Report with all the required information, the
UE is required to send a Measurement Report with whatever information it has been
able to collect.
In the case of IRAT CGI acquisition, T321 is equal to 8s. Thus, multiple consecutive
DRX cycles are necessary. For intra-LTE ANR and CSFB, the UE could need up to 2
DRX cycles, so multi-cycle DRX can apply to all DRX applications, just the DRX
application for UTRA ANR requires many more cycles than that for intra-LTE ANR or
CSFB. In LA6.0, when DRX is used for CSFB or intra-LTE ANR, only one DRX cycle
is allowed. For Intra-LTE ANR T321 is equal to 1s but it never expires as only 1 DRX
cycle is used.
The DRX handling is unified among all DRX applications and is characterized as
follows in LA6.0:
• The Sounding Reference Signal (SRS) is only transmitted during the
OnDuration.
• PUCCH CQI/PMI/RI reporting is not aligned with DRX OnDuration.
Page 52/472
Also, parameter cqiMaskR9, if set to “True”, suppresses PUCCH

CQI/PMI/RI reporting outside the DRX OnDuration, even if the UE is not in
DRX mode (but with DRX configured).
Note that this parameter must be set to “False” to allow PUCCH CQI/PMI/RI
reporting outside the OnDuration and avoid losing the PUCCH CQI/PMI/RI
reports that are to be sent outside the OnDuration.
CellL1ULConf::cqiMaskR9
Parameter cqiMaskR9
True/False
Value False (see rule below)
Feature FRS 108084
Rule: Parameter cqiMaskR9
This parameter must be set to “False” to allow PUCCH CQI/PMI/RI reporting

outside the OnDuration and avoid losing the PUCCH CQI/PMI/RI reports that are
to be sent outside the OnDuration.
Page 53/472
Restriction: DRX cycle length and DRX On Duration timer
The OnDuration timer is equal to 50ms in LR13.1.

The (long) DRX cycle length values supported in LR13.1 for intra LTE ANR are
160 ms and 320 ms. This is configurable through parameter
LteIntraFrequencyAnr::drxCycleForReportCGI (see [Vol. 6]).
The (long) DRX cycle length values supported in LR13.1 for UTRA ANR are
160ms, 320ms and 1280ms. This is configurable through parameter
UtraAnr::drxCycleForReportCGI (see [Vol. 6]).
The (long) DRX cycle length values supported in LA6.0 for CSFB are 320 ms and
640 ms. The DRX cycle length is set so as to avoid interworking with Timing
Advance timer expiry:
• 640 subframes if timeAlignmentTimerDedicated is greater than 750
subframes and maxTimeAllowedForCsfbMobilityAttempt is greater
than 640 ms.
• 320 subframes if timeAlignmentTimerDedicated is set to 500
subframes or maxTimeAllowedForCsfbMobilityAttempt is less than
640 ms.
4.2.1 DRX CONFIGURATION AND DRX MODE ACTIVATION

When the eNB decides to configure the UE with DRX for the UE to be able to enter
DRX (immediately or later on), an RRC Connection Reconfiguration message is sent
to the UE. This message contains the setup of long DRX and the measurement
configuration.
The UE responds by sending an RRC Reconfiguration Complete message.
Note that at handover, the target eNB sends an RRC Connection Reconfiguration
message that disables the DRX. In LR13.3, DRX is also disabled for a UE with at
least one High Priority Access (HPA) bearer established.
After the UE is put into DRX mode and immediately into DRX Off state by the first
correctly received (DRX + TA) command, the UE wakes up to listen to PDCCH (i.e.
monitor PDCCH) in every subsequent DRX OnDuration till it gets out of the DRX
mode. Note, however, that if UL data/signaling become available in the UE, the latter
sends a Scheduling Request (SR) at the earliest SR configured opportunity and
starts monitoring the PDCCH. The eNB looks for SR at the configured opportunity for
the UE irrespective of the DRX mode. When eNB detects SR, it considers the UE for
UL scheduling.
Page 54/472
Note that after the DL scheduler gets the UE into DRX mode (i.e. when an ACK is
received for the first (TA+DRX) command):
• The DL scheduler starts a timer DRXModeTimer whose value is the number
of DRX cycles times the DRX cycle length. If the timer expires and the UE is
still in DRX mode, the DL scheduler considers scheduling a TA-only
command for transmission to the user (at the earliest OnDuration) in order to
pull the UE out of the DRX mode.
• A DRX command is sent during every subsequent OnDuration to bring UE to

DRX OFF state and maximize the UE total DRX OFF time during which UE
can perform a requested measurement.
Similar to the case of the first DRX command (i.e. the one that is used to get
the UE in DRX mode and immediately in Off state), a Timing Advance
command is appended to the DRX command sent (to a UE in DRX mode)
during the OnDuration period. This is to maintain the UE UL timing
alignment.
If the eNB fails to send the (TA+DRX) command to the UE during
OnDuration, then the UE will only go back to DRX Off state when the
OnDuration expires.
4.2.2 DRX MODE DEACTIVATION

The UE gets out of the DRX mode if it receives an UL or DL grant:
On the other hand, the Downlink Scheduler terminates the DRX mode when one of
these events occurs:
• A measurement report or (more generally) UL (SRB or DRB) data are

received. The downlink scheduler detects the end of the DRX mode when
the (scheduled) UL data are received by the RLC entity.
• DL fresh data (SRB or DRB) become available in the DL RLC buffer. In this
case, the eNB tries to send a TA-only command to pull the UE out of DRX at
the first OnDuration following this event (i.e. DL fresh data becoming
available in the RLC buffer).
• Timer DRXModeTimer expires (i.e. the maximum number of cycles is reached
and the last cycle ends). In this case, the eNB tries to send a TA-only
command to pull the UE out of DRX at the first OnDuration following the
expiration of this timer.
Note that after the UE gets out of the DRX mode, it resumes monitoring PDCCH
continuously (i.e. the way it did before it got in the DRX mode). However, DRX
remains configured in the UE and if a DRX command is received again, it will get
back into the DRX mode.
Page 55/472
4.3 INACTIVITY BASED DRX MANAGEMENT

The inactivity based MAC-DRX is introduced by LR13.1 L165531 feature. The
objective of the feature is to extend the UE battery life.
This is achieved by sending the UE into a DRX connected mode. This mode is
defined by three states, referred to as OnDuration, StayActive, and Off. The Off
state provides the battery savings by allowing the UE to temporarily switch off the
receiver and transmitter for a period of time. During this period the UE will stop
monitoring PDCCH and stop sending the channel quality feedback and channel SRS.
Inactivity Timer Not Running Or expired
OnDurationTimer expired
#ShortCycles > ShortCycleTimer
ShortCycle OFF LongCycle

DLS & ULS OnDuration StayActive
Inactivity Timer Restarts

OnDuration Starts
OnDuration Starts
Figure 5: DL & UL Scheduler state machine used to control

scheduling traffic of user
DRX state machine in above figure is used by DLS and ULS to control the traffic
scheduling of the user.
Short description of the three states:
OnDuration is defined by DRX configuration, starts from drxStartOffset and lasts till
OnDurationTimer expires.
StatyActive includes all active time beyond OnDuration when inactivity timer is still
running.
OFF state is when UE stops monitoring PDCCH grants associated with its CRNTI,
PUCCH/PUSCH TPC-RNTI and SPS-RNTI. Only when there is no traffic activity in
either direction for the last InactivityTimer duration between two adjacent
OnDurations. UE not eligible to be scheduled in DL. The call is ONLY eligible to be
scheduled in UL for SR grants.
State Description
Definition: The OnDuration timer is running
DLS & ULS Behavior:
• Allowed to schedule new UL grants or new DL assignments
OnDuration
Note: DRX long cycle offset shall be configured such that P-CQI/PMI/RI transmission
and SRS transmission is aligned with OnDuration in 5ms after the onDuration offset
Definition: (The OnDuration timer has expired AND the inactivity timer is running) OR
(ULS buffer occupancy is not empty*)
StayActive DLS & ULS Behavior:
• Allowed to issue new UL grants or DL assignments
Page 56/472
* Most likely due to a detected SR
Definition: The OnDuration timer has expired AND the inactivity timer has expired
AND the ULS buffer occupancy is empty AND (the short cycle timer is running
(ShortCycle substate)or has expired (LongCycle substate))
ULS Behavior:
• Not allowed to schedule any new UL grants but UL HARQ retransmissions
are still allowed
• If an SR is detected, increase buffer occupancy (BO) estimate by the amount
ulBOIncreaseUponResourceRequest
• If a PUSCH packet is successfully received, restart the inactivity timer
• Not to request A-CQI from the UE
• Freeze or gradual decay SRS SINR metrics
• Block PUCCH/PUSCH TPC command via DCI3 for the UE
OFF • Suppress periodic BO increase associated with any radio bearers
[LongCycle]
• The UL Sync detection state machine shall be frozen with associated state
timer frozen (if any). If the UE is in OOS state and the OOSTimer is running,
the time associated with the DRX OFF should be discounted from the
OOSTimer (the OOSTimer is frozen when UE is in DRX OFF)
DLS Behavior:
• Not allowed to schedule any new DL assignments but DL HARQ
retransmissions are still allowed
• Pre-filter all bearers of the UE from scheduling including PDCCH order when
required
• If a P-CQI/PMI/RI transmission falls into the DRX OFF period, the P-
CQI/PMI/RI transmission shall be regarded as an erasure regardless the L1
report
OnDuration and StayActive collectively are called ActiveTime. During ActiveTime

UE must monitor PDCCH continuously and transmit any configured P-CQI reports
and SRS. The user is eligible to be scheduled on both DL/UL.
When the inactivity timer expires while the user is not in OnDuration, the call is
transitioned to OFF state.
inactivityTimer expires, or a DRX-
MAC CE is issued
Verification failure
New UL pkt or DL ACK/ New UL pkt or DL ACK/
Running Verification NotRunning
NACK received. Restart NACK received. Start
inactivity timer DL/UL new
inactivity timer grant sent, or
SR received.
Figure 6: Companion state machine to monitor the inactivity timer

Another state machine to monitor the inactivity timer is also needed:
Three states are defined:
Page 57/472
• Running: the inactivity timer has been started or restarted and it is running,
not expired yet. When IT is in this state, the call is in ActiveTime for sure.
• Verification: inactivity timer is not running yet, but the cell is verifying the
trigger(s) that will lead to start/restart of the timer. When IT is in this state,
regardless the call DRX state, the L1 metrics received by eNB are processed
by L2.
The verification is passed when the cell received an ACK or NACK from UE
associated with a DL new packet transmission, or the cell successfully decoded a
PUSCH packet. At that time, the inactivity timer is restarted and the state machine
moves to “Running”.
The verification is failed when the cell has exhausted all HARQ transmissions but not
received any indications listed above. At that time, the state machine moves back to
“NotRunning”.
• NotRunning: the inactivity timer has expired and is not running.

The reason to have the “verification” state is to avoid eNB/UE state mismatch where
eNB thinks UE is active but UE is already in dormant because UE missed the grant,
or eNB has a false-detection of SR on UL. When this mismatch happens, eNB may
try to send DL pkts to UE in vain and cause unnecessary packet loss and RF
resource waste.
Restriction: Inactivity based MAC DRX and SPS
The Inactivity based DRX is not supported when SPS (Semi-Persistent Scheduler)
is enabled on a call.
Restriction: Inactivity based MAC DRX and TTI Bundling
The Inactivity based MAC DRX cannot be enabled for users with TTI-bundling
configuration.
Restriction: Inactivity based MAC DRX and Measurement Gap
Because Measurement Gap(MG) implies DRX in the cell edge for other inter
frequency or IRAT neighbours the Inactivity based MAC DRX shall not be setup
when MG is configured and when MG needs to be configured the Inactivity based
MAC DRX shall be deconfigured.
Page 58/472
Restriction: VoLTE optimization with MAC DRX feature activation

When MAC DRX improvement feature is activated, QCI5 and QCI1 priorities
(logicalChannelPriorityDL) must be reversed inside MIM template to enable
feature activation:
ActivationService::isInactivityBasedDrxEnabled
Parameter isInactivityBasedDrxEnabled
True/False
Feature FRS 128003
This parameter activation flag will control whether or not inactivity based MAC-DRX
is activated or not.
InactivityBasedDrxConf::drxInactivityTimer
Parameter drxInactivityTimer
Object ENBEquipment/Enb/ DedicatedConf/InactivityBasedDrxConf
{ psf10, psf20, psf40, psf60, psf80, psf100, psf200, psf300,
psf500, psf750, psf1280, psf1920, psf2560}
Value Default: psf200
Feature FRS 128003
Engineering Recommendation: Parameter drxInactivityTimer

This parameter is set for every InactivityBasedDrxConf object.
For the object assigned to the ID corresponding to VoIP bearer ( QCI1 ) the
recommended value is psf2560.
Actual timer value of 2 ms is mapped to parameter value of psf2560. In LR14.1
release to be corrected as psf2 will be introduced in the range and mapping will
be aligned accordingly.
The 2ms inactivity timer for VoiP bearer is set in accordance with feature 173569
VoLTE optimization with MAC DRX to improve UE battery life .This will provide an
extra gain in UE battery life with active voice call.
Above parameter specifies the traffic inactivity time beyond which UE can go to DRX
dormant to save battery.
Page 59/472
InactivityBasedDrxConf::longDRXCycle
Parameter longDRXCycle
{ sf20, sf40, sf80, sf160, sf320, sf640, sf1280, sf2560}
Value Default: sf320
Feature FRS 128003
Engineering Recommendation: Parameter longDRXCycle

This parameter is set for every InactivityBasedDrxConf object. For the object
assigned to the ID corresponding to VoIP bearer ( QCI1 ) the recommended value
is sf40.
InactivityBasedDrxConf::onDurationTimer
Parameter onDurationTimer
{ psf5, psf10, psf20, psf30, psf40, psf50, psf60, psf80, psf100,
psf200}
Feature FRS 128003
InactivityBasedDrxConf::shortDRXCycle
Parameter shortDRXCycle
{ sf0, sf20, sf40, sf80}
Value Default: sf0
Feature FRS 128003
Restriction: shortDRXCycle
The shortDRXCycle is disabled in LR13.1 so this value will be ignored.
Page 60/472
InactivityBasedDrxConf::drxShortCycleTimer
Parameter drxShortCycleTimer
[1…16] step 1
Value Default: 4
Feature FRS 128003
Restriction: drxShortCycleTimer
The drxShortCycleTimer is disabled in LR13.1 so this value will be ignored.
InactivityBasedDrxConf::drxRetransmissionTimer
Parameter drxRetransmissionTimer
{ psf1, psf2, psf4, psf6, psf8, psf16, psf24, psf33}
Feature FRS 128003
This parameter specifies the time UE needs to stay active after the HARQ RTT (8ms
for FDD) associated with a packet transmission that has failed the HARQ before the
maximum HARQ transmissions are exhausted.
Above parameters are standard configuration parameters that need to be sent to UE

for DRX operation
InactivityBasedDrxConf::trafficBasedContextReleaseTimer
Parameter trafficBasedContextReleaseTimer
Range & Unit Float
[1…1080] step 0.1, seconds
Value Default: 10
Feature FRS 128003
This parameter specifies the desired RLC dormancy timer when the DRX
configuration is activated on the UE.
Page 61/472
InactivityBasedDrxConf::dlOnDurationPriorityBoost
Parameter dlOnDurationPriorityBoost
[0…16] step 1
Value Default: 4
Feature FRS 128003
CarrierAggregationSecondaryConf::dlOnDurationPriorityBoostForCABearer
Parameter dlOnDurationPriorityBoostForCABearer
ENBEquipment/Enb/LteCell/CarrierAggregationConf/Carrier
Object
AggregationSecondaryConf
[0…16] step 1
Value Default: 4
Feature 160847
This parameter specifies the extra DLS priority boost when considering the bearer for
scheduling within the OnDuration, when the user has DRX configured.
DRX configuration parameters are also configurable for each traffic class (QCI).
If UE has opened multiple bearers, the configuration that’s associated with the
highest priority QCI will be taken as the DRX configuration for the user.
TrafficRadioBearerConf::isInactivityBasedDrxConfigured
Parameter isInactivityBasedDrxConfigured
True/False
Default: True
Value
Feature FRS 128003
Page 62/472
This parameter indicates whether traffic inactivity based DRX is allowed when the
user has opened a traffic radio bearer of this QCI.
Engineering Recommendation: Parameter isInactivityBasedDrxConfigured

This parameter specifies whether the TRB allows inactivity based DRX to be
configured. This parameter should be unset if the parameter
ActivationService::inactivityBasedDrxEnabled is set to FALSE.
Parameter PerformanceManagement::inactivityBasedDrxReported specifies

whether or not the group of counters related to InactivityBasedDrx is selected to be
reported.
CellL1ULConf::srsSINRThresholdForReliableDetection
Parameter srsSINRThresholdForReliableDetection
Range & Unit Float
[-20…0] step 0.1 dB
Class/Source B--Cell / system_reserved
Default: -8
Value
Feature FRS 128003
This parameter specifies the measured SRS SINR (w/o any power compensation)
threshold beyond which the SRS detection is regarded as reliable hence can be used
for L1/L2 metric update purpose such as UL SINR, TA tracking and OOS detection.
Parameter dlPCQIValidityWindow specifies the validity window for a CQI/PMI/RI

report. In case of CQI/PMI/RI report erasure, DLS will assume the report to be the
same as last reported value if it falls in the validity window of the last reported value
(see 4.5.3.4.1).
Parameter dlSINRDecayUponPCQIErasure specifies the assumed DL SINR rate of

reduction (db/sec) and applies value of dlPCQIValidityWindow ms after the last valid
PCQI is received (see 4.5.3.4.1).
Page 63/472
4.3.1 INACTIVITY BASED DRX CONFIGURATION AND DRX

MODE ACTIVATION
The DRX parameters can be configured by the eNB via following messages: RRC
Connection Reconfiguration, RRC Connection Re-establishment, or Handover
Preparation Information messages.
The DRX is configured for the call only if all DRBs of the call support DRX operation.
eNB never sends a dedicated RRC reconfiguration message to UE for DRX
configuration( always sent along with other UE configurations in a single RRC
reconfiguration message)
The MAC-DRX mode shall be triggered by “PDCCH inactivity”, more exactly when
the associated timer expires.
Configuration of DRX will occur in the following scenarios:
As soon as one or more bearers is/are successfully established for the UE

supporting DRX whilst bearer(s) established all allow inactivity based DRX operation.
This can be upon S1 Initial Context Setup Request, E-RAB Setup Request or E-RAB
Release Command;
Incoming handover ( intra-eNodeB, X2 HO, S1 HO or PS HO from UTRA), when a

UE supporting DRX have all data bearers as allowing DRX configuration in the cell.
This includes handovers with partial CAC failures and partial S1 Path Switch;
RRC Re-establishment for a UE that supports DRX with all data bearers allowing
DRX configuration.
Reconfiguration of DRX will occur in the following scenarios:
During the call, one data bearer is added into a call running with DRX, the nearly
added data bearer also allows the DRX operation but changes the decision of DRX
configuration for the user.
During the call, one data bearer is left from a call running with DRX, and the decision
of DRX configuration is changed for the user.
Incoming handover (intra-eNodeB, X2 HO, S1 HO or PS HO from UTRA), when the

target cell determines that the UE supporting DRX have all admitted data bearers as
allowing DRX configuration in the cell, but the DRX configuration is different from the
one configured in the source cell.
4.3.2 DRX MODE DEACTIVATION

DRX state is abandoned when: the UE sends a Scheduling Request (the UE can use
any SR opportunity) or the UE decodes an UL grant or DL assignment for a new
transmission (during an OnDuration).
Page 64/472
eNB will release the DRX configuration in the UE via RRC Connection
Reconfiguration and deactivation in the modem will occur in the following scenarios:
As soon as a bearer that does not allow DRX configuration is added for a UE
configured with DRX;
Incoming normal handover, when UE is currently configured with DRX and the
feature is deactivated in the cell. In this case, the release is only towards the UE.
Note that in case of re-establishment or ‘full configuration’ handover, UE will
automatically release the DRX configuration, so there is no need to release it through
RRC signaling.
4.4 MEASUREMENT GAPS

The Measurement Gaps feature is activated/deactivated by parameter
isMeasurementGapsAllowed. It is a complement of the inter-RAT and inter-
frequency mobility features (described in [Vol. 6]) as it allows the UE to enter in
measurement periods on other RAT/LTE carriers. This is achieved by the creation of
measurement gaps.
A Measurement Gap (MG) is a small periodic time interval during which there is no
DL transmission and no UL transmission for the UE.
As shown in Table 4, there are 2 Gap pattern configurations, one with a

Measurement Gap Repetition Period (MGRP) of 40ms and another one with an
MGRP of 80ms. Both patterns have a Measurement Gap Length (MGL) of 6ms.
Gap Pattern Id Measurement Gap Measurement Gap Repetition Period

Length (MGL) in ms (MGRP)
0 6 ms 40 ms
1 6 ms 80 ms
Table 4: Gap Pattern configurations
The Gap pattern is configured by parameter measurementGapsPattern. Note,

however, that when MG is activated on CSFB trigger, the period is hardcoded to 40
ms regardless of the setting of parameter measurementGapsPattern (see [Vol. 6]).
The starting position of the Measurement Gap in a given MG period is defined by the
UE-specific Measurement Gap Offset (MGO). The latter is determined so that the UE
performance is degraded as little as possible by Measurement Gaps. This is
achieved by choosing the MG Offset so as to minimize the collision of MGs with the
other periodic transmissions:
Page 65/472
• CQI/PMI/RI reporting (UL)

• SRS transmissions (UL)
• ACK/NACK transmissions on PHICH (DL) and PUCCH (UL) (except the last
ACK/NACK, i.e. when the max number of retransmissions has been
reached).
• QCI1 transmissions.
• D-BCH transmissions (SIBs) (DL)
Note that the MGOs of the different UEs are also chosen so that their different MGs
are distributed over time so that during the MG of some UE, a sufficient number of
other UEs can transmit (and receive) and the total cell throughput performance is not
degraded.
Note that the MG offset is in the set {0, 1,..., 39} in Gap Pattern 0 (40ms periodicity
measurementGapsPattern = length6ms_period40ms) and in the set {0, 1, ..., 79} in
Gap Pattern 1 (80ms periodicity measurementGapsPattern =
length6ms_period80ms).
Interaction with TTI bundling

Due to the low number of subframes that can provide an opportunity for a TTI
bundling 1st HARQ transmission when the measurement gap period is set to 40ms,
the measurement gap period is forced to 80ms when the UE is configured with
Measurement Gap while TTI-bundling is activated.
Interaction with DRX

If the DRX command is to be sent in the same TTI where the Measurement Gap
starts, it is delayed by up to 10 ms (i.e. the Off Duration will be shorter by up to 10
ms). Thus, MGs have priority over DRX.
Interaction with SPS

The SPS is compatible with MG. If SPS is configured for a UE when MG feature is
activated, SPS will not be activated for that UE till MG is de-activated. If there is an
ongoing activated SPS when MG feature is activated, the SPS release procedure will
be initiated. In both of the above scenarios, VoIP bearer traffic is handled by the
Dynamic Scheduler till MG is de-activated.
Page 66/472
4.5 DOWNLINK SCHEDULER

The main role of the downlink scheduler is to efficiently manage and allocate the
available downlink resources to the UEs having contexts in the DL
RRCConnectedUserList.
The DL UE context contains:
• The UE C-RNTI
• The UE category.
• The UE DL AMBR. The value is provided at connection setup but can also
be modified on the fly by CallP for an already connected UE (see “E-RAB
modify” section in [Vol. 5]).
• The UE bearers list UebearerList.
• The UE MG status. The latter consists of the following 3 parameters:
o MgActive: Flag indicating if MG is active for the UE.
o MgPeriod: Measurement Gap Repetition Period, derived from
parameter measurementGapsPattern.
o MgOffset: MG Offset of the UE.
In the UEBearerList, a bearer context is identified by the Logical Channel Identifier

(LCID) of the logical channel it is mapped onto. The bearer context also contains the
bearer’s configuration, which consists of:
• The initial MCS to be used at bearer setup, configured by either

TrafficRadioBearerConf::macInitialMCSIndexForBearerSetupDl or
SignalingRadioBearerConf::macInitialMCSIndexForBearerSetupDl
(depending on whether it is a data radio bearer or a signaling radio bearer).
• The transmission mode allowed for the bearer, configured by
TrafficRadioBearerConf::macMIMOModeDl
SignalingRadioBearerConf::macMIMOModeDl or
CarrierAggregationSecondaryConf::macMIMOModeDl (depending on
whether it is a data radio bearer, a signaling radio bearer or a CA bearer (in
SCell)).
• The maximum number of transmission attempts per Transport Block of the
bearer, configured by
TrafficRadioBearerConf::macHARQMaxNumberOfTransmissionDl,
SignalingRadioBearerConf::macHARQMaxNumberOfTransmissionDl or
CarrierAggregationSecondaryConf::macHARQMaxNumberOfTransmiss
ionDl (depending on whether it is a data radio bearer, a signaling radio
bearer or a CA bearer (in SCell)).
Page 67/472
• The HARQ process timer, configured by

TrafficRadioBearerConf::macHARQMaxTimerDl,
SignalingRadioBearerConf::macHARQMaxTimerDl or
::macHARQMaxTimerDl (depending on whether it is a data radio bearer, a
signaling radio bearer or a CA bearer (in SCell)). It is started at the time of
the first transmission of the HARQ process in question. On its expiry, the
HARQ process is killed. A process is also killed after the maximum number
of transmissions for that process is reached. After a process is killed, all the
related allocated resources are freed.
• The VoIP flag (set to “True” if the QCI received from the MME over the S1-C
is equal to 1).
• The downlink GBR of the bearer (derived by CallP from QoS received from
the MME over the S1-C). The value is provided at bearer setup but can also
be modified on the fly by CallP for an on-going call.
• The downlink MBR of the bearer. This internal parameter is either ignored (if
the VoIP flag is set to true or if the GBR is set to 0) or forced to the value of
the GBR.
• The SINR offset that is used by the MCS allocation algorithm for the bearer
in question (see section 4.5.3.9), configured by
TrafficRadioBearerConf::macSINROffsetForLinkAdaptationDl,
SignalingRadioBearerConf::macSINROffsetForLinkAdaptationDl or
CarrierAggregationSecondaryConf::macSINROffsetForLinkAdaptation
Dl (depending on whether it is a data radio bearer, a signaling radio bearer
or a CA bearer (in SCell)).
• The BLER target used by the Link Adaptation algorithm for the bearer in
question (see section 4.5.3.9), configured by
TrafficRadioBearerConf::macOuterLoopBlerControlTargetBlerDl,
SignalingRadioBearerConf::macOuterLoopBlerControlTargetBlerDl or
CarrierAggregationSecondaryConf::macOuterLoopBlerControlTargetBl
erDl (depending on whether it is a data radio bearer, a signaling radio bearer
or a CA bearer (in SCell)).
• For data radio bearers, the Packet Delay Budget (PDB) associated with the
QCI of the bearer in question, configured by parameter
TrafficRadioBearerConf::packetDelayBudget or
CarrierAggregationSecondaryConf::packetDelayBudget (depending on
whether it is a CA bearer (in SCell)) as explained in section 3.1.2.
• For data radio bearers, the priority used by the downlink scheduler to
schedule the bearer, configured by parameter
TrafficRadioBearerConf::logicalChannelPriorityDL or
CarrierAggregationSecondaryConf::logicalChannelPriorityDL
(depending on whether it is a CA bearer (in SCell)). As explained in section
3.1.2, this priority is used to schedule a packet whose waiting time has
reached (or exceeded) the bearer QCI’s PDB.
Page 68/472
In the case of an SPS VoIP bearer, parameters

macInitialMCSIndexForBearerSetupDl, macMIMOModeDl,
macHARQMaxNumberOfTransmissionDl, macHARQMaxTimerDl, DL MBR,
macSINROffsetForLinkAdaptationDl, macOuterLoopBlerControlTargetBlerDl,
packetDelayBudget and logicalChannelPriorityDL are ignored and another set of
parameters is used instead:
• The initial MCS to be used at call setup , configured by parameter
DownlinkSemiPersistentSchedulingConf::spsInitialMCSIndexForBearer
SetupDl
• The number of HARQ processes dedicated to SPS, configured by parameter
DownlinkSemiPersistentSchedulingConf::numberOfConfSPSProcesses
Dl.
• The maximum number of HARQ attempts for SPS transmissions
DownlinkSemiPersistentSchedulingConf::macHARQMaxNumberOfTran
smissionWithSPSDl. It is impacted by the number of HARQ processes
dedicated to SPS.
• RoHC Status; this parameter is used to select the TBS for SPS (see section
4.5.3).
• The maximum time allowed for the completion of a HARQ process for SPS,
configured by parameter
DownlinkSemiPersistentSchedulingConf::macHARQMaxTimerWithSPS
Dl. It is impacted by the number of HARQ processes dedicated to SPS.
• The maximum value of BLER that is acceptable during a SPS Active phase,
configured by parameter
DownlinkSemiPersistentSchedulingConf::blerMaxVariationForSPSDl.
(see section 4.5.2.4).
• The SINR threshold that is used to determine the MCS to be used for the
SPS activation, configured by parameter
DownlinkSemiPersistentSchedulingConf::spsLinkAdaptationSINROffse
tDl.
• The number of successive 20ms-periods during which the buffer of the SPS
bearer is not empty before activating SPS, configured by parameter
DownlinkSemiPersistentSchedulingConf::activityPeriodForSPSActivati
onDl.
• The number of successive 20ms-periods during which the buffer of the SPS
bearer is empty before releasing SPS, configured by parameter
DownlinkSemiPersistentSchedulingConf::inactivityPeriodForSPSRelea
seDl (see section 4.5.2).
• The amount of RLC and MAC overhead assumed to be used for downlink
VoIP frames, configured by parameter
DownlinkSemiPersistentSchedulingConf::macRLCOverheadDl.
• The maximum number of unsuccessful SPS activation attempts before
declaring the SPS activation as failed, configured by parameter
DownlinkSemiPersistentSchedulingConf::maxSPSReleaseAttemptsDl.
Page 69/472
• The maximum allowed SINR degradation when SPS is active, configured by

parameter
DownlinkSemiPersistentSchedulingConf::sinrMaxVariationforSPSDl. If
the SINR is reduced by more than this value, the SPS is released and the
VoIP packets are managed by the dynamic scheduler (see section 4.5).
• The guard time following UE context creation and during which the DL SPS
grants activation is not allowed. It is configured by parameter
DownlinkSemiPersistentSchedulingConf::spsActivationProhibitTimeUp
onCallSetupWithoutROHCDl. This is to give time to Link Adaptation to
converge.
• The guard time following SPS abnormal release and during which the DL
SPS grants activation is not allowed. It is configured by parameter
onSPSAbnormalReleaseDl.
• The guard time following SPS activation failure and during which the DL SPS
grants activation is not allowed. It is configured by parameter
onSPSFailureDl.
Also note that, similar to QoS classes for data bearers (i.e. a given QCI), identified by
parameter TrafficRadioBearerConf::qCI and the configuration of which is defined
by the other parameters under object TrafficRadioBearerConf, each of the 2
dedicated signaling radio bearer types (i.e. SRB1 and SRB2, identified by parameter
SignalingRadioBearerConf::sRBIdentity which takes value “1” for SRB1 and value
“2” for SRB2) has a configuration that is defined by the other parameters under
object SignalingRadioBearerConf. Two instances need to be generated (one for
SRB1 and another one for SRB 2).
Also, a user friendly-name of the SRB can be defined using the optional parameter
SignallingRadioBearerConf::signalingRadioBearerConfName.
DownlinkSemiPersistentSchedulingConf::spsInitialMCSIndexForBearerSetupD
l
Parameter spsInitialMCSIndexForBearerSetupDl
ENBEquipment/Enb/DedicatedConf/SemiPersistentScheduling
Object
Conf/DownlinkSemiPersistentSchedulingConf
[0..15]
Value 4
Feature FRS 114531
Page 70/472
DownlinkSemiPersistentSchedulingConf::numberOfConfSPSProcessesDl
Parameter numberOfConfSPSProcessesDl
Object
[1..2]
Value 2
Feature FRS 114531
DownlinkSemiPersistentSchedulingConf::macHARQMaxNumberOfTransmissio
nWithSPSDl
Parameter macHARQMaxNumberOfTransmissionWithSPSDl
Object
[1..5]
Value 5
Feature FRS 114531
Restriction: Parameter macHARQMaxNumberOfTransmissionWithSPSDl
If numberOfConfSPSProcessesDl is set to 1, then any setting of

macHARQMaxNumberOfTransmissionWithSPSDl that is higher than 3 would
be treated as the setting macHARQMaxNumberOfTransmissionWithSPSDl =3.
Page 71/472
DownlinkSemiPersistentSchedulingConf::macHARQMaxTimerWithSPSDl
Parameter macHARQMaxTimerWithSPSDl
Object
[1..40] ms
Value 40
Feature FRS 114531
Restriction: Parameter macHARQMaxTimerWithSPSDl
If numberOfConfSPSProcessesDl is set to 1, then any setting of

macHARQMaxTimerWithSPSDl higher than 20 (ms) will be treated as the
setting macHARQMaxTimerWithSPSDl = 20 (ms).
DownlinkSemiPersistentSchedulingConf::spsLinkAdaptationSINROffsetDl
Parameter spsLinkAdaptationSINROffsetDl
Object
Range & Unit Float
[-40..40] step = 0.25 dB
Value -1.00
Feature FRS 114531
Page 72/472
DownlinkSemiPersistentSchedulingConf::activityPeriodForSPSActivationDl
Parameter activityPeriodForSPSActivationDl
Object
[0..160] step = 20 ms
Value 60
Feature FRS 114531
SignalingRadioBearerConf::sRBIdentity
Parameter sRBIdentity
Object ENBEquipment/Enb/DedicatedConf/SignalingRadioBearerConf
[1..2]
Feature
SignalingRadioBearerConf::signalingRadioBearerConfName
Parameter signalingRadioBearerConfName
Range & Unit String of up to 64 characters

Feature
Page 73/472
TrafficRadioBearerConf::macInitialMCSIndexForBearerSetupDl
Parameter macInitialMCSIndexForBearerSetupDl
[0..28]
Feature FRS 92483
Parameter macInitialMCSIndexForBearerSetupDl
[0..28]
Feature FRS 92483
TrafficRadioBearerConf::macMIMOModeDl
Parameter macMIMOModeDl
{ mimoTwoLayersNotAllowed, mimoTwoLayersAllowed }
Value See section 4.5.3.1
Page 74/472
CarrierAggregationSecondaryConf::macMIMOModeDl
Object
Value See section 4.5.3.1
SignalingRadioBearerConf::macMIMOModeDl
Value mimoTwoLayersNotAllowed
Feature FRS 92483
When parameter macMIMOModeDl is set to “mimoTwoLayersNotAllowed”, the

transmission is done using one of the two 1-layer schemes (TxDiv or CL-MIMO 1
layer).
TrafficRadioBearerConf::macHARQMaxNumberOfTransmissionDl
Parameter macHARQMaxNumberOfTransmissionDl
[1..8]
Class/Source C--New-set-ups / eng_tunable
Feature 160847
Page 75/472
CarrierAggregationSecondaryConf::macHARQMaxNumberOfTransmissionDl
Object
[1..8]
Feature 160847
SignalingRadioBearerConf::macHARQMaxNumberOfTransmissionDl
[1..8]
Value 8
Feature
TrafficRadioBearerConf::macHARQMaxTimerDl
Parameter macHARQMaxTimerDl
[1..500] ms
Feature 160847
CarrierAggregationSecondaryConf::macHARQMaxTimerDl
Object
[1..500] ms
Feature 160847
Page 76/472
SignalingRadioBearerConf::macHARQMaxTimerDl
[1..500] ms
Value 94
Feature
Engineering Recommendation: Parameters sRBIdentity,

signalingRadioBearerConfName and
Two instances of object SignalingRadioBearerConf need to be generated (one

for SRB1 and another one for SRB 2). Each instance is identified sRBIdentity
sRBIdentity signalingRadioBearerConfName
1 SRB1
2 SRB2
The current recommended setting for

SignalingRadioBearerConf::macInitialMCSIndexForBearerSetupDl is as
follows
dlBandwidth sRBIdentity macInitialMCSIndexForBearerSetupDl
n6-1_4MHz 1 4
n6-1_4MHz 2 4
n15-3MHz 1 6
n15-3MHz 2 4
n25-5MHz 1 6
n25-5MHz 2 4
n50-10MHz 1 4
n50-10MHz 2 4
n100-20MHz 1 4
n100-20MHz 2 4
Page 77/472
Rule: Regarding parameter

With the introduction of dual bandwidth support within the same eNB by feature
L115616 (3 cells on one band and 3 others on a different band), parameter
SignalingRadioBearerConf::macInitialMCSIndexForBearerSetupDl needs to
be configured per band. However, this parameter is configured per eNB instead of
per cell. Therefore, in LR13.1, for a dual band/dual carrier eNB which uses
different bandwidths for the different bands/carriers, a hardcoded value is used in
place of the values that are configured for them using WPS/SAM, or NEM. The
hardcoded value is:
sRBIdentity macInitialMCSIndexForBearerSetupDl
1 6, 4, 4 and 4 for BWs 5MHz, 10MHz, 15MHz and

20MHz, respectively
2 4
If different values are required, then see the Feature Activation Procedures
document for the procedure to be used. In a later release, the data model will be
modified to allow entry of different values for two different bandwidths that are
supported on a single eNB.
See [Vol. 5] and [Vol. 3] for more details about dual band support (L115616).
Page 78/472
Engineering Recommendation: Parameters

TrafficRadioBearerConf::macInitialMCSIndexForBearerSetupDl,
TrafficRadioBearerConf::macHARQMaxTimerDl,
CarrierAggregationSecondaryConf::macHARQMaxNumberOfTransmissionD
l, CarrierAggregationSecondaryConf::macHARQMaxTimerDl
An instance of object TrafficRadioBearerConf needs to be generated for at least

the 9 standardized QCIs. Each instance is identified by parameter qCI.
The current recommended setting for parameters
TrafficRadioBearerConf::macInitialMCSIndexForBearerSetupDl,
TrafficRadioBearerConf::macHARQMaxTimerDl is as follows:
qCI macInitialMCSI macHARQMaxNu macHARQMax

ndexForBearer mberOfTransmis TimerDl
SetupDl sionDl
1 5 3 32
2 6 4 62
3 6 4 62
4 6 4 62
5 5 4 62
6 5 4 62
7 5 5 62
8 5 4 62
9 5 4 62
In case of Carrier Aggregation, the current recommended setting for parameters

CarrierAggregationSecondaryConf::macHARQMaxNumberOfTransmissionD
l, CarrierAggregationSecondaryConf::macHARQMaxTimerDl applicable to all
CA bearers in the SCell is respectively 4 and 62.
The downlink scheduler is split into 4 functional parts:

Page 79/472
• The Static Scheduler, which assigns resources to synchronization signals

and to the BCCH that goes over the BCH Transport Channel.
• The Semi-static Scheduler, which assigns resources to PCCH and D-BCH
logical channels, where D-BCH refers to the part of the BCCH logical
channel that is sent over the DL-SCH channel, as opposed to the BCH which
is sent over the PBCH. The semi-static scheduler also assigns resources to
MCH and to RACH message 2.
• The Semi-Persistent Scheduler, which assigns Semi-Persistent grants to

DTCH VoIP bearers established by UEs having indicated the support of
semi-persistent grants. Note that the support of SPS and that of TTI bundling
at the UE are indicated by FGI29 and FGI28, respectively.
• The Dynamic Scheduler, which assigns resources to DTCH (data bearers),
CCCH (SRB0) and DCCH (SRB1 and SRB2). The dynamic scheduler also
assigns resources to Timing Advance control messages.
Note that Semi-Persistent Scheduling of VoIP bearers are enabled/disabled by the

flag isSpsConfigAllowed. In LR13.1, this parameter enables/disables the feature
162790. This feature supports Semi-Persistent Scheduler over bCEM. The Semi-
Persistent Scheduler increases VoIP capacity beyond what is offered by the Dynamic
Scheduler. It also offers significant reduction in the PDCCH channel usage. The
PDCCH channel can become a bottleneck as VoIP traffic increases. The decrease in
PDCCH usage will allow more users to access a cell thereby increasing the
throughput of non-VoIP applications. This parameter can be enabled only if VoIP
licensing (LicensingMngtSystem/isVoIPEnabled) is enabled at eNB and bCEM
modem is available. The VoIP with SPS is supported regardless whether RoHC is
enabled or not. In LR13.1, a change of parameter value is taken into account when a
UE enters in a cell upon the following events: a) call establishment; b) call re-
establishment; c) incoming mobility. This means that the mode of an established
VoIP bearer doesn’t change until one of the events listed above occurs. This
parameter also covers the support of SPS for the second VoIP bearer. The support
for SPS on eCEM modem was introduced via trial / demo feature 114531.1 in LA4.0.
However, SPS was not supported on eCEM in both LA5.0, LA6.0 and is not
supported in LR13.1 and beyond. A WIPS check forbids the activation of SPS over
eCEM. The VOIP bearers will only use Dynamic Scheduler on eCEM. Hence, no
impact to VOIP capacity after loading LR13.1 in an eCEM only network (or with
bCEM with SPS disabled).All the parameters introduced by feature 114531.1 in
LA4.0 are (re)used by feature 162790. In LR13.1, SPS is supported in 5MHz,
10MHz, 15MHz, 20MHz bandwidth. SPS for both 1.4MHz and 3MHz bandwidths is
still not supported.
Also note that parameter isUeRel8EligibleToSps controls the eligibility of UE Rel8

to SPS. This parameter is only applicable when
ActivationService::isSpsConfigAllowed is set to “TRUE”. It should be noted that
some Rel8 UEs that support SPS (indicates SPS support via FGI bits) are 3GPP
non-compliant and not operating properly. Hence, this parameter must be set to
False in LR13.1 limiting SPS activation to Rel9 or post Rel9 UEs. The Rel8 UEs will
Page 80/472
be automatically treated in the Dynamic Scheduler (DS) when VoIP bearers are
setup.
ActivationService::isSpsConfigAllowed
Parameter isSpsConfigAllowed
True/False
Feature FRS 114531, FRS 115239.1, FRS 162790
Engineering Recommendation: Parameter isSpsConfigAllowed
The activation of the SPS Feature is controlled by licensing. The

isSpsConfigAllowed flag is defaulted to “False” in the ALU template. In LR13.1,
the activation also requires availability of the bCEM modem.
Restriction: Support of SPS and setting of isSpsConfigAllowed
In LR13.1, SPS is supported in 5MHz, 10MHz, 15MHz, and 20MHz bandwidth

systems. Therefore, the flag isSpsConfigAllowed should be set to “False” in
systems operating on BWs other than listed above. Note that SPS is still not
supported in 1.4MHz and 3MHz bandwidths.
Restriction: Max number of UEs in SPS
In LR13.1, SPS is not yet commercial. However, it is supported at a level good

enough for UE certification. In practice, this implies the introduction of some hard-
coding, among which the max number of UEs which can simultaneously be in
SPS in each cell: this number is hard-coded to 4 and applies also to LR13.3.
Page 81/472
Enb::isUeRel8EligibleToSps
Parameter isUeRel8EligibleToSps
True / False
Value False
Feature FRS 115239(.1), FRS 162790
PCCH BCCH CCCH DCCH DTCH MCCH MTCH

Downlink
Logical channels
Downlink
Transport channels
PCH BCH DL-SCH MCH
Figure 6: Mapping between downlink logical channels and downlink transport

channels
BCH MCH PCH DL-SCH

Downlink
Transport channels
Downlink
Physical channels
PBCH PMCH PDSCH PDCCH
Figure 7: Mapping between downlink transport channels and downlink physical channel
Page 82/472
Radio Bearers
ROHC ROHC ROHC ROHC

PDCP
Security Security Security Security
Segm. Segm. Segm. Segm.

RLC ... ...
ARQ etc ARQ etc ARQ etc ARQ etc CCCH BCCH PCCH
Logical Channels
Scheduling / Priority Handling
MAC Multiplexing UE1 Multiplexing UEn
HARQ HARQ
Transport Channels
Figure 8: Layer 2 structure in the downlink
Restriction: Downlink Bearer Multiplexing
In LR13.1, downlink bearer multiplexing is not supported, meaning that only one
bearer can be scheduled per TTI per UE (i.e. meaning that 2 bearers of the same
UE cannot be scheduled in the same TTI).
In resource allocation type 0, the RBs are grouped into Resource Block Groups
(RBGs), which are of variable sizes depending on the bandwidth:
RBG Size System Bandwidth
(P) DL
N RB
1 ≤10
2 11 - 26
3 27 - 63
4 64 - 110
Table 5: RBG groups in resource allocation type 0
RBG-based resource allocation can be wasteful for small VoIP packets in large
system BWs. However, since LA6.0, in order to improve the efficiency, PRB-based
resource allocation can also be activated for VoIP traffic on SPS and DS via
DownlinkSemiPersistentSchedulingConf::spsPerPRBAllocationActivation and
CellL2DLConf::voIPPerPRBAllocationActivation respectively. Starting LR13.1,
this PRB-based resource allocation is also available for DL common channels and
Timing Advance commands and activated via spare bits:
o Bit 0 of LteCell:spare5 (isRBAllocationForPCHEnabled), when set to ‘1’,
allow PRB-based resource allocation for Paging Channel.
o Bit 1 of LteCell:spare5 (isRBAllocationForSRB1_2Enabled), when set to ‘1’,
allow PRB-based resource allocation for SRB1 & SRB2.
o Bit 2 of LteCell:spare5 (isRBAllocationForSRB0Enabled), when set to ‘1’,
allow PRB-based resource allocation for SRB0.
Page 83/472
o Bit 3 of LteCell:spare5 (isRBAllocationForDBCHEnabled), when set to ‘1’,

allow PRB-based resource allocation for Dynamic Broadcast Channel.
o Bit 4 of LteCell:spare5 (isRBAllocationForTAEnabled), when set to ‘1’, allow
PRB-based resource allocation for Timing Advance commands.
The downlink scheduler uses a bitmap of Resource Blocks (RB),

DL
PhyResBlocOccupancy. This bitmap contains all the N RB RBs.
In the time domain, at each subframe (i.e. every 1 ms), the number of RBs available
in the PhyResBlocOccupancy bitmap is updated. In order to manage the time
domain, matrix TimeFrequencyResBlocOccupancy is defined. It is composed of a
certain number of successive PhyResBlocOccupancy bitmaps.
This matrix has a depth of 20ms (i.e. consists of 20 successive
PhyResBlocOccupancy).
Matrix TimeFrequencyResBlocOccupancy is shown in Figure 11 for a 5MHz

DL
bandwidth ( N RB = 25 RBs):
Figure 9: Time-Frequency resource occupation matrix
Each matrix element TimeFrequencyResBlocOccupancy[t][rb] is filled with a number

indicating the occupancy state of the RB in question (free, reserved, used).
Note that if resourceBlockPersistentAreaStart ≤

resourceBlockPersistentAreaEnd the DL scheduler does not allocate resources
Page 84/472
outside the PRB area [resourceBlockPersistentAreaStart,

resourceBlockPersistentAreaEnd] to DCCH (SRB1 and SRB2) or DTCH (data
bearers). Otherwise, (i.e. if resourceBlockPersistentAreaStart >
resourceBlockPersistentAreaEnd) the restriction is deactivated.
Also, two frequency reuse schemes can be configured depending on the cell
interference from neighbor cells:
• The 1/1 frequency reuse scheme with limited neighbor cell interference. In
this scheme, all PRBs of the bandwidth are used by each of the 3 cells of the
eNB. This scheme is further referred to as the “1/1F” scheme.
• The 1/3 frequency reuse scheme with non negligible neighbor cell
interference. In this scheme, in order to limit the interference between the
cells, nearly 1/3 of the PRBs can be used by each cell of the eNB. This
scheme is further referred to as the “1/3F” scheme and uses parameters
FrequencyAndBandwidthFDD::resourceBlockPersistentAreaStart and
FrequencyAndBandwidthFDD::resourceBlockPersistentAreaEnd to set
the PRBs used by each cell, an instance of object
ENBEquipment/Enb/LteCell (in which is contained object
FrequencyAndBandwidthFDD) being generated for each of cell of the eNB.
FrequencyAndBandwidthFDD::resourceBlockPersistentAreaStart
Parameter resourceBlockPersistentAreaStart
[0..98]
Feature
FrequencyAndBandwidthFDD::resourceBlockPersistentAreaEnd
Parameter resourceBlockPersistentAreaEnd
[1..99]
Feature
Page 85/472
Engineering Recommendation: Parameters

resourceBlockPersistentAreaStart and resourceBlockPersistentAreaEnd
The valid ranges are summarized in the in Table 6 below as a function of the
downlink bandwidth:
dlBandwidth resourceBlockPersistentAr resourceBlockPersistentAre

eaStart aEnd
n6-1_4MHz Valid range is [0..4] Valid range is [1..5]
n15-3MHz Valid range is [0..13] Valid range is [1..14]
Table 6: Dependencies between dlBandwidth and

In the 1/3 scheme, the capacity among the cells is not homogeneous due to the
downlink control channels, thus the setting of parameters
among the 3 cells must be configured in such a way that more RBs are given to
the cells with more downlink control channels.
The current recommendation is to set parameters

resourceBlockPersistentAreaStart and resourceBlockPersistentAreaEnd to 2
and 1, respectively (i.e. deactivate the frequency restriction).
4.5.1 STATIC SCHEDULER

The static scheduler is in charge of scheduling the transmission of information with
stringent timing constraints and regular usage of the resource.
In order to meet the timing and regular throughput constraints, the static scheduler
prebooks resources in the TimeFrequencyResBlocOccupancy matrix. These
resources are always used and thus can never be retrieved by the Dynamic
Scheduler.
The downlink static scheduler assigns resources to synchronization signals and to
the BCCH that goes over the BCH Transport Channel (i.e. the MIB) and is
transmitted over the PBCH (see [Vol. 3]).
Page 86/472
The static scheduler is configured at cell setup, and does only change with a cell
restart.
4.5.2 SEMI-STATIC AND SEMI-PERSISTENT SCHEDULER

The semi-static scheduler is in charge of scheduling the transmission of information
with stringent timing constraints and non-regular usage of the resource.
In order to meet the timing constraints, the semi-static scheduler prebooks resources
in the TimeFrequencyResBlocOccupancy matrix. As opposed to the static scheduler,
and due to the non-regular throughput required by this type of information, the
prebooked resources are not always used. When not used, the resources are freed
by the semi-static scheduler and retrieved by the dynamic scheduler.
The downlink semi-static scheduler assigns resources to:
• D-BCH
• RACH message 2.
• PCCH
• MCH
The downlink Semi-Persistent Scheduler assigns resources to SPS VoIP DTCH.
Note that D-BCH refers to the part of the BCCH logical channel that is sent over the
DL-SCH channel (SIBs), as opposed to the BCH which is sent over the PBCH (MIB).
Every subframe (1 ms), the semi-static scheduler checks if some D-BCH, PCCH, or
some RACH message 2 need to be sent in that particular subframe and decides
whether to use the prebooked resources or free them to the benefit of the dynamic
scheduler. After this phase, the RBs used by the semi-static scheduler are known for
the current subframe, and the management of the remaining RBs is transferred to
the dynamic scheduler.
4.5.2.1 D-BCH SCHEDULING
D-BCH carries System Information Blocks (SIBs).

In LR13.1, SIB1, SIB2, SIB3, SIB4, SIB5, SIB6, SIB7, SIB8 and SIB12 are
supported.
Page 87/472
Support of CMAS and SIB12

CMAS (Commercial Mobile Alert System) is an alert system (similar to ETWS) that
allows broadcasting short messages to UEs present in specific cells of the network
(see [Vol. 5] for more details). It relies on SIB12 transmission.
Two CMAS events are transmitted:

• CMAS-indication, on PCCH, indicating to UEs monitoring the Paging channel
that a CMAS transmission is started
• CMAS-notification, on PDSCH, carried in the SIB12 (SIB12), containing a
CMAS message (or message segment).
CMAS-capable UEs are notified of the need to read SIB12 by the CMAS-indication
message. The latter is transmitted in every Paging Occasion at the start of the CMAS
transmission.
SIB1 is modified with the addition of SIB12 (when CMAS transmission is started) or
the removal of SIB12 (when CMAS transmission ends). SIB1 is updated for CMAS
transmission at the end of a 80ms-cycle.
SIB12 transmission starts immediately after CMAS-indication and SIB12 addition to
SIB1 and ends when no more CMAS messages are to be transmitted and SIB12
removal from SIB1.
A single CMAS message can be splitted in several CMAS segments, each
transmitted in a different SIB12.
SIB12 contents can be updated at each SIB12 transmission, so different CMAS

messages (or segments of CMAS messages) can be successively transmitted.
4.5.2.1.1 SIB1,…, SIB8 SCHEDULING
SIB1 is scheduled as follows:

• sent when SFN modulo 8 = 0 (i.e. every 80ms), in subframe 5.
• repeated when SFN modulo 2 = 0 (i.e. every 20ms), in subframe 5 (3

repetitions).
4.5.2.1.2 SIB1,…, SIB8 AND SIB12 SCHEDULING
SIB2 through SIB8 and SIB12 are scheduled according to a scheduling class (1, 2 or
3) to which each SIB is assigned. See [Vol. 5] for the definition of the SIB scheduling
class parameters. Each scheduling class is defined with a periodicity and target
MCS:
Page 88/472
• targetperiodicity: 80, 160, 320, 640, 1280, 2560, and 5120 ms are the
possible values. This is configured by parameter
sibClass[1,2,3]TargetPeriodicity (see [Vol. 5]).
• targetMCS: 0 – 9 are the possible values (QPSK modulation schemes only).
This is configured by parameter sibClass[1,2,3]TargetMCS (see [Vol. 5]).
• SIBs of the same scheduling class are mapped to the same SI-message for
transmission. Large SI-messages may be split into smaller messages for
transmission, especially if they require more RBs than the number of
available RBs.
• transmission can occur at any subframe except MBSFN subframes and SIB1
subframes.
The targetMCS indicates the most robust MCS (the lower the better), with no
retransmission. Retransmissions may result in a higher MCS to be selected.
The parameter sib1TargetMCS configures the index of the most robust MCS that
can be used for SIB1 messages.
The parameters sibClass(1,2,3)TargetMCS configure the index of the most robust

MCS that can be used for SIB2 – SIB8 and SIB12 messages.
The MCS used is determined by a specific algorithm and selected from the set
[sib1TargetMCS, 9] for SIB1 and [sibClass(1,2,3)TargetMCS, 9] for SIB2, through
SIB8 and SIB12 according to the scheduling class (1,2,or 3) assigned to the SIB.
Note that the MCS range never goes outside the range [0, 9] for QPSK is mandatory
for the transmission of SI messages.
SysInfoConf::sib1TargetMCS
Parameter sib1TargetMCS
Object ENBEquipment/Enb/LteCell/SysInfoConf
[0..9]
Value 2
Feature FRS 108958
Page 89/472
SysInfoConf::sibClass1TargetMCS
Parameter sibClass1TargetMCS
[0..9]
Value 0
Feature FRS 108958
[0..9]
Value 0
Feature FRS 108958
[0..9]
Value 0
Feature FRS 108958
The size of each SI-message, combined with the MCS to use, gives the number of
RBs to allocate. This number is compared to the number of available RBs, which is
DL
given by ( N RB - numberRBnotForSIB) where numberRBnotForSIB is an OAM
parameter configuring the number of RBs that are not used for SIB scheduling and
DL
N RB is the total number of RBs in the spectrum:
Page 90/472
DL channel DL transmission
dlBandwidth DL
bandwidth bandwidth in RBs ( N RB )
n6-1_4MHz 1.4 MHz 6
n15-3MHz 3 MHz 15
n25-5MHz 5 MHz 25
n50-10MHz 10 MHz 50
n75-15MHz 15 MHz 75
n100-20MHz 20 MHz 100
A large SI message containing at least two SIBs may be split into smaller SI-
messages, where each SIB from the large SI-message is allocated to one of the
smaller SI-messages. The class parameters of the smaller SI-messages remain the
same as those of the larger SI-message. An SI-message may be split for the
following reasons:
• If the size of the SI-message is greater than 2216 bits (3GPP limitation, see
[R05]).
• If the SI-message requires more RBs than the number of RBs that are
DL
available for SIB scheduling ( N RB - numberRBnotForSIB).
After SI-messages have been splitted (if needed), if the number of RBs to allocate for
DL
an SI-message is still greater than ( N RB - numberRBnotForSIB), the MCS is
increased by 3, and a retransmission is scheduled (to account for the possible
increase in BLER due to the higher MCS), until the recalculated number of RBs to
DL
allocate is less than or equal to the ( N RB - numberRBnotForSIB).
For a given SI message, the starting position of the corresponding RB allocation

SIBRBstart is computed as
SIBRBstart = 0 + sectorNumber × resourceBlockShift
Where sectorNumber is used to indicate the logical sector number that supports the
instance of the LteCell object.
This is to achieve SIB frequency diversity and avoid inter-cell interference.
Note that SIBRBstart can be lowered so that a large SI message fits into the available
bandwidth.
Also, even though D-BCH is not aligned to RBG, full RBGs are allocated as partial
RBGs cannot be reused by the Dynamic Scheduler.
Page 91/472
At each SI retransmission SIBRBstart is increased by resourceBlockShift, modulo

the “SIB PRB area”
Note that SIB scheduling uses

pdcchAggregationLevelForNonCRNTIGrantsInCommonSearchSpace CCEs in
the Common Search Space.
CellL2DLConf::resourceBlockShift
Parameter resourceBlockShift
Object ENBEquipment/Enb/LteCell/CellL2DLConf
[0..96]
0 ALU recommends the operator to not change change this
Value
setting
Feature FRS 108958
SysInfoConf::numberRBnotForSIB
Parameter numberRBnotForSIB
[0..100]
Feature FRS 108958
Page 92/472
Engineering Recommendation: Parameter numberRBnotForSIB
The setting of this parameter should be as follows:
dlBandwidth numberRBnotForSIB
n50-10MHz, n75-15MHz, n100-20MHz 8
n6-1_4MHz, n15-3MHz , n25-5MHz, 0
Rule: Parameter numberRBnotForSIB
This parameter must be provisioned within the bandwidth limits (i.e. in the range
DL
[1.. N RB ]) and should be a multiple of the RBG size (see Table 5):
DL transmission numberRBnotForSIB
dlBandwidth bandwidth in RBs
DL
( N RB )
n6-1_4MHz 6 In the range [0..6]
n15-3MHz 15 In the range [0..15] and a

multiple of 2

multiple of 2

multiple of 3

multiple of 4

multiple of 4
4.5.2.2 RACH MESSAGE 2 SCHEDULING
The RACH message 2 frequency resources are defined as follows:

• The starting PRB index is configured by parameter rachMsg2StartRB.
• The number of PRBs is configured by parameter rachMsg2numberOfRB.
In other words (before LR13.3), RACH message 2 PRBs are [rachMsg2StartRB,

rachMsg2StartRB + rachMsg2numberOfRB -1].
In LR13.3, in order to sustain the increased connected users capacity (FRS166802),
the RACH msg2 can contain up to 2 (nbrOfRARsPerRACHCycle) Random Access
Response (RAR) plus a MAC subheader of backoff parameter when it is enabled.
Page 93/472
• The parameter rachMsg2SpectralEfficiency specifies the spectrum

efficiency in terms of bits per PRB that the RACH msg2 should be coded
with. (introduced in LR13.3)
The RACH msg2 PRB are:
Msg2NbrPRB = min(rachMsg2NumberOrRB,
ceil(Msg2PayloadInBits(i)/rachmsg2SpectrumEfficiency))
where Msg2PayloadInBits = nbrRARs * 7 + (raBackOff needed? 1: 0).
The RACH msg2 will be sent starting from PRB index rachMsg2StartRB.
Refer to [Vol. 3] for the RACH backoff description.
RACH 2 scheduling uses Aggregation Level 4 in the common search space. A power
offset is applied to the associated PDCCH message. In LR13.1, this power offset is
configured by the 9th entry of table parameter dlTargetSINRTableForPDCCH. The
latter is described in section 6.1.2.
Note that when there is no RACH activity, the message 2 PRB resources are freed
for reuse by the dynamic scheduler.
.
When MBMS is activated, the RACH1-RACH2 time offset is increased (unless the
unicast message 2 subframe is part of the subset {0, 4, 5, 9}) so that RACH message
2 is not sent in an MBSFN subframe. Table 7 gives the RACH1-RACH2 time offset
as a function of RACHMsg1SubFrameNumber and the PRACH format for both cases
(i.e. with and without MBMS). It is based on the maximum MBSFN subframe
allocation (sf 1, 2, 3, 6, 7, 8).
pRACHPreamble RACHMsg1SubFrameNumber RACHMessage1toMessage2Offset with

Format2Enabled MBMS
(RACHMessage1toMessage2Offset
without MBMS)
False 1 8 (7)
False 4 10 (7)
False 7 7 (7)
True 1 9 (9)
True 4 10 (9)
True 7 12 (9)
Table 7: RACH1-RACH2 time offset RACHMessage1toMessage2Offset values
Page 94/472
The MCS used for the transmission of RACH message 2 is the one that corresponds
to the lowest TBS that can fit RACH message 2 for a transmission over 2 or 3 PRBs.
CellRachConf::rachMsg2ForceMCSmin
Parameter rachMsg2ForceMCSmin
[-1..9]
-1 ALU recommends the operator to not change change this
Value
setting
Feature FRS 76501
CellRachConf::rachMsg2StartRB
Parameter rachMsg2StartRB
[0..99]
Feature FRS 115435
Page 95/472
Engineering Recommendation: Regarding parameter rachMsg2StartRB
The current setting of this parameter depends on the RACH format used:
- If pRACHPreambleFormat = ‘format0’, the following values are
recommended:
dlBandwidth rachMsg2StartRB
n6-1_4MHz 0
n15-3MHz 12
n25-5MHz 20
n50-10MHz 24
n75-15MHz 36
n100-20MHz 48
- If pRACHPreambleFormat = ‘format2’ or ‘format3’, only the following

values are allowed and hardcoded:
dlBandwidth rachMsg2StartRB
n25-5MHz 20
n50-10MHz 45
n75-15MHz 68
n100-20MHz 92
CellRachConf::rachMsg2NumberOfRB
Parameter rachMsg2NumberOfRB
[1..9]
Feature FRS 115435
Page 96/472
Engineering Recommendation: Regarding parameter

rachMsg2NumberOfRB
The current setting of this parameter is as follows:
dlBandwidth rachMsg2NumberOfRB
n6-1_4MHz 3
n15-3MHz 4
n25-5MHz 4
n50-10MHz 3
n75-15MHz 4
n100-20MHz 4
CellRachConf::rachMsg2SpectralEfficiency
Parameter rachMsg2SpectralEfficiency
[1..256]
Class/Source C--Cell / system_restricted
Value Default 19
Feature FRS 166802
4.5.2.3 PCCH SCHEDULING
The downlink scheduler buffers the paging requests then constructs a paging
message bearing one or more Paging Records (up to 16 in LR13.1) to be sent in the
same TTI. If some requests do not fit in the message, the scheduler postpones them
to the next Paging Occasion. Please refer to [Vol. 5] for details on how paging
occasions are determined.
In each frame, the semi-static scheduler prebooks a set of contiguous PRBs for
PCCH. The resources are prebooked in subframe 9. The number of prebooked
PRBs depends on the MCS and is limited to 6.
Page 97/472
Parameter pagingForceMCSmin configures the index of the most robust MCS that
can be used for SI messages. The MCS used is determined by a specific algorithm
and selected from the set [pagingForceMCSmin, 9] if parameter
pagingForceMCSmin is not set to “-1”. If, on the other hand, pagingForceMCSmin
is set to “-1”, MCS0 is used.
Note that regardless of the value of parameter pagingForceMCSmin, the MCS

range never goes outside the range [0, 9] for QPSK is mandatory for the
transmission of paging messages.
Parameter numberRBnotForPaging specifies the number of RBs that will not be

used in DL by Paging Messages, in the subframes where they are transmitted. This
is to limit the bandwidth allocated to PCCH and keep room for SPS and dynamic
allocation in the same subframes.
Note that PCCH scheduling uses

pdcchAggregationLevelForNonCRNTIGrantsInCommonSearchSpace CCEs in
the Common Search Space.
CellL2DLConf::pagingForceMCSmin
Parameter pagingForceMCSmin
[-1..9]
Value -1
Feature FRS 76501, FRS 115217.1
CellL2DLConf::numberRBnotForPaging
Parameter numberRBnotForPaging
[0..100]
Value 0
Feature FRS 115114
Page 98/472
Rule: Parameter numberRBnotForPaging
DL
DL transmission numberRBnotForPaging
dlBandwidth bandwidth in RBs
DL
( N RB )

multiple of 2

multiple of 2

multiple of 3

multiple of 4

multiple of 4
4.5.2.4 SPS VOIP DTCH SCHEDULING
When an SPS-VoIP bearer is setup. It is managed by the dynamic scheduler. The

Semi-Persistent Scheduler activation can only occur after the prohibit timer, started
at call setup, expires. This mechanism is used to allow the MCS allocation and BLER
Loop Control to converge to a good SINR estimation, and, if RoHC is enabled, to
allow the RoHC protocol to converge to the optimal compression. This timer is
configured by parameter spsActivationProhibitTimeUponCallSetupWithROHCDl
when RoHC is enabled and by parameter
spsActivationProhibitTimeUponCallSetupWithoutROHCDl when RoHC is not
enabled.
The MCS, SPS TBS and number of RBs are determined by the dynamic scheduler
(see section 4.5.3.10).
The Semi-Persistent Scheduler tries to find RB resources that fit the SPS TBS with
the selected MCS. These RBs must be PCCH-collision-free, MCH-collision-free and
DBCH-collision-free and available every 20th TTI.
In order to create diversity in the frequency domain and to avoid interference with
neighbor cells, the RBG search is started at a randomized position.
Page 99/472
In order to limit the SPS consumption for a given TTI, a maximum number of RBs to
be used for Common Control Channels together with SPS is defined. It is
configurable by parameter maxResourceBlocksPerTTIToLimitSPSAllocation.
The scheduler also checks that the number of PRBs allocated by SPS does not
exceed the value imposed by the PRB license for the current TTI.
When spsHARQProcessReuseForDSWhenSPSReleased is set to “True”, the

HARQ process is not allocated by the scheduler at VoIP setup but upon activation of
SPS.
DownlinkSemiPersistentSchedulingConf::spsActivationProhibitTimeUponCall
SetupWithoutROHCDl
Parameter spsActivationProhibitTimeUponCallSetupWithoutROHCDl
Object
[0..15000] step = 20 ms
Value 100
Feature FRS 114531
DownlinkSemiPersistentSchedulingConf::spsActivationProhibitTimeUponCall
SetupWithROHCDl
Parameter spsActivationProhibitTimeUponCallSetupWithROHCDl
Object
[0..15000] step = 20 ms
Value 1000
Feature FRS 114531
Page 100/472
CellL2DLConf::maxResourceBlocksPerTTIToLimitSPSAllocation
Parameter maxResourceBlocksPerTTIToLimitSPSAllocation
[0..100]
Feature FRS 114531
Rule: Parameter maxResourceBlocksPerTTIToLimitSPSAllocation
DL
DL maxResourceBlocksPerTTIToLimitSPSAll
transmission ocation
dlBandwidth
bandwidth in
DL
RBs ( N RB )
n15-3MHz 15 In the range [0..15] and a multiple of 2
Page 101/472
Engineering Recommendation: Regarding parameter

maxResourceBlocksPerTTIToLimitSPSAllocation
The current setting of this parameter is as follows:
maxResourceBlocksPerTTITo
dlBandwidth isSpsConfigAllowed
LimitSPSAllocation
n6-1_4MHz True 6
n6-1_4MHz False Not Significant
n15-3MHz True 15
n15-3MHz False Not Significant
n25-5MHz True 25
n50-10MHz True 50
n75-15MHz True 75
n100-20MHz True 100
DownlinkSemiPersistentSchedulingConf::spsHARQProcessReuseForDSWhen
SPSReleased
Parameter spsHARQProcessReuseForDSWhenSPSReleased
Object
True/False
Value False
Feature FRS 115239(.1), FRS 162790
spsAllocationType1Activation: This parameter activates the usage of Allocation

Type 1 for SPS.
Page 102/472
DownlinkSemiPersistentSchedulingConf::spsAllocationType1Activation
Parameter spsAllocationType1Activation
Object
True/False
Value False
Feature FRS 115686
spsAllocationType2DistributedActivation: This parameter activates the usage of

Allocation Type 2 Distributed for SPS.
DownlinkSemiPersistentSchedulingConf::spsAllocationType2DistributedActiv
ation
Parameter spsAllocationType2DistributedActivation
Object
True/False
Value False
Feature FRS 115686
spsPdschPowerControlActivation: This parameter activates the PDSCH Power

control for SPS.
DownlinkSemiPersistentSchedulingConf::spsPdschPowerControlActivation
Parameter spsPdschPowerControlActivation
Object
True/False
Value False
Feature FRS 115686
Page 103/472
spsPerPRBAllocationActivation: This parameter activates the per PRB allocation

for SPS.
DownlinkSemiPersistentSchedulingConf::spsPerPRBAllocationActivation
Parameter spsPerPRBAllocationActivation
Object
True/False
Value False
Feature FRS 115686
spsVoIPDataRateMonitoringActivation: This parameter activates the monitoring of

the VoIP data rate for SPS.
DownlinkSemiPersistentSchedulingConf::spsVoIPDataRateMonitoringActivatio
n
Parameter spsVoIPDataRateMonitoringActivation
Object
True/False
Value False
Feature FRS 115686
4.5.2.4.1 SPS ACTIVATION
If the Semi-Persistent Scheduler fails to find resources in the first 20ms after SPS
activation has been engaged, the SPS activation is declared as failed. The failure is
reported to the dynamic scheduler. The latter takes on the management of the VoIP
bearer packets and starts the timer spsActivationProhibitTimeUponSPSFailureDl
at the expiry of which the SPS activation is attempted again.
The Semi-Persistent Scheduler reserves PDCCH resources, together with the

associated PDSCH resources, in the same TTI in the first
Page 104/472
maxSPSActivationAttemptsDl 20 ms periods, for the SPS activation. When an

ACK is received for the associated PDSCH transmission (SPS TB), the SPS grant
decoding (and thus the SPS pattern activation) is considered successful and the
PDCCH resources reserved for the remaining attempts are freed. If a NACK is
received, the SPS activation attempt is considered failed. Another SPS grant is
transmitted 20 ms after the last attempt. In the meantime, the retransmission of the
TB is managed by the dynamic scheduler.
If maxSPSActivationAttemptsDl SPS successive activation grants are sent
unsuccessfully, the SPS activation is declared as failed. The failure is reported to the
dynamic scheduler. The latter takes on the management of the VoIP bearer packets
and starts the timer spsActivationProhibitTimeUponSPSFailureDl at the expiry of
which the SPS activation is attempted again.
The scheduler checks whether there are enough PDCCH resources available for the
grant. If there are not enough CCE resources available for the grant, the bearer is not
scheduled.
Also, if PDCCH power control is activated (see section 6.1.2) and there aren’t
enough power resources available to achieve the PDCCH SINR target, all the
remaining power is provided to the grant. If there isn’t any, the bearer is not
scheduled.
After the SPS TB is transmitted, the Semi-Static scheduler checks if there still are
data from the VoIP frame in the VoIP buffer. This happens if the VoIP frame did not
fit entirely in the SPS TBS, the VoIP encoder rate being variable around the average.
In this case, the dynamic scheduler is notified that it needs to manage the remaining
data starting from the next TTI.
If spsMACMultiplexingAllowed is set to “True” (not supported in LA6.0, but

supported in LR13.1) and the UE has 2 SPS active bearers and both have non-
empty queues (i.e. VoIP frames to transmit) then the 2 frames are multiplexed in the
SPS TBS if the latter can fit them both or only the highest that fits the TBS is included
in the SPS TBS if the latter cannot fit both frames, in which case the dynamic
scheduler is notified that it needs to manage the transmission of the remaining VoIP
frame starting from the next TTI.
Also, the grant is persistent, meaning that once SPS is activated, the same
resources are reused for the (initial) transmission of the VoIP frame every 20ms
without the need for a grant until SPS is released (through a PDCCH SPS release
message).
Note that retransmissions are managed by the dynamic scheduler.
Also note that if spsHARQProcessReuseForDSWhenSPSReleased is set to
“True”, the HARQ process used by SPS is freed for use by the dynamic scheduler
when an ACK is received for the transmission of the SPS packet.
Page 105/472
DownlinkSemiPersistentSchedulingConf::maxSPSActivationAttemptsDl
Parameter maxSPSActivationAttemptsDl
Object
[0..5]
Value 3
Feature FRS 114531
DownlinkSemiPersistentSchedulingConf::spsActivationProhibitTimeUponSPS
FailureDl
Parameter spsActivationProhibitTimeUponSPSFailureDl
Object
Range & Unit Float
[0.0..15.0] step = 0.25 ms
Value 15.0
Feature FRS 114531
spsMACMultiplexingAllowed: This parameter activates the dual VoIP bearer

optimization allowing transmitting 2 VoIP frames for 2 different bearers in the same
SPS pattern. This functionality is supported in LR13.1 (not supported in LA6.0).
When a second VoIP bearer is setup for a given UE, and if the SPS Configuration
was provided as part of the initial VoIP bearer setup, the scheduler must use the
SPS capabilities for the second VoIP bearer for that UE if this parameter is set to
True. If the parameter is set to False, the second VoIP bearer is managed in the
Dynamic Scheduler.
Page 106/472
DownlinkSemiPersistentSchedulingConf::spsMACMultiplexingAllowed
Parameter spsMACMultiplexingAllowed
Object
True/False
Value False (See Restriction below)
Feature FRS 115239(.1), FRS 162790
Restriction: SPS multiplexing and parameter spsMACMultiplexingAllowed
In LR13.1, this functionality is supported and the parameter should be set to True.
Otherwise, spsMACMultiplexingAllowed must be set to “False”.
DownlinkSemiPersistentSchedulingConf::spsHARQProcessReuseForDSWhen
SPSActivated
Parameter spsHARQProcessReuseForDSWhenSPSActivated
Object
True/False
Value False
Feature FRS 115239(.1), FRS 162790
If both parameters spsHARQProcessReuseForDSWhenSPSReleased &

spsHARQProcessReuseForDSWhenSPSActivated are set to false and if UE is
flagged as SPS configured, the HARQ process(-es) for SPS is (are) reserved at VoIP
bearer setup and cannot be re-used by the Dynamic Scheduler until final VoIP bearer
is deleted for that UE.
4.5.2.4.2 SPS RELEASE
The SPS pattern is released if one of the following events occurs:
Page 107/472
• The SPS pattern collides with a RACH 2 message position or D-BCH

position (SPS incompatibility).
• The maximum difference between the estimated BLER and target BLER that
is acceptable during an SPS Active phase, configured by parameter
blerMaxVariationForSPSDl is exceeded (SPS incompatibility).
Note that no action of SPS release is performed during the first
spsBLCStabilizationPeriodDl ms period following the SPS activation. This
is to allow the SPS BLER estimation to stabilize (i.e. converge). Also note
that the SPS BLER estimation is performed in the dynamic scheduler.
• More than inactivityPeriodForSPSReleaseDl 20ms-periods have elapsed
with the SPS buffer empty (VoIP inactivity).
• If the SINR is reduced by more than sinrMaxVariationforSPSDl dB (SPS
incompatibility) as compared to the time the SPS activation was decided.
• If the SINR falls below minSINRForSPS (SPS incompatibility).

• UE speed, expressed as a Doppler shift, exceeds
maxDopplerShiftForSPSDl (SPS incompatibility).
• Measurement Gap is activated (SPS incompatibility).

• A DRX command is issued for that UE.
• SPS RBs collide with D-BCH RBs.
• PRS RBs collide with PRS RBs.
The SPS release may also be be initiated in case pending MBMS configuration is to
use the TTI currently booked for DL SPS. The timer (to be replaced by a proper MIM
parameter in LR14: timeToReleaseDueToEmbmsCollision), which triggers the
SPS release in this case, is controlled by bits 6-8 of LteCell::spare5 (possible
values: 000 - 0ms, 111 - 140ms (Default), in steps of 20ms).
The SPS release command is managed by the dynamic scheduler. The SPS release
is considered successful if an ACK is received. If a NACK is received, the SPS
release command is retransmitted. If the maximum number of attempts
maxSPSReleaseAttemptsDl is reached, the SPS release is considered
unsuccessful.
SPS release grants are allowed to be issued on TTI declared as MBSFN only if bit 5
of LteCell::spare5 is set to ‘1’ (by default, the bit is set to ‘0’ - Disabled).
Also, each SPS release command transmission attempt is associated with a timer
MaxTimerForSPSRelease (hardcoded to 200ms). This timer is started each time a new
transmission attempt is considered. It is stopped when the transmission occurs. If the
timer expires, the SPS release is considered unsuccessful.
If the SPS release fails, SPS is permanently deactivated for the VoIP bearer and
corresponding PDSCH resources are released.
Page 108/472
If the release is successful and triggered by inactivity, SPS can be activated again
when the VoIP traffic resumes.
If the release is successful and triggered by an incompatibility, SPS can be activated
again spsActivationProhibitTimeUponSPSAbnormalReleaseDl seconds after the
incompatibility condition is cleared.
When an SPS release is initiated, all transmissions (initial and retransmissions), are
managed by the dynamic scheduler.
Also, if the SPS is released, the remainder of the talk spurt is managed by the
dynamic scheduler.
DownlinkSemiPersistentSchedulingConf::blerMaxVariationForSPSDl
Parameter blerMaxVariationForSPSDl
Object
[0..100] %
Value 40
Feature FRS 114531
DownlinkSemiPersistentSchedulingConf::inactivityPeriodForSPSReleaseDl
Parameter inactivityPeriodForSPSReleaseDl
Object
[0..160] step = 20 ms
Value 60
Feature FRS 114531
Page 109/472
DownlinkSemiPersistentSchedulingConf::sinrMaxVariationforSPSDl
Parameter sinrMaxVariationforSPSDl
Object
Range & Unit Float
[0..40] step = 0.25 dB
Class/Source B--Cells-of-NE/ system_restricted
Value 6.00
Feature FRS 114531
CellL2DLConf::maxDopplerShiftForSPSDl
Parameter maxDopplerShiftForSPSDl
[0..850] Hz
Value 850
Feature FRS 114531
CellL2DLConf::minSINRForSPSDl
Parameter minSINRForSPSDl
Range & Unit Float
[-10..30] step = 0.25 dB
Value 0.00
Feature FRS 114531
Page 110/472
DownlinkSemiPersistentSchedulingConf::maxSPSReleaseAttemptsDl
Parameter maxSPSReleaseAttemptsDl
Object
[0..10]
Value 3
Feature FRS 114531
DownlinkSemiPersistentSchedulingConf::spsActivationProhibitTimeUponSPS
AbnormalReleaseDl
Parameter spsActivationProhibitTimeUponSPSAbnormalReleaseDl
Object
Range & Unit Float
[0.0..15.0] step = 0.25 s
Value 5.0
Feature FRS 114531
4.5.2.5 POSITIONING REFERENCE SIGNALS SCHEDULING
Positioning Reference Signals (PRS) are generated in PDSCH.

Below, PRS-RBs refer to the RBs that carry PRS symbols. These RBs do not carry
traffic in order to enhance PRS hearability by UEs.
The PRS configuration consists of:
• Parameter isOtdoaHearabilityEnhancementAllowed, which
enables/disables the transmission of Positioning Reference Signals in the
cell.
• Parameter prsNumSubframes, which specifies the number of consecutive
downlink subframes that contain positioning reference signals.
• Parameter prsBandwidth, which specifies the number of PRS-RBs.
Page 111/472
• Parameter prsConfigurationIndex, which specifies the positioning

reference signals configuration index (refer to table 6.10.4.3-1 in 36.211). It
should be coherent with PRS periodicity and PRS subframe offset values, as
per the 3GPP table below:
• Parameter prsPowerOffset, which configures the transmit power per RE and
per transmit antenna (expressed in dB relative to PREF ) for the PRS.
PRS configuration
PRS periodicity TPRS PRS subframe offset ∆ PRS
Index I PRS =
(subframes) (subframes)
prsConfigurationIndex
0 – 159 160 I PRS
160 – 479 320 I PRS − 160
480 – 1119 640 I PRS − 480
1120 – 2399 1280 I PRS − 1120
2400-4095 Reserved
Table 8: Positioning Reference Signal subframe configuration
PRS periodicity is the periodicity of PRS. PRS subframe offset is the offset of the
first subframe where PRS is transmitted within each PRS period.
When PRS is activated, the semi-static scheduler instructs the L1 to generate the
PRS data and transmit them in the resources defined as follows:
• In the time domain, PRS are transmitted in prsNumSubframes consecutive
subframes starting at the position defined by the offset PRS subframe offset
within the PRS period.
• In the frequency domain, PRS are evenly spread on each side of the central
carrier frequency. The exact number of PRS-RBs is prsBandwidth RBs
DL
when the difference ( N RB -prsBandwidth) is even and (prsBandwidth +1)
DL
RBs when the difference (numberOfRBs-prsBandwidth) is odd, where N RB
is the total number of RBs in the bandwidth.
Note that when the number of PRS-RBs is (prsBandwidth +1) the first 6
REs (i.e. half RB) and the last 6 REs in the PRS band are not used.
The PRS-RB range as a function of the DL bandwidth and prsBandwidth

setting is provided Table 9.
Page 112/472
prsBandwidth
dlBandwidth DL n6 n15 n25 n50 n75 n100

N RB
n6-1_4MHz 6 0..5
n15-3MHz 15 4..10 0.. 14
n25-5MHz 25 9..15 5..19 0..24
n50-10MHz 50 22..27 17..32 12..37 0..49
n75-15MHz 75 34..40 30..44 25..49 12..62 0..74
n100-20MHz 100 47..52 42..57 37..62 25..74 12..87 0..99
Table 9: PRS bandwidth
PRS muting
If optional parameters prsMutingPeriodicity and prsMutingSequence are set,
some PRS transmissions are muted (not transmitted): starting at leftmost position of
prsMutingSequence, for each bit of rank “i” set to 0, the corresponding PRS
position occasion “i" is muted where PRS position occasion “I” consists of
prsNumSubframes consecutive subframes, and starts at the subframe number
prsSubframeOffset of System Frame Number N that satisfies the following 2
conditions:
N modulo prsPeriodicity = 0
(N/prsPeriodicity) modulo prsMutingPeriodicity = i
For 0 ≤ i < prsMutingPeriodicity
Restriction: PRS muting is not currently supported
PRS muting is not currently supported
ActivationService::isOtdoaHearabilityEnhancementAllowed
Parameter isOtdoaHearabilityEnhancementAllowed
True/False
Value O.D. (ALU Default: False)
Feature FRS 115435
Page 113/472
PositioningReferenceSignals::prsNumSubframes
Parameter prsNumSubframes
Object ENBEquipment/Enb/LteCell/PositioningReferenceSignals
{sf1, sf2, sf4, sf6}
Value O.D. (ALU Default: sf1)
Feature FRS 115435, FRS 101821(.1)
PositioningReferenceSignals::prsBandwidth
Parameter prsBandwidth
{n6, n15, n25, n50, n75, n100}
Value O.D.
Feature FRS 115435, FRS 101821
PositioningReferenceSignals::prsConfigurationIndex
Parameter prsConfigurationIndex
[0..4095]
Value O.D.
Feature FRS 101821
Restriction: PRS configuation
The combination of prsNumSubframes, prsBandwidth, and prsConfigurationIndex

values must be approved by ALU. Setting an unapproved combination of values
could cause system performance issues. The recommended values are under
evaluating.
Page 114/472
PositioningReferenceSignals::prsMutingPeriodicity
Parameter prsMutingPeriodicity
{po2, po4, po8, po16}
Value O.D.
Feature
PositioningReferenceSignals::prsMutingSequence
Parameter prsMutingSequence
Range & Unit String of 2 to 16 bits

Value O.D.
Feature
prsMutingPeriodicity specifies the length of the PRS muting sequence, in number

of positioning occasions (po), as defined in TS 36.355. The PRS muting sequence
itself is defined by prsMutingSequence. of length prsMutingPeriodicity bits. If a bit
in the PRS muting sequence is set to 0, then the PRS is muted in the corresponding
PRS positioning occasion. If the parameter is not set, then the PRS muting is
inactive.
OTDOA is not supported on Metro in LR13.1 (see Volume 5), but is compatible with
OTDOA on macro eNodeB. As a matter of fact, a new parameter
CellL2DLConf::isOtdoaCompatibleNeighborWithoutPrs is introduced to allow
Metro to avoid interfering with macro OTDOA Positioning Reference Signals (PRS).
When set to true, CallP provides PRS configuration to modem without activating PRS
transmission i.e. Metro avoids scheduling downlink user traffic during subframes
used for PRS transmissions at neighboring macro cells. This makes the Metro
compatible with OTDOA position location enabled on other eNodeBs in the vicinity.
Page 115/472
Note: in this case, Metro excludes PRS from the DL power checks.
CellL2DLConf::isOtdoaCompatibleNeighborWithoutPrs
Parameter isOtdoaCompatibleNeighborWithoutPrs
True/False
Value O.D. (Default: false)
Feature FRS 159488
Engineering Recommendation: when Metro is in macro eNB’s vicinity and

OTDOA is activated on the macro eNB
isOtdoaCompatibleNeighborWithoutPrs shall be set to “True” (then

PositioningReferenceSignals object must exist on the cell), AND
Enb::ClockSync::sfnSyncOption shall be set to
“FrequencyAndPhaseAndTimeOfDay” AND
isOtdoaHearabilityEnhancementAllowed shall be set to “False”.
On Macro eNB, isOtdoaCompatibleNeighborWithoutPrs must be set to False.
4.5.2.6 MCH SCHEDULING
If isMbmsTrafficAllowed is set to “False”, the processing described in this section is

disabled (no MBSMS control or data is transmitted).
The scheduling of MCH consists in the scheduling of the following types of data:
• The MCH Scheduling Information (MSI), which provides information to the
UEs to demultiplex MTCH channels within an MCH. It essentially provides
the subframe number where the MTCH is ending within MCH (stopMTCH
field).
• The MCCH, which carries a single RRC message describing the mapping
between radio resources and the eMBMS services for one MBSFN area.
• The MTCH data coming from e-MBMS bearers.
SIB13 indicates to the UE the information necessary to locate and read the MCCH.
Page 116/472
commonSFAllocPeriod
sfAllocEnd in
instance 0
of MbsfnPmch
MCH 1 MCH 2 MCH 3 … MCH 1 MCH 2 MCH 3 …
MCH1 MCH2
sfAllocEnd
Scheduling Scheduling in instance 1
Period Period of MbsfnPmch
Figure 10: Periodic PMCH resource distribution between the different MCHs configured in
the MBSFN area
MSI/MCCH/MTCH scheduling
The MSI is always scheduled in the first subframe of an MSP.
In case the M-subframe corresponds to a subframe that carries MCCH and is the first
subframe of an MSP, the MCCH RRC message is included in the PDU.
In case the M-subframe corresponds to the first subframe of an MCH Scheduling
Period, the MSI is included in the PDU.
MTCH data are included in all M-subframes, multiplexed with MCCH RRC message
and/or with MSI.
The MCH PDU is transmitted using MCS sib13SignallingMCS if it contains MCCH
and/or MSI and using MCS MCS otherwise that is derived from dlSinr and
MceSupportedQCI of the bearer that the MTCH carries (i.e. if the MCH PDU only
contains MTCH data).
Note that sib13SignallingMCS is configured per MBSFN area (see [Vol. 5] for
description of the parameters).
No DL grant is necessary for the transmission of the transport block, as the

information necessary to decode the MBMS data is sent in SIB13 and in MCCH.
On the other hand, the transmission of the MCH Transport Block occurs on the entire
bandwidth. Therefore, the MCH Transport Block Size is derived from Table 59 using
DL
the I TBS derived from Table 55 using MCS determined above and N PRB = N RB .
Page 117/472
Parameters MbsfnSubframeAllocationPattern::radioFrameAllocationPeriod and

MbsfnSubframeAllocationPattern::radioFrameAllocationOffset identifie the
subframes allocated for the concerned MBSFN area: radio-frames that contain
MBSFN sub-frames occur when equation SFN mod radioFrameAllocationPeriod =
radioFrameAllocationOffset is satisfied. Value n1 for radioFrameAllocationPeriod
denotes value 1, n2 denotes value 2, and so on.
MbsfnSubframeAllocationPattern::radioFrameAllocationPeriod
Parameter radioFrameAllocationPeriod
ENBEquipment/Enb/Mbms/MbsfnCellConf/MbsfnArea/
Object
MbsfnSubframeAllocationPattern
{n1, n2, n4, n8, n16, n32}
Value n1
Feature L115217
MbsfnSubframeAllocationPattern::radioFrameAllocationOffset
Parameter radioFrameAllocationOffset
Object
[0..7]
Value 0
Feature L115217
Parameter MbsfnSubframeAllocationPattern::oneFrame identifies the sub-frame

allocated for the concerned MBSFN area in a frame (‘1’ denotes that the
corresponding subframe is allocated for MBSFN) with following mapping: the first,
leftmost bit defines the MBSFN allocation for sub-frame number 1, the second bit for
number 2, third bit for number 3, fourth bit for number 6, fifth bit for number 7, sixth
bit for number 8.
Page 118/472
MbsfnSubframeAllocationPattern::oneFrame
Parameter oneFrame
Object
With 6 characters
Value O.D.
Feature L115217
4.5.3 DYNAMIC SCHEDULER

The dynamic scheduler is in charge of scheduling all the logical channels which have
non-stringent timing constraints and non-regular usage of the resource.
The downlink dynamic scheduler assigns resources to:
• DTCH (data bearers) and DCCH (SRB1 and SRB2) logical channels.
• Timing Advance control messages.
The dynamic scheduling algorithm is not run in MBSFN subframes.
Because of the absence of timing constraints (as opposed to the static and the semi-
static schedulers), the dynamic scheduler does not prebook resources in the
TimeFrequencyResBlocOccupancy matrix. It uses the resources left by the static and
semi-static schedulers.
The Dynamic scheduler can be decomposed into 3 sequential functions:

1. Measurement processing and transmission mode selection, updated every
TTI and used in the 2 following functions.
2. HARQ retransmissions processing functions, managing in priority the users
with HARQ retransmissions.
3. Initial transmissions processing functions, allocating the remaining resources
to new transmissions.
4.5.3.1 TRANSMISSION MODE CONFIGURATION
The following PDSCH transmission modes are defined:

Page 119/472
• TM1: In this mode, the transmission scheme is SIMO. DCI1 is used for
granting.
• TM2: In this mode, the transmission scheme is TxDiv. In this mode, DCI1 is
used for granting.
• TM3: In this mode, the transmission scheme is either 2-layer Open Loop
MIMO (OL-MIMO) or TxDiv.
In this mode, DCI2A is used for granting.
• TM4: In this mode, the transmission scheme is one of the following:

o 2-layer Closed-Loop MIMO (CL-MIMO).
o 1-layer Closed-Loop MIMO.
o Transmit Diversity (TxDiv).
In this mode, DCI2 is used for granting.
Parameter transmissionMode configures the transmission mode of PDSCH in the

cell. In case of CA, transmissionModeR10 configures the PCell transmission mode
for CA UE.
LteCellFDD::transmissionMode
Parameter transmissionMode
{tm1, tm2, tm3, tm4}
DownlinkCAConf::transmissionModeR10
Parameter transmissionModeR10
Object
gregationPrimaryConf/DownlinkCAConf
{tm1, tm2, tm3, tm4}
Value tm4
Feature 160847
Page 120/472
Engineering Recommendation: Setting of parameter transmissionMode
The current default setting of this parameter is as follows:
dlBandwidth transmissionMode
n6-1_4MHz tm2
n15-3MHz tm4
n25-5MHz tm4
n50-10MHz tm4
n75-15MHz tm4
n100-20MHz tm4
4.5.3.2 DOWNLINK DYNAMIC SCHEDULER OPERATION MODE

DETERMINATION
The DL dynamic scheduler can work in 2 operational modes:

• Frequency Diverse Scheduling Only (when fDSOnly is set to “True”): In this
mode, the scheduler operates in the Frequency Diverse Scheduling mode
(FDS), exclusively.
• Frequency Selective Scheduling Capable (when fDSOnly is set to “False”):
In this mode, the scheduler can switch from Frequency Diverse Scheduling
(FDS) to Frequency Selective Scheduling (FSS), and vice versa. The initial
mode is set to FSS. Then, the mode is determined by the number of users
o When in the FSS mode, if the number of active users exceeds a

threshold FDS_User_Thr, the scheduler switches to the FDS mode.
o When in the FDS mode, if the number of active users drops below a
threshold (FDS_User_Thr – Delta_User_Thr), the scheduler switches the
mode to the FSS mode.
Note that FDS_User_Thr and Delta_User_Thr are internal parameters
maximumFSSUsers is an OAM parameter that configures the maximum number of

DL FS users that can be managed.
Parameter minimumCQIForFSS specifies the minimum CQI value, below which the
user is forced into FDS scheduling mode.
Page 121/472
CellL2DLConf::maximumFSSUsers
Parameter maximumFSSUsers
[1..60]
Value 60
CellL2DLConf::fDSOnly
Parameter fDSOnly
True/False
Feature FRS 90853
Engineering Recommendation: Setting of parameter fDSOnly
The current recommended setting for fDSOnly is as follows:
dlBandwidth fDSOnly
n6-1_4MHz True
n15-3MHz False
n25-5MHz False
n50-10MHz False
n75-15MHz False
n100-20MHz False
Page 122/472
CellL2DLConf::minimumCQIForFSS
Parameter minimumCQIForFSS
[1..15]
Value 6
4.5.3.3 DL A-CQI LIST USERS MEASUREMENTS PROCESSING
A UE can be requested to send PUSCH aperiodic CQI/PMI reports on top of the

PUCCH periodic reports.
A UE performs PUSCH (aperiodic) CQI, PMI and RI reporting upon reception of DCI
format 0 with the CQI request field set to 1.
The following PUSCH (aperiodic) CQI/PMI/RI reporting formats are supported in
LR13.1:
• Mode 3-0
o The UE reports a wideband CQI value.
o The UE also reports one subband CQI value for each subband
(calculated assuming transmission only in the subband).
o Both the wideband and subband CQI represent channel quality for
the first codeword, even when rank =2.
• Mode 3-1
o A single precoding matrix is reported. This matrix is selected from
the codebook subset assuming transmission on.
o The UE reports one subband CQI value per codeword for each
subband (calculated assuming the use of the selected precoding
matrix in all subbands).
o The UE reports a wideband CQI value per codeword (calculated
assuming the use of the selected precoding matrix in all subbands).
Parameter cqiReportingModeAperiodic configures the mode used for the PUSCH

(A-CQI) reports:
• Values “rm30”, “rm31” and “rm12” correspond to reported modes 3-0, 3-1
and 1-2 respectively.
Page 123/472
• If the parameter is set to “disabled”, the uplink scheduler does not send
grants for CQI reports.
CellL1ULConfFDD::cqiReportingModeAperiodic
Parameter cqiReportingModeAperiodic
{rm30, rm31, rm12}
Feature FRS 80279, FRS92095
Restriction: Parameter cqiReportingModeAperiodic and reporting mode 1-2
Reporting mode 1-2 is not supported in LR13.1. Therefore, parameter

cqiReportingModeAperiodic must not be set to “rm12”.
Engineering Recommendation: Parameter cqiReportingModeAperiodic
This parameter should be set in accordance to the transmission mode configured

by parameter transmissionMode.
The mapping is as follows:
transmissionMode cqiReportingModeAperiodic
tm1 rm30
tm2 rm30
tm3 rm30
tm4 rm31
Parameter cqiReportingModeAperiodic is defaulted to “rm31” in ALU templates.

Recall that transmissionMode is defaulted to “tm4”.
Page 124/472
In PUSCH (aperiodic) CQI reporting, the subband CQI value for each codeword is
encoded differentially with respect to the wideband CQI value using 2-bits and
according to the following equation:
Subband differential CQI offset level = subband CQI index – wideband CQI index.
The mapping from the 2-bit subband differential CQI value to the offset level is
shown in Table 10:
Subband differential Offset level
CQI value
0 0
1 1
2 2
3 -1
Table 10: Offset levels for Differential CQI
With a 3 MHz bandwidth, 4 subbands are reported, each subband representing the
CQI for 4 RBs (except the last one which measures the CQI over 3 RBs).
Subband index RBs where CQI Reported CQI for Codeword 1

is measured
SB0 0 to 3 CQI1,0; CQI1,1; CQI1,2; CQI1,3
SB3 12 to 14 CQI1,12; CQI1,13; CQI1,14
Table 11: Subband index with a 3 MHz bandwidth
Page 125/472
CQI for 4 RBs (except the last one which measures the CQI over 1 RB).
Subband index RBs where CQI Reported CQI for Codeword 1

is measured
SB6 24 CQI1,24
Sub-band RBs where Updated CQI for codeword 1

index CQI is
measured
SB0 0 to 5 CQI1,0; CQI1,1; CQI1,2; CQI1,3; CQI1,4; CQI1,5
SB1 6 to 11 CQI1,6; CQI1,7 ; CQI1,8; CQI1,9; CQI1,10; CQI1,11
SB2 12 to 17 CQI1,12; CQI1,13; CQI1,14; CQI1,15 ; CQI1,16; CQI1,17
SB8 48 and 49 CQI1,48; CQI1,49
Page 126/472
Sub-band RBs where CQI is Updated CQI for codeword 1

index measured
SB0 0 to 7 CQI1,0 to CQI1,7
SB2 16 to 23 CQI1,16 to CQI1,23
SB3 24 to 31 CQI1,24 to CQI1,31
SB4 32 to 39 CQI1,32 to CQI1,39
SB5 40 to 47 CQI1,40 to CQI1,47
SB6 48 to 55 CQI1,48 to CQI1,55
SB7 56 to 63 CQI1,56 to CQI1,63
SB8 64 to 71 CQI1,64 to CQI1,71
SB9 72 to 74 CQI1,72 to CQI1,74
With a 20 MHz bandwidth, 13 subbands are reported, each subband representing

the CQI for 8 RBs (except the last one which measures the CQI over 4 RBs).
Page 127/472
Subband RBs where CQI is Updated CQI for codeword 1

index measured
SB2 16 to 23 CQI1,16 to CQI1,23
SB3 24 to 31 CQI1,24 to CQI1,31
SB4 32 to 39 CQI1,32 to CQI1,39
SB5 40 to 47 CQI1,40 to CQI1,47
SB6 48 to 55 CQI1,48 to CQI1,55
SB7 56 to 63 CQI1,56 to CQI1,63
SB8 64 to 71 CQI1,64 to CQI1,71
SB9 72 to 79 CQI1,72 to CQI1,79
SB10 80 to 87 CQI1,80 to CQI1,87
SB11 88 to 95 CQI1,88 to CQI1,95
SB12 96 to 99 CQI1,96 to CQI1,99
CellRadioConf::aperiodicCQIrankAveragingCoefficient
Parameter aperiodicCQIrankAveragingCoefficient
[1..256]
15 The function associated with this parameter is considered to
Value be proprietary, and is thus not described here. The value of the
parameter should only be modified by qualified ALU personnel.
Feature FRS 90853
Page 128/472
CellRadioConf::periodicRIrankAveragingCoefficient
Parameter periodicRIrankAveragingCoefficient
[1..256]
Class/Source B--Cells-of-eNB/ system_restricted
Feature FRS 90853
The rank indicator is a metric feedback by the UE. It indicates the number of freedom
degrees measured by the receiver, which represents the maximum capacity of the
Tx/Rx channel in terms of independent streams.
• If the Rank is equal to 1, only one stream can be transmitted. I this case,
either Transmit Diversity or 1-layer MIMO is used.
• If the Rank is equal to 2, Spatial Multiplexing becomes possible with a
throughput higher than 1-layer schemes for high SINR values.
When in TM4 (transmissionMode=tm4), the UE also reports a codebook index to

indicate the precoding matrix to use in case CL-MIMO is used (see Table 16). The
PMI is reported in mode 3-1 (WB PMI) if cqiReportingModeAperiodic is set to
“rm31” and in mode 1-2 (NB PMI) if cqiReportingModeAperiodic is set to “rm12”.
Codebook Number of layers υ

index
1 2
1 1
0  -
2 1
1 1 1 1 1 
1    
2 −1 2 1 −1
1 1  1 1 1 
2    
2  j 2  j − j
1 1 
3   -
2 − j 
Table 16: Precoding matrix as a function of the codebook index and the rank
Page 129/472
Also, a set of boolean parameters is defined to allow or not the PMI and RI reporting
to correspond to the precoding matrix they are associated (according to Table 16):
• Parameter n2TxAntennaTm4OneLayerCodebook0
• Parameter n2TxAntennaTm4TwoLayersCodebook1
• Parameter n2TxAntennaTm4TwoLayersCodebook2
Parameter n2TxAntennaTm4OneLayerCodebook0
ENBEquipment/Enb/LteCell/TxDivOrMimoResources/MimoConf
Object
iguration/DownlinkMimo/CodebookSubsetRestriction
True/False
Feature FRS 80279
Object
True/False
Feature FRS 80279
Page 130/472
Object
True/False
Feature FRS 80279
Object
True/False
Feature FRS 80279
CodebookSubsetRestriction::n2TxAntennaTm4TwoLayersCodebook1
Parameter n2TxAntennaTm4TwoLayersCodebook1
Object
True/False
Feature FRS 80279
Page 131/472
CodebookSubsetRestriction::n2TxAntennaTm4TwoLayersCodebook2
Parameter n2TxAntennaTm4TwoLayersCodebook2
Object
True/False
Feature FRS 80279
Engineering Recommendation: CodebookSubsetRestriction parameters
Parameters n2TxAntennaTm4OneLayerCodebook0,
n2TxAntennaTm4OneLayerCodebook1,
n2TxAntennaTm4TwoLayersCodebook1 and
n2TxAntennaTm4TwoLayersCodebook2 should be set to “True” in TM4 (i.e.
when transmissionMode is set to “tm4”).
Note that the default codebook used by the downlink scheduler before the UE reports
the first PMI is configured by parameter dlMIMODefaultCodeBook.
DownlinkMimo::dlMIMODefaultCodeBook
Parameter dlMIMODefaultCodeBook
Object
iguration/DownlinkMimo
{1LayerCodebook0, 1LayerCodebook1, 1LayerCodebook2,
1LayerCodebook3, 2LayersCodebook1, 2LayersCodebook2}
Value 1LayerCodebook0
Feature FRS 80279
4.5.3.4 DL FD USERS MEASUREMENTS PROCESSING
Each connected UE is configured with periodic CQI/PMI reporting over PUCCH.
Page 132/472
Table 18 shows lists the different PUCCH CQI/PMI reporting modes.
PMI Feedback Type

No PMI Single PMI
Feedback Type
Wideband
PUCCH CQI
Mode 1-0 Mode 1-1
(wideband CQI)
UE Selected
Mode 2-0 Mode 2-1
(subband CQI)
Table 17: PUCCH CQI/PMI reporting modes
Recall that in LR13.1, PUCCH periodic CQI/PMI reports are used to provide
wideband CQI reports while subband CQI reports, if needed, are provided via
PUSCH aperiodic CQI reports since they can be provided with faster rate. Therefore,
only modes 1-0 and 1-1 are supported in LR13.1:
• Mode 1-0
o The UE reports a wideband CQI value, representing channel quality

for the first codeword, even when rank =2.
• Mode 1-1
o A single precoding matrix is reported. This matrix is selected from
the codebook subset assuming transmission on set S subbands.
o The UE reports a 4-bit wideband absolute CQI value CQI1,WB for the
first codeword, calculated assuming the use of the use of a single
precoding matrix in all subbands and transmission on all subbands.
o When rank = 2, the UE also reports a 3-bit wideband differential CQI
value for the second codeword. The wideband absolute CQI value
CQI2,WB for the second codeword is obtained as CQI2,WB = CQI1,WB –
CQI_Offset where CQI1,WB is derived from the differential CQI value
as shown in Table 18:
Page 133/472
3-bit differential CQI

value for second CQI_Offset
codeword
0 0
1 1
2 2
3 3
4 -4
5 -3
6 -2
7 -1
Table 18: Mapping of the 3-bit differential CQI value reported for the second
codeword (when rank = 2 in mode 1-1) to CQI_Offset.
Note that mode 1-1 provides PMI feedback, only necessary for CL-MIMO, and is
therefore used in transmission mode 4 (i.e. when transmissionMode is set to “tm4”).
Mode 1-0, on the other hand, provides no PMI feedback and is therefore used when
in transmission modes 2 or 3 (i.e. when transmissionMode is set to “tm2” or to
“tm3”).
4.5.3.4.1 CQI ERASURE AND DROP HANDLING
A specific mechanism is introduced to manage the case when CQI/PMI/RI report is

not available either due to erasure or dropping. It only applies to the FDS users or to
FSS users in case no A-CQI is received.
This mechanism is activated/deactivated using bit 13 of LteCell::spare4. It uses the
following 2 parameters:
o dlPCQIValidityWindow: The value represents the time window the last
reported PCQI is regarded as an accurate representation of the UE's RF
condition in case the subsequent PCQIs are erased.
o dlSINRDecayUponPCQIErasure: The value represents the assumed DL

SINR reduction if no valid PCQI/PMI is received in a whole second.
Restriction: bit 13 of LteCell::spare4
Note that, due to some interactions with feature MAC-DRX feature, this
mechanism is hardcoded to ON (bit 13 of LteCell::spare4 is hardcoded to ‘1’,
whatever the value in the database) starting LR13.1 for both bCEM and eCEM.
Page 134/472
CellL2DLConf::dlPCQIValidityWindow
Parameter dlPCQIValidityWindow
[0..1000] step = 10
Value 30 (corresponding to 300ms)
Feature FRS 128003 (L101843)
Rule: value of CellL2DLConf::dlPCQIValidityWindow
Currently, in LR13.x, the value of dlPCQIValidityWindow is coded in such a way

that the final value of the window duration in ms is computed by multiplying the
value of the MIM parameter by 10.
CellL2DLConf::dlSINRDecayUponPCQIErasure
Parameter dlSINRDecayUponPCQIErasure
Range & Unit Float
[0..10] step = 0.1 dB
Value 3.0
Feature FRS 128003 (L101843)
4.5.3.5 TRANSMISSION MODE 3
In this mode, if macMIMOModeDl is not set to “MimoTwoLayersNotAllowed” the

transmission scheme used is either 2-layer OL-MIMO or TxDiv.
The Open Loop MIMO/TxDiv selection is carried out based on the filtered rank, the
filtered effective SINR, an SINR threshold (ThSinrMimo).
Parameter dlSinrThresholdBetweenOLMimoAndTxDiv configures the SINR

threshold.
Page 135/472
DownlinkMimo::dlSinrThresholdBetweenOLMimoAndTxDiv
Parameter dlSinrThresholdBetweenOLMimoAndTxDiv
Object
Range & Unit Float
[-10.0..30.0] step = 0.1 dB
Feature

dlSinrThresholdBetweenOLMimoAndTxDiv
This parameter is a key RF optimization parameter. Higher values will reduce DL

data rate otherwise achievable in the higher SINR regime. Lower values would
allow OL MIMO too soon, resulting in HARQ retransmission rates and BLERs
higher than achievable with Tx diversity and hence the use of an MCS with a lower
DL data rate/throughput.
The current default value for this parameter is 15.0.
4.5.3.6 TRANSMISSION MODE 4
When in TM4, the downlink transmission scheme is one of the following

• TxDiv
• 1-layer CL-MIMO
• 2-layer CL-MIMO
Note that if the reported (and filtered) rank is 1, the downlink transmission scheme
configured at cell-level will be either TxDiv or 1-layer CL-MIMO for all the bearers
established in the cell.
Also note that if parameter macMIMOModeDl is set to “MimoTwoLayersNotAllowed”,
as per section 4.5 the downlink transmission scheme configured at the bearer-type
level will be either TxDiv or 1-layer CL-MIMO in all the cells hosted by the eNB
(TrafficRadioBearerConf::macMIMOModeDl and
SignalingRadioBearerConf::macMIMOModeDl are set at bearer-level for all the
cells of the eNB).
Page 136/472
Parameter dlSinrThresholdBetweenCLMimoOneLayerAndTxDiv defines the

switching threshold between TxDiv and 1-layer CL-MIMO.
Parameter dlSinrThresholdBetweenCLMimoTwoLayersAndOneLayer defines the
switching threshold between 1-layer CL-MIMO and 2-layer CL-MIMO.
Rule: Parameter dlSinrThresholdBetweenCLMimoOneLayerAndTxDiv

dlSinrThresholdBetweenCLMimoTwoLayersAndOneLayer
If parameter dlSinrThresholdBetweenCLMimoOneLayerAndTxDiv is set equal

to dlSinrThresholdBetweenCLMimoTwoLayersAndOneLayer the downlink
transmission scheme configured at cell level will be either TxDiv or 2-layer CL-
MIMO (i.e. CL-MIMO 1 layer is disabled), the switching threshold being
dlSinrThresholdBetweenCLMimoOneLayerAndTxDiv =
dlSinrThresholdBetweenCLMimoTwoLayersAndOneLayer in this case.
If, besides, the reported (and filtered) rank is 1, the downlink transmission scheme
will just be TxDiv.
Also, if parameter macMIMOModeDl is set to “MimoTwoLayersNotAllowed”, the
downlink transmission scheme configured at bearer-type level will be TxDiv for all
the cells hosted by the eNB.
Note that the configuration

dlSinrThresholdBetweenCLMimoOneLayerAndTxDiv >
dlSinrThresholdBetweenCLMimoTwoLayersAndOneLayer must be avoided.
Page 137/472
DownlinkMimo::dlSinrThresholdBetweenCLMimoTwoLayersAndOneLayer
Parameter dlSinrThresholdBetweenCLMimoTwoLayersAndOneLayer
Object
Range & Unit Float
[-10..30] step = 0.1 dB
Class/Source C--Immediate-Propagation / eng_tunable
Feature

dlSinrThresholdBetweenCLMimoTwoLayersAndOneLayer
This parameter is a key RF optimization parameter. Higher values will reduce

downlink 2 layers data rate too soon, resulting in HARQ retransmission rates and
BLERs higher than achievable with 1 layer and hence the use of an MCS with a
lower downlink data rate/throughput.
The current default value for this parameter is 12.0.
DownlinkMimo::dlSinrThresholdBetweenCLMimoOneLayerAndTxDiv
Parameter dlSinrThresholdBetweenCLMimoOneLayerAndTxDiv
Object
Range & Unit Float
[-10.0..30.0] step = 0.1dB
Value -10.0
Feature
4.5.3.7 HARQ RETRANSMISSIONS SCHEDULING
HARQ retransmissions are scheduled according to a priority metric. Timing Advance

packets have the highest priority, followed by SRB0, then by SRB1/SRB2, then by
QCI1 data packets and finally by non-QCI1 data packets. Note, however, that if the
HARQ retransmission of a non-QCI1 data packet is the last one, the latter may have
Page 138/472
a higher priority than SRB0/SRB1/SRB2/QCI1 (that depends on how close the

HARQ timer close to its expiry).
4.5.3.8 INITIAL HARQ TRANSMISSIONS SCHEDULING
This stage outputs the list of bearers scheduled for an initial HARQ transmission and
their allocated resource blocks.
The initial transmission scheduling algorithm is the so-called Alpha Fairness

scheduler, which is a generalization, by means of parameter alphaFairnessFactor,
of the widely used Proportional Fair scheduler.
Parameter alphaFairnessFactor tunes the alpha fairness factor (thus the behavior)
of the scheduler:
• alphaFairnessFactor = 0.0 yields a maximum C/I scheduler. The scheduler
provides more resources to UEs in better conditions. The better the radio
conditions of the UE, the more resources (and hence the higher the data
rate) it gets.
• alphaFairnessFactor = 1.0 yields a fair scheduler. The scheduler attempts
to provide the same number of RBs to all the UEs (despite their different
conditions).
• alphaFairnessFactor = 2.0 yields an increased fairness scheduler. The rate
difference due to different RF conditions is much attenuated as compared to
the fair scheduler (recall that different radio conditions result in different data
rates even when the number of resources is the same), hence the increased
fairness of the scheduler, as compared to the “regular” fair scheduler.
• alphaFairnessFactor = 0.5 is a scheduler with an intermediate behavior
between alphaFairnessFactor = 0.0 (maximum C/I scheduler) and
alphaFairnessFactor = 1.0 ( fair scheduler).
• alphaFairnessFactor = 1.5 is a scheduler with an intermediate behavior
between alphaFairnessFactor = 1.0 (fair scheduler) and
alphaFairnessFactor = 2.0 (increased fairness scheduler).
This parameter provides flexibility as to the choice of scheduler behavior, allowing

the operator to choose the scheduler behavior they want for their network.
Page 139/472
CellL2DLConf::alphaFairnessFactor
Parameter alphaFairnessFactor
Range & Unit Float
[0..2] step=0.5
Value O.D. (ALU default: 1.0)
Feature FRS 76432
4.5.3.8.1 QOS WEIGHT COMPUTATION
In order to enforce the QoS of the different bearers, a QoS weight is computed for
each bearer. Note that when the RLC buffer of a given bearer is empty, the QoS
weight is set to 0.
In LA6.0.1, with the introduction of feature L160636, a configurable per-QCI
scheduling weight boost can be applied to the bearer QoS weight. The weight boost
is controlled by parameter TrafficRadioBearerConf::dlQCISchedulingWeight. This
is to allow customers to tune the throughput differentiation (thus the throughput ratio)
between different QCIs of the same type (GBRs and nGBRs). The higher the ratio of
the settings of dlQCISchedulingWeight for 2 different bearers, the higher the
throughput ratio between these QCIs.
TrafficRadioBearerConf::dlQCISchedulingWeight
Parameter dlQCISchedulingWeight
{0.125, 0.25, 0.5, 1.0, 2.0, 4.0, 8.0, 16.0, 32.0, 64.0, 128}
Class/Source C--New-set-ups / system_reserved
Value O.D. (See Engineering Recommendation)
Feature FRS 160636
Page 140/472
CarrierAggregationSecondaryConf::dlCABearerSchedulingWeight
Parameter dlCABearerSchedulingWeight
Object
{0.125, 0.25, 0.5, 1.0, 2.0, 4.0, 8.0, 16.0, 32.0, 64.0, 128}
Feature 160847
Page 141/472
Engineering Recommendation: Parameter dlQCISchedulingWeight
This parameter is set at bearer level. The setting depends on the end-user quality
of the service that the operator wants to achieve.
e.g. if the operator need to provide 3 different Web Access (or some other Best
Effort) application Grades of Service (GoS), e.g. Gold, Silver and Bronze, this is
possible by mapping each GoS to a distinct QCI, e.g. QCI6, QCI8 and QCI9,
respectively, and setting dlQCISchedulingWeight associated with these QCIs in
the right proportions, i.e. for a resource allocation ratio of 4:2:1 among the
Gold:Silver:Bronze GoSs, setting dlQCISchedulingWeight as follows:
GoS qCI dlQCISchedulingWeight
Gold 6 2.0
Silver 8 1.0
Bronze 9 0.5
If on top of that, a VoIP service and a video service are also provided, 3 bearers
need to be established: a QCI1 bearer for the VoIP data traffic and e.g. a QCI5
bearer for the IMS signaling for the VoIP service, as well as e.g. a QCI2 bearer for
the video service.
In order for the VoIP service (with its very tight timing constraints) not to be
disturbed by the traffic of the other services, its priority (and thus QoS weight)
would need to be set much higher than that of Best Effort services, whereas the
video service would need a priority (and thus QoS weight) that would be higher
than that of Best Effort services but lower than that of the VoIP service. e.g.
Service qCI dlQCISchedulingWeight
VoIP IMS Signaling 5 16.0
VoIP data 1 8.0
Video Streaming 2 4.0
Note that the default setting does not create any differentiation on top of the
GBR/n-GBR and delay-based differentiations:
qCI dlQCISchedulingWeight
1 1.0
2 1.0
3 1.0
4 1.0
5 1.0
6 1.0
Page 142/472
7 1.0
8 1.0
9 1.0
In case of Carrier Aggregation, the current recommended setting for parameter

CarrierAggregationSecondaryConf::dlCABearerSchedulingWeight applicable
to all CA bearers in the SCell is 1.
Feature L115698 introduces a per-QCI minimum throughput target concept into the
dynamic RF schedulers and it is monitored / controlled by the schedulers.
The active throughput is defined as the throughput when the radio bearer has data.
To account for network jitter and protocol delay, any data bursts with distance lower
than a configurable threshold (rabInactivity) is regarded as one data burst but the
gap is discounted from throughput calculation.
When the active throughput approaches or falls below the minimum throughput
target, the scheduler applies a dynamic weight on the bearer to help scheduling the
traffic faster. Once the active throughput well exceeds the minimum throughput
target, the additional weight is removed.
DL scheduler supports PDB-based QoS enforcement for nonGBR traffic since LA3.
With the new feature, it is desirable to be able to achieve an appropriate QoS
behavior depending on the most relevant QoS metric for the applications. Therefore
a selection parameter (dlQoSMetricType) is provided to allow customers to choose
the desired metric for QoS 176 enforcement, which offers flexible QoS control across
different QCIs.
DL scheduler is operating on a radio bearer basis and tracks the performance
of each radio bearer:
Figure 11: Data burst where the active throughput is measured

To facilitate the implementation, the active throughput is estimated via an IIR filter
initialized at the beginning of each data burst. To account for network jitter and
protocol delay, any data bursts with distance lower than a configurable threshold is
regarded as one data burst but the gap duration is discounted.
Feature 128460 is optional and active with flag isNonGBRMinRateEnabled.
Page 143/472
When this parameter is set to ‘True’, DL scheduler will maintain a UE’s minimum
non-GBR throughput target.
ActivationService::isNonGBRMinRateEnabled
Parameter isNonGBRMinRateEnabled
True/False
Feature FRS 128460 (L115698)
LR13.1 Parameter isNonGBRMinRateEnabled
This parameter is new in LR13.1, it is introduced by Feature 128460.
Restriction: isNonGBRMinRateEnabled
LR13.1 feature minRate-based QoS for nonGBR is supported only on bCEM.
When the feature is activated, there are several configuration parameters that need
to be set to enable the feature functionality.
Parameter dlMinThroughputTarget specifies the minimum DL active throughput

target enforced by DL scheduler for non-GBR bearer per QCI, when the bearer has
data to be transmitted over DL.
TrafficRadioBearerConf::dlMinThroughputTarget
Parameter dlMinThroughputTarget
[0..5000] with step = 50 Kbps
Value Default: 0
Feature FRS 128460 (L115698), 160847
Page 144/472
CarrierAggregationSecondaryConf::dlMinThroughputTarget
Parameter dlMinThroughputTarget
ENBEquipment/Enb/LteCell/CarrierAggregationConf/Carrier
Object
[0..5000] with step = 50 Kbps
Value Default: 0
Feature FRS 128460 (L115698), 160847
Parameter dlQoSMetricType specifies the DL QoS metric for nonGBR service and
CA bearer in SCell.
TrafficRadioBearerConf::dlQoSMetricType
CarrierAggregationSecondaryConf::dlQoSMetricType
Parameter dlQoSMetricType
ENBEquipment/Enb/DedicatedConf/TrafficRadioBearerConf
Object ENBEquipment/Enb/LteCell/CarrierAggregationConf/Carrier
{None, Pdb, Rate}
Value Default: None
Feature FRS 128460 (L115698), 160847
When set to ‘None’, it means this QCI traffic radio bearer has no specific QoS metric
to enforce.
When set to ‘Pdb’, it means this bearer is under the PDB-dependent QoS control.
This selection requires L92095 (PDB enforcement) feature to be activated indicated
by the activation flag isNonGbrPdbForWeightAllowed. If the activation flag is set to
‘False’, this selection is not allowed.
When set to ‘Rate’, it means the bearer is under the minimum rate QoS control. This
selection requires feature activation as indicated above. If the feature is disabled, this
selection is not allowed.
Parameter dlNonGBRClippingFactor (resp. dlCABearerClippingFactor) specifies

the maximum DL QoS weight exp(dlNonGbrClippingFactor) for nonGBR service
(resp. for CA bearer in SCell) due to QoS metric enforcement, including minRate and
PDB.
Page 145/472
EnbRadioConf::dlNonGBRClippingFactor
Parameter dlNonGBRClippingFactor
[1..5]
Value Default: 2
Feature FRS 128460 (L115698)
EnbRadioConf::dlCABearerClippingFactor
Parameter dlCABearerClippingFactor
[1..5]
Value Default: 2
Feature 160847
Parameter dlActiveThroughputAverageCoefficient (resp.

dlActiveThroughputAverageCoefficientForCABearer) configures the forgetting
factor used in the IIR filter for the active bearer (resp. CA bearer in SCell) level
throughput evaluation.
This parameter specifies the averaging coefficient for the DL active bearer
throughput evaluation. Used in minRate evaluation for nonGBR service. The value is
divided by 1024 to provide a forgetting factor between 0 and 0.999.
EnbRadioConf::dlActiveThroughputAverageCoefficient
Parameter dlActiveThroughputAverageCoefficient
[0 – 1023]
Value Default: 1014
Feature FRS 128460 (L115698)
Page 146/472
EnbRadioConf:: dlActiveThroughputAverageCoefficientForCABearer
Parameter dlActiveThroughputAverageCoefficientForCABearer
[0 – 1023]
Value Default: 1014
Feature 160847
Parameter rabInactivityTimer (caBearerInactivityTimer for CA bearer in SCell)

defines the timer within which any traffic arrival is regarded as part of a continuous
data burst.
This parameter specifies the duration of the timer used to determine whether an
established E-RAB is inactive. This information is used to peg counter 12635 in case
a bearer is dropped while its inactivity time is above the value of this parameter.
EnbRadioConf::rabInactivityTimer
Parameter rabInactivityTimer
[0 – 10000] ms
Value Default: 150
Feature FRS 128460 (L115698)
EnbRadioConf::caBearerInactivityTimer
Parameter caBearerInactivityTimer
[0 – 10000] ms
Value Default: 150
Feature 160847
Parameter marginForNonGbrMinRateEnforcement (resp.

marginForCABearerMinRateEnforcement) specifies the margin beyond the
minimum throughput target that scheduler starts to raise the scheduling priority for
the user/bearer (resp. CA bearer in SCell).
Page 147/472
EnbRadioConf::marginForNonGbrMinRateEnforcement
Parameter marginForNonGbrMinRateEnforcement
Range & Unit Float&ms
[0.1..3.0] with step = 0.1 ms
Value Default: 0.5
Feature FRS 128460 (L115698)
EnbRadioConf::marginForCABearerMinRateEnforcement
Range & Unit Float&ms
[0.1..3.0] with step = 0.1
Value Default: 0.5
Feature 160847
Feature L115698 interacts with feature 92065, as already mentioned. Feature 92065
provides a PDB-based differentiation method for DL non-GBR traffic whereas feature
L115698 provides a min-rate enforcement for the non-GBR differentiation. To utilize
both QoS capabilities, configuration parameter dlQosMetricType will be placed per
non-GBR QCI to allow customer to select either the min-rate or PDB-based
enforcement when both features are enabled in the eNB.
Engineering Recommendation: Example to activate feature:

1. Set the feature activation flag: isMinRateEnforcementEnabled
2. For the QCI that wishes to use min rate control, set dlQoSMetricType=Rate
3. For that QCI, set dlMinThroughputTarget to the desired value.
4.5.3.8.2 RESOURCE BLOCK AND RESOURCE BLOCK

GROUP ALLOCATION
This procedure consists in allocating the Resource Blocks remaining after the semi-
static scheduling and HARQ allocation stages.
When the licensing of Resource Blocks is activated, i.e. when
isUnlimitedPRBLicenseAllowed is set to “False” and the PRB license is enforced,
the usage of RBs is monitored for this purpose and resource allocation for signaling
and traffic logical channels is constrained by this license.
Page 148/472
On bCEM, there is a specific RB zone defined where bearers are allocated RBs
instead of RBGs. This RB allocation zone is used for allocating bearers using
contiguous allocations (i.e. DCI1A). Therefore, when a bearer is using RB allocation
type 2 (i.e. DCI1A) and the per RB allocation is enabled for this type of bearer, it will
be allocated in the RB allocation zone.
When a bearer is sent in this zone, there is no round-up to the RBG boundary and
the RBs left after the allocations are usable for another bearer to be allocated in this
zone. This allows saving a lot of resources in particular when the VoIP load is getting
high.
The resource allocation for MAC CEs is done per RB (due to the limited size of MAC
CEs).
The procedure allocates an RB (in the RB allocation zone only) or an RBG to a

bearer chosen from the list of eligible bearers, according to their respective allocation
metric. The Algorithm consists in allocating each RB or RBG to the bearer or MAC
CE “u” with the highest allocation metric on the RB or RBG in question.
Note that in the RB allocation zone, due to the constraint of DCI1A contiguity, the
allocation is stopped when a first non-free RB is found.
Also note that the RBG allocation (main) loop scans RBGs and allocates them in
increasing order of RBG index whereas the RB Allocation zone loop scans RBs and
allocates them in decreasing order of RB index.
The start of the allocation (for both loops) is close to the middle of the bandwidth.
This is to have the MAC CEs sent far from the edge RBs which suffer from poor
performance.
The RB allocation zone starts from (RBG allocation zone start index -1) in
descending numbering order.
The RBG allocation zone start index is defined by the following table:
Bandwidth
5 MHz 10 MHz 15 MHz 20 MHz
RBGinit RBG4 RBG7 RBG8 RBG11
RBinit RB8 RB21 RB33 RB46
The RB allocation zone start index and size are given by the following table:
Bandwidth
5 MHz 10 MHz 15 MHz 20 MHz
RBZinit RB7 RB20 RB32 RB43
RBAllocationZoneSize 17 41 77 90
Page 149/472
Note that the 6 central RBs are excluded from the RB allocation Zone.
Central RBs
Init RB start index for
Init RB start index
RBAllocationZone
RB Allocation Zone
RB Allocation Zone Loop MainLoop
RB Allocation
MainLoop
Zone Loop
Figure 11 : RBG allocation main loop and RB Allocation zone loop
Note that the allocation size (MaxNbrRBG or MaxNbrRB for the RB allocation zone) is
upper-limited by the UE category maximum TBS and/or by the amount of data in the
RLC buffer of the bearer in question (i.e. the lowest TBS allowing to empty the RLC
buffer of the bearer in question). This upper limit is determined using an estimate of
the MCS (MCS0 for MAC CEs) that would be used for the transmission if the bearer
were scheduled. Also, if the estimate of the MCS, together with the upper limit on the
TBS lead to a coding rate higher than 0.93, the MCS estimate used for the
determination of MaxNbrRBG or MaxNbrRB (for the RB allocation zone) is
downgraded (while keeping the TBS upper limit intact) so that the coding rate goes
back below 0.93.
When a bearer is selected for transmission, the scheduler checks whether there are
enough PDCCH resources available for the grant. If there are not enough CCE
resources available for the grant, the bearer is not scheduled. Also, when there is no
CCE left, only previously scheduled UEs compete for the remaining resources.
On the other hand, if PDCCH power control is activated (see section 6.1.2) and there
aren’t enough power resources available for the transmission of the grant, the bearer
is not scheduled, except for Timing Advance, SPS grants and SRB1, in which case
the grant is transmitted with whatever power is left.
If enough contiguous CCEs are not found and/or if the bearer is SRB0, SRB2 or a
DRB, and PDCCH power control is activated (see section 6.1.2) and there aren’t
enough power resources available for the transmission of the grant, the bearer is not
scheduled and the next highest allocation metric bearer is considered for the
allocation of the RB or RBG in question.
Page 150/472
In case the bearer is SRB0, SRB1 or QCI1 DRB, if there are enough CCE/power
resources to grant the bearer, the next RBGs are allocated to the same bearer until
the maximum grant size is reached or until there are no more RBGs left. This is to
allocate contiguous RBs to these bearers.
fdsAllocationType1Activation : This parameter activates the usage of Allocation

Type 1 for FD users in Dynamic Scheduler.
CellL2DLConf::fdsAllocationType1Activation
Parameter fdsAllocationType1Activation
True/False
Value False
Feature FRS 115686
fdsAllocationType2DistributedActivation: This parameter activates the usage of

Allocation Type 2 Distributed for FD users in Dynamic Scheduler.
CellL2DLConf::fdsAllocationType2DistributedActivation
Parameter fdsAllocationType2DistributedActivation
True/False
Value False
Feature FRS 115686
fdsPerPRBAllocationActivation: This parameter activates the per PRB allocation

for FD users in Dynamic Scheduler.
Page 151/472
CellL2DLConf::fdsPerPRBAllocationActivation
Parameter fdsPerPRBAllocationActivation
True/False
Value False
Feature FRS 115686
voIPAllocationType1Activation: This parameter activates the usage of Allocation

Type 1 for VoIP in Dynamic Scheduler.
CellL2DLConf::voIPAllocationType1Activation
Parameter voIPAllocationType1Activation
True/False
Value False
Feature FRS 115686
voIPAllocationType2DistributedActivation: This parameter activates the usage

of Allocation Type 2 Distributed for VoIP in Dynamic Scheduler.
CellL2DLConf::voIPAllocationType2DistributedActivation
Parameter voIPAllocationType2DistributedActivation
True/False
Value False
Feature FRS 115686
Page 152/472
voIPPerPRBAllocationActivation: This parameter activates the per PRB allocation

for VoIP in Dynamic Scheduler.
CellL2DLConf::voIPPerPRBAllocationActivation
Parameter voIPPerPRBAllocationActivation
True/False
Value False
Feature FRS 115686
4.5.3.9 MCS ALLOCATION
For MAC CEs, the MCS that is used is MCS0.

For SRB 0, the MCS that is used is derived as follows:
• If rachMsg4ForceMCSmin is set to “-1”

o If maximumNumberOfDLTransmisionsRACHMessage4 ≥ 3 (i.e. if
maximumNumberOfDLTransmisionsRACHMessage4 is set to 3,
or 4, or 5, or 6, or 7 or 8), the MCS used is MCS 6.
o If maximumNumberOfDLTransmisionsRACHMessage4 is set to
2, the MCS used is MCS 3.
o Else (i.e. if maximumNumberOfDLTransmisionsRACHMessage4
is set to 1), the MCS used is MCS 0.
• Else, the MCS is given by parameter rachMsg4ForceMCSmin.
For other bearers and/or TA commands, the Modulation and Coding Scheme (MCS)
that is allocated (to transmit data on the scheduled bearer) is adapted to changing
radio conditions (or radio link quality) of the UE. An improvement in the radio link
quality (increase in the SINR) causes the transmitter to use a less robust MCS and
hence a higher data transmission rate. Conversely, a degradation in the radio link
quality (decrease in the SINR) causes the transmitter to use a more robust MCS and
hence a lower data transmission rate. The selected MCS is the one that maximizes
the transmission rate for a given targeted BLER. The latter is configured at bearer
type level using parameter
TrafficRadioBearerConf::macOuterLoopBlerConrolTargetBlerDl, parameter
SignalingRadioBearerConf::macOuterLoopBlerConrolTargetBlerDl or
CarrierAggregationSecondaryConf::macOuterLoopBlerControlTargetBlerDl
Page 153/472
(depending on whether it is a data radio bearer,a signaling dedicated radio bearer or

a CA bearer (in SCell)).
Note that when parameter cqiReportingModeAperiodic is set to “disabled”, the UE

reports no CQI. In this case, the downlink scheduler uses the MCS configured by
parameter TrafficRadioBearerConf::macInitialMCSIndexForBearerSetupDl and
SignalingRadioBearerConf::macInitialMCSIndexForBearerSetupDl.
CellRachConf::rachMsg4ForceMCSmin
Parameter rachMsg4ForceMCSmin
[-1..9]
Value -1
Feature FRS 90852
TrafficRadioBearerConf::macOuterLoopBlerControlTargetBlerDl
CarrierAggregationSecondaryConf::macOuterLoopBlerControlTargetBlerDl
Parameter macOuterLoopBlerControlTargetBlerDl
Object ENBEquipment/Enb/LteCell/CarrierAggregationConf/CarrierAg
[0..50] %
Value 10
Feature 160847
Page 154/472
SignalingRadioBearerConf::macOuterLoopBlerControlTargetBlerDl
Parameter macOuterLoopBlerControlTargetBlerDl
[0..50] %
Value 10
Feature
At each new TTI, the MCS allocation algorithm provides each scheduled bearer with
a coding scheme common to all its PRBs. The algorithm takes a set of allocated
PRBs and the associated reported CQI values as inputs, and outputs:
• The common MCS index to be applied for transmission over the allocated PRBs
• The associated TBS.
The MCS allocation algorithm converts CQI values into SINR values using a lookup
table configured by parameter cQIToSINRLookUpTable. These SINR values are
used to produce one SINR value that is used to derive the MCS ( SINR MCS ). Twenty-
nine SINR MCS intervals are defined. Each of them corresponds to an MCS. The
lowest interval corresponds to the most robust MCS (and hence to the lowest
transmission rate). The highest interval corresponds to the least robust MCS (and
hence to the highest transmission rate). The selected MCS is the one that is mapped
to the interval SINR MCS falls into. The intervals do not overlap and the transition from
an interval to another is defined by a threshold value.
Note that a BLER Loop Control (BLC) algorithm applies an offset to the SINR used to
derive the MCS in order for the BLER to converge to target BLER.
The patch for BLER convergence improvement, introduced in LA5.0 and

activated/deactivated by bit 12 of LteCell::spare4, is always activated (bit12 is
hardcoded to ‘1’) starting LR13.1 for both bCEM and eCEM..
Page 155/472
CellRadioConf::cQIToSINRLookUpTable
Parameter cQIToSINRLookUpTable
Range & Unit List of 15 Float values
[-10..30] step = 0.25 dB
[-6.00, -4.00, -2.75, -0.75, 1.25, 2.75, 5.00, 6.75, 8.50,
Value 10.75, 12.50, 14.50, 16.25, 17.75, 20.00] ALU recommends
the operator to not change change this setting
Feature
TrafficRadioBearerConf::macSINROffsetForLinkAdaptationDl
CarrierAggregationSecondaryConf::macSINROffsetForLinkAdaptationDl
Parameter macSINROffsetForLinkAdaptationDl
Object ENBEquipment/Enb/LteCell/CarrierAggregationConf/CarrierAg
Range & Unit Float
[-20..20] step = 0.25 dB
Value 0.0
Feature 160847
SignalingRadioBearerConf::macSINROffsetForLinkAdaptationDl
Parameter macSINROffsetForLinkAdaptationDl
Range & Unit Float
[-20.0..20.0] step = 0.25 dB
Feature
Page 156/472

SignalingRadioBearerConf::macSINROffsetForLinkAdaptationDl
The current setting of

SignalingRadioBearerConf::macSINROffsetForLinkAdaptationDl is as
follows:
sRBIdentity macSINROffsetForLinkAdaptationDl
1 -5.0
2 0.0
CellRadioConf::dlMCSTransitionTable
Parameter dlMCSTransitionTable
Range & Unit List of 28 Float values
[-10.0..30.0] step = 0.25 dB
See Engineering Recommendation ALU recommends the
Value
operator to not change change this setting
Feature
Page 157/472
Engineering Recommendation: Parameter dlMCSTransitionTable
This is a key RF optimization parameter. Higher threshold values will result in

lower data rates. Lower values will lead to more optimistic MCS assignments and
hence, more HARQ retransmissions and higher BLERs. Besides, TCP congestion
control will be triggered more often, resulting in a downlink throughput reduction.
This parameter is currently defaulted as follows:
dynamicCFIEnabled cFI dlMCSTransitionTable
False 1 [-6.25, -5.5, -5.0, -4.25, -3.25, -3.0, -1.5, -

0.75, 0.0, 1.0, 1.25, 2.25, 3.25, 3.75, 4.75,
5.5, 6.5, 7.75, 8.0, 9.0, 9.75, 10.5, 11.75,
12.5, 13.25, 14.0, 15.25, 16.25]
2 [-4.50 -4.00 -3.25 -2.50 -1.50 -1.25 0.50 1.25

2.00 3.00 3.25 4.25 5.25 5.75 6.50 7.25 8.50
9.75 10.00 10.75 11.75 12.50 13.75 14.50
15.25 16.00 17.00 19.00]
3 [-2.50, -2.00, -1.25,-0.50, 0.50, 0.75, 2.00,

2.75, 3.75, 4.75, 5.00, 6.00, 7.00, 7.25, 8.25,
9.00, 10.25, 11.50, 11.75, 12.50, 13.25,
14.25, 15.25, 16.25, 16.75, 17.75, 18.75,
20.00]
True Not Same as the (dynamicCFIEnabled = False,

Significant cFI=3) case as when dynamic CFI is
activated, the MCS allocation algorithm uses
the table corresponding to the case
(dynamicCFIEnabled = False, cFI=3) and
applies a CFI=2 (resp. CFI=1) offset to
SINR MCS in case CFI=2 (resp. CFI=1) is
decided by the dynamic CFI algorithm.
4.5.3.10 SPS MCS AND PRB ALLOCATION SIZE DETERMINATION
4.5.3.10.1 DETERMINATION OF THE MCS USED FOR

PRB ALLOCATION SIZE DETERMINATION
MCSSPS
In the case of the SPS allocation, the MCS is decided at the start of the talk spurt
and used throughout the talk spurt.
Page 158/472
If no CQI report is received when the first SPS Activation is engaged, the MCS
provisioned through parameter spsInitialMCSIndexForBearerSetupDl is used.
However, parameters spsActivationProhibitTimeUponCallSetupWithROHC and
spsActivationProhibitTimeUponCallSetupWithOutROHC which control the time
after call setup when SPS can be activated, should be provisioned large enough for a
CQI-report to be received when the SPS activation is engaged.
Note that the periodicCQISINRAveragingCoefficientForSPSDl is specific for the
lowest period of 20ms. Therefore, the averaging coefficient is scaled internally
depending for other periods:
P-CQI
cqi-pmi-ConfigIndex in LUT Forgetting Factor
Period
17 ≤ cqi-pmi-ConfigIndex ≤ 36 20 periodicCQISINRAveragingCoefficientForSPSDl
periodicCQISINRAveragingCoefficientForSPSDl
37 ≤ cqi-pmi-ConfigIndex ≤ 76 40
×2
periodicCQISINRAveragingCoefficientForSPSDl
77 ≤ cqi-pmi-ConfigIndex ≤ 156 80
×4
157 ≤ cqi-pmi-ConfigIndex ≤ periodicCQISINRAveragingCoefficientForSPSDl

160
316 ×8
If spsLinkAdaptationImprovementActivation is set to “True”, and in order to

minimize the padding, MCS SPS is not derived using SINRSPS MCS as per section
4.5.3.10.1 but derived using the “SINR-VoIP TBS to MCS LUT” based on DL SPS
TBS and min( SINRSPS (t ), SINR(t 0 )) .
SPS PRB size determination when spsLinkAdaptationImprovementActivation

is set to “True”:
If spsLinkAdaptationImprovementActivation is set to “True”, and in order to
minimize the padding, the SPS allocation size is derived using the “SINR-VoIP TBS
to PRB LUT” based on DL SPS TBS and min( SINRSPS (t ), SINR(t 0 )) .
Information about VoIP codec rate is received by the eNB over the S1. However, a
parameter, overrideS1GBRinfoForVoIP, controls whether the scheduler shall make
use of that S1 GBR information to derive the SPS or DS TBS (when the parameter is
set to ‘false’) or whether, instead, it shall assume the value of the
defaultCodecforVoIPserviceUl and defaultCodecforVoIPserviceDl parameters for
VoIP.
The SPS TBS is determined as follows (4 possible cases depending on RoHC status
and the overrideS1GBRinfoForVoIP flag):
Page 159/472
• If overrideS1GBRinfoForVoIP is set to “True”
In this case, the DL VoIP GBR received on the S1 interface is ignored.

The SPS VoIP TBS is derived assuming the default codec, configured by
parameter defaultCodecforVoIPserviceDl; a Lookup table is used. The
latter maps the codec to the VoIP packet size before the PDCP, RLC
and MAC headers are appended, associated with the nominal VoIP
frame size for the considered Codec. The TBS is obtained by adding the
DL PDCP/RLC/MAC overhead, configured by parameter
macRLCOverheadDl.
Three different Lookup tables are defined:
o A table for when RoHC is used, assuming RoHC header = 4 bytes.

o A second table for when RoHC is not used and IPv4 is used
(iPversionForVoIP is set to “ipv4”), assuming RTP/UDP/IPv4
header = 12(RTP) + 8(UDP) + 20 (IPv4) = 40 bytes.
o A third table for when RoHC is not used and IPv6 is used
(iPversionForVoIP is set to “ipv6”), assuming RTP/UDP/IPv6
header = 12(RTP) + 8(UDP) + 40 (IPv4) = 60 bytes.
VoIP codec IP packet size (bytes)

AMR 12.20 35
AMR 10.20 30
AMR 7.95 25
AMR 7.40 23
AMR 6.70 22
AMR 5.90 20
AMR 5.15 18
AMR 4.75 17
WB-AMR 23.85 65
WB-AMR 23.05 63
WB-AMR 19.85 55
WB-AMR 18.25 51
WB-AMR 15.85 45
WB-AMR 14.25 41
WB-AMR 12.65 37
WB-AMR 8.85 27
WB-AMR 6.60 22
Table 19: VoIP codec-to-IP packet size mapping when RoHC is used
Page 160/472
VoIP codec RLC SDU size (bytes) RLC SDU size (bytes)
IPv4 IPv6
AMR 12.20 71 71 + 20 = 91
AMR 10.20 66 66 + 20 = 86
AMR 7.95 61 61 + 20 = 81
AMR 7.40 59 59 + 20 = 79
AMR 6.70 58 58 + 20 = 78
AMR 5.90 56 56 + 20 = 76
AMR 5.15 54 54 + 20 = 74
AMR 4.75 53 53 + 20 = 73
WB-AMR 23.85 101 101 + 20 = 121
WB-AMR 23.05 99 99 + 20 = 119
WB-AMR 19.85 91 91 + 20 = 111
WB-AMR 18.25 87 87 + 20 = 107
WB-AMR 15.85 81 81 + 20 = 101
WB-AMR 14.25 77 77 + 20 = 97
WB-AMR 12.65 73 73 + 20 = 93
WB-AMR 8.85 63 63 + 20 = 83
WB-AMR 6.60 58 58 + 20 = 78
Table 20: VoIP codec-to-IP packet size mapping when RoHC is not used
• Else (i.e. if overrideS1GBRinfoForVoIP is set to “False”)

In this case, the DL VoIP GBR received on the S1 interface is used to
derive the TBS:
o If RoHC is used, the GBR value is mapped to one of the codecs:
AMR-12.20, AMR-10.20, AMR-7.95, AMR-7.40, AMR-6.70, AMR-
5.90, AMR-5.15, AMR-4.75, AMR-WB-23.85, AMR-WB-23.05,
AMR-WB-19.85, AMR-WB-18.25, AMR-WB-15.85, AMR-WB-14.25,
AMR-WB-12.65, AMR-WB-8.85, AMR-WB-6.60.
Then, the right lookup table is used to map the VoIP packet size
before the PDCP, RLC and MAC headers are appended, associated
with the nominal VoIP frame size for the considered Codec. The TBS
is obtained by adding the DL PDCP/RLC/MAC overhead, configured
by parameter macRLCOverheadDl.
o If RoHC is not used, the TBS is computed as TBS = S1 DL GBR ×
0.020 ms + macRLCOverheadDl.
Page 161/472
EnbVoipConf::overrideS1GBRinfoForVoIP
Parameter overrideS1GBRinfoForVoIP
Object ENBEquipment/Enb/EnbVoipConf
True/False
Class/Source B--Cells-of-NE / customer_settable
Value true
Feature L115647.1
defaultCodecforVoIPServiceDl: This parameter controls the type of downlink

speech codec assumed for deriving the SPS DL grant size when parameter
overrideS1GBRinfoForVoIP is set to ‘true’.
DownlinkSemiPersistentSchedulingConf::defaultCodecforVoIPServiceDl
Parameter defaultCodecforVoIPServiceDl
Object
{ AMR-12.20, AMR-10.20, AMR-7.95, AMR-7.40, AMR-6.70, AMR-
5.90, AMR-5.15, AMR-4.75, AMR-WB-23.85, AMR-WB-23.05, AMR-
WB-19.85, AMR-WB-18.25, AMR-WB-15.85, AMR-WB-14.25, AMR-
WB-12.65, AMR-WB-8.85, AMR-WB-6.60 }
Feature L114531.1
Engineering Recommendation: Parameter defaultCodecforVoIPServiceDl
This parameter should be set to the value corresponding to the VoIP codec being
used in the DL for the VoIP test in question.
This parameter is defaulted to “AMR-WB-12.20”.
macRLCOverheadDl: This parameter controls the amount of PDCP, RLC and MAC
overhead assumed to be used for downlink VoIP frames.
Page 162/472
DownlinkSemiPersistentSchedulingConf::macRLCOverheadDl
Parameter macRLCOverheadDl
Object
[0..64]
Value 3
Feature FRS 114531
tBScombinationMethodSPSDl: This parameter selects the TBS to be used when 2

VoIP calls are multiplexed. It is possible to select the sum or the max of the 2 TBS.
DownlinkSemiPersistentSchedulingConf::tBScombinationMethodSPSDl
Parameter tBScombinationMethodSPSDl
Object
{ sum (0), max(1) }
Value sum
Feature FRS 115239(.1), FRS 162790
spsLinkAdaptationImprovementActivation: This parameter activates the Link

Adaptation Improvement for SPS.
DownlinkSemiPersistentSchedulingConf::spsLinkAdaptationImprovementActi
vation
Parameter spsLinkAdaptationImprovementActivation
Object
True/False
Value False
Feature FRS 115686
Page 163/472
Restriction: spsLinkAdaptationImprovementActivation
Note that, the parameter should be set to true only if the voice codec rate is
<=15.85 kbps
4.5.3.10.2 MCS CAPPING
The value of MCS SPS is finally limited to the first 15 MCSs that are supported for
SPS. The allocated MCS is MCS SPS if 1 ≤ MCS SPS ≤ 15 and MCS15 if MCS SPS > 15 .
4.5.3.11 CARRIER AGGREGATION
4.5.3.11.1 DL DYNAMIC SCHEDULER RE-

ARCHITECTURE
In LR13.3, DL carrier aggregation with up to 2 carriers is supported. For this, the DL

dynamic scheduler is split into 2 parts in:
• The “UE Scheduler” (aka “DL Dynamic UE Scheduler”) and
• The “Carrier Scheduler” (aka “DL Dynamic Carrier Scheduler”)
For a given cell, the UE Scheduler is the first step responsible to select a subset of
UEs present in that (P)Cell for the Carrier Scheduler for the (P)Cell. The UE
Scheduler includes a new part dedicated to Carrier Aggregation, the CA Scheduler.
For CA configured users, the CA Scheduler selects a subset of Rel’10 CA activated
UEs for the Carrier Scheduler.
For a given cell, the Carrier Scheduler, is the second step responsible to allocate
radio resource to the “best” UE among the UEs selected by both UE & CA
Scheduler. Every TTI, the Dynamic Carrier Scheduler uses the resources which are
left available by the Static and Semi-Static Schedulers. The input for the dynamic
carrier scheduler is per sub-frame:
● The RB allocation of the semi-static scheduler, which are not usable by the
dynamic scheduler
● The remaining CCE resources to share among users
● The list of pre-selected UE & bearers candidate for scheduling in this TTI with
their metrics coming from the 2 UE Schedulers (further referred as Primary UE
Scheduler and Secondary UE Scheduler)
Page 164/472
UE/CA Scheduler function
Rel’8/Rel’9 Rel’10 CA
Functions Functions
UE Screening Bearer pre-

Metric Calculation UE pre-filtering
Process selection
CA Metric CA Bearer pre-

CA pre-filtering
Calculation selection
CA State Machine
Carrier Scheduler
CA Scheduler
Band ‘x’ Cell
UE Scheduler in Band ‘x’ Cell
UE Screening Bearer pre-

Metric Calculation UE pre-filtering
Process selection
CA Metric CA Bearer pre-

CA pre-filtering
Calculation selection
CA State Machine
CA Scheduler Carrier Scheduler
UE Scheduler in Band ‘y’ Cell Band ‘y’ Cell
Figure 12 DL Carrier Scheduler for CA operation
4.5.3.11.2 LINK AND RANK ADAPTATION ON PCELL

AND SCELL
Rel-10 Aperoidic Channel State Information (CSI) (A-CSI), which consists of channel
quality indicator (CQI), precoding matrix indicator (PMI) and /or rank indication (RI),
is supported to perform link and rank adaptation for SCell (A-CSI_S).
DownlinkCAConf::cqiReportAperiodicR10Enabled
Parameter cqiReportAperiodicR10Enabled
ENBEquipment/Enb/
Object CarrierAggregationConf/CarrierAggregationPrimaryConf/
DownlinkCAConf
True, False
Value True
Feature 160847
All CA configured and activated users are configured with A-CSI_S.
Page 165/472
Note: The number of UE that can be configured with CA

(CarrierAggregationPrimaryConf::nbMaxCAConfiguredUePerPcell) in a PCell
depends on the frequency bandwidth:
CarrierAggregationPrimaryConf::nbMaxCAConfiguredUePerPcell
Parameter nbMaxCAConfiguredUePerPcell
Object
gregationPrimaryConf/
[0..48]
48 for 10MHz
Value 25 for 5MHz
ALU recommends the operator to not change this value
Feature 160847
For link and rank adaptation on PCell, periodic CSI (P-CSI_P) is configured for CA
users as it is done for non-CA users via
CellL1ULConf::initPUCCHSRSConfigProfile (see [Vol. 3]); aperiodic CSI for PCell
(A-CSI_P) can be configured as well, using existing mechanisms, limited to 8 users.
A-CSI _S is configured via CQI-ReportAperiodic-r10 IE in RRC Reconfiguration
Procedure. The IE indicates for which serving cell(s) the aperiodic CSI report is
triggered when one or more SCells are configured. trigger1 corresponds to the CSI
request field 10 and trigger2 corresponds to the CSI request field 11 in the table
below, per 3GPP 36.213, section 7.2.1.
Value of CSI request field Description
’00’ No aperiodic CSI report is triggered

‘01’ Aperiodic CSI report is triggered for serving cell c
Aperiodic CSI report is triggered for a 1st set of
‘10’ serving cells configured by higher layers
Aperiodic CSI report is triggered for a 2nd set of
‘11’ serving cells configured by higher layers
trigger1 is configured via DownlinkCAConf::aperiodicCSITriggerR10Trigger1 by

default set to aCSIforSCell1
Note: trigger2 is not used in LR13

(DownlinkCAConf::aperiodicCSITriggerR10Trigger2)
Page 166/472
DownlinkCAConf::aperiodicCSITriggerR10Trigger1
Parameter aperiodicCSITriggerR10Trigger1
Object
aCSIforSCell1, aCSIforPCellAndSCell1
aCSIforSCell1 ALU recommends the operator to not change this
Value
setting
Feature 160847
CarrierAggregationSecondaryConf::aperiodicCSIRankAveragingCoefficientFor
SCell
Parameter aperiodicCSIrankAveragingCoefficientForSCell
ENBEquipment/Enb/LteCell/CarrierAggregationConf/
Object
CarrierAggregationSecondaryConf
[0.. 16384]
164 The function associated with this parameter is considered
Value
personnel.
Feature 160847
CarrierAggregationSecondaryConf::aperiodicCSISINRAveragingCoefficientFor
SCell
Parameter aperiodicCSISINRAveragingCoefficientForSCell
Object
[0.. 16384]
Class/Source B--Cells-of-eNB/ system_restricted
Value
personnel.
Feature 160847
Page 167/472
4.5.3.11.3 UL CRITERION FOR CA CONFIGURATION

AND DECONFIGURATION
In order to be eligible to CA in DL, the UE shall fullfill, among other criteria (see Call
Management Volume), UL radio conditions. As a matter of fact, UL shall meet certain
quality level to ensure ACK/NACK reporting meets the required detection /
misdetection performances. Similar UL monitoring mechanism as the one for the
activation/deactivation of TTI Bundling for VoIP calls in LR13.1 is implemented.
A UL link budget metric is calculated for each (candidate) CA UE and maintained in
the CA UL triggers state machine:
UL Link Budget Metric (user k) = Normalized Power Headroom (user k) +

WB_PUSCH_SINR (user k)
The UL link budget metric is initialized with a value configured via spare parameter
LteCell::spare10 bits [0..6] and then IIR filtered using LteCell::spare10 bits [7..9].
LteCell::spare10
Parameter spare10 bits [0..6]
[0..100]
Mapped to Enb value = (spareValue/2) – 20 i.e [-20..30] dB, step
0.5
Class/Source C--New-Set-ups / System-Restricted
Value 40 (Default) corresponding to 0dB
Feature 160847
LteCell::spare10
Parameter spare10 bits [7..9]
[0…7]
Mapped on (1/2(0), 1/4(1), 1/8(2), 1/16(3), 1/32(4), 1/64(5),
1/128(6), 1/256(7))
Class/Source C--New-Set-ups / System-Restricted
Value 3 (Default) corresponding to 1/16
Feature 160847
The trigger (resp. clearance) threshold for alarm to de-configure (resp. to configure)
CA is set via UplinkCAConf::uplinkLinkBudgetAlarmTriggerThresholdForCA
(resp. UplinkCAConf::uplinkLinkBudgetAlarmClearanceThresholdForCA)
Page 168/472
The time to trigger and to clear the alarms are set through
UplinkCAConf::uplinkLinkBudgetAlarmTimeToTriggerForCA and
UplinkCAConf::uplinkLinkBudgetAlarmTimeToClearForCA)
The parameter UplinkCAConf::uplinkCAtriggerNotificationRepetitionTimer
controls the amount of time the state machine waits before repeating an uplink CA
trigger notification to CallP function when there is a trigger to activate / deactivate the
Carrier Aggregation RRC configuration in a call
UplinkCAConf::uplinkLinkBudgetAlarmTriggerThresholdForCA
Parameter uplinkLinkBudgetAlarmTriggerThresholdForCA
Object
gregationPrimaryConf/UplinkCAConf
Range & Unit Float
[-20.0..30.0] step = 0.5 dB
Value 0.0
Feature 160847
UplinkCAConf::uplinkLinkBudgetAlarmClearanceThresholdForCA
Parameter uplinkLinkBudgetAlarmClearanceThresholdForCA
Object
Range & Unit Float
[-20.0..30.0] step = 0.5 dB
Value 10.0
Feature 160847
UplinkCAConf::uplinkLinkBudgetAlarmTimeToClearForCA
Parameter uplinkLinkBudgetAlarmTimeToClearForCA
Object
Range & Unit Float
[0..10.0] step = 0.1s
Value 2.0
Feature 160847
Page 169/472
UplinkCAConf::uplinkLinkBudgetAlarmTimeToTriggerForCA
Parameter uplinkLinkBudgetAlarmTimeToTriggerCA
Object
Range & Unit Float
[0..10.0] step = 0.1s
Value 2.0
Feature 160847
UplinkCAConf::uplinkCAtriggerNotificationRepetitionTimer
Parameter uplinkCAtriggerNotificationRepetitionTimer
Object
Range & Unit Float
[0..10.0] step = 0.5s
Value 1.0
Feature 160847
4.5.3.11.4 OUT OF COVERAGE DETECTION ON SCELL
For UE with CA Activated, regular A-CSI_S are received which are used in Rank &
Link adaptation. When successive A-CSI_S reports CQI=0 (parameter
DownlinkCAConf::numberOfCQI0ForSCellForOutOfCoverageDetection), the UE
is not able to determine the CQI to be used in the SCell, and thus is considered out
of the SCell coverage. The DL scheduler stops to schedule the UE in SCell. Note
that CA remains configured as long as UL fulfils the conditions described in section
4.5.3.11.3. CA deactivation is not supported in this release neither via MAC
commands nor via timer expiry (DownlinkCAConf::sCellDeactivationTimerR10 is
always set to “Infinity”).
Page 170/472
DownlinkCAConf::numberOfCQI0ForSCellForOutOfCoverageDetection
Parameter numberOfCQI0ForSCellForOutOfCoverageDetection
Object
CarrierAggregationPrimaryConf/DownlinkCAConf
[1..15]
Value 2
Feature 160847
DownlinkCAConf::sCellDeactivationTimerR10
Parameter sCellDeactivationTimerR10
Object
{ rf2, rf4, rf8, rf16, rf32, rf64, rf128, infinity)} frames
Infinity ALU recommends the operator to not change this
Value
setting
Feature 160847
4.5.3.11.5 DL DYNAMIC UE SCHEDULING
DL CA/UE Scheduler computes scheduling metrics (Proportional Fair, Throughput &

Spectral Efficiency) for the PCell for CA Configured UE in the same way as a Non-
CA UE until UE is CA Activated. When CA Configured UE is CA Activated, DL
CA/UE Scheduler takes into account the SCell when computing the metrics
(Proportional Fair, Throughput & Spectral Efficiency) for the PCell and SCell.
Proportional Fair metric computed for the SCell must take into account the specific
weight for CA. A carrier aggregation fairness factor is introduced to set fairness:
• Per carrier i.e. CA user is getting fair share of the resources on each of its
activated carrier
(CarrierAggregationSecondaryConf::carrierCompensationFactor is set
to 0)
• Per CA-sector i.e. CA user is getting fair share of the resources over entire
activated carrier
(CarrierAggregationSecondaryConf::carrierCompensationFactor is set
to 1)
• Intermediate values allow the scheduler to provide an intermediate
fairness, where the SCell carrier is considered but not with the same weight
as the PCell
Page 171/472
CarrierAggregationSecondaryConf::carrierCompensationFactor
Parameter sCellDeactivationTimerR10
Object
Range & Unit Float
[0..1]
Value 0
Feature 160847
There is a maximum number of UE that can be pre-selected by the DL CA/UE

Scheduler
(CarrierAggregationSecondaryConf::maxNumberOfUEPreSelectedperTTI).
It is recommended to set the value to ‘4’. There is no minimum amount of data to
transmit is order to be preselected as the parameter
DownlinkCAConf::minTBSForSchedulingInSecondary that determines the
minimum estimated TBS required to preselect the user for sending data in the
SCell for a given TTI (in bytes) is always set to ‘0’.
CarrierAggregationSecondaryConf::maxNumberOfUEPreSelectedperTTI
Parameter maxNumberOfUEPreSelectedperTTI
Object
[1..5]
4 ALU recommends the operator to not change this
Value
setting
Feature 160847
Page 172/472
DownlinkCAConf::minTBSForSchedulingInSecondary
Parameter minTBSForSchedulingInSecondary
Object
[0.. 18845] Bytes
Value
setting
Feature 160847
There is a maximum number of UE that can be scheduled per TTI by the DL CA/UE
Scheduler
(CarrierAggregationSecondaryConf::maxNumberOfUEScheduledPerTTI). It is
recommended to set the value to ‘2’.
CarrierAggregationSecondaryConf::maxNumberOfUEScheduledPerTTI
Parameter maxNumberOfUEScheduledPerTTI
Object
[1..5]
Value
setting
Feature 160847
Page 173/472
4.5.4 OCNS
4.5.4.1 PDSCH OCNS
The OFDM Cell Noise Simulator (OCNS) simulates radio load on an LTE cell. It
consists in using a fraction of the remaining PRBs to generate a radio activity.
This feature provides each eNB with the capability to simulate its own data activity
over the air interface. It also allows the customer to assess the radio performance of
the different sites in loaded conditions.
Note that OCNS traffic is transmitted using the most robust MCS (MCS0) and that a
Transport Block is transmitted over an OCNS group (consecutive RBGs allocated to
OCNS).
Once the nominal scheduling is performed, the non-allocated RBGs are collected
and transformed into a set of RBs named t_RB.
Define the following numbers:
• Nreg : Number of RBs allocated by the nominal scheduling.
• Ntarget: Total number of RBs allocated after the OCNS padding. Parameter
LoadTargetForOCNSonPDSCH is used to configure Ntarget. It represents the
DL
target load for OCNS in % of N RB
DL
Ntarget = max(LoadTargetForOCNSonPDSCH x N RB , Nreg )
DL
Recall that N RB depends on the bandwidth and is derived as follows
DL channel DL transmission
dlBandwidth DL
bandwidth bandwidth in RBs ( N RB )
n6-1_4MHz 1.4 MHz 6
n15-3MHz 3 MHz 15
n25-5MHz 5 MHz 25
n50-10MHz 10 MHz 50
n75-15MHz 15 MHz 75
n100-20MHz 20 MHz 100
DL
If Nreg exceeds LoadTargetForOCNSonPDSCH x N RB , OCNS will not add any load.
If not, RBGs from the set t_RB are allocated to OCNS until the target (in terms of
total number of allocated RBs) is reached.
Page 174/472
LteCell::loadTargetForOCNSonPDSCH
Parameter loadTargetForOCNSonPDSCH
[0..100] %
Value 0 (Default)
Feature FRS 76494
4.5.4.2 PDCCH OCNS
PDCCH OCNS aims at providing a minimum load (expressed in terms of PDCCH

transmit power) on the PDCCH channel. It is activated when parameter
LteCell::LoadTargetForOCNSonPDCCH is set to a non-null value.
Let PTargetPDCCH be the minimum PDCCH transmit power to achieve. The PDCCH
OCNS algorithm follows the following steps:
If the PDCCH power generated by real downlink traffic PPDCCHrealDLtraffic is greater
than or equal to PTargetPDCCH , then PDCCH does not add any load to the downlink
traffic.
Else
If the number of PDCCH CCEs reserved for the uplink compensates (in
terms of transmit power) for the difference ( PTargetPDCCH − PPDCCHrealDLtraffic ) ,
then no extra load is added by the downlink scheduler. However, the uplink
scheduler makes sure that enough CCEs (reserved for the uplink) are used
for the UL PDCCH transmit power to compensate for the difference
( PTargetPDCCH − PPDCCHrealDLtraffic ) . For this purpose, if the number of CCEs
used by the real uplink traffic does not use a transmit power greater than or
equal to ( PTargetPDCCH − PPDCCHrealDLtraffic ) then the uplink scheduler adds
dummy traffic.
Else the uplink scheduler uses all the PDCCH CCEs reserved for the uplink
(dummy traffic is generated if necessary) and the downlink scheduler adds
dummy traffic so that the number of CCEs used by the downlink traffic
compensates (in terms of transmit power) for the difference
( PTargetPDCCH − PPDCCHrealDLtraffic − PULtraffic ) . If the maximum number of PDCCH
CCEs is reached, the transmit power per CCE is increased to the appropriate
value.
Page 175/472
LteCell::loadTargetForOCNSonPDCCH
Parameter loadTargetForOCNSonPDCCH
Range & Unit Float
[0..100] step = 0.1%
Value 0 (Default)
Feature FRS 96293
4.6 UPLINK SCHEDULER

The main role of the uplink scheduler is to efficiently manage and allocate the
available uplink resources to the UEs having contexts in the UL
RRCConnectedUserList.
The UL UE context contains:
• The UE C-RNTI.
• The UE TPC-RNTI and TPC-Index (see section 6.2)
• The UE category.
• The UE UL AMBR. The value is provided at connection setup but can also
be modified on the fly by CallP for an already connected UE (see “E-RAB
modify” section in [Vol. 5]).
• The UebearerList.
• The UE MG status. The latter consists of the following 3 parameters:
o MgActive: Flag indicating if MG is active for the UE.
o MgPeriod: MG Repetition Period, derived from parameter
measurementGapsPattern.
o MgOffset: MG Offset of the UE.
In the UEBearerList, a bearer context is identified by the Logical Channel Identifier

(LCID) of the logical channel it is mapped onto. The bearer context also contains,
among other information:
• The VoIP flag (derived by CallP from QoS received from the MME over the
S1-C).
• The UL GBR (derived by CallP from QoS received from the MME over the
S1-C).
Page 176/472
The uplink scheduler consists of several functional parts:

• The Static Scheduler, which assigns resources to RACH message 1 and
RACH message 3.
• The Semi-Persistent Scheduler, which assigns resources to DTCH VoIP
bearers established by UEs having indicated the support of semi-persistent
grants. Note that the support of SPS and that of TTI bundling at the UE are
indicated by FGI29 and FGI28, respectively.
• The Dynamic Scheduler, which assigns resources to DTCH (data bearers)

and DCCH (SRB1 and SRB2).
• The MIMO Scheduler is part of the Dynamic Scheduler and is responsible for
scheduling multiple UEs in the same time-frequency resources.
Note that the Semi-Persistent Scheduling of VoIP bearers is enabled/disabled by the

flag isSpsConfigAllowed (see section 4.5).
Note that in case 2 VoIP bearers are configured on the UE, both bearers are
managed by the same scheduler (i.e. both by the Semi-Persistent Scheduler or both
by the Dynamic Scheduler).
CCCH DCCH DTCH

Uplink
Logical channels
Uplink
Transport channels
RACH UL-SCH
Figure 13: Mapping between uplink logical channels and uplink transport channels
UL-SCH RACH
Uplink
Transport channels
Uplink
Physical channels
PUSCH PRACH PUCCH
Figure 14 : Mapping between uplink transport channels and uplink physical channels
Page 177/472
The PRBs are assigned every subframe in the following order:

1. Static grants.
2. Dynamic grants.
4.6.1 INTERFERENCE COORDINATION

The purpose of the interference coordination is to apply restriction on the usable time
or frequency resources. The primary concern for interference coordination is to limit
the amount of interference caused to neighbor cell users and thus enhance the
overall user data rate provided (by several cells) and improve coverage for cell edge
users. In synchronized network deployment, both time and frequency reuse can be
applied. However, in a non-synchronized network, only frequency reuse is
applicable.
There are 2 basic approaches to interference coordination:

• The static interference coordination is typically designed for worst case
interference scenario.
• The dynamic interference coordination adapts to the changes in traffic
loading (of each cell) and radio conditions
There are two static frequency reuse patterns:

• The (1,1) reuse pattern: In this pattern, there is no restriction on the
frequency resource usage.
• The (1,3) reuse pattern: In this pattern, the frequency resources are equally
split among the 3 neighboring cells in the same eNB. The (1,3) reuse pattern
is shown in Figure 17. Each cell is allowed 1/3 of the frequency band. The
frequency resource is equally split among the neighboring cells, irrespective
of the traffic loads on the different cells. With this pattern, the UEs at the cell
border experience high SINR conditions due to reduced interference.
However, the overall cell throughput can be reduced significantly due to
reduced transmission bandwidth.
Page 178/472
γ α
β β
Frequency resource
γ α γ α
β F1 F2 F3
γ α
β
0 1 2 3 4 5 6 7 8 9 10 11
γ α γ α
β
Cell α Cell β Cell γ
γ α
(a) (b)
Figure 15 : The (1,3) frequency reuse pattern (a) Frequency reuse over the cells (b)
Sub-band allocation pattern
There are two static frequency reuse schemes:

• The (1,1) reuse scheme uses exclusively the (1,1) reuse pattern.
• The (1,3) reuse scheme uses the (1,3) reuse pattern for PUSCH and the
(1,1) reuse pattern for PRACH and PUCCH .
4.6.1.1 FRACTIONAL FREQUENCY REUSE
In the fractional frequency reuse scheme, the frequency use for cell edge users is
restricted to ((1,3) frequency reuse) predefined frequency zones. Users at the interior
of the cell, on the other hand, are allowed to transmit at any frequency zone ((1,1)
frequency reuse).
Figure 18 illustrates the fractional frequency reuse concept. Frequency zone F1 is
designated as an interference bearing (frequency) zone for cell α. Users close to cell
α are restricted to use the PRBs in frequency zone F1. Similarly, frequency zones F2
and F3 are designated as interference bearing zones for cells β and γ .
Page 179/472
γ α
β β 5 MHz
F1 F2 F3
γ α γ α
β
0 1 2 3 4 5 6 7 8 9 10 11
γ α
β β
1.67 MHz 1.67 MHz 1.67 MHz
γ α γ α Sector α Sector β Sector γ
β
γ α
(a) (b)
Figure 16 : Fractional (1,3) frequency reuse scheme
4.6.1.2 SOFT FRACTIONAL FREQUENCY REUSE
In the Soft Fractional Frequency Reuse (SFFR) scheme, all users in the cell are
allowed to transmit using all frequency resources. Users can use full transmit power
at the interference bearing zone and a reduced transmit power in non-interference
bearing zone.
The interference bearing zone is also called ‘preferred zone’ in this document.
The scheduler prefers to allocate resources for cell-edge users in the preferred (or
interference-bearing) frequency zone. If a cell-edge user is allocated resources in the
non-preferred frequency zone, it is scheduled with reduced transmit PSD.
ICIC (Inter Cell Interference Coordination) is not yet supported in LR13.1. Therefore,
sections 4.6.1.1 and 4.6.1.2 are for information only.
4.6.1.3 PRB EXCLUSION IN PUSCH DYNAMIC SCHEDULING AND

WIDEBAND SRS/NOISE CALCULATIONS
In order to cope with UL noise coming from different possible sources such as in-
band interference from a TV channel transmission, particularly in country border
areas, a new functionality has been added to prevent some (interfered) PRBs from
being used by the UL dynamic scheduler. Up to 2 PRBs can be configured as
blocked. Besides, these PRBs will not be taken into account in the calculations of
wideband SRS or Noise.
Parameter eNB::spare4 has been reserved for this feature activation and PRB
exclusion specification.
The bit allocation for eNB::spare4 is as following:
Page 180/472
o Bits 0-1 specify the number of PRB zones that are blocked from being
scheduled by ULS for any PUSCH transmissions:
o 00: no blocking - the function is effectively disabled.
o 01: 1 PRB zone is blocked.
o 10: 2 separate PRB zones are blocked.

o 11: not used.
o Bits 2-15 define the first blocked PRB zone (if applicable):
o Bits 2-8 (7 bits to cover 20MHz) specify the start PRB of the first UL
PRB zone that is to be blocked. If the PRB zone is regarded as
invalid, the code will ignore it (first PRB zone = no PRB).
o Bits 9-15 specify the end PRB of the first UL PRB zone that is to be
blocked (it should therefore be higher than the start PRB). If the PRB
zone is regarded as invalid and code will ignores it (first PRB zone =
no PRB).
o Bits 16-29 define the second blocked PRB zone (if applicable):
o Bits 16-22 (7 bits to cover 20MHz) specify the start PRB of the first
UL PRB zone that is to be blocked. If the PRB zone is regarded as
invalid, the code will ignore it (first PRB zone = no PRB).
o Bits 23-29 specify the end PRB of the first UL PRB zone that is to be
blocked (it should therefore be higher than the start PRB). If the PRB
zone is regarded as invalid and code will ignores it (first PRB zone =
no PRB).
o Bit 30 determine whether the eNodeB forces RACH msg3 to be located in
PRB8. If this bit is set to 0, then the eNodeB uses the MIM parameter
rachMessage3StartingPRBIndex. If this bit is set to 1, then it enforces RACH
msg3 starting from PRB8.
o Bit 31 is not used.
4.6.2 RACH REGION AVOIDANCE

[Descoped from LR13. For future reference only]
The PUSCH interference over RACH region may cause RACH false detection hence
waste of ressources, which is even more damageable when RACH capacity
increases.
In LR13.3, FRS 166802 increases the RACH capacity, hence implements at the
same time a solution to mitigate the PUSCH interference over RACH region.
With this solution, the uplink scheduler avoids assigning PUSCH to RACH region as
long as there’re other PRBs available.
Page 181/472
puschSinrBackoffOnRachRegion specifies the SINR back-off in the scheduler

priority weight calculation as well as MCS determination if the PUSCH involves any
PRB on the RACH PRB region.
CellL2ULConf::puschSinrBackoffOnRachRegion
Parameter puschSinrBackoffOnRachRegion
[0.0..10.0] step 0.1 (dB)
Class/Source C / system_restricted
Value Default (3)
Feature FRS 166802
4.6.3 L1 MEASUREMENTS PROCESSING

The uplink scheduler uses L1 measurements information as input for the resource
allocation and packet scheduling.
Parameter energyMetricSelect configures the energy metric used in RX physical

layer processing in the CE (0 is for short term metric and 1 is for long term metric).
EnbRadioConf::energyMetricSelect
Parameter energyMetricSelect
[0..1]
Feature
Parameter noiseVarianceMetricSelect configures the noise variance metric used in

RX physical layer processing in the CE (0 is for short term metric and 1 is for long
term metric).
Page 182/472
EnbRadioConf::noiseVarianceMetricSelect
Parameter noiseVarianceMetricSelect
[0..1]
Feature
Parameter l1NoiseAveragingCoefficient configures the coefficient for the averaging

of the noise power in L1 (averaging coefficient =
l1NoiseAveragingCoefficient/16384).
L1MeasurementConf::L1NoiseAveragingCoefficient
Parameter L1NoiseAveragingCoefficient
Object ENBEquipment/Enb/L1MeasurementConf
[0..16384] step = 16
16224 The function associated with this parameter is
considered to be proprietary, and is thus not described here.
Value
The value of the parameter should only be modified by qualified
ALU personnel.
Feature
Parameter l1SpeedCFOandSignalPowerAveragingCoefficient configures the

coefficient for the averaging of the speed, CFO (Frequency Offset Correction) and
signal power in L1 (averagincoefficient =
l1SpeedCFOandSignalPowerAveragingCoefficient/16384).
Page 183/472
L1MeasurementConf::l1SpeedCFOandSignalPowerAveragingCoefficient
Parameter l1SpeedCFOandSignalPowerAveragingCoefficient
[0..16384] step = 16
Value
ALU personnel.
Feature
Parameter l1TimingAdvanceAveragingCoefficient configures the coefficient for

the averaging of the timing advance in L1 (averagincoefficient =
l1TimingAdvanceAveragingCoefficient /16384).
L1MeasurementConf::l1TimingAdvanceAveragingCoefficient
Parameter l1TimingAdvanceAveragingCoefficient
[0..16384] step = 16
Value
ALU personnel.
Feature
Parameter noisePowerAveragingCoefficientForULMIMO configures the coefficient

for the averaging of the noise power metric used for UL MIMO decisions in the UL
scheduler. More precisely, it configures Knoise_power_MIMO at cell setup (Knoise_power_MIMO =
noisePowerAveragingCoefficientForULMIMO /214).
Page 184/472
EnbRadioConf::noisePowerAveragingCoefficientForULMIMO
Parameter noisePowerAveragingCoefficientForULMIMO
[0..16384]
Value
personnel.
Feature
4.6.3.1 PROCESSING OF PUSCH REPORTS
Restriction: PUSCH power control and PUSCH SINR
In LR13.1, PUSCH power control is based on SRS measurements (see section

4.6.3.3) and not on PUSCH power reports. Therefore, PUSCH power reports are
not processed.
4.6.3.2 PROCESSING OF PUCCH REPORTS
CellRadioConf::pUCCHFormat1xDMRSpowerAveragingCoefficient
Parameter pUCCHFormat1xDMRSpowerAveragingCoefficient
[0..16384]
Value
personnel.
Feature FRS 84873
Page 185/472
CellRadioConf::pUCCHFormat2xDMRSpowerAveragingCoefficient
Parameter pUCCHFormat2xDMRSpowerAveragingCoefficient
[0..16384]
Value
personnel.
Feature FRS 84873
4.6.3.3 PROCESSING OF SOUNDING REFERENCE SIGNAL REPORTS
CellRadioConf::pathLossAveragingCoefficient
Parameter pathLossAveragingCoefficient
[0..16384]
Value
personnel.
Feature
4.6.3.3.1 UPDATE OF THE SINR METRIC USED FOR

UPLINK SYNC DETECTION
Page 186/472
CellRadioConf::sRSpowerForULSyncAveragingCoefficient
Parameter sRSpowerForULSyncAveragingCoefficient
[0..16384]
Value
personnel.
Feature
4.6.3.3.2 UPDATE OF THE SINR METRIC USED FOR

PUSCH POWER CONTROL
CellRadioConf::pUSCHsinrAveragingCoefForDSpowerCtrl
Parameter pUSCHsinrAveragingCoefForDSpowerCtrl
[0..16384]
Value
personnel.
Page 187/472
CellRadioConf::pUSCHsinrAveragingCoefForSPSpowerCtrl
Parameter pUSCHsinrAveragingCoefForSPSpowerCtrl
[0..16384]
Value
personnel.
Feature FRS 114531
[The two below parameters are descoped from LR13. For future reference only]
From LR13.3, the fast PUSCH power control mechanism is used to speed up the
convergence of the UE power control when the measured PUSCH SINR metric is
substantially higher than the value of the SINR target.
This mechanism is enabled with the parameter
isPUSCHSinrConvergenceSpeedUpEnabled. The threshold between the measured
SINR and the SINR target triggering the speed up of the convergence is configured
through puschSinrConvergenceSpeedUpThresh.
ULPowerControlConf::isPUSCHSinrConvergenceSpeedUpEnabled
Parameter isPUSCHSinrConvergenceSpeedUpEnabled
Object ENBEquipment/Enb/LteCell/ULPowerControlConf
False/True
Value Default False
Feature FRS 166802
ULPowerControlConf::puschSinrConvergenceSpeedUpThresh
Parameter puschSinrConvergenceSpeedUpThresh
[0..15] (dB)
Value Default 6
Feature FRS 166802
Page 188/472
4.6.4 UPLINK SYNCHRONIZATION MONITORING

The uplink scheduler needs to monitor the uplink synchronization status of each user
so that it doesn’t waste resources trying to provide the QoS to a call that has no
chance to achieve it due to loss of synchronization.
CellRadioConf::ulSyncSINRsyncToOOSThreshold
Parameter ulSyncSINRsyncToOOSThreshold
Range & Unit Float
[-20.0..10.0] step = 0.1 dB
-17.0 The function associated with this parameter is considered
Value
personnel.
Feature FRS 764343
CellRadioConf::ulSyncSINROOStoSyncThreshold
Parameter ulSyncSINROOStoSyncThreshold
Range & Unit Float
[-20..10] step = 0.1 dB
-16.0 The function associated with this parameter is considered
Value
personnel.
Feature FRS 76434
Page 189/472
Rule: Regarding parameters ulSyncSINRsyncToOOSThreshold and

ulSyncSINROOStoSyncThreshold
The setting of these parameters must verify the condition

ulSyncSINRsyncToOOSThreshold < ulSyncSINROOStoSyncThreshold
4.6.5 STATIC SCHEDULER

The uplink static scheduler assigns resources to RACH message 1 and RACH
message 3.
The RACH preamble (RACH message 1) is generated by the MAC layer on RACH
and transmitted on PRACH (see Figure 16). PRACH location is discussed in [Vol. 3].
RACH message 3 is scheduled as follows:
• RACH message 3 is transmitted 6 ms after RACH message 2.

• The starting PRB index for the transmission of RACH Message 3 is
configured by parameter rACHMessage3StartingPRBIndex.
• The number of PRBs used for the transmission of RACH Message 3 is

configured by parameter rACHMessage3NumberOfPRBs. (From LR13.3,
this parameter is only applicable to Contention-Based RACH)
• The index of the MCS used for the transmission of RACH Message 3 is
configured by parameter rACHMessage3MCSIndex.
• The number of PRBs indicated in the embedded RAR grant for a contention-
free preamble detected is configured by parameter
cfRACHMessage3NumberOfPRBs
Note that the static scheduler only reserves resources and allocates them to RACH
message 3 when a preamble is detected. Otherwise, the resources remain available
and are considered as free by the dynamic scheduler.
Page 190/472
CellRachConfFDD::rACHMessage3NumberOfPRBs
Parameter rACHMessage3NumberOfPRBs
[1..4]
Feature FRS 92038
Engineering Recommendation: Parameter rACHMessage3NumberOfPRBs

setting
The recommended setting for this parameter is as follows
ulbandwidth rACHMessage3MCSIndex
n6-1_4MHz 2
n15-3MHz 3
n25-5MHz 3
n50-10MHz 3
n75-15MHz 3
n100-20MHz 3
CellRachConf::rACHMessage3StartingPRBIndex
Parameter rACHMessage3StartingPRBIndex
[0..99]
Value 3
Feature FRS 76432
Page 191/472
Engineering Recommendation: Parameter rACHMessage3StartingPRBIndex

setting
If the system is operating in the 700 MHz upper C band (i.e. if
ul700MHzUpperCBlockEnabled is set to “True”) parameter
rACHMessage3StartingPRBIndex should be set to 37.
If the system is not operating in the 700 MHz upper C band (i.e. if
ul700MHzUpperCBlockEnabled is set to “False”), parameter
rACHMessage3StartingPRBIndex must be set so that RACH message 3
resources do not overlap with PUCCH resources, i.e.
rACHMessage3StartingPRBIndex must be set in the range
[pucchPRBsize/2… N UL
RB - pucchPRBsize/2 - rACHMessage3NumberOfPRBs]. The
current setting is:
rACHMessage3StartingPRBIndex =
N UL
RB - pucchPRBsize/2 - rACHMessage3NumberOfPRBs
ulbandwidth ul700MHzUpperCBlock pucchPRBsize rACHMessage3S

Enabled tartingPRBIndex
n6-1_4MHz False 2 3
n15-3MHz False 2 11
n25-5MHz False 4 20
n50-10MHz False 4 45
CellRachConf::rACHMessage3MCSIndex
Parameter rACHMessage3MCSIndex
[0..4]
Feature FRS 76432
Page 192/472
Engineering Recommendation: Parameter rACHMessage3MCSIndex setting

The recommended setting for this parameter is as follows
ulbandwidth rACHMessage3MCSIndex
n6-1_4MHz 4
n15-3MHz 3
n25-5MHz 3
n50-10MHz 3
n75-15MHz 3
n100-20MHz 3
CellRachConfFDD::cfRACHMessage3NumberOfPRBs
Parameter cfRACHMessage3NumberOfPRBs
[1..5]
Value Default 3
Feature FRS 166802
4.6.6 SEMI-PERSISTENT SCHEDULER

defaultCodecforVoIPServiceUl: This parameter controls the type of downlink
speech codec assumed for deriving the SPS or DS UL grant size when parameter
overrideS1GBRinfoForVoIP is set to ‘true’.
Page 193/472
EnbVoipConf::defaultCodecforVoIPServiceUl
Parameter defaultCodecforVoIPServiceUl
{ AMR-12.20, AMR-10.20, AMR-7.95, AMR-7.40, AMR-6.70, AMR-
5.90, AMR-5.15, AMR-4.75, AMR-WB-23.85, AMR-WB-23.05, AMR-
WB-19.85, AMR-WB-18.25, AMR-WB-15.85, AMR-WB-14.25, AMR-
WB-12.65, AMR-WB-8.85, AMR-WB-6.60 }
Feature L115647.1
Engineering Recommendation: Parameter defaultCodecforVoIPServiceUl
This parameter should be set to the value corresponding to the VoIP codec being
used in the UL for the VoIP test in question.
This parameter is defaulted to “AMR-WB-12.20”.
Parameter activeToInactiveSpeechThresholdUl controls the threshold used for

transitioning a UE from “Speech Active” to “Speech Inactive” state. Expressed in
number of consecutive non-speech frames.
EnbVoipConf::activeToInactiveSpeechThresholdUl
Parameter activeToInactiveSpeechThresholdUl
[1..16]
Value 3
Feature L114531.1
Rule: Parameter activeToInactiveSpeechThresholdUl
The setting of this parameter must satisfy the following rules:

• activeToInactiveSpeechThresholdUl is an integer multiple of
floor(speechActivityObservationWindow/20), AND
• activeToInactiveSpeechThresholdUl ≤ implicitReleaseAfter
Page 194/472
speechActivityObservationWindow: This parameter controls the size or the

observation window used to detect if a VoIP UE is in Speech Active or in Speech
Inactive state.
EnbVoipConf::speechActivityObservationWindow
Parameter speechActivityObservationWindow
{ms40, ms50, ms60, ms70, ms80, ms90, ms100}
Value ms60
Feature L115239
Parameter inactiveToActiveSpeechthresholdUl controls the threshold used for

determining whether the amount of observed UL VoIP data observed in 40ms should
trigger a transition from “Speech Inactive” to “Speech Active” state. Expressed in
bytes.
EnbVoipConf::inactiveToActiveSpeechthresholdUl
Parameter inactiveToActiveSpeechthresholdUl
[1..255] bytes
Value 38
Feature FRS 114531
Parameter inactiveToActiveBSRthresholdUl controls the Buffer Status Report (as

per TS 36.321) threshold value. If a BSR report associated to a VoIP report is
received with a value higher or equal to that threshold then the UE is transitioned
from “Speech Inactive” to “Speech Active” state, if not already in that state. Unit is
BSR unit.
Page 195/472
EnbVoipConf::inactiveToActiveSpeechBSRthresholdUl
Parameter inactiveToActiveSpeechBSRthresholdUl
[0..63]
Value 17 (corresponding to a Buffer Occupancy of 125 bytes)
Feature FRS 114531
EnbVoipConf::sIDframeDetectionThresholdUl
Parameter sIDframeDetectionThresholdUl
[0 .. 255] bytes
Value 38 The function associated with this parameter is
The value of the parameter should only be modified by
qualified ALU personnel.
Feature L114531
4.6.6.1 DETERMINATION OF UPLINK SPS GRANT MCS AND TBS
Parameter nominalMCSforSPSgrantsUl controls the nominal MCS value used for

UL SPS grants. The UL SPS scheduler may use a lower value of MCS if it costs the
same amount of PRBs as the nominal MCS.
CellL2ULConf::nominalMCSforSPSgrantsUl
Parameter nominalMCSforSPSgrantsUl
[0..15]
Value 10
Feature FRS 114531
tBScombinationMethodUl: This parameter selects the TBS to be used when 2 VoIP

calls are multiplexed. It is possible to select the sum or the max of the 2 TBS.
Page 196/472
EnbVoiPConf::tBScombinationMethodUl
Parameter tBScombinationMethodUl
Object ENBEquipment/Enb/EnbVoiPConf
{sum, max}
Value max
Feature FRS 114536.1, FRS 115807, FRS 115239(.1)
isOnePRBMCS6forUplinkSPSgrantsAllowed: This parameter controls

whether the uplink SPS scheduler is allowed to make the use of the {1PRB,MCS6}
grant format. As per TS36.311, this format allows the transmission of 328 transport
block size over 1 PRB with QPSK modulation. The HARQ process requires multiple
HARQ transmissions before being decodable.
CellL2ULConf::isOnePRBMCS6forUplinkSPSgrantsAllowed
Parameter isOnePRBMCS6forUplinkSPSgrantsAllowed
True/False
Value False
Feature FRS 115686
onePRBMCS6forUplinkSPSgrantsminTBsize: This parameter controls the

smallest transport block size allowed to use the {1PRB,MCS6} grant format with
uplink SPS grants. Used when isOnePRBMCS6forUplinkSPSgrantsAllowed is set
to “true”.
CellL2ULConf::onePRBMCS6forUplinkSPSgrantsminTBsize
Parameter onePRBMCS6forUplinkSPSgrantsminTBsize
[0..328] bits
Value 144
Feature FRS 115686
Page 197/472
4.6.6.2 UPLINK SPS ACTIVATION
The UL scheduler periodically checks if UEs which have a VoIP bearer established
and which are in “UL SPS inactive state” are eligible for UL SPS activation, and if so
adds them to the list of UEs considered for UL SPS activation.
Note that there can be no more than maxSPSgrantActivationQueueSizeUl UEs

candidate for UL SPS grant activation at a time. This is to save CPU processing load.
UplinkSemiPersistentSchedulingConf::maxSPSgrantActivationQueueSizeUl
Parameter maxSPSgrantActivationQueueSizeUl
Object
Conf/UplinkSemiPersistentSchedulingConf
[0..120]
20 ALU recommends the operator to not change change the
Value
setting of this parameter
Feature FRS 115239(.1), FRS 162790
Parameter maxSPSgrantTxCountUL controls the maximum number of UL SPS

Activation grants that can be sent to a UE without getting any confirmation of the
activation of this grant. When the limit is reached, the uplink scheduler initiates an
SPS release procedure.
UplinkSemiPersistentSchedulingConf::maxSPSgrantTxCountUL
Parameter maxSPSgrantTxCountUL
Object
[1..20]
Class/Source B--Cells-of-NE/ system_restricted
Value 5
Feature FRS 114531
Page 198/472
Parameter maxVoIPdataRateForSPSactivationUl specifies the maximum VoIP

uplink throughput threshold to allow the activation of uplink SPS grant.
UplinkSemiPersistentSchedulingConf::maxVoIPdataRateForSPSactivationUl
Parameter maxVoIPdataRateForSPSactivationUl
Object
Range & Unit Float
[0..128] step = 0.1 Kbits/s
Value 17.0
Feature FRS 115239(.1)
onePRBMCS6forUplinkSPSgrantsSINRthreshold : This parameter controls the

minimum PUSCH SINR level for using the {1PRB,MCS6} grant format with uplink
SPS grants. The threshold value is in fact the sum of this parameter and the value of
sPSactivationSINRmarginUl. It is used when
isOnePRBMCS6forUplinkSPSgrantsAllowed is set to “true”.
CellL2ULConf::onePRBMCS6forUplinkSPSgrantsSINRthreshold
Parameter onePRBMCS6forUplinkSPSgrantsSINRthreshold
Range & Unit Float
[0.0..30.0] step = 0.1 dB
Value 10.0
Feature FRS 115686
4.6.6.3 UPLINK SPS RELEASE
An explicit SPS grant release is achieved by sending an uplink grant to the SPS-
RNTI value assigned to the UE with some of the fields of the DCI set to special
values. This grant is further referred to as an SPS release command. If the explicit
release was triggered after an uplink SPS grant activation failure or upon detection of
a performance issue with an SPS grant, a timer specified by parameter
sPSactivationProhibitTimeUponSPSfailureUl is started to prevent a new SPS
activation procedure during this guard time.
Page 199/472
UplinkSemiPersistentSchedulingConf::sPSactivationProhibitTimeUponSPSfail
ureUl
Parameter sPSactivationProhibitTimeUponSPSfailureUl
Object ENBEquipment/Enb/DedicatedConf/SemiPersistentScheduli
ngConf/UplinkSemiPersistentSchedulingConf
Range & Unit Float
[0.0..15.0] step = 0.25 s
Value 5.0
Feature L114531
Implicit release of the UL SPS grant is autonomously triggered in the UE after the
latter has transmitted a number of successive empty SPS VoIP Blocks.
4.6.6.4 SPS GRANT ACTIVATION / SPS GRANT RELEASE

(RE)TRANSMISSION SCHEDULING
In a given TTI, SPS grant (activation/release) commands are processed according to

the following priority:
1. SPS activation grant retransmissions.
2. SPS activation grant first transmissions.
3. SPS “deactivation” grant transmissions, i.e. SPS release commands.
Parameter isDynamicManagementOfSPSresourceEnabled controls whether the

amount of PUSCH resource allowed for Uplink SPS traffic is adapted to the number
of VoIP users with an SPS configuration.
Page 200/472
CellL2ULConf::isDynamicManagementOfSPSresourceEnabled
Parameter isDynamicManagementOfSPSresourceEnabled
True/False
Value False
Feature FRS 115686
Parameter sPSprioMetricTableMaskStartPositionUl controls the start positions in

terms of PRB index of the PRB zone where uplink SPS grants are not allowed to be
mapped. The different index values are related to the different SPSprioMetricTable
MaskThresholdUL thresholds. This parameter is only used when
isDynamicManagementOfSPSresourceEnabled is set to “True”.
CellL2ULConf::sPSprioMetricTableMaskStartPositionUl
Parameter sPSprioMetricTableMaskStartPositionUl
Range & Unit List of 3 Integers
[0..99]
Feature FRS 115686
Parameter sPSprioMetricTableMaskStopPositionUl controls the stop positions in

terms of PRB index of the PRB zone where uplink SPS grants are not allowed to be
mapped. The different index values are related to the different SPSprioMetricTable
MaskThresholdUL thresholds. This parameter is only used when
isDynamicManagementOfSPSresourceEnabled is set to “TRUE”.
Page 201/472
CellL2ULConf::sPSprioMetricTableMaskStopPositionUl
Parameter sPSprioMetricTableMaskStopPositionUl
[0..99]
Feature FRS 115686
Parameter sPSprioMetricTableMaskThresholdUL controls the threshold in terms

of maximum number of VoIP users with an SPS configuration for using the
SPSprioMetricTableMaskStart/Stop mask with the same table index. This
parameter is only used when isDynamicManagementOfSPSresourceEnabled is
set to “TRUE”.
CellL2ULConf::sPSprioMetricTableMaskThresholdUL
Parameter sPSprioMetricTableMaskThresholdUL
[0..600]
Feature FRS 115686
Rule: Regarding parameter sPSprioMetricTableMaskThresholdUL
The provisioning of this parameter must satisfy

sPSprioMetricTableMaskThresholdUL[2] > sPSprioMetricTableMaskThresholdUL[1] >
sPSprioMetricTableMaskThresholdUL[0].
Page 202/472
Engineering Recommendation: Parameters sPSprioMetricTableMaskStartPositionUl ,

sPSprioMetricTableMaskStopPositionUl, and sPSprioMetricTableMaskThresholdUl
The current recommended settings for

CellL2ULConf::sPSprioMetricTableMaskStartPositionUl,
CellL2ULConf::sPSprioMetricTableMaskStopPositionUl, and
CellL2ULConf::sPSprioMetricTableMaskThresholdUl are as follows:
dlBandwidth sPSprioMetricTable sPSprioMetricTable sPSprioMetricTable

MaskStartPositionUl MaskStopPositionUl MaskThresholdUl
n25-5MHz (8, 10, 12) (18, 14, 12) (9, 27, 40)
n50-10MHz (8, 10, 14) (43, 39, 35) (9, 27, 52)
N75-15MHz (9, 11, 15) (67, 63, 59) (9, 27, 52)
n100-20MHz (9, 11, 15) (92, 88, 84) (9, 27, 52)
Furthermore, sPSprioMetricTableMaskStartPositionUl and

sPSprioMetricTableMaskStopPositionUl should be provisioned so that the size of the mask
decreases as the number of SPS VoIP users increases, i.e.
sPSprioMetricTableMaskStopPositionUl and sPSprioMetricTableMaskStartPositionUl
should satisfy sPSprioMetricTableMaskStopPositionUl[0] >
sPSprioMetricTableMaskStopPositionUl[1] >
sPSprioMetricTableMaskStopPositionUl[2] and
sPSprioMetricTableMaskStartPositionUl[0] <
sPSprioMetricTableMaskStartPositionUl[1] <
sPSprioMetricTableMaskStartPositionUl[2].
CellL2ULConf::sPSprioMetricTableMaskThresholdUL
Parameter sPSprioMetricTableMaskThresholdUL
[0..600]
Feature FRS 115686
Page 203/472
Rule: Regarding parameter sPSprioMetricTableMaskThresholdUL
The provisioning of this parameter must satisfy

sPSprioMetricTableMaskThresholdUL[2] > sPSprioMetricTableMaskThresholdUL[1] >
sPSprioMetricTableMaskThresholdUL[0].
4.6.7 DYNAMIC SCHEDULER

The dynamic scheduler is in charge of scheduling all the logical channels which have
non-stringent timing constraints and non-regular usage of the resource.
The downlink dynamic scheduler assigns resources to DTCH (data bearers including
VoIP bearers that cannot be managed semi-persistently) and DCCH (SRB1 and
SRB2).
The dynamic scheduler allocates the resources left by the static scheduler, the semi-
static scheduler and the semi-persistent scheduler.
Every subframe, the static scheduler provides the dynamic scheduler with the map of
available resources (under the form of a PRB bitmap).
The dynamic scheduler is also provided with the following information:

• HARQ ACK/NACK/discard feedback for UEs that have been previously
scheduled.
• Channel measurement reports from L1.

• Indication of resource request events.
• Indications of in sync / out of sync status for each UE.
• Buffer increase predictions from the downlink scheduler.

• Buffer Status Reports (see [Vol. 3]).
• Power Headroom Reports (see [Vol. 3]).
Page 204/472
The dynamic scheduling algorithm is the so-called Alpha Fairness scheduler, which
is a generalization, by means of parameter ulSchedPropFairAlphaFactor, of the
widely used Proportional Fair scheduler.
Parameter ulSchedPropFairAlphaFactor tunes the alpha fairness factor (thus the

behavior) of the scheduler:
• ulSchedPropFairAlphaFactor = 1 yields a maximum C/I scheduler. The
scheduler provides more resources to UEs in better conditions. The better
the radio conditions of the UE, the more resources (and hence the higher the
data rate) it gets.
• ulSchedPropFairAlphaFactor = 0.5 yields a fair scheduler. The scheduler
attempts to provide the same number of RBs to all the UEs (despite their
different conditions).
• ulSchedPropFairAlphaFactor = 0 yields an increased fairness scheduler.
The rate difference due to different RF conditions is much attenuated as
compared to the fair scheduler (recall that different radio conditions result in
different data rates even when the number of resources is the same), hence
the increased fairness of the scheduler, as compared to the “regular” fair
scheduler.
This parameter provides flexibility as to the choice of scheduler behavior, allowing

the operator to choose the scheduler behavior they want for their network.
CellL2ULConf::ulSchedPropFairAlphaFactor
Parameter ulSchedPropFairAlphaFactor
Range & Unit Float
[0.0..1.0] step = 0.5
Value O.D. (ALU default: 0.5)
Feature
Note that the scheduler first manages the resource to accommodate any pending
HARQ retransmission, and then schedules 1st HARQ transmissions if there is any
resource left available. Only 1st HARQ transmission goes through the whole dynamic
scheduling algorithm detailed further in this section dedicated to UL dynamic
scheduler.
As the fairness parameter, ulSchedPropFairAlphaFactor, is only used in the
calculation of the QoS priority weight, which is computed only for 1st HARQ
transmission, it means that fairness can only be assessed based on the first
transmission.
Page 205/472
The following three examples may help understand better this fairness concept with
ulSchedPropFairAlphaFactor = 0.5:
1. Two UEs are in the cell, UE1 in Near Cell with an UL BLER of 0% and UE2
in Cell Edge with an UL BLER of 10% (typically with different UL SIR
targets): the average number of UL RBs over time allocated to UE2 may end
up being higher due to the HARQ retransmissions (especially if there is no
other limitation, such as UE Transmit power).
2. Two UEs are in the cell, UE1 in Near Cell and UE2 in Cell Edge which can
be granted only at the most a few UL RBs every TTI due to its limited
transmit power (especially if UL SIR target is still high at Cell Edge):
proportional fair will lead to UE2 being scheduled more often. However, if
both UEs can each be scheduled close to 100% of the time, then UE1 may
end up with a much higher average number of allocated UL RBs over time
(as it can be granted more UL RBs every TTI).
3. Six UEs are in the cell, two UEs in Near Cell and four UEs in Cell Edge
which can be granted only at the most a few UL RBs every TTI due to their
limited transmit power (especially if UL SIR target is still high at Cell Edge):
proportional fair will lead to UEs at Cell Edge to be scheduled more often
than UEs in Near Cell. However, as in some TTIs (may also happen with CFI
= 3), only a maximum of four UEs can be scheduled at the same time, this
means that the average number of allocated UL RBs over time for UEs in
Near Cell may be as low as for UEs in Cell Edge, and meaning a low total
average UL PRB allocation over all six UEs.
The uplink dynamic scheduling algorithm follows the following steps:
• Buffer estimation.
• QoS priority weight calculation.
• Channel estimates update.
• Spectrum efficiency correction.

• Scheduling stage (scheduling of dynamic HARQ retransmissions and
scheduling of 1st HARQ transmissions).
Parameter doNotForceVoIPusersToLowerBler controls whether the uplink

dynamic scheduler allows the use of higher BLER target for calls with a VoIP bearer
(for example when the user is managed by the frequency diverse scheduler).
Page 206/472
CellL2ULConf::doNotForceVoIPusersToLowerBler
Parameter doNotForceVoIPusersToLowerBler
True/False
Value False
Feature 115233(.1)
Parameter uEFailureReportRepetitionTimer determines how often the ULS will

repeat the UE Failure indication to the higher layers after the UE goes into the
UE_Failure state.
This is to cover cases such as the UE Failure indication being ignored by the higher
layers (for example, when HO preparation is in progress for the UE).
CellRadioConf::uEFailureReportRepetitionTimer
Parameter uEFailureReportRepetitionTimer
[0..10]
Value 5 ALU recommends the operator to not change this value
Feature 115233(.1)
4.6.7.1 TTI BUNDLING FOR VOIP
TTI Bundling for VoIP is introduced in LA5.0 by Feature 114536.1 and is enabled by
parameter isTTIBundlingForVoIPEnabled. In LA5.0, it is only committed for demo
and only supported on eCEM. In LR13.1, TTI Bundling is still only supported for VoIP
calls, with Feature L115807 only intended for bCEM this time.
TTI Bundling consists in systematically transmitting 4 PUSCH transmissions (which

is indeed regarded as 4 HARQ transmissions) in 4 consecutive TTIs following each
UL grant.
The eNB sends one ACK/NACK on PHICH channel at the end of this group of 4
HARQ transmissions. And depending on that HARQ feedback and on the max
number of HARQ transmissions configured, UE may initiate a HARQ retransmission
16ms after the beginning of the previous HARQ transmission. This means that up to
4 HARQ processes can be supported per UE instead of 8 HARQ processes for
Page 207/472
normal PUSCH transmission. Without TTI Bundling, 4 HARQ transmissions would

take 25ms, which is not acceptable for delay sensitive services such as VoIP.
UL
grant
N-4 N-3 N-2 N-1 N N+1 N+2 N+3 N+4 N+5 N+6 N+7 N+8 N+9 N+10 N+11 N+12 N+13 N+14 N+15 N+16 N+17 N+18 N+19 N+20 N+21 N+22 N+23 N+24 N+25 N+26 N+27 N+28 N+29 N+30 N+31 N+32 N+33 N+34 N+35
DL
NACK NACK
UL N-4 N-3 N-2 N-1 N N+1 N+2 N+3 N+4 N+5 N+6 N+7 N+8 N+9 N+10 N+11 N+12 N+13 N+14 N+15 N+16 N+17 N+18 N+19 N+20 N+21 N+22 N+23 N+24 N+25 N+26 N+27 N+28 N+29 N+30 N+31 N+32 N+33 N+34 N+35
RV0 RV2 RV3 RV1 RV0 RV2 RV3 RV1 RV0 RV2 RV3 RV1
4 ms
TTI Bundling transmission pattern for maxHARQtxTTIbundling = n12
ActivationService::isTTIBundlingForVoIPEnabled
Parameter isTTIBundlingForVoIPEnabled
True/False
Class/Source C--New-set-ups / customer_settable
Value O.D. (ALU default: False)
Feature FRS 114536.1, FRS 115807
Parameter maxHARQtxTTIbundling specifies the maximum number of UL bundled

HARQ transmissions for TTI-B users.
TTIBundlingConf::maxHARQtxTTIbundling
Parameter maxHARQtxTTIbundling
Object ENBEquipment/Enb/LteCell/CellL2ULConf/TTIBundlingConf
{ n4, n8, n12, n16}
Value n12
TTI Bundling activation/deactivation are performed in three steps:

o UE eligibility for TTI Bundling: this is evaluated at context creation (i.e. call
setup, HO, call re-establishment) and updated during normal call operation
(bearer creation or deletion or maybe bearer modification). The eNB
periodically monitors every 100ms the eligible UEs for TTI Bundling
activation/deactivation.
Page 208/472
o TTI Bundling feature is enabled: isTTIbundlingForVoIPAllowed =

true
o UE is TTI Bundling Capable:
 For a Release 8 UE: Feature Group Indicator bit#3 must be
set to ‘1’
 For a Release 9 or 10 UE: Feature Group Indicator bit#28
must be set to ‘1’
o UE does not have non-VoIP GBR bearer

o UE has at least one VoIP bearer
o Triggering of TTI Bundling activation/deactivation: when all criteria have
been met for a possible activation (resp. deactivation) of TTI Bundling on a
UE, Modem notifies to Callp of TTI Bundling alarm activation (resp.
clearance).
o TTI Bundling activation/deactivation: procedure to active/deactivate TTI

bundling is an intra cell HO using a RRC reconfiguration procedure.
TTI Bundling activation is triggered if all the following conditions are met:
o TTI Bundling is only activated in poor UL RF conditions:
o Achievable UL SINR for 1PRB Tx <
uplinkLinkBudgetAlarmTriggerThreshold, during a period of
uplinkLinkBudgetAlarmTimeToTrigger
o UL VoIP BLER:
o Measured UL VoIP BLER > ttiBundlingActivationBLERthresh
o UL VoIP rate (computed based on RoHC config and GBR of VoIP bearer(s)):
o UL VoIP call rate < maxULVoIPdataRateForTTIBundling (Note
that max PUSCH grant size with TTI bundling configuration is 3
PRB)
o Number of TTI Bundling users:
o Number of already existing TTI-Bundling users <
maxNbrOfTTIbundlingUsers (This is an extra protection
mechanism on top of TTI Bundling PRB Usage protection
mechanism)
o Non - Best Effort PRB usage:
o PRB usage for all non-BE bearers over all users <
ttiBundlingActivationLoadThresh (in PRB usage overload
conditions, no additional TTI Bundling calls are allowed)
o TTI Bundling PRB usage:
o TTI-B PRB usage < Max Nb of TTI-B PRB (configured in
ttiBundlingPRBpriorityOrder)
Page 209/472
uplinkLinkBudgetAlarmTriggerThreshold: This parameter controls the threshold

(expressed in terms of achievable PUSCH SINR at the eNB on a 1PRB
transmission) used to trigger a call reconfiguration from non-TTI bundling to TTI
Bundling mode.
TTIBundlingConf::uplinkLinkBudgetAlarmTriggerThreshold
Parameter uplinkLinkBudgetAlarmTriggerThreshold
Range & Unit Float
[-20.0..30.0] step = 0.5 dB
Value 0.0
uplinkLinkBudgetAlarmTimeToTrigger: This parameter controls the amount of

time a non-TTI bundling call must verify the condition:
uplinkLinkBudgetMetric(user) < uplinkLinkBudgetAlarmTriggerThreshold before
triggering a call reconfiguration to TTI Bundling mode.
TTIBundlingConf::uplinkLinkBudgetAlarmTimeToTrigger
Parameter uplinkLinkBudgetAlarmTimeToTrigger
Range & Unit Float
[0.0..10.0] step = 0.1 s
Value 2.0
ttiBundlingActivationBLERthresh: This parameter controls the BLER threshold

used for triggering the activation of the TTI Bundling configuration.
Page 210/472
TTIBundlingConf::ttiBundlingActivationBLERthresh
Parameter ttiBundlingActivationBLERthresh
[0..100] %
Value 2
ttiBundlingBLERmeasurementPoints: This parameter table controls the number of

HARQ Tx after which the BLER metric is measured when evaluating the conditions
for triggering TTI Bundling. The 8 elements of the table corresponds to:
o 1st element: controls the BLER measurement point associated to the

ttiBundlingActivationBLERthresh threshold when optimized segmentation is
enforced.
o 2nd element: controls the BLER measurement point associated to the
ttiBundlingActivationBLERthresh threshold when optimized segmentation is not
enforced.
o 3rd element: controls the BLER measurement point associated to the
ttiBundlingDeactivationBLERthresh threshold when optimized segmentation is
enforced.
o 4th element: controls the BLER measurement point associated to the
ttiBundlingDeactivationBLERthresh threshold when optimized segmentation is
not enforced.
ttiBundlingSegmentationThresh threshold.
ttiBundlingNoSegmentationThresh threshold.
ttiBundlingSPSactivationBLERthresh threshold.
ttiBundlingSPSDeactivationBLERthresh threshold.
Page 211/472
TTIBundlingConf::ttiBundlingBLERmeasurementPoints
Parameter ttiBundlingBLERmeasurementPoints
[0..12]
Value 4, 4, 4, 4, 12, 10, 1, 1
Feature FRS 115807
ttiBundlingBLERwindowSize: This parameter controls the size of the averaging

window (in terms of new HARQ transmissions) used to compute the BLER metrics
used by the TTI Bundling functionality.
TTIBundlingConf::ttiBundlingBLERwindowSize
Parameter ttiBundlingBLERwindowSize
[0..256]
Value 10
Feature FRS 115807
maxULVoIPdataRateForTTIBundling: This parameter controls the threshold in

terms of uplink data rate associated to the VoIP service to decide whether a VoIP call
can be considered candidate for TTI Bundling configuration or not. When 2 VoIP
bearers are configured, the sum or the max of the rates is compared against the
threshold (depending on the value of the tBScombinationMethodUl parameter).
Note that the uplink VoIP data rate is calculated by modem, taking into account the
RoHC activation status and S1-AP GBR info for the VoIP bearer(s).
Page 212/472
TTIBundlingConf::maxULVoIPdataRateForTTIBundling
Parameter maxULVoIPdataRateForTTIBundling
[1..65536] bits/s
Value 40000
tBScombinationMethodUl: This parameter selects the uplinkVoIP TBS computation

method to be used when 2 VoIP calls are multiplexed. It is possible to select the sum
or the max of the 2 TBS (see 4.6.6.1 for parameter box description).
maxNbrOfTTIbundlingUsers: This parameter controls the maximum number of

users with a TTI bundling configuration that can be supported in the cell.
TTIBundlingConf::maxNbrOfTTIbundlingUsers
Parameter maxNbrOfTTIbundlingUsers
[1..200]
Value 20
ttiBundlingActivationLoadThresh: This parameter controls the maximum load in

terms of non Best Effort PUSCH PRB utilization for allowing the activation of
additional TTI Bundling configurations. Index 0, 1 and 2 of the table corresponds to
calls requiring SPS grants of size 1, 2 and 3 PRB respectively.
Page 213/472
TTIBundlingConf::ttiBundlingActivationLoadThresh
Parameter ttiBundlingActivationLoadThresh
[1..100] %
Value 80, 70, 70
If isPRBMeasurementForTTIBundlingAllowed = true, the non Best Effort PUSCH

PRB utilization is based on modem measurement. Else, the GBR PRB usage used
by TTI Bundling PRB zone is estimated as gBRUlPrbConsumptionPerKbps PRB
per kbps.
TTIBundlingConf::gBRUlPrbConsumptionPerKbps
Parameter gBRUlPrbConsumptionPerKbps
Range & Unit Float
[0.0..100.0]
Value 2.0
Feature FRS 115807
TTIBundlingConf::isPRBMeasurementForTTIBundlingAllowed
Parameter isPRBMeasurementForTTIBundlingAllowed
True/False
Value false
Feature FRS 115807
ttiBundlingPRBpriorityOrder: This table defines the index of the PUSCH PRBs to

be used for TTI Bundling traffic and their priority in terms of activation order. See
below for more details on the format of this definition.
Page 214/472
TTIBundlingConf::ttiBundlingPRBpriorityOrder
Parameter ttiBundlingPRBpriorityOrder
Range & Unit List of 4 groups of 3 Integers
[0..255]
9,12,0,0,0,0,0,0,0,0,0,0 for 5 and 10MHz
Value
10,12,0,0,0,0,0,0,0,0,0,0 for 15 and 20MHz
Restriction: TTI Bundling and OP PUCCH

When Narrow Band SRS (OP PUCCH) is activated, the PRB zone allocations for
TTI Bundling shall ensure that there is no overlap with either PUCCH PRBs or
RACH PRBs.
A possible configuration, allowing a minimum of 8 UEs if

prbGrantSizeForTTIBundling = 2, would be (10MHz bandwidth):
16,4,2,0,0,0,0,0,0,0,0,0
PRB zone allocations for TTI Bundling calls are configured with parameter
ttiBundlingPRBpriorityOrder.
o Up to 4 zones can be configured, each with specification on {Start PRB,
Zone Size, Allocation Order}: this allows reserving from 1 up to 8 PRB blocks
for TTI Bundling.
o 4 possible allocation orders are defined:
o 0: from small to large PRB number
o 1: opposite of (0)
o 2: from small to large PRB number and with mirroring
o 3 opposite of (2)
o A Zone Size of 0, such as in {0, 0, 0}, means no reservation
In the below example, ttiBundlingPRBpriorityOrder = {{17, 4, 0}, {72, 12, 3}, {0, 0,
0}, {0, 0, 0}}, leading to a maximum of 28 PRBs that can be used for TTI-bundling:
Page 215/472
TTI Bundling deactivation is triggered if both following criteria are met:

o Good UL RF conditions:
o Achievable UL SINR for 1PRB Tx >

uplinkLinkBudgetAlarmClearanceThreshold during a period of
uplinkLinkBudgetAlarmTimeToClear
o UL VoIP BLER:
o Measured UL VoIP BLER < ttiBundlingDeactivationBLERthresh
TTI Bundling deactivation is also triggered as soon as following criteria is met:

o UL VoIP rate (computed based on RoHC config and GBR of VoIP bearer(s)):
o UL VoIP call rate > maxULVoIPdataRateForTTIBundling (Note
that this case may happen if the VoIP application ever decides to
use a higher UL VoIP rate; but the eNB scheduler will never promote
a TTI-B user to a higher UL VoIP rate)
uplinkLinkBudgetAlarmClearanceThreshold: This parameter controls the

threshold (expressed in terms of achievable PUSCH SINR at the eNB on a 1PRB
transmission) used to trigger a call reconfiguration from TTI bundling to non-TTI
Bundling mode.
TTIBundlingConf::uplinkLinkBudgetAlarmClearanceThreshold
Parameter uplinkLinkBudgetAlarmClearanceThreshold
Range & Unit Float
[-20.0..30.0] step = 0.5 dB
Value 10.0
uplinkLinkBudgetAlarmTimeToClear: This parameter controls the amount of time

a TTI bundling call must verify the condition: uplinkLinkBudgetMetric(user) >
uplinkLinkBudgetAlarmClearanceThreshold before triggering a call
reconfiguration to non-TTI Bundling mode.
Page 216/472
TTIBundlingConf::uplinkLinkBudgetAlarmTimeToClear
Parameter uplinkLinkBudgetAlarmTimeToClear
Range & Unit Float
[0.0..10.0] step = 0.1 s
Value 2.0
ttiBundlingDeactivationBLERthresh: This parameter controls the BLER threshold

used for triggering the deactivation of the TTI Bundling configuration.
TTIBundlingConf::ttiBundlingDeactivationBLERthresh
Parameter ttiBundlingDeactivationBLERthresh
[0..100] %
Value 0
TTI Bundling configuration follows the following rules:

o 1st VoIP bearer is always setup in normal mode and the call can only be
reconfigured to TTI bundling on later trigger. Any additional VoIP bearer is
setup in the current mode (only after a 2nd VoIP is added to a call in TTI
bundling mode, a reconfiguration to normal mode may occur, e.g. if data rate
is no longer compatible with TTI bundling).
o Upon incoming (inter cell) handover of VoIP, the call is always setup in
normal mode on the target cell, and can only be reconfigured to TTI bundling
on later trigger.
o Upon RRC re-establishment, to same cell or other cell, the call is always re-
established in normal mode and can only be reconfigured to TTI bundling on
later trigger.
o Upon intra cell handover with trigger other than TTI bundling, the call is left in
same mode.
Page 217/472
The TTI bundling feature also uses the following parameters:
ttiBundlingPRBdropThresh: This parameter controls the maximum number of

unused PRBs that is allowed to be left reserved for TTI Bundling traffic before
triggering a decrease of the size of the PRB zone upon expiration of the
ttiBundlingPRBdropTimer timer.
It is recommended to use a parameter value of 0 in a mature network when PRB
resources are scarce; in a young network, it is possible to use a higher value in order
to keep a minimum number of PRBs always reserved for TTI Bundling users.
If all reserved PRBs are fully utilized and more calls need to activate TTI bundling
operation, some PRBs are added into the reservation pool up to the maximum size
allowed by ttiBundlingPRBpriorityOrder.
TTIBundlingConf::ttiBundlingPRBdropThresh
Parameter ttiBundlingPRBdropThresh
[0..10]
Value 0
ttiBundlingPRBdropTimer: This parameter controls the amount of time the number

of unused TTI Bundling PRBs is at least equal to ttiBundlingPRBdropThreshold
before triggering a decrease of the size of the PRB zone dedicated to TTI Bundling
traffic.
TTIBundlingConf::ttiBundlingPRBdropTimer
Parameter ttiBundlingPRBdropTimer
[0..5000] step = 100 ms
Value 0
Page 218/472
prbGrantSizeForTTIBundling: This parameter controls the size in terms of number

of PRB of the PUSCH grants assigned to TTI Bundling users in the cell. The size is
restricted to the range [1..3] PRBs as per 3GPP specification.
TTIBundlingConf::prbGrantSizeForTTIBundling
Parameter prbGrantSizeForTTIBundling
[1..3]
Value 2
Minimum and maximum MCS values supported for TTI Bundling users are
configurable for each possible PRB grant size. In addition, these minimum and
maximum values are controlled separately for dynamic and SPS grant formats.
ttiBundlingMinMCSforDS: This table controls the minimum MCS value that is

allowed to be used for uplink dynamic grants when a UE is configured with TTI
Bundling. Index 0, 1 and 2 of the table corresponds to grants of size 1, 2 and 3
respectively.
TTIBundlingConf::ttiBundlingMinMCSforDS
Parameter ttiBundlingMinMCSforDS
[0..22]
Value 0, 0, 0
ttiBundlingMaxMCSforDS: This table controls the maximum MCS value that is

allowed to be used for uplink dynamic grants when a UE is configured with TTI
Bundling. Index 0, 1 and 2 of the table corresponds to grants of size 1, 2 and 3
respectively.
Page 219/472
TTIBundlingConf::ttiBundlingMaxMCSforDS
Parameter ttiBundlingMaxMCSforDS
[0..22]
Value 20, 20, 15
ttiBundlingMinMCSforSPS: This table controls the minimum MCS value that is

allowed to be used for uplink semi-persistent grants when a UE is configured with
TTI Bundling. Index 0, 1 and 2 of the table corresponds to grants of size 1, 2 and 3
respectively.
TTIBundlingConf::ttiBundlingMinMCSforSPS
Parameter ttiBundlingMinMCSforSPS
[0..22]
Value 0, 0, 0
ttiBundlingMaxMCSforSPS: This table controls the maximum MCS value that is

allowed to be used for uplink semi-persistent grants when a UE is configured with
TTI Bundling. Index 0, 1 and 2 of the table corresponds to grants of size 1, 2 and 3
PRB respectively.
TTIBundlingConf::ttiBundlingMaxMCSforSPS
Parameter ttiBundlingMaxMCSforSPS
[0..22]
Value 20, 20, 15
Page 220/472
The number of TTI Bundling users which can be scheduled per TTI may be restricted
by parameter maxNbrOfPreselectedTTIBundlingUsers.
maxNbrOfPreselectedTTIBundlingUsers: This parameter controls the maximum

number of TTI Bundling users that can be pre-selected for uplink dynamic scheduling
in any given TTI.
TTIBundlingConf::maxNbrOfPreselectedTTIBundlingUsers
Parameter maxNbrOfPreselectedTTIBundlingUsers
[0..31]
Value 2
In order to avoid TTI Bundling VoIP packet delay issues in loaded scenarios, the
uplink dynamic scheduler supports a mechanism enforcing a minimum priority level
for VoIP traffic over TTI Bundling and based on a minimum SINR level used for the
uplink SE (Spectrum Efficiency) metric associated to TTI Bundling users:
minimumSINRForTTIBundlingSEComputation.
As a matter of fact, in the scheduler, the UEs having the highest priority will have the
highest chance to be scheduled; this priority is based on uplink SE which
computation involves UE’s measured uplink SINR. By setting the SINR of TTI
Bundling users to a minimum value when their measured SINR is actually below that
minimum value, we favor these TTI Bundling users when their radio conditions are
starting to get so bad that it might impact too negatively the VoIP delay constraint.
minimumSINRForTTIBundlingSEComputation: This parameter controls the

minimum SINR level used for the uplink SE metric associated to TTI Bundling users.
This minimum floor is introduced to have a better control on the fairness between TTI
Bundling and non-TTI Bundling traffic.
Page 221/472
TTIBundlingConf::minimumSINRForTTIBundlingSEComputation
Parameter minimumSINRForTTIBundlingSEComputation
Range & Unit Float
[-15.0..20.0] step = 0.1 dB
Value 7.0
In order to provide the best trade-off between residual BLER and VoIP packets delay
when TTI Bundling is configured, two thresholds are introduced in order to control if
segmentation of the UL VoIP frames is allowed (see also L160815 - Optimized
segmentation).
ttiBundlingSegmentationBLERthresh: This parameter controls the BLER threshold
measured over dynamic TTI Bundling grants. The threshold is used to allow speech
payload segmentation for dynamic grants. A value of 0 means that segmentation is
disabled.
Note that segmentation is only available when maxHARQtx = 8 or lower.
TTIBundlingConf::ttiBundlingSegmentationBLERthresh
Parameter ttiBundlingSegmentationBLERthresh
[0..100]
Value 100
ttiBundlingNoSegmentationBLERthresh: This parameter controls the minimum

SINR level used for the uplink SE metric associated to TTI Bundling users. This
minimum floor is introduced to have a better control on the fairness between TTI
Bundling and non-TTI Bundling traffic.
Page 222/472
TTIBundlingConf::ttiBundlingNoSegmentationBLERthresh
Parameter ttiBundlingNoSegmentationBLERthresh
[0..100]
Value 1
minHARQtxWithoutMGcollisionForTTIbundling: This parameter controls the min

number of PUSCH transmission and retransmission bundles (for FDD) in TTI
bundling that are guaranteed not to collide with a Measurement Gap.
CellRadioConf::minHARQtxWithoutMGcollisionForTTIbundling
Parameter minHARQtxWithoutMGcollisionForTTIbundling
[1..16]
Value 12
TTI Bundling activation is carried out using an intra-cell handover and can therefore
involve a contention based or contention free RACH procedure.
Parameter isContentionFreeRACHForTTIBundlingAllowed controls whether
contention free RACH is allowed for configuring a UE with a TTI Bundling
configuration. When the parameter is set to false, a contention based RACH
procedure is used instead. The difference between the two cases is that in the case
of contention free RACH, the RACH msg3 uses a TTI Bundling timing whereas a
non-TTI Bundling timing is used for RACH msg3 in the case of contention based
RACH.
Page 223/472
TTIBundlingConf::isContentionFreeRACHForTTIBundlingAllowed
Parameter isContentionFreeRACHForTTIBundlingAllowed
True/False
Value false
Feature FRS 115807
Restriction: isContentionFreeRACHForTTI BundlingAllow ed
In LR13.1, contention free RACH is not supported when TTI bundling is configured.
Parameter isContentionFreeRACHForTTIBundlingAllowed shall therefore be
left to ‘false’.
isPUSCHType2HoppingOverTTIBundlingEnabled: This parameter enables or

disables the use of inter-subframe Type2 PUSCH Hopping for users configured with
TTI Bundling. It is in restriction in LR13.1.
TTIBundlingConf::isPUSCHType2HoppingOverTTIBundlingEnabled
Parameter isPUSCHType2HoppingOverTTIBundlingEnabled
True/False
Value false
Feature FRS 115807
Restriction: isP USCHType2HoppingOverTTI BundlingEnabled
In LR13.1, Type2 PUSCH hopping is not supported when TTI bundling is

configured. Parameter isPUSCHType2HoppingOverTTIBundlingEnabled shall
therefore be left to ‘false’.
Page 224/472
isSPSoverTTIBundlingEnabled: This parameter controls the activation of uplink

semi-persistent scheduling for TTI Bundling.
TTIBundlingConf::isSPSoverTTIBundlingEnabled
Parameter isSPSoverTTIBundlingEnabled
True/False
Value false
Feature FRS 115807
Restriction: isSPSoverTTI BundlingEnabled
In LR13.1, UL SPS is not supported when TTI bundling is configured. Parameter

isSPSoverTTIBundlingEnabled shall therefore be left to ‘false’. If this parameter
is set to ‘false’, downlink semi-persistent scheduling grant may still be used with
TTI Bundling users.
As a consequence of the above restriction, ttiBundlingSPSactivationBLERthresh

and ttiBundlingSPSDeactivationBLERthresh, which control the BLER thresholds
used to trigger respectively the activation and release of uplink SPS grant for UEs
configured with TTI Bundling, are not used either.
TTIBundlingConf::ttiBundlingSPSactivationBLERthresh
Parameter ttiBundlingSPSactivationBLERthresh
[0..100]
Value 0
Feature FRS 115807
Page 225/472
TTIBundlingConf::ttiBundlingSPSDeactivationBLERthresh
Parameter ttiBundlingSPSDeactivationBLERthresh
[0..100]
Value 2
Feature FRS 115807
tTIbundlingNotificationRepetitionTimer : This parameter specifies the period of

time for which the state machine waits before repeating the notification to RRC
function when there is a change required in the state of TTIbundling. The special
value ‘0’ implies that only a single notification is sent.
TTIBundlingConf::tTIbundlingNotificationRepetitionTimer
Parameter tTIbundlingNotificationRepetitionTimer
Range & Unit Float
[0.0..10.0] step = 0.5 s
Value 1
Feature FRS 115807
PerformanceManagement::tTIBundlingReported: This parameter specifies whether,

or not, the group of PM counters related to TTI Bundling is selected to be reported
(see [Vol. 2] for more info).
Parameter betaOffsetACKIndexForTTIbundling controls the gain adjustment when

ACK/NACK feedbacks are multiplexed on PUSCH for a UE configured with TTI
Bundling.
Page 226/472
CellL1ULConf::betaOffsetACKIndexForTTIbundling
Parameter betaOffsetACKIndexForTTIbundling
[0..14]
Value 12
Feature FRS 115807
extraDCI0powerOffsetForTTIBundling: This parameter specifies the additional

power offset applied to the DCI0 grants that are sent to UEs configured with TTI
Bundling.
CellL1L2ControlChannelsConf::extraDCI0powerOffsetForTTIBundling
Parameter extraDCI0powerOffsetForTTIBundling
[0.00..3.00]
Value 0.00
Feature FRS 115807
4.6.7.2 UPLINK DYNAMIC SCHEDULER OPERATION MODE

DETERMINATION
In LA6.0, the UL dynamic scheduler can work in 2 operational modes:

• Frequency Diverse Scheduling Only (when ulSchedulerMode is set to
“FrequencyDiverseOnly”): In this mode, the scheduler operates in the
Frequency Diverse Scheduling mode (FDS), exclusively.
• Frequency Selective Scheduling Capable (when ulSchedulerMode is set to
“FrequencySelectiveAllowed”): In this mode, the scheduler can switch from
Frequency Diverse Scheduling (FSS) to Frequency Selective Scheduling
(FSS), and vice versa. The initial mode is set to FSS. Then, the mode is
determined by the number of active users:
o When in the FSS mode, if the number of active users exceeds a

threshold nbrUserThrFDS, the scheduler switches the mode to
FDS.
Page 227/472
o When in the FDS mode, if the number of active users drops below a
threshold (nbrUserThrFDS – deltaNbrUserThrFDS), the scheduler
switches to the FSS mode.
Note that when narrow band SRS is enabled (i.e. when

isNarrowbandSRSuseEnabled is set to “True”), only FDS is supported.
FS/FD user classification

An FD user is classified as an FS user if it is in low mobility conditions (i.e. if it’s
(averaged) Doppler Shift satisfies Est_Doppler < lowMobilityDopplerUplinkThr[j])
and in good RF conditions (Est_SINR>sinrThrFSS). The index j corresponds to the
SRS period of the UE in question (j=0 for 5ms, j=1 for 10ms, j=2 for 20ms, j=3 for 40
ms, j=4 for 80ms and j=5 for 160ms).
An FS user is classified as an FD user if it is in high mobility conditions (i.e. if it’s

(averaged) Doppler Shift satisfies Est_Doppler > highMobilityDopplerUplinkThr[j])
and in relatively bad RF conditions (Est_SINR<sinrThrFSS-deltaSinrThrFSS). The
index j corresponds to the SRS period of the UE in question (j=0 for 5ms, j=1 for
10ms, j=2 for 20ms, j=3 for 40 ms, j=4 for 80ms and j=5 for 160ms).
Note that there can be no more than maxNbrULFSUsers UL FS users.

Also note that new UEs are considered as FD users by the UL scheduler.
CellL2ULConf::nbrUserThrFDS
Parameter nbrUserThrFDS
[0..600]
Feature FRS 90853
Page 228/472
CellL2ULConf::deltaNbrUserThrFDS
Parameter deltaNbrUserThrFDS
[0..600]
Value 10 ALU recommends the operator to not change this value
Feature FRS 90853
CellL2ULConf::sinrThrFSS
Parameter sinrThrFSS
Range & Unit Float
[-15.0..20.0] step = 0.1 dB
Value 0.0 ALU recommends the operator to not change this value
Feature FRS 90853
CellL2ULConf::deltaSinrThrFSS
Parameter deltaSinrThrFSS
Range & Unit Float
[0.0..10.0] step = 0.5 dB
Value 1.0 ALU recommends the operator to not change this value
Feature FRS 90853
Page 229/472
CellRadioConf::lowMobilityDopplerUplinkThr
Parameter lowMobilityDopplerUplinkThr
Range & Unit Table of 6 integer values
[0..100]
Value [99 99 99 99 99 99]
Feature FRS 90853
CellRadioConf::highMobilityDopplerUplinkThr
Parameter highMobilityDopplerUplinkThr
Range & Unit Table of 6 integer values
[0..100]
Value [100 100 100 100 100 100]
Feature FRS 90853
Rule: Regarding parameters lowMobilityDopplerUplinkThr and

highMobilityDopplerUplinkThr
The provisioning of these parameters must satisfy:

highMobilityDopplerUplinkThr[j] > lowMobilityDopplerUplinkThr[j] for j=1,…,6
CellL2ULConf::maxNbrULFSUsers
Parameter maxNbrULFSUsers
[0..600]
Feature FRS 90853
Page 230/472
Engineering Recommendation: Regarding parameters nbrUserThrFDS,

maxNbrULFSUsers
In LR13.1, the setting of these parameters should be:

- With eCEM:
dlBandwidth nbrUserThrFDS maxNbrULFSUsers
n6-1.4MHz 50 50
n15-3MHz 104 104
n25-5MHz 174 174
n50-10MHz 208 208
n100-20MHz 57 57
- With bCEM:
n25-5MHz 254 254
n50-10MHz 412 412
n75-15MHz 412 412
n100-20MHz 412 412

- With bCEM:
n6-1.4MHz 51 51
n15-3MHz 126 126
n25-5MHz 260 260
n50-10MHz 416 416
n75-15MHz 416 416
n100-20MHz 416 416
Page 231/472
CellL2ULConf::ulSchedulerMode
Parameter ulSchedulerMode
{FrequencySelectiveAllowed, FrequencyDiverseOnly}
Feature FRS 90853
Engineering Recommendation: Setting of parameter ulSchedulerMode
The current recommended setting for this parameter is as follows:
ulBandwidth isNarrowbandSRS ulSchedulerMode

useEnabled
n6-1_4MHz N.S. FrequencyDiverseOnly
n15-3MHz N.S. FrequencySelectiveAllowed
n50-10MHz False FrequencySelectiveAllowed
n50-10MHz True FrequencyDiverseOnly
4.6.7.3 BUFFER ESTIMATION
The buffer estimation function provides an estimate of the data available for
transmission in the UE UL RLC SDU buffers. The data already awaiting HARQ
feedback are not taken into account.
The buffer occupancy estimation relies on Buffer Status Reports (see [Vol. 3]) and
can be used as a mean to memorize and manage resource requests, by
incrementing the buffer estimate upon receipt of such a request.
The BSR is reported per group of bearers, or Group of Logical Channels (LCG). It
reports the amount of data available for transmission across all logical channels of a
given LCG identified by a 2-bit field in the BSR MAC PDU.
Parameter logicalChannelGroupUL indicates which Group ID the uplink Logical
Channel belongs to in the Buffer Status reports (i.e. which Buffer Occupancy), as per
36.321. When a logical Channel is not linked to a BO, no BSR is reported for that
Page 232/472
logical channel and the Buffer Occupancy Estimate of the logical channel in question
is not updated by a BSR report.
Upon receipt of a BSR report indicating a non-zero value for the LCGID
corresponding to SRB bearers, if the optimized segmentation is on for that user, then
the uplink scheduler deactivates optimized segmentation for that user and starts the
OverrideOptSegActivationTimer timer at the expiry of which optimized segmentation
can be activated again (see section 3.1.2). This is to keep the same transmission
robustness for SRBs.
SignalingRadioBearerConf::logicalChannelGroupUL
Parameter logicalChannelGroupUL
{ BufferOccupancy0, BufferOccupancy1, BufferOccupancy2,
BufferOccupancy3, noBufferOccupancy }
Value BufferOccupancy0
Feature FRS 76501
TrafficRadioBearerConf::logicalChannelGroupUL
Parameter logicalChannelGroupUL
{ BufferOccupancy0, BufferOccupancy1, BufferOccupancy2,
BufferOccupancy3, noBufferOccupancy }
Page 233/472

TrafficRadioBearerConf::logicalChannelGroupUL
The current default setting for this parameter is as follows:
TrafficRadioBearerConf::qCI TrafficRadioBearerConf::logicalChannelG
roupUL
1 BufferOccupancy3
2 BufferOccupancy1
3 BufferOccupancy1
4 BufferOccupancy1
5 BufferOccupancy0
6 BufferOccupancy2
7 BufferOccupancy2
8 BufferOccupancy2
9 BufferOccupancy2
Parameter SignalingRadioBearerConf::logicalChannelSRMask controls the one

bit flag provided to release 9 UEs or later upon creation or reconfiguration of an
uplink SRB. When set to “true”, it indicates that the UE should inhibit for that SRB the
triggering of Scheduling Requests when the UE is configured with an SPS active
grant.
Parameter TrafficRadioBearerConf::logicalChannelSRMask controls the one bit

flag provided to release 9 UEs or later upon creation or reconfiguration of an uplink
DRB. When set to “true”, it indicates that the UE should inhibit for that DRB the
triggering of Scheduling Requests when the UE is configured with an SPS active
grant.
Page 234/472
SignalingRadioBearerConf::logicalChannelSRMask
Parameter logicalChannelSRMask
True/False
Value False
Feature FRS 114531
TrafficRadioBearerConf::logicalChannelSRMask
Parameter logicalChannelSRMask
True/False
Value True
Feature FRS 114531
4.6.7.3.1 BUFFER OCCUPANCY ESTIMATE PERIODIC

INCREASE
Parameter macBOperiodicIncreaseEnabledUl enables/disables the (systematic)

increase of the buffer occupancy estimate.
Providing macBOperiodicIncreaseEnabledUl is set to “True”, the buffer increase
period and the buffer increase value are determined depending on the type of bearer
(SRB, QCI1, QCI2-4 and QCI5-9), as follows:
Page 235/472
SRB bearers and QCI5-9 (nGBR) bearers

The buffer increase period is derived from macBOPeriodicIncreasePeriodUl.
The buffer increase value is derived from mACBOminimumPeriodicIncreaseValue.
QCI2-4 (non QCI1) GBR bearers

The buffer increase period is derived from macBOPeriodicIncreasePeriodUl.
Assuming GBR is the Guaranteed Bit Rate value signaled for the logical channel in
question, expressed in bytes per ms, the buffer increase value is derived as
GBR × macBOperiodicIncreasePeriodUl but is lower bounded by the value of
mACBOminimumPeriodicIncreaseValue for the bearer in question, meaning that if
GBR × macBOperiodicIncreasePeriodUl is less than
mACBOminimumPeriodicIncreaseValue, the buffer increase value is set to
mACBOminimumPeriodicIncreaseValue.
SignalingRadioBearerConf::macBOperiodicIncreaseEnabledUl
Parameter macBOperiodicIncreaseEnabledUl
{enabled, disabled}
disabled ALU recommends the operator to not change these
Value
settings.
Feature
TrafficRadioBearerConf::macBOperiodicIncreaseEnabledUl
Parameter macBOperiodicIncreaseEnabledUl
{enabled, disabled}
Feature
Page 236/472
Rule: Buffer Occupancy estimate periodic increase
In LR13.1, periodic Buffer Occupancy estimate periodic increase is used for VoIP
services. It is also used for the default bearer (considered to be QCI9 in the
following engineering recommendations) in order to cope with possible PUSCH
power control drifts in case of UE inactivity.
The periodic increase should be disabled for all other data bearers.

TrafficRadioBearerConf::macBOperiodicIncreaseEnabledUl
As per the rule just above, the recommended setting for this parameter is as
follows:
TrafficRadioBearerConf::q TrafficRadioBearerConf::macBOperiodicIncreaseEnabl
CI edUl
1 enabled
2 disabled
3 disabled
4 disabled
5 disabled
6 disabled
7 disabled
8 disabled
9 enabled
ALU recommends the operator to not change these settings.
Page 237/472
SignalingRadioBearerConf::macBOPeriodicIncreasePeriodUl
Parameter macBOPeriodicIncreasePeriodUl
[1..250] ms
Value 5 ALU recommends the operator to not change this value.
Feature
TrafficRadioBearerConf::macBOPeriodicIncreasePeriodUl
Parameter macBOPeriodicIncreasePeriodUl
[1..250] ms
Feature
Page 238/472

TrafficRadioBearerConf::macBOperiodicIncreasePeriodUl
TrafficRadioBearerConf:: TrafficRadioBearerConf::macBOperiodicIncreasePer
qCI iodUl
1 20
2 5
3 5
4 5
5 5
6 5
7 5
8 5
9 250
ALU recommends the operator to not change these settings.
TrafficRadioBearerConf::mACBOminimumPeriodicIncreaseValue
Parameter mACBOminimumPeriodicIncreaseValue
[0..512] bytes
Value 5
Feature
Page 239/472
SignalingRadioBearerConf::mACBOminimumPeriodicIncreaseValue
Parameter mACBOminimumPeriodicIncreaseValue
[0..512] bytes
Value 5
Feature
EnbVoipConf::disableVoIPbearerPeriodicBOincreaseDuringSpeechInactivityUl
disableVoIPbearerPeriodicBOincreaseDuringSpeechInactivity
Parameter
Ul
True/False
True The function associated with this parameter is considered
Value
personnel.
Feature FRS 114531
4.6.7.4 QOS PRIORITY WEIGHT CALCULATION
The QoS priority weight indicates the difference between the experienced QoS and
the negotiated QoS.
There is one QoS weight metric per UE.
With the channel quality information, it is one of the two input parameters that are
used by the UL scheduler to decide which UEs are served and which resources they
are granted.
The QoS metric is based on:
• The uplink buffer occupancy estimate
• The observed UL throughput for each PS RAB compared to the negotiated
QoS parameters. This includes GBR bearers, as well as nonGBR bearers
for nonGBR minimum rate throughput target when
isNonGBRMinRateEnabled=True.
• The QCI weight associated with each bearer (GBR and nonGBR) when
isQCIWeightEnabled=True.
Page 240/472
The UE priority metric used for UE pre-selection is the product of the UE QoS Weight
and its predicted spectral efficiency (SE) . A UE close to cell centre will tend to have
a higher spectral efficiency compared to a UE at cell edge. This gives an advantage
to cell centre UEs to be served over cell edge UEs. To improve the chances of a
cell edge UE to be served over a cell centre UE, parameter uplinkSeFloor is
introduced in LR13.1 to enforce a minimum SE value. Thus, the output of UL
scheduler’s SE LUT is:
SE(ue) = max( SE_LUT(SINR(ue)), uplinkSeFloor )
Increasing the minimum SE value is expected to result in a lower QoS weight needed
for a UE at cell edge to be selected over a UE at cell centre.
For example, prior to LR13.1, if a UE at cell centre has SE=400 kbps/PRB and a UE
at cell edge has SE=2 kbps/PRB, then the cell edge UE would need to have a QoS
weight = 400/2=200 times higher than a UE at cell centre in order to be served
before the cell centre UE. However, in LR13.1, uplinkSeFloor can raise the
minimum SE, for example to 20 kpbs/PRB, so the cell edge UE would only need to
have a QoS weight = 400/20 = 20 times higher than a UE at cell centre in order to be
served before the cell centre UE. Furthermore, the cell edge UE can reach the same
level of priority with much fewer Scheduling Requests (SR) as the cell centre UE
after one SR.
EnbRadioConf::uplinkSeFloor
Parameter uplinkSeFloor
Range & Unit Float
[0.0..3.0] step = 0.01 dB
Value
personnel.
Feature L160636
When isVoIpSegmentationHandlingEnabled is set to “true”, the user priority is kept

high in the uplink scheduler until all segments of the speech frame have been
scheduled. This is an enhancement to improve VoIP packets delay statistics.
Page 241/472
CellL2ULConf::isVoIpSegmentationHandlingEnabled
Parameter isVoIpSegmentationHandlingEnabled
True/false
Value True
Feature FRS 115233.1
4.6.7.4.1 OVERALL QOS WEIGHT
When isQCIWeightEnabled=True a configurable per-QCI scheduling weight is

associated to each type of bearer. The weight is configured by parameter
TrafficRadioBearerConf::ulQCISchedulingWeight. This is to allow customers to
tune the throughput differentiation (thus the throughput ratio) between different QCIs
of the same type (GBRs and nonGBRs) when established on different UEs. The UE
is associated with the highest weight with a non-zero Buffer Occupancy estimate,
among the established bearers for that UE. The higher the ratio of these weights
between 2 UEs, the highest the throughput ratio between the 2 UEs in question.
Otherwise, when isQCIWeightEnabled=False, parameter ulQCISchedulingWeight
is ignored.
ActivationService::isQCIWeightEnabled
Parameter isQCIWeightEnabled
True/False
Feature FRS 160636, FRS 128460 (L115698)
Page 242/472
TrafficRadioBearerConf::ulQCISchedulingWeight
Parameter ulQCISchedulingWeight
{0.125, 0.25, 0.5, 1.0, 2.0, 4.0, 8.0, 16.0, 32.0, 64.0, 128}
Feature FRS 160636
Page 243/472
Engineering Recommendation: Parameter ulQCISchedulingWeight
This parameter is set at bearer level. The setting depends on the end-user quality
of the service that the operator wants to achieve.
e.g. if the operator need to provide 3 different upload application Grades of
Service (GoS), e.g. Gold, Silver and Bronze, this is possible by mapping each
GoS to a distinct QCI, e.g. QCI6, QCI8 and QCI9, respectively, and setting
ulQCISchedulingWeight associated with these QCIs in the right proportions, i.e.
for a resource allocation ratio of 4:2:1 among the Gold:Silver:Bronze GoSs, setting
ulQCISchedulingWeight as follows:
GoS qCI ulQCISchedulingWeight
Gold 6 2.0
Silver 8 1.0
Bronze 9 0.5
If on top of that, a VoIP service is also provided, 2 bearers need to be established:

a QCI1 bearer for the VoIP data traffic and e.g. a QCI5 bearer for the IMS
signaling.
In order for the VoIP service (with its very tight timing constraints) not to be
disturbed by the traffic of the other services, its priority (and thus QoS weight)
would need to be set much higher than that of Best Effort services, e.g.
Service qCI ulQCISchedulingWeight
VoIP IMS Signaling 5 16.0
VoIP data 1 8.0
Note that the default setting does not create any differentiation on top of the
GBR/n-GBR and delay-based differentiations:
qCI ulQCISchedulingWeight
1 1.0
2 1.0
3 1.0
4 1.0
5 1.0
6 1.0
7 1.0
8 1.0
9 1.0
Page 244/472
In LR13.1, minRate-based QoS for nonGBR bearers is activated when

isNonGBRMinRateEnabled is set to True., When this feature is activated, the UL
scheduler will maintain a UE’s minimum nonGBR throughput target for the set of its
established nonGBR bearers that have configured parameter
ullMinThroughputTarget > 0. This parameter specifies the minimum UL active
throughput target enforced by the UL scheduler when the nonGBR bearer has data
to be transmitted over the UL.
ActivationService::isNonGBRMinRateEnabled
Parameter isNonGBRMinRateEnabled
True/False
Feature FRS 128460 (L115698)
LA6.0 – LR13.1 Delta: Parameter isNonGBRMinRateEnabled
Restriction: isNonGBRMinRateEnabled
LR13.1 feature minRate-based QoS for nonGBR is supported only on bCEM.
TrafficRadioBearerConf::ulMinThroughputTarget
Parameter ulMinThroughputTarget
[0..5000] step 50 kbits/s
Value O.D. (See Engineering Recommendation - TBD)
Feature FRS 128460 (L115698)
LA6.0 – LR13.1 Delta: Parameter ulMinThroughputTarget
Page 245/472
Engineering Recommendation: Parameter ulMinThroughputTarget
This is an optional parameter. It should be <unset> if isNonGBRMinRateEnabled

is set to “False”.
Since UL scheduling is made at the aggregate UE level (not bearer level), all
nonGBR bearers that have minimum throughput target are considered together to
generate a per UE minimum active throughput target. Thus, a UE’s minimum
nonGBR throughput target is defined as:
MinNonGBRthrTarget =
∑ ulMinThroughputTarget (i)
Where i denotes the set of the UE’s established nonGBR bearers configured with
ulMinThroughputTarget > 0.
If nonGBR bearers that are transmitting UL data packets are falling below the
minimum nonGBR throughput target, even with per-QCI weight
(ulQCISchedulingWeight) applied, the UL scheduler will then apply an additional
minRate weight in order to maintain the minimum nonGBR throughput target for the
UE.
The minRate QoS throughput metric is evaluated during data bursts (when UL Buffer
Occupancy (BO) of any of the UE’s nonGBR bearers becomes non-zero from zero),
Data bursts with a spacing less than EnbRadioConf::rabInactivityTimer are
regarded as one burst, but the gap between bursts (i.e. zero Occupancy) is
discounted from the throughput evaluation. This is illustrated in Figure 19 below.
Page 246/472
one burst
UE aggregated UE aggregated
minRate QoS minRate QoS
BO throughput throughput
metric updated metric updated
gap
< rabInactivityTimer rabInactivityTimer
Figure 17: UL Scheduler view of data burst for minRate QoS throughput metric evaluation
Parameter ulActiveThroughputAverageCoefficient specifies the forgetting factor

of the throughput metric calculation. The forgetting factor is the value of this
parameter divided by 1024. Decreasing the value results in higher estimated
throughput metric calculated value.
EnbRadioConf::ulActiveThroughputAverageCoefficient
Parameter ulActiveThroughputAverageCoefficient
[0..1023]
Value 1014
Feature FRS 128460 (L115698)
LA6.0 – LR13.1 Delta: Parameter ulActiveThroughputAverageCoefficient
If the UL nonGBR throughput falls below the minimum nonGBR throughput target,
the UL scheduler applies uniformly increasing minRate weight until the throughput
exceeds this minimum target plus a margin specified by parameter
marginForNonGbrMinRateEnforcement. The maximum minRate weight that may
Page 247/472
be applied is specified by parameter ulMaxNonGbrQoSWeight. This maximum

weight is applied whenever the throughput remains below the minimum throughput
target (ullMinThroughputTarget). See Table for a summary.
Evaluated ulThroughput Metric(UlThr) minRate Weight Applied
UlThr < MinNonGBRthrTarget ulMaxNonGbrQoSWeight
MinNonGBRthrTarget ≤ UlThr <

(1 + marginForNonGbrMinRateEnforcement) uniformly increasing weight
× MinNonGBRthrTarget function
UlThr ≥
(1 + marginForNonGbrMinRateEnforcement) no weight
× MinNonGBRthrTarget
EnbRadioConf::marginForNonGbrMinRateEnforcement
Range & Unit Float
[0.1..3.0] step 0.1
Value 0.5
Feature FRS 128460 (L115698)
LA6.0 – LR13.1 Delta: Parameter marginForNonGbrMinRateEnforcement
EnbRadioConf::ulMaxNonGbrQosWeight
Parameter ulMaxNonGbrQosWeight
[1..64]
Value 8
Feature FRS 128460 (L115698)
Page 248/472
LA6.0 – LR13.1 Delta: Parameter ulMaxNonGbrQosWeight
4.6.7.5 UPLINK CHANNEL ESTIMATES UPDATE
Uplink channel estimates are based on L1 measurements reports (see section 4.6.3).
4.6.7.6 SPECTRUM EFFICIENCY CORRECTION
The spectrum efficiency correction function is a control loop in charge of the

computation of a spectrum efficiency correction factor that is added to the Spectrum
Efficiency value derived from the UL SRS SINR.
4.6.7.7 SCHEDULING STAGE
The dynamic scheduler considers HARQ retransmissions first and HARQ 1st
transmissions next.
4.6.7.7.1 MANAGEMENT OF HARQ

RETRANSMISSIONS
HARQ retransmissions are assigned resources before any resource is granted to any
first HARQ transmission.
HARQ retransmissions use the same PRBs as the initial transmission.
Also, two successive transmissions are always 8ms apart.
The MCS used for a HARQ retransmission is the same as the one used for the
related 1st HARQ transmission.
Parameter maxHARQtx configures the maximum number of HARQ transmissions (in

the uplink). Note that this does not apply only to dynamically scheduled transmission
but to all transmissions except the transmission of RACH message 3.
Page 249/472
CellL2ULConf::maxHARQtx
Parameter maxHARQtx
{ n1, n2, n3, n4, n5 }
Value n5
Feature
4.6.7.7.2 MANAGEMENT OF HARQ 1ST

TRANSMISSIONS
Once the UEs with dynamic HARQ retransmissions have been served, the
(remaining) HARQ transmissions are granted resources based on an iterative
algorithm denoted below as the MPE algorithm.
The inputs of the MPE algorithm include:

• A map of the remaining PUSCH resources and PDCCH resources made
available to the UL scheduler, similar to the one used in the downlink and
illustrated in Figure 11.
• The list of the UEs considered for dynamic scheduling in the current
subframe.
Management of SPS grants with PUSCH type 2 hopping

When SPS is configured for Type2 PUSCH Hopping (i.e. when
isPUSCHType2HoppingForSPSgrantsEnabled is set to “True”), there is a risk of
collision upon HARQ retransmission between SPS grants (hopping) and dynamic
grants (i.e. non-hopping). Therefore, when
isPUSCHType2HoppingForSPSgrantsEnabled is set to “True”, in any given TTI
the uplink scheduler considers as not available for dynamic scheduling both the
PRBs booked for SPS traffic and their symmetrical with respect to the central
PUSCH frequency.
MPE Algorithm stages

The stages of the algorithm are the following:
• Stage 1: Convert the QoS weight and the PUSCH SINR measurements into
Priority Metrics. A priority metric is associated to each PRB, for each user.
Page 250/472
• Stage 2: Find the Maximum Priority Envelope.

• Stage 3: Form the Maximum Priority Envelope groups.
• Stage 4: Allocate the envelope group with the highest priority metric.
• Repeat stages 3-4 until there is either no eligible user or no resource left.
• Stage 5: Allocate the remaining resources.
• Stage 6: Assign the TBS and modulation schemes.
• Stage 7: Update the UL buffer occupancy estimates with the latest
scheduling decisions.
The maximum number of MPE iterations (allowed in one TTI) is configured using
parameter maxNumberOfMPEiterations.
EnbRadioConf::maxNumberOfMPEiterations
Parameter maxNumberOfMPEiterations
[1..16]
See Engineering Recommendation The function associated
with this parameter is considered to be proprietary, and is thus
Value
not described here. The value of the parameter should only be
modified by qualified ALU personnel.
Feature
Rule: Regarding parameter maxNumberOfMPEiterations
maxNumberOfMPEiterations needs to be configured per band. However, this
parameter is configured per eNB instead of per cell. Therefore, in LR13.1, for a
dual band/dual carrier eNB which uses different bandwidths for the different
bands/carriers, a hardcoded value is used in place of the values that are
configured for them using WPS/SAM, or NEM. The hardcoded value is 4, 6, 8 and
10 for BWs 5MHz, 10MHz, 15MHz and 20MHz respectively.
Page 251/472
Engineering Recommendation: Parameter maxNumberOfMPEiterations
The current recommended setting for this parameter is as follows
ulbandwidth maxNumberOfMPEiterations
n6-1_4MHz 2
n15-3MHz 2
n25-5MHz 3
n50-10MHz 3
n75-15MHz 6
n100-20MHz 6
ALU recommends the operator to not change this value
EnbRadioConf::minGrantSizeForCQIreporting
Parameter minGrantSizeForCQIreporting
{1PRB, 2PRB, 3PRB, 4PRB, 5PRB, 6PRB, 8PRB, 9PRB, 10 PRB,
12PRB, 15PRB, 16PRB, 18PRB, 20PRB, 24PRB, 25PRB, 27PRB,
100PRB }
4PRB The function associated with this parameter is considered
Value
personnel.
Feature FRS 101841
Rule: Regarding parameter minGrantSizeForCQIreporting
minGrantSizeForCQIreporting needs to be configured per band. However, this
parameter is configured per eNB instead of per cell. Therefore, in LR13.1, for a
dual band/dual carrier eNB which uses different bandwidths for the different
Page 252/472

configured for them using WPS/SAM, or NEM. The hardcoded value is 4PRB,
4PRB, 5PRB and 6PRB for BWs 5MHz, 10MHz, 15MHz and 20MHz respectively.
• An MCS is derived according to section 4.5.3.9. Then:
o If the selected grant configuration is {IMCS=6, NPRB=1}, QPSK 4/3), it

is replaced by the configuration {IMCS=5, NPRB=1} QPSK 1/3). The
reason for this is that the former configuration does not provide
enough protection.
o If the UE is expected to send PCQI/PMI/RI in the considered TTI and
the MCS derived as per section 4.5.3.9 is lower than the minimum
MCS for PUSCH multiplexed P-CQI transmissions
minMCSwithPCQI, the latter is enforced (the selected MCS is
replaced with minMCSwithPCQI). This is to ensure that the P-CQI
report quality is acceptable (target error rate <0.1%).
o If the PUSCH grant requires an ACQI/PMI/RI report in the
considered TTI and the MCS derived as per section 4.5.3.9 is lower
than the minimum MCS for A-CQI transmissions minMCSwithACQI,
the latter is enforced (the selected MCS is replaced with
minMCSwithACQI). This is to ensure that the A-CQI report quality is
acceptable (target error rate <0.1%).
EnbRadioConf::minMCSwithPCQI
Parameter minMCSwithPCQI
[0..22]
Feature FRS 90853
Page 253/472
Rule: Regarding parameter minMCSwithPCQI
minMCSwithPCQI needs to be configured per band. However, this parameter is
configured per eNB instead of per cell. Therefore, in LR13.1, for a dual band/dual
carrier eNB which uses different bandwidths for the different bands/carriers, a
hardcoded value is used in place of the values that are configured for them using
WPS/SAM, or NEM. The hardcoded value is 0 for all BWs: 5MHz, 10MHz, 15MHz
and 20MHz.
EnbRadioConf::minMCSwithACQI
Parameter minMCSwithACQI
[0..22]
Feature FRS 101841
Rule: Regarding parameter minMCSwithACQI
minMCSwithACQI needs to be configured per band. However, this parameter is
configured per eNB instead of per cell. Therefore, in LR13.1, for a dual band/dual
carrier eNB which uses different bandwidths for the different bands/carriers, a
hardcoded value is used in place of the values that are configured for them using
WPS/SAM, or NEM. The hardcoded value is 0 for all BWs: 5MHz, 10MHz, 15MHz
and 20MHz.
Page 254/472
Parameter maxExtendedSRGrantSize controls the maximum grant size that can be

issued by the uplink scheduler when responding to an SR.
CellL2ULConf::maxExtendedSRGrantSize
Parameter maxExtendedSRGrantSize
[0..100]
Value 6
Feature FRS 115113
If optimized segmentation is active for some UE, then a minimum grant size is
enforced by parameter CellL2ULConf::minNbrPRBForULDSVoIP.
4.6.7.7.3 MANAGEMENT OF POWER HEADROOM

REPORTS
The Power Headroom reports are sent by the UE in the uplink MAC control
elements.
The UE is notified that it needs to apply the AMPR constraints by setting parameter
additionalSpectrumEmission to 7.
Page 255/472
LteCell::additionalSpectrumEmission
Parameter additionalSpectrumEmission
[1..32]
Feature FRS 76501
Engineering Recommendation: Parameter additionalSpectrumEmission

setting
The current recommended setting is as follows:
ul700MHzUpperCBlockEnabled additionalSpectrumEmission
False 1
True 7
EnbRadioConf::aMPRappliedToSRS
Parameter aMPRappliedToSRS
[0..20] step = 1 dB
Feature FRS 85004
Page 256/472
Engineering Recommendation: Parameter aMPRappliedToSRS setting
The current recommended setting is as follows:
isNarrowbandSRSuseEnabled aMPRappliedToSRS
False 12
True 0
Rule: Regarding parameter aMPRappliedToSRS
aMPRappliedToSRS needs to be configured per band. However, this parameter
is configured per eNB instead of per cell. Therefore, in LR13.1, for a dual
band/dual carrier eNB which uses different bandwidths for the different
configured for them using WPS/SAM, or NEM. The hardcoded value is:
ul700MHzUpperCBlockEnabled aMPRappliedToSRS
False 0
True 0, 12, 0 and 0 for BWs 5MHz,

10MHz, 15MHz and 20MHz,
respectively.
Specific 700MHz upper Block C band parameters are summarized below. These
parameters are only meaningful when parameter ul700MHzUpperCBlockEnabled
(which enables/disables the operation of the system in the 700 MHz Upper C Block)
is set to “true”.
Page 257/472
LteCell::ul700MHzUpperCBlockEnabled
Parameter ul700MHzUpperCBlockEnabled
True/False
Feature FRS 76432
Engineering Recommendation: Parameter ul700MHzUpperCBlockEnabled
The setting of this parameter depends on whether the customer operates their
network in the 700 MHz Upper Block C or not. It is only significant when the
system operates in a 10 MHz bandwidth (i.e. ulBandwidth is set to “n50-10MHz”),
otherwise the flag is ignored by the system.
EnbRadioConf::PHRthresholdFor700MHzZoneA
Parameter PHRthresholdFor700MHzZoneA
Range & Unit Float
[-24..58] step = 0.5 dB
Value 23.0
Feature FRS 85004
EnbRadioConf::PHRthresholdFor700MHzZoneB1
Parameter PHRthresholdFor700MHzZoneB1
Range & Unit Float
[-24..58] step = 0.5 dB
Value 25.0
Feature FRS 85004
Page 258/472
EnbRadioConf::PHRthresholdFor700MHzZoneB2
Parameter PHRthresholdFor700MHzZoneB2
Range & Unit Float
[-24..58] step = 0.5 dB
Value -24.0
Feature FRS 85004
EnbRadioConf::PHRthresholdFor700MHzZoneC
Parameter PHRthresholdFor700MHzZoneC
Range & Unit Float
[-24..58] step = 0.5 dB
Value 6.0
Feature FRS 85004
Parameter CellL2ULConf::OptSegPuschSinrThresh represents the achievable

PUSCH SINR below which optimized segmentation is possible for a given user.
The range of OptSegPuschSinrThresh is [-10, +40] dB with a step size of 0.5dB
4.6.7.8 MCS ALLOCATION
The Modulation and Coding Scheme (MCS) that is allocated (to transmit data on the
PRBs allocated to a given user) is adapted to changing radio conditions (or radio link
quality) of the UE. An improvement in the radio link quality (increase in the SINR
achieved at the eNB) causes the transmitter to use a less robust MCS and hence a
higher data transmission rate. Conversely, a degradation in the radio link quality
(decrease in the SINR achieved at the eNB) causes the transmitter to use a more
robust MCS and hence a lower data transmission rate.
The MCS is derived using the UL MCS transition table. The MCS derivation uses the
number of PRBs and the SINR.
Note that ulMCSTransitionTableForLargePUSCHGrants and

ulMCSTransitionTableForLargePUSCHGrants consist of 21 thresholds instead of
22. This is due to the fact that MCS21 is not used as it yields the same transport
Page 259/472
block size and modulation scheme as MCS20 (see section 7.2). Thus, the 21st
element represents the threshold for the transition from MCS20 to MCS22.
The MCS scheme defines

o The selected modulation: {QPSK, 16QAM}
o The selected coding scheme: Choices available are {1/3; ½; 2/3; ¾} for
QPSK, {1/2; 2/3; 3/4;7/8} for 16QAM SIMO and {1/2; 2/3;3/4} for 16QAM
MU-MIMO.
CellRadioConf::ulMCSTransitionTableForLargePUSCHGrants
Parameter ulMCSTransitionTableForLargePUSCHGrants
Range & Unit Table of 21 float values
[-15.0..20.0] step = 0.1 dB
[-2.5, -2.0, -1.4, -0.4, 0.0, 0.9, 1.9, 2.7, 3.2, 4.3, 5.1, 6.0,
Value
7.0, 7.9, 8.5, 9.3, 9.8, 11.0, 11.5, 13.5, 14.5] (Default)
Feature FRS 84873
CellRadioConf::ulMCSTransitionTableForSmallPUSCHGrants
Parameter ulMCSTransitionTableForSmallPUSCHGrants
[-15..20] step = 0.1 dB
[-2.0, -1.3, -1.0, 0.0, 0.6, 1.5, 2.2, 2.9, 3.8, 4.6, 5.2, 6.1,
Value
7.0, 8.0, 8.9, 9.2, 9.6, 11.0, 12.1, 13.4, 15.1] (Default)
Feature FRS 84873
Page 260/472
CellRadioConf::ulMCSTransitionTablePRBsizeThreshold
Parameter ulMCSTransitionTablePRBsizeThreshold
[0..100]
Value 7
Feature FRS 84873
Note that an MCS correction is applied to the SINR prior to the MCS selection in
order to make the latter more conservative when:
o A CQI report is embedded in the PUSCH transmission (in order to improve
the CQI BLER).
o The grant is small (in order to minimize PUSCH resource fragmentation due
to the retransmission of small grants).
o A HARQ retransmission related to the grant can potentially collide with a

RACH message 1 or RACH message 3.
o The grant corresponds to a UE that was initially considered for scheduling
following detection of a Scheduling Request coming from that UE.
The correction MCScorrection is computed as the maximum of MCScorrectionForCQI

(MCS correction due to a probable CQI report embedded in the PUSCH
transmission), MCScorrectionForRACHmsg1or3 (MCS correction due to a probable
collision risk of collision between a HARQ retransmission related to the grant and a
RACH message 1 or RACH message 3), MCScorrectionForSmallPackets (MCS
correction due to a probable small size for the grant) and MCScorrectionForSRGrant
(MCS correction due to a probable SR having led to the grant) which are derived as
follows
• MCScorrectionForCQI: If (the grant includes an A-CQI and the grant size is <
8 PRBs) then MCScorrectionForCQI is set equal to
mCScorrectionForACQIinLowerBLERcase for the Lower BLER case or to
mCScorrectionForACQIinHigherBLERcase for the Higher BLER case.
o Else if the grant includes a P-CQI then MCScorrectionForCQI is set

equal to mCScorrectionForPCQIinLowerBLERcase for the Lower
BLER case or to mCScorrectionForPCQIinHigherBLERcase for
the Higher BLER case.
 Else If P-CQI/P-RI reporting is expected to be sent along
with one of the first mCScorrectionPCQIguardTime
Page 261/472
(probable) HARQ retransmissions and the targeted BLER is

the high one then MCScorrectionForCQI is set equal to
mCScorrectionForPCQIinHigherBLERcase.
• Else MCScorrectionForCQI is set to 0.
• MCScorrectionForRACHmsg1or3 is set to
o mCScorrectionForGrantsBeforeRachMsg1or3ForLowerBLERSe
tpoint[i] for the Lower BLER case and
mCScorrectionForGrantsBeforeRachMsg1or3ForHigherBLERSe
tpoint[i] for the Higher BLER case, in the subframes that are 8×i
TTIs (and 8×i-1 TTIs if pRACHPreambleFormat2Enabled is set to
“True”) ahead of the RACH 1 subframe(s), i.e. in the subframes
where there is a risk of collision between a (potential) ith HARQ
retransmission (i=1,…, maxHARQtx-1) and RACH message 1 for
i=1,…, minHARQtx).
o mCScorrectionForGrantsBeforeRachMsg1or3ForLowerBLERSe
tpoint[i] for the Lower BLER case and
mCScorrectionForGrantsBeforeRachMsg1or3ForHigherBLERSe
tpoint[i] for the Higher BLER case, in the subframes that are 8×i
TTIs ahead of the RACH 3 subframes, i.e. in the subframes where
there is a risk of collision between a (potential) ith HARQ
retransmission (i=1,…, maxHARQtx-1) and RACH message 3 for
i=1,…, minHARQtx).
o Equal to 0, in the other subframes.
• MCScorrectionForSmallPackets: If the grant size is less than
smallPktPuschPRBThr and the normalized power headroom for UE k
PHnormalized(user k) is greater than smallPktHPuschPowerMargin, and the
targeted BLER is the High BLER one, MCScorrectionForSmallPackets is set
equal to mCScorrectionForSmallULPackets. Otherwise, it is set equal to 0.
Page 262/472
• MCScorrectionForSRGrant: If the grant is issued to respond to an SR,

MCScorrectionForSRGrant is set equal to sinrBackoffForSRGrant.
Otherwise, it is set equal to 0.
Note that if the conditions to apply the MCS correction for SR Grant or for A-CQI, or
RACH collision avoidance, then no Spectrum Efficiency correction is applied for the
grant.
CellRadioConf::mCScorrectionForACQIinHigherBLERcase
Parameter mCScorrectionForACQIinHigherBLERcase
Range & Unit Float
[0.0..5.0] step = 0.1 dB
Value 3.0 ALU recommends the operator to not change this setting
Feature FRS 101841
CellRadioConf::mCScorrectionForACQIinLowerBLERcase
Parameter mCScorrectionForACQIinLowerBLERcase
Range & Unit Float
[0.0..5.0] step = 0.1 dB
Feature FRS 101841
CellRadioConf::mCScorrectionForPCQIinHigherBLERcase
Parameter mCScorrectionForPCQIinHigherBLERcase
Page 263/472
Range & Unit Float
[0..5] step = 0.1 dB
Feature FRS 101841
CellRadioConf::mCScorrectionForPCQIinLowerBLERcase
Parameter mCScorrectionForPCQIinLowerBLERcase
Range & Unit Float
[0.0..5.0] step = 0.1 dB
Feature FRS 101841
CellRadioConf::mCScorrectionForGrantsBeforeRachMsg1or3ForHigherBLERS
etpoint
mCScorrectionForGrantsBeforeRachMsg1or3ForHigherBLERS
Parameter
etpoint
[0.0..5.0] step = 0.1 dB
[2.0 1.0 1.0 0.0] ALU recommends the operator to not change
Value
this setting
Feature FRS 104823
CellRadioConf::mCScorrectionForGrantsBeforeRachMsg1or3ForLowerBLERS
etpoint
mCScorrectionForGrantsBeforeRachMsg1or3ForLowerBLERSe
Parameter
tpoint
[0.0..5.0] step = 0.1 dB
Page 264/472

[2.0 1.0 1.0 0.0] ALU recommends the operator to not change
Value
this setting
Feature FRS 104823
CellRadioConf::smallPktPuschPRBThr
Parameter smallPktPuschPRBThr
[0..10] PRBs
Value 3 ALU recommends the operator to not change this setting
Feature FRS 90853
CellRadioConf::smallPktHPuschPowerMargin
Parameter smallPktHPuschPowerMargin
[0..20]
Feature FRS 90853
CellRadioConf::mCScorrectionForSmallULPackets
Parameter mCScorrectionForSmallULPackets
Range & Unit Float
[0.0..5.0] step = 0.1 dB
Feature FRS 90853
CellL2ULConf::sinrBackoffForSRGrant
Page 265/472
Parameter sinrBackoffForSRGrant
Range & Unit Float
[0.0..5.0] step = 0.5 dB
Value 1.0
Feature FRS 115113
When Optimized Segmentation is active for the UE, and the grant size is less than or
equal to 4 PRBs, then parameter table minMCSForULDSVoIP controls the minimum
MCS that is allowed to be used for VoIP grants of size x PRB when Optimized
Segmentation is applied (x corresponds to the index of the table). Setting the
parameter to 0 effectively disables the MCS override.
CellL2ULConf::minMCSForULDSVoIP
Parameter minMCSForULDSVoIP
Range & Unit List of 4 Integer
[0..10]
Value [8,4,2,1]
Feature FRS 160815
4.6.7.9 OVERRIDE OF GRANT DECISIONS TO ENFORCE UE CATEGORY

CONSTRAINTS
The uplink scheduler enforces the constraints in terms of max TBS for the category
of the UE. This is done by restricting the number of PRBs that are granted to a UE
for a given selected MCS and a given UE category, as per the following tables.
In LR13.x, only MCS 0-22 are supported.
For UE category 1, according to TS 36.306 the maximum TBS that can be assigned
is 5160bits. The PRB size corresponding to the MCS 22 is 10.
For UE category 2, according to TS 36.306 the maximum TBS that can be assigned
is 25456 bits. The PRB size corresponding to the MCS 22 is 54.
Page 266/472
For UE category 3 or 4, there is no such restriction for any system bandwidth

because the TBS limitation (i.e. max 51024 for UE category 3 or 4) is larger than the
max-allowed TBS size 45352 (96 PRBs, MCS22).
Max grant size in PRB

Selected MCS
for a cat 1 UE
0 100
1 100
2 100
3 81
4 72
5 54
6 50
7 40
8 36
9 32
10 27
11 27
12 25
13 20
14 20
15 18
16 16
17 16
18 12
19 12
20 12
21 12
22 10
Max number of PRBs that can be granted to a category 1 UE (max TB size = 5160 bits)
Page 267/472
Max grant size in PRB

Selected MCS
for a cat 2 UE
0 100
1 100
2 100
3 100
4 100
5 100
6 100
7 100
8 100
9 100
10 100
11 100
12 100
13 100
14 100
15 90
16 81
17 75
18 64
19 64
20 60
21 60
22 54
Max nbr of PRB that can be granted to a category 2 UE (max TB size = 25456)
4.6.7.10 OVERRIDE DECISIONS TO AVOID GRANTS WITH NO USEFUL

PAYLOAD
In order to avoid eNB continuously assigning UL grants for which a UE would
continuously transmit only padding, a minimum UL grants size has been defined by
3GPP (spec 36.321) for which UEs shall transmit RLC data:
o A Release 8 or 9 UE must transmit data when available (i.e. it is not allowed
to only send padding / padding BSR), at least when given an UL grant size of
“7 bytes” or larger.
o A Release 10 UE must transmit data when available (i.e. it is not allowed to
only send padding / padding BSR), at least when given an UL grant size of
“4 bytes” or larger.
However, bits 0-1 and bits 2-3 (respectively for Release 8-9 and Release 10 UEs) of
spare parameter Enb::spare9 give the possibility to configure 4 different values for
that minimum PUSCH TB size:
o Bits 0-1 define the minimum PUSCH TB size (it shall be replace by a proper
MIM parameter in LR14: minPuschTBsizeForRelease8and9UE) that can
Page 268/472
be assigned to a release 8 or 9 UE. The mapping is: 0--> 2bytes, 1-->4

bytes, 2-->7bytes, 3-->9bytes (default value: 2).
o Bits 2-3 define the minimum PUSCH TB (it shall be replace by a proper MIM
parameter in LR14: minPuschTBsizeForRelease10UEs) size that can be
assigned to a release 10 UE. The mapping is: 0--> 2bytes, 1-->4 bytes, 2--
>7bytes, 3-->9bytes (default: 1).
This given possibility to configure different values follows two logics:

o Not all UEs may be following this late released restriction (for example, a lot
of Release 8 UEs were already in the market when this restriction came up).
Therefore, capacity issue in the network naturally leads to set higher value
for this minimum PUSCH TB size in order not to waste any resource.
o In a low traffic network, to avoid any possible latency in the transmission of
data, it is possible for the operator to configure a lower minimum TB size
than the one defined by 3GPP.
4.6.7.11 ONE SHOT CSI SCHEDULING FOR CARRIER AGGREGATION
As described in section 4.5.3.11.2 above, Rel-10 A-CSI is introduced for Carrier

Aggregation. Instead of managing a preselected list of UE for which A-CSI report on
SCell is required, a “One Shot” CSI report request is preferred. Note that the list
based approach is still used for A-CSI_P and non-CA configured and activated UEs.
The DL scheduler determines when A-CSI for SCell is required and sends the
request to the UL scheduler. The UL Scheduler must schedule the One Shot A-CSI
requested by DL Scheduler within a maximum delay set by
CarrierAggregationPrimaryConf::oneShotACSIMaxDelay. When this timer
expires, and the One Shot A-CSI request is not granted yet, the request is discarded
by the UL Scheduler.
CarrierAggregationPrimaryConf::oneShotACSIMaxDelay
Parameter oneShotACSIMaxDelay
Object
gregationPrimaryConf
[100.. 10000] ms
Value 100
Feature 160847
4.6.8 MIMO SCHEDULER

In the uplink, the Multi-User MIMO is used to leverage the spatial multiplexing gain
through sharing the time-frequency resources among multiple UEs. The criteria to
switch the MU-MIMO on depend on whether it can achieve the spatial multiplexing
gain.
Page 269/472
The dynamic switch between MU-MIMO and SIMO is done per TTI since the gain
from MU-MIMO is highly dependent on the channel spatial correlation and its
frequency-selectiveness.
UL-MIMO is enabled on a cell basis by setting the parameter ulMIMOenabled.
CellActivationService::isulMIMOenabled
Parameter isulMIMOenabled
True/False
Value False
Feature FRS 76432
Restriction: UL MIMO
The following restrictions apply to UL MIMO in LA6.0:
• UL MIMO is only supported in 5MHz, 10MHz and 20MHz system BWs.

• UL-MIMO is not supported in 700 MHz Upper Block C
• UL-MIMO is only supported for demo purposes with a capacity of 2 UEs
per cell.
For MU-MIMO, two users with orthogonal channel conditions are selected for each
PRB.
4.6.9 BEARER MULTIPLEXING

The Logical Channel Prioritization procedure is applied when a new transmission is
performed.
RRC controls the scheduling of uplink data by giving each bearer (mapped to a
logical channel) a priority, where increasing priority values indicate lower priority
levels) and a Prioritized Bit Rate (PBR).
Let PBRj be the PBR associated to logical channel j.
The UE maintains a variable B for each logical channel. Let Bj be this variable for
logical channel j. Bj is initialized to zero (i.e. it set to 0 upon creation).
Page 270/472
Furthermore, each logical channel is associated with a Bucket Size Duration (BSD).
Let BSDj be the BSD associated to logical channel j. The bucket size of logical
channel j is equal to PBRj × BSDj.
Note that Bj cannot exceed the bucket size. It is incremented by (PBRj ×TTI duration)
for each TTI but if [Bj + (PBRj ×TTI duration)] exceeds the bucket size, Bj is set to the
bucket size).
When a new uplink transmission is performed (using the resources that the UE has
been allocated by the scheduler), the UE allocates resources to the logical channels
in the following steps:
• Step 1: All the logical channels with Bj > 0 are allocated resources in a
decreasing priority order. If the PBR of some bearer is set to “infinity”, the UE
allocates resources for all the data available for transmission on this bearer,
before moving on to the lower priority radio bearer.
• Step 2: The UE decrements Bj by the total size of MAC SDUs served to
logical channel j in Step 1.
• Step 3: If any resources remain after Steps 1 and 2, all the logical channels
are served in a strict decreasing priority order (regardless of the value of Bj)
until there are no more data to transmit or the uplink grant is exhausted. Note
that logical channels with equal priority are served equally.
Note that Bj can be negative.
The priority of a given type of bearer is configured by parameter

SignalingRadioBearerConf::logicalChannelPriorityUL for signaling radio bearers
and by parameter TrafficRadioBearerConf::logicalChannelPriorityUL for data
radio bearers. One value is signaled per bearer type.
The Prioritized Bit Rate (PBR) of a given type of bearer is configured by parameter
SignalingRadioBearerConf::logicalChannelPrioritizedBitRateUL for signaling
radio bearers and by parameter
TrafficRadioBearerConf::logicalChannelPrioritizedBitRateUL for data radio
bearers. One value is signaled per bearer type.
The Bucket Size Duration (BSD) of a given type of bearer is configured by parameter
SignalingRadioBearerConf::logicalChannelbucketSizeDurationUL for signaling
radio bearers and by parameter
TrafficRadioBearerConf::logicalChannelbucketSizeDurationUL for data radio
bearers. One value is signaled per bearer type.
Page 271/472
SignalingRadioBearerConf::logicalChannelPriorityUL
Parameter logicalChannelPriorityUL
[1..16]
Feature FRS 76501
TrafficRadioBearerConf::logicalChannelPriorityUL
Parameter logicalChannelPriorityUL
[1..16]
SignalingRadioBearerConf::logicalChannelPrioritizedBitRateUL
Parameter logicalChannelPrioritizedBitRateUL
{ kBps0, kBps8, kBps16, kBps32, kBps64, kBps128, kBps256,
infinity}
Feature FRS 76501
Page 272/472
TrafficRadioBearerConf::logicalChannelPrioritizedBitRateUL
Parameter logicalChannelPrioritizedBitRateUL
{ kBps0, kBps8, kBps16, kBps32, kBps64, kBps128, kBps256,
infinity}
Feature FRS 76501
With the following mapping between parameter values and the actual bit rates (only
the first three values are shown, the same holds for other values).
logicalChannelPrioritizedBitRateUL Actual bit rate
kBps0(0) 0
kBps8(1) 8 Kilo Bytes per second
kBps16(2) 16 Kilo Bytes per second
SignalingRadioBearerConf::logicalChannelbucketSizeDurationUL
Parameter logicalChannelbucketSizeDurationUL
{ms50, ms100, ms150, ms300, ms500, ms1000}
Page 273/472
TrafficRadioBearerConf::logicalChannelbucketSizeDurationUL
Parameter logicalChannelbucketSizeDurationUL
{ms50, ms100, ms150, ms300, ms500, ms1000}
With the following mapping between parameter values and the actual bit rates (only
the first three values are shown, the same holds for other values).
logicalChannelbucketSizeDurationUL Actual bit rate
ms50 50 ms
ms100 100 ms
ms150 150 ms
Page 274/472
Engineering Recommendation: Parameters logicalChannelPriorityUL,

logicalChannelbucketSizeDurationUL and
logicalChannelPrioritizedBitRateUL setting
An instance of object RadioBearerConf is generated for each type of bearer. The

type of bearer is defined by parameter LabelID. Parameters
logicalChannelPriority, bucketSizeDuration and
logicalChannelPrioritizedBitRate are set for each instance (bearer), according
to the priority of the bearer in question (i.e. the priority of the logical channel the
bearer in question is mapped onto).
For signaling radio bearers (i.e. SRB1 and SRB2), an instance of object
SignalingRadioBearerConf is generated for SRB1 and another one is generated
for SRB2. The SRB type is defined by parameter
SignalingRadioBearerConf::sRBIdentity. Parameters
SignalingRadioBearerConf::logicalChannelPriorityUL,
SignalingRadioBearerConf::logicalChannelbucketSizeDurationUL and
SignalingRadioBearerConf::logicalChannelPrioritizedBitRateUL are set for
each instance (i.e. for each SRB), according to the priority of the bearer in
question (i.e. the priority of the logical channel the bearer in question is mapped
onto). The current default setting is the following:
sRBIdentity logicalChannelPrio logicalChannelPrioritizedBitRate logicalChannelbuc

rityUL UL ketSizeDurationUL
1 1 infinity ms50
2 2 infinity ms50
For data radio bearers, an instance of object TrafficRadioBearerConf is

generated for each QCI, identified by parameter TrafficRadioBearerConf::qCI.
Parameters TrafficRadioBearerConf::logicalChannelPriorityUL,
TrafficRadioBearerConf::logicalChannelbucketSizeDurationUL and
TrafficRadioBearerConf::logicalChannelPrioritizedBitRateUL are set for each
instance (i.e. for each QCI), according to the priority of the bearer in question (i.e.
the priority of the logical channel the bearer in question is mapped onto).
The current default setting is the following:
qCI logicalChannelPriorityUL logicalChannelPrioritizedBitRateUL logicalChannelbuc

ketSizeDurationUL
1 4 infinity ms50
2 6 infinity ms50
3 5 infinity ms50
4 7 infinity ms50
5 3 kBps8 ms50
Page 275/472
6 8 kBps8 ms50
7 9 kBps8 ms50
8 10 kBps8 ms50
9 11 kBps8 ms50
Page 276/472
5 CONGESTION, RADIO ADMISSION CONTROL

AND ENB CAPACITY
5.1 CONGESTION AND RADIO ADMISSION CONTROL
This section describes the parameters used for Congestion and Radio Call
Admission Control (Radio CAC).
Radio CAC is responsible for:
 Deciding whether to admit or reject requests for new entrant bearers or
modification of established bearers.
 Ensuring efficient use of radio resources by accepting radio bearer requests
as long as configurable limits are not exceeded and sufficient radio
resources are available. Radio resources are expressed in terms of physical
resource blocks (PRBs) managed by the UL and DL schedulers.
 Minimize the impact on the QoS of established bearers, with preference
given to higher priority bearers over lower priority bearers when the cell is in
congestion.
There are different types of Call Admission Control, such as Transport CAC
(described in [R01]) and Radio CAC. Only Radio CAC is covered in this document.
Radio CAC admits or rejects:

• Establishment of SRBs for new incoming calls.
• Establishment of new incoming VoIP, GBR, and non-GBR Data Radio

Bearers (DRBs).
• Modification of established eRABs.
• Establishment of bearers in handover that were previously established in the

source cell before handover.
• Establishment of bearers in RRC Connection Re-establishment that were
previously established before radio link failure.
• Establishment of bearers required for CS Fallback (CSFB).
Radio CAC gives special consideration to the admission of emergency calls. Two
types of emergency calls are supported:
• IMS VoIP EC: emergency services provided on LTE.
• Emergency CSFB: requires the UE to change to another RAT to obtain
emergency services.
Radio CAC distinguishes an incoming call as IMS VoIP EC if all of the following are
true:
Page 277/472
1. IMS VoIP EC is enabled by setting parameter isIMSEmergencyCallAllowed

to ‘true’.
2. Establishment Cause of the RRC Connection Request is set to ‘emergency’,
or the ARP priority of at least one E-RAB is set to the value in parameter
PlmnIdentity::arpPriorityEmergency for the plmn-identity associated with
this UE.
3. There is no CSFB indicator during the RRC connection setup phase, or
CSFB is disabled (refer to Volume 6 for details).
Radio CAC distinguishes an incoming call as Emergency CSFB if all of the following
are true:
1. CSFB is enabled (refer to Volume 6 for details).
2. The CSFB Indicator IE is present and set in the incoming request.
3. Establishment Cause of the RRC Connection Request is set to ‘emergency’-
OR - the ARP priority of at least one E-RAB is set to the value in parameter
PlmnIdentity::arpPriorityEmergency for the plmn-identity associated with
this UE and feature IMS VoIP EC is also enabled.
ActivationService::isIMSEmergencyCallAllowed
Parameter isIMSEmergencyCallAllowed
True/False
PlmnIdentity::arpPriorityEmergency
Parameter arpPriorityEmergency
[1..15]
Value Default: 1
Page 278/472
In LR13.3, Radio CAC also gives special attention to High Priority Access calls,
which may be initiated by HPA UEs. HPA users will typically have special subscriber
authorization for purposes such as Public Safety or goverment, for example. The
recognition of High Priority Access is enabled in the eNB when flag
isHighPriorityAccessUserMgmtEnabled is set to True. A High Priority Access call is
identified by the eNB as:
1. Establishment Cause of the RRC Connection Request is set to
‘highPriorityAccess’.
2. ARP priority value (from S1AP message) of the E-RAB is equal to or less
than parameter arpPriorityHighPriorityAccess.
CAC and Transport-CAC treatment for HPA calls is the same as the treatment given
for Emergency Calls.
ActivationService::isHighPriorityAccessUserMgmtEnabled
Parameter isHighPriorityAccessUserMgmtEnabled
True/False
Feature L115860
Feature L115860 is a licensed feature.
PlmnIdentity::arpPriorityHighPriorityAccess
Parameter arpPriorityHighPriorityAccess
[1..15]
Value Default: 2
Feature L115860
Rule: Parameters arpPriorityEmergency and arpPriorityHighPriorityAccess
If arpPriorityEmergency ≤ arpPriorityHighPriorityAccess, a bearer with ARP

priority level = arpPriorityEmergency will be processed as an Emergency Call,
and not an HPA call.
In LR13.3, counters defined for bearer classification based on ARP priority classes
are used to monitor the number of HPA bearers. Feature 163172 defines 4 classes
Page 279/472
of ARP priority (refer to section 7.1.2.1 for configuration of 4 level ARP priority
classes). If 163172 is not activated, then 2 classes of ARP priority are defined. The
specific counter used for monitoring the number of bearers in the HPA ARP range
depends on parameter configuration and activation of CAC features, as shown in
Table 21.
Counter
providing the
PARAMETER SETTINGS
number of HPA
bearers
isFourLevelPrbCacEnabled arpPriorityHighPriorityAccess = 13801-4

= false lowArpPriority - 1
(feature 163172 is not
activated)
Top priority ARP class is configured 13801-6
AND
arpPriorityHighPriorityAccess
= highArpProrityStart - 1
isFourLevelPrbCacEnabled No Top priority class is configured, but High and 13801-4

= true Medium priority ARP classes are configured
(feature 163172 is activated) AND
arpPriorityHighPriorityAccess =
mediumArpPriorityStart - 1
Only Medium and Low priority ARP classes are 13801-5

configured
AND
arpPriorityHighPriorityAccess
= lowArpPriorityStart - 1
Table 21: Counters for monitoring number of HPA bearers
In LR13, the following Radio CAC criteria are checked:
• Number of connected users (per eNB, per cell, per PLMN per cell).
• Number of active users (per eNB, per cell).
• Number of established data bearers (per eNB, per cell, per PLMN per cell,
per QCI group per cell, per PLMN per QCI group per cell, VoIP per cell)
• Transport bandwidth (described in [R01])
• PRB consumption (per cell, per PLMN per cell)
Page 280/472
The CAC criteria which are checked in LR13 depend on the type of incoming
request, as summarized in the table below:
Number of Number of Number of PRB Transport

Criteria
active connected established consumption bandwidth
users (per users (per data (per cell, per (see [R01])
Trigger
eNB, per cell, per bearers (per PLMN per
cell) PLMN per cell, per cell, per
cell) PLMN per band)
cell)
RRC connection √ √ √
request
RRC connection setup √ √
complete
Handover request √ √ √ √ √
(inter-eNB)
Handover request √ √ √ √
(intra-eNB inter-cell)
RRC connection re- √ √ √ √

establishment in non-
serving cell
Initial UE context setup √ √

or eRAB setup
eRAB modify with √ √

higher GBR
eRAB modify with new √ √

QCI
Incoming IMS VoIP √

Emergency call or
Emergency CSFB call
or HPA call
OOT to active √
transitions triggered by
UL/DL Data, SRB1
signaling, Measurement
report for ANR or
entering Coverage
Alarm, S1AP E-RAB
Setup/Modify, S1AP UE
Context Modification
Page 281/472
If the active UEs per eNB capacity limit is reached, the eNB rejects the incoming
request (RRC Connection Request or X2/S1 HO Request) or release the UE in case
of TRB traffic while in OOT state.
If active UEs per eNB CAC fails as a result of SRB1 signalling or an S1AP Request
in OOT state, the CAC result is bypassed and the UE is kept in OOT state.
Enhanced eUTRAN sharing enables the eNB to additionally perform admission

control on a per PLMN per cell basis when a cell is shared by multiple operators.
Refer to Volume 5 for an overview of eUTRAN sharing. Per PLMN admission criteria
are checked when more than one PLMN is broadcast in SIB1 in the cell. The
resources which are checked per PLMN for admission control fall under the 3 Radio
CAC criteria (number of connected users, number of established data bearers, and
PRB consumption). The data parameters used to configure PLMN admission control
are associated with object RadioCacCellPerPlmn and are described in the sub-
sections corresponding to their respective criteria type. Parameter
RadioCacCellPerPlmn::plmnId identifies the instance of the PlmnIdentity object
that defines MCC and MNC of the concerned PLMN. See Volume 5 for additional
discussion of PlmnIdentity.
ReactiveLoadControlActionForBearerAdmission::plmnId
Parameter plmnId
ENBEquipment/Enb/DedicatedConf/TrafficRadioBearerConf/
Object
ReactiveLoadControlActionForBearerAdmission
Range & Unit Service Link
Points to corresponding instance of the PlmnIdentity object
Value O.D.
Feature FRS 115242
Activation of PRB licensing requires that Dual-Carrier is disabled. If Dual-Carrier is

activated with isDualCarrierEnabled = true, then CAC for PRB consumption per
band cannot be applied.
Congestion control may be invoked when CAC limits are exceeded or to prevent
congestion before it is detected. When invoked, congestion control may initiate the
offloading of lower priority UEs to neighboring inter-frequency eNBs or the release of
lower priority bearers in order to maintain the QoS of higher priority bearers in the
cell and to achieve load balancing with neighboring eNBs. Radio CAC will invoke
eMCTA to perform offloading of UEs (described in Volume 6). There are two types of
congestion control supported:
1. Reactive Load Control: initiated when congestion is detected during radio
admission control of a new request. This procedure attempts to offload UEs or
release radio bearers in order to free enough resources to admit a higher priority
request.
Page 282/472
2. Preventive Load Control: initiated before congestion is reached during radio

admission control of a new request or upon reception of a modem report. This
procedure attempts to offload lower priority UEs to avoid reaching congestion
and to achieve load balancing of calls between eNBs.
Figure 20 is an overview of Radio CAC and Congestion Control supported in LA6.0.
Incoming user/E-RAB or Modem report or SRB/

updated E-RAB TRB admission
Check on CAC criteria:

Update CAC context
• Number of user
• Number of context
• Transport bandwidth
• Number of data bearer Check on CAC criteria:
• PRB consumption • PRB consumption
N N
Accept Congestion? Load balancing? No action
Y Y
Reactive load control:

Preventive load control:
• Select candidate E-RABs;
• Select candidate UEs;
• Select candidate UEs;
N N
Reject Enough candidate? Candidate found? No action
(except # of user per cell)
Y Y
Accept the request immediately;
Release candidate E-RABs; Move candidate UEs by eMCTA;
Offload/release candidate UEs (if
offload fails the bearers are
released)
Figure 18: Radio CAC Overview
The following table summarizes admission checks which may trigger reactive load
control when a congestion (C) threshold is reached, or trigger preventive load control
when a load balancing (LB) threshold is reached.
Per Cell
Per Cell Per Band Per eNB
per PLMN
Number of connected
C - C C
users
Number of active users LB -
Number of bearers C - C C
Number of bearers in
C - - C
QCI group i
Number of VoIP
C - - -
bearers
UL PRB C, LB C, LB - C
DL PRB C, LB C, LB - C
Downlink throughput LB - - -
Page 283/472
for non-GBR bearer
Table 22: Summary of call admission checks which detect Congestion or Load
Balancing thresholds.
5.1.1 NUMBER OF CONNECTED (ACTIVE) USERS

5.1.1.1 PER ENB
In LR13.3 the following parameters are used to determine the criteria for the number
of users per eNB admitted.
• Parameter maxNumberOfCallPerEnodeB specifies the maximum number
of active users per eNB (active users is a subset of the RRC connected
users). The connected inactive users are not taken into account for this
check. Note this parameter was already used before LR13.3 with a different
meaning (maximum number of connected users per eNB).
• Parameter nbrOfContextsReservedForEcAndHpaCalls specifies the
number of UE contexts per eNB reserved for emergency and High Priority
calls.
• Parameter maxNbrOfRRCConnectedUsersPerEnb specifies the maximum
number of RRC connections the eNB can support.
• an additional 2% of CCM capacity is reserved (both eCCM and eCCM2), on
top of the committed capacity, for EC/HPA calls.
This means that non EC/HPA calls will start being blocked at
MaxNbOfRrcConnectedUsersPerEnb – nbrOfContextsReservedForEcAndHpaCalls,
whilst EC/HPA calls will only be blocked at MaxNbrOfRrcConnectedUsersPerEnb +
2% of committed CCM capacity.
nbrOfContextsReserv
MaxNbrOfRrcConnectedUsersPerEnb edForEcAndHpaCalls
2% of
committed
capacity
Non EC/HPA calls are blocked at this point

Reactive offload upon arrival of EC/HPA calls is triggered
at this point
EC/HPA calls are blocked at this point
Reactive offload (if activated), is triggered on arrival of EC/HPA calls when reaching
MaxNbOfRrcConnectedUsersPerEnb – nbrOfContextsReservedForEcAndHpaCalls
Page 284/472
RadioCacEnb::maxNumberOfCallPerEnodeB
Parameter maxNumberOfCallPerEnodeB
Object ENBEquipment/Enb/RrmServices/RadioCacEnb
[0..6000]
Feature FRS 92633, FRS 92038, FRS 166802
RadioCacEnb::maxNbrOfRRCConnectedUsersPerEnb
Parameter maxNbrOfRRCConnectedUsersPerEnb
[0..7200]
Feature FRS 166802
RadioCacEnb::nbrOfContextsReservedForEcAndHpaCalls
Parameter nbrOfContextsReservedForEcAndHpaCalls
[0..180]
Value 0 (Default)
5.1.1.2 PER CELL
The following parameters are used to determine the criteria for the number of users
per cell admitted. If the limits of these parameters below are exceeded, and the
incoming request is not IMS VoIP EC or CSFB EC or HPA call, then Radio CAC will
reject the incoming request:
• Parameter maxNbrOfUsers specifies the maximum number of connected

users that can be admitted on the cell.
Page 285/472
• Parameter nbOfContextsReservedForEcAndHpaCalls specifies the

number of UE contexts reserved for emergency calls and HPA calls.
Emergency calls may be either IMS VoIP EC or Emergency CSFB.
Therefore:
maximum number of non-emergency calls that can be admitted per cell =
maxNbrOfUsers - nbOfContextsReservedForEmergencyCalls
maxNbrOfUsers
Reserved
Reserved number of users (non-emergency + emergency call EC)
number
for EC
For the case of IMS VoIP EC or CSFB EC or HPA call, if maxNbrOfUsers is

exceeded, the call will be rejected.
In the modem, there is typically one context for each user in a cell. However, during
intra-cell RRC reestablishment and intra-cell handover, two contexts are temporarily
used for one user. Extra contexts are reserved in the modem to accommodate these
two procedures for call admission. The number of extra contexts is equal to
ceiling(maxNbrOfUsers × 0.05; 1) in LR13.1 (some can be used by Emergency
Calls).
Therefore, for the case of intra-cell RRC reestablishment and intra-cell handover:
maximum number of non-emergency/HPA calls that can be admitted per cell =
maxNbrOfUsers - nbOfContextsReservedForEcAndHpaCalls + ceiling(maxNbrOfUsers × 0.04; 1).
The request is rejected if this check fails.
For the case of IMS VoIP EC or CSFB EC or HPA call, if

maxNumberOfCallPerEnodeB or MaxNbOfRrcConnectedUsersPerEnb minus
nbrOfContextsReservedForEcAndHpaCalls or maxNbrOfUsers minus
nbOfContextsReservedForEcAndHpaCalls are exceeded, then reactive load
control may be triggered to manage congestion and to improve the chance of
admitting the EC/HPA call. If reactive load control is not enabled or no other UE may
be pre-empted, then the EC/HPA call will be admitted only if there are contexts
reserved for emergency calls available at eNB level (including the 2% margin
defined) and at cell level.
Page 286/472
RadioCacCell::maxNbrOfUsers
Parameter maxNbrOfUsers
Object ENBEquipment/Enb/LteCell/RadioCacCell
[0..1000]
Parameter maxNbrOfActiveUsersPerCell specifies the maximum number of active

users that is allowed in a cell (see 5.1.5).
RadioCacCell::maxNbrOfActiveUsersPerCell
Parameter maxNbrOfActiveUsersPerCell
[0..800]
Feature 166802
Page 287/472
Engineering Recommendation: Regarding parameters maxNbrOfUsers,

maxNbrOfActiveUsersPerCell, maxNumberOfCallPerEnodeB and
maxNbrOfRRCConnectedUsersPerEnb

- With eCEM:
dlBandwidth maxNbrOfUsers maxNumberOfCallPerEnodeB
n6-1.4MHz 48 144
n15-3MHz 100 300
n25-5MHz 167 501
n50-10MHz 200 600
n100-20MHz 54 162
- With bCEM:
dlBandwidth maxNbrOfUsers maxNumberOfCallPerEnodeB
n25-5MHz 250 750
n50-10MHz 400 1200
n75-15MHz 400 1200
n100-20MHz 400 1200
- With Metro Cell (1W 5MHz, 5W 10MHz):

• maxNbrOfUsers = 64
• maxNumberOfCallPerEnodeB = 64
In LR13.3, the setting (with bCEM and feature 166802) becomes:
maxNbrOfUsers maxNbrOfActive maxNbrOfRRCConne maxNumberOfCallPerE

dlBandwidth
UsersPerCell ctedUsersPerEnb nodeB
n6-1.4MHz 100 48 300 144
n15-3MHz 240 120 720 360
n25-5MHz 625 250 1800* 750
n50-10MHz 800 400 1800* 1200
n75-15MHz 800 400 1800* 1200
n100-20MHz 800 400 1800* 1200
(*) with eCCME2. With eCCM, it is 750 (5MHz) and 1200 (for 10MHz and beyond).
Page 288/472
RadioCacCell::nbOfContextsReservedForEcAndHpaCalls
Parameter nbOfContextsReservedForEcAndHpaCalls
[0..20]
Page 289/472

nbOfContextsReservedForEcAndHpaCalls
This parameter imposes an additional limit on the number of non-emergency/HPA

users that can be connected simultaneously in the cell. High settings will reserve
many contexts for emergency/HPA users but will leave fewer contexts for non-
emergency/HPA calls. If set to a too high value, contexts will be wasted given that
the average number of emergency/HPA calls is generally low. Fewer contexts
should be reserved for emergency/HPA calls if Reactive Load Control is enabled
because lower priority users may be released or offloaded from the eNB, thus
potentially freeing up additional contexts (see section 5.1.4).
The setting of this parameter should be as follows:
isCsFallbackToU isReactiveLoad nbOfContextsReservedForEcAndHpaCalls

traAllowed, ControlAllowed
isCsFallbackToG (refer to section
eranAllowed, 5.1.4)
isCsfbTo1xRttFo
rDRxUEallowed,
isRel8CsfbTo1xR
ttEnabled
isIMSEmergency
CallAllowed
All are set to not applicable 0

“False”
At least one is set False max(1, 0.02 × maxNbrOfUsers)

to ”True”
At least one is set True max(1, 0.01 × maxNbrOfUsers)

to “True”
A WPS warning will result if nbOfContextsReservedForEcAndHpaCalls is set to

0 and CSFB or IMS VoIP EC is enabled (i.e. isCSFallbackToUtraAllowed is
‘True’ and/or isCSFallbackToGeranAllowed and/or
isCsfbTo1xRttForDRxUEallowed and/or isIMSEmergencyCallAllowed is
‘True’).
See [Vol. 6] for the description of CSFB parameters.
nbOfContextsReservedForEcAndHpaCalls is defaulted to 0 in ALU templates.
5.1.1.3 PER PLMN PER CELL
If eUTRAN sharing is enabled in a cell (there are more than one PLMN broadcast in
the SIB1 in the cell), reserved number of users are also defined per PLMN per cell by
parameter RadioCacCellPerPlmn::reservedNbrOfUsers. The figure below shows
an example of how number of users are allocated for eUTRAN sharing (with 3
PLMNs).
Page 290/472
maxNbrOfUsers
Number of
reservedNbr reservedNbr Reserved
reservedNbrOfUsers users shared
OfUsers OfUsers for number
for PLMN 1 by all PLMNs
for PLMN 2 PLMN 3 for EC
(shared pool)
The maximum number of non-emergency calls that can be admitted for a specific
PLMN in the cell is calculated as:
maximum number of non-emergency calls that can be admitted per PLMN per cell =
reservedNbrOfUsers(this PLMN) + Number_of_users_shared_by_all_PLMNs –
Consumption_in_Shared_Pool(by other PLMNs)
where:
Number_of_users_shared_by_all_PLMNs =
maxNbrOfUsers - ∑reservedNumberOfUsers(all_PLMNs) – nbOfContextsReservedForEcAndHpaCalls
If this per PLMN per cell limit is exceeded, and the incoming request is not IMS VoIP
EC or CSFB EC, then Radio CAC will reject the incoming request.
For the case of IMS VoIP EC or CSFB EC, if the above limit (specified for non-
emergency calls) is exceeded, then reactive load control may be triggered to
manage congestion and to improve the chance of admitting the EC call. If reactive
load control is not enabled or no other UE may be pre-empted, then the EC call will
be admitted only if there are contexts reserved for emergency calls available.
RadioCacCellPerPlmn::reservedNbrOfUsers
Parameter reservedNbrOfUsers
ENBEquipment/Enb/LteCell/RadioCacCell/RadioCacCellPerPlm
Object
n
[0..1000]
Value 0 (default)
Feature FRS 115242
Page 291/472
Rule: Parameter reservedNbrOfUsers
The setting of this parameter must satisfy the following condition:

The sum of all instances of RadioCacCellPerPlmn::reservedNbrOfUsers +
nbOfContextsReservedForEcAndHpaCalls must not exceed maxNbrOfUsers.
Engineering Recommendation: Parameter reservedNbrOfUsers
This parameter should be set to a meaningful value if more than one PLMN is
defined in the eNB. However, if there is only one PLMN defined, then this
parameter value is ignored by the eNB.
5.1.2 NUMBER OF ESTABLISHED DATA BEARERS

5.1.2.1 PRIORITY CLASSES
For each data bearer there is ARP Priority Level whose valid range is from 1 to 15, in
which 1 is the highest priority and 14 the lowest priority, and 15 means “no priority”.
Bearers with ARP = 15 cannot trigger reactive load control. ARP = 15 is treated as
the lowest priority in the ALU implementation.
Parameter lowArpPriorityStart is used to divide ARP Priority Levels into two
ranges: from 1 to lowArpPriorityStart minus 1 (high priority bearer) and from
lowArpPriorityStart to 15 (low priority bearer). Setting lowArpPriorityStart to “1”
means that all ARP values are considered as low priority and there is no high priority
ARP value.
LR13.3 feature 163172 expands the ARP Priority Levels up to four priority classes
(top, high, medium, low), by setting isFourLevelPrbCacEnabled = true and the new
parameters mediumArpPriorityStart and/or highArpPriorityStart. In such context,
separate pairs of UL/DL thresholds for 4 different ARP priority classes are defined,
where a priority class is defined as a range of ARPs and the PRB threshold is the
maximum percentage of PRBs consumed. Those thresholds per ARP priority class
are used at new call or bearer admission. A separate UL/DL threshold pair is used
for call re-establishment and incoming mobility.
Parameters RadioCacCell::dlAdmissionThresholdOnPrb and
RadioCacCell::ulAdmissionThresholdOnPrb configure the percentage of the total
resource count, which is not be exceeded, for the acceptance of a low priority
request in the downlink and uplink, respectively. Reactive load control may also be
triggered if those thresholds are exceeded. Reactive Load Control is described in
section 5.1.4.
Parameters RadioCacCell::deltaAdmissionThresholdOnPrbForHighPrioReq,
RadioCacCell::deltaAdmissionThresholdOnPrbForMediumPrioReq and
RadioCacCell::deltaAdmissionThresholdOnPrbForTopPrioReq configures the
Page 292/472
additional percentage for the acceptance of a high priority request in the downlink
and uplink, respectively.
Parameter RadioCacCell::deltaAdmissionThresholdOnPrbForExisting specifies
the additional percentage threshold for admission of incoming intra-LTE mobility and
RRC Re-establishment in the downlink and uplink (only used if 4-level PRB CAC is
enabled).
Expanding on the existing delta the percentage added to the absolute threshold
(dl/ulAdmissionThresholdOnPrb percentage threshold on PRB consumption for
low priority new user admission request):
• dl/ulAdmissionThresholdOnPrb +
deltaAdmissionThresholdOnPrbForMediumPrioReq percentage threshold on
PRB consumption for medium priority new user admission request.
deltaAdmissionThresholdOnPrbForHighPrioReq percentage threshold on PRB
consumption for high priority new user admission request.
deltaAdmissionThresholdOnPrbForTopPrioReq percentage threshold on PRB
consumption for top priority new user admission request.
deltaAdmissionThresholdOnPrbForExisting percentage threshold on PRB
consumption for incoming intra-LTE mobility and RRC Re-establishment.
Note that in the case of handover and RRC re-establishment, all bearers are
considered high priority bearers regardless of their ARP priority level.
Incoming data bearers are checked from highest to lowest priority to ensure the
higher priority bearers are admitted in case of partial admission.
The following pictures provide an example of pre-existing (L114539) priority class
configuration and an example of priority class configuration when 163172 is enabled.
lowArpPriorityStart = 1 15
One Priority Class
ARP priority classes: low
1 lowArpPriorityStart-1 lowArpPriorityStart
15
Two Priority Classes
ARP priority classes: high low

Page 293/472
Examples of pre-existing (L114539) priority class configuration
New parameters in red

mediumArpPriorityStart=unset if not shown
highArpPriorityStart = 1 lowArpPriorityStart-1 lowArpPriorityStart

15
Two priority classes
ARP priority class: high low
1 highArpPriorityStart lowArpPriorityStart 15
Three priority classes
ARP priority class: top high low
highArpPriorityStart mediumArpPriorityStart lowArpPriorityStart

1 15
Four priority classes
ARP priority class: top high medium low
Examples of priority class configuration when 163172 is enabled
ActivationService::isFourLevelPrbCacEnabled
Parameter isFourLevelPrbCacEnabled
True/False
Feature FRS 163172
Notes: This parameter enables or disables ability to specify up to four ARP priority
classes for call admission.
Page 294/472
RadioCacEnb::lowArpPriorityStart
Parameter lowArpPriorityStart
[1..15]
Value 1 (meaning top, high, and medium priority classes are empty)
Feature FRS 114539
Notes: This parameter specifies the start of range of low ARP priority level. The
range [1..lowArpPriorityStart-1] is the medium/high/top priority levels, and the
range [lowArpPriorityStart..15] is the low priority level. lowArpPriorityStart=1
means all 1-15 are low priority and there are no medium/high/top priority ARPs.
RadioCacEnb:: mediumArpPriorityStart
Parameter mediumArpPriorityStart
[1..15]
Value 1 (medium priority class is empty)
Feature FRS 163172
Notes: This parameter specifies the start of range of the medium ARP priority level.
The range [1..mediumArpPriorityStart-1] is the high and top priority levels, and the
range [mediumArpPriorityStart..lowArpPriorityStart-1] is the medium priority
level. mediumArpPriorityStart = 1 means there are no high and top priority ARPs.
mediumArpPriorityStart = unset or mediumArpPriorityStart =
lowArpPriorityStart means there are no medium priority ARPs, in which case the
range [1..lowArpPriorityStart-1] is high and top priority levels.
RadioCacEnb:: highArpPriorityStart
Parameter highArpPriorityStart
[1..15]
Value 1 (top priority class is empty)
Feature FRS 163172
Notes: This parameter specifies the start of range of the high ARP priority level. The
range [1..highArpPriorityStart-1] is the top priority level, and the range
Page 295/472
[highArpPriorityStart..mediumArpPriorityStart-1] (or
highArpPriorityStart..lowArpPriorityStart-1] if mediumArpPriorityStart is unset)
is the high priority level. highArpPriorityStart = 1 means there are no top priority
ARPs. highArpPriorityStart = mediumArpPriorityStart (or highArpPriorityStart =
lowArpPriorityStart if mediumArpPriorityStart is unset) means there are no high
priority ARPs.
RadioCacCell::dlAdmissionThresholdOnPrb
Parameter dlAdmissionThresholdOnPrb
[0..100] %
Notes: This parameter specifies the DL percentage threshold on PRB consumption
for the admission of a low priority request. Reactive load control may be triggered if it
is exceeded.
RadioCacCell::ulAdmissionThresholdOnPrb
Parameter ulAdmissionThresholdOnPrb
[0..100] %
Notes: This parameter specifies the UL percentage threshold on PRB consumption
for the admission of a low priority request. Reactive load control may be triggered if it
is exceeded.
Page 296/472
RadioCacCell::deltaAdmissionThresholdOnPrbForHighPrioReq
Parameter deltaAdmissionThresholdOnPrbForHighPrioReq
[0..100] %
Feature FRS 92091, FRS114539
Notes: This parameter specifies an additional threshold to be used, on PRB
consumption, for admission of a high priority bearer. It is a delta percentage added to
the absolute threshold (dl/ulAdmissionThresholdOnPrb). A value of 0 means high
priority bearers are treated the same as low priority bearers.
RadioCacCell::deltaAdmissionThresholdOnPrbForMediumPrioReq
Parameter deltaAdmissionThresholdOnPrbForMediumPrioReq
[0..100] %
0 The value of the parameter should only be modified by
Value
Feature FRS 163172
consumption, for admission of a medium priority bearer. It is a delta percentage
added to the absolute threshold (dl/ulAdmissionThresholdOnPrb). A value of 0
means medium priority bearers are treated the same as low priority bearers.
RadioCacCell::deltaAdmissionThresholdOnPrbForTopPrioReq
Parameter deltaAdmissionThresholdOnPrbForTopPrioReq
[0..100] %
Value
Feature FRS 163172
consumption, for admission of a Top priority bearer. It is a delta percentage added to
Page 297/472
the absolute threshold (dl/ulAdmissionThresholdOnPrb). A value of 0 means top

priority bearers are treated the same as low priority bearers.
RadioCacCell::deltaAdmissionThresholdOnPrbForExisting
Parameter deltaAdmissionThresholdOnPrbForExisting
[0..100] %
Value
Feature FRS 163172
consumption, for admission of incoming intra-LTE mobility and RRC Re-
establishment. It is a delta percentage added to the absolute threshold
(dl/ulAdmissionThresholdOnPrb). A value of 0 means incoming handoffs and re-
establishments are treated the same as low priority bearers.
Rule: Parameter deltaAdmissionThresholdXXXX
The setting of different admission thresholds parameters must satisfy the

following condition:
dlAdmissionThresholdOnPrb + deltaAdmissionThresholdXXXX ≤ 100
ulAdmissionThresholdOnPrb + deltaAdmissionThresholdXXXX ≤ 100
5.1.2.2 PER CELL
If the limits of the parameters below are exceeded, then Radio CAC will reject the
incoming data bearer:
• Parameter maxNbOfDataBearersPerCell represents the maximum number
of established data bearers per cell.
• For a VoIP bearer, the DL VoIP GBR (received on the S1-C interface) cannot
be larger than maxGBRforVoIPserviceDl and/or the UL VoIP GBR cannot
be larger than maxGBRforVoIPserviceUl. However, if bit3 of Enb::spare15
(isVoIPGBRCapIncreaseEnabled – PM172164) is set to True, CAC criteria
ruled by maxGBRforVoIPserviceDl/Ul (max value = 65,536 Kbps) is
ignored. At context setup or RAB setup, if the bearer is QCI1 with GBR ≥ bit3
Page 298/472
of Enb::spare15 bits4-5 (voipGbrThresholdRoHCSpsActivation) then

Callp also deactivates ROHC for this bearer and deactivates SPS for QCI1
bearers. Feature PM172164 is only supported on bCEM modem and can be
also used to support a RAN-based solution for VoLTE call hold and 3 way
calling where the PCRF increases the QCI1 bearer rate by 2x or 3x due to
the additional call legs.
• Parameter maxNbOfDataBearersPerUe represents the maximum number
of established data bearers per UE.
If the limits of the parameters below are exceeded, then reactive load control may be
attempted to manage congestion:
• Parameter maxNbOfDataBearersPerEnodeB specifies the maximum
number of established data bearers per eNB.
• Parameter maxNbrOfDataBearersPerQciGroup specifies the maximum
number of established data bearers that are allowed for each QCI group in a
cell.
• Parameter maxNbrOfVoIP specifies the maximum number of established
VoIP data bearers per cell.
• Parameter admissionThresholdOnNbrOfDBs specifies the number of data
bearers (per cell) reserved for low priority data bearers.
• Parameter deltaAdmissionThresholdOnNbrOfDBsForHighPrioReq
specifies the number of data bearers (per cell) reserved for high priority data
bearers. Therefore:
maximum number of high priority data bearers that can be admitted per cell =
admissionThresholdOnNbrOfDBs + deltaAdmissionThresholdOnNbrOfDBsForHighPrioReq
Max number of Data Bearers (maxNbOfDataBearersPerCell)
Threshold for high priority bearer

(admissionThresholdOnNbrOfDBs+deltaAdmissionThresholdOnNbrOfDBsForHighPrioReq)
Threshold for low priority bearer (admissionThresholdOnNbrOfDBs)
number for
Number for both high&low priority bearer high priority Margin
bearer
Reactive load control, if enabled and if the incoming RB can preempt (see section
5.1.4), may be attempted under the following conditions:
• If the probable admission of the new bearer would make the total number of
established data bearers in the cell exceed
maxNumberOfDataBearersPerEnodeB.
• If the new bearer is a high priority data bearer and its probable admission
would make the total number of established data bearers in the cell exceeds
Page 299/472
the sum of admissionThresholdOnNbrOfDBs +

deltaAdmissionThresholdOnNbrOfDBsForHighPrioReq.
• If the new bearer is a low priority data bearer and its probable admission
would make the total number of data bearers in the cell exceeds
admissionThresholdOnNbrOfDBs.
• If the new bearer has a QCI = qCIforVoipRtpRtcp (=1 in LA6.0) , i.e. a VoIP
bearer, and its probable admission would make the total number of VoIP
bearers in the cell exceed maxNbrOfVoIP (plus internal hardcoded margin
of 4). The margin is used only if isReactiveLoadControlAllowed is set to
“True”, to account for transient cases such as handover. This same margin is
also taken into account by RRM for the same purpose. Another reason for
this margin is to keep the operator view of VoIP capacity simple.
• If the probable admission of the new bearer would make the total number of
data bearers in the QCI group (the new bearer’s QCI belongs to) exceed
maxNbrOfDataBearersPerQciGroup. This parameter is a list of up to 32
limits, each element (i.e. limit) corresponding to a given QCI Group (the first
element corresponds to QCI Group1, the second to QCI Group 2 and so on).
If no QCI group m was defined (i.e. if none of the instances of
TrafficRadioBearerConf has qciGroup=m) then the mth element of
maxNbrOfDataBearersPerQciGroup is insignificant. One QCI may belong
to only one group, and one group can contain all supported QCIs. QCIs in a
group can be non-continuous.
If reactive load control fails, the request is rejected. Reactive Load Control is
described in section 5.1.4.
RadioCacEnb::maxNbOfDataBearersPerEnodeB
Parameter maxNbOfDataBearersPerEnodeB
[0..12000]
3900 [Macro Cell bCEM 10MHz, 15MHz, 20MHz]
Value 2437 [Macro Cell bCEM 5MHz]
208 [Metro Cell]
Page 300/472
RadioCacCell::maxNbOfDataBearersPerCell
Parameter maxNbOfDataBearersPerCell
[0..4000]
RadioCacCell::maxNbrOfDataBearersPerQciGroup
Parameter maxNbrOfDataBearersPerQciGroup
Range & Unit List of up to 32 integers
[0..756]
Class/Source C--New-set-ups/ system_restricted
RadioCacCell::maxNbrOfVoip
Parameter maxNbrOfVoip
[0..400]
Page 301/472
Rule: Parameter maxNbrOfVoip
If a QCI group that only consists of QCI= qCIforVoipRtpRtcp (i.e. VoIP QCI) is
configured, then the setting of the element of
maxNbrOfDataBearersPerQciGroup that corresponds to the VoIP QCI and the
setting of maxNbrOfVoip should be the same.
If a QCI group consisting of more than QCI= qCIforVoipRtpRtcp (i.e. VoIP QCI)
is configured, then the setting of the element of
maxNbrOfDataBearersPerQciGroup that corresponds to the VoIP QCI and the
setting of maxNbrOfVoip should verify:
maxNbrOfDataBearersPerQciGroup ≥ maxNbrOfVoip
Page 302/472
Engineering Recommendation: Regarding parameters maxNbrOfVoip,

maxNbOfDataBearersPerCell and maxNbrOfDataBearersPerQciGroup

- With eCEM:
dlBandwidth maxNbrOfVoip maxNbOfDataBearersPerCell
n6-1.4MHz 0 156
n15-3MHz 0 325
n25-5MHz 50 543
n50-10MHz 100 650
n100-20MHz 20 176
- With bCEM:
n25-5MHz 50 813
n50-10MHz 100 1300
n75-15MHz 100 1300
n100-20MHz 100 1300

• maxNbrOfVoip = 32
• maxNbOfDataBearersPerCell = 208
The setting of parameter maxNbrOfDataBearersPerQciGroup is consequently:

- With eCEM:
dlBandwidth maxNbrOfDataBearersPerQciGroup
n6-1.4MHz [0, 156, 156, 156, 156, 156, 156, 156, 156]
n15-3MHz [0, 325, 325, 325, 325, 325, 325, 325, 325]
n25-5MHz [50, 543, 543, 543, 543, 543, 543, 543, 543]
n50-10MHz [100, 650, 650, 650, 650, 650, 650, 650, 650]
n100-20MHz [20, 176, 176, 176, 176, 176, 176, 176, 176]
- With bCEM:
Page 303/472
n25-5MHz [50, 813, 813, 813, 813, 813, 813, 813, 813]
n50-10MHz [100, 1300, 1300, 1300, 1300, 1300, 1300, 1300, 1300]
n75-15MHz [100, 1300, 1300, 1300, 1300, 1300, 1300, 1300, 1300]
n100-20MHz [100, 1300, 1300, 1300, 1300, 1300, 1300, 1300, 1300]

• maxNbrOfDataBearersPerQciGroup = [32, 208, 208, 208, 208,
208, 208, 208, 208]

- With bCEM:
n6-1.4MHz 0 325
n15-3MHz 0 780
n25-5MHz 50 813
n50-10MHz 100 1300
n75-15MHz 100 1300
n100-20MHz 100 1300
The setting of parameter maxNbrOfDataBearersPerQciGroup is consequently:

- With bCEM:
n6-1.4MHz [0, 325, 325, 325, 325, 325, 325, 325, 325]
n15-3MHz [0, 780, 780, 780, 780, 780, 780, 780, 780]
n5-5MHz [50, 813, 813, 813, 813, 813, 813, 813, 813]
n50-10MHz [100, 1300, 1300, 1300, 1300, 1300, 1300, 1300, 1300]
n75-15MHz [100, 1300, 1300, 1300, 1300, 1300, 1300, 1300, 1300]
n100-20MHz [100, 1300, 1300, 1300, 1300, 1300, 1300, 1300, 1300]
Page 304/472
RadioCacCell::qCIforVoipRtpRtcp
Parameter qCIforVoipRtpRtcp
[1..9]
1 (See Restriction Below) ALU recommends the operator to not
Value
change this setting
Feature FRS 114531
Restriction: VoIP QCI and parameter qCIforVoipRtpRtcp
In LA6.0, VoIP is only supported on QCI1. Therefore, parameter

qCIforVoipRtpRtcp must be set to “1”.
RadioCacCell::maxGBRforVoIPserviceDl
Parameter maxGBRforVoIPserviceDl
[1..1000000] bits/s
Feature FRS 114531
RadioCacCell::maxGBRforVoIPserviceUl
Parameter maxGBRforVoIPserviceUl
[1.. 1000000] bits/s
65536 CR 564598 ALU recommends the operator to not change
Value
this setting
Feature FRS 114531
Page 305/472
Bit3 of Enb::spare15, corresponding to internal variable

isVoIPGBRCapIncreaseEnabled, needs to be set to value ‘1’ in order to support
aggregated VoIP traffic (see feature 163172).
Bits 4-5 of Enb::spare15, corresponding to internal variable
voipGbrThresholdRoHCSpsActivation, controls the GBR value above which both
SPS & ROHC will be disabled upon call / bearer setup for QCI1. Possible values are
00 (25 kbps), 01 (50 kbps), 10 (75 kbps), 11 (100 kbps), the default recommended
value being 11 (100kbps). For more details, see feature 163172.
Note: When SPS is deactivated the modem will use DS instead. If
voipGbrThresholdRoHCSpsActivation = 100 kbps (the recommended default value)
then modem will use DS for all BCPS calls except for GBR=50 kbps case. If
voipGbrThresholdRoHCSpsActivation = 50 kbps then SPS will not be used for
any BCPS QCI1 bearers.
RadioCacCell::admissionThresholdOnNbrOfDBs
Parameter admissionThresholdOnNbrOfDBs
[0..4000]
Feature FRS 114539
RadioCacCell::deltaAdmissionThresholdOnNbrOfDBsForHighPrioReq
Parameter deltaAdmissionThresholdOnNbrOfDBsForHighPrioReq
[0..4000]
Feature FRS 114539
Page 306/472
Rule: Parameter deltaAdmissionThresholdOnNbrOfDBsForHighPrioReq

The sum of admissionThresholdOnNbrOfDBs +
deltaAdmissionThresholdOnNbrOfDBsForHighPrioReq must not exceed
maxNbOfDataBearersPerCell.
Engineering Recommendation: Parameter admissionThresholdOnNbrOfDBs

and parameter deltaAdmissionThresholdOnNbrOfDBsForHighPrioReq
settings
The current default settings for these 2 parameters are the following:
• admissionThresholdOnNbrOfDBs +
deltaAdmissionThresholdOnNbrOfDBsForHighPrioReq =
maxNbOfDataBearersPerCell
• deltaAdmissionThresholdOnNbrOfDBsForHighPrioReq = 0
RadioCacEnb::maxNbOfDataBearersPerUe
Parameter maxNbOfDataBearersPerUe
{1, 2, 3, 4, 5, 6, 7, 8}
Engineering Recommendation: Parameter maxNbOfDataBearersPerUe
Parameter maxNbOfDataBearersPerUe is controlled by licensing:

If capacity licensing is not activated or in case of an infinite license, it is
recommended that parameter maxNbOfDataBearersPerUe be set to “8”.
In case of a finite license, parameter maxNbOfDataBearersPerUe should be set
according to the license commercial agreement.
The current ALU default setting is “8”.
Page 307/472
5.1.2.3 PER PLMN PER CELL
the SIB1 in the cell), reserved number of data bearers and reserved number of data
bearers per QCI group are also defined per PLMN per cell by parameters
RadioCacCellPerPlmn::reservedNbOfDataBearers and
RadioCacCellPerPlmn::reservedNbOfDataBearersPerQciGroup, respectively. An
example of how number of these are allocated for eUTRAN sharing (with 3 PLMNs)
is shown below.
admissionThresholdOnNbrOfDBs
Number of data
reservedNbOfData
reservedNbOfData reservedNbOfData bearers shared by
Bearers for PLMN
Bearers for PLMN 2 Bearers for PLMN 3 all PLMNs (shared
1
pool)
maxNbrOfBearersPerQciGroup[i]
Number of data
reservedNbrOfData reservedNbrOfData reservedNbrOfData bearers for QCI[i]
BearersPerQciGrou BearersPerQciGrou BearersPerQciGrou shared by all
p[i] for PLMN 1 p[i] for PLMN 2 p[i] for PLMN 3 PLMNs (shared
pool)
The maximum number of data bearers that can be admitted for a specific PLMN in
the cell is calculated as:
reservedNbOfDataBearers(this PLMN) + Number_of_data_bearers_shared_by_all_PLMNs –
Consumption_in_Shared_Pool(by other PLMNs)
where:
Number_of_data_bearers_shared_by_all_PLMNs =
admissionThresholdOnNbrOfDBs - ∑reservedNbOfDataBearers(all_PLMNs)
If this per PLMN per cell limit is exceeded, then reactive load control may be
attempted (if enabled) to manage congestion. Otherwise, if reactive load control is
not possible or if it fails, then Radio CAC will reject the incoming request.
The maximum number of data bearers per QCI group [i] per PLMN per cell that can
be admitted for a specific PLMN in the cell is calculated as:
reservedNbOfDataBearersPerQciGroup[i](this PLMN) +
Number_of_data_bearers_per_QCI_group[i]_shared_by_all_PLMNs –
Consumption_in_Shared_Pool[i](by other PLMNs)
where:
Number_of_data_bearers_per_QCI_group[i]_shared_by_all_PLMNs =
maxNbOfDataBearersPerQciGroup[i] - ∑reservedNbrOfDataBearersPerQciGroup[i](all_PLMNs)
Page 308/472
If this per QCI per PLMN per cell limit is exceeded, then reactive load control may be
RadioCacCellPerPlmn::reservedNbOfDataBearers
Parameter reservedNbOfDataBearers
Object
n
[0..4000]
Value 0 (default)
Feature FRS 115242
Rule: Parameter reservedNbOfDataBearers

The sum of all instances of RadioCacCellPerPlmn::reservedNbOfDataBearers
must not exceed admissionThresholdOnNbrOfDBs.
Engineering Recommendation: Parameter reservedNbOfDataBearers
RadioCacCellPerPlmn::reservedNbrOfDataBearersPerQciGroup
Parameter reservedNbrOfDataBearersPerQciGroup
Object
n
Range & Unit List of up to 32 integers
[0..4000]
Value 0 (default)
Feature FRS 115242
Page 309/472
Rule: Parameter reservedNbrOfDataBearersPerQciGroup

The sum of all instances of
RadioCacCellPerPlmn::reservedNbrOfDataBearersPerQciGroup must not
exceed maxNbrOfDataBearersPerQciGroup for a given QCI value.

reservedNbrOfDataBearersPerQciGroup
5.1.2.4 MODEM MEASUREMENTS
Two modem measurements are used by Radio CAC:
1. Measurements (supported on eCEM and bCEM) report PRB consumption for

each bearer type on a per cell (except for VoIP bearers which are reported
per cell per PLMN) and per band basis. The reporting period of this
measurement is configurable by parameter
periodMeasForPRBConsumption.
2. Measurements which report UE radio conditions to identify UEs that are in
“bad radio conditions”. The reporting period of this measurement is
configurable by parameter periodMeasForUeRadioCondition. This
measurement is activated when overheadForUeInBadRadioCondition is
set to a non-zero value. This parameter represents the additional percentage
of available PRBs required for admitting UEs in “bad radio conditions”. A UE
is in “bad radio conditions” when its measured SINR falls below the threshold
badUeSinrThreshold. A UE exits “bad radio conditions” when its measured
SINR exceeds configurable threshold goodUeSinrThreshold.
Page 310/472
RadioCacCell::periodMeasForPRBConsumption
Parameter periodMeasForPRBConsumption
[1..10] seconds
Value 1
RadioCacCell::periodMeasForUeRadioCondition
Parameter periodMeasForUeRadioCondition
[500..10000] step = 500 milliseconds
Value 500
Feature FRS 92091
RadioCacCell::overheadForUeInBadRadioCondition
Parameter overheadForUeInBadRadioCondition
[0..50] %
Value 0
Feature FRS 92091
RadioCacCell::badUeSinrThreshold
Parameter badUeSinrThreshold
Range & Unit Float
[-10.0..30.0] step = 0.25 dB
Value -10.0
Feature FRS 92091
Page 311/472
RadioCacCell::goodUeSinrThreshold
Parameter goodUeSinrThreshold
Range & Unit Float
[-10.0..30.0] step = 0.25 dB
Value 30.0
Feature FRS 92091
Rule: Parameters badUeSinrThreshold, goodUeSinrThreshold,

periodMeasForUeRadioCondition
These parameters are used by Radio CAC only if parameter

overheadForUeInBadRadioCondition is set to a value greater than 0.
5.1.3 PRB CONSUMPTION

PRB consumption is the number of PRBs consumed by SRB, DRB and common
channel per second. Radio CAC maintains two global pools of PRB resources, one
for DL and one for UL. Each global pool is divided into established resources
consumed (PRBs consumed by common channels, multicast (MBMS), SRBs, VoIP
DRBs, GBR DRBs, and non-GBR DRBs) and free resources available for incoming
low and high priority bearers, as shown in Figure 21.
DL/UL Total Resource count (deduced from FrequencyAndBandwidthFDD::dl/ulBandwidth)
DL/UL threshold for high priority bearer:

(dl/ulAdmissionThresholdOnPrb+deltaAdmissionThresholdOnPrbForHighPrioReq)% of the DL/
UL Total Resource Count
DL/UL threshold for low priority bearer: (dl/ulAdmissionThresholdOnPrb) % of the DL/

UL Total Resource Count
PRB PRB
cons PRB
consumed PRB Free PRB for Free PRB for
PRB consumed by PRB consumed by consumed
umed
by by
consumed high&low high priority Margin
multi
VoIP DRB GBR DRB by Non-
common -cast by SRB priority bearer bearer
(MB GBR DRB
channel MS)
Figure 19: PRB Consumption in a Cell
PRB resource pools are updated when a SRB/DRB is accepted/released/off-loaded,

or GBR of an existing DRB is modified, or modem report on PRB consumption is
received.
Page 312/472
The following admission checks may be performed for incoming requests that require
PRB consumption as one of their admission criteria:
1. Admission based on total PRB resources available per cell (pre-LA5.0 behavior).
This check is always performed.
2. Admission based on PRB resources available per band across all cells in the
bCEM. This check is performed only if PRB licensing is enabled and dual-carrier is
disabled.
3. Admission based on PRB resources available per PLMN per cell, as illustrated in
Figure 22.
DL/UL total PRB (deduced from FrequencyAndBandwidthFDD::dl/ulBandwidth)
DL/UL threshold for high priority bearer (dl/ulAdmissionThresholdOnPrb+deltaAdmissionThresholdOnPrbForHighPrioReq)
DL/UL threshold for low priority bearer (dl/ulAdmissionThresholdOnPrb)
Common Consumption for PLMN 1 Consumption for PLMN 2

consumption (reservedDl/UlPrbPercentage for plmnId=1) (reservedDl/UlPrbPercentage for plmnId=2)
PRB
PRB PRB PRB PRB PRB PRB PRB Free PRB for Free PRB
consumed PRB consumed
consumed consumed consumed by consumed by consumed consumed by consumed by high&low for high
by VoIP by Non-GBR TRB Margin
by common by SRB GBR TRB Non-GBR TRB by SRB VoIP TRB GBR TRB priority priority
TRB (PLMN 2)
channel (PLMN 1) (PLMN 1) (PLMN 1) (PLMN 2) (PLMN 2) (PLMN 2) bearer bearer
(PLMN 1)
Figure 20: Example of PRB Consumption per PLMN (cell shared by 2 operators: plmnId=1 and
plmnId=2)
5.1.3.1 PRB CONSUMPTION CALCULATION
Modem reports on PRB consumption per cell (except for VoIP bearers: per PLMN
per cell) are used by Radio CAC to calculate the current view of PRB consumption of
SRBs and DRBs. This calculation may be differentiated between VoIP GBR DRBs
and non-VoIP GBR DRBs if parameter
isBearerTypeBasedPrbEstimationPreferred is set to ‘True’. Otherwise, if this
parameter is set to ‘False’, Radio CAC calculates the PRB consumption of VoIP
DRBs the same as it does for non-VoIP GBR DRBs.
Page 313/472
ActivationService::isBearerTypeBasedPrbEstimationPreferred
Parameter isBearerTypeBasedPrbEstimationPreferred
True/False
Value Default: True
Feature FRS 114539
RadioCacCell::dlOverheadConsumption
Parameter dlOverheadConsumption
[0..100000] PRBs/second
Value
RadioCacCell::ulOverheadConsumption
Parameter ulOverheadConsumption
Value
Page 314/472
Engineering Recommendation: Parameters dlOverheadConsumption,

ulOverheadConsumption
These parameters should be set according to System Bandwidth as follows:
dlBandwidth,ulBandwidth dlOverheadConsumption ulOverheadConsumption
n6-1_4MHz 1500 2500
n15-3MHz 1400 2700
n25-5MHz 1600 4700
n50-10MHz 1800 4700
n75-15MHz 2400 6700
n100-20MHz 2400 6700
Reference: CR 749669
RadioCacEnb::cchSelfLearningCoef
Parameter cchSelfLearningCoef
[0..100] %
RadioCacCell::dlSigConsumption
Parameter dlSigConsumption
Feature FRS 92633
Page 315/472
RadioCacCell::ulSigConsumption
Parameter ulSigConsumption
Feature FRS 92633
RadioCacCell::dlPRBconsumptionPerKbps
Parameter dlPRBconsumptionPerKbps
Range & Unit Float
[0.0..100.0] step = 0.1 PRBs/second per kbps of GBR
Value
personnel.
Feature FRS 92633
RadioCacCell::ulPRBconsumptionPerKbps
Parameter ulPRBconsumptionPerKbps
Range & Unit Float
[0.0..100.0] step = 0.1 PRB/second per kbps of GBR
Value
personnel.
Feature FRS 92633
Page 316/472
Parameters dlMinBitRateForBE and ulMinBitRateForBE respectively define the DL

and UL bit rates which Radio CAC assumes for a Best Effort (i.e. non-GBR) radio
bearer.
PRB-based CAC for non-GBR bearers and SRB, regardless of minBitRateForBE
value, are enabled only when the flag isNonGbrPrbCacEnabled is set to True.
RadioCacCell::dlMinBitRateForBE
Parameter dlMinBitRateForBE
[0..2048] Kbits/second
Value O.D. (ALU Default : 1)
Feature FRS 92091
RadioCacCell::ulMinBitRateForBE
Parameter ulMinBitRateForBE
[0..2048] Kbits/second
Value O.D. (ALU Default : 1)
Feature FRS 92091
RadioCacCell::isNonGbrPrbCacEnabled
Parameter isNonGbrPrbCacEnabled
True/False
Value O.D. (ALU Default: True)
Feature
Single/Multi minBitRateForBE isNonGbrPrb Possible Risk or Result if

LTE Carrier CacEnabled PRB limit is exceeded
setting
Single 0 True Cell operating in congestion;
CAC blocking of RRC
establishment (SRB)
Page 317/472
Single 0 False Cell operating in congestion

Single >0 True CAC blocking of non-GBR
and GBR bearers and RRC
establishment (SRB);
Offload/release due to
congestion (if reactive load
control enabled)
Single >0 False CAC blocking of GBR

bearers only;
Offload/release due to
congestion (if reactive load
control enabled)
Multi 0 True Cell operating in congestion;
CAC blocking of RRC
establishment (SRB);
Lack of load balancing for
non-GBR bearers may
cause imbalance between
LTE carriers
Multi 0 False Cell operating in congestion;

Lack of load balancing for
non-GBR bearers may
cause imbalance between
LTE carriers
Multi >0 True Load balancing (if
preventive load control
enabled)
Multi >0 False Load balancing (if

preventive load control
enabled)
Engineering Recommendation: dlMinBitRateForBE, ulMinBitRateForBE
Parameters dlMinBitRateForBE and ulMinBitRateForBE should be set to a

value greater than 0 when preventive load control is enabled in a multi-LTE carrier
environment. Preventive load control is described in section 5.1.5.
The following provides examples for calcluation of Miminum Bit Rate For Best Effort:
Assumptions:
 Only NonGBR bearers, No GBR bearer
 Average PRB consumption per SRB = 0.25 PRB/s
 Average PRB consumption for 1kbps = 10 PRB/s/kbps (eNB calculates this
based on real traffic, and it can vary)
 Average Number of NonGBR bearers per UE = 1 bearer/UE
 Overhead PRB consumption = 4000 PRB/s (dlOverheadConsumption =

2200 & ulOverheadConsumption = 5600)
Page 318/472
 PRB consumption is 70% of total bandwidth
Calculation for 10MHz cell:

 Amount of PRBs per sec = 50000 PRB/s
 Max Number of Users per cell = 250 users
 Offloading at >= 175 users (= 0.7*250) in cell
 Number of NonGBR Bearers = 175
 Number of SRB = 350 (2 SRBs per UE)
MinBitRateForBE = ((50000 * 0.7 PRB/s) – (4000 PRB/s) - (350 * 0.25 PRB/s)) /
(175 * 10 PRB/s/kbps) = ~18 kbps
Calculation for 5MHz cell:

 Amount of PRBs per sec = 25000 PRB/s
 Max Number of Users per cell = 200 users
 Offloading at >= 140 users (= 0.7*200) in cell
 Number of NonGBR Bearers = 140
 Number of SRB = 280 (2 SRBs per UE)
MinBitRateForBE = ((25000 * 0.7 PRB/s) – (4000 PRB/s) - (280 * 0.25 PRB/s)) /
(140 * 10 PRB/s/kbps) = ~10 kbps
5.1.3.2 MBMS MULTICAST PRB CONSUMPTION
If MBMS is activated (isMbmsBroadcastModeAllowed = TRUE), some DL PRB

resource will be reserved only for MBMS (multicast). The PRB reserved for MBMS
(only in DL) in a cell is the sum of PRBs reserved for MBMS for all MBSFN areas in
the cell.
The Total PRB Resource Count in the DL for call admission of unicast (non-MBMS)
requests subtracts PRBs reserved for MBMS in the call admission calculations.
5.1.3.3 ADMISSION DECISION
The acceptance of a new call (UE context creation) is conditioned by the availability
of enough PRB resources to accommodate the corresponding dedicated Signaling
Radio Bearers (SRB1 and SRB2). Similarly, the acceptance of a radio bearer
creation or modification request is conditioned by the availability of enough PRB
resources to accommodate the radio bearer.
The total DL and UL PRB resource count for a cell are deduced from bandwidth
parameters dl/ulBandwidth, as shown in the following table:
Page 319/472
dlbandwidth Total DL Resource Count (in PRBs per

second)
n6-1_4MHz 6000
n15-3MHz 15000
n25-5MHz 25000
n50-10MHz 50000
n75-15MHz 75000
n100-20MHz 100000
ulbandwidth Total UL Resource Count (in PRBs per

second)
n6-1_4MHz 6000
n15-3MHz 15000
n25-5MHz 25000
n50-10MHz 50000
n75-15MHz 75000
n100-20MHz 100000
Table 23: Total DL and UL Resource Count for a cell
As indicated in section 5.1.3.2, if MBMS is activated, then the number of PRBs

reserved in the DL is subtracted from the total DL resource count for the cell.
For admission of GBR DRBs (both VoIP and non-VoIP), the S1AP GBR value is
used. Since currently in 3GPP R9, the GBR setting must equal the MBR, the GBR
averaged over a period of time is typically lower than the GBR (=MBR) setting and
therefore may cause an over-estimation of the the PRB consumption. To adjust for a
realistic estimation of PRB consumption for GBR DRBs, optional parameter
prbReservationFactor is defined as a percentage of GBR to be used in the
admission calculation.
Thus:
New DL/UL PRB resources required by a GBR DRB =
(Average PRBs per second per kbps for GBR in DL/UL) × (S1AP GBR in DL/UL) ×
prbReservationFactor
Parameter [dl,ul]MinBitRateForBE is used for the PRB consumption estimate for
non-GBR DRBs if it is set to a value greater than 0.In LR13.1, optional parameter
prbReservationFactor may also be used for nonGBR PRB resource estimation to
differentiate PRB consumption per nonGBR QCI.
Thus:
New DL/UL PRB resources required by a nonGBR DRB =
(Average PRBs per second per kbps for non-GBR in DL/UL) ×
prbReservationFactor[qci] × [dl,ul]MinBitRateForBE (if > 0)
If [dl,ul]MinBitRateForBE is set to 0, then PRB resource calculations in the DL/UL,

respectively, are not performed for the incoming nonGBR DRB request. Thus, with
this parameter setting, the nonGBR DRB request will always pass the PRB resource
check.
Page 320/472
In the admission decision, the weight of the UE radio condition is applied as follows:
If the UE is in good radio conditions, or if no modem measurement for UE radio
condition is configured (i.e. overheadForUeInBadRadioCondition is set to “0”),
then
• weight of UE radio condition = 1.
• weight = 1 means no additional PRB resources are required for admission
Otherwise, if the UE is in bad radio conditions, then

• weight of UE radio condition =1+ overheadForUeInBadRadioCondition/100.
• weight > 1 means additional PRB resources are required for admission.
TrafficRadioBearerConf::prbReservationFactor
Parameter prbReservationFactor
[1..100] %
LA6.0 – LR13.1 Delta: Parameter prbReservationFactor
In LA6.0 and earlier releases, this parameter was restricted for GBR bearers only.
In LR13.1, this restriction is removed and this parameter may also be used for
nonGBR bearers along with existing parameter [dl/ul]MinBiteRateForBE in the
PRB resource estimation.
Engineering Recommendation: Parameter prbReservationFactor
For VoIP DRB, the recommended value is 65 because VAD reduces PRB
consumption to 60% of nominal and RTCP adds 5%.
This parameter is optional and it is <unset> in the ALU template.
Page 321/472
5.1.3.3.1 ADMISSION WITH EUTRAN SHARING (PER

PLMN PER CELL ADMISSION)
the SIB1 in the cell), then an additional check is performed to ensure that the PRB
resources consumed by a PLMN is not beyond the allowed capacity for this PLMN.
The percentage of the total cell capacity that is available for a PLMN is defined by
parameter reservedDlPrbPercentage in the DL and parameter
reservedUlPrbPercentage in the UL.
If this reserved PRB percentage is exceeded, then reactive load control may be
RadioCacCellPerPlmn::reservedDlPrbPercentage
Parameter reservedDlPrbPercentage
Object
n
[0..100] %
Value 0 (default)
Feature FRS 115242
Rule: Parameter reservedDlPrbPercentage
The sum of reservedDlPrbPercentage for all configured PLMN instances of a

cell must not exceed 100%, as PLMN consumption is evaluated on the total
available PRB resources (= (capacity given in Table 23 ×
RadioCacCell::dlAdmissionThresholdOnPrb) – CCCH consumption).
RadioCacCellPerPlmn::reservedUlPrbPercentage
Parameter reservedUlPrbPercentage
Object
n
[0..100] %
Value 0 (default)
Feature FRS 115242
Page 322/472
Rule: Parameter reservedUlPrbPercentage
The sum of reservedUlPrbPercentage for all configured PLMN instances of a

cell must not exceed 100%, as PLMN consumption is evaluated on the total
available PRB resources (= (capacity given in Table 23 ×
RadioCacCell::ulAdmissionThresholdOnPrb) – CCCH consumption).
Restriction: shared cell consumption and eMBMS
If eUTRAN sharing is enabled, eMBMS cannot be activated.
5.1.4 REACTIVE LOAD CONTROL

Failure during CAC checks for admission of a data bearer indicate some level of
congestion which may trigger reactive load control to pre-empt lower priority bearers
or UEs so that the higher priority request can be admitted. Incoming requests that
may trigger reactive load control are:
• Any RRC Connection request from UE with cause set to ‘emergency’ which
may trigger either CSFB emergency procedure or VoIP Emergency Call
establishment.
• Incoming High Priority Access call.
• Incoming bearer with Pre-emption Capability “may trigger pre-emption”and

its Priority Level is not 15.
Reactive load control is enabled when parameter
isOffloadUponReactiveLoadControlAllowed is set to “True”. During reactive load
control, a list of candidate UEs and/or a list of candidate bearers are selected for pre-
emption to allow enough resources to admit a higher priority call or bearer. There are
two main pre-emption actions which may be taken:
• Off-loading of UE to another frequency band.
o If congestion is at cell or band level, then offload may be performed to an
intra-eNodeB cell on a different frequency band from the serving cell if
bCEM is configured and dual-band is configured.
o Else, offload must be performed to a cell on another eNodeB.
• Release of UE or of bearer.
The choice of pre-emption action to be taken is based on the data parameter settings
described subsequently in this section. In the case of off-loading, Radio CAC will
invoke eMCTA to off-load UEs (see Volume 6 for details on eMCTA). A fallback to
UE/bearer release may occur when off-loading may not be processed or fails.
The eNB selects bearers in the order of low priority to high priority as pre-emption
candidates. For the bearers with same priority, the one with higher DL+UL bit rate
Page 323/472
(S1AP GBR, or minBitRate) is preferred. The candidate bearers selected are based
on the CAC check that triggered reactive load control. If the CAC check is the
number of data bearer per eNB, then bearers are selected from the whole eNB; if the
CAC check is the number of data bearers per cell (or per PLMN per cell) or PRB
consumption per cell (or per PLMN per cell), then bearers are selected from this cell
(or this PLMN in this cell); if the CAC check is the number of data bearers per QCI
group per cell (or per PLMN per QCI group per cell), then bearers are selected from
corresponding QCI group in this cell (or this PLMN in this cell). If the CAC check is
the number of VoIP bearers per cell, then bearers are selected from VoIP bearers of
this cell.
If the triggering CAC check is per PLMN per cell, suitable candidates inside the same
PLMN as the request that triggered reactive load control are selected. If no suitable
candidates inside the same PLMN in the cell can be found, then candidates inside a
different PLMN in the cell which meet criteria for reactive load control may be
considered if the resources that would remain after pre-emption do not go below the
minimum limit reserved for the operator of the other PLMN (i.e. resources for the
other PLMN cannot fall below reservedNbrOfUsers, reservedNbOfDataBearers,
reservedNbrOfDataBearersPerQciGroup, reservedDlPrbPercentage,
reservedUlPrbPercentage).
Bearer candidates for reactive load control are selected if they meet the following
criteria:
• It is not the only bearer of a UE;

• Its pre-emption vulnerability is pre-emptable, and its Priority Level is not 15;
• Its priority is lower than that of the bearer which triggered reactive load
control;
• Its UE is not in an ongoing procedure, including release, handover, CCO and
ANR procedure;
• Its UE is not a CSFB call;
• Its UE is not in coverage alarm (event A2 for Entering-Coverage-Alarm has
been received);
• Its UE is not the same UE of the bearer which triggered reactive load control.
A UE is a candidate for off-loading if:
• Parameter isOffloadUponReactiveLoadControlAllowed is set to “True”
(defined in Volume 6)).
• It has a pre-emption candidate bearer configured and parameter
ReactiveLoadControlActionForBearerAdmission::action (in the instance
of TrafficRadioBearerConf with qCI=incoming bearer QCI) is set to
“outgoingMobility”.
• All the bearers belonging to the UE are pre-emptable.
• All the bearers belonging to the UE have a lower priority than that of the
bearer which triggered reactive load control.
Page 324/472
If off-loading fails, it is only the selected candidate data bearers that will be released,
not the entire UE context.
In order not to involve too many UEs into one reactive load control procedure, an
optional parameter maxNbrOfUsersImpactedByReactiveLoadControl, is defined.
If this parameter is present and the number of UEs impacted by reactive load control
(either as a candidate UE to off-load or has a bearer which is a candidate to be
released) exceeds the value of this parameter, then reactive load control is not
performed and the admission of the new request is rejected.
For example:
maxNbrOfUsersImpactedByReactiveLoadControl = 10,
isReactiveLoadControlAllowed = True:
Case 1: Radio CAC identifies 4 UEs to be off-loaded and 3 UEs to have at least one
radio bearer released. Reactive load control will be performed because the number
of UEs impacted = 4 + 3 < 10.
Case 2: Radio CAC identifies 6 UEs to be off-loaded and 7 UEs to have at least one
radio bearer released. Reactive load control will NOT be performed because the
number of UEs impacted = 6 + 7 > 10.
ActivationService::isReactiveLoadControlAllowed
Parameter isReactiveLoadControlAllowed
True/False
Value False
Feature FRS 114539
RadioCacEnb::maxNbrOfUsersImpactedByReactiveLoadControl
Parameter maxNbrOfUsersImpactedByReactiveLoadControl
[1..1000]
Feature FRS 114539
Page 325/472

maxNbrOfUsersImpactedByReactiveLoadControl
This parameter is optional and is <unset> in the ALU template.

When <unset>, there is no limit on the maximum number of users that may be
impacted by reactive load control.
ReactiveLoadControlActionForBearerAdmission::action
Parameter action
TrafficRadioBearerConf/ReactiveLoadControlActionForBearer
Object
Admission
[callRelease, outgoingMobility]
Value Default: outgoingMobility
Feature FRS 114539
Parameter ReactiveLoadControlActionForBearerAdmission::action specifies the

action (bearer release, or UE offload) to be performed upon the configured bearer if it
is pre-empted by the admission of another bearer under reactive load control for the
concerned PLMN.
Note that the applicable parameter value is taken from the instance of
ReactiveLoadControlActionForBearerAdmission associated with the pre-empted
bearer, not from the instance associated with the bearer that is being admitted.
Parameter PlmnIdentity::reactiveLoadControlActionForEcAndHpaAdmission
defines the action (release or offload UE) for Reactive Load Control triggered by IMS
VoIP EC admission. The PlmnIdentity object instance is obtained from
TrafficRadioBearerConf::ReactiveLoadControlActionforBearerAdmission::plm
nId.
PlmnIdentity::reactiveLoadControlActionForEcAndHpaAdmission
Parameter reactiveLoadControlActionForEcAndHpaAdmission
[callRelease, outgoingMobility]
Value Default: outgoingMobility
Page 326/472
Rule: Parameter reactiveLoadControlActionForEcAndHpaAdmission
The setting of this parameter must be aligned with the setting of parameter
isOffloadUponReactiveLoadControlAllowed (defined in [Vol. 6]) as follows:
isOffloadUponReactiveLoa reactiveLoadControlActionForEcAndHpaAdmission
dControlAllowed
False callRelease
True outgoingMobility
plmnId: This parameter refers to the instance of the PlmnIdentity object that
defines the MCC and MNC of the concerned PLMN.
ReactiveLoadControlActionForBearerAdmission::plmnId
Parameter plmnId
ENBEquipment/Enb/DedicatedConf/TrafficRadioBearerConf/
Object
ReactiveLoadControlActionForBearerAdmission
Value O.D.
Feature FRS 115242
5.1.5 PREVENTIVE LOAD CONTROL

Preventive load control helps avoiding congestion and attempts call load balancing
between LTE carriers by offloading selected UEs to neighbouring inter-frequency
cells which have spare load capacity. With FRS 155912, preventive offloading can
also be performed towards UTRAN FDD macro cells that have spare load capacity.
The target cells to which UEs are offloaded may be intra-eNodeB if dual-band on
bCEM is configured, or inter-eNodeB. With FRS 163172, preventive load balancing is
enhanced by allowing prioritization of neighbour carriers for preventive offload. Such
capability allows having neighbour carriers (both LTE and WCDMA) using different
set of preventive offload threshold. Each LTE neighbor carrier is assigned to one of
up to 3 sets of thresholds, and a 4th set of thresholds is for preventive offload to
WCDMA (FDD only). Each set of per carrier load thresholds can include one or more
of the following:
• uplink estimated (semi-static) PRB consumption
• downlink estimated (semi-static) PRB consumption
• uplink real PRB consumption and average QoS degradation
• downlink real PRB consumption and average QoS degradation
Page 327/472
• number of connected UEs per cell

• number of connected UEs per eNB (same threshold value for all
neighbor carriers).
The following picture provides an example. In such scenario it will be possible

preventive offload first towards F2 and then towards F3 when F2 is loaded to the
point where it can’t be chosen anymore for preventive offload.
Preventive load control is enabled if both the following conditions are true:
• If one or both of the following conditions are true:
o Inter-frequency preventive offload is activated - both

isInterFreqLoadBalancingFeatureEnabled = True (described in
volume 6) and isInterFreqPreventiveLoadControlAllowed = True. This
is an optional feature managed by Feature Licensing (refer to Volume 2
for details)
o Inter-RAT preventive offload is activated –
isUtraLoadBalancingEnabled = True (described in volume 6),
isUtraPreventiveLoadControlEnabled = True, and
isPsHoToUtraAllowed = True
• If isStaticPrbBasedPreventiveLoadControlEnabled = True or
isQoSBasedPreventiveLoadControlEnabled = True (LR13.3 only).
If RadioCacCell::isPerNeighborCarrierLoadControlEnabled = True, then some of
the existing parameters in RadioCacCell and TrafficRadioBearerConf (e.g.
uldlRealPrb, uldlStaticPrb, cellNbrOfUsers and dlBitRate) no longer apply to
offloading. Instead, preventive offload thresholds for load balancing are specified in
the new Mos: PreventiveOffload & QciConfForOffload. The following picture
provides an overview on the object interactions.
Page 328/472
Preventive load control is triggered either upon reception of a modem report on PRB
consumption or upon successful admission of an incoming request if one or more of
the following conditions are true:
- Percentage of PRB resources used in the DL (including newly admitted
request) ≥
RadioCacCell::dlPreventiveLoadControlThresholdOnStaticPrb
- Percentage of PRB resources used in the UL (including newly admitted
request) ≥
RadioCacCell::ulPreventiveLoadControlThresholdOnStaticPrb
- If ActivationService::isNumUeBasedPreventiveLoadControlEnabled =
True, then the thresholds RadioCacCell::
cellNbrOfUsersLoadControlThreshold or
PreventiveOffload::cellNbrOfUsersLoadControlThreshold (depending or
not on Prioritization of neighbor carriers activation), RadioCacEnb::
enbNbrOfUsersLoadControlThreshold apply to preventive offload to both
intra-LTE and IRAT UTRAN-FDD:
Page 329/472
o Percentage of connected UEs per cell is ≥

RadioCacCell::cellNbrOfUsersLoadControlThreshold
o Percentage of connected UEs per eNB is ≥
RadioCacEnb::enbNbrOfUsersLoadControlThreshold
- The averaged number of active users reaches a configured percentage

(preventiveLoadControlThresholdNbrOfActiveUsers) of
maxNbrOfActiveUsersPerCell). The averaged number of active users is
determined over a configurable period
(averagingPeriodForNbrActiveUsersPreventiveOffload).
- The real PRB consumption in the cell is ≥
RadioCacCell::ulPreventiveLoadControlThresholdOnRealPrb or
RadioCacCell::dlPreventiveLoadControlThresholdOnRealPrb and the
reported average downlink throughput for active non-GBR bearers is below a
configurable threshold for one or many QCIs, defined by parameter
dlBitRateThresholdForPreventiveLoadControl.
LR13.3 also introduces the possibility to distinguish VoIP users for load balancing
purposes. Idea is improving VoIP user experience by selecting non-VoIP (non-QCI1)
bearers/UEs before selecting QCI1 bearers/UEs for preventive offload and load
equalization. It provides the possibility to keep VoIP users on the continuous
coverage carrier independently of Load Balancing strategy defined. This functionality
is activated by keeping RadioCacEnb::isVoipOffloadEnabled = False (only
meaningful if preventive offload or load equalization is enabled).
A hysteresis timer, configurable by parameter
preventiveLoadControlHysteresisTimer, is started when a preventive load control
procedure to offload UEs begins. This parameter controls the rate at which
preventive load control can be triggered. Any new preventive load control procedure
cannot be triggered while this timer is running. This timer is also started when a
reactive load control procedure begins so that a preventive load control procedure
cannot be triggered when there is an ongoing reactive load control. However, a
reactive load control procedure can still be triggered even if this timer is running.
Radio CAC will select enough UEs for off-loading in order to remain just below
thresholds [dl/ul]PreventiveLoadControlThresholdOnStaticPrb and
[dl/ul]PreventiveLoadControlThresholdOnRealPrb. In case real PRB consumption
is considered, the average throughput for active non-GBR bearers is jointly used as a
criterion to trigger load balancing, so the offloading will also try to keep the
throughput higher than dlBitRateThresholdForPreventiveLoadControl. UEs are
selected from the lowest to highest priority.
A UE can be a candidate for off-loading (for inter-frequency offload, or for UTRAN

offload, or for both depending on UE capability) if:
• For inter-frequency offload - It supports inter-frequency handover (and event
A4 (refer to volume 6 for details);
• For UTRAN offload:
o Its UTRA-FDD supported bands match at least one of the neighbor
UTRA-FDD band of the LTE serving cell
Page 330/472
o It supports event B2 or event B1 UTRAN measurements
o It supports PS handover
o Mobility to UTRAN is not forbidden for this UE (Handover Restriction
List IE received by eNB does not forbid access to UTRAN)
• It has at least one established eRAB;

• Its aggregate priority is equal to or greater than the value of parameter
arpThresholdForPreventiveLoadControl, where aggregate priority =
lowest ARP priority level of the UE’s radio bearers [Min(rb, ARP priority
level)];
• It is not in an ongoing procedure, including release, handover, CCO and
ANR procedure;
• It is not a CSFB call;
• It is not in coverage alarm (event A2 for Entering-Coverage-Alarm has been
received).
• If the preventive offload is triggered by the number of active users criteria,
UEs in OOT (inactive) are not favored. If not enough active users can be
found, OOT users may be selected. The number of UEs selected will ensure
that after offloading the number of active UEs is strictly below the offload
threshold. The number of UEs selected in each cell will be proportional to the
number of active UEs the cell has.
In addition, a UE will not be a candidate for off-loading if:
• It has only non-GBR bearers, all with dlMinBitRateForBE = 0, and
preventive load control was triggered by exceeding the DL PRB consumption
threshold;
• Is has only non-GBR bearers, all with ulMinBitRateForBE = 0, and
preventive load control was triggered by exceeding the UL PRB consumption
threshold.
If off-loading fails, the candidate UEs will remain unchanged in RRC Connected state
in the serving cell.
Parameter maxNbrOfUsersImpactedByPreventiveLoadControl is defined to limit
the number of UEs that can be selected as candidates for preventive load control off-
loading. This parameter restricts the number of UEs that can be involved in a
preventive load control (as candidates to off-load) to not exceed this value.
In case the cell triggers load balancing due to real PRB usage per cell and QoS
deficit (171232), the target number of UEs to offload is proportional to the scale of
the QoS deficit in relation to the average downlink throughput threshold,
dlBitRateThresholdForPreventiveLoadControl, and configurable using parameter
nbrOfUsersImpactedByQosBasedPreventiveOffload. The total amount of
offloaded UEs will never exceed the configured maximum that is defined by
maxNbrOfUsersImpactedByPreventiveLoadControl parameter, described above.
Callp will select a number of UEs higher than the target number of UEs to offload and
configure these UEs with inter-frequency A4 measurements. Note that the eNB won’t
Page 331/472
offload more UEs than the target. This extra margin is configurable using parameter
extraMarginNbUeSelectedPreventiveOffload.
When one or multiple thresholds for load balancing features are met at the same
time, the UE selection rules will be based on the trigger that requires the higher
number of UEs to be offloaded.
Callp will initially avoid triggering inter-frequency handover for UEs that have been
inactive for an extended period of time, since they should have not contributed to the
detected congestion and are less likely to contribute for it in the immediate future.
Upon reception of the A4 measurement report for load balancing, Callp will verify for
how long the UE has been inactive (based on modem report) and ignore the
measurement report if it has been inactive for a pre-determined amount of time,
defined using parameter inactivityTimeForPreventiveOffload. When the extra
configurable margin has elapsed, Callp will deactivate this filtering and allow
selecting inactive UEs.
When enough UEs have been selected for inter-frequency handover, A4
measurements will be deactivated for the remaining UEs.
Figure 23 illustrates the settings of different thresholds for reactive and preventive
load control.
PRB utilization
100% Reactive Offloading upon admission
for <xx> of low or high priority bearers
CAC view
TH 2 = <xx >AdmissionThresholdOnPrb +
deltaAdmissionThresholdOnPrbForHighPrioReq
Reactive Offloading upon admission
of low priority bearers
TH 1 = <xx >AdmissionThresholdOnPrb
Preventive Offloading of “low”

priority calls / Load balancing
TH 0 = <xx >Preventive
>PreventiveLoadControlThresholdOnPrb
Where <xx> stands for

respectively = ul, dl
Figure 21: Thresholds for Preventive and Reactive Load Control
Page 332/472
Parameter isPreventiveLoadControlAllowed is renamed in LR13.1 by

isInterFreqPreventiveLoadControlEnabled. It activates or deactivates only inter-
frequency preventive offloading / load balancing. It controls activation/deactivation of
load balancing triggered by semi-static PRB consumption or QoS deficit.
ActivationService::isInterFreqPreventiveLoadControlEnabled
Parameter isInterFreqPreventiveLoadControlEnabled
True/False
Value False (Default)
Feature FRS 115223(.1) , FRS 114538
ActivationService::isUtraPreventiveLoadControlEnabled
Parameter isUtraPreventiveLoadControlEnabled
True/False
Value False
Feature FRS 155912
Notes: This parameter can be set to ‘True’ only if
ActivationService::isUtraLoadBalancingEnabled is set to ‘True’.
ActivationService::isStaticPrbBasedPreventiveLoadControlEnabled
Parameter isStaticPrbBasedPreventiveLoadControlEnabled
True/False
Value False
Feature FRS 155912
Notes: This parameter activates/deactivates inter-frequency and inter-RAT load
balancing triggered by static PRB consumption. The parameter can be set to True if
inter-frequency preventive offload is activated
(isInterFreqLoadBalancingFeatureEnabled = True &&
isInterFreqPreventiveLoadControlEnabled = True) OR inter-RAT preventive
offload is activated (isUtraLoadBalancingEnabled = True &&
isUtraPreventiveLoadControlEnabled = True).
Page 333/472
ActivationService::isQosBasedPreventiveLoadControlEnabled
Parameter isQosBasedPreventiveLoadControlEnabled
True/False
Value False, in LR13.1
True, in LR13.3
See Restriction
Feature 171232
Notes: this parameter controls activation and deactivation of load balancing based
on actual PRB consumption and average QoS degradation of non-GBR bearer.
Restriction: Regarding parameter isQosBasedPreventiveLoadControlEnabled

in LR13.1
This parameter should be set to False to avoid triggering load balancing based on
non-GBR bearer QoS criteria, as this is not supported in LR13.1.
RadioCacCell::isPerNeighborCarrierLoadControlEnabled
Parameter isPerNeighborCarrierLoadControlEnabled
True/False
Value False
Feature FRS 163172
Notes: This parameter activates/deactivates the prioritization of neighbor carriers for
preventive offload. Preventive offload thresholds for load balancing are specified in
the new Mos: PreventiveOffload & QciConfForOffload and may include estimated
(semi-static) PRB consumption, real PRB consumption and average QoS
degradation and number of connected UEs per eNB/cell.
Page 334/472
LteNeighboringFreqConf::preventiveOffloadLink
Parameter preventiveOffloadLink
Object ENBEquipment/Enb/LteCell/LteNeighbouring/
LteNeighboringFreqConf
Range & Unit Service link
Value N/A
Feature FRS 163172
Notes: This parameter is set to identify to the instance of PreventiveOffload that
applies to this instance of LteNeighboringFreqConf when per neighbor carrier
preventive load balancing is used. Unset if this carrier is not used for per neighbor
carrier preventive offloading.
UtraFddNeighboringFreqConf::preventiveOffloadLink
Parameter preventiveOffloadLink
Object ENBEquipment/Enb/LteCell/LteNeighbouring/
UtraFddNeighboringFreqConf
Range & Unit Service link
Value N/A
Feature FRS 163172
Notes: This parameter is set to identify to the instance of PreventiveOffload that
applies to this instance of UtraFddNeighboringFreqConf when per neighbor carrier
preventive load balancing is used. Unset if this carrier is not used for per neighbor
carrier preventive offloading.
ActivationService::isNumUeBasedPreventiveLoadControlEnabled
Parameter isNumUeBasedPreventiveLoadControlEnabled
True/False
Value False
Feature FRS 163172
Notes: This parameter enables or disables ability to specify number of UEs triggers
for load balancing.
Page 335/472
RadioCacCell::isVoipOffloadEnabled
Parameter isVoipOffloadEnabled
True/False
Value False
Feature FRS 163172
Notes: This parameter enables or disables allowing UEs with a VoIP bearer to be
candidates for reactive offload. Idea is keeping VoIP calls including BCPS on the
higher coverage layer.
Parameter RadioCacCell::dlPreventiveLoadControlThresholdOnStaticPrb is the

DL threshold (per cell) above which preventive load control (load balancing) will be
triggered based on semi-static PRB usage. It replaces the existing parameter
dlPreventiveLoadControlThresholdOnPrb.
Parameter dlPreventiveLoadControlThresholdOnStaticPrb
ENBEquipment/Enb/LteCell/RadioCacCell
Object
ENBEquipment/Enb/LteCell/RadioCacCell/PreventiveOffload
[0..100] %
Value 80
Feature FRS 115223(.1), FRS 114538, FRS 163172
Rule: Parameter
The setting of this parameter must satisfy the following:
RadioCacCell::dlPreventiveLoadControlThresholdOnStaticPrb must be less

than RadioCacCell::dlAdmissionThresholdOnPrb.
Parameter RadioCacCell::ulPreventiveLoadControlThresholdOnStaticPrb is the

UL threshold (per cell) above which preventive load control (load balancing) will be
triggered based on semi-static PRB usage. It replaces the existing parameter
ulPreventiveLoadControlThresholdOnPrb.
Page 336/472
Parameter ulPreventiveLoadControlThresholdOnStaticPrb
Object
[0..100] %
Value 80
Feature FRS 115223(.1), FRS 114538, FRS 163172
Rule: Parameter

RadioCacCell::ulPreventiveLoadControlThresholdOnStaticPrb must be less
than RadioCacCell::ulAdmissionThresholdOnPrb.
RadioCacEnb::preventiveLoadControlHysteresisTimer
Parameter preventiveLoadControlHysteresisTimer
[500..65000] ms
Value Default: 3000
Notes: This timer runs on a per cell basis starting with LR13.1, and not anymore on a
per eNB basis as in LA6.
Rule: Parameter preventiveLoadControlHysteresisTimer

preventiveLoadControlHysteresisTimer must be greater than
tMeasWaitForOffload (this parameter is described in Volume 6).
Page 337/472
RadioCacEnb::arpThresholdForPreventiveLoadControl
Parameter arpThresholdForPreventiveLoadControl
[1..15]
Value Default: 1
RadioCacEnb::maxNbrOfUsersImpactedByPreventiveLoadControl
Parameter maxNbrOfUsersImpactedByPreventiveLoadControl
[1..1000]

maxNbrOfUsersImpactedByPreventiveLoadControl
This parameter is optional and is <unset> in the ALU template.

When <unset>, there is no limit on the number of users that may be impacted by
preventive load control.
Timer RadioCacEnb::ueTimerNoOffload is used in order to avoid a specific UE

being subject to repeated inter-frequency or inter-RAT handover in a short period.
The timer is started when UE enters a cell through inter-frequency or inter-RAT
handover. When the timer is running, the UE will not be selected for offload (reactive
or preventive). Setting the timer to 0 will deactivate this scheme.
RadioCacEnb::ueTimerNoOffload
Parameter ueTimerNoOffload
[0..5000] with step = 100ms
Value 1000
Feature L114538
Page 338/472
PreventiveOffload::cellNbrOfUsersLoadControlThreshold
Parameter cellNbrOfUsersLoadControlThreshold
Object
[1..100] %
Value 80
Feature FRS 163172
Notes: This parameter is set to the threshold for number of UEs in the cell as a
percentage of maxNbrOfUsers. If isNumUeBasedPreventiveLoadControlEnabled
= True and the threshold is exceeded, then preventive load control (load balancing)
is triggered to neighbor carriers defined by LteNeighboringFreqConf and
UtraFddNeighboringFreqConf MOs with preventiveOffloadLink pointing to this
instance of PreventiveOffload MO. The parameter may be unset if the number of
UEs in the cell is not being used as a trigger for preventive load control.

cellNbrOfUsersLoadControlThreshold
When using this parameter for prioritization of neighbor carriers for preventive
offload purposes, the following may apply:
RadioCacCell/ PreventiveOffload/0 with cellNbrOfUsersLoadControlThreshold

= 65 %
= 75 %
= 85 %
RadioCacEnb::enbNbrOfUsersLoadControlThreshold
Parameter enbNbrOfUsersLoadControlThreshold
[1..100] %
Value N/A
Feature FRS 163172
Page 339/472
Notes: This parameter is set to the threshold for number of UEs in the eNodeB as a
percentage of maxNumberOfCallPerEnodeB. When the threshold is exceeded,
preventive load control (load balancing) is triggered. Unset if not using number of
UEs in the eNB as a trigger for preventive load control.
QciConfForOffload::qCI
Parameter qCI
Object ENBEquipment/Enb/ LteCell/RadioCacCell/QciConfForOffload
[1..255]
Value N/A
Feature FRS 163172
Note: This parameter identifies the value of the QoS Class Identifier (QCI).
preventiveLoadControlThresholdNbrOfActiveUsers: This parameter specifies the

threshold in terms of active users per cell, upon which preventive offload will be
triggered to offload UEs towards less loaded cells. It is defined as a percentage of
maxNbrOfActiveUsersPerCell.
RadioCacCell::preventiveLoadControlThresholdNbrOfActiveUsers
Parameter preventiveLoadControlThresholdNbrOfActiveUsers
Object ENBEquipment/Enb/ LteCell/RadioCacCell/
[0..100] (%)
Value 100 (Default)
Feature FRS 166802
averagingPeriodForNbrActiveUsersPreventiveOffload: This parameter allows

controlling the period over which the number of active users per cell is averaged for
preventive offload.
Page 340/472
RadioCacEnb::averagingPeriodForNbrActiveUsersPreventiveOffload
Parameter averagingPeriodForNbrActiveUsersPreventiveOffload
[100..5000] (ms)
Value 500 (Default)
Feature FRS 166802
ulPreventiveLoadControlThresholdOnRealPrb is used as one condition for trigger

load balancing (in addition to QoS degradation). When the real uplink PRB
consumption in the cell is above this threshold and the QoS deficit hits another
threshold, load balancing is triggered.
RadioCacCell::ulPreventiveLoadControlThresholdOnRealPrb
Parameter ulPreventiveLoadControlThresholdOnRealPrb
Object
[0 .. 100] (%)
Value 100%
Feature 171232, 163172
dlPreventiveLoadControlThresholdOnRealPrb is used as one condition for trigger

load balancing (in addition to QoS degradation). When the real downlink PRB
consumption in the cell is above this threshold and the QoS deficit hits another
threshold, load balancing is triggered.
RadioCacCell::dlPreventiveLoadControlThresholdOnRealPrb
Parameter dlPreventiveLoadControlThresholdOnRealPrb
Object
[0 .. 100] (%)
Value 80%
Feature 171232, 163172
Page 341/472
dlBitRateThresholdForPreventiveLoadControl is used as a condition to trigger

load balancing, in addition to real uplink and downlink PRB consumption. It is
relevant at cell level and only applies to non-GBR bearers.
TrafficRadioBearerConf::dlBitRateThresholdForPreventiveLoadControl
Parameter dlBitRateThresholdForPreventiveLoadControl
Object
ENBEquipment/Enb/LteCell/RadioCacCell/QciConfForOffload
[0 .. 2000] (kbps)
Value 500
Feature 171232; 163172
nbrOfUsersImpactedByQosBasedPreventiveOffload is the target number of users

that the eNB will try to offload when the cumulated QoS deficit (across all non-GBR
QCIs) is at 20% versus the targeted threshold defined by parameter
dlBitRateThresholdForPreventiveLoadControl.
RadioCacEnb::nbrOfUsersImpactedByQosBasedPreventiveOffload
Parameter nbrOfUsersImpactedByQosBasedPreventiveOffload
[0 .. 100]
Value 5
Feature 171232
extraMarginNbUeSelectedPreventiveOffload defines an extra number of UEs that

the eNB may select for making measurements for preventive overload, in order to
make the offload more effective. This margin is required to try and favour for
reselection the UEs that were active in the recent past, as well as costly UEs that are
closer to the cell edge.
Page 342/472
RadioCacEnb::extraMarginNbUeSelectedPreventiveOffload
Parameter extraMarginNbUeSelectedPreventiveOffload
[0 .. 400]
Value 50
Feature 171232
When load balancing is triggered based on real PRB usage and QoS degradation,
Callp will initially avoid triggering inter-frequency handover for UEs that have been
inactive for a period longer than inactivityTimeForPreventiveOffload.
RadioCacEnb::inactivityTimeForPreventiveOffload
Parameter inactivityTimeForPreventiveOffload
[1 .. 10] (s)
Value 10 (default)
Feature 171232
filteringCoefficientForQosBasedPreventiveOffload is the filter coefficient applied

to modem PRB consumption measurements, assigning higher or lower importance to
measurements received in previous periods.
RadioCacEnb::filteringCoefficientForQosBasedPreventiveOffload
Parameter filteringCoefficientForQosBasedPreventiveOffload
Range & Unit Float
[0 .. 1], step = 0.1
Value 0.8
Feature 171232
Page 343/472
5.1.5.1 LOAD EQUALIZATION
Load equalization triggering (introduced in LR13.1 by feature L114538): early

equalization of load between LTE carriers is allowed when the load delta between
the target and serving cell is above a configurable threshold (target cell load is lower
than serving cell load). This requires a new load threshold in advance of the
preventive offload thresholds, so that load equalization between LTE carriers can be
triggered very early. In this case, the load is in terms of semi-static PRB usage only.
LR13.3 introduces the possibility to distinguish VoIP users for load balancing
purposes. For further details please refer to previous section Preventive Offload and
parameter RadioCacEnb::isVoipOffloadEnabled.
The RadioCacCell::LoadEqualizationDeltaThreshold parameter allows triggering

load equalization between carriers, before preventive offloading is triggered. It is a
negative offset to be applied on the preventive offload threshold for static PRB
usage. Value 0 means that load equalization is deactivated.
RadioCacCell::loadEqualizationDeltaThreshold
Parameter loadEqualizationDeltaThreshold
[0..100] %
Value Default: 0 (deactivated)
Feature FRS 114538
This parameter is only relevant if load equalization is activated for at least one
neighbor carrier (isLoadEqualizationEnabled = True). For more details on this
parameter, see Section 5.4.4.2 from Volume 6.

LoadEqualizationDeltaThreshold
This parameter should be set to a value different than 0 (for example 20%) in
order to have different triggering thresholds for load equalization and preventive
offloading (in order for load equalization to be triggered earlier than preventive
offloading).
For load equalization to be triggered, the serving cell load (PRB usage) needs to be
at:
ul/dlPreventiveLoadControlThresholdOnStaticPrb - LoadEqualizationDeltaThreshold
Page 344/472
When triggering preventive offload for load equalization (based on semi-static PRB
usage), the target cell must be less loaded than the source cell by this percentage,
otherwise it will not be considered as a valid target for load balancing.
RadioCacEnb::ThresholdRelativePreventiveOffload
Parameter ThresholdRelativePreventiveOffload
[0..100] %
Value Default: 20
Feature FRS 114538
This parameter is only relevant if load equalization is activated for at least one
neighbor carrier (isLoadEqualizationEnabled = True). For more details on this
parameter, see Section 5.4.4.2 from Volume 6.
This parameter represents the delta in load required between serving and target cell
for load equalization to be triggered.
This parameter was introduced to avoid the un-necessary ping ponging between two
carriers/bands that can be caused when the load on both bands exceed the
preventive offloading threshold and UE is offloaded between bands.
Parameter isFddTddRedirectionForPreventiveOffloadEnabled allows enabling /

disabling FDD/TDD redirection for preventive offload. This activation flag will control
whether or not FDD/TDD redirection for preventive offload is activated or not.
ActivationService::isFddTddRedirectionForPreventiveOffloadEnabled
Parameter isFddTddRedirectionForPreventiveOffloadEnabled
True/False
Class/Source C--Immediate-propagation
Feature FRS 114538
Page 345/472
Rule: Parameter isFddTddRedirectionForPreventiveOffloadEnabled
This flag must be set to False since this capability is not supported in LR13.1 and
LR13.3.
Although coding was performed in LR13.1 to allow FDD/TDD Redirection for

preventive offload, this functionality is not supported by the ALU eNB.
5.1.5.2 CONNECTION LOADING REDUCTION
In LR13.3 FRS 166802 allows eNB equipped with bCEM to support more connected
users on top of the active users capacity supported in the LR13.1. To support this
increased capacity, FRS 166802 also provides a new mechanism of reduction of
connection loading.
Upon a new connection admission, the cell shall release the longest dormant OOT
user if following conditions are satisfied:
• The number of the total connections in the cell or the eNB after the new
connection admission exceeds a critical threshold (configurable)
(cuLoadingThreshForEarlyOOTRelease), and
• The longest dormant OOT user has been dormant for at least a minimum
amount of time (configurable) (minInactiveTimeForEarlyOOTRelease).
• The minimum interval (configurable) (pacingTimerForEarlyOOTRelease)
between two consecutive early OOT user releases is satisfied, in order to
avoid bursty signaling load addition
RadioCacEnb::cuLoadingThreshForEarlyOOTRelease
Parameter cuLoadingThreshForEarlyOOTRelease
[0..100] %
Value 100 (Default)
Feature FRS 166802
Page 346/472
RadioCacEnb::minInactiveTimeForEarlyOOTRelease
Parameter minInactiveTimeForEarlyOOTRelease
[0.0..60.0] step 0.1 (unit = second)
Value 2 (Default)
Feature FRS 166802
RadioCacEnb::pacingTimerForEarlyOOTRelease
Parameter pacingTimerForEarlyOOTRelease
[0.0..5.0] step 0.1 (unit = second)
Value 0 (Default)
Feature FRS 166802
5.2 CAPACITY LICENSING

Some eNB capacity aspects are controlled by Capacity Licensing. This feature
serves as the technical base for proposing a “Pay-as-you-grow” commercial scheme
to LTE eUTRAN Operators.
With Capacity Licensing, the operator can order some eNB HW components with a
reduced capacity and subsequently purchase licenses for additional SW capacity.
This SW capacity is expressed in Tokens (also called RTUs = Rights To Use).
5.2.1 CAPACITY LICENSING HIGH LEVEL DESCRIPTION

Following capacity ordering (Purchase Order) placed for a specific number of eNB
capacity resources, a license is created with ALU Licensing tool (also called LKDI).
This License is available through an encrypted file, protected by a digital signature.
The license (file) is installed into SAM via an application called RAN License
Manager (RAN LM). This license will create at SAM a pool of Tokens (RTUs)
available for all eNBs handled by the SAM.
The operator can then distribute the pool of available capacity tokens between all
eNB(s) via specific OAM parameters.
Page 347/472
SAM/RAN LM
Capacity Tokens (RTUs) License file created and

purchased by operator entered into SAM/WLM
eNB(s) capacity controlled via

specific licensing parameters
configured at SAM
eNodeB eNodeB eNodeB eNodeB
Figure 22: Capacity Licensing Principle
These Licensing parameters are permanently checked by SAM (RAN LM) in order
not to exceed global license capacity provided by the License file:
If the above mentioned SAM check fails for one of the licensed resources, the
configuration of that specific capacity element is blocked on all eNBs under the SAM
(and the configuration work-order is rejected).
The following eNB capacity elements are managed:

• Transmission Power (per cell)
• Number of Active users per eNB (per eNB)
• Allocated Operating Bandwidth (per cell)
The table below shows how the eNB resources are managed by Capacity Licensing
and summarizes the units and capacity increase steps for each area:
Page 348/472
Resource Unit Licensed Capacity licensing

resource step token unit
Transmission RRH/TRDU allocated 10W/PA (**) 1 token

Power power in W per PA
(*)
Number of Connected users per 8 (users) 1 token

connected users eNB
Allocated Radio Bandwidth per N.A. 1 token (per type of

bandwidth cell (MHz) bandwidth)
Table 24 : eNB Resources controlled by Capacity Licensing in LA4.0
(*) One RRH2x or TRDU2x is considered to contain 2 PA(s)
(**) 20W are provided by default (10 W per PA).

Only one license file is used for all three eNB resources (transmission power,
number of active users, allocated bandwidth), each resource is handled in a separate
area of the same file.
5.2.2 LICENSING PARAMETERS VS. CONFIGURATION

PARAMETERS
For the three resources handled by Licensing, three Configuration Parameters (or set
of parameters) are used:
• The Transmission Power is controlled through cellDlTotalPower
configured at cell level (object LteCell) (see section 6.1.1.1).
• Number of Active Users is controlled through
maxNumberOfCallPerEnodeB configured at eNB level (object
RadioCacEnb) – as explained in section 5.
• Allocated Bandwidth is controlled through parameters: ulBandwidth and
dlBandwidth configurable at cell level (see [Vol. 3]).
The Licensing is managed by OAM (SAM) for the licensing rule check.
This section shows how the above-mentioned parameters are converted into tokens
and compared against the license file content.
Page 349/472
5.2.2.1 TRANSMISSION POWER
SAM sums up eNBNbOfCallTokens of all eNBs it manages to obtain the total amount
of Power tokens used and compare it with the value provided in the license (i.e.
number of purchased Power Tokens).
eNBTxPowerTokens depends on the Licensing commercial agreement and configured

value of cellDlTotalPower parameter.
• If capacity licensing is not activated (infinite license file is installed at SAM for
the Transmission Power, eNBNbOfCallTokens is set to “infinite” value.
• If capacity licensing is activated (finite license file is installed at SAM), this
eNBNbOfCallTokens is computed as follows:
eNBTxPowerTokens = CellαTxPowerTokens + CellβTxPowerTokens + CellγTxPowerTokens

Where:
C ellαTxPow erTok  
ens = 10(0.1×C ellD lTotalP ow er( cellα ) − 4 ) × num berO fDA (cellα )
Lntennas
ens = 10
C ellβTxPow erTok ( lPow er( cellβ ) − 4 )
0.1×C ellD lTota
 × num berO fDALntennas(cellβ )
ens = 10(0.1×C ellD lTotalPow er( cellγ ) − 4 )  × num berO fDA
C ellγTxPow erTok Lntennas(cellγ )
For a better understanding of CellTxPowerTokens computation formula, here is an

example of Power token computation for different values of cellDlTotalPower:
Page 350/472
cellDlTotalPower (cell Power (W) per PA Cell[α,β,γ]TxPowerTokens

[α,β,γ]) (dBm) (i.e. per antenna)
≤ 40.0 ≤ 10 numberOfDLAntennas × 1 = 2
40.1 10.23 numberOfDLAntennas × 2 = 4
Table 25 : Example of Power_Token_Cell for different cellDlTotalPower values and

numberOfDLAntennas = 2.
The Transmission Power Licensing configuration is summarized in Figure 25.
Figure 23: Transmission Power Licensing
Page 351/472
5.2.2.2 NUMBER OF ACTIVE USERS
SAM sums up eNBNbOfCallTokens of all eNBs it manages to obtain the total amount
of Active Users tokens used and compare it with the value provided in the license
(i.e. number of purchased Active Users Tokens).
In LA6.0, the maximum number of Simultaneous Active Users is the same as the
maximum number of RRC connected users. Therefore, eNBNbOfCallTokens is in
direct relation with parameter maxNumberOfCallPerEnodeB.
eNBNbOfCallTokens depends on the Licensing commercial agreement and configured

value of parameter maxNumberOfCallPerEnodeB:
• If capacity licensing on the number of active users is not activated (infinite
license file is installed in SAM), eNBNbOfCallTokens is set to “infinite” value.
• If capacity licensing is activated (finite license file is installed in SAM),
eNBNbOfCallTokens is computed as follows:
eNBNbOfCallTokens = RoundUp(maxNumberOfCallPerEnodeB / 8)
The Active Users Licensing configuration is summarized in Figure 26.
Figure 24: Number of Active Users Licensing
Page 352/472
5.2.2.3 ALLOCATED BANDWIDTH
SAM sums up eNB1_4MHzTokens, eNB3MHzTokens, eNB5MHzTokens,

eNB10MHzTokens, eNB15MHzTokens and eNB20MHzTokens of all eNBs it manages to
respectively obtain the total amount of 1.4MHz tokens, 3MHz tokens, 5MHz Tokens,
10 MHz Tokens, 15 MHz Tokens and 20 MHz Tokens used and compare them with
the values associated bandwidths in the license (i.e. number of purchased 1.4 MHz
Tokens, 3MHz Tokens, 5MHz Tokens, 10MHz Tokens, 15MHz Tokens and 20MHz
tokens, respectively).
eNBTxPowerTokens depends on the Licensing commercial agreement and configured

value of the cellDlTotalPower parameter.
• If capacity licensing is not activated (infinite license file is installed at SAM,
eNB1_4MHzTokens, eNB3MHzTokens, eNB5MHzTokens, eNB10MHzTokens ,
eNB15MHzTokens and eNB20MHzTokens are set to “infinite” value.
• If capacity licensing is activated (finite license file is installed at SAM), this
eNB1_4MHzTokens, eNB3MHzTokens, eNB5MHzTokens, eNB10MHzTokens ,
eNB15MHzTokens and eNB20MHzTokens are computed as follows:
o eNB1_4MHzTokens = Cellα1_4MHzTokens + Cellβ1_4MHzTokens +
Cellγ 1_4MHzTokens
o eNB3MHzTokens = Cellα3MHzTokens + Cellβ 3MHzTokens + Cellγ
3MHzTokens
o eNB5MHzTokens = Cellα5MHzTokens + Cellβ 5MHzTokens + Cellγ

5MHzTokens
o eNB10MHzTokens = Cellα10MHzTokens + Cellβ10MHzTokens + Cellγ
10MHzTokens
o Enb15MHzTokens = Cellα15MHzTokens + Cellβ15MHzTokens +
Cellγ15MHzTokens
o Enb20MHzTokens = Cellα20MHzTokens + Cellβ20MHzTokens +

Cellγ20MHzTokens
With:
o Cell[α,β,γ]1_4MHzTokens is set to 1 if dlBandwidth=ulBandwidth=

n6-1_4MHz and to 0 otherwise.
o Cell[α,β,γ]3MHzTokens is set to 1 if dlBandwidth=ulBandwidth=
n15-3MHz and to 0 otherwise.

Page 353/472

Restriction: Supported Bandwidths
In LA6.0, 15MHz bandwidth is not supported. This restriction is lifted in LR13.1.
The Bandwidth Licensing is summarized in Figure 27.
Figure 25: Bandwidth licensing example with 10 MHz for all the cells
5.2.3 “E2E” LICENSING CONFIGURATION EXAMPLE

Considering a small network composed of 5 eNBs handling 3 cells each (this is just
an example), for which the Radio Design and Network Dimensioning exercise
requires:
• 10 MHz bandwidth (for each of the 3 cells of each eNB)
Page 354/472
• 48 Active users per eNB

• No restriction in terms of Tx Power per cell
This can be translated in a total need of Licensing tokens per eNB of:
• 3 10 MHz BW Tokens
• 6 Active Users Tokens per eNB (8 users  1 token)
• Infinite Tx Power Tokens
For the entire network:

• 15 10 MHz BW Tokens
• 30 Active Users Tokens per eNB (8 users  1 token)
• Infinite Tx Power Tokens
This Licensing Tokens quantity will need to be ordered and will be included in the
encrypted License file (created via LKDI tool). On each eNB, the following settings
are used:
• ulBandwidth = n50-10MHz (for each of the 3 cells)

• dlBandwidth = n50-10MHz (for each of the 3 cells)
• maxNumberOfCallPerEnodeB = 48
• cellDlTotalPower = 46 dBm (on each of the 3 cells)
Page 355/472
The example presented above is depicted in Figure 28.
Figure 26: Capacity Licensing configuration example
Page 356/472
6 TRANSMIT POWER
6.1 DOWNLINK TRANSMIT POWER
6.1.1 POWER SETTINGS

6.1.1.1 CELL DOWNLINK TOTAL POWER
Let Pmax-hardware be the maximum transmit power of one RF Module Power Amplifier,
expressed in dBm (note that there is a one-to-one “power amplifier-to-transmit
antenna” mapping).
The hardware equipments for macro eNB available in LR13.1 have one of the
following power capacities:
• 30 Watts (Pmax-hardware = 44.7 dBm)
The hardware equipments for Metro eNB available in LR13.1 have one of the
following power capabilities
• 1 Watt (Pmax-hardware = 30 dBm)
• 5 Watts (Pmax-hardware = 37 dBm)
Parameter cellDLTotalPower is used, if need be, to impose additional limits on the

total power transmitted by a power amplifier, notably in conjunction with power
capacity licensing (see section 5.2.2.1).
Rule: Parameter cellDLTotalPower
If this parameter is set to a value higher than Pmax-hardware, the cell setup will fail and
an alarm will be generated by the eNB as a result of that.
The value of cellDLTotalPower is converted into linear scale according to the

following equation
PMax [mW ] = 10cellDLTotalPower/ 10
Page 357/472
LteCell::cellDLTotalPower
Parameter cellDLTotalPower
Range & Unit Float
[0.0..50.0] step=0.1 dBm
Class/Source See Rule below / customer_settable
Feature
Rule: Regarding parameter cellDLTotalPower
In LA6.0, if this parameter is changed, then the associated modem should be

manually reset.
Engineering Recommendation: Parameter cellDLTotalPower
As explained in section 5.2.2.1, the available transmit power per power amplifier is
controlled by licensing. Consequently, the value of parameter cellDLTotalPower
must not exceed certain values, as illustrated in the table below:
Power Amplifier hardware Transmission Power Maximum possible value for

capability (resulting from the parameter cellDLTotalPower
token distribution, as
explained in section
5.2.2.1)
30 W 20 W 43.0
30 W 44.7
40 W 20 W 43.0
30 W 44.7
40 W 46.0
60 W 20 W 43.0
30 W 44.7
40 W 46.0
60W 47.7
Note that the “Maximum possible value for parameter cellDLTotalPower” column also
represents the default setting of parameter cellDLTotalPower.
Page 358/472
Engineering Recommendation: Parameter cellDLTotalPower for Metro
There is no license control on the available transmit power per power amplifier for
Metro eNB. Consequently, the value of parameter cellDLTotalPower must not
exceed the power amplifier hardware capability:
Power Amplifier hardware Maximum possible value for parameter

capability cellDLTotalPower
1W 30.0
5W 37.0
Note that the “Maximum possible value for parameter cellDLTotalPower” column also
represents the default setting of parameter cellDLTotalPower.
6.1.1.2 REFERENCE SIGNAL POWER SETTING
Parameter referenceSignalPower configures the Cell RS absolute power applied

per Resource Element (RE) and per transmit antenna. This level is used as a power
level reference (the power levels for all the other DL signals and channels are set
relative to it).
Note that parameter referenceSignalPower must be comprised between

minRefSigPower and maxRefSigPower, which respectively specify the upper and
lower bounds of referenceSignalPower within which the cell's RFM operates
properly.
Also note that as part of the Cell Shrink capability, the per RE RS power configured
by referenceSignalPower is reduced in case of S1 link outage, or Cell Barring or
Cell Blocking. The reduction is configured by parameters
cellShrinkForS1LinksOutage, cellShrinkForOamBarring and
cellShrinkForCallsDraining for these 3 events, respectively (see [Vol. 5] for more
details).
As parameter referenceSignalPower provides a lower bound for the per RE RS
power, parameters cellShrinkForS1LinksOutage, cellShrinkForOamBarring and
cellShrinkForCallsDraining should satisfy the conditions
• referenceSignalPower – cellShrinkForS1LinksOutage ≥ minRefSigPower
• referenceSignalPower – cellShrinkForOamBarring ≥ minRefSigPower
• referenceSignalPower – cellShrinkForCallsDraining ≥ minRefSigPower
Parameters minRefSigPower and maxRefSigPower should not be changed without

an agreement from ALU.
Page 359/472
PowerOffsetConfiguration::referenceSignalPower
Parameter referenceSignalPower
Object
setConfiguration
[-60..50] dBm
Feature FRS 115217
This parameter is expressed in dBm. It is converted into linear scale (milliwatt)

according to
PREF [mW ] = 10 referenceSignalPower/ 10
Page 360/472
Engineering Recommendation: Parameter referenceSignalPower
This parameter is a key RF optimization parameter that influences the cell

coverage. It is set according to the cell size. The higher the setting, the larger the
cell coverage on the downlink, but leaves smaller power headroom available for
other downlink signals and channels.
The default setting for parameter referenceSignalPower is as follows:
transmissionMode cellDLTotalPower dlBandwidth referenceSignalPower
tm1 43.0 n6-1_4MHz 27
n15-3MHz 23
n25-5MHz 21
n50-10MHz 18
n75-15MHz 16
(Not Supported)
n100-20MHz 15
44.7 n6-1_4MHz 29
n15-3MHz 25
n25-5MHz 22
n50-10MHz 19
n75-15MHz 18
(Not Supported)
n100-20MHz 16
46.0 n6-1_4MHz 30
n15-3MHz 26
n25-5MHz 24
n50-10MHz 21
n75-15MHz 19
(Not Supported)
n100-20MHz 18
47.7 n6-1_4MHz 32
n15-3MHz 28
n25-5MHz 25
n50-10MHz 22
n75-15MHz 21
(Not Supported)
n100-20MHz 19
Page 361/472
30.0 [Metro Cell] n25-5MHz 8
n50-10MHz 5
n50-10MHz 12
tm2, tm3, tm4 43.0 n6-1_4MHz 27
n15-3MHz 23
n25-5MHz 21
n50-10MHz 18
n75-15MHz 16
(Not Supported)
n100-20MHz 15
44.7 n6-1_4MHz 29
n15-3MHz 25
n25-5MHz 22
n50-10MHz 19
n75-15MHz 18
(Not Supported)
n100-20MHz 16
46.0 n6-1_4MHz 30
n15-3MHz 26
n25-5MHz 24
n50-10MHz 21
n75-15MHz 19
(Not Supported)
n100-20MHz 18
47.7 n6-1_4MHz 32
n15-3MHz 28
n25-5MHz 25
n50-10MHz 22
n75-15MHz 21
(Not Supported)
n100-20MHz 19
n50-10MHz 5
Page 362/472
n50-10MHz 12
TxPowerDynamicRange::maxRefSigPower
Parameter maxRefSigPower
Object
setConfiguration/TxPowerDynamicRange
[-10..40] dBm
Class/Source N.A. / eng_tunable
Feature FRS 115217
The parameter maxRefSigPower specifies the upper bound of

referenceSignalPower above which the cells RRH/TRDU will not operate properly
and ACLR (adjacent channel leakage ratio) level is strictly limited by FCC and ETSI
regulations. The value is derived from the power settings of the cell. This parameter
shall not be changed without an agreement from ALU.
Page 363/472
Engineering Recommendation: Parameter maxRefSigPower
The current setting for parameter maxRefSigPower is as follows:
transmissionMode cellDLTotalPower dlBandwidth maxRefSigPower
tm1 43.0 n6-1_4MHz 27
n15-3MHz 23
n25-5MHz 21
n50-10MHz 18
n75-15MHz 16
(Not Supported)
n100-20MHz 15
44.7 n6-1_4MHz 29
n15-3MHz 25
n25-5MHz 22
n50-10MHz 19
n75-15MHz 18
(Not Supported)
n100-20MHz 16
46.0 n6-1_4MHz 30
n15-3MHz 26
n25-5MHz 24
n50-10MHz 21
n75-15MHz 19
(Not Supported)
n100-20MHz 18
47.7 n6-1_4MHz 32
n15-3MHz 28
n25-5MHz 25
n50-10MHz 22
n75-15MHz 21
(Not Supported)
n100-20MHz 19
n50-10MHz 5
Page 364/472
n50-10MHz 9
tm2, tm3, tm4 43.0 n6-1_4MHz 27
n15-3MHz 23
n25-5MHz 21
n50-10MHz 18
n75-15MHz 16
(Not Supported)
n100-20MHz 15
44.7 n6-1_4MHz 29
n15-3MHz 25
n25-5MHz 22
n50-10MHz 19
n75-15MHz 18
(Not Supported)
n100-20MHz 16
46.0 n6-1_4MHz 30
n15-3MHz 26
n25-5MHz 24
n50-10MHz 21
n75-15MHz 19
(Not Supported)
n100-20MHz 18
47.7 n6-1_4MHz 32
n15-3MHz 28
n25-5MHz 25
n50-10MHz 22
n75-15MHz 21
(Not Supported)
n100-20MHz 19
n50-10MHz 5
n50-10MHz 9
Page 365/472
TxPowerDynamicRange::minRefSigPower
Parameter minRefSigPower
Object
setConfiguration/TxPowerDynamicRange
[-40..40] dBm
Class/Source N.A. / eng_tunable
Feature FRS 115217
The parameter minRefSigPower specifies the lower bound of referenceSignalPower

below which the cells RRH/TRDU may not operate properly. The value is derived
from the power settings of the cell and managed by ALU Templates. Note: A value
close to minRefSigPower is to minimize RSRP (as measured by UEs in neighbor
cells) and not for high fidelity of signal. An example is cellShrinkForS1LinksOutage.
This parameter shall not be changed without an agreement from ALU.
Page 366/472
Engineering Recommendation: Parameter minRefSigPower
The current setting for parameter minRefSigPower is as follows:
transmissionMode cellDLTotalPower dlBandwidth minRefSigPower
tm1 43.0 n6-1_4MHz -1
n15-3MHz -7
n25-5MHz -8
n50-10MHz -8
n75-15MHz
-8
(Not Supported)
n100-20MHz -8
44.7 n6-1_4MHz 2
n15-3MHz -5
n25-5MHz -7
n50-10MHz -7
n75-15MHz
-6
(Not Supported)
n100-20MHz -7
46.0 n6-1_4MHz 2
n15-3MHz -4
n25-5MHz -5
n50-10MHz -5
n75-15MHz
-5
(Not Supported)
n100-20MHz -5
47.7 n6-1_4MHz 5
n15-3MHz -2
n25-5MHz -4
n50-10MHz -4
n75-15MHz
-3
(Not Supported)
n100-20MHz -4
30.0 [Metro Cell] n25-5MHz -21
n50-10MHz -21
Page 367/472
n50-10MHz -14
tm2, tm3, tm4 43.0 n6-1_4MHz -1
n15-3MHz -7
n25-5MHz -8
n50-10MHz -8
n75-15MHz
-9
(Not Supported)
n100-20MHz -9
44.7 n6-1_4MHz 2
n15-3MHz -5
n25-5MHz -7
n50-10MHz -7
n75-15MHz
-7
(Not Supported)
n100-20MHz -7
46.0 n6-1_4MHz 2
n15-3MHz -4
n25-5MHz -5
n50-10MHz -5
n75-15MHz
-6
(Not Supported)
n100-20MHz -6
47.7 n6-1_4MHz 5
n15-3MHz -2
n25-5MHz -4
n50-10MHz -4
n75-15MHz
-4
(Not Supported)
n100-20MHz -4
n50-10MHz -21
n50-10MHz -14
Page 368/472
6.1.1.3 POSITIONING REFERENCE SIGNAL POWER SETTING
Parameter prsPowerOffset configures the transmit power per RE and per transmit
antenna (expressed in dB relative to PREF ) for the PRS.
This parameter is expressed in dB, relative to the RS power, PREF. It is converted into
linear scale (milliwatt) as follows
PPRS [mW ] = PREF × 10 prsPowerOffset / 10
PowerOffsetConfiguration::prsPowerOffset
Parameter prsPowerOffset
Object
setConfiguration
Range & Unit Float
[-25.6..25.5] step = 0.1dB
O.D. (ALU default: 0.0)
Value
ALU recommends the operator to not change this setting
Restriction : LR13.3L OTDOA is not supported on MRO
OTDOA feature is not supported on MRO. To avoid any PRS interference, feature
170733 provides OTDOA PRS interference avoidance on MRO (Metro Radio
Outdoor). On MRO, prsPowerOffset shall always be set to -25.6dB because its
PRS signal shall not be used for OTDOA.
Restriction : On MCO, the full range of values for prsPowerOffset is not

supported.
For MCO, the range of values supported is reduced to [-6dB,+4dB] in LR13.3 and
[-12dB,+12dB] in LR14.1.
Page 369/472
6.1.1.4 SYNCHRONIZATION SIGNALS POWER SETTING
Parameters primarySyncSignalPowerOffset and

secondarySyncSignalPowerOffset configure the transmit power per RE and per
transmit antenna (expressed in dB relative to PREF ) for the primary synchronization
channel and the secondary synchronization channel, respectively.
These 2 parameters are expressed in dB, relative to the RS power, PREF. They are
converted into linear scale (milliwatt) as follows:
• PP − SCH [mW ] = PREF × 10 primarySyncSignalPowerOffset / 10 if the primary

synchronization signal is transmitted on one antenna (i.e. in case of transmit
antenna or in case of 2 transmit antenna and
isSyncSignalsDiversityAllowed =False).
• PP − SCH [mW ] = PREF × 10 (primarySyncSignalPowerOffset −3) / 10 in case of 2 transmit
antennas and isSyncSignalsDiversityAllowed =True (not supported in
LA6.0). In this case, the primary synchronization channel is transmitted at -
3dB compared to the parameter setting due to the fact that the transmit
power is shared between the 2 antennas.
• PS − SCH [mW ] = PREF × 10 secondarySyncSignalPowerOffset / 10 if the primary

synchronization signal is transmitted on one antenna (i.e. in case of one
transmit antenna or in case of 2 transmit antennas and
isSyncSignalsDiversityAllowed set to “False”).
• PS − SCH [mW ] = PREF × 10 (secondarySyncSignalPowerOffset −3) / 10 in case of 2 transmit
antennas and isSyncSignalsDiversityAllowed set to “True” (not supported
in LA6.0). In this case, the secondary synchronization channel is transmitted
at - 3dB compared to the parameter setting due to the fact that the transmit
power is shared between the 2 antennas.
Page 370/472
PowerOffsetConfiguration::primarySyncSignalPowerOffset
Parameter primarySyncSignalPowerOffset
Object
setConfiguration
Range & Unit Float
[-25.6..25.5] step = 0.1dB
Feature
PowerOffsetConfiguration::secondarySyncSignalPowerOffset
Parameter secondarySyncSignalPowerOffset
Object
setConfiguration
Range & Unit Float
[-25.6..25.5] step = 0.1dB
Feature
Page 371/472
Engineering Recommendation: Parameters primarySyncSignalPowerOffset

and secondarySyncSignalPowerOffset
These two parameters are key RF optimization parameters: Larger values

facilitate cell synchronization at the UE within the cell coverage area, but reduce
the amount of power available for traffic channels. Smaller settings will impair cell
synchronization at the UE.
The current default settings for parameters primarySyncSignalPowerOffset and
secondarySyncSignalPowerOffset are the following
transmissionMode cellDLTotalPower dlBandwidth primarySyncSignalPo

werOffset
tm1 43.0 n6-1_4MHz -2.0
n15-3MHz -1.4
n25-5MHz -1.5
n50-10MHz - 0.8
n75-15MHz 1.4
(Not Supported)
n100-20MHz 0.2
44.7 n6-1_4MHz -2.3
n15-3MHz -2.0
n25-5MHz 0.0
n50-10MHz 0.0
n75-15MHz -0.8
(Not Supported)
n100-20MHz 0.0
46.0 n6-1_4MHz -2.0
n15-3MHz -1.5
n25-5MHz -1.5
n50-10MHz - 0.8
n75-15MHz 0.0
(Not Supported)
n100-20MHz 0.0
47.7 n6-1_4MHz -2.3
n15-3MHz -2.0
n25-5MHz 0.6
n50-10MHz 1.5
Page 372/472
n75-15MHz -0.8
(Not Supported)
n100-20MHz 0.0
30.0 [Metro Cell] n25-5MHz -1.5
n50-10MHz -0.9
n50-10MHz -0.8
tm2, tm3, tm4 43.0 n6-1_4MHz -2.0
n15-3MHz -1.4
n25-5MHz -1.5
n50-10MHz - 0.8
n75-15MHz 1.4
(Not Supported)
n100-20MHz 0.2
44.7 n6-1_4MHz -2.3
n15-3MHz -2.0
n25-5MHz 0.0
n50-10MHz 0.0
n75-15MHz -0.8
(Not Supported)
n100-20MHz 0.0
46.0 n6-1_4MHz -2.0
n15-3MHz -1.4
n25-5MHz -1.5
n50-10MHz -0.8
n75-15MHz 0.0
(Not Supported)
n100-20MHz 0.0
47.7 n6-1_4MHz -2.3
n15-3MHz -2.0
n25-5MHz 0.0
n50-10MHz 0.0
n75-15MHz
-0.8
(Not Supported)
Page 373/472
n100-20MHz 0.0
n50-10MHz -0.9
n50-10MHz -0.8
transmissionMode cellDLTotalPower dlBandwidth secondarySyncSignal

PowerOffset
tm1 43.0 n6-1_4MHz -2.0
n15-3MHz -1.4
n25-5MHz -1.5
n50-10MHz - 0.8
n75-15MHz
1.4
(Not Supported)
n100-20MHz 0.2
44.7 n6-1_4MHz -2.3
n15-3MHz -2.0
n25-5MHz 0.0
n50-10MHz 0.0
n75-15MHz
-0.8
(Not Supported)
n100-20MHz 0.0
46.0 n6-1_4MHz -2.0
n15-3MHz -1.5
n25-5MHz -1.5
n50-10MHz - 0.8
n75-15MHz
0.0
(Not Supported)
n100-20MHz 0.0
47.7 n6-1_4MHz -2.3
n15-3MHz -2.0
n25-5MHz 0.6
n50-10MHz 1.5
n75-15MHz -0.8
Page 374/472
(Not Supported)
n100-20MHz 0.0
n50-10MHz -0.9
n50-10MHz -0.8
tm2, tm3, tm4 43.0 n6-1_4MHz -2.0
n15-3MHz -1.4
n25-5MHz -1.5
n50-10MHz - 0.8
n75-15MHz
1.4
(Not Supported)
n100-20MHz 0.2
44.7 n6-1_4MHz -2.3
n15-3MHz -2.0
n25-5MHz 0.0
n50-10MHz 0.0
n75-15MHz
-0.8
(Not Supported)
n100-20MHz 0.0
46.0 n6-1_4MHz -2.0
n15-3MHz -1.4
n25-5MHz -1.5
n50-10MHz - 0.8
n75-15MHz
0.0
(Not Supported)
n100-20MHz 0.0
47.7 n6-1_4MHz -2.3
n15-3MHz -2.0
n25-5MHz 0.0
n50-10MHz 0.0
n75-15MHz
-0.8
(Not Supported)
n100-20MHz 0.0
Page 375/472
n50-10MHz -0.9
n50-10MHz -0.8
6.1.1.5 ANTENNA PORT4 (MBSFN RS AND PMCH) POWER SETTING
Parameter port4PowerOffset configures the transmit power per RE (expressed in

dB relative to PREF ) for MBSFN RS and PMCH on antenna port 4.
PPMCH & MBSFNRS [mW ] = PREF × 10 port4PowerOffset / 10
PowerOffsetConfiguration::port4PowerOffset
Parameter port4PowerOffset
Object
setConfiguration
Range & Unit Float
[-25.6..25.5] step = 0.1dB
Value -3.0 ALU recommends the operator to not change this setting
Feature FRS 115527
6.1.1.6 PBCH POWER SETTING
Parameter pBCHPowerOffset configures the transmit power per RE and per

transmit antenna (expressed in dB relative to PREF ) for the PBCH channel.
Page 376/472
PowerOffsetConfiguration::pBCHPowerOffset
Parameter pBCHPowerOffset
Object
setConfiguration
Range & Unit Float
[-25.6..25.5] step = 0.1dB
Feature
• PPBCH [mW ] = PREF × 10 pBCHPowerOffset /10 with one transmit antenna.

• PPBCH [mW ] = PREF × 10 ( pBCHPowerOffset −3) /10 with 2 transmit antennas. In this
case, PBCH is transmitted at - 3dB compared to the parameter setting due to
TxDiv encoding.
Engineering Recommendation: Parameter pBCHPowerOffset
Parameter pBCHPowerOffset is a key RF optimization parameter: The higher the

setting, the more robust the PBCH reception within the cell coverage area, but this
reduces the power available for other downlink signals and channels.
The current default setting for parameter pBCHPowerOffset is the following
transmissionMode pBCHPowerOffset
tm1 -3.0
tm2, tm3, tm4 0.0
6.1.1.7 PCFICH POWER SETTING
Parameter pCFICHPowerOffset configures the transmit power per RE and per

transmit antenna (expressed in dB relative to PREF ) for the PCFICH.
Page 377/472
PowerOffsetConfiguration::pCFICHPowerOffset
Parameter pCFICHPowerOffset
Object
setConfiguration
Range & Unit Float
[-25.6..25.5] step = 0.1dB
Feature
• PPCFICH [mW ] = PREF × 10 pCFICHPowerOffset /10 with one transmit antenna.

• PPCFICH [mW ] = PREF × 10 ( pCFICHPowerOffset −3) /10 with 2 transmit antennas. In this
case, PCFICH is transmitted at - 3dB compared to the parameter setting due
to TxDiv encoding.
Page 378/472
Engineering Recommendation: Parameter pCFICHPowerOffset
This is a key RF optimization parameter: The higher the setting, the more robust
the CFI reception within the cell coverage area, but this reduces the power
available for other downlink signals and channels. Smaller settings will impair CFI,
hence PDCCH reception.
The current default setting for parameter pCFICHPowerOffset is the following
transmissionMode cellDLTotalPower dlBandwidth pCFICHPowerOffset
n6-1_4MHz -1.0
n15-3MHz 0.1
n25-5MHz 0.3
43.0 n50-10MHz 1.0
n75-15MHz
2.0
(Not Supported)
n100-20MHz 1.4
n6-1_4MHz -1.4
n15-3MHz -0.5
n25-5MHz 1.9
44.7 n50-10MHz 2.6
n75-15MHz
1.2
(Not Supported)
tm1 n100-20MHz 3.2
n6-1_4MHz -1.0
n15-3MHz 0.1
n25-5MHz 0.4
46.0 n50-10MHz 1.0
n75-15MHz
2.0
(Not Supported)
n100-20MHz 1.4
n6-1_4MHz -1.4
n15-3MHz -0.5
n25-5MHz 1.9
47.7
n50-10MHz 2.6
n75-15MHz
1.4
(Not Supported)
Page 379/472
n100-20MHz 3.2
30.0 [Metro Cell] n25-5MHz 0.4
n50-10MHz 1.0
n50-10MHz 1.0
n6-1_4MHz 2.1
n15-3MHz 3.2
n25-5MHz 3.4
43.0 n50-10MHz 4.0
n75-15MHz
5.0
(Not Supported)
n100-20MHz 4.4
n6-1_4MHz 1.5
n15-3MHz 2.5
n25-5MHz 4.9
44.7 n50-10MHz 5.6
n75-15MHz
4.2
(Not Supported)
n100-20MHz 6.2
tm2, tm3, tm4 n6-1_4MHz 2.1
n15-3MHz 3.2
n25-5MHz 3.4
46.0 n50-10MHz 4.0
n75-15MHz
5.0
(Not Supported)
n100-20MHz 4.4
n6-1_4MHz 1.5
n15-3MHz 2.5
n25-5MHz 4.9
47.7 n50-10MHz 5.6
n75-15MHz
4.2
(Not Supported)
n100-20MHz 6.2
Page 380/472
n50-10MHz 3.9
n50-10MHz 4.0
6.1.1.8 PHICH POWER SETTING
Parameter pHICHPowerOffset configures the transmit power per RE and per

transmit antenna (expressed in dB relative to PREF ) for the PHICH channel.
PowerOffsetConfiguration::pHICHPowerOffset
Parameter pHICHPowerOffset
Object
setConfiguration
Range & Unit Float
[-25.6..25.5] step = 0.1 dB
Feature
• PPHICH [mW ] = PREF × 10 pHICHPowerOffset / 10 with one transmit antenna.

• PPHICH [mW ] = PREF × 10 ( pHICHPowerOffset −3) / 10 with 2 transmit antennas. In this
case, PHICH is transmitted at - 3dB compared to the parameter setting due
to TxDiv encoding.
Page 381/472
Engineering Recommendation: Parameter pHICHPowerOffset
This parameter is a key RF optimization parameter: The higher the setting, the
more robust the PHICH reception within the cell coverage area, but this reduces
the power available for other downlink signals and channels. Smaller settings
impair PHICH reception causing many retransmissions and hence lower uplink
throughputs.
The current default setting for parameter pHICHPowerOffset is as follows
transmissionMode cellDLTotalPower dlBandwidth pHICHPowerOffset
tm1 43.0 n6-1_4MHz -4.8
n15-3MHz -4.0
n25-5MHz -3.9
n50-10MHz -3.4
n75-15MHz -2.3
(Not Supported)
n100-20MHz -3.0
44.7 n6-1_4MHz -5.7
n15-3MHz -4.8
n25-5MHz -2.5
n50-10MHz -1.7
n75-15MHz -3.2
(Not Supported)
n100-20MHz -1.2
46.0 n6-1_4MHz -4.8
n15-3MHz -4.0
n25-5MHz -3.9
n50-10MHz -3.4
n75-15MHz -2.3
(Not Supported)
n100-20MHz -3.0
47.7 n6-1_4MHz -5.7
n15-3MHz -4.8
n25-5MHz -2.5
n50-10MHz -1.7
n75-15MHz -3.2
Page 382/472
(Not Supported)
n100-20MHz -1.2
n50-10MHz -3.4
n50-10MHz -3.4
tm2, tm3, tm4 43.0 n6-1_4MHz -2.0
n15-3MHz -1.2
n25-5MHz -0.9
n50-10MHz -0.4
n75-15MHz 0.7
(Not Supported)
n100-20MHz 0.0
44.7 n6-1_4MHz -2.5
n15-3MHz -1.9
n25-5MHz 0.5
n50-10MHz 1.3
n75-15MHz -0.2
(Not Supported)
n100-20MHz 1.8
46.0 n6-1_4MHz -2.0
n15-3MHz -1.2
n25-5MHz -0.9
n50-10MHz -0.4
n75-15MHz 0.7
(Not Supported)
n100-20MHz 0.0
47.7 n6-1_4MHz -2.5
n15-3MHz -1.9
n25-5MHz 0.5
n50-10MHz 1.3
n75-15MHz -0.2
(Not Supported)
n100-20MHz 1.8
Page 383/472
n50-10MHz -0.4
n50-10MHz -0.4
6.1.1.9 PDCCH POWER SETTING
The PDCCH transmit power is either determined by the PDCCH power control
algorithm or derived from parameters pDCCHPowerOffsetSymbol1 and
pDCCHPowerOffsetSymbol2and3:
• When PDCCH power control is deactivated (by setting parameter
pDCCHPowerControlActivation to “False”), the PDCCH transmit power is
derived from parameters pDCCHPowerOffsetSymbol1 and
pDCCHPowerOffsetSymbol2and3:
o Parameter pDCCHPowerOffsetSymbol1 configures the transmit
power of PDCCH (expressed in dB relative to PREF ) per RE and per
Power Amplifier, in the first OFDM symbol.
o Parameter pDCCHPowerOffsetSymbol2and3 configures the

transmit power of PDCCH (expressed in dB relative to PREF ) per RE
and per Power Amplifier, in the second and third OFDM symbols.
• When PDCCH power control is activated (by setting parameter

pDCCHPowerControlActivation to “True”), the PDCCH transmit power is
initialized at cell setup as explained above (for the case when PDCCH power
control is not activated) and then updated by the PDCCH power control
algorithm (see section 6.1.2).
CellL2DLConf::pDCCHPowerControlActivation
Parameter pDCCHPowerControlActivation
True/False
Value True
Feature
Page 384/472
PowerOffsetConfiguration::pDCCHPowerOffsetSymbol1
Parameter pDCCHPowerOffsetSymbol1
Object
setConfiguration
Range & Unit Float
[-25.6..25.5] step = 0.1dB
Feature
PowerOffsetConfiguration::pDCCHPowerOffsetSymbol2and3
Parameter pDCCHPowerOffsetSymbol2and3
Object
setConfiguration
Range & Unit Float
[-25.6..25.5] step = 0.1dB
Feature
These 2 parameters are expressed in dB, relative to the RS power, PREF. They are
converted into linear scale (milliwatt) as follows
• PPDCCH 1[mW ] = PREF × 10 pDCCHPowerOffsetSymbol1 / 10 with one transmit antenna.

• PPDCCH 1[mW ] = PREF × 10 (pDCCHPowerOffsetSymbol1−3)/10 with 2 transmit antennas.
In this case, PDCCH is transmitted at - 3dB compared to the parameter
setting due to TxDiv encoding.
• PPDCCH 2,3 [mW ] = PREF × 10 pDCCHPowerOffsetSymbol2and3 /10 with one transmit
antenna.
• PPDCCH 2,3 [mW ] = PREF × 10 (pDCCHPowerOffsetSymbol2and3 −3)/10 with 2 transmit
antennas. In this case, PDCCH is transmitted at - 3dB compared to the
parameter setting due to TxDiv encoding.
Page 385/472
Engineering Recommendation: Parameters pDCCHPowerOffsetSymbol1 and

pDCCHPowerOffsetSymbol2and3
Parameters pDCCHPowerOffsetSymbol1 and

pDCCHPowerOffsetSymbol2and3 are key RF optimization parameters: The
higher the setting, the more robust the PDCCH reception within the cell coverage
area, but this reduces the power available for other downlink signals and
channels. Smaller settings impair PDCCH reception.
The current default setting for parameters pDCCHPowerOffsetSymbol1 and
pDCCHPowerOffsetSymbol2and3 are as follows
transmissionMode cellDLTotalPower dlBandwidth pDCCHPowerOffsetSy

mbol1
tm1 43.0 n6-1_4MHz -2.6
n15-3MHz -2.6
n25-5MHz -2.8
n50-10MHz -2.8
n75-15MHz -2.6
(Not Supported)
n100-20MHz -2.6
44.7 n6-1_4MHz -2.9
n15-3MHz -2.9
n25-5MHz -2.1
n50-10MHz -2.1
n75-15MHz -2.9
(Not Supported)
n100-20MHz -2.1
46.0 n6-1_4MHz -2.6
n15-3MHz -2.6
n25-5MHz -2.8
n50-10MHz -2.8
n75-15MHz -2.6
(Not Supported)
n100-20MHz -2.8
47.7 n6-1_4MHz -2.9
n15-3MHz -2.9
n25-5MHz -2.1
Page 386/472
n50-10MHz -2.1
n75-15MHz -2.9
(Not Supported)
n100-20MHz -2.1
n50-10MHz -2.8
n50-10MHz -2.8
tm2, tm3, tm4 43.0 n6-1_4MHz 0.4
n15-3MHz 0.4
n25-5MHz 0.2
n50-10MHz 0.2
n75-15MHz 0.4
(Not Supported)
n100-20MHz 0.2
44.7 n6-1_4MHz 0.1
n15-3MHz 0.1
n25-5MHz 0.9
n50-10MHz 0.9
n75-15MHz 0.1
(Not Supported)
n100-20MHz 0.9
46.0 n6-1_4MHz 0.4
n15-3MHz 0.4
n25-5MHz 0.2
n50-10MHz 0.2
n75-15MHz 0.4
(Not Supported)
n100-20MHz 0.2
47.7 n6-1_4MHz 0.1
n15-3MHz 0.1
n25-5MHz 0.9
n50-10MHz 0.9
n75-15MHz 0.1
Page 387/472
(Not Supported)
n100-20MHz 0.9
n50-10MHz 0.2
n50-10MHz 0.2
transmissionMode cellDLTotalPower dlBandwidth pDCCHPowerOffsetSy

mbol2and3
43.0 n6-1_4MHz -2.6
tm1 n15-3MHz -2.6
n25-5MHz -2.8
n50-10MHz -2.8
n75-15MHz -2.6
(Not Supported)
n100-20MHz -2.6
44.7 n6-1_4MHz -2.9
n15-3MHz -2.9
n25-5MHz -2.1
n50-10MHz -2.1
n75-15MHz -2.9
(Not Supported)
n100-20MHz -2.1
46.0 n6-1_4MHz -2.6
n15-3MHz -2.6
n25-5MHz -2.8
n50-10MHz -2.8
n75-15MHz -2.6
(Not Supported)
n100-20MHz -2.8
47.7 n6-1_4MHz -2.9
n15-3MHz -2.9
n25-5MHz -2.1
n50-10MHz -2.1
Page 388/472
n75-15MHz -2.9
(Not Supported)
n100-20MHz -2.1
n50-10MHz -2.8
n50-10MHz -2.8
tm2, tm3, tm4 43.0 n6-1_4MHz 0.4
n15-3MHz 0.4
n25-5MHz 0.2
n50-10MHz 0.2
n75-15MHz 0.4
(Not Supported)
n100-20MHz 0.2
44.7 n6-1_4MHz 0.1
n15-3MHz 0.1
n25-5MHz 0.9
n50-10MHz 0.9
n75-15MHz 0.1
(Not Supported)
n100-20MHz 0.9
46.0 n6-1_4MHz 0.4
n15-3MHz 0.4
n25-5MHz 0.2
n50-10MHz 0.2
n75-15MHz 0.4
(Not Supported)
n100-20MHz 0.2
47.7 n6-1_4MHz 0.1
n15-3MHz 0.1
n25-5MHz 0.9
n50-10MHz 0.9
n75-15MHz 0.1
(Not Supported)
Page 389/472
n100-20MHz 0.9
n50-10MHz 0.2
n50-10MHz 0.2
6.1.1.10 PDSCH POWER SETTING

The transmit power of PDSCH REs in OFDM symbols with no RS and denoted by
PPDSCH _ A [mW ] is configured by parameter paOffsetPdsch
PPDSCH _ A [mW ] = PREF × 10 paOffsetPdsch/ 10
The transmit power of PDSCH REs in OFDM symbols with RS and denoted by
PPDSCH _ B [mW ] is derived based on parameters paOffsetPdsch and
pbOffsetPdsch as follows:
1 transmit antenna
pbOffsetPdsch PPDSCH _ B [mW ]
0 PREF × 10 paOffsetPdsch/ 10
1 PREF × 10 (−1.0+ paOffsetPdsch )/ 10
2 PREF × 10 (- 2.2+ paOffsetPdsch )/ 10
3 PREF × 10 (- 4.0+ paOffsetPdsch )/ 10
2 transmit antennas
pbOffsetPdsch PPDSCH _ B [mW ]
0 PREF × 10 (1.0 + paOffsetPdsch )/ 10
1 PREF × 10 paOffsetPdsch/ 10
2 PREF × 10 (-1.2 + paOffsetPdsch )/ 10
3 PREF × 10 (-3.0 + paOffsetPdsch )/ 10
OFDM symbols with no RS OFDM symbols with RS

Number of Normal cyclic Extended cyclic Normal cyclic Extended
antenna ports prefix prefix prefix cyclic prefix
Page 390/472
One or two 1, 2, 3, 5, 6 1, 2, 4, 5 0, 4 0, 3
Four (Not 2, 3, 5, 6 2, 4, 5 0, 1, 4 0, 1, 3
supported in
LA6.0)
Table 26: Split between OFDM symbols with RS and OFDM symbols without RS
Note that for CQI computation, the UE assumes on top of paOffsetPdsch, an

additional offset configured by nomPdschRsEpreOffset, corresponding to
nomPDSCH-RS-EPRE-Offset that is signaled by RRC in CQI-ReportConfig.
In LR13.3, UE with CA activated, shall consider

DownlinkCAConf::cqiReportConfigR10NomPdschRsEpreOffset for reporting
Rel-10 aperiodic CSI on SCell (A-CSI_S).
PowerOffsetConfiguration::paOffsetPdsch
Parameter paOffsetPdsch
Object
setConfiguration
{dB-6, dB-4dot77, dB-3, dB-1dot77, dB0, dB1, dB2, dB3 }
Feature
The enumerate values are mapped to the values used in the equation
PPDSCH _ A [mW ] = PREF × 10 paOffsetPdsch/ 10 according to the table below
Page 391/472
Enumerate value Value used in the derivation

PPDSCH _ A [mW ] = PREF × 10 paOffsetPdsch/ 10
dB-6 -6 dB
dB-4dot77 -4.77 dB
dB-3 -3 dB
dB-1dot77 -1.77 dB
dB0 0 dB
dB1 1 dB
dB2 2 dB
dB3 3 dB
Engineering Recommendation: Parameter paOffsetPdsch setting
Parameter paOffsetPdsch is a key RF optimization parameter impacting the end

user data rate. Higher power levels improve the downlink throughput at the
expense of the power available for other downlink signals and channels. Smaller
settings degrade the downlink throughput but contribute lower interference to the
UEs served by the neighboring cells.
The current default value for this parameter is “dB-3”.
PowerOffsetConfiguration::pbOffsetPdsch
Parameter pbOffsetPdsch
Object
setConfiguration
[0..3]
Feature
Page 392/472
Engineering Recommendation: Parameter pbOffsetPdsch setting
transmissionMode cellDLTotalPower dlBandwidth pbOffsetPdsch
tm1 43.0 n6-1_4MHz 1
n15-3MHz 1
n25-5MHz 1
n50-10MHz 1
n75-15MHz
1
(Not Supported)
n100-20MHz 1
44.7 n6-1_4MHz 1
n15-3MHz 1
n25-5MHz 0
n50-10MHz 0
n75-15MHz
0
(Not Supported)
n100-20MHz 0
46.0 n6-1_4MHz 1
n15-3MHz 1
n25-5MHz 1
n50-10MHz 1
n75-15MHz
1
(Not Supported)
n100-20MHz 1
47.7 n6-1_4MHz 1
n15-3MHz 1
n25-5MHz 0
n50-10MHz 0
n75-15MHz
1
(Not Supported)
n100-20MHz 0
n50-10MHz 1
Page 393/472
n50-10MHz 1
tm2, tm3, tm4 43.0 n6-1_4MHz 1
n15-3MHz 1
n25-5MHz 1
n50-10MHz 1
n75-15MHz
1
(Not Supported)
n100-20MHz 1
44.7 n6-1_4MHz 1
n15-3MHz 1
n25-5MHz 1
n50-10MHz 1
n75-15MHz
1
(Not Supported)
n100-20MHz 1
46.0 n6-1_4MHz 1
n15-3MHz 1
n25-5MHz 1
n50-10MHz 1
n75-15MHz
1
(Not Supported)
n100-20MHz 1
47.7 n6-1_4MHz 1
n15-3MHz 1
n25-5MHz 1
n50-10MHz 1
n75-15MHz
1
(Not Supported)
n100-20MHz 1
n50-10MHz 1
n50-10MHz 1
Page 394/472
CellL2DLConf::nomPdschRsEpreOffset
Parameter nomPdschRsEpreOffset
[-2..12] step = 2 dB
Value 0
Feature
DownlinkCAConf::cqiReportConfigR10NomPdschRsEpreOffset
Parameter nomPdschRsEpreOffset
Object
[-2..12] step = 2 dB
Value 0
Feature 160847
6.1.2 PDCCH POWER CONTROL

When PDCCH power control is activated, the corresponding algorithm aims at
increasing the power of the UEs in bad radio conditions, i.e. adapting the PDCCH
transmit power to the UE’s radio conditions (especially with low aggregation levels
offering low protection), not possible with the static power setting.
The UE SINR is derived from the CQI it reports by means of a CQI-to-SINR lookup
table.
This SINR is then compared to the desired SINR (target SINR):
Page 395/472
• If the target SINR is not reached (Estimated SINR< target SINR), the power
is increased so that the difference [target SINR-Estimated SINR] (in the
linear scale) goes to zero. The power increase is limited, though. The limit is
configured by parameter pDCCHPowerControlMaxPowerIncrease.
• If the target SINR is exceeded (Estimated SINR> target SINR), the power is
decreased so that the difference [Estimated SINR-target SINR] (in linear
scale) goes to zero. The power decrease is limited, though. The limit is
configured by parameter pDCCHPowerControlMaxPowerDecrease.
An additional power offset is applied (on top of the PDCCH power required to meet
the SINR target for PDCCH grants) for RACH message 4 (i.e. SRB0), Timing
Advance (and DRX) commands, DL SPS Activation and DL SPS Release. This
power offset is configured by parameter powerOffsetForCriticalCRNTIGrants.
Also, an additional power offset is applied on PDCCH grants for RACH Message 2,
D-BCH (i.e. SIBs) and PCH (i.e. paging). This offset is configured by parameter
powerOffsetForNonCRNTIGrantsInCommonSearchSpace.
Similarly, an additional power offset is applied to DCI3. This offset is configured by
parameter powerOffsetForDCI3.
An additional power offset is applied to DCI0 messages to UE configured with TTI

bundling. This offset is configured by parameter
extraDCI0powerOffsetForTTIBundling.
CellL1L2ControlChannelsConf::extraDCI0powerOffsetForTTIBundling
Parameter extraDCI0powerOffsetForTTIBundling
Range & Unit Float
[0.0..3.0] step = 0.25 dB
Value 0.0
The target SINR depends on the DCI format and the aggregation level. Parameter
dlTargetSINRTableForPDCCH configures these SINR thresholds. It consists of a
table of 40 elements corresponding to a matrix of 4 rows and 10 columns; 1 row for
each aggregation level (1, 2, 4 and 8, respectively) and 1 column for each DCI format
(0, 1, 1A, 1B, 1C, 1D, 2, 2A, 3, 3A). Thus, the first 10 elements of
dlTargetSINRTableForPDCCH correspond to aggregation level 1, the next 10 to
Page 396/472
aggregation level 2, the next 10 to aggregation level 4 and the next (and final) 10 to
aggregation level 8.
Note that DCI formats 1B, 1C, 1D and 3A are not supported in LA6.0 and therefore,
the corresponding entries in the table are not significant.
In each subframe, while examining UEs for scheduling, the DL Scheduler (section
4.5) and the UL Scheduler (section 4.6) keep a running total of the PDCCH power
utilization and discard a UE from scheduling when the additional PDCCH power
requirements for this UE would bring the total PDCCH power requirements above the
total available PDCCH power (except in the case of TA/DRX/SRB1(DL), in which all
remaining power is assigned.
CellL1L2ControlChannelsConf::dlTargetSINRTableForPDCCH
Parameter dlTargetSINRTableForPDCCH
Range & Unit Table of 40 floats
[-10.0..30.0] step = 0.25 dB
[0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,5.00,6.
00,5.00,0.00,0.00,0.00,7.00,7.00,5.00,0.00,1.75,2.50,1.75,
Value 0.00,0.00,0.00,3.00,3.00,1.75,0.00,0.00,0.00,0.00,0.00,0.0
0,0.00,0.00,0.00,0.00,0.00]
ALU recommends the operator to not change this setting
Feature
Parameter pDCCHPowerControlType determines which algorithm to use: the

"Anticipated Scheduling PDCCH Power Control" or the “IN-Scheduling PDCCH
Power Control”.
Page 397/472
CellL2DLConf::pDCCHPowerControlType
Parameter pDCCHPowerControlType
{ AnticipatedScheduling, IN-Scheduling }
IN-Scheduling ALU recommends the operator to not change this
Value
setting
Feature
CellL2DLConf::pDCCHPowerControlMaxPowerIncrease
Parameter pDCCHPowerControlMaxPowerIncrease
Range & Unit Float
[0.. 12.7] step = 0.1dB
Value 6.7
Feature FRS 92801
CellL2DLConf::pDCCHPowerControlMaxPowerDecrease
Parameter pDCCHPowerControlMaxPowerDecrease
Range & Unit Float
[0..12.8] step = 0.1dB
Value 12.8
Feature FRS 92801
Page 398/472
CellL1L2ControlChannelsConf::powerOffsetForCriticalCRNTIGrants
Parameter powerOffsetForCriticalCRNTIGrants
Range & Unit Float
[-12.7..12.8] step = 0.1dB
Value 0.0
Feature FRS 115113
CellL1L2ControlChannelsConf::powerOffsetForNonCRNTIGrantsInCommonSe
archSpace
Parameter powerOffsetForNonCRNTIGrantsInCommonSearchSpace
Range & Unit Float
[-12.7..12.8] step = 0.1dB
Value 0.0
Feature FRS 115113
CellL1L2ControlChannelsConf::powerOffsetForDCI3
Parameter powerOffsetForDCI3
Range & Unit Float
[-12.7..12.8] step = 0.1dB
Value 0.0
Feature FRS 115113
6.1.3 DOWNLINK POWER BUDGET

While configuring the cell, the eNB verifies that the available power is not exceeded,
taking into account the RS power, the SCH powers, the PBCH power, the PCFICH
power, the PHICH power, the PDCCH power and the PDSCH power.
Page 399/472
This is done at OFDM symbol level.
Define the following numbers:

• nbRERS: Number of resource elements of the Reference Signal in the
considered OFDM symbol.
• nbREPRS: Number of resource elements of the Positioning Reference Signal in
the considered OFDM symbol.
• nbREP-SCH: Number of resource elements of the primary SCH in the
• nbRES-SCH: Number of resource elements of the secondary SCH in the
• nbREPBCH: Number of resource elements of the PBCH in the considered
OFDM symbol.
• nbREPDCCH: Number of resource elements of the PDCCH in the considered
OFDM symbol.
• nbREPCFICH: Number of resource elements of the PCFICH in the considered

OFDM symbol.
• nbREPHICH: Number of resource elements of the PHICH in the considered
OFDM symbol.
• nbREPDSCH: Number of resource elements of the PDSCH in the considered
OFDM symbol.
• nbREPMCH: Number of resource elements of the PMCH in the considered

OFDM symbol.
• nbREMBSFN RS: Number of resource elements of the MBSFN RS in the
The eNB computes the total power consumed in every symbol period as follows:
TotalPowerRS: total power used by Reference Signal in the current OFDM symbol.
TotalPowerRS = nbRERS × PREF
TotalPowerPRS: total power used by the Positioning Reference Signal in the current
OFDM symbol.
TotalPowerPRS = nbREPRS × PPRS
TotalPowerP-SCH: total power used by the primary Synchronization signal in the current
OFDM symbol.
TotalPowerP-SCH = nbREP-SCH × PP-SCH
TotalPowerS-SCH: total power used by the secondary synchronization signal in the

current OFDM symbol.
Page 400/472
TotalPowerS-SCH = nbRES-SCH × PS-SCH

TotalPowerPBCH: total power used by the PBCH in the current OFDM symbol.
TotalPowerPBCH = nbREPBCH × PPBCH
TotalPowerPDCCH: total power used by the PDCCH in the current OFDM symbol.
• If the PDCCH power control is disabled (i.e. flag

pDCCHPowerControlActivation is set to “False”), then
o If the current OFDM symbol index is the first OFDM symbol of slot 0
TotalPowerPDCCH = nbREPDCCH × PPDCCH1
o If the current OFDM symbol index is the 2nd or 3rd OFDM symbol of
slot 0
TotalPowerPDCCH = nbREPDCCH × PPDCCH2,3
• If the PDCCH power control is enabled (i.e. flag
pDCCHPowerControlActivation is set to “True”), TotalPowerPDCCH is
initialized at cell setup as explained above (for the case when PDCCH power
control is deactivated) and then updated by the PDCCH power control
algorithm.
TotalPowerPCFICH: total power used by the PCFICH in the current OFDM symbol.
TotalPowerPCFICH = nbREPCFICH × PPCFICH
TotalPowerPHICH: total power used by the PHICH in the current OFDM symbol.
TotalPowerPHICH = nbREPHICH × PPHICH
TotalPowerPDSCH: total power used by the PDSCH in the current OFDM symbol.
• If the current OFDM symbol index is 1, 2, 3, 5 or 6
TotalPowerPDSCH = nbREPDSCH × PPDSCH_A

• If the current OFDM symbol index is 0 or 4
TotalPowerPDSCH = nbREPDSCH × PPDSCH_B
TotalPowerPMCH & MBSFN RS: total power used by the PDSCH in the current OFDM
symbol.
TotalPowerPMCH & MBSFN RS = nbREPMCH × P PMCH & MBSFN RS + nbRE MBSFN RS × P PMCH & MBSFN RS
= (nbREPMCH + nbRE MBSFN RS) × P PMCH & MBSFN RS

= nbREBW × P PMCH & MBSFN RS
Page 401/472
where nbREBW = nbREPMCH + nbRE MBSFN RS is the total number of REs that are used by
PMCH and MBSFN RS on port 4, which equates to the total number of REs in the
Bandwidth (600 for 10MHz).
The sum of the transmitted power on all physical channels and signals must be
configured within the limit configured through parameter cellDLTotalPower for each
OFDM symbol.
The power budget algorithm consists thus in performing the following checking for
every OFDM symbol:
(TotalPowerRS + TotalPowerP-SCH + TotalPowerS-SCH + TotalPowerPBCH +

TotalPowerPDCCH + TotalPowerPCFICH + TotalPowerPHICH + TotalPowerPDSCH) ≤ PMax
This above checking is only performed for subframe 0 for if the conditions above are
satisfied in subframe 0, they are satisfied in the other subframes.
When eMBMS is activated (i.e. when isMbmsBroadcastModeAllowed is set to

“True”), the following check (for M-subframe) is used instead:
(TotalPowerRS + TotalPowerP-SCH + TotalPowerS-SCH + TotalPowerPBCH +

TotalPowerPDCCH + TotalPowerPCFICH + TotalPowerPHICH + TotalPowerPMCH & MBSFN RS) ≤
PMax
Also, when PRS are enabled (i.e. when isOtdoaHearabilityEnhancementAllowed

is set to “True”), the following check is used instead:
(TotalPowerRS + TotalPowerPRS + TotalPowerP-SCH + TotalPowerS-SCH + TotalPowerPBCH +

TotalPowerPDCCH + TotalPowerPCFICH + TotalPowerPHICH + TotalPowerPRS) ≤ PMax
If the condition above is not satisfied for at least 1 OFDM symbol, the cell setup fails,
(meaning that the cell does not go on air) and an alarm is generated by the eNB.
Note that the cell setup procedure is executed at eNB (re)boot and for some other
reasons such as when changes are made in the settings of Class B parameters
(power offset parameters for example). Also note that other checks are performed to
ensure that the maximum absolute power per RE is not exceeded. If at least one
condition is not verified, the cell setup fails. These checks are only performed at cell
Page 402/472
setup, meaning that if the latter is successful, the cell comes up (i.e. goes on air) and
the checks are not repeated.
Table 27, Table 28, Table 29, Table 30, Table 31, Table 32, Table 33, Table 34,
Table 35, Table 36, Table 37, Table 38, Table 39, Table 40, Table 41, Table 42,
Table 43, Table 44, Table 45, Table 46, Table 47, Table 48, Table 49 and Table 50
show the RE distribution for each OFDM symbol in subframe 0 for phichResource =
one, CFI = 3 (with 1.4MHz, 3MHz, 5MHz and 10MHz bandwidths) and CFI = 2 (with
15MHz and 20MHz bandwidth), i.e. for (CFI, phichResource) LA6.0 default
configuration for each system bandwidth, in the one transmit antenna case and the 2
transmit antenna case, respectively.
OFDM Symbol 0 1 2 3 4 5 6
Number of REs
nbRERS 12 0 0 0 12 0 0
nbREP-SCH 0 0 0 0 0 0 62
nbRES-SCH 0 0 0 0 0 62 0
nbREPBCH 0 0 0 0 0 0 0
nbREPDCCH 20 72 72 72 0 0 0
nbREPCFICH 16 0 0 0 0 0 0
nbREPHICH 12 0 0 0 0 0 0
nbREPDSCH A 0 0 0 0 0 0 0
nbREPDSCH B 0 0 0 0 60 0 0
Unused RE 12 0 0 0 0 10 10
Table 27: (transmissionMode=tm1, dlBandwidth=n6-1_4MHz, CFI=3,
phichResource=one) RE distribution in slot 0 of subframe 0
Number of REs
nbRERS 12 0 0 0 12 0 0
nbREP-SCH 0 0 0 0 0 0 0
nbRES-SCH 0 0 0 0 0 0 0
nbREPBCH 48 48 72 72 0 0 0
nbREPDCCH 0 0 0 0 0 0 0
nbREPHICH 0 0 0 0 0 0 0
nbREPDSCH A 0 0 0 0 0 72 72
nbREPDSCH B 0 0 0 0 60 0 0
Unused RE 12 24 0 0 0 0 0
Table 28: (transmissionMode=tm1, dlBandwidth=n6-1_4MHz, CFI=3,
Page 403/472
Number of REs
nbRERS 30 0 0 0 30 0 0
nbREP-SCH 0 0 0 0 0 0 62
nbRES-SCH 0 0 0 0 0 62 0
nbREPBCH 0 0 0 0 0 0 0
nbREPDCCH 80 180 180 0 0 0 0
nbREPHICH 24 0 0 0 0 0 0
nbREPDSCH A 0 0 0 180 0 108 108
nbREPDSCH B 0 0 0 0 150 0 0
Unused RE 30 0 0 0 0 10 10
Table 29: (transmissionMode=tm1, dlBandwidth=n15-3MHz, CFI=3,
Number of REs
nbRERS 12 0 0 0 12 0 0
nbREP-SCH 0 0 0 0 0 0 0
nbRES-SCH 0 0 0 0 0 0 0
nbREPBCH 48 48 72 72 0 0 0
nbREPDCCH 0 0 0 0 0 0 0
nbREPHICH 0 0 0 0 0 0 0
nbREPDSCH A 0 0 0 0 0 72 72
nbREPDSCH B 0 0 0 0 60 0 0
Unused RE 12 24 0 0 0 0 0
Page 404/472
Number of REs
nbRERS 30 0 0 0 30 0 0
nbREP-SCH 0 0 0 0 0 0 62
nbRES-SCH 0 0 0 0 0 62 0
nbREPBCH 0 0 0 0 0 0 0
nbREPDCCH 80 180 180 0 0 0 0
nbREPHICH 24 0 0 0 0 0 0
nbREPDSCH A 0 0 0 180 0 108 108
nbREPDSCH B 0 0 0 0 150 0 0
Unused RE 30 0 0 0 0 10 10
Number of REs
nbRERS 30 0 0 0 30 0 0
nbREP-SCH 0 0 0 0 0 0 0
nbRES-SCH 0 0 0 0 0 0 0
nbREPBCH 48 48 72 72 0 0 0
nbREPDCCH 0 0 0 0 0 0 0
nbREPHICH 0 0 0 0 0 0 0
nbREPDSCH A 0 108 108 108 0 180 180
nbREPDSCH B 90 0 0 0 150 0 0
Unused REs 12 24 0 0 0 0 0
Page 405/472
Number of REs
nbRERS 100 0 0 0 100 0 0
nbREP-SCH 0 0 0 0 0 0 62
nbRES-SCH 0 0 0 0 0 62 0
nbREPBCH 0 0 0 0 0 0 0
nbREPDCCH 300 600 600 0 0 0 0
nbREPHICH 84 0 0 0 0 0 0
nbREPDSCH_A 0 0 0 600 0 528 528
nbREPDSCH_B 0 0 0 0 500 0 0
Unused RE 100 0 0 0 0 10 10
Number of REs
nbRERS 100 0 0 0 100 0 0
nbREP-SCH 0 0 0 0 0 0 0
nbRES-SCH 0 0 0 0 0 0 0
nbREPBCH 48 48 72 72 0 0 0
nbREPDCCH 0 0 0 0 0 0 0
nbREPHICH 0 0 0 0 0 0 0
nbREPDSCH_A 0 528 528 528 0 600 600
nbREPDSCH_B 440 0 0 0 500 0 0
Unused RE 12 24 0 0 0 0 0
Number of REs
nbRERS 150 0 0 0 150 0 0
nbREP-SCH 0 0 0 0 0 0 62
nbRES-SCH 0 0 0 0 0 62 0
nbREPBCH 0 0 0 0 0 0 0
nbREPDCCH 464 900 0 0 0 0 0
nbREPHICH 120 0 0 0 0 0 0
nbREPDSCH_A 0 0 900 900 0 828 828
nbREPDSCH_B 0 0 0 0 750 0 0
Unused RE 150 0 0 0 0 10 10
phichResource=one) RE distribution in slot 0 of subframe 0.
Page 406/472
Number of REs
nbRERS 150 0 0 0 150 0 0
nbREP-SCH 0 0 0 0 0 0 0
nbRES-SCH 0 0 0 0 0 0 0
nbREPBCH 48 48 72 72 0 0 0
nbREPDCCH 0 0 0 0 0 0 0
nbREPHICH 0 0 0 0 0 0 0
nbREPDSCH_A 0 828 828 828 0 900 900
nbREPDSCH_B 690 0 0 0 750 0 0
Unused RE 12 24 0 0 0 0 0
Number of REs
nbRERS 200 0 0 0 200 0 0
nbREP-SCH 0 0 0 0 0 0 62
nbRES-SCH 0 0 0 0 0 62 0
nbREPBCH 0 0 0 0 0 0 0
nbREPDCCH 628 1200 0 0 0 0 0
nbREPHICH 156 0 0 0 0 0 0
nbREPDSCH_A 0 0 1200 1200 0 1128 1128
nbREPDSCH_B 0 0 0 0 1000 0 0
Unused RE 200 0 0 0 0 10 10
Page 407/472
Number of REs
nbRERS 200 0 0 0 200 0 0
nbREP-SCH 0 0 0 0 0 0 0
nbRES-SCH 0 0 0 0 0 0 0
nbREPBCH 48 48 72 72 0 0 0
nbREPDCCH 0 0 0 0 0 0 0
nbREPHICH 0 0 0 0 0 0 0
nbREPDSCH_A 0 1128 1128 1128 0 1200 1200
nbREPDSCH_B 940 0 0 0 1000 0 0
Unused RE 12 24 0 0 0 0 0
Number of REs
nbRERS 12 0 0 0 12 0 0
nbREP-SCH 0 0 0 0 0 0 62
nbRES-SCH 0 0 0 0 0 62 0
nbREPBCH 0 0 0 0 0 0 0
nbREPDCCH 20 72 72 72 0 0 0
nbREPHICH 12 0 0 0 0 0 0
nbREPDSCH A 0 0 0 0 0 0 0
nbREPDSCH B 0 0 0 0 48 0 0
Unused RE 12 0 0 0 12 10 10
Table 39: (transmissionMode=tm2/3/4, dlBandwidth=n6-1_4MHz, CFI=3,
Number of REs
nbRERS 12 0 0 0 12 0 0
nbREP-SCH 0 0 0 0 0 0 0
nbRES-SCH 0 0 0 0 0 0 0
nbREPBCH 48 48 72 72 0 0 0
nbREPDCCH 0 0 0 0 0 0 0
nbREPHICH 0 0 0 0 0 0 0
nbREPDSCH A 0 0 0 0 0 72 72
nbREPDSCH B 0 0 0 0 48 0 0
Unused RE 12 24 0 0 12 0 0
Table 40: (transmissionMode=tm2/3/4, dlBandwidth=n6-1_4MHz, CFI=3,
Page 408/472
Number of REs
nbRERS 30 0 0 0 30 0 0
nbREP-SCH 0 0 0 0 0 0 62
nbRES-SCH 0 0 0 0 0 62 0
nbREPBCH 0 0 0 0 0 0 0
nbREPDCCH 80 180 180 0 0 0 0
nbREPHICH 24 0 0 0 0 0 0
nbREPDSCH A 0 0 0 180 0 108 108
nbREPDSCH B 0 0 0 0 120 0 0
Unused RE 30 0 0 0 30 10 10
Table 41: (transmissionMode=tm2/3/4, dlBandwidth=n15-3MHz, CFI=3,
Number of REs
nbRERS 30 0 0 0 30 0 0
nbREP-SCH 0 0 0 0 0 0 0
nbRES-SCH 0 0 0 0 0 0 0
nbREPBCH 48 48 72 72 0 0 0
nbREPDCCH 0 0 0 0 0 0 0
nbREPHICH 0 0 0 0 0 0 0
nbREPDSCH A 0 108 108 108 0 180 180
nbREPDSCH B 72 0 0 0 120 0 0
Unused RE 30 24 0 0 30 0 0
Page 409/472
Number of REs
nbRERS 50 0 0 0 50 0 0
nbREP-SCH 0 0 0 0 0 0 62
nbRES-SCH 0 0 0 0 0 62 0
nbREPBCH 0 0 0 0 0 0 0
nbREPDCCH 136 300 300 0 0 0 0
nbREPHICH 48 0 0 0 0 0 0
nbREPDSCH A 0 0 0 300 0 228 228
nbREPDSCH B 0 0 0 0 200 0 0
Unused RE 50 0 0 0 50 10 10
Number of REs
nbRERS 50 0 0 0 50 0 0
nbREP-SCH 0 0 0 0 0 0 0
nbRES-SCH 0 0 0 0 0 0 0
nbREPBCH 48 48 72 72 0 0 0
nbREPDCCH 0 0 0 0 0 0 0
nbREPHICH 0 0 0 0 0 0 0
nbREPDSCH A 0 228 228 228 0 300 300
nbREPDSCH B 152 0 0 0 200 0 0
Unused REs 50 24 0 0 50 0 0
Page 410/472
Number of REs
nbRERS 100 0 0 0 100 0 0
nbREP-SCH 0 0 0 0 0 0 62
nbRES-SCH 0 0 0 0 0 62 0
nbREPBCH 0 0 0 0 0 0 0
nbREPDCCH 300 600 600 0 0 0 0
nbREPHICH 84 0 0 0 0 0 0
nbREPDSCH_A 0 0 0 600 0 528 528
nbREPDSCH_B 0 0 0 0 400 0 0
Unused RE 100 0 0 0 100 10 10
Number of REs
nbRERS 100 0 0 0 100 0 0
nbREP-SCH 0 0 0 0 0 0 0
nbRES-SCH 0 0 0 0 0 0 0
nbREPBCH 48 48 72 72 0 0 0
nbREPDCCH 0 0 0 0 0 0 0
nbREPHICH 0 0 0 0 0 0 0
nbREPDSCH_A 0 528 528 528 0 600 600
nbREPDSCH_B 352 0 0 0 400 0 0
Unused RE 100 24 0 0 100 0 0
Page 411/472
Number of REs
nbRERS 150 0 0 0 150 0 0
nbREP-SCH 0 0 0 0 0 0 62
nbRES-SCH 0 0 0 0 0 62 0
nbREPBCH 0 0 0 0 0 0 0
nbREPDCCH 464 900 0 0 0 0 0
nbREPHICH 120 0 0 0 0 0 0
nbREPDSCH_A 0 0 900 900 0 828 828
nbREPDSCH_B 0 0 0 0 600 0 0
Unused RE 150 0 0 0 0 10 10
Number of REs
nbRERS 150 0 0 0 150 0 0
nbREP-SCH 0 0 0 0 0 0 0
nbRES-SCH 0 0 0 0 0 0 0
nbREPBCH 48 48 72 72 0 0 0
nbREPDCCH 0 0 0 0 0 0 0
nbREPHICH 0 0 0 0 0 0 0
nbREPDSCH_A 0 828 828 828 0 900 900
nbREPDSCH_B 552 0 0 0 600 0 0
Unused RE 150 24 0 0 0 0 0
Number of REs
nbRERS 200 0 0 0 200 0 0
nbREP-SCH 0 0 0 0 0 0 62
nbRES-SCH 0 0 0 0 0 62 0
nbREPBCH 0 0 0 0 0 0 0
nbREPDCCH 628 1200 0 0 0 0 0
nbREPHICH 156 0 0 0 0 0 0
nbREPDSCH_A 0 0 1200 1200 0 1128 1128
nbREPDSCH_B 0 0 0 0 800 0 0
Unused RE 200 0 0 0 200 10 10
Page 412/472
Number of REs
nbRERS 200 0 0 0 200 0 0
nbREP-SCH 0 0 0 0 0 0 0
nbRES-SCH 0 0 0 0 0 0 0
nbREPBCH 48 48 72 72 0 0 0
nbREPDCCH 0 0 0 0 0 0 0
nbREPHICH 0 0 0 0 0 0 0
nbREPDSCH_A 0 1128 1128 1128 0 1200 1200
nbREPDSCH_B 752 0 0 0 800 0 0
Unused RE 200 24 0 0 200 0 0
Table 51 and Table 52 show the RE distribution for each OFDM symbol of the M
subframes for phichResource = one and CFI = 2 in a 10MHz bandwidth system, i.e.
for the only supported LA6.0 eMBMS configuration.
OFDM Symbol 0 1 2 3 4 5
Number of REs
nbRERS 100 0 0 0 0 0
nbREP-SCH 0 0 0 0 0 0
nbRES-SCH 0 0 0 0 0 0
nbREPBCH 0 0 0 0 0 0
nbREPDCCH 300 600 0 0 0 0
nbREPCFICH 16 0 0 0 0 0
nbREPHICH 84 0 0 0 0 0
nbREPMCH & MBSFN RS 0 0 600 600 600 600
Unused RE 100 0 0 0 200 10
Table 51: (dlBandwidth=n50-10MHz, CFI=2, phichResource=one) RE
distribution in slot 0 of an M-subframe
Page 413/472
OFDM Symbol 0 1 2 3 4 5
Number of REs
nbRERS 0 0 0 0 0 0
nbREP-SCH 0 0 0 0 0 0
nbRES-SCH 0 0 0 0 0 0
nbREPBCH 0 0 0 0 0 0
nbREPDCCH 0 0 0 0 0 0
nbREPCFICH 0 0 0 0 0 0
nbREPHICH 0 0 0 0 0 0
nbREPMCH & MBSFN RS 600 600 600 600 600 600
Unused RE 0 0 0 0 0 0
Table 52: (dlBandwidth=n50-10MHz, CFI=2, phichResource=one) RE
distribution in slot 1 of an M-subframe
6.2 UPLINK POWER CONTROL

Uplink Power control is open-loop with eNB controlled closed-loop adjustment.
Also, the UL Transmit Power Control (TPC) command is sent when DL or UL data
are granted via PDCCH; PUSCH TPC commands are sent in PDCCH DCI Format 0
and PUCCH TPC commands are sent in PDCCH DCI Format 1/1A/2/2A. PDCCH
DCI Format 3/3A on the other hand is needed when a TPC command needs to be
sent but no data are granted. It uses the common search space.
A TPC-Group (DCI format 3/3A) is identified by a particular TPC-RNTI. Each TPC-

RNTI is associated with a list of UEs. A TPC-Group command is addressed to the
TPC-RNTI on PDCCH and sent to all the UEs in the list associated with the TPC-
RNTI in question.
A TPC-Group command consists of several TPC commands assigned to several
UEs; one PDCCH DCI Format 3 TPC command is represented over 2-bits (4 values,
as in DCI formats 0, 1/1A, 2/2A) whereas one PDCCH DCI Format 3 TPC command
is represented over 1 bit (2 values).
At UE level, a TPC-RNTI and a TPC-Index are provided and signaled to the UE in
the RadioResourceConfigDedicated UE-message. The UE TPC-RNTI identifies the TPC-
Group it belongs to whereas the TPC-Index identifies the position of the 1-bit (DCI
format 3A) or 2-bit (DCI format 3) UE TPC command inside the TPC-Group
command.
Page 414/472
Restriction: DCI format 3/3A
In LA6.0, DCI format 3A is not supported. Only DCI format 3 is supported.
6.2.1 PUCCH POWER CONTROL

PUCCH power control is used to guarantee the required error rates of control
channels. The principles of PUCCH power control are the following:
• PUCCH is power-controlled independently from PUSCH

• Open-loop power control with closed-loop correction.
• Full propagation loss compensation.
• Power control command is signaled to the UE. This is sent to the UE in DCI
Format 1 or 2, when dynamic grant for DL allocation is available. Otherwise,
the command is sent in DCI Format 3 (and addressed to TPC-PUCCH-RNTI
associated to the UE in question).
When the UE is in OFF state based on the MAC DRX state machine, the ULS shall
block PUCCH TPC command via DCI3 for the user (i.e. if DCI3 needs to be sent
anyway, 0dB TPC is issued for the user.
The setting of the UE Transmit power PPUCCH for PUCCH in subframe i is defined by
 PCMAX,c (i ), 
PPUCCH (i ) = min 
 P0_PUCCH + PLc + h(nCQI , n HARQ , n SR ) + ∆ F_PUCCH (F ) + g (i )

[dBm]
Where
• PCMAX,c (i ) is the configured UE transmit power in subframe i for serving cell
• ∆ F _ PUCCH denotes the (PUCCH) format specific power offset. For formats 1
and 1b, it is configured by parameters deltaFPUCCHFormat1 and

deltaFPUCCHFormat1b, respectively. For format 1a, it is configured by
parameter deltaFPUCCHFormat1. For formats 2, 2a and 2b, it is configured
Page 415/472
by parameters deltaFPUCCHFormat2, deltaFPUCCHFormat1a and

deltaFPUCCHFormat1b, respectively. In LR13.3, with Carrier Aggregation,
FDD HARQ ACK/NACK feedback for more than one configured serving cell
is based on PUCCH format 1b with channel selection HARQ-ACK
procedure (see 36.213, §10.1.2.2.1). The power offset for PUCCH format
1b with channel selection is configured in this case using parameter
UplinkCAConf::deltaFPUCCHFormat1bCSR10
• h(nCQI , n HARQ , n SR ) is a PUCCH format dependent value, where nCQI

corresponds to the number of information bits for the channel quality
information defined in section 5.2.3.3 in 36.212. n SR = 1 if subframe i is
configured for SR for the UE not having any associated transport block for
UL-SCH, otherwise n SR =0. If the UE is configured with more than one
serving cell, the value of n HARQ is defined in section 10.1 in 36.213;
otherwise, n HARQ is the number of HARQ-ACK bits sent in subframe i.
o (
For PUCCH format 1,1a and 1b h nCQI , n HARQ , n SR = 0 )
o For PUCCH format 1b with channel selection, if the UE is configured
with more than one serving cell, h(nCQI , nHARQ , nSR ) =
nHARQ − 1
,
( )
2
(
otherwise, h nCQI , n HARQ , n SR = 0 )
o For PUCCH format 2, 2a, 2b and normal cyclic prefix
  nCQI 
(
h nCQI , n HARQ , n SR = )
10 log10 
 4 
 if nCQI ≥ 4

0
 otherwise
o For PUCCH format 2 and extended cyclic prefix

  nCQI + nHARQ 
(
h nCQI , nHARQ , nSR =  )
10 log10 
 4
 if nCQI + nHARQ ≥ 4


0
 otherwise
• P0 _ PUCCH is a parameter composed of the sum of a 5-bit cell specific

component P0 _ NOMINAL _ PUCCH configured by OAM parameter
p0NominalPUCCH and a UE specific component P0 _ UE _ PUCCH configured
by OAM parameter p0uePUCCH.
• δ PUCCH is a UE specific correction value in dB, also referred to as a TPC
command, included in a PDCCH with DCI formats 1/1A/2/2A or DCI format
3.
• Accumulated power control rule is used which is described by
g (i ) = g (i − 1) + δ PUCCH (i − 4) where g (i ) is the current PUCCH power control
adjustment state in subframe i .
The initial value of g (i ) is defined as
g (0) = ∆Prampup + δ Msg 2
Page 416/472
where
o δ Msg 2 is the TPC command indicated in the random access
response (RACH message 2).
o ∆Prampup is the total power ramp-up from the first to the last preamble
configured by parameter preambleTransmitPowerStepSize (see
section 6.2.4).
TPC Command Field δ PUCCH [dB]

0 -1
1 0
2 1
3 3
Table 53: Mapping of TPC command Field in DCI format 1/1A/2/2A to δ PUCCH
ULPowerControlConf::deltaFPUCCHFormat1
Parameter deltaFPUCCHFormat1
{ deltaFm2, deltaF0, deltaF2 }
Value deltaF0
Feature FRS 76501
deltaFPUCCHFormat1 Power Offset
deltaFm2 - 2 dB
deltaF0 0 dB
deltaF2 2 dB
Page 417/472
ULPowerControlConf::deltaFPUCCHFormat1b
Parameter deltaFPUCCHFormat1b
{ deltaF1, deltaF3, deltaF5 }
Value deltaF3
Feature FRS 76501
deltaFPUCCHFormat1b Power Offset
deltaF1 1 dB
deltaF3 3 dB
deltaF5 5 dB
UplinkCAConf::deltaFPUCCHFormat1bCSR10
Parameter deltaFPUCCHFormat1bCSR10
Object
{ deltaF1, deltaF2 }
Value TBD
Feature 160847
deltaFPUCCHFormat1bCSR10 Power Offset
deltaF1 1 dB
deltaF2 2 dB
Page 418/472
ULPowerControlConf::deltaFPUCCHFormat2
Parameter deltaFPUCCHFormat2
{ deltaFm2, deltaF0, deltaF1, deltaF2}
Value deltaF0
Feature FRS 84873
deltaFPUCCHFormat2 Power Offset value
deltaFm2 -2 dB
deltaF0 0 dB
deltaF1 1 dB
deltaF2 2 dB
ULPowerControlConf::deltaFPUCCHFormat2a
Parameter deltaFPUCCHFormat2a
Value deltaF0
Feature FRS 84873
deltaFPUCCHFormat2a Power Offset value
deltaFm2 - 2 dB
deltaF0 0 dB
deltaF2 2 dB
Page 419/472
ULPowerControlConf::deltaFPUCCHFormat2b
Parameter deltaFPUCCHFormat2b
Value deltaF0
Feature FRS 84873
deltaFPUCCHFormat2b Power Offset value
deltaFm2 - 2 dB
deltaF0 0 dB
deltaF2 2 dB
ULPowerControlConf::p0NominalPUCCH
Parameter p0NominalPUCCH
[-127..-96] step = 1 dBm
Feature FRS 76501
Page 420/472
Engineering Recommendation: Parameter p0NominalPUCCH
This parameter is a key RF optimization parameter. Higher settings of this

parameter will improve PUCCH reception, but will also drive higher UE Tx power
leading to interference to neighboring cells, and vice-versa.
The current default value for this parameter is -114.
ULPowerControlConf::p0uePUCCH
Parameter p0uePUCCH
[-8..7] step = 1 dBm
Value 0
Feature FRS 76501
The PUCCH power control procedure is used to guarantee the required error rate.
For this purpose, it aims at achieving a target SIR the value of which guarantees the
required error rate. The SIR target is set to sIRTargetforReferencePUCCHFormat
for PUCCH Format 1A and to sIRTargetforReferencePUCCHFormat +
deltaFPUCCHFormat1b for PUCCH format 1B.
ULPowerControlConf::sIRTargetforReferencePUCCHFormat
Parameter sIRTargetforReferencePUCCHFormat
Range & Unit Float
[-5.0..25.0] step = 0.1 dB
Feature FRS 76501
Page 421/472

sIRTargetforReferencePUCCHFormat
This parameter is a key RF optimization parameter. Higher settings of this

parameter will improve PUCCH reception, but will also drive higher UE Tx power
leading to interference to neighboring cells, and vice-versa.
The current default value for this parameter is “-3.0”.
ALU recommends the operator to not change the settings for this parameter.
6.2.2 PUSCH POWER CONTROL

PUSCH power control mode can be either based on SRS or on DMRS. However, in
LR13.1, only SRS-based PUSCH power control is supported.
For PUSCH power control, the TPC command is embedded in the uplink scheduling
grant with DCI0 or sent in DCI Format 3 and addressed to TPC-PUSCH-RNTI
associated to the UE in question (only for UEs configured with SPS). The TPC-
PUSCH-RNTI is assigned to the user upon UL SPS configuration.
The transmit power for PUSCH PPUSCH in subframe i is given by
{
PPUSCH = min PMAX ,10 log10 ( M PUSCH (i )) + P0 _ PUSCH +
pUSCHPowerControlAlphaFactor × PL + ∆TF (TF (i )) + f (i )} [dBm]
where
• PMAX is the maximum allowed power (depends on the UE power class).
• M PUSCH (i ) is the bandwidth of the PUSCH transmission expressed in

number of resource blocks taken from the resource allocation valid for uplink
subframe i from the scheduling grant received on subframe i − K PUSCH (with
K PUSCH = 4 in FDD).
• P0 _ PUSCH is the sum of an 8-bit cell-specific nominal component
P0 _ NOMINAL _ PUSCH and a 4-bit component P0 _ UE _ PUSCH .
For dynamic transmissions, P0 _ NOMINAL _ PUSCH and P0 _ UE _ PUSCH are
respectively configured by parameters p0NominalPUSCH and

p0UePUSCH, which are signaled to the UE as p0-NominalPUSCH and p0-
UE-PUSCH (see TS 36.331).
Page 422/472
For SPS transmissions, if isP0PersistentFieldPresent is set to “True”,

P0 _ NOMINAL _ PUSCH and P0 _ UE _ PUSCH are respectively configured by
parameters p0NominalPUSCHPersistent and p0UEPUSCHPersistent

which are signaled to the UE as p0-NominalPUSCH-Persistent and p0-UE-
PUSCH-Persistent (see TS 36.331). If on the other hand,
isP0PersistentFieldPresent is set to “False”, p0-NominalPUSCH-Persistent
and p0-UE-PUSCH-Persistent are not signaled to the UE and P0 _ NOMINAL _ PUSCH
and P0 _ UE _ PUSCH are respectively configured by parameters
p0NominalPUSCH and p0UePUSCH as for dynamic grants.
Thus, one could consider enforcing a fixed power offset between dynamic
transmissions and SPS transmissions (during the early period of the call
when the PUSCH Power Control algorithm is trying to converge to the SINR
target) if the need arises, by using different p0 setting for SPS vs. dynamic
transmissions.
• ∆ TF (TF (i )) = 10 log10 (2 MPR⋅K s − 1) , where

o K s is a cell specific parameter given by RRC. If K s = 0 , the MCS
compensation does not execute.
o TF (i ) is the PUSCH transport format valid for subframe i.
o MPR = Modulation × CodingRate = N INFO N RE where N INFO is the

number of information bits and N RE is the number of resource
elements determined from TF (i ) and M PUSCH (i ) for subframe i.
• f (i ) is the PUSCH power control adjustment state function and is described

in section 6.2.2.3.
• The term pUSCHPowerControlAlphaFactor × PL compensates for the
path loss:
o PL is the downlink path loss estimate calculated by the UE as
PL = RS power − filtered RSRP where the filtered RSRP is the result
of the averaging of RSRP using the configurable filter coefficient
filterCoefficient.
o pUSCHPowerControlAlphaFactor is a cell-specific parameter
transmitted as a 3-bit IE in SIB type 2. It takes values in the set : {0,
0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1}:
 When pUSCHPowerControlAlphaFactor
is set to 1,
pUSCHPowerControlAlphaFactor × PL = PL and hence the
uplink path loss is fully compensated.
Page 423/472
 When pUSCHPowerControlAlphaFactor is set in {0.9, 0.8, 0.7,

0.6, 0.5, 0.4}, pUSCHPowerControlAlphaFactor × PL < PL
and hence the uplink path loss is only partially compensated.
This is known as fractional power control (see section 6.2.2.1).
 When pUSCHPowerControlAlphaFactor is set to 0,

pUSCHPowerControlAlphaFactor × PL = 0 and hence the
uplink path loss is not compensated at all.
ULPowerControlConf::p0NominalPUSCH
Parameter p0NominalPUSCH
[-126..24] step = 1dBm
Feature FRS 76501
LogicalChannelConf::p0UePUSCH
Parameter p0UePUSCH
Object ENBEquipment/Enb/DedicatedConf/LogicalChannelConf
[-8..7] step = 1dBm
Feature FRS 76501
Page 424/472
Engineering Recommendation: Parameters p0NominalPUSCH and

p0uePUSCH
Parameters p0NominalPUSCH and p0uePUSCH are key RF optimization

parameters. Higher settings will improve PUSCH reception, but will also drive
higher UE Tx power leading to interference to neighboring cells, and vice-versa.
The current default value for parameter p0UePUSCH is 0.
The current default value for parameter p0NominalPUSCH is given by the table
below:
PUSCHPowerControlAlphaFactor p0NominalPUSCH
1.0 -108
0.8 -82
ULPowerControlConf::isP0PersistentFieldPresent
Parameter isP0PersistentFieldPresent
True/False
Value False ALU recommends the operator to not change this setting
Feature FRS 114531
ULPowerControlConf::p0NominalPUSCHPersistent
Parameter p0NominalPUSCHPersistent
[-126..24] dBm
Value -126 ALU recommends the operator to not change this setting
Feature FRS 114531
Page 425/472
ULPowerControlConf::p0UEPUSCHPersistent
Parameter p0UEPUSCHPersistent
[-8..7] dB
Feature FRS 114531
ULPowerControlConf::filterCoefficient
Parameter filterCoefficient
{fc0, fc1, fc2, fc3, fc4, fc5, fc6, fc7, fc8, fc9, fc11, fc13, fc15,
fc17, fc19 }
Feature FRS 97919
With value fc0 corresponding to k = 0, fc1 corresponding to k = 1, and so on.
Engineering Recommendation: Parameter filterCoefficient
Parameter filterCoefficient is an optional parameter. If it is not set then it is not

sent to the UE. The latter will use the default value defined in TS 36.331 ([R08]),
which is fc4.
Page 426/472
ULPowerControlConf::pUSCHPowerControlAlphaFactor
Parameter pUSCHPowerControlAlphaFactor
{ 0, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0 }
Engineering Recommendation: Parameter pUSCHPowerControlAlphaFactor
Parameter pUSCHPowerControlAlphaFactor is a key RF parameter. Setting it to

“1.0” deactivates fractional power control (i.e. full path loss compensation). As this
parameter decreases, the near-cell throughput and overall cell throughput
increase at the expense of a lower cell-edge throughput as a result of fractional
power control (partial path loss compensation).
This parameter should be set by the operator depending on their strategy. It is

defaulted to “0.8” in ALU templates.
Below, we also provide default settings for pUSCHPowerControlAlphaFactor =
“1.0”.
6.2.2.1 FRACTIONAL POWER CONTROL
Fractional Power Control is used in order to limit the interference that cell edge-users
create to the neighboring cells.
In fractional power control, the transmit power adjustment
pUSCHPowerControlAlphaFactor × PL compensates for only a fraction of the
estimated path loss PL . The result is that the SINR achieved by the UE at the eNB
varies linearly with the path loss. Higher levels of path loss are associated with lower
SINR and vice versa.
Figure 29 illustrates the principle of fractional power control. When the UE is close to
the cell centre, the pathloss decreases and hence the target SINR is increased.
When the UE is at the cell edge, the pathloss increases and hence the target SINR is
decreased.
Page 427/472
Target
SINR
Figure 27 : Principle of fractional power control
6.2.2.2 CQI ASSISTED UL SINR TARGET ADJUSTMENT
[Descoped from LR13. For future reference only]
Currently the cell uses FPC to determine the UL SINR target of a user. However FPC
only responds to UL pathloss, not to interference. This issue becomes most
pronouced around inter-cell border of the same eNB where the UE can be close to
the eNB hence has a small UL Pathloss but may cause high interference to the
neighboring cells.
CQI is a measure by UE to evaluate the DL channel quality amid the noise and the
interference condition, hence it responds to both DL pathloss as well as DL
interference. Although UL and DL may not operate at the same pathloss or traffic
condition, the relative conditions (a good DL pathloss UE is typically a good UL
pathloss UE as well. If DL loading goes up, UL loading typically also goes up) have
good correlation hence CQI can be regarded as a good reference that considers the
interference condition. This is very helpful to identify users in low pathloss region but
along cell borders.
It can be proved that in case of symmetric DL/UL pathloss and fully loaded DL/UL
network, the CQI based SINR determination can deliver an “interference fair” system,
that is, each user, regardless its RF location, will generate the same amount of total
interference to all other cells in the network.
In LR13.3, with FRS 166802, the CQI assisted UL SINR Target adjustement can be
used. If FPC is also used, the resulting UL SINR is the minimum of the two methods.
UL SINR target = min (FPC_SINR target, CQI_mapped_SINR target).
Page 428/472
isCQIbasedPushPowerCtrlEnabled controls the activation of the computation of

the PUSCH SINR target based on the CQI information reported by the UE.
ULPowerControlConf::isCQIbasedPushPowerCtrlEnabled
Parameter isCQIbasedPushPowerCtrlEnabled
[False, True]
Value Default False
Feature FRS 166802
dlSinrToUlSinrTargetConversionFactor indicates the conversion factor f from DL

combined SINR x (derived based on CQI) to UL per-antenna SINR target y: y = x - f.
All in dB.
ULPowerControlConf::dlSinrToUlSinrTargetConversionFactor
Parameter dlSinrToUlSinrTargetConversionFactor
Range & Unit Signed
[-10.0..10.0] step 0.1 (dB)
Value Default 1.5
Feature FRS 166802
dlSinrToUlSinrTargetConversionThresh controls the DL SINR threshold level

above which the CQI based power control requests the use of the maximum SINR
target. When this happens, the PUSCH power control is driven by the path loss
based FPC component of the PUSCH power control function.
ULPowerControlConf::dlSinrToUlSinrTargetConversionThresh
Parameter dlSinrToUlSinrTargetConversionFactor
Range & Unit Signed
[-5..25.0] step 0.1 (dB)
Value Default 25
Feature FRS 166802
Page 429/472
6.2.2.3 PUSCH POWER CONTROL ADJUSTMENT STATE
Define δ PUSCH as a UE specific correction value, sent in the TPC command and
included in PDCCH with DCI format 0. It is computed by a specific algorithm based
on the SINR target and the estimated SINR.
The PUSCH power control adjustment state is given by f (i ) which is defined by:
• If parameter accumulationEnabled is set to “False” (accumulation disabled)
then f (i ) = δPUSCH (i − K PUSCH ) with,
o K PUSCH = 4
o δPUSCH (i − K PUSCH ) was signaled on PDCCH with DCI format 0 on

subframe ( i − K PUSCH ).
• if parameter accumulationEnabled is set to “True” (i.e. accumulation

enabled) then f (i ) = f (i − 1) + δPUSCH (i − K PUSCH ) , with
o K PUSCH = 4
o f (0) = 0 ( f (0) is the first value after reset of accumulation.).
o δ PUSCH (i − K PUSCH ) is signaled on PDCCH with DCI format 0 on

subframe i − K PUSCH .
o If the UE has reached maximum power, positive TPC commands are

not accumulated.
o If the UE has reached minimum power, negative TPC commands

are not accumulated.
o The UE resets accumulation
 when an absolute TPC command is received.
 when PO_UE_PUSCH is received.
 when the UE receives random access response message.
The δ PUSCH dB values signaled on PDCCH with DCI format 0 are given in Table 54.
Page 430/472
TPC Command Accumulated
Field in
δ PUSCH [dB]
DCI format 0
0 -1
1 0
2 1
3 3
Table 54: Mapping of TPC Command Field in DCI format 0 to δ PUSCH values.
ULPowerControlConf::accumulationEnabled
Parameter accumulationEnabled
True/False
Value True
Feature FRS 76432
6.2.2.4 SINR TARGET COMPUTATION

When there is no active semi-static pattern for the UE, the SINR target
SIRTarget_PUSCH is initialized to
uplinkSIRtargetValueForDynamicPUSCHscheduling and then updated regularly

(see section 6.2.2.5) according to
SIRNew_Target_PUSCH =
 SIR − (1 − pUSCHPowerControlAlphaFactor )× ( PLav − pathLossNominal )
max  Target_PUSCH_initial 
min   minSIRtargetForFractionalPower Ctrl 
 
 maxSIRtarg etForFract ionalPower Ctrl 
where
• Parameter pathLossNominal configures the nominal path loss and

corresponds to the path loss at which we want the SINR target to be
uplinkSIRtargetValueForDynamicPUSCHscheduling (i.e. the SINR
uplinkSIRtargetValueForDynamicPUSCHscheduling is also the nominal
SINR target).
Page 431/472
• Parameter maxSIRtargetForFractionalPowerCtrl configures the maximum

SINR target.
• Parameter minSIRtargetForFractionalPowerCtrl configures the minimum

SINR target so that the end-user experience remains acceptable.
• PLav is an estimate of the average path loss based on the power headroom
reports of the UE and the average SRS power (see section 4.6.3.3).
s lo
pe
Target SINR
=
-(
1-
PU
SC
maxSIRtargetForFractionalPowerCtrl
HP
o
we
uplinkSIRtargetValueForDynamicPUSCHscheduling
rC
on
tro
lA
lp
ha
Fa
minSIRtargetForFractionalPowerCtrl
c
to
r)
pathLossNominal
PL
Figure 28: Power Control Parameters
Note that when the full path loss compensation is used (i.e. when
pUSCHPowerControlAlphaFactor is set to 1.0), the target SINR is always equal to
uplinkSIRtargetValueForDynamicPUSCHscheduling and parameters
pathLossNominal, maxSIRtargetForFractionalPowerCtrl, and
minSIRtargetForFractionalPowerCtrl are ignored.
Note that if [p0NominalPUSCH + (pUSCHPowerControlAlphaFactor - 1)×

pathLossNominal - uplinkSIRtargetValueForDynamicPUSCHscheduling] isn’t
comprised between minNoisePlusInterferenceLevelUL and
maxNoisePlusInterferenceLevelUL, the power control algorithm may not work
properly and a warning is displayed by WPS and/or OMC.
SPS SINR target Correction

An SPS correction is applied to the FPC SINR target to obtain the PUSCH SINR
target to use for UEs with an SPS configuration. This is done irrespective of whether
the UE is in SPS active or SPS inactive state.
The SPS SINR correction is itself updated upon termination of each UL SPS HARQ
process (successful termination or failure after maxHARQtx unsuccessful
transmissions). This is based on an SPS BLER loop control.
Thus, the SINRtargetSPSCorrection metric is initialized to 0 and updated (upon
termination of an UL SPS HARQ process) as follows:
Page 432/472
SINRtargetSPSCorrection new = SINRtargetSPSCorrection old

+ SIRtargetSPSCorrectionTable[n HARQ ]
where
• nHARQ is defined as follows:

o If the UL SPS HARQ process terminates successfully, nHARQ
represents the number of HARQ transmissions performed.
o If, on the other hand, the HARQ process fails (after maxHARQtx
unsuccessful transmissions), nHARQ is equal to maxHARQtx+1.
• SIRtargetSPSCorrectionTable is a table of correction step values,
corresponding to the number of HARQ retransmissions:
o The first maxHARQtx elements correspond to the corrections
applied when nHARQ =1,.., maxHARQtx.
o The maxHARQtx +1st element corresponds to the correction applied

when nHARQ = maxHARQtx+1.
Note that the maximum value of maxHARQtx being 5, parameter
SIRtargetSPSCorrectionTable is a table of 5+1=6 values. However, if
maxHARQtx is set to a value less than 5, the (5-maxHARQtx) last
elements of SIRtargetSPSCorrectionTable are insignificant.
Note, however, that the SINR target correction is capped between

minSIRtargetSPSCorrectionValue and maxSIRtargetSPSCorrectionValue.
Also note that after the detection of an UL SPS performance issue (i.e. when
SIRtargetSPSCorrection exceeds
sIRtargetSPSCorrectionThresholdForSPSreleaseUl), the SPS SINR correction is
reset to sIRtargetSPSCorrectionResetValueUl.
The SIRtargetSPSCorrection correction factor is added to the PUSCH FPC SINR target
to yield the SINR target used for PUSCH power control of UEs with an SPS
configuration.
Page 433/472
ULPowerControlConf::SIRtargetSPSCorrectionTable
Parameter SIRtargetSPSCorrectionTable
Range & Unit Table of 6 floats
[-0.5..0.5] step = 0.00078125 dB
Class/Source B--Cell/ eng_tunable
[-0.06250000, 0.06250000, 0.12500000, 0.25000000,
Value 0.50000000, 0.50000000] ALU recommends the operator to not
change this setting
Feature FRS 114531
ULPowerControlConf::maxSIRtargetSPSCorrectionValue
Parameter maxSIRtargetSPSCorrectionValue
Range & Unit Float
[-10.0..10.0] step = 0.1dB
Feature FRS 114531
ULPowerControlConf::minSIRtargetSPSCorrectionValue
Parameter minSIRtargetSPSCorrectionValue
Range & Unit Float
[-10.0..10.0] step = 0.1dB
Feature FRS 114531
Page 434/472
UplinkSemiPersistentSchedulingConf::sIRtargetSPSCorrectionResetValueUl
Parameter sIRtargetSPSCorrectionResetValueUl
Object
Range & Unit Float
[-10.0..10.0] step = 0.1dB
Feature FRS 114531
UplinkSemiPersistentSchedulingConf::sIRtargetSPSCorrectionThresholdForS
PSreleaseUl
Parameter sIRtargetSPSCorrectionThresholdForSPSreleaseUl
Object
Range & Unit Float
[0.0..10.0] step = 0.1 dB
Feature FRS 114531
ULPowerControlConf::pathLossNominal
Parameter pathLossNominal
[0..127] dB
Value 60
Feature FRS 97919
Page 435/472
CellRadioConf::uplinkSIRtargetValueForDynamicPUSCHscheduling
Parameter uplinkSIRtargetValueForDynamicPUSCHscheduling
Range & Unit Float
[-5.0..25.0] step = 0.1 dB
Value See Engineering Recommendation CR 565705
Feature

uplinkSIRtargetValueForDynamicPUSCHscheduling setting
This parameter is a key RF optimization parameter.

In case of limited interference (unloaded neighbor cells), the higher the setting of
this parameter the higher the throughput, but also, the higher the setting the
higher the interference generated in the neighboring cells. However, as in this
mode the focus is on the target cell performance rather than the overall network
performance, this is not an issue.
In loaded network scenarios, the higher the SINR target (i.e. the higher the setting
of uplinkSIRtargetValueForDynamicPUSCHscheduling) the higher the near-
cell throughput but the higher the interference generated in the different cells of
the network (and thus the lower the cell-edge throughput and at some point the
lower overall cell throughput too). In this case, the default setting of this parameter
(for a target IoT of 5.5 dB and a nominal pathloss of 60 dB) should be as follows:
PUSCHPowerControlAlphaFactor uplinkSIRtargetValueForDynamicPUS
CHscheduling
1.0 1.0
0.8 19.0
Note that fine-tuning is required to achieve the right level of interference. Ideally,
the tuning would be done on a cell-by-cell basis (as the topology and the resulting
radio propagation environment generally change from cell to cell).
Page 436/472
ULPowerControlConf::maxSIRtargetForFractionalPowerCtrl
Parameter maxSIRtargetForFractionalPowerCtrl
Range & Unit Float
[-5.0..25.0] step = 0.1dB
Value 19.0
Feature
Rule: Parameter maxSIRtargetForFractionalPowerCtrl setting
The setting of this parameter must satisfy the condition

maxSIRtargetForFractionalPowerCtrl ≥ uplinkSIRtargetValueForDynamicPUSCHscheduling
Rule: Regarding parameter maxSIRtargetForFractionalPowerCtrl
In LA6.0, if this parameter is changed, then the associated modem should be

manually reset.
ULPowerControlConf::minSIRtargetForFractionalPowerCtrl
Parameter minSIRtargetForFractionalPowerCtrl
Range & Unit Float
[-5.0..25.0] step = 0.1dB
Value 0.0
Feature
Rule: Parameter minSIRtargetForFractionalPowerCtrl setting
The setting of this parameter must satisfy the condition

minSIRtargetForFractionalPowerCtrl ≤ uplinkSIRtargetValueForDynamicPUSCHscheduling
Page 437/472
ULPowerControlConf::maxNoisePlusInterferenceLevelUL
Parameter maxNoisePlusInterferenceLevelUL
Range & Unit Float
[-113..-103] step = 1 dBm
Value -108
Feature FRS 115217
The parameter maxNoisePlusInterferenceLevelUL specifies the upper bound of

estimated UL noise and interference level above which FPC (fractional power
control) can fail to work properly. It is used only by WPS and OMC in this release.
Note: The real-time actual UL noise and interference level should be equal to
p0NominalPUSCH + (pUSCHPowerControlAlphaFactor - 1)*pathLossNominal -
uplinkSIRtargetValueForDynamicPUSCHscheduling -- (1) When one or more of the
parameters is changed resulting in a mismatch between the received SINR and the
expectation, the cell requests the UE to adjust its Tx power, effectively making the
equation valid for whatever the noise and interference level the UE is experiencing at
the moment.
ULPowerControlConf::minNoisePlusInterferenceLevelUL
Parameter minNoisePlusInterferenceLevelUL
Range & Unit Float
[-123..-113] step = 1 dBm
Value -118
Feature FRS 115217
The parameter minNoisePlusInterferenceLevelUL specifies the lower bound of

estimated UL noise and interference level below which FPC (fractional power control)
can fail to work properly. It is used only by WPS and OMC in this release.
Note: The real-time actual UL noise and interference level should be equal to
p0NominalPUSCH + (pUSCHPowerControlAlphaFactor - 1)*pathLossNominal -
uplinkSIRtargetValueForDynamicPUSCHscheduling -- (1)
When one or more of the parameters is changed resulting in a mismatch between
the received SINR and the expectation, the cell requests the UE to adjust its Tx
power, effectively making the equation valid for whatever the noise and interference
level the UE is experiencing at the moment. Certain values or combination of values,
however, may cause problems (for example if p0NominalPUSCH is too small, UE Tx
power can be too low to even reach eNB resulting in UE attach failure).
Page 438/472
6.2.2.5 PUSCH POWER CONTROL PROCEDURE
The PUSCH power control procedure is as follows:

• The eNB estimates the PUSCH SINR from the SRS measurement reports
and the noise power received from L1.
• Each time the number of measurements since the last non-zero TPC
command was sent reaches Nmeasurement_threshold:
o The SINR target is updated according to section 6.2.2.4.
o The correction factor δ PUSCH is computed by a specific internal

algorithm.
o The TPC command (containing the correction factor) is sent.
Nmeasurement_threshold is the (minimum) number of UL measurements between non-zero

PUSCH TPC commands. It is computed as
Nmeasurement_threshold=max{1,(5/SRSperiodValue)×Nmeasurement_threshold_reference}
where:
• SRSperiodValue is the SRS period for the user in question.

• Nmeasurement_threshold_reference is the (minimum) number of UL measurements
between non-zero PUSCH TPC commands for a reference SRS period of
5ms:
o When the UE is configured with SPS and is in SPS active state,
Nmeasurement_threshold_reference is configured by parameter
numberofULmeasurementsNeededForSendingValidTPCComma
ndForPUSCHspsMode.
o When the UE is not configured with SPS or is configured with SPS
but is in SPS inactive state, Nmeasurement_threshold_reference is configured by
parameter
numberofULmeasurementsNeededForSendingValidTPCComma
ndForPUSCHdynamicMode.
Note that once UL SPS grant is sent, if there is no non-SPS traffic, there will be no
DCI0 grants and therefore no TPC command will be sent.
Consequently, PUSCH TPC commands are sent on either DCI0 or DCI3, whichever
DCI whose transmit opportunity comes first.
DCI3 for PUSCH power control is targeted to be sent towards an SPS UE every
tpcPeriodForPUSCHtpcOverDCI3 ×10ms.
Page 439/472
CellRadioConf::numberofULmeasurementsNeededForSendingValidTPCComm
andForPUSCHdynamicMode
numberofULmeasurementsNeededForSendingValidTPCComm
Parameter
andForPUSCHdynamicMode
[1..255]
Feature
CellRadioConf::numberofULmeasurementsNeededForSendingValidTPCComm
andForPUSCHspsMode
numberofULmeasurementsNeededForSendingValidTPCComm
Parameter
andForPUSCHspsMode
[1..255]
Feature FRS 114531
ULPowerControlConf::tpcPeriodForPUSCHtpcOverDCI3
Parameter tpcPeriodForPUSCHtpcOverDCI3
[1..20]
Feature FRS 114531
Page 440/472
6.2.2.6 UPLINK INTERFERENCE CONTROL
6.2.2.6.1 GENERIC ALGORITHM
A basic uplink interference control mechanism was introduced in LA5.0 with

CR604179. The activation of this mechanism and the parameters used by this
mechanism was controlled by some bits of LteCell::spare0 and LteCell:spare1. In
LR13.1, new parameters described below are used instead.
The purpose of the interference control mechanism is two fold.

• In high uplink interference scenarios: Stops PUSCH power control avalanche
effects when two adjacent cells are strongly interfering with each other. This is
achieved by forcing all PUSCH SIR Targets to 0dB on the cell when the level
interference reaches a threshold level.
• In lighter uplink interference scenarios: Backs off the PUSCH SIR target
proportionally to the measured level of interference. This allows to tune PUSCH
power control aggressively for unloaded scenarios (and therefore allow optimal
performance for single UE drive tests) whilst ensuring a more conservative
power control tuning for load levels corresponding to commercial deployment
scenarios.
ULPowerControlConf::pUSCHioTControlActivationFlag
Parameter pUSCHioTControlActivationFlag
True/False
Value False
Feature
This parameter controls the activation of the PUSCH IoT control functionality in the
uplink scheduler.
ULPowerControlConf::pUSCHioTControlCoefAboveThr1
Parameter pUSCHioTControlCoefAboveThr1
Range & Unit Float
[0.0..2.0] step 0.1
Value 0.5
Feature
This parameter control the coefficient used to compute the amount of PUSCH SIR
target correction for IoT levels above pUSCHioTControlThresh1.
Page 441/472
ULPowerControlConf::pUSCHioTControlCoefBelowThr1
Parameter pUSCHioTControlCoefBelowThr1
Range & Unit Float
[0.0..2.0] step 0.1
Value 1.0
Feature
This parameter control the coefficient used to compute the amount of PUSCH SIR
target correction for IoT levels below pUSCHioTControlThresh1.
ULPowerControlConf::pUSCHioTControlMinTargetCorrAboveThr1
Parameter pUSCHioTControlMinTargetCorrAboveThr1
[-10..10] dB
Value 0
Feature
This parameter controls the minimum amount of SIR target correction that can be
applied to the call by the IoT control function when the IoT level is above the value of
pUSCHioTControlThresh1.
ULPowerControlConf::pUSCHioTControlMinTargetCorrBelowThr1
Parameter pUSCHioTControlMinTargetCorrBelowThr1
[-10..10] dB
Value -3
Feature
This parameter controls the minimum amount of SIR target correction that can be
applied to the call by the IoT control function when the IoT level is below the value of
pUSCHioTControlThresh1.
Page 442/472
ULPowerControlConf::pUSCHioTControlThermalNoiseCorr
Parameter pUSCHioTControlThermalNoiseCorr
[-10..50] dB
Value 0
Feature
This parameter controls the correction to the default wideband thermal noise value
that is assumed by the PUSCH IoT control function.
ULPowerControlConf::pUSCHioTControlThresh1
Parameter pUSCHioTControlThresh1
[0..60] dB
Value 3
Feature
This parameter controls the IoT threshold values for applying a PUSCH SIR target
correction proportional to the amount of IoT above pUSCHioTControlThresh1
expressed in dB.
ULPowerControlConf::pUSCHioTControlThresh2
Parameter pUSCHioTControlThresh2
[0..60] dB
Value 15
Feature
This parameter controls the threshold values for forcing all UEs to use PUSCH SIR
target of 0dB and block any PUSCH TPC power up command.
Page 443/472
Engineering Recommendation: Regarding parameters

pUSCHioTControlThresh1 and pUSCHioTControlThresh2 in HetNet (same
frequency and frequency bandwidth)
pUSCHioTControlThresh1 for Metro = pUSCHioTControlThresh1 for Macro +
delta, and
pUSCHioTControlThresh2 for Metro = pUSCHioTControlThresh2 for Macro +
Delta,
where Delta [dB] = referenceSignalPower for Macro [dBm] –
referenceSignalPower for Metro [dBm], according to configuration
This recommendation is applicable for both isolated and group of Metro Cells.
6.2.2.7 INTRA-ENB INTER-SECTOR IOT CONTROL
[Descoped from LR13; for future reference only]

In order to address even more ambitious capacity figures in LR13.1 and LR13.3, the
IoT control mechanism is enhanced to intra-eNB inter-sector IoT control in order to
limit UL interference. The rationale for this enhancement is that field observations
show that, in macrocell scenarios, the majority of inter-cell interference is inter-sector
interference.
LR13.1 provides the ability for the eNB to monitor the UL interference conditions in
all its serving cells. The information is then used by each of these cells to compute
an IoT level. And this IoT metric finally serves as input to calculate the PUSCH SINR
target correction described in previous section.
This functionality is controlled by bits 4 to 14 of spare parameter Enb::spare9 in
LR13.1, replaced by real parameters in LR13.3, as follows:
Spare parameter used in LR13.1:
o Bit 4 in LR13.1, parameter isInterSectorIoTcontrolEnabled in LR13.3:
controls the activation of the intra-eNB inter-Sector IoT control functionality.
By default, the functionality will be deactivated.
o Bits 5-7 in LR13.1, parameter interSectorIoTcontrolPeriod in LR13.3: defines
the reporting period of the intra-eNB inter-Sector IoT control functionality.
This period can take values from 200 to 1000ms with steps of 200ms (0--
>200ms, 5--> 1000ms, default value: 1000ms).
o Bits 8-14 in LR13.1, parameter interSectorIoTcontrolminCellLoadThr in

LR13.3: defines the minimum traffic load on the cell. Below that level, all IoT
reports sent to other sectors is forced to the thermal noise level (i.e. IoT =
0dB). This traffic load can take values from 0 to 100% with a step of 1%
(default value: 5%).
Page 444/472
Real parameters used in LR13.3:
ULPowerControlConf::isInterSectorIoTcontrolEnabled
Parameter isInterSectorIoTcontrolEnabled
True/False
Value False (Default)
Feature FRS 166802
ULPowerControlConf::interSectorIoTcontrolPeriod
Parameter interSectorIoTcontrolPeriod
[200..1000] step 200 (ms)
Value 1000 (Default)
Feature FRS 166802
ULPowerControlConf::interSectorIoTcontrolminCellLoadThr
Parameter interSectorIoTcontrolminCellLoadThr
[0..100] (%)
Value 5 (Default)
Feature FRS 166802
6.2.2.8 IOT AWARE PRB ASSIGNMENT FOR FDS
[Descoped from LR13; for future reference only]

In order to decrease IoT issue at carrier edges, the UL scheduler applies an IoT-
based weight to the PRB assignment for FDS users. That is, a PRB that has lower
IoT measurement shall be prefered for FD PUSCH transmission over a PRB that has
higher IoT measurement.
This mechanism is enabled through the parameter iotAwareFDSEnabled.
Page 445/472
CellL2ULConf::iotAwareFDSEnabled
Parameter iotAwareFDSEnabled
{False, True}
Value Default False
Feature FRS 166802
6.2.3 SOUNDING REFERENCE SIGNAL POWER CONTROL

The transmit power of the SRS signal is set in dBm at the UE as
PSRS (i ) = min( PMAX , PSRS _ OFFSET + 10 log( M SRS ) + P0 _ PUSCH

+ pUSCHPowerControlAlphaFactor × PL + f (i ))
where
• PSRS _ OFFSET is a power offset configured by parameter pSRSoffset.
o For K s = 0 , PSRS _ OFFSET is a 4-bit UE specific parameter configured by

RRC with 1.5 dB step size in the range [-10.5,12] dB ( PSRS _ OFFSET = -10.5
+ 1.5 × pSRSOffset).
o For K s = 1.25 , PSRS _ OFFSET is a 4-bit UE specific parameter configured by

RRC with 1dB step size in the range [-3, 12] ( PSRS _ OFFSET = pSRSOffset
- 3).
o M SRS is the bandwidth of the SRS transmission expressed in number of

resource blocks (see [Vol. 3] for more details on Sounding Reference
Signal).
• f (i ) is the current power control adjustment state for the PUSCH.
Page 446/472
ULPowerControlConf::pSRSOffset
Parameter pSRSOffset
[0..15]
Value 4
Feature FRS 76501
6.2.4 RACH POWER CONTROL

6.2.4.1 POWER ALLOCATION FOR RA PREAMBLE
Open-loop power control is applied for initial transmission of RACH. The transmit
power is determined taking into account the total uplink interference level and the
required SINR operating point.
Transmit power can be determined at the UE as
(
PRACH _ msg1 = min Pmax , PL + P0 _ PREAMBLE + ∆ PREAMBLE + (N PREAMBLE − 1) × ∆PRAMP _ UP )
where
• The term PL is the downlink path loss estimated at the UE from DL RS.
• P0 _ PREAMBLE is the starting preamble transmit power offset configured by
parameter preambleInitialReceivedTargetPower.
• ∆ PREAMBLE is the power offset value dependent on PRACH preamble format.

It is hardcoded to 0 dB in LA6.0.
• ∆PRAMP _ UP is the power ramping step size. It is configured by parameter

preambleTransmitPowerStepSize.
• N PREAMBLE is the maximum number of preamble transmissions. It is
configured by parameter preambleTransMax described in [Vol. 3].
Page 447/472
CellRachConf::preambleInitialReceivedTargetPower
Parameter preambleInitialReceivedTargetPower
{ dBm-120, dBm-118, dBm-116, dBm-114, dBm-112, dBm-110,
dBm-108, dBm-106, dBm-104, dBm-102, dBm-100, dBm-98,
dBm-96, dBm-94, dBm-92, dBm-90 }
Feature

preambleInitialReceivedTargetPower
This parameter is a key RF optimization parameter that impacts connection setup

performance and UL interference to neighboring cells. Higher values will minimize
the repetitions/ RACH attempts and hence expedite connection setup, but will
cause higher interference to other cells. Lower values will tend to increase RACH
repetition/ connection setup delay. Ideally initial power should be set high enough
to achieve good success at 1st attempt at reasonable IoT loading levels.
The current default value for this parameter is dBm-104.
CellRachConf::preambleTransmitPowerStepSize
Parameter preambleTransmitPowerStepSize
{dB0, dB2, dB4, dB6}
Feature
Page 448/472
Engineering Recommendation: Parameter preambleTransmitPowerStepSize
This parameter is a key RF optimization parameter that impacts connection setup

performance and uplink interference to neighboring cells. Higher values will
minimize the repetitions/ RACH attempts and hence expedite connection setup,
but will cause higher interference to other cells. Lower values will tend to increase
RACH repetition/ connection setup delay.
The current default value for this parameter is dB6.
6.2.4.2 POWER ALLOCATION FOR RACH MESSAGE 3
The Nominal transmit power for RACH msg3, denoted as PO _ NOMINAL _ PUSCH is
computed at the UE as
PO _ NOMINAL _ PUSCH = PO _ PREAMBLE + ∆ PREAMBLE _ Msg 3
where ∆ PREAMBLE _ Msg 3 is the nominal power offset between RACH preamble and
RACH message 3. It is configured by parameter deltaPreambleMsg3.
ULPowerControlConf::deltaPreambleMsg3
Parameter deltaPreambleMsg3
[-2..12] step = 2 dB
Value 0
Feature FRS 96760
The Transmit power for RACH message 3 is determined (in dBm) by normal PUSCH
power control formula:
PPUSCH (i ) = min( Pmax ,10 log10 ( M PUSCH (i )) + P0 _ PUSCH
+ pUSCHPowerControlAlphaFactor × PL + ∆ TF (i ) + f (i ))
Page 449/472
where
• Pmax is the maximum allowed power and depends on the UE power class.
• M PUSCH (i ) is the bandwidth of the PUSCH transmission expressed in

number of resource blocks taken from the resource allocation valid for uplink
subframe i from scheduling grant received on subframe i − K PUSCH .
• Parameter P0 _ PUSCH is computed as
P0 _ PUSCH = P0 _ NOMINAL _ PUSCH + P0 _ UE _ PUSCH
• PL is the downlink pathloss estimate calculated in the UE.
• ∆ TF (TF (i )) = 10 log10 (2 MPR⋅K s − 1) is the transport format dependent power

offset parameter.
f (i ) is initialized (for the first transmission of RACH message 3) as follows
f (0) = ∆Prampup + δ msg 2

where δ msg 2 is the TPC command indicated in the Random Access Response
(RACH message 2). It is configured by parameter tPCRACHMsg3.
CellRachConf::tPCRACHMsg3
Parameter tPCRACHMsg3
{-6dB, -4dB, -2dB, 0dB, 2dB, 4dB, 6dB, 8dB}
Value 4dB
Feature FRS 76501
With the following mapping between the TPC command and parameter values
tPCRACHMsg3 TPC Command
-6 0
-4 1
-2 2
0 3
2 4
4 5
6 6
8 7
Page 450/472
For subsequent transmission of RACH message 3, accumulated power control

formula f (i ) = f (i − 1) + δ PUSCH (i − K PUSCH ) applies.
Page 451/472
7 ANNEX: MODULATION AND CODING SCHEMES

AND TBS DETERMINATION
7.1 DOWNLINK MODULATION AND CODING SCHEMES AND
TBS DETERMINATION
Each Transport Block (MAC PDU) is coded prior to modulation, layer mapping,
precoding and OFDM processing.
The combination of the modulation and the channel coding (identified by its rate)
forms one of the 32 possible Modulation and Coding Schemes defined in [R06] (see
Table 55).
MCS Index( I MCS ) Modulation TBS Index( I TBS )

0 QPSK 0
1 QPSK 1
2 QPSK 2
3 QPSK 3
4 QPSK 4
5 QPSK 5
6 QPSK 6
7 QPSK 7
8 QPSK 8
9 QPSK 9
10 16QAM 9
11 16QAM 10
12 16QAM 11
13 16QAM 12
14 16QAM 13
15 16QAM 14
16 16QAM 15
17 64QAM 15
18 64QAM 16
19 64QAM 17
20 64QAM 18
21 64QAM 19
22 64QAM 20
23 64QAM 21
24 64QAM 22
25 64QAM 23
26 64QAM 24
27 64QAM 25
28 64QAM 26
29 QPSK
30 16QAM reserved
31 64QAM
Table 55: Modulation TBS index for Downlink Modulation and Coding Schemes
Page 452/472
Note that MCSs 29, 30, 31 indicate to use the previous MCS received in PDCCH
(MCS 29 for the previous QPSK-based MCS, MCS 30 for the previous 16-QAM
based MCS and MCS 31 for the previous 64-QAM-based MCS), which can be used
when a Transport Block is repeated (if isDlSchedulingInSchPbchRbEnabled is set
to “True”).
Also note that the UE may skip decoding a transport block in an initial transmission if
the effective channel code rate is higher than 0.93:
• With two transmit antennas, this may occur with MCS=28 when CFI=2 or
CFI=3 (depending on the number of allocated PRBs).
• With one transmit antenna, this may occur with MCS=28 when CFI=3.
The Transport Block Size (TBS) is derived from Table 59 based on I TBS (mapped
from the MCS) and N PRB (number of PRBs used for the transmission of the transport
block in question).
Note that MCSs 9 and 10 give the same TBS (since they are mapped to the same
value of I TBS ). Similarly, MCSs 16 and 17 give the same TBS.
7.2 PUSCH MODULATION AND CODING SCHEMES AND TBS

DETERMINATION
Each Transport Block (MAC PDU) is coded prior to modulation and SC-FDMA
processing.
The combination of the modulation and the channel coding (identified by its rate)
forms one of the 32 possible Modulation and Coding Schemes defined in [R06] (see
Table 56).
Note that MCSs 29, 30 and 31 indicate to use the previous MCS received in PDCCH.
Page 453/472
MCS Index( I MCS ) Modulation TBS Index( I TBS )

0 QPSK 0
1 QPSK 1
2 QPSK 2
3 QPSK 3
4 QPSK 4
5 QPSK 5
6 QPSK 6
7 QPSK 7
8 QPSK 8
9 QPSK 9
10 QPSK 10
11 16QAM 10
12 16QAM 11
13 16QAM 12
14 16QAM 13
15 16QAM 14
16 16QAM 15
17 16QAM 16
18 16QAM 17
19 16QAM 18
20 16QAM 19
21 64QAM 19
22 64QAM 20
23 64QAM 21
24 64QAM 22
25 64QAM 23
26 64QAM 24
27 64QAM 25
28 64QAM 26
29
30 Reserved
31
Table 56: Modulation and TBS index for PUSCH Modulation and Coding Schemes
Restriction: PUSCH Modulation and Coding Schemes
In LR13.1, only MCSs [0,…, 22] are supported.

Also, MCS21 is not used as it yields the same transport block size and modulation
scheme as MCS20.
The Transport Block Size (TBS) is derived from Table 59 based on I TBS (mapped
from the MCS) and N PRB (number of PRBs used for the transmission of the transport
block in question).
Note that MCSs 10 and 11 give the same TBS (since they are mapped to the same
value of I TBS ). Similarly, MCSs 20 and 21 give the same TBS.
Page 454/472
Also note that the constraints on the maximum TBS for UE categories 1 and 2 (see
Table 3) impose the following constraints on the maximum number of PRBs that are
granted to a given UE for a given MCS:
Selected MCS Maximum grant size (in PRBs)

0 100
1 100
2 100
3 81
4 72
5 54
6 50
7 40
8 36
9 32
10 27
11 27
12 25
13 20
14 20
15 18
16 16
17 16
18 12
19 12
20 12
21 12
22 10
Table 57: Maximum grant size (in PRBs) for a category 1 UE
Page 455/472
Selected MCS Maximum grant size (in PRBs)

0 100
1 100
2 100
3 100
4 100
5 100
6 100
7 100
8 100
9 100
10 100
11 100
12 100
13 100
14 100
15 90
16 81
17 75
18 64
19 64
20 60
21 60
22 54
Table 58: Maximum grant size (in PRBs) for a category 2 UE
On the other hand, parameters betaOffsetCQIIndex, betaOffsetRIIndex and

HARQ − ACK RI
betaOffsetACKIndex respectively configure the indexes I offset , I offset and
CQI
I offset (as defined in TS 36.213) which control the robustness of the CQI/RI/ACK-
NACK over PUSCH.
HARQ − ACK
Parameter betaOffsetACKIndexForTTIbundling controls the I offset index (as
defined in TS 36.213) that is sent to UEs configured with TTI Bundling.
In LR13.3, parameter UplinkCAConf::betaOffsetACKIndexForFourBitsAckNack

HARQ − ACK
controls the I offset index (as defined in TS 36.213) that is sent to UEs
configured with Carrier Aggregation.
Page 456/472
CellL1ULConf::betaOffsetCQIIndex
Parameter betaOffsetCQIIndex
[2..15]
Value 8
Feature
CellL1ULConf::betaOffsetRIIndex
Parameter betaOffsetRIIndex
[0..12]
Value 6
Feature
CellL1ULConf::betaOffsetACKIndex
Parameter betaOffsetACKIndex
[0..15]
Value 10
Feature
Page 457/472
CellL1ULConf::betaOffsetACKIndexForTTIbundling
[0..14]
Value 12
UplinkCAConf::betaOffsetACKIndexForFourBitsAckNack
Object
[0..15]
Value 1
Feature 160847
Page 458/472
7.3 3GPP TRANSPORT BLOCK SIZE TABLE

I TBS N PRB
1 2 3 4 5 6 7 8 9 10
0 16 32 56 88 120 152 176 208 224 256
1 24 56 88 144 176 208 224 256 328 344
2 32 72 144 176 208 256 296 328 376 424
3 40 104 176 208 256 328 392 440 504 568
4 56 120 208 256 328 408 488 552 632 696
5 72 144 224 328 424 504 600 680 776 872
6 328 176 256 392 504 600 712 808 936 1032
7 104 224 328 472 584 712 840 968 1096 1224
8 120 256 392 536 680 808 968 1096 1256 1384
9 136 296 456 616 776 936 1096 1256 1416 1544
10 144 328 504 680 872 1032 1224 1384 1544 1736
11 176 376 584 776 1000 1192 1384 1608 1800 2024
12 208 440 680 904 1128 1352 1608 1800 2024 2280
13 224 488 744 1000 1256 1544 1800 2024 2280 2536
14 256 552 840 1128 1416 1736 1992 2280 2600 2856
15 280 600 904 1224 1544 1800 2152 2472 2728 3112
16 328 632 968 1288 1608 1928 2280 2600 2984 3240
17 336 696 1064 1416 1800 2152 2536 2856 3240 3624
18 376 776 1160 1544 1992 2344 2792 3112 3624 4008
19 408 840 1288 1736 2152 2600 2984 3496 3880 4264
20 440 904 1384 1864 2344 2792 3240 3752 4136 4584
21 488 1000 1480 1992 2472 2984 3496 4008 4584 4968
22 520 1064 1608 2152 2664 3240 3752 4264 4776 5352
23 552 1128 1736 2280 2856 3496 4008 4584 5160 5736
24 584 1192 1800 2408 2984 3624 4264 4968 5544 5992
25 616 1256 1864 2536 3112 3752 4392 5160 5736 6200
26 712 1480 2216 2984 3752 4392 5160 5992 6712 7480
I TBS N PRB
11 12 13 14 15 16 17 18 19 20
0 288 328 344 376 392 424 456 488 504 536
1 376 424 456 488 520 568 600 632 680 712
2 472 520 568 616 648 696 744 776 840 872
3 616 680 744 808 872 904 968 1032 1096 1160
4 776 840 904 1000 1064 1128 1192 1288 1352 1416
5 968 1032 1128 1224 1320 1384 1480 1544 1672 1736
6 1128 1224 1352 1480 1544 1672 1736 1864 1992 2088
7 1320 1480 1608 1672 1800 1928 2088 2216 2344 2472
8 1544 1672 1800 1928 2088 2216 2344 2536 2664 2792
9 1736 1864 2024 2216 2344 2536 2664 2856 2984 3112
10 1928 2088 2280 2472 2664 2792 2984 3112 3368 3496
11 2216 2408 2600 2792 2984 3240 3496 3624 3880 4008
12 2472 2728 2984 3240 3368 3624 3880 4136 4392 4584
13 2856 3112 3368 3624 3880 4136 4392 4584 4968 5160
14 3112 3496 3752 4008 4264 4584 4968 5160 5544 5736
15 3368 3624 4008 4264 4584 4968 5160 5544 5736 6200
16 3624 3880 4264 4584 4968 5160 5544 5992 6200 6456
17 4008 4392 4776 5160 5352 5736 6200 6456 6712 7224
18 4392 4776 5160 5544 5992 6200 6712 7224 7480 7992
19 4776 5160 5544 5992 6456 6968 7224 7736 8248 8504
20 5160 5544 5992 6456 6968 7480 7992 8248 8760 9144
21 5544 5992 6456 6968 7480 7992 8504 9144 9528 9912
Page 459/472
22 5992 6456 6968 7480 7992 8504 9144 9528 1029 1068
6 0
23 6200 6968 7480 7992 8504 9144 9912 1029 1106 1144
6 4 8
24 6712 7224 7992 8504 9144 9912 1029 1106 1144 1221
6 4 8 6
25 6968 7480 8248 8760 9528 1029 1068 1144 1221 1257
6 0 8 6 6
26 8248 8760 9528 1029 1106 1183 1257 1353 1411 1468
6 4 2 6 6 2 8
I TBS N PRB
21 22 23 24 25 26 27 28 29 30
0 568 600 616 648 680 712 744 776 776 808
1 744 776 808 872 904 936 968 1000 1032 1064
2 936 968 1000 1064 1096 1160 1192 1256 1288 1320
3 1224 1256 1320 1384 1416 1480 1544 1608 1672 1736
4 1480 1544 1608 1736 1800 1864 1928 1992 2088 2152
5 1864 1928 2024 2088 2216 2280 2344 2472 2536 2664
6 2216 2280 2408 2472 2600 2728 2792 2984 2984 3112
7 2536 2664 2792 2984 3112 3240 3368 3368 3496 3624
8 2984 3112 3240 3368 3496 3624 3752 3880 4008 4264
9 3368 3496 3624 3752 4008 4136 4264 4392 4584 4776
10 3752 3880 4008 4264 4392 4584 4776 4968 5160 5352
11 4264 4392 4584 4776 4968 5352 5544 5736 5992 5992
12 4776 4968 5352 5544 5736 5992 6200 6456 6712 6712
13 5352 5736 5992 6200 6456 6712 6968 7224 7480 7736
14 5992 6200 6456 6968 7224 7480 7736 7992 8248 8504
15 6456 6712 6968 7224 7736 7992 8248 8504 8760 9144
16 6712 7224 7480 7736 7992 8504 8760 9144 9528 9912
17 7480 7992 8248 8760 9144 9528 9912 1029 1029 1068
6 6 0
18 8248 8760 9144 9528 9912 1029 1068 1106 1144 1183
6 0 4 8 2
19 9144 9528 9912 1029 1068 1106 1144 1221 1257 1296
6 0 4 8 6 6 0
20 9912 1029 1068 1106 1144 1221 1257 1296 1353 1411
6 0 4 8 6 6 0 6 2
21 1068 1106 1144 1221 1257 1296 1353 1411 1468 1526
0 4 8 6 6 0 6 2 8 4
22 1144 1183 1257 1296 1353 1411 1468 1526 1584 1641
8 2 6 0 6 2 8 4 0 6
23 1221 1257 1296 1353 1411 1468 1526 1584 1641 1699
6 6 0 6 2 8 4 0 6 2
24 1296 1353 1411 1468 1526 1584 1641 1699 1756 1833
0 6 2 8 4 0 6 2 8 6
25 1353 1411 1468 1526 1584 1641 1699 1756 1833 1908
6 2 8 4 0 6 2 8 6 0
26 1526 1641 1699 1756 1833 1908 1984 2061 2138 2215
4 6 2 8 6 0 8 6 4 2
I TBS N PRB
31 32 33 34 35 36 37 38 39 40
0 840 872 904 936 968 1000 1032 1032 1064 1096
1 1128 1160 1192 1224 1256 1288 1352 1384 1416 1416
2 1384 1416 1480 1544 1544 1608 1672 1672 1736 1800
3 1800 1864 1928 1992 2024 2088 2152 2216 2280 2344
Page 460/472
4 2216 2280 2344 2408 2472 2600 2664 2728 2792 2856
5 2728 2792 2856 2984 3112 3112 3240 3368 3496 3496
6 3240 3368 3496 3496 3624 3752 3880 4008 4136 4136
7 3752 3880 4008 4136 4264 4392 4584 4584 4776 4968
8 4392 4584 4584 4776 4968 4968 5160 5352 5544 5544
9 4968 5160 5160 5352 5544 5736 5736 5992 6200 6200
10 5544 5736 5736 5992 6200 6200 6456 6712 6712 6968
11 6200 6456 6712 6968 6968 7224 7480 7736 7736 7992
12 6968 7224 7480 7736 7992 8248 8504 8760 8760 9144
13 7992 8248 8504 8760 9144 9144 9528 9912 9912 1029
6
14 8760 9144 9528 9912 9912 1029 1068 1106 1106 1144
6 0 4 4 8
15 9528 9912 1029 1029 1068 1106 1144 1183 1183 1221
6 6 0 4 8 2 2 6
16 9912 1029 1068 1106 1144 1183 1221 1221 1257 1296
6 0 4 8 2 6 6 6 0
17 1106 1144 1183 1221 1257 1296 1353 1353 1411 1468
4 8 2 6 6 0 6 6 2 8
18 1221 1257 1296 1353 1411 1411 1468 1526 1526 1584
6 6 0 6 2 2 8 4 4 0
19 1353 1353 1411 1468 1526 1526 1584 1641 1699 1699
6 6 2 8 4 4 0 6 2 2
20 1468 1468 1526 1584 1641 1699 1699 1756 1833 1833
8 8 4 0 6 2 2 8 6 6
21 1584 1584 1641 1699 1756 1833 1833 1908 1984 1984
0 0 6 2 8 6 6 0 8 8
22 1699 1699 1756 1833 1908 1908 1984 2061 2138 2138
2 2 8 6 0 0 8 6 4 4
23 1756 1833 1908 1984 1984 2061 2138 2215 2215 2292
8 6 0 8 8 6 4 2 2 0
24 1908 1984 1984 2061 2138 2215 2292 2292 2368 2449
0 8 8 6 4 2 0 0 8 6
25 1984 2061 2061 2138 2215 2292 2368 2449 2449 2545
8 6 6 4 2 0 8 6 6 6
26 2292 2368 2449 2545 2545 2641 2737 2833 2929 2929
0 8 6 6 6 6 6 6 6 6
I TBS N PRB
41 42 43 44 45 46 47 48 49 50
0 1128 1160 1192 1224 1256 1256 1288 1320 1352 1384
1 1480 1544 1544 1608 1608 1672 1736 1736 1800 1800
2 1800 1864 1928 1992 2024 2088 2088 2152 2216 2216
3 2408 2472 2536 2536 2600 2664 2728 2792 2856 2856
4 2984 2984 3112 3112 3240 3240 3368 3496 3496 3624
5 3624 3752 3752 3880 4008 4008 4136 4264 4392 4392
6 4264 4392 4584 4584 4776 4776 4968 4968 5160 5160
7 4968 5160 5352 5352 5544 5736 5736 5992 5992 6200
8 5736 5992 5992 6200 6200 6456 6456 6712 6968 6968
9 6456 6712 6712 6968 6968 7224 7480 7480 7736 7992
10 7224 7480 7480 7736 7992 7992 8248 8504 8504 8760
11 8248 8504 8760 8760 9144 9144 9528 9528 9912 9912
12 9528 9528 9912 9912 1029 1068 1068 1106 1106 1144
6 0 0 4 4 8
13 1068 1068 1106 1144 1144 1183 1221 1221 1257 1296
0 0 4 8 8 2 6 6 6 0
14 1183 1221 1221 1257 1296 1296 1353 1353 1411 1411
Page 461/472
2 6 6 6 0 0 6 6 2 2
15 1257 1296 1296 1353 1353 1411 1468 1468 1526 1526
6 0 0 6 6 2 8 8 4 4
16 1353 1353 1411 1411 1468 1468 1526 1584 1584 1641
6 6 2 2 8 8 4 0 0 6
17 1468 1526 1526 1584 1641 1641 1699 1756 1756 1833
8 4 4 0 6 6 2 8 8 6
18 1641 1641 1699 1756 1756 1833 1833 1908 1908 1984
6 6 2 8 8 6 6 0 0 8
19 1756 1833 1833 1908 1908 1984 2061 2061 2138 2138
8 6 6 0 0 8 6 6 4 4
20 1908 1984 1984 2061 2061 2138 2215 2215 2292 2292
0 8 8 6 6 4 2 2 0 0
21 2061 2138 2138 2215 2292 2292 2368 2449 2449 2545
6 4 4 2 0 0 8 6 6 6
22 2215 2292 2292 2368 2449 2449 2545 2545 2641 2737
2 0 0 8 6 6 6 6 6 6
23 2368 2449 2449 2545 2545 2641 2737 2737 2833 2833
8 6 6 6 6 6 6 6 6 6
24 2545 2545 2641 2641 2737 2833 2833 2929 2929 3057
6 6 6 6 6 6 6 6 6 6
25 2641 2641 2737 2833 2833 2929 2929 3057 3170 3170
6 6 6 6 6 6 6 6 4 4
26 3057 3057 3170 3285 3285 3400 3516 3516 3669 3669
6 6 4 6 6 8 0 0 6 6
I TBS N PRB
51 52 53 54 55 56 57 58 59 60
0 1416 1416 1480 1480 1544 1544 1608 1608 1608 1672
1 1864 1864 1928 1992 1992 2024 2088 2088 2152 2152
2 2280 2344 2344 2408 2472 2536 2536 2600 2664 2664
3 2984 2984 3112 3112 3240 3240 3368 3368 3496 3496
4 3624 3752 3752 3880 4008 4008 4136 4136 4264 4264
5 4584 4584 4776 4776 4776 4968 4968 5160 5160 5352
6 5352 5352 5544 5736 5736 5992 5992 5992 6200 6200
7 6200 6456 6456 6712 6712 6712 6968 6968 7224 7224
8 7224 7224 7480 7480 7736 7736 7992 7992 8248 8504
9 7992 8248 8248 8504 8760 8760 9144 9144 9144 9528
10 9144 9144 9144 9528 9528 9912 9912 1029 1029 1068
6 6 0
11 1029 1068 1068 1106 1106 1144 1144 1183 1183 1221
6 0 0 4 4 8 8 2 2 6
12 1183 1183 1221 1221 1257 1257 1296 1296 1353 1353
2 2 6 6 6 6 0 0 6 6
13 1296 1353 1353 1411 1411 1468 1468 1468 1526 1526
0 6 6 2 2 8 8 8 4 4
14 1468 1468 1526 1526 1584 1584 1641 1641 1699 1699
8 8 4 4 0 0 6 6 2 2
15 1584 1584 1641 1641 1699 1699 1756 1756 1833 1833
0 0 6 6 2 2 8 8 6 6
16 1641 1699 1699 1756 1756 1833 1833 1908 1908 1984
6 2 2 8 8 6 6 0 0 8
17 1833 1908 1908 1984 1984 2061 2061 2061 2138 2138
6 0 0 8 8 6 6 6 4 4
18 1984 2061 2138 2138 2215 2215 2292 2292 2368 2368
8 6 4 4 2 2 0 0 8 8
19 2215 2215 2292 2292 2368 2449 2449 2545 2545 2545
2 2 0 0 8 6 6 6 6 6
Page 462/472
20 2368 2449 2449 2545 2545 2641 2641 2737 2737 2833
8 6 6 6 6 6 6 6 6 6
21 2545 2641 2641 2737 2737 2833 2833 2929 2929 3057
6 6 6 6 6 6 6 6 6 6
22 2737 2833 2833 2929 2929 3057 3057 3170 3170 3285
6 6 6 6 6 6 6 4 4 6
23 2929 2929 3057 3057 3170 3170 3285 3285 3400 3400
6 6 6 6 4 4 6 6 8 8
24 3170 3170 3285 3285 3400 3400 3516 3516 3669 3669
4 4 6 6 8 8 0 0 6 6
25 3285 3285 3400 3400 3516 3516 3669 3669 3788 3788
6 6 8 8 0 0 6 6 8 8
26 3788 3788 3923 4057 4057 4057 4236 4236 4381 4381
8 8 2 6 6 6 8 8 6 6
I TBS N PRB
61 62 63 64 65 66 67 68 69 70
0 1672 1736 1736 1800 1800 1800 1864 1864 1928 1928
1 2216 2280 2280 2344 2344 2408 2472 2472 2536 2536
2 2728 2792 2856 2856 2856 2984 2984 3112 3112 3112
3 3624 3624 3624 3752 3752 3880 3880 4008 4008 4136
4 4392 4392 4584 4584 4584 4776 4776 4968 4968 4968
5 5352 5544 5544 5736 5736 5736 5992 5992 5992 6200
6 6456 6456 6456 6712 6712 6968 6968 6968 7224 7224
7 7480 7480 7736 7736 7992 7992 8248 8248 8504 8504
8 8504 8760 8760 9144 9144 9144 9528 9528 9528 9912
9 9528 9912 9912 1029 1029 1029 1068 1068 1106 1106
6 6 6 0 0 4 4
10 1068 1106 1106 1144 1144 1144 1183 1183 1221 1221
0 4 4 8 8 8 2 2 6 6
11 1221 1257 1257 1296 1296 1353 1353 1353 1411 1411
6 6 6 0 0 6 6 6 2 2
12 1411 1411 1411 1468 1468 1526 1526 1526 1584 1584
2 2 2 8 8 4 4 4 0 0
13 1584 1584 1641 1641 1699 1699 1699 1756 1756 1833
0 0 6 6 2 2 2 8 8 6
14 1756 1756 1833 1833 1833 1908 1908 1984 1984 1984
8 8 6 6 6 0 0 8 8 8
15 1833 1908 1908 1984 1984 2061 2061 2061 2138 2138
6 0 0 8 8 6 6 6 4 4
16 1984 1984 2061 2061 2138 2138 2215 2215 2215 2292
8 8 6 6 4 4 2 2 2 0
17 2215 2215 2292 2292 2368 2368 2449 2449 2449 2545
2 2 0 0 8 8 6 6 6 6
18 2449 2449 2449 2545 2545 2641 2641 2737 2737 2737
6 6 6 6 6 6 6 6 6 6
19 2641 2641 2737 2737 2833 2833 2929 2929 2929 3057
6 6 6 6 6 6 6 6 6 6
20 2833 2929 2929 2929 3057 3057 3170 3170 3170 3285
6 6 6 6 6 6 4 4 4 6
21 3057 3170 3170 3170 3285 3285 3400 3400 3516 3516
6 4 4 4 6 6 8 8 0 0
22 3285 3400 3400 3400 3516 3516 3669 3669 3669 3788
6 8 8 8 0 0 6 6 6 8
23 3516 3516 3669 3669 3788 3788 3788 3923 3923 4057
0 0 6 6 8 8 8 2 2 6
24 3669 3788 3788 3923 3923 4057 4057 4236 4236 4236
6 8 8 2 2 6 6 8 8 8
Page 463/472
25 3923 3923 4057 4057 4057 4236 4236 4381 4381 4381
2 2 6 6 6 8 8 6 6 6
26 4535 4535 4688 4688 4893 4893 4893 5102 5102 5275
2 2 8 8 6 6 6 4 4 2
I TBS N PRB
71 72 73 74 75 76 77 78 79 80
0 1992 1992 2024 2088 2088 2088 2152 2152 2216 2216
1 2600 2600 2664 2728 2728 2792 2792 2856 2856 2856
2 3240 3240 3240 3368 3368 3368 3496 3496 3496 3624
3 4136 4264 4264 4392 4392 4392 4584 4584 4584 4776
4 5160 5160 5160 5352 5352 5544 5544 5544 5736 5736
5 6200 6200 6456 6456 6712 6712 6712 6968 6968 6968
6 7480 7480 7736 7736 7736 7992 7992 8248 8248 8248
7 8760 8760 8760 9144 9144 9144 9528 9528 9528 9912
8 9912 9912 1029 1029 1068 1068 1068 1106 1106 1106
6 6 0 0 0 4 4 4
9 1106 1144 1144 1183 1183 1183 1221 1221 1257 1257
4 8 8 2 2 2 6 6 6 6
10 1257 1257 1296 1296 1296 1353 1353 1353 1411 1411
6 6 0 0 0 6 6 6 2 2
11 1411 1468 1468 1468 1526 1526 1584 1584 1584 1641
2 8 8 8 4 4 0 0 0 6
12 1641 1641 1641 1699 1699 1756 1756 1756 1833 1833
6 6 6 2 2 8 8 8 6 6
13 1833 1833 1908 1908 1908 1984 1984 1984 2061 2061
6 6 0 0 0 8 8 8 6 6
14 2061 2061 2061 2138 2138 2215 2215 2215 2292 2292
6 6 6 4 4 2 2 2 0 0
15 2215 2215 2215 2292 2292 2368 2368 2368 2449 2449
2 2 2 0 0 8 8 8 6 6
16 2292 2368 2368 2449 2449 2449 2545 2545 2545 2641
0 8 8 6 6 6 6 6 6 6
17 2545 2641 2641 2641 2737 2737 2737 2833 2833 2929
6 6 6 6 6 6 6 6 6 6
18 2833 2833 2929 2929 2929 3057 3057 3057 3170 3170
6 6 6 6 6 6 6 6 4 4
19 3057 3057 3170 3170 3285 3285 3285 3400 3400 3400
6 6 4 4 6 6 6 8 8 8
20 3285 3400 3400 3400 3516 3516 3516 3669 3669 3669
6 8 8 8 0 0 0 6 6 6
21 3516 3669 3669 3669 3788 3788 3923 3923 3923 4057
0 6 6 6 8 8 2 2 2 6
22 3788 3923 3923 4057 4057 4057 4236 4236 4236 4381
8 2 2 6 6 6 8 8 8 6
23 4057 4057 4236 4236 4381 4381 4381 4535 4535 4535
6 6 8 8 6 6 6 2 2 2
24 4381 4381 4535 4535 4535 4688 4688 4688 4893 4893
6 6 2 2 2 8 8 8 6 6
25 4535 4535 4688 4688 4688 4893 4893 4893 5102 5102
2 2 8 8 8 6 6 6 4 4
26 5275 5275 5505 5505 5505 5505 5733 5733 5733 5925
2 2 6 6 6 6 6 6 6 6
I TBS N PRB
81 82 83 84 85 86 87 88 89 90
0 2280 2280 2280 2344 2344 2408 2408 2472 2472 2536
1 2984 2984 2984 3112 3112 3112 3240 3240 3240 3240
Page 464/472
2 3624 3624 3752 3752 3880 3880 3880 4008 4008 4008
3 4776 4776 4776 4968 4968 4968 5160 5160 5160 5352
4 5736 5992 5992 5992 5992 6200 6200 6200 6456 6456
5 7224 7224 7224 7480 7480 7480 7736 7736 7736 7992
6 8504 8504 8760 8760 8760 9144 9144 9144 9144 9528
7 9912 9912 1029 1029 1029 1068 1068 1068 1106 1106
6 6 6 0 0 0 4 4
8 1144 1144 1144 1183 1183 1221 1221 1221 1257 1257
8 8 8 2 2 6 6 6 6 6
9 1296 1296 1296 1353 1353 1353 1353 1411 1411 1411
0 0 0 6 6 6 6 2 2 2
10 1411 1468 1468 1468 1468 1526 1526 1526 1584 1584
2 8 8 8 8 4 4 4 0 0
11 1641 1641 1699 1699 1699 1756 1756 1756 1833 1833
6 6 2 2 2 8 8 8 6 6
12 1833 1908 1908 1908 1908 1984 1984 1984 2061 2061
6 0 0 0 0 8 8 8 6 6
13 2061 2138 2138 2138 2215 2215 2215 2292 2292 2292
6 4 4 4 2 2 2 0 0 0
14 2292 2368 2368 2449 2449 2449 2545 2545 2545 2545
0 8 8 6 6 6 6 6 6 6
15 2449 2545 2545 2545 2641 2641 2641 2737 2737 2737
6 6 6 6 6 6 6 6 6 6
16 2641 2641 2737 2737 2737 2833 2833 2833 2929 2929
6 6 6 6 6 6 6 6 6 6
17 2929 2929 3057 3057 3057 3057 3170 3170 3170 3285
6 6 6 6 6 6 4 4 4 6
18 3170 3285 3285 3285 3400 3400 3400 3516 3516 3516
4 6 6 6 8 8 8 0 0 0
19 3516 3516 3516 3669 3669 3669 3788 3788 3788 3923
0 0 0 6 6 6 8 8 8 2
20 3788 3788 3923 3923 3923 4057 4057 4057 4236 4236
8 8 2 2 2 6 6 6 8 8
21 4057 4057 4236 4236 4236 4381 4381 4381 4535 4535
6 6 8 8 8 6 6 6 2 2
22 4381 4381 4535 4535 4535 4688 4688 4688 4893 4893
6 6 2 2 2 8 8 8 6 6
23 4688 4688 4688 4893 4893 4893 5102 5102 5102 5102
8 8 8 6 6 6 4 4 4 4
24 4893 5102 5102 5102 5275 5275 5275 5275 5505 5505
6 4 4 4 2 2 2 2 6 6
25 5102 5275 5275 5275 5505 5505 5505 5505 5733 5733
4 2 2 2 6 6 6 6 6 6
26 5925 5925 6166 6166 6166 6377 6377 6377 6659 6659
6 6 4 4 4 6 6 6 2 2
I TBS N PRB
91 92 93 94 95 96 97 98 99 100
0 2536 2536 2600 2600 2664 2664 2728 2728 2728 2792
1 3368 3368 3368 3496 3496 3496 3496 3624 3624 3624
2 4136 4136 4136 4264 4264 4264 4392 4392 4392 4584
3 5352 5352 5352 5544 5544 5544 5736 5736 5736 5736
4 6456 6456 6712 6712 6712 6968 6968 6968 6968 7224
5 7992 7992 8248 8248 8248 8504 8504 8760 8760 8760
6 9528 9528 9528 9912 9912 9912 1029 1029 1029 1029
6 6 6 6
7 1106 1144 1144 1144 1144 1183 1183 1183 1221 1221
4 8 8 8 8 2 2 2 6 6
Page 465/472
8 1257 1296 1296 1296 1353 1353 1353 1353 1411 1411
6 0 0 0 6 6 6 6 2 2
9 1411 1468 1468 1468 1526 1526 1526 1526 1584 1584
2 8 8 8 4 4 4 4 0 0
10 1584 1641 1641 1641 1699 1699 1699 1699 1756 1756
0 6 6 6 2 2 2 2 8 8
11 1833 1833 1908 1908 1908 1908 1984 1984 1984 1984
6 6 0 0 0 0 8 8 8 8
12 2061 2138 2138 2138 2138 2215 2215 2215 2292 2292
6 4 4 4 4 2 2 2 0 0
13 2368 2368 2368 2449 2449 2449 2545 2545 2545 2545
8 8 8 6 6 6 6 6 6 6
14 2641 2641 2641 2737 2737 2737 2833 2833 2833 2833
6 6 6 6 6 6 6 6 6 6
15 2833 2833 2833 2929 2929 2929 2929 3057 3057 3057
6 6 6 6 6 6 6 6 6 6
16 2929 3057 3057 3057 3057 3170 3170 3170 3170 3285
6 6 6 6 6 4 4 4 4 6
17 3285 3285 3400 3400 3400 3516 3516 3516 3516 3669
6 6 8 8 8 0 0 0 0 6
18 3669 3669 3669 3788 3788 3788 3788 3923 3923 3923
6 6 6 8 8 8 8 2 2 2
19 3923 3923 4057 4057 4057 4057 4236 4236 4236 4381
2 2 6 6 6 6 8 8 8 6
20 4236 4236 4381 4381 4381 4535 4535 4535 4688 4688
8 8 6 6 6 2 2 2 8 8
21 4535 4688 4688 4688 4688 4893 4893 4893 4893 5102
2 8 8 8 8 6 6 6 6 4
22 4893 4893 5102 5102 5102 5102 5275 5275 5275 5505
6 6 4 4 4 4 2 2 2 6
23 5275 5275 5275 5505 5505 5505 5505 5733 5733 5733
2 2 2 6 6 6 6 6 6 6
24 5505 5733 5733 5733 5733 5925 5925 5925 6166 6166
6 6 6 6 6 6 6 6 4 4
25 5733 5925 5925 5925 6166 6166 6166 6166 6377 6377
6 6 6 6 4 4 4 4 6 6
26 6659 6880 6880 6880 7111 7111 7111 7371 7371 7537
2 8 8 8 2 2 2 2 2 6
I TBS N PRB
101 102 103 104 105 106 107 108 109 110
0 2792 2856 2856 2856 2984 2984 2984 2984 2984 3112
1 3752 3752 3752 3752 3880 3880 3880 4008 4008 4008
2 4584 4584 4584 4584 4776 4776 4776 4776 4968 4968
3 5992 5992 5992 5992 6200 6200 6200 6200 6456 6456
4 7224 7224 7480 7480 7480 7480 7736 7736 7736 7992
5 8760 9144 9144 9144 9144 9528 9528 9528 9528 9528
6 1068 1068 1068 1068 1106 1106 1106 1144 1144 1144
0 0 0 0 4 4 4 8 8 8
7 1221 1257 1257 1257 1296 1296 1296 1296 1353 1353
6 6 6 6 0 0 0 0 6 6
8 1411 1411 1468 1468 1468 1468 1526 1526 1526 1526
2 2 8 8 8 8 4 4 4 4
9 1584 1641 1641 1641 1641 1699 1699 1699 1699 1756
0 6 6 6 6 2 2 2 2 8
10 1756 1833 1833 1833 1833 1833 1908 1908 1908 1908
8 6 6 6 6 6 0 0 0 0
11 2061 2061 2061 2138 2138 2138 2138 2215 2215 2215
Page 466/472
6 6 6 4 4 4 4 2 2 2
12 2292 2368 2368 2368 2368 2449 2449 2449 2449 2545
0 8 8 8 8 6 6 6 6 6
13 2641 2641 2641 2641 2737 2737 2737 2737 2833 2833
6 6 6 6 6 6 6 6 6 6
14 2929 2929 2929 2929 3057 3057 3057 3057 3170 3170
6 6 6 6 6 6 6 6 4 4
15 3057 3170 3170 3170 3170 3285 3285 3285 3400 3400
6 4 4 4 4 6 6 6 8 8
16 3285 3285 3400 3400 3400 3400 3516 3516 3516 3516
6 6 8 8 8 8 0 0 0 0
17 3669 3669 3669 3788 3788 3788 3923 3923 3923 3923
6 6 6 8 8 8 2 2 2 2
18 4057 4057 4057 4057 4236 4236 4236 4236 4381 4381
6 6 6 6 8 8 8 8 6 6
19 4381 4381 4381 4535 4535 4535 4688 4688 4688 4688
6 6 6 2 2 2 8 8 8 8
20 4688 4688 4893 4893 4893 4893 4893 5102 5102 5102
8 8 6 6 6 6 6 4 4 4
21 5102 5102 5102 5275 5275 5275 5275 5505 5505 5505
4 4 4 2 2 2 2 6 6 6
22 5505 5505 5505 5733 5733 5733 5733 5925 5925 5925
6 6 6 6 6 6 6 6 6 6
23 5733 5925 5925 5925 5925 6166 6166 6166 6166 6377
6 6 6 6 6 4 4 4 4 6
24 6166 6166 6377 6377 6377 6377 6659 6659 6659 6659
4 4 6 6 6 6 2 2 2 2
25 6377 6377 6659 6659 6659 6659 6880 6880 6880 7111
6 6 2 2 2 2 8 8 8 2
26 7537 7537 7537 7537 7537 7537 7537 7537 7537 7537
6 6 6 6 6 6 6 6 6 6
Table 59: 3GPP Transport Block Size table
8 ANNEX: ABBREVIATIONS
ACK Acknowledgement
AM Acknowledged Mode
AMPR Additional Maximum Power Reduction
ANR Automatic Neighbor Relation
ARP Allocation and Retention Priority
AS Access Stratum
BSR Buffer Status Report
BTS Base Transceiver Station
CCCH Common Control Channel
CL-MIMO Closed-Loop MIMO
CP Cyclic Prefix
Page 467/472
CSFB Circuit Switched Fall Back

DL Downlink
DRX Discontinuous Reception
eNB E-UTRAN NodeB
FDS Frequency Diverse Scheduling
FSS Frequency Selective Scheduling
GP Guard Period
GTP GPRS Tunnelling Protocol
HARQ Hybrid ARQ
ICIC Inter Cell Interference Coordination
MBSFN Multimedia Broadcast Multicast Service Single Frequency Network
MCCH Multicast Control Channel
MG Measurement Gap
MGL Measurement Gap Length
MGO Measurement Gap Offset
MGRP Measurement Gap Repetition Period
MU-MIMO Multi-User MIMO
MPE Maximum Priority Envelope
MSI MBMS Scheduling Information
MSP MBMS Scheduling Period
NA Not Applicable
NB Narrow Band
OD Operator Dependent
OL-MIMO Open-Loop MIMO
OTA Over The Air
OTDOA Observed Time Different of Arrival
PCH Paging Channel
Page 468/472

PGW Packet Data Network (PDN) Gateway
PHY Physical layer
PHR Power Headroom Report
PLMN Public Land Mobile Network
PMI Precoding Matrix Indicator
PRACH Physical Random Access Channel
PRS Positioning Reference Signal(s)
SGW Serving Gateway
RAT Radio Access Technology
RAN Radio Access Network
RAN LM RAN License Manager
RBG Resource Block Group
RF Radio Frequency
RI Rank Indicator
RoHC Robust Header Compression
ROCM Reverse Optical Communication Module
SCTP Stream Control Transmission Protocol
SRB Signaling Radio Bearer
SRS Sounding Reference Signal
SU-MIMO Single User MIMO
TB Transport Block
TBS Transport Block Size
UDP User Datagram Protocol
UE User Equipment
UL Uplink
Page 469/472

WB Wide Band
Page 470/472
Page 471/472
VOLUME 5 CALL MANAGEMENT

FDD eNodeB LTE Parameters User Guide 09.05/EN 27-September-2013
Volume 5 : Call Management
CONTENTS
1 INTRODUCTION ............................................................................................................................. 13

1.1 OBJECTIVE .............................................................................................................................. 13
1.2 SCOPE OF THIS VOLUME........................................................................................................ 13
1.3 LIST OF RELATED FEATURES ........................................................................................... 15
2 RELATED DOCUMENTS AND PREREQUISITES ........................................................................ 19

2.1 LPUG VOLUMES ..................................................................................................................... 19
2.2 REFERENCE DOCUMENTS ......................................................................................................... 19
2.3 PREREQUISITE FOR READING THIS VOLUME................................................................. 20
3 OVERVIEW ..................................................................................................................................... 21
4 CELL SETUP .................................................................................................................................. 23

4.1 EUTRAN CELL IDENTIFICATION ............................................................................................... 23
4.1.1 Mobile Country Code and Mobile Network Code Parameters ......................................... 23
BscAccess::plmnMobileCountryCode ................................................ 24
ExternalPlmnIdentity::plmnMobileCountryCode ............................... 24
HrpdNeighboringPerCarrier::plmnMobileCountryCode .................... 24
LteNeighborPlmnIdentity::plmnMobileCountryCode ........................ 24
MbmsBearerService::plmnMobileCountryCode ................................ 24
OneXRttNeighboringPerCarrier::plmnMobileCountryCode .............. 24
PlmnIdentity::plmnMobileCountryCode.............................................. 24
RncAccess::plmnMobileCountryCode ................................................ 24
TaiListNotSupportingImsVoip::plmnMobileCountryCode ................ 24
X2Access::plmnMobileCountryCode .................................................. 24
BscAccess::plmnMobileNetworkCode................................................ 25
ExternalPlmnIdentity::plmnMobileNetworkCode ............................... 25
HrpdNeighboringPerCarrier::plmnMobileNetworkCode ................... 25
LteNeighborPlmnIdentity::plmnMobileNetworkCode ........................ 25
MbmsBearerService::plmnMobileNetworkCode ................................ 25
OneXRttNeighboringPerCarrier::plmnMobileNetworkCode ............. 25
PlmnIdentity::plmnMobileNetworkCode ............................................. 25
RncAccess::plmnMobileNetworkCode ............................................... 25
TaiListNotSupportingImsVoip::plmnMobileNetworkCode ................ 25
X2Access::plmnMobileNetworkCode .................................................. 25
4.1.1.1 Primary Operator PLMN Identification ......................................................................... 26
PlmnIdentity::isPrimary ........................................................................ 27
LteNeighborPlmnIdentity::isPrimary ................................................... 27
4.1.2 EUTRAN Cell Global Identifier: ECGI .............................................................................. 27
Page 1/289
Enb::macroEnbId................................................................................... 28
LteNeighboringCellRelation::macroEnbId .......................................... 28
X2Access::macroEnbId ........................................................................ 28
LteCell::relativeCellIdentity .................................................................. 29
LteNeighboringCellRelation::relativeCellIdentity .............................. 29
4.1.3 Physical Cell Identity: PCI ................................................................................................ 29
LteCell::pci ............................................................................................. 30
LteNeighboringCellRelation::pci ......................................................... 30
4.1.4 Distributed Antenna Systems (DAS) ................................................................................ 30
4.1.5 Automatic Configuration of Physical Cell ID .................................................................... 31
4.1.5.1 Centralized PCI Allocation Algorithm .......................................................................... 33
4.1.5.1.1 PCI Provisioning .................................................................................................... 33
LteCell::lteCellPositionLongitude........................................................ 35
LteCell::lteCellPositionLatitude ........................................................... 35
LteCell::cellRadius ................................................................................ 36
AutomaticPhysicalCellIdentity::pciAllowedList ................................. 40
4.1.5.1.2 PCI Auto-Correction ............................................................................................... 41
4.1.5.1.3 Impact of cabling delay on centralized Automatic PCI allocation .......................... 44
4.1.5.2 Distributed PCI allocation algorithm ............................................................................ 44
4.1.5.2.1 Enabling Distributed PCI ALOCATION For AN ENODEB ..................................... 45
ActivationService::isSonPciAllocationEnabled ................................. 45
4.1.5.2.2 PCI Conflict Correction Maintenance Period .................................................... 46
AutomaticPhysicalCellIdentity::enableMaintenancePeriod .............. 46
AutomaticPhysicalCellIdentity::maintenancePeriodStartTime ........ 46
Enb::timeZoneName.............................................................................. 47
AutomaticPhysicalCellIdentity::enableCollisionMaintenancePeriod
49
4.1.5.2.3 Special Rules for Automatic PCI Allocation and One or Two Cell eNBs ....... 50
4.1.5.3 Support of automatic PCI for up to 6 sectors per site and up to 9 cells per eNB
configuration (feature 115340) .................................................................................... 52
LteCell::cellSiteNumber ........................................................................ 52
ActivationService::isSonPci6Sectors9CellsEnabled......................... 54
LteCell::pciMod3Maintained ................................................................. 54
4.1.5.4 Adaptation of Automatic pci assignment to HetNet with MetroCells ........................... 56
ActivationService::isSonPciInterferenceReductionEnabled ............ 56
AutomaticPhysicalCellIdentity::interferenceMinMeasurements ...... 58
AutomaticPhysicalCellIdentity::interferenceThreshold .................... 58
4.2 EUTRAN SHARING .................................................................................................................. 60
LicensingMngtSystem::maxNbPlmnForMocnLicense ...................... 62

LicensingMngtSystem::maxNbPlmnForGwcnLicense ...................... 64
4.3 COMMON AND SHARED CHANNELS SETUP ................................................................................ 64
4.4 SYSTEM INFORMATION BROADCASTING ........................................................................ 67
4.4.1 INTRODUCTION.............................................................................................................. 67
SysInfoConf::sib2SchedulingClass..................................................... 70
Page 2/289
SysInfoConf::sib12SchedulingClass................................................... 73
SysInfoConf::sibClass1TargetPeriodicity........................................... 74
CellActivationService::isTransmitSib16Enabled ............................... 75
CellActivationService:: isDayLightSavingTimeInSib16Enabled ...... 76
CellActivationService:: isLocalTimeOffsetInSib16Enabled .............. 76
4.4.2 Value Tag Management................................................................................................... 76
4.5 SYSTEM INFORMATION MODIFICATION .......................................................................... 77
LteCell::modificationPeriodCoeff ........................................................ 79

4.6 SYSTEM INFORMATION IMPACTING UE CONNECTIVITY, IDLE MODE CELL RESELECTION AND
INTER-RAT MOBILITY ........................................................................................................................ 80
4.7 COMMERCIAL MOBILE ALERT SYSTEM ...................................................................................... 81
4.7.1 CMAS Parameters ........................................................................................................... 83
ActivationService::isCmasEnabled ..................................................... 84
LteCell::emergencyAreaIdList ............................................................. 84
4.8 CELL RESET AND LOCK/UNLOCK .............................................................................................. 85
4.9 FAILURE CASES ....................................................................................................................... 85
4.9.1 Cell Setup Failure ............................................................................................................ 85
4.9.2 Modem failure .................................................................................................................. 85
4.9.3 CELL Recovery DUE TO LOSS OF S1 SERVICES ........................................................ 86
Enb::cellBarringHysteresisTimer ........................................................ 86
ActivationService::isTurningRadioOffOnS1FailureEnabled ............. 87
Enb::radioOffHysteresisTimer ............................................................. 87
4.9.3.1 Cell Shrink for S1 Links Outage .................................................................................. 88
DynamicCoverageMgmt::cellShrinkForS1LinksOutage.................... 89
4.10 INTERACTIONS WITH OTHER FEATURES ..................................................................................... 91
4.11 OBJECT STATE MANAGEMENT .................................................................................................. 92
5 S1 MANAGEMENT ......................................................................................................................... 94
Enb::eNBname ....................................................................................... 94

5.1 S1 FLEX CAPABILITY ................................................................................................................ 95
MmeAccess::plmnId.............................................................................. 96
5.2 S1-SETUP ............................................................................................................................... 96
Enb::s1APProcedureDefenseTimer..................................................... 97
Page 3/289
5.3 MME CONFIGURATION UPDATE ....................................................................................... 98

5.4 MME SELECTION ..................................................................................................................... 99
5.5 INTERACTIONS WITH OTHER FEATURES ................................................................................... 101
5.6 OBJECT STATE MANAGEMENT ................................................................................................ 101
6 X2 MANAGEMENT ....................................................................................................................... 103

6.1 FAILURE CASES ..................................................................................................................... 106
6.1.1 X2 Setup Failure ............................................................................................................ 106
X2Access::noX2 .................................................................................. 106
Enb::x2APProcedureDefenseTimer................................................... 107
OverloadControl:: ovLevelForX2SetupReqAction ........................... 107
6.1.2 X2 Link Failure ............................................................................................................... 107
6.2 MULTIPLE X2 LINKS ............................................................................................................... 108
LteNeighboringCellRelation::x2AccessId ......................................... 108

6.3 INTERACTIONS WITH OTHER FEATURES ................................................................................... 108
6.4 X2 LOCK/UNLOCK .................................................................................................................. 109
6.4.1 Behaviour when locking an X2 link ................................................................................ 109
6.4.2 Behaviour when unlocking an X2 link ............................................................................ 109
6.5 X2 BLACK-LISTING ................................................................................................................. 109
6.6 X2 WHITE-LISTING ................................................................................................................. 110
6.7 X2 ONLINE CREATION ............................................................................................................. 110
6.8 X2 ONLINE DELETION ............................................................................................................. 110
6.9 OBJECT STATE MANAGEMENT ................................................................................................ 111
6.10 ENB CONFIGURATION UPDATE ...................................................................................... 111
OverloadControl::ovLevelForX2ENBConfUpdAction ...................... 113

6.11 X2 RESOURCE STATUS REPORTING ....................................................................................... 113
Enb::x2ResourceReportPeriodicity ................................................... 115

RadioCacCell::cellCapacityClass ...................................................... 115
OverloadControl::ovLevelForCellLoadReportAction ...................... 116
Enb::x2ResourceStatusMaxOverload ............................................... 117
7 CALL HANDLING ......................................................................................................................... 118

7.1 DESCRIPTION OF THE IDLE MODE ................................................................................... 118
7.2 PLMN SELECTION & INTER TRACKING AREA MOBILITY .............................................. 121
7.2.1 PLMN SELECTION: ....................................................................................................... 121
7.2.2 CELL RESERVATIONS AND ACCESS RESTRICTIONS ............................................ 122
LteCell::cellBarred............................................................................... 123
CellReservation::cellReservedForOperatorUse ............................... 124
CellReservation::plmnId ..................................................................... 125
CellSelectionReselectionConf::intraFrequencyReselection........... 125
7.2.3 NEIGHBORING CELL ANTENNA INFORMATION ....................................................... 126
LteCell::presenceAntennaPort1......................................................... 126
7.3 PAGING ................................................................................................................................. 127
Page 4/289
7.3.1 Paging channels ............................................................................................................ 127

7.3.2 Paging occasion ............................................................................................................. 127
Enb::defaultPagingCycle .................................................................... 131
LteCell::nB ........................................................................................... 132
7.3.3 PAGING PROCEDURE ................................................................................................. 132
OverloadControl::s1PagingIgnoreRateMinor ................................... 133
OverloadControl::s1PagingIgnoreRateMajor ................................... 133
OverloadControl::s1PagingPriorityIndicationHandling .................. 134
7.4 UE CALL STATES AND STATE TRANSITIONS ............................................................................. 135
7.4.1 UE STATE TRANSITIONS ............................................................................................ 135
ActivationService:: isOOTManagementEnabled .............................. 139
TrafficRadioBearerConf:: isOOTAllowed .......................................... 140
Enb:: isRedirectionForOotEnabled ................................................... 140
CellRachConf:: pdcchOrderTransMax .............................................. 141
Enb:: rrcRlsTimerForOOTUser .......................................................... 141
PerformanceManagement:: oOTManagementReported .................. 142
7.4.2 CONNECTED MODE & End OF CONNECTED MODE ................................................ 142
UeTimers::t310..................................................................................... 142
UeTimers::n310.................................................................................... 142
UeTimers::n311.................................................................................... 143
7.5 CALL HANDLING PROCEDURES ................................................................................................ 143
7.5.1 RRC connection management ....................................................................................... 144
7.5.1.1 RANDOM ACCESS PROCEDURE ........................................................................... 144
7.5.1.2 RRC CONNECTION ESTABLISHEMENT ................................................................ 146
7.5.1.2.1 RRC CONNECTION INITIATION checks ............................................................ 148
AccessBarring::accessBarringStatus ............................................... 154
AccessBarring::accessBarringForEmergencyCalls ........................ 154
AccessBarringForOriginatingCalls::accessBarringTime................ 155
AccessBarringForOriginatingCalls::accessProbabilityFactor ....... 155
AccessBarringForOriginatingCalls::accessClass11Barring .......... 156
AccessBarringForSignaling::accessBarringTime ........................... 158
AccessBarringForSignaling::accessProbabilityFactor ................... 159
AccessBarringForSignaling::accessClass11Barring ...................... 159
7.5.1.2.2 Access Barring for Multimedia Voice and Video Calls .................................. 161
SsacBarringForVoiceMMTEL::accessBarringTime ......................... 162
SsacBarringForVoiceMMTEL::accessProbabilityFactor ................. 163
Page 5/289
SsacBarringForVoiceMMTEL::accessClass11Barring .................... 163

SsacBarringForVideoMMTEL::accessBarringTime ......................... 166
SsacBarringForVideoMMTEL::accessProbabilityFactor................. 166
SsacBarringForVideoMMTEL::accessClass11Barring .................... 167
OverloadControl::accessClassBarringDefense ............................... 169
7.5.1.2.3 Access Barring for Circuit Switched Fallback Calls ...................................... 169
AccessBarring::accessBarringCsfbStatus ....................................... 170
AccessBarringForCsfb::accessBarringTime ................................... 170
AccessBarringForCsfb::accessProbabilityFactor ........................... 171
AccessBarringForCsfb::accessClass11Barring .............................. 171
7.5.1.3 RRC CONNECTION ESTABLISHMENT Failures..................................................... 173
7.5.1.3.1 ENB failure to setup the RRC Connection ........................................................... 173
UeTimers::t302..................................................................................... 174
UeTimers::t300..................................................................................... 175
OverloadControl::rrcCnxReqRejectRateMinor ................................. 176
OverloadControl::rrcCnxReqRejectRateMajor ................................. 176
OverloadControl::rrcCnxReqWaitTimeMinor ................................... 177
OverloadControl::rrcCnxReqWaitTimeMajor ................................... 177
UeTimers::extendedWaitTimeDueToENB ......................................... 178
OverloadControl::ecHighPriorityCallsFilteringCriticalOverload .... 179
OverloadControl::mtAccessRrcCnxReqFilteredInOverload ........... 179
UeTimers::tOverload ........................................................................... 180
UeTimers::extendedWaitTimeDueToMME ........................................ 181
ActivationService::overloadCallRejectNotAllowed ......................... 182
7.5.1.3.2 UE failure to setup the RRC Connection (internal guard timer expiration) .......... 182
Enb::rrcProcedureDefenseTimer ....................................................... 183
Enb::rrcConnSetupCompleteTimer ................................................... 184
Enb::ueContextMaxLifeTime .............................................................. 184
7.5.1.4 RRC CONNECTION RE-ESTABLISHMENT ............................................................ 186
UeTimers::t301..................................................................................... 187
Page 6/289
UeTimers::t311..................................................................................... 187
OverloadControl::rrcCnxReestabRejectRateMinor ......................... 188
OverloadControl::rrcCnxReestabRejectRateMajor .......................... 188
7.5.2 Signalling Connection Management .............................................................................. 188
7.5.2.1 DEDICATED S1 ESTABLISHMENT CONTROL PROCEDURE .............................. 188
Enb::s1APinitUeMsgTimer ................................................................. 190
7.5.3 Context Management..................................................................................................... 190
7.5.3.1 INITIAL CONTEXT SETUP ....................................................................................... 190
TrafficBasedReleaseConf::rrcOnlyCnxLifeTime .............................. 194
7.5.3.2 UE CONTEXT RELEASE .......................................................................................... 194
7.5.3.2.1 UE CONTEXT RELEASE MME TRIGGERED .................................................... 194
7.5.3.2.2 UE CONTEXT RELEASE eNB TRIGGERED ..................................................... 196
7.5.3.2.3 UE CONTEXT RELEASE ENB TRIGGERED Failure cases .............................. 197
7.5.4 Bearer Management ...................................................................................................... 198
OverloadControl::s1RabSetupReqRejectRateMinor ....................... 198
OverloadControl::s1RabSetupReqRejectRateMajor........................ 198
7.5.4.1 DEFAULT E-RAB ESTABLISHMENT ....................................................................... 198
7.5.4.1.1 Mobile Originated default E-RAB establishment HIGH LEVEL PROCEDURE ... 198
7.5.4.1.2 Mobile Terminated default E-RAB establishment HIGH LEVEL PROCEDURE . 201
7.5.4.2 DEDICATED E-RAB ESTABLISHMENT ................................................................... 202
7.5.4.2.1 Dedicated E-RAB establishment HIGH LEVEL PROCEDURE ........................... 202
7.5.4.2.2 Dedicated E-RAB SETUP CONTROL PROCEDURE ......................................... 203
7.5.4.3 E-RAB RELEASE MME TRIGGERED ...................................................................... 207
7.5.4.3.1 E-RAB release MME triggered HIGH LEVEL PROCEDURE .............................. 207
7.5.4.3.2 E-RAB release MME triggered CONTROL PROCEDURE.................................. 208
7.5.4.4 E-RAB Modify MME TRIGGERED ............................................................................ 209
ActivationService::isQciArpOnLineModificationEnabled ............... 210
OverloadControl::s1RabModifyReqRejectRateMinor ...................... 211
OverloadControl::s1RabModifyReqRejectRateMajor ...................... 211
7.5.4.4.1 E-RAB Modify EPC triggered HIGH LEVEL PROCEDURE ................................ 211
7.5.4.4.2 E-RAB Modify MME triggered CONTROL PROCEDURE (EXCEPT for QCI
Modification) 212
7.5.4.4.3 E-RAB Modify MME triggered CONTROL PROCEDURE for QCI Modification .. 214
7.5.5 NAS transport................................................................................................................. 216
7.5.5.1 CONNECTION ESTABLISHMENT FOR NAS SIGNALLING TRANSFER High level
procedure................................................................................................................... 216
7.5.5.2 NAS SIGNALLING TRANSFER CONTROL PROCEDURE ..................................... 217
7.5.5.3 NAS In-Sequence Delivery ........................................................................................ 219
Enb::dlNasDeliveryWaitTimeNoDRX ................................................. 219
7.5.6 Resource Management.................................................................................................. 219
7.5.6.1 E-RAB MATCHING OVERVIEW ............................................................................... 219
7.5.6.1.1 E-RAB LEVEL QoS PARAMETERS.................................................................... 222
7.5.6.1.2 SIGNALLING RADIO BEARER ........................................................................... 225
7.5.6.1.3 L1/L2 CONFIGURATIONS BASED ON Configuration PARAMETERS .............. 225
7.5.6.1.4 SECURITY MANAGEMENT ................................................................................ 226
7.5.6.2 TRAFFIC MONITORING ........................................................................................... 226
Page 7/289
ActivationService::isTrafficBasedContextReleaseAllowed ............ 227

TrafficBasedReleaseConf::timeToTrigger ........................................ 227
TrafficBasedReleaseConf::timeToTriggerSRB2 .............................. 228
Enb:: changeCauseInUeCtxRlsReqRetry.......................................... 229
7.5.7 Carrier Aggregation Configuration and Activation ......................................................... 231
7.5.7.1 CA-DL configuration at call establishment ................................................................ 231
7.5.7.2 CA eligibility ............................................................................................................... 233
CarrierAggregationSecondaryConf::secondaryCellId .................... 233
7.5.7.3 UL radio quality criterion ............................................................................................ 233
7.5.7.4 Carrier aggregation activation ................................................................................... 234
DownlinkCAConf::caMaximumActivationAttempts ......................... 234
DownlinkCAConf::caOneShotACQIRequestAttemptsUponCAConfig
uration .................................................................................................. 235
DownlinkCAConf::caOneShotACQIRequestPeriodUponCAConfigura
tion ........................................................................................................ 235
7.5.7.5 Carrier aggregation Deconfiguration ......................................................................... 235
7.6 CELL OUTAGE DETECTION ..................................................................................................... 236
LteCell::sleepingCellInactivityTimer ................................................. 237

ActivationService::isSystemIntegrityMonitorEnabled .................... 239
SystemIntegrityMonitor::simTxPowerDegradedTimer .................... 239
8 DYNAMIC COVERAGE MANAGEMENT WITH CELL SHRINK ................................................. 240

8.1 CELL SHRINK FOR OAM BARRING .......................................................................................... 241
DynamicCoverageMgmt::cellShrinkForOamBarring ....................... 241

DynamicCoverageMgmt::cellShrinkForCallsDraining..................... 243
9 ENHANCED MULTIMEDIA BROADCAST MULTICAST SERVICE (EMBMS) .......................... 244

9.1 MULTIMEDIA BROADCAST SINGLE FREQUENCY NETWORK ....................................................... 245
9.2 EMBMS CHANNELS ............................................................................................................... 247
9.3 ALU INITIAL IMPLEMENTATION OF EMBMS ............................................................................. 247

9.3.1 Characteristics of the Current Implementation .............................................................. 249
9.4 EMBMS DATA MODEL AND PARAMETERS ............................................................................... 250
9.4.1 Activating the eMBMS Feature ...................................................................................... 252

ActivationService::isMbmsBroadcastModeAllowed ....................... 253
ActivationService::isMceDistributedModeEnabled ......................... 253
Mbms::isMbmsTrafficAllowed ........................................................... 254
9.4.2 Configuration of eMBMS at the eNB .............................................................................. 254
9.4.2.1 General Parameters for the Multimedia Broadcast Single Frequency Network
(MBSFN) .................................................................................................................... 254
LteCell::isMBMSBearerServiceCountingAllowed ............................ 255
9.4.2.2 MCE and Parameters ................................................................................................ 255
Mce::uniqueName................................................................................ 257
Mce::mceName .................................................................................... 257
Mce::mceId ........................................................................................... 258
Mce::latencySessionStart ................................................................... 258
Page 8/289
Mce::latencySessionStop ................................................................... 259

Mce::mcchModificationPeriod ........................................................... 259
Mce::mceActionOverloadControl ...................................................... 260
Mce::provisioningSynchronization ................................................... 260
MceMbsfnSynchroArea::hetNetMacroBlankingPatternDL.............. 261
MceMbsfnSynchroArea::mbsfnAreaPooledRfList ........................... 263
MceMbsfnSynchroArea::mbsfnAreaPooledSfList ........................... 264
MceMbsfnSynchroArea::mbsfnAreaSynchroPatternRfList ............ 265
MceMbsfnSynchroArea::mbsfnAreaSynchroPatternSfList ............ 266
MceMbsfnSynchroArea::mbsfnSynchroAreaId ............................... 267
MceMbsfnSynchroArea::mbsfnSynchroAreaName ......................... 267
MceMbsfnSynchroArea::spsFavor .................................................... 268
MceMbsfnArea::mbmsServiceAreaIdList ......................................... 269
MceMbsfnArea::mbsfnAreaId ............................................................ 269
MceMbsfnArea::mbsfnAreaName ...................................................... 269
MceMbsfnArea::mbsfnAreaPartitionRfList ....................................... 270
MceMbsfnArea::mbsfnAreaPartitionSfList ....................................... 270
MceMbsfnArea::sib13NonMBSFNregionLength .............................. 273
MceMbsfnArea::sib13SignalingMCS ................................................. 273
MceMbsfnArea::useOfPooledSf......................................................... 274
MbsfnPositioningReferenceSignal::prsConfigurationIndex ........... 274
MbsfnPositioningReferenceSignal::prsNumSubframes ................. 275
9.4.2.3 MCE resources allocator ........................................................................................... 275
MceSupportedQci::packetErrorLossRate ......................................... 277
MceMbsfnSynchroArea::dlBandwidth .............................................. 277
MceMbsfnArea::dlSinr ........................................................................ 277
MceSupportedQci::supportedQci ...................................................... 278
MceSupportedQci::mchSchedulingPeriod ....................................... 278
MceMbsfnArea::mcchRepetitionPeriod ............................................ 279
MceMbsfnArea::minMchSchedulingPeriod ...................................... 279
MceMbsfnArea:: mceQosToMcsProfileId ......................................... 281
MceQosToMcsProfile::mceQoSToMcsProfilName .......................... 281
MceQosToMcsProfile::mcsTransitionTableBler1 ............................ 281
MceQosToMcsProfile::mcsTransitionTableBler10 .......................... 282
MceQosToMcsProfile::mcsTransitionTableBler5 ............................ 282
9.4.2.4 Intra-freq and inter-freq mobility ................................................................................ 282
ActivationService::isMbsfnInformationOverX2Enabled.................. 283
ActivationService:: isMeasSubframePatternNeighInterFreqEnabled
283
10 ANNEX .......................................................................................................................................... 284

10.1 ABBREVIATIONS ............................................................................................................... 284
Page 9/289
TABLES
Table 1 : Paths for Objects with plmnMobileCountryCode and plmnMobileNetworkCode Parameters 24
Table 2 : Classes and Feature Numbers for plmnMobileCountryCode and plmnMobileNetworkCode
Parameters ..................................................................................................................................... 26
Table 3 : Enumerated Values for Parameter timeZone ......................................................................... 48
Table 4 : Example PCI Allowed Lists..................................................................................................... 51
Table 5 : L115966 Feature Interaction & Dependencies ....................................................................... 59
Table 6 : LteCell MO State attributes .................................................................................................... 67
Table 7 : System Information Block Sizes (in bits) ................................................................................ 69
Table 8 : LteCell State Management ..................................................................................................... 92
Table 9 MmeAccess State Management ........................................................................................... 101
Table 10 : i_s vs Ns ............................................................................................................................. 130
Table 11 : UE Timer Stop and Start Summary .................................................................................... 185
Table 12 : Bearer Management ........................................................................................................... 221
Table 13 : E-RAB LEVEL QoS PARAMETERS and LABEL ............................................................... 224
Table 14 : Signalling Radio Bearer Mapping ....................................................................................... 225
Table 15 : eMBMS Objects and Parameters ....................................................................................... 252
Page 10/289
FIGURES
Figure 1: CallP overview ........................................................................................................................ 21
Figure 2: Distributed Antennas System Coverage Example, e.g. 4 coverage areas ............................ 31
Figure 3 : Example of PCI collision........................................................................................................ 32
Figure 4 : Example of PCI confusion ..................................................................................................... 33
Figure 5 : PCI allocation algorithm principle .......................................................................................... 34
Figure 6 : Centralized Algorithm for PCI provisioning ........................................................................... 41
Figure 7 : Centralized Algorithm for PCI auto-correction....................................................................... 43
Figure 8 : GWCN Architecture ............................................................................................................... 63
Figure 9 : Downlink transport channel mapping .................................................................................... 65
Figure 10 : Uplink transport channel mapping ....................................................................................... 65
Figure 11 : Downlink logical channel mapping ...................................................................................... 66
Figure 12 : Uplink logical channel mapping ........................................................................................... 66
Figure 13 : Channels used for System Information ............................................................................... 67
Figure 14 : Master Information Block periodicity ................................................................................... 69
Figure 15 : CNP when there is a full paging cycle before the end of Modification Period (N). ............. 78
Figure 16 : CNP when there is not a full paging cycle before the end of Modification Period (N). ....... 78
Figure 17: Change of system Information ............................................................................................. 79
Figure 18 : Warning System Architecture for CMAS (LTE View) .......................................................... 81
Figure 19 : LteCell State Diagram ......................................................................................................... 93
Figure 20 : S1 Setup Success ............................................................................................................... 96
Figure 21 : MME Configuration Update Success .................................................................................. 98
Figure 22 : MMEAccess State Diagram .............................................................................................. 102
Figure 23 : X2 Setup Success ............................................................................................................. 104
Figure 24 : X2Access State Diagram .................................................................................................. 111
Figure 25 : X2 ENB Configuration Success ........................................................................................ 112
Figure 26 : X2 Resource Status Reporting Message Flow................................................................. 114
Figure 27 : Overall Idle Mode process................................................................................................. 118
Figure 28 : State transitions and pprocedures in idle mode ................................................................ 120
Figure 29 : Relationship of AccessBarring and Cell Reservation Objects .......................................... 126
Figure 30: Channels for Paging ........................................................................................................... 127
Figure 31: Frome IMSI to a paging occasion ...................................................................................... 129
Figure 32 : Paging Messages .............................................................................................................. 133
Figure 33 : UE State Transitions ......................................................................................................... 136
Figure 34 : UE State transition in the RRC Connected mode ............................................................. 139
Figure 35 : UE Call Processing Functions ........................................................................................... 143
Figure 36 : Mobile Terminated VoIP Establishment ............................................................................ 144
Figure 37 : Channels for initial random procedure .............................................................................. 145
Figure 38 : Initial random procedure messages .................................................................................. 145
Figure 39 : RRC connection establishment procedure........................................................................ 147
Figure 40 : RRC Connection Initiation for Emergency Calls ............................................................... 149
Figure 41 : RRC Connection Initiation for Originating Calls ................................................................ 150
Figure 42 : RRC Connection Initiation for Signaling Calls ................................................................... 151
Figure 43 : LR13.1 Access Barring Configuration Model .................................................................... 153
Figure 44 : eNB failure to setup the RRC Connection scenario call flow ............................................ 173
Figure 45 : UE failure to setup the RRC Connection scenario call flow .............................................. 183
Figure 46: RRC Connection Re-Establishment call flow ..................................................................... 186
Figure 47 : S1 Estabablishment Controle procedure scenario call flow .............................................. 189
Figure 48 : Initial Context Setup scenario call flow.............................................................................. 191
Figure 49 : UE Context Release MME triggered scenario call flow .................................................... 195
Figure 50 : UE Context Release eNB triggered scenario call flow ...................................................... 196
Figure 51: “Attach” scenario call flow in the case default E-RAB establishment................................. 200
Figure 52: “Service request” scenario call flow in the case default E-RAB establishment.................. 201
Figure 53: “Mobile Terminated” call flow in the case default E-RAB establishment ........................... 202
Figure 54 : Dedicated E-RAB Establishment scenario call flow .......................................................... 203
Figure 55 : Dedicated E-RAB Control procedure scenario call flow with security (L92638) activated 204
Page 11/289
Figure 56 : E-RAB Release MME Triggered scenario call flow ........................................................... 207
Figure 57 : E-RAB Release MME Triggered Control Procedure scenario call flow ............................ 208
Figure 58 : EPC Triggered ERAB Modification ................................................................................... 212
Figure 59 : MME Triggered ERAB Modification (except QCI modification)......................................... 213
Figure 60: MME Triggered ERAB Modification for QCI Modification .................................................. 215
Figure 61 : “Attach” scenario call flow in the case NAS SIGNALLING TRANSFER ........................... 217
Figure 62 : NAS Signal. Transfer Control procedure scenario call flow .............................................. 218
Figure 63 : Two Unicast EPS bearers (GTP-based S5/S8) ................................................................ 222
Figure 64 : Configuration model for SRB & TRB ................................................................................. 225
Figure 65 : 3GPP R9 eMBMS Reference Architecture ....................................................................... 244
Figure 66 : MBSFN/Service Area Relationships ................................................................................. 246
Figure 67 : ALU eMBMS Architecture ................................................................................................. 248
Figure 68 : MCE resource allocator overview ..................................................................................... 276
Figure 69 : Multiple profiles for MCS management principle............................................................... 280
Page 12/289
1 INTRODUCTION
1.1 OBJECTIVE
The objective of this document is to describe from an engineering point of view the
LTE Call Processing entity.
This includes a system description and covers configuration aspects together with
some engineering recommendations.

and LR13.3 is colored with a gray background as illustrated by this paragraph.
For information concerning parameters for an LTE release earlier than LR13.1, please
refer to the LPUG Edition that supports that release.
individual volume contains a list of features that are described in that volume.
In addition, the listings of new, modified, and deleted parameters, and
parameters that are not described in LPUG have been deleted from the
• A new Volume 2 (Miscellaneous Features and Parameters) has been added.
This volume incorporates some of the material that was previously found in
Volume 1 (Feature Licensing), Volume 7 (Hardware oriented parameters),
and Volume 8.
• Material concerning Location Based Services that was previously included in
Volume 8 has been moved to Volume 5 (Call Management)
Page 13/289

deleted.
If a newer Template delivery becomes available, then the Template is authoritative

as to parameter values
LPUG is written with the assumption that features that are scheduled for the LR13.1
delivery release become available as initially planned.
Note that three types of modem are available in LR13.1: the eCEM, the bCEM, and
the MET3C1 for Metro. Some features are modem-type specific and/or their delivery
date may be modem-type dependent. This is specified in the document whenever
that is necessary.
Support for the Time Division Duplex (TDD) implementation is provided in a separate
document.
Page 14/289

Transport related parameters are described in the Transport Engineering Guide

(TEG). Please refer to that document for information on transport-related parameters.

LA0.x
Feature
Feature Title
Number
L34348 Commercial LTE Introduction – Call Processing, RRM, MM
L75908 Seamless Intra-LTE Mobility
LA1.x
Feature
Feature Title
Number
L76501 3GPP Standard Compliance
L76511 Bearer Management & Applications
L82729 S1 Flex introduction

L82735 HRPD to LTE mobility
LA2.0
Feature
Feature Title
Number
L92638 Ciphering & Integrity Protection For Radio Interface
L97935 Partial Failure Support in E-RAB Setup Procedure
L98840 Up to 4 Simultaneous Data Bearers per User
Page 15/289
L97937 Support of new RRC Reestablishment cases

Dynamic SysInfo Modification under Cell Parameter
L97933 Change
L81873 Automatic Configuration of Physical Cell ID (Trial scope)

Automatic Neighbour Relation Configuration and
L81872 Optimisation
L96760 eNB Configuration Update Enhancements
LA3.0
Feature
Feature Title
Number
L108958 Sys-Info Scheduling Improvements
LTE mobilty enhancements (dormancy timer
L92093
enhancement)
L92483 Up to 8 Concurrent Data Radio Bearers per User
eNB Based PCI Allocation, Conflict Detection and
L108258
Correction
LA4.0
Feature
Feature Title
Number
L103186.1 Cell Outage Detection
eUTRAN Sharing basics: MOCN with shared LTE
L104835
spectrum
L114644.1 EUTRAN Standard Alignment on 3GPP Rel-9
L92127.1 Commercial Mobile Alert System (CMAS) support
L115665.1 MME Overload Indication support
L97084.1 eNB Synchronization support for OTDOA (Trial)
Overload Control Evolutions & QoS Differentiation on
L115241.1
eNB Backplane
LA5.0
Feature Number Feature Title
L115220 eNB US Time Zone Support for PM Files
L115217 eNB Class Parameter Change Improvements
L115223.1/L115223 Inter-freq Load Balancing
eUTRAN Sharing: enhanced MOCN (either shared

L115242/L115242.1
or dedicated spectrum)
GWCN configuration (with shared MME) for eUtran

L115244/L115244.1
Sharing
Page 16/289
Overload Control Evolutions & QoS Differentiation

L115241
on eNB Backplane (bCEM support)
eMBMS trial support (eMBMS services configured
L115527
by OAM command)
LA6.0
Feature Delivery
Feature Title
Number Phase
131966 eNB Time Zone Management for FM Files LA6.0.0
134392 CMAS Evolutions in LTE – Step 1 LA6.0.0
LR13.1
Feature Delivery
Feature Title
Number Phase
L115767 RACH Improvements (Format 3) LR13.1
L115680 eUTRAN Sharing - Multi-carriers support (test only) LR13.1
L115805 Overload Control Phase 3 LR13.1
L115644 Bearer Characteristics Online Modifications LR13.1
163420 OAM Reset Eradication LR13.1
L115225 EUTRAN Standard Alignment LR13.1
LR13.3
Feature Delivery
Feature Title
Number Phase
Adaptation of automatic PCI assignment to HetNet with LR13.3

L115966
Metrocells
L115860 High Priority Access Admission Control LR13.3
167219 eMBMS Commercial (step 2) LR13.3
170745 Neighbor cell classification and mobility counters for HetNet LR13.3
Support of Auto PCI for up to 9 cells per eNB and up to 6 LR13.3

L115340
sectors per site configurations
160847 Commercial CA LR13.3
162309 3 chip metro software platform parity with macro step 1.3 LR13.3
162310 3 chip metro software platform parity with macro step 1.4 LR13.3
Page 17/289

Page 18/289
2 RELATED DOCUMENTS AND

PREREQUISITES
2.1 LPUG VOLUMES

[Vol. 1] Introduction

[Vol. 6] Mobility
For LPUG editions supporting release LA4.0.1 and later releases, the transport
related parameters that were previously described in LPUG Volume 7 have been
moved to the Transport Engineering Guide (TEG) [R15]. Please refer to that
document for information on transport-related parameters.

[R01] 3GPP TS 22.011: “Service accessibility”
[R02] 3GPP TS 23.122: “Non-Access-Stratum (NAS) functions related to Mobile
Station (MS) in idle mode” .(2010-09)
[R03] 3GPP TS 23.401: "GPRS enhancements for E-UTRAN access".
[R04] 3GPP TS 24.301 - Non-Access-Stratum (NAS) protocol for Evolved Packet
System (EPS)
[R05] 3GPP TS 32.422– Trace control and configuration management
Physical channels and modulation".
[R07] 3GPP TS 36.213: “Physical layer procedures”
User Equipment (UE) procedures in idle mode”
[R09] 3GPP TS 36.321: “Medium Access Control (MAC) protocols specification”
UTRAN; Radio Resource Control (RRC)
S1 Application Protocol (S1AP)”.
Page 19/289
[R12] 3GPP TS 36.423– X2 Application Protocol

[R13] LTE Trial Specification Layer 3 – NAS v2.0
[R14] R2-083824 LS Response to LS on synchronization of L1 parameter from
system information
[R16] 3GPP TS 36.300, E-UTRAN Overall Description
http://www.3gpp.org/ftp/Specs/archive/36_series/

Before reading this volume, the reader should read the Introduction (Volume 1).
Volume 1 provides an explanation of the presentation and conventions that are used
throughout the document (i.e., common to all volumes).
Page 20/289
3 OVERVIEW
This volume is dedicated to the description and parameters settings related to LTE
CallP. The Granularity of all CallP parameters is Cell by Cell.
In addition to pure call handling description, additional informations are included
because of their obvious interactions with CallP:
- Cell Setup :
o in charge of Common and shared channels setup:
Physical channels
Transport channels
Control logical channels
o And System Information broadcast over BCCH
- S1 Management (management of S1-AP procedures)
- X2 Management (management of X2-AP Procedures)
- Call Handling / Processing

- Mobility
As shown in Figure 1
eNB eNB MME
Cell Configuration
S1 Configuration
X2 Configuration
Call Handling
Mobility
eNB eNB MME
Figure 1: CallP overview
Page 21/289
Restriction: Mobility
CallP aspects related to Mobility are covered in a dedicated LPUG Volume (Vol. 6)
Page 22/289
4 CELL SETUP
Cell setup consists in common and shared channels setup followed by System
Information broadcast.
The common and shared channels setup is described in section 4.3
The System Information procedure is described in section 4.4

Prior to triggering the cell setup procedure, the eNodeB will have performed the
following steps,
- Hardware discovery,
- Internal MIB generation.
It is therefore ensured that all configuration parameters required to perform cell setup
are available at the time call setup is launched.
4.1 EUTRAN CELL IDENTIFICATION

eUTRAN Cell identity is used by the UE during the idle mode procedure, as well as in
connected mode (see next chapters in this document), and during mobility procedures
(see [Vol. 6]).
Each Cell in eUTRAN will be known through two different identifiers:
- ECGI : E-UTRAN Cell Global Identifier (including Mobile Country Code
(MCC) and Mobile Network Code (MNC) parameters)
- PCI : Physical Cell Identifier
4.1.1 MOBILE COUNTRY CODE AND MOBILE NETWORK

CODE PARAMETERS
The Mobile Country Code (MCC) and the Mobile Network Code (MNC) parameters
are used to specify the country code and network code of several managed objects
within the LTE data model. They are concatenated to form a portion of the ECGI for
identifying a cell. As a result, a general description of these parameters will be
provided in this section, and then referenced in future sections of this Volume and in
Volume 6.
Public Land Mobile Network (PLMN) identity uniquely identifies the network, and is
formed by concatenating two elements plmnMobileCountryCode and
plmnMobileNetworkCode.
Table 1 shows the path for objects which have plmnMobileCountryCode and
plmnMobileNetworkCode parameters.
Page 23/289
Path
<ENBEquipment>-<Enb>-<GeranAccessGroup>-<BscAccess>
<ENBEquipment>-<Enb>-<ExternalPlmnIdentity>
<ENBEquipment>-<Enb>-<LteCell>-<HrpdNeighboring>-<HrpdBandClassConf>-
<HrpdNeighboringPerCarrier>
<ENBEquipment>-<Enb>-<LteCell>-<LteNeighboring>-<LteNeighboringFreqConf>-
<LteNeighboringCellRelation>-<LteNeighborPlmnIdentity>
<ENBEquipment>-<Enb>-<Mbms>-<MbmsBearerService>
<ENBEquipment>-<Enb>-<LteCell>-<OneXRttNeighboring>-<OneXRttBandClassConf>-
<OneXRttNeighboringPerCarrier>
<ENBEquipment>-<Enb>-<PlmnIdentity>
<ENBEquipment>-<Enb>-<UtranAccessGroup>-<RncAccess>
<ENBEquipment>-<Enb>-<TaiListNotSupportingImsVoip>
<ENBEquipment>-<Enb>-<X2AccessGroup>-<X2Access>
Table 1 : Paths for Objects with plmnMobileCountryCode and plmnMobileNetworkCode
Parameters
• plmnMobileCountryCode: Mobile Country Code (MCC) uniquely identifies the

country in which the related object (and its PLMN) is located. The value of the MCC is
the same as the three digit MCC contained in International Mobile Subscriber Identity
(IMSI). The plmnMobileCountryCode parameter is a 3 digit BCD-string (each digit is
coded into 4 bits, which results in a 12 bit string).
The allocation of MCCs is administered by the ITU-T. See TS 23.003.
BscAccess::plmnMobileCountryCode
ExternalPlmnIdentity::plmnMobileCountryCode
HrpdNeighboringPerCarrier::plmnMobileCountryCode
LteNeighborPlmnIdentity::plmnMobileCountryCode
MbmsBearerService::plmnMobileCountryCode
OneXRttNeighboringPerCarrier::plmnMobileCountryCode
PlmnIdentity::plmnMobileCountryCode
RncAccess::plmnMobileCountryCode
TaiListNotSupportingImsVoip::plmnMobileCountryCode
X2Access::plmnMobileCountryCode
Parameter plmnMobileCountryCode
Object See Table 1 for associated objects
Range & Unit BcdString
String Length = 3
Class/Source See Table 2 / customer_init
Value O.D
Feature See Table 2
• plmnMobileNetworkCode : Mobile Network Code (MNC) is a code identifying

the PLMN within a country. The MNC takes the same value as the two or three digit
MNC contained in IMSI, and the plmnMobileNetworkCode parameter is a 2 or 3 digit
BCD-string (each digit is coded into 4 bits, resulting in an 8 or 12 bit string).
Page 24/289
BscAccess::plmnMobileNetworkCode
ExternalPlmnIdentity::plmnMobileNetworkCode
HrpdNeighboringPerCarrier::plmnMobileNetworkCode
LteNeighborPlmnIdentity::plmnMobileNetworkCode
MbmsBearerService::plmnMobileNetworkCode
OneXRttNeighboringPerCarrier::plmnMobileNetworkCode
PlmnIdentity::plmnMobileNetworkCode
RncAccess::plmnMobileNetworkCode
TaiListNotSupportingImsVoip::plmnMobileNetworkCode
X2Access::plmnMobileNetworkCode
Parameter plmnMobileNetworkCode
Object See Table 1 for associated objects
Range & Unit BcdString
String Minimum Length = 2
String Maximum Length = 3
Class/Source See Table 2 / customer_init
Value O.D
Feature See Table 2
For the MbmsBearerService object (see Section 9.), we would normally expect the
MCC and MNC to be the same as one of the MCC and MNC entries of the
PlmnIdentity object instances. However, this is not required, since it is possible for an
operator to broadcast services coming from another PLMN.
In fact those IDs must be consistent with the service description files that the UE
receives from the service provider. A UE will search for a service in a “guide file” (as if
you were looking for some particular broadcast in a TV Guide) and then will search for
the service id in the MBMS control channel that is continuously transmitted over the
air. The PLMN id for the MbmsBearerService object (MCC and MNC) is a part of the
service id transmitted on air, so it has to be the same as the one found in the guide,
and it could be different from what is configured in PlmnIdentity which has another
purpose. However, it is likely that in most cases the operators will use same
MCC/MNC in the 2 objects.
Page 25/289
Feature
Object Class
Number
BscAccess C--New-set-ups L96371
ExternalPlmnIdentity A--full-eNB-reset 159394
HrpdNeighboringPerCarrie C--New-set-ups L104836
LteNeighborPlmnIdentity C--New-set-ups L104835
MbmsBearerService C--New-set-ups L115527
OneXRttNeighboringPerCarrier C--New-set-ups 134791
PlmnIdentity A--full-eNB-reset L104835
RncAccess N.A. L108084

TaiListNotSupportingImsVoip C--New-set-ups L115685
C--Immediate-
X2Access propagation L81872
Table 2 : Classes and Feature Numbers for plmnMobileCountryCode and

plmnMobileNetworkCode Parameters
The combination of both MCC and MNC (the PLMN Identity), uniquely identifies a
network operator, allows communications to be established between terminals
recorded on different mobile networks and/or between land line and mobile terminals.
In the case of roaming the PLMN Identity is mandatory to identify a target network.
As described above, separate PLMN Identification parameters are also used for the
handover relationship declaration. They appear in other objects used for handover
purposes (LteNeighborPlmnIdentity MO, X2Access MO, BscAccess MO,
RncAccess MO) – see Volume 6 [Vol. 6] for additional explanation on the uses of
these. In addition, the TaiListNotSupportingImsVoip MO is used to define PLMNs/
Tracking Areas that do not support VoIP for handover - see [Vol. 6]. The
MbmsBearerService MO is used to define bearers that are associated with the
eMBMS feature (see Section Section 9).
4.1.1.1 PRIMARY OPERATOR PLMN IDENTIFICATION
As discussed in Section 4.2, Feature L104835 allows an eNB to support multiple

PLMNs (combination of MCC and MNC). This is accomplished through the use of
multiple instances of the PlmnIdentity object. Each PlmnIdentity object will have a
distinct plmnMobileCountryCode and plmnMobileNetworkCode parameter. The
instance of the PlmnIdentity object that is associated with the primary operator’s
PLMN will have its associated isPrimary parameter value set to “True”. The other
instance(s) of the PlmnIdentity object will have the isPrimary parameter value set to
“False”.
Similarly, an LteNeighborPlmnIdentity object also has an isPrimary parameter value

to indicate the primary PLMN for an LTE neighbor cell.
Page 26/289
• isPrimary : This parameter allows specification of the matching PLMN as the

primary one for the eNB (the one that is part of eNB Global Identity and Cell Global
Identity) or is just one of the PLMNs broadcast in the cells of the eNB.
PlmnIdentity::isPrimary
Parameter isPrimary
Object ENBEquipment Enb/PlmnIdentity
ntity

True, False
Class/Source A--full-eNB-reset / customer_settable
Value O.D
Feature L104835
LteNeighborPlmnIdentity::isPrimary
Parameter isPrimary
Object ENBEquipment/Enb/LteCell/LteNeighboring/LteNeighboringFreq
Conf/LteNeighboringCellRelation/LteNeighborPlmnIdentity

True, False
Class/Source N.A./ customer_settable
Value O.D or may be set by ANR
Feature L104835
Rule: PlmnIdentity::isPrimary parameter

The PlmnIdentity instance that is associated with the primary PLMN should
have this flag set to 'true'. The value for any other instance(s) should be “false”.
4.1.2 EUTRAN CELL GLOBAL IDENTIFIER: ECGI

The Global Cell Identity (ECGI) is a cell identifier unique in the world. It has a global
scope, and is used for cell identification purposes with MME, with another eNB, etc.
It represents a combination of PLMN identity and E-UTRAN Cell Identifier (ECI):
1) The PLMN identity has been described in Section 4.1.1. The PLMN identity is
transmitted in the downlink in SystemInformationBlockType1. See Section 4.4 and TS
36.331 for additional information.
2) EUTRAN Cell Identifier (ECI) uniquely identifies the cell within the network
Page 27/289
The ECI value is given by the combination of the following attributes: macroEnbId,
relativeCellIdentity
It is the operator’s role (with help from WPS checks) to ensure that the E-UTRAN cell
identifier is unique within the network.
macroEnbId: eNB Identifier (eNB-Id) is used to identify eNBs within a PLMN (TS
36.423 9.2.24 Global eNB ID). This parameter corresponds to the 20 leftmost bits of
E-UTRAN Cell Identifier in TS 36.423 9.2.14.
Note also that each LteNeighboringCellRelation object and the associated
X2Access object also have a macroEnbId and parameter value that is used for
neighbor cell identification.
Enb::macroEnbId
Parameter macroEnbId
0 to 1048575, Step 1
Class/Source A--full-eNB-reset / customer_init
Value O.D. or may be set by ANR function for a Neighbor cell
Feature L81872
LteNeighboringCellRelation::macroEnbId
X2Access::macroEnbId
Parameter macroEnbId
Object ENBEquipment/Enb/ LteCell/ LteNeighboring/
LteNeighboringFreqConf/ LteNeighboringCellRelation
ENBEquipment/Enb/X2Access
0 to 1048575, Step 1
Value O.D. or may be set by ANR function for a Neighbor cell
Feature L81872
• relativeCellIdentity: The relativeCellIdentity parameter, when associated with

the macroEnbId, uniquely identifies a cell within E-UTRAN. This parameter
corresponds to the 8 rightmost bits of E-UTRAN Cell Identifier in TS 36.423
9.2.14 ECGI.
Page 28/289
LteCell::relativeCellIdentity
Parameter relativeCellIdentity
0 to 255, Step 1
Value O.D.
Feature L81872
LteNeighboringCellRelation::relativeCellIdentity
Parameter relativeCellIdentity

0 to 255, Step 1
Value O.D. or may be set by ANR function
Feature L81872
4.1.3 PHYSICAL CELL IDENTITY: PCI

The Physical Cell Identity differs from the Global Cell Identity in that it has a local
scope, and is only used for identification purposes between UE and eNB.
As defined in [R01] “There are 504 unique physical-layer cell identities. The physical
cell identity is used in the generation of the cell-specific reference signal, as well as
the primary and secondary synchronization signals.
Physical cell identity must be unique within a given region, as it is used to identify a
cell in UE – eNB interactions.
A single parameter, pci, is used to define the physical-layer cell identity. It is also used
to identify a neighbor cell, so a pci parameter is associated with both the LteCell and
the LteNeighboringCellRelation objects.
• pci: This parameter provides the physical cell identity as specified by TS 36.211,
Chapter 6.11 Synchronization signals.
Page 29/289
LteCell::pci
Parameter pci
0..503, step 1
Value O.D
Feature
LteNeighboringCellRelation::pci
Parameter pci
0..503, step 1
Value O.D. or may be set by ANR function
Feature
4.1.4 DISTRIBUTED ANTENNA SYSTEMS (DAS)

A Distributed Antenna System is a collection of antenna nodes, each radiating low
power, that are spread over a geographic area. This is done to distribute the coverage
of the cell to a group of smaller coverage areas, with each antenna node covering a
small coverage area (see Figure 2).
Note that an “antenna node” consists of just one antenna or of a set of antennas (for
multiple antenna techniques purposes such as MIMO and TxDiv).
Also note that from a network perspective, the cell is known and identified (by its PCI
and ECGI), meaning that each antenna node broadcasts the same Cell-Specific
Reference Signal, the same Primary and Secondary Synchronization signals and the
same Cell System Information (MIB and SIBs).
The antennas are connected by fiber back to the RF Module.
Page 30/289
CA3 Antenna Node
CA2 Antenna Node CA4 Antenna Node

Coverage
Area 3
CA1 Antenna Node
Coverage Coverage
Area (CA) 2 Area (CA) 4
Cell Coverage
Area (CA) 1
Figure 2: Distributed Antennas System Coverage Example, e.g. 4 coverage areas
Note that DAS Hardware (DAS HW) can also be used as fiber transport instead of a
means to distribute the coverage of the cell to a group of smaller coverage areas.
Such situations occur when there is a need to place the antennas far away from the
RF Module (RFM), in which case DAS hardware can be used to support the fiber
transport.
Note that the MetroCell Outdoor (MCO) cannot be used with a DAS.
In the rest of this document, we will distinguish between the use of DAS HW to
distribute the coverage of the cell to a group of smaller coverage areas and the use of
DAS HW to support fiber transport.
4.1.5 AUTOMATIC CONFIGURATION OF

PHYSICAL CELL ID
In order to minimize the provisioning during the deployment of LTE Networks, 3GPP
has specified algorithms that allow the eUTRAN network to automate the configuration
of some network parameters. These algorithms are part of the Self Optimizing
Network concept (SON) as defined by 3GPP.
One of the parameters that can be automatically configured is the Physical Cell ID
(PCI). With this capability, the eUTRAN system automatically assigns a PCI for each
of its supported cells, ensuring that each ID is unique when compared against itself,
neighbor cells, and neighbors’ neighbor cells.
3GPP (TS 32.500) specifies three solutions for automatic configuration of the
Physical Cell ID:
• Centralized solution: all the mechanism and algorithms are implemented in
OAM system (for instance in SAM/WPS). SAM/WPS is then in charge of the
PCI allocation.
• Distributed solution is implemented within the eNB. The automatic PCI
allocation is managed by the eNB
Page 31/289
• Hybrid solution mixes the centralized solution with the distributed one. Some
of the programs are running within the SAM and other ones within the eNB.
In LA2.0, the Centralized algorithm was implemented for the Automatic configuration
of the PCI (SAM/WPS is in charge for the PCI allocation). In LA3.0, distributed
determination of the PCI was introduced.
This Centralized solution corresponds to the implementation of the OAM feature
83932 and Feature 81873. The Distributed solution is introduced by Feature 108258
(eNB Based PCI Allocation, Conflict Detection and Correction).
The main purpose of this algorithm is to allocate to each individual LTE Cell a
particular PCI while avoiding PCI collision and PCI confusion conditionsand in
respect to the PCI Modulo 3 rule (see details below).
PCI Collision
A PCI collision occurs when in a given location; the signals from two different cells
radiating the same PCI can be received by a UE.
In the worst situation, a UE may be unable to access either of the two cells due to the
interference generated. At best, a UE will be able to access one of the cells but will be
highly interfered.
Another way to describe a PCI collision is to say that two cells that are neighbors
share the same PCI.
Collision Area
Figure 3 : Example of PCI collision
PCI Confusion
PCI confusion appears when a given cell, knowingly or unknowingly, has two
neighbors sharing the same PCI.
Since the UE uses the PCI to identify the cell on which it reports measurements (see
details HO algorithm in Volume 6 - [Vol. 6]), this will cause confusion in the eNB, as it
will not know which of the two cells the report relates to. In the best case, the eNB
knows of the two cells and will ask the UE to report the CGI before triggering a
handover. In the worst case, the eNB knows of only one cell and will trigger a
handover to that cell, whereas the UE may have been reporting the other cell. This
may lead to a high number of handover failures and/or call drops.
Page 32/289
Confusion Area
Figure 4 : Example of PCI confusion
Rule of “PCI MOD 3”

As defined by 3GPP in [R01], the cell-specific frequency shift is given by
vshift = NID-cell MOD 3
This rule limits the risk of interference between the served cells of the same eNB.
This means that the PCI value Modulo 3 of all LteCell of the same eNB having the
same frequency must be different. Note that 3GPP defines a Modulo 3 rule that was
developed for situations with up to six cells per eNB (all operating on the same
frequency), and only one transmit antenna per cell. In the Alcatel-Lucent
implementation of the distributed PCI allocation, a modulo 3 rule is enforced.
4.1.5.1 CENTRALIZED PCI ALLOCATION ALGORITHM
Two different parts can be distinguished in the centralized PCI allocation algorithm:
- PCI provisioning allocates a PCI value for each LteCell while guaranteeing
confusion free and collision free.
- PCI Auto-correction fixes PCI collision & PCI confusion situations.
Restriction: Centralized PCI Allocation Algorithm
If a cell uses antennas that are distributed over a geographic area (a Distributed
Antenna System or DAS), then the cell should not be included in the list of cells for
which the centralized PCI algorithm is run, and the PCI for that cell should be
manually assigned instead.
4.1.5.1.1 PCI PROVISIONING
This part of algorithm is integrated in the WPS cell creation wizard and the objective is
to allocate each cell the first PCI found in the list of available PCIs that is not already
used by another cell having the same frequency and located closer than a
configurable secure distance (called Secured Radius).
Page 33/289
PCI x
Se
cu
re
ra
diu
s
PCI x
Figure 5 : PCI allocation algorithm principle
The algorithm checks also that the PCI allocated is different modulo 3 from all the
existing served cells of the same eNB with the same frequency. The PCI used in the
existing neighbor relations are also taken into account.
This algorithm is based on a specific set of parameters that are mandatory to be set
correctly:
1. Geographical coordinates (latitude and longitude) are used to compute
the geographical location of the eNB and LteCell in the network. The
algorithm uses the coordinates to compute the distance between neighbor
cells and allocate the PCIs.
Geographical coordinates are defined with the following parameters:
- lteCellPositionLongitude : Longitude position of the LteCell in the
WGS84 reference frame (Decimal Degrees) measured from the antenna.
Encoding: < 0: west prime meridian; = 0: at prime meridian; > 0: east of
prime meridian.
Page 34/289
LteCell::lteCellPositionLongitude
Parameter lteCellPositionLongitude
Range & Unit [-180..+180] decimal degrees, step=0.00001
decimalPlaces=5
Class/Source N.A. 1 / customer_init
Value O.D.
Feature L83932
lteCellPositionLatitude : Latitude position of the LteCell in the WGS84

reference frame (Decimal Degrees) measured form the antenna.
Encoding: < 0: south of the equator; = 0: at the equator; > 0: north of the
equator.
LteCell::lteCellPositionLatitude
Parameter lteCellPositionLatitude
Range & Unit [-90..+90] decimal degrees, step=0.00001
decimalPlaces=5
Class/Source N.A.1 / customer_init
Value O.D.
Feature L83932
Note that the lteCellPositionLatitude and lteCellPositionLongitude parameters

contain information that is identical to the information provided by the
mainAntennaPositionLatitude and mainAntennaPositionLongitude parameters
that are described in Volume 7. It is necessary to enter this information for both sets of
parameters, because the lteCellPositionLatitude and lteCellPositionLongitude
parameters are used by in an off-line mode by the WPS PCI allocation wizard, while
the mainAntennaPositionLatitude and mainAntennaPositionLongitude
parameters are used by the eNB to support UE position location when the eNB is
operational.
Engineering Recommendation: Geographical coordinates
The centralized PCI provisioning algorithm is fully dependent on the knowledge of

eNB/cell position, thus its accuracy depends on the correct entry of LteCell Latitude
and Longitude information. These values typically represent the location of the
antennas that are associated with the cell.
1
This parameter is only known at the OMC, so changes have no impact on the eNB state.
Page 35/289
The geographical distance between two cells is computed from the

longitude and the latitude of both cells. It is given by the following formula:
GeographicalDistance (cell1,cell2) = ACOS (SIN (Lat1)*SIN (Lat2) + COS

(Lat1 )* COS (Lat2) * COS (Lon2-Lon1))*6371
With:
- GeographicalDistance in kilometers.
- Lat1: lteCellPositionLatitude of cell1 expressed in radian
(1 degree = 0.0174532925 radians (radian=arc/radius)).
- Lat2: lteCellPositionLatitude of cell2 expressed in radian.
- Lon1: lteCellPositionLongitude of cell1 expressed in radian.
- Lon2: lteCellPositionLongitude of cell2 expressed in radian.
- 6371 is the Earth’s radius in Km
- ACOS : Arc cosine
2. Cell Frequency (dlEARFCN) - the algorithm is executed only on

LteCell(s) that use the same frequency.
The dlEARFCN is an existing parameter (described in [Vol. 3])
3. cellRadius is an LteCell parameter used by the algorithm to identify the

cell coverage and define the default value of Secured Radius that can
guarantee collision free and confusion free condition.
LteCell::cellRadius
Parameter cellRadius
Range & Unit Float
[0..100] km, step = 0.1 km
Feature L115767
Inter-Release Delta: cellRadius
In LR13.1, the range has been increased from 30 km to 100 km; however, the
maximum allowed value is restricted to 70 km. See [Vol. 3] for details.
The step has been decreased from 0.5 km to 0.1 km, thus removing the need
Page 36/289
to “round up” the actual cell radius to the nearest 0.5 km increment.
Rule: cellRadius parameter
If the value of parameter pRACHPreambleFormat = format0 (see [Vol. 3] then

the value of the cellRadius parameter must be no greater than 14 km.
If the value of parameter pRACHPreambleFormat = format2 (see [Vol. 3]), then
the value of the cellRadius parameter must be no greater than 29.5 km.
If the value of parameter pRACHPreambleFormat = format3 (see [Vol. 3]), then

the value of the cellRadius parameter must be no greater than 70 km.
The following rules should be used in setting the value of the cellRadius
parameter:
For RACH Format 0, cell radius up to 14.5 km is supported. For actual
cell radius between 14.0 and 14.5 km, the cellRadius parameter value
should be entered as 14.0km.
For RACH Format 2, cell radius up to 30 km is supported. For actual cell

radius between 29.5 and 30km, the cellRadius parameter value should
be entered as 29.5km.
Page 37/289
Engineering Recommendation: Parameter cellRadius
This information is provided by the cell planning on a cell-by-cell basis. It is

recommended that this parameter be provisioned accurately if the
centralized automatic PCI allocation algorithm is used.
If this parameter cannot be provisioned accurately (on a cell-by-cell basis
using RF planning information) the default value (derived according to the
RF design rule below) can be used:
Dense urban/ urban
@ 2600MHz: 1km cell radius
@ 1800MHz,1900MHz, AWS and 2100MHz: 1km cell radius
@ 850MHz and 900MHz: 2km cell radius
Suburban
@ 1800MHz,1900MHz, AWS and 2100MHz: 2.5km cell radius
Rural
@ 1800MHz,1900MHz, AWS and 2100MHz: 6km cell radius
@ 700MHz 14km cell radius
Note that if the cabling delay exceeds the maximum delay that the modem
can compensate for (i.e. 75000ns), the extra delay adds to the Over-The-
Air delay and must be accounted for in the N CS determination (see [Vol. 4]
for more information).
This is done by provisioning the PRACH apparent Cell Radius = [OTA Cell
Radius + 3×Extra Delay (ns)/10000] (km) in the cellRadius parameter,
where Extra Delay (ns) is the one-way non-compensated cabling delay and
is equal to “Cabling Delay (ns) – 75000 ns”. Please refer to [Vol. 3] for
more information.
The recommended procedure is as follows:

1. Provision the OTA Cell Radius in the cellRadius parameter.
2. Run the centralized Automatic PCI allocation algorithm (offline).
3. Overwrite the OTA Cell Radius value with the PRACH apparent
Cell Radius value for the cells with the cabling delay exceeding
75000ns.
4. Proceed with the workorder generation and the setup of the
cells managed by the SAM server in question.
Please refer to [Vol. 3] for more details on PRACH apparent Cell Radius,
and to [Vol. 2] for more details on the Hardware configurations and
parameters antennaPathDelayUL/ antennaPathDelayDL.
Page 38/289
The secured radius defines the circular area inside of which the PCI must be
unique for each cell)
SecuredRadius = N * cellRadius with N ≥ 3
SecuredRadius is a WPS internal parameter that can be accessed by

the customer during the PCI configuration operation via the PCI
configuration wizard. It is an integer calculated in kilometers (Km).
N is not a configurable parameter, but only a default multiplicative factor
that is used to calculate the proposed value of SecuredRadius size using
cellRadius. The default value of SecuredRadius is computed based on
N = 4 (default SecuredRadius = 4 * cellRadius)
Engineering Recommendation: SecuredRadius
Even though SecuredRadius (computed in km) is modifiable by the operator (within

the PCI configuration wizard in WPS), it is highly recommended to keep the default
value (that is calculated using a value of N = 4).
In case securedRadius must be changed (due to customer and/or geographical

constraints), it must be done carefully as it can have the following negative effects:
• a securedRadius value that is too low will drastically increase the risk of
PCI collision and confusion; on the other hand
• a securedRadius value that is too high will increase the risk of having no
free PCI available.
Engineering Recommendation: SecureRadius vs. cellRadius configuration
The SecuredRadius value can be directly modified in the WPS PCI Configuration
wizard, or indirectly through the cellRadius value.
If SecuredRadius must be modified (to increase PCI algorithm precision), it should

be directly changed in the PCI Configuration wizard, rather than indirectly changed
by modifying the cellRadius value.
Rule: securedRadius internal variable
The WPS system will not allow the securedRadius variable value to be set lower than
2 * cellRadius.
4. List of PCI allowed: The PCI list is a set of PCI that the operator can
pre-define at eNB level and use to allocate the PCI.
There are only 504 PCI to be shared between macro eNB, Pico eNB
and Femto in a specific cluster, thus it is important that the operator
can control the number of PCI used in specific parts of its network.
Page 39/289
AutomaticPhysicalCellIdentity::pciAllowedList
Parameter pciAllowedList
Object ENBEquipment/Enb/SelfOrganizingNetwork/AutomaticPhysical
CellIdentity
Range & Unit list with a maximum of 504 integers in the range of [0..503]
Value O.D.
Feature L83932, L108258
Engineering Recommendation: pciAllowedList
If the list is empty, all the PCI range will be considered. It is recommended to keep
this list empty in order to allow the maximum number of PCIs for algorithm choice.
Operators can decide to reduce the list of PCI according to their own rules (regional
specific).
Each time a new cell (LteCellA) is created on an eNB (with the above mentioned
mandatory parameters correctly set and the PCI not set), the PCI
allocation/provisioning algorithm is run.
Detailed algorithm description is captured in Figure 6.
Page 40/289
lteCellA is selected
- pciListTobeUsed = pciAllowedList (see note)

- sort pciListTobeUsed
Remove from pciListToBeUsed the PCI of the cells

for which lteCellA has a neighbor relation. or a
neighbor’s-neighbor relation with lteCellA
For each lteCell_j of the network having the same

frequency (dlEARFCN) as lteCellA :
- compute geographicalDistance(lteCellA, lteCell_j)
geographicalDistance(lteCellA, lteCell_j)< securedRadius
no yes
Remove PCI of lteCell_j from pciListTobeUsed
Display an error
yes message to the
pciListToBeUsed empty ? operator. Not enough
PCI in pciAllowedList
no
Search the first PCI in pciListTobeUsed

Figure 6 : Centralized Algorithm for
respecting thePCI
ruleprovisioning
PCI MOD 6
yes Allocate the PCI

4.1.5.1.2 PCI AUTO-CORRECTIONDoes PCI exist ? to lteCellA
The algorithm for auto corrective PCI consists of checking then fixing all the potential
PCI collisions and PCI confusion. The algorithm no is implemented in WPS and runs
according to the existing neighbor relations. This means that cells without any
adjacencies cannot be checked by the algorithm.
Display an errorAlso if there
message are some PCI conflicts
to the
provoked by a cell without any neighbor relation,
operator. the respecting
No PCI algorithm thecan neither detect them
nor fix them. rule PCI MOD 6. Increase the
list or manually set the PCI
This auto corrective algorithm takes advantage of the fact that the different
lteNeighboringCellRelation of each LteCell contain all the information needed to
know the PCI used by If
Note: the served cell and
pciAllowedList also the
is empty, thenneighbor cells. = the Full PCI Range
pciListTobeUsed
The geographical coordinates are not used by the algorithm (for performance
reasons). This algorithm has the capability to detect and fix PCI conflicts across the
entire network contrary to the algorithm for PCI provisioning which only fixes conflicts
on a per eNB basis.
The following elements are taken into account by the PCI auto-correction algorithm:
Page 41/289
1. ECGI composed of macroEnbId, relativeCellIdentity and PLMN Identity as

described in 4.1.2
2. PCI as described in 4.1.3
3. List of PCI allowed as described in 4.1.5.1.1

The algorithm selects each LteCell of the network and compares it with its neighbor
cells. If the PCI of LteCell is already used by one of its neighbor cells, the algorithm
identifies the cell having the lower number of neighboring relations then provides it a
new PCI by enforcing the following conditions:
- New PCI must belong to pciAllowedList defined by the operator.
- New PCI must be unique among the neighbor cells and the neighbor
neighbor’s cells.
- New PCI must respect the rule (“PCI MOD 3”) mentioned in Section
4.1.5
A detailed algorithm description is captured in the following diagram:
Page 42/289
For each lteCell of eNB

- collect (ECGI, PCI) of its local cells
- collect (ECGI, PCI) of its neighbour cells
no Does lteCell have a

neighbor relation?
yes
go to the next lteCell Check the uniqueness of PCI of lteCell around its
local and neighbor cells.
Collect (ECGI, PCI) of lteCell having the same PCI
yes no
Is PCI lteCell already
used?
Among the lteCell having the same

PCI, select the one having the
minimum of neighbor relation
Check is OK
Search the first PCI in pciAllowedList

compliant to:
- Unique around the local and
neighbour cells
- Rule PCI MOD 6
yes
Does PCI exist in the Allocate the PCI to lteCEll
pciAllowedList?
no
Display an error message to

the operator
Figure 7 : Centralized Algorithm for PCI auto-correction
Page 43/289
4.1.5.1.3 IMPACT OF CABLING DELAY ON CENTRALIZED

AUTOMATIC PCI ALLOCATION
The centralized Automatic PCI allocation feature requires knowledge of the antenna
node position. Therefore,
areas, then Centralized Automatic PCI allocation should not be used as it is
impossible to define one antenna (node) position (since there are several of
them). In this case, manual provisioning of automatic PCI allocation should be
used for the concerned cells, and these cells with DAS distributed antenna
nodes should not be included in the the list of cells that are input to the
centralized PCI algorithm. Automatic PCI allocation can be used to develop
the PCIs of other cells managed by the same SAM server.
• If DAS HW is used as a fiber transport or if DAS HW is not used, Centralized
Automatic PCI allocation can be used to generate the PCIs (of all the cells).
Please refer to Section 4.1.4 for more details on the use of DAS HW.
4.1.5.2 DISTRIBUTED PCI ALLOCATION ALGORITHM
With Feature 108258 (eNB Based PCI Allocation, Conflict Detection and Correction), a
distributed algorithm for PCI allocation is introduced in connection with the Automatic
Neighbor Relation (ANR) Feature. Both the centralized and distributed algorithms
have the same objective – to allocate a conflict and confusion free PCI to each cell of
the eNB, but the approach used is much different.
With the distributed algorithm, the operator may provide an initial PCI (using the pci
parameter that is described in Section 4.1.3) or the eNB may choose the initial PCIs
for each of its cells from the list defined by the value of the pciAllowedList parameter
(see Section 4.1.5.1.1).
3GPP Standards provide a set of basic tools to facilitate the task of choosing conflict-
free PCIs:
ANR function: an eNB can dynamically learn of its actual neighbors through
UE measurements, rather than depend on configured and possibly faulty or
incomplete information. This maximizes the chances of discovering which
PCIs are in use within the area that is actually covered by a cell.
X2 Served Cells Information: when two eNBs share an X2 connection, they
exchange information about the cells they serve, and in particular, the PCIs
they use. So an eNB can learn which PCIs are in use by neighboring eNBs.
X2 Neighbor Information: two eNBs with an X2 connection between
themselves may also optionally share information about their neighbors. In
this way an eNB can learn about the PCIs of cells served by the neighbor
eNBs of its neighbor eNBs.
Page 44/289
Via X2 interface, eNB can know the frequency used by each neighbor cell.
This information is important because two cells running in different
frequencies can use the same PCI.
The eNB uses information from these sources to choose an initial PCI (if one is not
provided by the operator) and to detect PCI conflicts. PCI conflicts (collision and/or
confusion) that are detected must then be resolved during the next Maintenance
Period (see Section 4.1.5.2.2).
4.1.5.2.1 ENABLING DISTRIBUTED PCI ALOCATION FOR AN

ENODEB
The distributed PCI allocation feature is directly associated with the ANR Feature (see
Volume 6). As a result, it can only be enabled if the ANR feature is enabled (a WPS
check enforces this relationship). by setting the value of parameter
lteIntraFrequencyAnrEnabled to “True”.
The isSonPciAllocationEnabled parameter combined with the
lteIntraFrequencyAnrEnabled parameter, allows the activation and the deactivation
of distributed PCI allocation by eNodeB. Enabling the ANR feature is a pre-requisite
for PCI allocation by eNodeB.
This optional feature is managed by Feature Licensing (refer to LPUG Volume 1 for
details). This parameter can be set to 'True' only if licensing (Tokens) are available for
the feature. The total number of activations for each feature is counted across all
eNBs by SAM.
ActivationService::isSonPciAllocationEnabled
Parameter isSonPciAllocationEnabled
[false; true]
Class/Source C--Immediate-propagation/ system_restricted
Value O.D., Default: false
Feature L108258
If the value of parameter isSonPciAllocationEnabled is equal to “False” and a PCI

conflict is detected, then a critical alarm is raised, and operator intervention is needed
to resolve the conflict.
If the value of parameter isSonPciAllocationEnabled is equal to “True” and a PCI
confusion is detected, then a warning alarm is raised, and the system will attempt to
resolve the confusion during the next maintenance period as described in the next
section. PCI conflict resolution is attempted immediately
Page 45/289
4.1.5.2.2 PCI CONFLICT CORRECTION MAINTENANCE PERIOD
PCI confusion that is detected by the distributed PCI allocation algorithm is corrected
during a maintenance period that is defined by the parameters that are described in
this section. The following general rules are used:
Correction of PCI collision is performed immediately – this action does not

wait for a maintenance period. However, the
enableCollisionMaintenancePeriod parameter can be used to delay this
correction until the maintenance period. See the explanation provided later in
this section.
If a newly commissioned eNB chooses a PCI that causes a confusion, then
it, rather than the previously-existing eNB, will attempt to find a conflict-free
PCI.
enableMaintenancePeriod : This parameter allows the operator to enable or disable
the maintenance period for PCI confusion correction if needed. By default, the
maintenace period is enabled. Typically, if the isSonPciAllocationEnabled value is
“True”, then the value of the enableMaintenancePeriod parameter should also be
“True”
AutomaticPhysicalCellIdentity::enableMaintenancePeriod
Parameter enableMaintenancePeriod
Object ENBEquipment/Enb/SelfOrganizingNetwork
/AutomaticPhysicalCellIdentity
[false; true]
Value Default: True
Feature L108258
maintenancePeriodStartTime: This parameter specifies the start time from which the
eNodeB may select randomly a timer conditioning the PCI confusion correction. It is
set in local time.
AutomaticPhysicalCellIdentity::maintenancePeriodStartTime
Parameter maintenancePeriodStartTime
Object ENBEquipment/Enb/SelfOrganizingNetwork
/AutomaticPhysicalCellIdentity
Range & Unit Integer, h (hour)
[1..24] step = 1
Value Default: 2
Feature L108258
Page 46/289
The value of the timeZoneName parameter is used by the eNB to offset the UTC time
defined in the eNB to local time that is used to determine when to start the
maintenance period based on maintenancePeriodStartTime parameter value. The
timeZoneName parameter is also used to provide timestamp data in local time for
performance files as part of Feature L115220. See [Vol. 2] for a discussion of this use
of the timeZoneName parameter.
Enb::timeZoneName
Parameter timeZoneName
Object ENBEquipment/Enb/
Range & Unit Enumerate, See Table 3 for enumerated values
Value Default: UTC
Feature L115220
Restriction: timeZoneName parameter
Not all values in the Olson timezone database are currently. Only those values that
are needed to support current or projected eNB locations are supported.
Page 47/289
UTC Pacific_Guam
America_Adak Pacific_Honolulu
America_Anchorage Pacific_Johnston
America_Boise Pacific_Midway
America_Chicago Pacific_PagoPago
America_Denver Pacific_Saipan
America_Detroit Pacific_Wake
America_Indiana_Indianapolis Africa_Ceuta
America_Indiana_Knox America_Cayenne
America_Indiana_Marengo America_Guadeloupe
America_Indiana_Petersburg America_Marigot
America_Indiana_Tell_City America_Martinique
America_Indiana_Vevay America_Miquelon
America_Indiana_Vincennes America_Saint_Barthelemy
America_Indiana_Winamac Asia_Almaty
America_Juneau Asia_Aqtan
America_Kentucky_Louisville Asia_Dubai
America_Kentucky_Monticello Asia_Riyadh
America_Los_Angeles Asia_Shanghai
America_Menominee Atlantic_Canary
America_New_York Europe_Madrd
America_Nome Europe_Paris
America_NorthDakota_Center Indian_Reunion
America_NorthDakota_NewSalem Pacific_Gambier
America_Phoenix Pacific_Marquesas_Islands
America_Shiprock Pacific_Noumea
America_St_Thomas Pacific_Tahiti
America_Yakutat
Table 3 : Enumerated Values for Parameter timeZone
The eNB maintenance period happens once a day and is used by the automatic PCI
feature to resolve PCI confusion situations.
The enableCollisionMaintenancePeriod, parameter value of True can be used to
indicate that PCI collision correction should also wait until the maintenance period to
start (rather than starting immediately when it is detected. If the
enableCollisionMaintenancePeriod, parameter value is False, then the PCI collision
correction process begins immediately. If the enableCollisionMaintenancePeriod,
parameter value is True, then the PCI collision correction process does not begin until
the maintenance period. In either case the first step of the collision resolution process
is to start a timer of random length so that only one of the cells with the same PCI will
have to change it.
Page 48/289
AutomaticPhysicalCellIdentity::enableCollisionMaintenancePeriod
Parameter enableCollisionMaintenancePeriod
Object ENB/SelfOrganizingNetwork/AutomaticPhysicalCellIdentity
Range & Unit Boolean, True or False
False – Do not delay PCI collision correction until the
maintenance period
True – Delay PCI collision correction until the maintenance
period
Value Recommended Value = 0
Feature L108258
Engineering Recommendation: enableCollisionMaintenancePeriod
If the value of the enableMaintenancePeriod parameter is “False”, then the value

of parameter enableCollisionMaintenancePeriod should be equal to “False”.
If the operator wishes to delay PCI collision correction until the maintenance
period, then the value of this parameter can be set equal to “True”.
Inter-Release Delta: enableCollisionMaintenancePeriod
In the previous release the function controlled by this parameter was controlled by
parameter Enb::spare15, bit 0.
The eNB must be running with Automatic PCI function activated. That means
ActivationService::isSonPciAllocationEnabled is set to ‘true’
The eNB maintenance period begins. This will happen when local time (calculated
from UTC time by applying offset value defined by the timeZone parameter) is equal
to AutomaticPhysicalCellIdentity::maintenancePeriodStartTime and
AutomaticPhysicalCellIdentity::enableMaintenancePeriod is set to ‘true’.
When the maintenance period (by default, 02:00 hours local time) begins, then, for
each cell that it serves, eNB will:
1. Look for detected PCI confusion situations that involve the cell.
2. If at least one PCI confusion exists:
a. If the cell is new, start a timer with duration that is randomly chosen
between 0 and 15 minutes
b. If the cell is mature, start a timer with duration that is randomly
chosen between 16 and 60 minutes
If an ENB CONFIGURATION UPDATE message is received and signals an update of

a neighbor’s PCI that resolves the conflict, the timer is stopped and the PCI conflict
alarm is cleared.
Page 49/289
If the timer expires, the eNB tries to select a new PCI value for the cell. If it succeeds,
it sends ENB CONFIGURATION UPDATE messages to its peer eNBs to signal the
PCI value update and clears the PCI conflict alarm.
If it fails, the eNB waits for the end of the maintenance period.
If at the end of the maintenance period at least one PCI conflict remains, a PCI
conflict critical alarm is sent to warn the operator and request manual intervention to
solve the issue.
Note: If the issue is resolved through the reception of an ENB CONFIGURATION

UPDATE message, the alarm is not sent
4.1.5.2.3 SPECIAL RULES FOR AUTOMATIC PCI ALLOCATION

AND ONE OR TWO CELL ENBS
The parameter pciAllowedList (see Section 4.1.5.1.1) provides a list of allowable
PCIs for the AutoPCI Algorithm to use when updating a PCI to address PCI collision
or PCI confusion. This parameter is set per eNB, and the values will be available for
all cells on the eNB. As a result, there are special engineering considerations for
setting the parameter on one- and two-cell eNBs. This is due to a current deficiency
with the AutoPCI PCI Selection Algorithm which may cause PCI Index Rotation.
Before discussing the engineering parameter solution for PCI index rotation, the
problem must be defined.
Background: The AutoPCI feature has the capability to allocate confusion-free and
collision-free PCIs to eNBs during startup commissioning. However, operators may
choose to engineer the initial PCIs, even when planning to enable Auto PCI, in order
to minimize Reference Signal Interference or PCI mod 3 interference. PCI mod 3
interference occurs when the reference signal of the serving cell experiences
interference from another cell with the same mod 3 PCI index (or PCI index). It is
impossible to avoid PCI mod 3 interference completely, but the impact can be reduced
by careful PCI planning using offline RF Engineering tools.
For example, common engineering practice is to set the PCI Index of alpha cell
(where alpha cells point a common direction) to zero, beta to one, and gamma to two.
In these cases, consideration of azimuth is required to select the appropriate PCI
index for eNBs with one or two cells. If the AutoPCI algorithm is permitted to select
from a pciAllowedList that contains PCIs whose PCI index values are not among the
PCI indices of the initial PCI assignments, the mod 3 PCI indices may change and the
interference profile will change. The scenario when the PCI index changes from its
initial design value is called PCI index rotation.
It is possible that PCI index rotation could result in better RF performance but, in all
likelihood, the result would be more interference and worse RF performance. This has
been demonstrated in lab testing, so, it is important to prevent PCI index rotation. The
AutoPCI PCI selection algorithm prevents the eNB from choosing a PCI with the same
PCI index as other cells on the eNB, ensuring that PCI index rotation should not
happen on 3-cell eNBs. However, the problem may occur on one-cell and two-cell
eNBs.
For example, consider a worst-case scenario for a three-cell eNB: all three cells of the
eNB require PCI changes, and the AutoPCI Correction random timer of all three cells
coincidently selects the same timer value. AutoPCI is centrally controlled for the entire
eNB, and it performs the PCI Correction modification to the cells in a serial fashion. As
noted above, AutoPCI is not allowed to choose a PCI that will introduce PCI mod 3
interference among cells on the same eNB, so the algorithm will select a new PCI for
Page 50/289
each cell that retains the previous PCI index. This process retains the originally
engineered PCI Index of the cell and avoids PCI Index Rotation.
One and two cell eNBs are another case entirely. If the pciAllowedList parameter is
unset, all PCIs (including all PCI indices) are available to the AutoPCI PCI selection
algorithm. Further, if the pciAllowedList used for three-cell eNBs were used for one-
and two-cell eNBs, the list would have PCIs with all PCI index values available. In
both cases, the pciAllowedList contains PCIs that, if selected for one of its cells,
would introduce PCI mod 3 interference. These PCI values should never be chosen
for the one or two cell eNB. (The eNB does not try to retain the PCI mod 3 index on a
cell, just to avoid introducing PCI mod 3 interference with other cells on the same
eNB.) There is a high probability that the PCI index on one of the cells will change
when AutoPCI is enabled.
Parameter Engineering
The engineering parameter solution, therefore, is to build a pciAllowedList that
contains only PCIs that have a PCI index equal to one of the designed PCIs on that
eNB. This will make it impossible for the eNB to select a PCI Index that is currently not
used on the eNB. And because AutoPCI is not permitted to choose a PCI that
introduces PCI mod 3 interference with another cell on the same eNB, it cannot chose
a PCI which has the same PCI index as the other cells on the eNB. Therefore, by
careful selection of the pciAllowedList, PCI Index Rotation can be avoided.
Special rules are used to prevent Reference Signal interference or PCI mod 3
interference. This is done by allowing
• Alpha cells PCI = 0, 3, 6, 9, 12, 15,…
• Beta cells PCI = 1, 4, 7,10, 13, 16,…
• Gamma cells PCI = 2, 5, 8, 11, 14, 17,…
For eNBs with more than one sector the pciAllowedList may be merged as shown in in
Table 4and the PCI allocation algorithm will take care of avoiding Refererence Signal
Inteference
Initial Initial PCI Index

Number
Cells Defined Values to Example pciAllowedList
of Cells
Defined PCI Index Remove
alpha,
3 beta, 0,1,2 none 0,1,2,3,4,5,6,7,8,9,10,11
gamma
2 alpha, beta 0,1 2 0,1,3,4,6,7,9,10,12,13,15,16
alpha,
2 0,2 1 0,2,3,5,6,8,9,11,12,14,15,17
gamma
beta,
2 1,2 0 1,2,4,5,7,8,10,11,13,14
gamma
1 alpha 0 1,2 0,3,6,9,12,15
1 beta 1 0,2 1,4,7,10,13,16
1 gamma 2 0,1 2,5,8,11,14,17
Table 4 : Example PCI Allowed Lists
Because the pciAllowedList should be defined based on the RAN and eNB
architecture, it is not defined on a per operator basis in the Golden Parameter List
(GPL) but rather in the Customer Information Questionnaire (CIQ or CQ). The
assignment of the pciAllowedList should be permanently bound to the eNB and not
be changed by GPL updates.
Page 51/289
4.1.5.3 SUPPORT OF AUTOMATIC PCI FOR UP TO 6

SECTORS PER SITE AND UP TO 9 CELLS PER ENB
CONFIGURATION (FEATURE 115340)
As we saw in the introduction paragraph of section 4.1.5, in pre-LR13.3, the “PCI MOD
3” interference rule consists in checking that, for a given frequency, two cells of an
eNB use different PCI modulo 3 values.
Starting LR13.3, as the supported number of cells of the same frequency in an eNB
may be superior to 3 (up to 9 cells per eNB), and there are only 3 different PCI modulo
3 values, this interference rule has to evolve. For this, feature L115340 introduces the
notion of ‘site’:
o Two cells of the same eNB are considered as located on the same site if they
are sharing the same value for parameter LteCell::cellSiteNumber.
o A site can not have more than 6 cells (current limitation).

o Cells of the same site are positioned in ‘star configuration’, pointing outwards.
o When cells do not fit with the ‘star configuration’, they are provisioned as 1 cell
per site. Therefore, they can be up to (and no more than) 9 sites per eNB.
This notion of ‘site’ is used to manage intra-sites or inter-sites Interference both for:
Support of Auto PCI for up to 9 cells per eNB and up to 6 sectors per site
configurations feature, as described here.
Adaptation of automatic PCI assignment to HetNet with Metro cell feature, as
described in a later section. For intra-site interference, azimuth is used to
determine which cells of the same site are adjacent. Inter-sites Interference is
managed for Metro cells when there is no more than one cell per site.
LteCell::cellSiteNumber
Parameter cellSiteNumber
Object Enb/LteCell
Range & Unit Integer,
[1.. 9]
Value Default=1
Feature L115340, L115966
With feature L115340, the interference rule consists now in checking that, for a given
frequency, two cells of a site, identified as adjacent, use different PCI modulo 3 values
(the adjacencies being defined after sorting the cells by ascending azimuths values).
As PCI modulo 3 can take only 3 values – 0, 1 and 2 –, figure below shows, for a 6
sectors configuration, the “best case” which the algorithm will try to reach as well as a
Page 52/289
“less good case” (both case are considered as valid and therefore will not lead to any
alarm being raised):
Cell1 Cell1
Cell6 Cell2 Cell6 Cell2

0 0
2 1 2 1
Best case Less good
1 2 1 0
0 2
Cell5 Cell3 Cell5 Cell3
Cell4 Cell4
More precisely, the “PCI MOD 3” interference rule works as follows:

Let cell(n) be the cell of a site for which a PCI value must be found, with 1 ≤ n ≤ N, N
being the total number of cells of the site:
• If N ≤ 3, then the only interference requirement for the PCI of cell(n) is that its
PCI is different modulo 3 from the PCI of the other sectors of the site.
• If 3 < N < 6:
o PCI of cell(n) shall be different modulo 3 from the PCI of the 2
adjacent cells:
Different modulo 3 from PCI of cell(n+1)
Different modulo 3 from PCI of cell(n-1)
• If N = 6:
o PCI of cell(n) shall, if possible, be equal modulo 3 to PCI of cell(n+3)
and different modulo 3 from the PCIs of the 2 adjacent cells on each
side:
Different modulo 3 from PCIs of cell(n+1) and cell(n+2)
Different modulo 3 from PCIs of cell(n-1) and cell(n-2)
o If not possible, PCI of cell(n) shall at least verify the same conditions
as when 3 < N < 6.
Note that, in the different cases when N > 3, the cells need first to be sorted by
ascending azimuths values – from cell(1) to cell (N) – to determine the different
adjacencies.
Therefore, PCI interference detection alarm is raised in the following cases:

• If N ≤ 3:
o Two cells of the same site share the same PCI modulo 3.
• If N > 3:
Page 53/289
o Two adjacent cells share the same PCI modulo 3
Feature LR115340 is activated through the activation flag

ActivationService::isSonPci6Sectors9CellsEnabled. It can only be enabled if
ActivationService::isSonPciAllocationEnabled and ActivationService::
lteIntraFrequencyAnrEnabled are also enabled.
If set to ‘false’, parameter LteCell::cellSiteNumber will not be used and all the cells
are assumed to be on the same site: the automatic PCI algorithm will preserve the
pre-LR13.3 behavior with mono-site 3 cells eNB.
ActivationService::isSonPci6Sectors9CellsEnabled
Parameter isSonPci6Sectors9CellsEnabled
[false; true]
Value false
Feature L115340
Feature L115340 introduces also the parameter LteCell::pciMod3Maintained. If this

parameter, is set to ‘true’, only the PCI with the same PCI modulo 3 as the current one
can be selected when fixing a collision or confusion. This allows keeping a
hypothetical PCI modulo 3 planning performed by the operator.
Nevertheless, even if pciMod3Maintained = ‘false’, the PCI modulo 3 properties of a
cell shall be maintained as long as possible without PCI conflict, as the radio cell
planning may have been performed in such a way to minimize the interference
betweens cells of different eNBs (note that there is no automatic detection of inter-eNB
interference).
LteCell::pciMod3Maintained
Parameter pciMod3Maintained
[false; true]
Value false
Feature L115340
Page 54/289
Automatic PCI resolution with feature L115340:
When a PCI collision or confusion is detected, following constraints, ordered by

priority, have to be taken into account for new PCI selection:
1. The PCI is in the PCI allowed list (SelfOrganizingNetwork::
AutomaticPhysicalCellIdentity::pciAllowedList).
2. If ‘pciMod3Maintained’ is ‘true’, only the PCI with the same PCI modulo 3 as
the current one can be selected.
3. Only the PCI that fits with the “PCI MOD 3” interference algorithm can be
selected => no interference.
4. Only the PCI that are not already used within the eNB can be selected => no
collision intra-eNB (new collision concept introduced by feature L115340).
5. Only the PCI that are not already used within neighbour eNBs can be selected
=> no collision inter-eNB.
6. Only the PCI that are not already used within neighbours’ neighbour eNBs can
be selected => no confusion.
7. If possible, a PCI with the same PCI modulo 3 as the current one will be
selected.
If one of the constraints above can not be respected, the PCI is changed only if, by
changing the PCI, a higher priority conflict is resolved. For example:
• If current PCI leads to interference conflict (constraint 3 above), then the PCI
is modified to solve the interference, even if a confusion (lower priority
constraint 6) is then introduced.
Note that, in the case of a PCI selection in OAM centralized mode (WiPS), an
additional constraint is added as seen in section 4.1.5.1.1 to take into account the
Secured Radius. Keeping the above 6 first constraints, the last two constraints
become:
7. Only the PCI that are not already used by any cell in the Secured Radius can
be selected.
8. If possible, a PCI with the same PCI modulo 3 as the current one will be
selected.
Page 55/289
4.1.5.4 ADAPTATION OF AUTOMATIC PCI ASSIGNMENT TO

HETNET WITH METROCELLS
The goal of the Adaptation of Automatic PCI assignment to HetNet with MetroCells feature
(L115966) is to manage the PCI mod 3 interference (also referred to as Reference Signal
interference, or just interference in this section) between cells of different eNBs in a
Heterogeneous Network (Hetnet). The interference management algorithm analyzes UE
measurements and adjusts PCIs modulo 3 to reduce the interference.
(Another portion of the feature, not discussed here, is a centralized PCI assignment
algorithm available in WPS since LA3.0. WPS algorithm should ease the design and
configuration of HetNets by selecting PCI values that minimize interference between cells
of different sites or different eNBs. Macro and metro cells may utilize different PCI
allowed lists.)
The interference detection and correction algorithm is executed in Metro cells situated in
mono-cell sites. It manages interference between cells of different sites or of different
eNB’s, specifically between metro cells or between macro and metro cells in a Hetnet
Network. Additionally, because the Metro Radio Outdoor (MRO) configuration consists of
several metro cells within the same eNB, for which each cell is on a different site (see
interaction with L115340); the algorithm design is not limited to eNBs with just one metro
cell, but to eNBs with just one metro cell per site.
For the initial version of the feature, however, the implementation is limited to metro cells
with only one cell per site.
The feature is enabled by setting the parameter ActivationService
::isSonPciInterferenceReductionEnabled to True.
ActivationService::isSonPciInterferenceReductionEnabled
Parameter isSonPciInterferenceReductionEnabled
Object ENB/ActivationService
Range & Unit Boolean, True or False
False – Do not activate the management of interference
True – Activates the management of interference
Value Default=False
Feature L115966
The calculation of the interference level, which may lead to a PCI change, is performed
within the maintenance window. The actual time of the change is managed by random
timers set at each cell; cells that are ANR active will use shorter timer values than cells
that are ANR complete, to bias PCI changes toward newer cells over established cells. If
a PCI conflict (PCI collision or PCI confusion) is also detected, only one timer will be set.
When the timer expires, the eNB will take actions to address both the interference and the
conflict on the cell whose timer expired. If a remote eNB takes actions to clear the PCI
conflict and alerts the local eNB, the timer on the local eNB will not be cleared if PCI
interference has not been addressed.
Page 56/289
The interference management portion of the algorithm utilizes the power measurement
obtained from intra-frequency HO measurement reports and intra-frequency ANR
measurement reports to determine the neighbors ordered by power and as well to weigh
the contribution of each of them. Taking these measurements reports into account, will
prevent us to detect for instance a powerful neighbor that is detected in a lowly user place.
When the timer expires, the eNB evaluates the counters and computes the total number of
measurements for each cell. If the sum of the counts for all cells is greater than or equal
to interferenceMinMeasurements the interference level is computed and the relevant
counters are cleared. If this level is not reached, no calculation is performed; the counter
values are not cleared, allowing accumulation of the measurements to continue. In order
to consider a PCI change on a particular cell, the count for that cell divided by the sum of
the counters for all cells must meet or exceed the parameter InterferenceThreshold.
When the threshold interferenceMinMeasurements is reached, the eNB computes three
interference counters for that the eligible cells, one for each PCI mod 3 value. (If a remote
cell changes its PCI mod 3 during the counting, the count for that neighbor is assigned to
the interference counter associated with the new PCI mod 3 value.)
, the algorithm then evaluates the three interference counters. If the difference between
the any two of the counters, expressed as a percentage of the total number of
measurements, is less or equal to the threshold interferenceThreshold, the PCI mod 3
values associated with those counters are grouped together. The resulting groups are
then ranked from best (counter or group of counters with the lowest interference) to worst
(counter or group of counters with the highest interference) according to their interference
counters. If the mod 3 value of the current PCI is not among the group or groups ranked
“best,” then the cell is considered to suffer from interference.
Page 57/289
AutomaticPhysicalCellIdentity::interferenceMinMeasurements
Parameter interferenceMinMeasurements
Object Enb/SelfOrganizingNetwork/AutomaticPhysicalCellIdentity
[0..65000] Step 1

Value Default=100
Feature L115966
AutomaticPhysicalCellIdentity::interferenceThreshold
Parameter interferenceThreshold
Object Enb/SelfOrganizingNetwork/AutomaticPhysicalCellIdentity
[0..100] Step 1

Value Default=20
Feature L115966
If a cell suffers from PCI mod 3 interference; then when the timer expires, the interference
management algorithm will look for a new PCI from among the “best” PCI groups in order
to minimize the interference. The new PCI should not introduce PCI collision or confusion,
whenever possible. If this is not possible, then a PCI should be selected to cause the
lowest priority problem, according to the list below:
1. Intra-site interference
2. Inter-site interference
3. Intra-eNB PCI collision
4. Inter-eNB PCI collision
If the eNB is not able to find a PCI in the pciAllowedList from the best mod 3 group, no
change is made and a critical Interference alarm is raised.
The following feature interactions have been identified.
Feature ID Feature Title Nature of Interaction
This feature defines the site

Support of Auto PCI for up to
notion and MIM parameter
L115340 9 cells and up to 6 sectors
that is necessary to manage
eNB configurations
Interference between metro
Page 58/289
cells in case of MRO (up to 9

metro cells within an eNB).
This feature closes a common
Open Point about the PCI
modulo that prevents from
interference
Auto PCI Advanced The controlled mode is not
T115169 Requirements - Controlled compatible with the current
mode with WATSON feature
Describes the HW
Nine cells (one frequency) configurations and the 'site'
115401
support on three modems provisioning that is used by
this feature
Automatic Configuration of Initial description of PCI
81873
Physical Cell ID centralized algorithm
Initial description of PCI
83932 SOON: physical cell ID
centralized algorithm
Initial description of PCI
eNB Based PCI Allocation,
distributed algorithm.
108258 Conflict Detection and
This feature must be
Correction
activated
The ANR feature must be
108172 Full Support of Intra-LTE ANR
activated
PM counters created for ANR
replacement function are re-
159506 ANR Enhancements - Phase 3
used. So increment is
dependent of both features.
Table 5 : L115966 Feature Interaction & Dependencies
Engineering Recommendation: isSonPciInterferenceReductionEnabled
If the value of the isSonPciInterferenceReductionEnabled parameter is “True”,

then the following rules should be applied:
ActivationService::isSonPciAllocationEnabled’=True (should be set to true to
have ‘Automatic PCI’ activated)
ActivationService::lteIntraFrequencyAnrEnabled’=True (should be set to ‘true’

to have ANR activated).
ActivationService::isPciControlledModeEnabled=false (should be set to ‘false’
because both features are not compatible)
LteCell::PciMod3Maintained=false (should be set to ‘false’ because features are
not compatible)
LteCell::CellKind=Metro
LteCell::CellSiteNumber=1 (The cell is alone in its site (cells are grouped per site
using the ‘cellSiteNumber’ parameter of the ‘lteCell’ MO
Page 59/289
4.2 EUTRAN SHARING

The current eUTRAN sharing (among operators) capability is supported by the
following feature:
• L115242 (bCEM) and L115242.1 (eCEM) – eUTRAN Sharing: enhanced

Multi-Operator Core Network (MOCN) (either shared or dedicated spectrum)
This feature enhances the initial MOCN eUTRAN sharing solution to support:
• Additional Resource Management capability
• Extended number of PLMN shared per eNB
• RAN sharing with Multi-carrier configuration with bCEM modem unit.
In case both RAN sharing MOCN and Multi-carrier configuration (in same or different
band with the bCEM modem unit) are supported on the eNB, either shared spectrum
or dedicated spectrum configuration is possible. When eUTRAN sharing is supported
in a single carrier configuration, only shared spectrum is possible.
Following are some significant characteristics of eUTRAN sharing with Feature
L115242:
• For eNB, operators are distinguished by their PLMN (combination of MCC and
MNC) – see Section 4.1.2.
• Each eNB may be shared by up to four operators.
• A mix of dedicated and shared cells can be supported on the eNB. Note that
3GPP TS36.331 requires that all cells of an eNB have the same primary
PLMN and to broadcast this identity in SIB1. Thus, a workaround must be
used when there is a dedicated cell for a non-primary PLMN operator.
• Within a shared cell, specific resources can be devoted to each operator, and
some resources can be shared among operators.
• A primary operator is determined on a per eNB basis. This operator operates
the network in which the eNB appears. The primary operator’s PLMN is
indicated by setting the value of the isPrimary parameter value for the
associated PlmnIdentity instance to “True” (see Section 4.1.2). The instance
of the PlmnIdentity with the value of isPrimary set equal to “True” defines
the MCC and MNC that are used to define the ECGI for each of the eNB’s
cells.
• Arrangements are provided in SAM so that each operator can view their own
resources, but not see those devoted to other operators.
• Each cell of the eNB will broadcast the list of PLMN identities in SIB1 (see
Section 4.3). The primary operator’s PLMN will be broadcast first in the list.
Depending on how the sharing is configured, each cell can broadcast the
same or a different list of associated PLMNs.
• The eNB will provide the list of PLMN identities that are broadcast on the cells
that it serves in messages that are exchanged over the X2 and S1 interfaces.
The impacted procedures are:
Page 60/289
o X2 Setup
o X2 eNB Configuration Update
o S1 Setup
o S1 eNB Configuration Update

• It is possible for all of the links to an operator’s MMEs to be down. In this case,
the matching PLMN ID will be removed from SIB1, unless the operator is the
primary operator. The PLMN ID for the primary operator will not be removed
from SIB1, because TS36.331 states that at least one PLMN identity must be
broadcast in SIB1 (and the first PLMN ID is necessarily this primary PLMN
ID.)
• If the eNB cannot access any MME, then all cells of the eNB will be barred as
described in Section 4.9.3 (this is consistent with the behavior in previous
releases). Cell barring applies to all PLMN IDs, so it cannot be used when
access is still available to one or more PLMN ID(s).
• eUTRAN sharing is an optional feature that is managed by Feature Licensing
(refer to LPUG Volume 1 for details). The number of PLMNs that can be
supported is checked across all eNBs to determine if sufficient licenses
(Tokens) are available for the feature. The total number of PLMN activations
for the feature is counted across all eNBs by SAM based on the value of the
maxNbPlmnForMocnLicense parameter. One activation is counted for each
operator that is associated with one or more of the eNB’s cells.
• Admission control is possible on a per operator basis. A given amount of

resources (in terms of connected users and bearers) can be assigned to each
of the operators that share the eNB. As a result, call admission can be
performed for each operator individually. See [Vol. 4] for information on call
admission impacts of the eUTRAN sharing features.
• Interworking of carriers on different frequencies and having different supported
PLMN lists on the same eNB is possible with the bCEM modem unit.
Page 61/289
maxNbPlmnForMocnLicense This parameter specifies the operator's view of the

maximum number of Mobile Networks that are permitted to be supported by the
eNodeB under eUTRAN-sharing in a Multi-Operator Core Network environment. The
value of this parameter is checked by the license-management system for consistency
with the license for eUTRAN-sharing that is issued to the operator. The value of this
parameter should be equal to the number of instances of the PlmnIdentity object.
LicensingMngtSystem::maxNbPlmnForMocnLicense
Parameter maxNbPlmnForMocnLicense
Object ENBEquipment/Enb/LicensingMngtSystem
Enumerate
Range & Unit {disabled, 2, 3, 4, 5, 6}
Note: Values of 5 and 6 are not currently supported
Value O.D.
Feature L104835, L104836, L114383, L115242, L115680
Restriction: maxNbPlmnForMocnLicense
For parameter maxNbPlmnForMocnLicense, only values of disabled, 2, 3, and 4

are supported lin release LR13.1
Page 62/289
In addition to the MOCN capability, a capability is included with Features L115244

(bCEM) and L115244.1 (eCEM) [GWCN configuration (with shared MME) for eUtran
Sharing] so that the eNB can support core networks that are shared by multiple
operators. This capability is called Gateway Core Network (GWCN), and it allows
several operators to share the MME and potentially the Serving Gateway (S-GW). This
concept is illustrated in Figure 8.
CN CN CN
Operator A Operator B Operator C
......... .........
Shared Shared Shared
MME MME MME
Shared
S-GW Shared
S-GW
S1
eNB eNB eNB
Radio Access Network

Operator X
Figure 8 : GWCN Architecture
With the GWCN capability, from an eNB perspective, each MME and the S-GW can
be shared by up to four PLMNs. One of the PLMNs must still be designated as the
primary PLMN. This is done by the setting of the isPrimary parameter that is defined
in Section 4.1.1.1. Each PLMN defined for the shared eNB must be associated with at
least one shared MME.
The GWCN capability is a licensed feature, and a license is needed to match the
maximum number of PLMNs for which there are shared MMEs. The maximum number
of PLMNs that can share an MME for which resources are reserved in the eNB is
defined by the value of the maxNbPlmnForGwcnLicense parameter.
maxNbPlmnForGwcnLicense : This parameter specifies the operator's view of the
maximum number of shared MME between different CN that are permitted to be
supported by the eNodeB in a GWCN environment (multiple core network operators,
but with shared Gateways).
The value of this parameter is checked by the license-management system for
consistency with the license for eUTRAN-sharing that is issued to the operator.
Page 63/289
LicensingMngtSystem::maxNbPlmnForGwcnLicense
Parameter maxNbPlmnForGwcnLicense
Object ENBEquipment/Enb/LicensingMngtSystem
Enumerate
Range & Unit {disabled, 2, 3, 4, 5, 6}
Note, the values of 5 and 6 are not supported in release LR13.1
Value O.D.
Feature L115244, L115680
Restriction: maxNbPlmnForGwcnLicense
For parameter maxNbPlmnForGwcnLicense, only values of disabled, 2, 3, and 4

are supported lin release LR13.1
In release LR13.1, Feature L115680 supports sharing among PLMNs for dual carrier
cells in which cells are overlaid on two different frequencies either in the same band or
different bands. One cell may be dedicated to a single PLMN, and the overlaid cell can
be shared among several PLMNs. This is a combination of the capabilities provided by
the following features from LA5.0 and LA6.0:
Feature Number Nature of Dependency
L115242 and These features introduce the support of MOCN architecture in
L115242.1 (LA5) LA5.
L115244 and These features introduce the support of GWCN architecture in
L115244.1 (LA5) LA5.
This feature introduces the support of dual carrier on one
L115938 (LA6)
band
This feature introduces the support of dual band on two
L115616 (LA6)
modem boards
Only a limited set of combinations of possible carrier configurations will be tested and
supported in LR13.1, based on identified and potential customer needs.
4.3 COMMON AND SHARED CHANNELS SETUP

Based on the configuration parameters received during the eNodeB startup sequence,
the eNodeB will start the initialization of each of its cells.
The following physical channels are established in the cell:
Page 64/289
• Physical broadcast channel (PBCH)

• Physical control format indicator channel (PCFICH)
• Physical downlink control channel (PDCCH)
• Physical downlink shared channel (PDSCH)
• Physical multicast channel (PMCH)
• Physical uplink control channel (PUCCH)
• Physical uplink shared channel (PUSCH)
• Physical Hybrid ARQ Indicator Channel (PHICH)
• Physical random access channel (PRACH)
The following transport channels are established in the cell:

• Broadcast Channel (BCH)
• Downlink Shared Channel (DL-SCH)
• Paging Channel (PCH)
• Multicast Channel (MCH)
• Uplink Shared Channel (UL-SCH)
• Random Access Channel(s) (RACH)
The mapping of downlink transport channels on physical channels is the following:
Figure 9 : Downlink transport channel mapping
The mapping of the uplink transport channels on physical channels is the following:
RACH UL-SCH
Uplink
Transport channels
Uplink
Physical channels
PRACH PUCCH PUSCH
Figure 10 : Uplink transport channel mapping
Page 65/289
The following control logical channels are established in the cell:

• Broadcast Control Channel (BCCH)
• Paging Control Channel (PCCH)
• Common Control Channel (CCCH) in the UL and DL
• Multicast Control Channel (MCCH)
The mapping of downlink logical channels to transport channels is the following:

Downlink
Logical channels
Downlink
Transport channels
PCH BCH DL-SCH MCH
Figure 11 : Downlink logical channel mapping
The mapping of uplink logical channels to transport channels is the following:
CCCH DCCH DTCH

Uplink
Logical channels
Uplink
Transport channels
RACH UL-SCH
Figure 12 : Uplink logical channel mapping
As part of the cell setup procedure after the physical and transport channels are setup
in the cell, the eNB will start broadcasting RRC System Information messages on
BCCH of the cell.
During the Cell setup, the states changes of the LteCell MO are managed as
described in section 4.11
At the end of the cell setup procedure, the eNB is ready to accept mobile originated or
terminated calls in this cell.
Failure cases
Page 66/289
In case of cell setup failure the LteCell MO state is changed as below. A human
intervention via OMC is needed to correct the configuration data and proceed with e.g.
a modem board reset.
Event LteCell MO states attributes

(administrative/operational/availa
bility)
When cell initialization starts Unlocked/Disabled/Dependency
When a sector and a modem are available Unlocked/Disabled/Failed
and cell setup fails ( see Note)
Table 6 : LteCell MO State attributes
Note: The availability “failed” is used for cases like invalid configuration parameter
or software anomaly for which there is no defense mechanism (e.g. board reset(s)
done but error persists or no defense at all).
4.4 SYSTEM INFORMATION BROADCASTING
4.4.1 INTRODUCTION
System Information messages are carried over the BCCH logical channel and provide
network-related configuration data to the mobiles. The BCCH is mapped onto both:
- The BCH transport channel (for the MasterInformationBlock) which is carried by the
PBCH physical channel
- The DL-SCH transport channel (for all other system information blocks) which is
carried on the PDSCH.

Downlink
Logical channels
(SIB1, SIM)
Downlink
Transport channels
PCH BCH DL-SCH MCH
Figure 13 : Channels used for System Information
There are a maximum of 32 System Information Blocks that may be defined, in

addition to the MasterInformationBlock. Currently only thirteen have been
standardized. Following is a brief description of the current information blocks' content:
• MasterInformationBlock or MIB: essential physical layer information.
• SystemInformationBlockType1 or SIB1: cell access information and scheduling of
other system information messages.
Page 67/289
• SystemInformationBlockType2 or SIB2: common, shared channel information, Class

Barring info and if eMBMS is enabled: MBSFN-SubframeConfigList
• SIB3: cell re-selection information
• SIB4: intra-frequency neighboring cells
• SIB5: inter-frequency neighboring cells
• SIB6: inter-RAT cell re-selection towards UTRAN
• SIB7: inter-RAT cell re-selection towards GERAN
• SIB8: inter-RAT cell re-selection towards CDMA2000
• SIB9: home eNB identifier (not currently used)
• SIB10 and SIB11: Earthquake and Tsunami Warning System or ETWS (not used in
current implementation)
• SIB12: Commercial Mobile Alert Service or CMAS – Feature 92127
• SIB13: acquire the MBMS control information associated with one or more MBSFN
areas
• SIB16 (introduces in Release 11): providing time information to the UE.
SIB6/SIB7 and SIB8 are mutually exclusive – that is, if one is present, the other
cannot be transmitted. Operators are not expected to support mobility to
UTRAN/GERAN and to HRPD from an eNB.
SIB16 is needed for EMBMS devices to interpret the EMBMS service descrition files
and to be able to consume the services when they are broadcast.
The SIB16 includes the following IEs:
• The UTC time (mandatory)
• The number of leap seconds necessary to convert GPS to UTC time (optional)
• IE necessary to convert UTC time to local time and Daylight Saving Time.
(optional)
System Information size ranges in bits are provided hereafter. Minimum and maximum
sizes are derived from the ASN1 constructs, while expected size is estimated based
on current feature content. The numbers are given to provide an indication of System
Information Block sizes, and must be used with caution.
Page 68/289
Message / Block Min Size Max Size Expected Size

MIB 24 24 24
SIB1 114 460 172 (=158 + 6 + 8)
SIB2 186 300 (=273 + (2x12+3)) 270 (205 +[3 + 2 *
470 (=300 + [170 if 31 if eMBMS is
eMBMS is enabled)] enabled])
SIB3 29 75 66
SIB4 4 490 476
SIB5 66 2202 584
SIB6 7 763 763
SIB7 56 2202 522
SIB8 (HRPD Only) 10 2202 540 (=377
+9x16+19)
SIB8 (1xRTT Only) 10 2202 612 (=377
+9x24+19)
SIB8 (Drx 1xCSFB 12 2202 705 (=377 + (377 - 5
+ HRPD + 1xRTT) -51) + 7)
SIB8 (HRPD + 154 2202 868 (=377 + (377 - 5
1xRTT + e1xCSFB) -51) + 7 + 163)
SIB12 50 2202 690
SIB13 41 237 41 (= 13 + 28*1)
Table 7 : System Information Block Sizes (in bits)
The MasterInformationBlock and SystemInformationBlockType1 use fixed

scheduling, whereas all other system information blocks are carried in System
Information Messages whose scheduling is defined in SIB1.
The MasterInformationBlock is scheduled in sub-frame 0 of frames with SFN mod 4
= 0, with repetitions in sub-frame 0 of every radio frame. It therefore has a periodicity
of 40ms (a MasterInformationBlock with a new System Frame Number is sent every
40 ms) and a repetition rate of 10ms (the MasterInformationBlock is repeated 3 times
at 10ms intervals without changing the SFN).
Figure 14 : Master Information Block periodicity
Page 69/289
Note: the full system frame number is 10 bits long, composed of 8 bits provided in the
MasterInformationBlock and 2 bits acquired implicitly from the BCH decoding.
The SystemInformationBlockType1 is scheduled in sub-frame 5 of frames with SFN

mod 8 = 0, and is repeated in sub-frame 5 of every even frame. It therefore has a
periodicity of 80ms, with a repetition rate of 20ms. Note that the SIB1 maximum size
includes four PLMN identities for the cell, the inclusion of ims-EmergencySupport-r9 (1
bit), snd the SIB1 structural overhead in R-9 to encode the presence or absence of
optional Relase 9 extensions.
The other System Information Blocks have a periodicity that may be individually set
among the following values: 8, 16, 32, 64, 128, 256, or 512 radio frames. The
periodicity of System Information Blocks 2 and upwards is indicated to the UEs by
the SchedulingInformation IE contained in SystemInformationBlockType1.
SIBs 2 and upwards are carried in System Information Messages, which contain one
or several SIBs and are broadcast within recurring periods called SI-windows. The
duration of the SI-window is common to all SI Messages, and is broadcast in SIB1. SI-
windows of different SI Messages do not overlap, in other words only one SI
Message is broadcast and eventually repeated within an SI-window. The first SI
Message to be scheduled must contain SIB2 in the first position, and an SI Message
may only contain SIBs that have the same periodicity.
Resource allocation for System Information Blocks is signalled on the PDCCH channel
using the dedicated SI-RNTI (defined as 0xFFFF in [R07]).
Each SIB (2…13) is assigned to a scheduling class, and for each scheduling class a
target periodicity is configured. The use of the scheduling classes allows SIBs of the
same class to be grouped into the same SI message, and this reduces bandwidth
requirements and complexity. Allowing the operator to configure the MCS for each
class allows the operator to optimize the physical link usage.
The parameters that configure the MCS usage are defined in Volume 4, since they are
directly related to the scheduler. The parameters that define the SIB scheduling
classes and the target periodicity are defined in the following paragraphs.
• sib2SchedulingClass: This parameter specifies the SIB Scheduling Class id for

SystemInformationBlockType 2
SysInfoConf::sib2SchedulingClass
Parameter sib2SchedulingClass
1 to 3, Step 1
Value 1
Feature L108958
Page 70/289

Parameter sib3SchedulingClass
1 to 3, Step 1
Value 1
Feature L108958

Parameter Sib4SchedulingClass
1 to 3, Step 1
Value 3
Feature L108958

1 to 3, Step 1
Value 3
Feature L108958
Page 71/289

1 to 3, Step 1
Value 3
Feature L108958

1 to 3, Step 1
Value 3
Feature L108958

1 to 3, Step 1
Value 3
Feature L108958
Page 72/289

1 to 3, Step 1
Value 2
Feature L92127
Rule: sib12SchedulingClass
As indicated in the recommended values shown above, the value of parameter
sib12SchedulingClass should be different from the value used for parameters
sib5SchedulingClass, sib6SchedulingClass, and sib7SchedulingClass.

1 to 3, Step 1
Value 1 ALU recommends that the operator not change this
value
Feature L90280, L115527
Page 73/289

1 to 3, Step 1
Value 3
Feature 167219
• sibClass1TargetPeriodicity: This parameter specifies the target periodicity to

be applied for transmissions of SIB Scheduling Class 1, broadcast in SIB1.
SysInfoConf::sibClass1TargetPeriodicity
Parameter sibClass1TargetPeriodicity
[rf8, rf16, rf32, rf64, rf128, rf256, rf512]
Value Rf16
Feature L108958

[rf8, rf16, rf32, rf64, rf128, rf256, rf512]
Value Rf32
Feature L108958
Page 74/289

[rf8, rf16, rf32, rf64, rf128, rf256, rf512]
Value Rf64
Feature L108958
Rule:
1. Each scheduling class must differ by the periodicity, the targetMCS, or
both.
2. sibClass1TargetPeriodicity ≤ .sibClass2TargetPeriodicity ≤
sibClass3TargetPeriodicity
3. When the downlink bandwidth is equal to 1.4 MHz, then the

sibClass1TargetPeriodicity should be greater than or equal to 160
milliseconds (Rf16)
isTransmitSib16Enabled: This parameter enables SIB16 transmission in the related

cell. When set to true, the SIB16 will include GPS time and leap seconds.
CellActivationService::isTransmitSib16Enabled
Parameter isTransmitSib16Enabled
Object EnbEquipment/Enb/LTECell/CellActivationService
True, False
Value False
Feature 167219
Page 75/289
isDayLightSavingTimeInSib16Enabled: This parameter enables the presence of

the daylight saving time IE in SIB16 when this information block is transmitted.
CellActivationService:: isDayLightSavingTimeInSib16Enabled
Parameter isDayLightSavingTimeInSib16Enabled
True, False
Value False
Feature 167219
isLocalTimeOffsetInSib16Enabled: This parameter enables the presence of the

local time offset IE in SIB16 when this information block is transmitted.
CellActivationService:: isLocalTimeOffsetInSib16Enabled
Parameter isLocalTimeOffsetInSib16Enabled
True, False
Value False
Feature 167219
4.4.2 VALUE TAG MANAGEMENT

SystemInformationValueTag (hereafter referred to as value tag) is a mandatory
Information Element in RRC message SystemInformationBlockType1. It takes integer
values within a set of 32 values, and must be updated every time the system
information changes.
It is one of two mechanisms used to signal to the UEs that System Information has
changed and must be read again. The other mechanism uses an optional bit in RRC
Paging to indicate the change in System Information. Support of this second
mechanism was included starting in LA2.0.
With feature L97933 (Dynamic SysInfo Modification under Cell Parameter Change) if
there are any changes of “Class C” parameters relating to SIBs in the configuration
data, SAM notifies the eNB about the change to support dynamic System Info
modification. The value tag in SIB1 is updated to be included in System Info and, prior
to the inclusion of the actual change in System Info broadcasting, an optional bit in
RRC Paging is used indicate to all UEs about the upcoming change in System Info.
Page 76/289
This process is referred to as DSIM with CNP (dynamic System Info modification with
Change Notification Paging).
There is no simple way for the CallP to know that system information has changed
since the last ENB restart or since the cell has been locked. As a result, following eNB
restart or cell unlock, the value tag is updated, regardless of the reason that triggered
the action.
4.5 SYSTEM INFORMATION MODIFICATION

Dynamic modification of the system information is only permitted at specific points in
time. These instants are the boundaries of periods called "modification periods", which
is somewhat misleading because in fact, no change may occur during a modification
period.
The duration of the modification period is calculated using two parameters that are
broadcast in SIB2: modificationPeriodCoeff which takes its values in the range {2, 4,
8, 16} and defaultPagingCycle which may be set to 32, 64, 128 or 256 radio frames
(cf. the paragraph on Paging, 7.3). The duration of the modification period is
expressed in numbers of radio frames and is given by the following formula:
modificationPeriod = modificationPeriodCoeff * defaultPagingCycle
When the value of one or several parameters broadcasted in the System Information
messages is changed during a given modification period N, or when there is a growth
or de-growth of instances in the configuration data that are mapped to SIBs
parameters, the actual messages being broadcast over the air interface will be
updated at the boundary between modification period N and N+1 if there remains a full
paging cycle before the end of period N (see Figure 15), Otherwise, the update will be
at the boundary of periods N+1 and N+2 (see Figure 16).
Page 77/289
SAM
XMS
SIBx, Cell_ID=K)
SCHEDULING_REQUEST(SIBx, sizes, etc)

Delta Update(
Encode the modified SIBx and
UPDATE_REQUEST(encoded SIBx)
When the ending boundary of Modification Period
set SIB1’s ValueTag += 1
(N) is about to be reached, the DL Scheduler
CELL_RLC_MAC_SYSINFO_
eNB • Copies Next_SIBx to Current_SIBx;
CallP • Deletes the existing SIB pre-booking;
• Re-performs SIB pre-booking.
Send a CNP for
Broadcast of SI messages carrying the updated
each PO in the last
SIBs begins at the starting boundary of
defaultPagingCycle
Modification Period (N+1).
DL
Scheduler N N+1 N+2 BCCH
Current SIBx Current SIBx Modification
Period
Next SIBx
Modification)
Modem (K)
systemInfo
Page(
…
RRC Idle &
Connected
UEs Assume 2 DefaultPagingCycle’s
in a Modification Period A UE’s Paging Occasion
(PO) in DefaultPagingCycle
SIB1 and SIBx prior to and
during “change notification”
Change notification Updated information
(Same or modified) SIB1 with
ValueTag change and
modified SIBx after “change
BCCH modification period (N) BCCH modification period (N+1)
notification”
Figure 15 : CNP when there is a full paging cycle before the end of Modification Period (N).
SAM
XMS
SIBx, Cell_ID=K)
SCHEDULING_REQUEST(SIBx, sizes, etc)

Delta Update(
In this variation the DSIM trigger arrives after When the ending boundary of Modification
UPDATE_REQUEST(encoded SIBx)
the start of the last DefaultPagingCycle of Period (N+1) is about to be reached, the DL
Modification Period (N) such that at least one Scheduler
PO has been missed for CNP purpose. So • Copies Next_SIBx to Current_SIBx;

eNB • Deletes the existing SIB pre-booking;
CNP starts in the 1st DefaultPagingCycle of
CallP
Modification Period (N+1), as shown. • Re-performs SIB pre-booking.
Broadcast of SI messages carrying the
updated SIBs begins at the starting boundary
of Modification Period (N+2).
DL
Scheduler N N+1 N+2 BCCH
Current SIBx Current SIBx … Current SIBx Modification
Period
Next SIBx Next SIBx

Modification)
Modem (K)
systemInfo
Page(
RRC Idle &

Connected
UEs Assume 2 DefaultPagingCycle’s
Send a CNP for each PO in in a Modification Period
the last defaultPagingCycle.
May repeat CNP in previous
paging cycle(s). Change notification Updated information
BCCH modification period (N) BCCH modification period (N+1)
Figure 16 : CNP when there is not a full paging cycle before the end of Modification Period (N).
Page 78/289
The reason for CNP is that one of the two methods that the UEs can use to check for
System Information modification is to listen for a Paging message indicating a
change in System Information. Since a UE only listens to its own paging occasions
and since there is only one paging occasion during a paging cycle for each UE, it is
necessary to go through a full paging cycle in order to page all mobiles for a change in
System Information.
The other method that a UE may use to check for System Information updating is to
check the Value Tag at each boundary between modification periods. The eNodeB
must update the value tag every time the system information that is broadcast is
modified.
modificationPeriodCoeff : Defines the duration of the period during which System

Information cannot be modified, in number of default paging cycles. Defined in TS
36.331.Broadcast in SystemInformationBlockType2
LteCell::modificationPeriodCoeff
Parameter modificationPeriodCoeff
[n2, n4, n8, n16]
Value n2
Feature
The modification period boundaries are defined by SFN values for which SFN mod m=
0, where m is the number of radio frames comprising the modification period. The
modificationPeriod is configured by system information.[R07]
When the network changes (some of the) system information, it first notifies the UEs
about this change i.e. this may be done throughout a modification period. In the next
modification period, the network transmits the updated system information. These
general principles are illustrated in figure below, in which different colors indicate
different system information. Upon receiving a change notification, the UE knows that
the current system information is valid until the next modification period. The UE
applies the previously acquired system information until the UE acquires the new
system information.[R07]
Change notification Updated information
BCCH modification period (n) BCCH modification period (n+1)
Figure 17: Change of system Information

The Paging message is used to inform UEs in RRC_IDLE and UEs in
RRC_CONNECTED about a system information change. If the UE receives a Paging
Page 79/289
message including the systemInfoModification, it knows that the system information

will change at the next modification period boundary. Although the UE may be
informed about changes in system information, no further details are provided e.g.
regarding which system information will change.[R07]
E-UTRAN may not update systemInfoValueTag upon change of some system

information e.g. ETWS information, regularly changing parameters like CDMA system
time. Similarly, E-UTRAN may not include the systemInfoModification within the
Paging message upon change of some system information.[R07]
4.6 SYSTEM INFORMATION IMPACTING UE CONNECTIVITY,

IDLE MODE CELL RESELECTION AND INTER-RAT MOBILITY
With dynamic modification of System Information, the parameters whose modification
could affect UE connectivity have been analyzed by RAN1 in [R14] and are listed
hereunder:
(2)
- N RB in [R01] indicates the number of CQI only RBs.
(1)
- N cs in [R01] indicates the number of CS values used for CQI in mixed RBs of CQI
and ACK/NACK or SR.
(1)
- N PUCCH in [R01] indicates the boundary between the resource for ACK/NACKs for
persistent scheduling or SR and the resource for ACK/NACK for dynamic scheduling.
- ΔPUCCH
shift in [R01] indicates how to use the PUCCH resource.
At this stage no other parameters are considered to possibly affect UE connectivity
when modified dynamically.
In addition to UE connectivity, dynamic modification of System Info also impacts idle-
mode UE cell reselection and active UE inter-RAT mobility. This is because some
SIB-related parameters and MOs/sub-MOs are optional and, if of “Class C” type, can
become present or absent dynamically.
As an example, consider LTE-to-HRPD mobility. SIB8 in System Info is optional; if
present, it has an influence on idle UE cell reselection. If the IRAT feature control is
also activated, the influence of SIB8 extends to active UE IRAT redirection/mobility
and the associated KPI. This means once SIB8 is included in System Info, dynamic
change of parameters in SIB8 can have an impact on new calls, existing calls, and
incoming HO calls.
Note: Modifying the period of the following IEs (e.g. sib8SchedulingClass parameter
or the associated target periodicity parameter in the eNB configuration) is not subject
to system information change notifications or modification of the SIB1 value tag:
- cdma2000-SystemTimeInfo (SIB8)
- oneXRTT-LongCodeState (SIB8)
- any IE of SIB11 (not currently supported)
- transmission or cessation of transmission of of SIB12 (for CMAS).
Page 80/289
4.7 COMMERCIAL MOBILE ALERT SYSTEM

Feature 92127 supports introduction of the Commercial Mobile Alert System (CMAS)
for use with the LTE FDD system. UE requirements to support this service can be
found in Reference [R07]. This system is sponsored by the FCC in the United States
under the “Warning, Alert and Response Network” or WARN Act which was passed in
1996. CMAS provides a mechanism for distributing three types of alerts to wireless
(including LTE) subscribers:
Presidential Alerts
Imminent Threats (typically weather-related)
Child Abduction Emergency / AMBER Alerts
Presidential Alerts must be transmitted to all subscribers, but subscribers can opt-out
of receiving other types of alerts.
The availability of Feature 92127 is controlled by Feature Licensing (see Volume 1 for
additional detail on Feature Licensing).
General characteristics of the service are summarized below:
• Warning Notifications are broadcast to multiple users simultaneously with
no acknowledgement required.
• The network must support concurrent broadcast of multiple Warning
Notifications.
• Warning Notifications are broadcast to a Notification Area based on
geographical information specified by the Warning Notification Provider.
• Text alerts are mandatory, with a maximum of 90 English characters.
• UEs are required to support text display, distinct vibration cadence and
audio attention signals, as a means for distributing the CMAS alert
messages to the CMSP’s (Commercial Mobile Service Provider) subscribers.
• Warning notifications to the user are broadcast using signaling messages,
and, thus, they do not preempt an active data session.
Figure 18 provides an overview of the functional architecture and interfaces of the

CMAS application within the LTE system.
Alert CMSP
Gateway Gateway CBC MME E-UTRAN
SBc S1-MME LTE-Uu
Figure 18 : Warning System Architecture for CMAS (LTE View)
The Alert Gateway provides the source of alert messages, and it is expected to be
operated by a government agency. It interfaces with multiple Commercial Mobile
Service Provider (CMSP) Gateways. The CMSP Gateway for a specific service
provider serves as the interface to a provider’s network. Within the network, the Cell
Broadcast Center (CBC) determines the affected network elements for CMAS alerts,
and manages the transmission and retransmission of the alerts that are received by
the CMSP Gateway. Only the interface to the LTE carrier network is within the scope
of Feature 92127. In ALU’s implementation, the 5140 Broadcast Management Center
(BMC) provides both the CMSP Gateway function, and the CBC function.
Page 81/289
The MME selects the appropriate eNBs based on information provided by the CBC for
the purpose of CMAS message distribution and forwards these messages to the
selected eNBs. The eNB transmits and re-transmits CMAS notifications over the air
interface based on information provided by the CBC. The eNB uses RRC Paging to
alert CMAS-capable UEs of the presence of CMAS notification broadcast(s)
information.
The remainder of the description will focus on the effects of CMAS on the
eNB/eUTRAN. Two principal capabilities are added to the eNB to support the CMAS
feature:
• S1-AP enhancement to receive and respond to CMAS warning notification
from the MME – support the read/write procedure for CMAS related
messages, and a Kill Procedure (defined in Reference [R11])
• Air interface modifications to support the delivery of CMAS alerts to CMAS-
capable UEs including:
o creation of SIB12 to carry CMAS messages
o scheduling SIB12 transmission, retransmission, and stopping
o indication of SIB12 scheduling in SIB1
o paging enhancement to indicate the presence of CMAS message(s) in
SIB12
When the eNB receives a CMAS notification message, the eNB:
• determines the affected cells from the notification list in the message,
• For each affected cell

• schedules the transmission of SIB12,
• indicates the scheduling of the SIB 12 in SIB1,
• prepares SIB12, which contains the CMAS notification
message, and
• begins transmitting SIB12 on the schedule indicated and
• then it inserts an indication of the presence of the CMAS alert in
each paging message,
Note that multiple CMAS notifications can be sent sequentially, and that CMAS
notification messages can be split and transmitted in different SIB12 messages.
Feature 134392 (CMAS Evolutions) provides additional capabilities for CMAS
broadcast. These improved capabilities are:
• When an eNB receives a request to broadcast a CMAS alert on a cell is in a
state that does not allow CMAS broadcast (e.g., the cell is locked, disabled, or
barred) then the eNB will store the request, and, if the cell becomes available
during the broadcast window, then the eNB will broadcast the alert for the
remainder of the broadcast window.
Page 82/289
• The second capability added by this feature is to include additional

information in the notification that is raised by the eNB when the broadcast is
completed. The additional information includes:
o The CMAS Alert Identifier (Message Identifier plus serial number)

o The CMAS Alert (message content)
o The number of broadcasts requested and the repetition period
o The time at which the broadcast was started and the time at which the
broadcast completed
o The list of cells on which the broadcast was requested, and how the
list of cells was determined from the Warning Area List (e.g., how
Tracking Area or Emergency Area ID list was mapped to cells)
o The list of cells on which broadcast was achieved, and the number of
broadcasts that were performed.
Feature 134392 does not add any new configuration parameters.
4.7.1 CMAS PARAMETERS

The CMAS Feature (92127) adds three parameters:
• An Enb level activation parameter, isCmasEnabled that allows the CMAS
feature to be activated for the eNB. Note that a feature licensing token must
be available for the feature at SAM before the value of this parameter can be
set equal to “True”.
• An LteCell level parameter that provides an emergencyAreaIdList for the
emergency areas that are supported by the associated cell [R11]. When a
CMAS notification is received from the MME, it will normally include a
WarningAreaList. Only cells where an entry in the emergencyAreaIdList
matches an entry in the WarningAreaList received from the MME will
broadcast the CMAS notification. If no WarningAreaList is received from the
MME, the eNB will broadcast the CMAS notification on all of its cells.
Depending on agreements between the emergency center operator and the
carrier, the WarningAreaList contain one of three types of data:
- an emergencyAreaIdList,
- a trackingAreaListforWarning,
- or a cellIDList
• A scheduling class for SIB12 – see Section 4.4.1 for information about this
parameter.
Page 83/289
isCmasEnabled: This parameter enables or disables the Commercial Mobile Alert

Service (CMAS)
ActivationService::isCmasEnabled
Parameter isCmasEnabled
Object EnbEquipment/Enb/ActivationService
True, False
Value False
Feature L92127
emergencyAreaIdList: This parameter defines the Emergency Area Identity List

associated to the cell for Public Warning Systems purposes.
LteCell::emergencyAreaIdList
Parameter emergencyAreaIdList
Range & Unit Comma separated list of up to 16 integers
Range of (each integer) 0 to 16777215, step 1
Value <Unset>
Feature L92127
Rule: emergencyAreaIdList parameter
This is a required parameter, and at least one value must be provided in the list, even
if the associated feature is not activated.
On the S1 interface between the MME and the eNB (and the SBc interface between
MME and the CBC), there are three ways in which the broadcast area can be defined:
• as a list of cells
• as a list of TAs
• As a list of Emergency Areas.
The method used will be determined between the operator and the emergency service
provider. The Emergency Area has been created to have an operator independent
identifier that can be used to broadcast a CMAS warning across several operators’
networks. To handle different granularities of broadcast areas, different Emergency
Page 84/289
Areas can be defined as city wide, county wide, state wide, regional, etc. This results
in the need for each cell of an eNB to be part of multiple (up to 16) Emergency Areas.
4.8 CELL RESET AND LOCK/UNLOCK

A cell reset will consist in triggering a modem board reset. All calls are properly
released, and the cell is unavailable for the duration of the modem board restart and
subsequent cell setup procedure.
When the cell is locked, all calls are released and the modem board is reset. Once the
modem board has restarted, the cell will not be setup until the unlock command has
been issued. During the period between cell lock and cell unlock, the cell does not
process calls or generate control channels.
The cell administrative state (which can take values Locked and Unlocked) is
managed by the ENB and OAM chain. This administrative state is preserved through
an eNB restart, so that a cell that has been locked remains locked after the eNB
restart.
4.9 FAILURE CASES
4.9.1 CELL SETUP FAILURE

Cell setup may fail, either because the modem board is not responding or is failing to
perform the cell setup procedure. In this case the managed object LteCell's state is
changed to Disabled/Failed.
If the modem board is not responding, a critical alarm is raised by CallP and this
triggers a modem reset. When the modem has restarted, the cell setup procedure is
attempted again.
If the cell setup procedure fails in the modem board, it will raise a critical alarm which
will trigger its own reset. When the modem has restarted, the cell setup procedure is
attempted again.
4.9.2 MODEM FAILURE

In the event of a modem failure (in other words a reset), the state of managed object
LteCell is changed to Disabled/Dependency. All established calls are released: RRC
resources are locally released (in other words no RRC message exchanges occur)
and the MME is notified via a UE Context Release Request message.
If cell setup failure occurs and there is no associated sector or modem failure, then the
state of the LteCell would be Disabled/Failed. Examples of the unusual situations that
might cause such a failure are the presence of an invalid configuration parameter and
a software anomaly for which there is no defense mechanism (e.g., a board reset has
been performed, but the error persists).
Page 85/289
4.9.3 CELL RECOVERY DUE TO LOSS OF S1

SERVICES
After successful cell setup, if S1 service (availability/ connectivity) on the last S1 link is
lost from either the eNB side or MME side due to faults or customer OAM actions,
UEs in the eNB coverage area that attempt calls will keep failing unless some
recovery action is taken by the eNB.
When the last S1 link is lost, the eNB starts a timer with duration controlled by the
value of the Enb::cellBarringHysteresisTimer parameter. If the timer expires without
S1 link recovery, the eNB initiates recovery action (see below). Once recovery action
is triggered, the eNB ceases to handle any calls including emergency calls.
• cellBarringHysteresisTimer : This parameter specifies the time to wait (in

seconds) before eNodeB triggers recovery action after loss of S1 services.
Enb::cellBarringHysteresisTimer
Parameter cellBarringHysteresisTimer
Range & Unit Integer, seconds
[1 to 60] step = 1
Value Default: 10 seconds
Feature L97933 L115217
If the cell barring hysteresis timer described above expires, either of two different
actions is possible depending on the value of parameter
isTurningRadioOffOnS1FailureEnabled:
1. If parameter isTurningRadioOffOnS1FailureEnabled value = “False”, then
the eNB will declare all of its cells as “barred” (changing LteCell::cellBarred
=‘barred’ in SIB1). The eNB performs self-triggered cell barring by utilizing
the DSIM/ CNP procedure (see Section 4.5). Once cell barring is triggered,
the eNB ceases to handle any calls, including emergency calls. The S1 Links
Outage Cell Shrink capability that is described in Section 4.9.3.1 may also be
activated (depending on the value of parameter
cellShrinkForS1LinksOutage) to reduce the downlink power levels.
If parameter isTurningRadioOffOnS1FailureEnabled value = “True”, then
the eNB will deconfigure all of its cells (which discontinues all RF
transmission) after the timer whose duration is determined by parameter
radioOffHysteresisTimer (See description later in this section) expires.
Either approach allows UEs in the vicinity of an eNB with no operational S1 links to
select neighbor LTE cells on the same frequency or other inter-RAT service (if
available). This decreases the service impact and corresponding KPI degradation.
Page 86/289
ActivationService::isTurningRadioOffOnS1FailureEnabled
Parameter isTurningRadioOffOnS1FailureEnabled
Boolean
Range & Unit True or False
Value O.D. Default value = False

Feature
Inter-Release Delta: isTurningRadioOffOnS1FailureEnabled Parameter
In previous releases, the functionality of this parameter was controlled by the use of the
Enb::spare11 parameter, bit 1.
In release LR13.1, a new parameter is introduced that is called the

radioOffHysteresisTimer. The equivalent capability was provided using a spare
parameter in release LA6.0. The radioOffHysteresis timer is started when all S1 links
have failed (at the same time that the cellBarringHysteresisTimer that is described in
earlier in this Section is started. If the radioOffHysteresisTimer expires and parameter
isTurningRadioOffOnS1FailureEnabled value = “True”, then the RF will be shut
down for all cells on the eNB.
Enb::radioOffHysteresisTimer
Parameter radioOffHysteresisTimer
Integer
Range & Unit 1 to 60 seconds
Value Default = 1 second (Capability is disabled)

Feature
Inter-Release Delta: radioOffHysteresisTimer Parameter
In previous releases, the functionality of this parameter was controlled by the use of the
Enb::spare11 parameter, bits 2-7.
Page 87/289
Rule: radioOffHysteresisTimer parameter
If the value of parameter isTurningRadioOffOnS1FailureEnabled = “False”, then

parameter radioOffHysteresisTimer is not used.
The recommended value of the radioOffHysteresisTimer parameter depends on the

values of the cellBarringHysteresisTimer and the cellShrinkForS1LinksOutage
parameters. As a result, an engineering recommendation is provided in the next
section after the cellShrinkForS1LinksOutage parameter has been discussed.
4.9.3.1 CELL SHRINK FOR S1 LINKS OUTAGE
The Cell Shrink for S1 Links outage capability is provided as one of a series of
dynamic coverage management with cell shrink capabilities when specific events
occur. The other capabilities are described in Section 8 of this document. When all S1
links have failed, this capability reduces the reference signal power in the downlink.
The reduction in reference signal power should be configured such that the reduced
reference signal power ensures that
(a) Connected UEs in the edge of neighbor cell(s) reduce sending measurement
reports for intra-LTE HO to this cell;
(b) Edge UEs previously served by this cell in the coverage overlapping area
now get LTE service from neighbor cell(s).
When all S1 links fail, reference signal power reduction (cell shrink) capability can be
activated after cell autobarring becomes active. The parameter associated with the S1
link outage cell shrink capability is the
DynamicCoverageMgmt::cellShrinkForS1LinksOutage parameter.
Note that the S1 link outage cell shrink capability can be an alternative to or it can
work in conjunction with the capability that uses
isTurningRadioOffOnS1FailureEnabled that is described in Section 4.9.3. See the
discussion there for additional detail.
cellShrinkForS1LinksOutage: This parameter specifies an offset from
referenceSignalPower that is applied to minimize cell coverage when the cell is auto
barred due to S1 links outage where existing calls are locally released and outgoing
HOs are not possible.
Page 88/289
DynamicCoverageMgmt::cellShrinkForS1LinksOutage
Parameter cellShrinkForS1LinksOutage
Object ENBEquipment/Enb/LteCell/DynamicCoverageMgmt
Integer
Range & Unit 0 to 30 dB, step 1

Feature L115217
Restriction: cellShrinkForS1LinksOutage parameter
The value of the cellShrinkForS1LinksOutage parameter should be such that

referenceSignalPower minus cellShrinkForS1LinksOutage
>= minRefSigPower (see Volume 4 [Vol. 4] for a discussion of the
minRefSigPower parameter)
The cell shrink capability does not apply to the Metro Cell in release LR13.1. As
a result, the value of parameter cellShrinkForS1LinksOutage should be
set to 0 dB.
Page 89/289
Engineering Recommendation: cellShrinkForS1LinksOutage parameter

value
The value of the cellShrinkForS1LinksOutage parameter is dependent on

frequency, bandwidth, downlink power, number of antennas, and other factors.
The upper bound value to be used is determined from the following relationship:
In a typical case, cellShrinkForS1LinksOutage =referenceSignalPower –
minRefSigPower = the maximum dynamic range of referenceSignalPower.
referenceSignalPower is set to maxRefSigPower in the power configuration
specific Template.
If referenceSignalPower is changed to a smaller value, the upper bound of

cellShrinkForS1LinksOutage cannot exceed referenceSignalPower –
minRefSigPower.
Values of the referenceSignalPower and minRefSigPower parameters for the
various conditions are provided in [Vol. 4].
Depending on whether the type of RF Module of the cell supports "EDPD
bypass" or not, an RFM Signal Quality alarm (IK4006014) may be raised as a
result of referenceSignalPower change to the minimum (reduced by 30 dB) when
all S1 links are lost. Since referenceSignalPower is proportional to total Tx power
and output linearization for high fidelity of signal is not needed when the Tx
power is reduced by (up to) 30 dB, the alarm may be ignored if the goal is to
eliminate inter-cell interference when all S1 links are lost. Alternatively, the
configurable offset value of cellShrinkForS1LinksOutage can be set to a
smaller value (for example, 15 dB) to avoid the alarm in the S1 link outage
scenario (at the expense of a certain level of inter-cell interference).
Engineering Recommendation: Relationship of radioOffHysteresisTimer

parameter value to isTurningRadioOffOnS1FailureEnabled,
radioOffHysteresisTimer, cellShrinkForS1LinksOutage,
cellBarringHysteresisTimer parameter values
Assuming that the value of parameter

isTurningRadioOffOnS1FailureEnabled is True, then the recommended
value for the radioOffHysteresisTimer parameter is determined by the value
of the cellShrinkForS1LinksOutage parameter and the value of parameter
cellBarringHysteresisTimer as described bleow:
o If the value of parameter cellShrinkForS1LinksOutage = 0, then the
value of the radioOffHysteresisTimer parameter should be equal to
the value of the cellBarringHysteresisTimer parameter + 5 seconds.
o If the value of parameter cellShrinkForS1LinksOutage is not equal
to 0, then the value of the radioOffHysteresisTimer parameter
should be equal to the value of the cellBarringHysteresisTimer
parameter + 10 seconds.
If the value of parameter isTurningRadioOffOnS1FailureEnabled is False,
Page 90/289
then the value of the radioOffHysteresisTimer parameter is not used.
The use of the four parameters together:
• Enb::cellBarringHysteresisTimer to determine the length of time before

recovery action is initiated. Example value = 10 seconds (default)
• cellShrinkForS1LinksOutage (to shrink the cell when the cell is
autobarred because of failure of all S1 links). Example 10 dB.
• isTurningRadioOffOnS1FailureEnabled (to shut down the RF when the
radioOffHysteresisTimer expires). Example value = True.
• radioOffHysteresisTimer to set the duration of the
radioOffHysteresisTimer. Example value = (value of
cellBarringHysteresisTimer parameter + 10 seconds) = 20 seconds (should
be longer than cellBarringHysteresisTimer value.)
Using these values, the duration of the radioOffHysteresisTimer will be 20 seconds.
Assume that at time T=0, a failure of all S1 links occurs and all links are down for more
than 20 seconds.
• Both the cellBarringHysteresisTimer and the radioOffHysteresisTimer will
be started at time T=0
• At time T = 10 seconds, the cellBarringHysteresisTimer will expire. At that
time all of the eNB’s cell’s downlink power will be reduced by 10 dB (the value
of the cellShrinkForS1LinksOutage parameter) causing edge UEs to attach
to neighbor cells, and autobarring will cause “cell barred” to be broadcast in
SIB1 for all of the eNB’s cells.
• At time T = 20 seconds, the radioOffHysteresisTimer will expire, and the
eNB will deconfigure all of its cells which discontinues all RF transmission. All
remaining calls will be dropped, causing mid- and near-cell UEs to attach to
neighbor cells.
• The end result: The attach attempts in neighbor cells and associated
messaging in the EPC are spread over time, with a first spike after T=10 sec
and 2nd spike after T=20 sec.
As described in Section 4.9.3, recovery action will be initiated when at least one S1
link returns to service.
4.10 INTERACTIONS WITH OTHER FEATURES

At ENB startup, at least one S1 link must be operational (in other words, at least one
MmeAccess instance must be Enabled/None) for the cell setup procedure to be
initiated. S1 link availability can therefore be seen as a pre-condition to the cell setup
and system information broadcast procedure.
Page 91/289
However if all S1 links fail at a later stage (once the cells have been set up and the
system information is being broadcast), the recovery action that is described in
Section 4.9.3 is employed.
4.11 OBJECT STATE MANAGEMENT

During the Cell setup, the following states changes of the LteCell MO are sent to
OMC:
Meaning LteCell MO states attributes

(operational/availability)
Supporting hardware is not available Disabled/Dependency
Sector and a modem are available and cell setup Disabled/(None)
can start
Cell setup is successful and the System Enabled/(None)
Information is broadcast. Cell is not barred.
Cell setup has failed Disabled/Failed
Cell is locked Disabled/Off line
Cell is barred (refer to section 7.5.1.2.1 for details) Enabled/ Off-duty
Table 8 : LteCell State Management
Page 92/289
LteCell Cell is locked LteCell

Disabled
(any state)
Off line
Cell is unlocked and modem is not available
Cell is unlocked and modem is available: cell setup may begin
Cell initial state
LteCell
Disabled
Dependency Sector and modem
A sector and modem become become unavailable
available: cell setup may begin
Sector and modem

become unavailable
Sector and modem
LteCell become unavailable
Disabled Sector and modem LteCell

become unavailable
(None) Disabled
Cell setup fails Failed
Cell setup is successful and LteCell

System Information is broadcast (cell not barred)
Enabled
(None)
Cell is barred Cell is unbarred

Cell setup is successful and
System Information is broadcast (cell barred by operator)
LteCell
Enabled
Off duty
Figure 19 : LteCell State Diagram
After successful cell setup the eNB can self-trigger cell barring (refer to section 4.9.3 ),
and transition the state LteCell state to “Enabled/ Off-duty”.
When no S1 link is operational during the cell setup, the cell will first be changed from
“Disabled/None” to “Enabled/None”. The cell starts radiating and Sys Info is broadcast
while S1 links setup is still in progress. After timer expiry, if no S1 link is operational,
the cell will be autobarred by eNB and becomes “Enabled/Off duty”.
Page 93/289
5 S1 MANAGEMENT
The S1 management consists of:
- S1 SCTP association setup procedure.
- S1-AP S1 setup procedure described in this section.
- S1-AP MME configuration update.
• eNBname : 3GGPP 36.413: This is the name of the eNB transmitted by the eNB
to the ePC in the S1-AP procedure[R11]
Enb::eNBname
Parameter eNBname
Range & Unit String
MinimumLength = 1
Maximum Length = 150
Value O.D.
Feature
Rule: eNBname
ALU recommends that the value of the eNBname parameter be limited to 28 characters
for new installations.
Restriction: Take care about the characters for eNBname

The eNBname must not contain any of the following characters
"#$%&*;<>@[\]^`{|}~!
Because they are not supported.
The eNBname character set for PrintableString is:

A, B, ..., Z
a, b, ..., z
0, 1, ..., 9
' ( ) + , - . / : = ?_
Page 94/289
5.1 S1 FLEX CAPABILITY

S1 Flex describes the ability for the ENB to be connected to more than one MME.
Currently, the eNB can connect to up to 16 MMEs.
When the ENB is connected to several MMEs, it must select one MME to establish an
S1 link for a given UE.
The MME selection process is based on information elements that are dynamically
received from the MMEs and the UE (in other words they are not configured):
- The relative MME capacity (mandatory information element RelativeMMECapacity
received in S1 Setup Response), which is typically set according to the capacity of an
MME node relative to other MME nodes ([R01]). This relative capacity is coded as an
integer in the 0 to 255 range and not as a percentage, in order to avoid having to
update all the relative capacities when a new MME is introduced into the network.
“Relative MME capacity = 0” (see MME Configuration Update in Section 5.3) means
some OAM action was taken on the MME (e.g. for maintenance) and ALU MME will,
over a time window, gradually release RRC Connected UEs (not in emergency calls)
by sending UE Context Release Request messages to the UEs via the eNB with the
Cause IE set to 'Load Balancing TAU Required'; the affected UEs send TAU in
response. A different MME (if available) is then selected. Other vendor’s MME may
or may not do this.
- The identity of the MME to which a UE was previously registered (mmec in optional
information element S-TMSI received in RRC Connection Request or optional
information element registeredMME received in RRC Connection Setup Complete). If
a UE is currently registered in the Tracking Area of the cell it is attempting to access, it
must provide its S-TMSI which contains the MME Code in the RRC Connection
Request; the ENB shall then establish the S1 link for this UE with the MME identified
by the MME Code. If a UE is currently not registered in the Tracking Area of the cell
but has previously been registered to a given MME when in the same Tracking Area
as the cell it is camped on, it must provide this information in the RRC Connection
Setup Complete through the registeredMME; the ENB must then establish the S1 link
for this UE with the MME identified by the GUMMEI contained in registeredMME. If the
ENB is unable to match an MME with the MME Code or the GUMMEI, it will initiate an
MME selection based on the relative MME capacity of the MMEs it is connected to.
- PLMNs that are served by each MME (provided in the S1 Setup response or an
MME configuration update), and PLMN that has been selected by the UE (provided by
the UE in the RRC Setup Complete Message. If the UE has not previously registered
with an MME, then MMEs that do not serve the UE-selected PLMN will be filtered out
of the candidate list.
When the ENB is connected to several MMEs, the S1 Setup procedures will be
triggered as soon as the SCTP association for each MME is available, and may
therefore happen in parallel. They may also run in parallel to X2 Setup procedures.
The relative MME capacity received during the setup procedure will be stored for
future use at call establishment,
Once an S1 connection is set up successfully and System Info broadcasting starts,

calls can be setup through the S1. S1 links can subsequently be lost due to various
Page 95/289
reasons. If the last S1 connection on the eNB is lost, the eNB triggers cell-barring as
described in Section 4.9.3. When any S1 link is recovered, the cells are un-barred
• plmnId: This parameter refers to the instance of PlmnIdentity object that defines
the MCC and MNC of the concerned PLMN for the MME. See Section 4.1.1.1 for
additional discussion of the PlmnIdentity object.
MmeAccess::plmnId
Parameter plmnId
ENBEquipment/Enb/S1AccessGroup/MmeAccessGroup/Mm
Object
eAccess
Service Link
Range & Unit Points to corresponding instance of the PlmnIdentity object
Class/Source B--S1-interface / customer_init
Value O.D.
Feature L114383, L104835
5.2 S1-SETUP
The S1 SCTP association must be successfully set up, either at eNodeB startup or
following an S1 link failure. This is described in Transport Engineering Guide [R15]
The purpose of the S1 Setup procedure is to exchange application level data needed
for the eNB and MME to interoperate correctly over the S1 interface.
ENB MME
S1 SCTP Association is set up
S1 SETUP REQUEST
Global eNB ID
eNB Name
Supported TAs (1 to 256)
>TAC
>Broadcast PLMNs (1 to 6)
>>PLMN Identity
S1 SETUP RESPONSE
MME Name
Served PLMNs (1 to 32)
>PLMN Identity
Served GUMMEIs (1 to 256)
>GUMMEI
Relative MME Capacity
ENB MME
Figure 20 : S1 Setup Success
The eNB initiates the procedure by sending a S1 SETUP REQUEST message

including its own configuration data to the MME. This message shall be the first S1AP
Page 96/289
message sent after the TNL association has become operational, i.e. the S1 SCTP
association is successfully setup.
The MME responds with S1 SETUP RESPONSE including its own configuration data.
The received data shall be stored in the eNodeB and used for the duration of the TNL
association. It may be updated by a subsequent MME Configuration Update
procedure. It shall not be erased during a Reset procedure. When this procedure is
finished, S1 interface is operational and other S1 messages can be exchanged; in
particular, calls can be set up.
The maximum number of Served GroupIDs and Served MMECs are defined in
standard with values respectively 65536 and 256.
To avoid memory consumption, the ENB will limit the number of saved information
to 16 Served GroupIDs and 16 Served MMECs. In LTE networks, one MME
should support only one GroupID and one MME code. The potential issue is with
configuration data received for other RATs (2G or 3G) which may exceed our design
values. If more than 16 instances of Served GroupIDs and Served MMECs are
received, they will be ignored by ENB, only the first ones will be stored by ENB.
In case there is at least one X2 instance setup already, on reception of a S1 Setup
Response message from a MME, an ENB will compute the GU Group ID List .
• s1APProcedureDefenseTimer: This eNB internal defense timer is used to monitor

the non answer from the MME in case of any S1-AP procedure. The timer is
started in the eNB at message transmission and stopped at response message
reception from the MME. At timer expiry the procedure is failed.
Enb::s1APProcedureDefenseTimer
Parameter s1APProcedureDefenseTimer
Range & Unit Integer in ms
[50..30000] Step = 10
Value 3000
Feature
Page 97/289
5.3 MME CONFIGURATION UPDATE

The purpose of the MME Configuration Update procedure is to update application
level configuration data needed for the eNB and MME to interoperate correctly on the
S1 interface. This procedure doesn’t affect existing UE-related contexts, if any.
ENB MME
MME CONFIGURATION UPDATE

MME Name
Served GUMMEIs (1 to 8)
>Served PLMNs (1 to 32)
>>PLMN Identity
>Served GroupIDs (1 to 16)
>>MME GroupID
>Served MMECs (1 to 16)
>>MME Code
Relative MME Capacity
MME CONFIGURATION UPDATE ACKNOWLEDGE

ENB MME
Figure 21 : MME Configuration Update Success
The MME initiates the procedure by sending a MME CONFIGURATION UPDATE

message including the appropriated updated configuration data to each of the eNBs
currently connected with it.
The eNB responds with MME CONFIGURATION UPDATE ACKNOWLEDGE
message to acknowledge that it has successfully updated the configuration data.
The received data will be stored in the eNodeB and used for the duration of the TNL
association until reception of a new MME Configuration Update message. It will not be
erased during a Reset procedure.
If some information element(s) is/are not included in the MME Configuration Update
message, the eNB will infer that the corresponding configuration data is not changed
and will continue to operate the S1 with the existing related configuration data.
Page 98/289
The following configuration data can be updated:

- MME Name : if present it will be stored by the eNB and used as a human
readable name of the MME, e.g. for alarms.
- Served GUMMEIs : the eNB will store the Served GUMMEIs and use the
first on the list for L97982 purpose. Per June-2009 36.413 the first on the list relates
to LTE configuration pool and the rest relate to 2G/3G pools (for example if a UE was
in 3G connected to a pool of "combined" 3G SGSN/ MME and then moves to LTE,
eNB would select the same combined node if possible). The eNB shall compute the
GU Group Id List based on the GUMMEI information received from the MME
- Served PLMNs – in case the list is updated, then the update will be used for
subsequent calls, but will not affect existing calls.
- Relative MME Capacity : the new MME Capacity received from MME will be
stored by the eNB.
In case there is at least one X2 instance setup already, on reception of a MME
Configuration Update message from a MME, an ENB will compute the GU Group ID
List
It’s possible that the Relative MME Capacity is changed to a lower value or even to 0.
• For new calls, the new Relative MME Capacity info will be taken into account
in MME selection;
• For existing calls, the MME can take Call Admission Control (CAC) action
• For S1-based HOs, if Source MME picks a Target MME with "Relative MME
Capacity" = 0 or a capacity too low to handle the HO, it will be up to the Target MME
to decide whether to reject the HO (e.g. do not send "HO Request" message to the
Target eNB). On the other hand, if the Target eNB receives an HO Request message
from an MME (with or without MME relocation), it will respond to the message and let
the MME decide whether to reject the HO or not.
The configuration received for non supported PLMNs will be ignored by ENB
5.4 MME SELECTION

In the case where several S1 links to MMEs are configured, the ENB is expected to
dispatch UEs to the specific MMEs to which they are registered, or to select an MME
to which they will register when they haven't previously done so. In this later case, the
selected MME must support the PLMN provided by the UE.
A UE which has previously registered with a given MME covering the Tracking Area
in which the UE is currently positioned will indicate this by including optional
information Element registeredMME in the RRC Connection Setup Complete
message it sends to the ENB. In this case, the ENB will attempt to match the
registeredMME with an MME identity in the list of GUMMEIs received during S1
Setup procedure.
If no match is found, the ENB will initiate MME selection as described hereafter; if a
match is found, the ENB will direct the call establishment to the matched MME.
If the S1 link of the matched MME is down (as indicated by a state different than
Enabled/None for the MmeAccess object of the matched MME), the eNB will initiate
MME selection. If one or more MMEs with matching PLMN are found, the eNB will
direct the call establishment to another MME that supports the PLMN. If no match is
Page 99/289
found, then the call will be released through an RRC Connection Release (using
cause "other").
The ENB maintains a list of the GUMMEI (Globally Unique Mobility Management
Identity) received during the S1 Setup procedures. Associated to each MME is a
relativeMMECapacity also received during the S1 Setup procedure. When the ENB
must perform MME selection for a given UE, it establishes the list of eligible MMEs.
This list consists of all the MMEs for which the S1 link is operational (an S1 link is
considered operational when an S1 Setup procedure has been successfully
completed; MmeAccess managed object is in the state Enabled/None) and one of the
PLMNs provided by the MME matches the PLMN provided by the UE. To perform
MME selection, the ENB first computes the totalMmeCapacity by summing the
relativeMmeCapacity of all the eligible MMEs. It then randomly draws a number
between 1 and totalMmeCapacity. Each MME has a selection range, which starts at
one plus the sum of the relativeMMECapacity of all the MMEs preceding it in the list
of eligible MMEs, and ends at the sum of relativeMMECapacity of all the MMEs
preceding it in the list and of its own relativeMmeCapacity. In this manner, the
randomly drawn number falls within a unique MME selection range, and the ENB has
then performed its MME selection. It then pursues normal call establishment towards
the selected MME.
Feature 115665.1 (MME Overload Indication Support) provides the capability for an
MME to indicate an overload condition to a subset of the eNBs that it supports, in
order to reduce traffic.
When an overload condition occurs on the MME, it sends an OVERLOAD START
message to a randomly selected subset of the eNBs with which it has S1 interface
connections. The message contains an overload action IE that indicates the overload
level (type of traffic that the MME wants to stop). Currently the MME only supports the
the overload action, “only permit RRC connection establishment for emergency
sessions and mobile terminated services”.
When an eNB receives the OVERLOAD START message, it stores the MME’s
overload level, and discontinues selecting that MME for new incoming UEs (for
prohibited traffic types). The eNB ensures that only signaling traffic related to
permitted traffic types is sent to an overloaded MME.
Mobile terminating traffic is not affected by this feature, since it is in reaction to MME
initiated action (and, thus, the assumption is that the MME is able to respond to the
resulting signaling messages). Also, handover is not affected by this feature.
When the overload condition at the MME subsides, the MME gradually sends
OVERLOAD STOP messages to the affected eNBs. When the OVERLOAD STOP
message is received by an eNB, then it immediately resumes sending signaling
messages that are associated with all traffic types to the corresponding MME.
Two configuration parameters are associated with Feature 115665.1. They are:
• tOverload – a UE timer value that defines the length of time that a UE must
wait before re-originating prohibited traffic that is associated with an
overloaded MME (see Section 7.5.1.3.1 for additional detail.)
Page 100/289
• overloadCallRejectNotAllowed – the setting of this parameter determines

whether the eNB uses a non-standard approach to direct signaling traffic from
a UE away from an overloaded MME (see Section 7.5.1.3.1 for additional
detail.)

S1 management has interactions with cell setup, call setup and inter-ENB handover:
- Cell setup interactions: cell setup is triggered only when at least one S1 link
becomes operational (at least one MmeAccess managed object is in state
Enabled/None).
- Call setup interactions:
- When all S1 links are not operational (all MmeAccess managed objects are in
a state different from Enabled/None), RRC connection attempts are rejected
using RRC Connection Reject message
- Inter-ENB handover interactions:
- When all S1 links are not operational (all MmeAccess managed objects are in
a state different from Enabled/None), incoming X2 Handover Requests are
rejected using Handover Preparation Failure
- When the S1 link to the MME designated by the GUMMEI information element
in the X2 Handover Request is not operational, the ENB rejects the handover
request using Handover Preparation Failure

During the S1 setup, the following states changes of the S1 associated
TransportLayerAccess MO, MmeAccess MO and MmeAccessGroup MO are
reported to OMC:
Meaning MmeAccess MO states attributes

(operational/availability)
MmeTransportLayerAccess (SCTP association) is Disabled/Dependency
not enabled
SCTP association is up, and S1 Setup Request has Disabled/(None)
been sent
S1 SCTP association is up, and S1 Setup Failure Disabled/Failed
has been received or no answer received to
several S1 Setup Request
S1 setup procedure is successful Enabled/(None)
S1 link is locked (through MMEAccess Disabled/Offline
administrativeState)
Table 9 MmeAccess State Management
Page 101/289
Trigger: MMEAccess is locked

MMEAccess
MMEAccess MA7 Disabled
Offline
(any state)
MA4 Trigger: MMEAccess is unlocked
Trigger: MMETransportLayerAccess leaves state Enabled / None MA8
MMEAccess
Disabled
Trigger: MMETransportLayerAccess becomes Enabled / None
Dependency
Action: S1 Setup Request sent to MME
MA1
Trigger: No response to S1 Setup Request or S1 Setup Failure received

Action: wait before sending next S1 Setup Request
MA3
MMEAccess
MMEAccess Disabled
Disabled MA5 Failed
(None)
Trigger: S1 Setup Response received from MME MA6
No response to S1 Setup Request
or S1 Setup Failure received
Trigger: S1 Setup Response received from MME
MMEAccess
MA2
Enabled
(None)
Figure 22 : MMEAccess State Diagram
State transitions have been numbered (MAG1, MAG2, etc.) to facilitate cross-
referencing in this and other documents. In the diagram above, transition MA6 differs
from the other transitions in that no state change is generated. The idea is that once
the first state change to Disabled/Failed has been sent, if the S1 setup continues to
fail repetitively (through no response to S1 Setup Request or reception of S1 Setup
Failure), the ENB will not repeat the state change. This avoids duplicating events
unnecessarily and flooding the OAM.
Page 102/289
6 X2 MANAGEMENT
X2 Management is conditioned to the administrative state of the associated X2Access
object, to the black listing status of the associated X2Access object, and to the
availability of the X2 SCTP association. (which is described in the Transport
Engineering Guide [R15],
It is therefore completely independent of both:
• the cell setup procedure, whose status is given by the operationalState and
availabilityStatus of objects LteCell;
• the S1 interface setup procedure, whose status is given by the
operationalState and availabilityStatus of objects MmeAccess.
In the following sections, the "initiating ENB" refers to the ENB sending the X2 Setup
Request and the "peer ENB" refers to the recipient of the X2 Setup Request.
With the introduction of the ANR feature, in addition to setting up X2 links for
configured neighbor relations, the ENB is also able to:
¾ Set up an X2 link towards a neighbor ENB that was not previously
configured;
¾ Accept the opening of an X2 link coming from an unknown ENB (in this
case it is not necessary for ANR to be activated on the peer ENB). By
unknown ENB what is meant here is an ENB that was not configured as a
neighbor in the ENB's configuration file
Rule: X2 interface configuration and management
• If ANR is deactivated on two eNBs and an X2 relation needs to be

established between them, it is essential that an instance of object
X2Access corresponding to the peer eNB be generated and populated
appropriately in the configuration of one of the two eNBs.
• If ANR is activated on two eNBs, the need to establish an X2 relation will
depend on radio measurements (i.e. there is no guarantee that there will be
at least one neighbor relation between a cell hosted by the first eNB and a
cell hosted by the second eNB, as per [Vol. 6]).
Nevertheless, it is possible to enforce the X2 relation through OAM by
generating an instance of object X2Access corresponding to the peer eNB
in the configuration of one of the two eNBs (it is not essential to do the same
in the configuration of the other eNB, ANR being activated for it is enough
for both the SCTP connection establishment (see Reference [R15]) and the
X2-AP setup procedure (see description later in this section) to be
successful). Note, however, that parameter X2Access::noRemove must be
set to “True”, otherwise if no cell-to-cell neighbor relation is created between
the 2 eNBs, the X2Access instance will be removed by ANR (see [Vol. 6]).
• If ANR is deactivated on some eNB and activated on some peer eNB, the
latter can establish an X2 connection between the two eNBs, and handovers
Page 103/289
can occur.
It is also possible to enforce an X2 relation between these 2 eNBs through
OAM by generating an instance of object X2Access corresponding to peer
eNB (ANR not activated) in the configuration of the eNB with ANR activated.
It is also necessary to set parameter X2Access::noRemove to “True”, so
that ANR garbage collection cannot remove the link.
ENB ENB2
X2 SCTP Association is set up
X2AP X2 SETUP REQUEST

Global eNB ID
Served Cells (1 to 256)
> Served Cell Information
> Neighbour Information (0 to 512)
>>ECGI
>> PCI
>> EARFCN
GU GroupID List (0 to 16)
> GU Group ID
X2AP X2 SETUP RESPONSE
Global eNB ID
Served Cells (1 to 256)
>> ECGI
>> PCI
>> EARFCN
GU Group ID List (0 to 16)
> GU Group ID
ENB ENB2
Figure 23 : X2 Setup Success
Page 104/289
In the diagram above, only the Information Elements that are currently managed are
represented.
Note that the served cell information includes the PLMN IDs for each cell. The two
eNBs are not required to have consistent PLMN IDs among their cells. However, X2
handover must be between two cells that serve the same PLMN ID, otherwise, an S1
handover will be required.
Peer ENB Behaviour

The following applies to an ENB for which the ANR feature is not activated
Upon receiving the X2 Setup Request message, the peer ENB checks whether an
X2Access instance exists in the configuration data for the ENB that initiated the X2
Setup procedure. If no X2Access instance exists (or in other words if the neighbor
ENB had not been configured) the peer ENB responds with an X2 Setup Response.
The information received from the initiating ENB (in particular served cell information)
is not kept. Incoming and outgoing handovers with the initiating ENB will however be
processed normally.
If an X2Access instance exists in the MIM for the ENB that initiated the X2 Setup
procedure, the peer ENB checks the received information elements against
itsconfiguration data.
If all the neighbor cells associated in the configuration data to the initiating ENB for
which the X2 Setup Request has been received can be matched to a cell in the
Served Cells list, the peer ENB considers the setup to be completely successful and
responds with an X2 Setup Response.
Before sending an X2 Setup Response message to a peer ENB, an ENB will

compute the GU Group ID List based on the GUMMEI information received by MMEs
it is connected to and include it in the X2 Setup Response message. An empty GU
Group ID List will not prevent the X2 setup procedure from being performed.[L97982]
If at least one but not all of the neighbor cells associated in the MIM to the initiating
ENB for which the X2 Setup Request has been received cannot be matched to a cell
in the Served Cells list, the peer ENB considers the setup to be partially successful
and responds with an X2 Setup Response, while raising an alarm to notify the
mismatch in configuration.
Initiating ENB behaviour

The following applies to an ENB for which the ANR feature is not activated
Before sending a X2 Setup Request message to a peer ENB, an ENB shall compute
the GU Group ID List based on the GUMMEI information received by MMEs it is
connected to and include it in the X2 Setup Request message. An empty GU Group
ID List shall not prevent the X2 setup procedure from being performed.
Upon receiving the X2 Setup Response message, the initiating ENB checks the
received information elements against its configuration data.
If all the neighbor cells associated in the data received from the peer ENB for which
the X2 Setup Response has been received can be matched to a cell in the Served
Cells list, the X2 Setup procedure is considered completely successful.
Page 105/289
If at least one but not all of the neighbor cells in the data received from the peer ENB
for which the X2 Setup Response has been received cannot be matched to a cell in
the Served Cells list, the X2 Setup procedure is considered partially successful, and
an alarm is raised to notify the mismatch in configuration.
6.1 FAILURE CASES
6.1.1 X2 SETUP FAILURE

Peer ENB behaviour
There are two use cases for rejecting an X2 Setup procedure in the Alcatel-Lucent
implementation of the ENB.
When the X2 link is locked (through the administrative state of the associated
X2Access instance), the ENB will allow the SCTP association to be set up and reject
the X2 Setup procedure by sending an X2 Setup Failure message.
Similarly, when an X2 link has been black-listed (through the noX2 attribute of the
associated X2Access instance), incoming SCTP INIT messages will be accepted by
the ENB, but the X2 Setup procedure will be rejected by sending an X2 Setup Failure
message.
In both cases, the X2 Setup Failure will contain a Time To Wait IE set to the
maximum value (v60s) and the Cause IE will be set to "om-intervention".
If the peer ENB is in a state to do so, it may initiate an X2 Setup procedure of its own
and become the initiating ENB.
• noX2 : This flag allows or forbids eNodeB to establish the X2 link. The permitted
values are true or false. The default value is false. It is used for X2 black-listing
and X2 white-listing (see Sections 6.5 and 6.6.)
X2Access::noX2
Parameter noX2
Object ENBEquipment/Enb/ X2AccessGroup/X2Access

[false, true]
Value false
Page 106/289
• x2APProcedureDefenseTimer: This eNB internal defense timer is used to monitor

the non answer from the remote eNB in case of any X2-AP procedure. The timer
is started in the local eNB at message transmission and stopped at response
message reception from the remote eNB. If the timer expires, the procedure is
failed.
Enb::x2APProcedureDefenseTimer
Parameter x2APProcedureDefenseTimer
[50..3000] Step = 10
Value 3000
Feature
A parameter, ovLevelForX2SetupReqAction, controls the overload level (minor,

major, or critical) at which or above which any incoming X2 Setup Request messages
will be rejected.
See LPUG [Vol. 4] for additional information about overload control.
OverloadControl:: ovLevelForX2SetupReqAction
Parameter ovLevelForX2SetupReqAction
[Major, Minor, Critical]
Class/Source C--Immediate-Propagation / system_restricted
Value Critical
Feature L115241
6.1.2 X2 LINK FAILURE

X2 Link failures are detected at SCTP level and reported via a state change
notification: the underlying X2TransportLayerAccess object becomes
Disabled/Failed. The X2Access object state becomes Disabled/Dependency and
remains so while the SCTP association is down.
When the SCTP association is re-established, the ENB will trigger a new X2 Setup
procedure as specified in Section 6
Page 107/289
6.2 MULTIPLE X2 LINKS

An eNB may be connected to up to 32 other ENBs. The X2 Setup procedures will be
triggered as soon as the SCTP association for each ENB is available, and may
therefore happen in parallel. They may also run in parallel to S1 Setup procedures.
• x2AccessId: This parameter refers to the instance of X2Access MO that

represents the X2 interface link to the Neighboring cell relation
LteNeighboringCellRelation::x2AccessId
Parameter x2AccessId
Object ENBEquipment/Enb/LteCell/LteNeighboring/LteNeighboring
CellRelation/
Value BTSEquipment/W Enb/X X2AccessGroup/Y X2Access/Z
Value is a Link
Rule:
W, X ,Y,Z are the Operator Dependent values. The number of x2AccessId is limited
to 32, from 0 to 31 id.
The value of this parameter points to an instance of the X2Access object that is also
associated with the same LTE neighboring cell. As a result, the value of this service
link is not expected to be modified. If it must be modified (for example, a mistake was
made and an incorrect X2Access instance was selected for the pointer), the value
can be changed as a Class C parameter (that is, no need to lock/unlock cells).

When a target cell has been identified for an inter-ENB handover and the X2 link to
the ENB supporting that cell is not operational (managed object X2Access is in a
state different from Enabled/None), the handover may be attempted over the S1
interface if S1 handover is allowed; otherwise it is abandoned. See [Vol. 6].
With the introduction of Feature 97926, an eNB will reset the X2 interface on reception
of a reset request from the other eNB. When the X2 interface is reset, the eNB will
abort any other ongoing procedures over X2 between the two eNBs, and all X2 UE
contexts will be released. An ALU eNB will only send a reset request when
commanded by ALU personnel using a “debug” command, so an ALU eNB should not
generate an X2 interface message in commercial operation. However, it is possible
that another vendor’s eNB will send an X2 interface reset message, and the ALU eNB
will behave as described above.
Page 108/289
6.4 X2 LOCK/UNLOCK
Using SAM, an X2 link can be locked or unlocked through the administrativeState
attribute attached to X2Access object instance.
An unlocked X2 link will be established and allowed to operate (except if black-listed
or released by ANR garbage collection mechanism, refer to following chapters for
details).[L81872]
A locked X2 link will not be established.
Note: the “shuttingdown” value is not currently supported.
The following sections specify eNB behaviour on transitions from “unlock to lock” and
“lock to unlock”.
6.4.1 BEHAVIOUR WHEN LOCKING AN X2 LINK

Locking an X2 link is performed by setting X2Access administrativeState to
“locked”.
In this case, if the X2 link was established, it has to be released. As X2 SCTP
association is managed through X2TransportLayerAccess object instance being part
of the X2Access sub-tree, it will have to disabled as well.
Then, when X2 lock command is received, the eNB will shutdown the underlying
SCTP association.
As long as the X2 link is locked, the X2 link and SCTP association will not be
established.
6.4.2 BEHAVIOUR WHEN UNLOCKING AN X2 LINK

Unlocking an X2 link is performed by setting X2Access administrativeState to
“unlocked”.
In this case, given that the link is not black-listed, it will be established using the X2
setup procedure. Of course, underlying SCTP association shall be established
beforehand.
6.5 X2 BLACK-LISTING
The ANR function introduced the notion of an X2 link “black-list”, meaning that the
operator has the possibility to declare that an X2 link shall never be established by the
eNB, whatever the condition. To “black-list” an X2 Access, set the value of parameter
X2Access::noX2 to “True” for the X2Access instance that is associated with the eNB
that is to be black-listed.
In case an X2 link is black-listed, it will not be established and in case it was, it will
be released whatever its administrative state.
Page 109/289
This means black-listing will always take precedence over administrative state.
[L81872]
6.6 X2 WHITE-LISTING
ANR also introduced the notion of X2 link “white-list”, meaning that the operator has
the possibility to declare that an X2 link must always be established. To “white-list” an
X2 Access, the X2 Access must be created, and the value of the X2Access::noX2
parameter must be set equal to “False”.
In case an X2 link is white-listed, then it will then be established, unless it is
locked.
This means it will always be possible to lock an X2 link, even if it is white-listed. This is
mandatory because locking an X2 link may be needed for maintenance purpose.
[L81872]
6.7 X2 ONLINE CREATION

It is possible to create (while the eNB is online) an X2Access instance along with its
underlying X2TransportLayerAccess instance (X2TransportLayerAccess
cardinality ensures that if an X2Access instance is created, then the associated
X2TransportLayerAccess instance will also be).
eNB behaviour on X2Access instance creation will be:
- If X2 link is white-listed, it will be established
- If X2 link is black-listed, it will not be established
- If X2 link is neither white-listed nor black-listed, it will be established only if
unlocked[L81872]
6.8 X2 ONLINE DELETION

It is also possible to delete online an X2Access instance along with its underlying
X2TransportLayerAccess instance.
eNB behaviour in case of X2 link deletion will be
- If X2 link was established, it will be released through SCTP shutdown
- If it was not, it will be simply removed from the MIB. [L81872]
Page 110/289
X2Access
Disabled
XA10 Offline XA8
Trigger: X2 link is locked or blacklisted, repeated
eNB Configuration Update failure
Action: send an SCTP SHUTDOWN Trigger: X2 link is un-locked or un-blacklisted, SCTP Shutdown
following eNB Configuration Update
Action: send an SCTP INIT
X2Access X2Access initial state at
XA6 eNB start-up or at creation
Trigger: X2TransportLayerAccess leaves state Enabled / None through new neighbour
(any state) PCI discovered (ANR)
X2Access
Disabled
Trigger: X2TransportLayerAccess becomes Enabled/None
Action: X2 Setup Request sent to peer eNB Dependency
XA1
Trigger: No response to X2 Setup Request or X2 Setup Failure received

Action: wait before sending X2 Setup Request
X2Access X2Access
XA3
Disabled XA5 Disabled
(None) Failed
Trigger: X2 Setup Response received from peer eNB,
or X2 Setup Request received from
peer eNB and X2 Setup Response sent XA7
Trigger: X2 Setup Response received from peer eNB
No response to X2 Setup Request
or X2 Setup Failure received
X2Access XA4
XA2
Enabled Trigger: X2 Setup Request received from
X2Access initial state (None) peer eNB and X2 Setup Response sent
on creation through X2
SETUP REQUEST
XA12
received (ANR)
Trigger: an X2 link is not used (e.g. ANR garbage collection)
– not whitelisted or blacklisted
Action: send an SCTP SHUTDOWN
Figure 24 : X2Access State Diagram
State transitions have been numbered (XA1, XA2, etc.) to facilitate cross-referencing
in this and other documents. In the diagram above, transition XA7 differs from the
other transitions in that no state change is generated. The idea is that once the first
state change to Disabled/Failed has been sent, if the X2 setup continues to fail
repetitively (through no response to X2 Setup Request or reception of X2 Setup
Failure), the ENB will not repeat the state change. This avoids duplicating events
unnecessarily and flooding the OAM.
6.10 ENB CONFIGURATION UPDATE

The purpose of the eNB Configuration Update procedure is to update application level
configuration data needed for two eNBs to interoperate correctly over the X2 interface.
The procedure uses non UE-associated signalling.[L97982]
Page 111/289
ENB1 ENB2
ENB CONFIGURATION UPDATE

Served Cells To Add (1 to 256)
> Neighbour Information
>> ECGI
>> PCI
>> EARFCN
Served Cells To Modify (1 to 256)
> Old ECGI
>> ECGI
>> PCI
>> EARFCN
Served Cells To Delete (1 to 256)
> Old ECGI
GU Group Id To Add List (1 to 16)
GU Group Id To Delete List (1 to 16)
ENB CONFIGURATION UPDATE ACKNOWLEDGE

ENB1 ENB2
Figure 25 : X2 ENB Configuration Success
Initiating ENB behavior

The reception of new GUMMEI information from an MME instance in an S1 Setup
Response or a S1 MME Configuration Update message may cause the GU Group
Id List to change. If it does change, the eNB is expected to provide the new list to
neighboring eNBs using the X2 ENB CONFIGURATION UPDATE procedure towards
all its X2 neighbors.
The X2 ENB CONFIGURATION UPDATE procedure requires the eNB to provide a
delta of the GU Group ID List, i.e. the eNB needs to provide the new GU Group IDs,
as well as the GU Group Ids that need to be deleted. These items will be the same
across all X2 instances.
The eNB Configuration Update procedure may also be triggered by:
• the ANR function. [L81872]
• configuration update of served PLMN ID(s) [L104835].
Peer ENB behavior
Upon reception of the GU Group Id List in the X2 ENB CONFIGURATION UPDATE

message, the peer eNB will update the previous list and store the new information so
that it can be used for mobility decisions.
Page 112/289
A parameter, ovLevelForX2ENBConfUpdAction, controls the overload level (minor,

major, or critical) at which new X2 configuration update requests are rejected for the
duration of the overload condition. See LPUG [Vol. 4] for additional information about
overload control.
OverloadControl::ovLevelForX2ENBConfUpdAction
Parameter ovLevelForX2ENBConfUpdAction
[Major, Minor, Critical]
Value Critical
Feature L115241
6.11 X2 RESOURCE STATUS REPORTING

Feature L115223, Inter-freq Load Balancing, supports the capability for an eNB to
request eNB/cell load information over the X2 interface from a neighbor eNB (and for
the neighbor eNB to respond with appropriate data). This information is used in a
procedure to balance the load across overlapping cells that operate on different
frequencies to improve overall service. The load balancing capability is called
preventive load control and is described in [Vol. 4]. Note that Feature L115223
provides this capability for the bCEM modem card, and Feature L115223.1 provides
this capability for the eCEM modem card.
The use of the capabilities provided by Feature L115223 is controlled by the value of
parameter isInterFreqLoadBalancingFeatureEnabled. If this parameter value is
False, then the capability is disabled. If the parameter value is true, then the capability
is enabled. Note that the parameter value must be equal to “True” in both neighbor
eNBs in order for the capability to work. Activation of Feature L115223 is managed by
Feature Licensing (refer to LPUG Volume 1 for details). This parameter can be set to
'True' only if licensing (Tokens) are available for the feature. The total number of
activations for the feature is counted across all eNBs by SAM. See [Vol. 6] for
additional information concerning the isInterFreqLoadBalancingFeatureEnabled
parameter.
Page 113/289
The message flow that is associated with requesting and providing load
measurements from an eNB is illustrated in Figure 26.
ENB1 ENB2
RESOURCE STATUS REQUEST

eNB1 measurement ID
eNB2 measurement ID
X2ResourceStatus Registration Request (start / stop)
ResponseTimer Report Characteristics
Cell To Report
>Cell tTo Report Item
>>Cell ID
Reporting Periodicity
RESOURCE STATUS RESPONSE
eNB1 Measurement ID
eNB2 Measurement ID enb1::x2ResourceRepo
enb::x2ResourceStatus rtPeriodicity
MaxOverload Criticality Diagnostics
RESOURCE STATUS UPDATE

eNB1 Measurement ID
enb::x2ResourceStatus eNB2 Measurement ID enb1::x2ResourceRepo
MaxOverload Cell Measurement Result rtPeriodicity
>Cell Measurement Result Item
>>Cell ID
>>Hardware Load Indicator
>>S1 TNL Load Indicator
>>Radio Resource Status
>>Composite Available Capacity Group
RESOURCE STATUS UPDATE
......
......
Figure 26 : X2 Resource Status Reporting Message Flow
If the value of the isInterFreqLoadBalancingFeatureEnabled parameter is equal to

“True”, then eNB1 will send the RESOURCE STATUS REQUEST as soon as each X2
link operational state is Enabled. If the value of
isInterFreqLoadBalancingFeatureEnabled is changed from “False” to “True”, then
eNB1 will send the RESOURCE STATUS REQUEST for each X2 link in Enabled
state.
Note that the duration of the X2ResourceStatusResponseTimer that is shown in
Figure 26 is not configurable – the timer value is fixed in the current release. Also
note in Figure 26, that the eNB2 sends RESOURCE STATUS UPDATE messages
periodically, and the period is determined by the value of parameter
x2ResourceReportPeriodicity.
Page 114/289
x2ResourceReportPeriodicity : This parameter corresponds to the periodicity of X2

resource status report messages from peer eNodeBs. This parameter corresponds to
the periodicity of X2 resource status Update messages, which is determined by the
requesting Enb1.
Enb::x2ResourceReportPeriodicity
Parameter x2ResourceReportPeriodicity
Range & Unit Enumerate, milliseconds
[1000ms, 2000ms, 5000ms,10000ms]
Value 5000ms
Feature L115223
The RESOURCE STATUS REQUEST message can include requests for the following
load information:
o PRB Usage (UL/DL GBR PRB usage, UL/DL non-GBR PRB usage,
UL/DL Total PRB usage), in percentage [0…100%]
o S1 Transport Network Layer (TNL) Load, representing the S1 transport
network load [low, medium, high, overload]
o Hardware Load, [low, medium, high, overload]
o Composite available capacity (Rel-9 only), made up of a Capacity Class

[1…100%] and a Capacity Value [0…100%]
The RESOURCE STATUS REQUEST message can also be sent to stop the sending
of RESOURCE STATUS UPDATE messages (e.g., if the value of parameter
isInterFreqLoadBalancingFeatureEnabled is changed from “True” to “False”).
RadioCacCell::cellCapacityClass this parameter indicates the relative capacity of
the LteCell and is provided to the requesting eNB in the RESOURCE STATUS
UPDATE message. For example, the value of the cellCapacityClass parameter
should be smaller for a cell that is associated with a micro eNB than for a cell that is
associated with a macro eNB.
RadioCacCell::cellCapacityClass
Parameter cellCapacityClass
Range & Unit Integer, Percentage
0 to 100, step 1
Value O.D.
Feature L115223
Page 115/289
The cellCapacityClass parameter value represents the relative cell capacity when
compared to an overlapping neighbor cell(s). For example, if one of the cells has a
capacity of 20 calls, and the overlapping neighbor cell has a capacity of 5 calls, then
their cellCapacityClass parameter values might be set as follows:
2. Cell with 20 call capacity => cellCapacityClass value = 100 (%)
3. Cell with 5 call capacity => cellCapacityClass value = 25 (%)
In an operational network, cells would be divided into capacity classes based on their
call handling capacity and the cells in each capacity class would be assigned the
same cellCapacityClass value.
The overload status of either eNB that is shown in Figure 26 can affect the sending of
RESOURCE STATUS REQUEST and RESOURCE STATUS UPDATE messages.
Parameter ovLevelForCellLoadReportAction can be configured at each eNB to
control the overload level at which the eNB disables the Inter-freq Load Balancing
Feature. See LPUG [Vol. 4] for additional information about overload control.
OverloadControl::ovLevelForCellLoadReportAction: This parameter specifies the

level of overload at which or above which cell load exchanges are stopped:
• on X2 interface: any incoming X2AP eNB Resource Status Request
messages will be rejected, and any incoming X2AP eNB Resource Status
Update message will be ignored, and the eNB will stop sending X2AP eNB
Resource Status Update messages.
• on S1 interface: RIM messages for cell load are ignored.
See LPUG [Vol. 4] for additional information about overload control
OverloadControl::ovLevelForCellLoadReportAction
Parameter ovLevelForCellLoadReportAction
[Minor, Major, Critical]
Value Critical
Feature L115223, L115241
Inter-Release Delta: ovLevelForCellLoadReportAction
In release LA6.0, the function performed by this parameter was controlled by

parameter ovLevelForX2ENBResourceReportAction. The parameter name
and its function were expanded in release LR13.1 to also cover actions on the
S1 interface for RIM messages.
Page 116/289
When each RESOURCE STATUS UPDATE message is received a timer with duration
that is determined by the value of parameter x2ResourceStatusMaxOverload is
started. If overload or other reason causes an eNB to delay or stop sending
RESOURCE STATUS UPDATE messages and the timer expires at the receiving eNB,
then the resource status information is considered obsolete and will be discarded at
the receiving eNB, and all cells of the sending eNB changed to a status of “Not
Loaded”.
Enb::x2ResourceStatusMaxOverload : This parameter specifies the maximum
duration for which the eNodeB retains the resource status information of its
neighboring eNodeBs as received on the X2 interface.
Enb::x2ResourceStatusMaxOverload
Parameter x2ResourceStatusMaxOverload
1 to 3600 seconds, step = 1 second
Value 300 seconds
Feature L115223
Page 117/289
7 CALL HANDLING
7.1 DESCRIPTION OF THE IDLE MODE
The idle mode tasks can be subdivided into three processes:
- PLMN selection;
- Cell selection and reselection management;
- Location registration.
The relationship between these processes is illustrated in Figure 27.
Manual Mode Automatic mode
PLMN Selection
Indication
to user Location PLMNs
Registration available
response
PLMN
selected
NAS Control
Cell Selection
and Reselection
Radio measurements
Registration
Area
changes
Service requests
Location
Registration
Figure 27 : Overall Idle Mode process
When a UE is switched on, a public land mobile network (PLMN) is selected by NAS.
For the selected PLMN, associated RAT(s) may be set [R02]. The NAS will also
provide a list of equivalent PLMNs, if available, that the AS will use for cell selection
and cell reselection.
With the cell selection, the UE searches for a suitable cell of the selected PLMN and
chooses that cell to provide available services, further the UE will tune to its control
channel. This choice is known as "camping on the cell". Served PLMNs are broadcast
in SIB1 to assist the UE in finding an appropriate cell to camp on.
Page 118/289
The UE will, if necessary, then register its presence, by means of a NAS registration
procedure, in the tracking area of the chosen cell and as the outcome of a successful
Location Registration the selected PLMN becomes the registered PLMN [R02].
If the UE finds a more suitable cell, according to the cell reselection criteria, it
reselects onto that cell and camps on it.
If necessary, the UE will search for higher priority PLMNs at regular time intervals as
described in [R02] and search for a suitable cell if another PLMN has been selected
by NAS.
If the UE loses coverage of the registered PLMN, either a new PLMN is selected
automatically (automatic mode), or an indication of which PLMNs are available is
given to the user, so that a manual selection can be made (manual mode).
Registration is not performed by UEs that are only capable of services that need no
registration.
The purpose of camping on a cell in idle mode is fourfold:
a) It enables the UE to receive system information from the PLMN.
b) When registered and if the UE wishes to establish an RRC connection, it

can do this by initially accessing the network on the control channel of the
cell on which it is camped.
c) If the PLMN receives a call for the registered UE, it knows (in most cases)
the set of tracking areas in which the UE is camped. It can then send a
"paging" message for the UE on the control channels of all the cells in this
set of tracking areas. The UE will then receive the paging message
because it is tuned to the control channel of a cell in one of the registered
tracking areas and the UE can respond on that control channel.
d) It enables the UE to receive ETWS or CMAS (see Section 4.7)

notifications.
If the UE is unable to find a suitable cell to camp on, or the SIM is not inserted, or if
the location registration failed (except for LR rejected with cause #12, cause #14 or
cause #15, or cause #25, see [R02]), it attempts to camp on a cell irrespective of the
PLMN identity, and enters a "limited service" state in which it can only attempt to make
emergency calls.
If the value of parameter isIMSEmergencyCallAllowed is equal to True, then the
EIA0 (‘null’) integrity protection algorithm should be configured as an allowed integrity
protection algorithm. As a result, the eNB will populate the ims-EmergencySupport-r9
information element in SystemInformationBlockType1 to provide an indication that
“limited service” emergency calls are supported for unauthenticated UEs.
Page 119/289
go here whenever a
new PLMN is
selected
cell information no cell information

stored for the PLMN 1 stored for the PLMN
Stored Initial
information no suitable cell found Cell Selection
Cell Selection
no suitable
cell found suitable cell found 2 suitable cell found
no suitable
cell found
Cell Selection NAS indicates that
when leaving suitable Camped registration on selected
connected cell found normally PLMN is rejected
mode (except with cause
#12, #14 , #15 or #25
[5][16])
return to leave trigger
idle mode idle mode suitable
cell found
Connected
Cell
mode Reselection no suitable
Evaluation cell found
Process
go here
when no
USIM in
the UE
Any Cell
no acceptable cell found Selection
USIM inserted
acceptable
cell found
1
Cell Selection
acceptable
when leaving Camped on suitable
cell found
connected any cell cell found 2
mode
return to leave trigger

idle mode idle mode acceptable
cell found
Connected
mode Cell
(Emergency Reselection no acceptable
calls only) Evaluation cell found
Process
Figure 28 : State transitions and pprocedures in idle mode
Page 120/289
7.2 PLMN SELECTION & INTER TRACKING AREA MOBILITY

When the UE is in RRC Idle mode there are three different levels of mobility
management:
- PLMN Selection
- Tracking Area mobility management
- Cell Re-Selection management
- Cell Reservations an Access Restrictions
7.2.1 PLMN SELECTION:

PLMN selection is a procedure triggered by the NAS layer and carried out in the NAS
layer of the UE, when e.g. the UE is switched on.
It is based on the PLMN information provided of the system broadcast channels of the
strongest cell (from an RF metric point of view) seen by the UE.
The procedure is internal to the UE and there is therefore no E-UTRA level use case
for it.
36.304 [R12] defines the procedure as follows:

<<
The UE shall scan all RF channels in the E-UTRA bands according to its capabilities
to find available PLMNs. On each carrier, the UE shall search for the strongest cell
and read its system information, in order to find out which PLMN(s) the cell belongs to.
If the UE can read one or several PLMN identities in the strongest cell, each found
PLMN shall be reported to the NAS as a high quality PLMN (but without the RSRP
value), provided that the following high quality criterion is fulfilled:
1. For an E-UTRAN cell, the measured RSRP value shall be greater than or
equal to -110 dBm.
Found PLMNs that do not satisfy the high quality criterion, but for which the UE has
been able to read the PLMN identities are reported to the NAS together with the
RSRP value. The quality measure reported by the UE to NAS shall be the same for
each PLMN found in one cell.
The search for PLMNs may be stopped on request of the NAS. The UE may optimise
PLMN search by using stored information e.g. carrier frequencies and optionally also
information on cell parameters from previously received measurement control
information elements.
Once the UE has selected a PLMN, the cell selection procedure shall be performed in
order to select a suitable cell of that PLMN to camp on.>>
One or more PLMNs are provisioned by the operator on a per eNB basis. PLMNs are
broadcast on the BCCH channel on SIB-1.
Page 121/289
The corresponding configuration parameters are:

• plmnMobileCountryCode and
• plmnMobileNetworkCode
Present in the MO PlmnIdentity, which is described in Section 4.1.2
Rule: Regarding eUTRAN Sharing
With the introduction of eUTRAN sharing (e.g., Feature 104835), multiple PLMN
MCC and MNC values are supported. See Section 4.2 for additional information.
7.2.2 CELL RESERVATIONS AND ACCESS

RESTRICTIONS
As specified in 3GPP [R07] and [R12] there are two mechanisms which allow an
operator to impose cell reservations or access restrictions.
The first mechanism uses indication of cell status and special reservations for
control of cell selection and re-selection procedures.
The second mechanism, referred to as Access Control, prevents classes of users
from sending initial access messages for load control reasons. At subscription, one or
more Access Classes are allocated to the subscriber and stored in the USIM, which
are employed for this purpose.
Cell status and cell reservations are indicated in the
SystemInformationBlockType1 (SIB Type1) by means of two Information Elements:
- cellBarred (IE type: "barred" or "not barred")

In case of multiple PLMNs indicated in SIB1, this IE is common for all PLMNs
- cellReservedForOperatorUse (IE type: "reserved" or "not reserved")

In case of multiple PLMNs indicated in SIB1, this IE is specified per PLMN.
Note that additional discussion of access barring can be found in Section 7.5.1.2.1
a/ When cell status is indicated as "not barred" and "not reserved" for operator
use,
- All UEs will treat this cell as candidate during the cell selection and cell re-
selection procedures.
b/ When cell status is indicated as "not barred" and "reserved" for operator use
for any PLMN,
- UEs assigned to Access Class 11 or 15 operating in their HPLMN/EHPLMN
will treat this cell as candidate during the cell selection and reselection procedures if
the IE cellReservedForOperatorUse for that PLMN set to “reserved”.
- UEs assigned to an Access Class in the range of 0 to 9, 12 to 14 and UEs

with AC 11 or 15 not operating in their HLPMN/EHPLMN shall behave as if the cell
status is “barred” in case the cell is “reserved for operator use” for the PLMN the UE is
currently registered with.
NOTE 1: ACs 11, 15 are only valid for use in the HPLMN/ EHPLMN; ACs 12,
13, 14 are only valid for use in the home country.
Page 122/289
c/ When cell status "barred" is indicated or to be treated as if the cell status is

"barred",
- The UE is not permitted to select/re-select this cell, not even for
emergency calls.
- The UE must select another cell according to the following rule:
- If the IE intraFrequencyReselection in IE cellAccessRelatedInfo in

SystemInformationBlockType1 is set to "allowed", the UE may select another
cell on the same frequency if re-selection criteria are fulfilled.
- The UE shall exclude the barred cell as a candidate for cell

selection/reselection for 300 seconds.
- If the IE intraFrequencyReselection in IE cellAccessRelatedInfo in

SystemInformationBlockType1 is set to "not allowed" the UE shall not re-select
a cell on the same frequency as the barred cell.
- The UE shall exclude the barred cell and other cells on the
same frequency as a candidate for cell selection/reselection for 300
seconds.
The cell selection of another cell may also include a change of RAT.
• cellBarred: Indicates whether the cell is barred. Consult [R12] for more details.
Defined in TS 36.331 broadcast in SystemInformationBlockType1. ‘Barred’
means barred for all calls [R07], and as defined in TS 36.304. If the parameter
is set to 'notBarred', the cell is auto barred.
Upon detection of S1 links outage, and the cell coverage can be

reduced along with barring (see cellShrinkForS1LinksOutage);
If the parameter is manually changed to barred, the cell is barred, and
the cell coverage can be reduced along with barring (see
cellShrinkForOamBarring).
Prior to Cell Block for calls draining, and the cell coverage can be
reduced along with barring (see cellShrinkForCallsDraining) – this
capability is not currently implemented.
"
LteCell::cellBarred
Parameter cellBarred

[barred, notBarred]
Value notBarred
Feature L97933, L96760
Rule: cellBarred parameter
Cell barring affects not only cell selection/reselection, but also handover. If a cell is
Page 123/289
barred, then handover attempts to the barred cell will fail with cause “Cell Not
Available”.
Feature L115458 provides the capability to allow:

4. Specification that non-operator UEs can attempt handover to a second
best LTE cell when the handover preparation to the best cell has failed for
reasons associated with the neighbor cell being locked, barred or reserved
to operator use
5. Parameter spidAllowedInReservedCells specifies the Subscriber Profile
ID for which incoming handovers to a cell reserved for operator use are
allowed. This parameter must be set if
"isIncomingHoToReservedCellBasedOnSpidAllowed" is set to True.
See [Vol. 6] for more information on Feature L115458.
• cellReservedForOperatorUse: Indicates whether the cell is reserved for

operator use. Consult TS 36.304 for more details. In case of multiple PLMNs
indicated in SIB1, this parameter is specified per PLMN. Defined in TS 36.331
and broadcast in SystemInformationBlockType1.
CellReservation::cellReservedForOperatorUse
Parameter cellReservedForOperatorUse
Object ENBEquipment/Enb/LteCell/CellReservation

[reserved, notReserved]
Value notReserved
Feature L97933, L96760, L104835
Page 124/289
• plmnId: This parameter refers to the instance of the PlmnIdentity object that
defines the MCC and MNC of the concerned PLMN. See Section 4.1.1.1 for
additional discussion of the PlmnIdentity object.
CellReservation::plmnId
Parameter plmnId
Object ENBEquipment/Enb/LteCell/CellReservation

Value O.D.
Feature L104835
Note that the number of CellReservation instances should be equal to the number of
PLMNs that the eNB supports, and the plmnId parameter for each CellReservation
instance should point to a different PlmnIdentity instance.
• intraFrequencyReselection: This parameter Indicates whether intra-frequency

cell reselection is allowed when the cell is barred. Defined in TS 36.331.
Broadcast in SystemInformationBlockType1
CellSelectionReselectionConf::intraFrequencyReselection
Parameter intraFrequencyReselection
Object ENBEquipment/Enb/LteCell/ CellSelectionReselectionConf

[allowed, notAllowed]
Value Allowed
Information on cell access restrictions associated with the Access Classes is

broadcast as system information SIB2 in the ac-BarringInfo IE.[R07] .
The UE behaviour at reception of this control IE is specified in 3GPP [R12] and 3GPP
RRC specification [R07].
The MIM configuration model is shown in Figure 29.
Page 125/289
Figure 29 : Relationship of AccessBarring and Cell Reservation Objects
7.2.3 NEIGHBORING CELL ANTENNA

INFORMATION
• presenceAntennaPort1: 3GPP 36.331. This parameter is used to set the IE

PresenceAntennaPort1 in SIB3 used to indicate whether all the neighboring cells
use Antenna Port 1. When set to TRUE, the UE may assume that at least two
cell-specific antenna ports are used in all neighboring cells.
.
LteCell::presenceAntennaPort1
Parameter presenceAntennaPort1
Object ENBEquipmentEnb/LteCell

[False, True]
Value True
Feature
Page 126/289
7.3 PAGING
7.3.1 PAGING CHANNELS

In 3GPP 36.300 the following mapping of DL transport channels on L1 channels is
defined:
Figure 30: Channels for Paging
Note: PCH and DL-SCH are both carried at L1 on PDSCH. The L1 channel PDCCH
informs the UE about DL-SCH and PCH allocation.
PCCH uses RLC TM mode and MAC transparent mode. As a consequence the RRC
has the function to perform padding up to the Transport Block Size. The size of the
Transport Block is selected such as the best robustness is achieved given the RRC
Paging message size.
Paging messages are sent over the PCCH logical channel. PCCH is mapped onto the
PCH transport channel, which itself is carried on the PDSCH physical channel.
Transport format and resource allocation for the PCH channel is signalled on the
PDCCH channel, using the dedicated P-RNTI (defined as 0xFFFE in [R07]).
7.3.2 PAGING OCCASION

The moment at which a given UE can be paged in a paging frame (same length as a
radio frame) is called a Paging Occasion, as defined in [R08]. The paging occasion for
a given UE is calculated using the three following parameters:
- the UE_ID, equal to the UE IMSI modulo 1024 (but appeared like s-TMSI in
the paging traces) . This is provided to the eNodeB in the S1 Paging
message by mandatory information element "UE Identity Index Value",
- the DRX Paging Cycle; either the default value transmitted in the System
Information (defaultPagingCycle in SIB2 / and Enb::defaultPagingCycle in
the configuration data), or the UE-specific value received in the S1 Paging
message if it is shorter.
- parameter nB, transmitted in the System Information (in SIB2), which defines a
sort of "paging occasion density" within a radio frame.
Page 127/289
These three parameters participate in creating time diversity for the sending of
paging messages. In other words, they spread out in time the opportunities for
paging and in this way limit the scheduling conflicts while allowing the UEs to go into
DRX mode and reduce their power consumption.
The UE_ID splits the UE population into groups with identical paging occasions. All
UEs with the same UE_ID (defined as IMSI modulo 1024) shall be paged within the
same unique paging occasion. However a given paging occasion is always shared by
at least four UE_ID groups, and generally much more (in the "worst" case, all UEs
share a single paging occasion).
The DRX Paging Cycle defines the period over which paging messages will be
spread. A given UE will have one and only one paging occasion during the paging
cycle; if the occasion was missed (because the S1 Paging came after the occasion or
because there were too many paging messages buffered for the given paging
occasion), the eNodeB will have to buffer the paging until the next paging cycle. The
length of the paging cycle is a trade-off between mobile terminating call establishment
performance on one hand (the shorter the cycle the sooner the mobile will be paged)
and paging capacity on the other hand (the longer the cycle, the more paging
occasions there will be). The DRX Paging Cycle may be set to 32, 64, 128, or 256
radio frames (note that this parameter is called "T"in [R08]).
Parameter nB is expressed as a multiple or divisor of the paging cycle: it defines
the ratio of paging occasions to the number of radio frames. It is defined as an
enumerated taking its values in the following range : {fourT, twoT, oneT, halfT,
quarterT, oneEightT, onSixteenthT, oneThirtySecondT}.
Rule: Regarding: nB
A maximum of 1 paging sub-frame per frame is supported; this implies that values
"fourT" and "twoT" are not permitted for nB
If for example nB is set to "twoT", there will be two paging occasions in each radio
frame; if it is set to "quarterT", there will be one paging occasion every four radio
frames. The trade-off here is between radio resources (the smaller nB is, the less
radio resources may be consumed for paging) and paging capacity (the bigger nB, the
more paging occasions there are for a given paging cycle).
Paging occasion for a given UE:
Page 128/289
UE_ID Paging Occasions (*):

1023 1 to 1024
1022 n
IMSIs n-1
(up to 1021 mod 1024
values) 3
2 1
1 0
0
(*): depends on the DRX
Paging Cycle and nB
Figure 31: Frome IMSI to a paging occasion

A paging occasion for a given UE occurs within a given radio frame (referred to as a
"paging frame") at a given sub-frame number.
The paging frame for a given UE is characterized by:
SFN mod T = (T div N) * (UE_ID mod N)
The sub-frame number of a given UE's paging occasion is retrieved from a table
using the index i_s defined as follows:
i_s = floor (UE_ID / N) mod Ns
The previous formulas use the following parameters:

T is the DRX Paging Cycle, expressed in numbers of radio frames. The DRX
Paging Cycle is either parameter defaultPagingCycle broadcast in SIB2, or the UE-
specific value received in the S1 Paging message if it is shorter (pagingDRX optional
information element). Its values are in range {32, 64, 128, 256}.
nB is the parameter broadcast in SIB2, taking its values in the range {4T, 2T, T, T/2,
T/4, T/8, T/16, T/32}.
N is equal to min(T, nB). N defines the number of frames within the paging cycle that
will be used for paging, or in other words, the number of paging frames. With the
different possible values for T and nB, this may be as little as 1 or can represent all
the radio frames within the paging cycle.
Ns is equal to max(1, nB/T); given the definitions for T and nB, Ns is therefore in the
range {1,2,4}. Ns defines the number of sub-frames used as paging occasions within
a paging frame.
UE_ID is equal to IMSI mod 1024, provided to the eNodeB in the S1 Paging message
by mandatory information element "UE Identity Index Value".
Given the value of Index i_s and the value of Ns, the subframe number can be found
in Table 10
Ns \ i_s 0 1 2 3
1 9 NA NA NA
2 4 9 NA NA
Page 129/289
4 0 4 5 9
Table 10 : i_s vs Ns
Following are two example computations to illustrate the process:

Example 1:
Assume:
no UE-specific paging cycle from upper layers
defaultPagingCycle = rf128
nB = oneT = 1.0 (when expressed as a decimal number)
UE_ID = IMSI mod 1024 = 512
Then the subframe for the specific UE can be determined as follows:

T = DRX paging cycle in number of frames = defaultPagingCycle = 128
N = min(T, nB*T) = min(128, 1.0*128) = 128
Ns = max(1, nB/T) = max(1, 1.0/128) = 1
i_s = floor (UE_ID/N) mod Ns = floor (512/128) mod 1 = 4 mod 1 = 0
Using the values of i_s = 0, and Ns = 1 in Table 10, the paging subframe will be
subframe 9.
The paging frame is computed as:

SFN mod T = (T div N) * (UE_ID mod N) = (128/128) * (512 mod 128)
=1*4=4
Thus the UE can be paged in paging frame 4 and again 128 radio frames later.
Example 2:
Assume:
no UE-specific paging cycle from upper layers
defaultPagingCycle = rf256
nB = twoT = 2.0 (when expressed as a decimal number) – note this value is not
recommended, it is only for an interesting example
UE_ID = IMSI mod 1024 = 147
Then the subframe for the specific UE can be determined as follows:

T = DRX paging cycle in number of frames = defaultPagingCycle = 256
N = min(T, nB*T) = min(256, 2.0*256) = 256
Ns = max(1, nB/T) = max(1, 2.0/256) = 1
i_s = floor (UE_ID/N) mod Ns = floor (147/256) mod 1 = 0 mod 1 = 0
Using the values of i_s = 0, and Ns = 1 in Table 10, the paging subframe will be
subframe 9.
The paging frame is computed as:

SFN mod T = (T div N) * (UE_ID mod N) = (256/256) * (147 mod 256)
=1*0=0
Page 130/289
In this example, the UE will be paged in paging frame 0 and subframe 9. The same
UE can be paged again 256 radio frames later.
Once the paging occasion has been determined, the ue-Identity (referred to as "UE
Paging ID" in the S1 Paging message) and pagingCause are buffered until the time
comes for the paging frame and associated sub-frame pointed to by the paging
occasion.
Only one paging record is sent at a time, giving a capacity of up to 100 pages per
second (which is equal to the RACH capacity).
A paging message may also contain a notification of system information change.
The system supports Feature 97933, Dynamic System Info Modification (DSIM)
using Change Notification Paging (CNP). For each Paging Occasion (PO) in a paging
frame over a full paging cycle, the optional systemInfoModification flag in the Paging
message is sent as a standalone page if the PO has no S1-based page records, and it
piggybacks with S1 page records, otherwise.
Since all UEs in RRC Idle and RRC Connected need to be notified about an upcoming
change in System Info, CNP needs to be applied to each and every PO in a paging
cycle. This means the eNB can use the defaultPagingCycle and other pre-change
parameters nB, Ns etc to determine all the POs without the need to know the UEs
IMSIs (in fact the eNB does not know idle UEs IMSIs anyway).
If a UE uses a per-UE DRX and is shorter than the defaultPagingCycle), the per-UE
DRX paging cycle has to be ½ to 1/32 of the defaultPagingCycle. The UE will wake
up two or more times within the defaultPagingCycle to listen to a page destined for it,
and one of them will coincide with the PO calculated using the defaultPagingCycle.
• defaultPagingCycle : This parameter defines the default DRX paging cycle in

use within the cell, which corresponds to the period over which paging occasions
are spread. For more details consult TS 36.304. Defined in TS 36.331. Broadcast
in SystemInformationBlockType2
Enb::defaultPagingCycle
Parameter defaultPagingCycle
[rf32, rf64, rf128, rf256]
Value rf128
Feature
Note: The recommended value of this parameter was changed from rf32 to rf128 in
order to improve UE battery life. This leads to a slight increase in call setup time for
terminating calls.
Page 131/289
The units of the defaultPagingCycle parameter are in radio frames where a radio
frame is 10 milliseconds, so rf128 = 1280 milliseconds or 1.28 seconds.
• nB : Parameter nB is a multiple or divisor of the paging cycle: it defines the

ratio of paging occasions to the number of radio frames. For more details consult
TS 36.304. Defined in TS 36.331. Broadcast in SystemInformationBlockType2
LteCell::nB
Parameter nB
[oneT, halfT, quarterT, oneEightT, onSixteenthT,
oneThirtySecondT]
Value oneT
Feature
Inter-Release Delta: nB Parameter
Values of fourT and twoT have been removed and cannot be used. If they are used
in an existing system, they will be migrated to a value of oneT when it is upgraded to
LR13.1.
Rule: nB parameter
To allow fixed VoIP and PCCH bandwidth allocation, up to 1 paging sub-frame

per frame is supported: nB <= T. As a result, the values fourT and twoT should
not be used.
7.3.3 PAGING PROCEDURE

Upon receiving a Paging message on the S1 interface, the eNodeB determines the
list of cells on which to page the UE from the TAIList IE in the S1 Paging message.
For each cell on which the UE must be paged, the CallP will:
Compute the frame number and sub-frame number of the UE's paging
occasion,
Encode the paging record for the given UE,
Send this data to the Scheduler along with the paging cycle to be used
Page 132/289
Figure 32 : Paging Messages
If the eNB is in an overload condition, Feature L115241 (Overload Control Evolutions)

allows controls to be applied to retard the rate of S1 paging requests. In this case,
either a minor or a major overload condition may be exist, as discussed in LPUG [Vol.
4]. The rate at which S1 paging requests are rejected is controlled by two configuration
parameters as described in the following paragraphs.
s1PagingIgnoreRateMinor: This parameter defines the rate R at which incoming S1
Paging Requests are ignored during a Minor Overload condition. One out of R is
ignored, unless R equals zero in which case none are ignored.
OverloadControl::s1PagingIgnoreRateMinor
Parameter s1PagingIgnoreRateMinor
Range & Unit Unitless Integer
0 to 10, step 1
Value 10
Feature L115241
s1PagingIgnoreRateMajor: This parameter defines the rate R at which incoming S1

Paging Requests are ignored during a Major Overload condition. One out of R is
ignored, unless R equals zero in which case none are ignored.
OverloadControl::s1PagingIgnoreRateMajor
Parameter s1PagingIgnoreRateMajor
0 to 10, step 1
Value 5
Feature L115241
Page 133/289
MPS Paging messages are those in which the Priority Indication IE is present. Paging
Priority is introduced in the S1AP Paging message in Rel-10 and supported by the
eNB in LR13.1.
Setting parameter s1PagingPriorityIndicationHandling to True will allow S1 Paging
messages for Multimedia Priority Service (MPS) to be processed by the eNB during
critical overload until the expiration of an internal eNB timer, which is started when the
eNB enters critical overload. When this internal timer expires, the eNB will begin to
reject MPS Paging messages at a rate that is determined by an internal eNB
parameter. Also, when this parameter is True, rejection rate parameters
rrcCnxReqRejectRateMinor and rrcCnxReqRejectRateMajor will not apply to MPS
Paging messages.
Otherwise, if s1PagingPriorityIndicationHandling is set to False, the eNB will begin
to reject MPS Paging messages immediately after it enters critical overload. In
addition, rejection rate parameters rrcCnxReqRejectRateMinor and
rrcCnxReqRejectRateMajor will apply.
OverloadControl::s1PagingPriorityIndicationHandling
Parameter S1PagingPriorityIndicationHandling
[false, true]
Value true (default)
Feature L115805
Inter-Release Delta: s1PagingPriorityIndicationHandling
This parameter is new in LR13.1.
Page 134/289
7.4 UE CALL STATES AND STATE TRANSITIONS
7.4.1 UE STATE TRANSITIONS

There are basically 2 states in the RAN, namely RRC-IDLE and RRC-CONNECTED.
For each of these states, a number of operations can be conducted as described
below:
On the eNB, this simplified view is modified for call handling purposes. Each state and
transitions between states can be associated to defined scenaros which are detailed
below:
Page 135/289
Figure 33 : UE State Transitions
Rule:
Maximum number of bearers is controlled by the parameter

RadioCACFDD::maxNbOfDataBearersPerUe this parameter is described in [Vol. 4]
Restriction: Feature 92483 (Up to 8 Concurrent Data Radio Bearers per User)
Up to 8 Data Radio Bearers per UE are supported with Feature 92483. See Volume
4 for additional detail.
If Feature 92483 is not activated, then no more than four Data Radio Bearers are
supported.
In the descriptions that follow, a number in parentheses, e..g., (x), indicates a state
transition as shown in Figure 33.
1. NAS SIGNALLING ONLY SESSION ESTABLISHMENT (NO E-RAB SETUP)

FROM IDLE MODE
Could be used for UE Attach at power up (without E-RAB) or Tracking Area Update
Corresponds to Connection establishment for NAS signalling transfer (no E-RAB
establishment) described in section 7.5.5.1
Requires transition (idle ->SRB only): (1) only
Page 136/289
2. MOBILE ORIGINATED (MO) DATA SESSION SETUP FROM IDLE MODE

Could be used by the UE to obtain data service
Corresponds to Mobile Originated default E-RAB establishment in section
7.5.4.1.1. And initial context setup in section 7.5.3.1
Requires transitions (idle ->SRB only->SRB + default bearer): (1) + (3)
3. MOBILE TERMINATED (MT) DATA SESSION SETUP FROM IDLE MODE

Could be used due to DL data re-start (after traffic inactivity and transition to idle)
Corresponds to Mobile Terminated default E-RAB establishment in 7.5.4.1.2.
Requires paging and transitions (idle ->SRB only->SRB + default bearer): (1) + (3)
4. MO VOIP SESSION SETUP FROM IDLE MODE

Could be used by the UE to setup either VoIP/IMS or any other service requiring
specific QoS (Label) e.g. audio/video streaming, etc
Corresponds to Mobile Originated default E-RAB establishment as in section

7.5.4.1.1. followed by 1 dedicated E-RAB establishment as in section 7.5.4.2.
Requires transitions (idle ->SRB only->SRB + default bearer-> SRB + default bearer +
dedicated bearer) (1) + (3) + (4) or (1) + (3bis)
5. MT VOIP SESSION SETUP FROM IDLE MODE

Could be used by the UE to setup VoIP/IMS
Corresponds to Mobile Terminated default E-RAB establishment as in section
7.5.4.1.2 followed by 1 dedicated E-RAB establishment as in section 7.5.4.2.
Requires paging + transitions (idle ->SRB only->SRB + default bearer-> SRB + default
bearer + dedicated bearer) (1) + (3) + (4) or (1) + (3bis)
6. MO OR MT VOIP SESSION SETUP FROM CONNECTED MODE

Could be used by the UE to setup either MO or MT VoIP/IMS or any other service
requiring specific QoS (Label) e.g. audio/video streaming, etc. The default bearer is
used for SIP/IMS signalling.
Corresponds to 1 Dedicated E-RAB establishment as in section 7.5.4.2.
Requires transitions (SRB + default bearer -> SRB + default bearer + dedicated
bearer) (4)
7. VOIP SESSION RELEASE

Could be used to release VoIP/IMS session or any other service requiring specific
QoS (Label) e.g. audio/video streaming, etc
Corresponds to 1 E-RAB release (EPC triggered) as in section 7.5.4.3.
Requires transition (SRB + default bearer + dedicated bearer -> SRB + default bearer)
(5)
8. TRANSITION TO IDLE MODE
Page 137/289
Intiation by the EPC (e.g. “detach”, or TAU without activity flag set, or any other EPC
scenario etc)
y Corresponds to UE context release (EPC triggered) as in section 7.5.3.2.1.
y Requires transition (SRB only -> idle) (2) or (SRB + default

bearer+(dedicated) -> idle) (6)
Intiated by the eNB (e.g. due to traffic inactivity detection (to see the RRM
Algorithms part of this document), RL failure, defense mechanism, etc)
y Corresponds to UE context release (eNB triggered) as in section 7.5.3.2.2
y Requires transition (SRB only -> idle) (2) or (SRB + default
bearer+(dedicated) -> idle) (6)
Starting LR13.3 the connected mode mode is split in two states:
• Active state
• OOT state or Out of time alignment
State Definition Comment
Active A user has PUCCH/SRS This is an existing state (preOOT).

Resource configured by eNB,
AND, it is time-aligned with
eNB (i.e., its
TimeAlignmentTimer has not
yet expired).
OOT A user has no PUCCH/SRS Once the user’s TimeAlignmentTimer

resource configured by eNB, expires, the user releases its
AND, it is not time-aligned with PUCCH/SRS resource automatically.
eNB. DL scheduler will only handle
SRB1&SRB2.
Pending- A user has no PUCCH/SRS The Pending-State is a state that is

Active resource configured by eNB, used as a transition when going from
BUT, it is time-aligned with OOT to Active only.
eNB.
RLF A user is detected with RF This is an existing state (preOOT)

problem by eNB. and only RRC Cnx Reestablisment is
allowed
Active state to OOT state:

If no TAC is sent by eNB for “timeAlignmentTimer” duration then the user goes to OOT
and releases its PUCCH/SRS resource. eNB then puts the user into OOT state.
OOT state to Pending-Active state:
OOT user becomes Pending-Active, only when eNB determines that user is time-
aligned with eNB : when msg3 is received due to UL TRB/SRB1/SRB2 arrival or due
to user UL response to DL SRB1/SRB2 message.
OOT to Active (via Pending Active):
Page 138/289
RRC Connection request indicates the flag “from OOT to Active”. Now eNB decides to
assign and send new PUCCH/SRS resource to user (RACH msg5 received)
Figure 34 : UE State transition in the RRC Connected mode

isOOTManagementEnabled parameter enables or disables the OOT management.
OOT stands for “Out Of Time alignment”, and is used to efficiently use the limited
PUCCH/SRS resource of the air interface among active users.
ActivationService:: isOOTManagementEnabled
Parameter isOOTManagementEnabled
True/False
Class/Source B--Cells-of-NE / customer_settable
Value Default: True
Feature 166502
isOOTAllowed parameter specifies whether the traffic radio bearer allows the
operation of OOT (Out Of TimeAlignment).
Page 139/289
TrafficRadioBearerConf:: isOOTAllowed
Parameter isOOTAllowed
True/False
Class/Source Class-C (New-set-ups)/ customer_settable
Feature 166502
Engineering Recommendation: isOOTAllowed
The default value of this parameter is False. It can be changed to True if the
operator wants the indicated behavior for specific Traffic Radio Bearer. It is
recommende to set value to TRUE for all bearer, except for the VoIP QCI1
bearer and the bearers used by operator for real time service ( e.g. real time
gaming) because of the delay introduced when going back to active mode.
isRedirectionForOotEnabled parameter indicates whether to use redirection-based

RRC connection release or basic RRC connection release when there is no CAC
capacity or no PUCCH/SRS resource available for the state activation from OOT to
Active. “TRUE” indicates the former (redirection) and “FALSE” indicates the latter
(basic RRC release).
Enb:: isRedirectionForOotEnabled
Parameter isRedirectionForOotEnabled
True/False
Class/Source Class-C (Immediate-propagation)/ customer_settable
Feature 166502
Page 140/289
Engineering Recommendation: isRedirectionForOotEnabled
operator wants the indicated behavior. In case of TRB data, the recommendation
is to set to TRUE to perform RRC Connection Release with Redirection to a
specific carrier, based on the eMCTA algorithm. If set to FALSE the UE is going
to be requesting another RRC Connection after going to idle mode and if load
balancing is activated and depending on CAC filtering the UE may be accepted
or redirected.
pdcchOrderTransMax parameter specifies the maximum number of PDCCH

transmissions for an PDCCH order (in order to bring an OOT user to Active due to DL
traffic arrival).
CellRachConf:: pdcchOrderTransMax
Parameter pdcchOrderTransMax
Object ENBEquipment/Enb/LteCell/ CellRachConf
[1..10] step = 1
Class/Source Class-C (Immediate-propagation)/ system_restricted
Value Default: 3
Feature 166502
rrcRlsTimerForOOTUser parameter specifies the timer for the eNodeB to wait after
the RRC connection release message is sent to OOT user. Only when the timer
expires, the eNodeB triggers the removal of the user context.
Enb:: rrcRlsTimerForOOTUser
Parameter rrcRlsTimerForOOTUser
[0..800] step = 50ms
Class/Source Class-C (New-set-ups)/ system_restricted
Value Default: 100
Feature 166502
oOTManagementReported parameter specifies whether, or not, the group of

counters related to OOTManagement is selected to be reported.
Page 141/289
PerformanceManagement:: oOTManagementReported
Parameter oOTManagementReported
True/False
Class/Source Class-C (Immediate-propagation)/ system_restricted
Feature 166502
7.4.2 CONNECTED MODE & END OF

CONNECTED MODE
• t310: Defined in TS 36.331 This UE timer is started in the UE in connected mode
upon detecting radio link problems. At timer expiration the UE goes to idle mode.
Defined in TS 36.331. Broadcast in SystemInformationBlockType2
UeTimers::t310
Parameter t310
Object ENBEquipment/Enb/DedicatedConf/UeTimers
Range & Unit Enumerate in ms
[ms0, ms50, ms100, ms200, ms500, ms1000, ms2000]
Value ms1000
Feature L96760
Note: 36.331 says: If security is not activated: go to RRC_IDLE else: initiate the
connection re-establishment procedure.
• n310: Defines the number of consecutive "out-of-sync" indications received from

lower layers for the UE to detect physical layer problems Defined in TS 36.331
UeTimers::n310
Parameter n310
[n1, n2, n3, n4, n6, n8, n10, n20]
Value n1
Page 142/289
• n311: Defines the number of consecutive "in-sync" indications received from lower
layers for the UE to recover from physical layer problems Defined in TS 36.331
UeTimers::n311
Parameter n311
[n1, n2, n3, n4, n5, n6, n8, n10]
Value n1
7.5 CALL HANDLING PROCEDURES

Figure 34 provides an overview of UE call processing functions.
Ue Call Processing
1. RRC 2. Signaling
3. Context 4. Bearer 5. NAS 6. Resources
Connection Connection
Management Management Transport Management
Management Management
RRC connection S1 dedicated Initial context bearer setup Initial NAS E-RAB matching
establishment connection setup transport
establishment bearer release Transport CAC
RRC connection with or without UE context (MME initiated NAS transport
Radio CAC
reconfiguration E-RAB release (MME or ENB before / during
initiated or ENB initiated) / after initial Traffic based
RRC connection S1 dedicated
initiated) context setup release
release connection
management
release request Generic NAS
with or without transport Inter-cell
E-RAB interference
Security mode coordination
configuration (ICIC)
Figure 35 : UE Call Processing Functions
The use of some of the functions shown in Figure 34 are illustrated in a Mobile
Terminated VoIP call establishment as shown in Figure 35.
Page 143/289
UE eNodeB MME
Paging S1AP PAGING

RRC PAGING (NAS Paging ID, TAI(s), Paging DRX ID)
RRC Connection Establishment

RRC CONNECTION SETUP COMPLETE
S1 Dedicated Connection Establishment
NAS Service Request
with or without default E-RAB
S1AP INITIAL UE MESSAGE REQUEST
NAS Service Request
Measurement configuration
Initial Context Setup S1AP INITIAL CONTEXT SETUP REQUEST
Security Mode Command
RRC Connection Reconfiguration for Default Radio Bearer

Establishment
S1AP INITIAL CONTEXT SETUP RESPONSE
Subsequent bearer establishment S1AP E-RAB SETUP REQUEST
RRC Connection Reconfiguration

for Subsequent Radio Bearer Establishment
RRC CONNECTION RECONFIGURATION
RRC CONNECTION RECONFIGURATION COMPLETE
S1AP E-RAB SETUP RESPONSE
UE eNodeB MME
Figure 36 : Mobile Terminated VoIP Establishment
7.5.1 RRC CONNECTION MANAGEMENT

We will first start this section with the random access procedure as it is a prerequisite
for RRC connection to take place.
7.5.1.1 RANDOM ACCESS PROCEDURE
It is supposed that during the cell setup phase the PRACH is configured and setup in
the cell.
The PRACH configuration is indicated to the UE in System Information SIB2 [R07]
Page 144/289
Figure 37 : Channels for initial random procedure
RACH: 5-bit preamble, 1-bit info on initial L3 message size (ref to Sysinfo)
DL-SCH: RA preamble identifier, initial UL grant, Temp C-RNTI

No HARQ, semi-sync with message 1, Addressed to RA-RNTI on L1/L2 control channel
Figure 38 : Initial random procedure messages
The UE transmits a Random Access Preamble. When the eNB correctly receives a
Random Access Preamble and if eNB resources are available it will respond with
Random Access Response. A more detailed explanation can be found in [R07].
In the Random Access Response the eNB MAC will transmit
- the RA-RNTI corresponding to the received Random Access Preamble,
RA-RNTI = 1+ sub-frame number. See section 5.1.4 in [R07]

- the Timing Advance (received from L1),
- an initial UL grant to be used by the UE for the next UL RRC message (i.e. RRC
CONNECTION REQUEST)
- a temp C-RNTI (The IE C-RNTI identifies a UE having a RRC connection within a
cell). The temp C-RNTI allocation is done at MAC layer. The association of temp-
cCRNTI and granted UL resources is stored at MAC layer.
The RRC Connection Establishment procedure is described in Section 7.5.1.2.
Page 145/289
Rule: Regarding : Timing Advance and l1TimingAdvanceAveragingCoefficient

Timing Advance is used in several processes: in Random Access Response
reception; in Maintenance of Uplink Time Alignment; See [Vol. 4] for more detail
regarding parameter l1TimingAdvanceAveragingCoefficient in MO
L1MeasurementConf
RRC connection establishment involves SRB1 establishment. The procedure is also

used to transfer the initial NAS dedicated information/ message from the UE to E-
UTRAN.
7.5.1.2 RRC CONNECTION ESTABLISHEMENT
Purpose: to establish the RRC connection (i.e. SRB1) between the UE and eNB
triggered by the initial random access procedure.
According to [R07], the "Signalling Radio Bearers" (SRBs) are defined as Radio
Bearers (RB) that are used only for the transmission of RRC and NAS messages.
More specifically, the following three SRBs are defined:
- SRB0 is for RRC messages using the CCCH logical channel;
Note: the SRB0 is established at cell setup. [R07]
- SRB1 is for RRC messages (which may include a piggybacked NAS
message) as well as for NAS messages prior to the establishment of SRB2, all using
DCCH logical channel. SRB1 is secure; that is, it is integrity protected and, if a
ciphering algorithm is available, then it is also ciphered by the PDCP layer (see [Vol.
3]).
- SRB2 is for NAS messages, using DCCH logical channel. SRB2 has a
lower-priority than SRB1 and is always configured by E-UTRAN after security
activation. The establishment of SRB2 is specified in section INITIAL CONTEXT
SETUP. SRB2 is secure; that is, it is integrity protected and, if a ciphering algorithm is
available, then it is also ciphered by the PDCP layer (see [Vol. 3]).
Page 146/289
Call flow
Figure 39 : RRC connection establishment procedure
Initial state
It is assumed that a CCCH is available in the cell in order to receive the RRC
CONECTION REQUEST message on UL-CCCH.
After the UE initiates Random Access procedure (contention-based) by sending a
Random Access Preamble, the eNB will respond with a Random Access Response
and allocate a Temp C-RNTI. More details about the initial random access procedure
are in section 7.5.1.1..
Trigger
Reception of MAC PDU on UL-SCH using resources granted previously in Random

Access Response.
Procedure description
Upon reception of this MAC PDU (containing the RRC CONNECTION REQUEST
message), MAC will retrieve the temp C-RNTI previously associated with these
resources where the MAC PDU was received. This identity is sent to the RRC entity
together with the MAC SDU.
In case of Initial Access, the UE identity in the RRC CONNECTION REQUEST is
either a NAS identity (i.e. S-TMSI if valid), or a random number (S-TMSI not valid).
If the RRCConnectionRequest included the ue-Identity set to S-TMSI the eNB will
store it in order to include it in the INITIAL UE MESSAGE message
SRB matching is performed and associated radio configuration is retrieved.
Page 147/289
If ADMISSION CONTROL is passed, a new UE context is created and SRB1 is setup

in the eNB. The initial UE identity and the allocated C-RNTI are stored in the UE
context.
The RRCConnectionSetup is transmitted to the UE using CCCH. The message will

contain SRB1 configuration. The MAC contention resolution is based on UL CCCH
SDU used as UE Contention Resolution Identity in the MAC control element.
Defense mechanisms: An internal guard timer is started on transmission of RRC
CONNECTION SETUP message.
The procedure ends on eNB when it receives the RRC CONNECTION SETUP
COMPLETE message and the guard timer is stopped..
On reception of the RRCConnectionSetupComplete message, the eNB will use the
IEs NAS-DedicatedInformation , SelectedPLMN-Identity, RegisteredMME (if present)
to initiate the S1 dedicated establishment procedure.
Final state
UE Context created
SRB1 established
7.5.1.2.1 RRC CONNECTION INITIATION CHECKS
All UEs are members of one out of ten randomly allocated mobile populations,
defined as Access Classes 0 to 9. [R01]
The population number is stored in the SIM/USIM.
In addition, UEs may be members of one or more out of 5 special categories

(Access Classes 11 to 15), also held in the SIM/USIM. These are allocated to
specific high priority users as follows. (The enumeration is not meant as a priority
sequence):
Class 15 - PLMN Staff;

Class 14 - Emergency Services;
Class 13 - Public Utilities (e.g. water/gas suppliers);
Class 12 - Security Services;
Class 11 - For PLMN Use.[R01]
Note: In accordance with 3GPP TS 22.011:

Access Classes 0 – 9 are applicable to Home and Visited PLMNs.
Access Classes 11 – 15 – are applicable to Home PLMN only if the Equivalent
Home PLMN list or any EHPLMN is not present.
Access Classes 12, 13, 14 – are applicable to Home PLMN and visited PLMN of
home country only. For this purpose the home country is defined as the country
specified in the MCC part of a UE IMSI.
The RRC connection initiation procedure source is 3GPP TS 36.331 [R07], and the
material presented below has been prepared using source material from the standard.
First a view of the UE procedures is presented followed by a presentation of the eNB
Page 148/289
configuration parameters that are used by the UE (and are referenced in the
procedures)
If the UE is establishing the RRC connection for mobile terminating calls:
If timer T302 is running, then the UE considers access to the cell as barred;
Otherwise, the UE considers access to the cell as not barred

UE is Establishing the RRC Connection for Emergency Calls
Figure 39 provides a brief flowchart showing the decisions that are made by the
UE for emergency calls.
If the UE is Establishing the RRC connection; For Emergency Calls
SIB2 includes
No
Cell Not Barred accessBarringInformation
Yes
Yes accessBarringForEmergencyCalls
Cell Not Barred
under AccessBarring = False?
No
No UE has access class in range

Cell Barred
11…15?
No
Yes
Cell Barred All UE access Classes barred in
configuration Data?
No
Cell Not Barred
Figure 40 : RRC Connection Initiation for Emergency Calls
Page 149/289
UE is Establishing the RRC Connection for Originating Call
Figure 40 provides an overview flowchart that shows the decisions that are made
by the UE for originating calls.
UE is establishing the RRC connection for originating calls
Yes timer T302 or

Cell Barred T303 is running
No
No SIB2 includes accessBarringInformation

and accessBarringForOriginatingCalls
= True
Cell Not Barred
yes
UE has access class in range No

11…15?
yes
yes
At least one UE Access Class not
barred for originating calls
Cell Not Barred

No
draw a random number ‘rand’ uniformly distributed in the range: 0 ≤ rand < 1
‘rand’ is lower than the value of

No
accessProbabilityFactor included in
accessBarringForOriginatingCalls
Cell Barred
yes
Cell Not Barred
Figure 41 : RRC Connection Initiation for Originating Calls
Page 150/289
UE is Establishing the RRC Connection for Signaling Calls (e.g,, Traffic Area
Update)
Figure 41 provides an overview flowchart that shows the decisions that are made
by the UE for signaling calls.
UE is establishing the RRC connection for signaling calls
Yes timer T302 or

Cell Barred T303 is running
No
No SIB2 includes accessBarringInformation

and accessBarringForSignalingCalls =
True
Cell Not Barred
yes
UE has access class in range

11…15?
yes
yes
At least one UE Access Class not
barred for signaling calls
Cell Not Barred

No
draw a random number ‘rand’ uniformly distributed in the range: 0 ≤ rand < 1
‘rand’ is lower than the value of

No accessProbabilityFactor included in
accessBarringForOriginatingCalls
Cell Barred
yes
Cell Not Barred
Figure 42 : RRC Connection Initiation for Signaling Calls
Page 151/289
If access to the cell, as specified above, is not barred:
2> apply the default physical channel configuration as specified in [R07]

section 9.2.4, until explicitly receiving a configuration;
2> apply the default semi-persistent scheduling configuration as specified in

[R07] section 9.2.3, until explicitly receiving a configuration;
2> apply the default MAC main configuration as specified in [R07] section
9.2.2, until explicitly receiving a configuration;
2> apply the CCCH configuration as specified in [R07] section 9.1.1.2;
2> apply the timeAlignmentTimerCommon included in

SystemInformationBlockType2;
2> start timer t300;
2> initiate transmission of the RRCConnectionRequest message in

accordance with [R07] section 5.3.3.3;
NOTE 2: Upon initiating the connection establishment procedure, the UE is not

required to ensure it maintains up to date system information applicable only for UEs
in RRC_IDLE state. However, the UE needs to perform system information acquisition
upon cell re-selection.
If access to the cell, as specified above, is barred:
2> if the UE is establishing the RRC connection for mobile originating

calls and if both timers T302 and T303 are not running:
3> draw a random number ‘rand’ that is uniformly distributed in

the range 0 ≤ rand < 1;
3> start timer T303 with the timer value calculated as follows,
using the accessBarringTime included in accessBarringForOriginatingCalls:
T303= (0.7+ 0.6 * rand) * accessBarringTime
3> inform upper layers about the failure to establish the RRC
connection and that access barring for mobile originating calls is applicable,
upon which the procedure ends.
2> else if the UE is establishing the RRC connection for mobile

originating signalling and if both timers T302 and T305 are not running:
3> draw a random number ‘rand’ that is uniformly distributed in

the range 0 ≤ rand < 1;
3> start timer T305 with the timer value calculated as follows,
using the accessBarringTime included in accessBarringForSignalling:
T305= (0.7+ 0.6 * rand) * accessBarringTime
connection and that access barring for mobile originating signalling is
applicable, upon which the procedure ends.
2> else if the UE is establishing the RRC connection for emergency

calls:
Page 152/289
connection and that access barring for emergency calls is applicable, upon
which the procedure ends.
2> else:
connection, upon which the procedure ends.
The configuration model is shown in Figure 42.
LteCel
[1…6]
PlmnIdentity
Cell AccessBarring
Reservation
AccessBarring AccessBarring
SsacBarringFor SsacBarringFor AccessBarring
ForOriginating ForCSFB Calls
VideoMMTEL VoiceMMTEL ForSignaling
Calls
Figure 43 : LR13.1 Access Barring Configuration Model
The parameters that are associated with the Service Specific Access Control (SSAC)
for Multi-Media Telephony (MMTEL) objects are described in Section 7.5.1.2.2.
The types of cell barring that are in effect are determined by a configuration parameter
accessBarringStatus. This parameter determines the type of Access Barring
information that is broadcast in the cell (in SystemInformationBlockType2):
• none: no access classes are barred.
• emergencyCallsExclusively: only the bit indicating whether emergency calls

are barred is broadcast.
• signalingOnly: access barring information is broadcast for signaling calls

only (the bit for emergency calls is also broadcast).
• originatingCallsOnly: access barring information is broadcast for originating

calls only (the bit for emergency calls is also broadcast).
Page 153/289
• signalingAndOriginatingCalls: access barring information is broadcast for

both signaling calls and originating calls (the bit for emergency calls is also
broadcast).
AccessBarring::accessBarringStatus
Parameter accessBarringStatus
Object ENBEquipment/Enb/LteCell/AccessBarring
[none, emergencyCallsExclusively, signalingOnly,
originatingCallsOnly, signalingAndOriginatingCalls]
Value None
• accessBarringForEmergencyCalls: Indicates whether access is barred in the cell

for originating emergency calls. Defined in [R07] Broadcast in
SystemInformationBlockType2
AccessBarring::accessBarringForEmergencyCalls
Parameter accessBarringForEmergencyCalls
Object ENBEquipment/Enb/LteCell/AccessBarring
[false, true]
Value false ( if this value is set to “true”, also modify
“AccessBarring” parameter settings)
A restriction on emergency calls, if needed, is indicated by the IE

accessBarringForEmergencyCalls. If access class 10 is indicated as barred in a
cell, UEs with access class 0 to 9 or without an IMSI are not allowed to initiate
emergency calls in this cell. Otherwise, emergency calls are allowed for those UEs.
Full details of operation under "Access class barred list" are described in [R01].
• accessBarringTime: Defines the average time that a UE must consider the cell
barred for originating calls. Working at the level of RRC Connection
establishment.
A UE will set timer T303 to value (0.7+ 0.6 * rand) * accessBarringTime, where rand is
a random value drawn between 0 and 1. Defined in [R07] Broadcast in
Page 154/289
AccessBarringForOriginatingCalls::accessBarringTime
Parameter accessBarringTime
Object ENBEquipment/Enb/LteCell/AccessBarring/AccessBarringForOri
ginatingCalls
Range & Unit Enumerate in seconds
[s4, s8, s16, s32, s64, s128, s256, s512]
Value S32
Note: Not applied to LTE E911 calls.
• accessProbabilityFactor: Defines the probability that a UE may access the cell

for an originating call. When this parameter is set, the UE draws a random number
between 0 and 1; if the drawn number is lower than the
accessProbabilityFactor, the UE considers the cell as not barred and may
initiate an originating call. Defined in [R07] Broadcast in
SystemInformationBlockType2 (the 3GPP name is ac-BarringFactor) . Working at
the level of RRC Connection establishment.
AccessBarringForOriginatingCalls::accessProbabilityFactor
Parameter accessProbabilityFactor
Object ENBEquipment/Enb/LteCell/AccessBarring/AccessBarringForOri
ginatingCalls
Range & Unit Enumerate in %
[p00, p05, p10, p15, p20, p25, p30, p40, p50, p60, p70, p75, p80,
p85, p90, p95]
Value p50
Note: Not applied to LTE E911 calls.
Page 155/289
The parameters below are in the scope of the accessClassBarringList. According to

the mobile access class (between 11 and 15) the cell must be barred in specific
condition as was described at the beginning of this section.
• accessClass11Barring : This parameter specifies whether the UE access class

11 (For PLMN use) is barred in the cell for originating calls. See TS 36.331 [R10].
Broadcast in SystemInformationBlockType2.
AccessBarringForOriginatingCalls::accessClass11Barring
Parameter accessClass11Barring
Object ENBEquipment/Enb/LteCell/AccessBarring/AccessBarringForOrigi
natingCalls
[false, true]
Value false
Note: Access Class 11 is applicable to Home PLMN only if the Equivalent Home
PLMN list or any EHPLMN is not present. Barring of UEs with AC 11 from
making LTE E911 calls requires parameter AccessBarring::accessBarringStatus
to be set to originatingCallsOnly, or signalingOnly , or
signalingAndOriginatingCalls.

12 (Security Services) is barred in the cell for originating calls. See TS 36.331
[R10]. Broadcast in SystemInformationBlockType2.
natingCalls
[false, true]
Value false
Note: Access Class 12 is applicable to Home PLMN and Visited PLMN of the
home country only. Barring of UEs with AC 12 from making LTE E911 calls
requires parameter AccessBarring::accessBarringStatus to be set to
originatingCallsOnly, or signalingOnly , or signalingAndOriginatingCalls.
Page 156/289

13 (Public Utilities) is barred in the cell for originating calls. See TS 36.331 [R10].
natingCalls
[false, true]
Value false

14 (Emergency Services) is barred in the cell for originating calls. See TS 36.331
natingCalls
[false, true]
Value false
Page 157/289

15 (PLMN Staff) is barred in the cell for originating calls. See TS 36.331 [R10].
natingCalls
[false, true]
Value false
Note: Access Class 15 is applicable to Home PLMN only if the Equivalent Home
PLMN list or any EHPLMN is not present. Barring of UEs with AC 15 from
making LTE E911 calls requires parameter AccessBarring::accessBarringStatus
to be set to originatingCallsOnly, or signalingOnly , or
signalingAndOriginatingCalls.
The set of parameters described in the following tables control access barring for
signaling.
accessBarringTime: Defines the average time that a UE must consider the cell barred
for signaling calls. Working at the level of RRC Connection establishment.
A UE will set timer T305 to value (0.7+ 0.6 * rand) * accessBarringTime, where rand
is a random value drawn between 0 and 1. Defined in [R10] Broadcast in
AccessBarringForSignaling::accessBarringTime
Object ENBEquipment/Enb/LteCell/AccessBarring/
AccessBarringForSignaling
[s4, s8, s16, s32, s64, s128, s256, s512]
Value S32
accessProbabilityFactor: Defines the probability that a UE may access the cell for a
signaling call. When this parameter is set, the UE draws a random number between 0
and 1; if the drawn number is inferior to the accessProbabilityFactor, the UE
considers the cell as not barred and may initiate a signaling call. Defined in [R10]
Page 158/289
Broadcast in SystemInformationBlockType2. Working at the level of RRC Connection

establishment.
AccessBarringForSignaling::accessProbabilityFactor
AccessBarringForSignaling
[p00, p05, p10, p15, p20, p25, p30, p40, p50, p60, p70, p75,
p80, p85, p90, p95]
Value P50

11 (For PLMN use) is barred in the cell for signaling calls. See TS 36.331 [R10].
AccessBarringForSignaling::accessClass11Barring
Object ENBEquipment/Enb/LteCell/AccessBarring/AccessBarringForSigna
ling
[false, true]
Value false

12 (Security Services) is barred in the cell for signaling calls. See TS 36.331
ling
[false, true]
Value false
Page 159/289

13 (Public Utilities) is barred in the cell for signaling calls. See TS 36.331 [R10].
ling
[false, true]
Value false

14 (Emergency Services) is barred in the cell for signaling calls. See TS 36.331
ling
[false, true]
Value false
Page 160/289

15 (PLMN Staff) is barred in the cell for signaling calls. See TS 36.331 [R10].
ling
[false, true]
Value false
7.5.1.2.2 ACCESS BARRING FOR MULTIMEDIA VOICE AND

VIDEO CALLS
As part of Feature L114644.1, EUTRAN Standard Alignment on 3GPP Rel-9, a

capability is added to provide access blocking for voice and video multimedia calls.
These capabilities are referred to Service Specific Access Control (SSAC) for Multi-
Media Telephony (MMTEL):
• SSAC for Voice MMTEL
• SSAC for Video MMTEL
The access blocking parameters are comparable to those that are used for controlling
access for originating calls and signaling calls, and the procedures are also
comparable. The parameters are listed in the following paragraphs. The parameter
values are used in the population of SIB2. The procedures that the UE uses when
access blocking is indicated can be found in 3GPP TS 36.331 [R10].
Multimedia Voice Call Barring parameters:
Page 161/289
LteCell::spare6, bit 23 in LR13.1) The value of this parameter controls whether or not
SsacBarringForVoiceMMTEL is included in SIB2.
LteCell::spare6, bit 23
Range & Unit Integer 0, 1

0 – SsacBarringForVoiceMMTEL will not be included in SIB2
1 - SsacBarringForVoiceMMTEL will be included in SIB2
Value 0
Feature L114644
Inter-Release Delta: LteCell::spare6, bit 23
In a future release, the function currently performed by this spare bit will be
assumed by a regular parameter named ssacBarringVoiceStatus
accessBarringTime: Defines the average time that a UE must consider the cell
barred for MMTEL voice or video calls.
SsacBarringForVoiceMMTEL::accessBarringTime
Object ENBEquipment/Enb/LteCell/AccessBarring/SsacBarringForVoiceMMTEL
[s4, s8, s16, s32, s64, s128, s256, s512]
Value S32
Feature L114644.1
Page 162/289
considers the cell as not barred and may initiate an MMTEL voice or video call.
Defined in [R10] Broadcast in SystemInformationBlockType2.
SsacBarringForVoiceMMTEL::accessProbabilityFactor
Object ENBEquipment/Enb/LteCell/AccessBarring/SsacBarringForVoiceMMTEL
[p00, p05, p10, p15, p20, p25, p30, p40, p50, p60, p70, p75, p80, p85,
p90, p95]
Value P50
Feature L114644.1

11 (For PLMN use) is barred in the cell for originating multimedia voice calls. See
TS 36.331 [R10]. Broadcast in SystemInformationBlockType2
SsacBarringForVoiceMMTEL::accessClass11Barring
Object ENBEquipment/Enb/LteCell/AccessBarring/SsacBarringForVoiceM
MTEL
[false, true]
Value false
Feature L114644

12 (Security Services) is barred in the cell for originating multimedia voice calls.
See TS 36.331 [R10]. Broadcast in SystemInformationBlockType2
MTEL
[false, true]
Value false
Feature L114644
Page 163/289

13 (Public Utilities) is barred in the cell for originating multimedia voice calls See
MTEL s
[false, true]
Value false
Feature L114644

14 (Emergency Services) is barred in the cell for originating multimedia voice calls
MTEL
[false, true]
Value false
Feature L114644
Page 164/289

15 (PLMN Staff) is barred in the cell for originating multimedia voice calls See TS
36.331 [R10]. Broadcast in SystemInformationBlockType2
MTEL
[false, true]
Value false
Feature L114644
Multimedia Video Call Barring parameters:
LteCell::spare6, bit 24 in LR13.1) The value of this parameter controls whether or not
SsacBarringForVideoMMTEL is included in SIB2.
LteCell::spare6, bit 24
Range & Unit Integer 0, 1

0 – SsacBarringForVideoMMTEL will not be included in SIB2
1 - SsacBarringForVideoMMTEL will be included in SIB2
Value 0
Feature L114644
Inter-Release Delta: LteCell::spare6, bit 24
In a future release, the function currently performed by this spare bit will be
assumed by a regular parameter named ssacBarringVideoStatus
Page 165/289
barred for MMTEL voice or video calls.
SsacBarringForVideoMMTEL::accessBarringTime
Object ENBEquipment/Enb/LteCell/AccessBarring/SsacBarringForVideoMMTEL
[s4, s8, s16, s32, s64, s128, s256, s512]
Value S32
Feature L114644.1
considers the cell as not barred and may initiate an MMTEL voice or video call.
Defined in [R10] Broadcast in SystemInformationBlockType2.
SsacBarringForVideoMMTEL::accessProbabilityFactor
Object ENBEquipment/Enb/LteCell/AccessBarring/SsacBarringForVideoMMTEL
[p00, p05, p10, p15, p20, p25, p30, p40, p50, p60, p70, p75, p80, p85,
p90, p95]
Value P50
Feature L114644.1
Page 166/289

11 (For PLMN use) is barred in the cell for originating multimedia video calls. See
SsacBarringForVideoMMTEL::accessClass11Barring
Object ENBEquipment/Enb/LteCell/AccessBarring/SsacBarringForVideoM
MTEL
[false, true]
Value false
Feature L114644

12 (Security Services) is barred in the cell for originating multimedia video calls.
MTEL
[false, true]
Value false
Feature L114644

13 (Public Utilities) is barred in the cell for originating multimedia video calls See
MTEL s
[false, true]
Value false
Feature L114644
Page 167/289

14 (Emergency Services) is barred in the cell for originating multimedia video calls
MTEL
[false, true]
Value false
Feature L114644

15 (PLMN Staff) is barred in the cell for originating multimedia video calls See TS
MTEL
[false, true]
Value false
Feature L114644
Access class barring may also be used when a CCM or CEM board of the eNB is in
critical overload to minimize RRC Connection Request message processing, to
conserve CPU resources, and improve accessibility KPIs. Note that the access class
barring procedure is applicable per cell. Thus, the “overload” level, taken into account
is the maximum level between CCM and CEM boards. The CEM board involved is the
CEM where the concerned cell is located.
Setting parameter OverloadControl::accessClassBarringDefense to True will allow
the access class barring procedure to be initiated for non-emergency MO-Signaling
and MO-Data RRC Connection establishments when the eNB enters critical overload.
Otherwise if set to False, then access class barring will not be initiated during critical
overload unless it is manually initiated by the operator.
When the eNB exits critical overload, UEs are notified via SIB2 broadcast that access
class barring no longer applies.
Page 168/289
OverloadControl::accessClassBarringDefense
Parameter accessClassBarringDefense
[false, true]
Feature L115805
Inter-Release Delta: accessClassBarringDefense
Restriction: regarding accessClassBarringDefense
In LR13.1, access class barring defense is supported only on bCEM. That is,
parameter accessClassBarringDefense may be set to True only if the modem
type is bCEM.
Note that an internal parameter in the eNB (not user configurable) is used by qualified
ALU personnel to configure the percentage of blocking of RRC Connection Requests
when the eNB is in critical overload. If this internal parameter is set to a non-zero
percentage of blocking (100% is the standard configuration), this new RRC
Connection Request handling mechanism introduced by activation of L115805 will be
performed when the eNB enters critical overload.
If the eNB is internally configured for no blocking in critical overload (internal
parameter set to 0%),, then this new handling mechanism is not used.
7.5.1.2.3 ACCESS BARRING FOR CIRCUIT SWITCHED

FALLBACK CALLS
As part of Feature L115225, EUTRAN Standard Alignment on 3GPP Rel-10, a

capability is added to provide access blocking for Circuit Switched Fallback (CSFB)
calls. See [Vol. 6] for additional information about CSFB capabilities.
The access blocking parameters are comparable to those that are used for controlling
access for originating calls, signaling calls, and multimedia voice and video calls that
have already been described, and the procedures are also comparable. The
Page 169/289
parameters are listed in the following paragraphs, and the parameter values are used
in the population of SIB2. The procedures that the UE uses when access blocking is
indicated can be found in 3GPP TS 36.331 [R10].
This parameter determines the status of Access Barring information for CS Fallback
which is broadcast in the cell (in SystemInformationBlockType2):
• false: no barring for mobile originating CS Fallback.
• true: barring for mobile originating CS Fallback.
AccessBarring::accessBarringCsfbStatus
Parameter accessBarringCsfbStatus
[True, False]
Value False
Feature L115225
barred for CSFB calls. Works at the level of RRC Connection establishment.
AccessBarringForCsfb::accessBarringTime
Object ENBEquipment/Enb/LteCell/AccessBarring/AccessBarringForCsfb
[s4, s8, s16, s32, s64, s128, s256, s512]
Value S32
Feature L115225
Page 170/289
CSFB call. When this parameter is set, the UE draws a random number between 0 and
1; if the drawn number is inferior to the accessProbabilityFactor, the UE
considers the cell as not barred and may initiate a CSFB call. Defined in [R10]
Broadcast in SystemInformationBlockType2. Works at the level of RRC Connection
establishment.
AccessBarringForCsfb::accessProbabilityFactor
[p00, p05, p10, p15, p20, p25, p30, p40, p50, p60, p70, p75, p80,
p85, p90, p95]
Value P50
Feature L115225

11 (For PLMN use) is barred in the cell for originating CSFB calls. See TS 36.331
[R10]. Broadcast in SystemInformationBlockType2
AccessBarringForCsfb::accessClass11Barring
[false, true]
Value false
Feature L115225

12 (Security Services) is barred in the cell for originating CSFB calls. See TS
[false, true]
Value false
Feature L115225
Page 171/289

13 (Public Utilities) is barred in the cell for originating CSFB calls See TS 36.331
s
[false, true]
Value false
Feature L115225

14 (Emergency Services) is barred in the cell for originating CSFB calls See TS
[false, true]
Value false
Feature L115225

15 (PLMN Staff) is barred in the cell for originating CSFB calls See TS 36.331
[false, true]
Value false
Feature L115225
Page 172/289
7.5.1.3 RRC CONNECTION ESTABLISHMENT FAILURES
7.5.1.3.1 ENB FAILURE TO SETUP THE RRC CONNECTION

If the eNB fails to setup the RRC Connection (i.e. SRB1), it will respond to the
RRCConnectionRequest message with RRCConnectionReject including the IE
waitTime set to the MIM parameter t302 in MO UeTimers. The ENB may fail to set up
the RRC Connection for the following reasons:
- ADMISSION CONTROL failure
- The cell is barred (indicated by MIM parameter LteCell/cellBarred)
- All S1 links are down (indicated by the fact that all MmeAccess managed objects
are in state different from Enabled/None)
- The eNB is in a minor or major overload condition or the associated MME is in an
overload condition (see description later in this section)
- Internal reasons.
No UE context is created.
Figure 44 : eNB failure to setup the RRC Connection scenario call flow
Page 173/289
• t302: This UE timer is started upon reception of RRCConnectionReject and is

stopped upon successful RRC establishment or cell re-selection. Defined in TS
36.331. Sent in RRCConnectionReject (information element waitTime)
UeTimers::t302
Parameter t302
Range & Unit Integer in s
[1..16] step=1
Value 5
Feature L96760
Rule: t302 expires

The UE will:
1> if timer t302 expires or is stopped:
2> inform upper layers about barring alleviation for mobile terminating
access;
2> if timer t303 is not running:
3> inform upper layers about barring alleviation for mobile originating
calls;
signalling;
calls;
2> if timer T302 is not running:
signalling.
Rule: t302
t302 works in several processes : RRC connection establishment; at the level of

Initiation; and at the Reception of the RRCConnectionSetup by the UE; during Cell
re-selection while t300, t302, t303 or t305 is running; at the Reception of the
RRCConnectionReject by the UE.
Page 174/289
t300: This UE timer is started when sending RRCConnectionRequest and is

stopped upon reception of RRCConnectionSetup or RRCConnectionReject. Defined in
TS 36.331. Broadcast in SystemInformationBlockType2
UeTimers::t300
Parameter t300
Object Enb/ DedicatedConf/ UeTimers
Range & Unit t300Enum in s
[ms100, ms200, ms400, ms600, ms1000, ms1500, ms2000]
Value ms400
Feature L96760
Rule: t300 expires

1> If timer t300 expires:
2> reset MAC, release the MAC configuration and re-establish RLC for all
RBs that are established;
2> inform upper layers about the failure to establish the RRC connection,
upon which the procedure ends.
Rule: t300
t300 is used in several processes : RRC connection establishment; at the level of

Reception of the RRCConnectionSetup by the UE; during Cell re-selection while t300,
t302, t303 or t305 is running; at the Reception of the RRCConnectionReject by the UE;
upon abortion of connection establishment by upper layers.
Page 175/289
eNodeB Overload: If the eNodeB is in an overload condition, Feature L115241

(Overload Control Evolutions), allows controls to be applied to retard the rate of new
RRC connections. In this case, either a minor or a major overload condition may be
exist as discussed in LPUG [Vol. 4]. The rate at which new RRC connections are
rejected is controlled by the four configuration parameters that are described in the
following paragraphs.
Note: the two “Reject Rate” parameters that follow are expressed as a rate, R, at
which RRC connection requests are rejected. This can also be expressed as a
percentage = (1/R) * 100. So, for example, if R = 4, then (1/8)*100 = 12.5% of RRC
connection requests will be rejected.
rrcCnxReqRejectRateMinor: This parameter defines the rate R at which incoming
RRC Connection Requests are rejected during a Minor Overload condition. One out of
R requests is rejected, unless R equals zero in which case none are rejected. RRC
Connection Requests from delay-tolerant UEs are all rejected using
extendedWaitTimeDueToENB regardless of the settings.
OverloadControl::rrcCnxReqRejectRateMinor
Parameter rrcCnxReqRejectRateMinor
0 to 10, step 1
Value 8
Feature L115241
rrcCnxReqRejectRateMajor: This parameter defines the rate R at which incoming

RRC Connection Requests are rejected during a Major Overload condition. One out of
R requests is rejected, unless R equals zero in which case none are rejected. RRC
Connection Requests from delay-tolerant UEs are all rejected using
extendedWaitTimeDueToENB regardless of the settings.
OverloadControl::rrcCnxReqRejectRateMajor
Parameter rrcCnxReqRejectRateMajor
0 to 10, step 1
Value 3
Feature L115241
In addition to defining a rejection rate for RRC connection requests, the overload
control feature also provides the capability to increase the UE wait time before
launching a new RRC connection request. In this case the RRCConnectionReject
message (information element waitTime) will contain the value of a configuration
parameter that is related to the overload level in place of the value of parameter t302.
Page 176/289
rrcCnxReqWaitTimeMinor: This parameter defines the waitTime value to be used

when RRC Connection Requests are rejected in Minor Overload. Sent in the
RRCConnectionReject message (information element waitTime). A random value in
the range of (75% to 125%) of the parameter value (respecting min/max values of the
parameter range) will be used. Also, refer to extendedWaitTimeDueToENB for
delay-tolerant UEs.
OverloadControl::rrcCnxReqWaitTimeMinor
Parameter rrcCnxReqRejectRateMinor
Range & Unit Integer, Seconds
1 to 16, step 1
Value 10 seconds
Feature L115241
rrcCnxReqWaitTimeMajor: This parameter defines the waitTime value to be used

when RRC Connection Requests are rejected in Minor Overload. Sent in the
RRCConnectionReject message (information element waitTime). A random value in
the range of (75%, 125%) of the parameter respecting min/max cardinalities will be
used. Refer to extendedWaitTimeDueToENB for delay-tolerant UEs.
OverloadControl::rrcCnxReqWaitTimeMajor
Parameter rrcCnxReqWaitTimeMajor
1 to 16, step 1
Value 16 seconds
Feature L115241
Page 177/289
extendedWaitTimeDueToENB: This parameter specifies the IE extendedWaitTime in

RRC Connection Reject for delay-tolerant UEs (establishmentCause is
delayTolerantAccess) in response to eNB overload/congestion, where exponential
back-offs can be configured in proportion to the degrees of overload. The elements in
the list correspond to the values of X (see below) to be used, respectively, with eNB
overload levels of:Minor Overload, Major Overload, and Critical Overload.
A random value in the range of (75%*X, 125%*X), where X is the chosen element in
the list (depending on eNB overload level) and the random value respects the
minimum and maximum values of the parameter. The random value, is used to set
RRC extendedWaitTime, and releaseCause is set to a value other than
loadBalancingTAURequired or cs-FallbackHighPriority. See TS 36.331.
Note: The first element is also used in RRC Reject when CAC actions are applied to
delay-tolerant UEs.
UeTimers::extendedWaitTimeDueToENB
Parameter extendedWaitTimeDueToENB
Range & Unit List of three integers corresponding to the value used for
minor, major, and critical overload conditions
Integer, Seconds
1 to 1800, step 1
Value (100, 250, 500) seconds
Feature L115225
Setting parameter ecHighPriorityCallsFilteringCriticalOverload to True will allow

emergency calls (LTE or CSFB) and HPA calls (in LR13.3), to be processed during
critical overload until the expiration of an internal eNB timer, which is started when the
cell enters critical overload. When this internal timer expires, the eNB will begin to
reject emergency calls at a rate that is determined by an internal eNB parameter.
This handling applies to all of the following messages for emergency calls and HPA
calls (in LR13.3):
• RRC Connection Request
• RRC Connection Re-establishment
• S1 Handover Request
• X2 Handover Request
• S1 E-RAB Setup Request
• S1 E-RAB Modify Request
• RRC Measurement Report for intra-eNB HO

Otherwise, if ecHighPriorityCallsFilteringCriticalOverload is set to False, the eNB
will begin to reject emergency calls and HPA calls (in LR13.3), immediately after it
enters critical overload.
Note that an internal parameter in the eNB (not user configurable) is used by qualified
ALU personnel to configure the percentage of blocking of RRC Connection Requests
when the eNB is in critical overload. If this internal parameter is set to a non-zero
Page 178/289
percentage of blocking (100% is the standard configuration), this new RRC

Connection Request handling mechanism introduced by activation of L115805 will be
performed when the eNB enters critical overload.
If the eNB is internally configured for no blocking in critical overload (internal
parameter set to 0%), then this new handling mechanism is not used.
OverloadControl::ecHighPriorityCallsFilteringCriticalOverload
Parameter ecHighPriorityCallsFilteringCriticalOverload
[false, true]
Feature L115805
Inter-Release Delta: ecHighPriorityCallsFilteringCriticalOverload
In LR13.1, this Critical Overload filtering applies to Emergency Calls.
In LR13.3, this Critical Overload filtering applies to Emergency Calls and High
Priority Access (HPA) Calls.
Setting parameter mtAccessRrcCnxReqFilteredInOverload to False will allow RRC

Connection Request messages with cause “mt-access” to be processed while the eNB
is in overload, regardless of the overload level. Otherwise, if this parameter is set to
True, then the rejection rate parameters rrcCnxReqRejectRateMinor and
rrcCnxReqRejectRateMajor apply for overload control.
OverloadControl::mtAccessRrcCnxReqFilteredInOverload
Parameter mtAccessRncCnxReqFilteredInOverload
[false, true]
Value false (default)
Feature L115805
Page 179/289
Inter-Release Delta: mtAccessRrcCnxReqFilteredInOverload
If the eNB is internally configured for no blocking, then these new handling
mechanisms are not used as they would not be applicable.
MME Overload: With the introduction of Feature 115665.1 (MME Overload Indication
Support), an MME can indicate that it is in overload condition to the eNB (see Section
5.4 for additional information about this feature). When the MME is in overload
condition, and an RRC connection request for a prohibited type of traffic is received
that involves the overloaded MME, the connection will be rejected. In this case the
RRCConnectionReject message (information element waitTime) will contain the value
of a configuration parameter, tOverload, that is related to the MME overload in place
of the value of parameter t302.
tOverload : This parameter is used to configure the IE waitTime of the IE
rrcConnectionReject-r8 of the message RRCConnectionReject (see TS36.331) in
case of RRC Connection rejected due to MME Overload. It specifies the time in
seconds before the UE can attempt a new RRC Connection. A random value in the
range of (75%*tOverload to 125%*tOverload) respecting the minimum and maximum
values of the parameter will be used. Refer to extendedWaitTimeDueToMME for
delay-tolerant UEs.
UeTimers::tOverload
Parameter tOverload
Object Enb/ DedicatedConf/ UeTimers
1 to 16, step 1
Value 16 seconds
Feature L101845
Page 180/289
extendedWaitTimeDueToMME: This parameter specifies extendedWaitTime in RRC

Connection Reject or Release for delay-tolerant UEs (establishmentCause is
delayTolerantAccess) in response to MME overload, where exponential back-offs can
be configured in proportion to the degrees of overload. The five elements in the list
correspond to, respectively, MME overload actions of:
* reject only Delay-Tolerant Access;
* reject MO-Data and Delay-Tolerant Access;
* reject MO-Signaling and MO-Data and Delay-Tolerant Access;
* only permit Emergency and MT-Access;
* only permit High-Priority Access and MT-Access.
A random value in the range of (75%*X to 125%*X), where X is the chosen element in
the list and the random value respects the minimum and maximum parameter values,
is used to set RRC extendedWaitTime, and releaseCause is set to a value other than
loadBalancingTAURequired or cs-FallbackHighPriority. See TS 36.413 and 36.331.
UeTimers::extendedWaitTimeDueToMME
Parameter extendedWaitTimeDueToMME
Range & Unit List of five integers corresponding to the conditions listed
above
Integer, Seconds
1 to 1800, step 1
Class/Source C--New-Set-ups / system_restricted
Value (60, 120, 240, 480, 480) seconds
Feature L115225
The MME overload indication support feature also provides the ability to support a
non-standard means for re-directing UEs with non-permitted RRC traffic away from an
overloaded MME. Activation of this capability is controlled by parameter
overloadCallRejectNotAllowed.
• If the value of parameter overloadCallRejectNotAllowed is set equal to

false, non-permitted RRC traffic will be rejected or released.
• If the value of parameter overloadCallRejectNotAllowed is set equal to true,

then a “non-standard” specific overload handling is activated for non-permitted
RRC traffic. The RRCConnectionRequest is accepted, even if an S-TMSI
matching an overloaded MME is provided. However, on reception of
RRCConnectionSetupComplete, if either the S-TMSI or registered MME
match an overloaded MME, the RRC connection is released with cause
“loadbalancingTAUrequired”. This allows the UE to establish a new RRC
connection with a TAU, without providing an S-TMSI or registered MME, and
to select a different MME to handle the call.
overloadCallRejectNotAllowed: Setting the value of this parameter to “True”
activates a proprietary MME overload-handling mechanism. Rather than rejecting calls
in case of MME overload as specified in 36.413, the eNB releases the RRC
Connection with cause "loadbalancingTAUrequired" for non-delay-tolerant UEs. This
results in a new RRC Connection without providing S-TMSI or registeredMME, and a
Page 181/289
new MME is selected by the eNodeB. This proprietary mechanism must be used with
caution and limited to specific network topologies, because it can cause overload of
other MMEs.
ActivationService::overloadCallRejectNotAllowed
Parameter overloadCallRejectNotAllowed
Object Enb/ActivationService
True, False
Class/Source C--New-set-ups/ customer_settable
Value O.D. (see Engineering Recommendation)
Feature L101845
Engineering Recommendation: overloadCallRejectNotAllowed
operator wants the indicated behavior. Note that if there is no alternate MME
available, then the parameter value should be False.
7.5.1.3.2 UE FAILURE TO SETUP THE RRC CONNECTION

(INTERNAL GUARD TIMER EXPIRATION)
When the eNB transmits the RRC CONNECTION SETUP message to the UE a
defense timer is started in order to prevent the scenario when the UE does not receive
the message due to e.g; cell reselection. If the eNB does not receive RRC
CONNECTION SETUP COMPLETE before the timer expiry, the RRC connection is
considered as failed and the eNB will delete UE context and release any associated
eNB resources.
Page 182/289
Figure 45 : UE failure to setup the RRC Connection scenario call flow
• rrcProcedureDefenseTimer: This eNB internal defense timer is used to monitor the

non answer from the UE in case of any RRC procedure except RRC Connection
setup (see below for information on setup). The timer is started in the eNB at
message transmission and stopped at response message reception from the UE. At
timer expiration the procedure is failed. The specific procedures to which this timer
applies are:
Ö Security Mode Command – see Section 7.5.3.1 for example
Ö UE Capability Enquiry – see Section 7.5.3.1 for example
Ö RRC Connection Re-Establishment – see Section 7.5.1.4
Enb::rrcProcedureDefenseTimer
Parameter rrcProcedureDefenseTimer
[50..3000] Step = 10
Value 2000
Feature
Page 183/289
• Enb:: rrcConnSetupCompleteTimer : This eNB internal defense timer is used to

monitor the non answer from the UE in case of RRC connection setup procedure.
The timer is started in the eNB at message transmission and stopped at response
message reception from the UE. At timer expiration the setup procedure is failed.
Enb::rrcConnSetupCompleteTimer
Parameter rrcConnSetupCompleteTimer
[50 to 3000] Step = 10
Value 1000 ms
Feature
Inter-Release Delta: rrcConnSetupCompleteTimer
In the previous release, the function of this parameter was provided by the
parameter Enb::spare13, bits 8 – 19.
The ueContextMaxLifeTime parameter is an optional parameter that specifies, in

hours (to a precision of 0.5 hours), the maximum life-time for a UE context. The
parameter's function is to protect call admission control against an accumulation of
phantom UE contexts.
If the parameter value is <unset>, then no limit is imposed upon the life-
time of a UE context.
If the parameter is set, then the life-time of each UE context is limited to
the given value. A UE context is released if its life-time exceeds the value
of this parameter.
Enb::ueContextMaxLifeTime
Parameter ueContextMaxLifeTime
Range & Unit Floating point number
0.5 to 72 hours, increment 0.5 hours
Value 24 hours
Feature
Page 184/289
Timer Start Stop At expiry

T300 Transmission of Reception of Perform the actions as specified
RRCConnectionRequest RRCConnectionSetup or in [R07] section 5.3.3.6
RRCConnectionReject
message, cell re-selection and
upon abortion of connection
establishment by upper layers
T301 Transmission of Reception of Go to RRC_IDLE
RRCConnectionReestabil RRCConnectionReestablishmen
shmentRequest t or
RRCConnectionReestablishmen
tReject message as well as
when the selected cell becomes
unsuitable
T302 Reception of Upon entering Inform upper layers about
RRCConnectionReject RRC_CONNECTED and upon barring alleviation as specified in
while performing RRC cell re-selection [R07] section 5.3.3.7
connection establishment
T303 Access barred while Upon entering Inform upper layers about
performing RRC RRC_CONNECTED and upon barring alleviation as specified in
connection establishment cell re-selection [R07] section 5.3.3.7
for mobile originating
calls
T304 Reception of Criterion for successful In case of cell change order
RRCConnectionReconfig completion of handover to from E-UTRA or intra E-UTRA
uration message EUTRA or cell change order is handover, initiate the RRC
including the met (the criterion is specified in connection re-establishment
MobilityControl Info or the target RAT in case of inter- procedure; In case of handover
reception of RAT) to E-UTRA, perform the actions
MobilityFromEUTRACom defined in the specifications
mand message including applicable for the source RAT.
CellChangeOrder
T305 Access barred while Upon entering Inform upper layers about
performing RRC RRC_CONNECTED and upon barring alleviation as specified in
connection establishment cell re-selection [R07] section 5.3.3.7
for mobile originating
signalling
T310 Upon detecting physical Upon receiving N311 If security is not activated: go to
layer problems i.e. upon consecutive in-sync indications RRC_IDLE else: initiate the
receiving N310 from lower layers, upon connection re-establishment
consecutive out-of-sync triggering the handover procedure
indications from lower procedure and upon initiating
layers the connection re-establishment
procedure
T311 Upon initiating the RRC Selection of a suitable E-UTRA Enter RRC_IDLE
connection re- cell or a cell using another RAT.
establishment procedure
T320 Upon receiving t320 or Upon entering Discard the cell reselection
upon cell (re)selection to RRC_CONNECTED, when priority information provided by
E-UTRA from another PLMN selection is performed on dedicated signalling.
RAT with validity time request by NAS, or upon cell
configured for dedicated (re)selection to another RAT (in
priorities (in which case which case the timer is carried
the remaining validity on to the other RAT).
time is applied).
T321 Upon receiving Upon acquiring the information Initiate the measurement
measConfig including a needed to set all fields of reporting procedure, stop
reportConfig with the cellGlobalId for the requested performing the related
purpose set to reportCGI cell, upon receiving measConfig measurements and remove the
that includes removal of the corresponding measId
reportConfig with the purpose
set to reportCGI
Table 11 : UE Timer Stop and Start Summary
Page 185/289
7.5.1.4 RRC CONNECTION RE-ESTABLISHMENT
Purpose: Re-establish the SRB1, SRB2 and DRB(s) and resume normal operation
Call flow
UE ENB
Trigger for RRC Re- Possible RL Failure

establishment detection
(UL L1 or DL RLC-AM)
SRB1, SRB2, DRB(s): CallP creates the new DL MAC context in dormant state for SRB2 and DRB(s) (i.e.
- re-establish PDCP as in case of mobility in the target eNB). The UL MAC is ready to receive
T311 - reset MAC Other option for suspension (not retained): PDCP SDU level
- re-establish RLC
- suspend SRB2, DRB(s)
RRCConnectionReestablishmentRequest
(CCCH)
L1, MAC, RLC
Add new ctx for SRB1,
SRB2, DRB(s) Requirements on PDCP for PDCP re-establishment:
- new command from CallP to PDCP
T301 Implies
PDCP re-establishment
PDCP entity is maintained and no data loss for RLC AM.
SRB1, SRB2, DRB(s)
- Re-initiliaze ROHC ctx for DRB(s)
- Reset PDCP SN+HFN for RLC-UM DRB and SRB1+2
L1, MAC, RLC - Maintain PDCP SN+HFN for RLC-AM DRB
Delete old ctx for SRB1, - New RLC SAPs provided to PDCP
SRB2, DRB(s) - PDCP resend data to DL RLC if RLC is AM .
RRCConnectionReestablishment (CCCH) Summary: same PDCP behaviour as intraNodeB HO with the difference that
PCDP will not be waiting for the end marker from the old RLC entity for doing the
RRCConnectionReestablishmentComplete reset, reinitialise, etc...
(DCCH)
Resume SRB2, DRB(s) SRB2 and DRB(s) are resumed by CallP notification to MAC DL at (TBC)
reception of RRCConnectionReconfigurationComplete
Resume DL SRB2,
DRB(s)
UE ENB
Figure 46: RRC Connection Re-Establishment call flow
Initial state:
UE in RRC Connected mode with SRB1, SRB2 and DRB(s) established. If the re-
establishment trigger occurs in the UE during SRB1 only state the UE moves to idle
mode as required by 3GPP RRC.
Trigger
eNB detects RL failure (UL L1 failure, DL RLC-AM failure), or
UE initiates RRC Connection Re-establishment procedure
Page 186/289
o RL failure detection (L1/L2) no timer eNB side but t310 started UE

side
o Handover failure
o Mobility from E-UTRA failure

Note: If the eNB initiates the procedure, then a timer of duration determined the value
of parameter rrcProcedureDefenseTimer is started when the eNB sends a
RRCReconfigurationReEsatblishmentRequest message. The timer is cancelled when
a UE response is received. If the timer expires, then the procedure is failed, and the
context is cleared.
• t301: This UE timer is started upon transmission of

RRCConnectionReestablishmentRequest and is stopped upon reception of
RRCConnectionReestablishment or RRCConnectionReestablishmentReject.
UeTimers::t301
Parameter t301
[ms100, ms200, ms400, ms600, ms1000, ms1500, ms2000]
Value ms1500
Feature L96760
• t311: This UE timer is started upon initiating the RRC connection re-
establishment procedure and is stopped when a suitable cell has been selected.
UeTimers::t311
Parameter t311
[ms1000, ms3000, ms5000, ms10000, ms15000, ms20000,
ms30000]
Value Ms5000
Feature L96760

allows controls to be applied to retard the rate of RRC connection re-establishments.
In this case, either a minor or a major overload condition may be exist, as discussed in
Page 187/289
LPUG [Vol. 4]. The rate at which RRC connection re-establishments are rejected is
controlled by two configuration parameters as described in the following paragraphs.
rrcCnxReestabRejectRateMinor: This parameter defines the rate R at which
incoming RRC Re-Establishment Requests are rejected during a Minor Overload
condition. One out of R requests is rejected, unless R equals zero in which case none
are rejected.
OverloadControl::rrcCnxReestabRejectRateMinor
Parameter rrcCnxReestabRejectRateMinor
0 to 10, step 1
Value 0
Feature L115241
rrcCnxReestabRejectRateMajor: This parameter defines the rate R at which

incoming RRC Re-Establishment Requests are rejected during a Major Overload
condition. One out of R requests is rejected, unless R equals zero in which case none
are rejected.
OverloadControl::rrcCnxReestabRejectRateMajor
Parameter rrcCnxReestabRejectRateMajor
0 to 10, step 1
Value 5
Feature L115241
7.5.2 SIGNALLING CONNECTION MANAGEMENT
7.5.2.1 DEDICATED S1 ESTABLISHMENT CONTROL

PROCEDURE
Purpose: to establish the S1 dedicated (logical) connection over S1 triggered by the

reception of RRC CONNECTION SETUP COMPLETE message ending the RRC
Connection establishment procedure.
The S1 dedicated connection is a logical connection at S1-AP level uniquely
identified by the eNB S1 UE identity in the eNB and MME S1-AP UE identity in the
MME. This logical connection is carried over a common Transport layer (i.e. SCTP
association and SCTP streams are not dedicated per UE)
Page 188/289
Call flow
Figure 47 : S1 Estabablishment Controle procedure scenario call flow
Initial state
eNB initiated the RRC Connection establishment procedure.

Trigger
The reception of the RRC message RRC CONNECTION SETUP COMPLETE will
trigger the S1 dedicated connection establishment.
ENB performs selection of MME based on S1-flex functionality.
ENB performs S1 Transport Layer ADMISSION CONTROL
The eNB allocates a “eNB UE identity” to uniquely identify the UE over the S1
connection. The identity is stored in the UE context.
The eNB sends the S1-AP message INITIAL UE MESSAGE including the “eNB UE
identity” and the NAS PDU received in the RRCConnectionSetupComplete message
.
If the RRCConnectionRequest included the ue-Identity set to S-TMSI the eNB will
include it in the INITIAL UE MESSAGE message.
Defense mechanism: a guard timer with a duration that is controlled by the value of
the Enb::s1APinitUeMsgTimer parameter is started on INITIAL UE MESSAGE
transmission. The timer is stopped at reception of either a S1-AP DL NAS
TRANSPORT or S1-AP INITIAL UE CONTEXT SETUP REQUEST, i.e. based on the
Page 189/289
NAS signalling: the MME may respond with one or the other. If this timer expires, then
the eNB releases the RRC connection and deletes the UE context.
In either case, the MME will allocate a MME UE identity to uniquely identify the UE
over the S1 dedicated connection. The eNB will store this identity in the UE context.
The eNB will use the “eNB UE identity” and “MME UE identity” for any subsequent
UE dedicated signalling exchange with the MME requiring UE dedicated logical
connection (e.g. dedicated procedure).
Enb::s1APinitUeMsgTimer
Parameter s1APinitUeMsgTimer

[1 to 60] step = 1
Value 30
Feature
An additional defense mechanism is provided by a timer with duration controlled by

the s1APProcedureDefenseTimer parameter (see Section 5.2).
Final state
S1 dedicated connection established. eNB will execute the NAS transfer procedure or
Default E-RAB based on the message received from the MME.
7.5.3 CONTEXT MANAGEMENT
7.5.3.1 INITIAL CONTEXT SETUP
Purpose: to establish the first E-RAB(s) and activate the Access Stratum (AS)
security.
In addition to the E-RAB context, the MME may transmit information to be used by the
eNB:
- the UE security context to activated security over radio interface
- UE capabilities
- NAS-PDU(s)
Call flow is shown in Figure 47.
Page 190/289
Initiated when only

SRB1is established (i.e.,
prior to establishment of
SRB2 and/or DRBs)
Integrity protected but not ciphered
Integrity protected and ciphered

Integrity protected but not
ciphered
Integrity protected and

ciphered
Figure 48 : Initial Context Setup scenario call flow
Initial state: SRB1 is established. The S1 dedicated connection may be already

established (if DL NAS transfer already took place).
Trigger: reception of the S1-AP INITIAL CONTEXT SETUP REQUEST over the S1
for a UE identified with a UE context Id allocated by the eNB in previous INITIAL UE
MESSAGE.
UE radio capability handling:
If the IE UE Radio Capability is not included in the S1-AP INITIAL CONTEXT SETUP
REQUEST, the eNB will initiate the RRC UE capability transfer procedure on SRB1
prior to security activation. The eNB transmits the message UECapabilityEnquiry
including “e-utra” and “utra” in ue-RadioAccessCapRequest.
On reception from the UE of UECapabilityInformation, the eNB will store
ueCapabilitiesRAT-Container with the rat-Type set to eutra and use it for the DRBs
establishment. The eNB will transmit the S1-AP UE CAPABILITY INFO INDICATION
including in the IE UE Radio Capability the IE RRC ueCapabilitiesRAT-Container after
the successful execution of the Initial Context setup procedure. The eNB will also store
the ueCapabilitiesRAT-Container with the rat-Type set to utra if the UE provided it, but
will not send it to the MME. After the UE capability transfer procedure the eNB
continues with security activation procedure.
Defense mechanisms:
Page 191/289
- an internal guard timer of duration determined by the value of parameter

RRCProcedureDefenseTimer (see Section 7.5.1.3.2) is armed on
transmission of UECapabilityEnquiry and stopped on reception from the UE of
UECapabilityInformation,
If the IE UE Radio Capability is included in the S1-AP INITIAL CONTEXT SETUP
REQUEST the eNB will store ueCapabilitiesRAT-Container and with the rat-Type set
to eutra and use it for the DRBs establishment. The eNB continues with security
activation procedure.
Rule: Regarding L97925: X2 Operation in Multi-release Sw Environment:
Handover Restriction List, Subscriber Profile ID for RAT/Frequency priority, SRVCC

Operation handling:
The eNB will store Handover Restriction List, Subscriber Profile ID for
RAT/Frequency priority and SRVCC Operation possible received in S1AP Initial
Context Setup message and forward it at X2 handover in X2AP HANDOVER
REQUEST message.
Subscriber Profile ID for RAT/Frequency priority will also be forwarded in case of S1
Handover in S1AP HANDOVER REQUIRED message, in IE Source to Target
Transparent Container.
AS security activation
The eNB will initiate the Security activation over the radio interface prior to
establishment of SRB2 and/ or DRBs. The eNB will perform
- key derivation function and integrity/ciphering algorithm selection.
- Configure PDCP to start integrity protection using the key and the algorithm
determined at previous step on all DL and UL RRC messages on SRB1 including
the SecurityModeCommand message.
- Configure PDCP to start ciphering using the key and algorithm determined at
previous step on all DL RRC messages on SRB1 subsequent to
SecurityModeCommand message
- Configure PDCP to start deciphering using the key and algorithm determined at
previous step on all UL RRC messages on SRB1 after the first RRC message has
successfully passed the integrity check (i.e. SecurityModeComplete)
- Transmit the SecurityModeCommand to initiate the AS security using the
configure the integrity protection and ciphering algorithms determined at previous
step. A timer of duration determined by the value of parameter
rrcProcedureDefenseTimer (see Section 7.5.1.3.2) is started for protection when
the SecurityModeCommand message shown in Figure 47 is sent to the UE. The
timer is stopped on reception of the SecurityModeComplete message from the
UE.
Page 192/289
- Initiate the SRB2 and DRB(s) establishment procedure without waiting for
SecurityModeComplete reception from UE
SRB2 and DRB(s) establishment

For each E-RAB to be setup received in the S1-AP INITIAL CONTEXT SETUP
REQUEST, the eNB will
- Perform E-RAB matching (see Section 7.5.6.1) based on requested S1 QoS (e.g.
QCI, MBR, GBR) and UE capabilities.
- And select associated L1/L2 dedicated resources configuration.
- Perform Admission Control based on configuration parameters (i.e.

RadioCacConf::maxNbOfDataBearersPerUe) and on QoS associated to the
radio bearer selected by the bearer matching algorithm. See Volume 4 for
additional detail.
- Configure the S1 U-plane with UL Transport Layer Address and GTP TEID.
- Configure the radio L2 U-plane (MAC, RLC) based on radio bearer QoS and
allocate associated resources. Provide to UL/DL MAC schedulers the QoS
parameters associated to the requested QCI (i.e. Priority, PDB, PLR) together with
the QCI as well as the received S1 QoS parameters (AMBR, GBR, MBR, etc).
Note that Feature 92095 provides the capability to define customized QoS classes
through the use of configuration parameters (see Volumes 3 and 4 for additional
detail.)
- Activate Integrity Protection and ciphering for SRB2 and ciphering for DRB(s)
using the algorithms and keys.
The eNB will initiate the RRC procedure to setup the radio bearers for which
ADMISSION CONTROL passed.
The eNB will include in the RRCConnectionReconfiguration message the IE
RadioResourceConfigDedicated for SRB2 and DRB(s) associated with the E-RAB ID
(s) (received in the INITIAL CONTEXT SETUP REQUEST), and the NAS-
DedicatedInformationList including NAS PDU(s) if received in the S1-AP INITIAL
CONTEXT SETUP REQUEST (e.g. Attach Accept)
Defense mechanisms:
- an internal guard timer is armed on transmission of SecurityModeCommand
and stopped on reception of RRCConnectionReconfigurationComplete
UE is in RRC connected state. SRB1 is established.
• rrcOnlyCnxLifeTime: This timer is started by eNB for a given UE when the first
dedicated message is received from the MME (Initial Context Setup Request or
Downlink NAS Transport). The timer is stopped when a transport bearer is
established.
Page 193/289
TrafficBasedReleaseConf::rrcOnlyCnxLifeTime
Parameter rrcOnlyCnxLifeTime
Object ENBEquipment/Enb/RrmServices/TrafficBasedReleaseConf
Range & Unit milliseconds

[1000..86400] step = 1
Value 14000
Feature L96760
If the procedure is successful on the UE side, it will transmit

RRCConnectionReconfigurationComplete. On successful RRC procedure
termination, the eNB will respond to the MME with S1-AP INITIAL CONTEXT SETUP
RESPONSE including the list of E-RAB successfully established and their S1 U-plane
DL Transport address and eNB TEID and the procedure successfully ends..
If the activation flag isTrafficBasedContextReleaseAllowed in the MO
ActivationService is set to TRUE the eNB will start DL U-plane Traffic Volume
Monitoring at UE level based on the configuration parameters in the MO
TrafficBasedReleaseConf [The parameters are described in the section 7.5.6.2]..
The UE may start sending UL data after the reception of the RRC CONNECTION
RECONFIGURATION and the procedure is successful on the UE side.
As part of this procedure, UE timer t304 is started in the UE in connected mode

upon reception of RRCConnectionReconfiguration message including the
MobilityControl Information or reception of MobilityFromEUTRACommand message.
At timer expiry the UE initiates the RRC connection re-establishment procedure.
Sent in MobilityFromEUTRACommand and RRCConnectionReconfiguration. See [Vol.
6] for additional information about timer t304.
DL data may start after the MME received the S1-AP INITIAL CONTEXT SETUP
RESPONSE message.
Final state
U-plane (radio and S1) is established and ready for data transmission.
7.5.3.2 UE CONTEXT RELEASE
7.5.3.2.1 UE CONTEXT RELEASE MME TRIGGERED
Purpose: This procedure is initiated by the MME to release of all E-RABs for a UE,
including all S1-U bearers and Radio bearers and the S1-MME signalling connection
for the UE. Note: in some cases the UE may notify the MME using NAS signaling of
“UE switchoff”. This can result in the eNB receiving a UE context release command
even though no there may be no E-RAB to be released.
Page 194/289
Call flow
UE ENB MME
S1AP UE CONTEXT RELEASE COMMAND

Peg UEContextReleaseCommand eNB S1-AP UE Identity
(NormalRelease or AuthenticationFailure or Detach) MME S1-AP UE Identity
Peg UEContextReleaseCommandSum Cause
Peg NormalERABRelease(QCI[1..9]) OR
Peg AbnormalERABReleasePerQCI(QCI[1..9])
RRCConnectionRelease (IP, Ciphering)

ReleaseCause
Peg NbUeRrcConnected(-1])
Release internal resources
S1AP UE CONTEXT RELEASE COMPLETE

MME S1-AP UE Identity
eNB S1-AP UE Identity
UE ENB MME
Figure 49 : UE Context Release MME triggered scenario call flow

Initial state: connected mode. 1 or more E-RABs are established.
Trigger: reception of S1-AP UE CONTEXT RELEASE COMMAND

At the reception of the S1-AP UE CONTEXT RELEASE COMMAND, the eNB will
initiate the RRC procedure to release the RRC Connection and any remaining RB.
If the cause received in the S1-AP UE CONTEXT RELEASE COMMAND is " load-
balancing-tau-required", the ENB shall use cause " loadBalancingTAUrequired " in
the RRCConnectionRelease, and "other" in all other cases.
The eNB will send the S1-AP UE CONTEXT RELEASE COMPLETE after transmitting
the RRC CONNECTION RELEASE to the UE.
Since RRC CONNECTION RELEASE is not acknowledged at RRC layer an internal
mechanism is supported to allow the RRC message transmission before eNB
resources deletion.
This mechanism is based on internal timer. The timer is started on RRC message
transmission and when the timer expires, the UE context and associated resources
are deleted.
After the UE context is deleted the Transport Layer ADMISSION CONTROL is
updated as well as Radio ADMISSION CONTROL.
.
Final state: This procedure results in the UE state in MME being set to LTE_IDLE,
and, in the eNB, all UE related context information is deleted.
Page 195/289
7.5.3.2.2 UE CONTEXT RELEASE ENB TRIGGERED
Purpose: allows eNB to request the MME to release all E-RABs for a UE, including
all S1-U bearers and Radio bearers and the S1-MME signalling connection for the UE
Call flow
Figure 50 : UE Context Release eNB triggered scenario call flow

Initial state: connected mode. One or more E-RABs are established.
Trigger:
- U-plane inactivity detection based on Traffic Volume monitoring if Traffic
Based Release is activated (see section 7.5.6.2).
- RL failure
UL RL failure detected by the eNB.
DL RL failure reported by the UE in RRC
- eNB internal failure, defense mechanisms
- Inter-RAT mobility :
The eNB receives from the UE a RRC Measurement Report message
associated with (inter-RAT) Event A2 previously setup by
the eNB.
The eNB sets cause='Inter-RAT Redirection' in the S1AP
UE CONTEXT RELEASE REQUEST message sent to the MME.
- CAC audit determines that UE context exceeds maximum allowed lifetime (see
Section 7.5.1.3.2).
The eNB initiate the procedure by sending the S1-AP UE CONTEXT RELEASE
REQUEST message.
If the MME accepts the request, it will initiate the S1 Release procedure. At the
reception of S1-AP UE CONTEXT RELEASE COMMAND, the eNB release the UE
Context.
Page 196/289
Final state: This procedure results in the UE state in MME being set to LTE_IDLE,
and, in the eNB, all UE related context information is deleted.
Defense mechanisms: In the absence of MME response S1-AP UE CONTEXT
RELEASE REQUEST is repeated several times. The retry interval is controlled by the
value of the s1APProcedureDefenseTimer parameter as described in Section 5.2.
7.5.3.2.3 UE CONTEXT RELEASE ENB TRIGGERED FAILURE

CASES
On the following events:

- no MME response after repeated S1-AP UE CONTEXT RELEASE REQUEST
transmission (The retry interval is controlled by the value of the
s1APProcedureDefenseTimer parameter as described in Section 5.2.)
the procedure is failed and eNB initiates the RRC Connection release procedure and
will locally delete the UE context and any associated resources.
Procedure interactions:
If after S1-AP UE CONTEXT RELEASE REQUEST transmission and before reception
of S1-AP UE CONTEXT RELEASE COMMAND, the eNB receives
- a S1-AP DL NAS TRANSPORT, the eNB will execute the RRC NAS transfer
procedure
- a RRC ULInformationTransfer, the eNB will execute the S1-AP NAS transfer
procedure
- a S1-AP E-RAB SETUP REQUEST or S1-AP E-RAB RELEASE COMMAND the
eNB ignores this message and continues with the release.
Page 197/289
7.5.4 BEARER MANAGEMENT

allows controls to be applied to retard the rate of S1 RAB setup requests. In this case,
either a minor or a major overload condition may be exist, as discussed in LPUG [Vol.
4]. The rate at which S1 RAB setup requests are rejected is controlled by two
configuration parameters as described in the following paragraphs.
s1RabSetupReqRejectRateMinor: This parameter defines the rate R at which
incoming S1 E-RAB Setup Requests are rejected during a Minor Overload condition.
One out of R is rejected, unless R equals zero in which case none are rejected.
OverloadControl::s1RabSetupReqRejectRateMinor
Parameter s1RabSetupReqRejectRateMinor
0 to 10, step 1
Value 10
Feature L115241
s1RabSetupReqRejectRateMajor: This parameter defines the rate R at which

incoming S1 E-RAB Setup Requests are rejected during a Major Overload condition.
OverloadControl::s1RabSetupReqRejectRateMajor
Parameter s1RabSetupReqRejectRateMajor
0 to 10, step 1
Value 5
Feature L115241
7.5.4.1 DEFAULT E-RAB ESTABLISHMENT
7.5.4.1.1 MOBILE ORIGINATED DEFAULT E-RAB ESTABLISHMENT

HIGH LEVEL PROCEDURE
Applicable end-to-end scenario:

• attach (registration) with default E-RAB establishment
• TAU with activity flag set to TRUE
• UE triggered Service request
Page 198/289
Purpose: Establishes the default E-RAB for a UE in idle mode.
Pre-conditions:
• Cell setup
• S1 setup
Initial state:
• UE in idle mode
• No UE context in the eNB.
Applicable eNB procedures:
• RRC Connection Establishment

• Dedicated S1 establishment
• NAS signalling transfer
• Default E-RAB setup (this section)
Final state
• UE in RRC connected mode, UE context in the eNB
• Default E-RAB established
The “Attach” scenario call flow is the following
Page 199/289
Figure 51: “Attach” scenario call flow in the case default E-RAB establishment
Note: the EPC signalling is provided only for information in order to present the eNB
behaviour. Not all the scenarios and messages are shown.
From the eNB point of view it is transparent whether the attach is performed with IMSI
or S-TMSI. In case of S-TMSI, the MME may initiate the UE identity request
procedure towards the UE via an eNB NAS transfer procedure (possibly followed by
the Authentication procedure).
The only difference for the eNB is that following the S1-AP Initial UE message
(carrying the attach NAS message) the eNB may receive either a S1-AP NAS
Transfer message (typically for S-TMSI attach but with a UE identification request) or
a S1-AP Initial Context Setup procedure. The eNB should be prepared to receive
any of the two messages and should not make any assumption on the UE-MME NAS
signalling procedure.
The “Service request” scenario is the following:
Page 200/289
Figure 52: “Service request” scenario call flow in the case default E-RAB establishment
7.5.4.1.2 MOBILE TERMINATED DEFAULT E-RAB

ESTABLISHMENT HIGH LEVEL PROCEDURE

• EPC triggered service request
Pre-conditions:
• Cell setup
• S1 setup
Initial state:
• UE in idle mode

• Paging
• Dedicated S1establishment
• Default E-RAB setup
Page 201/289
Final state
• UE in RRC connected mode, UE context in the eNB
• Default E-RAB established
Figure 53: “Mobile Terminated” call flow in the case default E-RAB establishment
Support of partial failures during Initial Context Setup and E-RAB setup is always
enabled - the eNB continues to setup the remaining radio bearers in case one of radio
bearers fails to be setup.
7.5.4.2 DEDICATED E-RAB ESTABLISHMENT
7.5.4.2.1 DEDICATED E-RAB ESTABLISHMENT HIGH LEVEL

PROCEDURE

• Dedicated EPS bearer activation
Initial state:
• UE in connected mode
• Default E-RAB is already setup
• E-RAB setup (one or more dedicated bearers)
Final state
Page 202/289
• Default and Dedicated E-RAB (one or more) are established.
Figure 54 : Dedicated E-RAB Establishment scenario call flow
7.5.4.2.2 DEDICATED E-RAB SETUP CONTROL PROCEDURE
Purpose: Establish new E-RAB(s) (after the Initial Context Setup procedure)
Call flow
Page 203/289
UE ENB MME
S1 E-RAB SETUP REQUEST

Retrieve in the UE security context:

- the selected Ciphering algorithm
- the current KUP enc security key
DRB establishment
(L2 ressources allocation)
Start DL ciphering on new DRB
Start UL deciphering on new DRB
nas-DedicatedInformationList
RadioResourceConfigDedicated (DRB(s)) Integrity Protected and Ciphered
(SRB1 previously setup and protected)
Start DL deciphering on new DRB
Start UL ciphering on new DRB
Integrity Protected and Ciphered
S1 E-RAB SETUP RESPONSE
(SRB1 previously setup and protected
E-RAB Setup List
UE ENB MME
Figure 55 : Dedicated E-RAB Control procedure scenario call flow with security (L92638)
activated
Initial state:
SRB1, SRB2, Default E-RAB and possibly another dedicated DRB are established.
AS security is activated.
Trigger: reception of the S1-AP E-RAB SETUP REQUEST over the S1 dedicated
connection.
Rule: Regarding L92638:

In Dedicated E-RAB Setup procedure:
no algorithm selection is performed since the current Ciphering algorithm will be used
for the new DRB.
no security key derivation is performed since the current KUPenc will be used for the
new DRB.
For each E-RAB to be setup received in the S1-AP E-RAB SETUP REQUEST the
eNB will
Page 204/289
- perform E-RAB matching based on requested S1 QoS (e.g. QCI, MBR, GBR)
and UE capabilities and select associated L1/L2 dedicated resources
configuration. (including RB-id allocation)
- perform Admission Control based on MIM parameters (i.e.

RadioCacEnbf.maxNbOfDataBearersPerUe) [see [Vol. 4]] and QoS of the radio
bearer selected by the bearer matching algorithm.
Details on radio ADMISSION CONTROL

Transport Layer ADMISSION CONTROL
- Configure the S1 U-plane with UL Transport address and GTP TEID.
- Configure the radio L2 U-plane (MAC, RLC) based on received QoS and allocates
associated resources.
Provide to UL/DL MAC schedulers the standardized QoS parameters
associated to the requested QCI (i.e. Priority, PDB, PLR) together with the
QCI as well as the received S1 QoS parameters (e.g. AMBR, GBR, MBR,
etc).
If the UE Aggregate Maximum Bit Rate IE is included in the E-RAB SETUP
REQUEST the eNB replaces the previously provided UE Aggregate
Maximum Bit Rate by the received UE Aggregate Maximum Bit Rate in the
UE context; the eNB uses the received UE Aggregate Maximum Bit Rate for
non-GBR Bearers for the concerned UE. If the UE Aggregate Maximum Bit
Rate IE is not contained in the E-RAB SETUP REQUEST message, the eNB
uses the previously provided UE Aggregate Maximum Bit Rate which is
stored in the UE context.
Rule: Regarding L92483: Up to 8 Simultaneous Bearers per User
The eNB stores the last value of UE Aggregate Maximum Bit Rate received from
MME in S1AP E-RAB SETUP REQUEST message and forwards it at handover in
the X2AP HANDOVER REQUEST message.
- Create and configure the PDCP entities, activate DL ciphering and UL deciphering
for the new DRB(s) using the algorithms and keys.
- Update the DL U-plane Traffic Volume Monitoring function.
The eNB will initiate the RRC procedure to setup the radio bearers for which the
ADMISSION CONTROL passed by sending the RRCConnectionReconfiguration
(integrity-protected and ciphered message) to the UE. Partial failure is supported.
The eNB will include in the RRCConnectionReconfiguration message the IE
RadioResourceConfigDedicated for DRB(s), the associated with the E-RAB ID
(received in the S1-AP E-RAB SETUP REQUEST), and the nas-
DedicatedInformationList including NAS PDU(s) if received in the E-RAB SETUP
REQUEST.
Page 205/289
If the procedure is successful on the UE side, it will transmit an integrity-protected and

ciphered RRCConnectionReconfigurationComplete.The eNB will then respond to
the MME with S1-AP E-RAB SETUP RESPONSE including the list of E-RAB
successfully established and the procedure successfully ends.
On successful RRC procedure termination, the eNB will respond to the MME with S1-
AP E-RAB SETUP RESPONSE including the E-RAB successfully established and
their S1 U-plane DL Transport address and eNB TEID and the procedure successfully
ends.
The UE may start sending UL data after the reception of the
RRCConnectionReconfiguration message has been received and the procedure is
successful on the UE side.
DL data may start after the MME received the S1-AP E-RAB SETUP RESPONSE.
Final state
U-plane (radio and S1-u) is established for the new bearer(s) or DRB(s) requested,
and ready for data transmission. AS security (ie. ciphering) is activated for these
DRB(s).
Defense mechanism: The defense timer with duration controlled by the value of
parameter rrcProcedureDefenseTimer (see Section 7.5.1.3.2) is started on
transmission of RRC CONNECTION RECONFIGURATION and stopped on reception
of RRC CONNECTION RECONFIGURATION COMPLETE.
Procedure interactions:
If after S1-AP E-RAB SETUP REQUEST reception and before transmission of S1-AP
E-RAB SETUP RESPONSE, the eNB receives
- a S1-AP DL NAS TRANSPORT, the eNB will execute the RRC NAS transfer
procedure over SRB2
- a RRC ULInformationTransfer, the eNB will execute the S1-AP NAS transfer
procedure
- a S1-AP E-RAB SETUP REQUEST (or RELEASE) or S1-AP UE CONTEXT
RELEASE COMMAND the eNB will execute the corresponding S1-AP procedure
after the procedure ends (i.e. S1-AP E-RAB SETUP RESPONSE transmission)
- If at S1-AP E-RAB SETUP REQUEST reception, the eNB detects that new key
values are needed, the eNB will first execute an intra-cell handover to generate
additional keys. The eNB will then perform an RRC Reconfiguration procedure to
add the new E-RAB.
- If after S1-AP E-RAB SETUP REQUEST reception, and before transmission of
RRC Connection Reconfiguration, the eNB receives a notification from the PDCP
layer that keys need to be refreshed, then the eNB initiates an intra-cell handover
to refresh the security keys. Then the new E-RAB is setup. If the notification from
the PDCP layer is received after the RRC Connection Reconfiguration has been
transmitted, then the eNB completes the E-RAB setup procedure and then
performs the intra-cell handover.
Page 206/289
7.5.4.3 E-RAB RELEASE MME TRIGGERED
7.5.4.3.1 E-RAB RELEASE MME TRIGGERED HIGH LEVEL

PROCEDURE

• Dedicated E-RAB de-activation (EPC triggered)
Purpose: E-RAB is released at the request of the MME
Initial state:
• Dedicated E-RAB was setup

• E-RAB release
Final state
• Default E-RAB is established
• One or more E-RABs established
Figure 56 : E-RAB Release MME Triggered scenario call flow

Page 207/289
7.5.4.3.2 E-RAB RELEASE MME TRIGGERED CONTROL

PROCEDURE
Purpose: Execute the release requested by the MME of already established E-RABs
for a given UE
Call flow
Figure 57 : E-RAB Release MME Triggered Control Procedure scenario call flow
Initial state: SRB1 + default E-RAB is established+ dedicated E-RAB (s) (a maximum
of 4 Data bearers are allowed per UE, or up to 8 Data bearers if Feature 92483 is
enabled. More information regarding radio bearers and Feature 92483 can be found in
[Vol. 4] section 4 and [Vol. 3].)
Trigger: reception of S1-AP: E-RAB RELEASE COMMAND
Procedure description:
Upon reception of the E-RAB RELEASE COMMAND message the eNB shall execute
the release of the requested E-RABs (identified by E-RAB ID). RRC procedure is
initiated to release the corresponding Radio Bearers. The eNB shall pass to the UE in
the RRC CONNECTION RECONFIGURATION the value contained in the E-RAB
identity IE for each SAE Radio Bearer to be released and NAS PDU if received in the
S1-AP E-RAB RELEASE COMMAND.
Defense mechanism: The defense timer with duration controlled by the value of
parameter rrcProcedureDefenseTimer (see Section 7.5.1.3.2) is started on
Page 208/289
transmission of RRC CONNECTION RECONFIGURATION and stopped on reception

of RRC CONNECTION RECONFIGURATION COMPLETE
On successful termination of the RRC procedure, the eNB releases the allocated
resources on Uu.
The eNB shall release allocated resources on S1 for the E-RABs requested to be
released. Transport ADMISSION CONTROL is updated as well as Radio ADMISSION
CONTROL
If the UE Aggregate Maximum Bit Rate IE is included in the E-RAB RELEASE
COMMAND the eNB replaces the previously provided UE Aggregate Maximum Bit
Rate by the received UE Aggregate Maximum Bit Rate in the UE context; the eNB
uses the received UE Aggregate Maximum Bit Rate for non-GBR Bearers for the
concerned UE. If the UE Aggregate Maximum Bit Rate IE is not contained in the E-
RAB RELEASE COMMAND message, the eNB uses the previously provided UE
Aggregate Maximum Bit Rate which is stored in the UE context.
The eNB will report to the MME, in the E-RAB RELEASE COMPLETE message, the
result for all the E-RABs to be released.
The eNB shall be prepared to receive an E-RAB RELEASE COMMAND message on
an established UE-associated logical S1-connection containing an E-RAB Release
List IE at any time and shall always reply to it with an E-RAB RELEASE COMPLETE
message.
After sending an E-RAB RELEASE RESPONSE message containing an E-RAB
identity within the E-RAB Release List IE, the eNB shall be prepared to receive an E-
RAB SETUP REQUEST message requesting establishment of an E-RAB with this E-
RAB identity.
Final state:
Connected state with remaining SRB1 + default bearer established + remaining
dedicated E-RAB (s)
7.5.4.4 E-RAB MODIFY MME TRIGGERED
The purpose of the MME Triggered E-RAB Modify procedure is to enable

modifications of already established E-RAB(s) for a given UE.
The following QoS parameters are supported for modification:
- GBR
- AMBR
- AMBR + GBR
- QCI for nonGBR bearer
- ARP
Page 209/289
In LR13.1, feature L115644 supports modification of QCI and ARP (including priority
level, pre-emption capability, and pre-emption vulnerability) only if parameter
isQciArpOnLineModificationEnabled is set to True. This flag is not a license and is
disabled by default.
QCI change is only applicable to E-RAB with initial QCI and modified QCI that are
both of non-GBR type. Modification of QCI 5 is also not allowed to avoid impact on
VoIP. Change of ARP does not impact an ongoing reactive load control and
preventive load control. The new ARP is taken into account in next reactive load
control and preventive load control.
The eNB does not support ARP changes for an LTE emergency IMS call bearer. That
is, the eNB will reject E-RAB Modify with ARP modification for a bearer with ARP
priority level = PlmnIdentity::arpPriorityEmergency, with failure cause “Radio
Network Layer Cause / Invalid QoS”.
The eNB does not support modification of ARP priority that would convert the bearer
into an emergency call. That is, the eNB will reject E-RAB Modify with ARP priority
level modified to PlmnIdentity::arpPriorityEmergency, with failure cause “Radio
Network Layer Cause / Invalid QoS”.
QCI modification is only supported for non-GBR bearers. That is, the eNB will reject
E-RAB Modify if the old or new QCI is ≤ 5, with failure cause “Miscellaneous Cause /
Unspecified”.
If isQciArpOnLineModificationEnabled is set to False, then the eNB will fail E-RAB

Modify requests with QCI or ARP changes, with failure cause “Miscellaneous Cause /
O&M Intervention”.
ActivationService::isQciArpOnLineModificationEnabled
Parameter isQciArpOnLineModificationEnabled
[false, true]
Value false (default)
Feature L115644
Inter-Release Delta: isQciArpOnLineModificationEnabled

allows controls to be applied to retard the rate of S1 RAB modify requests. In this
Page 210/289
case, either a minor or a major overload condition may be exist, as discussed in LPUG
[Vol. 4]. The rate at which S1 RAB modify requests are rejected is controlled by two
configuration parameters as described in the following paragraphs.
s1RabModifyReqRejectRateMinor: This parameter defines the rate R at which
incoming S1 E-RAB Modify Requests are rejected during a Minor Overload condition.
OverloadControl::s1RabModifyReqRejectRateMinor
Parameter s1RabModifyReqRejectRateMinor
0 to 10, step 1
Value 10
Feature L115241
s1RabModifyReqRejectRateMajor: This parameter defines the rate R at which

incoming S1 E-RAB Modify Requests are rejected during a Major Overload condition.
OverloadControl::s1RabModifyReqRejectRateMajor
Parameter s1RabModifyReqRejectRateMajor
0 to 10, step 1
Value 5
Feature L115241
7.5.4.4.1 E-RAB MODIFY EPC TRIGGERED HIGH LEVEL

PROCEDURE

• EPC triggered E-RAB modification
Purpose: E-RAB is modified at the request of the MME
Initial state:
• Dedicated E-RAB was setup
Page 211/289
• E-RAB modify
Final state
• Default E-RAB remains established

• One or more E-RABs modified
Serving PDN
UE eNB MME PCRF
SAE- GW SAE -GW
(1 . PCRF Session Modification begin )
Update Bearer Request
Update Bearer Request
S1- AP : E-RAB Modify Request

(Session Management Configuration )
RRC Connection Reconf
(Session Management Configuration )
RRC Connection Reconf Cmplt
S1- AP : E-RAB Modify Response

UL NAS Transfer
(Session Management Response )

UL NAS Transport
(
Session Management Response )
Update Bearer Response
Update Bearer Response
(10. PCRF Session Modification end )
Figure 58 : EPC Triggered ERAB Modification

Note: the EPC signaling is provided only for information in order to present the eNB behavior.
Not all the scenarios and messages are shown.
7.5.4.4.2 E-RAB MODIFY MME TRIGGERED CONTROL

PROCEDURE (EXCEPT FOR QCI MODIFICATION)
Purpose: Enable modifications of already established E-RAB(s) for a given UE. In

LR13.1, this procedure also supports ARP modification.
Call flow:
Page 212/289
Figure 59 : MME Triggered ERAB Modification (except QCI modification)
Initial state:
E-RAB
SRBs+Default or SRBs+Default+dedicated DRB(s) (could be up to 8 DRBs).
Trigger: reception of the S1-AP E-RAB MODIFY REQUEST over the S1 dedicated
connection.
For each E-RAB to be modified received in the S1-AP E-RAB MODIFY REQUEST the
eNB will
- Check that modified E-RAB IDs are known and that new received parameters
values can be accepted: only previously set values of an E-RAB configuration can
be modified.
- Perform E-RAB matching based on requested S1 QoS (e.g. ARP, MBR, GBR)
and UE capabilities, and select associated L1/L2 dedicated resources
configuration.
- Perform Admission Control based on MIM parameters (i.e.
RadioCacEnb::maxNbOfDataBearersPerUe) and QoS of the radio bearer
selected by the bearer matching algorithm.
details on radio ADMISSION CONTROL are in Radio Resource Management
Volume 4,
- Update the radio L2 U-plane (MAC, RLC) based on received QoS and allocates
associated resources.
Provide to UL/DL MAC schedulers the standardized QoS parameters
associated with the requested QCI (i.e. Priority, PDB, PLR) together with the
QCI as well as the received S1 QoS parameters (e.g. AMBR, GBR, MBR,
etc).
If the UE Aggregate Maximum Bit Rate (AMBR) IE is included in the E-RAB
MODIFY REQUEST, the eNB replaces the previously provided UE AMBR by
the received UE AMBR in the UE context; the eNB uses the received UE
AMBR for non-GBR Bearers for the concerned UE.
Page 213/289
The eNB stores the last value of UE AMBR received from MME in the S1AP
E-RAB MODIFY REQUEST message and forwards it at handover in X2AP
HANDOVER REQUEST and S1AP HANDOVER REQUEST messages.
The eNB will initiate the RRC Connection Reconfiguration procedure to send
associated NAS PDU(s) to the UE.
The eNB will include in the RRCConnectionReconfiguration message the IE nas-
DedicatedInformationList including NAS PDU(s) received for successfully modified in
the E-RAB MODIFY REQUEST; NAS PDUs associated to the failed-to-modify bearers
are however not sent to the UE.
As per Dec-09 (36.413) R3-093078 CR #606, the E-RAB ID is not provided to the UE
in RRCConnectionReconfiguration message in case of a successful E-RAB
modification.
On successful RRC procedure termination, the eNB will respond to the MME with S1-
AP E-RAB MODIFY RESPONSE including the E-RABs successfully modified and the
E-RABs failed to modify, and the procedure successfully ends.
Final state
DRB configuration is updated according to new E-RAB level QoS parameters and
AMBR.
Defense mechanism: an internal guard timer is armed on transmission of
RRCConnectionReconfiguration and stopped on reception of
7.5.4.4.3 E-RAB MODIFY MME TRIGGERED CONTROL

PROCEDURE FOR QCI MODIFICATION
In LR13.1, QCI modification is supported as described in 7.5.4.4. Each time a QCI is

changed by an E-RAB Modify Request message, the eNB also performs an intra cell
handover that induces the UE and modem L1, L2 configuration update of allowed
parameters.
Call flow:
Page 214/289
Figure 60: MME Triggered ERAB Modification for QCI Modification
If QCI is changed, and if the old QCI of the E-RAB and/or the target QCI have not both
type “non-GBR”, modification on this E-RAB fails and cause is set to “Miscellaneous
Cause / Unspecified”. Support of proprietary QCI is not required (because proprietary
QCI are implemented but not E2E validated in LA7); therefore it is required to support
changes of QCIs in range [6..9].
If QCI is changed: Radio CAC checks the limitation on number of data bearer per QCI
group if new QCI is in a different group, updates and checks the PRB consumption
since minBitRateForBE is now configured per QCI ; then pre-emption is triggered if
necessary. If fails finally, modification on this E-RAB fails and cause is set to “Radio
Network Layer Cause / Radio resources not available”, but each of the 2 root causes
pegs a different counter screen.
Transport CAC checks the limitation on transport resource per QCI. If fails finally,
modification on this E-RAB fails and cause is set to “Transport Layer Cause /
Transport Resource Unavailable”.
E-RAB matching is performed with new QCI. TS36.331 defines that in
RadioResourceConfigDedicated, IE pdcp-Config should not be sent in this case, and
in IE RLC-Config, the UM / AM mode cannot be changed (but parameters within the
mode can be changed). These definitions should be taken into account in E-RAB
matching. If E-RAB matching fails then modification on this E-RAB fails and cause is
set to “Radio Network Layer Cause / Invalid QoS combination”.
Page 215/289
Inter-freq and/or inter-RAT measurement is reconfigured based on new QCI if it leads

to change of eMCTA priority
7.5.5 NAS TRANSPORT
7.5.5.1 CONNECTION ESTABLISHMENT FOR NAS

SIGNALLING TRANSFER HIGH LEVEL PROCEDURE

• TAU update
Purpose: RRC Cnx and dedicated S1 connection are established to allow NAS
signalling transfer between the UE and the EPC
Pre-conditions:
• Cell setup
• S1 setup
Initial state:
• UE in idle mode

• Dedicated S1establishment
• UE context release
Final state:
Based on whether the UE has set the activity flag in the NAS TAU request message or
not:
- If the flag is not set (the UE does not request bearer setup):
• UE in idle mode
• No UE context in eNB
Page 216/289
Figure 61 : “Attach” scenario call flow in the case NAS SIGNALLING TRANSFER
If the flag is set (the UE does request bearer setup)

• UE remains in connected mode and MME initiates the default E-RAB establishment
Note: the use case is similar Mobile Originated default E-RAB establishment
7.5.5.2 NAS SIGNALLING TRANSFER CONTROL

PROCEDURE
Purpose: to transfer transparently NAS messages between the UE and the MME.
Call flow
Page 217/289
Figure 62 : NAS Signal. Transfer Control procedure scenario call flow
Initial state
Connected mode
Trigger:
UE RRC message for UL procedure. MME S1-AP message for DL procedure.
Case 1: NAS PDU received in RRCConnectionSetupComplete is included in the S1-
AP INITIAL UE MESSAGE
Case 2: NAS PDU received in the S1-AP DL NAS TRANSPORT is included in RRC
DLInformationTransfer and transmitted over SRB2 if established otherwise over SRB1
Case 3: NAS PDU received in the RRC ULInformationTransfer over SRB2 if
established or over SRB1 otherwise is included in the S1-AP UL NAS TRANSFER. If
a subsequent ULInformationTransfer is received before S1 dedicated is setup then the
message is stored and transmitted after the S1 dedicated is setup.
Case 4: NAS PDU received in S1-AP message other than S1-AP DL NAS
TRANSPORT (i.e. S1-AP INITIAL CONTEXT SETUP REQUEST, E-RAB SETUP
REQUEST or E-RAB SETUP RELEASE COMMAND ) will be included in the
RRCConnectionReconfiguration message.
The eNB will store Handover Restriction List received in DOWNLINK NAS
TRANSPORT message and forward it at handover in X2AP HANDOVER REQUEST
message.
Page 218/289
Final state
Connected mode
7.5.5.3 NAS IN-SEQUENCE DELIVERY
A capability is provided to help insure in-sequence delivery of NAS messages to the

UE. The implementation uses a configurable parameter called
dlNasDeliveryWaitTimeNoDRX. This parameter is used for a UE that is configured
without DRX. It specifies the maximum time Call-Processing waits for an
acknowledgment from the Modem, indicating delivery of a DL NAS message to the UE
over SRB2, before it sends any pending RRC + NAS messages or RRC Connection
Release to the UE for NAS in-sequence delivery. Refer to TS 36.331.
If the UE is configured with DRX, an additional time based on the DRX cycle time
configuration is added to the value of the dlNasDeliveryWaitTimeNoDRX parameter.
A value of zero (0) means this capability is disabled for both no DRX configured and
DRX configured cases. If a non-zero value is set, then in general a value of at least
2000 should be used. Otherwise, the selected value may be less than the sum of the
SRB scheduling delay and the delay associated with maximum RLC re-transmission
limit
Enb::dlNasDeliveryWaitTimeNoDRX
Parameter dlNasDeliveryWaitTimeNoDRX
Range & Unit Integer, milliseconds
0 to 3000, step 50
Value 1500
Feature L115225
A non-zero value is now recommended for dlNasDeliveryWaitTimeNoDRX to

support 3GPP compliance of in-sequence delivery of DL NAS messages. Note that
the recommended value for this parameter has been changed from 1500 to 2000.
7.5.6 RESOURCE MANAGEMENT
7.5.6.1 E-RAB MATCHING OVERVIEW
E-RAB Matching procedure determines the best suitable Radio Configuration when a
service is established, released or reconfigured. This function may also filter some
Page 219/289
multi-QCI configuration requested by the MME or the UE due to possible test

restrictions in the first releases.
The E-RAB Matching Procedure consists of six steps that are outlined in Table 12.
STEP ID STEP NAME STEP DESCRIPTION
S1 Parameters checking
Step 1 1. VoIP Bearer Detection Detection of a VoIP bearer (RTP) is based on S1AP
Parameters (QoS parameters like QCI, GBR and
MBR) and MIM parameters (i.e. RadioCacCell.
qCIforVoipRtpRtcp)
Step 2 2. Bit Rate Estimation Bit Rate Estimation is simple and optimized since it
retrieves the UL/DL GBR, UL/DL MBR and UL/DL
AMBR from S1AP parameters. There is no estimation
of any UL/DL minimum bit rate for the requested bearer
for which no UL/DL GBR is requested.
ARP information encapsulated in the S1AP E-RAB
level QoS parameters IE will be ignored
Step 3 3. QCI supported The MIM configures for each 3GPP defined QCI if the
eNB supports it or not. If the requested S1 QCI is not
configured as supported the eNB rejects the request.
Multi-Bearers Configuration Checking
Step 4 4. Multi-Bearers Multi-Bearers Configuration Filter filters out the

Configuration Filter associations of QCI that are not simultaneously
supported by the eNB for a UE
This function is based on the overall number of data
bearers (i.e. already configured and/or requested) for a
given UE configured by one CM parameter that fixes
the maximum number of data bearers that may be
configured for an UE, i.e.
RadioCacEnb::.maxNbOfDataBearersPerUe,
UE capability checking
Page 220/289
STEP ID STEP NAME STEP DESCRIPTION
S1 Parameters checking
Step 5 5. UE Capabilities UE Capabilities Checking verifies that the resulting

Checking multi-QCI configuration associated with the QoS of
each bearer is compliant with the UE capabilities.
The function does not determine any identifier of multi-
QCI configuration.
If featureGroupIndicators has been received from the
UE in UECapabilityInformation message, the supported
radio bearer combinations shall be checked and
relevant L1/L2 configurations determined.
If bit#2 is 1 (i.e. PUCCH format 2a and 2b), eNB sets
SimultaneousAckNackAndCQI the CQI-ReportConfig
IE to True for the UE or False, otherwise. FDD/TDD
cells always support PUCCH Format2a/2b.
If bit#7 is 0, no UM DRB is supported by UE; if it is 1
but bit#3 is 0, RLC UM for voice is possible but no
SPS.
If bit#20 is 0, the UE supports up to 4 AM DRB (+ up to
1 UM DRB if bit#7 is 1).
If bit#20 is 1, the UE supports:
- up to 8 AM DRBs, if bit#7 is set to 0
- up to 8 AM DRBs, or up to 5 AM DRBs + up to 3
UM DRBs, if bit#7 is set to 1
L1/L2 configuration selection
Step 6 6. Radio Bearer ID, Radio Radio Bearer ID, and associated Radio Configuration
Configuration Selection Selection determines the mandatory identifiers required
by the requested bearer
Radio Bearer ID (RB ID)
The L1/L2 configuration is selected from the MIM

configuration.
Table 12 : Bearer Management
Page 221/289
7.5.6.1.1 E-RAB LEVEL QOS PARAMETERS
Application / Service Layer
UL Traffic Flow Aggregates DL Traffic Flow Aggregates

UL-TFT DL-TFT
UL-TFT → RB-ID DL-TFT → S5/S8-TEID
RB-ID ↔S1-TEID S1-TEID ↔S5/S8-TEID
UE eNodeB
eNB Serving GW PDN GW
Radio Bearer S1 Bearer S5/S8 Bearer
Figure 63 : Two Unicast EPS bearers (GTP-based S5/S8)
[R01] section 4.7.2.2 specifies the following labels:
A Label Characteristic describes the bearer level packet forwarding treatment that is
expected from an access node (e.g. eNodeB). A standardized Label Characteristic
comprises the following elements:
1 Bearer Type (GBR or Non-GBR),

2 L2 Packet Delay Budget, and (more explanation in [Vol. 4])
3 L2 Packet Loss Rate. (more explanation in [Vol. 4])
A Label Characteristic is not signaled on any interface.
The Bearer Type determines if dedicated network resources related to a Guaranteed

Bit Rate (GBR) value that is associated with an EPS bearer are permanently
allocated (e.g. by an admission control function in the access node) at bearer
establishment/modification (see clause 4.7.2 in [R01]).
The L2 Packet Delay Budget (L2 PDB) denotes the time that a link layer SDU (e.g.,
an IP packet) may reside within the link layer between an access node and a UE.
The link layer may include a queue management function. For a certain Label
Characteristic the value of the L2 PDB is the same in uplink and downlink. The
purpose of the L2 PDB is to support the configuration of scheduling and link layer
functions (e.g. the setting of scheduling priority weights and HARQ target operating
points). (more explanation in [Vol. 4])
Page 222/289
NOTE: For Non-GBR bearers, the L2 PDB denotes a "soft upper bound" in the
sense that an "expired" link layer SDU, i.e. a link layer SDU that has exceeded the L2
PDB, does not need to be discarded (e.g. by RLC in E-UTRAN). The discarding
(dropping) of packets is expected to be controlled by a queue management function,
e.g. based on pre-configured dropping thresholds.
Sources running on a Non-GBR bearer should be prepared to experience congestion
related packet drops and/or per packet delays that may exceed a given L2 PDB. This
may for example occur during traffic load peaks or when the UE becomes coverage
limited.
Sources running on a GBR bearer and sending at a rate smaller than or equal to GBR
can in general assume that congestion related packet drops will not occur, and that
per packet delays will not exceed a given L2 PDB. Exceptions (e.g. transient link
outages) can always occur in a radio access system. The fraction of traffic sent on a
GBR bearer at a rate greater than GBR may be treated like traffic on a Non-GBR
bearer. (more explanation in [Vol. 4])
The L2 Packet Loss Rate (L2 PLR) determines the rate of SDUs (e.g. IP packets)
that have been processed by the sender of a link layer ARQ protocol (e.g. RLC in E-
UTRAN) but that are not successfully delivered by the corresponding receiver to the
upper layer (e.g. PDCP in E-UTRAN). Thus, the L2 PLR denotes a rate of non
congestion related packet losses. The purpose of the L2 PLR is to allow for
appropriate link layer protocol configurations (e.g. RLC and HARQ in E UTRAN). For a
certain Label Characteristic the value of the L2 PLR is the same in uplink and
downlink. (more explanation in [Vol. 4])
[R01] and 3GPP TS 23.203 specifies the following QCIs and associated L2
parameters:
Page 223/289
3GPP L2 PACKET
3GPP 3GPP 3GPP L2 PACKET
LABEL DELAY BUDGET 3GPP EXAMPLE SERVICES
QCI value Priority LOSS RATE (PLR)
(PDB)
GBR-1 1 (GBR) 2 100 ms 10-2 Conversational Voice

GBR-2 2 (GBR) 4 150 ms 10-3 Conversational Video (Live Streaming)
GBR-3 3 (GBR) 3 50 ms 10-3 Real Time Gaming
Non-Conversational Video (Buffered
GBR-4 4 (GBR) 5 300 ms 10-6
Streaming)
5 (non-
nGBR-5 1 100 ms 10-6 IMS Signalling
GBR)
Video (Buffered Streaming)
6 (non-
nGBR-6 6 300 ms 10-6 TCP-based (e.g., www, e-mail, chat, ftp,
GBR)
p2p file sharing, progressive video, etc.)
Voice,
7 (non-
nGBR-7 7 100 ms 10-3 Video (Live Streaming)
GBR)
Interactive Gaming
8 (non-
nGBR-8 8 Video (Buffered Streaming)
GBR)
300 ms 10-6 TCP-based (e.g., www, e-mail, chat, ftp,
9 (non- p2p file sharing, progressive video, etc.)
nGBR-9 9
GBR)
Table 13 : E-RAB LEVEL QoS PARAMETERS and LABEL

In general, congestion related packet drop rates and per packet delays can not be
controlled precisely for Non GBR traffic. Both metrics are mainly determined by the
current Non-GBR traffic load, the UE's current radio channel quality, and the
configuration of user plane packet processing functions (e.g. scheduling, queue
management, and rate shaping). That is the reason why sources running on a Non-
GBR bearer should be prepared to experience congestion related packet drops and/or
per packet delays that may exceed a given L2 PDB
An operator would choose GBR bearers for services where the preferred user
experience is "service blocking over service dropping", i.e. rather block a service
request than risk degraded performance of an already admitted service request. This
may be relevant in scenarios where it may not be possible to meet the demand for
those services with the dimensioned capacity (e.g. on "new year's eve"). Whether a
service is realized based on GBR bearers or Non GBR bearers is therefore an
operator policy decision that to a large extent depends on expected traffic load vs.
dimensioned capacity. Assuming sufficiently dimensioned capacity any service, both
Real Time (RT) and Non Real Time (NRT), can be realized based only on Non-GBR
bearers. (see [Vol. 4] for more detail)
It’s necessary to create 9 instances of TrafficRadioBearerConf MO with one value of

QCI per instance with the appropriate parameter settings (see Volumes 3 and 4 for
parameter values).
Page 224/289
7.5.6.1.2 SIGNALLING RADIO BEARER
In addition to these nine 3GPP QCI mapped to ALU labels, two additional Alcatel-
Lucent Proprietary configurations are defined in the eNB for the Signalling Radio
Bearers SRB1 and SRB2. Thus the eNB typically uses 11 configurations (9 QCIs by
3GPP for DRBs plus 2 by Alcatel-Lucent for SRBs - SRB1 and SRB2).
SRB Identity 3GPP SRB identity COMMENT
SRB0 SRB 0 Example Services: Paging, RRC Connection Request.

SRB1 SRB 1 Example Services: RRC and NAS messaging before SRB2 is established..
SRB2 SRB 2 Example Services:. NAS messaging
Table 14 : Signalling Radio Bearer Mapping
7.5.6.1.3 L1/L2 CONFIGURATIONS BASED ON CONFIGURATION

PARAMETERS
The configuration model used for radio L1/L2 configuration to be configured in the
UE/eNB when a new SRB or TRB is setup is the following:
Figure 64 : Configuration model for SRB & TRB
As explained in the previous section, each QCI or Signaling Radio Bearer type (i.e.
corresponding to a 3GPP QCI for DRBs or to SRB 1, 2) is configured by either an MO
Page 225/289
TrafficRadioBearerConf or SignalingRadioBearerConf. If the QCI is supported

then the MO TrafficRadioBearerConf will be created, and it will have pointers to the
associated PDCPConf MO, RlcConf MO, and LogicalChannelConf MO. For the
SRB, the SignalingRadioBearerConf will point to the appropriate RlcConf and the
LogicalChannelConf. One or more instances could be pointed (allowing one to
specify different configurations in the UE or eNB, in UL and in DL). For information
about the qCI and srbIdentity parameters, see [Vol. 4].
Note: In addition to the standardized QCI 1 to QCI 9, Feature 92095 (QCI & QCI
Parameters For Enhanced Scheduling Decisions) opens the possibility of operator
specific (non-standard) QCI, and that is the reason that the range is increased to
potentially support up to 32 values of the qCI parameter.
7.5.6.1.4 SECURITY MANAGEMENT
Key derivation function (KDF)

The AS applies three different security keys: one for the integrity protection of RRC
signalling (KRRCint), one for the encryption of RRC signalling (KRRCenc) and one for
the encryption of user data (KUPenc). All three AS keys are derived from the KeNB (a
key that is UE specific in the scope of a cell under eNB).
• See [Vol. 3] for a discussion of the Integrity Protection algorithms that are
available and how the priority is selected. [Vol. 3] also contains a discussion of
the Ciphering algorithms that are available and how the priority is specified.
7.5.6.2 TRAFFIC MONITORING
Whether Traffic Monitoring is performed depends on the setting of the

“isTrafficBasedContextReleaseAllowed” parameter.
If the “isTrafficBasedContextReleaseAllowed” parameter is set to “true”, then
Traffic Monitoring is performed.
The UE inactivity detection mechanism is supported in order to transition inactive UEs
to RRC IDLE state (to save battery and to allow assignment of better radio resources
to newly connected UEs).
Page 226/289
• isTrafficBasedContextReleaseAllowed : This flag activates the UE context

release triggered by traffic inactivity
ActivationService::isTrafficBasedContextReleaseAllowed
Parameter isTrafficBasedContextReleaseAllowed
[false; true]
Value True See Engineering Recommendation
Feature L96760
Engineering Recommendation: isTrafficBasedContextReleaseAllowed
It is strongly recommended that this parameter value be set equal to “True” in a

commercial network. This functionality disconnects dormant users after a
preconfigured UE Inactivity timer expires (specified by parameter timeToTrigger,
described later in this section, supporting an optimal eNB resource usage.
If the value of parameter isTrafficBasedContextReleaseAllowed equals “True”, then

when the first traffic radio bearer (the default bearer) is established, a timer whose
duration is determined by parameter timeToTrigger is started (referred to as the
timeToTrigger timer). Any uplink or downlink user traffic on a traffic radio bearer will
cause the timeToTrigger timer to be restarted. If the timeToTrigger timer expires, then
the UE RRC context is released from the eNB.
Depending on the setting of parameter timeToTriggerSRB2 (described below), traffic
on the signaling radio bearers will or will not cause the timeToTrigger timer to be reset.
• timeToTrigger: This timer is started in the eNodeB when the first traffic radio
bearer is established, and it is restarted when any uplink or downlink traffic
occurs on a traffic radio bearer. If the timer expires, then the UE context is
released from the eNodeB.
TrafficBasedReleaseConf::timeToTrigger
Parameter timeToTrigger
Range & Unit Float, seconds
[1..1080] step = 0.1
Value 10.0
Feature L96760 L92093
If the value of parameter isTrafficBasedContextReleaseAllowed equals “True”, and

if the value parameter timeToTriggerSRB2 is non-zero, then traffic that occurs on
SRB2 can also cause the the timeToTrigger timer to be reset. The time to which the
Page 227/289
timer is reset is dependent on the value of parameter timeToTriggerSRB2 . When

traffic occurs on SRB2, then the timeToTrigger timer is reset to a value equal to:
Max { remaining time for timeToTrigger timer ,
decimal value of timeToTriggerSRB2 }.
If the decimal value of timeToTriggerSRB2 is zero, then SRB2 traffic has no effect on
the operation of the timeToTrigger timer.
TrafficBasedReleaseConf::timeToTriggerSRB2
Parameter timeToTriggerSRB2
Range & Unit Float, 0 to 10 seconds
Increment = 0.1 seconds (100 milliseconds)
Value O.D. Default = 0.0
Feature
Rule: LogicalChannelConf:: timeToTriggerSRB2
If the use of this capability is desired, then the recommended value is 1.0
seconds (set the value to 10).
Expiration of the TimeToTrigger timer:
If the value of the timeToTriggerSRB2parameter (described above) is zero or during

some race conditions, the Time-ToTrigger timer may expire while the MME is sending
SMS traffic to the associated UE on the SRB2 channel. Expiration of the
TimeToTrigger timer causes the eNB to send a UE context release request message
to the MME. The response of the MME depends on the cause value that the eNB
includes in the UE context release request message, and on the specific programming
of the MME that is involved.
For this discussion, the two types of MME will be described:
• MME with SMS Enhancement – when this MME receives a UE context
release request message with cause value = “UE Inactivity”, the MME will
ignore the message and will not send the UE Context Release Command if
there is on going SMS activity for the UE. When this MME receives a UE
context release request message with cause value = “Release-Due-To-
EUTRAN-Generated-Reason”, the MME will clear the UE context and return
the UE Context Release Command as shown in Section 7.5.3.2.2 (even if
there is on going SMS activity for the UE).
• Regular MME – when this MME receives a UE context release request
message, the MME will clear the UE context and return the UE Context
Page 228/289
Release Command as shown in Section 7.5.3.2.2 (even if there is on going

SMS activity for the UE).
Currently, when the TimeToTrigger timer expires:,
• the eNB will send a UE context release request message to the MME with
cause value = “UE Inactivity”.
• If no response is received after an internal timer expires, then it will send a
second UE context release request message to the MME with cause value =
“Release-Due-To-EUTRAN-Generated-Reason”.
• If still no response, then a third UE context release request message will be
sent to the MME with cause value = “Release-Due-To-EUTRAN-Generated-
Reason”.
The value of parameter changeCauseInUeCtxRlsReqRetry can be used to modify
this behavior.
Enb:: changeCauseInUeCtxRlsReqRetry
Parameter changeCauseInUeCtxRlsReqRetry
Range & Unit Boolean [True, False]
Value O. D. Default = False (change from existing behavior)
Feature
Inter-Release Delta: changeCauseInUeCtxRlsReqRetry
In the previous release, the function of this parameter was controlled by the
parameter Enb::spare12, bit 5.
If the value of changeCauseInUeCtxRlsReqRetry is equal to “False”, then the eNB

behavior is as described above (UE Context Release Request Message cause value =
“UE Inactivity” for first attempt and cause value = “Release-Due-To-EUTRAN-
Generated-Reason” for the second and third attempts.
If the value of changeCauseInUeCtxRlsReqRetry is equal to “True”, and the
TimeToTrigger timer expires:
• then the eNB will include the cause value of “UE Inactivity” in the UE Context
Release Request message to the MME.
• If no response is received and an internal timer expires, then it will include
the cause value = “UE Inactivity” in the second UE Context Release Request
message to the MME. (this is the change in behavior caused by the setting of
the changeCauseInUeCtxRlsReqRetry to “True”)
Page 229/289
• If the internal timer expires again, then the eNB will include the cause value
“Release-Due-To-EUTRAN-Generated-Reason” in the third (final) UE Context
Release Request Message to the MME.
Rule: Enb:: changeCauseInUeCtxRlsReqRetry
The value used for changeCauseInUeCtxRlsReqRetry, is dependent on the

type of MME that is involved.
• If the MME is a “Regular MME” as described above, then use a value of
“False”. This avoids unnecessary delay in clearing the UE context.
• If the MME is an “MME with SMS Enhancement”, then using a value of
“True” may avoid interruption of SMS messages being sent to UE.
LTE Mobility Enhancements (dormancy timer enhancement):

Feature 92093 [LTE mobilty enhancements (dormancy timer enhancement)] transfers
the current value of the timeToTrigger timer (that is, the time that the UE has been
inactive) to the target eNB during an intra-LTE handover.
If no TimeToTrigger timer is running, then a special value will be used to indicate

“N/A”. The TimeToTrigger timer remains running in the source cell RLC in case the UE
remains on the source cell.
At the target cell, if UE inactivity monitoring is being performed, then when an
RRCConnectionReconfigurationComplete message is received (e.g., at the end of
handover), then RLC checks to determine if there are any buffered PDUs for the UL
and DL. The first PDU for either UL or DL will be a status (non-traffic) PDU.
If there is more than one buffered PDU for either UL or DL, RLC will restart the
TimeToTrigger timer (with the value specified by parameter timeToTrigger). If this
condition is not met, then:
The target eNB will calculate the “Remaining Time” as:
Remaining Time = timeToTrigger value – UE inactivity time from source
eNB
If the remaining time is less than 0, then RLC sends a notification to CallP,
indicating that UE inactivity has been detected; This condition can occur,
because a smaller value can be set on the target eNB for the
timeToTrigger parameter than was set on the source eNB.
Else If the remaining time is larger than 0, then RLC resumes the
TimeToTrigger timer (with the value set to the Remaining Time);
Else (i.e., if the remaining time received from the source eNB is “N/A”),
then RLC should re-start/reset the TimeToTrigger timer (with the value set
to the value of parameter timeToTrigger).
Page 230/289
Note that the remaining time for the TimeToTrigger timer is sent to RLC by CallP
during the RLC-Entity setup at the target cell, and the value is allowed to be negative.
In this case, there is actually no difference between handover and initial setup in the
sense that during initial setup CallP sends a value of N/A to RLC so that the timer is
initialized to the time specified by the timeToTrigger parameter.
7.5.7 CARRIER AGGREGATION CONFIGURATION

AND ACTIVATION
DL Carrier Aggregation is introduced in LR13.3. The call management for CA includes
additional functionalities:
• 3GPP Rel-10 UE capability management
• CA eligibility verification (UE frequency and frequency bandwidths combinations
vs. supported Carrier Aggregation configurations)
• UL quality verification for CA configuration and deconfiguration
• SCell configuration (incl. Rel-10 A-CSI configuration) and deconfiguration
Note: mobility management for CA configured calls is described in [Vol. 6].
Restriction: Carrier Aggregation feature support on modem-type
Carrier Aggregation is supported on bCEM only, in DL and with up to 2 carriers.

See [Vol. 2] for further information re. configuration.
7.5.7.1 CA-DL CONFIGURATION AT CALL ESTABLISHMENT
Page 231/289
UE ENB MME
Same as
RRCConnectionrequest
LR13.1:
Include P-CSI
RRCConnectionSetup
for Pcell
with Rel’8 IE
cqi- RRCConnectionSetupComplete
ReportConfig
and using S1AP INITIAL UE MESSAGE
InitPUCCHSR
SConfigProfil
(MeasurementConfiguration: measObject (PCELL
e=Super
freq))
No change
S1AP INITIAL CONTEXT SETUP REQUEST
with regard
to P-CSI UECapabilityEnquiry (eNB S1-AP UE Identity, MME S1-AP UE Identity, E-
configuratio RAB to be Setup List, Security, NAS PDU
(UE-RadioAccessCapRequest=eutran)
n UE Radio Capability *, Handover Restriction List
UECapabilityInformation Subscriber Profile ID for RAT/Frequency priority
(rat-Type, ueCapabilitiesRAT-Container) SRVCC Operation Possible)
Call eligible to CA
R10 UE:
No
Yes R10 capabilities are known
CA uplink radio criterion is configured in
eNB modem (at dbearers setup)
SecurityModeCommand
(IntegrityProtAlgorithm
CipheringAlgorithm)
(nas-DedicatedInformationList
RadioResourceConfigDedicated (SRB2, DRB(s))
SecurityModeComplete
S1AP INITIAL CONTEXT SETUP RESPONSE

(MME S1-AP UE Identity, eNB S1-AP UE Identity
E-RAB Setup List, Transport Layer Information)
S1AP UE CAPABILITY INFO INDICATION

(MME S1-AP UE Identity, eNB S1-AP UE Identity
UE Radio Capability)
Low priority meas
update if needed
MeasurementConfiguration
R10 UE:
R10 capabilities are included
Configure
A-CSI_S.
No change
CA uplink radio criterion is fulfilled
of the P-
CSI_P
configuratio CA-dl is configured in modem
n RRCConnectionReconfiguration
(….sCellToAddModList-r10, measConfig:
measObjectToAddModList(SCELL freq),
measCycleSCELLl-r10)
RRCConnectionReconfigurationComplete Scell configured in UE but not
activated
UE ENB MME
*if the IE UE Radio Capability is present in the S1AP INITIAL CONTEXT SETUP REQUEST then the messages in blue are
Passing on or copying of thisabsent
document, usecall
in this andflow.
communication of Radio
If the IE UE its contents not permitted
Capability without
is absent theyAlcatel·Lucent
are present. written authorization
Page 232/289
eNB gets UE capabilities including R10 capabilities from MME or from UE by using
usual S1 or RRC procedures. When getting from UE they are reported to MME by
eNB.
eNB CallP checks call eligibility to CA-dl configuration in order to configure or not
uplink radio trigger in modem during dbearers setup.
When eNB CallP receives later a notification from modem indicating CA uplink radio
criterion is fulfilled eNB CallP verifies the notification validity by checking call eligibility
to CA-dl configuration and conditionally configures CA-dl in modem and UE, i.e. SCell
addition processing.
7.5.7.2 CA ELIGIBILITY
• A call is eligible to Carrier Aggregation when the following conditions are met:
• The feature is enabled (ActivationService::isCarrierAggregationEnabled is

set to “True” eNB::cellMappingOverBoardMode set to “modeCA”). Refer to
[Vol. 2] for these parameters.
• Serving cell supports CA-dl,

• UE category is allowed for CA-dl
• Bands & bandwidths combination of (PCell, SCell) is supported by UE (UE CA
capabilities)
SCell ID is read by eNB CallP in MIM within MO “CarrierAggregationSecondaryConf”

(link to SCell set CarrierAggregationSecondaryConf::secondaryCellId)
CarrierAggregationSecondaryConf::secondaryCellId
Parameter secondaryCellId
Object ENBEquipment/Enb/LteCell/CarrierAggregationConf/CarrierAggr
egationSecondaryConf
Value N/A
Feature 160847
7.5.7.3 UL RADIO QUALITY CRITERION
UL quality is verified for the configuration of CA at call establishment and then

continuously monitored to ensure that the UL performances for HARQ ACK are met.
The UL quality criterion is described in [Vol. 4].
Page 233/289
If the UE fulfills the UL criterion, CA is then configured. Rel-10 A-CSI is configured via
CQI-ReportAperiodic-r10 IE in RRC Reconfiguration Procedure, see [Vol. 4] for
details. In case UL radio conditions do not meet the required level anymore, CA is
deconfigured on the UE, see description below.
7.5.7.4 CARRIER AGGREGATION ACTIVATION
At RRC Connection Reconfiguration Complete, CA is configured (SCell is configured)

but not yet activated. CA activation is managed by the scheduler. Note that in LR13.3,
deactivation is not supported.
UE UL L1 ULS DLS
CA Activation
Command
AN(ACK) AN(ACK)
One Shot A-CSI

A-CSI Request(Scell)
Request
for SCell
A-CSI(Scell) A-CSI(Scell)
CQI Threshold
Note that CQI0 means UE
does not detect the Scell
and it must no be
scheduled in the SCell
UE UL L1 ULS DLS
When the MAC Command is not acknowledged by the UE after

DownlinkCAConf::caMaximumActivationAttempts transmissions, the PCell UE/CA
Scheduler considers CA activation failure.
DownlinkCAConf::caMaximumActivationAttempts
Parameter caMaximumActivationAttempts
Object
[1..15]
Class/Source B--Cell/system_restricted
Value 5
Feature 160847
Else a one shot A-CSI is requested.
Page 234/289
The maximum number of One Shot A-CSI requests for SCell performed after the CA
Configuration in order to detect UE is in SCell coverage is set using parameter
DownlinkCAConf::caOneShotACQIRequestAttemptsUponCAConfiguration and
the
delay between two successive One Shot A-CSI requests performed after the CA
Configuration is set using parameter
DownlinkCAConf::caOneShotACQIRequestPeriodUponCAConfiguration.
DownlinkCAConf::caOneShotACQIRequestAttemptsUponCAConfiguration
Parameter caOneShotACQIRequestAttemptsUponCAConfiguration
Object
[0..15]
Value 5
Feature 160847
DownlinkCAConf::caOneShotACQIRequestPeriodUponCAConfiguration
Parameter caOneShotACQIRequestPeriodUponCAConfiguration
Object
Range & Unit Float
[0.1..15] 0.1s
Value 0.5
Feature 160847
7.5.7.5 CARRIER AGGREGATION DECONFIGURATION
Carrier aggregation is deconfigured upon UL quality alarm notification from eNB

modem.
CallP eNB de-configures CA-dl in UE by using a RRC Connection reconfiguration

procedure with setting of the SCell index (sCellToReleaseList-r10.sCellIndex IE) to
identify the SCell to be released. Then eNB CallP de-configures CA-dl in modem.
Some L1 and L2 parameters are also updated due to CA-dl de-configuration in
modem and in UE.
Page 235/289
UE ENB
Call is established with CA-dl configured (SCELL active or not)
CA radio criterion is not fulfilled

anymore
CA-dl is de-configured
(...sCellToReleaseList-r10, MeasConfig:
in UE
measObjectToRemoveList (SCELL freq))
CA-dl is de-configured in modem

(i.e. SCELL deletion)
Call is established without CA-dl
UE ENB
7.6 CELL OUTAGE DETECTION

An extensive set of eNodeB and cell monitoring features are provided for detecting
and defending against hardware and software faults that are encountered by
operational equipment. Feature 103186.1, Cell Outage Detection, provides an
additional mechanism that can be used to detect cell problems that prevent calls from
being processed (new calls, X1 or S2 Handover) when these problems cannot be
detected by other capabilities.
Cells that appear to be operating normally based on fault and event monitoring, but
that cannot process calls, are referred to as “sleeping cells”. Feature 103186.1 adds
an additional level of protection against sleeping cells through the addition of a timer
(the Sleeping Cell Inactivity Timer) that can be set to an appropriate duration for each
cell.
The Sleeping Cell Inactivity Timer is started (or restarted if it is already running) if the
parameter sleepingCellInactivityTimer value is > 0, and any of the following
conditions occur:
• The last RRC connection is removed from this cell (via RRC release, RLF, or
mobility) while the cell is in a normal service condition (operationalState is
enabled, cell is not barred, cell is not reserved)
• Cell changes state to a normal service condition as defined above
The timer is stopped if any of the following occur –
• RRC connection is successfully setup after receipt of a valid
RRCConnectionSetupComplete
Page 236/289
• RRC connection is successfully re-established after receipt of a valid

RRCConnectionReestablishmentComplete
• Target cell completes a successful incoming handover after receipt of a valid
• SIB1 cellBarred is changed to ‘barred’
• SIB1 cellReservedForOperatorUse is ‘reserved’ for all of the listed PLMNs
• LteCell::operationalState changes to ‘disabled’
If the timer expires, then a major alarm is raised to alert the operator to the need for
potential corrective action. The alarm does not affect the operational state or the
availability status of the cell.
If the alarm is set, it will be cleared by any of the events listed above that would cause
the timer to be stopped.
The duration of the Sleeping Cell Inactivity Timer is controlled on a per cell basis by
the setting of configuration parameter sleepingCellInactivityTimer. Setting the
sleepingCellInactivityTimer parameter value to 0 disables the timer.
LteCell::sleepingCellInactivityTimer
Parameter sleepingCellInactivityTimer
Integer
Range & Unit 0 to 1440 minutes
Value O.D. Default value = 0 (disabled)

Feature L103186.1
Engineering Recommendation: sleepingCellInactivityTimer parameter
The value of this parameter must be tuned for each cell, depending on the
expected traffic levels. In general, the value should be set to 0 until typical traffic
levels for the cell can be determined. Once typical traffic levels are determined,
then the parameter value can be changed to a value that does not lead to
excessive false alarms.
Setting the value of this parameter too low will cause alarms when there is no
fault.
Setting the value of this parameter too high will lead to the potential for extended
delays before problem conditions can be detected.
In LR13.1, the System Integrity Monitor (SIM) function is introduced and enabled when
isSystemIntegrityMonitorEnabled is set to True. SIM provides TX Path Monitoring to
detect cell failure by monitoring the status of the transmit paths (Cell, RFM id, antenna
port number) of each enabled cell. If the cell is enabled and one or more active
Page 237/289
transmit paths is found to have zero power continuously for

simTxPowerDegradedTimer seconds, SIM will detect that TX power has failed for
that cell and raise the following alarm: SIM HEALTH CHECK – TX PWR FAILED.
After this alarm is raised, TX Path Monitoring will continue and when transmit path(s)
cease to be degraded, SIM will clear the alarm.
Page 238/289
ActivationService::isSystemIntegrityMonitorEnabled
Parameter isSystemIntegrityMonitorEnabled
Range & Unit Boolean [True, False]
Feature 163420
Inter-Release Delta: isSystemIntegrityMonitorEnabled
SystemIntegrityMonitor::simTxPowerDegradedTimer
Parameter simTxPowerDegradedTimer
Object ENBEquipment/Enb/SystemIntegrityMonitor
[0..86400] step 300 seconds
Value Default = 900
Feature 163420
Inter-Release Delta: simTxPowerDegradedTimer
Page 239/289
8 DYNAMIC COVERAGE MANAGEMENT WITH

CELL SHRINK
A capability is provided for dynamic coverage management with cell shrink when
specific events occur. This capability is accomplished by reducing the reference signal
power in the downlink. The reduction in reference signal power should be configured
such that the reduced reference signal power ensures that
(c) Connected UEs in the edge of neighbor cell(s) reduce sending measurement
reports for intra-LTE HO to this cell;
(d) Edge UEs previously served by this cell in the coverage overlapping area
now get LTE service from neighbor cell(s).
The events that can cause cell shrink and the associated parameters that control the
magnitude of reference signal power reduction are:
S1 links outage –the S1 link outage reference signal power reduction (cell
shrink) capability can be activated when cell autobarring becomes active
as a result of loss of all S1 links. The parameter associated with the S1 link
outage cell shrink capability is the
DynamicCoverageMgmt::cellShrinkForS1LinksOutage parameter.
Note that the S1 link outage cell shrink capability can be an alternative to
or it can work in conjunction with the capability that uses
isTurningRadioOffOnS1FailureEnabled that is described in Section
4.9.3. See the discussion there for additional detail.
OA&M barring – if cell barring is requested by changing the value of the
LteCell::cellBarred parameter value equal to "Barred", then the reference
signal power reduction (cell shrink) capability will be activated. The
parameter associated with the OA&M barring cell shrink capability is the
DynamicCoverageMgmt::cellShrinkForOamBarring parameter.
Cell blocking – a capability that is not currently implemented. The
parameter associated with the cell blocking reference signal power
reduction (cell shrink) capability is the
DynamicCoverageMgmt::cellShrinkForCallsDraining parameter.
When one of the events listed above occurs, then the reference signal power will be
reduced by the value of the associated parameter that is listed above. As discussed in
LPUG Volume 4 ([Vol. 4]), the power levels of several other channels are set relative
to the reference signal power, and, as a result of the reduction in reference signal
power, their power levels will also be reduced.
Additional detail is provided about each of the parameters below. The
cellShrinkForS1LinksOutage parameter discussion is provided in Section 4.9.3.1
along with additional discussion of actions during S1 links failure.
Page 240/289
The cell shrink capability does not apply to the Metro Cell in release LR13.1
8.1 CELL SHRINK FOR OAM BARRING

cellShrinkForOamBarring: This parameter specifies an offset from
referenceSignalPower that is applied when the cell is manually barred by OAM. The
offset can be set to a value different from cellShrinkForCallsDraining or
cellShrinkForS1LinksOutage.
DynamicCoverageMgmt::cellShrinkForOamBarring
Parameter cellShrinkForOamBarring
Integer
Value Default = 9 dB
Feature L115217
Restriction: cellShrinkForOamBarring parameter
The value of the cellShrinkForOamBarring parameter should be such that
referenceSignalPower minus cellShrinkForOamBarring

>= minRefSigPower (see [Vol. 4] for a discussion of the
Example Use of the cellShrinkForOamBarring parameter

As an example of the use of the Cell Shrink for OAM Barring capability, consider the
case where an operator must schedule downtime for an eNB during a relatively busy
period. In this case, it is desirable to spread out the load as currently served UEs re-
attach to neighbor cells, and the Cell Shrink for OAM barring capability can be used
for this purpose. The general approach used is to:
1. Set the desired value for the cellShrinkForOamBarring parameter (9 dB in

our example, which should ensure coverage overlapping with neighbors is still
maintained after a drop of 9dB in referenceSignalPower so that intra-LTE HO
can occur naturally). This is typically done with a WPS/SAM workorder.
2. Set the value of the LteCell::cellBarred parameter (see Section 7.2.2) to
“Barred”. This is typically done with a WPS/SAM workorder.
Page 241/289
3. As a result, the eNB will broadcast “Cell Barred” in SIB1 for the cell(s) that are
barred, and the eNB will reduce the reference signal power by an offset equal
to the value of the cellShrinkForOamBarring parameter (9 dB in our
example).
4. About 10 seconds later, an additional step can be taken to further reduce
downlink signal power by using a WPS workorder to change the value of the
referenceSignalPower parameter to a value smaller than the original value of
referenceSignalPower minus the value of cellShrinkForOamBarring.
Ideally, this smaller new value would still maintain some coverage overlapping
with neighbors in urban area so that intra-LTE HO can still occurs.
5. After another 10 seconds, the cell(s) can be locked.
As a result of these actions there will be no new attaches (because the cell is barred),
and, since the total downlink Transmit power is proportional to
referenceSignalPower, the reduction in transmit power encourages outgoing HO of
currently served UEs and discourages incoming HO to the affected cell(s) in a two
step process before the cell(s) are locked. The load on neighbor cells and the
signaling messaging with the MME will be spread out in time to provide improved
performance.
Example for Gradually Bringing up Cell Power and Traffic Loading:

When the scheduled maintenance action is completed, the process can be reversed
to gradually bring the cell(s) into service without:
• Causing a large increase in HO rates to the recovering eNB and
• Causing the UE to observe a big and sudden jump in DL signal power from
the recovering eNB..
For this example, we will assume a value of 9 dB is used for expanding the cell in
steps, similar to the steps that were used for reducing the cell size. The following
steps will be used:
1. In step 1, unblock the cell(s) by using a WPS workorder to change the value
of parameter LteCell::cellBarred to “notBarred”, and, with the same work
order set the value of parameter referenceSignalPower to the value of
parameter minRefSigPower plus 9 dB.
2. After 10 seconds, use another WPS workorder to increase the value of
parameter referenceSignalPower again by 9 dB. As a result, the
referenceSignalPower equals minRefSigPower plus 18 dB.
3. After 10 seconds, use another WPS workorder to set the value of parameter
referenceSignalPower to its desired final value for each affected cell.
Typically, this is the same value as the value of parameter maxRefSigPower.
Note: information about parameters referenceSignalPower, maxRefSigPower, and
minRefSigPower can be found in [Vol. 4].
Page 242/289
cellShrinkForCallsDraining : This parameter specifies an offset from

referenceSignalPower that is applied to encourage outgoing HO from the cell and
discourage incoming HO to the cell when existing calls on the cell are drained prior to
Cell Block by auto use of cell barring. Typically the offset value is smaller than the
value of cellShrinkForS1LinksOutage (by 15 to 23 dB) to maintain coverage
overlapping with neighbor cells during the draining interval.
Note: The capability that is to be controlled by this parameter is not currently
implemented.
DynamicCoverageMgmt::cellShrinkForCallsDraining
Parameter cellShrinkForCallsDraining
Integer
Value N. S. Default = 6 dB
Feature L115217
Restriction: cellShrinkForCallsDraining parameter
The value of the cellShrinkForCallsDraining parameter should be such that

referenceSignalPower minus cellShrinkForCallsDraining
>= minRefSigPower (see Volume 4 [Vol. 4] for a discussion of the
Page 243/289
9 ENHANCED MULTIMEDIA BROADCAST

MULTICAST SERVICE (EMBMS)
The eMBMS feature is introduced into FDD LTE RAN capabilities by features L115527
[eMBMS trial support (eMBMS services configured by OAM command)] and 158990
[eMBMS Commercial with distributed MCE]. The objective of eMBMS is to provide a
means to broadcast information from a source to multiple UEs. By the use of
broadcast mode, radio spectrum is used efficiently when the same information is to be
provided to multiple UEs.Typical applications of eMBMS are
audio and/or video streaming (entertainment, news, or advertising)
audio and video downloading for off-line viewing (multimedia content
distribution)
file downloading to a large population (e.g., for software upgrade)
In the discussions that follow the term MBMS will typically be used to describe core
network entities, because the core may be shared with 3G for this purpose. The
reference architecture used by 3GPP is illustrated in Figure 63.
M2
M3
UEs eNode-B MCE MME
M2 Content
Sm Sources
M1 BMSC
SGmb
eNode-B SGi-mb
M1
M2 MBMS
GW Data
M1 Control
eNode-B
Figure 65 : 3GPP R9 eMBMS Reference Architecture

Definitions of logical/physical elements shown in section 9.2:
Content provider: In charge of delivering the media. (TV channels, radio channels, file
download, etc.)
BMSC (Broadcast/Multicast Service Control): The BMSC is responsible for MBMS
service provisioning and delivery. It can serve as the entry point for content provider
MBMS transmissions. It is used to authorize and initiate MBMS Bearer Services within
the PLMN and to schedule and deliver MBMS transmissions
MBMS Gateway (MBMS GW) – is a logical entity between the BMSC and the eNBs
that is responsible for the sending/broadcasting of MBMS bearer data to each eNB.
The MBMS GW uses IP Multicast as the means of forwarding MBMS user data to the
Page 244/289
eNB. The MBMS GW performs MBMS Session Control towards the E-UTRAN via the
MME.
MCE (Multi-cell/multicast Coordination Entity): The MCE provides admission control
and coordination of radio resource allocations used by all eNBs that broadcast
simultaneously within an area (explained later).
eNB: transmits the eMBMS bearers for one or more eMBMS user services
MME – provides session control, connecting the MBMS gateway and the RAN control
functions
Interfaces shown in Figure 65:
M1 – (based on GTP-U) is a point-to-multipoint (ptm) bearer interface towards the
RAN using IP source-specific multicast
M2/M3 - (based on SCTP), and Sm (based on GTP-C) are point-to-point (ptp) control
interfaces to support session control and radio configuration
SGi-mb is a ptp or ptm bearer interface towards the MBMS GW
SGmb (based on Diameter) – is a ptp control interface between the BMSC and the
MBMS GW to support session control
9.1 MULTIMEDIA BROADCAST SINGLE FREQUENCY NETWORK

MBMS has previously been supported by GSM and UMTS networks, but some
significant improvements in network operation have been designed into the LTE
standards. A key improvement is to exploit the OFDM radio interface of LTE to
transmit broadcast data as a multicell transmission over a synchronized group of LTE
cells (which is called a Single Frequency Network) – this is referred to as a Multimedia
Broadcast Single Frequency Network (MBSFN).
For MBSFN operation, eMBMS data is transmitted simultaneously over the air from
multiple tightly time-synchronized cells. The UE receiver observes multiple versions of
the signal with different delays, because of the multicell transmission. If the
transmissions from the multiple cells are synchronized sufficiently, they will arrive at
the UE within the cyclic prefix time at the start of the symbol, and there will be no
InterSymbol Interference (ISI). The UE can treat the multicell transmissions as
multipath components of a single-cell transmission and not require any additional
processing complexity. This capability is especially useful at the cell edge where a UE
can receive eMBMS transmissions from multiple cells of about the same signal
strength.
Synchronization of cells within an MBSFN is accomplished using GPS timing and a
SYNC protocol between the eMBMS Gateway and the eNB. The GPS timing is used
to time and phase align the eNB transmissions at their respective antennas, and the
SYNC protocol is used to align frame numbers for the eMBMS transmissions.
A Service Area (SA) is an area in which the same set of messages is broadcast. An
MBSFN may belong to multiple SAs, but all of the cells within the MBSFN must be
contained within the SA (the SA must contain all of the cells of the MBSFN.)
Page 245/289
Finally, multiple MBSFNs may be synchronized in an MBSFN synchronization area.
MBSFN Synchronization Area
Service Area Service Area
MBSFN MBSFN MBSFN
Cells
sync sync
Figure 66 : MBSFN/Service Area Relationships
Please note the following from Figure 64:

o A cell can be a member of multiple MBSFNs. In the current ALU
implementation, a cell can be a member of up to six MBSFNs
o If a cell is a part of more than one MBSFN, then the MBSFNs which share
the cell must be within an MBSFN Synchronization Area (so that the
messages for multiple service areas can be synchronized at the cell). The
three cells on the left hand side Fig 64 illustrate this – note that both
MBSFNs on the left hand side of the figure are within one MBSFN
Synchronization Area
o Each MBSFN must be wholly contained within a service area (the MBSFN’s
cells cannot be split with part in the the SA, and part not in the SA).
Configuration data from SAM is used to prepare a static network RAN configuration
that is not changed often. This provisioning consists of:
o Assigning each cell to an MBSFN Syncronization Area. All GPS
synchronized eNBs can potentially be in the same MBSFN Synchronization
Area.
o Assign one or more service areas to each cell
o Assign one or more cells to an MBSFN area
Page 246/289
9.2 EMBMS CHANNELS

eMBMS provides a broadcast service using the Multicast Control Channel (MCCH)
and the Multicast Traffic Channel (MTCH) logical channels that are mapped into the
Multicast Channel (MCH) transport channel (refer to [Vol. 3]). The MCH is then
mapped to the Physical Multicast Channel (PMCH) for transmission to the UEs. The
key features of the PMCH to support the MBSFN transmission are:
o The extended Cyclic Prefix (CP) is used (17us instead of 5us). Since
differences in propagation delay among multiple cells will typically be greater
than the multipath delay for a single cell, the use of the extended CP helps to
ensure that the signals received at the UE from multiple cells fall with in the
CP time (thus reducing ISI).
o The Reference Signal (RS) pattern is modified compared to non-eMBSFN
data transmission – the RS are spaced more closely in the frequency domain
than for non-eMBSFN transmission.
Additional detail of the extended CP and the RS pattern changes can be found in [Vol.
3] and [Vol. 4]..
System Information Block 1 (SIB1) lists all other SIBs that are being transmitted via a
scheduling information list. If an eMBMS broadcast is active then SIB13 is included in
the scheduling information list.
SIB2 carries the eMBMS subframe definition. If a broadcast is active, then an eMBMS
subframe information element Information Element is included in SIB2.
SIB13 describes where to find the MCCH that contains program to PMCH mappings. If
eMBMS broadcast is active, then SIB13 is transmitted.
When a change to eMBMS broadcast occurs, the eNB sends S1 page with
systeminfoModification set to True and applies all SIB and MCCH changes that are
triggered by eMBMS changes. The UEs reacquire the SIBs as a result of the S1 page.
9.3 ALU INITIAL IMPLEMENTATION OF EMBMS

The ALU implementation of the eMBMS feature provides a subset of the full 3GPP
RAN architecture as illustrated in Figure 63.
The architecture for the eMBMS feature that is currently supported is illustrated in
Figure 65
Page 247/289
E-UTRAN PDN
M3
Gateway
MCE MME
E-UTRAN Uu
LTE SGi
M2 Sm
ENB SGmb
LTE-UMTS UE ENB MBMS BM-SC Content Provider
ENB GW
M1 SGi-mb
Uu Iu Sn
UTRAN SGSN
UE
Figure 67 : ALU eMBMS Architecture
Page 248/289
MBMS GW is responsible for IP multicast distribution of MBMS packets towards either

the LTE and/or UMTS RAN
y E-UTRAN eNBs are required to support IP multicast
y UTRAN RNC may use IP unicast if IP multicast is not supported

y MBMS GW allocates the IP multicast address(es) to which eNBs/RNCs can
join to receive MBMS data belonging to a session
For location-dependent content transfer of the same MBMS User
service, a separate IP Multicast address is allocated per TMGI
(Temporary Mobile Group Identity) + Flow identifier pair
Temporary Mobile Group Identifier (TMGI)
y Allocated by the BM-SC per MBMS bearer service (globally unique)
y For broadcast, UE obtains the TMGI through MCCH and application level
Service Announcement (e.g. ESG)
eMBMS bearer QoS parameters
y Sourced from the BM-SC based on service requirements
y Same set of QoS parameters as for unicast bearers are applicable to MBMS
y Used for bearer allocation
MBMS service area
y The area within which data of a specific MBMS session are sent
y Defined by PLMN-ID and service area codes (SAC), mapped to cells.
y MCE(s) manages mapping of MBMS SA to MBSFN areas and cell list
y SAC=0 means broadcast to entire PLMN, can be used for national TV and
Radio channels
MBMS bearer service identification
y TMGI (+ optional Flow ID for location dependent content delivery), or
y IP multicast address + APN (allocated based on TMGI + optional Flow ID)
M1 data stream identification
y IP multicast transport bearer is identified by the C-TEID and the M1 IP
multicast address
9.3.1 CHARACTERISTICS OF THE CURRENT

IMPLEMENTATION
Some of the major characteristics of the current ALU eMBMS implementation are as
follows:
o eMBMS is supported using the bCEM modem card only, eCEM is not
supported
Page 249/289
o Both 10 MHz and 20 MHz bandwidth systems are supported. 15MHz

is supported in LR13.3. Other bandwidths will be supported in future
releases.
o The following dual band configuration is supported:

10MHz in B13 + 15MHz in B4
o One LTE cell can belong to up to 6 MBSFN areas
o Within a cell, each MBSFN Area can support one MCCH and up to 15
PMCH/MTCHs
o Each MTCH supports one MBMS Bearer Service or session (a
broadcast flow from the BMSC)
o The eMBMS feature is not compatible with the FDD Half Duplex
Feature (L115820).
9.4 EMBMS DATA MODEL AND PARAMETERS

Table 15 lists EMBMS parameters. This list will change in a future release.
Object Name Param identity LPUG Volume
ActivationService isMbmsBroadcastModeAllowed Volume 5,
ActivationService isMceDistributedModeEnabled Volume 5,
isMBMSBearerServiceCountingAl
LteCell Volume 5,
lowed
LteCell mbmsExcessDataThrHigh Volume 3
LteCell mbmsExcessDataThrLow Volume 3
LteCell mbmsPacketLossThrHigh Volume 3
LteCell mbmsPacketLossThrLow Volume 3
Mbms isMbmsTrafficAllowed Volume 5,
isMBMSBearerServiceCountingE
MbsfnArea Volume 5,
nabled
MbsfnPmch sfAllocEnd Volume 4
MbsfnSubframeAllo
fourFrames Volume 4
cationPattern
MbsfnSubframeAllo
oneFrame Volume 4
cationPattern
Page 250/289
MbsfnSubframeAllo
radioFrameAllocationOffset Volume 4
cationPattern
MbsfnSubframeAllo
radioFrameAllocationPeriod Volume 4
cationPattern
PowerOffsetConfigu
port4PowerOffset Volume 4
ration
SysInfoConf sib13SchedulingClass Volume 5,
Mce uniqueName Volume 5
Mce mceName Volume 5
Mce mceId Volume 5
Mce latencySessionStart Volume 5
Mce latencySessionStop Volume 5
Mce mcchModificationPeriod Volume 5
MceSupportedQci supportedQci Volume 5
MceSupportedQci mchSchedulingPeriod Volume 5
MceSupportedQci packetErrorLossRate Volume 5
MceMbsfnSynchroA
dlBandwidth Volume 5
rea
MceMbsfnSynchroA
mbsfnSynchroAreaName Volume 5
rea
MceMbsfnSynchroA
rea mbsfnSynchroAreaId Volume 5
MceMbsfnSynchroA
rea mbsfnAreaSynchroPatternSfList Volume 5
MceMbsfnSynchroA
rea mbsfnAreaSynchroPatternRfList Volume 5
MceMbsfnSynchroA
rea mbsfnAreaPooledSfList Volume 5
MceMbsfnSynchroA
rea mbsfnAreaPooledRfList Volume 5
MceMbsfnSynchroA
rea spsFavor Volume 5
MceMbsfnSynchroA
rea hetnetMacroBlankingPatternDL Volume 5
Page 251/289
MceMbsfnArea mbsfnAreaName Volume 5
MceMbsfnArea mbsfnAreaId Volume 5
MceMbsfnArea mbmsServiceAreaIdList Volume 5
MceMbsfnArea mbsfnAreaPartitionSfList Volume 5
MceMbsfnArea mbsfnAreaPartitionRfList Volume 5
MceMbsfnArea useOfPooledSf Volume 5
MceMbsfnArea mcchRepetitionPeriod Volume 5
MceMbsfnArea minMchSchedulingPeriod Volume 5
MceMbsfnArea dlSINR Volume 5
MceMbsfnArea sib13SignalingMCS Volume 5
MceMbsfnArea Sib13NonMBSFNregionLength Volume 5
MbsfnPositioningRe
prsNumSubframes Volume 5
ferenceSignal
MbsfnPositioningRe
prsConfigurationIndex Volume 5
ferenceSignal
Table 15 : eMBMS Objects and Parameters
Activation of eMBMS traffic consists of three principal activities:
1. Preparation of the configuration data for the eNB

2. Activation of the eMBMS feature for the eNB
3. Enabling eMBMS traffic flow for each cell of the eNB.
The eMBMS-specific parameters are listed in Table 15 along with an indication of the
LPUG volume (or the TEG - see Reference [R15]) in which each parameter appears.
9.4.1 ACTIVATING THE EMBMS FEATURE

The eMBMS feature is activated on a per eNB basis using the parameter
isMbmsBroadcastModeAllowed and isMceDistributedModeEnabled. (for eMBMS
activation, both flags should be set to TRUE, for eMBMS deactivation: Both flags
should be set to FALSE). Feature is not activated by default.
Page 252/289
ActivationService::isMbmsBroadcastModeAllowed
Parameter isMbmsBroadcastModeAllowed
Boolean
Range & Unit [True, False]
Value O.D. (Default value = False)

Feature L115527
ActivationService::isMceDistributedModeEnabled
Parameter isMceDistributedModeEnabled
Boolean
Value O.D. (Default value = False)

Feature L158990
Changing the parameter value from “False” to “True” activates the eMBMS feature for
the eNB, but this act does not actually start the data flow. The proper configuration
data must be entered for the eMBMS data flows that are desired (for all of the
parameters listed inTable 15), and then the data flow can be enabled by changing the
value of parameter isMbmsTrafficAllowed from :”False” to “True”.
Page 253/289
isMbmsTrafficAllowed :This parameter activates/deactivates the eMBMS traffic. If

deactivated, then SIB13 is removed and MBSFN SF are muted and not reusable for
unicast.
Mbms::isMbmsTrafficAllowed
Parameter isMbmsTrafficAllowed
Object ENBEquipment/Enb/Mbms
Boolean
Value O.D. (Default value = True)

Feature L115527
9.4.2 CONFIGURATION OF EMBMS AT THE ENB

As indicated in Section 9.1 and Table 15, the eMBMS related parameters for Service
Area, MBSFN area must be configured from SAM for the eNB. This section will
describe the configuration of some of the parameters that can be configured by the
operator. Other parameters can be found in other LPUG volumes as indicated in Table
15
9.4.2.1 GENERAL PARAMETERS FOR THE MULTIMEDIA

BROADCAST SINGLE FREQUENCY NETWORK
(MBSFN)
Parameters that are related to the assignment of the cell to an MBSFN and the logical
setup of the MBSFN are documented in this section.
Page 254/289
isMBMSBearerServiceCountingAllowed : This parameter flag will be used to

indicate one cell on which the eMBMS counters will be reported. There is only one cell
on which the eMBMS counters will be reported at most. So for this cell the flag will be
set to TRUE, while for the other cells the flag will be set to FALSE.
LteCell::isMBMSBearerServiceCountingAllowed
Parameter isMBMSBearerServiceCountingAllowed
Boolean
Value False (see Rule below)

Feature L115527
Rule: isMBMSBearerServiceCountingEnabled parameter
The eMBMS counters can only be reported for one (cell, MBSFN area) per eNB,
so only one cell and one MBSFN area of the eNB may have the flag set to TRUE,
and the other cells and any other MBSFN area(s) must have the flag set to
FALSE.
9.4.2.2 MCE AND PARAMETERS
Main MCE functions are based on 3GPP Rel’ 9. They are admission control for
eMBMS services and Radio resources allocation for eMBMS services.
ALU adopts distributed MCE architecture for eMBMS. All the MCEs of the MBSFN
area are provisioned with the same set of configuration parameters and perform the
same admission control and radio resources allocation algorithms. They re-assess at
every session start, update, stop or MBSFN Area reconfiguration the list of MBMS
sessions to be scheduled.
MCE minimizes operators’ provisioning efforts and optimizes radio resource usage
through dynamic subframe allocations. MCE can support different MBMS deployment
schemes such as single MBSFN area, multiple MBSFN areas in overlay or overlap.
Page 255/289
Figure 79 : Mce Service Area Objects
Page 256/289
uniqueName : This parameter is the user friendly. It is used for eMBMS counter
reporting.
Mce::uniqueName
Parameter uniqueName
Object ENBEquipment/Mce
String
Range & Unit 0 to 64 characters
Value O.D.
Feature 158990
mceName : This parameter defines the name of the Mce. This parameter can be
unset, it is just as administrative field not used by the system.
Mce::mceName
Parameter mceName
String
Range & Unit 0 to 64 characters
Value O.D.
Feature 158990
Page 257/289
mceId : This parameter identifies the MCE at the creation.

Mce::mceId
Parameter mceId
Decimal
Range & Unit [0 .. 65535]
Value O.D.
Feature 158990
latencySessionStart : This parameter corresponds to a network + eNB latency

corresponding to a session start.
Mce::latencySessionStart
Parameter latencySessionStart
Decimal
Range & Unit [0 .. 256] Unit = seconds
Value O.D.
Feature 158990
Page 258/289
latencySessionStop : This parameter corresponds to a network + eNB latency

corresponding to a session stop.
Mce::latencySessionStop
Parameter latencySessionStop
Decimal
Range & Unit [0 .. 256] Unit = seconds
Value O.D.
Feature 158990
mcchModificationPeriod : This parameter defines periodically appearing boundaries,

radio frames for which SFN mod mcch-ModificationPeriod = 0, The contents of
different transmissions of MCCH information can only be different if there is at least
one such boundary in-between them.
Mce::mcchModificationPeriod
Parameter mcchModificationPeriod
Enumarate
Range & Unit [rf512, rf1024]
Value Rf512
Feature 158990
mceActionOverloadControl: This parameter allows selecting the actions made by the

MCE when the eNB leaves the critical state. The both possible actions depends on the
MME capability and are the following: Shutdown connection SCTP or Send a M3
RESET.
Page 259/289
Mce::mceActionOverloadControl
Parameter mceActionOverloadControl
Enumarate
Range & Unit [ShutdownSCTP(0), M3RESET(1)]
Value ShutdownSCTP
Feature 167219
provisioningSynchronization: This parameter indicates the absolute time at which the

configuration update should apply upon an online provisioning parameter on the MCE
side. It created in order to synchronize the online provisioning update on MCE side
between several eNB
Mce::provisioningSynchronization
Parameter provisioningSynchronization
Integer
Range & Unit [0 … 4294967295]
Value ShutdownSCTP
Feature 167219
isCrcCheckSyncProtocolEnabled: This parameter enables or disables CRC check

from SYNC protocol 25.446. By default, the parameter is disabled.
Mbms::isCrcCheckSyncProtocolEnabled
Parameter isCrcCheckSyncProtocolEnabled
Object ENBEquipment/Mce/Mbms
Boolean
Range & Unit [False, True]
Value False
Feature 167219
Page 260/289
m1SyncSequenceDuration: This parameter specifies the sync sequence duration of

the packets sent over M1 as defined in TS 36.300. The duration specified here will
apply to all M1 bearers.
Mbms::m1SyncSequenceDuration
Parameter m1SyncSequenceDuration
Object ENBEquipment/Mce/Mbms
Enumerate
Range & Unit [rf4(0), rf8(1), rf16(2), rf32(3), rf64(4), rf128(5), rf256(6), rf512(7),
rf1024(8)]
Value rf8
Feature 167219
MceMbsfnSynchroArea is set of cells having common radio characteristics

• Frequency carrier, bandwidth, type frame used (type 1 applicable to FDD),
• Sub-frames, which can be allocated to MBMS
• MBSFN transmission capable
MBSFN synchro Area(s) are provisioned on the MCE.
hetNetMacroBlankingPatternDL: This parameter indicates to the MCE the HetNet

macro blanking pattern configuration, on a 40ms period. Each bit set to 1 will block DL
grants in the corresponding subframe, bit 0 (LSB) being the subframe 0 in the 0..39
range. Only macro cell applies the blanking, the pico cell uses this information to avoid
interference from the macro cell. This parameter can be unset which means the MCE
does not take into consideration the interaction with ABS feature.
MceMbsfnSynchroArea::hetNetMacroBlankingPatternDL
Parameter hetNetMacroBlankingPatternDL
Object ENBEquipment/Mce/ MceMbsfnSynchroArea
BitString
Range & Unit [40 .. 40]
Value O.D
Feature 158990
The customer is able to define an optional radio resources pattern named pool at
MBSFN synchronization Area level. The pool is a matrix with 2 dimensions (subframe ;
Page 261/289
radio frame) defined by the parameters mbsfnAreaPooledSfList and

mbsfnAreaPooledRfList.
This pool is useful when the customer is not able to estimate precisely the quantity of
radio resources needed for the sessions of a MBSFN Area. This pool will be used by
the MCE allocator when it needs to allocate more resources than what is authorized in
the partition of the MBSFN Area. The pool access is restricted to only two MBSFN
Areas.
The operator defines the sub frames list and the radio frames list. Both lists are not
mandatory contiguous. Each defined radio frame will contain the defined sub frame list
mbsfnAreaPooledRfList: This parameter specifies the second dimension of a matrix

having 2 dimensions. The matrix represents the pool of eMBMS radio resources
shared between two MBSFN Areas which cohabit on a cell. This parameter allows
choosing one or several radio frames and then the selected radio frames will contain
the eMBMS sub frames specified by the other parameter mbsfnAreaPooledSfList
belonging to the object MceMbsfnSynchroArea. If this parameter is unset while the
parameter mbsfnAreaPooledSfList is set, that means all the radio range is selected. If
this parameter and mbsfnAreaPooledSfList parameter are both unset, that means
there is no pool, no selection.
Page 262/289
MceMbsfnSynchroArea::mbsfnAreaPooledRfList
Parameter mbsfnAreaPooledRfList
Enumerate
Range & Unit [rf0, rf1, rf2, rf3, rf4, rf5, rf6, rf7]
Value O.D
Feature 158990
mbsfnAreaPooledSfList: This parameter defines the first dimension of a matrix

having 2 dimensions. The matrix represents the pool of eMBMS radio resources
shared between two MBSFN Areas which cohabit on a cell. The dimension
represented by this parameter is the list of sub frames which can be used for eMBMS
inside radio frame. This list respects the 3GPP definition in term of sub frames that
can be used for eMBMS and which is: For FDD: Starting from the first group and from
the first/leftmost bit in the group the allocation applies to subframes 1, 2, 3 , 6, 7 and 8.
Page 263/289
If this parameter and mbsfnAreaPooledRfList parameter are both unset, that means
there is no pool, no selection.
MceMbsfnSynchroArea::mbsfnAreaPooledSfList
Parameter mbsfnAreaPooledSfList
Enumerate
Range & Unit [sf1, sf2, sf3, sf4, sf5, sf6, sf7, sf8]
Value O.D
Feature 158990
mbsfnAreaSynchroPatternRfList: This parameter specifies the second dimension of

a matrix having 2 dimensions. The matrix represents the eMBMS radio resources
pattern at synchronization Area level that can be used by the sessions of the MBSFN
Synchronization Area. This matrix allows differentiating the unicast part from the
multicast part. This parameter allows choosing one or several radio frames and then
Page 264/289
the selected radio frames will contain the eMBMS sub frames specified by the other
parameter mbsfnAreaSynchroPatternSfList belonging to the object
MceMbsfnSynchroArea. If this parameter is unset while the parameter
mbsfnAreaSynchroPatternSfList is set, that means all the radio range is selected. If
this parameter and mbsfnAreaSynchroPatternSfList parameter are both unset, that
means there is no synchro pattern defined.
MceMbsfnSynchroArea::mbsfnAreaSynchroPatternRfList
Parameter mbsfnAreaSynchroPatternRfList
Enumerate
Class/Source C--Immedaite-propagation / customer_init
Value O.D
Feature 158990
Page 265/289
mbsfnAreaSynchroPatternSfList: This parameter defines the first dimension of a

matrix having 2 dimensions. The matrix represents the eMBMS radio resources
pattern at synchronization Area level that can be used by the sessions of the MBSFN
Synchronization Area. This matrix allows differentiating the unicast part from the
multicast part. The dimension represented by this parameter is the list of sub frames
which can be used for eMBMS inside radio frame. This list respects the 3GPP
definition in term of sub frames that can be used for eMBMS and which is: For FDD:
Starting from the first group and from the first/leftmost bit in the group the allocation
applies to subframes 1, 2, 3 , 6, 7 and 8. If this parameter is unset while the parameter
mbsfnAreaSynchroPatternRfList is set, that means all the subframes range is
selected. If this parameter and mbsfnAreaSynchroPatternRfList parameter are both
unset, that means there is no Synchro pattern defined.
MceMbsfnSynchroArea::mbsfnAreaSynchroPatternSfList
Parameter mbsfnAreaSynchroPatternSfList
Enumerate
Class/Source C-- Immedaite-propagation / customer_init
Value O.D
Feature 158990
Page 266/289
mbsfnSynchroAreaId: This parameter identifies the MBSFN Synchronization Area

identity at the MBSFN synchronization area creation.
MceMbsfnSynchroArea::mbsfnSynchroAreaId
Parameter mbsfnSynchroAreaId
Decimal
Range & Unit [0 .. 65535]
Value O.D
Feature 158990
mbsfnSynchroAreaName: This parameter is a free name for the MBSFN

Synchronization Area. This parameter can be unset, it is just as administrative field not
used by the system.
MceMbsfnSynchroArea::mbsfnSynchroAreaName
Parameter mbsfnSynchroAreaName
ASCII String
Range & Unit [1 .. 64]
Value O.D
Feature 158990
Page 267/289
spsFavor: This parameter defines the priority in term of sub frame use between the
eMBMS and the SPS feature. When the flag is set to TRUE and then the SPS is
activated the MCE will coordinate the radio resource allocation in order to minimize
collision with the SPS.
MceMbsfnSynchroArea::spsFavor
Parameter spsFavor
Boolean
Range & Unit [true, false]
Value O.D
Feature 158990
MBSFN Area = set of cells belonging to the same MBSFN synchronization area and
serving the same set of Service Areas. It’s an area in which, each cell simultaneously
transmit the same content.
• An MBSFN Area can be smaller or as large as the MBSFN synchronization
Area
• Several MBMS sessions might be broadcasted in one MBSFN area
• LR13.1: up to 15
• A cell may serve several MBSFN areas

• LR13.1: up to 6
mbmsServiceAreaIdList: This parameter allows to define a list of MBMS Service

area for the cell.
This parameter can be unset which means that the cell is temporarely not in charge of
any eMBMS sessions transmission while the cell is configured for eMBMS. Otherwise
it means that the cell is not configured for the eMBMS.
Page 268/289
MceMbsfnArea::mbmsServiceAreaIdList
Parameter mbmsServiceAreaIdList
Object ENBEquipment/Mce/ MceMbsfnArea
Decimal
Range & Unit [1 ... 65535]
Class/Source C-- Immediate-propagation / customer_init
Value 5.0
Feature 158990
mbsfnAreaId: This parameter identifies the MBSFN area at the creation.

MceMbsfnArea::mbsfnAreaId
Parameter mbsfnAreaId
Decimal
Range & Unit [0 ... 255]
Value O.D
Feature 158990
mbsfnAreaName: This parameter is a free name for the MBSFN Area. This
parameter can be unset, it is just as administrative field not used by the system.
MceMbsfnArea::mbsfnAreaName
Parameter mbsfnAreaName
String
Range & Unit [1 ... 64]
Value O.D
Feature 158990
mbsfnAreaPartitionRfList: This parameter specifies the second dimension of a

matrix having 2 dimensions. The matrix represents the eMBMS radio resources
partitionned for the MBSFN Area. This parameter allows choosing one or several radio
frames and then the selected radio frames will contain the eMBMS sub frames
specified by the other parameter mbsfnAreaPartitionSfList belonging to the object
MceMbsfnArea. This parameter can be unset, which means that all the range is
selected.
Page 269/289
MceMbsfnArea::mbsfnAreaPartitionRfList
Parameter mbsfnAreaPartitionRfList
Enumerate
Value O.D
Feature 158990
mbsfnAreaPartitionSfList: This parameter defines the first dimension of a matrix

having 2 dimensions. The matrix represents the eMBMS radio resources partitionned
for the MBSFN Area. The dimension represented by this parameter is the list of sub
frames which can be used for eMBMS inside radio frame. This list respects the 3GPP
definition in term of sub frames that can be used for eMBMS and which is: For FDD:
Starting from the first group and from the first/leftmost bit in the group the allocation
applies to subframes 1, 2, 3 , 6, 7 and 8. This parameter can be unset, which means
that all the range is selected.
MceMbsfnArea::mbsfnAreaPartitionSfList
Parameter mbsfnAreaPartitionSfList
Enumarate
Value O.D
Feature 158990
Rules:
• If mbsfnAreaPartitionSfList is not present then the MBSFN area partition takes all
lines
• If only mbsfnAreaPartitionSfList is present then the MBSFN area partition takes all
columns
• If mbsfnAreaPartitionRfList is not present then the MBSFN area partition takes all
columns
• If only mbsfnAreaPartitionRfList is present then the MBSFN area partition takes all
lines
There is one additional rule
• If both parameters mbsfnAreaPartitionRfList & mbsfnAreaPartitionSfList are NOT

present
Page 270/289
• then the MBSFN area partition takes the whole matrix space
The MBMS configuration for an MBSFN area is invalid if there is not at least 1 SF in
the first radio frame of the MbsfnArea (the first element of the MbsfnAreaRfList or
the first radio frame of the 80ms block if MbsfnAreaRfList is absent) that can be
allocated by the MCE. In LR13, the first radio frame of the MbsfnArea has always an
even SFN.
mbmsServiceAreaId: This parameter assigns the MBMS Service Area identity for
which the regional business operational team will define some characteristics.
MbmsServiceAreaCharacteristics::mbmsServiceAreaId
Parameter mbmsServiceAreaId
Object ENBEquipment/Mce/MbmsServiceAreaCharacteristics
Integer
Range & Unit [0 … 65535]
Value
Feature 167219
fecMbmsServiceArea: This parameter specifies the recommended FEC overhead that

can be applied on this MBMS Service Area.
This parameter can be unset.
MbmsServiceAreaCharacteristics::fecMbmsServiceArea
Parameter fecMbmsServiceArea
Integer
Range & Unit [0 … 100] %
Value
Feature 167219
maxBitRateMbmsServiceAreaId: This parameter specifies the maximum bit rate

supported by the MBMS Service Area identity for the sum of the sessions which will be
mapped on it. This parameter can be unset.
Page 271/289
MbmsServiceAreaCharacteristics::maxBitRateMbmsServiceAreaId
Parameter maxBitRateMbmsServiceAreaId
Integer
Range & Unit [0 … 100000] Kbits/s
Value 1
Feature L167219
maxBitRateSession: This parameter specifies the maximum bit rate that can be
affected to a session for a given MBMS Service Area Identity. This parameter can be
unset.
MbmsServiceAreaCharacteristics::maxBitRateSession
Parameter maxBitRateMbmsServiceAreaId
Integer
Range & Unit [0 … 100000] Kbits/s
Value 1
Feature 167219
sib13NonMBSFNregionLength: This parameter indicates how many symbols from

the beginning of the subframe constitute the non-MBSFN region. This value applies in
all subframes of the MBSFN area used for PMCH transmissions as indicated in the
MSI. The values s1 and s2 correspond with 1 and 2 symbols, respectively: see TS
36.211 [21, Table 6.7-1].
Page 272/289
MceMbsfnArea::sib13NonMBSFNregionLength
Parameter sib13NonMBSFNregionLength
Enumarate
Range & Unit [s1, s2]
Value s2
Feature 158990
Engineering Recommendation: sib13NonMBSFNregionLength
Reducing this value can improve the PMCH performance but may take risk of
impacting the UL grants sent over MBSFN subframes. It is recommended to set to
s2
sib13SignalingMCS: This parameter indicates the Modulation and Coding Scheme

(MCS) applicable for the subframes indicated by the field sf-AllocInfo and for the first
subframe of each MCH scheduling period (which may contain the MCH scheduling
information provided by MAC). Value n2 corresponds with the value 2 for parameter in
TS 36.213 [23, Table 7.1.7.1-1], and so on.
MceMbsfnArea::sib13SignalingMCS
Parameter sib13SignalingMCS
Enumarate
Range & Unit [n2, n7, n13, n19]
Value n7
Feature 158990
Engineering Recommendation: sib13SignalingMCS
To achieve promising MBSFN performance, this value should be smaller than the
data MCS used by MTCH
useOfPooledSf: This parameter indicates if the MBSFN Area can use the pool of
subframes shared between the MBSFN Areas once it set of partitioned sub frames is
Page 273/289
fully used. If this parameter is set No then the MBSFN Area is not authorized to use
the pool, otherwise if the parameter is set to YesAsPrimaryMbsfnArea or
YesAsSecondaryMbsfnArea, the MBSFN Area is authorized to use the pool of share
sub frame and the MCE allocator will trig different way of radio resource allocation
within this pool depending if YesAsPrimaryMbsfnArea or YesAsSecondaryMbsfnArea
is used.
MceMbsfnArea::useOfPooledSf
Parameter useOfPooledSf
Enumarate
Range & Unit [No, YesAsPrimaryUser, YesAsSecondaryUser]
Value n7
Feature 158990
Rule: OTDOA and EMBMS coexistence
OTDOA and eMBMS. When both feature activated, eMBMS won’t use the radio
frame used by the OTDOA.
prsConfigurationIndex: This parameter specifies the positioning reference signals

configuration index. This parameter is a copy of the parameter
PositioningReferenceSignals::prsConfigurationIndex, and it is used by the MCE
allocator to manage the conflict one radio frame use between the MBMS and PRS
(OTDOA) feature.
MbsfnPositioningReferenceSignal::prsConfigurationIndex
Parameter prsConfigurationIndex
Object ENBEquipment/Mce/MbsfnPositioningReferenceSignal
[0..4095]
Value O.D.
Feature 158990
prsNumSubframes: This parameter specifies to the MCE the number of consecutive

downlink subframes with positioning reference signals. The content for this parameter
should be the same than the one used for PRS feature (prsNumSubframes located
into the PositioningReferenceSignals object). This parameter can be unset which
means the MCE does not take into consideration the interaction with PRS feature.
Page 274/289
MbsfnPositioningReferenceSignal::prsNumSubframes
Parameter prsNumSubframes
Object ENBEquipment/Mce/MbsfnPositioningReferenceSignal
[sf1, sf2, sf4, sf6]
Value O.D.
Feature 158990
9.4.2.3 MCE RESOURCES ALLOCATOR
MCE resource allocator allows to:

Minimize operator provisioning efforts
y Minimize amount of parameters
y Minimize complexity of parameter semantic

y Avoid need for operator to have a very accurate view of resources needed per
MBSFN area
Support of different MBMS deployment schemes

y Single MBSFN area, multiple MBSFN areas in overlay or overlap
Generic method of construction of SF patterns (i.e. applicable to any CSA period)
Optimize SF resource
y Avoid blocked SF (unused MBSFN SF and therefore which cannot be used
for unicast by legacy UEs)
y Minimize number of underutilized SF(s)
Page 275/289
Figure 68 : MCE resource allocator overview
Page 276/289
packetErrorLossRate: This parameter defines the packet error loss rate to be applied
for the eMBMS Session for data transmission.
MceSupportedQci::packetErrorLossRate
Parameter packetErrorLossRate
Object ENBEquipment/Mce/MceSupportedQci
Enumarate
Range & Unit [0.1, 0.05, 0.01]
Value 0.01
Feature 158990
dlBandwidth: This parameter indicates the transmission bandwidth configuration

(NRB). n6 corresponds to 6 resource blocks, n15 to 15 resource blocks and so on.
MceMbsfnSynchroArea::dlBandwidth
Parameter dlBandwidth
Object ENBEquipment/Mce/MceMbsfnSynchroArea
Enumarate
Range & Unit [n6, n15, n25, n50, n75, n100]
Value n50
Feature 158990
dlSinr: This parameter corresponds to the dl SINR to be filled by the customer or ALU
expert following the measurement on the worst cell of the MBSFN Area. It is used by
the MCE to determine the MCS to be used inside the MBSFN Area when a service
needs to be broadcasted.
MceMbsfnArea::dlSinr
Parameter dlSinr
Float
Range & Unit [-10.0..30.0] step = 0.1 dB
Value 5.0
Feature 158990
Page 277/289
Engineering Recommendation: dlSinr
The dlSinr should be set such that the corresponding MTCH data MCS can provide
satisfactory MBSFN performance within the service area. The recommended values
are under evaluating
supportedQci : This parameter defines the QCI supported by the MCE. The QCI
contained into the received session start message will be compared to this parameter.
If not present, then the MCE will reject the session by sending a session start failure
with the appropriate cause
MceSupportedQci::supportedQci
Parameter supportedQci
Decimal
Range & Unit [4 .. 255]
Class/Source C—Immediate-propagation / customer_init
Value O.D
Feature 158990
mchSchedulingPeriod: This parameter defines the internal delay to be used for

eMBMS data transmission. This parameter is per supportedQCI specific
MceSupportedQci::mchSchedulingPeriod
Parameter mchSchedulingPeriod
Enumerate
Value Rf32 (for supportedQci 4)

Feature 158990
mcchRepetitionPeriod: This parameter specifies the interval, in radio frames,

between transmissions of MCCH information. The value rf32 corresponds to 32 radio
frames, rf64 corresponds to 64 radio frames and so on.
Page 278/289
MceMbsfnArea::mcchRepetitionPeriod
Parameter mcchRepetitionPeriod
Enumarate
Range & Unit [rf32, rf64, rf128, rf256]
Value rf128
Feature 158990
minMchSchedulingPeriod: This parameter defines the internal delay to be used for

eMBMS data transmission.
MceMbsfnArea::minMchSchedulingPeriod
Parameter minMchSchedulingPeriod
Enumerate
Value rf8
Feature 158990
In LR13.3, a flexibility is brought concerning CS determination for a given

MBSFN Area according to the SINR and to the Packet Error Loss Rate of an
incoming eMBMS session.
The data model has evolved and allows defining several profiles. Each profile is a
mapping table between SINR and MCS value and depending on the packet error loss
rate. This profile is managed inside a new object MceQosToMcsProfile.
The parameter mceQosToMcsProfileId is an optional parameter introduced to allow

the MBSFN area to point on one profile which defines the mapping table between
BLER/SINR and MCS. If the MBSFN area does not point on any profile, then the
default internal table already defined in LR13.1 will be used by the system to
determine the MCS.
For an incoming eMBMS session, the system will check which profile should be used
for the MBSFN Area. If no profile has been defined via the provisioning, then the
system uses the internal table and the mechanism is the same than in LR13.1.
If a profile has been defined for the MBSFN Area, then the system will deduce from
the profile the MCS according to the BLER and the SINR. The BLER allows the
system to choose the appropriate parameter of type list among the three one defined
into MceQosToMcsProfile. The SINR allows retrieving the MCS inside the parameter
Page 279/289
list. The parameter list indicates a list of SINR corresponding to the greatest SINR
value for each MCS.
Figure 69 : Multiple profiles for MCS management principle
mceQosToMcsProfileId: This parameter allows a MBSFN Area to point on a

eMBMS MCS mapping profile. The parameter can be unset which means that the
eNodeB will take the internal MCE to MCS mapping table rather than the one
which has been provisioned.
Page 280/289
MceMbsfnArea:: mceQosToMcsProfileId
Parameter mceQoSToMcsProfilName
Object ENBEquipment/Mce/MceMbsfnSynchroArea/MceMbsfnArea
Value
Feature 167219
mceQoSToMcsProfilName: This parameter specifies the name of the profile to

be used for eMBMS MCS mapping table.
MceQosToMcsProfile::mceQoSToMcsProfilName
Parameter mceQoSToMcsProfilName
Object ENBEquipment/Mce/ MceQosToMcsProfile
String
Range & Unit [1..30]
Value
Feature 167219
mcsTransitionTableBler1: This parameter specifies the list of SINR that is used

by the MCE to determine which MCS shall be used in a MBSFN area for target
BLER 1%. The first entry is the SINR for the transition from MCS0 to MCS1,
second entry transition from MCS1 to MCS2 and so.
MceQosToMcsProfile::mcsTransitionTableBler1
Parameter mcsTransitionTableBler1
Float
Value
Feature 167219

Page 281/289
Float
Value
Feature 167219

Float
Range & Unit [-10.0..30.0] step = 0.5dB
Value
Feature 167219
9.4.2.4 INTRA-FREQ AND INTER-FREQ MOBILITY
LR13.3 implement the standard allowing signaling the UE with information elements
which help the UE to select the correct subframes for measurement of neigbor cells.
Those IE, implement in neighCEllConfig, indicates whether the neighbour cells have a
MBSFN configuration similar to the serving cell:
• 00: Not all neighbour cells have the same MBSFN subframe allocation as the serving
cell on this frequency, if configured, and as the PCell otherwise
• 10: The MBSFN subframe allocations of all neighbour cells are identical to or
subsets of that in the serving cell on this frequency, if configured, and of that
in the PCell otherwise
• 01: No MBSFN subframes are present in all neighbour cells
• 11: Different UL/DL allocation in neighbouring cells for TDD compared to the
serving cell on this frequency, if configured, and compared to the PCell
otherwise
Page 282/289
This IE is mandatory and present in SIB3, SIB5 and in the MeasObjectEUTRA IE. In
LR13.1, the eNB hardcoding neighCellConfig and an OAM parameter
(LteNeighboringFreqConf::neighCellConfig) allow to set it in per frequency in SIB5.
In LR13.3 this IE shall be set in SIB3, SIB5 and MeasObjectEUTRA according to the
value set in the relevant LteNeighboringFreqConf object.
isMbsfnInformationOverX2Enabled:: This parameter when enabled allows

transmission and reception of MBSFN Subframe Information over X2. When this
is activated the neighCellConfig transmitted in SIB3, SIB5 and
MeasObjectEUTRA is computed according to the information received from
neighbor cell.
ActivationService::isMbsfnInformationOverX2Enabled
Parameter isMbsfnInformationOverX2Enabled
ENBEquipment/ActivationService/
Object
isMbsfnInformationOverX2Enabled
Boolean
Value False
Feature 167219
isMeasSubframePatternNeighInterFreqEnabled: This parameter when enabled

and ismbsfnInformationOverX2Enabled when enabled, allows the eNB to set
measSubframePatternNeigh and measSubframeCellList in MeasObjectEUTRA
with the values computed according to MBSFN Information received from
neighbor cells.
ActivationService:: isMeasSubframePatternNeighInterFreqEnabled
Parameter 'isMeasSubframePatternNeighInterFreqEnabled
ENBEquipment/ActivationService/
Object
isMbsfnInformationOverX2Enabled
Boolean
Value False
Feature 167219
Page 283/289
10 ANNEX
10.1 ABBREVIATIONS
All terms, definitions and abbreviations used in the present document, that are
common across 3GPP TSs, are defined in the 3GPP Vocabulary
For the purposes of the present document, the abbreviations given in following apply.
ACK Acknowledgement
ACLR Adjacent Channel Leakage Ratio
aGW Access Gateway (in LTE This aGW was an intermediate name and is
now exchanged more precisely by the MME and UPE, cf. 36.300)
AM Acknowledge Mode
AMBR Aggregate Maximum Bit Rate
ANR Automatic Neighbour Relation
AS Access Stratum
BMC Broadcast Management Center
BMSC Broadcast/Multicast Service Control
BSR Buffer Status Reports
C/I Carrier-to-Interference Power Ratio
CAZAC Constant Amplitude Zero Auto-Correlation
CAC Channel Admisson Control
CBC Cell Broadcast Center
CFC Call Final Class
CFCQ Call Final Class Qualifier
CMAS Commercial Mobile Alert System
CMC Connection Mobility Control
CP Cyclic Prefix
C-plane Control Plane
CQI Channel Quality Indicator
CRS Cell Reference Signal
C-RNTI Cell RNTI
CSG Closed Subscriber Group
CMSP Commercial Mobile Service Provider
DAS Distributed Antenna System
DAS HW DAS Hardware
DCH Dedicated Channel (The DCH is a downlink or uplink transport channel
that is used to carry user or control information between the network
and the UE)
DL Downlink
DFTS DFT Spread OFDM
DRX Discontinuous Reception
DTX Discontinuous Transmission
DwPTS Downlink Pilot Time Slot
ECGI E-UTRAN Cell Global Identifier
ECID Enhanced Cell Identification
ECM EPS Connection Management
eMBMS Enhanced Multimedia Broadcast Multicast Service
Page 284/289
EMM EPS Mobility Management

eNB eUTRAN NodeB
eNodeB eUTRAN NodeB
E-RAB eUTRAN Radio Access Bearer
E-SMLC Evolved Serving Mobile Location Center
ETWS Earthquake and Tsunami Warning System
eUTRA Evolved UTRA
eUTRAN Evolved UTRAN
FDM Frequency Division Multiplexing
GERAN GSM EDGE Radio Access Network
GNSS Global Navigation Satellite System
GSM Global System for Mobile communication ( ou Groupe Spécial Mobile )
GP Guard Period
GPS Global Positioning System
GWCN GateWay Core Network
HARQ Hybrid ARQ
HO Handover
HRPD High Rate Packet Data
HSDPA High Speed Downlink Packet Access
ICIC Inter-Cell Interference Coordination
ISI Inter-Symbol Interference
LB Load Balancing
LCR Low Chip Rate
LPP LTE Positioning Protocol
MBMS Multimedia Broadcast Multicast Service
MBMS-GW MBMS GateWay
MBR Maximum Bit Rate
MBSFN Multimedia Broadcast multicast service Single Frequency Network
MCC Mobile Country Code
MCCH Multicast Control CHannel
MCE Multi-cell/multicast Coordination Entity
MIB Master Information Block
MMTEL Multi-Media Telephony
MNC Mobile Network Code
MO Management Object (refer to the parameter object) or
MO Mobile Originated (call)
MOCN Multi-Operator Core Network
MT Mobile Terminated (call)
MTCH Multicast Traffic CHannel
MSAP MCH Sub-frame Allocation Pattern
N.A Not Applicable
NAS Non-Access Stratum
NCC Next Hop Chaining Counter
NH Next Hop key
NR Neighbour cell Relation
NRT Neighbour Relation Table
Page 285/289
N.S Not Significant

O.D Operator Dependant (depends on operator network specific
configuration)
OTA Over-The-Air
OTDOA Observed Time Difference of Arrival
P-GW PDN Gateway
P-RNTI Paging RNTI
PA Power Amplifier
PBCH Physical Broadcast CHannel
PBR Prioritised Bit Rate
PCFICH Physical Control Format Indicator CHannel
PCH Paging Channel
PCI Physical Cell Identifier
PDCCH Physical Downlink Control CHannel
PDSCH Physical Downlink Shared CHannel
PHICH Physical Hybrid ARQ Indicator CHannel
PHY Physical layer
PLMN Public Land Mobile Network
PMCH Physical Multicast CHannel
PRACH Physical Random Access CHannel
PRS Position Reference Signal
PSC Packet Scheduling
PUCCH Physical Uplink Control CHannel
PUSCH Physical Uplink Shared CHannel
OL Overload
RA-RNTI Random Access RNTI
RAC Radio Admission Control
RACH Random Access Channel
RAN Radio Access Network
RAT Radio Access Technology
RB Radio Bearer
RBC Radio Bearer Control
RBG Radio Bearer Group
RF Radio Frequency
RIM RAN Information Management
RNC Radio Network Controller
RNL Radio Network Layer
ROHC Robust Header Compression
RS Reference Signal
RSRP Reference Signal Received Power
RTD Round Trip Delay
RU Resource Unit
SA Service Area
Page 286/289

S-GW Serving Gateway
S1-MME S1 for the control plane
SC-RNTI System Information Change RNTI
SCFCQ Sub-CFCQ
SI System Information
SIB System Information Block
SI-RNTI System Information RNTI
S1-U S1 for the user plane
SAE System Architecture Evolution
SAP Service Access Point
SCH Synchronization Channel
SDF Service Data Flow
SDMA Spatial Division Multiple Access
SDU Service Data Unit
SFN System Frame Number
SLP Supplemental Location Platform
SPID Subscriber Profile ID for RAT/Frequency Priority
SR Scheduling Request
SRB Signalling Radio Bearer
SSAC Service Specific Access Control
SU Scheduling Unit
TA Tracking Area
TB Transport Block
TEG Transport Engineering Guide
TFT Traffic Flow Template
TM Transparent Mode
TNL Transport Network Layer
UE User Equipment
UL Uplink
UM Un-acknowledge Mode
U-plane User plane
UpPTS Uplink Pilot Time Slot
WPS Wireless Provisioning System
X2-C X2-Control plane
X2-U X2-User plane
Page 287/289
Z END OF VOLUME Y
Page 288/289
VOLUME 6 MOBILITY
Volume 6 : Mobility
1 INTRODUCTION ..............................................................................................................................20
1.1 OBJECT ...................................................................................................................................20
1.2 SCOPE OF THIS VOLUME ........................................................................................................20
1.3 LIST OF RELATED FEATURES ............................................................................................22

2.1 LPUG VOLUMES ......................................................................................................................24
2.3 PREREQUISITESFOR READING THIS VOLUME ................................................................26
3 OVERVIEW ......................................................................................................................................26
4 RRC IDLE MODE MOBILITY ..........................................................................................................26

4.1 CELL SELECTION AND RESELECTION PROCEDURES .........................................................26
4.1.1 INTER TRACKING AREA MOBILITY: ..............................................................................26
LteCell::trackingAreaCode ................................................................. 27
LteNeighboringCellRelation::trackingAreaCode .............................. 27
4.1.2 PLMN Selection & CELL RESERVATION and CELL RESTRICTION .............................27
4.1.3 INTRA-FREQUENCY RRC IDLE MODE MOBILITY ........................................................28
4.1.3.1 CELL RESELECTION ALGORITHM DESCRIPTION .................................................28
4.1.3.1.1 CELL SELECTION CRITERION .................................................................................... 28
CellSelectionReselectionConf::pMax ................................................ 31
CellReselectionConfLte::pMax ........................................................... 32
CellSelectionReselectionConf::qRxLevMin ...................................... 33
CellSelectionReselectionConf::qQualMin ......................................... 33
CellReselectionConfLte::qRxLevMin ................................................. 34
CellReselectionConfLte::qQualMin .................................................... 35
CellSelectionReselectionConf::qRxlevminoffset .............................. 35
CellSelectionReselectionConf::qQualMinOffset ............................... 36
CellSelectionReselectionConf::sIntraSearch .................................... 36
CellSelectionReselectionConf::sIntraSearchP ................................. 37
CellSelectionReselectionConf::sIntraSearchQ ................................. 38
LteNeighboringFreqConf::measurementBandwidth ........................ 38
CellReselectionConfLte::cellReselectionPriority ............................. 40
4.1.3.1.2 INTRA-FREQUENCY AND EQUAL PRIORITY INTER-FREQUENCY CELL
RESELECTION CRITERIA ...................................................................................................................... 41
CellSelectionReselectionConf::qHyst................................................ 42
CellReselectionConfLte::tReselectionEUTRAN ................................ 42
4.1.3.1.3 SIB4 Broadcasting and Blacklisted Cells for Mobility.................................................. 45
LteNeighboringCellRelation::qOffsetCell .......................................... 45
LteNeighboringOpenOrHybridHeNBCellLayerRelation::qoffsetcell45
4.1.4 Inter-Frequency RRC IDle Mode Mobility .........................................................................46
4.1.4.1 CELL SELECTION CRITERION ..................................................................................46
4.1.4.2 CELL RESELECTION CRITERION.............................................................................48
Page 1/543
Volume 6 : Mobility
ActivationService::isInterFreqEutraSameFrameStructureMobilityAll
owed.................................................................................................................... 48
ActivationService::isInterFreqEutraOtherFrameStructureMobilityEn
abled ................................................................................................................... 48
BlackCellConf::range .......................................................................... 50
BlackCellConf::start ............................................................................ 50
CellSelectionReselectionConf::threshServingLow .......................... 54
CellSelectionReselectionConf::threshServingLowQ........................ 54
CellReselectionConfLte::threshXHigh ............................................... 55
CellReselectionConfLte::threshXHighQ ............................................ 56
CellReselectionConfLte::threshXLow................................................ 56
CellReselectionConfLte::threshXLowQ ............................................. 57
4.1.4.3 Configuration Model for SystemInformationBlockType5 Parameters ..........................57
4.1.5 INTER-RAT CELL RESELECTION TO UTRAN ...............................................................58
4.1.5.1 CELL RESELECTION ACTIVATION ...........................................................................58
ActivationService::isMobilityToUtranAllowed .................................. 59
4.1.5.2 SIB 6 AND SIB 3 FOR CELL RESELECTION.............................................................59
4.1.5.3.1 CELL SELECTION CRITERIA ON SERVING CELL .................................................. 60
CellSelectionReselectionConf::sNonIntraSearch ............................. 61
CellSelectionReselectionConf::sNonIntraSearchP .......................... 62
CellSelectionReselectionConf::sNonIntraSearchQ .......................... 63
4.1.5.3.2 CELL SELECTION CRITERIA ON TARGET CELLS ................................................. 63
CellReselectionConfUtraFdd::qRxLevMin ......................................... 66
CellReselectionConfUtraFdd::pMaxUTRA......................................... 66
CellReselectionConfUtraFdd::qQualMin ........................................... 67
4.1.5.3.3 CELL RESELECTION PRIORITIES HANDLING ........................................................ 69
UeTimers::t320 ..................................................................................... 70
4.1.5.3.4 UE SPEED MANAGEMENT ........................................................................................... 70
UtraSpeedDependentConf::tReselectionUtraSfHigh ........................ 71
UtraSpeedDependentConf::tReselectionUtraSfMedium .................. 72
4.1.5.3.5 INTER-RAT CELL RESELECTION CRITERIA............................................................ 72
UtraNeighboring::tReselectionUtra.................................................... 74
CellReselectionConfUtraFdd::threshXHigh ...................................... 75
CellReselectionConfUtraFdd::threshXHighQ .................................... 76
CellReselectionConfUtraFdd::threshXLow ....................................... 76
CellReselectionConfUtraFdd::threshXLowQ .................................... 77
4.1.5.3.6 ALGORITHM FOR CELL RESELECTION PRIORITY ............................................... 78
CellReselectionConfUtraFdd::cellReselectionPriority ..................... 79
UtraFddNeighboringFreqConf::bandUtraFdd ................................... 80
UtraFddNeighboringFreqConf::carrierFreq....................................... 80
4.1.5.3.7 LTE TO UTRA FDD RESELECTION CONFIGURATION .......................................... 80
4.1.6 INTER-RAT CELL RESELECTION TO GERAN ..............................................................81
4.1.6.1 CELL RESELECTION ACTIVATION ...........................................................................82
ActivationService::isMobilityToGeranAllowed ................................. 82
4.1.6.2.1 CELL SELECTION CRITERION on SERVING CELL................................................. 83
4.1.6.2.2 CELL SELECTION CRITERION on TARGETS CELLS ............................................. 85
CellReselectionConfGERAN::qRxLevMin ......................................... 87
CellReselectionConfGERAN::pMaxGeran ......................................... 87
CellReselectionConfGERAN::nccPermitted ...................................... 89
4.1.6.2.3 CELL RESELECTION PRIORITIES HANDLING ........................................................ 89
4.1.6.2.4 UE SPEED MANAGEMENT ........................................................................................... 89
GeranSpeedDependentConf::tReselectionGERANSfHigh ............... 91
GeranSpeedDependentConf::tReselectionGERANSfMedium ......... 92
4.1.6.2.5 E-UTRAN INTER-FREQUENCY AND INTER-RAT CELL RESELECTION
CRITERIA 92
Page 2/543
Volume 6 : Mobility
GeranNeighboring::tReselectionGERAN ........................................... 94
CellReselectionConfGERAN::threshXHigh ....................................... 94
CellReselectionConfGERAN::threshXLow ........................................ 95
4.1.6.2.6 ALGORITHM FOR CELL RESELECTION PRIORITY ............................................... 96
CellReselectionConfGERAN::cellReselectionPriority ...................... 97
GeranNeighboringFreqsConf::GeranARFCNList .............................. 97
GeranNeighboringFreqsConf::bandGERAN ..................................... 98
4.1.6.2.7 LTE TO GERAN RESELECTION CONFIGURATION ................................................ 98
4.1.7 inter-rat cell reselection to HRPD or 1xRTT .....................................................................98
LteCell::searchWindowSizeSIB8 ........................................................ 99
ActivationService::isSynchCDMASystemTimeAllowed ................... 99
HrpdNeighboring::hrpdInfoConfigured ........................................... 100
OneXRttNeighboring::oneXRttInfoConfigured ............................... 101
4.1.7.1 HRPD cell reselection parameters in sib8 .................................................................101
HrpdNeighboring::tReselectionCdmaHrpd ..................................... 103
CellReselectionConfHrpd::cellReselectionPriority ........................ 103
CellReselectionConfHrpd::threshXHigh .......................................... 104
CellReselectionConfHrpd::threshXLow........................................... 104
4.1.7.2 HRPD Neighbor parameters in sib8 ..........................................................................104
HrpdBandClassConf::bandClass ..................................................... 105
HrpdNeighboringPerCarrier::frequency .......................................... 105
HrpdNeighboringPerCarrier::pnOffsetList ...................................... 106
HrpdNeighboring::hrpdPreRegAllowed........................................... 106
4.1.7.3 HRPD speed dependent parameters in Sib8.............................................................107
HrpdSpeedDependentConf::tReselectionHrpdSfHigh ................... 107
HrpdSpeedDependentConf::tReselectionHrpdSfMedium .............. 107
4.1.7.4 1xRTT cell reselection parameters in Sib8 ................................................................107
OneXRttNeighboring::tReselectionCdma1xRtt ............................... 110
CellReselectionConf1xRtt::cellReselectionPriority ........................ 110
CellReselectionConf1xRtt::threshXHigh ......................................... 111
CellReselectionConf1xRtt::threshXLow .......................................... 111
4.1.7.5 1XRTT Neighbor parameters in sib8 .........................................................................111
OneXRttBandClassConf::bandClass ............................................... 112
OneXRttNeighboringPerCarrier::frequency .................................... 112
OneXRttNeighboringPerCarrier::pnOffsetList ................................ 113
4.1.7.6 1xRTT speed dependent parameters in Sib8 ............................................................113
OneXRttSpeedDependentConf::tReselection1xRttSfHigh ............. 114
OneXRttSpeedDependentConf::tReselection1xRttSfMedium ....... 114
4.2 SPEED ADJUSTMENT TO CELL SELECTION/RESELECTION PARAMETERS...............114
SpeedStateEvalConf::tEvaluation .................................................... 115
SpeedStateEvalConf::nCellChangeHigh ......................................... 115
SpeedStateEvalConf::nCellChangeMedium .................................... 116
SpeedStateEvalConf::tHystNormal .................................................. 116
SpeedStateEvalConf::qHystSfHigh .................................................. 117
LteSpeedDependentConf::tReselectionEutraSfHigh...................... 118
SpeedStateEvalConf::qHystSfMedium ............................................ 118
LteSpeedDependentConf::tReselectionEutraSfMedium ................ 119
4.2.1 Configuration MODEL .....................................................................................................119
4.3 LOAD BASED ADJUSTMENTS TO CELL SELECTION/RESELECTION PARAMETERS .121
ActivationService::isSIB3ReselectionAutomationEnabled ........... 122
4.3.1 Cell loading calculation ...................................................................................................122
CellSelectionReselectionConf::autoReselectMinInterval .............. 123
CellSelectionReselectionConf::weightDlPrbCell ............................ 124
CellSelectionReselectionConf::weightDlPrbEnb ............................ 124
CellSelectionReselectionConf::weightUlPrbCell ............................ 124
CellSelectionReselectionConf::weightUlPrbEnb ............................ 125
4.3.2 Delta parameter selection ...............................................................................................125
Page 3/543
Volume 6 : Mobility
CellReselectionAdaptation::lowerBound ........................................ 125
CellReselectionAdaptation::upperBound........................................ 126
CellReselectionAdaptation::qHystDelta .......................................... 126
CellReselectionAdaptation::sNonIntraSearchDelta........................ 127
CellReselectionAdaptation::sNonIntraSearchPDelta ..................... 128
CellReselectionAdaptation::sNonIntraSearchQDelta ..................... 128
CellReselectionAdaptation::threshServingLowDelta ..................... 129
CellReselectionAdaptation::threshServingLowQDelta .................. 129
4.3.3 Reselection parameter adjustment .................................................................................130
CellSelectionReselectionConf::autoReselectValueTagChange .... 131
5 EVOLVED MULTI-CARRIER TRAFFIC ALLOCATION (EMCTA) ...............................................131

5.1 EMCTA OVERVIEW ................................................................................................................131
5.2 SUMMARY OF UE MEASUREMENT CONFIGURATIONS..................................................135
5.2.1 EVENT TYPES AND TRIGGERING CONDITIONS .......................................................135
5.2.1.1 EVENT a1 ..................................................................................................................136
5.2.1.2 EVENT a2 ..................................................................................................................137
5.2.1.3 EVENT a3 ..................................................................................................................138
5.2.1.4 EVENT A4 ..................................................................................................................140
5.2.1.5 EVENT A5 ..................................................................................................................141
5.2.1.6 EVENT B1 ..................................................................................................................143
5.2.1.7 EVENT B2 ..................................................................................................................144
5.2.2 SERVING RADIO CONDITION AND UE MEASUREMENT CONFIGURATION ...........146
5.2.3 Measurement Gaps ........................................................................................................148
ActivationService::isMeasurementGapsAllowed ........................... 148
RrcMeasurementConf::measurementGapsPattern ........................ 149
5.2.4 eMCTA Candidate Measurement Truncation .................................................................150
RrcMeasurementConf::maxMeasIdForMultipleMonitoring ............ 151
RrcmeasurementConf::maxNbCarriersForMultipleMonitoringUsing
MeasGaps ......................................................................................................... 152
Enb::maxNumberOfCdmaChannelFor1xCsfbMeasurements ........ 153
5.3 MOBILITY PRIORITY TABLE ......................................................................................................153
ActivationService::isServiceBasedTrafficSegmentationAllowed . 156
MobilityPriorityTable::defaultConnectedPriorityOfFreq ................ 157
ServiceTypePriorityConf::eMctaPriority .......................................... 158
QciPriorityConf::eMctaPriority ......................................................... 158
ServiceTypePriorityConf::serviceType ............................................ 160
QciPriorityConf::qci........................................................................... 162
MobilityPriorityTable::qciHierarchyForMultiQciCallList ................ 164
5.4 EMCTA TRIGGERS .................................................................................................................165
5.4.1 CS Fallbackto UTRAN and GERAN ...............................................................................165

5.4.1.1 UE Capabilities ..........................................................................................................166
5.4.1.2 Mobility Path Information ...........................................................................................166
5.4.1.3 Network Capabilities ..................................................................................................167
5.4.1.4 Service-Based Policy .................................................................................................167
5.4.1.5 RRC Measurement Configuration ..............................................................................169
5.4.2 CS Fallback to 1xRTT .....................................................................................................169
5.4.3 Serving Radio Monitoring ...............................................................................................170
5.4.3.1 UE Capabilities ..........................................................................................................174
ActivationService::isDifferentiateUtranModeInFGIsEnabled ......... 174
TaiListNotSupportingImsVoip::trackingAreaCode ......................... 176
5.4.3.4 QCI-Based Policy.......................................................................................................177
5.4.4 Offload UE upon Reactive Load Control.........................................................................179
Page 4/543
Volume 6 : Mobility
ActivationService::isOffLoadUponReactiveLoadControlAllowed . 180
Enb::tMeasWaitForOffload ............................................................... 180
5.4.4.1 UE Capabilities ..........................................................................................................181
5.4.4.4 QCI-Based Policy.......................................................................................................182
5.4.5 Offload UE upon Preventive Load Control .....................................................................183
ActivationService::isInterFreqLoadBalancingFeatureEnabled ..... 184
ActivationService::isUtraPreventiveLoadControlEnabled ............. 184
5.4.5.1 Frequency Load Filter ................................................................................................185
UtraLoadBalancingConf::dlUtraCellLoadedThreshold .................. 187
UtraLoadBalancingConf::ulUtraCellLoadedThreshold .................. 187
5.4.5.1.1 Load Filtering at Carrier Level ...................................................................................... 188
5.4.5.1.2 Load Filtering at Cell Level............................................................................................ 189
Enb::dlCellLoadedThreshold ............................................................ 189
Enb::ulCellLoadedThreshold ............................................................ 190
5.4.5.2 Load equalization .......................................................................................................190
LteNeighboringFreqConf::isLoadEqualizationEnabled ................. 191
5.4.5.3 Blind preventive offloading .........................................................................................191
5.4.6 ANR ................................................................................................................................191
6 INTRA-LTE RRC CONNECTED MODE MOBILITY PROCEDURES ...........................................192

6.1 INTRA-FREQUENCY RRC CONNECTED MODE MOBILITY......................................................192
6.1.1 INVOKING INTRA-FREQUENCY RRC CONNECTED MODE MOBILITY ....................192
6.1.1.1 EVENTA3 MEASUREMENT CONFIGURATION MODEL ........................................194
6.1.1.2 RRC MEASUREMENT CONFIGURATION PARAMETERS .....................................195
RrcMeasurementConf::filterCoefficientRSRP ................................. 197
RrcMeasurementConf::filterCoefficientRSRQ ................................ 198
RrcMeasurementConf::measurementIdentityConfIdList ............... 199
RrcMeasurementConf::sMeasure .................................................... 199
ReportConfigEUTRA::triggerQuantity ............................................. 200
ReportConfigEUTRA::reportQuantity .............................................. 200
ReportConfigEUTRA::maxReportCells ............................................ 201
ReportConfigEUTRA::hysteresis ..................................................... 202
ReportConfigEUTRA::timeToTrigger ............................................... 204
ReportConfigEUTRA::reportInterval ................................................ 206
ReportConfigEUTRA::reportAmount ............................................... 207
6.1.1.3 THRESHOLDS FOR INTER-RAT MOBILITY WITH INTRA-LTE MEASUREMENTS:
BLIND 207
ReportConfigEUTRA::triggerTypeEUTRA ....................................... 208
ReportConfigEUTRA::eventA3Offset ............................................... 209
ReportConfigEUTRA::thresholdEutraRsrp ..................................... 211
ReportConfigEUTRA::thresholdEutraRsrq ..................................... 212
LteCell::cellIndividualOffset ............................................................. 212
6.1.1.4 SPEED STATE MEASUREMENTS CONFIGURATION ...........................................214
RrcMeasurementConf::timeToTriggerSfHigh ................................. 215
RrcMeasurementConf::timeToTriggerSfMedium ............................ 216
6.1.2 REPORTING SETTING FOR INTRA-FREQUENCY MEASUREMENTS ......................216
MeasurementIdentityConf::measurementPurpose ......................... 217
MeasurementIdentityConf::measObjectLink................................... 218
MeasurementIdentityConf::reportConfigLink ................................. 218
ReportConfig::reportConfigId .......................................................... 218
6.1.2.1 Measurement setup upon transition to RRC-Connected state ..................................219
6.1.2.2 Measurement update upon completion of handover .................................................219
Page 5/543
Volume 6 : Mobility
MeasObjectEUTRA::dlEARFCN ........................................................ 223
LteNeighboringFreqConf::dlEARFCN .............................................. 223
MeasObjectEUTRA::offsetFreq ........................................................ 224
LteNeighboringFreqConf::offsetFreq .............................................. 224
LteNeighboringFreqConf::neighCellConfig .................................... 225
LteNeighboringFreqConf::presenceAntennaPort1 ......................... 226
6.1.2.3 NEIGHBOR CELL INFORMATION PROVIDED TO UES IN CONNECTED MODE.226
LteNeighboringCellRelation::cellIndividualOffset .......................... 227
LteNeighboringOpenOrHybridHeNBCellLayerRelation::cellIndividua
lOffset ............................................................................................................... 227
6.1.3 TRIGGERING INTRA-FREQUENCY RRC CONNECTED MODE MOBILITY ...............228
6.1.3.1 Intra-frequency handover ...........................................................................................228
6.1.3.2 Reception of a RRCConnectionReconfiguration including the
mobilityControlInformation by the UE (handover) .........................................................................228
UeTimers::t304 ................................................................................... 229
6.1.3.3 TARGET CELL SELECTION .....................................................................................229
LteNeighboringCellRelation::noHoOrReselection .......................... 231
X2Access::noX2HO ........................................................................... 231
6.1.3.4 HANDOVER TYPE SELECTION ...............................................................................232
6.1.3.4.1 X2-C INTERFACE NOT AVAILABLE .......................................................................... 233
6.1.3.5 TARGET eNB NOT CONNECTED TO SERVING MME ...........................................233
6.1.3.5.1 X2 HANDOVER REJECTED WITH APPROPRIATE CAUSE ................................. 235
6.1.3.5.2 SELECTION OF S1 HANDOVER OR X2 HANDOVER BASED ON
CONFIGURATION .................................................................................................................................. 236
6.1.4 HANDOVER PROCEDURE FOR INTRA-FREQUENCYRRC CONNECTED MODE
MOBILITY ........................................................................................................................................237
6.1.4.1 MOBILITY ACTIVATION............................................................................................238
ActivationService::isIntraFreqMobilityAllowed .............................. 238
6.1.4.2 INTRA-FREQUENCY INTRA-eNB MOBILITY ..........................................................238
OverloadControl::intraEnbHoReqRejectRateMinor ........................ 243
OverloadControl::intraEnbHoReqRejectRateMajor ........................ 243
6.1.4.2.1 Key Refresh or Re-keying ............................................................................................. 243
6.1.4.2.2 Intra-frequency intra-eNB mobility with Carrier Aggregation.................................... 244
6.1.4.3 INTRA-FREQUENCY INTER-eNB – X2 Handover ...................................................246
TrafficBasedReleaseConf::inactivityTimerToReleaseOutGoingHOIn
CCMOverload ................................................................................................... 251
OverloadControl::inactivityTimerToSkipHODataForwarding ........ 252
OverloadControl::thrForPOToSkipHODataForwarding .................. 253
ActivationService::isFullConfigForHandoverAllowed.................... 253
ActivationService::isUseCommonIEsForUeConfigReleaseEnabled254
ActivationService::isIncomingHoToReservedCellBasedOnSpidAllo
wed .................................................................................................................... 255
PlmnIdentity::spidAllowedInReservedCells .................................... 255
TrafficRadioBearerConf::dataForwardingForX2HoEnabled .......... 256
ActivationService::isS1EnhancementsAllowed .............................. 258
6.1.4.3.1 Failure Cases .................................................................................................................. 258
ActivationService::isHoRetryToSecondBestCellAllowed .............. 259
OverloadControl::x2HoReqRejectRateMinor .................................. 260
OverloadControl::x2HoReqRejectRateMajor .................................. 260
TrafficBasedReleaseConf::inactivityTimerToRejectInComingHOInC
CMOverload ...................................................................................................... 260
6.1.4.3.2 FEATURE INTERACTIONS ......................................................................................... 261
6.1.4.3.3 Intra-frequency inter-eNB mobility via X2 with Carrier Aggregation ....................... 262
6.1.4.4 INTRA-FREQUENCY Inter-eNB – S1 Handover .......................................................263
6.1.4.4.1 Failure Cases .................................................................................................................. 269
OverloadControl::s1HoReqRejectRateMinor .................................. 270
OverloadControl::s1HoReqRejectRateMajor .................................. 270
6.1.4.4.2 Feature Interactions ....................................................................................................... 271
6.1.4.4.3 S1 Handover parameters .............................................................................................. 272
Page 6/543
Volume 6 : Mobility
TrafficRadioBearerConf::dataForwardingForS1HoEnabled .......... 273
X2Access::directFwdPathAvailability .............................................. 273
S1HoTimersConf::tS1RelocPrepForS1Handover ........................... 274
S1HoTimersConf::tS1RelocOverallForS1Handover ....................... 275
S1HoTimersConf::endFwdData ........................................................ 276
6.1.4.4.4 Intra-frequency inter-eNB mobility via S1 with Carrier Aggregation ....................... 276
6.1.4.5 The Last visited cell information ................................................................................277
LteCell::cellSize ................................................................................. 278
6.1.5 Handover Optimization ...................................................................................................279
6.1.5.1 Handover Optimization COUNTERS .........................................................................279
ActivationService::isRlfMonitoringAllowed .................................... 280
CellActivationService::isMroIntraFreqEnabled ............................... 280
MobilityRobustnessOpt::hoRejectedTimer ..................................... 280
6.1.5.1.1 Handover Too Early ....................................................................................................... 281
LteCell::hoReportTimer..................................................................... 281
6.1.5.1.2 Handover Too Late......................................................................................................... 286
6.1.5.1.3 Handover to Wrong Cell ................................................................................................ 288
6.1.5.1.4 Ping Pong Handover ...................................................................................................... 298
MobilityRobustnessOpt::pingPongTime ......................................... 299
6.1.5.2 Handover Optimization Algorithm ..............................................................................299
6.1.5.2.1 Handover Parameters to Optimize .............................................................................. 299
MobilityRobustnessOptCell::a3OffsetMin ....................................... 300
MobilityRobustnessOptCell::a3OffsetMax ...................................... 300
MobilityRobustnessOptCell::cioMin ................................................ 301
MobilityRobustnessOptCell::cioMax ............................................... 301
MobilityRobustnessOptCell::timeToTriggerAllowedValues .......... 302
6.1.5.2.2 Handover Optimization Algorithm Steps ..................................................................... 302
MobilityRobustnessOpt::minMobilityEventsGeneral ..................... 303
MobilityRobustnessOpt::mroCostGeneralOk ................................. 303
MobilityRobustnessOpt::tooEarlyWeight ........................................ 303
MobilityRobustnessOpt::tooLateWeight ......................................... 304
MobilityRobustnessOpt::pingPongWeight ...................................... 304
MobilityRobustnessOpt::wrongCellWeight ..................................... 304
MobilityRobustnessOpt::attemptOppositeDirection ...................... 306
MobilityRobustnessOpt::minMobilityEventsPerNeighbor ............. 307
MobilityRobustnessOpt::minNeighborimbalance .......................... 307
MobilityRobustnessOpt::cioBeginAdjustThreshold....................... 307
MobilityRobustnessOpt::maxAdjustmentAttempts ........................ 308
MobilityRobustnessOpt::fasterSlowerMargin ................................. 308
LteCell::mroCostHysteresis ............................................................. 309
6.2 LTE INTER-FREQUENCY RRC CONNECTED MODE MOBILITY .....................................309
6.2.1 INTEr-FREQUENCY UE MEASUREMENT CRITERIA..................................................309
6.2.2 INTER-FREQUENCY UE MEASUREMENT CONFIGURATION ...................................310
6.2.3 INTER-FREQUENCY REDIRECTION ...........................................................................311
6.2.4 INTER-FREQUENCY HANDOVER ................................................................................312
6.2.5 INTER-FREQUENCY MOBILITY WITH CARRIER AGGREGATION ............................314
6.3 ENB MACRO/METRO CELL TO HENB OPEN CELL MOBILITY ......................................................314
ActivationService::isMobilityToHeNBEnabled ................................ 314
LteNeighboringOpenOrHybridHeNBCellLayerRelation::pCIList ... 315
6.3.1 eNB to HeNB Handover Procedure ................................................................................317
6.3.2 170745 Neighbor cell classification and mobility counters for HetNet............................319
6.3.2.1 NEIGHBOR TYPE IDENTIFICATION METHODS.....................................................319
6.3.2.2 eNB Interaction with and dependencies on other features ........................................320
6.3.2.3 Proposed Network Architecture .................................................................................320
6.3.2.4 Feature scenarios ......................................................................................................321
6.3.2.5 Activation Strategy .....................................................................................................322
6.3.2.5.1 Intra-Freq Metro Deployment in Macro: ...................................................................... 322
6.3.2.5.2 Inter-freq Metro deployment in Macro ......................................................................... 322
6.3.2.5.3 HeNB Deployment in Macro /Metro: ............................................................................ 322
Page 7/543
Volume 6 : Mobility
6.3.2.6 Parameters related ....................................................................................................323
LteNeighboringCellRelation::cellKind ............................................. 323
CellKindPerCellSizeConf::cellKindForCellSizeLarge ..................... 323
CellKindPerCellSizeConf::cellKindForCellSizeMedium ................. 324
CellKindPerCellSizeConf::cellKindForCellSizeSmall ..................... 324
CellKindPerCellSizeConf::cellKindForCellSizeVerySmall ............. 325
ActivationService::isAutoUpdateOnLteNeighborCellKindEnabled325
6.3.2.7 Counters Pegged .......................................................................................................325
7 EUTRAN TO UTRAN RRC CONNECTED MODE MOBILITY PROCEDURES ...........................326

7.1 EUTRAN TO UTRAN UE MEASUREMENT CONFIGURATION .........................................326
RrcMeasurementConf::measQuantityUtraFdd ................................ 327
RrcMeasurementConf::filterCoefficientOfQuantityConfigUtra ...... 327
7.1.1 PARAMETERS UNDER MEASOBJECTUTRA ..............................................................327
MeasObjectUTRA::offsetFreqUTRA ................................................. 328
MeasObjectUTRA::carrierFreq ......................................................... 328
7.1.2 PARAMETERS UNDER REPORTCONFIGUTRA .........................................................328
ReportConfigUTRA::hysteresis ........................................................ 329
ReportConfigUTRA::thresholdEutraRsrpB2 ................................... 330
ReportConfigUTRA::thresholdEutraRsrqB2 ................................... 330
ReportConfigUTRA::thresholdUtraEcN0 ......................................... 330
ReportConfigUTRA::thresholdUtraRscp ......................................... 331
ReportConfigUTRA::maxReportCells .............................................. 331
ReportConfigUTRA::timeToTrigger ................................................. 331
ReportConfigUTRA::reportInterval .................................................. 332
ReportConfigUTRA::reportAmount.................................................. 332
ReportConfigUTRA::triggerTypeInterRAT ....................................... 332
ReportConfigUTRA::reportQuantityUtraFddR10 ............................ 333
7.1.3 RRC MEASUREMENT CONFIGURATION MODEL ......................................................333
7.2 EUTRAN TO UTRAN REDIRECTION PROCEDURES .......................................................334
7.3 EUTRAN TO UTRAN PS HANDOVER PROCEDURES.......................................................336
7.3.1 Overview of PS handover ...............................................................................................336
ActivationService::isPsHoToUtraAllowed ....................................... 336
7.3.2 PS handover procedure in enb .......................................................................................337
UtraFddNeighboringCellRelation::physCellIdUTRA ....................... 338
UtraFddNeighboringCellRelation::rncAccessId ............................. 338
UtraFddNeighboringSmallCellLayerRelation::rncAccessId .......... 338
RncAccess::psHandoverUtraEnabled ............................................. 339
7.3.2.1 handover Preparation phase .....................................................................................339
RncAccess::psHoToUtraTimersConfId ........................................... 340
PsHoToUtraTimersConf::tS1RelocPrepForPsHandoverToUtra .... 340
UtraFddNeighboringCellRelation::lac .............................................. 341
UtraFddNeighboringCellrelation::rac............................................... 342
RncAccess::rncId .............................................................................. 342
RncAccess::extendedRncId ............................................................. 342
RncAccess::directFwdPathAvailability ........................................... 343
UtraFddNeighboringCellrelation::cId ............................................... 343
7.3.2.2 handover Execution phase ........................................................................................343
PsHoToUtraTimersConf::tS1RelocOverallForPsHandoverToUtra 344
ActivationService::isUtraDataForwardingAllowed ......................... 345
7.4 EUTRAN TO UTRAN FDD SMALL CELL MOBILITY SUPPORT.........................................345
Page 8/543
Volume 6 : Mobility
ActivationService::isMobilityToUtranOpenSmallCellEnabled ....... 345
UtraFddNeighboringSmallCellLayerRelation::pciUtraFddForOpenS
mallCellList ....................................................................................................... 346
UtraFddNeighboringSmallCellLayerRelation::voiceOverIpCapability347
RncAccess::isSmallCellGateway ..................................................... 347
PerformanceManagement::mobilityToUtranOpenSmallCellReported350
8 EUTRAN TO GERAN RRC CONNECTED MODE MOBILITY PROCEDURES ...........................350

8.1 EUTRAN TO GERAN MEASUREMENT CONFIGURATION ...............................................350
RrcMeasurementConf::measQuantityGERAN ................................ 351
RrcMeasurementConf::filterCoefficientOfQuantityConfigGERAN 351
8.1.1 PARAMETERS UNDER MEASOBJECTGERAN ...........................................................351
MeasObjectGERAN::offsetFreqGERAN ........................................... 351
MeasObjectGERAN::nccPermitted .................................................. 352
MeasObjectGERAN::bandGERAN .................................................... 352
MeasObjectGERAN::geranARFCNList............................................. 352
8.1.2 PARAMETERS UNDER REPORTCONFIGGERAN ......................................................353
ReportConfigGERAN::hysteresis ..................................................... 353
ReportConfigGERAN::thresholdEutraRsrpB2 ................................ 354
ReportConfigGERAN::thresholdEutraRsrqB2 ................................ 354
ReportConfigGERAN::thresholdGeran ............................................ 354
ReportConfigGERAN::maxReportCells ........................................... 355
ReportConfigGERAN::reportAmount............................................... 355
ReportConfigGERAN::reportInterval ............................................... 355
ReportConfigGERAN::triggerTypeInterRAT .................................... 356
ReportConfigGERAN::timeToTrigger .............................................. 356
8.2 EUTRAN TO GERAN REDIRECTION PROCEDURES .......................................................357
8.3 EUTRAN TO GERAN CELL CHANGE ORDER PROCEDURES.........................................358
8.3.1 Overview of Cell Change Order with/without NACC.......................................................358
ActivationService::isGeranCcoAllowed .......................................... 359
8.3.2 Cell Change Order Mobility Procedure in eNB ...............................................................359
GeranNeighboringCellRelation::arfcn ............................................. 361
GeranNeighboringCellRelation::baseStationColorCode................ 361
GeranNeighboringCellRelation::networkColorCode ...................... 361
GeranNeighboringCellRelation::networkControlOrder .................. 362
UeTimers::t304CellChangeOrder ..................................................... 363
NaccTimersConf::tMobilityFromEutraCCO ..................................... 363
8.3.3 RAN Information Management (RIM) Procedure for GERAN ........................................363
GeranNeighboringCellRelation::bscAccessId ................................ 364
BscAccess::naccTimersConfId ........................................................ 364
8.3.3.1 GERAN System Information Transfer Initiation .........................................................364
GeranNeighboringCellRelation::isCellIncludedForRedirectionAssist
ance................................................................................................................... 365
BscAccess::rimForNaccEnabled ..................................................... 366
NaccTimersConf::tS1EnbDirectInfoTransferTrir ............................ 367
NaccTimersConf::timeToWaitForEnbDirectInfoTransfer ............... 367
GeranNeighboringCellRelation::lac ................................................. 368
GeranNeighboringCellRelation::rac ................................................. 368
GeranNeighboringCellRelation::ci ................................................... 369
8.3.3.2 GERAN System Information Update .........................................................................369
8.3.3.3 GERAN System Information Update Stop .................................................................370
8.3.3.4 GERAN System Information Update End ..................................................................371
9 EUTRAN TO HRPD RRC CONNECTED MODE MOBILITY PROCEDURES..............................371

9.1 EUTRAN TO HRPD UE MEASUREMENT CONFIGURATION............................................371
RrcMeasurementConf::measQuantityCDMA2000 ........................... 372
9.1.1 parameters under measobjectcdma2000 .......................................................................372
Page 9/543
Volume 6 : Mobility
MeasObjectCDMA2000::bandClass ................................................. 373
MeasObjectCDMA2000::carrierFreq................................................. 373
MeasObjectCDMA2000::cdma2000Type .......................................... 374
MeasObjectCDMA2000::offsetFreq .................................................. 374
MeasObjectCDMA2000::searchWindowSize ................................... 375
9.1.2 parameters under reportconfigcdma2000 ......................................................................375
ReportConfigCDMA2000::hysteresis ............................................... 376
ReportConfigCDMA2000::thresholdCDMA2000 .............................. 376
ReportConfigCDMA2000::thresholdEutraRsrpB2........................... 377
ReportConfigCDMA2000::thresholdEutraRsrqB2........................... 377
ReportConfigCDMA2000::maxReportCells ..................................... 377
ReportConfigCDMA2000::reportAmount ......................................... 378
ReportConfigCDMA2000::reportInterval.......................................... 378
ReportConfigCDMA2000::timeToTrigger......................................... 379
ReportConfigCDMA2000::triggerTypeInterRAT .............................. 379
9.2 EUTRAN TO HRPD REDIRECTION PROCEDURE ............................................................379
ActivationService::isMobilityToHrpdAllowed ................................. 380
ActivationService::isHrpdMeasBasedRedirAllowed ...................... 380
10 CS FALLBACK AND S RVCC .......................................................................................................382

10.1 CS FALLBACK TO UTRAN AND GERAN..................................................................................382
10.1.1 Overview .........................................................................................................................382
ActivationService::isCsfbEnhancedRedirectionAndPsHoAllowed383
10.1.2 CS Fallback Procedure in eNB .......................................................................................385
ActivationService::isCsFallbackToUtraAllowed ............................. 385
ActivationService::isCsFallbackToGeranAllowed .......................... 386
ActivationService::isCsfbEnhancedRedirectionEnabled............... 388
UtraFddNeighboringCellRelation::utraSystemInformationContainer389
GeranNeighboringCellRelation::dtmCapability .............................. 393
10.1.3 CS Fallback UE Measurement Configuration .................................................................393
10.1.3.1 Event B1 or B2 Configuration ....................................................................................393
10.1.3.2 Measurement GAPs and DRX Setting for CS Fallback .............................................394
ActivationService::isForcedDrxForCsFallbackAllowed ................. 395
Enb::maxTimeAllowedForCsfbMobilityAttempt ............................. 395
10.1.4 CS Fallback mobility Procedure to Utran ........................................................................396
ActivationService::isPsHoToUtraForCsfbGeneralVoiceCallAllowed396
ActivationService::isPsHoToUtraForCsfbEmergencyCallAllowed396
ActivationService::isUtraCsfbBasedOnUeStateAllowed ............... 397
10.1.5 RAN Information Management (RIM) Procedure for UTRAN .........................................399
RncAccess::rimForUtraSiEnabled ................................................... 400
RncAccess::utraSiTimersConfId ...................................................... 400
RncAccess::rimForCellLoadEnabled............................................... 401
RncAccess::utraCellLoadTimersConfId .......................................... 401
10.1.5.1 UTRAN System Information Transfer Initiation..........................................................402
10.1.5.1.1 UTRAN System Information Transfer Initiation for System Information Retrieving402
UtraFddNeighboringCellRelation::isCellIncludedForRedirectionAssi
stance ............................................................................................................... 402
UtraSiTimersConf::tS1EnbDirectInfoTransferTrir .......................... 404
UtraSiTimersConf::timeToWaitForEnbDirectInfoTransfer ............. 404
10.1.5.1.2 UTRAN System Information Transfer Initiation for Cell Load Retrieving ............... 404
ActivationService::isUtraLoadBalancingEnabled .......................... 405
UtraCellLoadTimersConf::tS1EnbDirectInfoTransferTrir ............... 405
UtraCellLoadTimersConf::timeToWaitForEnbDirectInfoTransfer . 406
UtraLoadBalancingConf::numberOfMeasReportingLevels ........... 407
10.1.5.2 UTRAN System Information update ..........................................................................407
10.1.5.2.1 UTRAN System Information Update for System Information Retrieving ................ 407
10.1.5.2.2 UTRAN System Information Update for Cell Load Retrieving ................................. 408
10.1.5.3 UTRAN System Information update Stop ..................................................................408
Page 10/543
Volume 6 : Mobility
10.1.5.3.1 UTRAN System Information Update Stop for System Information Retrieving ...... 408
10.1.5.3.2 Utran System Information Update Stop for Cell Load Retrieving ............................ 409
10.1.5.4 UTRAN System Information update End ...................................................................410
10.1.5.4.1 UTRAN system Information Update End for System Information Retrieving ........ 410
10.1.5.4.2 UTRAN system Information Update End for Cell Load Retrieving.......................... 411
10.1.6 CS Fallback Mobility Procedure to GERAn ....................................................................411
ActivationService::isCcoWithNaccForCsfbGeneralVoiceCallAllowe
d......................................................................................................................... 412
ActivationService::isCcoWithNaccForCsfbEmergencyCallAllowed412
ActivationService::isGeranCsfbBasedOnUeStateAllowed ............ 413
10.1.7 Resource Reservation for emergency call ......................................................................415
10.2 CS FALLBACK TO 1XRTT ........................................................................................................415
10.2.1 Overview .........................................................................................................................415
10.2.2 1xRTT CS Pre-Registration Procedure ..........................................................................416
10.2.2.1 Parameters To GenerateAuthentication Challenge Parameter (rand) ......................418
Enb::randUpdateInterval ................................................................... 419
Enb::seed ........................................................................................... 419
10.2.2.2 parameters in OnexRttMobilityParameters MO .........................................................419
OneXRttMobilityParameters::auth ................................................... 420
OneXRttMobilityParameters::daylt .................................................. 421
OneXRttMobilityParameters::fpcFchIncluded ................................ 421
OneXRttMobilityParameters::fpcFchInitSetptRc11 ........................ 421
OneXRttMobilityParameters::fpcFchInitSetptRc12 ........................ 422
OneXRttMobilityParameters::fpcFchInitSetptRc3 .......................... 422
OneXRttMobilityParameters::gcsnaL2AckTimer ............................ 423
OneXRttMobilityParameters::gcsnaSequenceContextTimer ......... 423
OneXRttMobilityParameters::imsi1112 ............................................ 424
OneXRttMobilityParameters::imsiTSupported ................................ 424
OneXRttMobilityParameters::leapSecondsCount .......................... 424
OneXRttMobilityParameters::localTimeOffset ................................ 425
OneXRttMobilityParameters::maxNumAltSo .................................. 425
OneXRttMobilityParameters::mcc .................................................... 426
OneXRttMobilityParameters::minPRev............................................ 426
OneXRttMobilityParameters::pilotIncrement .................................. 426
OneXRttMobilityParameters::prefMsidType.................................... 427
OneXRttMobilityParameters::pRev .................................................. 427
10.2.2.3 1xRTT Reference Cell Parameters ............................................................................427
OneXRttReferenceCell::bandClass .................................................. 428
OneXRttReferenceCell::cellId ........................................................... 428
OneXRttReferenceCell::frequency ................................................... 428
OneXRttReferenceCell::mscId .......................................................... 429
OneXRttReferenceCell::pnOffset ..................................................... 429
OneXRttReferenceCell::sectorNumber ............................................ 429
10.2.3 SIB8 Parameter Configuration to Support 1xCSFB........................................................429
10.2.3.1 1xCSFB Registration Parameters in SIB8 .................................................................430
Page 11/543
Volume 6 : Mobility
OneXRttRegistrationParameters::foreignNidReg ........................... 431
OneXRttRegistrationParameters::foreignSidReg ........................... 431
OneXRttRegistrationParameters::homeReg ................................... 432
OneXRttRegistrationParameters::multipleNid ................................ 432
OneXRttRegistrationParameters::multipleSid ................................ 432
OneXRttRegistrationParameters::nid .............................................. 433
OneXRttRegistrationParameters::parameterReg ........................... 433
OneXRttRegistrationParameters::powerDownReg ........................ 433
OneXRttRegistrationParameters::powerUpReg ............................. 434
OneXRttRegistrationParameters::registrationPeriod ..................... 434
OneXRttRegistrationParameters::registrationZone ....................... 434
OneXRttRegistrationParameters::sid .............................................. 435
OneXRttRegistrationParameters::totalZones ................................. 435
OneXRttRegistrationParameters::zoneTimer .................................. 435
10.2.3.2 1xRTT neighbor parameters ......................................................................................436
10.2.3.3 1xRTT Access Barring Parameters ...........................................................................436
OneXRttAccessBarring::acBarringStatus ....................................... 437
OneXRttAccessBarring::acBarringClass0To9 ................................ 437
OneXRttAccessBarring::acBarringClass10 .................................... 437
OneXRttAccessBarring::acBarringClassEmg ................................. 439
OneXRttAccessBarring::acBarringClassMsg ................................. 440
OneXRttAccessBarring::acBarringClassReg .................................. 440
10.2.4 UE Measurement configuration ......................................................................................440
10.2.4.1 RRC Measurement Configuration Model ...................................................................440
10.2.4.2 1xRTT Measurement .................................................................................................441
ActivationService::isRel8CsfbTo1XRttMeasurementBasedEnabled442
10.2.5 UE Capability and 1xCSFB Procedure Selection ...........................................................443
10.2.6 Release 8 1xCSFB procedure ........................................................................................445
ActivationService::isRel8CsfbTo1XRttEnabled .............................. 445
Enb::maxTimeAllowedFor1xCsfbMeasurements ........................... 447
10.2.7 Enhanced 1xCSFB Procedures ......................................................................................449
ActivationService::isEnhancedCsfbTo1XRttEnabled..................... 449
Enb::maxTimeAllowedFor1xCsfbReEstablishment........................ 453
10.2.8 Dual Receiver UE 1xCSFB Procedure ...........................................................................453
ActivationService::isCsfbTo1xRttForDRxUEallowed ..................... 453
Enb::idle1xCsfbForDualRxUE .......................................................... 456
10.3 SRVCC TO UTRAN FDD/TDD ..............................................................................................457
ActivationService::isSrvccToUtraAllowed ...................................... 457
UtraFddNeighboringCellRelation::voiceOverIpCapability ............. 458
RncAccess::srvccType ..................................................................... 460
SrvccToUtraTimersConf::tS1RelocPrepForSrvccHandoverToUtra461
SrvccToUtraTimersConf::tS1RelocOverallForSrvccHandoverToUtra461
11 AUTOMATIC NEIGHBOR RELATION (ANR) CONFIGURATION AND OPTIMISATION ...........462

11.1 ANR OVERVIEW .....................................................................................................................462
OverloadControl::ovLevelForANRInhibition ................................... 466
AutomaticNeighborRelation::isA2CAhandlingDuringAnrAllowed 466
LteNeighboringCellRelation::userLabel .......................................... 467
X2Access::userLabel ........................................................................ 467
UtraFddNeighboringCellRelation::userLabel .................................. 467
RncAccess::userLabel ...................................................................... 467
LteNeighboringOpenOrHybridHeNBCellLayerRelation::userLabel467
UtraFddNeighboringSmallCellLayerRelation::userLabel ............... 467
11.2 LTE INTRA-FREQUENCY ANR .................................................................................................467
Page 12/543
Volume 6 : Mobility
11.2.1 intra-frequency ANR in Active Phase - Discover Neighbor Relation through UE Reporting468
ActivationService::lteIntraFrequencyAnrEnabled .......................... 468
LteIntraFrequencyAnr::uEContributionTargetInActivePhase ....... 470
LteIntraFrequencyAnr::anrMeasurementOnly ................................ 470
11.2.1.1 Parameters Included in aN intra-frequency NEIGHBOR RELATION ........................470
LteNeighboringCellRelation::measuredByANR .............................. 472
LteNeighboringCellRelation::noRemove ......................................... 472
11.2.1.2 Intra-frequency ANR MEASUREMENT CONFIGURATION......................................472
ReportConfigEUTRA::threshold2EutraRsrp ................................... 476
ReportConfigEUTRA::threshold2EutraRsrq ................................... 476
11.2.1.3 DRX Configuration for ECGI Retrieving.....................................................................476
LteIntraFrequencyAnr::drxCycleForReportCGI .............................. 477
11.2.1.4 DRX Configuration with Measurement Gap...............................................................477
11.2.1.5 Set Up X2 links with Intra-frequency ANR .................................................................477
AutomaticNeighborRelation::
noX2AccessCreationOnIPAddressRetrievalFailure...................................... 479
X2Access::noRemove ....................................................................... 480
11.2.1.6 Conservative ANR Enhancement ..............................................................................481
11.2.2 Receiving Neighbor Relation through X2 Messages with intra-frequency ANR .............481
11.2.3 End of Active Phase........................................................................................................482
LteIntraFrequencyAnr::activePhaseMeasReportHysteresis .......... 482
LteIntraFrequencyAnr::activePhaseMeasReportThreshold .......... 483
11.2.4 intra-frequency ANR in Dormant/Monitoring/Wake-up Phase ........................................483
LteIntraFrequencyAnr::uEContributionTargetInMonitoringPhase 484
AutomaticNeighborRelation::dormantPhaseTimerForCgiDiscovery485
11.2.5 intra-frequency ANR Neighbor Relation Maintenance Function - Garbage Collection ..486
LteIntraFrequencyAnr::garbageCollectionInterval ......................... 486
11.2.6 Intra-frequency ANR Synchronization Function .............................................................487
11.2.7 intra-frequency ANR Reset Function ..............................................................................487
11.3 LTE INTER-FREQUENCY ANR .................................................................................................488
11.3.1 Inter-frequency Anr in active phase – discover neighbor relation through UE reporting 488
ActivationService::lteInterFrequencyAnrEnabled .......................... 488
LteNeighboringFreqConf::anrActiveAfterX2Setup ......................... 489
LteNeighboringFreqConf::anrInitiateX2Setup ................................ 490
LteInterFrequencyAnr::uEContributionTargetInActivePhase ....... 491
LteInterFrequencyAnr::anrMeasurementOnly ................................ 491
11.3.1.1 Inter-frequency anr measurement configuration ........................................................491
11.3.1.2 Idle periods for inter-frequency measurements .........................................................492
LteInterFrequencyAnr::drxCycleForReportCGI .............................. 493
11.3.1.3 Conservative ANR enhancement ..............................................................................493
11.3.2 Receiving Neighbor Relation through X2 Messages with inter-frequency ANR .............493
11.3.3 end of active phase .........................................................................................................493
LteInterFrequencyAnr::activePhaseMeasReportThreshold .......... 494
LteInterFrequencyAnr::activePhaseMeasReportHysteresis .......... 495
11.3.4 Inter-frequency anr in dormant/monitoring/wake-up phase ............................................495
LteInterFrequencyAnr::uEContributionTargetInMonitoringPhase 496
11.3.5 inter-frequency anr neighbor relation maintenance function – garbage collection .........497
LteInterFrequencyAnr::garbageCollectionInterval ......................... 497
11.3.6 inter-frequency anr synchronization function ..................................................................498
11.3.7 inter-frequency anr reset function ...................................................................................498
11.4 UTRAN ANR ........................................................................................................................498
11.4.1 UTRAN ANR in Active phase – discover neighbor relation through ue reporting ..........498
ActivationService::utraAnrEnabled ................................................. 499
UtraAnr::uEContributionTargetInActivePhase ............................... 500
UtraFddNeighboringFreqConf::hnbPciList ..................................... 500
11.4.1.1 UtRAN neighbor Relation parameters added by UTRAN ANR feature .....................501
Page 13/543
Volume 6 : Mobility
UtraFddNeighboringCellRelation::measuredByAnr ....................... 501
UtraFddNeighboringCellRelation::noHoOrRedirection .................. 502
UtraFddNeighboringCellRelation::noRemove ................................ 502
11.4.1.2 Association with the Serving Rnc ..............................................................................502
UtraAnr::isRncidInUtraCgi ................................................................ 503
RncAccess::noRemove..................................................................... 503
RoutingArea::locationAreaCode ...................................................... 504
RoutingArea::routingAreaCode ....................................................... 504
11.4.1.3 Utran ANR measurement configuration .....................................................................504
11.4.1.4 UTRAN ANR Idle periods for inter-RAT measurements............................................505
UtraAnr::drxCycleForReportCGI ...................................................... 506
11.4.2 End of active phase ........................................................................................................506
UtraAnr::activePhaseMeasReportHysteresis.................................. 506
UtraAnr::activePhaseMeasReportThreshold .................................. 507
11.4.3 UTRAN ANR in Dormant/monitoring/wake-up phase .....................................................507
UtraAnr::uEContributionTargetInMonitoringPhase ........................ 508
11.4.4 UTRAN ANR neighbor relation maintenance function – garbage collection ..................509
UtraAnr::garbageCollectionInterval ................................................. 509
11.4.5 UTRAN ANR synchronization function ...........................................................................509
11.4.6 UTRAN ANR reset function ............................................................................................509
11.5 LTE ANR ENHANCEMENTS .....................................................................................................510
11.5.1 159506 LTE ANR ENhancements –phase 3 - Enhancements lists ...............................510
11.5.2 ANR NEIGHBOR REPLACEMENT ................................................................................510
LteIntraFrequencyAnr::nRPriorityStatPeriod .................................. 511
LteIntraFrequencyAnr:: nRPriCountMode....................................... 512
LteIntraFrequencyAnr:: nRReplaceHysteresis ............................... 512
LteIntraFrequencyAnr:: filterCoefficientNRPriority ........................ 513
11.5.3 Cardinalities increase......................................................................................................513
11.5.3.1 Increase Neighbour limit per Macro Cell....................................................................513
11.5.3.2 X2 Limit Increase .......................................................................................................514
11.5.4 X2 not created when X2 IP retrieval failure ....................................................................514
11.5.5 171148 LTE ANR ENhancements – phase 3 – ANR Enhancements Up to 72 visible X2
support of March012 FGI bits ..........................................................................................................514
11.6 COORDINATION OF DIFFERENT ANR FUNCTIONS ......................................................................515
11.6.1 Periodically entering monitoring phase ...........................................................................515
11.6.2 ANR measurement dispatch function .............................................................................516
12 FEATURES APPLY TO MOBILITY FROM LTE TO ALL TECHNOLOGIES ...............................521

12.1 MOBILITY MEASUREMENT PARAMETER ENHANCEMENT ..............................................................521
ActivationService::isEnhancedMeasurementParametersEnabled 521
12.1.1 Simultaneous RSRP and rsrq measurements ................................................................522
12.1.2 per-qos class offset to ue measurement configuration thresholds .................................522
Page 14/543
Volume 6 : Mobility
RrcMeasurementConf::rsrpOffsetOnServingCellForOtherGbrCalls524
RrcMeasurementConf::rsrpOffsetOnServingCellForTtiBVoIPCalls524
RrcMeasurementConf::rsrpOffsetOnServingCellForVoIPCalls ..... 525
RrcMeasurementConf::rsrqOffsetOnServingCellForOtherGbrCalls525
RrcMeasurementConf::rsrqOffsetOnServingCellForTtiBVoIPCalls526
RrcMeasurementConf::rsrqOffsetOnServingCellForVoIPCalls ..... 526
RrcMeasurementConf::rsrpOffsetOnNeighborCellForOtherGbrCalls527
RrcMeasurementConf::rsrpOffsetOnNeighborCellForTtiBVoIPCalls527
RrcMeasurementConf::rsrpOffsetOnNeighborCellForVoIPCalls .. 528
RrcMeasurementConf::rsrqOffsetOnNeighborCellForOtherGbrCalls528
RrcMeasurementConf::rsrqOffsetOnNeighborCellForTtiBVoIPCalls529
RrcMeasurementConf::rsrqOffsetOnNeighborCellForVoIPCalls .. 529
RrcMeasurementConf::cpichEcn0OffsetForOtherGbrCalls ........... 530
RrcMeasurementConf::cpichEcn0OffsetForTtiBVoIPCalls ............ 530
RrcMeasurementConf::cpichEcn0OffsetForVoIPCalls................... 531
RrcMeasurementConf::cpichRscpOffsetForOtherGbrCalls .......... 531
RrcMeasurementConf::cpichRscpOffsetForTtiBVoIPCalls ........... 532
RrcMeasurementConf::cpichRscpOffsetForVoIPCalls .................. 532
RrcMeasurementConf::rssiOffsetForOtherGbrCalls ...................... 533
RrcMeasurementConf::rssiOffsetForTtiBVoIPCalls ....................... 533
RrcMeasurementConf::rssiOffsetForVoIPCalls .............................. 534
RrcMeasurementConf::pilotStrengthOffsetForOtherGbrCalls ...... 534
12.1.3 UE consecutive measurement configuration ..................................................................535
RrcMeasurementConf::mediumToHighPriorityThreshold ............. 536
RrcMeasurementConf::lowToMediumPriorityThreshold ............... 536
RrcMeasurementConf::timeOffsetForMediumPriorityCarriers ...... 537
RrcMeasurementConf::timeOffsetForLowPriorityCarriers ............ 537
12.2 MOBILITY MEASUREMENT RANGE EXTENSION FOR EMERGENCY CALLS ....................................537
13 ANNEX: ..........................................................................................................................................539
13.1 ABBREVIATIONS ................................................................................................................539
Page 15/543
Volume 6 : Mobility
TABLES
Table 1: First condition for non-serving cell is considered to be detectable: RSRP AND RSRQ are
involved in Release 9................................................................................................................................. 28
Table 2: Cell Reselection Criteria parameters ............................................................................................... 30
Table 3: UE power Class vs. LTE maximum output power, Pumax. .......................................................... 32
Table 4: Transmission bandwidth configuration NRB in E-UTRA channel bandwidths............................. 39
Table 5: Cell Ranking Procedure parameters ................................................................................................ 41
Table 6: Measurements of EUTRAN FDD cells selection [3GPP 36133]. ................................................. 43
Table 7: Cell Reselection Criteria parameters ............................................................................................... 65
Table 8: UE power Class vs. maximum output power, Pumax. .................................................................. 67
Table 9: Measurements of UTRAN FDD cells selection [3GPP 36133]. ................................................... 74
Table 10: Parameter to propagate between both WCDMA network and LTE network for iRAT
configuration................................................................................................................................................ 81
Table 11: Cell Reselection Criteria parameters ............................................................................................. 86
Table 12: Maximum TX power level an UE may use when transmitting on the uplink in the cell (dBm).
...................................................................................................................................................................... 88
Table 13: UE power Class vs. maximum output power, Pumax. ................................................................ 88
Table 14:MeasConfig information element ................................................................................................... 198
Table 15:ReportConfigEUTRA information element ................................................................................... 202
Table 16:An Example on How to set LteCell::cellSize ................................................................................ 279
Table 17: CellSize Mapping Table ................................................................................................................. 322
Page 16/543
Volume 6 : Mobility
FIGURES
Figure 1 : Start of measurements for reselection if serving cell is degraded under a RSRP threshold ......... 31
Figure 2 : Start of measurements for reselection if serving cell is degraded under a RSRQ threshold for UE
R9 capable. .......................................................................................................................................................... 31
Figure 3: The Definition of Channel Bandwidth and Transmission Bandwidth Configuration for one E-UTRA
carrier .................................................................................................................................................................... 39
Figure 4 : Cell Reselection criteria intra-LTE intra-frequency and equal priority inter-frequency .................... 44
Figure 5 : Ranking between Equal priority cells. .................................................................................................... 44
Figure 6 : Start of measurements for inter-freq reselection if serving cell is degraded under a RSRP
threshold ............................................................................................................................................................... 47
Figure 7 : Start of measurements for inter-freq reselection if serving cell is degraded under a RSRQ
threshold ............................................................................................................................................................... 47
Figure 8 : User Case, with R8 UE Class3 and in the same PLMN, showing reselection towards higher
priority EUTRAN cell inter-freq. ......................................................................................................................... 51
Figure 9 : User Case, with R8 UE Class3 and in the same PLMN, showing reselection towards lower
Figure 10 : User Case, with R8 UE Class3 and in the same PLMN, showing reselection towards equal
Figure 11 Configuration Model for SIB5 Parameters ............................................................................................. 57
Figure 12: Reselection from eUTRAN to UTRAN .................................................................................................. 58
Figure 13 : Start of measurements for inter-RAT reselection if serving cell is degraded under a RSRP
threshold ............................................................................................................................................................... 60
Figure 14 : Start of measurements for inter-RAT reselection if serving cell is degraded under a RSRQ
threshold ............................................................................................................................................................... 61
Figure 15 : newly detectable UTRA FDD cells and Cell selection Thresholds. ................................................. 68
Figure 16 : Configuration Model UTRAFDDNEIGHBORING................................................................................ 69
priority UTRAN cell.............................................................................................................................................. 77
Figure 18 : Reselection from eUTRAN to GERAN ................................................................................................. 82
Figure 19 : Start of measurements for inter-RAT GSM reselection if serving cell is degraded under a RSRP
threshold ............................................................................................................................................................... 84
Figure 20 : Start of measurements for inter-RAT GSM reselection if serving cell is degraded under a RSRQ
threshold ............................................................................................................................................................... 84
Figure 21 : User Case, with UE Class3 and in the same PLMN, showing reselection towards lower priority
GERAN cell. ......................................................................................................................................................... 95
Figure 22 : User Case, tim e o f re s e le c tio n value according to the values of the parameters under
SpeedStateEvalConf......................................................................................................................................... 119
Figure 23 : Configuration Model related to speed dependent parameters ....................................................... 120
Figure 24 : Intra-LTE reselection configuration..................................................................................................... 121
Figure 25 eMCTA Interfaces.................................................................................................................................... 132
Figure 26: Overview of eMCTA Framework .......................................................................................................... 133
Figure 27: Overview of eMCTA RRC Measurement Configuration process ................................................... 135
Figure 28 Event A1 Reporting ................................................................................................................................. 137
Figure 33 Event B1 Reporting ................................................................................................................................. 144
Figure 34 Event B2 Reporting ................................................................................................................................. 145
Figure 35 Serving Radio Condition and UE Measurement Configurations ...................................................... 146
Figure 36: RAT/Carrier Neighboring configuration with MobilityPriorityTable ................................................. 154
Figure 37: MobilityPriorityTable data structure .................................................................................................... 155
Figure 38: CSFB Trigger Neighbor RAT/Carrier Candidates for RRC Measurements .................................. 165
Figure 39: eMCTA triggered by reception of Coverage Alarm ........................................................................... 171
Figure 40: eMCTA triggered by reception of Below Serving Floor Alarm (bad radio conditions) .................. 172
Figure 41: Serving Radio Monitoring Trigger Neigbhor RAT/Carrier Candidates for RRC Measurements 173
Page 17/543
Volume 6 : Mobility
Figure 42: Offload UE Upon Reactive Load Control Trigger Neighbor RAT/Carrier Candidates for RRC
Measurements ................................................................................................................................................... 181
Figure 43 : 3GPP Parameters in relationship with Event A3: Entering condition ............................................ 193
Figure 44 : Event A3 and parameters: Entering condition .................................................................................. 193
Figure 45 : Event A3 and parameters: Leaving condition ................................................................................... 194
Figure 46 : EventA3 measurements configuration ............................................................................................... 195
Figure 47 : Hysteresis used to tuning HO decision, reportAmount = 4 ............................................................. 205
Figure 48 : Redirection towards another RAT or carrier ...................................................................................... 213
Figure 49 : Blind and intraFreq Measurements for redirection towards another RAT or carrier .................. 214
Figure 50: Measurement setup at call setup ......................................................................................................... 219
Figure 51: Measurement update upon handover – inter-eNB handover .......................................................... 221
Figure 52: Measurement update upon handover – intra-eNB handover .......................................................... 222
Figure 53: LTE cell/eNB neighbourhood configuration model ............................................................................ 232
Figure 54 : MME pools – Handover type decision................................................................................................ 234
Figure 55 Call Flow for Intra-eNB Mobility - UE in RRC Connected.................................................................. 241
Figure 56: Call flow for Inter-eNB mobility, X2 HO - UE in RRC CONNECTED .............................................. 249
Figure 57: Call flow for Inter-eNB mobility, S1 HO - UE in RRC CONNECTED .............................................. 266
Figure 58 Handover Too Early ................................................................................................................................ 282
Figure 59 Handover Too Early - After Intra-eNB Handover ................................................................................ 283
Figure 60 Handover Too Early – After X2 Handover (Target is Prepared)....................................................... 284
Figure 61 Handover Too Early - Intra-eNB Handover Failure ............................................................................ 285
Figure 62 Handover Too Early - X2 Handover Failure ........................................................................................ 285
Figure 63 Handover Too Late.................................................................................................................................. 286
Figure 64 Handover Too Late - Intra-eNB Handover Failure.............................................................................. 287
Figure 65 Handover Too Late - X2 Handover Failure (X2 Handover Preparation initiated) ......................... 287
Figure 66 Handover to Wrong Cell - 1 ................................................................................................................... 289
Figure 67 Handover to Wrong Cell – 2................................................................................................................... 290
Figure 70 Handover to Wrong Cell - After Intra-eNB HO, Re-establish Requested on Same eNB .............. 293
Figure 71 Handover to Wrong Cell - After intra-eNB HO, Re-establish Requested on Other eNB .............. 294
Figure 72 Handover to Wrong Cell - After X2 HO, Re-establish Requested on Other eNB .......................... 295
Figure 73 Handover to Wrong Cell - After X2 HO, Re-establish Requested on Target eNB ......................... 296
Figure 74 Handover to Wrong Cell - Intra-eNB HO Failure, Re-establish Requested on Same eNB .......... 297
Figure 75 Handover to Wrong Cell - X2 HO Failure, Re-establish Requested on 1st eNB ........................... 297
Figure 76 Handover to Wrong Cell - X2 HO Failure, Re-establish Requested on 2nd eNB .......................... 298
Figure 77 Event A3/Event A5 Inter-Freq UE Measurement Configuration Model ........................................... 311
Figure 78 Intra-LTE Inter-Frequency Redirection ................................................................................................. 312
Figure 79 eNB to HeNB Handover Procedure ...................................................................................................... 318
Figure 80 RRC Measurements Configuration Model for Inter-RAT Mobility .................................................... 334
Figure 81 : Call flow Redirection EUTRA-TO-UTRA-FDD .................................................................................. 335
Figure 82 PS Handover Preparation Phase .......................................................................................................... 340
Figure 83 PS Handover Execution Phase ............................................................................................................. 344
Figure 84 : Redirection to GERAN.......................................................................................................................... 358
Figure 85 Cell Change Order with or without NACC............................................................................................ 360
Figure 86 GERAN System Information Transfer Initiation .................................................................................. 366
Figure 87 GERAN System Information Update .................................................................................................... 369
Figure 88 GERAN System Information Update Stop ........................................................................................... 370
Figure 89 GERAN System Information Update End ............................................................................................ 371
Figure 90 LTE TO HRPD Redirection .................................................................................................................... 382
Figure 91 CS Fallback Triggered by an Idle UE ................................................................................................... 386
Figure 92 CS Fallback Triggered by a Connected UE......................................................................................... 387
Figure 93 CS Fallback Triggered by PS Handover .............................................................................................. 390
Figure 94 CS Fallback Triggered by Cell Change Order..................................................................................... 391
Figure 95 CS Fallback Triggered by Redirection.................................................................................................. 392
Figure 96 Selection of CSFB to UTRAN Mobility Procedures ............................................................................ 398
Figure 97 UTRAN System Information Transfer Initiation ................................................................................... 403
Figure 98 UTRAN System Information Update ..................................................................................................... 408
Figure 99 UTRAN System Information Update Stop ........................................................................................... 409
Page 18/543
Volume 6 : Mobility
Figure 100 UTRAN System Information Update End .......................................................................................... 411
Figure 101 Selection of CSFB to GERAN Mobility Procedures ......................................................................... 414
Figure 102 Pre-registration to 1xRTT ..................................................................................................................... 417
Figure 103 1xCSFB Procedure Selection .............................................................................................................. 444
Figure 104 Rel-8 1xCSFB for MO CS Call (Connected Mode) or MT CS Call ................................................ 446
Figure 105 Rel-8 1xCSFB for MO CS Call (Idle Mode) ....................................................................................... 448
Figure 106 Enhanced 1xCSFB for MO CS Call (Connected Mode) or MT CS Call ........................................ 450
Figure 107 Enhanced 1xCSFB for MO CS Call (Idle Mode)............................................................................... 451
Figure 108 Dual Rx UE 1xCSFB Procedure for Idle UE ..................................................................................... 455
Figure 109 Dual Rx UE 1xCSFB Procedure for Connected UE......................................................................... 456
Figure 110 SRVCC to UTRA FDD/TDD................................................................................................................. 459
Figure 111 : Intra-freq ANR Phases ....................................................................................................................... 464
Figure 112 Inter-freq ANR Phases ......................................................................................................................... 464
Figure 113: UTRAN ANR Phases ........................................................................................................................... 465
Figure 114 : Intra-Frequency Neighbor Cell Search ............................................................................................ 469
Figure 115 : S1 Procedure for Neighbor eNB X2 IP Address Retrieval ............................................................ 478
Figure 116 ANR Monitoring Slots for Different RAT............................................................................................. 515
Figure 117 ANR Monitoring Slots for LTE Different Carriers .............................................................................. 516
Figure 118 Example 1 of Dispatch Function ......................................................................................................... 518
Figure 120Example 3 of Dispatch Function .......................................................................................................... 520
Figure 122 UE Consecutive Configuration Based on Carrier Priority................................................................ 535
Page 19/543
Volume 6 : Mobility
1 INTRODUCTION
1.1 OBJECT
The objective of this document is to describe from an engineering point of view the Mobility
parameters.
This includes a system description, configuration aspect and engineering
recommendations.

This document provides configuration information for LTE eNodeB products in Releases
LR13.1 and LR13.3 for the Frequency Division Duplex (FDD) implementation. Information
that is added in this edition to support Releases LR13.1 and LR13.3 are colored with a gray
background as illustrated by this paragraph.
References to LA0.x, LA1.0, LA1.1, LA2.0, LA3.0, LA4.0, LA5.0, and LA6.0 in this volume
refer to features that became available in those releases.
For information concerning parameters for an LTE release earlier than LR13.1, please refer
to the LPUG Edition that supports that release.
Substantial changes have been made in LPUG structure and content for Release LR13.1
with the objective of reducing the document size and improving the readability of the
document. A summary of the most important changes are:
• The content of Volume 1 has been reduced. The listing of features per Volume
and the summary descriptions of features have been deleted. Each individual
volume contains a list of features that are described in that volume. In addition,
the listings of new, modified, and deleted parameters, and parameters that are
not described in LPUG have been deleted from the Appendices. The material
related to feature licensing has been moved to new Volume 2 (see below).
• Previous issues of LPUG included Volume 2 (LTE Overview). This material has
been deleted from the current issue
• A new Volume 2 (Miscellaneous Features and Parameters) has been added.

This volume incorporates some of the material that was previously found in
Volume 1 (Feature Licensing), Volume 7 (Hardware oriented parameters), and
Volume 8.
• Material that describes the LTE channels has been moved from Volume 4 (RRM)
to Volume 3 (LTE Air Interface)
• Material concerning Location Based Services that was previously included in

Volume 8 has been moved to Volume 5 (Call Management)
• Volume 7 (Hardware) has been discontinued, and the hardware configuration

material is now covered in the Product Engineering Guide (PEG). The remaining
Page 20/543
Volume 6 : Mobility
material has been re-distributed to other LPUG Volumes as described above.
• Volume 8 (OA&M) has been discontinued. Most of the material has been moved
to the new Volume 2 (Miscellaneous Features and Parameters). Some of the
detailed material about test related parameters has been deleted.

If a newer Template delivery becomes available, then the Template is authoritative as to

parameter values
LPUG is written with the assumption that features that are scheduled for the LR13.1
delivery release become available as initially planned.
Note that three types of modem are available in LR13.1: the eCEM, the bCEM, and the
MET3C1 for Metro. Some features are modem-type specific and/or their delivery date
may be modem-type dependent. Thisis specified in the document whenever that is
necessary.
Support for the Time Division Duplex (TDD) implementation is provided in a separate
document.
All engineering information, algorithms description and parameters values provided in
this document are strictly related to “standard” Alcatel-Lucent eNodeB products, including
Macro and Metro eNodeB, unless explicitly mentioned.
Transport related parameters are described in the Transport Engineering Guide (TEG).
Page 21/543
Volume 6 : Mobility
Please refer to that document for information on transport-related parameters.

LA0.x
Feature
Feature Title
Number
L34348 Commercial LTE Introduction – Call Processing, RRM, MM
L75908 Seamless Intra-LTE Mobility
LA1.x
Feature
Feature Title
Number
L76501 3GPP Alignment
L76500 Lossless Intra-LTE Handover
L82728 non-optimized LTE to HRPD mobility
L82729 S1 Flex Introduction
L82735 HRPD to LTE mobility
LA2.0
Feature
Feature Title
Number
Inter-eNB S1 HO with MME&SGW Relocation for Inter-vendor
L98841
Mobility
L97979 Support of Partial Handover Failure
L97941 Support of new mobility procedure interactions
L97940 Handover Cancel Support
eUTRAN to UTRAN Inter-RAT Mobility Cell Reselection and
L76498
redirection
eUTRAN to GERAN Inter-RAT Mobility Cell Reselection and
L84807
redirection
L103612 eUTRAN to UTRAN Inter-RAT Mobility Blind PS handover
L96760 eNB Configuration Update Enhancements
L97982 Support of MME Group
L81872 Automatic Neighbor Relation Configuration and Optimisation
LA3.0
Feature
Feature Title
Number
Page 22/543
Volume 6 : Mobility
L92025 CS Fallback to UTRA (WCDMA) for Voice Calls
L92026 CS Fallback to GERAN for Voice Calls
L93270 Measurement Gaps Management
L96371 EUTRA-to-GERAN Inter-RAT Mobility -- NACC
L106136 Common Mobility Management Framework (eMCTA Phase 1)
L103792 Intra-LTE Inter-Frequency Mobility
Enhancement of LTE-to-HRPD Mobility – redirection with eHRPD
L84876
measurement
EUTRAN-to-UTRAN (WCDMA) Inter-RAT Mobility – PS
L96372
Handover 1
L104002 Broadcast per cell SIB4
L108172 Full Support of Intra-LTE ANR1
Support of enhanced RRC Releses redirection for CSFB to
L116051
UTRAN
LA4.0
Feature
Feature Title
Number
L76499.1 LTE and 1xRTT Cell Reselection
CS Fallback to 1xRTT for Voice Calls – Dual Receiver UE
L92024.1
Standard Based Solution
Service and Load Based Handover Behavior Support (eMCTA –
L103892.1
Phase 2)
CSFB Enhancement to UTRAN/GERAN – Enhanced Redirection
L114190.1
and PSHO
L114644.1 EUTRA Standard Alignment on 3GPP Rel-9
L104836 eUTRAN Sharing - Mobility
L108084.1 ANR Support for Inter RAT Neighbors (UTRAN)
Overload Control Evaluations & QoS Differentiation on eNB
L115241.1
Backplane
LA5.0
Feature
Feature Title
Number
L92126 SRVCC Support to UTRAN – FDD/TDD
L97980 Improvement Over S1
L115203 Load Based Idle Mode Mobility
L115204 Enhanced Measurement Parameter Support for Mobility
L115227 EUTRAN Standard Alignment
L115233 eNB SW Capacity Targets
L115361 RLF Monitoring and Recovery Improvement
L115458 Connected Mode Mobility Enhancement for Reserved Cells
L115223 Inter-freq Load Balancing
L115685 Mobility Enhancement for VoIP Service
L115222 VoIP Emergency Call for Commerical Deployment
1
This feature was not fully functional at the time this document was prepared. Please check the current release notes
for any limitations or restrictions associated with this feature.
Page 23/543
Volume 6 : Mobility
LA6.0
Feature
Feature Title
Number
L103176 ANR Support for Inter Freq Neighbors
L115616 Support for Dual-band eNodeB with Two Modems
LR13.1
Feature
Feature Title
Number
L101815 Intra-LTE FDD/TDD Handover
L103177 Handover Optimization Counters
L103790 Intra-LTE Inter Band Cell Reselection for TDD <>FDD
L114538 Enhanced Load Balancing Criteria
L115225 EUTRAN Standard Alignment
L115393 LTE to UTRAN (FDD) Small Cell Mobility Support
134689 Macro/Metro to HeNB Cell Mobility
134791 Enhanced CSFB to 1xRTT
155912 Target Cell Load Consideration for IRAT Mobility to WCDMA
159506 ANR Enhancements - Phase 3
LR13.3
Feature
Feature Title
Number
170745 Neighbor cell classification and mobility counters for HetNet
ANR Enhancements: Up to 72 Visible X2 & Support of March
171148
2012 FGI Bits
L115852 SON Intra-Frequency Handover Optimisations
173501 Mobility Measurements Range Extension for Emergency Calls


2.1 LPUG VOLUMES
[Vol. 1] LPUGIntroduction

[Vol. 6] Mobility
Page 24/543
Volume 6 : Mobility

For LPUG editions supporting release LA4.0 and later releases, the transport related
parameters that were previously described in LPUG Volume 7 have been moved to
the Transport Engineering Guide (TEG) [R01]. Please refer to that document for

[R02] LTE/DCL/APP/031106 FDD eNodeB Product Engineering Guide
[R03] 3GPP TS 36.211: "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
channels and modulation".( 2010-03)
Multiplexing and channel coding".( 2010-09)
[R05] 3GPP TS 36.213: "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer procedures".( 2010-09 )
[R06] 3GPP TS 36.401: “Evolved Universal Terrestrial Radio Access Network(E-UTRAN;
Architecture description R8”.( 2010-06 )
[R07] 3GPPTS 36.300: " Evolved Universal Terrestrial Radio Access (E-UTRA) and
Evolved Universal Terrestrial Radio Access Network(E-UTRAN) Overall
description Stage 2".( 2010-06 )
[R08] 3GPPTS23.003: "Numbering, addressing and identification".( 2010-09 )
[R09] 3GPP TS23.401: "GPRS enhancements for E-UTRAN access".(2010-03)

Radio Resource Control (RRC)”( 2011-03)
Redium Access Control (MAC) R9” .( 2010-06 )
Radio Link Control (RLC) R8” .( 2010-06 )
[R13] 3GPP TS 22.011: “Service accessibility” .( 2010-06 )
[R14] 3GPP TS 36.101: “Evolved Universal Terrestrial Radio Access (E-UTRA); User
Equipment (UE) radio transmission and reception”.( 2010-06 )
S1 Application Protocol (S1AP)” ( 2010-09)
[R16] 3GPP TS 36.304 “Evolved Universal Terrestrial Radio Access (E-UTRA);
User Equipment (UE) procedures in idle mode”( 2011-03)
[R17] 3GPP TS 23.122 "NAS functions related to Mobile Station (MS) in idle mode". (
2010-09 )
[R18] 3GPP2 C.S0005-A: "Upper Layer (Layer 3) Signalling Standard for cdma2000
Spread Spectrum Systems".( 2010-06 )
Page 25/543
Volume 6 : Mobility
UTRAN); X2 Application Protocol (X2AP)” (2011-04)
2.3 PREREQUISITESFOR READING THIS VOLUME

Before reading this volume, the reader should read the introduction (Volume 1). Volume 1
provides an explanation of the presentation and conventions that are used throughout the
document (i.e., common to all volumes).
3 OVERVIEW
This volume depicts the LTE Parameters regarding Mobility features. The granularity of all
Mobility parameters is Cell by Cell.
This document is built in the same chronological order of the events attributed to the work
of the mobile and the network, like if you begin to attach the mobile to the network and after
you moved with this one.
In first step, you moved in idle mode and reselection process is used by your mobile.
In second step, you are on call, and Handover process is practiced by your mobile.
These two steps are reported for each type of mobility features.
It specifies:
• intra-LTE mobility features, covering the control plane aspects.
• The management of intra-LTE and inter-LTE measurements configuration is also
specified in this document.
• Inter-RAT mobility features, covering control plane aspects, regarding the three
following mobilities:
o eUTRAN to UTRAN Inter-RAT Mobility
o eUTRAN to GERAN Inter-RAT Mobility
o eUTRAN to HRPD Inter-RAT Mobility
o eUTRAN to 1xRTT Inter-RAT Mobility
4 RRC IDLE MODE MOBILITY

4.1 CELL SELECTION AND RESELECTION PROCEDURES
4.1.1 INTER TRACKING AREA MOBILITY:

When the UE is in RRC-Idle state, its position is known by the network on a per Tracking
Area (TA) basis. In case of network originated transition from RRC-idle to RRC-connected,
the network will page the UE across the whole Tracking Area. Tracking area mobility is
supported by the System Information broadcast of TAC.
The TA area identity is provisioned by OAM on a per cell basis.
Page 26/543
Volume 6 : Mobility
The TA Code information is broadcast on the BCCH channel on SIB-1.
When the UE enters a new cell which belongs to a TAC where it is not registered it will
initiate the TAU procedure.Note: Up to 3 tracking areas can be managed per ENB in LA3.0
(103163).The corresponding configuration parameters are described below.
• trackingAreaCode:3GPP 36.331 This parameters identifies the TAC (Tracking Area

Code) to which the cell belongs.
LteCell::trackingAreaCode
Parameter trackingAreaCode
Object ENBEquipment/ Enb/ LteCell

stringMinLength = 16
string Length = 16
Value O.D.
Feature L96760, 97933
LteNeighboringCellRelation::trackingAreaCode
Object ENBEquipment/ Enb/ LteCell/ LteNeighboring/


Maxlength = 16
Value O.D. (set by ANR function or by operator)
Feature L81872
4.1.2 PLMN SELECTION & CELL RESERVATION AND CELL

RESTRICTION
Note: PLMN Selection Procedure is depicted in [Vol. 5] section 7 (Call Handling). The
mechanism of cell reservation and cell restriction will play on the intra LTE mobility
procedures for idle mobiles.
Page 27/543
Volume 6 : Mobility
4.1.3 INTRA-FREQUENCY RRC IDLE MODE MOBILITY
Cell selection is a procedure triggered by the UE in Idle Mode to determine which LTE cell
to camp on. The trigger can be internal (e.g. periodic trigger to ensure that UE is still on the
best cell) or external (e.g. upon change of Cell Reselection parameters broadcast on the
selected cell’s BCH). When a UE, camps on a cell it monitors its broadcast and paging
channels. The procedure is internal to the UE and there is therefore no E-UTRA level use
case for it.
Access Class Barring are introduced in LA1.x (to see [Vol. 5] and [R16] for more details.),
minor changes regarding this part for LA3.0.
The cell selection and reselection is controlled by the System Information parameters
provided in SIB1, SIB3 and SIB4, 3GPP [R10].
The inter-frequency cell selection and reselection is controlled by the System Information
parameters provided in SIB3 and SIB5.
Before cell reselection algorithm description, we depict inter tracking area mobility.
4.1.3.1 CELL RESELECTION ALGORITHM DESCRIPTION
Cell Reselection is a procedure run in the UE that relies on:
- Measured RF quality related metrics of camped on and detected cells

- System parameters broadcast by the cell on which the UE is currently camping on.
4.1.3.1.1 CELL SELECTION CRITERION
An intra frequency cell is considered to be detectable if levels of RSRP and RSRQ below
are verified (36.133-940, Section 4.2.2.3):
Bands RSRP RSRQ
7,2,17 RSRP|dBm≥ -122 dBm RSRP Ês/Iot ≥ -4 dB

12,13,14,20 RSRP|dBm≥ -121 dBm RSRP Ês/Iot ≥ -4 dB
4 RSRP|dBm > -124 dBm RSRP Ês/Iot ≥ -4 dB
Table 1: First condition for non-serving cell is considered to be detectable: RSRP

AND RSRQ are involved in Release 9.
Restriction: Release 8 UE restriction
TIf UE is not R9 capable, qQualMin, qQualMinOffset and sIntraSearchQ parameter

husage is not possible. Then UE will use only to the qRxLevMin, qRxLevMinOffset and
esIntraSearch.
Cell selection S criterion (Calculated by the UE) is fulfilled when:
Page 28/543
Volume 6 : Mobility
Srxlev > 0 AND Squal > 0
Where:
Srxlev = Qrxlevmeas – (Qrxlevmin + Qrxlevminoffset) – Pcompensation
Squal = Qqualmeas – (Qqualmin + Qqualminoffset)
Where:
The signalled value QrxlevminOffsetis only applied when a cell is evaluated for cell
selection as a result of a periodic search for a higher priority PLMN while camped
normally in a VPLMN [R16]. During this periodic search for higher priority PLMN the UE
may check the S criteria of a cell using parameter values stored from a different cell of this
higher priority PLMN.
Note: The Squal criterion is used only if UE is R9 capable.
Page 29/543
Volume 6 : Mobility
Srxlev Calculated Cell selection RX level value (dB)
by the UE
Squal Calculated Cell selection quality value (dB)
by the UE
Qrxlevmeas Measured by Measured cell RX level value (RSRP)
the UE
Qqualmeas Measured by Measured cell quality value (RSRQ)
the UE
Qrxlevmin CellSelection Minimum required RX level in the cell (dBm). With SIB1
ReselectionC or SIB3.
onf
::qRxLevMin
or
CellReselecti
onConfLte
::qRxLevMin
Qrxlevminof qRxlevminoff Offset to the signalled Qrxlevmin taken into account in the
fset
set Srxlev evaluation as a result of a periodic search for a
higher priority PLMN while camped normally in a
VPLMN [5] (SIB1)
Pcompen Calculated max(Pemax – Pumax, 0) (dB). With SIB1 or SIB3
sation by the UE
(See below)
Qqualmin CellSelection Minimum required quality level in the cell (dB). With SIB1
ReselectionCo or SIB3
nf::qQualMin
CellReselectio
nConfLte::qQ
ualMin
Qqualminoffs CellSelection Offset to the signalled Qqualmin taken into account in the
et ReselectionCo Squal evaluation as a result of a periodic search for a
nf::qQualMin higher priority PLMN while camped normally in a VPLMN
Offset [5]. With SIB1
Pemax CellSelection Maximum TX power level an UE may use when
Reselection transmitting on the uplink in the cell (dBm) defined as
Conf::pMax PEMAX in [TS 36.101] and the value is provided by IE p-
CellReselection Max if a value is signalled to a UE (see TS 36.331). With
ConfLte::pMax SIB1 or SIB3
Pumax Hardcoded Maximum RF output power of the UE (dBm) according to

the UE power class as defined in [TS 36.101] and fixed to
23dBm for UE class 3 (for all the EUTRA band)
Table 2: Cell Reselection Criteria parameters

Note: In the table above and in all this section, parameters under
CellSelectionReselectionConf Object are related to serving cell (SIB1 and SIB3-
parameters), whereas parameters under CellReselectionConfLte Object are related to
neighboring cell (SIB3-parameters).
Page 30/543
Volume 6 : Mobility
RSRP Looking for cell UE filter all priority cell via at least 2
S-ServingCell at least every measurements.
Tdetect,EUTRAN_Intra sec. Each meas. Are spaced by at least
Tmeasure,EUTRAN_Intra / 2.
Qrxlevmin(SIB1) +
Qrxlevminoffset(SIB1) +
Pcompensation +
sIntraSearchP(SIB3)
Min. = (Tdetect,EUTRAN_Intra) s=32s.
Min. = (Tmeasure,EUTRAN_Intra) s=1,28s.
•t
Figure 1 : Start of measurements for reselection if serving cell is degraded under a RSRP
threshold
RSRQ
Looking for cell UE filter all priority cell via at least 2
S-ServingCell at least every measurements.
Tdetect,EUTRAN_Intra sec. Each meas. Are spaced by at least
Tmeasure,EUTRAN_Intra / 2.
Qqualmin(SIB1) +
Qqualminoffset(SIB1)
+ sIntraSearchQ(SIB3)
Min. = (Tdetect,EUTRAN_Intra) s=32s.

Min. = (Tmeasure,EUTRAN_Intra) s=1,28s.
Figure 2 : Start of measurements for reselection if serving cell is degraded under a RSRQ
threshold for UE R9 capable.
Note: Tmeasure,EUTRAN_Intra and Tdetect,EUTRAN_Intra value are in inter-working with
Enb::defaultPagingCycle value.
• pMax:This parameter specifies the maximum UL power level allowed to be
transmitted to the local cell at selection time. It corresponds to the parameter
P_EMAX as defined in TS 36.101. (SIB1)
CellSelectionReselectionConf::pMax
Parameter pMax
Object ENBEquipment/ Enb/ LteCell/ CellSelectionReselectionConf
Range & Unit Integer, dBm

[-30..+33] step = 1
Value 23
Feature
Note: Value applicable for the cell. If absent, the UE applies the maximum power according
to the UE capability.
Engineering Recommendation: pMax
Currently, we recommend to set a pMax value in order to get Pcompensation to 0:
The value 23 dBm is the recommended value.
Page 31/543
Volume 6 : Mobility
• pMax:This parameter specifies the maximum UL power level allowed to be

transmitted for neighbor cell reselection, including intra frequency. The parameter
corresponds to P_EMAX in TS 36.101.(SIB3)
CellReselectionConfLte::pMax
Parameter pMax

LteNeighboringFreqConf/ CellReselectionConfLte

[-30..+33] step = 1
Class/Source C – New-set-ups / customer_settable
Value 23
Feature
Note: Value applicable for the intra-frequency neighbouring E-UTRA cells. If absent, the
UE applies the maximum power according to the UE capability.
Pcompensationis a compensation factor to penalize the low power mobiles.
Pcompensation = max(PEMAX - PUMAX, 0)
Where:
PEMAX = pMax
PUMAX = maximum UE output power (dBm) according to its power class in 4g and
operating band. (see table below)
Power (dBm)
Operating Band
Class 1 Class 2 Class 3 Class 4
IV LTE 2100 MHz N.A. N.A. +23 N.A.
VII LTE 2600 MHz N.A. N.A. +23 N.A.
XIII LTE 700 MHz Upper N.A. N.A. +23 N.A.
XVII LTE 700 MHz Lower N.A. N.A. +23 N.A.
XX LTE 800 MHz N.A. N.A. +23 N.A.
Table 3: UE power Class vs. LTE maximum output power, Pumax.
Page 32/543
Volume 6 : Mobility
• qRxLevMin:3GPP 36.331[R10] This parameter configures the serving cell min
required RSRP level used by the UE in cell reselection. The value sent over the
RRC interface is half the value configured. Broadcast by the eNB in
CellSelectionReselectionConf::qRxLevMin
Parameter qRxLevMin
Range & Unit dBm

[-140..-44] step = 2
Value -120 see Engineering Recommendation
Feature L96760
Parameter qRxLevMin in [R16]. Actual value Qrxlevmin = IE value*2 [dBm]. Specifies the
minimum required Rx RSRP level in the cell (Where IE value specify the message value
send to the UE).
Changing this value will affect cell size in terms of re-selection area. Increasing this value
will lead the mobile to start cell-selection/re-selection procedure sooner and then
will artificially decrease cell size in idle mode.
Engineering Recommendation: CellSelectionReselectionConf::qRxLevMin

This parameter has impact on idle mode coverage. The recommended value for the
parameter is -120 dBm.
• Qrxlevmin:This parameter configures the neighbouring cell min required RSRQ level
used by the UE in cell reselection. See 3GPP 36.331. Broadcast in
SystemInformationBlockType1.
CellSelectionReselectionConf::qQualMin
Parameter qQualMin
Range & Unit dB

[-34..-3] step = 1
Value NA see Engineering Recommendation
Feature L114644.1
Page 33/543
Volume 6 : Mobility
Engineering Recommendation: CellSelectionReselectionConf::qQualMin
parameter is not yet available.
• qRxLevMin:3GPP 36.331[R10] This parameter configures the min required RSRP

level used by the UE in cell reselection on the frequency Carrier for the
neighbors cells.The value sent over the RRC interface is half the value configured.
The UE then multiplies the received value by 2. Broadcast in
SystemInformationBlockType3 or 5.
CellReselectionConfLte::qRxLevMin
Parameter qRxLevMin

Range & Unit dBm

[-140..-44] step = 2
Value -120 see Engineering Recommendation
Feature 108283
Note: The qRxLevMin sent by the SIB3 applies to the signal of the same neighbor
frequency than the serving cell.
Engineering Recommendation: CellReselectionConfLte::qRxLevMin

The recommended value for this parameter is -120 dBm.
Page 34/543
Volume 6 : Mobility
• qQualMin:This parameter configures the neighbouring cell min required RSRQ level
used by the UE in cell reselection. See 3GPP 36.331. Broadcast in
SystemInformationBlockType3 or SystemInformationBlockType5.
CellReselectionConfLte::qQualMin
Parameter qQualMin

Range & Unit dB

[-34..-3] step = 1
Value NA see Engineering Recommendation
Feature L114644.1
Engineering Recommendation: CellReselectionConfLte::qQualMin

parameter is not yet available.
• qRxlevminoffset:This parameter defines an offset to be applied in cell selection

criteria by the UE when it is engaged in a periodic search for a higher priority
PLMN. The value sent over the RRC interface is half the value configured Defined in
TS 36.331. Broadcast by the eNB in SystemInformationBlockType1[R16].
CellSelectionReselectionConf::qRxlevminoffset
Parameter qRxlevminoffset
Range & Unit dB

[2..16] step = 2
Value 8
Feature L96760
Note: If you do not use inter-PLMN mobility, this parameter is inhibited.
Page 35/543
Volume 6 : Mobility
• qQualMinOffset:This parameter specifies an offset to be applied in cell selection
criteria by the UE when it is engaged in a periodic search for a higher priority PLMN.
Defined in TS 36.331. Broadcast in SystemInformationBlockType1.
CellSelectionReselectionConf::qQualMinOffset
Parameter qQualMinOffset
Range & Unit dB

[1..8] step = 1
Value N.A
Feature L114644.1
Note: If you do not use inter-PLMN mobility, this parameter is inhibited.
• sIntraSearch :This parameter specifies the threshold for the serving cell reception
level, below which the UE triggers intra-frequency measurements for cell
reselection.The value sent over the RRC interface is half the value provisioned; the
UE then multiplies the received value by 2. See TS 36.304. The RRC parameter is
defined in TS 36.331 and is broadcast in SystemInformationBlockType3. However, if
this parameter is not configured, then the RRC parameter is not broadcast in the cell,
in which case, UEs in idle mode in the cell will measure for intra-frequency reselection
unconditionally.
CellSelectionReselectionConf::sIntraSearch
Parameter sIntraSearch
Range & Unit dB

[0..62] step = 2
Value See Engineering Recommendation Below
Feature L96760
Rule: If sIntraSearch value unknown by UE (R9 UE check sIntraSearchP)
If the field is not provisioned, UE applies the default value of infinity.
Page 36/543
Volume 6 : Mobility
Engineering Recommendation:sIntraSearch
UE starts intra-frequency measurements for cell re-selection when serving cell’s RSRP
value <= qRxLevMin + qRxLevMinOffset + Pcompensation + sIntraSearch.
Increasing sIntraSearch value will make UE to start intra-frequency neighbor search
earlier. Test results indicate sIntraSearch should be set to the highest allowed value to
minimize SINR degradation in reselection boundaries. The current recommended value
for sIntraSearch is 62 dB.
In order to further restrict the amount of measurement carried out by the UE in RRC-
Idle mode, this parameter should be provisioned.
• sIntraSearchP : In case of R9 UE, UE applies the value of sIntraSearchP instead of

CellSelectionReselectionConf::sIntraSearch. Defintion is the same as for
CellSelectionReselectionConf::sIntraSearch.
CellSelectionReselectionConf::sIntraSearchP
Parameter sIntraSearchP
Range & Unit dB

[0..62] step = 2
Value See Engineering Recommendation Below
Feature L114644.1
Rule: If sIntraSearchP value unknown by R9 UE
If the field is not provisioned, R9 UE applies the value of sIntraSearch. Otherwise,

if neither sIntraSearch nor sIntraSearchP is provisioned UE applies the (default)
value of infinity.
Engineering Recommendation:sIntraSearchP
The recommended value is the same as the recommended value of parameter

CellSelectionReselectionConf::sIntraSearch (62 dB)
Page 37/543
Volume 6 : Mobility
• sIntraSearchQ:This parameter specifies the threshold for the serving cell reception
quality, below which the UE triggers intra-frequency measurements for cell
reselection. If the field is not present, the UE applies the (default) value of 0 dB.
CellSelectionReselectionConf::sIntraSearchQ
Parameter sIntraSearchQ
Range & Unit dB

[0..31] step = 1
Value N.A.
Feature L114644.1
Rule: If sIntraSearchQ value unknown by R9 UE
If the field is not provisioned, R9 UE applies the (default) value of 0 dB for

sIntraSearchQ.
• measurementBandwidth: This parameter is expressed as the number of resource

blocks. It is also referred to as Transmission Bandwidth Configuration NRB in TS
36.101(UE) & 36.104(BTS). It is broadcasted in SystemInformationBlockType3 (Intra-
frequency) / SystemInformationBlockType5 (Inter-frequency) and is also used in the
RRCConnectionReconfiguration message, including during HO through
RRCConnectionReconfiguration message. Refer to
TS 36.331.
LteNeighboringFreqConf::measurementBandwidth
Parameter measurementBandwidth


[mbw6, mbw15, mbw25, mbw50, mbw75, mbw100]
Value Refer to Engineer Recommendation below
Feature L96760, 97933, 108283
Page 38/543
Volume 6 : Mobility
Engineering Recommendation: measurementBandwidth
The value of measurementBandwidth is recommended to be set based on channel bandwidth

as shown in the table below:
Channel bandwidth
1.4 3 5 10 15 20
BWChannel[MHz]
Transmission bandwidth
6 15 25 50 75 100
configuration NRB
measurementBandwidth mbw6 mbw15 mbw25 mbw50 mbw75 mbw100
Table 4: Transmission bandwidth configuration NRB in E-UTRA channel bandwidths
The above table shows the relation between the Channel bandwidth (BWChannel) and the
Transmission bandwidth configuration (NRB). The channel edges are defined as the
lowest and highest frequencies of the carrier separated by the channel bandwidth, i.e. at FC
+/- BWChannel /2. For more information regarding the frame structure, you can refer to [Vol.
3] section 6.
Channel Bandwidth [MHz]
Transmission Bandwidth Configuration [RB]
Transmission
Bandwidth [RB]
Channel edge
Channel edge
Resource block
Active Resource Blocks Center subcarrier (corresponds to DC in

baseband) is not transmitted in downlink
Figure 3: The Definition of Channel Bandwidth and Transmission Bandwidth

Configuration for one E-UTRA carrier
Note: As a general rule, the resolution bandwidth of the measuring equipment should be
equal to the measurement bandwidth. However, to improve measurement accuracy,
sensitivity and efficiency, the resolution bandwidth may be smaller than the measurement
bandwidth. When the resolution bandwidth is smaller than the measurement bandwidth, the
result should be integrated over the measurement bandwidth in order to obtain the
equivalent noise bandwidth of the measurement bandwidth.[R14] [TS 36.101]
Page 39/543
Volume 6 : Mobility
• cellReselectionPriority: This parameter specifies the relative priority for cell
reselection (0 means lowest priority). See TS 36.331. Broadcast in
SystemInformationBlockType3 for the intra-frequency neighborhood or in
SystemInformationBlockType5 for inter-frequency neighborhood.
CellReselectionConfLte::cellReselectionPriority
Parameter cellReselectionPriority


[0..7] step = 1
Class/Source C - Immediate-propagation / customer_settable
Value 5 (Refer to Engineering Rule below)

Note: This parameter specifies the relative priority for cell reselection (0 is the lowest
priority). It is included in SystemInformationBlockType3 for serving cell and intra-frequency
neighbor cells or included in SystemInformationBlockType5 for LTE inter-frequency
neighbor cells.
Engineering Rule: cellReselectionPriority
Since equal priorities across RAT are not supported by standard, for a network that
supports LTE and UTRAN/GERAN, the following parameters should be set to
different values:
• CellReselectionConfLte::cellReselectionPriority
• CellReselectionConfUtra::cellReselectionPriority
• CellReselectionConfGeran::cellReselectionPriority
For example, if CellReselectionConfLte::cellReselectionPriorityis set to 5,

CellReselectionConfUtra::cellReselectionPrioritycan be set to 3 and
CellReselectionConfGeran::cellReselectionPrioritycan be set to 2. This way, the
LTE will have higher priority than UTRAN and UTRAN will have higher priority than
GERAN in cell reselection.
For a network that supports LTE and HRPD/1xRTT, the following parameters should
be set to different values:
• CellReselectionConfLte::cellReselectionPriority
• CellReselectionConHrpd::cellReselectionPriority
• CellReselectionConf1xRtt::cellReselectionPriority
UTRAN/GERAN and HRPD/1xRTT cannot coexist in the same network.
Page 40/543
Volume 6 : Mobility
4.1.3.1.2 INTRA-FREQUENCY AND EQUAL PRIORITY INTER-
FREQUENCY CELL RESELECTION CRITERIA
The cell-ranking criterion Rs for serving cell and Rn for neighboring cellsis defined by
[R16]:
Rs = Qmeas,s + QHyst
Rn = Qmeas,n - Qoffset
where:
Qmeas RSRP measurement quantity used in cell reselections.

Qoffset qOffsetCell For intra-frequency: Equals to Qoffsets,n, if Qoffsets,nis
valid, otherwise this equals to zero.
For inter-frequency: Equals to Qoffsets,nplus
Qoffsetfrequency, if Qoffsets,nis valid, otherwise this equals to
Qoffsetfrequency.
QHyst qHyst This parameter configures the hysteresis value of the
serving cell used by the UE for ranking criteria in cell
reselection.
Table 5: Cell Ranking Procedure parameters

The UE will perform ranking of all cells that fulfil the cell selection S criterion, which is
defined in section 4.1.5.3.
The cells are ranked according to the R criteria specified above, deriving Qmeas,n and
Qmeas,s and calculating the R values using averaged RSRP results.
If a cellis ranked as the best cell, the UE will perform cell re-selection to that cell.
In all cases, the UE will actually reselect the new cell, only if the following conditions are
met:
- The new cellis better ranked than the serving cell during a time interval
tReselectionEUTRANs or tReselectionRATs
Qmeas,s + QHyst < Qmeas,n – QOffset
- More than 1 second(s) has elapsed since the UE camped on the current serving cell.
Page 41/543
Volume 6 : Mobility
• qHyst:3GPP 36.331[R10] This parameter configures the hysteresis value of the
serving cell used by the UE for ranking criteria in cell reselection. Broadcast in
SystemInformationBlockType3.
CellSelectionReselectionConf::qHyst
Parameter qHyst
Range & Unit Enumerate in dB

[dB0, dB1, dB2, dB3, dB4, dB5, dB6, dB8, dB10, dB12, dB14, dB16,
dB18, dB20, dB22, dB24]
Value dB2
Feature L96760
Notes: This parameter configures the hysteresis value of the serving cell used by the UE
for ranking criteria in cell reselection. When
ActivationService::isSIB3ReselectionAutomationEnabled is set to ‘True’, this
parameter will be adjusted automatically based on cell loading. Refer to section 4.1.3.5 for
details.
Decreasing qHyst leads to do cell-reselection earlier.
• tReselectionEUTRAN:3GPP 36.331 This parameter specifies the value of the cell

reselection UE timer in the serving cell. The parameter value under the
LteNeighboringFreqConf MO pointed to by
LteCell::lteNeighboringFreqConfId (corresponding to the serving
frequency) is broadcasted in SystemInformationBlockType3. The parameter
value for all other instances are broadcasted in SystemInformationBlockType5.
CellReselectionConfLte::tReselectionEUTRAN
Parameter tReselectionEUTRAN

Range & Unit seconds

[0..7] step = 1
Value 2
Feature L96760, 108283

This parameter avoids ping pong radio phenomena during the RA-Update & idle
mobility.
Increasing this value will lead the mobile to start cell-reselection later.
Warning: For an intra-frequency cell that has been already detected, but that has not been
reselected to, the filtering will be such that the UE will be capable of evaluating that the
intra-frequency cell has met reselection criterion defined in this section within Tevaluate,E-
UTRAN_intra = 5,12 sec when tReselectionEUTRAN = 0as specified in table below (with
Page 42/543
Volume 6 : Mobility
Enb::defaultPagingCycle=rf128 [Vol. 5]), provided that the cell is at least 3dB better
ranked. [TS 36.133]
During Tdetect,EUTRAN_Intra when that tReselectionEUTRAN = 0, the UE will be able to

evaluate whether a newly detectable intra-frequency cell meets the reselection criteria.
The UE will measure RSRP at least every Tmeasure,EUTRAN_Intra (see table below) for
intra-frequency cells that are identified and measured according to the measurement rules.
The UE shall filter RSRP measurements of each measured intra-frequency cell using at
least 2 measurements. Within the set of measurements used for the filtering, at least two
measurements shall be spaced by at least Tmeasure,EUTRAN_Intra/2.
DRX Tdetect,EUTRAN_Intra [s] Tmeasure,EUTRAN_Intra [s] Tevaluate,E-UTRAN_intra

cycle (number of DRX (number of DRX [s] (number of DRX
length cycles) cycles) cycles)
[s]
0.32 [11.52 (36)] [1.28 (4)] [5.12 (16)]
0.64 [17.92 (28)] [1.28 (2)] [5.12 (8)]
1.28 [32(25)] [1.28 (1)] [6.4 (5)]
2.56 [58.88 (23)] [2.56 (1)] [7.68 (3)]
Table 6: Measurements of EUTRAN FDD cells selection [3GPP 36133].
Page 43/543
Volume 6 : Mobility
Qoff
Serving
QHyst
RSRP Cell
Serving Cell Timer is started

Cell2 becomes better than
sIntraSearch or sNonIntraSearch the serving cell
tReselectionEUTRAN
Cell 1
Cell 2
t
UE triggers intra-frequency Timer is aborted Cell2 is reselected

measurements
Figure 4 : Cell Reselection criteria intra-LTE intra-frequency and equal priority inter-frequency
Note: sNonIntraSearchis also used for inter-frequency reselection measurements and for
I-RAT measurements. See Section 4.1.4for inter-frequency scenarios.
Figure 5 : Ranking between Equal priority cells.
Page 44/543
Volume 6 : Mobility
4.1.3.1.3 SIB4 BROADCASTING AND BLACKLISTED CELLS FOR
MOBILITY
System Information SIB4 (L104002) is supported from (T)LA4.0 and is used to:
- broadcast qOffsetCell parameter (per neighbor cell, max. 16) for LTE intra-frequency cell
reselection (used during the ranking process)
- list the intra-frequency black-listed cells
All the contents of SIB4 are optional because UE's can automatically detect and
complete neighbour INTRA_frequency cells and it will be only broadcasted if at least one
neighbour EUTRAN carrier MO has been configured or blacklist is defined.
Intra frequency MO LteNeiboringFreqConf is pointed by the attribute

LteCell::lteNeighboringFreqsConfId, the following assertions must be true:
• A neighbor cell is defined: there exists at least one instance of

LteCell/LteNeighboringCellRelation containing mandatory parameters for cell
reselection.
• The SIB4 intraFreqNeighCellList includes the intra-frequency neighboring cells:
these are neither blacklisted nor with zero-valued
LteNeighboringCellRelation::qOffsetCell in MIM.
• If more than 16 neighboring cells meet the above requirement, only the 16
neighboring cells with the highest absolute qOffsetCell are selected.
If there is no neighboring cell meeting the above requirement, the intraFreqNeighCellList is

not included in SIB4.
• qOffsetCell:This parameter defines the offset between the current LteCell and the
intra-frequency or inter-frequency LteNeighboringCell to be included in SIB4 or SIB5
(TS 36.331).
LteNeighboringCellRelation::qOffsetCell
LteNeighboringOpenOrHybridHeNBCellLayerRelation::qoffsetcell
Parameter qOffsetCell

ENBEquipment/ Enb/ LteCell/ LteNeighboring/
LteNeighboringFreqConf/
LteNeighboringOpenOrHybridHeNBCellLayerRelation

[dB-24, dB-22, dB-20, dB-18, dB-16, dB-14, dB-12, dB-10, dB-8, dB-
6, dB-5, dB-4, dB-3, dB-2, dB-1, dB0, dB1, dB2, dB3, dB4, dB5,
dB6, dB8, dB10, dB12, dB14, dB16, dB18, dB20, dB22, dB24]
Value dB0
Feature L96760, LL103792, 134689

Note: If this parameter is unset or is set to dB0 for an intra-frequency neighbor cell, the
neighbor cell will not be included in the IntraFreqNeighCellList IE of SIB4. Similarly, if the
parameter is unset or is set to dB0 for an inter-frequency neighbor cell, the neighbor cell
Page 45/543
Volume 6 : Mobility
will not be included in the InterFreqNeighCellList IE of SIB5. HeNB neighbor cell and the
corresponding LteNeighboringOpenOrHybridHeNBCellLayerRelation::qOffsetCell will
be included in SIB5 only if inter-frequency mobility to HeNB is activated (refer to section
6.3).
Black Cell List is computed by CallP either in IDLE mode for reselection (SIB4, SIB5), or in
CONNECTED mode for measurements configuration used for handover and redirection.
If a blacklist is defined, then the intra frequency blacklist for SIB4 IE computed by the ENB
CallP is not empty:
It can be convenient for the operator to blacklist large quantities of cells.
The operator has two possibilities to blacklist an intra frequency cell:

 In case of a well known configured cell: the Operator can set the flag called
LteNeigbouringCellRelation::NoHoOrReselection that exists before LA3.0 for
handover and that is expanded to reselection.
 If the operator wants to blacklist many or all cells of a given carrier frequency: the
Operator can set a larger range of Physical Cell Identity (PCI) in the
BlackCellConf IEs of the LteNeigbouringFreqConf instance that is pointed by
LteCell::lteNeighboringFreqsConfId.
Note: a pointer from LteCell to an LteNeighboringFreqConf instance identifies the current

frequency. This pointer is called lteNeighboringFreqsConfId.
Also, ANR and automatic retrieval of intra frequency neighbouring information feeds the
MIM. ANR shall set the LteNeigbouringCellRelation::NoHoOrReselection flag in
coherence with the existing blacklist defined in the BlackCellConf IEs of the
LteNeigbouringFreqConf instance that is pointed by LteCell::lteNeighboringFreqsConfId.
The ENB builds the SIB4 blacklist IE by computing the inclusive OR of the two above MIM
information. If there is no intra-frequency neighboring cell being blacklisted in MIM, the
intraFreqBlackCellList is not included in SIB4.If the number of blacklisted intra-frequency
cells is greater than 16, only the first 16 ones, in ascending order of PhysCellId, shall be
included in the SIB4 intraFreqBlackCellList. Otherwise all blacklisted intra-frequency cells
are included in the SIB4 intraFreqBlackCellList. Nominally, the number of blacklisted intra-
frequency cells in MIM should be less than or equal to 16.
- Note1: Among the cells with the same absolute qOffsetCell, the cell with lower
PhysCellId has the higher priority in SIB4 intraFreqNeighCellList selection.
- Note2: SIB4 doesn’t exist if neither intraFreqNeighCellList nor
intraFreqBlackCellList exists after initial SIB4 calculation.
A blacklist is a set of starting PCI (BlackCellConf::start) and ranges

(BlackCellConf::range) of PCI (refer to section 4.1.4.2).
In LA3.0 the same information (a single MO) is used for RRC IDLE and RRC
CONNECTED modes in order to simplify the configuration.
4.1.4 INTER-FREQUENCY RRC IDLE MODE MOBILITY

4.1.4.1 CELL SELECTION CRITERION
The first condition for non-serving cell is considered to be detectable, are the same as for
intra-freq case in section 4.1.3.1.1.
Page 46/543
Volume 6 : Mobility
The cell selection criterion S is the same as for intra-freq case in section 4.1.3.1.1.
• For UE only R8 capable:

If SServingCell of the E-UTRA serving cell is greater than sNonIntraSearch then the
UE will search for inter-frequency layers of higher priority at least every
Thigher_priority_search.
If SServingCell ≤ sNonIntraSearch, then the UE will search for and measure inter-
frequency layers of higher, equal or lower priority in preparation for possible
reselection. The UE shall measure RSRP at least every Kcarrier *
Tmeasure,EUTRAN_Inter for identified lower or equal priority inter-frequency cells.
• For UE R9 capable:
If Srxlev >sNonIntraSearchPand Squal >sNonIntraSearchQ, then the UE will search

for inter-frequency layers of higher priority at least every Thigher_priority_search.
If Srxlev ≤ sNonIntraSearchPor Squal ≤ sNonIntraSearchQ then the UE shall search

for and measure inter-frequency layers of higher, equal or lower priority in preparation
for possible reselection. The UE will measure RSRP or RSRQ at least every Kcarrier *
Tmeasure,EUTRAN_Inter for identified lower or equal priority inter-frequency cells.
Note: If the UE detects on a E-UTRA carrier a cell whose physical identity is indicated
as not allowed for that carrier in the measurement control system information of the
serving cell, the UE is not required to perform measurements on that cell.
RSRP
Looking for Higher priority cell Measurements for all priority cell at
S-ServingCell at least every (60 * Nlayers) sec. least every
(Kcarrier) * Tmeasure,EUTRAN_Inter
sec.
Qrxlevmin(SIB1) +
Pcompensation +
sNonIntraSearchP Min. = (60* Nlayers) s
Min. = (Kcarrier)* Tmeasure,EUTRAN_Inter s
Tdetect,EUTRAN_Inter=32s.
= (Kcarrier)*1,28 s.
•t
Figure 6 : Start of measurements for inter-freq reselection if serving cell is degraded under a
RSRP threshold
Note: Kcarrier is the number of E-UTRA inter-frequency carriers indicated by the
serving cell.
Note: Tmeasure,EUTRAN_Inter and Tdetect,EUTRAN_Inter value are in inter-working
with Enb::defaultPagingCycle value.
RSRQ
Looking for Higher priority cell Measurements for all priority cell at
S-ServingCell at least every (60 * Nlayers) sec. least every
(Kcarrier) * Tmeasure,EUTRAN_Inter
sec.
Qqualmin(SIB1) +
Qqualminoffset(SIB1) +
sNonIntraSearchQ
Min. = (60* Nlayers) s
Min. = (Kcarrier)* Tmeasure,EUTRAN_Inter s
Tdetect,EUTRAN_Inter=32s.
= (Kcarrier)*1,28 s.
•t
Figure 7 : Start of measurements for inter-freq reselection if serving cell is degraded under a
RSRQ threshold
Page 47/543
Volume 6 : Mobility
4.1.4.2 CELL RESELECTION CRITERION
Feature LL103792 supports intra-LTE inter-frequencyidle mode mobility – cell reselection.

With Feature LL103792, the source and target frequencies can be in the same band or
different bands with the same frame structure (i.e. both source and target are FDD, or both
are TDD). Intra-LTE inter-frequency cell reselection is activated when
ActivationService::isInterFreqEutraSameFrameStructureMobilityAllowedis set to
‘True’. The same activation flag also controls Intra-LTE inter-frequency RRC connected
mode mobility (section 6.2 of LPUG Volume 6).
ActivationService::isInterFreqEutraSameFrameStructureMobilityAllowed
Parameter isInterFreqEutraSameFrameStructureMobilityAllowed

[True, False]
Value False
Feature LL103792
Notes: This optional feature is managed by Feature Licensing (refer to LPUG Volume 2 for
details). This parameter can be set to 'True' only if licensing (Tokens) are available for the
feature. The total number of activations for each feature is counted across all eNBs by
SAM.
Feature L103790 supports intra-LTE inter-frequency FDD-TDD idle mode mobility – cell
reselection. With L103790, the source and target frequencies must be in different bands
with different frame structures (i.e. source is FDD and target is TDD). Intra-LTE inter-
frequency FDD-TDD cell reselection is activated when
ActivationService::isInterFreqEutraOtherFrameStructureMobilityEnabled is set to
‘True’. The same activation flag also controls Intra-LTE inter-frequency FDD-TDD RRC
connected mode mobility (section 6.2 of LPUG Volume 6).
ActivationService::isInterFreqEutraOtherFrameStructureMobilityEnabled
Parameter isInterFreqEutraOtherFrameStructureMobilityEnabled

[True, False]
Value False
Feature L103790, L101815

SAM.
Page 48/543
Volume 6 : Mobility
Cell reselection is an UE procedure to determine which cell/frequency a UE should camp
on when it is in idle state. The parameters used in UE cell reselection algorithm are
controlled by eNB through the broadcasting of the related SystemInformationBlockType
(SIB) IE on the BCH of the cell the UE is camping on. To support intra-LTE inter-frequency
cell reselection, SIB5 is broadcasted in addition to SIB3.
SIB3 contains cell reselection information common to intra-frequency, inter-frequency and

inter-RAT cell reselection. It is always broadcasted unless it cannot be built because one or
more 3GPP mandatory parameters are not provisioned. In this case, the cell is in
disabled/failed state and a critical alarm will be raised by the eNB for operator intervention.
Typically there is one instance of LteNeighboringFreqConf MO that contains intra-

frequency neighbors and that instance is pointed to by
LteCell::lteNeighboringFreqsConfId. If there are additional instances of
LteNeighboringFreqConf MO, these instances contain inter-frequency neighbors.
FDD-TDD Mobility is by 3GPP definition an intra-LTE mobility, therefore all cases

throughout the discussion of Inter-Frequency RRC Idle Mode Mobility, the eNB shall use
the same algorithms for both FDD-FDD and FDD-TDD. For licensing validity, the DL
EARFCN shall be used to cross check the feature activation flag to determine if the target
frequency is the same frame structure (FDD) or a different frame structure (TDD).
• FDD bands: DL EARFCN in the range = 0 – 17999

• TDD bands: DL EARFCN in the range = 36000 – 65535
A FDD eNodeB may receive a TAU from a UE previously served by a TDD node.
SIB5 contains information used for inter-frequency cell reselection only. SIB5 is
broadcasted if the following conditionis true:
• ActivationService::isInterFreqEutraSameFrameStructureMobilityAllowedis
set to ‘True’
OR
• ActivationService::isInterFreqEutraOtherFrameStructureMobilityEnabled is
set to ‘True
AND
• It exists one or more instances of LteNeighboringFreqConf MO that contain inter-

frequency neighbors. Each instance may contain the following MO:
o CellReselectionConfLte
o LteSpeedDependentConf (optional)
o One or more instances of LteNeighboringCellRelation (optional)
o One or more instances of BlackCellConf (optional)
The parameters to be configured for eNB to broadcast SIB5 can be found in the
configuration model in section6.2.1.The UE cell reselection algorithms can be found in
section4.1.4.3. Templates of the parameters contained in above MO can be found in the
following sections: CellReselectionConfLte MO (section 4.1.3.1.1),
LteSpeedDependentConf MO (section 4.2) and LteNeighboringCellRelation MO
(section 4.1.1, 4.1.3.1.3, 6.1.2.3, 6.1.3.3, 11.1, 11.2.1.1).
The BlackCellConf MO contains one or a list of black cells of a carrier frequency that are
not to be considered as cell reselection candidates. Intra-frequency black cell list of SIB4
and inter-frequency black cell list of SIB5 includes black cells that are specified in the
corresponding frequency LteNeighboringCellRelation MO with noHoOrReselection set
Page 49/543
Volume 6 : Mobility
to ‘True’, and the black cells that are specified in BlackCellConf MO under the same
LteNeighboringFreqConf MO.
In LA3.0, the same black cell list is sent to UE in RRC measurement object message when
UE in RRC connected mode.
Intra-frequency black cell list and inter-frequency black cell list sent to UE in RRC
measurement object (except for emergency calls) will also include the cells that do not
support the serving PLMN and list of equivalent PLMN of the call, or belong to the
forbidden TAs. However, the intra-frequency black cell list of SIB4 and the inter-frequency
black cell list of SIB5 are not impacted by the changes.
BlackCellConf MO contains the following two parameters:

• range
• start
BlackCellConf::range
Parameter Range

LteNeighboringFreqConf/ BlackCellConf

[n4, n8, n12, n16, n24, n32, n48, n64, n84, n96, n128, n168, n252,
n504]
Class/Source C – New Setups / customer_init
Value O.D.
Feature LL103792, L104002

Notes: The parameter indicates the total number of black cells included in the
BlackCellConf MO. It is optional and do not need to be provisioned if there is only one
black cell in the BlackCellConf MO.
BlackCellConf::start
Parameter start

LteNeighboringFreqConf/ BlackCellConf

[0..503] step = 1
Value O.D.
Feature LL103792, L104002

Notes: The parameter indicates the lowest physical cell identity of the black cells included
in the BlackCellConf MO.
Black cells specified in the BlackCellConf MO under the LteNeighboringFreqConf MO

that is pointed to by LteCell::lteNeighboringFreqsConfIdis used to build the
intraFreqBlackCellList of SIB4.
Page 50/543
Volume 6 : Mobility
Criteria 1a :
Squal of evaluated cell > threshXHighQ (SIB5or6)
during a time interval tReselectionRAT
Criteria 1b :
Srxlev of evaluated cell > threshXHigh (SIB5or6)
• If threshServingLowQisprovided in SIB3,
Cell reselection to a cell on a higher priority E-UTRAN frequency or UTRAN frequency

than serving frequency will be performed if:
- A higher priority cell fulfils criteria 1a

With tReselectionRAT = tReselectionUtra or tReselectionEUTRAN
Cell reselection to a cell on a lower priority E-UTRAN frequency or UTRAN frequency

- No cell on a higher priority E-UTRAN frequency or inter-RAT frequency

than serving frequency fulfills the criteria 1a
- And SqualservingCell<threshServingLowQ
- And the Squal of a cell of a lower priority inter or UTRAN frequency
>threshXLowQ during a time interval tReselectionRAT
(tReselectionUtra or tReselectionEUTRAN)
• If threshServingLowQisnot provided in SIB3,

- A higher priority cell fulfils criteria 1b



than serving frequency fulfills the criteria 1b
- And SrxlevservingCell<threshServingLow
- And the Srxlev of a cell of a lower priority inter or UTRAN frequency
>threshXLow during a time interval tReselectionRAT (tReselectionUtra
or tReselectionEUTRAN)
If UE is not R9 capable, threshServingLowQ, threshXHighQ and threshXLowQ usage is

not possible. Then UE uses only threshServingLow, threshXHigh and threshXLow.
Figure 8 : User Case, with R8 UE Class3 and in the same PLMN, showing reselection towards
higher priority EUTRAN cell inter-freq.
Page 51/543
Volume 6 : Mobility
1: Serving cell degrades and the RSRP level decrease under [Qrxlevmin(SIB1) + X +
max[(pMax(SIB1)-Pumax), 0] + sNonIntraSearch]. Then cell detection of better cell is
possible with other time frequency towards all cells.
Rq: It was possible to reselect towards higher priority inter-freq cell before this threshold.
2: The situation above is still reached (or not) and, in the target cell, threshold
[Qrxlevmin(SIB5) + X + max[(pMax(SIB5)-Pumax), 0]+threshXHigh] is reached.
tReselectionEUTRAN or tReselectionRAT is started.
During tReselectionEUTRAN, NO higher cell priority reaches [Qrxlevmin + X +
Pcompensation+threshXHigh].
3::tReselectionEUTRAN or tReselectionRAT is achieved, reselection is triggered.
UE starts Inter freq meas
1
(and iRAT) for lower and
equal priority cell
4 •Eutran cell is reselected
with other freq
reselection
Srxlev > 0
RSRP Serving Cell tReselectionEUTRAN RSRP lower priority eUTRAN cell

or tReselectionRAT
Qrxlevmin(SIB5)
+Qrxlevminoffset(SIB1)
Qrxlevmin(SIB1) +Pcompensation(SIB5)
+Qrxlevminoffset(SIB1) +threshXHigh(SIB5)
+Pcompensation(SIB1)
+sNonIntraSearch(SIB3)
3 Qrxlevmin(SIB5)
Qrxlevmin(SIB1) +Pcompensation(SIB5)
+Qrxlevminoffset(SIB1) +threshXLow(SIB5)
+Pcompensation(SIB1) LTE lower priority
+threshServingLow (SIB3)
cell – criteria not met
UE starts looking at lower

2 priority cell for reselection
time
qrxlevminoffset = 0 if same PLMN
priority EUTRAN cell inter-freq.
1: Serving cell becomes less good and the RSRP level decrease under [qrxlevmin(SIB1)
+ X + max[(pMax(SIB1)-Pumax), 0] + sNonIntraSearch]. Then cell detection of better
cell is possible towards all cells, and we can detect and measured lower priority cells than
the serving.
2: Serving cell becomes worse and the RSRP level decrease under [qrxlevmin(SIB1) + X
+ max[(pMax-Pumax), 0] + threshServingLow]. Cell reselection would be possible, but
not yet candidate cell, not reaching [qrxlevmin(SIB5) + X
+max[(pMax(SIB5)-Pumax), 0] +threshXLow].
Page 52/543
Volume 6 : Mobility
3: The situation just above is still reached and also, in the target cell, threshold
[qrxlevmin+X+ max[(pMax(SIB5)-Pumax), 0] +threshXLow]is reached.
tReselectionEUTRAN or tReselectionRATis started.
During tReselectionEUTRAN or tReselectionRAT, NO higher cell priority reaches
[qrxlevmin+X+Pcompensation+threshXHigh]
4:tReselectionEUTRAN or tReselectionRAT is achieved, reselection is triggered.
Rq: This reselection process for inter-freq is also always used if sNonIntraSearchis not
broadcasted thus, only thethreshold threshServingLowis applying in this case.
For reselection towards equal priority inter-freq cell, step 1 above is mandatory (because
you do not measure any equal priority before get this threshold with sNonIntraSeach) and
the same ranking as for intra-freq reselection is apply on step 3.
1
UE starts Inter freq meas
(and iRAT) for equal 4 •Eutran cell is reselected
with other freq
priority cell reselection
Srxlev > 0
RSRP equal priority
RSRP Serving Cell tReselectionEUTRAN
or tReselectionRAT eUTRAN cell
Qrxlevmin(SIB1)
3 Rn > Rs
qOffsetCell
+sNonIntraSearch(SIB3)
Qrxlevmin(SIB5)
LTE equal priority
cell – criteria not met Traditional”S” criteria
2 UE starts ranking cells

qHyst
time
qrxlevminoffset = 0 if same PLMN
equal priority EUTRAN cell inter-freq.
1: Serving cell becomes less good and the RSRP level decrease under [qrxlevmin(SIB1)
+ X + max[(pMax(SIB1)-Pumax), 0] + sNonIntraSearch]. Then cell detection of better
cell is possible towards equal priority inter-freq neigboring cell.
2: The situation just above is still reached and also, in the target cell, threshold
[qrxlevmin+X+ max[(pMax(SIB5)-Pumax), 0] ]is reached. UE start ranking cells.
3: Ranking is verified between serving cell and neighboring cell

i.e : Qmeas,s + qHyst <Qmeas,n – qOffsetCell
During tReselectionEUTRAN or tReselectionRAT
4: tReselectionEUTRAN or tReselectionRATis end with the condition above, reselection

towards equal priority inter-freq cell is trigger.
Page 53/543
Volume 6 : Mobility
• threshServingLow:Threshold for serving cell reception level used in reselection

evaluation towards lower priority E-UTRAN frequency or RAT. The value sent over
the RRC interface is half the value configured (the UE then multiplies the received
value by 2). Defined in TS 36.331. Broadcast in SystemInformationBlockType3.
CellSelectionReselectionConf::threshServingLow
Parameter threshServingLow
Range & Unit Integer, dB

[0..62] step = 2
Value 10 see engineering recommendation
Feature L96760, L76498, L84807

Notes:When ActivationService::isSIB3ReselectionAutomationEnabled is set to ‘True’,
this parameter will be adjusted automatically based on cell loading. Refer to section 4.1.3.5
for details.
Engineering Recommendation: threshServingLow
To get the option to reselect as soon as possible, with serving cell reception level below
sNonIntraSearch, we can set threshServingLowat the same level than
sNonIntraSearch, i.e set threshServingLow to 16 dB.
• threshServingLowQ:This parameter specifies the threshold for serving cell reception

quality used in reselection evaluation towards lower priority E-UTRAN frequency or
RAT. Broadcast in SystemInformationBlockType3.
CellSelectionReselectionConf::threshServingLowQ
Parameter threshServingLowQ

[0..31] step = 1
Value see engineering recommendation
Feature L114644.1
Notes: When ActivationService::isSIB3ReselectionAutomationEnabled is set to ‘True’,
for details.
Page 54/543
Volume 6 : Mobility
Engineering Recommendation: threshServingLowQ
sNonIntraSearchQ, we can set threshServingLowQat the same level than
sNonIntraSearchQ, i.e set threshServingLowQ to 10 dB.
• threshXHigh:This parameter configures the IE threshX-High included in IE

SystemInformationBlockType5 for inter-frequency. The value sent over the RRC
interface is half the value configured and the UE then multiplies the received value by
2. See 3GPP 36.331.
CellReselectionConfLte::threshXHigh
Parameter threshXHigh


[0..62] step = 2
Value 20
Feature 108283
Note: The value entered for CellReselectionConfLte::threshXHigh of a LTE frequency is
divided by 2 before it is used to populate the field of s-IntraSearch in SIB3, or the field of
threshX-High in SIB5. The threshold value used by UE is the parameter value received
from SIB3 or SIB5 multiplied by 2 in unit of dB (same value entered for
CellReselectionConfLte::threshXHigh).
Page 55/543
Volume 6 : Mobility
• threshXHighQ:This parameter configures the IE threshX-HighQ included in IE
SystemInformationBlockType5 for inter-frequency reselection. See 3GPP 36.331.
CellReselectionConfLte::threshXHighQ
Parameter threshXHighQ


[0..31] step = 1
Value N.A.
Feature L114644.1
• threshXLow:This parameter configures the IE threshX-Low included in IE

SystemInformationBlockType5 for inter-frequency. The value sent over the RRC
interface is half the value configured and the UE then multiplies the received value by
2. See 3GPP 36.331.
CellReselectionConfLte::threshXLow
Parameter threshXLow


[0..62] step = 2
Value 0
Feature 108283
Note: The value entered for CellReselectionConfLte::threshXLow of a LTE frequency is
divided by 2 before it is used to populate the field of threshServingLow in SIB3, or the field
of threshX-Low in SIB5. The threshold value used by UE is the parameter value received
from SIB3 or SIB5 multiplied by 2 in unit of dB (same value entered for
CellReselectionConfLte::threshXLow).
Page 56/543
Volume 6 : Mobility
• threshXLowQ:This parameter configures the IE threshX-LowQ included in IE
SystemInformationBlockType5 for inter-frequency reselection. See 3GPP 36.331.
CellReselectionConfLte::threshXLowQ
Parameter threshXLowQ


[0..31] step = 1
Value 0
Feature L114644.1
4.1.4.3 CONFIGURATION MODEL FOR

SYSTEMINFORMATIONBLOCKTYPE5 PARAMETERS
The configuration model below summarizes the parameters that need to be provisioned to
support broadcasting SIB5 in eNB.
Figure 11 Configuration Model for SIB5 Parameters
Page 57/543
Volume 6 : Mobility
4.1.5 INTER-RAT CELL RESELECTION TO UTRAN
The feature L76498 provides basic mobility capability for UE moving from LTE radio
coverage to UMTS radio coverage. This feature enables the LTE-to-UMTS mobility for
multi-mode UEs in RRC idle mode, allowing a UE to leave the LTE coverage (island, hot-
spot or hot-spots cloud) and recover the service in the UMTS coverage; as soon as the
UMTS coverage is available i.e. inter-RAT measurement demonstrate that the UMTS radio
conditions are sufficiently good.
GSM_Connected
CELL_DCH Handover E-UTRA Handover
RRC CONNECTED
GPRS Packet
transfer mode
CELL_FACH
Reselection CCO with
optional CCO,
CELL_PCH NACC Reselection
URA_PCH
Connection establishment/release establishment/release
establishment/release
Reselection Reselection GSM_Idle/GPRS

UTRA_Idle E-UTRA
RRC IDLE Packet_Idle
Reselection CCO, Reselection
Figure 12: Reselection from eUTRAN to UTRAN
4.1.5.1 CELL RESELECTION ACTIVATION
Cell reselection to UTRA of feature L96372 is activated when

ActivationService::isMobilityToUtranAllowedis set to ‘True’.
When reselection to UTRA is activated, eNB will broadcast SystemInformationBlockType6

(SIB6) in addition to SystemInformationBlockType3 (SIB3) to support UE for LTE to UTRA
cell reselection in RRC idle mode.
Page 58/543
Volume 6 : Mobility
ActivationService::isMobilityToUtranAllowed
Parameter IsMobilityToUtranAllowed

[True, False]
Value True
Feature L96372
Notes: This parameter controls the activation/deactivation of feature L76498 and L96372.
This optional features are managed by Feature Licensing (refer to LPUG Volume 2 for
features. The total number of activations for the features is counted across all eNBs by
SAM.
This parameter is to replace the two LA2.0 parameters,
isCellReselectionToUtraFddAllowed and isRedirectionToUtraFddAllowed.
4.1.5.2 SIB 6 AND SIB 3 FOR CELL RESELECTION

UE relies on the parameters in SystemInformationBlockType3 (SIB3) and
SystemInformationBlockType6 (SIB6) broadcasted by the cell for LTE to UTRA Inter-RAT
cell reselection.
The IE SystemInformationBlockType3 contains cell re-selection information common for
intra-frequency, inter-frequency and/or inter-RAT cell re-selection (i.e. applicable for more
than one type of cell re-selection but not necessarily all) as well as intra-frequency cell re-
selection information other than neighboring cell related.
SystemInformationBlockType3 contains also speed dependant reselection parameters
(Refer to Section 4.4 of LPUG Volume 6 for parameters included in SIB3).
The IE SystemInformationBlockType6 contains information relevant only for inter-RAT cell
re-selection i.e. information about UTRA-FDD frequencies and UTRA-FDD neighboring
cells relevant for cell re-selection. The IE includes cell re-selection parameters common for
a frequency as well as cell specific re-selection parameters.
The IE contains common parameters to all UTRA frequencies:
UtraNeighboring::tReselectionUtra,
UtraSpeedDependentConf::tReselectionUtraSfHigh and
UtraSpeedDependentConf::tReselectionSfMedium.
The IE SystemInformationBlockType6 also contains CarrierFreqListUTRA-FDD. Each
CarrierFreqUTRA-FDD includes UtraFddNeigboringFreqConf::carrierFreq and the
reselection parameters for the carrier frequency including
CellReselectionConfUtraFdd::cellReselectionPriority,
CellReselectionConfUtraFdd::pMaxUTRA, CellReselectionConfUtraFdd::qQualMin,
CellReselectionConfUtraFdd::qRxLevMin,
CellReselectionConfUtraFdd::threshXHigh,
CellReselectionConfUtraFdd::threshXLow.
Page 59/543
Volume 6 : Mobility
The S criterion is used once again to select the available cells for reselection, but with the
parameters broadcasted in SIB6.
Prerequisites on serving cell are based on SIB3 and SIB1 parameters.
4.1.5.3.1 CELL SELECTION CRITERIA ON SERVING CELL

The cell selection criterion S is the same as for intra-freq case.

UE will search for UTRA layers of higher priority at least every Thigher_priority_search.
If SServingCell ≤ sNonIntraSearch then the UE will search for and measure UTRA
layers of higher and lower priority in preparation for possible reselection. The UE shall
measure RSRP at least every (NUTRA_carrier) * Tmeasure,EUTRAN_Inter for identified
lower or higher priority UTRAN cells.
If Srxlev >sNonIntraSearchPand Squal >sNonIntraSearchQ then the UE will search

for UTRA layers of higher priority at least every Thigher_priority_search.

for and measure UTRA layers of higher and lower priority in preparation for possible
reselection. The UE will measure RSCP or Ec/No at least every (NUTRA_carrier) *
TmeasureUTRA_FDDfor identified lower and higher priority UTRA cells.
RSRP
Looking for Higher priority cell Looking for Higher and lower priority cell
S-ServingCell at least every (60 * Nlayers) sec. at least every (30 * NUTRA_carrier) sec.
Measurements for higher and lower
priority cell at least every
(NUTRA_carrier) * TmeasureUTRA_FDD
Qrxlevmin(SIB1) +
Pcompensation +
sNonIntraSearchP(SIB3) Min. Detect = (60* Nlayers) s.
Min. Detect =(NUTRA_carrier) * 30s
Min. Measurements = (NUTRA_carrier)* 6,4 s.
•t
Figure 13 : Start of measurements for inter-RAT reselection if serving cell is degraded under
a RSRP threshold
Note: NUTRA_carrier is the number of UTRA inter-RAT carriers indicated by the
serving cell.
Note: TmeasureUTRA_FDD, Tdetect and UTRA_FDD values are in inter-working with
Enb::defaultPagingCycle value.
Page 60/543
Volume 6 : Mobility
RSRQ
S-ServingCell at least every (60 * Nlayers) sec. at least every (30 * NUTRA_carrier) sec.
(NUTRA_carrier) * TmeasureUTRA_FDD
Qqualmin(SIB1) +
sNonIntraSearchQ(SIB3)
Min. Detect = (60* Nlayers) s.
Min. Detect =(NUTRA_carrier) * 30s
Min. Measurements = (NUTRA_carrier)* 6,4 s.
•t
Figure 14 : Start of measurements for inter-RAT reselection if serving cell is degraded under
a RSRQ threshold
• sNonIntraSearch:Threshold for serving cell reception level under which the UE must
trigger inter-frequency and inter-RAT measurements to cells of equal or lower priority
for cell reselection .The value sent over the RRC interface is half the value configured
(the UE then multiplies the received value by 2). For more details consult
TS36.304. Defined in TS 36.331. Broadcast in SystemInformationBlockType3
CellSelectionReselectionConf::sNonIntraSearch
Parameter sNonIntraSearch
Range & Unit Integer in dB

[0..62] step = 2
Class/Source C - Immediate Propagation / customer_settable
Value see engineering recommendation below

Notes: For r8 UE, if this field is not provisioned, UE applies the default value of infinity. For
r9 UE, if CellSelectionReselectionConf::sNonIntraSearchP is provisioned, UE applies
the value of sNonIntraSearchP instead. Otherwise, if neither sNonIntraSearch nor
sNonIntraSearchP is provisioned, r9 UE applies the default value of infinity. When
details.
Engineering Recommendation: sNonIntraSearch

For better performance, we recomend to do measurements earlier.
The value 10is the recommended value
Engineering Recommendation: CellSelectionReselectionConf::sNonIntraSearch
To avoid ping pong between LTE and WCDMA, after a UE reselected to LTE from
WCDMA, the WCDMA signal has to be strong enough for the UE to consider LTE to
WCDMA reselection again: Enough so that the UE does not measure 3G again.
qRxLevmin (LTE_sib1) + sNonIntraSearch(LTE_sib 3)
Page 61/543
Volume 6 : Mobility
<
eUtraTargetFrequencyQrxlevmin (wcdma_sib19) +
eUtraTargetFrequencyThreshxHigh (wcdma_sib19)
If CellSelectionReselectionConf::qRxLevmin =
EUtranFrequencyAndPriorityInfoList.eUtraTargetFrequencyQrxlevmin, then
sNonIntraSearch(LTE_sib 3)
<
eUtraTargetFrequencyThreshxHigh (wcdma_sib19)
If LTE is preferred (LTE cell has higher priority than WCDMA cell,
eUtraTargetFrequencyThreshxHighis set to the higher value above
sNonIntraSearch.
Typically if sNonIntraSearchis set to 10, eUtraTargetFrequencyThreshxHigh
should be set to 16.
Since sNonIntraSearchis used in many iRAT procedures, it is recommended to set
the value of eUTRATargetFrequencyThreshxHigh (wcdma_sib19) based on the
setting of sNonIntraSearch.
Similar rule should apply to eUtraTargetFrequencyThreshxLow.
If the SservingCell of the E-UTRA serving cell (or other cells on the same frequency layer)
is greater than Snonintrasearch then (3GPP 36133):
o the UE may not search for, or measure inter-RAT layers of lower priority.
o the UE searches for inter-RAT layers of higher priority at least every
Thigher_priority_search = (60 * Nlayers) seconds, where
Nlayersis the total number of configured higher priority E-UTRA, UTRA FDD, UTRA TDD,
CDMA2000 1x and HRPD carrier frequencies and is additionally increased by one if one or
more groups of GSM frequencies is configured as a higher priority.
• sNonIntraSearchP:This parameter specifies the threshold for serving cell reception

level, below which the UE R9 capable triggers inter-frequency and inter-RAT
measurements for cell reselection. If the field is not present, the UE applies the
(default) value of infinity. The value sent over the RRC interface is half the value
configured and the UE then multiplies the received value by 2. See TS 36.304 and TS
36.331. Broadcast in SystemInformationBlockType3.
CellSelectionReselectionConf::sNonIntraSearchP
Parameter sNonIntraSearchP

[0..62] step = 2
Value see engineering recommendation below
Feature L114644.1
Notes: For r9 UE, if this field is not provisioned but
CellSelectionReselectionConf::sNonIntraSearch is, UE applies the value of
sNonIntraSearch. Otherwise if neither sNonIntraSearch nor sNonIntraSearchP is
Page 62/543
Volume 6 : Mobility
provisioned, UE applies the default value of infinity. When
details.
Engineering Recommendation: sNonIntraSearchP

We recommend to follow the sNonIntraSearch recommendation just above.
Rule: If sNonIntraSearchP or sNonIntraSearch unknown by the UE
If the field s-NonIntraSearchP is present, the UE applies the value of

sNonIntraSearchP(and also instead of sNonIntraSearch value). Otherwise if
neither s-NonIntraSearch nor s-NonIntraSearchP is present, the UE applies the
(default) value of infinity for sNonIntraSearchP (or sNonIntraSearch).
That means that in this case UEs carry out measurements towards all priority cells
and with a high level of measurement frequency.
• sNonIntraSearchQ:This parameter specifies the threshold for serving cell reception

quality, below which the UE R9 capable triggers inter-frequency and inter-RAT
measurements for cell reselection. If the field is not present, the UE applies the
(default) value of 0 dB. Broadcast in SystemInformationBlockType3.
CellSelectionReselectionConf::sNonIntraSearchQ
Parameter sNonIntraSearchQ

[0..31] step = 1
Value N.A.
Feature L114644.1
Notes: When ActivationService::isSIB3ReselectionAutomationEnabled is set to ‘True’,
for details.
Rule: If sNonIntraSearchQ value unknown by R9 UE
If the field is not provisioned, r9 UE applies the (default) value of 0 dB for

sNonIntraSearchQ.
4.1.5.3.2 CELL SELECTION CRITERIA ON TARGET CELLS

The cell selection criterion S (Calculated by the UE) is fulfilled when [3GPP 25.304]:
Page 63/543
Volume 6 : Mobility
Srxlev > 0
And
Squal > 0
Where:
Srxlev = Qrxlevmeas – (Qrxlevmin + Qrxlevminoffset) - Pcompensation
And
Squal = Qqualmeas – (Qqualmin + QqualminOffset)
Where:
The signalled value QrxlevminOffset is only applied when a cell is evaluated for cell
Page 64/543
Volume 6 : Mobility
Srxlev Calculated by the Cell Selection RX level value (dB).
UE
Squal Calculated by the Cell Selection quality value (dB) Applicable only
UE for FDD cells.
Qrxlevmeas Measured by the Measured cell RX level value (RSRP).
UE
Qrxlevmin CellSelectionResel Minimum required RX level in the cell (dBm).

ectionConf::qRxLe SIB6 for the target cell.
vMin or
CellReselectionCo
nfUtraFdd::qRxLev
Min
Qrxlevminoffs CellSelectionReselec Offset to the signalled Qrxlevmin taken into
et
tionConf::qRxlevmin account in the Srxlev evaluation as a result of a
offset periodic search for a higher priority PLMN while
camped normally in a VPLMN [R17].
SIB1
Qqualmin CellReselectionCo Minimum required quality level in the cell (dB).
nfUtraFdd::qQualM Applicable only for FDD cells.SIB6 in inter-working
in with 3G SIB3 Qqualmin.
QqualminOf Not yet implemented Offset to the signalled Qqualmin taken into account in
fset the Squal evaluation as a result of a periodic search
for a higher priority PLMN while camped normally in a
VPLMN. Not yet implemented [R17]
Pcompens Calculated by the Max (pMaxUTRA – Pumax, 0) (dB).
ation UE : to see
pMaxUTRA
configuration
parameter
Pemax CellReselectionConf Broadcasted in SIB6, the maximum allowed
UtraFdd ::pMaxUTRA transmission power on the (uplink) carrier frequency,
see TS 25.304(UE_TXPWR_MAX_RACH) . In dBm
Pumax Value is 24dBm for maximum UE output power (dBm) according to its
Class 3 UE power class in 3g.
When camped normally, the UE shall perform the following tasks [R16]:
o select and monitor the indicated Paging Channels of the cell according to information
sent in system information;
o monitor relevant System Information;
o perform necessary measurements for the cell reselection evaluation procedure;
o execute the cell reselection evaluation process on the following occasions/triggers:
- UE internal triggers;
- When information on the BCCH used for the cell reselection
evaluation procedure has been modified.
Page 65/543
Volume 6 : Mobility
• qRxLevMin:This specifies the minimum required Rx level in the cell in dBm.This
parameter configures the q-RxLevMin included in the SystemInformationBlockType6.
The value sent over the RRC interface is computed by substracting 1 to the
configured value and dividing by 2 (the UE performs the opposite computation, i.e. IE
vale * 2 + 1)
CellReselectionConfUtraFdd::qRxLevMin
Parameter qRxLevMin
Object ENBEquipment/ Enb/ LteCell/ UtraNeighboring/

UtraFddNeighboringFreqConf/ CellReselectionConfUtraFdd
Range & Unit Integer in dBm

[-119..-25] step = 2
Class/Source C – Immediate Propagation / customer_settable
Value -119
Feature L76498
Actual value Qrxlevmin = IE value * 2+1 [dBm]. Specifies the minimum required Rx RSRP
level in the cell. (Where IE specify the DLU database value)
Changing this value will affect cell size in terms of re-selection area toward UMTS.
Increasing this value will lead the mobile to start cell-selection/re-selection procedure
sooner and then will artificially decrease cell size in idle mode.
Rule: qRxlevminoffset MO CellSelectionReselectionConf
The same Offset used for inter-LTE mobility is used whatever is the target cell,
indeed the qRxlevminoffset parameter is unique in the database.
• pMaxUTRA :TS36.331: this parameter configures the p-MaxUTRA included in the IE

CellReselectionConfUtraFdd::pMaxUTRA
Parameter pMaxUTRA


[-50..33] step = 1
Value 24
Feature L76498
Pcompensation is a compensation factor to penalize the low power mobiles.
Page 66/543
Volume 6 : Mobility
Where:
PEMAX = pMaxUTRA
operating band. (see table below)
Power (dBm)
Operating Band
I UMTS 2100 MHz +33 +27 +24 +21
II UMTS 1900 MHz N.A. N.A. +24 +21
V UMTS 850 MHz N.A. N.A. +24 +21
VI UMTS 850 MHz N.A. N.A. +24 +21
VIII UMTS 900 MHz N.A. N.A. +24 +21
Table 8: UE power Class vs. maximum output power, Pumax.
• qQualMin :TS36.331: this parameter configures the q-QualMin included in the IE

CellReselectionConfUtraFdd::qQualMin
Parameter qQualMin


[-24..0] step = 1
Value -20
Feature L76498
Page 67/543
Volume 6 : Mobility
•CPICH RSCP
Measurement zones :
Qrxlevmin(SIB6)+Qrxlevminoffset Qqualmeas > Qqualmin
+Pcompensation Qrxlevmeas > Qrxlevmin(SIB6)
+Qrxlevminoffset+Pcompensation
Qqualmeas > Qqualmin

and
Qrxlevmeas > Qrxlevmin(SIB6)
+Qrxlevminoffset+Pcompensation
•CPICH Ec/Io
Qqualmin
Figure 15 : newly detectable UTRA FDD cells and Cell selection Thresholds.
Comments related to the diagram just above:

When the measurement rules indicate that UTRA FDD cells are to be measured, the UE
shall measure CPICH Ec/No and CPICH RSCP of detected UTRA FDD cells in the
neighbor cell list at the minimum measurement rate in relationship with
Enb::defaultPagingCycle.
In inter-working with the value of Enb::defaultPagingCycle, which isrf128, Measures
occur at least:
(NUTRA_carrier) * [6.4 sec]
NUTRA_carrier: number of carriers used for all UTRA FDD cells in the neighbor cell list
Configuration Model
The MO UtraNeighboring contains information related to the cells neighboring (e.g. at the
network level but not at the frequency level): this information is gathered in a child MO that
is called UtraFddNeighboringCellRelation MO.
The MO UtraNeighboring contains information related only to the frequencies neighboring
(i.e. only at the frequency level): this information is gathered in a child MO that is called
UtraFddNeighboringFreqConf MO.
Page 68/543
Volume 6 : Mobility
Figure 16 : Configuration Model UTRAFDDNEIGHBORING
4.1.5.3.3 CELL RESELECTION PRIORITIES HANDLING
Absolute priorities of different E-UTRAN frequencies ([R16] in 5.2.4.1) or inter-RAT

frequencies may be provided to the UE in the:
o system information
o RRCConnectionRelease message releasing the RRC connection., or
o by inheriting from another RAT at inter-RAT cell (re)selection.

In the case of system information, an E-UTRAN frequency or inter-RAT frequency may
be listed without providing a priority (i.e. the field cellReselectionPriorityis absent for that
frequency).
If priorities are provided in dedicated signalling, the UE shall ignore all the priorities
provided in system information.
If UEis in camped on any cell state, UE shall only apply the priorities provided by system
information from current cell, and the UE preserves priorities provided by dedicated
signalling unless specified otherwise. When the UE is camped in normal state, it shall
consider the current frequency to be the lowest priority frequency (i.e. lower than the
eight network configured values).
The UE shall delete priorities provided by dedicated signalling when:
• the UE enters RRC_CONNECTED state; or

• the optional validity time of dedicated priorities (t320) expires; or
• a PLMN selection is performed on request by NAS.
NOTE: Equal priorities between RATs are not supported.
Page 69/543
Volume 6 : Mobility
The UE shall only perform cell reselection evaluation for E-UTRAN frequencies and inter-
RAT frequencies that are given in system information and for which the UE has a priority
provided. The UE shall not consider any black listed cells as candidate for cell reselection.
The UE shall inherit the priorities provided by dedicated signalling and the remaining
validity time (i.e., t320…), if configured, at inter-RAT cell (re)selection.
NOTE: The network may assign dedicated cell reselection priorities for
frequenciesnot configured by system information.
− t320: TS36.331: This parameter contributes to the configuration of the IE

IdleModeMobilityControlInfo used in the message RRCConnectionRelease. This
parameter isoptional.
UeTimers::t320
Parameter t320
Object ENBEquipment/ Enb/ DedicatedConf/ UeTimers
Range & Unit Enumerate in s
[min5, min10, min20, min30, min60, min120, min180]
Value N.A.
Feature L76498
Keys for Hierarchy: ENBEquipment Enb DedicatedConf UeTimers
Start: Upon receiving t320 or upon cell (re)selection to E-UTRA from another RAT with
validity time configured for dedicated priorities (in which case the remaining validity time is
applied).
Stop: Upon entering RRC_CONNECTED, when PLMN selection is performed on request
by NAS, or upon cell (re)selection to another RAT (in which case the timer is carried on to
the other RAT).
At expiry: Discard the cell reselection priority information provided by dedicated
signalling.This parameter is optional: if not present, then the eNB shall not send the IE
IdleModeMobilityControlInfo in the message RRCConnectionRelease.
4.1.5.3.4 UE SPEED MANAGEMENT
Parameters in relationship with mobility speed states of a UE, in case of inter-RAT mobility,
are the same as in case of intra-LTE mobility, except parameters in the MO object
UtraSpeedConf andtReselectionUtra, which are specific.
Scaling rules:
The cell ranking procedure is the same as in 4.1.5.3.3but with variable values for
parameters qHyst and tReselection. UE shall apply the following scaling rules:
- If neither Medium- nor Highmobility state is detected:
- no scalingis applied.
- If High-mobility state is detected:
- AddqHystSfHigh to Qhyst for high mobility state if sent on system information.
Page 70/543
Volume 6 : Mobility
- For UTRAN cellsmultiplytReselectionUtra by tReselectionUtraSfHigh if sent on
system information.
- For CDMA2000 HRPD cellsmultiplytReselectionCdmaHrpd by the IE sf-High of

"Speed dependent ScalingFactor for TreselectionCDMA_HRPD for high mobility
state” if sent on system information. See section 4.1.7.3.
- For CDMA2000 1xRTT cells multiply tReselectionCdma1xRtt by the IE sf-High of

"Speed dependent ScalingFactor for TreselectionCDMA_1xRTT for high mobility
state” if sent on system information. Refer to section 8.1.5.
- If Medium-mobility state is detected:

- Add qHystSfMediumto Qhyst if sent on system information.
- For E-UTRAN cells multiply tReselectionEUTRAN by

tReselectionEutraSfMedium, if sent on system information.
- For UTRAN cells multiply tReselectionUtra by tReselectionUtraSfMedium, if

sent on system information.
- For CDMA2000 HRPD cells multiply tReselectionCdmaHrpd by the IE sf-Medium

of "Speed dependent ScalingFactor for tReselectionCdmaHrpd for medium mobility
state”" if sent on system information. See section 4.1.7.3.
- For CDMA2000 1xRTT cells multiply tReselectionCdma1xRtt by the IE sf-Medium

of "Speed dependent ScalingFactor for TreselectionCDMA_1xRTT for medium
mobility state”" if sent on system information. Refer to section 8.1.5.
• tReselectionUtraSfHigh :TS36.331: this parameter contributes to the configuration of

the IE SystemInformationBlockType6. This parameter configures the t-
ReselectionUTRA-SF included in the IE SystemInformationBlockType6. Parameter
“Speed dependent ScalingFactor for TreselectionUTRA” in TS 36.304. If the field is
not present, the UE behaviour is specified in TS 36.304. The concerned mobility
control related parameter ismultiplied with this factor if the UEis in High Mobility
state as defined in TS 36.304. Value oDot25 corresponds to 0.25, oDot5 corresponds
to 0.5, oDot75 corresponds to 0.75 and so on.
UtraSpeedDependentConf::tReselectionUtraSfHigh
Parameter tReselectionUtraSfHigh

UtraSpeedDependentConf

[oDot25, oDot5, oDot75, IDot0]
Value oDot25
Feature L76498
This parameter helps avoid ping pong radio phenomena during the RA-Update & idle
mobility.
• tReselectionUtraSfMedium:TS36.331: this parameter contributes to the configuration
of the IE SystemInformationBlockType6. This parameter configures the t-
ReselectionUTRA-SF included in the IE SystemInformationBlockType6. Parameter
Page 71/543
Volume 6 : Mobility
“Speed dependent ScalingFactor for TreselectionUTRA” in TS 36.304. If the field is
not present, the UE behaviour is specified in TS 36.304. The concerned mobility
control related parameter ismultiplied with this factor if the UEis in Medium
Mobility state as defined in TS 36.304. Value oDot25 corresponds to 0.25, oDot5
corresponds to 0.5 , oDot75 corresponds to 0.75 and so on.
UtraSpeedDependentConf::tReselectionUtraSfMedium
Parameter tReselectionUtraSfMedium

UtraSpeedDependentConf

[oDot25, oDot5, oDot75, lDot0]
Value oDot25
Feature L76498
mobility.
4.1.5.3.5 INTER-RAT CELL RESELECTION CRITERIA
Criteria 1a :
Squal of evaluated cell > threshXHighQ (SIB5or6)
Criteria 1b :
For UTRAN and inter-freq cell, Squal, Srxlev are the Squal-value and Srxlev-value of an
evaluated target cell. Report to section 4.1.3.1.1to know whatSqual andSrxlev are.
Rule: tReselectionRAT matching with the type of mobility

tReselectionRAT : This specifies the cell reselection timer value. For each target
frequency/frequency group per RAT a specific value for the cell reselection timer is
defined, which is applicable when evaluating reselection within E-UTRAN or towards
other RAT (i.e. tReselectionRAT for E-UTRAN istReselectionEUTRAN, for UTRAN
tReselectionUtra, for GERAN tReselectionGERAN, for Cdma
tReselectionCdmaHrpd, and for tReselectionCdma1xRtt).
Note: tReselectionRATis not sent on system information, but used in reselection

rules by the UE for each RAT.
• If threshServingLowQisprovided in SIB3,
Page 72/543
Volume 6 : Mobility
- A higher priority cell fulfils criteria 1a


-No cell on a higher priority E-UTRAN frequency or inter-RAT frequency

than serving frequency fulfills the criteria 1a
- And the Squal of a cell of a lower priority inter or UTRAN frequency
>threshXLowQ during a time interval tReselectionRAT
(tReselectionUtra or tReselectionEUTRAN)
• If threshServingLowQisnot provided in SIB3,

- A higher priority cell fulfils criteria 1b



than serving frequency fulfills the criteria 1b
- And the Srxlev of a cell of a lower priority inter or UTRAN frequency
>threshXLow during a time interval tReselectionRAT (tReselectionUtra
or tReselectionEUTRAN)
Cell reselection to a cell on an equal priority E-UTRAN frequency will be based on

ranking for Intra-frequency Cell Reselection as defined in section 4.1.3.1.2or in [R16]
section 5.2.4.6.
In all the above criteria the value of tReselectionRATisscaled when the UEis in the
medium or high mobility state as defined in section 4.2or in subclause [R16] 5.2.4.3.1.
If more than one cell meets the above criteria, the UE shall reselect a cell as follows:
- If the highest-priority frequency is an E-UTRAN frequency, a cell ranked as the best
cell among the cells on the highest priority frequency(ies) meeting the criteria according to
section 4.1.3.1.2or in [R16] section 5.2.4.6;
- If the highest-priority frequency is from another RAT, a cell ranked as the best cell
among the cells on the highest priority frequency(ies) meeting the criteria of that RAT.
SqualservingCell is the Squal value of the serving cell based on Squal described and
available to section 4.1.3.1.1.
SrxlevservingCell is the Srxlev value of the serving cell based on Srxlev described and
availableto section 4.1.3.1.1.
If UE is not R9 capable, threshServingLowQ, threshXHighQ and threshXLowQ

parameters usage is not possible. Then UE will use only to the threshServingLow,
Page 73/543
Volume 6 : Mobility
threshXHigh and threshXLow.
• tReselectionUtra:TS36.331: this parameter configures the t-ReselectionUTRA

included in the IE SystemInformationBlockType6. Parameter “TreselectionUTRAN” in
TS 36.304. This concerns the cell reselection timer TreselectionRAT for UTRA. Value
in seconds.
UtraNeighboring::tReselectionUtra
Parameter tReselectionUtra
Object ENBEquipment/ Enb/ LteCell/ UtraNeighboring
Range & Unit Integer in second

[0..7] step = 1
Value N.A.
Feature L76498
mobility.
Warning: For a cell that has been already detected, but that has not been reselected to,
the filtering will be such that the UE will be capable of evaluating that an already identified
UTRA FDD cell has met reselection criterion, within (NUTRA_carrier) * [15,36 seconds]
when tReselectionUtra = 0as specified in table below (with Enb::defaultPagingCycle =
rf128 [Vol. 5]), provided that the reselection criteria is met by a margin of at least 6 dB. [TS
36.133]
NUTRA_carrier: number of carriers used for all UTRA FDD cells in the neighbor cell list.
DRX TdetectUTRA_FDD TmeasureUTRA_FDD TevaluateUTRA_FDD

cycle [s] [s] (number of DRX [s] (number of DRX
length cycles) cycles)
[s]
0.32 5.12 (16) 15.36 (48)
0.64 30 5.12 (8) 15.36 (24)
1.28 6.4(5) 19.2 (15)
2.56 60 7.68 (3) 23.04 (9)
Table 9: Measurements of UTRAN FDD cells selection [3GPP 36133].
Page 74/543
Volume 6 : Mobility
value by 2) Defined in TS 36.331 Broadcast in SystemInformationBlockType3. See
section 4.1.4.2.
Note: You cannot leave serving cell, if this one gets some reception level, greater
than threshServingLow.
Engineering Recommendation: threshServingLow
sNonIntraSearch, we can set threshServingLowat the same level than
sNonIntraSearch. i.e set threshServingLow to 16 dB.
• threshXHigh:TS36.331: this parameter configures the threshX-High included in the IE

CellReselectionConfUtraFdd::threshXHigh


[0..62] step = 2
Value 10
Feature L76498
Note: The value entered for CellReselectionConfUtraFdd::threshXHigh of a UTRA
frequency is divided by 2 before it is used to populate the field of threshX-High in SIB6. The
threshold value used by UE is the parameter value received from SIB6 multiplied by 2 in
unit of dB (same value entered for CellReselectionConfUtra::threshXHigh).
Note: This parameter is used in the Algorithm of cell selection and reselection towards an
iRAT cell which get priority greater than the LTE serving cell.
Keys for Hierarchy: ENBEquipment Enb LteCell UtraFddNeighboring
UtraFddNeighboringFreqConf CellReselectionConfUtraFdd
Note: Like we have chosen to favor LTE cell in our proposal implementation and that:
CellReselectionConfLte::cellReselectionPriority
>
CellReselectionConfUtraFdd::cellReselectionPriority
>
CellReselectionConfGERAN::cellReselectionPriority or
CellReselectionConfHrpd::cellReselectionPriority or
CellReselectionConf1xRtt:: cellReselectionPriority
Page 75/543
Volume 6 : Mobility
Then
threshXHighis not used because it does not exist iRAT cell with a greater priority than the
source cell.
• threshXHighQ:This parameter configures the IE threshX-HighQ included in IE
SystemInformationBlockType6 for reselection to UTRAN. See 3GPP 36.331.
CellReselectionConfUtraFdd::threshXHighQ
Parameter threshXHighQ


[0..31] step = 1
Value N.A.
Feature L114644.1
Note: Because we have chosen to favor LTE cell in our proposal implementation, for the
same reasons asthreshXHigh, threshXHighQis not used because it does not exist iRAT
cell with a greater priority than the source cell.
• threshXLow:TS36.331: this parameter configures the threshX-Low included in the IE
CellReselectionConfUtraFdd::threshXLow


[0..62] step = 2
Value 0
Feature L76498
Note: The value entered for CellReselectionConfUtraFdd::threshXLow of a UTRA Fdd
frequency is divided by 2 before it is used to populate the field of threshX-Low in SIB6. The
unit of dB (same value entered for CellReselectionConfUtra::threshXLow).
Note:If some selected cell reaches this threshold, when Sserving cell
<threshServingLow, then treselectionUtrais started.
For E-UTRAN, SnonServingCell,xis the Srxlev-value of an evaluated cell.
For Utra-Fdd, another S criterionis used in the Utra-Fdd cell reselection process; to
determine which UtraFdd cell(s) can be selected. S-criterion is divided into 2 sub-criteria:
Page 76/543
Volume 6 : Mobility
o SnonServingCell=Srxlev: it aims at checking the good level of reception in the cell
(measurement is based on CPICH_RSCP). If above a Rx minimum level, the UtraFdd
cell has a sufficient signal level.
o Squal:(refer to section 4.1.3.1.2) it aims at checking the good quality of the signal, it
means not to much interferences (measurement is based on CPICH_Ec/No). If above
a minimum quality level, the cell has a sufficient signal quality.
Finally, if both criteria are fulfilled (1) SnonServingCell=Srxlev>ThresX** and (2)
Squal>0 allows the UtraFdd cell to be selected
• threshXLowQ:This parameter configures the IE threshX-LowQ included in IE
SystemInformationBlockType6 for reselection to UTRAN. See 3GPP 36.331.
CellReselectionConfUtraFdd::threshXLowQ
Parameter threshXLowQ


[0..31] step = 1
Value N.A.
Feature L114644.1
RSRP 1 X = qrxlevminoffset = 0 if same PLMN

Qrxlevmin(SIB1) + X 2
+max[(pMax-Pumax), 0] + UE
sNonIntraSearch
Source Cell -104 dBm
sNonIntraSearch =
threshServingLow=16
t
CPICH RSCP treselectionUtra :2s 4
UE
Qrxlevmin(SIB6)+ X 3
+max[(pMaxUTRA-Pumax), 0]
+threshXLow
-115 dBm
-115+0
+max[(24-24), 0]
Target Cell +0 = -115 dBm t
CPICH Ec/Io
3
-16 dB
qQualMin
-16 dB
t
Chronologic state Cell Cell

Measures
of the target UMTS cell Selected Reselected
lower priority UTRAN cell.
Page 77/543
Volume 6 : Mobility
1 : Serving cell becomesworse and the RSRP level decreases under
[qRxlevmin(SIB1)+qRxlevminoffset+sNonIntraSearch]. Then cell detection of better
cell is possible twice more frequently in average towards all cells, and we can detect
and measured lower priority cells than the serving.
2 : Serving cell becomes worse and the RSRP level decrease under
[qRxlevmin(SIB1)+qRxlevminoffset+threshServingLow]. Cell reselection would be
possible, but not yet candidate cell, reaching [qRxlevmin(SIB6)+qRxlevminoffset
+Pcompensation+threshXLow] and [qQualmin]. In this user case, 1 and 2 occur at
the same time because we have chosen to implement sNonIntraSearch=
threshServingLow.
3 : The situation just above is still reached and also, in the target cell, thresholds
[qQxlevmin+qRxlevminoffset+Pcompensation+threshXLow] and [qQualmin] are
reached. tReselectionUTRA is started.
During tReselectionUTRA, NO higher cell priority reaches
[qRxlevmin+qRxlevminoffset+Pcompensation+threshXHigh]
4 : tReselectionUtrais achieved, reselection is triggered.
4.1.5.3.6 ALGORITHM FOR CELL RESELECTION PRIORITY
The presence and the content of IE freqPriorityListEUTRA depends on the attribute

CellReselectionConfUtraFddcellReselectionPriority; the priority of the carrierFreq
(thisis an optional parameter in the MiM).
The ENB call processing

o Retrieves from its UE context, the bandUtraFdd supported by the UE as specified by
[RRC] UE-EUTRA-Capability that are specified by SupportedBandUTRA-FDD
o Retrieves from attributes ENBEquipment Enb LteCell UtraFddNeighboring
UtraFddNeighboringFreqConf {bandUtraFdd; carrierFreq} the carrierFreq
supported by both the network and the UE
o Retrieves from attributes ENBEquipment Enb LteCell UtraFddNeighboringFreqConf
CellReselectoinConfUtraFdd cellReselectionPriority the priority of the
carrierFreq retrieved during (2.)
1. Case ENB triggers Blind Redirection to UTRA-FDD:

The eNB does not send the idleModeMobilityControlInfo. In this case if the redirection
fails and the UE comes back to idle then the UE relies on SiB6.
2. Case ENB triggers Measurement based Redirection To UTRA-FDD:

The eNBsends the idleModeMobilityControlInfo
The eNB will build the RRC IE
1>IdleModeMobilityControlInfo and
2>freqPriorityListUTRA-FDD
Page 78/543
Volume 6 : Mobility
- takes the MiM configuration as entered by the Operator in
UtraFddNeighboringFreqConf MO and.
- gives the highest priority to the UTRAN Freq or GERAN Freqs received
inMeasReport
- builds all the other priorities by following the order configured in
Duringt320, the UEwill follow the cell reselection priorities provided by

IdleModeMobilityControlInfo.
Aftert320, the UE will follow the SIB6 (and/or SIB7) (as specified by 36.304
section[36304-860] 5.2.4.1)
3. Optional sending of this IE idleModeMobilityControlInfo: depens on the presence of

optional configuration parameter "t320" (see definition of attribute ‘t320’)
• cellReselectionPriority:[36331]: this parameter contributes to the configuration of the

IE IdleModeMobilityControlInfofreqPriorityListUTRA-FDD (Optional). This attribute is
used by the Algorithm for RRC Measurement Configuration, and/or for Control
Procedure for Mobility (RAT chosen for the blind redirection).
CellReselectionConfUtraFdd::cellReselectionPriority


[0..7] step = 1
Value O.D.Refer to Engineering Recommendation below
Feature L76498
Note: The lowest priority is 0.
Engineering Recommendation: cellReselectionPriority

In general, LTE system is preferred over UTRAN and UTRAN is preferred over GERAN
for better performance. So it is recommended to set
CellReselectionConfLte::cellReselectionPriority >
CellReselectionConfUtraFdd::cellReselectionPriority >
CellReselectionConfGeran::cellReselectionPriority
Page 79/543
Volume 6 : Mobility
• bandUtraFdd:ENUMERATED {bandI, bandII, bandIII, bandIV, bandV,
bandVI,bandVII, bandVIII, bandIX, bandX, bandXI, bandXII, bandXIII, bandXIV,
bandXV, bandXVI,..} that is compared with the IE supportedBandUTRA-FDD of the IE
UE-EUTRA-Capability. TS36.331: the IE UE-EUTRA-Capability is used to convey the
E-UTRA UE Radio Access Capability Parameters, see TS 36.306, to the network. The
IE UE-EUTRA-Capability is transferred in E-UTRA or in another RAT.
UtraFddNeighboringFreqConf::bandUtraFdd
Parameter bandUtraFdd


[bandI, bandII, bandIII, bandIV, bandV, bandVI, bandVII, bandVIII,
bandIX, bandX, bandXI, bandXII, bandXIII, bandXIV, bandXV,
bandXVI]
Value O.D.
Feature L76498
• carrierFreq:The IE carrierFreq is used to indicate the ARFCN applicable for a

downlink (Nd, FDD) or bi-directional (Nt, TDD) UTRA carrier frequency, as defined in
TS 25.331. For example in TS36.331: this parameter configures the IE carrierFreq
included in the IE SystemInformationBlockType6
UtraFddNeighboringFreqConf::carrierFreq
Parameter carrierFreq


[0..16383] step = 1
Class/Source C – Immediate Propagation / customer_init
Value 0.D.
Feature L76498
Note: Inter-working with MeasObjectUTRA::carrierFreq:The value must be the same.
4.1.5.3.7 LTE TO UTRA FDD RESELECTION CONFIGURATION
For LTE to UTRA FDD Reselection to work properly, following feature activation flags and
MO must be configured:
• ActivationService::isMobilityToUtranAllowedis set to ‘True’.

• CellSelectionReselectionConf MO
Page 80/543
Volume 6 : Mobility
• UtraNeighboring MO
• UtraFddNeighboringFreqsConf MO
• CellReselectionConfUtraFdd MO
• UtraSpeedDeppendentConf MO
You must take care about interaction between WCDMA network and LTE network.
Following table show parameters matching together.
MIB 3G Parameter MIM 4G parameter

-> Or
<-
Parameters from 3G to be propagated on 4G
FDDCell.DlFrequencyNumber
-> UtraFddNeighboringFreqConf::carrierFreq
CellSelectionInfo.qQualMin
(path:RNC/NodeB/FDDCell/CellSele
-> CellReselectionConfUtraFdd::qQualMin
ctionInfo
CellSelectionInfo.qRxLevMin
-> CellReselectionConfUtraFdd::qRxLevMin
CellSelectionInfo.tReselection
-> UtraNeighboring::tReselectionUtra
PowerConfClass.SibMaxAllowedUlTx
PowerOnRach
->
CellReselectionConfUtraFdd::pMaxUTRA
Parameters from 4G to be propagated on 3G
FDDCell.eUtraTargetFrequencyQrxl
<- CellSelectionReselectionConf::qRxLevMin
evmin
No Parameters in UA8 WCDMA
Release
<- CellSelectionReselectionConf::qQualMin
(UE R9)
Table 10: Parameter to propagate between both WCDMA network and LTE network for
iRAT configuration.
4.1.6 INTER-RAT CELL RESELECTION TO GERAN

The feature L84807 provides basic mobility capability for UE moving from LTE radio
coverage to GERAN radio coverage. The benefit from the LTE-to-GERAN mobility in
RRC_IDLE is to allow a LTE/GERAN capable user to recover GERAN coverage, as soon
as it gets available, i.e. radio conditions are sufficiently good.
Page 81/543
Volume 6 : Mobility
GSM_Connected
CELL_DCH Handover E-UTRA Handover
RRC CONNECTED
GPRS Packet
transfer mode
CELL_FACH
Reselection CCO with
optional CCO,
CELL_PCH NACC Reselection
URA_PCH
Connection establishment/release establishment/release
establishment/release
Reselection E-UTRA Reselection GSM_Idle/GPRS

UTRA_Idle
RRC IDLE Packet_Idle
Reselection CCO, Reselection
Figure 18 : Reselection from eUTRAN to GERAN
Cell reselection E-UTRA-FDD to GERANis internal to the UE and controlled by system

information parameters provided in SystemInformationBlockType7 and
SystemInformationBlockType3. The UE applies inter-RAT cell reselection criteria as
described in 4.1.6.2.2 (3GPP 36.304). The UE selects a GERAN cell that fulfills criteria
defined in 4.1.6.2.5 (3GPP 36.304 section 5.2.4.5)
From eNodeB perspective, cell reselection to GERAN is supported with SIB7. Cell
reselection to GERAN is enhanced with SIB3 (RRC IE speedStateReselectionPars).
4.1.6.1 CELL RESELECTION ACTIVATION
ActivationService::isMobilityToGeranAllowed
Parameter isMobilityToGeranAllowed

[True, False]
Value False
Feature L96371
Notes: This parameter controls the activation/deactivation of feature L84807 and L96371.
The optional features are managed by Feature Licensing (refer to LPUG Volume 2 for
feature. The total number of activations for the features is counted across all eNBs by
SAM.
This parameter is to replace the two LA2.0 parameters,
isCellReselectionToGeranFddAllowed and isRedirectionToGeranAllowed.
The S criterion is again used to select the good cells for cell reselection, but with the
SIB7 parameters.
Page 82/543
Volume 6 : Mobility
SystemInformationBlockType7 field descriptions
carrierFreqsInfoList
Provides a list of neighboring GERAN carrier frequencies, which may be monitored for neighboring GERAN cells. The
GERAN carrier frequencies are organised in groups and the cell reselection parameters are provided per group of
GERAN carrier frequencies.
carrierFreqs
The list of GERAN carrier frequencies organised into one group of GERAN carrier frequencies.
commonInfo
Defines the set of cell reselection parameters for the group of GERAN carrier frequencies.
t-ReselectionGERAN
Parameter “TreselectionGERAN” in TS 36.304.
t-ReselectionGERAN-SF
Parameter “Speed dependent ScalingFactor for TreselectionGERAN” in TS 36.304 [4]. If the field is not present, the UE
behaviour is specified in TS 36.304 .
ncc-Permitted
Field encoded as a bit map, where bit N is set to "0" if a BCCH carrier with NCC = N-1 is not permitted for monitoring
and set to "1" if the BCCH carrier with NCC = N-1 is permitted for monitoring; N = 1 to 8; bit 1 of the bitmap is the
leading bit of the bit string.
q-RxLevMin
Parameter “Qrxlevmin” in TS 45.008. The actual value of Qrxlevmin in dBm = (IE value * 2) − 115.
p-MaxGERAN
Maximum allowed transmission power for GERAN on an uplink carrier frequency, see TS 45.008 [28]. Value in dBm.
Applicable for the neighboring GERAN cells on this carrier frequency. If pmaxGERANis absent, the maximum power
according to the UE capability is used.
threshX-High
Parameter "Threshx,high" in TS 36.304.
threshX-Low
Parameter "Threshx,low" in TS 36.304.
4.1.6.2.1 CELL SELECTION CRITERION ON SERVING CELL
Prerequisites on serving cell are based on SIB3 and SIB1 parameters.
The UE will measure the signal level of the GSM BCCH carriers if the GSM BCCH carriers
are indicated in the measurement control system information of the serving cell.

UE will search for GSM BCCH carriers of higher priority at least every
Thigher_priority_search.
If SServingCell ≤ sNonIntraSearch then the UE will search for and measure GSM
BCCH carriers of higher and lower priority in preparation for possible reselection. The
UE will measure signal level of the GSM BCCH carriers at least every Tmeasure,GSM
for identified lower or higher priority GSM BCCH carriers.
If Srxlev >sNonIntraSearchPand Squal >sNonIntraSearchQ then the UE will search

for GSM BCCH carriers of higher priority at least every Thigher_priority_search

for and measure GSM BCCH carriers of higher and lower priority in preparation for
possible reselection. The UE will measure signal level of the GSM BCCH carriers at
least every Tmeasure,GSMfor identified lower and higher priority GSM BCCH carriers.
Page 83/543
Volume 6 : Mobility
RSRP
S-ServingCell at least every (60 * Nlayers) sec. at least every (30) sec.
Tmeasure,GSM
Qrxlevmin(SIB1) +
Pcompensation +
sNonIntraSearchP Min. Detect = (60* Nlayers) s.
Min. Detect = 30s
Min. Measurements = 6,4 s.
•t
Figure 19 : Start of measurements for inter-RAT GSM reselection if serving cell is degraded
under a RSRP threshold
Note: Tmeasure,GSM value are in inter-working with Enb::defaultPagingCycle value.
RSRQ
S-ServingCell at least every (60 * Nlayers) sec. at least every (30) sec.
Tmeasure,GSM
Qqualmin(SIB1) +
sNonIntraSearchQ
Min. Detect = (60* Nlayers) s.
Min. Detect = 30s
Min. Measurements = 6,4 s.
•t
Figure 20 : Start of measurements for inter-RAT GSM reselection if serving cell is degraded
under a RSRQ threshold
Note: The UE shall not consider the GSM BCCH carrier in cell reselection, if the UE cannot
demodulate the BSIC of that GSM BCCH carrier. Additionally, the UE shall not consider a
GSM neighbour cell in cell reselection, if it is indicated as not allowed in the measurement
control system information of the serving cell.
Rule: To limit GERAN Measurements

The GERAN carrier frequencies are organised in groups and the cell reselection
parameters are provided per group of GERAN carrier frequencies.
In order to further restrict the amount of measurement carried out by the UE in
RRC-Idle mode, The UE shall apply the following rules for inter-RAT Geran groups
of frequencies, which are indicated in SystemInformationBlockType7 and for
which the UE has cellReselectionPriority:
For inter-RAT Geran groups of frequencies, with a cellReselectionPriority higher
than the cellReselectionPriority of the current E-UTRA frequency, the UE shall
perform measurements of higher priority inter-RAT Geran groups of
frequencies.
For inter-RAT Geran groups of frequencies, with cellReselectionPrioritylower
than the cellReselectionPriority of the current E-UTRAN frequency:
Snonintrasearch : This parameter specifies the threshold (in dB) for inter frequency and
inter-RAT measurements. configuration parameter name issNonIntrasearch for R8
UE andsNonIntrasearchP or sNonIntrasearchQ for R9 UE capable.
For R8 UE, If SServingCell >Snonintrasearch, UE may choose not to perform
measurements of inter-RAT frequency cells of lowercellReselectionPriority
For R9 UE, If SServingCell >sNonIntrasearchP and SServingCell
Page 84/543
Volume 6 : Mobility
>sNonIntrasearchQ, UE may choose not to perform measurements of inter-
RAT frequency cells of lowercellReselectionPriority.
For R8 and R9 UE, If SServingCell<= Snonintrasearch, or if sNonIntrasearch or
sNonIntrasearchP or sNonIntrasearchQis not sent in
SystemInformationBlockType3 in the serving cell, The UE shall perform
measurements of inter-RAT frequency cells of
lowercellReselectionPriority
• sNonIntraSearch:Refer to section 4.1.5.3.1.Threshold for serving cell reception level

under which the UE shall trigger inter-frequency and inter-RAT measurements for
cell reselection.The value sent over the RRC interface is half the value configured
(the UE then multiplies the received value by 2). For more details consult
TS36.304. Defined in TS 36.331. Broadcast in SystemInformationBlockType3
• cellReselectionPriority: Relative priority for cell reselection (0 means lowest

priority). Defined in TS 36.331. Broadcast in SystemInformationBlockType3
Engineering Rule: cellReselectionPriority

0 is the current default value.
Warning: in relationship withcellReselectionPriority withinHrpdBandClassInfo MO.
Refer to section 4.1.7.1.
Cannot be equal to HrpdBandClassInfo::cellReselectionPriority
4.1.6.2.2 CELL SELECTION CRITERION ON TARGETS CELLS

The cell selection criterion S (Calculated by the UE) is fulfilled when:
Srxlev > 0
Where:
Srxlev = Qrxlevmeas – (Qrxlevmin + Qrxlevminoffset) - Pcompensation
Where:
The signalled value QrxlevminOffsetis only applied when a cell is evaluated for cell
Page 85/543
Volume 6 : Mobility
Srxlev Calclated by Cell Selection RX level value (dB).
the UE
Qrxlevmeas Measured by Measured cell RX level value (RSRP).
the UE
Qrxlevmin CellReselection Minimum required RX level in the cell (dBm).

ConfGERAN::q Broadcasted in SIB 7
RxLevMin
Qrxlevmino CellSelectionR Offset to the signalled Qrxlevmin taken into account in the
ffset eselectionConf Srxlev evaluation as a result of a periodic search for a
::qRxlevminoff higher priority PLMN while camped normally in a
set VPLMN [R17].
Broadcasted inSIB1
Pcompe 0 if E-UTRA cell, max(Pemax – Pumax, 0) (dB).
nsation Calculated by
the UE for
GERAN cell
Pemax Inhibited if E- Maximum TX power level an UE may use when
UTRA cell, transmitting on the uplink in the cell (dBm) defined as
CellReselection MS_TXPWR_MAX_CCHin [3GPP TS 45.008].
ConfGERAN::p
MaxGeran for
GERAN cell
Pumax The value is Maximum RF output power of the UE (dBm) according
different for DCS to the UE power class as defined in [3GPP TS 45.005,
bands and GSM section 4.1.1].
bands
When camped normally, the UE shall perform the following tasks [R16]:
o select and monitor the indicated Paging Channels of the cell according to information
sent in system information;
o monitor relevant System Information;
o perform necessary measurements for the cell reselection evaluation procedure;
o execute the cell reselection evaluation process on the following occasions/triggers:
- UE internal triggers;
- When information on the BCCH used for the cell reselection
evaluation procedure has been modified.
Page 86/543
Volume 6 : Mobility
• qRxLevMin :3GPP 36.331[R10] Minimum required RX level in the GERAN cell
(dBm).This parameter configures the IE q-RxLevMin included in IE
SystemInformationBlockType7.The value sent over the RRC interface is computed by
adding 115 to the configured value and dividing by 2 (the UE performs the opposite
computation, i.e. IE vale * 2 -115) TS 45.008
CellReselectionConfGERAN::qRxLevMin
Parameter qRxLevMin
Object ENBEquipment/ Enb/ LteCell/ GeranNeighboring/

GeranNeighboringFreqsConf/ CellReselectionConfGERAN

[-115..-25] step = 2
Value -115
Feature L84807
Parameter qRxLevMin in TS 45.008. Actual value Qrxlevmin = IE value * 2-115 [dBm].
Specifies the minimum required Rx RSRP level in the cell. (Where IE specify the DLU
database value)
Changing this value will affect cell size in terms of re-selection area toward GERAN.
Increasing this value will lead the mobile to start cell-selection/re-selection procedure
sooner and then will artificially decrease cell size in idle mode.
Rule: qRxlevminoffset MO CellSelectionReselectionConf
The same Offset used for inter-LTE mobility is used whatever is the target cell,
indeed the qRxlevminoffset parameter is unique in the database.
• pMaxGeran :TS36.331: this parameter configures the p-MaxGERAN included in the

IE SystemInformationBlockType7
CellReselectionConfGERAN::pMaxGeran
Parameter pMaxGeran


[0..39] step = 1
Value 3
Feature L84807
Pcompensation is a compensation factor to penalize the low power mobiles.
Page 87/543
Volume 6 : Mobility
Where:
PEMAX = pMaxGERAN
Operating Band Power (dBm)

II DCS 1900 MHz +30
III DCS 1800 MHz +30
VIII GSM 900 MHz +33
Table 12: Maximum TX power level an UE may use when transmitting on the uplink in the
cell (dBm).
operating band. [3GPP 45005, section 4.1.1]
Power (dBm)
Operating Band
II DCS 1900 MHz +30 +24 +33 N.A
III DCS 1800 MHz +30 +24 +36 N.A
VIII GSM 900 MHz N.A +39 +37 +33
GSM 850 MHz N.A +39 +37 +33
GSM 700 MHz N.A +39 +37 +33
GSM 400 MHz N.A +39 +37 +33
Table 13: UE power Class vs. maximum output power, Pumax.
Page 88/543
Volume 6 : Mobility
• nccPermitted:This parameter configures the IE ncc-Permitted included in IE
SystemInformationBlockType7. (3GPP 44060: NCC_Permitted)
CellReselectionConfGERAN::nccPermitted
Parameter nccPermitted


stringLength = 8
Value 11111111
Feature L84807
Note: nccPermitted is specific to inter-RAT GERAN management. This field is a bitmap of
NCCs for which the mobile station is permitted to report measurement; this bitmap relates
to NCC part of BSIC.This parameter not existing for inter-RAT UMTS Management.
4.1.6.2.3 CELL RESELECTION PRIORITIES HANDLING
Absolute priorities of different E-UTRAN frequencies ([R16] in 5.2.4.1) or inter-RAT

frequencies may be provided to the UE with different way.
4.1.6.2.4 UE SPEED MANAGEMENT
SIB3 parameters and algorithms working to speed state measurements configuration in

case of intra-LTE mobility, work also to speed state measurements configuration in case of
GERAN inter-RAT mobility, except parameters in the MO object GeranSpeedConf
andtReselectionGERAN, which are specific: Then you can report to section 4.1.6.2.5with
this latest restriction.
• tEvaluation:TS36.331: this parameter contributes to the configuration of the
SystemInformationBlockType3. This parameter configures the IE t-Evaluation
included in the IE MobilityStateParameters. The duration for evaluating criteria to
enter mobility states. Corresponds to TCRmax in TS 36.304. Value in seconds, s30
corresponds to 30 s and so on.
• nCellChangeHigh: TS36.331: this parameter contributes to the configuration of the
SystemInformationBlockType3. This parameter configures the IE n-CellChangeHigh
included in the IE MobilityStateParameters. The number of cell changes to enter high
mobility state. Corresponds to NCR_H in TS 36.304.
• nCellChangeMedium:TS36.331: this parameter contributes to the configuration of the
SystemInformationBlockType3. This parameter configures the IE n-
CellChangeMedium included in the IE MobilityStateParameters. The number of cell
changes to enter medium mobility state. Corresponds to NCR_M in TS 36.304.
• tHystNormal:TS36.331: this parameter contributes to the configuration of the
SystemInformationBlockType3. This parameter configures the IE t-HystNormal
included in the IE MobilityStateParameters. The additional duration for evaluating
criteria to enter normal mobility state. Corresponds to TCRmaxHyst in TS 36.304.
Value in seconds, s30 corresponds to 30 s and so on.
Scaling rules:
Page 89/543
Volume 6 : Mobility
The cell ranking procedure is the same as insection 4.1.3.1.2but with variable values for
- AddqHystSfHigh to Qhyst for high mobility state if sent on system information.
- For GERAN cellsmultiplytReselectionGERAN by tReselectionGERANSfHigh if


- AddqHystSfMedium to Qhyst for medium mobility state, if sent on system
information.
- For GERAN cells multiplytReselectionGERAN by

tReselectionGERANSfMedium, if sent on system information.
In case scaling is applied to any TreselectionRAT parameter the UE shall round up the
result after all scalings to the nearest second.
• qHystSfHigh:TS36.331: this parameter contributes to the configuration of the IE

SystemInformationBlockType3.This parameter configures the IE sf-High included in
the IE SpeedStateReselectionPars. Parameter “Speed dependent ScalingFactor for
Qhyst” in TS 36.304. The sf-High concerns the additional hysteresis to be applied,
in High Mobility state, to Qhyst as defined in TS 36.304. In dB. Value dB-6
corresponds to -6dB, dB-4 corresponds to -4dB and so on.
This parameter is an environment dependent parameter. This parameter configures the
hysteresis value of the serving cell used by the UE for ranking criteria in cell reselection.
Decreasing qHystSfHigh leads to do cell-reselection earlier
Page 90/543
Volume 6 : Mobility
• tReselectionGERANSfHigh :TS36.331v850: this parameter contributes to the
configuration of the IE SystemInformationBlockType7 ifthe UEis in High Mobility
state. TS36.331v850: this parameter configures the t-ReselectionGERAN-SF included
in the IE SystemInformationBlockType7. The concerned mobility control related
parameter ismultiplied with this factor if the UEis in High Mobility state as defined
in TS 36.304. Value oDot25 corresponds to 0.25, oDot5 corresponds to 0.5 , oDot75
corresponds to 0.75 and so on.
GeranSpeedDependentConf::tReselectionGERANSfHigh
Parameter tReselectionGERANSfHigh

GeranSpeedDependentConf

Value N.A.
Feature L84807
This parameter avoid ping pong radio phenomena during the RA-Update & idle
mobility.
• qHystSfMedium:TS36.331: this parameter contributes to the configuration of the IE
SystemInformationBlockType3.This parameter configures the IE sf-Medium included
in the IE SpeedStateReselectionPars. Parameter “Speed dependent ScalingFactor for
Qhyst” in TS 36.304. The sf-Medium concerns the additional hysteresis to be
applied, in Medium Mobility state, to Qhystin dB. Value dB-6 corresponds to -6dB,
dB-4 corresponds to -4dB and so on.
Decreasing qHystSfMedium leads to do cell-reselection earlier
Page 91/543
Volume 6 : Mobility
• tReselectionGERANSfMedium :TS36.331v850: this parameter contributes to the
configuration of the IE SystemInformationBlockType7 ifthe UEis in High Mobility
state. TS36.331v850: this parameter configures the t-ReselectionGERAN-SF included
in the IE SystemInformationBlockType7. The concerned mobility control related
parameter ismultiplied with this factor if the UEis in Medium Mobility state as
defined in TS 36.304. Value oDot25 corresponds to 0.25, oDot5 corresponds to 0.5,
oDot75 corresponds to 0.75 and so on.
GeranSpeedDependentConf::tReselectionGERANSfMedium
Parameter tReselectionGERANSfMedium

GeranSpeedDependentConf

Value N.A.
Feature L84807
mobility.
4.1.6.2.5 E-UTRAN INTER-FREQUENCY AND INTER-RAT CELL
RESELECTION CRITERIA
Criteria 1b :
For GERAN and HRPD cell, Srxlevis the Srxlev-value of an evaluated target cell. Please
refer to section 4.1.3.1.1to know what is Srxlev.
Rule: tReselectionRAT matching with the type of mobility

tReselectionRAT : This specifies the cell reselection timer value. For each target
frequency/frequency group per RAT a specific value for the cell reselection timer is
defined, which is applicable when evaluating reselection within E-UTRAN or towards
other RAT (i.e. tReselectionRAT for E-UTRAN istReselectionEUTRAN, for UTRAN
tReselectionUtra, for GERAN tReselectionGERAN, for HRPD
tReselectionCdmaHrpd, and for tReselectionCdma1xRtt).
Note: tReselectionRATis not sent on system information, but used in reselection
rules by the UE for each RAT.
• Cell reselection to a cell on a higher priority GERAN frequency or HRPD frequency

Page 92/543
Volume 6 : Mobility
- A cell of a higher priority GERAN frequency or HRPD frequency fulfils criteria
1b
With tReselectionRAT = tReselectionGERAN or tReselectionCdmaHrpd or
tReselectionCdma1xRtt
• Cell reselection to a cell on a lower priority GERAN frequency or HRPD frequency

If threshServingLowQis provided in SIB3:
- No cell on a higher priority GERAN frequency or HRPD frequency than serving
frequency fulfills the criteria 1b
- And the Srxlev of a cell of a lower priority GERAN frequency or HRPD
frequency >threshXLow during a time interval tReselectionRAT
(tReselectionGERAN or tReselectionCdmaHrpd or tReselectionCdma1xRtt)
If threshServingLowQis not provided in SIB3:
- No cell on a higher priority GERAN frequency or HRPD frequency than serving
frequency fulfills the criteria 1b
- And the Srxlev of a cell of a lower priority GERAN frequency or HRPD
frequency >threshXLow during a time interval tReselectionRAT
(tReselectionGERAN or tReselectionCdmaHrpd)
Cell reselection to a cell on an equal priority E-UTRAN frequency will be based on

ranking for Intra-frequency Cell Reselection as defined in section 4.1.3.1.2or in [R16]
section 5.2.4.6.
In all the above criteria the value of tReselectionRATisscaled when the UEis in the
medium or high mobility state as defined in section 4.1.5.3.4or in subclause [R16]
5.2.4.3.1.
If more than one cell meets the above criteria, the UE shall reselect a cell as follows:
- If the highest-priority frequency is an E-UTRAN frequency, a cell ranked as the best
cell among the cells on the highest priority frequency(ies) meeting the criteria according to
section4.1.3.1.2or in [R16] section 5.2.4.6;
- If the highest-priority frequency is from another RAT, a cell ranked as the best cell
among the cells on the highest priority frequency(ies) meeting the criteria of that RAT.
SqualservingCell is the Squal value of the serving cell based on Squal described and
available to section 4.1.3.1.2.
SrxlevservingCell is the Srxlev value of the serving cell based on Srxlev described and
availableto section 4.1.3.1.2.
Page 93/543
Volume 6 : Mobility
• tReselectionGERAN :This parameter configures the t-ReselectionGERAN included in
the IE SystemInformationBlockType7
GeranNeighboring::tReselectionGERAN
Parameter tReselectionGERAN
Object ENBEquipment/ Enb/ LteCell/ GeranNeighboring

[0..7] step = 1
Value 2
Feature L84807
mobility.

value by 2) Defined in TS 36.331 Broadcast in SystemInformationBlockType3
• threshXHigh:TS36.331: this parameter configures the threshX-High included in the IE
CellReselectionConfGERAN::threshXHigh


[0..62] step = 2
Value 10
Feature L84807
Note: The value entered for CellReselectionConfGERAN::threshXHigh of a GERAN
frequency is divided by 2 before it is used to populate the field of threshX-High in SIB7. The
unit of dB (same value entered for CellReselectionConfGERAN::threshXHigh).
Page 94/543
Volume 6 : Mobility
• threshXLow:TS36.331: this parameter configures the threshX-Low included in the IE
CellReselectionConfGERAN::threshXLow
Object Enb/ LteCell/ GeranNeighboring/ GeranNeighboringFreqsConf/

CellReselectionConfGERAN

[0..62] step = 2
Value 0
Feature L84807
Note: The value entered for CellReselectionConfGERAN::threshXLow of a GERAN
frequency is divided by 2 before it is used to populate the field of threshX-Low in SIB7. The
unit of dB (same value entered for CellReselectionConfGERAN::threshXLow).
For GERAN, SnonServingCell,xis the Srxlev-value of an evaluated cell.

Note:If some selected cell reach this threshold, when Sserving cell <threshServingLow,
then treselectionGERANis start.
RSRP X = qrxlevminoffset = 0 if same PLMN

Qrxlevmin(SIB1) + X 1
+max[(pMax-Pumax), 0] +
2 UE
sNonIntraSearch
Source Cell -104 dBm
sNonIntraSearch =
threshServingLow=16
t
RSSI treselectionGERAN: 2s UE
Qrxlevmin(SIB7) + X
Target +max[(pMaxGeran-Pumax), 0] 3 4
+threshXLow
GERAN Cell
-102+0 -102dBm
2g +max[(37-39), 0]
+0 = -102 dBm t
CPICH RSCP
WCDMA Cell. Qrxlevmin + X -115 dBm
Priority between +max[(pMaxUTRA-Pumax), 0] 3
Source Cell +threshXLow
and GERAN Cell
-115+0
+max[(24-24), 0]
3g +0 = -115 dBm t
Chronologic state Cell Cell

Measures
of the target GERAN cell Selected Reselected
Figure 21 : User Case, with UE Class3 and in the same PLMN,

showing reselection towards lower priority GERAN cell.
Page 95/543
Volume 6 : Mobility
1 : Serving cell become less good and the RSRP level decrease under
[Qrxlevmin(SIB1)+Qrxlevminoffset +max[(pMax-Pumax), 0]+sNonIntraSearch]. Then
cell detection of better cell is possible twice more frequently in average towards all
cells, and we can detect and measured lower priority cells than the serving.
2 : Serving cell becomes worse and the RSRP level decrease under
[Qrxlevmin(SIB1)+Qrxlevminoffset+ max[(pMax-Pumax), 0+ threshServingLow]. Cell
reselection would be possible, but not yet candidate cell, not reaching
[Qrxlevmin(SIB7)+Qrxlevminoffset
+Pcompensation+threshXLow]. In this user case 1 and 2 occur at the same time
because we have chosen to implement sNonIntraSearch= threshServingLow.
3 : The situation just above is still reached and also, in the target cell, threshold
[Qrxlevmin+Qrxlevminoffset+Pcompensation+threshXLow] is reached.
tReselectionGERANis started.
During tReselectionGERAN, NO higher cell priority reaches
[Qrxlevmin(SIB6(or7))+Qrxlevminoffset+Pcompensation+threshXLow]
4 : tReselectionGERAN is achieved, reselection is triggered.
4.1.6.2.6 ALGORITHM FOR CELL RESELECTION PRIORITY
The eNodeB CallP may send IE freqPriorityListGERAN in IdleModeMobilityControlInfo

of RRCConnectionRelease. IE freqPriorityListGERAN specifies the reselection priority
for each group of GERAN carrier frequencies.
The content of IE freqPriorityListGERAN depends on:

• UE capability: supported GERAN bands as indicated in [RRC] UE-EUTRA-Capability as
specified in SupportedBandGERAN.
• GERANNeigboringFreqsConf {bandGERAN, GERANarfcnList}
• LteCell GERANNeigboring CellReselectionConfGERANcellReselectionPriority for
the group of GERAN carrier frequencies.
In order to fill the IE freqPriorityListGERAN of IE IdleModeMobilityControlInfo,eNodeB

CallP processing is as follow:
− ENodeB CallP retrieves the GERANNeigbouringFreqsConf instances
for the bandGERAN supported by the UE.
− ENodeB CallP retrieves the corresponding priorityOfFreqs from the
instance.
2. Case eNB triggers a Measurement based Redirection To UTRA-FDD

The eNBsends the idleModeMobilityControlInfo
The eNB will builds the RRC IE
1>IdleModeMobilityControlInfo and 2>freqPriorityListGERAN and
2>freqPriorityListUTRA-FDD
- takes the MiM configuration as entered by the Operator in
UtraFddNeighboringFreqConf MO and GeranNeighboringFreqsConf MO.
- gives the highest priority to the UTRAN Freq or GERAN Freqs received
inMeasReport
- builds all the other priorities by following the order configured in
UtraFddNeighboringFreqConf and GeranNeighboringFreqsConf
Page 96/543
Volume 6 : Mobility
Duringt320, the UEwill follow the cell reselection priorities provided by

IdleModeMobilityControlInfo.
Aftert320, the UE will follow the SIB6 and SIB7 (as specified by 36.304 section[36304-
860] 5.2.4.1)
3. Case eNB triggers a Measurement based Redirection To GERAN:

Like ‘2. Case Meas-Redirection-To-UTRA-FDD’
4. Optional sending of this IE idleModeMobilityControlInfo: depens on the presence of

optional configuration parameter "t320" (see definition of attribute ‘t320’)
• cellReselectionPriority:[36331]: this parameter contributes to the configuration of the

IE IdleModeMobilityControlInfo: freqPriorityListGERAN (Optional). This attribute is
used by the Algorithm for RRC Measurement Configuration, and/or for Control
Procedure for Mobility (RAT chosen for the blind redirection).
CellReselectionConfGERAN::cellReselectionPriority
Object ENBEquipment/ Enb/LteCell/GeranNeighboring/


[0..7] step = 1
Class/Source C – Immediate Propagation/ customer_settable
Value N.A.
Feature L84807
Note: The lowest priority is 0, the proposal setting is 2 for this parameter.
• GeranARFCNList:This attribute corresponds to a list of GERANARFCN
GeranNeighboringFreqsConf::GeranARFCNList
Parameter GeranARFCNList
Object ENBEquipment/Enb/ LteCell/ GeranNeighboring/

GeranNeighboringFreqsConf

[0..1023] step = 1
ListSizeMin = 1
ListSizeMax = 32
Value O.D.
Feature L84807
Page 97/543
Volume 6 : Mobility
• bandGERAN:This indicates the GERAN band for the ARFCNlist.
GeranNeighboringFreqsConf::bandGERAN
Parameter bandGERAN
Object ENBEquipment/Enb/ LteCell/ GeranNeighboring/

GeranNeighboringFreqsConf

[gsm450, gsm480, gsm710, gsm750, gsm810, gsm850, gsm900P,
gsm900E, gsm900R, gsm1800, gsm1900]
Value O.D.
Feature L84807
Note: The parameter bandGERAN is used for UE caps checking. Callp use bandGERAN
to fill the RRC messages.
4.1.6.2.7 LTE TO GERAN RESELECTION CONFIGURATION
For LTE to UTRA FDD Reselection to work properly, following feature activation flags and
MO must be configured:
• ActivationService::isMobilityToGERANAllowedis set to ‘True’.

• CellSelectionReselectionConf MO
• GeranNeighboring MO
• GeranNeighboringFreqsConf MO
• CellReselectionConfGERAN MO
• GeranSpeedDeppendentConf MO
4.1.7 INTER-RAT CELL RESELECTION TO HRPD OR 1XRTT

If a LTE cell is in the border area of the HRPD or 1xRTT system,
SystemInformationBlockType8 (SIB8) should be broadcasted in addition to SIB3 for UE to
perform LTE to HRPD or 1xRTT reselection.
SIB8 contains the following optional information blocks:
• systemTimeInfo
• searchWindowSize
• parametersHRPD
• parameters1XRTT
Whether eNB will broadcast SIB8 and which information blocks will be included in the
message depending on the provisioning of the following parameters:
• To include searchWindowSize in SIB8, LteCell::searchWindowSizeSIB8 must be

provisioned.
Page 98/543
Volume 6 : Mobility
• To include systemTimeInfo in SIB8, LteCell::searchWindowSizeSIB8 must be
provisioned andActivationService::isSynchCdmaSystemTimeAllowed must be
set to ‘true’.
• To include parametersHRPD in SIB8, HrpdNeighboring::hrpdInfoConfigured
must be set to ‘true’.
• To include parameters1xRTT in SIB8,
OneXRttNeighboring::oneXRttInfoConfigured must be set to ‘true’.
LteCell::searchWindowSizeSIB8
Parameter searchWindowSizeSIB8

[0, 15] step=1
Value unset
Feature L82728
Notes: Search window size (common for HRPD & 1xRTT) is a CDMA2000 parameter to be used to
assist UE in searching for the neighboring CDMA pilots to perform LTE to HPRD mobility
including cell reselection, redirection, or to perform LTE to 1xRTT cell reselection.
Rule: searchWindowSizeSIB8
To include searchWindowSize in SIB8, this parameter must be provisioned. The
recommended value is 8 (60 PN chips).
In the field where LTE to HRPD or LTE to 1xRTT mobility is not activated (SIB8 is not to
be broadcasted), this parameter must be unset. LTE to HRPD or LTE to 1xRTT mobility
cannot be activated if either LTE to UTRAN mobility feature or LTE to GERAN mobility
feature is activated.
ActivationService::isSynchCDMASystemTimeAllowed
Parameter isSynchCDMASystemTimeAllowed

[False, True]
Value False
Feature L84876
Rule: isSynchCDMASystemTimeAllowed
To include systemTimeInfo in SIB8, this parameter must be set to ‘True’. This
Page 99/543
Volume 6 : Mobility
parameter can be set to ‘True’ only if all of the following requirements are met:
• LteCell::searchWindowSizeSIB8is provisioned.
• ClockSync::GpsTime::CdmaPhaseSync MO is created. Refer to Volume
9 of LPUG for CdmaPhaseSync::availabilityStatus and
CdmaPhaseSync::operationalState. systemTimeInfo is included in SIB8
only if GpsTime::availabilityStatus (read only) is empty,
GpsTime::operationalState (read only) is ‘Enabled’,
CdmaPhaseSync::availabilityStatus (read only) is empty, and
CdmaPhaseSync::operationalState (read only) is ‘Enabled’.
• ClockSync::sfnSyncOptionis set to ‘FreqAndPhaseSyncEnabled’ or
‘FreqandPhaseAndTimeOfDaySyncEnabled’. Refer to Transport
Engineering Guide (TEG) [R01] for the parameter.
• ClockSync::clockSyncSourcePriorityListis set to {‘gps-synchronised-

gps’, ‘free-running-internal-oscillator’}. Refer to Transport Engineering
Guide (TEG) [R01] for the parameter.
• ClockSync::gpsClockEnable is set to‘True’.
HrpdNeighboring::hrpdInfoConfigured
Parameter hrpdInfoConfigured
Object ENBEquipment/ Enb/ LteCell/ HrpdNeighboring

[false, true]
Value False
Feature L82728
Rule: hrpdInfoConfigured
To include parametersHRPD in SIB8, this parameter must be set to ‘True’. This

parameter can be set to ‘True’ if at least one HrpdNeighboringPerCarrier MO
under HrpdNeighboringis configured.
Page 100/543
Volume 6 : Mobility
OneXRttNeighboring::oneXRttInfoConfigured
Parameter oneXRttInfoConfigured
Object ENBEquipment/ Enb/ LteCell/ OneXRttNeighboring

[false, true]
Value False
Feature L76499.1
Rule: oneXRttInfoConfigured
To include parameters1XRTT in SIB8, this parameter must be set to ‘True’. This

parameter can be set to ‘True’ if at least one OneXRttNeighboringPerCarrier MO
under OneXRttNeighboring is configured.
4.1.7.1 HRPD CELL RESELECTION PARAMETERS IN SIB8

HRPD Cell reselection parameters to be broadcasted in SIB8 include:
• Parameters applied to all HRPD neighbors

o HrpdNeighboring::tReselectionCdmaHrpd
• Parameters applied to HRPD neighbors in the same band class:
o CellReselectionConfHrpd::cellReselectionPriority
o CellReselectionConfHrpd::threshXHigh
o CellReselectionConfHrpd::threshXLow
CellReselectionConfHrpd::cellReselectionPriorityis used to determine the relative

priorities between a HRPD frequency and the EUTRAN serving frequency
(CellReselectionConfLte::cellReselectionPriority of serving frequency). Cell reselection
priorities of different RAT cannot be set to the same value. If a HRPD frequency has higher
priority than the EUTRAN serving frequency, all the HRPD neighbor cells under the HRPD
frequency have higher priority than the EUTRAN serving cell, or vice versa.
The reselection parameters are used in measurement rules and HRPD cell reselection
criteria below.
UE measurement rules for cell reselection:
A. If a HRPD frequency has higher priority than the serving frequency

(CellReselectionConfHrpd::cellReselectionPriority of the HRPD frequency
>CellReselectionConfLte::cellReselectionPriority of serving frequency), UE is
required to perform measurements on the HRPD frequency to determine if
reselection to the frequency should be performed.
B. If a HRPD frequency has lower priority than the serving frequency
(CellReselectionConfHrpd::cellReselectionPriority of the HRPD frequency
<CellReselectionConfLte::cellReselectionPriority of serving frequency),
whether UE is required to perform measurements on the HRPD frequency
depends on how good the signal on serving cell is:
• For Rel-8 UE:
Page 101/543
Volume 6 : Mobility
o If serving cell fulfills Srxlev > sNonIntraSearch, UE may choose not to
perform measurements of the lower priority HRPD frequency
o Otherwise, UE is required to perform measurements of the lower
priority HRPD frequency
• For Rel-9 UE:
o If serving cell fulfills Srxlev > sNonIntraSearchP and Squal >
sNonIntraSearchQ, UE may choose not to perform measurements of
the lower priority HRPD frequency.
priority HRPD frequency
Where
• sNonIntraSearch = CellSelectionReselectionConf::sNonIntraSearch if it is
provisioned. Otherwise, sNonIntraSearch = infinity
• sNonIntraSearchP = CellSelectionReselectionConf::sNonIntraSearchP if it
is provisioned. If itis not provisioned but
CellSelectionReselectionConf::sNonIntraSearch is provisioned,
sNonIntraSearchP = CellSelectionReselectionConf::sNonIntraSearch.
Otherwise, if neither CellSelectionReselectionConf::sNonIntraSearchP nor
sNonIntraSearchP = infinity
• sNonIntraSearchQ = CellSelectionReselectionConf::sNonIntraSearchQ if it
is provisioned. Otherwise, sNonIntraSearchQ = 0
HRPD cell reselection criteria:
A. Cell reselection to a higher priority EUTRAN inter-frequency neighbor cell or a

higher priority HRPD neighbor cell will be performed:
• Refer to section 4.1.4.2for criteria to reselect a higher priority EUTRAN inter-

frequency neighbor cell
• If S nonServingCell > 2 x CellReselectionConfHrpd::threshXHigh during a time
interval HrpdNeighboring::tReselectionCdmaHrpd
• More than 1 second has elapsed since the UE camped on the current serving
cell
B. Cell reselection to a lower priority EUTRAN inter-frequency neighbor cell or a lower

priority HRPD neighbor cell will be performed if all of the following conditions are true:
• No higher priority inter-frequency EUTRAN neighbor cell or higher priority

HRPD neighbor cell that meet the criteria as in A
• No cell on serving frequency or on the same priority inter-frequency can be
selected that meet the criteria as specified in section4.1.4.2.
• Refer to section 4.1.4.2for criteria to reselect a lower priority EUTRAN inter-
• S ServingCell <CellSelectionReselectionConf::threshServingLow
and S nonServingCell > 2 x CellReselectionConfHrpd::threshXLow during a time
interval HrpdNeighboring::tReselectionCdmaHrpd
• More than 1 second has elapsed since UE camped on the current serving cell
Where
• S ServingCell is the S rxlev value of an serving cell.
• For HRPD, S nonServingCell = -FLOOR (-20 x log10Ec/Io) in the unit of 0.5 dB. Ec/Io is
the value measured from the evaluated cell.
Page 102/543
Volume 6 : Mobility
HrpdNeighboring::tReselectionCdmaHrpd
Parameter tReselectionCdmaHrpd

[0, 7] step=1
Value 5
Feature L82728
CellReselectionConfHrpd::cellReselectionPriority
Object ENBEquipment/ Enb/ LteCell/ HrpdNeighboring/

HrpdBandClassConf/ CellReselectionConfHrpd

[0, 7] step=1
Value O.D.
Feature L82728
0 is the lowest priority value. In general, LTE intra-frequency and inter-frequency

neighbors are preferred over the inter-RAT neighbors, and so this parameter is
recommended to be set to a value lower than
CellReselectionConfLte::cellReselectionPriority of the LTE serving frequency and
inter-frequency neighbors if exist.
Rule: cellReselectionPriority
This parameter must be set to a different value than

CellReselectionConfLte::cellReselectionPriority of any LTE frequency. Carrier
frequencies of different RAT cannot be set to the same cell reselection priority.
Page 103/543
Volume 6 : Mobility
CellReselectionConfHrpd::threshXHigh


[-31.5 .. 0] step = 0.5
Value N.A.
Feature L82728
Rule: threshXHigh
In SIB8, the range of the parameter is [0, 63]. The configued value of this
parameter in unit of 0.5 dB is multiplied by (-2) before it is broadcast in SIB8. The
actual value used by the UE is the parameter value received in SIB8 multiplied by
(-1).
CellReselectionConfHrpd::threshXLow


[-31.5 .. 0] step = 0.5
Value N.A.
Feature L82728
Rule: threshXLow
(-1).
4.1.7.2 HRPD NEIGHBOR PARAMETERS IN SIB8
HRPD neighbor cell related parameters to be broadcasted in SIB8 include:
Page 104/543
Volume 6 : Mobility
• HrpdBandClassConf::bandClass
• HrpdNeighboringPerCarrier::frequency
• HrpdNeighboringPerCarrier::pnOffsetList
• HrpdNeighboring::hrpdPreRegAllowed
HrpdBandClassConf::bandClass
Parameter bandClass

HrpdBandClassConf

[800MHz-cellular, 1.8-to-2.0-GHz-PCS]
Value 800MHz-cellular
Feature L82728
Notes: This parameter indicates the frequency band of the underlying HRPD neighbor
cells.
HrpdNeighboringPerCarrier::frequency
Parameter frequency

HrpdBandClassConf/ HrpdNeighboringPerCarrier

[0, 2047] step=1
Value O.D.
Feature L82728
Notes: This parameter indicates the carrier frequency under a HRPD band class. Unique
frequencies must be provisioned under the same HRPD band class.
Page 105/543
Volume 6 : Mobility
HrpdNeighboringPerCarrier::pnOffsetList
Parameter pnOffsetList

HrpdBandClassConf/ HrpdNeighboringPerCarrier
Range & Unit Integer, PN offset

[0, 511] step=1
ListSizeMin = 1
ListSizeMax = 32
Value O.D.
Feature L82728
Rule: pnOffsetList
Each PNOffset value in the same pnOffsetList must be unique.

Total number of pnOffset under all HrpdNeighboringPerCarrier MOsmust be less
than or equal to 32. The first 16 at most are used by both Rel-8 and Rel-9 UEs.
The last 16 at most map to neighCellList-v920 in
cellReselectionParametersHRPD-v920 of SIB8 applicable only to Rel-9 UEs.
HrpdNeighboring::hrpdPreRegAllowed
Parameter hrpdPreRegAllowed

[false, true]
Value False
Feature L82728
Notes: This parameter indicates whether UE should perform an HRPD pre-registration if
UE does not have a valid/current pre-registration.
Rule: hrpdPreRegAllowed
Currently, eNB does not support HRPD pre-registration. This parameter must be
set to ‘False’ until pre-registration is supported in eNB in a future release.
Page 106/543
Volume 6 : Mobility
4.1.7.3 HRPD SPEED DEPENDENT PARAMETERS IN SIB8

Two speed dependent parameters,
HrpdSpeedDependentConf::tReselectionHrpdSfHigh and
HrpdSpeedDependentConf::tReselectionHrpdMedium are used to populate the speed
state scale factors (optional) in SIB8. UE will determine whether it is in high speed, medium
speed, or normal speed based on the mobility state parameters broadcasted in SIB3. If it is
in high speed state, UE will multiply tReselectionCdmaHrpd by
tReselectionHrpdSfHigh. If it is in medium state, UE will multiply
tReselectionCdmaHrpd by tReselectionHrpdSfMedium.
HrpdSpeedDependentConf::tReselectionHrpdSfHigh
Parameter tReselectionHrpdSfHigh

HrpdSpeedDependentConf

[oDot25, oDot5, oDot75, 1Dot0]
Class/Source C – Immediate - Propagation / customer_settable
Value N.A.
Feature 108283
HrpdSpeedDependentConf::tReselectionHrpdSfMedium
Parameter tReselectionHrpdSfMedium

HrpdSpeedDependentConf

Value N.A.
Feature 108283
4.1.7.4 1XRTT CELL RESELECTION PARAMETERS IN SIB8

When OneXRttNeighboring::oneXRttInfoConfiguredis set to ‘True’, the following 1xRTT
Cell reselection parameters are to be broadcasted in SIB8:
• Parameter applied to all 1xRTT neighbors

o OneXRttNeighboring::tReselectionCdma1xRtt
• Parameters applied to 1xRTT neighbors in the same band class:
o CellReselectionConf1xRtt::cellReselectionPriority
o CellReselectionConf1xRtt::threshXHigh
o CellReselectionConf1xRtt::threshXLow
Page 107/543
Volume 6 : Mobility
CellReselectionConf1xRtt::cellReselectionPriorityis used to determine the relative

priorities between a 1xRTT frequency and the EUTRAN serving frequency
(CellReselectionConfLte::cellReselectionPriority under serving frequency). Cell
reselection priorities of different RAT cannot be set to the same value. If a 1xRTT
frequency has higher priority than the EUTRAN serving frequency, all the 1xRTT neighbor
cells under the 1xRTT frequency have higher priority than the EUTRAN serving cell, or vice
versa.
The reselection parameters are used in measurement rules and 1xRTT cell reselection
criteria below.
UE measurement rules for cell reselection:
A. If a 1xRTT frequency has higher priority than the serving frequency

(CellReselectionConf1xRtt::cellReselectionPriority of the 1xRTT frequency
>CellReselectionConfLte::cellReselectionPriority of serving frequency), UE is
required to perform measurements on the 1xRTT frequency to determine if
reselection to the frequency should be performed
B. If a 1xRTT frequency has lower priority than the serving frequency
(CellReselectionConf1xRtt::cellReselectionPriority of the 1xRTT frequency
<CellReselectionConfLte::cellReselectionPriority of serving frequency),
whether UE is required to perform measurements on the 1xRTT frequency
depends on how good the signal on serving cell is:
• For Rel-8 UE:

o If serving cell fulfills Srxlev > sNonIntraSearch, UE may choose not to
perform measurements of the lower priority 1xRTT frequency
priority 1xRTT frequency
• For Rel-9 UE:
o If serving cell fulfills Srxlev > sNonIntraSearchP and Squal >
sNonIntraSearchQ, UE may choose not to perform measurements of
the lower priority 1xRTT frequency
priority 1xRTT frequency
Where
• sNonIntraSearch = CellSelectionReselectionConf::sNonIntraSearch if it is
provisioned. Otherwise, sNonIntraSearch = infinity
• sNonIntraSearchP = CellSelectionReselectionConf::sNonIntraSearchP if it
is provisioned. If it is not provisioned but
sNonIntraSearchP = CellSelectionReselectionConf::sNonIntraSearch.
Otherwise, if neither CellSelectionReselectionConf::sNonIntraSearchP nor
sNonIntraSearchP = infinity
• sNonIntraSearchQ = CellSelectionReselectionConf::sNonIntraSearchQ if it
is provisioned. Otherwise, sNonIntraSearchQ = 0
1xRTT cell reselection criteria:
A. Cell reselection to a higher priority EUTRAN inter-frequency neighbor cell or a

higher priority 1xRTT neighbor cell will be performed if:
• Refer to section 4.1.4.2for criteria to reselect a higher priority EUTRAN inter-

Page 108/543
Volume 6 : Mobility
• If S nonServingCell > 2 x CellReselectionConf1xRtt::threshXHigh during a time
interval OneXRttNeighboring::tReselectionCdma1xRtt
• More than 1 second has elapsed since the UE camped on the current serving
cell
B. Cell reselection to a lower priority EUTRAN inter-frequency neighbor cell or a lower

priority 1xRTT neighbor cell will be performed if all of the following conditions are true:
• No higher priority inter-frequency EUTRAN neighbor cell or higher priority

1xRTT neighbor cell that meet the criteria as in A
• No cell on serving frequency or on the same priority inter-frequency can be
selected that meet the criteria as specified in section4.1.4.2.
• Refer to section 4.1.4.2for criteria to reselect a lower priority EUTRAN inter-
• S ServingCell <CellSelectionReselectionConf::threshServingLow
and S nonServingCell > 2 x CellReselectionConf1xRtt::threshXLow during a time
interval OneXRttNeighboring::tReselectionCdma1xRtt
• More than 1 second has elapsed since UE camped on the current serving cell
Where
• S ServingCell is the S rxlev value of an serving cell
• For 1xRtt, S nonServingCell = -FLOOR (-20 x log10Ec/Io) in the unit of 0.5 dB. Ec/Io is
the value measured from the evaluated cell
Page 109/543
Volume 6 : Mobility
OneXRttNeighboring::tReselectionCdma1xRtt
Parameter tReselectionCdma1xRtt
Object ENBEquipment/ Enb/ LteCell/ OneXRttNeighboring

[0, 7] step=1
Value N.A.
Feature L76499.1
CellReselectionConf1xRtt::cellReselectionPriority
Object ENBEquipment/ Enb/ LteCell/ OneXRttNeighboring/

OneXRttBandClassConf/ CellReselectionConf1xRtt

[0, 7] step=1
Value O.D.
Feature L76499.1
0 is the lowest priority value. In general, LTE intra-frequency and inter-frequency

neighbors are preferred over the inter-RAT neighbors, and so this parameter is
recommended to be set to a value lower than
CellReselectionConfLte::cellReselectionPriority of the LTE serving frequency and
inter-frequency neighbors if exist.
Rule: cellReselectionPriority
This parameter must be set to a different value than

CellReselectionConfLte::cellReselectionPriority of any LTE frequency. Carrier
frequencies of different RAT cannot be set to the same cell reselection priority.
Page 110/543
Volume 6 : Mobility
CellReselectionConf1xRtt::threshXHigh


[-31.5 .. 0] step = 0.5
Value N.A.
Feature L76499.1
Rule: threshXHigh
(-1).
CellReselectionConf1xRtt::threshXLow


[-31.5 .. 0] step = 0.5
Value N.A.
Feature L76499.1
Rule: threshXLow
(-1).
4.1.7.5 1XRTT NEIGHBOR PARAMETERS IN SIB8
1xRTT neighbor cell related parameters to be broadcasted in SIB8 include:
• OneXRttBandClassConf::bandClass
• OneXRttNeighboringPerCarrier::frequency
Page 111/543
Volume 6 : Mobility
• OneXRttNeighboringPerCarrier::pnOffsetList
SIB 8 also includes 1xRTT neighbor parameters used for 1xCSFB. Refer to section 10.2.3.2.
OneXRttBandClassConf::bandClass
Parameter bandClass

OneXRttBandClassConf

[800MHz-cellular, 1.8-to-2.0-GHz-PCS]
Value 800MHz-cellular
Feature L76499.1
Notes: This parameter indicates the frequency band of the underlying 1xRTT neighbor
cells.
OneXRttNeighboringPerCarrier::frequency
Parameter frequency

OneXRttBandClassConf/ OneXRttNeighboringPerCarrier

[0, 2047] step=1
Value O.D.
Feature L76499.1
Notes: This parameter indicates the carrier frequency under a 1xRTT band class. Unique
frequencies must be provisioned under the same 1xRTT band class.
Page 112/543
Volume 6 : Mobility
OneXRttNeighboringPerCarrier::pnOffsetList
Parameter pnOffsetList

OneXRttBandClassConf/ OneXRttNeighboringPerCarrier
Range & Unit Integer, PN offset

[0, 511] step=1
ListSizeMin = 1
ListSizeMax = 40
Value O.D.
Feature L76499.1
Rule: pnOffsetList
Each PNOffset value in the same pnOffsetList must be unique.

Total number of pnOffset under all OneXRttNeighboringPerCarrier MOsmust be
less than or equal to 40. The first 16 at most are used by both Rel-8 and Rel-9
UEs. The last 24 at most map to neighborCellList-v920 in
cellReselectionParameters1xRTT-v920 of SIB8 applicable only to Rel-9 UEs.
4.1.7.6 1XRTT SPEED DEPENDENT PARAMETERS IN SIB8

Two speed dependent parameters,
OneXRttSpeedDependentConf::tReselection1xRttSfHigh and
OneXRttSpeedDependentConf::tReselection1xRttMedium are used to populate the
speed state scale factors (optional) in SIB8. UE will determine whether it is in high speed,
medium speed, or normal speed based on the mobility state parameters broadcasted in
SIB3. If it is in high speed state, UE will multiply tReselectionCdma1xRtt by
tReselection1xRttSfHigh. If it is in medium state, UE will multiply
tReselectionCdma1xRtt by tReselection1xRttSfMedium.
Page 113/543
Volume 6 : Mobility
OneXRttSpeedDependentConf::tReselection1xRttSfHigh
Parameter tReselection1xRTTSfHigh

OneXRttSpeedDependentConf

Value N.A.
Feature L76499.1
OneXRttSpeedDependentConf::tReselection1xRttSfMedium
Parameter tReselection1xRTTSfMedium

OneXRttSpeedDependentConf

Value N.A.
Feature L76499.1
4.2 SPEED ADJUSTMENT TO CELL SELECTION/RESELECTION

PARAMETERS
Parameters in relationship with mobility speed states of a UE, in case of intra-LTE mobility,
are the same as in case of inter-RAT mobility, except parameters in the MO object
UtraSpeedConf andtReselectionUtra, which are specific. Please report to section
4.1.5.3.4 and 4.1.5.3.5for those parameters in case of inter-RAT mobility.
Besides Normal-mobility state a High-mobility and a Medium-mobility state are applicable if
the parameters (tEvaluation (TCRmax), nCellChangeHigh (NCR_H),
nCellChangeMedium (NCR_M) and tHystNormal (TCRmaxHyst)) are sent in the system
information broadcast SIB3 of the serving cell.
State detection criteria:

Medium-mobility state criteria:
- If number of cell reselections during time period tEvaluation exceeds
nCellChangeMediumand not exceeds nCellChangeHigh
High-mobility state criteria:
- If number of cell reselections during time period tEvaluation exceeds
nCellChangeHigh
Page 114/543
Volume 6 : Mobility
The UE shall not count consecutive reselections between same two cells into mobility state
detection criteria if same cell is reselected just after one other reselection.
State transitions:
The UE shall:
- if the criteria for High-mobility state is detected:
- enter High-mobility state.
- else if the criteria for Medium-mobility state is detected:
- enter Medium-mobility state.
- else if criteria for either Medium- or High-mobility state is not detected during time
periodtHystNormal:
- enter Normal-mobility state.
If the UEis in High- or Medium-mobility state, the UE shall apply the speed dependent
scaling rules as defined in subclause [R16] section 5.2.4.3.1.
• tEvaluation:TS36.331: this parameter contributes to the configuration of the
SystemInformationBlockType3. This parameter configures the IE t-Evaluation
included in the IE MobilityStateParameters. The duration for evaluating criteria to
enter mobility states. Corresponds to TCRmax in TS 36.304. Value in seconds, s30
SpeedStateEvalConf::tEvaluation
Parameter tEvaluation
Object ENBEquipment/ Enb/ LteCell/ SpeedStateEvalConf

[s30, s60, s120, s180, s240]
Value N.A.
Feature L76498, 108283
• nCellChangeHigh: TS36.331: this parameter contributes to the configuration of the

SystemInformationBlockType3. This parameter configures the IE n-CellChangeHigh
included in the IE MobilityStateParameters. The number of cell changes to enter high
mobility state. Corresponds to NCR_H in TS 36.304.
SpeedStateEvalConf::nCellChangeHigh
Parameter nCellChangeHigh

[1..16] step = 1
Value N.A
Feature L76498, 108283
Page 115/543
Volume 6 : Mobility
• nCellChangeMedium:TS36.331: this parameter contributes to the configuration of the
SystemInformationBlockType3. This parameter configures the IE n-
CellChangeMedium included in the IE MobilityStateParameters. The number of cell
changes to enter medium mobility state. Corresponds to NCR_M in TS 36.304.
SpeedStateEvalConf::nCellChangeMedium
Parameter nCellChangeMedium

[1..16] step = 1
Value N.A
Feature L76498, 108283

• tHystNormal:TS36.331: this parameter contributes to the configuration of the
SystemInformationBlockType3. This parameter configures the IE t-HystNormal
included in the IE MobilityStateParameters. The additional duration for evaluating
criteria to enter normal mobility state. Corresponds to TCRmaxHyst in TS 36.304.
Value in seconds, s30 corresponds to 30 s and so on.
SpeedStateEvalConf::tHystNormal
Parameter tHystNormal

[s30, s60, s120, s180, s240]
Value N.A
Feature L76498, 108283

Scaling rules:
The cell ranking procedure is the same as in 4.1.3.1.2but with variable values for
- Add the qHystSfHigh to Qhystfor high mobility state if sent on system information.
- For E-UTRAN cellsmultiplytReselectionEUTRANbytReselectionEutraSfHigh if

- For UTRAN cellsmultiplytReselectionUtra by tReselectionUtraSfHigh if sent on

system information.
- For CDMA2000 HRPD cellsmultiplytReselectionCdmaHrpd by the IE sf-High of

"Speed dependent ScalingFactor for TreselectionCDMA_HRPD for high mobility
Page 116/543
Volume 6 : Mobility
- For CDMA2000 1xRTT cells multiply tReselectionCdma1xRtt by the IE sf-High of
"Speed dependent ScalingFactor for TreselectionCDMA_1xRTT for high mobility
state” if sent on system information. Refer to section 8.1.5.

- AddqHystSfMedium to Qhyst for medium mobility state, if sent on system
information.
- For E-UTRAN cells multiplytReselectionEUTRAN by

tReselectionEutraSfMediumif sent on system information.
- For UTRAN cells multiply tReselectionUtra by tReselectionUtraSfMedium, if

- For CDMA2000 HRPD cells multiply tReselectionCdmaHrpd by the IE sf-Medium

of "Speed dependent ScalingFactor for tReselectionCdmaHrpd for medium mobility
- For CDMA2000 1xRTT cells multiply rReselectionCdma1xRtt by the IE sf-Medium

of "Speed dependent ScalingFactor for TreselectionCDMA_1xRTT for medium
mobility state”" if sent on system information. Refer to section 8.1.5.
In case scaling is applied to any TreselectionRAT parameter the UE shall round up the
result after all scalings to the nearest second.
• qHystSfHigh:TS36.331: this parameter contributes to the configuration of the IE
SystemInformationBlockType3.This parameter configures the IE sf-High included in
the IE SpeedStateReselectionPars. Parameter “Speed dependent ScalingFactor for
Qhyst” in TS 36.304. The sf-High concerns the additional hysteresis to be applied,
in High Mobility state, to Qhyst as defined in TS 36.304 and in section 4.1.3.1.2. In
dB. Value dB-6 corresponds to -6dB, dB-4 corresponds to -4dB and so on.
SpeedStateEvalConf::qHystSfHigh
Parameter qHystSfHigh

[dB-6, dB-4, dB-2, dB0]
Value N.A.
Feature L76498, 108283

Decreasing qHystSfHigh leads to do cell-reselection earlier
• tReselectionEutraSfHigh :TS36.331: this parameter contributes to the configuration of

the IE SystemInformationBlockType3. This parameter configures the t-
ReselectionEUTRA-SF included in the IE SystemInformationBlockType3 and
timeToTrigger-SF in IE MeasConfig. Parameter “Speed dependent ScalingFactor for
tReselectionEUTRAN” (TS 36.304). If the field is not present, the UE behaviour is
specified in TS 36.304. The concerned mobility control related parameter ismultiplied
with this factor if the UEis in High Mobility state as defined in TS 36.304. Value
Page 117/543
Volume 6 : Mobility
oDot25 corresponds to 0.25, oDot5 corresponds to 0.5 , oDot75 corresponds to 0.75
and so on.
LteSpeedDependentConf::tReselectionEutraSfHigh
Parameter tReselectionEutraSfHigh

LteNeighboringFreqConf/ LteSpeedDependentConf

Value N.A
Feature L76498, 108283

mobility.
• qHystSfMedium:TS36.331: this parameter contributes to the configuration of the IE
SystemInformationBlockType3.This parameter configures the IE sf-Medium included
in the IE SpeedStateReselectionPars. Parameter “Speed dependent ScalingFactor for
Qhyst” in TS 36.304. The sf-Medium concerns the additional hysteresis to be
applied, in Medium Mobility state, to Qhyst as defined in TS 36.304 and in section
4.1.3.1.2. In dB. Value dB-6 corresponds to -6dB, dB-4 corresponds to -4dB and so
on.
SpeedStateEvalConf::qHystSfMedium
Parameter qHystSfMedium

[dB-6, dB-4, dB-2, dB0]
Value N.A
Feature L76498, 108283

Exemple with the Value 4dB: With this value, the cell-reselection should be made with a
neighboring cell at RSRP > -86dBm (case with qRxLevMin (see by the UE) =-100 dBm,
sIntraSearch=10, intra-frequency mobility )
Decreasing qHystSfMedium leads to do cell-reselection earlier
• tReselectionEutraSfMedium:TS36.331: this parameter contributes to the

configuration of the IE SystemInformationBlockType3. This parameter configures the
t-ReselectionEUTRA-SF included in the IE SystemInformationBlockType3 and
timeToTrigger-SF in IE MeasConfig. Parameter “Speed dependent ScalingFactor for
tReselectionEUTRAN” (TS 36.304). If the field is not present, the UE behaviour is
specified in TS 36.304. The concerned mobility control related parameter ismultiplied
Page 118/543
Volume 6 : Mobility
with this factor if the UEis in Medium Mobility state as defined in TS 36.304. Value
oDot25 corresponds to 0.25, oDot5 corresponds to 0.5 , oDot75 corresponds to 0.75
and so on.
LteSpeedDependentConf::tReselectionEutraSfMedium
Parameter tReselectionEutraSfMedium

LteNeighboringFreqConf/ LteSpeedDependentConf

Value N.A
Feature L76498, 108283

This parameter avoids ping pong radio phenomena during the RA-Update & idle mobility.
reselections
tEvaluation tReselectionEUTRAN
During tEvaluation (Tcrmax) ×
1 => tReselectionEutraSfHigh tR:0.5s
[Nb. Reselections] > nCellChangeHigh (NCR_H)
•t
reselections
tEvaluation tReselectionEUTRAN
2 During tEvaluation (Tcrmax) ×
=> tReselectionEutraSfMedium tR:1s
NCR_M < [Nb. Reselections] < nCellChangeHigh
reselections •t
tHystNormal
During tHystNormal (TcrmaxHyst)
3
=> tReselectionEUTRAN tR:2s
[Nb. Reselections] < nCellChangeMedium (i.e NCR_M)
•t
Figure 22 : User Case, tim e o f re s e le c tio n value according to the values of the parameters under
SpeedStateEvalConf.
4.2.1 CONFIGURATION MODEL
Page 119/543
Volume 6 : Mobility
Figure 23 : Configuration Model related to speed dependent parameters
Page 120/543
Volume 6 : Mobility
ENBEquipment CellSelectionReselectionConf
ENb •intraFrequencyReselection
LTECell •qRxLevMin
•pMax
•sIntraSearch
FrequencyAndBandwidtFDD
•qHyst
•dlBandwidth
•threshServingLow
•dlEARFCN
LteNeighboring/0
•ulBandwidth
LteNeighboringFreqConf/0-8 •ulEARFCN
•dlEARFCN
LteSpeedDependentConf/0
•measurementBandwidth
tReselectionEutraSfHigh
SpeedStateEvalConf
tReselectionEutraSfMedium
Optional subtree
•tEvaluation CellReselectionConfLte
•nCellChangeHigh •cellReselectionPriority
•nCellChangeMedium •qRxLevMin
•tHystNormal •pMax
•tReselectionEUTRAN
•qHystSfHigh
•threshXHigh
•qHystSfMedium
•threshXLow
Figure 24 : Intra-LTE reselection configuration
4.3 LOAD BASED ADJUSTMENTS TO CELL

SELECTION/RESELECTION PARAMETERS
Feature L115203 (Load Based Idle Mode Mobility) provides the capability for eNB to
automatically adjust six of the cell reselection parameter values broadcast in SIB3 based
on cell loading. This is for eNB to have control on how likely an idle UE will reselect to a
neighbor cell (a LTE cell or an inter-RAT cell) when the serving cell has a certain loading.
The feature is activated when
ActivationService::isSIB3ReselectionAutomationEnabled is set to ‘True’.
Page 121/543
Volume 6 : Mobility
ActivationService::isSIB3ReselectionAutomationEnabled
Parameter isSIB3ReselectionAutomationEnabled

[True, False]
Class/Source C – Immediate-propagation / customer_settable
Value False
Feature L115203
Notes: This parameter controls the activation/deactivation of the feature that automatically
adjusts the reselection parameters broadcast in SIB3 based on the cell loading.
Restriction: Load based idle m ode m obility for Metro Cell in LR13.1
This capability is not supported on Metro Cell in release

LR13.1.ActivationService::isSIB3ReselectionAutomationEnabled can not be
set to TRUE for Metro Cell.
This restriction is removed in LR13.3.
4.3.1 CELL LOADING CALCULATION
For reselection parameter adjustments, % of cell PRB consumption is used as the

indication of cell loading. Up to four types of PRB consumption measurements have been
available in eNB. They are DL PRB consumption per cell, UL PRB consumption per cell,
DL PRB consumption per band per eNB and UL PRB consumption per band per eNB. The
two per band per eNB PRB consumption measurements are available only if
ActivationService::isUnlimitedPRBLicenseAllowed is set to ‘False’.
The four PRB consumption measurements are originally used by CAC with measurement
interval determined by RadioCacCell::periodMeasForPRBConsumption (refer to volume
4 of LPUG for this parameter). For reselection parameter adjustment, however, each of the
PRB consumption measurement is averaged over a longer period of time (determined by
CellSelectionReselectionConf::autoReselectMinInterval) to come up with a more stable
% of PRB consumption. Since it is required that autoReselectMinInter must be a multiple
k of periodMeasForPRBConsumption, the calculation of each of the four average % of
PRB consumption in one autoReselectMinInter becomes:
% of average PRB consumption

k k
=( ∑
i =1
PRB consumption i ) / ( ∑i =1
Total PRB resource i )
In the above equation:

• PRB consumption i - It can be one of the following: DL/UL PRB consumption per
cell, or DL/UL PRB consumption per band per eNB in the ith period of
periodMeasForPRBConsumption in the interval of autoReselectMinInter
Page 122/543
Volume 6 : Mobility
• Total PRB resource i - Corresponding to PRB consumption i , Total PRB
resource i can be one of the following: total DL/UL PRB resource per cell, or total
DL/UL PRB resource per band per eNB in the ith period of
periodMeasForPRBConsumption in the interval of autoReselectMinInter
• % of average PRB consumption - Corresponding to PRB consumption i , % of
average PRB consumption can be one of the following: % of average DL/UL PRB
consumption per cell, or % of Average DL/UL PRB consumption per band per eNB
CellSelectionReselectionConf::autoReselectMinInterval
Parameter autoReselectMinInterval

[10..3600] step = 1
Value 600
Feature L115203
Note: This parameter indicates the time interval to update the cell loading and to evaluate
whether the reselection parameters need to be adjusted based on cell loading changes.
Rule: autoReselectMinInterval
autoReselectMinInterval must be set to a value multiple of

RadioCacCell::periodMeasForPRBConsumption.
If ActivationService::isUnlimitedPRBLicenseAllowed is set to ‘False’, the % of cell PRB

consumption is the weighted average of the four % of Average PRB Consumption:
% of cell PRB consumption = (weightDlPrbCell × % of average DL PRB consumption per

cell + weightUlPrbCell × % of average UL PRB consumption per cell + weightDlPrbEnb
× % of average DL PRB consumption per band per eNB + weightUlPrbEnb × % of
average DL PRB consumption per band per eNB) / (weightDlPrbCell + weightUlPrbCell
+ weightDlPrbEnb + weightUlPrbEnb)
If ActivationService::isUnlimitedPRBLicenseAllowed is set to ‘True’, the % of cell PRB

consumption is the weighted average of the two % of Average PRB Consumption:
% of cell PRB consumption = (weightDlPrbCell × % of average DL PRB consumption per

cell + weightUlPrbCell × % of average UL PRB consumption per cell) / (weightDlPrbCell
+ weightUlPrbCell)
Where
weightDlPrbCell, weightUlPrbCell, weightDlPrbEnb,and weightUlPrbEnb are defined
in CellSelectionReselectionConf MO.
Page 123/543
Volume 6 : Mobility
CellSelectionReselectionConf::weightDlPrbCell
Parameter weightDlPrbcell

[0..100] step = 1
Value 1
Feature L115203
Note: This parameter indicates the weighting factor of % of cell DL PRB consumption
contributing to the calculation of cell load (cell PRB consumption).
CellSelectionReselectionConf::weightDlPrbEnb
Parameter weightDlPrbEnb

[0..100] step = 1
Value 1
Feature L115203
Note: This parameter indicates the weighting factor of % of total PRB consumption of the
band in DL contributing to the calculation of cell load (cell PRB consumption).
CellSelectionReselectionConf::weightUlPrbCell
Parameter weightUlPrbCell

[0..100]
Value 1
Feature L115203
Note: This parameter indicates the weighting factor of % of cell UL PRB consumption
contributing to the calculation of cell load (cell PRB consumption).
Page 124/543
Volume 6 : Mobility
CellSelectionReselectionConf::weightUlPrbEnb
Parameter weightUlPrbEnb

[0..100]
Value 1
Feature L115203
Note: This parameter indicates the weighting factor of % of total PRB consumption of the
band in UL contributing to the calculation of cell load (cell PRB consumption).
4.3.2 DELTA PARAMETER SELECTION
Feature L115203 supports up to 3 instances of CellReselectionAdaptation MO. The

lowerBound and upperBound in each of the CellReselectionAdaptation MO define the
range of % of cell PRB consumption. When the calculated % of cell PRB consumption is
between the lowerBound and upperBound of an instance, the delta parameters defined
in the same instance including qHystDelta, threshServingLowDelta,
threshServingLowQDeltasNonIntraSearchDelta, sNonIntraSearchPDelta and
sNonIntraSearchQDelta are used to adjust the reselection parameters broadcast in SIB3.
For example, if for instance 1, lowerBound is set to 0%, upperBound is set to 20%. For
instance 2, lowerBound is set to 20%, upperBound is set to 80%. For instance 3,
lowerBound is set to 80%, upperBound is set to 100%. If the calculated % of cell PRB
consumption is 75%, it is within the range between lowerBound and UpperBound of
instance 2. Therefore, the delta parameter values in instance 2 are used to adjust the
corresponding reselection parameters broadcast in SIB3.
CellReselectionAdaptation::lowerBound
Parameter lowerBound
Object ENBEquipment/ Enb/

[0..100] step = 1
Class/Source C – New-Setups / customer_settable
Value 0
Feature L115203
Notes: When the % of cell PRB consumption is within the range between lowerBound and
upperBound in an instance of CellReselectionAdaptation MO, the values of
qHystDelta, threshServingLowDelta, threshServingLowQDeltasNonIntraSearchDelta,
sNonIntraSearchPDelta and sNonIntraSearchQDelta in the same instance are used to
adjust the values the corresponding parameters, qHyst, threshServingLow,
threshServingLowQ, sNonIntraSearch, sNonIntraSearchP and sNonIntraSearchQ
before they are broadcast in SIB3.
Page 125/543
Volume 6 : Mobility
Rule: lowerBound
Operator may define up to three instances of CellReselectionAdaptation MO.

The value of lowerBound must be less than or equal to the value of upperBound
in the same instance. The range between lowerBound and upperBound of one
instance must not have overlapped area with that of another instance.
CellReselectionAdaptation::upperBound
Parameter upperBound

[0..100] step = 1
Value 0
Feature L115203
Notes: When the % of cell PRB consumption is within the range between lowerBound and
upperBound in an instance of CellReselectionAdaptation MO, the values of
qHystDelta, threshServingLowDelta, threshServingLowQDeltasNonIntraSearchDelta,
sNonIntraSearchPDelta and sNonIntraSearchQDelta in the same instance are used to
adjust the values of the corresponding parameters, qHyst, threshServingLow,
threshServingLowQ, sNonIntraSearch, sNonIntraSearchP and sNonIntraSearchQ
before they are broadcast in SIB3.
Rule: upperBound
Operator may define up to three instances of CellReselectionAdaptation MO.

The value of upperBound must be greater than or equal to the value of
lowerBound in the same instance. The range between lowerBound and
upperBound of one instance must not have overlapped area with that of another
instance.
CellReselectionAdaptation::qHystDelta
Parameter qHystDelta

[-15.. 15] step = 1
Value 0
Feature L115203
Notes: When the % of PRB consumption of the cell is within the range between
lowerBound and upperBound in an instance of CellReselectionAdaptation MO, the
value of qHystDelta in the same instance are used to adjust the value of
CellSelectionReselectionConf::qHyst before it is broadcast in SIB3.
Page 126/543
Volume 6 : Mobility
Rule: qHystDelta
The allowed values of CellSelectionReselectionConf::qHyst are [dB0, dB1, dB2,

dB3, dB4, dB5, dB6, dB8, dB10, dB12, dB14, dB16, dB18, dB20, dB22, dB24].
The value of qHystDelta indicates the relative position the adjusted value should
be moved in the list of allowed values. For example, if qHyst is set to dB10 and
qHystDelta is set to -2, the adjusted value of q-Hyst broadcast in SIB3 is dB6. If
qHyst is set to dB12 and qHystDelta is set to 3, the adjusted value of q-Hyst is
dB18. Based on the value of qHyst, qHystDelta must be set to a value that keeps
the adjusted value of q-Hyst one the allowed values of
CellSelectionReselectionConf::qHyst.
CellReselectionAdaptation::sNonIntraSearchDelta
Parameter sNonIntraSearchDelta

[-62.. 62] step = 2
Value 0
Feature L115203
value of sNonIntraSearchDelta in the same instance are used to adjust the value of
CellSelectionReselectionConf::sNonIntraSearch before it is broadcast in SIB3.
Rule: sNonIntraSearchDelta
The range of CellSelectionReselectionConf::sNonIntraSearch is [0.. 62], step =

2. The adjusted value of s-NonIntraSearch broadcast in SIB3 is equal to
sNonIntraSearch + sNonIntraSearchDelta. Based on the value of
sNonIntraSearch, sNonIntraSearchDelta must be set to a value that keeps the
adjusted value of s-NonIntraSearch in the range of
CellSelectionReselectionConf::sNonIntraSearch.
Page 127/543
Volume 6 : Mobility
CellReselectionAdaptation::sNonIntraSearchPDelta
Parameter sNonIntraSearchPDelta

[-62.. 62] step = 2
Value 0
Feature L115203
value of sNonIntraSearchPDelta in the same instance are used to adjust the value of
CellSelectionReselectionConf::sNonIntraSearchP before it is broadcast in SIB3.
Rule: nonIntraSearchPDelta
The range of CellSelectionReselectionConf::sNonIntraSearchP is [0.. 62], step

= 2. The adjusted value of s-NonIntraSearchP-r9 broadcast in SIB3 is equal to
sNonIntraSearchP + sNonIntraSearchPDelta. Based on the value of
sNonIntraSearchP, sNonIntraSearchPDelta must be set to a value that keeps
the adjusted value of s-NonIntraSearchP-r9 in the range of
CellSelectionReselectionConf::sNonIntraSearchP.
CellReselectionAdaptation::sNonIntraSearchQDelta
Parameter SNonIntraSearchQDelta

[-31..31] step = 1
Value 0
Feature L115203
value of sNonIntraSearchQDelta in the same instance are used to adjust the value of
CellSelectionReselectionConf::sNonIntraSearchQ before it is broadcast in SIB3.
Rule: sNonIntraSearchQDelta
The range of CellSelectionReselectionConf::sNonIntraSearchQ is [0.. 31], step

= 1. The adjusted value of s-NonIntraSearchQ-r9 broadcast in SIB3 is equal to
sNonIntraSearchQ + sNonIntraSearchQDelta. Based on the value of
sNonIntraSearchQ, sNonIntraSearchQDelta must be set to a value that keeps
the adjusted value of s-NonIntraSearchQ-r9 in the range of
Page 128/543
Volume 6 : Mobility
CellSelectionReselectionConf::sNonIntraSearchQ.
CellReselectionAdaptation::threshServingLowDelta
Parameter threshServingLowDelta

[-62..62] step = 2
Value 0
Feature L115203
value of threshServingLowDelta in the same instance are used to adjust the value of
CellSelectionReselectionConf::threshServingLow before it is broadcast in SIB3.
Rule: threshServingLowDelta
The range of CellSelectionReselectionConf::threshServingLow is [0.. 62], step

= 2. The adjusted value of threshServingLow broadcast in SIB3 is equal to
threshServingLow + threshServingLowDelta. Based on the value of
threshServingLow, threshServingLowDelta must be set to a value that keeps
the adjusted value of threshServingLow in the range of
CellSelectionReselectionConf::threshServingLow.
CellReselectionAdaptation::threshServingLowQDelta
Parameter threshServingLowQDelta

[-31..31] step = 1
Value 0
Feature L115203
value of threshServingLowQDelta in the same instance are used to adjust the value of
CellSelectionReselectionConf::threshServingLowQ before it is broadcast in SIB3.
Page 129/543
Volume 6 : Mobility
Rule: threshServingLowQDelta
The range of CellSelectionReselectionConf::threshServingLowQ is [0.. 31],

step = 1. The adjusted value of threshServingLowQ-r9 broadcast in SIB3 is equal
to threshServingLowQ + threshServingLowQDelta. Based on the value of
threshServingLowQ, threshServingLowQDelta must be set to a value that
keeps the adjusted value of threshServingLowQ-r9 in the range of
CellSelectionReselectionConf::threshServingLowQ.
4.3.3 RESELECTION PARAMETER ADJUSTMENT
In L115203, the six cell reselection parameters broadcast in SIB3 to be adjusted by cell
loading include:
• q-Hyst
• threshServingLow
• threshServingLowQ-r9
• s-NonIntraSearch
• s-NonIntraSearchP-r9
• s-NonIntraSearchQ-r9
When the % of cell PRB consumption is with the lowerBound and UpperBound of an
instance of CellReselectionAdaptation MO, the value of a delta parameter in the same
instance is added to the value of the base parameter before it is used to populate the
corresponding cell reselection parameter broadcast in SIB3:
• q-Hyst is populated with the value of CellSelectionReselectionConf::qHyst +

CellReselectionAdaptation::qHystDelta
• threshServingLow is populated with the value of
CellSelectionReselectionConf::threshServingLow +
CellReselectionAdaptation::threshServingLowDelta
• threshServingLowQ-r9 is populated with the value of
CellSelectionReselectionConf::threshServingLowQ +
CellReselectionAdaptation::threshServingLowQDelta
• s-NonIntraSearch is populated with the value of
CellSelectionReselectionConf::sNonIntraSearch +
CellReselectionAdaptation::sNonIntraSearchDelta
• s-NonIntraSearchP-r9 is populated with the value of
CellSelectionReselectionConf::sNonIntraSearchP +
CellReselectionAdaptation::sNonIntraSearchPDelta
• s-NonIntraSearchQ-r9 is populated with the value of
CellSelectionReselectionConf::sNonIntraSearchQ +
CellReselectionAdaptation::sNonIntraSearchQDelta
L115203 also includes a parameter

CellSelectionReselectionConf::autoReselectValueTagChange to allow operator to
determine whether the systemInformationTag broadcast in SIB1 will be modified when load
based adjustments are made to the relection parameters. The handling of the value tag for
all SIB parameter changes other than the ones that can be adjusted by L115203 remains
the same as before L115203.
Page 130/543
Volume 6 : Mobility
CellSelectionReselectionConf::autoReselectValueTagChange
Parameter autoReselectValueTagChange

[true, false]
Value true
Feature L115203
Note: This parameter indicates whether systemInformationValueTag broadcast in SIB1 will
be updated due to cell load based reselection parameters changes.
5 EVOLVED MULTI-CARRIER TRAFFIC

ALLOCATION (EMCTA)
5.1 EMCTA OVERVIEW
eMCTA is a proprietary ALU mobility management framework in the eNodeB used for
allocating the traffic efficiently for LTE sessions across multiple RAT and multiple LTE RF
carriers based on enhanced triggers.
eMCTA supports the mobility management of inter-frequency LTE neighboring carriers,
inter-RAT GERAN neighboring carriers, inter-RAT UTRAN neighboring carriers, inter-RAT
CDMA2000 HRPD neighboring carriersand Inter-RAT CDMA2000 1xRTT neighboring
carriers.
eMCTA is invoked only in the RRC-Connected Mode.
eMCTA also evaluates measurement gap needs for each candidate RAT/carrier.
When invoked, the eMCTA Framework takes the ‘Neighbor RAT/Carrier List’ from eNB
configuration data; applies filters to it; and generates a ‘Candidate RAT/Carrier List’, sorted
by RAT/carrier priority, as its output.
The RRC Measurement Configuration function uses the ‘Candidate RAT/Carrier List’ to
configure RRC Measurements towards the UE to measure potential target carriers. The
RRC measurement configuration function also triggers the most appropriate mobility
procedure to the best target carrier.
The interfaces to eMCTA are shown in Figure 25below.
Page 131/543
Volume 6 : Mobility
Preventive Load Control

Reactive Load Control (new in LA5.0) Configured RAT/Carrier
ANR for UTRA/inter-freq Neighbors:
Lte / UtraFdd / Geran /
RRC Measurement Reports HrpdNeighboring
(A2-CA/A2_Floor)
(triggers radio mobility) Measurement-Based Mobility
S1AP Fallback Indicator IE (1) Measured Candidate RAT/Carriers
(triggers CS Fallback) RRC Measurement (sorted) (2)
Process eMCTA
Inter-Freq/Inter-RAT Blind Mobility
Blind Candidate RAT/Carriers
Framework
measurements config.
(sorted)
One single best

carrier is selected for UE Capabilities
(3) blind redirection.
Mobility
Procedures SRVCC
Cell Change Order

Redirection
Inter-Frequency PS Handover
Handover
2
Figure 25 eMCTA Interfaces
eMCTA consists of algorithms which have the purpose of generating a list of RAT/carriers
suitable for RRC Measurements, sorted in a prioritzed order, in response to a mobility
trigger. eNB configuration parameters are used by eMCTA that influence the selection of
suitable RAT/Carriers and their order of priority.
Figure 26 below provides an overview of the eMCTA framework using hypothetical LTE,
UTRAN, and GERAN RAT neighbors configured in eNB data for a given LTE serving cell.
Page 132/543
Volume 6 : Mobility
OUTPUT:
INPUT: Candidate RAT/Carrier List
RAT/Carrier Neighboring eMCTA FILTERS
Sorted with a Priority shown
eMCTA TRIGGERS eNB Data of ServingCell by
LTE carrier-1 UECapabilitie LTE carrier-1 2

s
CS LTE carrier-2
LTE carrier-2
Fallback
LTE carrier-3 Mobility Path LTE carrier-3
Information
Serving Radio
Monitoring
LTE carrier-4 LTE carrier-4 1
NetworkCapa UTRAN carrier-1
UTRAN carrier-1
bilities 3
UTRAN carrier-2 UTRAN carrier-2
Reactive Load Service
Control Based Policy UTRAN carrier-3
UTRAN carrier-3 4
Preventive GERAN carrier-1 GERAN carrier-1
Load Control QCI-Based
(new in LA5.0) GERAN carrier-2 Policy GERAN carrier-2 5
GERAN carrier-3 Frequency GERAN carrier-3
Load (new in
These two filters LA5.0)
useMobilityPriorityTabl
eparameters to prioritize
RAT/carriers.
RAT/Carriers which do not pass eMCTA filtering are excluded as candidates for mobility.
Figure 26: Overview of eMCTA Framework
eMCTA can be invoked by the following triggers:

 Circuit-Switched Fallback (CSFB) via CSFB Indicator from the MME,
 Serving Radio Monitoring via RRC Measurements.
 Offload UE upon Reactive Load Control triggered by eNB Radio CAC (refer to
Volume 4 for details).
 ANR for selection of FDD-UTRA and inter-frequency carriers for ANR
measurements using the eMCTA framework. The details of ANR are provided in
section 11 of this volume.
 Offload UE upon Preventive Load Control triggered by eNB Radio CAC (refer to
Volume 4 for details). This is a new trigger introduced by feature L115223 in
LA5.0.0 (based on semi-static PRB consumption), complemented by features
171232 (based on real PRB consumption and DL throughput degradation) and
163172 (based on number of connected UEs), available in LR13.3.
eMCTA applies the following filters to the configured RAT/Carrier neighbors of the LTE
serving cell:
 UE Capabilities – based on the UE Capabilities.
Page 133/543
Volume 6 : Mobility
 Mobility Path Information – based on RATs forbidden for Handover as indicated by
the S1AP Handover Restriction List IE and in LA5.0.0 there are additional mobility
restrictions applicable to IMS VoIP calls.
 Network Capabilities – based on other RAT network capabilities as configured in
eNodeB data.
 Service Based Policy – indicates the type of service supported by a call, for which
the RAT/carrier allocation is optimized. As of LA5.0.0, only CSFB services are
supported. Therefore, this filter is used only when the eMCTA trigger is CSFB.
 QCI Based Policy – used for all cases except CSFB and ANR triggers. This filter
allows operator configuration of mobility target optimization based on a QCI value
of the call.
 Frequency Load – based on the load of neighbouring LTE and UTRAN carriers and
associated cells.
The particular algorithm used by each of these filters is dependent on the specific trigger
invoking eMCTA, which is explained in later sections.
The output of the eMCTA framework is a ‘Candidate RAT/Carrier List’ which is a list of
suitable RAT/Carriers sorted in order of highest to lowest priority. This list indicates for
each candidate RAT/carrier:
 Target Measurement Configuration (B1, B2, A4, A5, or none for blind)
 Priority (0-lowest through 7-highest)
 Whether a Measurement Gap needs to be configured (yes, no)

The ‘Candidate RAT/Carrier List’ is used for selecting RAT/Carrier candidates for RRC
Measurement configuration or blind mobility targets
Figure 27 below provides an overview of the RRC Measurement configuration following the
example in Figure 26.
Page 134/543
Volume 6 : Mobility
eMCTA Sorted Candidates Prioritized Configured

for Measurement RRC Measurements
Configuration
Intra-frequency
(1) Intra freq (A3) measurements have
highest priority.
(2) Intra freq (A1)
(1) LTE carrier-4 (3) LTE carrier-4 (A5)

eMCTA Measurements
(2) LTE carrier-1 (4) LTE carrier-1 (A5) follow.
(3) UTRAN carrier-1 (5) UTRAN carrier-1 (B2)

Lowest priority eMCTA
UTRAN carrier-3 measurements may be
(4) UTRAN carrier-3
truncated (not
(5) GERAN carrier-2 configured) for UE
GERAN carrier-2
performance reasons.
Two parameters determine whether the candidate eMCTA measurement list needs to be truncated:
maxMeasIdForMultipleMonitoring(refer to section 5.2.4)
maxNbCarriersForMultipleMonitoringUsingMeasGaps (refer to section 5.2.4)
Measurements to be configured for eMCTA may then be separated into Priority Groups if feature 115204 (Enhanced
Measurement Parameters, introduced in LA5.0) is enabled. Refer to section 12.1 for details.
Figure 27: Overview of eMCTA RRC Measurement Configuration process
The RRC Measurement Process uses the ‘Candidate RAT/Carrier Sorted List’ to configure
RRC Measurements toward the UE. Measurement Gaps are also configured as needed.
In the case of blind mobility, the best target carrier is selected from the ‘Blind Candidate
RAT/Carriers List’ for blind redirection.
5.2 SUMMARY OF UE MEASUREMENT CONFIGURATIONS
5.2.1 EVENT TYPES AND TRIGGERING CONDITIONS

All of the intra-LTE and inter-RAT RRC connected mode mobility procedures are UE
measurement based with the exception of blind redirections. For a UE to send
measurement reports that trigger mobility procedures under certain RF conditions, eNB
configures the UE to perform measurements on selected candidate RAT/carriers and
provides the offsets/thresholds to be used by the UE to trigger the measurement reports.
LTE supports seven UE measurement events to be used in different neighbor settings and
for different measurement purposes. The seven events include event A1, event A2, event
A3, event A4, event A5, event B1 and event B2:
 Event A1 – UE sends measurement reports when serving is better than a threshold
value
Page 135/543
Volume 6 : Mobility
 Event A2 – UE sends measurement reports when serving is worse than a
threshold value
 Event A3 – UE sends measurement reports when LTE neighbor becomes offset
better than serving
 Event A4 – UE sends measurement reports when LTE neighbor is better than a
threshold value
 Event A5 – UE sends measurement reports when serving becomes worse than
threshold1 and neighbor becomes better than threshold2
 Event B1 – UE sends measurement reports when inter-RAT neighbor becomes
bettter than threshold
 Event B2 – UE sends measurement reports when servign becomes worse than
threshold1 and inter-RAT neighbor becomes better than threshold2
5.2.1.1 EVENT A1
When event A1 is configured, UE will send measurement reports when the serving cell
becomes better than a threshold value. In ALU eNB, event A1 is used to configure UE to
perform serving radio condition exiting coverage alarm measurements (refer to section
5.2.2).
Event A1 entering condition:

Ms >thresholdEutraRsrp/thresholdEutraRsrq + hysteresis
Event A1 leaving condition:
Ms <thresholdEutraRsrp/thresholdEutraRsrq - hysteresis
Where:
 Ms: the measurement result of the serving cell
 hysteresis: defined in reportConfigEUTRA::hysteresis
 thresholdEutraRsrp: is used if Ms is measured in RSRP, and is defined
inreportConfigEUTRA::thresholdEutraRsrp
 thresholdEutraRsrq: is used if Ms is measured in RSRQ, and is defined
inreportConfigEUTRA::thresholdEutraRsrq
Besides the parameters listed above, the other parameters that will have impacts to event
A1 UE measurement report include timeToTrigger, reportQuantity,
reportAmountdefined under ReportConfigEutra MO, and reportOnLeave (hard coded to
‘No’ in ALU eNB). Figure 28 illustrates the parameters related to event A1 reporting.
Page 136/543
Volume 6 : Mobility
Figure 28 Event A1 Reporting
5.2.1.2 EVENT A2
When event A2 is configured, UE will send measurement reports when the serving cell
becomes worse than a threshold value. In ALU eNB, event A2 is used to configure UE to
perform serving radio condition entering coverage alarm and below serving floor
measurements (refer to section 5.2.2).

Where:
Page 137/543
Volume 6 : Mobility
A2 UE measurement report include timeToTrigger, reportQuantity, reportAmount
defined under ReportConfigEutra MO, and reportOnLeave (hard coded to ‘No’ in ALU
eNB). Figure 29 Event A2 Reporting illustrates the parameters related to event A2
reporting.
5.2.1.3 EVENT A3
When event A3 is configured, UE will send measurement reports when the neighbor cell
becomes offset better than the serving cell. In ALU eNB, event A3 may be used to trigger
intra-frequency/inter-frequency HO, inter-frequency redirection and intra-frequency/inter-
frequency ANR.

Mn + offset > Ms + hysteresis

Mn + offset < Ms – hysteresis
Page 138/543
Volume 6 : Mobility
offset = cellIndividualOffset_n + offsetFreq_n - cellIndividualOffset_s - offsetFreq_s –
eventA3Offset
Where:
 Mn: measurement result of the neighbor cell
 Ms: measurement result of the serving cell
 eventA3Offset: defined in reportConfigEUTRA::eventA3Offset
 cellIndividualOffset_s: defined in
LteNeighboringCellRelation::cellIndividualOffset corresponding to serving
frequency
 cellindividualOffset_n: defined in
LteNeighboringCellRelation::cellIndividualOffsetcorresponding to neighbor
frequency
 offsetFreq_s: defined in MeasObjectEutra::offsetFreq corresponding to serving
frequency
 offsetFreq_n: defined in MeasObjectEutra::offsetFreq corresponding to neighbor
frequency
eNB).
Figure 30 illustrates the parameters related to event A3 reporting.
Page 139/543
Volume 6 : Mobility
5.2.1.4 EVENT A4
When event A4 is configured, UE will send measurement reports when the neighbor cell
becomes better than a threshold value. Event A4 is mainly used to configure UE to perform
measurements on inter-frequency carriers for offloading purpose. It may also be used to
configure UE for intra-frequency/inter-frequency ANR measurements.

Mn + offset >thresholdEutraRsrp/thresholdEutraRsrq + hysteresis
Mn + offset<thresholdEutraRsrp/thresholdEutraRsrq - hysteresis
offset = cellIndividualOffset_n + offsetFreq_n
Where:
Page 140/543
Volume 6 : Mobility
frequency
frequency
eNB). Figure 31 illustrates all of parameters in event A4 reporting.
5.2.1.5 EVENT A5
When event A5 is configured, UE will send measurement reports when the serving
becomes worse than threshold1 and inter-frequency neighbor cell becomes better than
threshold2. Event A5 may be used to configure UE to perform inter-frequency
redirection/HO and inter-frequency ANR.
Event A5 entering condition 1:

Page 141/543
Volume 6 : Mobility
Event A5 entering condition 2:
Mn + offset >threshold2EutraRsrp/threshold2EutraRsrq + hysteresis
Event A5 leaving condition 1:
Event A5 leaving condition 2:
Mn + offset <threshold2EutraRsrp/threshold2EutraRsrq - hysteresis
offset = cellIndividualOffset_n + offsetFreq_n
Where:
 Ms: measurement result of serving cell
 Mn: measurement result of neighbor cell
 hysteresis: defined in ReportConfigEutra::hysteresis
 thresholdEutraRsrp/thresholdEutraRsrq: defined
inReportConfigEutra::thresholdEutraRsrq/thresholdEutraRsrq
 threshold2EutraRsrp/threshold2EutraRsrq: defined
inReportConfigEutra::threshold2EutraRsrp /threshold2EutraRsrq
frequency
frequency
 thresholdEutraRsrp/threshold2EutraRsrp: used if RSRP used for Mn, Ms
 thresholdEutraRsrq/threshold2EutraRsrq: used if RSRQ used for Mn, Ms
eNB). Figure 32 illustrates all of parameters in event A5 reporting.
Page 142/543
Volume 6 : Mobility
5.2.1.6 EVENT B1
When event B1 is configured, UE will send measurement reports when the inter-RAT
neighbor cell becomes better than a threshold value. Event B1 is used to configure UE to
perform inter-RAT measurements for CS fallback to UTRAN or GERAN, and for offloading.
Event B1 entering condition:
Mn + offsetFreqInterRAT > thresholdInterRAT + hysteresis
Event B1 leaving condition:
Mn + offsetFreqInterRAT < thresholdInterRAT - hysteresis
Where:
 Mn: measurement result of the neighbor cell
 hysteresis: defined in
ReportConfigUTRA/ReportConfigGERAN/ReportConfigCDMA2000::hysteresi
s
 offsetFreqInterRAT: defined in MeasObjectUTRA::offsetFreqUTRA or
MeasObjectGERAN::offsetFreqGERAN or MeasObjectCDMA2000::offsetFreq
 thresholdInterRAT: defined in
ReportConfigUTRA::thresholdUtraRscp/thresholdUtraEcN0 or
ReportConfigGERAN::thresholdGeran or
ReportConfigCDMA2000::thresholdCDMA2000
Page 143/543
Volume 6 : Mobility
B1 UE measurement report include timeToTrigger, reportQuantity, reportAmount
eNB). Figure 33 illustrates all of parameters in event B1 reporting.
Figure 33 Event B1 Reporting
5.2.1.7 EVENT B2
When event B2 is configured, UE will send measurement reports when the serving
becomes worse than threshold1 and inter-RAT neighbor cell becomes better than
threshold2. Event B2 is used to configure UE to perform inter-RAT measurements for
mobility.
Event B2 entering condition 1:
Ms <thresholdEutraRsrpB2/thresholdEutraRsrqB2- hysteresis
Event B2 entering condition 2:
Mn + offsetInterRAT > thresholdInterRAT + hysteresis
Event B2 leaving condition 1:
Ms >thresholdEutraRsrpB2/thresholdEutraRsrqB2 + hysteresis
Event B2 leaving condition 2:
Mn + offsetInterRAT < thresholdInterRAT - hysteresis
Page 144/543
Volume 6 : Mobility
Where:
 Ms: measurement result of serving cell
 Mn: measurement result of neighbor cell
 hysteresis: defined in
ReportConfigUtra/ReportConfigGERAN/ReportConfigCDMA2000::hysteresis
 thresholdEutraRsrpB2/thresholdEutraRsrqB2: defined
inReportConfigUTRA/ReportConfigGERAN/ReportConfigCDMA2000::
thresholdEutraRsrpB2/thresholdEutraRsrqB2
 offsetFreqInterRAT: defined in MeasObjecUTRA::offsetFreqUTRA
orMeasObjecGERAN::offsetFreqGERAN orMeasObjecCDMA2000::offsetFreq
 thresholdInterRAT: defined in
ReportConfigUTRA::thresholdUtraRscp/thresholdUtraEcN0, or
ReportConfigGERAN::thresholdGeran, or
ReportConfigCDMA2000::thresholdCDMA2000
B2 UE measurement report include timeToTrigger, reportQuantity, reportAmount
eNB). Figure 34 illustrates all of parameters in event B2 reporting.
Figure 34 Event B2 Reporting
Page 145/543
Volume 6 : Mobility
5.2.2 SERVING RADIO CONDITION AND UE MEASUREMENT
CONFIGURATION
Based on its serving radio condition, UE can be in one of the three conditions: in good
radio condition (green), in alarm radio condition (yellow) or in red radio condition (red). UE
is configured to perform different measurement configurations under different radio
conditions. UE measurement configuration procedure is described as below.
Figure 35 Serving Radio Condition and UE Measurement Configurations
UE is configured to perform the following measurements for the life of the call until UE
moves out of the serving cell:
a. Event A3 intra-LTE intra-frequency measurement with measurementPurpose =

Mobility-Intra-Freq). If eNB receives event A3 measurement report from UE, an intra-
LTE intra-frequency handover will be triggered to the best cell reported by UE. Intra-
LTE intra-Frequency handover trigger has higher priority than any intra-LTE inter-
frequency or inter-RAT mobility triggers if received simultaneously.
b. Event A2 measurements with measurementPurpose = Below-Serving-Floor. If eNB
receives event A2 measurement report from UE with measurementPurpose =
Below-Serving-Floor, UE entersbad radio condition (red) as shown in step 3 ofFigure
35, a blind redirection will be triggered immediately to the target RAT/carrier selected
by eMCTA framework.
When UE enters good radio condition (green) area, in addition to the life time
measurements in step a. and b., eNB will configure and de-configure UE for the following
measurement:
c. De-configure event A1 measurement with measurementPurpose = Leaving-

Coverage-Alarm if UE is currently configured to perform event A1 measurement.
Page 146/543
Volume 6 : Mobility
d. De-configure all event A5/A3 measurement with measurementPurpose = Mobility-
Inter-Freq-to-EUTRA if configured.
e. De-configure all event B2 measurement with measurementPurpose = Mobility-Inter-
RAT-to-UTRA and/or Mobility-Inter-RAT-to-GERAN and/or Mobility-Inter-RAT-to-
HRPD if configured
f. Configure event A2 measurements with measurementPurpose = Entering-
Coverage-Alarm.
If eNB receives event A2 measurement report with measurementPurpose =

Entering-Coverage-Alarm, UE is moving into alarmradio condition (yellow) area as
shown in step 1 of Figure 35.
When UE enters alarm radio condition (yellow) area, in addition to the life time
measurements in step a. and b., eNB will configure and de-configure UE for the following
measurements:
g. De-configure event A2 measurements with measurementPurpose = Entering-

Coverage-Alarm.
h. Configure event A1 measurement with measurementPurpose = Leaving-Coverage-
Alarm.
i. Configure event A5/A3 measurements with measurementPurpose = Mobility-Inter-
Freq-to-EUTRA for all intra-LTE inter-Frequency candidates selected by eMCTA
framework.
j. Configure event B2 measurements with measurementPurpose = Mobility-Inter-
RAT-to-UTRA and/or Mobility-Inter-RAT-to-GERAN and/or Mobility-Inter-RAT-to-
HRPD for all inter-RAT candidates selected by eMCTA framework.
If eNB receives event A5/A3 measurement report for intra-LTE inter-frequency handover
or event B2 measurement report for inter-RAT mobility, intra-LTE inter-frequency
handover or inter-RAT mobility (PS handover/redirection to UTRA or CCO/redirection to
GERAN, or redirection to HRPD) will be triggered.
If eNB receives event A1 measurement report with measurementPurpose = Leaving-

Coverage-Alarm, UE is moving back into goodradio condition (green) area as shown in
step 2 ofFigure 35.
In above UE measurement configuration procedure step j, for the GERAN candidates that
are selected by eMCTA framework to be measured, eNB will configure UE to perform
event B2 measurements with measurement purpose = ‘Mobility-Inter-RAT-to-GERAN’.
UE will be triggered to send event B2 measurement report if radio condition of the serving
becomes worse than the configurable parameter
thresholdEutraRsrpB2/thresholdEutraRsrqB2 and radio condition of the GERAN target
becomes better than the configurable parameter thresholdGeran. Refer to section 5.2.3.3
of LPUG Volume 6 for introduction to event B2.
When the eNB receives a UE event B2 or event B1 (for CS fallback) measurement report
for the measurement purpose of ‘Mobility-Inter-RAT-to-GERAN’, if UE supports CCO and
ActivationService::isGeranCcoAllowedis set to ‘True’, LTE to GERAN cell change order
specified in section 6.3.3 of LPUG Volume 6 will be triggered. Otherwise, LTE to GERAN
measurement based redirection specified in section 6.2 of LPUG Volume 6 will be
triggered.
In above UE measurement configuration procedure step b, if a GERAN carrier is selected

as the blind redirection target, LTE to GERAN blind redirection procedured specified in
section 6.2 of LPUG Volume 6 will be triggered.
To support event B2 measurement configuration, operator should configure one or multiple

instances of MeasurementIdentityConf with measurementPurpose set to ‘Mobility-Inter-
RAT-to-GERAN’ and measObjectLink and reportConfigLink pointing to the properly
Page 147/543
Volume 6 : Mobility
configured MeasObjectGERAN instance (with valid geranARFCNList as provisioned in a
GeranNeighboringFreqsConf instance) and the ReportConfigGERAN instance (with
triggerTypeInterRAT set to ‘eventB2’). Operator should also configure one or multiple
instances of RrcMeasurementConf with measurementIdentityConfIdList including one
or multiple instances of MeasurementIdentityConf with measurementpurpose set to
‘Mobility-Inter-RAT-to-GERAN’. Refer to Figure 80 for inter-RAT mobility configuration
model.
Parameter settings of MeasurementIdentityConf,MeasObjectGERAN,

ReportConfigGERAN, andRrcMeasurementConf can be found in section 4.2.5, 6.2.3.1,
6.2.4.2 and 6.2.4.3, and 6.2.4.1 of LPUG Volume 6.
5.2.3 MEASUREMENT GAPS

eMCTA evaluates the need for Measurement Gaps. Measurement Gaps (MG) are periods
that the UE uses to perform measurements on LTE frequencies different from the serving
frequency or other non-LTE RAT carrier frequencies.
The need for MG by the UE is specified in the UE Capabilities (single-receiver UEs need
MG, dual-receiver UEs do not need MG). For each selected inter-RAT carrier or inter-
frequency LTE carrier, eMCTA determines the MG need based on the information in the
UE Capabilities for the carrier band
Parameter isMeasurementGapsAllowed set to ‘True’ allows the eNB to configure MG for
RAT/Carriers which need MG. A RAT/Carrier will be excluded (i.e. its measurement will be
not configured) if it needs MG but isMeasurementGapsAllowedis set to ‘False’
ActivationService::isMeasurementGapsAllowed
Parameter isMeasurementGapsAllowed

[false, true]
Value S e e e n g in e e rin g re c o m m e n d a tio n
Feature L93270
Engineering Recommendation: isMeasurementGapsAllowed

is Me a s ure me n tGa p s Allo we d s h o u ld b e s e t to ‘tru e ’ wh e n th e e No d e B is
c o n fig u re d to a c tiva te IRAT m o b ility to UTRAN o r GERAN, o r IRAT m o b ility to
HRP D, 1xRTT, o r in te r-fre q u e n c y to EUTRAN m o b ility.
Th e d e fa u lt va lu e is ‘fa ls e ’.
The measurement gap configuration is sent to the UE via RRC signaling. Key parameters
are:
Page 148/543
Volume 6 : Mobility
• GAP Length: thisis the length of the gap and it is fixed to 6ms by 3GPP. It is not
configurable. The UE can measure one frequency at each 6 ms gap.
• GAP Periodicity: thisis the interval between two measurement gaps. Measurement
gap occurs periodically with this period. This parameter may be configured per
RAT/carrier to 40ms or 80ms, except for the CSFB case where GAP periodicity is
always 40ms.
• GAP Offset: this indicates which sub-frame marks the start of the measurement
gap. It is determined by the Scheduler at each measurement gap activation. See
Volume 4 for details.
MG length = 6 ms MG offset
MG repetition period = 40 ms
MG repetition period = 80 ms
Parameter RrcMeasurementConf::measurementGapsPattern configures the MG period.

The MG period is configurable to either 40 ms (value ‘length6ms_period40ms’ or 80 ms
(value ‘length6ms_period80ms’). Only one gap pattern can be configured per RAT/carrier.
However, if measurements for multiple RAT/carriers requiring MG are configured, it is
possible to have both 40ms and 80ms MG periods active at the same time. Each
configured instance of a MeasurementIdentityConf object for inter-RAT and inter-frequency
measurements may be configured with its own gap period.
RrcMeasurementConf::measurementGapsPattern
Parameter measurementGapsPattern
Object ENBEquipment/Enb/ RrmServices/ UeMeasurementConf/

RrcMeasurementConf

[length6ms_period40ms, length6ms_period80ms]
Value length6ms_period40ms
Feature L93270
The value length6ms_period80ms would be set if the operator prefers to increase the user
data resource while measurement gap is activated, although this means that
measurements would be performed less frequently which could impact handover
performance.
Page 149/543
Volume 6 : Mobility
Rule: Regarding measurementGapsPattern
Parameter measurementGapsPatternis a combination of the Measurement

Gap Duration and the Measurement Gap Period. The Gap Duration is always
fixed at 6 ms per 3GPP specifications. The Gap Period is variable and can be
set to either 40 ms (length6ms_period40ms) or 80 ms (length6ms_period80ms).
The Measurement Gap Period is forced to 40ms when requested by a CSFB
trigger. The reason for this specific handling is to speed up the CSFB processing
as much as possible (high priority procedure). The shortest pattern allows longer
duration for the UE to perform the measurements (7.5% of time for 80ms against
15% of time for 40ms). Therefore, the operator setting of parameter
measurementGapsPatternis ignored for the case of MG triggered by CSFB.
The Measurement Gap Period is forced to 80ms when UE is in TTI Bundling
Mode. The longer period allows more opportunities for scheduling of TTI
Bundling packets.
The following cases are relevant:
Case 1) MG activation on any trigger except CSFBand UE is not in TTI Bundling
mode:
Gap Period = 40ms or 80ms => value determined by parameter
measurementGapsPattern.
Case 2) MG activation on CSFB trigger, where MG not already activated:
Gap Period = 40 ms, measurementGapsPattern parameter value is
not used.
Case 3) MG activation on CSFB trigger, where MB already activated by a
previous trigger:
The current activated Gap Period (80ms or 40ms) is kept.

Case 4) MG activation while UE is in TTI Bundling mode:
Gap Period = 80 ms, measurementGapsPattern parameters value is
ignored.
5.2.4 EMCTA CANDIDATE MEASUREMENT TRUNCATION

The sum of the intra-frequency, inter-frequency and inter-RAT measurements configured
toward the UE cannot exceed maxMeasId = 32 per 3GPP. The operator can limit the total
number of inter-frequency and inter-RAT measurements to a smaller sum for UE
performance reasons by the setting of parameter maxMeasIdForMultipleMonitoring. If
the total number of eMCTA candidate measurements (inter-frequency and inter-RAT)
exceeds this parameter value, then RRC Measurement Configuration removes the
candidates with the lowest priority in the candidate list. Thisis shown in Figure 27.
If maxMeasIdForMultipleMonitoringis set to ‘0’ or <unset>, then the eNodeB will not
configure any inter-frequency nor inter-RAT measurements. This parameter does not
Page 150/543
Volume 6 : Mobility
affect the intra-frequency measurements since intra-frequency measurements are never
removed. In addition, if both mobility and ANR measurements are candidates to be
configured on a given RAT/carrier, precedence is given to ANR.
RrcMeasurementConf::maxMeasIdForMultipleMonitoring
Parameter maxMeasIdForMultipleMonitoring

RrcMeasurementConf

[0..28] step = 1
Value O.D.
Feature L106136
Rule: Regarding maxMeasIdForMultipleMonitoring
This parameter must be set to a value > 0 under any of the following conditions:
 isInterFreqEutraSameFrameStructureMobilityAllowed = True, and the
LteCell has at least one associated MeasurementIdentityConf instance
whose measurementPurpose is set to ‘Mobility-Inter-Freq-to-EUTRA’, and
at least one inter-frequency LteNeighboringFreqConf object exists on the
LteCell.
 isCsFallbackToUtraAllowed = True or isMobilityToUtranAllowed =
True or isPsHoToUtraAllowed = True, and the LteCell has at least one
associated MeasurementIdentityConfinstance whose
measurementPurpose is set to ‘Mobility-Inter-RAT-to-UTRA’, and at least
one UtraFddNeighboringFreqConf object exists on the LteCell.
 isCsFallbackToGeranAllowed = True or isGeranCcoAllowed = True or
isMobilityToGeranAllowed = True, and the LteCell has at least one
measurementPurpose is set to ‘Mobility-Inter-RAT-to-GERAN’, and at
least oneGeranNeighboringFreqsConf object exists on the LteCell.
 isHrpdMeasBasedRedirAllowed = True or isMobilityToHrpdAllowed =
True, and the LteCell has at least one associated
MeasurementIdentityConf instance whose measurementPurpose is set to
‘Mobility-Inter-RAT-to-HRPD’, and at least one
HrpdNeighboringPerCarrier object exists on theLteCell.
The UE will be capable of monitoring using gaps a total of at least 7 carrier frequency
layers comprising of any allowed combination of E-UTRA FDD, E-UTRA TDD, UTRA FDD,
UTRA TDD and GSM layers (one GSM layer corresponds to 32 cells), cdma2000 and
HRPD layers. Parameter maxNbCarriersForMultipleMonitoringUsingMeasGaps allows
the operator to restrict the total number of eMCTA candidate measurements that need a
MG for UE performance reasons. If the total number of eMCTA candidate measurements
that need a MG exceeds this parameter value, then the lowest priority ones that use a MG
are removed. Thisis shown in Figure 27. If this parameter is set to ‘0’ or <unset>, then the
Page 151/543
Volume 6 : Mobility
eNodeB will not configure any inter-frequency nor inter-RAT measurements that need a
MG.
RrcmeasurementConf::maxNbCarriersForMultipleMonitoringUsingMeasGaps
Parameter maxNbCarriersForMultipleMonitoringUsingMeasGaps

RrcMeasurementConf

[0..7] step = 1
Value O.D.
Feature L106136
Rule: Regarding maxNbCarriersForMultipleMonitoringUsingMeasGaps
This parameter must be set to a value > 0 under any of the following conditions:
 isMeasurementGapsAllowed = True
andisInterFreqEutraSameFrameStructureMobilityAllowed = True, and
the LteCell has at least one associated MeasurementIdentityConf
instance whose measurementPurpose is set to ‘Mobility-Inter-Freq-to-
EUTRA’, and at least one inter-frequency LteNeighboringFreqConf object
exists on the LteCell.
 isMeasurementGapsAllowed = True and
isCsFallbackToUtraAllowed = True or isMobilityToUtranAllowed =
True or isPsHoToUtraAllowed = True, and the LteCell has at least one
measurementPurpose is set to ‘Mobility-Inter-RAT-to-UTRA’, and at least
one UtraFddNeighboringFreqConf object exists on the LteCell.
isCsFallbackToGeranAllowed = True or isGeranCcoAllowed = True or
isMobilityToGeranAllowed = True, and the LteCell has at least one
measurementPurpose is set to ‘Mobility-Inter-RAT-to-GERAN’, and at
least oneGeranNeighboringFreqsConf object exists on the LteCell.
isHrpdMeasBasedRedirAllowed = True or isMobilityToHrpdAllowed =
True, and the LteCell has at least one associated
MeasurementIdentityConf instance whose measurementPurpose is set to
‘Mobility-Inter-RAT-to-HRPD’, and at least one
HrpdNeighboringPerCarrier object exists on theLteCell.
For 1xCSFB, eMCTA will provide a list of candidate1xRTT bands/frequencies for UE to

perform measurements. The maximum number of bands/frequencies in the candidate list is
limited by Enb::maxNumberOfCdmaChannelFor1xCsfbMeasurements in addition to the
limitations of RrcMeasurementConf::maxMeasIdForMultipleMonitoring and
RrcMeasurementConf::maxNbCarriersForMultipleMonitoringUsingMeasGaps.
Page 152/543
Volume 6 : Mobility
Enb::maxNumberOfCdmaChannelFor1xCsfbMeasurements
Parameter maxNumberOfCdmaChannelFor1xCSFBMeasurements
Object ENBEquipment/ Enb
Range & Unit Integer step = 1

[1..6]
Value 1
Feature 134791
Notes: This parameter specifies the maximum number of CDMA channels that can be
configured for 1xCSFB measurements (The current standard allowed maximum value is
5.). This parameter must be set if
ActivationService::isRel8CsfbTo1xRttMeasurementBasedallowed is set to ‘True’, or if
ActivationService::isEnhancedCsfbTo1xRttAllowed is set to ‘True’.
5.3 MOBILITY PRIORITY TABLE

The MobilityPriorityTable is eNB configuration data which is used to optimize the
RAT/Carrier allocation for inter-RAT and intra-LTE inter-frequency mobility management. It
is used by the Service-Based Policy and QCI-based Policy and significantly influences the
priority ordering of eMCTA target RAT/Carrier candidates. The MobilityPriorityTable is
configurable for each RAT/Carrier as highlighted in Figure 36 below. The data structure of
the MobilityPriorityTable is shown in Figure 37 below.
Page 153/543
Volume 6 : Mobility
LteCell
[0..1]
[0..1] [0..1] [0..1]
Lte Utra OneXRtt Geran Hrpd

Neighboring Neighboring Neighboring Neighboring Neighboring
[1..2] [1..2]
OneXRtt Hrpd
[1..9] [0..16] BandClassConf [0..16] BandClassConf
[0..3] [0..3]
UtraFdd OneXRtt Geran

LteNeighboring Neighboring HrpdNeighboring
Neighboring Neighboring
FreqConf PerCarrier PerCarrier
FreqConf FreqsConf
Mobility Mobility Mobility Mobility Mobility

PriorityTable PriorityTable PriorityTable PriorityTable PriorityTable
Figure 36: RAT/Carrier Neighboring configuration with MobilityPriorityTable

.
Page 154/543
Volume 6 : Mobility
Figure 37: MobilityPriorityTable data structure

Parameter isServiceBasedTrafficSegmentationAllowed, when set to ‘true’, enables use
of the Service-Based Policy (ServiceTypePriorityConf data) and QCI-Based Policy
(QciPriorityConf data) to determine the priority per RAT/Carrier. Otherwise, when this
parameter is set to ‘false’, defaultConnectedPriorityOfFreqis used to determine priority.
Parameter isServiceBasedTrafficSegmentationAllowed requires a licensing token
managed by Feature Licensing. It can be set to 'true' only if licensing tokens are available
for feature L106136 (refer to LPUG Volume 2 for details). The licensing of feature L106136
allows the use of both the Service-Based Policy and the QCI-Based Policy.
Page 155/543
Volume 6 : Mobility
ActivationService::isServiceBasedTrafficSegmentationAllowed
Parameter isServiceBasedTrafficSegmentationAllowed

[false, true]
Feature L106136
SAM.
Engineering Recommendation: isServiceBasedTrafficSegmentationAllowed

Parameter isServiceBasedTrafficSegmentationAllowed should be set to ‘true’ for
configurations enabling CS Fallback or upgrading to QCI–Based Policy for traffic
segmentation.
Otherwise, isServiceBasedTrafficSegmentationAllowed should be set to ‘false’.
Page 156/543
Volume 6 : Mobility
MobilityPriorityTable::defaultConnectedPriorityOfFreq
Parameter defaultConnectedPriorityOfFreq
Objects ENBEquipment/Enb/ LteCell/

UtraFddNeigboring/UtraFddNeighboringFreqConf/MobilityPriorityTa
ble
ENBEquipment/Enb/ LteCell/
GeranNeigboring/GeranNeighboringFreqsConf/MobilityPriorityTable
HrpdNeigboring/HrpdBandClassConf/HrpdNeighboringPerCarrier/
MobilityPriorityTable
ENBEquipment/Enb/LteCell/LteNeighboring/LteNeighboringFreqConf
/ MobilityPriorityTable
OneXRttNeigboring/OneXRttBandClassConf/OneXRttNeighboringPerC
arrier/MobilityPriorityTable

[serviceOrQci-not-allowed-in-RAT-carrier, 0-lowest, 1, 2, 3, 4, 5, 6, 7]
Value O.D.
Feature L106136, 103892, 134791
Engineering Recommendation: defaultConnectedPriorityOfFreq

It is recommended to set defaultConnectedPriorityOfFreq to a lower priority for HeNB
cell dedicated carriers than that set for eNB macro/metro cell carriers. It may have lower
successful rate for eNB to HeNB blind redirection and may take longer timer to perform
eNB to HeNB handover.
Rule: Regarding defaultConnectedPriorityOfFreq
This parameter must be <unset> for intra-frequency LTE neighbors.

If isInterFreqEutraSameFrameStructureMobilityAllowed = True, then
defaultConnectedPriorityOfFreq must be set in the MobilityPriorityTable for each
inter-frequency LTE neighbor.
If isCsFallbackToUtraAllowed = True or isMobilityToUtranAllowed = True or
isPsHoToUtraAllowed = True, then defaultConnectedPriorityOfFreq must be
set in the MobilityPriorityTable for each UTRA neighbor.
If isCsFallbackToGeranAllowed = True or isGeranCcoAllowed = True or
isMobilityToGeranAllowed = True, then defaultConnectedPriorityOfFreq must
be set in the MobilityPriorityTable for each GERAN neighbor.
If isRel8CsfbTo1xRttEnabled = True, then defaultConnectedPriorityOfFreq
must be set in the MobilityPriorityTable for each OneXRtt neighbor.
Page 157/543
Volume 6 : Mobility
Parameter eMctaPriorityis used when flag
isServiceBasedTrafficSegmentationAllowedis set to True.
ServiceTypePriorityConf::eMctaPriority
QciPriorityConf::eMctaPriority
Parameter eMctaPriority
Objects ENBEquipment/ Enb/ LteCell/ LteNeighboring/

LteNeighboringFreqConf/ MobilityPriorityTable
ENBEquipment/ Enb/ LteCell/ UtraNeighboring/
UtraFddNeighboringFreqConf/ MobilityPriorityTable
ENBEquipment/ Enb/ LteCell/ GeranNeighboring/
GeranNeighboringFreqsConf/ MobilityPriorityTable
ENBEquipment/Enb/ LteCell/HrpdNeighboring/ HrpdBandClassConf/
HrpdNeighboringPerCarrier/ MobilityPriorityTable
OneXRttNeigboring/OneXRttBandClassConf/OneXRttNeighboringPer
Carrier/ MobilityPriorityTable

[serviceOrQci-not-allowed-in-RAT-carrier, 0-lowest, 1, 2, 3, 4, 5, 6, 7]
Value O.D.
Feature L106136, 103892, 134791

Note: value ‘0-lowest’ is lowest priority and value ‘7’ is highest priority.
ServiceTypePriorityConf/QciPriorityConf::eMctaPriority
It is recommended to set QciPriorityConf::eMctaPriority to a lower priority for HeNB
cell dedicated carriers than that set for eNB macro/metro cell carriers. It may have lower
successful rate for eNB to HeNB blind redirection and may take longer timer to perform
eNB to HeNB handover.
For each instance of UtraFddNeighboringFreqConf that includes an

UtraFddNeighboringSmallCellLayerRelation MO,
ServiceTypePriorityConf::eMctaPriority must be set to ‘serviceOrQci-not-allowed-in-
RAT-carrier’ for all settings of ServiceTypePriorityConf::serviceType including
‘csfbByIdleUE’, ‘emergencyCsfbByIdleUE’, ‘csfbByConnectedUE’, and
‘emergencyCsfbByConnecedUE’.
Rule: Regarding eMctaPriority, defaultConnectedPriorityOfFreq
Equal priorities between RATs are not supported.
Equal priorities within GERAN are supported

Equal priorities within UTRA-FDD are supported
Page 158/543
Volume 6 : Mobility
Equal priorities within HRPD are supported
Equal priorities within OneXRtt are supported
Equal priorities within LTE are supported
In case of equal priorities within the same RAT for CSFB to UTRAN or GERAN
mobility reason trigger:
 ENB configures one measurement for one of the randomly selected
highest priority carriers.
In case of equal priorities within the same RAT for CSFB to 1xRTT mobility reason
trigger:
 ENB configures all the possible measurements in a random order
In case of equal priorities within the same RAT for Below-Serving-Floor radio
condition trigger:
 ENB blindly redirects the call towards one of the randomly selected
highest priority carriers.
In case of equal priorities within the same RAT for all other mobility triggers:
 ENB configures all the possible measurements in a random order
Parameter serviceTypeis used for the Service-Based Policy for CSFB and is applicable to
UTRA-FDD, GERAN or 1xRTTcarriers. Each instance of serviceTypeis assigned a priority
determined by parameter ServiceTypePriorityConf::eMctaPriority. Service Types are
defined as follows:
csfbByIdleUE: UTRAN and GERAN RAT carriers configured with this type are candidates
when S1AP CS Fallback Indicator IE is present in message S1AP INITIAL CONTEXT
SETUP with the value ‘CS Fallback required”. It indicates that a fallback to the CS domain
is required for a UE in RRC idle state before CS Fallback. CSFB indicator prevails over the
RRC establishment cause”.
emergencyCsfbByIdleUE: UTRAN and GERAN RAT carriers configured with this type are
candidates when S1AP CS Fallback Indicator IE is present in message S1AP INITIAL
CONTEXT SETUP with the value ‘CS Fallback High Priority”. It indicates that a fallback to
the CS domain is required for a UE in RRC idle state before CS Fallback. CSBF indicator
prevails over the RRC establishment cause”.
csfbByConnectedUE: UTRAN and GERAN RAT carriers configured with this type are
candidates when S1AP CS Fallback Indicator IE is present in message S1AP UE
CONTEXT MODIFICATION with the value ‘CS Fallback required’. It indicates that a
fallback to the CS domain is required for a UE in RRC connected state before CS
Fallback. CSBF indicator prevails over the RRC establishment cause”.
emergencyCsfbByConnectedUE: UTRAN and GERAN RAT carriers configured with this
type are candidates when S1AP CS Fallback Indicator IE is present in message S1AP UE
CONTEXT MODIFICATION with the value ‘CS Fallback High priority’. It indicates that a
fallback to the CS domain is required for a UE in RRC connected state before CS Fallback.
CSBF indicator prevails over the RRC establishment cause”.
Page 159/543
Volume 6 : Mobility
csfbTo1XRtt: 1XRTT RAT carriers configured with this type are candidates for CS Fallback
to 1XRTT for emergency or non-emergency calls: S1AP CS Fallback Indicator IE is
present in message S1AP INITIAL CONTEXT SETUP REQUEST or S1AP UE CONTEXT
MODIFICATION, regardless the setting of ‘CS Fallback Indicator’.
ServiceTypePriorityConf::serviceType
Parameter serviceType
Objects ENBEquipment/ Enb/ LteCell/ UtraNeighboring/

UtraFddNeighboringFreqConf/ MobilityPriorityTable/
ServiceTypePriorityConf
ENBEquipment/Enb/ LteCell/ GeranNeighboring/
GeranNeighboringFreqsConf/ MobilityPriorityTable/
ServiceTypePriorityConf

[csfbByIdleUE, emergencyCsfbByIdleUE, csfbByConnectedUE,
emergencyCsfbByConnectedUE, csfbTo1XRtt]
Value O.D.
Feature L106136, 103892, 134791
Rule: Regarding serviceType
A given serviceType cannot appear more than once under a given

MobilityPriorityTable.
Rule: Regarding isServiceBasedTrafficSegmentationAllowed,

isCsFallbackTo[Utra/Geran]Allowed, isRel8CsfbTo1xRttEnabled,serviceType
If flag isCsFallbackToUtraAllowed = True and
isServiceBasedTrafficSegmentationAllowed = True:
- ServiceTypePriorityConf::serviceType set to ‘csfbByIdleUE’ must be found

under at least one UtraFddNeighboringFreqConf object.
- ServiceTypePriorityConf::serviceType set to ‘emergencyCsfbByIdleUE’ must
be found under at least one UtraFddNeighboringFreqConf object.
- ServiceTypePriorityConf::serviceType set to ‘csfbByConnectedUE’ must be
found under at least one UtraFddNeighboringFreqConf object.
- ServiceTypePriorityConf::serviceType set to
‘emergencyCsfbByConnectedUE’ must be found under at least one
UtraFddNeighboringFreqConf object.
If flag isCsFallbackToGeranAllowed = True and

isServiceBasedTrafficSegmentationAllowed = True:
- ServiceTypePriorityConf::serviceType set to ‘csfbByIdleUE’ must be found

under at least one GeranNeighboringFreqsConf object.
- ServiceTypePriorityConf::serviceType set to ‘emergencyCsfbByIdleUE’ must
Page 160/543
Volume 6 : Mobility
be found under at least one GeranNeighboringFreqsConf object.
- ServiceTypePriorityConf::serviceType set to ‘csfbByConnectedUE’ must be
found under at least one GeranNeighboringFreqsConf object.
- ServiceTypePriorityConf::serviceType set to
‘emergencyCsfbByConnectedUE’ must be found under at least one
GeranNeighboringFreqsConf object.
If flag isRel8CsfbTo1xRttEnabled = True

isServiceBasedTrafficSegmentationAllowed = True, there must be a
ServiceTypePriorityConf object with serviceType = csfbTo1xRtt under the
MobilityPriorityTable object of at least one OneXRttNeighboringPerCarrier
object.
Parameter qciis used for the QCI-Based Policy for all eMCTA triggers except CSFB. Each
QCI configured by the ENB may be assigned a priority determined by parameter
QciPriorityConf::eMctaPriority. Up to 32 QCI values may be configured as determined
by the number of configured QciPriorityConf instances.
Page 161/543
Volume 6 : Mobility
QciPriorityConf::qci
Parameter qci
Objects ENBEquipment/ Enb/ LteCell/ LteNeighboring/

LteNeighboringFreqConf/ MobilityPriorityTable/
QciPriorityConf
ENBEquipment/ Enb/ LteCell/ UtraNeighboring/
UtraFddNeighboringFreqConf/ MobilityPriorityTable/
QciPriorityConf
ENBEquipment/ Enb/ LteCell/ GeranNeighboring/
GeranNeighboringFreqsConf/ MobilityPriorityTable/
QciPriorityConf
ENBEquipment/ Enb/ LteCell/ HrpdNeighboring/
HrpdBandClassConf/ HrpdNeighboringPerCarrier/
MobilityPriorityTable/ QciPriorityConf
ENBEquipment/ Enb/ LteCell/ OneXRttNeighboring/
OneXRttBandClassConf/ OneXRttNeighboringPerCarrier/
MobilityPriorityTable/ QciPriorityConf

[Qci1, Qci2, Qci3, Qci4, Qci5, Qci6, Qci7, Qci8, Qci9, Qci10,
Qci11, Qci12, Qci13, Qci14, Qci15, Qci16, Qci17, Qci18,
Qci99, Qci100, Qci101, Qci102, Qci103, Qci104, Qci105,
Qci253, Qci254, Qci255]
Page 162/543
Volume 6 : Mobility
Value O.D.
Feature 103892
Parameter qciHierarchyForMultiQciCallListis used for multi QCI calls for all eMCTA
triggers except CSFB. A multi-QCI call is a multi-eRAB call in which some of the eRABs
have a different QCI. It is used by the QCI-Based Policy to manage mobility of multi QCI
calls. The parameter specifies an ordered list of up to 32 QCI values. The QCI value having
the lowest position value in the list (that is, element[0] ) is the most important QCI and the
QCI value having the highest position is the least important QCI. An established QCI with
the lowest position in the list is selected for the RAT/Carrier. The priority assigned to a
RAT/Carrier is the value of eMctaPriority of the qci representing the most important
established QCI found in the list. If no established QCI is found in the list, then parameter
defaultConnectedPriorityOfFreqis used to determine the priority value.
For example, if a RAT/Carrier has the following qciHierarchyForMultiQciCallList
configured: [Qci1, Qci6, Qci2, Qci3] and a multi-eRAB call has both QCI-3 bearers and
QCI-6 bearers established when eMCTA is invoked, then Qci6 is more important because it
has a lower position in the list. The RAT/Carrier will have a priority equal to the value of
eMctaPriority corresponding to qci = Qci6.
Page 163/543
Volume 6 : Mobility
MobilityPriorityTable::qciHierarchyForMultiQciCallList
Parameter qciHierarchyForMultiQciCallList
Objects ENBEquipment/Enb/LteCell/LteNeighboring/
LteNeighboringFreqConf/ MobilityPriorityTable
ENBEquipment/Enb/ LteCell/ UtraNeighboring/
UtraFddNeighboringFreqConf/ MobilityPriorityTable
ENBEquipment/Enb/ LteCell/ GeranNeighboring/
GeranNeighboringFreqsConf/ MobilityPriorityTable
ENBEquipment/Enb/LteCell/HrpdNeighboring/
HrpdBandClassConf/HrpdNeighboringPerCarrier/
ENBEquipment/Enb/LteCell/OneXRttNeighboring/
OneXRttBandClassConf/OneXRttNeighboringPerCarrier/

[Qci1, Qci2, Qci3, Qci4, Qci5, Qci6, Qci7, Qci8, Qci9, Qci10,
Qci253, Qci254, Qci255]
Value O.D.
Feature 103892
Page 164/543
Volume 6 : Mobility
5.4 EMCTA TRIGGERS
5.4.1 CS FALLBACKTO UTRAN AND GERAN

In response to a CS Fallback trigger (reception of S1AP INITIAL CONTEXT SETUP or
S1AP UE CONTEXT MODIFICATION with CS Fallback Indicator IE present), eMCTA
builds a list of candidates by matching configured UTRA-FDD and GERAN neighbors of the
Serving Cell with a configured B1 measurement object, as shown in Figure 38. This
matched list of candidate RAT/carrier neighbors is passed through eMCTA filters.
MeasurementIdentity
UtraFddNeighboring
Conf
UtraFddNeighboring
MeasObjectUTRA ReportConfigUTRA
FreqConf
triggerTypeInterRAT
carrierFreq = carrierFreq
= eventB1
MeasurementIdentity
GeranNeighboring
Conf
GeranNeighboring
MeasObjectGERAN ReportConfigGERAN
FreqsConf
triggerTypeInterRAT
GeranARFCNList = GeranARFCNList
= eventB1
35
Figure 38: CSFB Trigger Neighbor RAT/Carrier Candidates for RRC Measurements
UTRA-FDD and GERAN neighboring RAT/carriers must fulfull the checks performed by the
following eMCTA filters for CSFB:
Page 165/543
Volume 6 : Mobility
 UE Capabilities: UE support of RAT/Carrier frequency band and FGI bit checks
are performed for measurement capabilities.
 Mobility Path Information: checks for restrictions in the Handover Restriction List
IE.
 Network Capabilities: checks for neighbor UTRA RNCs’ support of PS Handover.
 Service-Based Policy: candidates may be prioritized based on service type in
ServiceTypePriorityConf configuration data.
One single best RAT/carrier target is selected for either a Handover (with measurement) or
a Blind Redirection (without measurement).
5.4.1.1 UE CAPABILITIES
The following table summarizes the filter checks of the UE Capabilities (provided by the
UE) for CSFB.
UE Capabilities UtraFdd Geran

Neighboring Neighboring
- Indicates the carriers and RAT To Pass filter (for CSFB via To Pass filter (for CSFB via
supported by the UE blind redirection or via PS blind redirection or via CCO):
- Feature Group Indicator bits HO): - GERAN RAT Carrier must be
indicate RRC Measurements - UTRA FDD RAT Carrier supported.
supported by the UE must be supported. For CSFB via CCO only:
For CSFB via PS HO only: - FGI bit #23 for event B2
FGI bit #22 for event B2 measurement must be set.
measurement must be set. - If FGI bit #15is also
- If FGI bit #15is set (optional but
also set (optional preferred for CSFB
but preferred for mobility), then event
CSFB mobility), B1 measurement can
then event B1 be configured;
measurement can be otherwise event B2 is
configured; configured.
otherwise event B2 - FGI bit #10 must be
is configured. set for CCO.
- FGI bit #8 must be
set for PS HO.
5.4.1.2 MOBILITY PATH INFORMATION
The Mobility Path Information filter performs the following checks on candidate neighboring
cells (except for the case of Emergency CSFB, for which this filter does not apply):
 RATs restricted for handover.
 PLMNs allowed.
 Forbidden LACs.
Page 166/543
Volume 6 : Mobility
The following table summarizes the Mobility Path Information checks which rely on the
information contained in the S1AP Handover Restriction List IE.
Handover UtraFddNeighboring Candidates GeranNeighboring Candidates

Restriction List
‘Forbidden Inter- To Pass filter: To Pass filter:

RATs’ ‘Forbidden inter RATs’ cannotbe set to ‘Forbidden inter RATs’ cannot be set to
‘ALL’, ‘UTRAN’, ‘GERAN and ‘ALL’, ‘GERAN’, or ‘GERAN and
UTRAN’, or ‘CDMA2000 and UTRAN’. UTRAN’.
‘Equivalent To Pass filter: To Pass filter:

PLMNs’ (list) Candidate carrier must have at least one Candidate carrier must have at least one cell
cell with PLMN with PLMN
(RncAccess::plmnMobileCountryCode (BscAccess::plmnMobileCountryCode and
and BscAccess::plmnMobileNetworkCode) in
RncAccess::plmnMobileNetworkCode) ‘Equivalent PLMNs’ list or same PLMN as
in ‘Equivalent PLMNs’ list or same the serving cell.
PLMN as the serving cell.
‘Forbidden To Pass filter: To Pass filter:
LACs’ (list) Candidate carrier does not have all of its Candidate cararier does not have all of its
cells with LAC cells with LAC
(UtraFddNeighboringCellRelation::lac) (GeranNeighboringCellRelation::lac)
belonging to a forbidden LAC in the belonging to a forbidden LAC in the
‘Forbidden LACs’ list. ‘Forbidden LACs’ list.
5.4.1.3 NETWORK CAPABILITIES
The Network Capability filter for CSFB checks the RNC capability for PS-handover.
A measurement towards UTRA FDD for CSFB can be configured only if the neighbor RNC
demonstrates the following capabilities:
RncAccess::psHandoverUtraEnabled set to TRUE.
RncAccess::administrativeState set to UNLOCKED.
If one target UTRA-FDD cell provisioned by the operator for PS handover corresponds to a
target RNC with the administrativeState set to ‘unlocked’ and with a capability to support
the PS handover from EUTRAN to UTRA-FDD; this filter allows the corresponding (UTRA-
FDD; carrier) to be added in E-MCTA candidate list with a measurement purpose set to
Mobility-Inter-RAT-to-UTRA (for CSFB to UTRA-FDD); Else this sub-filter forbids the
corresponding (UTRA-FDD; carrier) to be added in E-MCTA candidate list with a
measurement purpose Mobility-Inter-RAT-to-UTRA (for CSFB to UTRA-FDD).
5.4.1.4 SERVICE-BASED POLICY
eMCTA triggered by CSFB uses the Service-Based Policy for RAT/Carrier priority as
follows:
The parameters under ServiceTypePriorityConf are used to determine priority if:
Page 167/543
Volume 6 : Mobility
 ActivationService::isServiceBasedTrafficSegmentationAllowedis ‘True’. This
setting enables Service Segmentation and requires a licensing token managed by
Feature Licensing.
 And a RAT/Carrier is found with a serviceType that matches the service requested
in CSFallbackIndicator (see description for serviceType under section 5.2).
Otherwise:
 defaultConnectedPriorityOfFreq is used to determine priority.
Example of a ServiceTypePriorityConf configuration:
RAT/Carrie defaultConnectedPriorityOfFr serviceType eMctaPriorit
r Neighbor eq y
UTRA f1 4 csfbByIdleUE 4
csfbByConnectedUE 4
emergencyCsfbByIdleUE 3
emergencyCsfbByConnected 3
UE
UTRA f2 3 csfbByIdleUE 3
csfbByConnectedUE 3
UE
GERAN 1 csfbByIdleUE 1
csfbByConnectedUE 1
UE
Scenario 1:
Incoming S1AP INITIAL CONTEXT SETUP with CS Fallback Indicator IE = ‘cs-fallback-
required’ (this maps to serviceType = csfbByIdleUE) & Service Segmentationis enabled:
Determine priority from serviceType and eMctaPriority.
RAT/Carriers sorted from highest to lowest priority:
UTRA f1,
UTRAN f2,
GERAN
UTRA-FDD carrier-1 is selected for CSFB target.
Scenario 2:
Incoming S1AP UE CONTEXT MODIFICATION with CS Fallback Indicator IE = cs-
fallback-high-priority (this maps to serviceType = emergencyCsfbByConnectedUE &
Service Segmentation is enabled:
Determine priority from serviceType and eMctaPriority
UTRA f2,
UTRA f1,
GERAN
UTRA f2 is selected for CSFB target
Page 168/543
Volume 6 : Mobility
Scenario 3:
Incoming S1AP INITIAL CONTEXT SETUP with CS Fallback Indicator IE = ‘cs-fallback-
high-priority’ (this maps to serviceType = emergencyCsfbByIdleUE) & Service
Segmentationis disabled:
Determine priority from defaultConnectedPriorityOfFreq
UTRA f1,
UTRA f2,
GERAN
UTRA f1 is selected for CSFB target
5.4.1.5 RRC MEASUREMENT CONFIGURATION
The one single highest priority RAT/carrier from the eMCTA output (may be a measured
candidate or a blind candidate) is selected for the CSFB target. PS HO (for UTRAN
carrier) and CCO (for GERAN carrier) are the preferred mobility solutions.
If handover is possible:
 Either an event B1 (preferable if supported by the UE) or event B2 measurement is
configured for the target RAT/carrier, as specified by the eMCTA output.
 A Measurement Gap may be configured, if one is needed. For CSFB, the MG period is
always fixed to 40 ms to shorten the time to trigger handover for CSFB, so parameter
measurementGapsPatternis not used in this scenario.
If handover is not possible, then a blind redirection is triggered. For CSFB case, redirection
with measurement is not performed. The assumption is that the UE will be more efficient at
measuring the carriers in idle mode than it would be in connected mode using
measurement gaps.
5.4.2 CS FALLBACK TO 1XRTT

To perform Rel-8 1xCSFB or enhanced 1xCSFB, eMCTA builds a list of 1xRTT neighbors
of the Serving Cell with ReportConfigCDMA2000::triggerTypeInterRAT set to
‘periodicalForCsfbTo1xRtt’. The list of candidate neighbors is passed through the following
eMCTA filters:
 UE Capabilities: checks SupportedBandList1xRTT in UE-EUTRA-Capability IE for

a list of 1xRTT bandclass the UE supports
 Mobility Path Information: for non-emergency 1xCSFB only, checks for restrictions
in the Handover Restriction List IE. A carrier will pass this filter if:
o Forbidden inter-RATs IE associated to the 1xRTT carrier is not set to
‘cdma2000’, ‘cdma2000 and utran’ or ‘all’
o The PLMN associated to the 1xRTT carrier is the serving PLMN or one of
the equivalent PLMNs
 Service-Based Policy: candidates should be prioritized based on service type in
ServiceTypePriorityConf configuration data
The 1xRTT carriers that pass the above filters will be truncated as specified in section
5.2.4. The resulting list of candidate carriers will be used to configure UE for 1xRTT
Page 169/543
Volume 6 : Mobility
measurement if measurement based 1xCSFB is to be perfomed. A single best 1xRTT
carrier is selected if a blind redirection is to be performed for 1xCSFB.
5.4.3 SERVING RADIO MONITORING

eMCTA may be invoked by the following serving radio monitoring triggers:
• Event A2 Coverage Alarm (A2_CA): The reception of RRC Measurement Report
with report configuration eventA2 and measurement purpose set to ‘Entering-
Coverage-Alarm’, indicating serving radio degradation is reached at which point
another RAT/carrier should be monitored. This condition triggers RRC
measurements for neighboring carriers to be filtered and sorted according to their
configured. RRC Measurements with eventB2 report configuration are configured
for inter-RAT mobility and eventA5/eventA3 for intra-LTE inter-frequency mobility.
The coverage alarm trigger is shown in Figure 39.
• Below Serving Floor (bad radio conditions): The reception of an RRC
Measurement Report with report configuration eventA2 and measurement purpose
set to ‘Below-Serving-Floor’, indicating a strong degradation of the serving radio
conditions that requires a blind redirection to another RAT carrier. This condition
triggers neighboring carriers to be filtered and sorted according to their configured
priority and only one single carrier with the highest priority from the sorted list is
selected as the target RAT carrier. If there is more than one carrier with highest
priority, then one of them is randomly chosen to avoid always selecting the same
carrier. RRC Measurements are not configured for blind redirection. The Below
Serving Floor alarm trigger is shown in Figure 40.
Page 170/543
Volume 6 : Mobility
TRIGGER: RECEPTION OF EVENT A2 ENTERING-COVERAGE-ALARM (A2_CA)
1. Serving radio level falls below the A2_CA_threshold:

Event A2 configuration:
Radio Level ReportConfigEUTRA::thresholdEutraRsrp for RSRP quantity
Quality (dB) or (ALU recommends value = -90 dBm);
Power (dBm) ReportConfigEUTRA:: thresholdEutraRsrq for RSRQ quantity
timeToTrigger
(RSRQ not tested yet – no recommended value);
for duration of time timeToTrigger
(ALU recommends value = 40ms).
A2_CA_threshold
(serving)
serving
GOOD ALARM
2. A2_CA reception: UE enters the Coverage Alarm Radio Condition. 3. eMCTA returns a list of RAT/Carrier
RRC Measurement Configuration process : Candidates which RRC Measurement Process
- Releases event A2_CA measurement, uses to configure inter-frequency (A5/A3)
- Configures event A2 Leaving-Coverage-Alarm, and/or inter-RAT (B2) measurements.
and
- invokes the eMCTA Framework
16
Figure 39: eMCTA triggered by reception of Coverage Alarm
Page 171/543
Volume 6 : Mobility
TRIGGER: RECEPTION OF EVENT A2 BELOW SERVING FLOOR ALARM (A2_Floor)
Radio Level
Quality (dB) or
Power (dBm)
1. Serving radio level falls below the A2_Floor_threshold:
Event A2 configuration:
A2_CA_threshold ReportConfigEUTRA::thresholdEutraRsrp for RSRP quantity
(serving) (ALU recommends value = -120 dBm);
ReportConfigEUTRA:: thresholdEutraRsrq for RSRQ quantity
(RSRQ not tested yet – no recommended value);
for duration of time timeToTrigger
timeToTrigger (ALU recommends value = 40ms).
serving
A2_floor_threshold
(serving)
GOOD BAD
2. A2_Floor Reception. 3. eMCTA returns a list of RAT/Carrier

UE enters the Bad Alarm Radio Condition. Candidates which RRC Measurement Process
RRC Measurements Configuration process : uses for the blind redirection target.
- Releases event A2_Floor measurement
- invokes the eMCTA Framework for blind mobility.
29
Figure 40: eMCTA triggered by reception of Below Serving Floor Alarm (bad radio
conditions)
In response to a A2_CA trigger, eMCTA builds initial list of neighboring RAT/Carrier

candidates by matching configured neighbors with a configured B2 or A5 measurement
object (see Figure 41).This matched candidate list is passed through eMCTA filters.
Page 172/543
Volume 6 : Mobility
MeasurementIdentity MeasurementIdentity
LteNeighboring UtraFddNeighboring
Conf Conf
MeasObjectEUTRA ReportConfigEUTRA MeasObjectUTRA ReportConfigUTRA
FreqConf FreqConf
triggerTypeEUTRA triggerTypeInterRAT
dlEARFCN = dlEARFCN carrierFreq = carrierFreq
= eventA5 = eventB2
bandClass = MeasurementIdentity
HrpdNeighboring
MeasurementIdentity bandClass Conf
GeranNeighboring
Conf
HrpdBandClass
Conf
GeranNeighboring
MeasObjectGERAN ReportConfigGERAN MeasObject ReportConfig
FreqsConf
HrpdNeighboring CDMA2000 CDMA2000
PerCarrier
GeranARFCNList triggerTypeInterRAT
= GeranARFCNList triggerTypeInterRAT
= eventB2 frequency = carrierFreq
= eventB2
18
Figure 41: Serving Radio Monitoring Trigger Neigbhor RAT/Carrier Candidates for RRC
Measurements
Neighboring RAT/carriers of the Serving Cell must fulfull the checks performed by the
following eMCTA filters for the Serving Radio Monitoring trigger:

 Mobility Path Information: checks for restrictions on mobility.
 Network Capabilities: HRPD measurement gap evaluation (used if there are
HRPD neighbors).
 QCI-Based Policy: candidates may be prioritized based on the call’s most
important QCI in QciPriorityConf configuration data.
 Frequency Load: applicable only to Below Serving Floor Alarm trigger if there are
“unloaded” LTE inter-frequency carriers. If there are no “unloaded” LTE carriers
then a “loaded” LTE carrier may be selected. Refer to section 5.4.5.1 for details
on the Frequency Load filter.
Page 173/543
Volume 6 : Mobility
The following table summarizes the UE Capability filtering for Serving Radio Monitoring
trigger. For the case of Below Serving Floor (Bad Radio Condition) trigger, Frequency
Band checks are performed but measurement capability checks are not performed since no
measurements are configured.
UE Capability FILTER Lte UtraFdd Geran Hrpd

Neighboring Neighboring Neighboring Neighboring
To Pass filter: To Pass filter: To Pass filter: To Pass filter:

- Indicates the carriers - LTE FDD Inter- - UTRA FDD - GERAN RAT - HRPD RAT Band
and RAT supported by Frequency Band RAT Frequency Frequency Band Class must be
the UE must be supported. Band must be must be supported. supported.
- Feature Group Indicator - FGI bit #25 for supported. - FGI bit #23 for - FGI bit #26 for
bits indicate RRC inter-frequency - FGI bit #22 for event B2 event B2
Measurements supported measurement must event B2 measurement must measurement must
by the UE be set. measurement be set. be set.
- If FGI bit #14is must be set. - FGI bit #10 must
also set (optional - FGI bit #8 must be set for CCO to
but preferred), then be set for PS HO be performed,
event A5 to be performed, otherwise, a
measurement will otherwise, a redirection is
be configured, redirection is performed.
otherwise, event performed.
A3 will be - FGI bit #27
configured instead. must bet set for
SRVCC to
UTRAN
procedure to be
performed.
ActivationService::isDifferentiateUtranModeInFGIsEnabled
Parameter isDifferentiateUtranModeInFGIsEnabled

[false, true]
Value false
Feature 167243
Notes: CR1011 in 3GPP Rel-9 standard TS 36.331 modifies the Feature Group Indicators.
After the changes, some of the UTRAN related FGI bits will have different meanings based
on whether a UE supports FDD only, TDD only, or both FDD and TDD, and whether the
target is UTRAN FDD or UTRAN TDD. If the target is UTRAN FDD, the meanings of the
FGI bits are the same before and after the CR changes for a UE that supports UTRAN
Page 174/543
Volume 6 : Mobility
FDD. When this parameter is set to ‘true’,it indicates eNB applies the new FGI definitions.
Otherwise, it indicates eNB applies the old FGI definitions.
The Mobility Path Information filter for Serving Radio Monitoring performs the following
checks on candidate neighboring cells (except for IMS VoIP emergency calls, for which this
filter does not apply):
 RATs restricted for handover.

 PLMNs allowed.
 Forbidden TACs.
 Forbidden LACs(not apply to UTRAN FDD open small cell, L115393).

 TAI not allowed for IMS VoIP (introduced in LA5.0.0 by feature L115685).
 SRVCC to UTRAN allowed for IMS VoIP (introduced in LA5.0.0 by feature
L92126).
The following tables summarize the Mobility Path Information checks which rely on the
information contained in the S1AP Handover Restriction List IE.
Handover UtraFddNeighboring Candidates GeranNeighboring Candidates

Restriction List
‘Forbidden Inter- To Pass filter: To Pass filter:

RATs’ ‘Forbidden inter RATs’ cannotbe set to ‘Forbidden inter RATs’ cannot be set to
‘ALL’, ‘UTRAN’, ‘GERAN and ‘ALL’, ‘GERAN’, or ‘GERAN and
UTRAN’, or ‘CDMA2000 and UTRAN’. UTRAN’.

(RncAccess::plmnMobileCountryCode (BscAccess::plmnMobileCountryCode and
and BscAccess::plmnMobileNetworkCode) in
RncAccess::plmnMobileNetworkCode) ‘Equivalent PLMNs’ list or same PLMN as
in ‘Equivalent PLMNs’ list or same the serving cell.
‘Forbidden To Pass filter: To Pass filter:
LACs’ (list) Candidate carrier does not have all of its Candidate carrier cannot have any cells with
cells with LAC LAC (GeranNeighboringCellRelation::lac)
(UtraFddNeighboringCellRelation::lac) belonging to a forbidden LAC in the
belonging to a forbidden LAC in the ‘Forbidden LACs’ list.
‘Forbidden LACs’ list.
Handover LteNeighboring Candidates HrpdNeighboring Candidates

Restriction List
Page 175/543
Volume 6 : Mobility
‘Forbidden Inter- Not applicable. To Pass filter:
RATs’ ‘Forbidden inter RATs’ cannot be set to
‘ALL’, ‘CDMA2000’, or ‘CDMA2000 and
UTRAN’.

(LteNeighboringCellRelation::LteNeigh (HrpdNeighboringPerCarrier::plmnMobil
borPlmnIdentity::plmnMobileCountryCo eCountryCode and
de and HrpdNeighboringPerCarrier::plmnMobile
LteNeighboringCellRelation::LteNeighb NetworkCode) in ‘Equivalent PLMNs’ list
orPlmnIdentity::plmnMobileNetworkCo or same PLMN as the serving cell.
de) in ‘Equivalent PLMNs’ list or same
‘Forbidden To Pass filter: Not applicable.
TACs’ (list) Candidate carrier does not have all of its
cells with TAC
(LteNeighboringCellRelation::trackingA
reaCode) belonging to a forbidden TAC
in the ‘Forbidden TACs’ list.
In addition to the Handover Restriction List, additional checks are performed for a call with
a VoIP radio bearer (qCI = 1) in the case of non-blind mobility:
- To pass filter, an LteNeighboring candidate cannot have all of its cells belonging to the
TAI specified by parameters of the TailListNotSupportingImsVoip object:
plmnMobileCountryCode, plmnMobileNetworkCode, and trackingAreaCode.
- To pass filter, at least one cell of a UtraFddNeighboring candidate must either support
VoIP, or ‘SRVCC to UTRAN’ must be allowed in the eNB. Refer to section 10.3 for details.
TaiListNotSupportingImsVoip::trackingAreaCode
Object ENBEquipment/ Enb/ TaiListNotSupportingImsVoip

Maxlength = 16
Value O.D.
Feature L115685
Refer to Volume 5 for a description of parameters plmnMobileCountryCode and

plmnMobileNetworkCode.
The Network Capability filter for Serving Radio Monitoring is applicable only to HRPD to
configure a UE that requires MG for event B2 measurement towards HRPD.
Page 176/543
Volume 6 : Mobility
eMCTA will configure a UE that requires MG for measurement towards HRPD if both of the
following conditions are satisfied:
• ActivationService::isSynchCdmaSystemTimeAllowedis set to ‘True’ (refer to

section 8 for the parameter)
• At least one of the following conditions is satisfied:
o GpsTime::operationalStateis ‘Enabled’ and GpsTime::availableStatusis
empty.
o CdmaPhaseSync::operationalStateis ‘Enabled’ regardless of the status
of CdmaPhaseSync::availabilityStatus
5.4.3.4 QCI-BASED POLICY
eMCTA triggered by Serving Radio Monitoring uses the QCI-Based Policy for RAT/Carrier
priority as follows:
The parameters under QciPriorityConf are used to determine priority if:
 ActivationService::isServiceBasedTrafficSegmentationAllowedis ‘True’. This
setting enables Service Segmentation and requires a licensing token managed by
Feature Licensing.
 And a RAT/Carrier is found with a qci that matches the most important established
QCI, which corresponds to the QCI of the one established bearer in the mono-QCI
case or corresponds to the most important QCI in the
qciHierarchyForMultiQciCallList for the multi-QCI case. (See description of
these parameters in section 5.2).
Otherwise:
 defaultConnectedPriorityOfFreq is used to determine priority.
Example of a QciPriorityConf, Qci, and QciHierarchyForMultiQciCallList configuration:
iF/iRAT eUTRA f1 eUTRA f2 UTRA GERAN HRPD

Carrier
QCI
Instance QCI Value
#1 QCI_1 (VoIP) 6 1 0 Not allowed Not allowed
#2 QCI_3 2 Not allowed 3 4 7
#3 QCI_4 5 Not allowed Not allowed 4 3
#4 QCI_5 6 Not allowed 5 4 3
#5 QCI_7 Not allowed Not allowed 5 4 2
#6 QCI_20 3 6 2 Not allowed Not allowed
#7 QCI_240 7 6 4 5 2
Page 177/543
Volume 6 : Mobility
LTE f1 LTE f2 UTRA GERAN HRPD
defaultConnectedPriority 4 4 7 6 6
OfFreq
LTE f1 LTE f2 UTRA GERAN HRPD

QciHierarchyFor {1, 2, 3, 4, 7, {1, 2, 3, 4, 7, {1, 2, 3, 4, 7} {2, 3, 7, 4} {2, 3, 4, 7,
MultiQciCallList 20} 20} 240}
Scenarios:
Scenario Inputs: Outputs:
Established Reference Carrier Priority
Bearers’ iFreq/iRat QCI Evaluation
QCI(s) carrier
eUTRA f1 1 6 1st
eUTRA f2 1 1 2nd
1
1 UTRA 1 0 3rd
(mono-QCI)
GERAN n.a. Not Allowed
HRPD n.a. Not Allowed
eUTRA f1 1 6 1st
eUTRA f2 1 1 4th
6, 1, 4
2 UTRA 1 0 5th
(multi-QCI)
GERAN 4 4 2nd
HRPD 4 3 3rd
eUTRA f1 20 3 5th
eUTRA f2 20 6 2n d ,
3rd ,
or
4th
20, 5 UTRA n.a. 7 1st

3 (defaultConnected
(multi-QCI) PriorityOfFreq)
GERAN n.a. 6 2n d ,
(defaultConnected 3rd ,
PriorityOfFreq) or
4th
HRPD n.a. 6 2n d ,
Page 178/543
Volume 6 : Mobility
(defaultConnected 3rd ,
PriorityOfFreq) or
4th
The prioritized RAT/Carrier list is used to configure RRC measurements (event B2 for inter-
RAT, and A5/A3 for LTE inter-frequency). Intra-frequency RRC measurements (A1 for
exiting-coverage-alarm and A3 for LTE intra-frequency are also configured. The lowest
priority RRC measurements may not be configured if the sum of the measurements
exceeds the value of parameter maxMeasIdForMultipleMonitoring . Also, some of the
lowest priority RRC measurements that need measurement gap may not be configured if
the number of these measurements exceeds the value of parameter
maxNbCarriersForMultipleMonitoringUsingMeasGaps . Refer to section 5.2.4). If
needed, Measurement Gaps may be configured, based on the value of parameter
measurementGapsPattern for each configured instance of RrcMeasurementConf object.
In the case of Radio Mobility triggered by Below Serving Floor (bad radio conditions), no
RRC measurements are configured. Therefore, the blind candidate RAT/Carrier list may
contain RAT/Carrier neighbors for which the UE does not support measurements. (Thisis
the main difference between A2_Floor and A2_CA output candidate lists). One single best
RAT/Carrier target from the Blind candidate list is selected for a Blind Redirection mobility
procedure.
5.4.4 OFFLOAD UE UPON REACTIVE LOAD CONTROL

Reactive load control is triggered by Radio CAC which identifies UEs to off-load in order to
free resources when congestion is detected. Refer to Volume 4 for the UE selection
criteria. eMCTA is invoked to identify target RAT/carriers to be monitored in order to
configure inter-frequency and/or inter-RAT mobility measurements to leave the serving cell
and to redirect or handover to another RAT/carrier’s cell.
Parameter isOffLoadUponReactiveLoadControlAllowed allows or disables the mobility

load-based feature to off-load UE upon reactive load control decision. This parameter can
be set to 'true' only if licensing tokens are available for this load-based mobility trigger (refer
to LPUG Volume 2 for details on feature licensing).
Page 179/543
Volume 6 : Mobility
ActivationService::isOffLoadUponReactiveLoadControlAllowed
Parameter isOffLoadUponReactiveLoadControlAllowed

[false, true]
Value false
Feature L106136
Rule: Regarding isOffloadUponReactiveLoadControlAllowed

If flag isOffloadUponReactiveLoadControlAllowed = True and
isInterFreqEutraSameFrameStructureMobilityAllowed = True, then at least one
MeasurementIdentityConf instance with measurementPurpose=‘Mobility-Inter-
Freq-to-EUTRA’ must exist forthe LteCell, and with reportConfigLink that points to
a ReportConfigEUTRA object withtriggerTypeEUTRA = ‘eventA4’.
A timer controlled by parameter tMeasWaitForOffloadis started when inter-frequency and

inter-RAT measurements for the off-load process are configured to guard the measurement
period. When this timer elapses, these measurements are removed and the off-load
process is ended.
Enb::tMeasWaitForOffload
Parameter tMeasWaitForOffload

[100..60000] ms
Value 2000
Feature 103892
In response to an offload trigger, eMCTA builds initial list of neighboring RAT/Carrier

candidates by matching configured neighbors with a configured B1 or A4 measurement
object (see). If reactive load control is triggered due to congestion at the cell or band level,
then intra-eNodeB inter-frequency carriers may also be offload candidates if the serving
eNodeB is configured with bCEM supporting dual-band or dual-carrier. Otherwise, only
inter-eNodeB inter-frequency neighbors may be offload candidates. This matched
candidate list is passed through eMCTA filters.
Page 180/543
Volume 6 : Mobility
MeasurementIdentity MeasurementIdentity
Conf Conf
MeasObjectEUTRA ReportConfigEUTRA MeasObjectUTRA ReportConfigUTRA
FreqConf FreqConf
triggerTypeEUTRA triggerTypeInterRAT
dlEARFCN = dlEARFCN carrierFreq = carrierFreq
= eventA4 = eventB1
bandClass = MeasurementIdentity
HrpdNeighboring
MeasurementIdentity bandClass Conf
GeranNeighboring
Conf
HrpdBandClass
Conf
GeranNeighboring
MeasObjectGERAN ReportConfigGERAN MeasObject ReportConfig
FreqsConf
HrpdNeighboring CDMA2000 CDMA2000
PerCarrier
GeranARFCNList triggerTypeInterRAT
= GeranARFCNList triggerTypeInterRAT
= eventB1 frequency = carrierFreq
= eventB1
18
Figure 42: Offload UE Upon Reactive Load Control Trigger Neighbor RAT/Carrier Candidates for
RRC Measurements
Neighboring RAT/carriers of the Serving Cell must fulfull the checks performed by the
following eMCTA filters for the Offload UE Upon Reactive Load Control trigger:
 Mobility Path Information: checks for restrictions on mobility.
 Network Capabilities: HRPD measurement gap evaluation (used if there are
HRPD neighbors).
 QCI-Based Policy: candidates may be prioritized based on the call’s most
important QCI in QciPriorityConf configuration data.
 Frequency Load: checks for LteNeighboring carriers that have all “loaded” cells
which cannot be selected for off-loading. Refer to section 5.4.5.1 for details.
The following table summarizes the UE Capability filtering for Offload UE Upon Reactive
Load Control trigger.
Page 181/543
Volume 6 : Mobility
UE Capability FILTER Lte UtraFdd Geran Hrpd

Neighboring Neighboring Neighboring Neighboring
To Pass filter: To Pass filter: To Pass filter: To Pass filter:

- Indicates the carriers - LTE FDD Inter- - UTRA FDD - GERAN RAT - HRPD RAT Band
and RAT supported by Frequency Band RAT Frequency Frequency Band Class must be
the UE must be supported. Band must be must be supported. supported.
- Feature Group Indicator - FGI bit #25 for supported. - FGI bit #23 for - FGI bit #26 for
bits indicate RRC inter-frequency - FGI bit #22 for event B2 event B2
Measurements supported measurement must event B2 measurement must measurement must
by the UE be set. measurement be set. be set.
- If FGI bit #14is must be set. - If FGI bit #15is - If FGI bit #15is
also set (optional - If FGI bit #15is also set (optional also set (optional
but preferred), then also set (optional but preferred), then but preferred), then
event A4 but preferred), event B1 event B1
measurement will then event B1 measurement can measurement can be
be configured, measurement can be configured; configured;
otherwise, event be configured; otherwise event B2 otherwise event B2
A3 will be otherwise event is configured. is configured.
configured instead. B2 is configured. - FGI bit #10 must
- FGI bit #8 must be set for CCO to
be set for PS HO be performed,
to be performed, otherwise, a
otherwise, a redirection is
redirection is performed.
performed.
- FGI bit #27
must bet set for
SRVCC to
UTRAN
procedure to be
performed.
-For preventive
load control, FGI
bit #8must be set.
Mobility Path Information is the same as that for Serving Radio Monitoring. See section
5.4.3.2.
Network Capabilities filtering is the same as that for Serving Radio Monitoring. See section
5.4.3.3.
5.4.4.4 QCI-BASED POLICY
eMCTA triggered by Offload UE Upon Reactive Load Control trigger uses the QCI-Based
Policy for RAT/Carrier priority. It uses the same policy as Serving Radio Monitoring. See
section 5.4.3.4.
The RRC Measurement Configuration for trigger Offload UE Upon Reactive Load Control is
similar to the Serving Radio Monitoring case except:
Page 182/543
Volume 6 : Mobility
 event A4 (instead of event A5) is configured for EUTRA inter-freqency
measurements. The event A4 measurement configuration is described in Section
4.
 event B1 may be configured instead of event B2 for inter-RAT measurements.
Multiple RAT/Carriers may be monitored, and measurement gaps may be configured if
needed.
Blind mobility may be triggered if measurement based mobility is not possible.
5.4.5 OFFLOAD UE UPON PREVENTIVE LOAD CONTROL

Preventive load control is triggered by Radio CAC which identifies UEs to off-load to
another inter-frequency LTE carrier (L115223) or a UTRAN FDD macro cell carrier
(155912)for load balancing purposes. Refer to Volume 4 for the UE selection criteria.
eMCTA is invoked to identify “unloaded” inter-frequency LTE candidatesand/or UTRAN
FDD macro cell carrier candidates to be monitored in order to configure inter-frequency
LTE measurements and/or UTRAN FDD macro cell carrier measurementsto leave the
serving cell and handover to another LTE carrier’s cell or PS handover/SRVCC (PS and
CS) to another UTRAN FDD macro cell.
For a LTE cell, load information is received directly from neighboring eNBs via the X2
Resource Status Updates (refer to Volume 5 for details).
For a UTRAN FDD macro cell, load information is received through RIM for cell load
procedure (refer to Error! Reference source not found.).
Parameter isInterFreqLoadBalancingFeatureEnabled allows or disables all functions

associated with feature L115223. This parameter can be set to 'true' only if licensing tokens
are available for this load-based mobility trigger (refer to LPUG Volume 2 for details about
feature licensing). In addition, parameter isInterFreqPreventiveLoadControlAllowed
must be set to ‘true’ to enable UE off-loading for preventive load control (refer to Volume 4
for details about this parameter).
To enable preventive load control to UTRAN FDD macro cells,

ActivationService::isUtraPreventiveLoadControlEnabledmust be set to ‘True’ and PS
handover to UTRAN must also be enabled (ActivationService::isPsHoToUtraAllowed =
‘True’).
Page 183/543
Volume 6 : Mobility
ActivationService::isInterFreqLoadBalancingFeatureEnabled
Parameter isInterFreqLoadBalancingFeatureEnabled

[false, true]
Value false
Feature L115223
ActivationService::isUtraPreventiveLoadControlEnabled
Parameter isUtraPreventiveLoadControlEnabled

[false, true]
Value false
Feature 155912
Notes: This parameter can be set to ‘True’ only if
ActivationService::isUtraLoadBalancingEnabled is set to ‘True’. To enable preventive
load to UTRAN FDD, this parameter must be set to ‘True’ and
ActivationService::isPsHoToUtraAllowed must be set to ‘True’.
Preventive load control uses the same procedure guard timer for off-loading as reactive
load control, specified by parameter tMeasWaitForOffload (refer to section 5.4.4 for
details).
Preventive load control uses the same filtering as reactive load control for UE offloading.
The only difference is that for preventive load control, inter-frequency LTE carriers and
UTRAN FDD macro cell carriersmay be candidatesfor preventive load control, while for
reactive load control, inter-frequency LTE and all types of inter-RAT carriers may be
candidates.
An inter-frequency intra-eNB cell can be a candidate for offload target for preventive load
control if the serving eNB is configured with bCEM supporting dual-band or dual-carrier.
Otherwise, only an inter-frequency inter-eNB cell can be an offload target.
For preventive load control, only UTRAN FDD macro cell that supports PS handover or
SRVCC (PS and CS) can be a candidate for offload target. UTRAN FDD small cell cannot
be a candidate for preventive offload target since it does not support PS handover or
SRVCC (PS and CS).
Page 184/543
Volume 6 : Mobility
Mobility for UE offloading triggered by preventive load control is measurement based using
event A4. Blind mobility is not attempted for this trigger.
5.4.5.1 FREQUENCY LOAD FILTER
Frequency load filtering is applicable to the following mobility triggers:

 Serving Radio Monitoring
 Reactive Load Control
 Preventive Load Control

 CS Fallback to UTRAN FDD macro cell dedicated carriers
This filter applies to inter-frequency LteNeighboring carriers and associated cells. Since
there is no X2 connection between eNB and HeNB, cell load is not available for a LTE
HeNB open cell (134689). A HeNB open cell load status and its dedicated carrier load
status aretreated as ‘load unknown’ for Serving Radio Monitoring, Reactive Load Control
and Preventive Load Control.
With 155912, this filter also applies to UTRAN FDD macro cells and their carriersfor
Serving Radio Monitoring and CS Fallback to UTRAN carriers if
ActivationService::isUtraLoadBalancingEnabled is set to ‘True’. It also applies to
UTRAN FDD macro cells and their carriers for Preventive Load Control if
ActivationService::isUtraPreventiveLoadControlEnabled is set to ‘True’. For Reactive
Load Control, a UTRAN FDD macro cell load status and its carrier load status are
alwaystreated as ‘load unknown’ regardless of the actual cell load status.
Since UTRAN FDD small cells do not support RIM for cell load retrieving, cell load is not
available for a UTRAN FDD small cell (L115393). A UTRAN FDD small cell load status and
its dedicated carrier load status are treated as ‘load unknown’ for Serving Radio Monitoring
and Reactive Load Control. A UTRAN FDD small cell load status and its dedicated carrier
load status are treated as ‘loaded’ for Preventive Load Control.
LTE cell load information from a neighbor eNB is provided in message ‘X2 Resource Status
Update’ CellMeasurementResult IE. A LTEcell’s load status is “loaded” if any condition
shown in the table below is fulfilled. If there is no load information provided in this X2
message for a cell, the cell’s load status is “load unknown”. Otherwise, the cell’s status is
“non-loaded”.
Page 185/543
Volume 6 : Mobility
eNB receives cell load of a UTRAN FDD neighbor macro cell through RIM for cell load
retrieving procedure (refer to section Error! Reference source not found.). S1-MME
Direct Information Transfer message includes the Downlink Cell Load Information and the
Uplink Cell InformationIEs. With 155912, the information contained in the IEs relevant to
downlink cell load and uplink cell load of the UTRAN FDD neighbor macro cell include:
 Cell Capacity Class Value [1…100] – specifies the cell capacity with respective to
other cells. Value 1 indicates the minimum cell capacity and 100 indicates the
maximum cell capacity
 Load Value [0…100%] – contains the total cell load relative to the maximum
planned load. It is defined as the load percentage of the Cell Capacity Class. Value
0 indicates the minimum load and 100 indicates the maximum load
From the received DL/UL cell load received through RIM procedure, eNB calculates the
DL/UL available capacity as below:
DL Available Capacity = DL Cell Capacity Class Value x (100 – DL Load Value) / 100
Page 186/543
Volume 6 : Mobility
UL Available Capacity = UL Cell Capacity Class Value x (100 – UL Load Value) / 100
A UTRAN neighbor macro cell is considered as ‘loaded’ if one or more of the following
conditions are true:
 Its DL Available Capacity
<UtraLoadBalancingConf::dlUtraCellLoadedThreshold or its UL Available
Capacity <UtraLoadBalancingConf::ulUtraCellLoadedThreshold
 UtraFddNeighboringCell::noHoOrRedirection is set to ‘True’
If cell load information is available for a UTRAN FDD neighbor macro cell and it is not
loaded based on above criteria, the cell is ‘not loaded’. Otherwise, if no valid cell load
information is available for the UTRAN FDD neighbor cell, it has ‘unknown load’.
UtraLoadBalancingConf::dlUtraCellLoadedThreshold
Parameter dlUtraCellLoadedThreshold

[0..100]step = 1
Value 15
Feature 155912
Notes: This parameter indicates the DL threshold used to determine if a UTRAN neighbor
cell is loaded. If DL Available Capacity is less than the value of this parameter, the UTRAN
neighbor cell is considered as loaded.
UtraLoadBalancingConf::ulUtraCellLoadedThreshold
Parameter ulUtraCellLoadedThreshold

[0..100]step = 1
Value 15
Feature 155912
Notes: This parameter indicates the UL threshold used to determine if a UTRAN neighbor
cell is loaded. If UL Available Capacity is less than the value of this parameter, the UTRAN
neighbor cell is considered as loaded.
Page 187/543
Volume 6 : Mobility
5.4.5.1.1 LOAD FILTERING AT CARRIER LEVEL
Carrier load is determined by the aggregate load status of the individual cells in the carrier.
If all of the cells in the carrier are loaded, then the carrier is loaded. Otherwise, the carrier
is considered to be non-loaded, even if some or all of its cells’ load status are “load
unknown”.
If a UTRAN carrier has no neighbor cell, the carrier is considered as ‘not loaded’.
Carrier load filtering actions depend on the mobility procedure as summarized in the
following table:
Mobility Trigger Measurement-Based Blind Mobility

Mobility
Reactive Load Control UE Loaded carriers are filtered Loaded carriers are filtered
offloading out. Only non-loaded out. Only non-loaded
carriers may be selected. carriers may be selected.
Preventive Load Control UE Loaded carriers are filtered Not applicable

offloading out. Only non-loaded
carriers may be selected.
A2_CA Coverage Alarm No load filtering at carrier Not applicable.

level. Filtering will occur at
cell level at Measurement
Report time (refer to
5.4.5.1.2).
A2 Below Serving Floor Not applicable. Loaded carriers are filtered

Alarm out. However, if all carriers
are loaded, then the highest
priority carrier is selected.If
several candidate
RAT/carriers have the
highest priority, the least
loaded RAT/carrier is
selected.
CS Fallback to UTRAN Loaded carriers are filtered Same as for Measurement-

out. If all carriers are loaded, Based Mobility.
the highest priority carrier is
selected. If several
candidate carriers have the
highest priority, the least
loaded carrier is selected.
Page 188/543
Volume 6 : Mobility
5.4.5.1.2 LOAD FILTERING AT CELL LEVEL
Cell load filtering is also performed at Measurement Report (MR) time for target cell
selection, as summarized in the following table:
Mobility Trigger Cell Filtering action
Reactive Load Control UE offloading Loaded cells are filtered out.
Preventive Load Control UE Only the best cell of the MR is considered.

offloading
Discard the MR if:
- The best cell load is loaded or load unknown.
- The best cell is non-loaded, but its reported
Dl Total PRB usage
>dlPreventiveLoadControlThresholdOnPrb
or
Ul Total PRB usage
>ulPreventiveLoadControlThresholdOnPrb.
A2_CA Coverage Alarm Discard loaded cells. However, if all cells of the
MR are loaded, then in this case select the best
cell.
CS Fallback to UTRAN Select the best ‘not loaded’ or ‘unknown load’ cell.
However, if all cells are loaded, select the best
cell.
Enb::dlCellLoadedThreshold
Parameter dlCellLoadedThreshold

[0..100] %
Value 15
Feature L115223
Page 189/543
Volume 6 : Mobility
Enb::ulCellLoadedThreshold
Parameter ulCellLoadedThreshold

[0..100] %
Value 15
Feature L115223
5.4.5.2 LOAD EQUALIZATION
Load equalization is an early form of preventive offload and it is introduced in LR13.1 by

feature L114538. The aim is to provide consistent user QoS in different LTE carriers by
correcting load imbalances very early. The only criteria for triggering load equalization in
LR13.1 is semi-static PRB consumption (refer to notes below). When this serving cell
threshold is met, Callp will ask UEs to measure cells on other LTE carriers.
In order to avoid triggering load equalization too often, one condition is that there is a
sufficient gap in load between the cells on different carriers. Upon receiving a UE
measurement report for load equalization, Callp will need to check that there is a sufficient
delta between source and target cell load. If a target cell does not satisfy this criterion, load
equalization will not be triggered towards this cell.
UE selection for load equalization will be the same as for preventive offload triggered by
semi-static PRB usage, meaning the number of UEs selected will be based on the PRB
usage deficit compared with the load equalization threshold. The eNB will stop offloading
UEs to a cell when the load between the two cells has reached equal levels in terms of
semi-static PRB usage.
Notes: The thresholds for load equalization are described in volume 4 (Section 5.1.5.1.2)
as they are RadioCac parameters.
For load equalization to be triggered, the serving cell load (PRB usage) needs to be
at:
ul/dlPreventiveLoadControlThresholdOnStaticPrb - LoadEqualizationDeltaThreshold
Load equalization can be done between 2 cells from 2 different eNBs if they are on
different frequencies.
TheLteNeighboringFreqConf::isLoadEqualizationEnabledparameter allows to
enable/disable load equalization for each LTE neighbor carrier. It is not applicable to the
serving carrier.
Page 190/543
Volume 6 : Mobility
LteNeighboringFreqConf::isLoadEqualizationEnabled
Parameter isLoadEqualizationEnabled
True/False
Feature L114538
5.4.5.3 BLIND PREVENTIVE OFFLOADING
Up to LR13.1, preventive offloading can only be triggered towards a cell which is

considered not loaded, which implies prior knowledge of loading. This is to avoid
performing load balancing towards a cell that is itself performing load balancing.
Some customers will be performing preventive offloading between eNBs, and in some
cases there will be no X2 link (or no X2 load exchange). Consequently, we need our
solution to allow inter-frequency preventive offload towards a neighbor cell for which there
is no load information available. This is introduced in LR13.1 by feature L114538.
Upon receiving a UE measurement report for preventive offload (inter-frequency A4 event)
where there is no load information available for the best cell, when performing target cell
capacity filtering for preventive offloading, the following behavior will apply:
 If eNB::spare15 bit0 = 1 (True), trigger redirection or handover towards the best
cell;
 If eNB::spare15 bit0 = 0 (False), ignore the UE measurement report.
If the load of the neighbor cell is known, the eNB behavior remains the same and does not
depend on the spare setting.
Refer to LPUG volume 2 for details of the spare parmeter eNB::spare15 bit 0.
5.4.6 ANR
ANR may trigger eMCTA to select candidates for ANR measurements. eMCTA may be
invoked for selection of UTRA-FDD and/or LTE inter-frequency neighboring carriers
suitable for configuration of UTRA-FDD and/or LTE inter-frequency ANR measurements.
Section 11 in this volume describes the parameters used for configuring ANR.
When triggered by ANR, eMCTA builds an initial list of neighboring RAT/Carrier candidates
by matching configured neighbors with a configured ANR measurement object. This
matched candidate list undergoes UE Capability filtering. The Feature Group Indicator of
the UE Capabilites must have bit #19 set for configuration of inter-RAT ANR periodical
Page 191/543
Volume 6 : Mobility
measurements and bit #18 set for configuration of inter-frequency ANR periodical
measurements. For UTRAN ANR, FGI must have bit #22 set for configuration of eventB2
measurements. The Mobility Priority Table is not used by eMCTA when triggered by ANR.
Candidates for ANR measurements are assigned a fixed priority of 8 to ensure that they
are of higher priority than any measurement used by other mobility cases.
6 INTRA-LTE RRC CONNECTED MODE MOBILITY

PROCEDURES
6.1 INTRA-FREQUENCY RRC CONNECTED MODE MOBILITY
RRC CONNECTED mode intra-frequency mobility provides service continuity in the same
frequency. Only intra-frequency EventA3 is used to trigger an intra-frequency handover
based either on RSRP or RSRQ measurements.
The following sections details the different mechanisms that lead to handover a call to
another cell in the same frequency, including measurements, reporting, detection, and
handover execution.
On reception of measurement report, the eNB may decide to trigger intra-eNB handover, or
inter-eNB handover through the X2 or the S1 interface.
6.1.1 INVOKING INTRA-FREQUENCY RRC CONNECTED MODE

MOBILITY
Intra-frequency mobility procedure is invoked when the neighbour cell becomes offset
better than the serving cell in the same frequency band. To simplify, the following scenario
does consider cell and frequency offsets are not used. Intra-frequency mobility mode is
based on the following principles:
1. If EventA3 entering condition is satisfied (Mn -eventA3Offset> Ms + hysteresis)
during timeToTrigger period, UE will start sending measurement reports EventA3
(relying on triggerQuantity configuration).
2. Those measurement reports EventA3 contains a maximum number of reported
cells equal to maxReportCells and will be reported with periodicity equal to
reportInterval and a maximum number of reportAmount repeated times.
3. Upon reception of measurement reports EventA3 with illegible cells Intra-
frequency mobility is detected and handover to the best reported cell is triggered.
4. Meanwhile, If EventA3 leaving condition is satisfied (Mn -eventA3Offset< Ms -
hysteresis) during timeToTrigger period, measurements are disarmed.
The following sub-sections details the parameters impacting the mechanism that leads to
invoke the intra-frequency mobility. Please note that summary of UE measurement
configurations may be found in section 5.2, including event A3 reference.
Page 192/543
Volume 6 : Mobility
Measurement eventA3
Mn
off
Mn - Hyst
TimeToTrigger
Ms + Off
hyst Ms
t
Figure 43 : 3GPP Parameters in relationship with Event A3: Entering condition
Mn
Ms Trigger EventA3
LteNeighboringCellRelation MeasObjectEUTRA::offsetFreq : dB0

neighbor cell
::cellIndividualOffset: dB0 LteNeighboringCellRelation::cellIndividualOffset : dB0
MeasObjectEUTRA::offsetFreq : dB0
eportConfigEUTRA::eventA3Offset : 2.0
reportConfigEUTRA::hysteresis : 2.0
serving cell
reportAmount
reportQuantity
timeToTrigger:ms40 time
reportInterval: ms240
Figure 44 : Event A3 and parameters: Entering condition
Page 193/543
Volume 6 : Mobility
Mn
Ms
LteNeighboringCellRelation EventA3 Leaving
::cellIndividualOffset: dB0 LteNeighboringCellRelation::
MeasObjectEUTRA::offsetFreq : dB0 cellIndividualOffset : dB0
MeasObjectEUTRA::offsetFreq : dB0
eportConfigEUTRA::eventA3Offset : 2.0
reportConfigEUTRA::hysteresis : 2.0
serving cell
neighbor cell
reportQuantity
time
timeToTrigger:ms40 reportOnLeave
Figure 45 : Event A3 and parameters: Leaving condition
6.1.1.1 EVENTA3 MEASUREMENT CONFIGURATION MODEL
The EventA3 configuration model is described in the next figure including hierarchy and
associations (pointers) of the MOs and MOs cardinality.
Page 194/543
Volume 6 : Mobility
ENBEquipment MeasurementIdentityConf MO: each
LteNeighboringCellRelation/2- 48
instance defines a RRC measurement
eNB LteNeighboringCellRelation/1
cellIndividualOffset identity and refers to an instance of
LTECell MeasObject MO and an instance of
•cellIndividualOffset
ReportConfig MO. The parameter
LteNeighboringFreqConf/0-8
measurementPurpose identifies the goal
•LteNeighboringFreqConf/0 of the measurement.
LteNeighboring/0 To identify that an instance of

RRCMeasurementConf/0-5 MeasurementIdentityConf is relating to a
•filterCoefficientRSRP
mobility case to EUTRA-FDD, the
RrmServices parameter measurementPurpose shall be
•filterCoefficientRSRQ set to Mobility-Intra-Freq (or
UeMeasurementConf
Automatic-Neighbor-Relation )
•sMeasure
ReportConfig MO: each instance
MeasurementIdentityConf/0-47
defines the characteristics of the
•measurementPurpose measurements.
MeasObject/0-31 MeasObjectEUTRA A specific instance will be

valorized in MIM to configure the
•offsetFreq RRC measurement dedicated to
MeasObjectUTRA the event A3 for EUTRA-FDD.
•dlEARFCN
ReportConfig/0-31 ReportConfig MO: Each instance
ReportConfigEUTRA has a child ReportConfigEUTRA.
Other children for intra-frequency
•triggerQuantity measurements and inter-RAT
measurements towards GERAN and
•triggerTypeEUTRA HRPD
•Hysteresis
ReportConfigUTRA
•eventA3Offset
•timeToTrigger
Figure 46 : EventA3 measurements configuration
In each cell,the UE measurements configuration (i.e. the list of one or more measurement
identities and their related measurement configuration parameters) is provided by the MO
RrcMeasurementConf.
Each measurement (i.e. measurement identity and its related configuration parameters) is
defined by one instance of the MO MeasurementIdentityConf.
Each instance of the MeasurementIdentityConftogether with
associatedMOsReportConfigandMeasObject form a complete configuration of one RRC
measurement configuration.
One instance of the MO MeasurementIdentityConfis a profile of one RRC measurement
configuration. In the eNB one or more profiles (instances of
MeasurementIdentityConf)could be configured. The profiles are shared in the cells under
the eNB among the measurement configurations (i.e. RrcMeasurementConf).
6.1.1.2 RRC MEASUREMENT CONFIGURATION PARAMETERS
Measurement configurations for inter-frequency handover come from instances of object

MeasurementIdentityConf whose attribute measurementPurpose is set to Inter-
frequency-handover-trigger.
Page 195/543
Volume 6 : Mobility
The RrcMeasurementConfcontains parameters needed to configure the IEs in the
RRCConnectionReconfiguration. The MO MeasurementIdentityConf contains the
RRCMeasId and the associations with the MOs ReportConfigand MeasObject which
contains the parameters to configure the RRC ReportConfigand respectively MeasObject.
One or more instances of the MO MeasurementIdentityConfcan be configured with the
measurementPurpose attribute set toMobility-Intra-Freq.
Only intra-frequencyeventA3is used to trigger an intra-frequency handover. This
could be triggered either on RSRP or RSRQ.
One instance of MeasurementIdentityConfMO can be configured with
measurementPurpose attribute set to “Automatic-Neighbor-Relation”.
This type of measurement is only dedicated to ANR function and is not used for call
management.
The eNB could provide or not neighbour list to the UE based on MIM configuration. If the
eNB does NOT provide a neighbour list to the UE, the UE is able to detect on its own
the radio identity of the neighbour cells. The eNB should have via MIM configuration a
mapping between this radio cell id and the associated X2 interface.
Neighbour cells that do not support the serving PLMN or the list of equivalent PLMN, or are
in the forbidden TAs, or with LteNeighboringCellRelation::cellIndividualOffset being
unset will be excluded from the neighbour cell list and will be included from the black cell
list in MeasObjectEUTRA sent to UE for intra-LTE intra-frequency or inter-frequency
measurement.
Note: measIDdo not exist like OAM parameter in LA3.0, but is broadcasted by the Call P.
The quantities used to evaluate the triggering condition for the event. The values rsrp and
rsrq correspond to Reference Signal Received Power (RSRP) and Reference Signal
Received Quality (RSRQ)[R10]
Page 196/543
Volume 6 : Mobility
• filterCoefficientRSRP:[R10]. This parameter configures the RRC IE

filterCoefficientRSRP included in the IE quantityConfigEUTRA in the
MeasurementConfiguration IE.
RrcMeasurementConf::filterCoefficientRSRP
Parameter filterCoefficientRSRP
Object ENBEquipment/ Enb/ RrmServices/ UeMeasurementConf/

RrcMeasurementConf

[fc0, fc1, fc2, fc3, fc4, fc5, fc6, fc7, fc8, fc9, fc11, fc13, fc15, fc17,
fc19]
Value Fc8
Feature L96760
Note: The higher the value of filterCoefficientRSRP, the less likely ping-ponging occurs
between sectors.
Engineering Recommendation: filterCoefficientRSRP
When triggerQuantity = ‘rsrp’, eventA3 related parameter settings recommended by

ALU performance teams are as below:
The parameter values to be used in the environments with UE of all speed (This set of
parameter values are default settings):
• hysteresis = 1 dB
• eventA3Offset = 1 dB for mobility measurements, eventA3Offset = -1 dB for
ANR measurements
• timeToTrigger = 40 ms
• filterCoefficientRSRP = fc8
The parameter values to be used in the environments with primarily low
mobility/stationary UE:
• eventA3Offset = 2 dB for mobility measurements, eventA3Offset = 0 dB for
ANR measurements
Page 197/543
Volume 6 : Mobility
• filterCoefficientRSRQ:[R10]. This parameter configures the RRC IE

filterCoefficientRSRQ included in the IE quantityConfigEUTRA in the
MeasurementConfiguration IE.
RrcMeasurementConf::filterCoefficientRSRQ
Parameter filterCoefficientRSRQ

RrcMeasurementConf

[fc0, fc1, fc2, fc3, fc4, fc5, fc6, fc7, fc8, fc9, fc11, fc13, fc15, fc17,
fc19]
Value Fc8
Feature L96760
Engineering Recommendation: filterCoefficientRSRQ
Must be kept consistent withfilterCoefficientRSRPvalue, at this moment.
MeasConfig field descriptions

measObjectToRemoveList
List of measurement objects to remove.
measObjectLink
Used to identify a measurement object configuration.
measObject
Specifies measurement object configurations for E-UTRA, UTRA, GERAN, or CDMA2000 measurements.
reportConfigToRemoveList
List of measurement reporting configurations to remove.
reportConfigId
Used to identify a measurement reporting configuration.
reportConfig
Specifies measurement reporting configurations for E-UTRA, UTRA, GERAN, or CDMA2000 measurements.
measIdToRemoveList
List of measurement identities to remove.
measGapConfig
Used to setup and release measurement gaps.
s-Measure
Serving cell quality threshold controlling whether or not the UE is required to perform measurements of intra-
frequency, inter-frequency and inter-RAT neighbouring cells. Value “0” indicates to disable s-Measure.
PreRegistrationInfoHRPD
The CDMA2000 HRPD Pre-Registration Information tells the UE if it should pre-register with the CDMA2000 HRPD
network and identifies the Pre-registration zone to the UE.
timeToTrigger-SF
The timeToTrigger in ReportConfigEUTRA and in ReportConfigInterRAT are multiplied with the scaling factor
applicable for the UE’s speed state.
Table 14:MeasConfig information element
• measurementIdentityConfIdList: This parameter refers to the instance of

MeasurementIdentityConf MO that must be considered when the UE is handled on
this cell.
Page 198/543
Volume 6 : Mobility
RrcMeasurementConf::measurementIdentityConfIdList
Parameter measurementIdentityConfIdList

RrcMeasurementConf

listSizeMin = 1
listSizeMax = 16
Value Value is a link, see Engineering Recommendation
Feature
Rule: Regarding measurementIdentityConfIdList

measurementIdentityConfIdList must point to a list of existing
MeasurementIdentityConf MO.
Engineering Recommendation: measurementIdentityConfIdList
The recommended value for this parameter is the following:

RrmServices/X UeMeasurementConf/Y MeasurementIdentityConf/Z
• sMeasure:3GPP 36.331. This parameter configures the RRC IE s-Measure used to

define the serving cell quality threshold controlling whether or not the UE is
required to perform measurements of intra-frequency, inter-frequency and inter-
RAT neighbouring cells. Value in dBm.
RrcMeasurementConf::sMeasure
Parameter sMeasure

RrcMeasurementConf

[-140..-43] step = 1
Value -43
Feature L96760, 92079
Page 199/543
Volume 6 : Mobility
The MO MeasurementIdentityConf contains the RRC reportConfigId and
MeasObjectLink the associations with the MOs ReportConfigand MeasObject which
contains the parameters to configure the RRC ReportConfigand respectively
MeasObject.
• triggerQuantity:3GPP 36.331. This parameter configures the RRC IE
triggerQuantity included in the IE reportConfigEUTRA in the
MeasurementConfiguration IE
ReportConfigEUTRA::triggerQuantity
Parameter triggerQuantity

ReportConfig/ ReportConfigEUTRA

[rsrp, rsrq]
Value rsrp (Refer to Rules below)
Feature L96760, LL103792
Rule: triggerQuantity
For all mobility related measurements, triggerQuantity may be set to RSRP in

ReportConfigEUTRA/0 and/or RSRQ in ReportConfigEUTRA/1.
If both measurements are activated, the measurement which trigger the HO is the
one first met the HO criterions
For ‘Automatic-Neighbor-Relation’ trigger, the recommended value for
triggerQuantity is ‘rsrp’.
For ‘Report-CGI’ trigger, triggerQuantity is not used but must not be left unset.
• reportQuantity:3GPP 36.331. This parameter configures the RRC IE reportQuantity

included in the IE reportConfigEUTRA in the MeasurementConfiguration IE
ReportConfigEUTRA::reportQuantity
Parameter reportQuantity


[sameAsTriggerQuantity, both]
Value Refer to Engineering Recommendation below.
Page 200/543
Volume 6 : Mobility
Engineering Recommendation: reportQuantity
For all mobility related measurements using eventA1, eventA2, eventA3, event4 and
eventA5, reportQuantity should be set to ‘both’.
For ‘Automatic-Neighbor-Relation’ trigger, reportQuantity should be set to
‘sameAsTriggerQuantity’.
For ‘Report-CGI’ trigger, reportQuantity is not used but must not be left unset.
ReportConfigEUTRA::maxReportCells
Parameter maxReportCells

Range & Unit integer

[1..8] step = 1
Value Refer to Engineering Recommendation below

Notes: This parameter defines the maximum number of cells to be reported in a
measurement report.
Engineering Recommendation: maxReportCells
This parameter allows UE to report up to number of maxReportCells neighbour cells

in each MeasurementReport message. UE may include less than maxReportCells
neighbour cells in the MeasurementReport message based on environment (e.g. how
many neighbour cells actually exist) and the settings of other measurement
configuration parameters (e.g. how many neighbour cells are good enough to trigger
the report based on measurement configuration).
For all mobility related measurements, the default value of the corresponding
maxReportCellsis set to ‘3’.
For ‘Automatic-Neighbor-Relation’ trigger, the value of the corresponding
maxReportCells should be set to the maximum value of ‘8’. Thisis to ensure UE to
report as many new neighbour cells as possible in a short time.
For ‘Report-CGI’ trigger, maxReportCells is not used but must not be left unset.
Page 201/543
Volume 6 : Mobility
ReportConfigEUTRA field descriptions
eventId
Choice of E-UTRA event triggered reporting criteria.
aN-ThresholdM
Threshold to be used in EUTRA measurement report triggering condition for event number aN. If multiple thresholds
are defined for event number aN, the thresholds are differentiated by M.
a3-Offset
Offset value to be used in EUTRA measurement report triggering condition for event a3. The actual value is IE value *
0.5 dB.
reportOnLeave
Indicates whether or not the UE shall initiate the measurement reporting procedure when the leaving condition is met
for a cell in cellsTriggeredList, as specified in [R10] section 5.5.4.1.
triggerQuantity
The quantities used to evaluate the triggering condition for the event. The values rsrp and rsrq correspond to
Reference Signal Received Power (RSRP) and Reference Signal Received Quality (RSRQ), see TS 36.214 [48].
timeToTrigger
Time during which specific criteria for the event needs to be met in order to trigger a measurement report.
reportQuantity
The quantities to be included in the measurement report. The value both means that both the rsrp and rsrq quantities
are to be included in the measurement report.
maxReportCells
Max number of cells, excluding the serving cell, to include in the measurement report.
reportAmount
Number of measurement reports applicable for triggerType ‘event’ as well as for triggerType ‘periodical’. In case
purposeis set to ‘reportCGI’ only value 1 applies.
ThresholdEUTRA
For RSRP: RSRP based threshold for event evaluation.
For RSRQ: RSRQ based threshold for event evaluation.
Table 15:ReportConfigEUTRA information element
• hysteresis:3GPP 36.331. This parameter configures the RRC IE hysteresis included

in the IE reportConfigEUTRA in the MeasurementConfiguration IE. The value sent
over the RRC interface is twice the value configured (the UE then divides the received
value by 2).
ReportConfigEUTRA::hysteresis
Parameter hysteresis

Range & Unit dB

[0.0..15.0] step = 0.5
Feature L96760, 92079, LL103792

Note: hysteresis is used in several process: Event A3 (Neighbour becomes offset better
than serving); Event A2 (Serving becomes worse than threshold); Event A1 (Serving
becomes better than threshold); Event A4 (Neighbour becomes better than threshold);
Event A5 (Serving becomes worse than threshold1 and neighbour becomes better than
threshold2). The 3GPP name is Hys in [R10]
Page 202/543
Volume 6 : Mobility
Engineering Recommendation: hysteresis
Some field trials does demonstrate better performance when Total Offset (Hysteresis +
EventA3Offset) for handover does equal 3.5 dB. Using lower values for the Total Offset
may generate, in normal mobility environments, too many transitions and consequent
conditions to have more drops.
When triggerQuantity = ‘rsrp’, eventA3 related parameter settings recommended by ALU
performance teams are as below:
• hysteresis = 2.5 dB
ANR measurements
• eventA3Offset = 2 dB for mobility measurements, eventA3Offset = 0 dB for ANR
measurements
For LTE to eHRPD mobility:

1. For event A1 measurement with measurementPurpose = Leaving-Coverage-Alarm,
hysteresisis set to 1.0 dB.
2. For event A2 measurement with measurementPurpose = Entering-Coverage-Alarm,

3. For event A2 measurement with measurementPurpose = Below-Serving-Floor,
For intra-frequency ANR (event A3) and inter-frequency ANR (event A4) measurement,
the recommended value for this parameter is 1dB.
Engineering Recommendation: hysteresisand inter-working withtriggerQuantity for

Event A2
The recommended value for hysteresisis 1.0 when triggerQuantityis set to RSRP.
Page 203/543
Volume 6 : Mobility
Rule: hysteresis
For ‘Report-CGI’ trigger, hysteresisis not used but must not be left unset.
• timeToTrigger: 3GPP 36.331. This parameter configures the RRC IE TimeToTrigger

This parameter defines the period of time during which the conditions to trigger an event
report have to be satisfied before sending a RRC measurement report in event triggered
mode
timeToTriggeris used in several process: Measurement identity removal; Measurement
identity addition/ modification; Measurement object removal; Measurement object addition/
modification; Reporting configuration removal; Reporting configuration addition/
modification; Quantity configuration; in general in Measurement report triggering;
Measurement related actions upon handover and re-establishment; [R10]
ReportConfigEUTRA::timeToTrigger
Parameter timeToTrigger

Range & Unit Enumerate, ms

ms480, ms512, ms640, ms1024, ms1280, ms2560, ms5120]
Value Refer to Engineering Recommendation and Rule below
Rule: timeToTrigger
For ‘Automatic-Neighbor-Relation’ trigger, timeToTrigger can only be set to the

same value of the timeToTrigger (corresponding to triggerQuantity = ‘rsrp’ if it
exists; otherwise, corresponding to triggerQuantity = ‘rspq’) used for ‘intra-
frequency-handover-trigger’.
For ‘Report-CGI’ trigger, timeToTrigger is not used but must not be left unset.
Page 204/543
Volume 6 : Mobility
Engineering Recommendation: timeToTrigger
When triggerQuantity = ‘rsrp’, eventA3 related parameter settings recommended by ALU

performance teams are as below:
ANR measurements
• eventA3Offset = 2 dB for mobility measurements, eventA3Offset = 0 dB for ANR
measurements
This parameter is recommended to be set to ms40 for eventA2.
Hysteresis used to tuning HO decision

RSRP Target Cell
8 Serving Cell hysteresis
7
6
5
4
3
2
1
0
5
timeToTrigger 10 15 20 25 30 35 Time
reportingInterval reportAmount: nb of mes.
Figure 47 : Hysteresis used to tuning HO decision, reportAmount = 4
Page 205/543
Volume 6 : Mobility
• reportInterval:3GPP 36.331. This parameter configures the RRC IE reportInterval
ReportConfigEUTRA::reportInterval
Parameter reportInterval

Range & Unit Enumerate in ms or min

[ms120, ms240, ms480, ms640, ms1024, ms2048, ms5120,
ms10240, min1, min6, min12, min30, min60]
Engineering Recommendation: reportInterval
For event A3 LTE intra-frequency HO, the recommended value for

reportIntervalisms240.
As the current default value of reportAmount for ‘Automatic-Neighbor-Relation’ is set to
‘r1’, the value of reportInterval is not used by UE.
For LTE to eHRPD redirection:
1. For event A1 measurement with measurementPurpose = Leaving-Coverage-Alarm
measurement, reportIntervalis set to 240 ms.
2. For event A2 measurement with measurementPurpose = Entering-Coverage-Alarm
3. For event A2 measurement with measurementPurpose = Below-Serving-Floor
The ReportInterval indicates the interval between periodical reports. The

ReportIntervalis applicable if the UE performs periodical reporting (i.e. when
reportAmount exceeds 1), for triggerType ‘event’ as well as for triggerType
‘periodical’.[R10]
• reportAmount:3GPP 36.331. This parameter configures the RRC IE reportAmount

reportIntervalis used in the process: Measurement reporting [R10] ;
1> if the numberOfReportsSent as defined within the VarMeasReportList for thismeasIdis

less than the reportAmount as defined within the corresponding reportConfig for
thismeasId:
Page 206/543
Volume 6 : Mobility
2> start the periodical reporting timer with the value of reportInterval as defined within
the corresponding reportConfig for thismeasId;[R10]
ReportConfigEUTRA::reportAmount
Parameter reportAmount


[r1, r2, r4, r8, r16, r32, r64, infinity]
Value Refer to Engineering Recommendation below.

This parameter configures the number of periodical reports the UE has to transmit after the
event was triggered.
This parameter informs UE to send up to number of reportAmount duplicated
measurement reports during the interval when the measurement report entering condition
is continuously satisfied.
Engineering Recommendation: reportAmount
For all intra-LTE mobility related measurements, the recommended value for
reportAmount is ‘r4’
For ‘Automatic-Neighbor-Relation’ trigger, the value of the corresponding
reportAmount must be set to ‘r1’.
For ‘Report-CGI’ trigger, the value of the corresponding reportAmount must be set to
‘r1’.

1. For event A1 measurement with measurementPurpose = Leaving-Coverage-
Alarm, reportAmountis set to r8.
2. For event A2 measurement with measurementPurpose = Entering-Coverage-
Alarm, reportAmountis set to r8.
3. For event A2 measurement with measurementPurpose = Below-Serving-Floor
measurement, reportAmountis set to r8.
6.1.1.3 THRESHOLDS FOR INTER-RAT MOBILITY WITH INTRA-

LTE MEASUREMENTS: BLIND
• triggerTypeEUTRA: This parameter configures the RRC IE triggerType included in

the IE reportConfigEUTRA in the MeasurementConfiguration IE .This parameter
Page 207/543
Volume 6 : Mobility
defines the event-triggered type of the intra-frequency measurement , of the RRC
measurement.
ReportConfigEUTRA::triggerTypeEUTRA
Parameter triggerTypeEUTRA


[eventA3, periodicalStrongestCells, eventA2, eventA4, eventA1,
eventA5, periodicalReportCGI]
Value Refer to Restriction below
Feature L96760
Restriction: triggerTypeEUTRA
For measurementPurpose = ‘Leaving-Coverage-Alarm’, triggerTypeEUTRA should
be set to ‘eventA1’.
For measurementPurpose = ‘Entering-Coverage-Alarm’ or ‘Below-Serving-Floor’,

triggerTypeEUTRA should be set to ‘eventA2’.
For measurementPurpose = ‘Mobility-Intra-Freq’, triggerTypeEUTRA should be set

to ‘eventA3’.
For measurementPurpose = ‘Mobility-Inter-Freq-to-EUTRA’, an instance of

triggerTypeEUTRA should be set to ‘eventA3’. Another instance of
triggerTypeEUTRA should be set to ‘eventA5’.
For measurementPurpose = ‘Automatic-Neighbor-Relation’ for intra-frequency ANR,

the recommended setting for triggerTypeEUTRAis ‘eventA3’. triggerTypeEUTRA
may also be set to ‘eventA4’ or ‘eventA5’ for testing purpose. Only one instance of
triggerTypeEUTRA for measurementPurpose = ‘Automatic-Neighbor-Relation’ can
exist for the serving frequency.
For measurementPurpose = ‘Automatic-Neighbor-Relation’ for inter-frequency ANR,

the recommended setting for triggerTypeEUTRAis ‘eventA4’. triggerTypeEUTRA
may also be set to ‘eventA3’ or ‘eventA5’.Only one instance of triggerTypeEUTRA
for measurementPurpose = ‘Automatic-Neighbor-Relation’ can exist the neighbour
frequency.
For measurementPurpose = ‘Report-CGI’, triggerTypeEUTRA should be set to

‘periodicalReportCGI’
Page 208/543
Volume 6 : Mobility
eventA3Offset:[R10]This peventA3Offset parameter configures the RRC IE a3-Offset
included in the IE reportConfigEUTRA in the MeasurementConfiguration IE. This IE
should be present if the parameter triggerTypeEUTRAis set to eventA3. Otherwise it
should be absent. The value sent over the RRC interface is twice the value configured (the
UE then divides the received value by 2)
ReportConfigEUTRA::eventA3Offset
Parameter eventA3Offset

Range & Unit dB

[-15.0..15.0] step = 0.5
Feature L96760
Page 209/543
Volume 6 : Mobility
Engineering Recommendation: eventA3Offset
Some field trials does demonstrate better performance when Total Offset (Hysteresis
+ EventA3Offset) for handover does equal 3.5 dB. Using lower values for the Total
Offset may generate, in normal mobility environments, too many transitions and
consequent conditions to have more drops.
When triggerQuantity = ‘rsrp’, eventA3 related parameter settings recommended by
ALU performance teams are as below:
ANR measurements
• eventA3Offset = 2 dB for mobility measurements, eventA3Offset = 0 dB for
ANR measurements
The value of eventA3Offset ANR usedfor measurementPurpose = ‘Automatic-

Neighbor-Relation’ trigger should be set to a value around 2 dB lower than the value of
eventA3Offset HO used for measurementPurpose = ‘Mobility-Intra-Freq’, unless the
more conservative ANR option is being used where ANR measurement is configured
more conservatively than mobility.
Page 210/543
Volume 6 : Mobility
• thresholdEutraRsrp:[R10]. This parameter configures the RRC IE Threshold EUTRA
RSRP included in the IE reportConfigEUTRA in the MeasurementConfiguration IE.
This IE should be present if the parameter triggerTypeEUTRAis set to eventA1,
eventA2, eventA4 or eventA5 and triggerQuantityis set to RSRP. Otherwise it
should be absent.
ReportConfigEUTRA::thresholdEutraRsrp
Parameter thresholdEutraRsrp


[-140 ... -43] step = 1
Engineering Recommendation: thresholdEutraRsrp

• For event A1 measurement with measurementPurpose = Leaving-Coverage-
Alarm, this parameter is set to -105 dBm.
• For event A2 measurement with measurementPurpose = Entering-Coverage-
Alarm, this parameter is set to -108 dBm.
• For event A2 measurement with measurementPurpose = Below-Serving-
Floor, this parameter is set to -116 dBm.
For inter-frequency ANR event A4 measurement (measurementPurpose = Automatic-
Neighbor-Relation, the recommended value for this parameter is -100 dBm.
Page 211/543
Volume 6 : Mobility
• thresholdEutraRsrq:[R10]This parameter configures the RRC IE Threshold EUTRA

RSRQ included in the IE reportConfigEUTRA in the MeasurementConfiguration IE.
This IE should be present if the parameter triggerTypeEUTRAis set to eventA1,
eventA2, eventA4 or eventA5 and triggerQuantityis set to RSRQ. Otherwise it
should be absent.
ReportConfigEUTRA::thresholdEutraRsrq
Parameter thresholdEutraRsrq

Range & Unit Float in dB

[-20 ... -3] step = 0.5
Value N.A.
Feature L81872
LteCell::cellIndividualOffset
Parameter cellIndividualOffset

[dB-24, dB-22, dB-20, dB-18, dB-16, dB-14, dB-12, dB-10, dB-8, dB-
6, dB-5, dB-4, dB-3, dB-2, dB-1, dB0, dB1, dB2, dB3, dB4, dB5,
Value dB0
Feature
Notes: This parameter specifies the cell specific offset of the serving cell (i.e.
cellIndividualOffset as defined within measObjectEUTRA corresponding to the serving
frequency). It corresponds to Ocs in event A3 entering condition and leaving condition as
defined in TS 36.331. If the parameter is set to default value of dB0, it will be omitted from
measObjectEUTRA IE sent to UE.
Page 212/543
Volume 6 : Mobility
Radio Level
Quality (dB) or
Power (dBm)
interRAT
A2_CA_threshold
(serving)
interFreq
serving A2_floor for

A2_floor_threshold
redirection
(serving)
A2_floor reception
GOOD BAD
Figure 48 : Redirection towards another RAT or carrier
A2_floor_threshold in the chart above is thresholdEutraRsrp or thresholdEutraRsrq

threshold.
The UE is established within the serving cell. The intra-LTE intra-frequency measurements
for the monitoring of the serving floor are configured in the UE. The radio conditions enter
bad radio conditions. The ENB receives an intra-frequency measurement report indicating
that the serving radio level is below this floor, the ENB redirects to another (RAT;carrier) by
an inter-frequency or inter-RAT mobility procedure in a blindly fashion i.e. without
measurements on the target (RAT;Carrier)
Page 213/543
Volume 6 : Mobility
RRMServices/0
RRCMeasurementConf/0 (0..5)
UEMeasurementConf/0 •measurementIdentityConfidList = /0, /1 (up to 16

links)
•timeToTriggerSfMedium
•timeToTriggerSfHigh
MeasurementIdentityConf/0
MeasurementIdentityConf/1(up to 47)
•measurementPurpose = Mobility-Intra-Freq
•measurementPurpose = Mobility-Intra-Freq
•measObjectLink= /0
•measObjectLink= /0
•reportConfigLink= /0
•reportConfigLink= /1
MeasObject/0 (up to 31) MeasObjectEUTRA/0
•offsetFreq (OD)
•dlEARFCN (OD)
ReportConfig/1 (up to 31)

ReportConfig/0 ReportConfigEUTRA/0 ReportConfigEUTRA/0
•EventA3Offset •EventA3Offset
•hysteresis •hysteresis
•timeToTrigger •timeToTrigger
•triggerQuantity = rsrp •triggerQuantity = rsrq

•triggerTypeEUTRA = eventA3 •triggerTypeEUTRA = eventA3
Figure 49 : Blind and intraFreq Measurements for

redirection towards another RAT or carrier
6.1.1.4 SPEED STATE MEASUREMENTS CONFIGURATION
Parameters working to configure speed state measurements configuration for intra-LTE

mobility also configure the speed state measurements configuration for inter-RAT mobility.
The implementation is similar to the state idle mode, but with the following parameters:
Page 214/543
Volume 6 : Mobility
• tEvaluation:TS36.331: this parameter contributes to the configuration of the IE
MeasConfig. This parameter configures the IE t-Evaluation included in the IE
MobilityStateParameters. The duration for evaluating criteria to enter mobility states.
Corresponds to TCRmax in TS 36.304. Value in seconds, s30 corresponds to 30 s
and so on.
• nCellChangeHigh: TS36.331: this parameter contributes to the configuration of the IE
MeasConfig. This parameter configures the IE n-CellChangeHigh included in the IE
MobilityStateParameters. The number of cell changes to enter high mobility state.
Corresponds to NCR_H in TS 36.304.
• nCellChangeMedium: TS36.331: this parameter contributes to the configuration of
the IE MeasConfig.This parameter configures the IE n-CellChangeMedium included in
the IE MobilityStateParameters. The number of cell changes to enter medium mobility
state. Corresponds to NCR_M in TS 36.304.
• tHystNormal:TS36.331: this parameter contributes to the configuration of the IE
MeasConfig. This parameter configures the IE t-HystNormal included in the IE
MobilityStateParameters. The additional duration for evaluating criteria to enter normal
mobility state. Corresponds to TCRmaxHyst in TS 36.304. Value in seconds, s30
LA2.0 – LA3.0 :tEvaluation, nCellChangeHigh, nCellChangeMedium,

tHystNormal
These parameters are now under Enb/ LteCell/ LteNeighboring/

SpeedStateEvalConf and are the same as for the reselection case.
• timeToTriggerSfHigh:TS36.331: this parameter configures the timeToTrigger-SF

included in the IE MeasConfig. Parameter “Speed dependent ScalingFactor for
timeToTrigger”. The concerned mobility control related parameter is multiplied with
this factor if the UE is in High Mobility state as defined in TS 36.304. Value oDot25
corresponds to 0.25, oDot5 corresponds to 0.5, oDot75 corresponds to 0.75 and so
on.
RrcMeasurementConf::timeToTriggerSfHigh
Parameter timeToTriggerSfHigh

RrcMeasurementConf

Value N.A.
Feature L76498, 108283
Page 215/543
Volume 6 : Mobility
• timeToTriggerSfMedium:TS36.331: this parameter configures the timeToTrigger-SF
included in the IE MeasConfig. Parameter “Speed dependent ScalingFactor for
timeToTrigger”. The concerned mobility control related parameter is multiplied with
this factor if the UE is in Medium Mobility state as defined in TS 36.304. Value
oDot25 corresponds to 0.25, oDot5 corresponds to 0.5, oDot75 corresponds to 0.75
and so on.
RrcMeasurementConf::timeToTriggerSfMedium
Parameter timeToTriggerSfMedium

RrcMeasurementConf

Value N.A.
Feature L76498, 108283
6.1.2 REPORTING SETTING FOR INTRA-FREQUENCY

MEASUREMENTS
The handover strategy relies entirely on measurement reports from the UE. The UE
reports to the eNB when the handover trigger conditions are met. Upon receipt of the
measurement report the eNBis expected to trigger a handover procedure as per section
6.1.4.2 or 6.1.4.3 or 6.1.4.4.
The measurements are setup, modified or deleted in the UE using RRC signalling, more
precisely the RRCConnectionReconfiguration message including the IE
“MeasurementConfiguration”.
The measurements defined as intra-frequency LTE mobility triggers are configured as early
as possible in the UE. These measurements are identified by a measurement identity
configured to measId and the
attributeMeasurementIdentityConf.measurementPurposeequal to “Mobility-Intra-Freq”
Page 216/543
Volume 6 : Mobility
• measurementPurpose:This parameter configures the purpose of this measurement
reporting.
MeasurementIdentityConf::measurementPurpose
Parameter measurementPurpose

MeasurementIdentityConf

[Mobility-Intra-Freq (0),
Mobility-Inter-RAT-to-HRPD (1),
Automatic-Neighbor-Relation (2),
Report-CGI (3),
Leaving-Coverage-Alarm (4),
Entering-Coverage-Alarm (5),
Below-Serving-Floor(6),
Mobility-Inter-RAT-to-UTRA(7),
Mobility-Inter-RAT-to-GERAN(8),
Mobility-Inter-Freq-to-EUTRA(9),
Report-Strongest-Cells-For-SON (10),
EcidTimingMeas(11),
EcidRsrqRsrpMeas(12),
Report-Strongest-Cells-forCsfbTo1XRtt(13)
Cell-Edge-Intra-Freq(14),
Mobility-To-CSG-Cell(15),
Mobility-Inter-RAT-to-UTRA-CSG-Cell(16)]
Class/Source C - New-set-ups / customer_init
Value O.D.
Feature L96760, L96371, L96371, L92025, L92026, L103792, 103896,

134791
Rule: measurementPurpose
Only one instance of MeasurementIdentityConf MO per cell can have

measurementPurpose set to ‘Automatic-Neighbor-Relation’.
Only one instance of MeasurementIdentityConf MO per cell can have
measurementPurpose set to ‘Report-CGI’
The parameters below are under the scope of measurement information elements.
Page 217/543
Volume 6 : Mobility
MeasurementIdentityConf::measObjectLink
Parameter measObjectLink

Class/Source C – New Set-ups / customer_init
Value RrmServices/x UeMeasurementConf/y MeasObject/z
Feature L96760
Notes: This parameter refers to the instance of the MeasObject MO that is considered
when the UE is configured with the measurement configured by the instance of the MO
MeasurementIdentityConf.
MeasurementIdentityConf::reportConfigLink
Parameter reportConfigLink

Class/Source C – new set-ups / customer_init
Value RrmServices/x UeMeasurementConf/y ReportConfig/z
Feature L96760
Notes: This parameter refers to the instance of the ReportConfig MO that is considered
when the UE is configured with the measurement configured by this instance of the MO
MeasurementIdentityConf.
ReportConfig::reportConfigId
Parameter reportConfigId

ReportConfig

[1..32] step = 1
Class/Source C – new set-ups / customer_init
Value O.D.
Feature L96760
Notes: This parameter specifies the RRC IE reportConfigId in the ReportConfig IE.
Page 218/543
Volume 6 : Mobility
6.1.2.1 MEASUREMENT SETUP UPON TRANSITION TO RRC-
CONNECTED STATE
If the intra-frequency mobility is enabled via MIM configuration (i.e.

isIntraFreqMobilityAllowedset to TRUE in MO ActivationService) the eNB will initiate a
RRC Connection reconfiguration procedure after the RRC Connection establishment
completion to setup the intra-frequency measurements corresponding to the instances of
the MOs MeasurementIdentityConf having the parameter measurementPurposeset to
“Mobility-Intra-Freq”
If the procedure fails the UE will transit to idle mode. Indeed, according to 3GPP if a RRC
reconfiguration procedure fails in the UE, the UE will initiate a RRC Connection Re-
establishment procedure. If this happens before the security activation, the UE will
transit directly to idle mode.
The eNB will initiate after the default bearer establishment (and security activation) another
RRC Connection reconfiguration procedure to set-up intra-frequency measurements
corresponding to the instances of the MOs MeasurementIdentityConfhaving the
parameter measurementPurposedifferent than “Mobility-Intra-Freq” (if any).The RRC
message RRCConnectionReconfiguration includes the IE “measurementConfiguration”
used to configure the intra-frequency measurement profile described in section 6.1.1.
Thisprofileis applicable for the cell on which the call is established.
If the measurement configuration fails in the UE, it will initiate RRC Connection Re-
establishment.
UE ENB MME/SGW
S1-AP INITIAL UE MESSAGE
Default SAE Bearer establishment and security activation [A15]
MeasurementConfiguration Optional depending
RRCConnectionReconfigurationComplete on OAM configuration
UE ENB MME/SGW
Figure 50: Measurement setup at call setup
6.1.2.2 MEASUREMENT UPDATE UPON COMPLETION OF

HANDOVER
The measurement configuration is specified in section 6.1.1.
Page 219/543
Volume 6 : Mobility
The measurement configuration updated by the eNB is that of the target cell intra-
frequency measurement profile described in section 6.1.1.
Inter-eNB handover:
In case of inter-eNB handover, (both X2 based and S1 based) the target eNB updates the
measurement triggering the handover procedure (if target configuration is different from the
source configuration) by including the Measurement Configuration parameters in the
RRCConnectionReconfiguration message transmitted to the UE via the Source eNB.
Based on the MIM configuration applicable in the target cell and received UE capability, the
target eNB prepares the target cell measurement configuration. The target eNB uses the
RRC container (i.e. HandoverPreparationInformation. AS-Configuration.
MeasurementConfiguration) to learn the configuration used in the source eNB. In order to
minimize the size of the signalling message, the target eNB will update only the changing
configuration, the unchanged configuration is not signalled (i.e. OC option in asn.1
definition) and the UE keeps the previous configuration.
In the handover message, the configuration of any measurement not matching the target
cell configuration for handover trigger (i.e. same measId, same MeasObjectEUTRA, same
ReportConfigEUTRA) is handled as follows:
- Source ReportConfigEUTRAis kept in the UE,
- Source MeasObjectEUTRAis deleted. In 3GPP RRC only one MeasObject per
frequency is supported in the UE.
- Source MeasIdis kept in the UE.
After the handover procedure is completed at the target eNB (i.e. after the X2 CONTEXT
RELEASE transmitted to the Source eNB for X2 based handover, or after the end of data
forwarding if any for S1 based handover), based on its own MIM configuration, the target
eNB configures (add/modify/delete) other measurements compared to the source eNB
configuration (not for handover triggering purposes). The target eNB takes into account the
configuration resulting from the measurement update done in the handover message (as
explained in the previous paragraph) and updates it using a separate RRC procedure.
Note: The description above only applies to “event-based” UE measurements.
Page 220/543
Volume 6 : Mobility
UE Source ENB Target ENB
X2 handover preparation
MobilityControlInformation
RadioResourceConfigDedicated
UE-RelatedInformation
Detach from old cell and
synchronize to new cell
Random Access Preamble

Random Access Response
S1 Path switch procedure
X2 release resource procedure
Source ENB
MeasurementConfiguration Optional depending
RRCConnectionReconfigurationComplete on OAM configuration
UE Target ENB
Figure 51: Measurement update upon handover – inter-eNB handover
Intra-eNB handover:
In case of intra-eNB handover, the measurements are re-configured only if the
configuration of the target cell is different than the source cell.
UE Source ENB

Mobility control information
UE related information
Radio resource configuration
Detach from source cell and
synchronize to target cell
Random Access Preamble
Random Access Response
COMPLETE

Measurement configuration Optional depending
RRC CONNECTION RECONFIGURATION on OAM configuration
COMPLETE
UE Source ENB
Page 221/543
Volume 6 : Mobility
Figure 52: Measurement update upon handover – intra-eNB handover
If the measurement MIM configuration is different in the target cell compared to the source
cell the eNB updates the measurement triggering the handover procedure by including the
Measurement Configuration parameters in the RRC CONNECTION RECONFIGURATION
message transmitted to the UE.
In the handover message, the configuration of any measurement not matching the target
cell configuration for handover trigger (i.e. same MeasId, same MeasObjectEUTRA, same
ReportConfigEUTRA) is handled as follows:
- Source ReportConfigEUTRAis kept in the UE,
- Source MeasObjectEUTRAis deleted. In 3GPP RRC only one MeasObject per
frequency is supported in the UE.
- Source MeasId is kept in the UE.
After the handover procedure is completed, based on MIM configuration,the eNB
configures (add/modify/delete) other measurements compared to the source cell
configuration (not for handover triggering purposes) after the handover procedure is
completed. The eNB takes into account the configuration resulting from the measurement
update done in the handover message (as explained in the previous paragraph) and
updates it using a separate RRC procedure.
The measurement configuration fails in the UE, it will initiate RRC Connection Re-
establishment.
Rule: Regarding dlEARFCN (sourceDL-CarrierFreq under AS-Config field

descriptions in the 3GPP36.331) parameter
dlEARFCN (sourceDL-CarrierFreq)is used in the several process: in Reception of a
RRCConnectionReconfiguration including the mobilityControlInformation by the
UE (handover); in Inter-RAT mobility, in Handover to E-UTRA, in Reception of the
RRCConnectionReconfiguration by the UE; [R10]
dlEARFCNis always in relationship with ulEARFCN andfrequencyBandIndicator;

which are all decrypted in [Vol. 3]section 4.4.6LTE Air Interface
Page 222/543
Volume 6 : Mobility
• dlEARFCN: 3GPP 36.331. This parameter configures the RRC IE carrierFreqof
MeasObjectEUTRAFDD IE (sourceDL-CarrierFreq is the 3GPP name of this
parameter)
MeasObjectEUTRA::dlEARFCN
Parameter dlEARFCN

MeasObject/ MeasObjectEUTRA

[0..39649] step=1
Value O.D.
Feature
f 0, DL
Note: dlEARFCN = 10 × ( - FDL_low ) + NOffs-DL [where FDL_low and NOffs-DL
f
are some constants which various with E-UTRA Band using for radio. 0, DL is the central
carrier frequency of the bandwidth.] Please refer to [Vol. 3] section 4.4.6
• dlEARFCN: This parameter specifies the downlink EUTRAN Absolute Radio

Frequency Channel Number of a LTE carrier. If the instance of
LteNeighboringFreqConf is pointed to by the parameter
LteCell::lteNeighboringFreqsConfId, it contains the intra-frequency neighbours and
the corresponding dlEARFCN should be set to the same value as
FrequencyAndBandwidthFDD::dlEARFCN of the same LTE cell. Otherwise, the
instance of LteNeighboringFreqConf contains the inter-frequency neighbours and
the corresponding dlEARFCN should be set to the inter-frequency EUTRAN Absolute
Radio Frequency Channel Number of the neighbours.
LteNeighboringFreqConf::dlEARFCN
Parameter dlEARFCN


[0..39649] step=1
Class/Source N.A./ customer_init
Value O.D to see the rule just above
Feature 108283
Notes: If the class of a parameter is N.A., it indicates it is an R+Wc parameter. That is, the
value of the parameter can be set only when the object of LteNeighboringFreqConf is
created and cannot be updated on line after that.
Page 223/543
Volume 6 : Mobility
• offsetFreq:3GPP 36.331. This parameter configures the RRC IE offsetFreq included
in the IE MeasObjectEUTRA. Offset value applicable to the carrier frequency. If this
parameter is absent then the default value 0 is used in UE.
MeasObjectEUTRA::offsetFreq
Parameter offsetFreq

MeasObject/ MeasObjectEUTRA

[dB-24, dB-22, dB-20, dB-18, dB-16, dB-14, dB-12, dB-10, dB-8,
dB-6, dB-5, dB-4, dB-3, dB-2, dB-1, dB0, dB1, dB2, dB3, dB4, dB5,
dB6, dB8, dB10, dB12, dB14, dB16, dB18, dB20, dB22, dB24,
spare]
Value dB0
Feature L96760
Note: For the same frequency measurement, value of MeasObjectEUTRA::offsetFreqis
used to set both Ofs and Ofn.
The function of this parameter is to favour or not, HO between some specific
neighbouring frequencies.
Rule: Regarding offsetFreqparameter

offsetFreq is used in the process Event A3 (Neighbour becomes offset better than
serving) Ofs;[R10]
• offsetFreq:This parameter configures the RRC IE q-OffsetFreq, included in the SIB5.

The offset value is applicable to the carrier frequency. Not used for Intrafrequency
mobility. See 3GPP TS 36.331. 3GPP 36.331.
LteNeighboringFreqConf::offsetFreq
Parameter offsetFreq


dB6, dB8, dB10, dB12, dB14, dB16, dB18, dB20, dB22, dB24,
spare]
Value dB0
Feature 108283
Page 224/543
Volume 6 : Mobility
• neighCellConfig:This parameter advises the eNodeB of information related to
MBSFN and TDD UL/DL configuration of neighbour cells of this frequency. The
possible values are as follows (SIB3/SIB5):
00: Not all neighbour cells have the same MBSFN subframe allocation as serving cell;
10: The MBSFN subframe allocations of all neighbour cells are identical to or are subsets
of that in the serving cell;
01: No MBSFN subframes are present in any neighbour cell;
11: Different UL/DL allocation in neighbouring cells for TDD compared to the
serving cell. For TDD, 00,
10 and 01 are used only for same UL/DL allocation in neighbouring cells compared to the
serving cell.
Restriction: LA3.0
FDD current implementation, only the value 01 is supported. For TDD current
implementation, only the values 01 and 11 are supported. See 3GPP TS 36.331.
LteNeighboringFreqConf::neighCellConfig
Parameter neighCellConfig


[NotAllNeighbourHaveSameMBSFNSubframeAllocationAsServing(0),
NoMbsfnSubframesArePresent(1),
AllNeighbourHaveSameOrSubsetsMBSFNSubframeAllocationAsServing(
2),
DifferentUlDlAllocation(3)]
Value NoMbsfnSubframesArePresent
Feature 108283
Page 225/543
Volume 6 : Mobility
• presenceAntennaPort1:This parameter is used to set the IE PresenceAntennaPort1
in SIB5, which indicates whether all neighbouring cells use Antenna Port 1 on the
indicated frequency. When this parameter is set to ‘True’, UE will assume that at least
two cell-specific antenna ports are used in all neighbouring cells.
LteNeighboringFreqConf::presenceAntennaPort1
Parameter presenceAntennaPort1


[false, true]
Value True
Feature 103789, 103791
6.1.2.3 NEIGHBOR CELL INFORMATION PROVIDED TO UES IN

CONNECTED MODE
In 3GPP RRC a measurement object is defined as one on which the UE shall perform the
measurements. For intra-frequency measurements a measurement object is a single E-
UTRA carrier frequency. Associated with this carrier frequency, the eNB can configure a
list of cell specific offsets.
The eNB can configure a list of ‘blacklisted’ cells, i.e. cells that are not considered in event
evaluation or measurement reporting.
Neighbour cells can be either configured by the operator or autonomously discovered by
the eNB thanks to ANR function.
Neighbour cells are represented by an LteNeighboringCellRelationMO instance.

A neighbour cell will be included in the neighbour cell list in the measurement object only in
case it has specific (i.e. non-null) specific offset value associated. This value is provided by
“qOffsetCell” attribute attached to LteNeighboringCellRelation object class.
If a neighbour cell list is configured in the cell where initial context setup is performed the
eNB will added it (by modifying the Measurement Object) in the RRC Connection
reconfiguration procedure dedicated to measurement configuration after the initial
context setup as specified in section 6.1.2.1.
The neighbour cell list may be updated at cell change using the RRC Connection
reconfiguration procedure dedicated to measurement configuration after the handover
as specified in previous section. It is not updated in the handover command message.
If this optional parameter is implemented, then, the UE receives from the eNB the list of the
neighbouring; else, the neighbouring list is build by UE himself.
Reminder: in order to understand this algorithm, one needs to understand the roles of the
different parameters of a neighbouring cell:
2. cellIndexis only used to unambiguously identify a neighbouring cell within a
measurement configuration of a given UE
Page 226/543
Volume 6 : Mobility
3. physCellId permanently identifies a cell in the network (although it is not guaranteed
unique across the network), therefore thisis the parameter to test in order to decide
whether a neighbour of source cell and a neighbour of target cell are actually the same cell
4. cellIndividualOffsetis just a parameter of a given neighbour cell in the neighbouring
of a given cell
Principle: The algorithm compares the cell instances of the old and target configurations in
2 steps (actually 2 loops). The 1st step loops through the old configuration: instances found
identical in the target configuration are unchanged, instances found different are modified,
and instances not found are removed. The 2nd step loops through the target configuration:
instances not matched in the previous step are added.
The algorithm manages in particular the cellIndex values so that:
5. a neighbouring cell present in both source and target configurations (identified by it
physical cell identity) keeps its cellId
6. a neighbouring cell present in target configuration but not in source configuration gets
as cellId the lowest available value
The algorithm updates the target cell list by setting the cellIndex values, therefore
targetCellsList is both input and output parameter.
• cellIndividualOffset:3GPP 36.331.This parameter defines the cell individual offset

between the current LteCell and the neighbour cell provided to the UE in RRC
Connected mode for measurement. This parameter will be present if the neighbour
cell is included in the neighbour cell list to be provided in MeasObject. In dB.
LteNeighboringCellRelation::cellIndividualOffset
LteNeighboringOpenOrHybridHeNBCellLayerRelation::cellIndividualOffset
Parameter cellIndividualOffset

ENBEquipment/ Enb/ LteCell/ LteNeighboring/
LteNeighboringFreqConf/
LteNeighboringOpenOrHybridHeNBCellLayerRelation

Value dB0
Feature L96760, 134689

Note: The function of this parameter is to favour or not, HO between some specific
neighbouring cells.
Dependencies: For using this parameter, it is mandatory to set
LteNeighboringCellRelation::noHoOrReselection to Fa

ALCATEL Parameters

Uploaded by

Document Information

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

ALCATEL Parameters

Uploaded by

Copyright:

Available Formats

FDD eNodeB LTE Parameters User Guide (LPUG)

Document number: FDD eNodeB LTE Parameters User Guide

Copyright 2013 Alcatel-Lucent, All Rights Reserved

2 RELATED DOCUMENTS .................................................................................................................. 6

3 CONFIGURATION MANAGEMENT OVERVIEW ............................................................................. 7

4 LPUG TERMINOLOGY ................................................................................................................... 10

P UBLICATION HIS TORY

26-J u ly, 2013

1.2 SCOPE OF THIS DOCUMENT

Inter-Release Delta: LPUG Volumes

parameters), and Volume 8.

• Material concerning Location Based Services that was previously included

• Volume 7 (Hardware) has been discontinued, and the hardware

Engineering Recommendation: Parameter Values

If a newer Template delivery becomes available, then the Template is

Engineering Recommendation: Feature Status

Engineering Recommendation: Modem Type in LR13.x

Restriction: Time Division Duplex (TDD) System

Support for the Time Division Duplex (TDD) implementation is provided in a

Restriction: eNodeB equipment types covered

All engineering information, algorithms description and parameters values

Inter-Release Delta: Transport Parameters

2.1 LPUG VOLUMES

2.2 REFERENCE DOCUMENTS

3 CONFIGURATION MANAGEMENT OVERVIEW

3.1 CONFIGURATION MANAGEMENT COMPONENTS

WPS Configuration Tool

Figure 1: eUTRAN Configuration Management Data Flows

The principal configuration management physical components are:

 IP Networks – Used to transport data among the OAM Configuration

3.2 ENB CONFIGURATION MODEL

From zero to three instances

Containing Another Another

1 Object from eslewhere in

Containing Node within the CM

Contained Leaf within the CM

3.3 RDNID AND CONFIGURATION ID PARAMETERS

 A configuration ID parameter assigns an instance of another object to the

Figure 3: Example Object Model for DedicatedConf Object

Each of the up to 32 instances of object TrafficRadioBearerConf has four ConfId

Parameter The Name of the parameter is provided here

Range & Unit The range and unit of the parameter.

Value The default or recommended value of the parameter

Feature Feature the parameter is directly associated with (if applicable)

• Class – Each parameter is assigned to a class according to the impact that

The eNB resets external resources to avoid triggering defense

 B--Modem+Cell(s): Reset of associated Modem + all its cells.

 B--Cell(s)-of-Modem: Disable and re-enable of all cells of the

The cell is then reinitialized with the modified Class B parameter

Restriction: Metro reset behavior

Table 1 : LTE Parameter Groups

In previous issues of LPUG a category field was provided in the parameter

Source Field Value Definition

LPUG Category Source Value

o Even though a “default” value may be provided by ALU, the parameters

• The system restrictions are presented as follows:

• The engineering recommendations for parameter value are presented as

VOLUME 2 MISCELLANEOUS FEATURES AND

CONTENTS AND PARAMETER GUIDE

2 RELATED DOCUMENTS AND PREREQUISITES ......................................................................... 20

3 FEATURE AND CAPACITY LICENSING ....................................................................................... 22

4 ENHANCED NODE B (ENB) HARDWARE .................................................................................... 34

4.4.1 AISG 2.0 support (TMA&RET) L156783 .......................................................................... 47

5 INSTALLATION AND COMMISSIONING PARAMETERS ............................................................ 88