TMO18315 - V7.0 SG ENLR13.3L Ed1

Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent
Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

TERMS OF USE AND LEGAL NOTICE
Alcatel-Lucent provides this training course to you subject to these Terms of Use and Legal Notice. Your use of this training
course and/or this site constitutes your acceptance of and agreement to these Terms of Use and Legal Notice. These
Terms of Use and Legal Notice, as well as the contents of this training course, may be updated or amended by Alcatel-
Lucent from time to time without prior notice to you. Your use of the Alcatel-Lucent training materials after such update
or amendment constitutes your acceptance of and agreement to said updated or amended Terms of Use and Legal Notice.
SAFETY WARNING
Alcatel-Lucent training materials can be for products or refer to products that have both lethal and dangerous voltages
present. Always observe all safety precautions and do not work on the equipment alone. The user is strongly advised not
to wear conductive jewelry while working on the products. Equipment referred to or used during this course may be
electrostatic sensitive. Please observe correct anti-static precautions.
PERMISSION TO USE CONTENT

The information, communications, scripts, photos, text, video, graphics, music, sounds, images and other materials
provided in this training course (collectively the "Content"), is intended for the lawful use of employees of Alcatel-Lucent
and other authorized participants in this Alcatel-Lucent training course. You are hereby granted a non-exclusive, non-
transferable permission to access and use the Content solely for your personal training and non-commercial use. This
permission may be terminated by Alcatel-Lucent at any time for any reason or no reason, with or without notice. You must
immediately cease use of the Content upon such termination.
COPYRIGHTS AND TRADEMARKS

The unauthorized copying, displaying or other use of any Content from this training course is a violation of the law and
Alcatel-Lucent’s corporate policies. The Content is protected in France, the U.S. and other countries by a variety of laws,
including but not limited to, copyright laws and treaty provisions, trademark laws, patent laws and other proprietary rights
laws (collectively, "IP Rights"). In addition to Alcatel-Lucent’s IP Rights in the Content, in part and in whole, Alcatel-Lucent,
and any of the third parties who have licensed and/or contributed to the Content, owns a copyright in the formatting and
presentation of the Content.
Alcatel-Lucent does not grant you any permission to use the Content other than the permission expressly stated in these
Terms of Use and Legal Notice. All other use of Content from this training course, including, but not limited to,
modification, publication, transmission, participation in the transfer or sale of, copying, reproduction, republishing,
creation of derivative works from, distribution, performance, display, incorporation into another training course or
presentation, or in any other way exploiting any of the Content, in whole or in part, for uses other than those expressly
permitted herein is strictly prohibited and shall not be made without Alcatel-Lucent’s prior written consent. All characters
appearing in this training course are fictitious. Any resemblance to real persons, living or dead, is purely coincidental.
There may be a number of proprietary logos, marks, trademarks, slogans and product designations found in the
Content. Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logos are trademarks of Alcatel-Lucent. All other
trademarks are the property of their respective owners. Alcatel-Lucent does not grant you a license to use any of the
foregoing logos, marks, trademarks, slogans and product designations in any fashion. Granting of the right to access and
use the Content for training purposes does not confer upon you any license under any of Alcatel-Lucent’s or any third
party's IP Rights.
DISCLAIMER
ALCATEL-LUCENT DISCLAIMS ALL WARRANTIES REGARDING THE TRAINING COURSES OR THE CONTENT, EXPRESS OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE. THE ALCATEL-LUCENT WILL NOT BE RESPONSIBLE OR LIABLE FOR ANY INJURY, LOSS, CLAIM, DAMAGE, OR ANY
SPECIAL, EXEMPLARY, PUNITIVE, INDIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES OF ANY KIND (INCLUDING WITHOUT
LIMITATION LOSS PROFITS OR LOSS SAVINGS), WHETHER BASED IN CONTRACT, TORT, STRICT LIABILITY OR OTHERWISE, THAT
ARISES OUT OF OR IS IN ANY WAY CONNECTED WITH (A) ANY USE OR MISUSE OF THE CONTENT OR THE TRAINING COURSES
BY YOU, OR (B) ANY FAILURE OR DELAY BY ALCATEL-LUCENT, ITS OFFICERS, DIRECTORS, AGENTS OR EMPLOYEES IN
CONNECTION WITH THE CONTENT OR THE TRAINING COURSES (INCLUDING, WITHOUT LIMITATION, THE USE OF OR INABILITY
TO USE ANY COMPONENT OF THE CONTENT OR TRAINING BY YOU). SOME JURISDICTIONS LIMIT OR PROHIBIT SUCH
EXCLUSION OF WARRANTIES OR LIMITATION OF LIABILITIES AND SO THE FOREGOING EXCLUSION OF WARRANTIES OR
LIMITATION OF LIABILITY MAY NOT APPLY TO YOU.
GOVERNING LAW
These Terms of Use and Legal Notice are governed by the laws of France. The operation and use of the training course is
governed by the laws of the country that governs your employment contract, if applicable. If any provision of these Terms
of Use and Legal Notice, or the application thereto to a person or circumstance, is held invalid or unenforceable by law,
statute or a court of competent jurisdiction, for any reason, then such provision shall be modified and/or superseded by a
provision that reflects the intent of the original provision as closely as possible. All other provisions of these Terms of Use
and Legal Notice shall remain in full force and effect. You may not assign these Terms of Use or any permission granted
hereunder without Alcatel-Lucent’s prior written consent. Nothing herein shall be deemed an employment agreement or
an offer of employment or an alteration in any way of a user’s terms of employment with or within Alcatel-Lucent.
Copyright © 2013 Alcatel-Lucent. All Rights Reserved

Welcome to 9400 LTE
LR13.3L Radio Algorithms And Parameters Description
1. 9400 LTE Radio Algorithms And Parameters Description

1. introduction
2. air_interface
3. RRM
4. session
5. mobility
6. son_services
7. specific_services

9400 LTE
LR13.3L Radio Algorithms And Parameters Description
Upon completion of this course, you should be able to:
Describe all the radio features until LR13.3 (FDD),

Link the associated 3GPP features,
Localize the technical context of each parameter,
Describe the role of each parameter,
Be able to measure the effect of a modification of the parameter value,
Be able to optimize a parameter
Your feedback is appreciated!

Please feel free to Email your comments to:
training.feedback@alcatel-lucent.com
Please include the following training reference in your email:

TMO18315_V7.0-SG Edition 1
Thank you!

TMO18315_V7.0-SG-English-LR13.3L-Ed1 Module 1.1 Edition 1
Section 1 · Module 1 · Page 1
This page is left blank intentionally
Document History
Edition Date Author Remarks
07 2013-12-11 Kine Jean-Philippe Update LR13.3


Page
1 LTE RAN LA6 to LR13.3L delta Features 7

1.1 Introduction 8
1.2 LR13.1L Drivers 9
1.3 LTE RAN LR13.1L Features 10
1.4 LR13.3L Drivers 15
1.5 LTE RAN LR13.3L Features 16
2 Configuration Management Overview 19
2.1 Configuration Management Component 20
2.2 eNB Configuration Model 21
2.3 Parameters Template 22
2.4 Parameter Properties 23
2.5 Licensing Purpose 25
2.6 Feature License Process 26
2.7 Example of SAM License Manager 27


The information in this document is preliminary, for planning purposes only, and subject to change. This
document reflects the current state of the release. Features may be added or removed from the release after
the publication of this document.

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 routers, switches and eNBs. 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 (Installation &
Commissioning) parameters. NEM can be used at the eNodeB location, and it can also update some
parameters remotely.
As indicated in the slide, 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.

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.

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.
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 Source field is intended to indicate the source of the parameter value that is to be used. It is introduced
in LR13.1L.
Even though a “default” value may be provided by ALU, the parameters are set by the customer.
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).

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 eNB resets external resources 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 mngt from SAM is lost during the reset period
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: 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 layers.
• B--X2-interface: Reset of associated SCTP & X2 interface.
• B--S1-interface: Reset of associated SCTP & S1 interface.
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.

Capacity Licensing was introduced as a method of reducing initial costs to customers.
Some eNodeB resources can be limited and monitored individually. In this way, the eNodeB capacity can be
measured and restricted under the terms of a licensing agreement. As network demands increase, the eNodeB
license capacity can be increased up to the maximum hardware capacities.
A license is generated for one specific SAM and contains the set of tokens that can be distributed to all the
eNodeBs supervised by the SAM.
The tokens represent the sum of the feature values that can be manually applied to the group of eNodeBs in a
RAN.
Capacity licensing allows the operator to reduce initial costs by tailoring its network capacities to meet its
current network requirements. As network demands increase, the license capacity can be increased up to the
maximum hardware capacities.
Feature licensing gives customers the rights to choose from a list of options,which features they require.
Customers limit their requirements to their needs.

Document History
01 YYYY-MM-DD Last name, first name First edition


Page
1 MIMO and Transmission Mode 7

1.1 Introduction 8
1.1.1 Layers, Rank and Codewords Mapping 9
1.2 Transmission Modes 11
1.2.1 Summary 12
1.2.2 transmissionMode 13
1.2.3 macMIMOModeDl 16
1.3 Precoding Function 17
1.4 TM3 – Modes 2-layers OL-MIMO / TxDiv 18
1.5 TM4 - Modes TxDiv/ CL-MIMO1lay/ CL-MIMO2lay 19
1.6 Mimo and Transmission Modes Summary 20
2 Uplink Control Information 22
2.1 Main Concepts 23
2.1.1 Channel Quality Indicator 24
2.1.2 Wideband and Subband CQI 25
2.1.3 Structure of the Subbands 26
2.1.4 Periodic and Aperiodic UCI Reporting 27
2.1.5 PUCCH Formats 29
2.2 Aperiodic CQI Reporting Modes on PUSCH 30
2.2.1 Reporting Modes on PUSCH 31
2.2.2 CQI/PMI/RI Reporting Mechanism 33
2.3 Periodic CQI - Reporting Modes on PUCCH 34
2.3.1 Reporting Modes on PUCCH 35
2.3.2 Periodic CQI Erasure and Drop Handling 37
2.4 CQI to SINR Conversion 38
3 Physical Channels Configuration 40
3.1 REG and CCE Definition 41
3.2 Downlink Physical Signals 42
3.2.1 Cell-Specific Reference Signal (antenna ports 0-3) 43
3.2.2 Synchronization Signals (FDD) 44
3.3 Physical Broadcast Channel (PBCH) 45
3.4 Downlink Control Channels 46
3.4.1 PCFICH 47
3.4.1.1 Static and Dynamic CFI 48
3.4.1.2 Dynamic CFI Based on UE Contexts 49
3.4.2 PDCCH 51
3.4.2.1 DCI formats 53
3.4.2.2 TM and DCI Formats Mapping 54
3.4.2.3 CCE Mapping for PDCCH 55
3.4.2.4 PDCCH Search Spaces 56
3.4.2.5 Common Search Space 57
3.4.2.6 UE-specific Search Spaces 58
3.4.2.7 ALU Parameters for PDCCH 59
3.4.3 PHICH 62
3.4.3.1 ALU Parameters for PHICH 63
3.5 The Physical Downlink Shared Channel (PDSCH) 65
3.6 Physical Multicast Channel (PMCH) 66
3.7 Uplink Physical Signals 67
3.7.1 Uplink Demodulation Reference Signal (DRS) 68
3.7.2 Sounding Reference Signal (SRS) 69
3.7.2.1 ALU Parameters for SRS 70
3.8 Physical Uplink Control Channel (PUCCH) 73
3.8.2 Scheduling Request (SR) over PUCCH 74
3.9 Random Access Channel (RACH) 77
3.9.1 RACH Format 2 78

Page
3.9.2 RACH Format 3 79

3.9.3 PRACH Preamble 80
3.9.4 Support of Fiber Delay 82
4 Timing Advance Control and Synchro Monitoring 85
4.1 Role of the Timing Advance 86
4.2 Timing Advance Update 87
4.3 Parameters for Timing Advance 88
4.4 Uplink Synchronization Monitoring 89
4.5 Downlink Synchronization Monitoring 90
5 DRX Management 92
5.1 Basic DRX 93
5.2 Inactivity Based DRX 94
5.2.1 State Machine 95
5.2.2 Parameters 96
5.3 DRX Activation / Deactivation 97

An antenna port may in practice be implemented either as a single physical transmit antenna, or as a combination of
multiple physical antenna elements. The transmitted RS corresponding to a given antenna port defines the antenna
port from the point of view of the UE, and enables the UE to derive a channel estimate for that antenna port –
regardless of whether it represents a single radio channel from one physical antenna or a composite channel from a
multiplicity of physical antenna elements together comprising the antenna port. (ex: in BF, 8 antennas are seen by the
UE as a single antenna port). When a resource element is used to transmit an RS on one antenna port, the
corresponding resource element on the other antenna ports is set to zero to limit the interference.
A spatial layer is the term used in LTE for the different streams generated by spatial multiplexing. A layer can be
described as a mapping of symbols onto the transmit antenna ports. Each layer is identified by a (precoding)
vector of size equal to the number of transmit antenna ports and can be associated with a radiation pattern.
The rank of the transmission (reported by the UE) is the number of layers transmitted. Some UE may not support
2 independent data streams and report rank=1 even in good radio conditions.
A codeword is an independently encoded data block, corresponding to a single Transport Block (TB) delivered
from the Medium Access Control (MAC) layer in the transmitter to the physical layer, and protected with a CRC.
For ranks greater than 1, two codewords can be transmitted. Note that the number of codewords is always less than or
equal to the number of layers, which in turn is always less than or equal to the number of antenna ports.
In principle, a SU-MIMO spatial multiplexing scheme can either use a single codeword mapped to all the available
layers, or multiple codewords each mapped to one or more different layers.
The main benefit of using only one codeword is a reduction in the amount of control signalling required, both for CQI
reporting, where only a single value would be needed for all layers, and for HARQ ACK/NACK feedback, where only one
ACK/NACK would have to be signalled per subframe per UE. In such a case, the MLD receiver is optimal in terms of
minimizing the bit error rate.
At the opposite extreme, a separate codeword could be mapped to each of the layers. The advantage of this type of
scheme is that significant gains are possible by using Successive Interference Cancellation (SIC), albeit at the expense
of more signalling being required.
The codeword-to- layer mapping is static, since only minimal gains were shown for a dynamic mapping method. Note
that in LTE all RBs belonging to the same codeword use the same MCS, even if a codeword is mapped to multiple
layers.

In TxDiv, there is one RS signal per antenna port, i.e. per physical antenna: RS0 and RS1. The same
information is sent on the two antennas with different coding and different frequency resources (SFBC).
This improves the SINR and makes transmission more robust.
CL-MIMO 1 layer is used in spatial multiplexing when rank = 1 in good radio conditions. It differs from
TxDiv because the eNodeB receives from the UE the PMI matrix intended to orthogonalize the 2 radio
signals and thus avoiding interference between them. The consequence is a better throughput in CL-MIMO
1 layer than in TxDiv.
CL-MIMO 2 layers is used in spatial multiplexing when rank=2 with good radio conditions. The case of a
single codeword mapped to two layers is only applicable when the number of antenna ports is 4 (not
supported in LA6.0).
In (T)LA6.0, only 2 layers at maximum can be used. In spatial multiplexing, 1 codeword is used for 1 layer
and 2 codewords for 2 layers. For transmit diversity, there is only one codeword and 2 layers.

SFBC stands for Space Frequency Bloc Code, this is a technique to space the frequency sent at the same
time on both antennas: antenna1 transmits symb1-symb2-… and antenna2 transmits symb2-symb1...
Additional comments on transmission modes:
TM3: OL spatial multiplexing: A predefined precoder matrix located in the eNodeB is used based on RI
feedback. This mode saves overhead in UL.
TM4: CL spatial multiplexing: A Precoding Matrix Indicator (PMI) is sent by the UE. This mode allows
better DL performance but induce UL overhead.

Example of reading of the table with OL-MIMO:
Rank=2 is required for OL-MIMO. You have then 2 layers and 2 codewords.
If rank=1, then TxDiv is applied (1 codeword and 2 layers)
Remark: If you had rank=1 with OL-MIMO, you would have no extra gain compared to TxDiv.
There is one SINR per transmission scheme (for instance, in TM3, there are two SINR, one for TxDiv mode
and one for OL-MIMO)

VoIP (QCI 1) is always sent in TxDiv, because the rate is constant and priority is set to the robustness
QCI is the QoS Class Identifier (values 1 to 9)
SRB1 is for RRC messages and NAS messages prior to the establishment of SRB2, all using the DCCH
logical channel
SRB2 is for NAS messages, using DCCH logical channels. SRB2 has a lower priority than SRB1 and is always
configured by the e-UTRAN after security activation.
The signaling radio bearers are transmitted in TxDiv mode (MIMO not used)
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).

Multiple-antenna configuration consists in M transmit antennas and N receive antennas. The number of
parallel signals that can be spatially multiplexed is upper limited by NL = min (M , N) (no more than M
different signals can be transmitted and no more than N spatially multiplexed signals can be separated). NL
is the number of layers available.
Precoding in case of spatial multiplexing implies that linear processing by means of a size MxN precoding
matrix is applied at the transmitter side where NL signals are spatially multiplexed and transmitted using M
transmit antennas.
The precoding is used to ‘orthogonalize’ (isolate) the parallel transmissions (channels), and the precoding
matrix V is determined based on the size M x N channel matrix H . In practice, the channel matrix cannot
be perfectly estimated because 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 (NL).
It is clear that to determine the matrices V, 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. In the case of closed-loop spatial multiplexing, a UE feeds back to the eNodeB the most
desirable entry from a predefined codebook. The preferred precoder is the matrix which would maximize
the capacity based on the receiver capabilities. In a single-cell, interference-free environment the UE will
typically indicate the precoder that would result in a transmission with an effective SNR following most
closely the largest singular values of its estimated channel matrix. The receiver then reports this
information to the transmitter (PMI). This procedure is used in LTE.

In this mode TM3, if macMIMOModeDl is not set to “MimoTwoLayersNotAllowed”, the transmission scheme
used is either 2-layer OL-MIMO or TxDiv.
The UE reports the CQI for its radio conditions and the Rank Indicator (RI) to indicate if it is able to
distinguish the transmission scheme of each antenna (rank=1 : TxDiv; rank=2 : OL-MIMO or TxDiv
depending on the SINR value). The eNodeB can derive the estimated SINR from the CQI thanks to a table.
In OL-MIMO, the eNodeB can transmit 2 different transport blocks on each antenna using the same time-
frequency resources. The DCI2A on PDCCH provides the transmission scheme to the UE. The pre-coding
matrix is pre-defined in Open-Loop MIMO. This is the way the data are mapped on each antenna.
The speed is an important factor in MIMO because the eNodeB must be able to react quickly enough to
take into account the UE reports (CQI and RI) in the next transmission before the UE radio conditions have
changed. The parameter thSpeedMimo is not supported in (T)LA6.0
The dlSinrThresholdBetweenOLMimoAndTxDiv 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 recommended default value is 15.0 dB

The CL-MIMO1lay/ TxDiv selection is carried out based on the reported rank (if rank=1 : TxDiv) and the
CQI (if rank=2 and SINR -derived from CQI- below the threshold : TxDiv). BLER is also taken into account.
ThspeedMimo is not supported in (T)LA6.0
CL-MIMO 2layers transmission scheme improves the DL performances when the SINR is high in average
and the speed low in the cell.
Parameter dlSinrThresholdBetweenCLMimoOneLayersAndTxDiv is a key RF optimization parameter. Higher
values will reduce downlink CL-MIMO1lay data rate 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 downlink data
rate/throughput. Default=-10dB
Parameter dlSinrThresholdBetweenCLMimoTwoLayersAndOneLayer is a key RF optimization parameter.
Higher values will reduce downlink CL-MIMO2lay data rate too soon, resulting in HARQ retransmission rates
and BLERs higher than achievable with CL-MIMO1lay and hence the use of an MCS with a lower downlink
data rate/throughput. Default=12.0dB
Transition CL-MIMO2lay > CL-MIMO1lay: When the eNB receives from the UE RI=2, it may use 1 layer or 2
layers for the next transmission. In our case, the UE worked in CL-MIMO2lay but the SINR dropped and
crossed the threshold between CL-MIMO2lay and CL-MIMO1lay. The nb of retransmissions in CL-MIMO2lay
with such SINR is likely to be too high and the final throughput drops. In this case, it is much more efficient
to move to CL-MIMO1lay transmission mode because this mode is much more robust (the same data are
transmitted twice on both antennas and are othogonalized and precoded).

The UCI (Mac level) assists the physical layer in uplink by providing:
the DL Channel Quality Indicator (CQI) which indicates the highest modulation and coding rate that
can be supported in the DL with 10% BLER (block error rate) on the first H-ARQ process
H-ARQ acknowledgement of the UL frames
Scheduling Request (SR) to request radio resources for the UL transmission
Precoding Matrix Indicator (PMI) and Rank Indicator (RI). RI is the maximum number of layers that
can be used for spatial multiplexing in DL and PMI indicates the preferred precoding matrix
PUCCH: Physical Uplink Control Channel
PUSCH: Physical Uplink Shared Channel

SINR: Signal to Interference plus Noise Ratio
CQI values from 0 to 15 (4 bits integer) with value 15 reflecting the better radio conditions and value 0 the
worst conditions.
In the CQI Table above:
Efficiency=Qm x code rate, with Qm being the number of bits in the modulation constellation
Example for CQI=4 and modulation QPSK (thus, 2 bits in the modulation constellation):
Efficiency= 2x308/1024
The CQI is computed by the UE based on :
The Received DL RS signal level
The total received DL signal + interference + Noise level (RSSI)
The difference between the DL RS transmitted power and the PDSCH transmitted power (in SIB2)

The value ‘m’ in case of UE selected subbands is provided by the higher layers but is also contingent on the
system bandwidth.
On the graph you can see that the average sector throughput is roughly the same for vehicle 30km/h
whatever the CQI Feedback mode. It is better in this case to choose for these mobiles the Wideband CQI
which is less uplink bandwidth consuming.
FDS (Frequency Diverse Scheduling) is based on Wideband CQI. The PRB allocation in the frequency
domain is random.
FSS (Frequency Selective Scheduling) is based on Subband CQI. The PRB allocation in frequency allocation
is based on the subband CQI. FSS is much more efficient for low speed UE and for BE radio bearers.
Design Issue: The critical aspect for designing the CQI feedback mode is the trade-off between the
downlink system performance and the uplink bandwidth consumption (scare resource). Wideband CQI
optimizes the uplink bandwidth but does not allow FSS (which maximizes DL performance).
Wideband CQI is preferred for high speed UEs (channel changes rapidly and too many aperiodic CQI
reports would be required) or for VoIP (latency is more critical than the overall throughput)

In case of Periodic reporting when Subband CQI is requested, the UE cycles through the different subbands
at each reporting with only one subband per report. This optimizes the UL bandwidth but it takes a while
for the eNodeB to have the whole picture to effectively utilize the CQI information in the FSS scheduler. In
contrast, with aperiodic reporting, the UE can forward the CQI across all the subbands in one single report.
FDS and FSS can be used for any Transmission Mode.
ALU implementation in (T)LA6.0 is to use aperiodic reporting for subbands CQI report.
The PUCCH is never transmitted simultaneously with the PUSCH from the same UE in order to retain the
single carrier property of SC-FDMA. They are time multiplexed. If there is a radio link established with the
UE, the periodic reporting is then done on PUSCH (and not on PUCCH). For TDD, the PUCCH is never
transmitted in the UpPTS field (contains the UL sounding reference signal and the random access). The
PUCCH is transmitted at the bandwidth edge, in order to provide the contiguous bandwidth in the middle
for data (as only localized resource allocation is allowed in UL, that means contiguous PRBs allocation per
UE)
There are 4ms between the PDCCH grant and the PUSCH transmission.

The SR is carried by the presence/absence of transmission of PUCCH from the UE, so there are no extra
bits.
Formats 1a and 1b and formats 2a and 2b carry the same type of enformation, but are encoded differently,
which allows individual adjustments of transmission energy using different coding rates.
encoding HARQ-ACK and SR: ACK is encoded as a binary ‘1’ and NACK as ‘0’. There is one HARQ-ACK
bit per single-codeword.
CQI/PMI are encoded using a (20, Ncqi) code with codewords being a linear combination of 13 basis
sequences and Ncqi is the number of CQI and PMI bits.

Mode 3-0 does not report PMI and is used for OL-MIMO and single antenna port transmission.
Mode 3-1 reports a single PMI (i.e. only the wideband PMI) for CL MIMO
Wideband CQI (only) and UE selected subband CQI are not supported in LA04.0 for aperiodic CQI
reporting. Multiple PMI means one PMI report per subband.
The UCI (CQI/PMI/H-ARQ-ACK and SR) can be multiplexed with UL-SCH data on the PUSCH channel and
there is no need to send a SR (scheduling request) since the UE BSR (buffer status report) is included. In
this case, the channel coding for H-ARQ-Ack, RI, CQI/PMI is done independently. Different coding rates can
be achieved by allocating different numbers of coded symbols, depending on the amount of allocated radio
resource. After encoding, the CQI encoded sequence is multiplexed with UL-SCH data, the output of which
is interleaved with the RI and H-ARQ-ACK encoded sequence.

‘Single’ PMI means PMI computed by UE assuming transmission over the whole bandwidth (wideband)

Example: in TM3, the CQI reporting mode in LA6.0 will be Mode 3-0 and the wideband CQI for codeword0
will be reported 4 sf later than the received DCI format0 on PDCCH (providing higher layers do not
configure subband CQI). No PMI is reported.

In LA6.0, each connected user can be configured with periodic CQI/PMI reports over PUCCH. The same
user can also be requested to report aperiodic CQI/PMI measurements over PUSCH.
Mode 1-0 does not report PMI and is used for OL MIMO and single antenna port transmission.
Mode 1-1 reports a single PMI (i.e. only the wideband PMI) for CL MIMO
UE Selected subband CQI is not supported in LA6.0
The wideband CQI report for modes 1-0 is a single 4 bits sequence. For the mode 1-1, the feedback is 4
bits (for single codeword spatial multiplexing) or 7 bits (for two codewords spatial multiplexing) plus a
single PMI (calculated on all subbands). The PMI is a codebook index (0,1,2,3) for two antennas.
There are different PUCCH formats (1, 1a, 1b, 2, 2a, 2b) from 1 to 22 bits depending on what info is
included (CQI, PMI, RI and H-ARQ-ACK).
The PUCCH is transmitted at the bandwidth edges.

LR13.1 feature L101843: MAC DRx State Mgt under Inactivity Conditions
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.
Example of CQI/PMI/RI report erasure: If the report falls into the DRX OFF period, it shall be regarded as an
erasure.
This mechanism is activated/deactivated using bit 13 of LteCell::spare4. It uses the following two parameters:
- 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.
- dlSINRDecayUponPCQIErasure: The value represents the assumed DL SINR reduction if no valid PCQI/PMI is
received in a whole second.

SINR is used in the link adaptation algorithm further described. A mean SINR is created in order to deduce
the target MCS (of the data that will be transmitted on PDSCH) that will be forwarded to the UE in PDCCH
(DCI). Please refer to the Link Adaptation chapter.
Table cQIToSINRLookUpTable does not provide PDCCH SINR targets but PDSCH SINR equivalents to the
reported CQI. PDCCH SINR targets are configured by dlTargetSINRTableForPDCCH.

REG = Resource Element Group
CCE = Control Channel Element
Four QPSK symbols (of 2 bits) are mapped to each REG (8bits)

No physical channels are associated with the DL physical signals.
UE specific Reference Signal is for Beamforming (not in LA6.0)

Only antenna ports 0&1 are used in (T)LA6.0 (ports 2&3 are used for 4 antennas MIMO).
The Reference Signal consist of known reference symbols (from the eNodeB and from the UE) that are
intended for DL channel estimation at the UE needed to perform coherent demodulation.
To simplify, if you consider r= H[]*t + n, with r is the received signal, t the transmitted signal, n the noise,
then the matrix H is built by the UE from the RS signals.
Cell-specific Reference Signals are transmitted in all DL subframes in a cell supporting non-MBSFN
transmission. In the subframe used for transmission with MBSFN, only the two first OFDM symbols can be
used for cell-specific RS. There is one separate cell-specific RS per antenna.
The RS from different antennas are orthogonal to each other (frequency domain).
There is a frequency shift determined by the slot number and the cell identity. So, cell-specific RS from
different cells of the same eNodeB will have different frequency shifts (since the PCI are chosen to be
different Modulo 3 between the 3 cells of same eNodeB having 2 antenna ports), which allow the UE to
detect the neighboring eNodeB and estimate the associated channel.
The cell-specific RS configuration for 2 antenna ports is used for transmission mode 2/3/4/7 in (T)LA6.0 (16
RS per PRB). TM7 is supported only in TLA6.0. Each subframe contains a maximum payload of 152 RE
(7x2x12-16).
RS configuration for 1 antenna port is used for transmission mode 1 and transmission mode 7 in (T)LA6.0.
Each subframe contains a maximum payload of 160 RE.
Antenna ports 0-3 are used for Cell-Specific RS (4 is used for MBSFN and 5 for BF)
There are only 24 (and not 2x16=32) RS per PRB with 4 antennas because antenna ports 0 and 1 have
twice as many RS as antenna ports 2 and 3 (standard), in order to reduce the RS overhead.
There is a cell-specific cyclic shifting with physical-layer cell-identity groups (modulo 6)

The DL synchronization signals are sent to facilitate the cell search procedure, during which process the
time and frequency synchronization between the UE and the eNodeB is achieved and the physical cell ID
(PCI) is obtained. There are 168 physical-cell-ID groups and 3 physical-cell-ID index within a group (total of
504=3*168 physical Cell-ID with PCI=3*physical-cell-ID-group + physical-cell-ID-index). There is a primary
and a secondary synchronization signals.
the primary SS identify the symbol timing and the physical-cell-ID index={0,1 or 2}
the secondary SS identify the frame timing and the physical-cell-ID-group={0 to 167}
The sequence used for the primary SS is generated from a frequency domain Zadoff-Chu sequence having
low PAPR (peak-to-average power ratio) to improve coverage. There are three different root sequences
corresponding to cell-ID index=0,1,2 making the primary SS for different cell-ID orthogonal to each other
(for eNodeB with 3 sectors);
The secondary SS is an interleaved concatenation of two length 31 binary sequences. It can be detected
only after the primary SS because the sequences are scrambled with the key cell-ID-index.
Both primary and secondary SS are transmitted on the 72 subbcarriers centered around the DC subcarrier
with 5 subcarriers reserved on either side.
In the time domain, PSS and SSS are transmitted twice per radio frame 10ms (slots0-1 and slots 11-12
among 20 slots)
Recall on frame structure type 2 (TDD only):
DwPTS and Location of PSS and SSS:
P-SCH is always transmitted in the 3rd OFDM symbol of DwPTS (subframes 1 and 6)
PDCCH in DwPTS (subframes 1 and 6) may span 1 or 2 OFDM symbols
Data is transmitted after the control region as in other DL subframes
Same cell specific RS patterns as in other DL subframes, RS in GP are muted
UpPTS: - SRS transmission on UpPTSAgreement on 1 SRS symbol in UpPTS

Broadcast channels carry system information such as DL system bandwidth, antenna configuration,
reference signal power… The UE can get the information after the cell search (or synchronization)
procedure. Due to the large size of information field, it is divided into two parts: Master Information Block
(MIB) transmitted on PBCH and System Information Blocks (SIB) transmitted on PDSCH. MIB contains basic
system parameters (MIB length=14 bits) necessary to enter the cell and to demodulate the PDSCH (with
SIB).
For PBCH: modulation QPSK, CRC added to MIB, strong error protection with tail-biting convolutional coding
(rate 1/3), no quality feedback, no HARQ support, single antenna transmission with TxDiv (using SFBC-
space frequency block code- to ensure coverage over the whole cell).
PBCH is transparent from a DL scheduler perspective as there is no MAC header and this is not granted
over PDCCH but permanently assigned, also the content of the PBCH is built at RRC level
Frequency domain: mapped around the 72 subcarriers centered around the DC subcarrier for all system
bandwidth (1.4, 5, …, 20MHz)
Time domain: 4 OFDM symbols in slot 1 in subframe0 during four consecutive radio frames (the TTI for
PBCH is 4*10=40ms, the same MIB is repeated 4 times in order to have time diversity and secure the
signal for the UE). If the SINR is good enough, the UE can decode the MIB in the first subframe and does
not listen to the 3 forthcoming MIB (save UE battery)
The UE can detect the PBCH without any prior knowledge of the system bandwidth and the duplex mode
(PBCH bandwidth=72 subcarriers of 15kHz=1,04MHz < 1,4MHz).

LTE needs DL control channels to provide the time/frequency resources to the UE in UL, to indicate which
DL resources are used on PDSCH and how to decode them (modulation and coding rate), to ensure UL
retransmissions and to control the power in UL.
The control information are managed in the MAC layer and they include the downlink control information
(DCI), the Control Format Indicator (CFI) and the H-ARQ Indicator (HI). There is a specific physical channel
for each type of control information.
The PDCCH and the PDSCH are time multiplexed such that the PDCCH is carried over the first few OFDM
symbols of each subframe and the PDSCH over the rest of the OFDM symbols.
The number of OFDM symbols allocated for PDCCH can vary from 1 to 4 and is conveyed by the CFI (which
is carried by the PCFICH in a predetermined format over the first OFDM symbol of each subframe).
The HI is for H-ARQ acknowledgement in response of UL transmission.
Design requirements for the control channels:
It must be possible to transmit multiple control channels to several UE within the duration of one
subframe.
Common (for the transmission of the SIB on SDCCH) and dedicated (one UE) control channels should
be possible.
If data arrives in a regular basis, f.i. for VoIP, it is possible to predict in advance when resources will
have to be allocated in DL or granted in UL. It must be possible to reduce in this case the control
channels overhead with ‘semi-permanent scheduling’ mechanisms.

The CFI is cell-specific and indicates how many OFDM symbols the DCI spans in the subframe (dynamically
calculated). Indeed, the load on PDCCH varies depending on the number of resource blocks and the
signaling format conveyed on PDCCH. The CFI is mapped on PCFICH carried by the first OFDM symbol of
the subframe. The PCFICH is transmitted only when data have to be transmitted on PDCCH . Such a
location allows (first OFDM symbol decoded first) the UE to sleep if there is no assignment, in order to save
battery.
In order to make the CFI robust, there are three 32 bits codewords for CFI (for values 1,2,3). These 32 bits
are mapped to 16 resource elements using QPSK modulation (2bits per symbol, thus 16RE for 32bits). In
order to achieve frequency diversity, the 16 resource elements carrying the PCFICH are distributed across
the frequency domain. This is done according to a predefined pattern in the first OFDM symbol in each
downlink subframe, so that the UEs can always locate the PCFICH information, which is a prerequisite to
being able to decode the rest of the control signaling PDCCH.
To minimize the possibility of confusion with PCFICH information from a neighbouring cell, a cell-specific
frequency offset is applied to the positions of the PCFICH resource elements; this offset depends on the
Physical Cell ID, which is deduced from the primary and secondary synchronization signals.
In addition, a cell specific scrambling sequence (again a function of the Physical Cell ID) is applied to the
CFI codewords, so that the UE can preferentially receive the PCFICH from the desired cell.

Feature L84872
With static CFI, the cFI parameter is set at the relevant value to accommodate the largest expected PDCCH
load.
The dynamic CFI allows to adapt the DCI length according to some metrics and thus to optimize the DL
payload for PDSCH.
Parameter cFI (case static CFI) is a key RF optimization parameter. Higher values allow for more PDCCH
robustness and/or more users served (increased capacity), but at the expense of throughput (fewer
resources for PDSCH).

A PDCCH carries a message known as Downlink Control Information (DCI), which includes resource
assignments and other control information for a UE or group of UEs. In general, several PDCCHs can be
transmitted in a subframe.
In order to provide robustness against transmission errors, the PDCCH information bits are coded
(convolutional), rate matching applied and then scrambled with a cell-specific scrambling sequence; this
reduces the possibility of confusion with PDCCH transmissions from neighbouring cells. The scrambled bits
are mapped to blocks of four QPSK symbols (REGs). Interleaving is applied to these symbol blocks, to
provide frequency diversity, followed by mapping to the available physical resource elements on the set of
OFDM symbols indicated by the PCFICH. This mapping process excludes the resource elements reserved for
reference signals and the other control channels (PCFICH and PHICH). The PDCCHs are transmitted on the
same set of antenna ports as the PBCH, and transmit diversity is applied if more than one antenna port is
used.
During the coding phase of the PDCCH, a 16-bit CRC is added. Furthermore, in order the UE can identify
which PDCCH(s) are intended for it, the ‘UE identity’ is scrambled in the CRC (C-RNTI)
The number of OFDM symbols allocated to PDCCH can vary from 1 to 3 and is conveyed by the CFI (on
PCFICH physical channel always over the first OFDM symbol of each subframe).
For subframes containing MBSFN transmission, there may be 0, 1 or 2 symbols for the control signaling
(MBSFN does not contain any control channel)

MCS= Modulation and Coding Scheme
TPC= Transmit Power Control
PMI= Precoding Matrix Indicator
In general the number of bits required for resource assignment depends on the system bandwidth, and
therefore the message sizes also vary with the system bandwidth. LTE is intended to support system
bandwidth from 6 resource blocks (1.4MHz) to 100 resource blocks (20MHz).

A UE always monitor the PDCCH for possible allocations. For dynamically scheduled data traffic, the UE is
configured by higher layers to decode the PDCCH with CRC scrambled by the C-RTNI. The UE shall decode
the PDCCH and any corresponding PDSCH according to the combinations in the table above.
For example, if the UE configured in TM3 or TM4 receives a DCI format1A assignment, it shall assume that
the PDSCH transmission is associated with transport block1 and that transport block2 is disabled, and
transmit diversity is applied.
DCI format and transmission mode:

In TM1, only SIMO is supported (1 codeword), DCI1 is used
In TM2, only TxDiv is supported (1 codeword), DCI1 is used
In TM3, 1 or 2 codewords are possible in OL-MIMO and switch to TxDiv possible, DCI2A is used
In TM4, 1 or 2 codewords are possible in CL-MIMO and switch to TxDiv or CL-MIMO 1 layer possible,
DCI2 is used
In TM7, BF is supported (1 codeword), and switch to TxDiv possible, DCI1 is used for BF and DCI1A
for TxDiv.
In TM8, dual layer BF (2 codewords) and switch to TxDiv and single layer BF, DCI1 is used for BF and
DCI1A for TxDiv and DCI2 for dual layer BF

Rationale for using CCE:
The most simplest approach to allocate PRB resources to a mobile is to send to each UE a bitmap in which
each bit indicates a particular PRB. This would work well for small system bandwidths, but for large system
bandwidths (i.e. up to 110 PRBs) the bitmap would need 110 bits, which would be a prohibitive overhead –
particularly for transmission of small packets, where the PDCCH message could be larger than the data
packet! The solution in LTE is to group the PRB in CCE (which is a set of PRB) and to use different resource
allocations types (0,1, or 2) and to refer to a set of CCE.
To understand the table: in QPSK (2 bits per symbol), we need 4 REs for 8 bits and therefore 9 REGs for
72bits (with CRC included), etc.
CCEs are numbered and used consecutively, and, to simplify the decoding process, a PDCCH with a format
consisting of n CCEs may only start with a CCE with a number equal to a multiple of n.
The number of CCEs used for transmission of a particular PDCCH is determined by the eNodeB according to
the channel conditions. For example, if the PDCCH is intended for a UE with a good downlink channel (e.g.
close to the eNodeB), then one CCE is likely to be sufficient. However, for a UE with a poor channel (e.g.
near the cell border) then eight CCEs may be required in order to achieve sufficient robustness. In addition,
the power level of a PDCCH may be adjusted to match the channel conditions. In LA6.0, the aggregation
level (AL) is fixed per system bandwidth.

If we place the PDCCH anywhere in the PDCCH resources (or CCEs), the UE would need to check all
possible PDCCH locations, PDCCH formats and DCI formats, and act on those messages with correct CRCs
(taking into account that the CRC is scrambled with a UE identity). Carrying out such a ‘blind decoding’ of
all the possible combinations would require the UE to make many PDCCH decoding attempts in every
subframe. This is reasonable for small bandwidths but not for large bandwidths (for example, blind
decoding of 100 possible CCE locations for PDCCH Format 0 would be equivalent to continuously receiving a
data rate of around 4 Mbps).
The approach adopted for LTE is to define for each UE a limited set of CCE locations where a PDCCH may
be placed (which is called a “search space”).
The search spaces are divided into:
The common search space: to be decoded by all UE in the cell in idle or RRC connected state. It is
subdivided into:
The non-C-RNTI common search space: for Paging, D-BCH (SIB), Mess4
The C-RNTI common search space used for Timing advance cmd, SRB1, VoIP
For SIB, the identity indicated on the PDCCH is not the UE identity but is the System Information Radio
Network Temporary Identifier (SI-RNTI).
UE-specific search spaces: to be decoded by the UE once RRC connected. The UE derives its own UE
search space based on the C-RNTI assigned during the RACH procedure (DCI CRC scrambled with UE
Identity). Several blind decoding are possible.
Note that for VoIP, in order to minimize overhead, certain frequency resources may be persistently-
scheduled, i.e. certain resource blocks in the frequency domain are allocated on a periodic basis to a
specific UE by RRC signaling rather than by dynamic PDCCH signaling. VoIP is always used with DCI1A to
improve cell coverage at cell edge. Common search space is used for VoIP.

In order to select the protection offered on the different DCI format, 3 parameters are used to select the
robustness of PDCCH:
pdcchAggregationLevelForUESearchSpace controlling the number of CCE for all DCI formats in the UE
search space. For (T)LA6.0, the Aggregation Level (AL) is reduced (fixed value among:1,2,4,8) or adaptive
(dynamic). When AL is adaptive (only supported in TLA6.0), its value depends on the CQI-Report: the
higher the UE SINR the less CCEs are needed (less parity bits). On the other hand no power boosting is
needed to reach cell edge users as the higher AL serves this with more efficiency (more parity bits). In
addition, in 'Full adaptive' mode, AL = 8 also supported for UL grants in the common search space. Note
that Adaptive AL has no meaning for common search space since several UE with different CQI coexist.
pdcchAggregationLevelForCRNTIGrantsInCommonSearchSpace; controlling the number of CCE for
DCI0/DCI1A formats sent over Common Search Space for a given UE:
only value 4 is supported in the UL direction (i.e. parameter is ignored & never rejected).
both values 4 and 8 are supported in the DL direction
pdcchAggregationLevelForNonCRNTIGrantsInCommonSearchSpace; controlling the number of CCE for
DCI1A formats sent over Common Search Space for DL Control channels (Msg4, Paging & D-BCH) – Note
that Msg2 never uses AL-8 and this parameter is ignored by UL Scheduler:
only value 4 is supported for Msg2 (i.e. parameter is ignored & never rejected)
both values 4 & 8 are supported in the DL direction
Question: can the aggregation level of a PDCCH change according to the radio conditions or is it fixed ?
Answer: Actually, it can be fixed but it can also depend on the radio conditions. There is no 3GPP
constraint for the AL to be fixed.
For example, RACH2 grant uses AL4, and SRB1, TA/DRX commands, SPS grants are derived from the
settings of these parameters and also from RF conditions (using parameter
sINRThresholdBetweenAL4andAL8)

The control information HI is used for H-ARQ acknowledgement in response to UL transmission. As spatial
multiplexing is not supported in UL, only one information bit is required (HI=0 (ack) or 1 (nack)). Coding
rate of 1/3 is applied. BPSK modulation.
The HI information is repeated in each of three BPSK (Binary Phase Shift Keying) symbols. Multiple PHICHs
are mapped to the same set of resource elements. These constitute a PHICH group, where different
PHICHs within the same PHICH group are separated through different complex orthogonal Walsh
sequences. The sequence length is four for the normal cyclic prefix (or two in the case of the extended
cyclic prefix). As the sequences are complex, the number of PHICHs in a group (i.e. the number of UEs
receiving their acknowledgements on the same set of downlink resource elements) can be up to twice the
sequence length. A cell-specific scrambling sequence is applied. Factor-3 repetition coding is applied for
robustness, resulting in three instances of the orthogonal Walsh code being transmitted for each ACK or
NACK. The error rate on the PHICH is intended to be of the order of 10−2 for ACKs and as low as 10−4 for
NACKs. (HARQ indicator: 1bit > coding rate 1/3 : 3 bits > Walsh sequence: 12 bits: needs 12RE in BPSK)
HI is mapped onto the PHICH channel. Multiple PHICHs mapped to the same set of Resource Elements
constitute a PHICH group, where PHICHs of the same group are separated through orthogonal sequences
with a spreading factor of 4. A PHICH is identified by (Ngroup, Nseq) where Ngroup is the PHICH group
number and Nseq the orthogonal sequence index in the group.
In order to indicate which PHICH carries the ACK/NACK response for each PUSCH transmission, the PHICH
index is implicitly associated with the index of the lowest uplink resource block used for the corresponding
PUSCH transmission. This relationship is such that adjacent PUSCH resource blocks are associated with
PHICHs in different PHICH groups, to enable some degree of load balancing.
The PHICHs are transmitted on the same set of antenna ports as the PBCH, and transmit diversity is
applied if more than one antenna port is used.

The Physical Downlink Shared Channel (PDSCH) is the main data-bearing downlink channel in LTE. It is
used for all user data, as well as for broadcast system information (SIB) which is not carried on the PBCH,
and for paging messages – there is no specific physical layer paging channel in the LTE system.
Except for TM7, the phase reference for demodulating the PDSCH is given by the cell-specific RS, and the
number of eNodeB antenna ports used for transmission of the PDSCH is the same as the number of
antenna ports used in the cell for the PBCH. In TM7, UE specific RS provide the phase reference for the
PDSCH. The configured transmission mode also affects the transmission of the associated downlink control
signaling and the channel quality feedback from the UE.
The modulation can be QPSK, 16QAM or 64QAM.
The mapping of data to physical resource blocks can be carried out in one of two ways:
localized mapping : allocate a set of contiguous RB (in pairs) for a particular UE
distributed mapping : distribution in frequency of the different RB to take benefit from frequency
diversity. Used for VoIP.

The basic structure of the Physical Multicast Channel (PMCH) is very similar to the PDSCH. However, the PMCH
is designed for ‘single-frequency network’ operation, whereby multiple cells transmit the same modulated
symbols with very tight time-synchronization, ideally so that the signals from different cells are received within
the duration of the cyclic prefix. This is known as MBSFN (MBMS Single Frequency Network) operation. As the
channel in MBSFN operation is in effect a composite channel from multiple cells, it is necessary for the UE to
perform a separate channel estimate for MBSFN reception from that performed for reception of data from a
single cell (on PDSCH). Therefore, in order to avoid the need to mix normal reference symbols and reference
symbols for MBSFN in the same subframe, frequency-division multiplexing of the PMCH and PDSCH is not
permitted within a given subframe; instead, certain subframes may be specifically designated for MBSFN, and it
is in these subframes that the PMCH is transmitted.
The key differences from PDSCH in respect of the PMCH are as follows:
• The dynamic control signalling (PDCCH and PHICH ) cannot occupy more than two OFDM symbols in an
MBSFN subframe. The PDCCH is used only for uplink resource grants and not for the PMCH, as the scheduling of
MBSFN data on the PMCH is carried out by higher-layer signalling.
• The pattern of reference symbols embedded in the PMCH is different from that in the PDSCH. (Note, however,
that the common reference symbol pattern embedded in the OFDM symbols carrying control signalling at the
start of each subframe remains the same as in the non-MBSFN subframes.)
• The extended cyclic prefix is always used. Note, however, that if the non-MBSFN subframes use the normal
cyclic prefix, then the normal cyclic prefix is also used in the OFDM symbols used for the control signalling at the
start of each MBSFN subframe.
The latter two features are designed so that a UE making measurements on a neighbouring cell does not need
to know in advance the allocation of MBSFN and non-MBSFN subframes. The UE can take advantage of the fact
that the first two OFDM symbols in all subframes use the same cyclic prefix duration and reference symbol
pattern.

No physical channels are associated with the UL physical signals.
The roles of the uplink physical signals include enabling channel estimation to aid coherent demodulation,
channel quality estimation for uplink scheduling, power control, timing estimation and direction-of-arrival
estimation to support downlink beamforming. Two types of RS are supported on the uplink:
Demodulation RS (DRS), associated with transmissions of uplink data on PUSCH and/or PUCCH. These
RSs are primarily used for channel estimation for coherent demodulation. Since PUSCH and PUCCH
cannot be transmitted simultaneously, there are two DRS for PUCCH and PUSCH.
Sounding RS (SRS), not associated with uplink data and/or control transmissions, and primarily used
for wideband channel quality determination to enable frequency-selective scheduling FSS on the uplink
(i.e. the frequency resource is assigned selectively on the subbands having the best CQI)
Why do we have two types of RS in UL (unlike the DL)? The DRS in UL are only transmitted on subcarriers
assigned to UE and therefore do not provide sufficient wideband channel quality information for resource
allocation (particulary for RB not allocated to UE).

Unlike the DL, the RS in UL cannot be transmitted at the same time as user data. Instead, the UL RS are
time multiplexed with the UL data on the assigned subcarriers. In this way, the power level of the RS can
be different from that of the data (in SC-FDMA, the PAPR within one symbol –same time but different
frequencies- must be preserved)
The ZC-based sequence provides a constant amplitude in the frequency domain and the ability to provide a
large number of sequences with zero or low correlation

SRS is transmitted on the last SC-FDMA symbol of the subframe (i.e. the 14th SC-FDMA symbol of the
subframe). Frequency hopping of SRS is not supported in LA6.0
UE-specific parameter srsDuration (one shot, infinite) allows the eNodeB to request a one-shot UE-specific
SRS transmission or to configure a UE to periodically send SRS. The SRS period is increased as the number
of UEs increases. In LA6.0, there can be up to 3 period configurations assigned among all users. The first
UEs have an SRS period of 5ms if uplinkControlChannelLUTindex = 0 and an SRS period of 20ms if this
parameter is 1. If number of users in the cell is small enough, these periods are assigned to all users in the
cell.
Only wideband SRS is configured in LA6.0: the SRS bandwidth is limited to the cell-specific parameter
srsBandwidthConfiguration (6 possible values per system bandwidth, ex: 16/20/24/36/40/48 PRBs for
10MHz). Notice that full bandwidth sounding provides the most complete channel information when the UE
is sufficiently close to the eNodeB, but degrades as the path-loss increases when the UE cannot further
increase its transmit power to maintain the transmission across the full bandwidth.
In order to support frequency-selective scheduling between multiple UEs, it is necessary that SRS from
different UEs with different sounding bandwidths can overlap. In order to support this, Interleaved FDMA is
used with SRS with a Repetition Factor (RPF) of 2 (the signal occupies every 2nd subcarrier within the
allocated bandwidth). The comb (0 or 1) can be configured with parameter initSrsTransmissionComb (not
supported in LA04.0)
All these parameters are forwarded to the UE through the broadcast signalling (cell specific SIB2).
SRS is not sent when there is a PUCCH format 2/2a/2b (over 10 symbols) or when there is a ACK/NACK or positive SR
in the same subframe on the last symbol

In LA6.0, initSrsTransmissionCom (0 or 1) is set by Local Terminal (LUT). Will be configurable in further
releases.
Reminder: the PUCCH/SRS configuration profiles specify the periodicity for Periodic CQI, SR (Scheduling
Request) and SRS (Sounding Reference Signal) that the UE is configured with to use in the cell. The shorter
is the periodicity, the higher is the profile.
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 (hardcoded but is configurable in LR13.3). 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.

LR13.3 feature 166802

When the UCI (CQI+ACK/NACK+SR+PMI/RI) is transmitted on the PUSCH, the modulation and coding
scheme is determined by the MAC scheduler in the eNodeB. But here with PUCCH, no resource is assigned
to the UE by the eNodeB. There are 6 formats of PUCCH (1,1a,1b,2,2a,2b) depending on what data has to
be sent. All PUCCH formats use a cyclic shift of a based sequence to transmit in each symbol, so UCI from
multiple UE can be multiplexed.
PUCCH modulation is BPSK or QPSK and based on a Zadoff-Chu sequence (12 cyclic shift sequences
corresponding to 12 subcarriers).
Resource mapping: the PUCCH is never transmitted simultaneously with the PUSCH from the same UE
(time-division to retain single carrier property of SC-FDMA). Notice that for a given UE, if CQI or ACK/NACK
have to be sent when there is PUSCH they have to be multiplexed on PUSCH. However, the PUCCH can be
frequency multiplexed with the PUSCH from other UEs in the same subframe. For TDD, the PUCCH is not
transmitted in the UpPTS field of the special subframe (only for SRS or random access). The PUCCH uses
one RB in each of the two slots in a subframe (the same data is doubled at both ends). The PUCCH is
transmitted at the bandwidth edge (in order to provide contiguous bandwidth in the middle for data as only
localized resources is allowed in UL and in addition, it provides frequency hopping.)
Each UE is assigned a Zadoff-Chu sequence as well as a PUCCH region.
Number of PUCCH regions: for 1.4, 3, 5, 10, 20MHz: 1, 2, 4, 8, 16

Scheduling request (SR) is sent when the UE has something to send (Buffer Status Reporting). The SR is
sent over PUCCH with format 1. When L1 of the eNodeB receives SR on PUCCH, it should notify UL
scheduler about this event. Then the UL scheduler should deal with this request based on its scheduling
principles. If the eNodeB doesn’t support the scheduling request, the UE will trigger a RACH each time it
receives some data in its transmission buffer and hasn’t got an UL grant in that same TTI. It is unexpected
due to the resource waste by RACH and possible data delay due to RACH procedure.

LTE uses the RACH for initial network access (but the RACH cannot carry any user data in contrast to
UMTS). The LTE RACH is used to achieve uplink time synchronization for a UE which either has not yet
acquired, or has lost, its uplink synchronization. Once uplink synchronization is achieved for a UE, the
eNodeB can schedule orthogonal uplink transmission resources for it. Relevant scenarios in which the RACH
is used are therefore:
(1) A UE in RRC_CONNECTED state, but not uplink-synchronized, needing to send new uplink data or
control information (e.g. an event-triggered measurement report);
(2) A UE in RRC_CONNECTED state, but not uplink-synchronized, needing to receive new downlink data,
and therefore to transmit corresponding ACK/NACK in the uplink;
(3) A UE in RRC_CONNECTED state, handing over from its current serving cell to a target cell;
(4) A transition from RRC_IDLE state to RRC_CONNECTED, for example for initial access or tracking area
updates;
(5) Recovering from radio link failure.
One additional exceptional case is that an uplink-synchronized UE is allowed to use the RACH to send a
Scheduling Request (SR) if it does not have any other uplink resource allocated in which to send the SR.
There are 4 Preamble formats in LTE. Format 0 is the ‘normal’ format. Format 1, also known as the
‘extended format’, is used for large cells (extended CP). Format 2 and format 3 use repeated preamble
sequences to compensate for increased path loss, and are used for small cells and large cells respectively;
format 4 is defined for frame structure type2 only.
ALU LR13.1 supports formats 0&2&3; ALU TLA6.0 supports formats 0&4

Feature LA5.0 L115436
RACH Format 2 allows to support extended cell coverage up to a 29.5 km cell radius. In practice, the
propagation conditions and UE transmit power constraints will limit the cell radius to a smaller value and
link budget analysis must be carried out to determine the achievable cell radius.
The RACH Format 2 preamble has two key attributes that distinguish it from Format 0:
Longer CP which allows the higher cell radius (29.5 km vs. 14.5 km)
Longer sequence which allows a 2-3 dB gain in link budget
In LA4 (Phase 1), only the successful decoding of the longer CP of Format 2 will be supported at the eNB,
which would allow for the higher cell radius of 29.5 km. The preamble sent by the UE consists of twice the
same sequence (format 2). The eNB does not ignore the second part of the preamble, it cumulates the
energy received on both parts. On eCEM LA4 and LA5 we support “fake” format 2 which uses a format 0
receiver, meaning that only the first part of the RACH format 2 premable 2 is used, but this is a limitation.
In LA5/6 with bCEM, it is planned to support “real” format 2 (i.e. with a format 2 receiver: L92639 - RACH
Improvements - RACH Burst Format 2 Support).
It should be noted that each RACH Format 2 transmission occupies 2TTIs. Hence the RACH resource
overhead is increased from 6PRBs per frame to 12PRBs per frame.
The feature activation is on a per cell basis via OAM parameter pRACHPreambleFormat2Enabled. When
enabled, the allowable cell radius is increased from 14 km to 30 km, which can be configured via OAM
parameter cellRadius.
This feature is beneficial primarily in two scenarios:
Sub-urban & rural areas where UE has an approximate line-of-sight link to the eNB
Fiber DAS systems where distance can be “borrowed” from the cell radius to extend fiber distances
beyond 15 km (up to max of 35 km which would result in a very small cell radius)

LR13.1 feature L115767: Support of RACH Format 3
Maximum cell radius is 70km in LR13.1 and 100km in LR13.3

The UE aligns the start of the random access preamble with the start of the corresponding uplink subframe at the UE
assuming a timing advance of zero, and the preamble length is shorter than the PRACH slot in order to provide room
for a Guard Time (GT) to absorb the propagation delay. At the eNB, the end of the sequence is appended at the
start of the preamble (CP), thus allowing a periodic correlation at the PRACH receiver. The eNB has a fixed
Observation Period of the PRACH whatever the UE location in the cell.
Preamble:
The UE selects one of the (64 – Ncf) available PRACH contention-based signatures, where Ncf is the number of
signatures reserved by the eNodeB for contention-free RACH (only 16 signatures in W-CDMA: less collision in LTE). The
set of contention-based signatures is further subdivided into two subgroups, in order to indicate the amount of
resource needed to transmit the msg3 of the Random Access procedure (therefore, there is a one bit information in the
PRACH). The broadcast system information indicates which signatures are in each of the two subgroups, as well as the
meaning of each subgroup. The UE selects a signature from the subgroup corresponding to the size of transmission
resource needed for the appropriate RACH use case (some use cases require only a few bits to be transmitted at Step
3, so choosing the small message size avoids allocating unnecessary uplink resources), which may also take into
account the observed downlink radio channel conditions.
The preamble is a Zadoff-Chu sequence constructed from 64 cyclic shifts of one root ZC sequence (similar to the
Reference Signal). The 64 sequences are with zero cross-correlation: no interference from multiple RA attempts using
different preambles at the same time.
The initial preamble transmission power setting is based on an open-loop estimation with full compensation for the
path-loss. This is designed to ensure that the received power of the preambles is independent of the path-loss (see
further in chapter ‘Uplink Power Control’)
Tseq: 1) Trade-off between sequence length and overhead: a single sequence must be as long as possible to maximize
the number of orthogonal preambles, while still fitting within a single subframe in order to keep the PRACH overhead
small in most deployments; 2) Compatibility between PRACH and PUSCH subcarrier spacings (constraints on Tseq
linked to the carrier generation in SC-FDMA: Tseq*fs must be an integer, with fs being the system sampling rate, e.g.
30.72MHz); 3) Coverage performance (a longer sequence gives better coverage, but better coverage requires a longer
CP and GT in order to absorb the corresponding round-trip delay).
CP and GT Duration: CP must provide protection against multipath interference even for the cell-edge UEs. GT is the
Guard Time to absorb the propagation delay of the preamble.

There is one root ZC sequence allocated initially to a cell (through parameter rootSequenceIndex) and the
preambles are the 64 orthogonal cyclic shifts of this root ZC sequence. The same initial ZC sequence can be
allocated to several cells.
Sequences obtained from cyclic shifts of different ZC sequences are not orthogonal . Therefore, orthogonal
sequences obtained by cyclically shifting a single root sequence should be favoured over non-orthogonal
sequences; additional ZC root sequences should be used only when the required number of sequences (64)
cannot be generated by cyclic shifts of a single root sequence. The next root sequences of the cell are
rootSequenceIndex +1, +2 etc. The cyclic shift dimensioning is very important in the RACH design.
The restricted set is necessary for high speed cells. In this set, the minimum difference between two cyclic
shifts is NCS but the cyclic shifts are not necessarily multiples of NCS
CellRadius: This information is provided by the cell planning on a cell-by-cell basis. It is recommended that
this parameter be provisioned accurately to keep the probability of RACH preamble detection high enough
and also for the automatic PCI allocation algorithm
Remark: In TLA6.0, the cyclic shift index NCS is configured by parameter zeroCorrelationZoneConfig. The
value to be provisioned was derived “offline” based on high speed and cell radius information. But the
principle is the same.

These two features enable compensation for signal path delays between the BBU and antenna output of an
eNB so as to have no reduction of RF range due to fiber / cable delays.
Base Functionality (common to L100622 & L115670) is to support total distance from BBU to Antenna tip
(L1+L2) of up to 15 km without impacting the max cell radius (L3) as shown in the figure. The fiber
connection on BBU-radio or eNB-DAS links introduces additional round-trip delay which skews the RACH
preamble arrival time at the eNB. The base functionality compensates for this additional delay and adjusts
the center of the PRACH search window so that the search window range of the eNB can be fully used for
cell range.
This feature is optional and subject to licensing.

In LR13.1, TotalRTT0 = 200micros (on eCEM and on bCEM when maxTransportFiberDelayLengthCategory
is set to “fifteenKm”) and TotalRTT0 =170micros on bCEM when maxTransportFiberDelayLengthCategory is
set to “tenKm”, and Tprocessing is assumed to be equal to 50micros (the processing delay varies
depending on the Hardware used). Therefore, (T0, cabling) is assumed to be equal to 75000 ns (on eCEM
and on bCEM when maxTransportFiberDelayLengthCategory is set to “fifteenKm”) and to be equal to 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
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 above 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”.
TotalRTT0 is the hardcoded (value depends on maxTransportFiberDelayLengthCategory) maximum total
allocated round trip time delay between the BBU and the antenna. The (T0,cabling) is the actual one-way
delay between the BBU and the antenna without taking account the processing delay in the BBU, RRH, etc.
For example, if the two-way processing delay is 50us, and if maxTransportFiberDelayLengthCategory =
fifteenKm, i.e. TotalRTT0 = 200us, then the two-way cabling delay should not exceed 200 - 50 = 150us,
therefore (T0,cabling), which is a one-way delay, should not exceed 150/2= 75us.
If Cabling Delay is 75100ns (= 75100*10^-9 s), we will have :
Maximum Cell Radius = 14,5km – 300000km/s * (75100ns – 75000ns) * 10^-9 = 14,5 – 3 * (75100 –
75000) */10000

After a UE has first synchronized its receiver to the downlink transmissions received from the eNodeB, the
initial timing advance is set by means of the random access procedure. This involves the UE transmitting a
random access preamble from which the eNodeB can estimate the uplink timing and respond with an 11-bit
initial timing advance command contained within the Random Access Response (RAR) message. This allows
the timing advance to be configured by the eNodeB with a granularity of 0.52 µs from 0 up to a maximum
of 0.67 ms, corresponding to a cell radius of 100km.
The granularity of 0.52 µs enables the uplink transmission timing to be set with an accuracy well within the
length of the uplink Cyclic Prefix (CP) (the smallest value of which is 4.7 µs).

In deriving the timing advance update commands, the eNodeB may measure any UL signal which is useful.
This may include the Sounding Reference Signals (SRSs), Channel Quality Indicator (CQI), ACK/NACKs sent
in response to DL data, or the UL data transmissions themselves.
A timing advance command received at the UE is applied at the beginning of the uplink subframe which
begins 4–5 ms later (depending on the propagation delay).
For a TDD or half-duplex FDD system configuration, the new uplink transmission timing would take effect at
the start of the first uplink transmission after this point.
The timing advance update commands are generated at the Medium Access Control (MAC) layer in the
eNodeB and transmitted to the UE as MAC control packets which may be multiplexed together with data on
the Physical Downlink Shared Channel (PDSCH).
Like the initial timing advance command in the response to the RACH preamble, the update commands
have a granularity of 0.52 µs. The range of the update commands is ±16 µs, allowing a step change in
uplink timing equivalent to the length of the extended CP. They would typically not be sent more frequently
than about 2 Hz.
The eNodeB configures a timer for each UE, which the UE restarts each time a timing advance update is
received; if the UE does not receive another timing advance update before the timer expires, it must then
consider its uplink to have lost synchronization. In such a case, in order to avoid the risk of generating
interference to uplink transmissions from other UEs, the UE is not permitted to make another uplink
transmission of any sort without first transmitting a random access preamble to reinitialize the uplink
timing.

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.
timingAlignmentCommandTimer is no longer configurable starting from LA5.0. Instead, it is calculated
based on the UE timeAlignmentTimer as follows.
timingAlignmentCommandTimer = rounddown (timeAlignmentTimer/2.5), in the unit of msec.
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.

Upon UE creation, the UE is initialized in the init-sync state. Upon receipt of a RACH message 3 containing a
C-RNTI MAC CE matching the C-RNTI value assigned to a given user (this happens when UE uses RACH
procedure after Timing Advance failure at UE side or SR max event), the uplink scheduler transitions the UE
to the “in Sync state”.
The MAC function starts an uplink synchronization timer (ulSyncTimer) upon receipt of a notification from
the UL scheduler that the related call has transitioned to “out of sync state”. This timer is stopped upon
receipt of a notification that the call has transitioned back to “in sync state”. If the timer expires, the UL
scheduler transitions the UE to MAC_RLF state, i.e. declares “MAC RLF” (as opposed to RLF due to the
maximum number of RLC transmissions being reached without receiving an RLC ACK). Upon expiration of
ulSyncTimer, the uplink scheduler considers the radio link associated with the UE context to be failed.
Note that TA failure notification (from DL scheduler) transitions the UE to MAC_RLF state regardless of the
state it was in. The UL scheduler ignores the TA failure event from the DL scheduler if it occurs within
100ms after RACH 3 event (for an existing UE).
Also note that in case of UE RACH-back (i.e. if a RACH message 3 is received) the UL scheduler transitions
the UE to the UL IN_SYNC state.

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 RRC Connection Release or RRC Connection Re-establishment messages) to
be transmitted.

This is the basic DRX implementation without LR13.1 Feature L128003: MAC DRX Mgmt under Inactivity
DRX functionality can be configured for an ‘RRC_CONNECTED’ UE so that it does not always need to
monitor the downlink channels. A DRX cycle consists of an ‘On Duration’ during which the UE should
monitor the PDCCH and a ‘DRX period’ during which a UE can skip reception of downlink channels for
battery saving purposes.
There are two UTRA ANR measurement reports: ‘Report-CGI’ uses DRX while ‘Report-Strongest-Cells-For-
SON’ shares the same measurement gap pattern used by inter-RAT mobility measurement defined in
rcMeasurementConf::measurementGapsPattern

LR13.1 Feature L128003: MAC DRX Mgmt under Inactivity
DRX functionality can be configured for an ‘RRC_CONNECTED’ UE so that it does not always need to monitor the
downlink channels. A DRX cycle consists of an ‘On Duration’ during which the UE should monitor the PDCCH and
a ‘DRX period’ during which a UE can skip reception of downlink channels for battery saving purposes.
The parameterization of the DRX cycle involves a trade-off between battery saving and latency. On the one
hand, a long DRX period is beneficial for lengthening the UE’s battery life. For example, in the case of a web
browsing service, it is usually a waste of resources for a UE continuously to receive downlink channels while the
user is reading a downloaded web page. On the other hand, a shorter DRX period is better for faster response
when data transfer is resumed – for example when a user requests another web page.
To meet these conflicting requirements, two DRX cycles – a short cycle and a long cycle – can be configured for
each UE, with the aim of providing a similar degree of power saving for the UE in RRC_CONNECTED as in
RRC_IDLE. The transition between the short DRX cycle, the long DRX cycle and continuous reception is
controlled either by a timer or by explicit commands from the eNodeB. In some sense, the short DRX cycle can
be considered as a confirmation period in case a late packet arrives, before the UE enters the long DRX cycle – if
data arrives at the eNodeB while the UE is in the short DRX cycle, the data is scheduled for transmission at the
next wake-up time and the UE then resumes continuous reception. On the other hand, if no data arrives at the
eNodeB during the short DRX cycle, the UE enters the long DRX cycle, assuming that the packet activity is
finished for the time being.
The Figure shows an example of DRX operation. The UE checks for scheduling messages (indicated by its C-
RNTI on the PDCCH) during the ‘On Duration’ period of either the long DRX cycle or the short DRX cycle
depending on the currently active cycle. When a scheduling request message is received during an ‘On
Duration’, the UE starts a ‘DRX Inactivity Timer’ and monitors the PDCCH in every subframe while the DRX
Inactivity Timer is
running. During this period, the UE can be regarded as being in a continuous reception mode. Whenever a
scheduling message is received while the DRX Inactivity Timer is running, the UE restarts the DRX Inactivity
Timer, and when it expires the UE moves into a short DRX cycle and starts a ‘DRX Short Cycle Timer’. The short
DRX cycle may also be initiated by means of a MAC Control Element. When the ‘DRX Short Cycle Timer’ expires,
the UE moves into a long DRX cycle.

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. drxInactivityTimer is started when SR is received in OnDuration state and is
restarted if a PUSCH packet is received in StayActive or Off state.
Additional information on the Inactivity based DRX states:

OnDuration:
Definition: The OnDuration timer is running
DLS & ULS Behavior: Allowed to schedule new UL grants or new DL assignments
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
StayActive:
Definition: (The OnDuration timer has expired AND the inactivity timer is running) OR (ULS buffer occupancy is not empty*)
DLS & ULS Behavior: Allowed to issue new UL grants or DL assignments
* Most likely due to a detected SR
Off:
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
• Suppress periodic BO increase associated with any radio bearers

Engineering Recommendation for parameter drxInactivityTimer : 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.
Engineering Recommendation for parameter longDrxCycle: set for every InactivityBasedDrxConf object; for the
object assigned to the ID corresponding to VoIP bearer ( QCI1 ) the recommended value is sf40.
The shortDRXCycle is disabled in LR13.1 so this value will be ignored.
The drxShortCycleTimer is disabled in LR13.1 so this value will be ignored. Is a multiple of shortDrxCycle. That's
why there is not unit. If shorDrxCycle = sf20 and drxShortCycleTimer = 4, then drxShortCycleTimer = 80ms.
The Inactivity based DRX is not supported when SPS (Semi-Persistent Scheduler) is enabled for a call, or when
TTI-bundling is configured, or if Measurement Gap is configured.

DRX Configuration:
The eNB sends an RRC Connection Reconfiguration message to the UE, which contains the DRX parameters (cycle length, offset, on
duration) and the measurement configuration. The UE responds by sending an RRC Reconfiguration Complete message. At handover,
the target eNB sends an RRC Connection Reconfiguration message that disables the DRX
DRX mode activation: (DRX mode activation: description applies to DRX used for CSFB or ANR but not for DRX under inactivity
conditions. Here DRX is activated when both onduration and drxinactivity timers are not running)
CallP sends a DRX start command to the DL scheduler to request it to send the DRX command (MAC CE) to the UE.
The DL scheduler generates a Timing Advance command to preserve UL timing alignment during the cycle and thus avoid
having to resort to a RACH procedure to re-establish data flow (in case of TA timer expiry).
The DL scheduler generates a (TA + DRX) command and considers scheduling it immediately:
- The (DRX+TA) command has the highest or the 2nd highest scheduling priority
The DL scheduler notifies the UL scheduler that it is trying to get the UE into DRX.
If the first HARQ attempt fails, the (DRX+TA) command is retransmitted until
- an ACK is received
- a new DRX On Duration starts
- A new timing correction is generated
- The new timing correction is included in a (DRX+TA) command
When the HARQ ACK is received, the DL scheduler notifies the UL scheduler, indicating that the UE is now in DRX mode.
The DRX command, when correctly received, gets the UE in the DRX mode and immediately in OFF state.
DRX mode deactivation:

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. In this case, the UE is already out of DRX as it sent SR
to be granted.
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
The maximum number of cycles is reached. 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 the timer T321 = max nbr of cycles x cycle length.

Document History
07 22-12-2013 Kine, Jean-Philippe Updates for LR13.3


Page
1 Schedulers 8
1.1 Introduction 9
1.1.1 Schedulers in MAC Layer 10
1.2 DL UE Context 11
1.2.1 Number of DL UE Context 12
1.2.2 Number of DL UE Context at UE 13
1.3 DL Scheduler Principles 14
1.3.1 Prebooking and Scheduling Phases 15
1.3.2 TimeFrequencyResBlockOccupancy Matrix 16
1.4 DL Static Scheduler 17
1.5 DL Semi-Static Scheduler 19
1.5.1 DL Semi-Static Scheduler Figure 20
1.5.2 D-BCH Scheduling 21
1.5.3 SIB1 Scheduling 22
1.5.4 SIB2 to 13: Scheduling Class 23
1.5.5 SIB2 to 13: Target MCS 24
1.5.6 SIB2 to 13: Periodicity 25
1.5.7 SIB2 to 13: SI Messages 26
1.5.8 SIB2 to 13: SI Windows 27
1.5.9 SIB2 to 13: Example 28
1.5.10 SIB2 to 13: Scheduling Process 29
1.5.11 PCCH Prebooking 30
1.5.12 pagingForceMCSmin 31
1.6 DL Dynamic Scheduler 39
1.6.1 FDS and FSS Modes of Dynamic Scheduler 40
1.6.2 Scheduling Types 43
1.6.3 QoS Weighted Metric 45
1.6.4 alphaFairnessFactor 46
1.6.5 Resource Allocation 47
1.6.5.1 Implementation 49
1.7 Minimum Bitrate Enforcement for Non-GBR 53
1.7.1 Downlink Scheduler Mechanism 54
1.7.2 Uplink Scheduler Mechanism 55
1.7.3 minRate QoS Weight 56
1.7.4 Downlink Parameters 57
1.7.5 Uplink Parameters 58
1.7.6 Example 59
1.7 DL Semi-Persistent Scheduler for VoIP 62
1.7.1 Semi Persistent vs Dynamic Schedulers 63
1.7.2 VoIP Support at UE and eNB levels 64
1.7.3 DL SPS Prohibit Timers 65
1.7.4 Conditions to Activate the DL SPS 66
1.7.5 DL SPS Activation Procedure 67
1.7.6 MCS Computation for DL SPS 71
1.7.7 VoIP MAC frame with RoHC 72
1.7.8 TBS Computation for DL SPS 73
1.7.9 DL SPS Release 75
1.7.10 DL SPS Deactivation Procedure 76
1.8 UL Scheduler Principles 79
1.9 UL Static Scheduler 80
1.9.1 RACH Message1 Resource Allocation 81
1.9.2 RACH Message3 Resource Allocation 82
1.10 UL Dynamic Scheduler 84
1.10.1 UL Buffer Status Reporting from UE 85
1.10.2 UL Buffer Estimation in eNodeB 86

Page
1.10.3 Power Headroom Reporting by UE 88

1.10.4 Alpha Fairness Scheduler 89
1.10.5 Avoid UL Grants of Padding 90
1.11 UL Speech Activity Status Monitoring 92
1.12 UL Semi-Persistent Scheduler for VoIP 94
1.12.1 UE Candidate List for UL SPS 95
1.12.2 Conditions to Activate the UL SPS 97
1.12.3 UL SPS Activation/Deactivation Procedure 98
1.12.4 UL SPS HARQ Process 99
1.12.5 UL SPS Activation Timing 100
1.12.6 Zoom on the first 5 TTIs of UL SPS 102
1.12.7 PUSCH Resource Allocation 103
1.12.8 UL SPS MCS and TBS Computation 104
1.13 Optimized Segmentation for UL VoIP Calls 107
1.13.1 Minimum TBS for Optimized Segmentation 108
1.13.2 Minimum MCS for Optimized Segmentation 109
1.13.3 UE Conditions for Optimized Segmentation 110
1.13.4 Radio Fine Tuning 111
1.14.1 Customer Service Classes 115
1.14.2 QCI Scheduling Weight Parameters 116
1.14.3 Example of Configuration 117
1.15 Summary of the Schedulers 120
2 Carrier Aggregation 121
2.1 Overview 122
2.2 DL UE and Carrier Schedulers 124
2.3 DL Dynamic UE Scheduler 125
2.4 Link and Rank Adaptation 127
2.4 CA Activation 129
2.4.1 UE Capability Retrieval 130
2.4.2 Call Eligibility to DL CA 131
2.4.3 CA Call Configuration 133
2.4.4 CA Activation 134
2.5 UL Criterion for CA (De)Configuration 135
2.6 Out of Coverage Detection on SCell 137
2.7 Object Model 138
3 Transmit Power 143
3.1 DL Power Setting – Introduction 144
3.2 Cell Transmit Power Setting 146
3.2.1 cellDLTotalPower per antenna port 147
3.2.2 cellDLTotalPower 148
3.3 Reference Signal Power Setting 149
3.4 Synchonization Signals Power Setting 151
3.5 PBCH Power Setting 152
3.6 PCFICH Power Setting 154
3.7 PHICH Power Setting 155
3.8 PDCCH Power Setting 156
3.9 PDSCH Power Setting 157
3.12 PDCCH Power Control 159
3.12.1 ALU Parameters 160
3.13 DL Power Budget 162

Page
4 Uplink Power Control 164
4.1 Introduction 165
4.1.1 UL Open-loop Power Control 166
4.1.2 UL Fractional Power Control 167
4.1.3 UL Closed-loop Power Control 168
4.1.4 UL Closed Loop Power Control Protocol at eNodeB 169
4.2 UL Power Control on PUCCH 170
4.3 UL Power Control on PUSCH 171
4.4 SINR Target Computation 172
4.4.1 UL Pathloss Simulation (Pathloss Nominal) 173
4.4.2 UL Pathloss Simulation (Alpha Factor) 174
4.5 Uplink Interference Control 175
4.6 UL Power Control on SRS 179
4.7 UL Power Control on RACHmsg1 180
5 Link Adaptation 185
5.1 Link Adaptation Process 186
5.2 Adaptative Modulation and Coding in DL 187
5.2.1 AMC in DL - Example 188
5.2.2 dlMCSTransitionTable 189
5.2.3 TBS Index Table 190
5.3 Adaptative Modulation and Coding in UL 191
5.3.1 TBS index table 192
6 H-ARQ Process 196
6.1 H-ARQ Process in DL 197
6.1.1 Example (FDD) 198
6.1.2 PDSCH HARQ Timing 199
6.2 H-ARQ Process in UL (FDD) 200
6.2.1 PUSCH H-ARQ Timing 201
6.3 H-ARQ Parameters 202
6.4 TTI bundling for VoIP 205
6.4.1 TTI Bundling Activation 206
6.4.2 TTI Bundling Deactivation 208
6.4.3 Other Parameters 209

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.
The radio conditions of the UEs identified through measurements made at the eNB (in the uplink on
SRS signal) or reported by the UE (CQI 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).

According to the figure, a MAC PDU can consist of multiple MAC SDUs.
Multiplexing of MAC SDU in downlink is supported, that means multiple bearers of the same UE can be
scheduled in the same TTI. As a result, multiplexing of multiple logical channels into a transport block will
enable the scheduler to use the resource more effectively.

The downlink UE context contains the UE category, the UE DL AMBR and the UE bearers list UeBearerList,
and the UE MG (Measurement Gap) status.
AMBR: Aggregate Maximum Bit Rate
The UsBearerList is a list of bearer context identified by their LCID (logical channel ID mapped onto). Each bearer
context contains:
initial MCS to be used at bearer setup
transmission mode
HARQ max nb of transmissions
HARQ process timer
VoIP flag
DL GBR
DL MBR
SINR offset for link adaptation
target BLER
Packet Delay Budget (PDP)
Priority
MG status consists of the following 3 parameters:
MgActive: Flag indicating if MG is active for the UE
MgPeriod: Measurement Gap Repetition Period
MgOffset: MG Offset of the UE
The measurement Gaps functionality is introduced in LA3.0 by Feature L93270. It is a complement of the inter-RAT and
inter-frequency mobility features 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.

1. Feature Group Indicator bit 7 from the UE Capabilities:
bit 7 of IEfeatureGroupIndicators = 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.
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).
No more than two VoIP bearers per UE is supported (3GPP). If more than 2 UM is supported, then VoIP
bearer checking has to be performed to ensure this restriction. Also, requested combinations not supported
by the UE are rejected.

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.
VoIP can be handled by both Dynamic Scheduler and Semi-Persistent Scheduler. SPS is an optional feature
(commercial LA6.0) and offers better efficiency of VoIP. SPS is not supported in TLA05.
After an RRC connection, several SRBs are established.
An SRB is a Radio Bearer (RB) 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 (CCCH is used for control data when no
RRC connection is available). SRB0 is established at Call Setup during the RA procedure.
SRB1 is for RRC messages as well as for NAS messages prior to the establishment of SRB2, all using
the DCCH logical channel (DCCH is used for control data when RRC connection is established).
SRB2 is for NAS messages, using the DCCH logical channel. SRB2 has a lower priority than SRB1 and
is always configured by e-UTRAN after security activation (which means that RRC messages are
handled by the eNB with higher priority than NAS messages). SRB2 is established during the Attach
procedure.

The downlink scheduler is composed of 2 main algorithms:
A prebooking stage at low rate (20ms) which reserves resources for the static and semi-static
schedulers. The static resources like RS, PSS, SSS, PBCH (static), RACH Msg2 and SIB0 are reserved
A scheduling stage at TTI rate (1ms) which assigns the resources for effective traffic. The remaining
RE are shared in time and frequency for PDCCH, PCFICH, PHICH, PDSCH.

The downlink scheduler uses a bitmap of Resource Blocks (RB), PhyResBlocOccupancy. This bitmap
contains all the N(DL,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.
In (T)LA6.0, this matrix has a depth of 20ms (i.e. consists of 20 successive PhyResBlocOccupancy).
Matrix TimeFrequencyResBlocOccupancy is shown in the figure for a 5MHz bandwidth ( N(DL,RB)= 25 RBs)
TimeFrequencyResBlockOccupancy[t][rb] are flagged with for example:

FREE
USED_D_BCH
USED_PCCH
RESERVED_SRB_TA
USED_VOIP

The static scheduler is configured at cell setup, and does only change with a cell restart.

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).
The resources are freed at the scheduling stage when not needed anymore for any reason (call release,
handover, radio link failure, etc.)

In this example, RACH Msg2 had been booked at prebooking stage of the Semi-Static Scheduler. But a link
failure happened and this resource is not anymore to be used. No RACH Msg2 has to be sent at t0 + k ms
due to radio link failure and the resources are freed in order to be available by the Dynamic Scheduler.

SIB13 is not supported in LA6.0 (MBMS)
SIB8 and SIB12 are not supported in TLA6.0 (HRPD and CMAS)

SIB1: cell access information and scheduling of other system information messages. SIB1 suffers a specific
treatment because it carries essential data for the decoding of the other SIB.
in LA6.0, SIB1 has the capability to broadcast up to four PLMN identities for the cell, although only
broadcasting of two PLMN identities is tested and supported in this release.

In TLA6.0, SIB2 size increases from 223 to 257 bits to support eMBMS subframe configuration information
IE. In addition, mobility and eMBMS are not required simultaneously, so SIB13 does not need to be sent at
the same time as SIB4,…,7
Note that the MCS range never goes outside the range [0, 9] for QPSK is mandatory for the transmission of
SI messages.

The MCS used is determined by a specific algorithm and selected from the set [sib1TargetMCS +6, 9] for
SIB1 and [sib1TargetMCS, 9] for SIB2, SIB3, SIB4, SIB5, SIB6, SIB7, SIB8 and SIB13

Scheduling class 1 has the lowest periodicity by construction:
sibClass1TargetPeriodicity (sysInfoConf; default=16rf) <= sibClass2TargetPeriodicity (default=64rf) <=
sibClass3TargetPeriodicity (default=128rf)

System Information Message has a size limit of 2216 bits due to the imposed DCS format; since the header
has a 14-bit size, this implies a maximum size of 2202 bits for System Information Blocks.
The expected size of SIBs is based on the following assumptions in addition to TLA6.0:
SIB2: mbsfn-SubframeConfigList is included and maxMBSFN-Allocations is 1.
SIB13: maxMBSFN-Area is 1

The SI-message0 contains SIB2 in the first position and possibly other SIB (at same periodicity). The semi
static scheduler can retransmit twice SI-message0 within the SI-window of 20ms, at any place except SIB1
place.
SI-Windows of different SI-Messages do not overlap, i.e. only one SI-Message is broadcasted and
retransmitted within the subframes of an SI-window

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 given by ( N(RB in DL)- numberRBnotForSIB
) where numberRBnotForSIB is an OAM parameter configuring the number of RBs that are not used for SIB
scheduling and N(RB in DL) is the total number of RBs in the spectrum.
A large SI message containing at least 2 SIBs may be split into smaller SI messages, where eah SIB from
the large SI-message is allocated to one of the smaller SI-messages. The class parameters of the smaller
SI-messages remains the same as those of the larger SI-message. An SI-message may be split for the
following reasons:
-the size of the SI-message is greater than 2216 bits (3GPP limitation)
-if the SI-message requires more RBs than the nb of RBs that are available for the SIB scheduling N(RB in
DL) – numberRBnotForSIB)
After SI-messages have been splitted (if needed), if the nb of RBs to allocate for an SI-message is still
greater than (N(RB in DL) – numberRBnotForSIB), the MCS is increased by 3 and a retransmission is
scheduled (to acount for the possible increasee in BLER due to the higher MCS) until the recalculated
number of RBs to allocate is less than or equal to the N(RB in DL) – numberRBnotForSIB

The downlink scheduler buffers the paging requests then constructs a paging message bearing one or more
Paging Records to be sent at the same time. If some requests do not fit in the message, the scheduler
postpones them to the next Paging Occasion.
In each frame, the semi-static scheduler prebooks a set of contiguous RBs for PCCH. The resources are
prebooked in subframe 9. The number of prebooked RBs depends on the MCS and is limited to 6 at 10MHz
and 8 at 20MHz.

Parameter pagingForceMCSmin configures the index of the most robust MCS that can be used for paging
messages:
The MCS used is determined by a specific algorithm and selected from the set:
[0 , 9] for paging messages if parameter pagingForceMCSmin is set to -1
[pagingForceMCSmin, 9] if parameter pagingForceMCSmin is not set to -1
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.
Restriction:
In LA6.0, to keep available bandwidth for semi-persistent VoIP and PCCH allocation, up to 1 paging sub-
frame per frame is supported: nB ≤ T. This gives a PCCH bandwidth of 1 sub-frame per Paging Cycle, so up
to 32 Paging Occasions per Paging Cycle of 320 ms.
nB represents the number of paging sub-frames per Paging Frame. Its value is {4T, 2T, T, T/2, T/4, T/8,
T/16, T/32}.

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. The
example above is for RACH Format 0.

RACH 2 scheduling uses Aggregation Level 4 in the common search space. When there is no RACH activity,
the message 2 PRB resources are freed for reuse by the dynamic scheduler.
Parameter rachMsg2ForceMCSmin configures the index of the least robust MCS used for the transmission of
RACH message 2. The range is 0-9 since QPSK is mandatory.
Msg2SubFrameNumber = (RACHMsg1SubFrameNumber + RACHMessage1toMessage2Offset) modulo 10
RACHMsg1SubFrameNumber represents the number of the subframe RACH message 1 and is derived
from the physicalLayerCellIdentityIndex (PCI-Index=0>1;1>4;2>7).
RACHMessage1toMessage2Offset represents the offset between RACH message1 and RACH messag2
in units of subframes. It is hardcoded to 7ms for eCEM (fake RACH format2) and 9ms for bCEM (real
RACH format2)

LR13.3 feature 166802: RACH capacity improvement part in Enb Software Capacity Configuration
The eNB can send the RAR within the RA response window (raResponseWindowSize ) after the receipt of the
RACH Msg1. The eNB can decode 2 RACH msg1 received from 2 Ues on the same PRBs providing the preambles
are orthogonal. So, it can send in the same RACH Msg2 2 RAR to 2 different Ues.
Msg2 grant size in the RACH cycle i :

• Msg2NbrPRB (i) = min { rachMsg2NumberOfRB, ceil
[Msg2PayloadInBits(i) / rachmsg2SpectrumEfficiency ] }
where Msg2PayloadInBits = nbrRARs(i) * 7 + (RA backoff needed? 1: 0)
RA backoff: The RAR (Random Access Response) conveys the identity of the detected preamble, a timing
alignment instruction to synchronize subsequent uplink transmissions from the UE, an initial uplink resource
grant for transmission of the Step 3 message, and an assignment of a temporary Cell Radio Network Temporary
Identifier (C-RNTI). The RAR message can also include a ‘backoff indicator’ which the eNodeB can set to instruct
the UE to back off for a period of time before (random value between 0 and raBackoff) retrying a random access
attempt.

VoIP can be managed by the Dynamic Scheduler and by the Semi-Persistent Scheduler (option)
Measurement processing is on CQI,PMI, RI

Frequency Diverse Scheduling: UE resource assignment (PRBs + MCS) is based on wideband CQI.
However, the RBs allocation in the frequency domain is random. It can exploit time selectivity and
frequency diversity of the channel.
Frequency Selective Scheduling: UE resource assignment (PRBs + MCS) is based on the subband CQI. It
can exploit time selectivity and frequency diversity of the channel. But only a few nb of users can work in
FSS: the DL dynamic scheduler evaluates, among the connected users, the ones to be frequency selective
or frequency diverse users based on the estimated user mobility condition & radio quality.
The dynamic scheduler uses load-based scheduler mode (i.e. user number threshold) to switch between
FDS and FFS mode and tunable at the console.
FSS provides better performances than FDS but is more UL bandwidth consuming (due to aperiodic PUSCH
subband CQI)
DL CQI is reported on periodic PUCCH (wideband) and on aperiodic PUSCH (wideband+subband)
UL CQI (wideband) is estimated from the Sounding Reference Signal
The other inputs for the scheduler are traffic volume and QoS requirements for the UE and associated radio
bearers

Default value of nbrUserThrFDS is 168 for Macro and 16 for Metro cell
Default value of deltaNbrUserThrFDS is 10

A preliminary allocation phase consists in scheduling retransmissions before allocating resources to new
transmissions. In case retransmissions are scheduled in the coming TTI, the amount of power available for
new transmissions is reduced accordingly.

There are three basic scheduling types defined.
Round Robin: serve UEs one after the other
Advantage: all UEs are served
Drawback: allocated resources are not adapted to radio conditions, Ues in bad radio conditions will
lead to retransmissions and therefore decrease of MAC cell throughput
Max C/I: serve UEs which reports the best radio conditions (best CQI)
Advantage: choosing UEs on radio conditions improves effective throughput by inducing smaller
probability to get errors and thus triggering less retransmissions
Drawback: selecting UEs according to radio conditions induces UEs in bad conditions to never be
served
Proportional Fair: all UEs benefit from the same throughput
Advantage: all UEs are served
Drawback: allocated resources are not adapted to the amount of data to be sent per UE

If proportional fair or increased fairness, the instantaneous data rate Ru(Su) will be compensated by the
denominator expressing an average bit rate over a time window (Ru)α
The QoS weight itself is a function of the bearer parameters setting (bearer type (GBR or not), GBR value,
MBR value, DL/UL priority, PDB,...).
For alpha=0, (Ru)α = 1 and then does not penalize UE already granted; only the instantaneous best
spectral efficiency among the UEs is considered; this is a max C/I behaviour
For alpha=2, the UE alreagy granted will be penalized by (Ru)2 and then the other UE (not granted, even
with worse spectral efficiency) will be granted: this is a fair process

Alcatel Lucent implements in LA6.0 only one scheduler which is the proportional fair one: the fairness is
tunable as it is a function of the QoS Weight and the alpha factor value. The QoS weight itself is a function
of the bearer parameters setting (bearer type (GBR or not), GBR value, MBR value, DL/UL priority, PDB,...).
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 scheduler attempts to allocate
the resources in such a way that all the Ues eventually get the same data rate (which is not the case
of the fair scheduler since 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).

Type1 of resource allocation is more flexible than type0 and is able to provide more frequency diversity, but
it also requires a larger overhead in PDCCH.

The 3GPP mapping rule allow to optimize the frequency diversity and the PDCCH overload is low with type2
RA.

This slide presents the status before LR13.1
LA3.0 feature L92095: QCI & QCI Parameters For Enhanced Scheduling Decisions.
The Packet Delay Budget represents the upper bound for the time that spends between the UE and the Packet
Data Network – Gateway confidence level of 98%.
In general, congestion related packet loss rates (PLR) and per packet delays budget (PDB) 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).
With the LA3 feature, the DL scheduler supports PDB-based QoS enforcement for non-GBR traffic. The PDB is
configurable by the customer and is taken into account in the calculation of the QoS weight per non-GBR bearer.

LR13.1 feature L128460: Minimum bitrate enforcement for non-GBR.
Non-GBR QCIs can be used to carry content-rich services which are often bursty and variable-rate in nature, but
has a certain minimum throughput tolerance level when the traffic is active.
The active throughput is defined as the throughput when the radio bearer has data to transmit. 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.
The DL Scheduler maintains the DL-active-throughput per non-GBR bearer having dlMinThroughputTarget > 0
DL scheduler supports PDB-based (Packet Delay Budget) QoS enforcement for non-GBR 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= PDP) is provided to
allow customers to choose the desired metric for QoS enforcement, which offers flexible QoS control across
different QCIs.
The ‘margin’ here is an hysteresis configurable with parameter marginForNonGbrMinrateEnforcement

The UL Scheduler maintains the UL-active-throughput per UE (and not per bearer as in DL), for all non-GBR
bearers having ulMinThroughputTarget > 0. It makes no sense indeed to compute the metric per NonGBR
bearer because in the end the UE could not support the total throughput of all its elementary NonGRB bearers.
The available NonGBR throughput is the resource left once the GBR bearers have been served.

The formula for the min-rate driven weight applied ON TOP OF the per-QCI weight associated with the nonGBR
radio bearer b is:
Wa(b)= exp(dlNonGbrClippingFactor x max (0, 1 – max (0, Ra(b)/Rmin(b) - 1) / m)
where Rmin(b) is the minimum throughput target dlMinThroughputTarget for the radio bearer b, and m is the
margin applied on top of the min throughput target marginForNonGbrMinRateEnforcement.
The increasing weight function is not linear as it is for the UL min-rate enforcement, but its logarithm is linear.
In fact, we can simplify the formula above by writing:
• DL throughput measured ≤ Rmin(b) => Wa(b) = exp( dlNonGbrClippingFactor)

• Rmin(b) ≤ DL throughput measured ≤ (1 + m) * Rmin(b) => Wa(b) = exp[ dlNonGbrClippingFactor * (1 –
u/m)], with 0 ≤ u ≤ m
• DL throughput measured ≥ (1 + m) * Rmin(b) => Wa(b) = 1
The variable u above represents the ratio of throughput in excess of Rmin(b): DL throughput measured = Ra(b)
= (1 + u) * Rmin(b), 0 ≤ u ≤ m.
To better understand the calculations, see the example a couple of slides further.

The active throughput is defined as the throughput when the radio bearer has data to transmit. 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.
The minimum bit rate enforcement feature introduces different scheduling weight depending on the non-GRB
throughput. To avoid too frequent changes of the scheduling weight as the throughput changes, a forgetting
factor is used to smooth out the throughput measured (a new throughput measure at instant t is averaged using
the filtered throughput computed at instant t-1):
Filtered_Throughput[t] = (1 - Forgetting_Factor) * Filtered_Throughput[t-1] + Forgetting_Factor *
Throughput[t]
Engineering rules recommendation:

1. Set the feature activation flag: isMinRateEnforcementEnabled = ‘True’
2. For the QCI that wishes to use min rate control, set dlQoSMetricType = ‘Rate’
3. For that QCI, set dlMinThroughputTarget to the desired value.

ulMinNonGbrThrTarget metric is evaluated during data bursts (when UL Buffer Occupancy (BO) of any of the
UE’s non-GBR 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.
If ulMinNonGbrThrTarget= ∑ ulMinThroughputTarget, the UL scheduler applies uniformly increasing minRate
weight until the throughput exceeds this minimum target plus a margin specified by parameter
marginForNonGbrMinRateEnforcement. The maximum QoS weight that may be applied is specified by parameter
ulMaxNonGbrQoSWeight. This maximum weight is applied whenever the throughput remains below the
minimum throughput target (ullMinThroughputTarget).

VoIP is characterized by the small packet size with very stringent delay and jitter requirements and a large
number of simultaneous users. The eNodeB allocates radio resources (RB) to UEs and informs each UE on
PDCCH (DCI) of the modulation and coding of the next PDSCH packet. The CRC of the PDCCH is scrambled
with the UE C-RNTI. Due to small packet sizes and constant inter-arrival time of VoIP packets, a large
control overhead may be induced by VoIP every TTI.
In order to solve this problem, the scheduler uses a semi-persistent-scheduling for VoIP: the first packet is
preceded by PDCCH (UL/DL grants in DCI) and the next ones –providing the previous ones have been
acknowledged - arrive at a RRC defined periodicity without PDCCH. If one packet is NACK, PDCCH is used
again.
Specific setting of DCI parameters inform the UE of a semi-persistent scheduling process (for formats 1/1A:
MCS=‘0’;H-ARQ process=‘000’). The ‘scheduling interval’ for VoIP is provided in SIB2.
In LA6.0, the management of VoIP is updated as follows:
Speech activity status monitoring is introduced
Semi-Persistent Scheduling (SPS) is introduced (only supported by bCEM)
Dynamic Scheduler for VoIP is updated to take into account the speech activity status and the Robust
Header Compression (RoHC) status
Benefits:
Reduced PDCCH resource consumption (i.e. granting resource consumption for VoIP) thanks to the
introduction of SPS
Reduced PDSCH/PUSCH resource consumption (i.e. traffic resource consumption for VoIP) thanks to
the introduction of speech activity status management.
Enhanced Quality of Service for VoIP.

A UE can manage up to 2 VoIP bearers simultaneously in LTE (3GPP limitation).
eCEM supports only Dynamic scheduler for VoIP.

RLC UM provides in-sequence delivery of data due to HARQ process in MAC, but there is no retransmission
at RLC level of the lost PDU.
ETSI TS 136 523-2 describes the FeatureGroupIndicator
bit 7: Support of RLC UM (can only be set to ‘0’ if UE does not support VoLTE)
bit29: Support of Semi-Persistent Scheduler
bit20:
If bit number 7 is set to ‘0’:
- SRB1 and SRB2 for DCCH + 8x AM DRB
If bit number 7 is set to ‘1’:
- SRB1 and SRB2 for DCCH + 8x AM DRB
- SRB1 and SRB2 for DCCH + 5x AM DRB + 3x UM DRB
NOTE: UE which indicate support for a DRB combination also support all subsets of the DRB
combination. Therefore, release of DRB(s) never results in an unsupported DRB combination.
The support of SPS is introduced by Feature L114531

When an SPS-VoIP bearer is setup, it is first managed by the dynamic scheduler. The Semi-Persistent
Scheduler activation can only occur after the prohibit timer, started when the bearer is 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. 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 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.

If the Semi-Persistent Scheduler fails to find resources in the first 20ms after SPS activation has been
decided, 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.

When SPS is enabled in the cell, the following information is provided by the RRC layer:
SPS C-RNTI which is a unique identification of the UE used by the SPS
UL and DL SP scheduling intervals
The UE uses this SPS C-RNTI (provided during the random access procedure) to decode the message on
PDCCH
The Semi-Persistent Scheduler reserves PDCCH resources in the same TTI in the first
maxSPSActivationAttemptsDl x 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.

Starting from the SPS bearer setup, the SINR SPS (t) is updated each time a WB-CQI is received. The W-
CQI is reported by the periodic CQI report on PUCCH or by the aperiodic CQI report on PUSCH. In order to
provide sufficient margin for the duration of the talk spurt, a specific offset for SPS is added to the common
MCS computation in order to provide a margin for subsequent SINR reduction:
spsLinkAdaptationSINROffsetDl.
The updated SINR SPS MCS is used for the computation of SPS MCS, TBS and PRB size determination
upon SPS activation and for SINR monitoring, in order to trigger SPS release in case of an SINR
degradation exceeding some thresholds (see further SPS Release).
The dlMCSTransitionTable is a list of 28 SINR thresholds associated with MCS indexes (Modulation and
Coding Scheme). The lowest MCS index correspond to the lowest data rate and the most robust
modulation. SPS support only the first 15 MCS values. Another table links the MCS index with the TBS index
(Transport Block Size) and finally the number of PRB can be deduced. This is explained further in chapter
Link Adaptation.

VoIP frame with RoHC compression. The principle is to transmit the non-changing parts of the headers only
once.

Transport Block Size (TBS) is at MAC level before modulation and coding done at physical level.
defaultCodecforVoIPserviceDl : enumerate { 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 }
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 (see the left bottom table in the slide):
A table for when RoHC is used, assuming RoHC header = 4 bytes.
A second table for when RoHC is not used and IPv4 is used (iPversionForSPS is set to “ipv4”),
assuming RTP/UDP/IPv4 header = 12(RTP) + 8(UDP) + 20 (IPv4) = 40 bytes.
A third table for when RoHC is not used and IPv6 is used (iPversionForSPS is set to “ipv6”), assuming
RTP/UDP/IPv6 header = 12(RTP) + 8(UDP) + 40 (IPv4) = 60 bytes.

The GBR is provided on S1 interface at call setup. The TBS is over 20ms. The VoIP bit rate here is fixed by
the network. 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 sec + macRLCOverheadDl.

BLER is computed by the eNB based on the number of retransmissions

If the maximum number of attempts maxSPSReleaseAttemptsDl is reached, the SPS release is considered
unsuccessful: SPS is permanently deactivated for the VoIP bearer and corresponding PDSCH resources are
released

There is no Semi-Static scheduler because the RACH may be sent at any time by the UE.
The UL UE context contains the UE category, the UE UL AMBR, UebearerList and the UE MG status. The
latter consists of the following 3 parameters:
MgActive: Flag indicating if MG is active for the UE.
MgPeriod: MG Repetition Period, derived from parametermeasurementGapsPattern.
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).

RA-RNTI= Random Access Radio Network Temporary Identity
C-RNTI= Cell Radio Network Temporary Identity
Contention resolution is for the case multiple UEs use the same preamble
The UE Identity sent in RACH Msg3 is either the C-RNTI (UE in connected mode) or a random sequence of
48 bits (UE in Idle mode). The UE Identity is used for contention resolution.

Physical Random Access Channel Design:
The random access preamble part of the random access procedure is mapped at the physical layer onto the
PRACH. The design of the preamble is crucial to the success of the RACH procedure. The PRACH is time-
and frequency-multiplexed with PUSCH and PUCCH. PRACH time-frequency resources are semi-statically
allocated within the PUSCH region, and repeat periodically.
The PRACH resources within a radio frame are given by higher layers. For frame structure type1 with
preamble format 0 to 3, there is at most one random access resource per subframe; for frame structure
type2 with preamble 0 to 4, there might be multiple random access resources in an UL subframe depending
on the UL/DL configuration.
In LTE, the PRACH allocation bandwidth (frequency domain) is fixed to 6 RBs (=72 subcarriers) whatever
the system bandwidth. Note that for the smallest system bandwidth (1.4 MHz, 6 RBs) the PRACH overlaps
with the PUCCH.
It is recommended to set parameter prachFrequencyOffset so that PRACH resources do not overlap with
PUCCH resources.
The PRACH uses a different subcarrier spacing ∆fRA than other physical channels together with the
preamble sequence length NZC. Note that the data symbol subcarrier spacing ∆f = 15kHz is an integer
multiple of the PRACH subcarrier spacing ∆fRA (=1.25kHz for RACH formats0-3 and 7.5kHz for RACH
format4). This is to minimize the orthogonality loss in the frequency domain and can reuse the IFFT/FFT
component.
The baseband signal generation for the PRACH is different from other UL physical channels and no DFT-
based precoding is applied, as the DFT of a Zadoff-Chu sequence is also a Zadoff-Chu sequence.

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.
If the system is operating in the 700 MHz upper C band (i.e. if ul700MHzUpperCBlockEnabled is set to
“True”) parameter rACHMessage3StartingPRBIndex must be set to 37.
Parameter cfRACHMessage3NumberOfPRBs is introduced in LR13.3

The dynamic scheduler manages also the VoIP bearers when SPS is not activated or when SPS is activated
but the radio conditions do not allow SPS to be active for a given mobile

Buffer Status Reports (BSRs) from the UE to the eNodeB are used to assist the eNodeB’s allocation of uplink radio
resources. The basic assumption underlying scheduling in LTE is that radio resources are only allocated for transmission
to or from a UE if data is available to be sent or received. In the downlink direction, the scheduler in the eNodeB is
obviously aware of the amount of data to be delivered to each UE; however, in the uplink direction, because the
scheduling decisions are performed in the eNodeB and the buffer for the data is located in the UE, BSRs have to be
sent from the UE to the eNodeB to indicate the amount of data in the UE that needs to be transmitted over the UL-
SCH.
Two types of BSR are defined in LTE: a long BSR and a short BSR; which one is transmitted depends on the amount of
available uplink transmission resources for sending the BSR, on how many groups of logical channels have non-empty
buffers, and on whether a specific event is triggered at the UE. The long BSR reports the amount of data for four
logical channel groups, whereas the short BSR reports the amount of data for only one logical channel group. Although
the UE might actually have more than four logical channels configured, the overhead would be large if the amount of
data in the UE were to be reported for every logical channel individually. Thus, grouping the logical channels into four
groups for reporting purposes represents a compromise between efficiency and accuracy.
A BSR can be triggered in the following situations:
whenever data arrives for a logical channel which has a higher priority than the logical channels whose buffers
previously contained data;
whenever a certain time has elapsed since the last transmission of a BSR (periodic BSR timer);
whenever the serving cell changes.
If a UE is not allocated with enough UL-SCH resources to send a BSR, either a single bit ‘Scheduling Request’ (SR) is
sent over the Physical Uplink Control Channel (PUCCH), or the random access procedure is performed to request an
allocation of an uplink radio resource for sending a BSR.
Thus LTE provides suitable signalling to ensure that the eNodeB has sufficient information about the data waiting in
each UE’s uplink transmission buffer to allocate corresponding uplink transmission resources in a timely manner.
Each time retxBsrTimer expires and the UE has data available for transmission, a BSR is sent (regular BSR). If it
remains data in UE not granted by eNB, BSR retransmission timer expires. This timer is used to prevent deadlock
situations where the eNodeB waits for a SR and the UE does not trigger a regular BSR.

There is a short or a long Buffer Status Report identified by different headers. The short BSR reports (LCG-ID, buffer size) for one
LCG (Logical Channel Group) while the long BSR reports (LCG-ID, buffer size) for 4 LCGs.
The Logical Channel Group ID field identifies the group of logical channel(s) whose buffer status is being reported. The length is 2
bits.
The Buffer Size field identifies the total amount of data available across all logical channels of a logical channel group after the MAC
PDU has been built. The amount of data is indicated in number of bytes. The length of this field is 6 bits. In fact, the buffer size is an
index (0 to 63) mapped on size ranges from 0 to 150 000 octets (ex: index=50 is mapped on BS=22624 octets)
Mapping of the Logical Channel Groups (LCG ID) onto the Radio Bearer:
00: Signalling Bearer; 01: GBR bearer; 10: Non-GBR bearer1; 11: Non-GBR bearer2
If more than 1 LCG has data available for transmission in the TTI where the BSR is transmitted: report Long BSR; else report Short
BSR
MAC Buffer Occupancy (BO) information profiles are provided at cell setup: 2 profiles for SRB1/SRB2 (SignalingRadioBearerConf) and
10 profiles for the traffic bearers (TrafficRadioBearerConf). Each profile contains:
Logical Channel ID group (LCGID) value
Max-buffer-occupancy-estimate-value
Periodic-buffer-increase-flag: true / false
Periodic-buffer-increase-period
Periodic-buffer-increase-value
SRB-buffer-estimate-increase-upon-Resource-Request
Minimum-periodic-buffer-increase-value
BSR handling. The handling of the BSR is done by the UL scheduler at MAC level. Upon receipt of a long or short BSR, the UL
scheduler updates the Buffer Occupancy estimate per LCG-ID. BSR is sent in particular for non-GBR LCG like internet service.
Case of Periodic BO updates. The periodic-buffer-increase-flag can be set to ‘true’ for instance for VoIP. In this case, there is no BSR
sent in UL. The eNB has to estimate the UE BO itself (recall for VoIP: the first packet is preceded by PDCCH (UL/DL grants in DCI) and
the next ones arrive at a RRC defined periodicity without PDCCH). The BO is calculated based on GBR for VoIP and the time allocated
in UL for transmission (Periodic-buffer-increase-period and Periodic-buffer-increase-value). The speech activity and inactivity periods
are taken into account, with different parameters.
Upon notification of receipt of a Scheduling Resource request from the UE, the UL scheduler shall increase the BO estimate of each of
the logical channels configured on the call by the value of the UL-BO-Increase-Upon-Resource-Request parameter related to that
logical channel. The UE sends SR whenever data arrives on a logical channel of higher priority than the logical channels for which
data is possibly available for transmission. In any case, the UE request more grant and has not enough.
You can also receive a PUSCH grant or an Anticipated Uplink Grant (AUG from the DL scheduler on SRB1 or on RACH msg4/5): in this
case, the BO estimate shall be decreased (or resp. increased) by the number of granted bytes. The SRB are managed by the AUG
mechanisms.

In order to assist the eNodeB to schedule the uplink transmission resources to different Ues in an
appropriate way, it is important that the UE can report its available power headroom to the eNodeB.
The eNodeB can use the power headroom reports to determine how much more uplink bandwidth per
subframe a UE is capable of using. This can help to avoid allocating uplink transmission resources to UEs
which are unable to use them; as the uplink is basically orthogonal in LTE, no other UE would be able to
use such resources, so system capacity would be wasted.
The range of the power headroom report is from +40 to −23 dB. The negative part of the range enables
the UE to signal to the eNodeB the extent to which it has received an uplink resource grant which would
require more transmission power than the UE has available. This would enable the eNodeB to reduce the
size (i.e. the number of RBs in the frequency domain) of a subsequent grant, thus freeing up transmission
resources to allocate to other UEs.
A power headroom report can only be sent in subframes in which a UE has an uplink transmission grant;
the report relates to the subframe in which it is sent. The headroom report is therefore a prediction rather
than a direct measurement; the UE cannot directly measure its actual transmission power headroom for the
subframe in which the report is transmitted.
It therefore relies on reasonably accurate calibration of the UE’s power amplifier output, especially at high
output powers when reliable knowledge of the headroom is more critical to system performance.
A number of criteria are defined to trigger a power headroom report. These include:
A significant change in estimated path loss since the last power headroom report;
More than a configured time has elapsed since the previous power headroom report;
More than a configured number of closed-loop TPC commands have been implemented by the UE.
The eNodeB can configure parameters to control each of these triggers depending on, for example, the
system loading and the requirements of its scheduling algorithm.

The formula of the QoS weighted metric is different in UL with (1-alpha) at the numerator instead of alpha
at the denominator
ulSchedPropFairAlphaFactor = 1 yields a maximum C/I scheduler. The scheduler provides more
resources to UEs in better conditions.
ulSchedPropFairAlphaFactor = 0.5 yields a proportional fair scheduler. The scheduler attempts to
provide the same number of RBs to all the UEs (despite their specific radio conditions).
ulSchedPropFairAlphaFactor = 0 yields an increased fairness scheduler. The scheduler attempts to
allocate the resources in such a way that all the UEs eventually get the same data rate (which is not
the case of the proportional fair factor)

LR13.1 feature L161003: eNB SW Capacity Configurations.
- 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
-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. This 3GPP feature is implemented in the UE (the values of 7 or 4 bytes below are hardcoded in the UE and
the eNB cannot change them):
o A Release 8 or 9 UE must transmit data when available (i.e. is not allowed to send only padding / padding
BSR) when it receives an UL grant size of 7 bytes or larger.
o For a Release 10 UE, the minimum UL grant size is of 4 bytes or larger.
Consequence: as a release 8 or release 9 UE is not forced to send data (but can send padding instead) when it
receives an UL grant of less than 7 bytes, there is a risk of wasting resources if the eNB sends UL grants of less
than 7 bytes. On the other hand, because this 3GPP requirement came late, some release 8 UEs might not be
following this 3GPP requirement.
Therefore, the operator is given the possibility to set the minimum UL grant size sent by the eNB. 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 that can 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 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.

The uplink scheduler maintains a speech activity state machine for each VoIP bearer, irrespective of whether SPS is
configured or not for the bearer. Monitoring of the presence of Silence Description (SID) frames involves the monitoring
of UL RLC SDUs size, for SDUs corresponding to the 3GPP 39 bit SID frame + Header. However, there is a possible risk
of mistaking the 3GPP SID frame (39 or 40 bits mapped onto 5 bytes) with the EVRC (Enhanced Variable Rate Codec
used in CDMA) quarter rate frame (40 bits mapped also on 5 bytes). This is a problem when the UE is in Speech
Inactive state to determine whether a UE is really in speech inactive state or in EVRC rate ¼.
In LA6.0, the differentiation of SID frames and EVRC rate 1/4 frames consists in observing the amount of data
delivered over a 40ms period to the UL RLC entity used for the UL VoIP bearer.
If it is a stream of SID frames, then one or zero SID frame is received over the 40ms period (since the SID frame
interval is 160 or 320ms).
If it is a stream of ¼ speech frames, then two or three speech frames are typically received over the 40ms
period (since the speech frame interval is 20ms).
Thus, upon entering the “speech active” state, in every 40 ms interval, the amount of data delivered to the UL RLC
entity associated to UL VoIP bearer of a given user is compared to the threshold sIDframeDetectionThresholdUl
(ENBEquipment/Enb/EnbVoipConf; default=69):
If the amount of UL VoIP data observed in the 40ms interval is below sIDframeDetectionThresholdUl bytes, it is
considered that either 1 SID frame was received or no frame was received at all.
If on the other hand, the amount of UL VoIP data observed in the 40ms interval exceeds
sIDframeDetectionThresholdUl bytes, it is considered that speech frames were received.
If the number of consecutive non speech frames reaches ActiveToInactiveSpeechThresholdUl
(ENBEquipment/Enb/EnbVoipConf; default=4), the bearer is transitioned to “speech Inactive” state.
Upon entering the “speech inactive” state, in every 40 ms interval, if the amount of UL VoIP data observed exceeds
InactiveToActiveSpeechThresholdUl (ENBEquipment/Enb/EnbVoipConf; default=17 what means 125 bytes) bytes, it is
considered that talk spurt has resumed and the VoIP bearer is transitioned back to “Speech Active” State.
Also, if a BSR report indicating that the amount of speech data is greater than or equal to
inactiveToActiveSpeechBSRthresholdUl (in BSR unit) is waiting in the UE buffer, the UE is transitioned to the “Speech
Active” State.

Three situations can cause an SPS activation prohibit timer to be launched:
At call setup
Upon UL SPS activation failure
Upon Measurement Gap activation
Upon UL SPS grant release due to poor UL SPS link performance

The Wideband SINR is the one calculated on PUSCH (and not on SRS)

RACH msg1 and RACH msg3 are managed by the static UL scheduler

UL SPS is activated when the PUSCH/PUCCH resources have been found.

spsHarqTxCountBeforeSpsGrantReTxUl = 2 transmissions of the UL TB on PUSCH

The PUSCH is scheduled 4 ms after the PDCCH

Once the initial SPS VoIP TBS is determined, it is used, in conjunction with the nominal MCS configured by
parameter nominalMCSforSPSgrantsUl to obtain the grant size, the actual MCS to be used and the final
SPS VoIP TBS:
The grant size (i.e. number of PRBs to allocate) NPRB is determined as the lowest value that fits the
initial SPS VoIP TBS assuming a transmission with MCS=nominalMCSforSPSgrantsUl.
The MCS to be used MCSSPS is determined as the lowest one allowing to fit the initial SPS VoIP TBS
assuming a transmission on NPRB PRBs.
The final SPS VoIP TBS is derived assuming a transmission on NPRB PRBs using MCSSPS.
Question: What happens when, during the SPS UL transfer, the MCS to be used is lowering so that the NPRB
reserved for SPS does not allow to select a SPS TBS big enough to send all needed VoIP frame bits ?
Answer: The MCS to be used for the SPS transmission is chosen prior to SPS activation and does not
change throughout the period SPS is activated. There is such a procedure as UL SPS release, which is
different from the DL one but the principle is the same, based on SPS release grants
Example: TBS=30bytes (VoIP) = 240 bits; initial MCS parameter=12; TBS index=11 providing 2 PRBS (376
bits); then lowest I_TBS to support 240bits on 2 PRBs is I_TBS=8; MCS=8; final TBS=256 bits

This feature (LA6.0 L160815) 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 labelled “s5-N” requires 3 or more transmissions, then a new voice
packet (which arrives every 20ms) will experience a delay in scheduling.

Note that in LA6.0, the solution can be tuned only on a per eNB basis for only one type of codec, 12.65
kbps AMBR WB codec, and when RoHC is enabled over the call. (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.)

VoLTE needs to be running otherwise feature has no application on the network
RoHC needs to be enabled, eNB parameter: ActivationService::isRohcAllowed = “True”
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).

Feature LA6.0 L160636
This feature concerns all dynamic and semi persistent UL/DL schedulers. Supports weighted proportional
fair scheduling based on QCI.
Performance differentiation provided: non-GBR vs non-GBR, GBR vs non-GBR
Until LA3, the requirements were just:

For GBR QCIs, maintain the GBR.
For the nonGBR beares, the traffic is equally split between the bearers, no matter the QCI
The QCI differentiation feature has been implemented in LA4 (92095 feature): DL offers a fixed (3:1)
nonGBR QoS differentiation PDB based QoS as a temporary solution. It was possible to have 3 times more
throughput for a nonGBR bearer compared to another one.
In the example above:

QCI9 traffic will be allocated the double of RF Resource (throughput) comparing with QCI8 traffic
QCI7 traffic has 4 times more than QCI8

Data traffic can be classified into different QCIs based on the service tier, which can then be assigned with
different scheduling weights in the eNB and obtain differentiated performance.
Role of the UL/DL priority: mobility (QCI based mobility)

Recall of some basic concepts already explained in the LTE Radio Principles course.
Introduction:
LTE-Advanced aims to support peak data rates of 1 Gbps in the downlink and 500 Mbps in the uplink. In order to
fulfil such requirements, a transmission bandwidth of up to 100 MHz is required; however, since the availability
of such large portions of contiguous spectrum is rare in practice, LTE-Advanced uses carrier aggregation of
multiple Component Carriers (CCs) to achieve high-bandwidth transmission. Release 8 LTE carriers have a
maximum bandwidth of 20 MHz, so LTE-Advanced supports aggregation of up to five 20 MHz CCs.

LR13.3 introduces DL carrier aggregation with up to 2 serving cells (feature L160847).
• cellMappingOverBoard = ‘modeNonCA’ means that a bCEM can manage cells of different sectors; when CA is used, each
bCEM can manage only the cells of one sector
• In case of one modem failure (among several ones), cells with the same frequency are assigned to the same working
modem (no CA mode). In case of modem recovery, eNB re-assigns the modem resources to enable the use of CA again if
isCellRemappingForCarrierAggregationRecoveryEnabled = True
• Interaction with features - must be deactivated
• eUTRAN sharing
• L115244 - eUtran sharing: enhanced MOCN (either shared or dedicated spectrum) (LA5)
• L115242 - GWCN configuration (with shared MME) for eUtran Sharing (LA5)
• L104836 - eUTRAN sharing mobility (LA4)
• L115680 - eUTRAN Sharing - Up to 6 PLMN and Multi-carriers support (LR13.1)
• eMBMS
• L115527 - eMBMS trial support (eMBMS services configured by OAM command) (LA5)
• 167219 - eMBMS commercial (step2) (LR13.3)
• Other features
• L114492 - Generalized OP-PUCCH (T/LA6)  WPS check
• L115767 - RACH Improvements - RACH burst format 3 support (up to 70 km radius) (LR13.1)
• 163181 - Full Range support for RACH Format 3 (LR13.3)
• L115808 – 128505 - Tri-carrier BBU (LR13.3)
• L115401 - Nine cells (one frequency) support on three modems (LR13.3)
• 134689 - Macro/Metro to HeNB cell mobility (LR13.1)
• VoIP is exclusive to CA for a particular UE when the VoIP bearer is setup, RRC Reconfiguration sent to UE includes
VoIP bearer addition and CA de-configuration at the same time
•CA is compatible with DRX and measurement gap to GERAN and UTRAN
•CA user is not eligible to OTDOA

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 DL UE Scheduler and
• The DL Carrier Scheduler
In the figure, the CA is supposed to be activated.
The DL UE Scheduler is the first step responsible to select a subset of UEs present in (P)Cell for the Carrier
Aggregation.
The DL Carrier Scheduler is in the second step responsible to allocate radio resource to the best UE among the
UEs selected by DL UE Scheduler. Every TTI, the DL Carrier Scheduler uses the resources which are left available
by the Static and Semi-Static Schedulers.
In LR13.3, CA only applies to DL i.e. UL CA reports are only on Pcell: CSI report for both PCell and SCell are sent
on UL to PCell. The CSI report of measurements done on Scell are not sent to SCell but to Pcell which transfers it
to the Scell (eNB internally).

In LR13.3, in the initial CA implementation, A-CSI for SCell was managed using a list of elected UEs (as for A-
CQI in previous releases). The scheduler can manage up to 48 A-CQI requests on SCell. The implementation has
then been changed to a one-shot approach (no list) i.e. when an A-CSI is required for Scell (period expiry
depending on the number of CA users in Scell), the request will be queued in the UL scheduler and if the request
cannot be carried out, it will just be discarded thus “one shot” or best effort. The A-CSI is requested by the DL
scheduler to the UL scheduler to perform link adaptation on SCell.
The UL Scheduler must schedule the One Shot A-CSI requested by DL Scheduler within a maximum delay set by
CarrierAggregationPrimaryConf:: oneShotACSIMaxDelay (default=100ms). When this timer expires, and the One
Shot A-CSI request is not granted yet, the request is discarded by the UL Scheduler.

Refer to 3GPP 36.213 §7.2.1
CSI request is a field in the DCI on PDCCH.
Trigger1 is a bitmap of 8 bits. With 1 PCell + up to 4 SCells, the first 5 bits of trigger1 are sufficient to identify
the serving cells and the 3 last (rightmost) bits are not used.
In LR13.3, the 6 rightmost bits are currently not used since we are supporting only 1 SCell; and that’s why the
only two current possible values of trigger1 are ‘aCSIforSCell1’ (01000000 -> SCell1) and ‘aCSIforPCellAndSCell1’
(11000000 -> PCell + SCell1).

Refer to 3GPP 36.213 §7.2.1
CSI request is a field in the DCI on PDCCH.
Trigger1 is a bitmap of 8 bits. With 1 PCell + up to 4 SCells, the first 5 bits of trigger1 are sufficient to identify
the serving cells and the 3 last (rightmost) bits are not used.
In LR13.3, the 6 rightmost bits are currently not used since we are supporting only 1 SCell; and that’s why the
only two current possible values of trigger1 are ‘aCSIforSCell1’ (01000000 -> SCell1) and ‘aCSIforPCellAndSCell1’
(11000000 -> PCell + SCell1).

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.

•The timing of activation is defined to ensure that there is a common understanding between the eNodeB and
the UE. If a MAC control message activating an SCell is received in subframe n, then the SCell has to be ready
for operation in subframe n + 8. Hence, from subframe n + 8, the UE is required to monitor the PDCCH for
downlink assignments corresponding to the newly activated SCell. SRS transmissions, CSI report, Power
Headroom can also be started in subframe n + 8.
•Normally, the 3GPP standard defines the possibility to activate and deactivate the SCells. The CA deactivation in
Scell allows the UE to save battery (not listening anymore to the PDCCH). ALU does not support deactivation in
LR13.3 via Mac command neither via UE timer. Alcatel-Lucent implementation is to stop to schedule the UE in
Scell.
•CQI=0 means UE does not detect the Scell and must no be scheduled in the SCell
•Parameter sCellDeactivationTimerR10 (DownlinkCAConf ): this timer can be used by the UE, according to the
3GPP standard, to deactivate itself the Scell. But with the value ‘infinity’, the UE can never deactivate the SCell.

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.

In LA6.0, one antenna port= one physical antenna

Rationale to have DL Power Control on PDCCH and not on PDSCH: the reception of grants (and to a lesser
extent power control commands) is crucial in LTE and therefore the power allocated to PDCCH must be
carefully tuned. On the other hand, PDSCH does not carry control information (traffic and repeated system
information). In any case, the standard does not offer the possibility to have power control on PDSCH given
that referencesignalpower and paoffset parameters are broadcasted in system information. Notice that
paOffset is UE specific and therefore the power allocated per UE on PDSCH is also specific.

The licensing is the ability to buy output power step by step according to the capacity growth of the
customer network. This is a “pay as you grow” mechanism. We must have the relation:
cellDLTotalPower < Pmax-hardware
dBm to mW conversion:
P = 10 x/10 with P in mW and x in dBm.
0dBm=1mW; 3dBm=2mW (adding 3dB means doubling the power); -3dBm=0.5mW (substracting 3dB
means dividing the power by 2) etc.

The red squares are the max power available per symbol (sum of all elementary RE powers within one TTI)
per antenna port.
The mapping of cellDLTotalPower to the physical antennas is illustrated by a red circle.
Parameter cellTotalPower is defined per antenna port. In case of 2 physical antennas, cellTotalPower is
mapped on one physical antenna (for instance cellTotalPower= 20W for antenna port0 mapped on the 1st
physical antenna of RRH2x20 and also 20W for antenna port1 mapped on the 2nd physical antenna).
In LA6.0, one antenna port= one physical antenna

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.

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 (problem for UE at cell edge to enter the cell)
If the synchro signal is sent on the two antennas (not supported in LA6.0), the power per antenna is twice
lower due to diversity effect

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.

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 singnals and channels.
Smaller settings will impair CFI, hence PDCCH reception.
CFICH must be received at high power level because this channel is key for PDCCH decoding.

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.

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 or require more PDCCH symbols to maintain PDCCH integrity, hence impacts the downlink
capacity negatively.

The power allocated to the PDSCH PRBs of a given UE are associated with a UE specific offset.
PDSCH power is not configured in TxDiv scheme (You can have spatial multiplexing with two independent
data flows).
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 power offset assoiciated with pbOffset index (0,1,2,3) correspond to the different cases in one symbol
of the ratio between the PDSCH RE and RS RE (cell-specific and related to the antenna port). The ratio can
be:
pbOffsetPdsch index case Single Antenna case Multiple Antennas

0 1 5/4
1 4/5 1
2 3/5 ¾
3 2/5 ½
The power offset are derived from this ratio (with log10 function).

The PDCCH power control is activated if pDCCHPowerControlActivation= TRUE
Power control on PDCCH is meaningful because PDCCH is UE-specific (in contrast to the shared PDSCH channel);
The DL radio conditions are based on the CQI reported by the UE. The CQI is built from DL RS signal analysis
compared to the RS Tx Power value provided in SIB2
Definitions:
In FSS scheduling, the UE reports on PUSCH for each subband a given CQI. All the PRB of a given subband will
have the same CQI value.
In FDS scheduling (high speed UE), the UE reports on PUCCH only the wideband CQI (in this case, the sole
wideband CQI value is associated with all RBs)
The CQI is by definition the highest MCS (Modulation and Coding Scheme) level that can be supported with a 10%
BLER on the first H-ARQ process
PDCCH Power Control mechanism:
A given UE is assumed in the following to have several PRBs spread over several subbands within one TTI
The CQI values per PRB are converted into SINR values thanks to the CQItoSINRlookUpTable (15 values fixed
per NodeB with the assumption 10% BLER). The SINR are averaged using a forgetting factor for A-CQI or P-CQI,
in order to have the estimated SINR.
The target SINR comes from the table dlTargetSINRTableForPDCCH
An algorithm aims at defining the PDCCH Power Offset to be applied for a given UE at a given TTI in order to
reach the target SINR, depending on the UE search space (common or UE-specific) and on the DCI format. The
same power is applied per CCE.
If the target SINR is not reached (Estimated SINR< target SINR), the power is increased. The limit is
configured by parameter pDCCHPowerControlMaxPowerIncrease.
If the target SINR is exceeded (Estimated SINR> target SINR), the power is decreased. The limit is
configured by parameter pDCCHPowerControlMaxPowerDecrease.
The UE power increase/decrease steps are limited by the the parameters
pDCCHPowerControlMaxPowerIncrease & pDCCHPowerControlMaxPowerDecrease (fixed; cell; default 6dB)

The target SINR for PDCCH is defined per AL and per DCI format.
Analysis: SINR higher for low AL (in a short duration you have more chance to transmit at high throughput)
Non 0 values are provided for AL8 that could be chosen for Common Search Space PDCCH

Uplink power control applies on PUSCH, PUCCH channels and SRS signals.
In LTE uplink, the orthogonality between intra-cell transmission for multiple Ues is achieved, which removes
the intra-cell interference. This leaves the inter-cell interference as the major cause of performance
degradation. In LTE, the power control in the uplink is to control the interference caused by Ues to
neighboring cells while maintaining the required SINR at the serving cell. Conventional power control in UL
is to achieve the same SINR for different Ues at the base station, also known as full compensation, but it
suffers low spectral efficiency as the common SINR is limited by the cell-edge UEs. The UL power control in
LTE employs a combination of open-loop and closed-loop control. This in theory requires less feedback than
a purely closed-loop scheme, as the closed-loop feedback is only needed to compensate for cases when the
UE’s own estimate of the required power setting is not satisfactory.
Uplink power control in LTE can be seen as a ‘toolkit’ from which different power control strategies can be
selected and used depending on the deployment scenario, system loading and operator preference.

This formula is the general formula applicable to PUSCH, PUCCH and SRS.
LTE specifies Fractional Power Control (FPC) as the open-loop power control. FPC (α(j) * PL) allows UEs
with high path loss, i.e. at cell edge, to operate with low SINR requirements while generating less
interference to other neighboring cells.
Mean SINR P0 is used in order to be able to decode the signal in the cell over the noise.
For PUCCH and SRS, P0 is fixed (there is only one transmission type)
RACH Msg3 is the ‘Scheduled Transmission’ message (PUSCH RRC Connection Request)
RSRP= Reference Signal Received Power (measured by UE)

FPC is an optional licensed feature introduced in in (T)LA3.0
The objective of FPC is to have a range of SINR target at eNodeB (instead of one unique value) in order to
be able to have high throughput –or high SINR- close to the antenna (too far from the neighbor cells to
induce inter-cell interferences) and lower throughput –or low SINR- at cell edge (responsible of inter-cell
interference)

For FDD and TDD, the values of k follows the H-ARQ process discussed further in the presentation.
Case FDD: k=4
Case TDD:
For UL/DL configuration1 UL subframes 2 and 6: f(∆i)= f(∆(i-1)) + SUM ∆(i-k) with k=7,6
For UL/DL configuration1 UL subframes 3 and 7: f(∆i)= f(∆(i-1)) + SUM ∆(i-k) with k=4
For UL/DL configuration2 UL subframes 2 and 6: f(∆i)= f(∆(i-1)) + SUM ∆(i-k) with k=8,7,4,6

N is a parameter fixed at 50 in ALU (T)LA6.0 implementation
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 reaches the value of a parameter (ALU implementation:
numberofULmeasurementsNeededForSendingValidTPCCommandForPUSCHdynamicMode=50)
The SINR target is known by configuration per traffic and signalling bearer
The correction factor d_PUSCH is computed by a specific internal algorithm.
The TPC . command (containing the correction factor) is sent
If above ALU parameter=50 (fixed by default), PUSCH SINR is computed from UE SRS measurement
reports sent for instance every 5ms: there will be at most one TPC command sent every 50*5 = 250ms >
closed-loop power control in LTE is a slow mechanism
Power control command is sent to the UE in DCI Format 0, 1 or 2, when dynamic grant for DL allocation is
available. Otherwise, the command is sent in DCI Format 3/3a (and addressed to TPC-RNTI associated to
the UE). DCI Formats 3/3a carry only TCP command, format 3a is more compact.
Mapping of TPC Command Field in DCI format 0/1A/1/2A/2/3 and δ PUCCH [dB]:
0 : -1; 1 : 0; 2 : 1; 3 : 3
For DCI format 3a: 0 : -1 and 1 : 1

PUCCH is used to carry the periodic UCI reporting (CQI/PMI/RI/HARQ) and there are several PUCCH formats with
different sizes from 1 to 22 bits
Function h(CQI, HARQ) is a log function depending on the number of bits of CQI and HARQ in the PUCCH. In LA6.0, H
is null; In TLA6.0, H formula depends on the DCI format and on the cyclic prefix:
DCI format1,1a,1b and extended prefix: h=0
DCI format2,2b and normal prefix: 10log(nbCQIbits/4) if nbCQIbits>=4, otherwise 0.
DCI format2 and extended prefix: 10log((nbCQIbits+nbHARQbits)/4) if nbCQIbits+nbHARQbits>=4, otherwise 0.
DCI is carried by PDCCH physical channel. DCI format0 is for UL scheduling grants, format1/1a/1b/1c/1d for DL
scheduling information without spatial multiplexing, format2/2a/2b for DL scheduling information with spatial
multiplexing and format3/3a to carry TPC commands.
P0nominalPUCCH (ENBEquipment/Enb/LteCell/ULPowerControlConf) is an optimization parameter (default=-114
dBm for FDD and TDD UL /DL cfg1 and -100 for UL /DL cfg2) andP0UePUCCH parameter is fixed (default 0 dBm).
P0nominalPUCCH 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.
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. Parameter sIRTargetforReferencePUCCHFormat 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. The current default value for this parameter is -3.0 dB. ALU recommends
that the operator not change the settings for this parameter.
The initial value of g(i) is defined as: g(0) = ∆Prampup +δ Msg2
Where: δ Msg2 is the TPC command indicated in the random access response (RACH message 2).
∆Prampup is the total power ramp-up from the first to the last preamble configured by parameter
preambleTransmitPowerStepSize.
Mapping of TPC Command Field in DCI format 1A/1/2A/2/3 and δ PUCCH [dB]:
0 : -1; 1 : 0; 2 : 1; 3 : 3
For DCI format 3a: 0 : -1 and 1 : 1

Kpush =4 for FDD and depends on the UL/DL configuration for TDD.
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.
IN (T)LA6.0, the current default value for parameter and p0UePUSCH is 0.
The current default value for parameter p0NominalPUSCH is : TDD: cfg1 -108; cfg2 -100; FDD: depends on
PUSCHPowerControlAlphaFactor (for alpha=0.7, P0NominalPUSCH=-80dBm; see LPUG)
Formula: p0NominalPUSCH = UL_Interference + SIR_Target
PL is the downlink path loss estimate calculated by the UE as PL = RS Tx power − filtered RSRP where the filtered RSRP is the result
of the averaging of RSRP using the configurable filter coefficient filterCoefficient.
In the TLA3.0 implementation, parameter pUSCHPowerControlAlphaFactor is cell-specific and does not depend on the transmission
type j =0,1,2.
Parameter P0UePUSCH is logical channel specific.
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 1.0 in ALU templates. Below, we also provide default settings for
pUSCHPowerControlAlphaFactor = 0.8 and pUSCHPowerControlAlphaFactor = 0.7. Setting pUSCHPowerControlAlphaFactor to 0.9
yields a performance quite close to that obtained by setting pUSCHPowerControlAlphaFactor to 1.0. On the other hand, setting
parameter pUSCHPowerControlAlphaFactor to values lower than 0.7 causes a considerable decrease of cell-edge throughput.
∆TF ( TF(i )) = 10log10 (2MPR⋅Ks −1) , where:
Ks is a cell specific parameter given by RRC. If Ks = 0 , the MCS compensation does not execute.
TF(i) is the PUSCH transport format valid for subframe i.
MPR = Modulation × CodingRate = NINFO/ NRE where NINFO is the number of information bits and NRE is the number of resource
elements determined from TF(i) and MPUSCH (i) for subframe i.
Note: p0NominalPUSCH can be approximately computed as:
= -121dBm + 3dB IoT + SIR_Target(PL = RStxpower - qRxLevMin) + (1 – αPL).(RStxpower – qRxLevMin)
For 20MHz, RStxpower = referenceSignalPower = 14dBm, qRxLevMin = -120dBm, αPL = 0.7,
SIR_TargetInitial = 10dB, PLNominal = 100dB, then we would have:
p0NominalPUSCH = -121 + 3 + 0 + 40 = -78dBm

The SINR formula is obtained by subtraction of the Open-loop PC formula at current and initial times (the
closed-loop offset is assumed to be the same or negligible in both cases):
Power received at NodeB=P(j)=P(UE)-PL=[10logM + P0(j) + α(j) * PL] – PL=10logM + P0(j) + (1-α(j) )PL
With P0(j)= SINRtarget_initial + Ul_noise and P(j)= SINRtarget_current + Ul_noise
The Target_PUSCH_initial SIR is set to the value specified by parameter

uplinkSIRtargetValueForDynamicPUSCHscheduling ((Enb/EnbRadioConf). This is a key optim parameter. In
the commercial mode, and on a network level, the higher the SINR target 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 and overall cell throughput). In this case, the default setting of this parameter is as
follows: for alpha=0.8: 19.0dB; for alpha=0.7: 15.0 dB. 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).
Parameter pathLossNominal (ENBEquipment/Enb/LteCell/ULPowerControlConf) configures the nominal path
loss and corresponds to the path loss at which we want the SINR target to be
uplinkSIRtargetValueForDynamicPUSCHscheduling. Default 60dB
Parameter maxSIRtargetForFractionalPowerCtrl (ENBEquipment/Enb/LteCell/ULPowerControlConf)
configures the maximum SINR target. Default 19dB
Parameter minSIRtargetForFractionalPowerCtrl configures the minimum SINR target so that the end-user
experience remains acceptable. Default 0dB
PLav is an estimate of the average path loss based on the power headroom reports of the UE and the
average SRS power (expressed as a positive number).

The idea is to show that the pathLossNominal has to be chosen according to the estimation of the UL PL at
cell-edge and the SIR target initial. For instance, for a given UE in the cell, if you have an UL pathloss of
140dB at cell edge with a minimum SIR Target initial of 6 dB, you may choose pathLossNominal=90dB.

The idea is to show that with Alpha=0.7 or 0.8 you still reach good SIR target even at cell edge when the
UL PL is high. Value 0.9 could induce too much inter-cell interference. Values below 0.6 may limit the
possible UL path loss at cell edge. For instance, for a given UE in the cell, if you have an UL PL of 120dB at
cell edge and a minimum SIR Target of 6 dB, you can choose alpha=0.8

LA6.0 basic PUSCH interference control mechanism (CR604179)
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 (blocking the PUSCH power-up commands
and) forcing all PUSCH SINR targets to 0dB on the cell when the level of Interference over Thermal noise
(IoT) exceeds a threshold level pUSCHioTControlThresh2.
Other means in LA5 for interference management:
Interference Randomization
Frequency Selective Scheduling (FSS): allocation of resources (PRB) based on channel quality
(subband CQI)
Frequency hopping: frequency diversity and randomization of interference
Other features like ICIC and eICIC (inter-cell interference coordination) are introduced in LR13.

The Wideband noise power is computed as follows:
WidebandNoisePowerdBm = 10log10 [Σ(from p =SRSPRBStart to SRSPRBEnd) NoisePowerLinear( p)]
where NoisePowerLinear(p) is the average noise power for PRB p expressed in the linear domain.
ThermalNoisePowerdBm is a constant established during the eNB calibration procedure or computed
at cell setup.
This correction on PUSCH SINR Target allows to tune (boost) PUSCH power control aggressively for light
interference scenarios (IoT < pUSCHioTControlThresh1 and therefore allow optimal performance for single
UE Handover tests) whilst ensuring a more conservative power control tuning for load levels corresponding
to an IoT level between pUSCHioTControlThresh1 dB and pUSCHioTControlThresh2 dB.

In low interference scenarios, we allow for the correction to be negative to actually boost the UL
transmission.

Sounding Reference Signal (SRS) is a wideband signal sent to the eNodeB to measure channel quality for
UL resource allocation. SRS is not associated with PUSCH or PUCCH channels (as DMRS).
In (T)LA6.0, pSRSoffset is fixed at 7dB

Open-loop power control is applied for initial transmission of RACH (closed-loop is indeed not relevant
because RACH is a one shot procedure). The transmit power is determined taking into account the total
uplink interference level and the required SINR operating point.
The random access preamble consists of a Sequence and a CP. As UL synchronization is not established
prior to the random access procedure, a guard period GT is added to account for the round trip propagation
delay to the eNodeB. There are 5 formats of Preamble in TDD of different length. The preambles are
generated from Zadoff-Chu sequences.
preambleInitialReceivedTargetPower 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-94 (TDD) and -104 (FDD)
preambleTransmitPowerStepSize 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.

The current Modulation and Coding Scheme (MCS) (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 causes
the transmitter to use a less robust MCS and hence a higher data transmission rate. Conversely, a
degradation in the radio link quality 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.

The DL radio conditions are based on the CQI reported by the UE. The CQI is built from DL RS signal analysis
compared to RS Tx Power value provided in SIB2
Definitions:
In FSS scheduling, the UE reports on PUSCH for each subband a given CQI. All the PRB of a given subband will
have the same CQI value.
In FDS scheduling (high speed UE), the UE reports on PUCCH only the wideband CQI (in this case, the sole
wideband CQI value is associated with all RBs)
The CQI is by definition the highest MCS (Modulation and Coding Scheme) level that can be supported with a 10%
BLER on the first H-ARQ process
There is per radio bearer a target BLER defined by configuration in table macOuterLoopBlerControlTargetBler (per
traffic or signaling bearer, range 0-50%, default 10%); it may be interesting to provide a higher BLER value for
VoIP in order to avoid retransmission of this semi-permanent transmission process.
The estimated BLER is calculated by the eNodeB per RB per UE according to the number of ACK/NACK
retransmissions
AMC mechanism:
A given UE is assumed in the following to have several PRBs spread over several subbands within one TTI
The CQI values per PRB are converted into SINR values thanks to the CQItoSINRlookUpTable (15 values fixed
per NodeB with the assumption 10% BLER: [-6.00, -4.00, -2.75, -0.75, 1.25, 2.75, 5.00, 6.75, 8.50,
10.75, 12.50, 14.50, 16.25, 17.75, 20.00]) and then to capacities per PRB (expressing the throughput taking into
account the coding rate and the repetitions; there is a hardcoded table SINR-capacities in eNodeB) which are
averaged in order to deduce a mean SINR (inverse hardcoded table).
An algorithm in the AMC will produce the target SINR according to the mean SINR, the estimated BLER and the
target BLER. The algorithm provides per TTI for each scheduled bearer a common MCS to all its PRBs.
A power offset is added to the target SINR formula (new TLA3.0) to support different BLER targets depending on
the bearer type (parameter macSINROffsetForLinkAdaptation). This parameter has a role at call setup when the
BLER estimate is not available (no ACK/NACK received). During this period, only different
macSINROffsetForLinkAdaptation values can account for different SINR targets at bearer level.
The target MCS is derived from the target SINR. 29 target SINR intervals are provided. Each of them corresponds
to an MCS. The lowest interval corresponds to the most robust MCS (and hence to the lowest transmission rate).
This is done with the parameter dlMCSTransitionTable. 3GPP standard defines 31 MCS values. The last 3 ones are
reserved.

The final objective of the BLER loop control algorithm is to have the estimated BLER as close as possible as
the target BLER. The algorithm is able to add a power offset in the target SINR taking into account the
delta= target BLER – estimated BLER. Then, the target MCS is derived from the target SINR.
Recall: MCS=0 is the most robust MCS and MCS=28 the less robust (with the highest payload)

This is a key RF optimization parameter.
For MCS values: The lowest MCS value (MCS0) corresponds to the most robust MCS (and hence to the
lowest transmission rate). The highest value (MCS28) corresponds to the least robust MCS (and hence to
the highest transmission rate).
For the table: Higher threshold values (ex: changing default 2.00-3.00 to 2.00-3.50) will result in lower (but
more robust) data rates (for the target SINR values between 2 and 2.5 in our example). Lower threshold
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.

The I_MCS is provided to the UE in the DCI (5 bits field “modulation and coding scheme”). Then the UE can
derive the modulation and the TBS. The TBS (in number of bits) is obtained from the TBS index
(corresponding to the input: target MCS) and the number of PRB in DL for the next transmission.
With TBS index=0 you have bad radio conditions and need a lot of parity bits.
Notice that the table on the links side is the ITBS to NPRB mapping for only up to 10 PRB (NPRBcan be up to
110)
Notice that I_MCS 9 and 10 are mapped on the same I_TBS 9, resulting in the same data rate. Such
modulation overlap is adopted to improve the performances around the modulation switching point, as
different combinations of modulation and coding with the same rate may provide different performance in
different scenario.

The AMC in UL is less complex than in DL in (T)LA5.0
The uplink SIRN is estimated by the eNodeB from the SRS signal. Then, the SINR is mapped to one MCS
value according to two tables (fixed, per eNodeB):
ulMCSTransitionTableForSmallPUSCHGrants
ulMCSTransitionTableForLargePUSCHGrants
The choice between these two table depend on the number of PRBs that will be granted in UL for the next
transmission. This is configured by parameter (optim, per eNodeB): ulMCSTransitionTablePRBsizeThreshold
The fact to have two tables brings more flexibility in the AMC process because you can for exemple accept
less robust MCS on small packets in order to favor the throughput vs the robustness (a retransmission of a
small packet has less impact on the global UL performances than a large packet)
The SINR range is [-15, 20] dB

The SINR-MCS mapping tables (small and large) define 22 intervals (less than in DL because 64QAM is not
supported in TLA6.0 for UL). Each interval is associated to an MCS index (ex: MCS0 is associated to default
interval (-2.5, -2.0) dB)
The default value for large PUSCH is {-2.5,-2.0,-1.4,-0.4,0.0,0.9,1.9,2.7,3.2,4.3,5.1,6.0,7.0,7.9,8.5,9.3,9.8,
11.0,11.5,13.5,14.5,14.5}
Note that MCS20 and MCS21 are the same because 64 QAM in (T)LA6.0
The default value for small PUSCH is {-2.5,-2.0,-1.4,-0.4,0.0,0.9,1.9,2.7,3.2,4.3,5.1,6.0,7.0,7.9,8.5,9.3,9.8,
11.0,11.5,13.5,14.5,14.5}
The default value for the threshold is 7 PRB

The UE decodes in DCI format0 the 5bits « modulation and coding scheme » field (I_MCS), and then the
modulation is derived as well as the TBS in the same manner as in DL.
Only UL MCSs 0-22 are supported in (T)LA6.0
TBS (in number of bits) is deduced in the same manner as in DL.

It is impossible in radio to guarantee error-free transmission no matter how robust the channel coding is,
due to the effects of fading and interferences. A more robust transmission has a its limits because it
decreases the payload drastically. The solution is to use an H-ARQ protocol which is an hybrid combination
of soft combining (incremental redundancy) in Physical layer and MAC retransmissions operation.
At the Receiver (UE): the received code block coming from the eNodeB is combined with the previously
received block version for decoding. There is a buffer in UE to store the previous blocks. The ACK/NACK is
then sent on PUCCH.
At the Transmitter (NodeB) : the same turbo encoded data with different puncturing is retransmitted upon
receipt of NACK. Puncturing is done during the rate matching. The rate matcher can produce four different
redundancy versions of the original coded block.
The ACK/NACK is sent by the UE on PUCCH physical channel.
It takes a certain time for the ACK/NACK to be handled by the eNodeB: LTE specifies 8msec Round Trip
Time (RTT) between two retransmissions. To mitigate the time lost to wait the answer, N parallel H-ARQ
process per UE are supported in LTE (N=8 for FDD and depends on the UL/DL config in TDD)
The H-ARQ in DL is asynchronous : the retransmitted frame can be re-scheduled with an other MCS
(adaptative HARQ) and PDCCH with DCI format1 is required to describe the retransmitted frame. The
eNodeB decides when to retransmit a message.
HARQ in UL is synchronous where H-ARQ process is assigned to a specific subframe: this introduces less
overhead but there is no UL rescheduling to optimize the UL transmission

The HARQ ACK/NACK for process#1 is received in TTI index 5. Then, in TTI index 9, the HARQ process 1 is
transmitted again, either a new transmission if ACK or a retransmission (puncturing) if NACK.

Tp: Propagartion delay
UE DL Rx processing tie: 3TTI – 2 Tp
eNodeB DL Tx processing time: 3TTI

LTE applies a synchronous HARQ protocol in UL, that is, the retransmissions are scheduled on a periodic
interval unlike DL where the scheduler determines the timing of retransmissions. Synchronous
retransmission in UL is preferred because there is less protocol overhead.
There are two HARQ operation types in UL:
Normal HARQ operation (each frame is acknowledged one by one)
Bundling HARQ operation (Four redundancy versions of one frame are sent by the UE and the eNodeB
waits for the four versions before sending an ACK/NACK)
For the TDD mode, the number of HARQ process depends on the UL/DL configuration

The maximum number of transmission attempts per Transport Block of the bearer is configured by
parameter macHARQMaxNumberOfTransmissionDl (per radio bearer or per signaling bearer; fixed, range 1-
8)
The HARQ process timer is configured by parmeter macHARQMaxTimerDl (per radio bearer or per signaling
bearer; fixed, range 1-500ms). It is started at the time of the first transmission of the HARQ process. At its
expiry, the HARQ process is killed (RLC ARQ process can reinitialize the sending of the message). An HARQ
process is also killed after the maximum number of transmissions reached. After the killing of a process, all
the related allocated resources are freed.
For TLA6.0 only: In an adaptive HARQ scheme, transmission attributes such as the modulation and coding
scheme, and transmission resource allocation in the frequency domain, can be changed at each
retransmission in response to variations in the radio channel conditions. In a non-adaptive HARQ scheme,
the retransmissions are performed without any change. Parameter hARQRetransmissionMode (per cell;
fixed, default non-adaptative) controls whether adaptave HARQ is applied to retransmission.
Note that HARQ process does not apply to MBSFN subframe, and special subframe in special subframe
configuration 5 in TLA6.0.

TTI bundling is supported only for VoIP in current Alcatel-Lucent implementation.
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 normal PUSCH
transmission. Without TTI Bundling, 4 HARQ transmissions would take 25ms (1ms+8x3ms), which is not
acceptable for delay sensitive services such as VoIP.

The UE context creation happens on call setup, HO or call-reestablishment.
A Rel8 UE is TTI bundling capable if FGI bit#3 is set to ‘1’ and a Rel9 or 10 UE is TTI bundling capable if FGI
bit#28 is set to ‘1’.
The procedure to activate/deactivate TTI bundling is using RRC reconfiguration procedure.
The max PUSCH grant size using TTI bundling is 3 PRBs.

There is a little advantage between using allocation order 0 or 1, or between using allocation order 2 or 3. Any
PRB allocation order 0 could be mapped into a PRB allocation order 1. Same remark with 2 and 3.
However, the possibility to use allocation order 2 or 3 is quite convenient for 3 reasons: first, it allows to define
up to 8 PRBs zones with the 4 allocation triplets available; secondly, it allows to distribute the load easily on both
sides of the spectrum; and third, it allows a simple way to define optimal PRB zones when supporting PUSCH
hopping.

Note that the case: UL VoIP call rate > maxULVoIPdataRateForTTIBundling 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.

It is recommended to use ttiBundlingPrbDropThresh 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.
ttiBundlingPRBdropTimer: This parameter controls the amount of time the number of unused TTI Bundling PRBs
is at least equal to ttiBundlingPRBdropThresh before triggering a decrease of the size of the PRB zone dedicated
to TTI Bundling traffic.
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.
The Min and Max MCS are configurable for the Dynamic Scheduler and for SPS.
If the number of UNUSED PRB by the TTI Bundling is higher than ttiBundlingPRBdropThresh during at least
ttiBundlingPRBdropTimer, then the zone reserved for TTI Bundling (and configured by
ttiBundlingPRBpriorityOrder) is decreased by the number of unused PRB minus ttiBundlingPRBdropThresh
Example: if 18 reserved PRBs for TTI Bundling are not used during at least ttiBundlingPRBdropTimer, and
ttiBundlingPRBdropThresh = 12, then the zone for TTI Bundling will be decreased by 18-12=6 PRBs.
On the other hand, if the required number of PRBs for TTI Bundling is greater than the number of available PRBs
for TTI Bundling, the zone reserved for TTI Bundling will be increased by the maximum number of possible
prbGrantSizeForTTIBundling , without exceeding the zone configured by ttiBundlingPRBpriorityOrder.
Example:
prbGrantSizeForTTIBundling = 2
Max number of PRBs configured by ttiBundlingPRBpriorityOrder = 28
Current number of PRBs reserved for TTI Bundling = 14
Number of PRBs required for TTI Bundling = 17
=> The zone reserved for TTI bundling will be increased to reach 18 (=14 + 2*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.
This minimum floor is introduced to have a better control on the fairness between TTI Bundling and non-TTI
Bundling traffic.
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.
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.

Document History
07 2013-12-11 Kine, Jean-Philippe Updates for LR13.3


Page
1 Random Access Procedure 7

1.1 Overview 8
1.2 Overall Parameters of RA Procedure 10
1.3 Focus on RACH Message 3 12
1.4 Focus on RACH Message 4 13
2 RRC Connection Management 18
2.1 RRC Connection Establishment 19
2.2 Data Flow – Success Case 20
2.3 Data Flow – Failure Cases 24
2.3.1 rrcProceduredefenseTimer 25
2.3.2 Extended Wait Time for Non Delay Tolerant UE 26
2.3.3 Extended Wait Time for Delay Tolerant UE 27
2.3.4 Emergency Calls during eNB Overload 28
2.4 Cell Access Barring 31
2.4.1 accessBarringStatus Parameter 32
2.4.2 Other Cell Access Barring Parameters 33
2.4.4 MO Call Algorithm for Cell Access Barring 34
2.4.5 Emergency Call Algorithm for Cell Access Barring 35
2.4.6 Cell Access Barring when CCM/CEM Overload 36
3 Call Setup and Bearer Management 44
3.1 Call Setup 45
3.2 Bearer Management 46
3.3 QoS Parameters 48
3.3 QoS Parameters 49
3.4 On-line Bearer Modification 51
3.4.1 Data flow - ARP Modification 52
3.4.1 Data flow - QCI Modification 53
4 Paging 55
4.1 Overview 56
4.2 Paging Frame and Paging Occasion Computation 57
4.3 Paging and eNB Overload 58
5 Radio Call Admission Control 61
5.1 Overview 62
5.3 Number of Users Criteria per PLMN per Cell 75
5.4 Number of Data Bearers Criteria 78
5.5 Number of Data Bearers Criteria per PLMN per Cell 83
5.6 PRB Consumption Criteria 85
5.7 PRB Consumption Criteria per PLMN per Cell 93
5.8 PRB Consumption Criteria per Band 94
5.9 Reactive Load Control 95
5.9.1 Preemptable Bearer 96
5.9.2 Preemptable Candidate Bearers 97
5.9.3 Max Number of Ues in Reactive Load Control 98
5.11 Overview of Load Control Mechanisms 101
5.12 Preventive Load Control 102
5.12.1 Triggers for Preventive Load Control 103
5.12.2 Prioritization of Neighbor Carriers 106
5.12.3 UE Candidates for Off-loading 110
5.12.4 Number of Ues to Be Offloaded 112
5.13 Load Equalization 123
5.13.1 Offloading Mechanism 124
5.13.2 Blind Preventive Offloading 125
5.14 Connection Loading Reduction 126
5.15 Example 127

Page

6 RoHC v1 (Robust Header Compression) for VoIP 132
6.1 Introduction 133
6.2 VoIP MAC frame without RoHC compression 134
6.3 VoIP MAC frame with VoIP compression 135
6.4 Protocol Stack with RoHC 136
6.5 RoHC Channels and Contexts 137
6.6 RoHC Parameters 138

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.

The eNodeB broadcast in SIB1 random access parameters, PRACH freq and position, preamble format etc
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. Once
message 1 is transmitted, the UE starts monitoring the PDCCH for Random Access Response in the PDCCH
common space with the RA-RNTI key (the time-freq slot used for the preamble is associated with an 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.
Message 3 (First scheduled UL transmission on UL-SCH). The UE is UL synchronized to send data on PUSCH.
The UEs send the Scheduled Transmission with the temporary C-RNTI and its UE identity (C-RNTI for
connected UE or a 48bits random sequence). For users that do not already have a C-RNTI (but only a
temporary one), 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). 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.
Message 4 (Contention Resolution on DL-SCH): eNodeB selects only one UE and sends its UE identity in
the Contention Resolution message. The UE whose identity matches the one sent by eNodeB
acknowledges. The UE Contention Resolution identity 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). At the
end of the Contention Resolution process, Temporary C-RNTI= C-RNTI

Parameter preambleTransMax configures the maximum number of attempts for preamble.
It is randomly selected from a set of Random Access Preambles the number of which is configured by
parameter numberOfRAPreambles.
Parameter maxHARQmsg3Tx configures the maximum number of attempts for message3
Parameter maximumNumberOfDLTransmisionsRACHMessage4 configures the maximum number of attempts for
message4
Parameter macContentionResolutionTimer configures the mac-contention resolution timer. The timer is
started on transmission of RACH message3 and stopped as soon as a valid RACH message4 is received. If the
timer expires, the contention resolution procedure is considered as failed.

The max number of preambles is 64 in 3GPP

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

If message 4 is successfully received and the UE contention resolution identity (C-RNTI for connected UE or
48bits random UE Identity for Idle UE) 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:
The mac-contention resolution timer is stopped.
The UEs that already have a C-RNTI resume using it.
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.
If the Random Access Response or the Contention Resolution fails, the UE makes an immediate reattempt

After an RRC connection, several SRBs are established.
An SRB is a Radio Bearer (RB) 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 (CCCH is used for control data when no RRC
connection is available). SRB0 is established at Call Setup during the RA procedure.
SRB1 is for RRC messages as well as for NAS messages prior to the establishment of SRB2, all using the
DCCH logical channel (DCCH is used for control data when RRC connection is established).
SRB2 is for NAS messages, using the DCCH logical channel. SRB2 has a lower priority than SRB1 and is
always configured by e-UTRAN after security activation (which means that RRC messages are handled by
the eNB with higher priority than NAS messages). SRB2 is established during the Attach procedure.
SRB1 and SRB2 are secure; that is, it is integrity protected and, if a ciphering algorithm is available, then it is
also ciphered by the PDCP layer

S-TMSI is the SAE-Temporary Mobile Subscriber Identity.
The MME creates a UE context when a UE is turned on and attaches to the network. It assigns a unique short
temporary identity termed the SAE-Temporary Mobile Subscriber Identity (S-TMSI) to the UE which identifies
the UE context in the MME. This UE context holds user subscription information downloaded from the HSS.
The local storage of subscription data in the MME allows faster execution of procedures such as bearer
establishment since it removes the need to consult the HSS every time. In addition, the UE context also holds
dynamic information such as the list of bearers that are established and the terminal capabilities.
RRC Connection Request includes the S-TMSI and the establishment cause. If accepted (radio resource
available in eNodeB), the eNodeB returns RRC Connection Setup including the initial radio resource
configuratation with SRB1.
RRC Connection Setup Complete includes the NAS message (Service Request, Initial attachment, Tracking Area
Update, etc) to be transferred to the MME. This NAS message triggers the establishment of the S1 connection,
which normally initiates a subsequent step during which E-UTRAN activates AS-security (integrity protection
and ciphering) and establishes (RRC Connection Reconfiguration message) SRB2 and one or more DRBs
(corresponding to the default bearer and optionally dedicated EPS bearers).

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)
Internal reasons.
No UE context is created.
t302: This UE timer is started upon reception of RRCConnectionReject and is stopped upon successful RRC
establishment or cell re-selection. Sent in RRCConnectionReject (information element waitTime)
t300: This UE timer is started when sending RRCConnectionRequest and is stopped upon reception of
RRCConnectionSetup or RRCConnectionReject. Broadcasted in SystemInformationBlockType2

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.

LR13.1 feature 115805: Overload Control phase 3
If the eNodeB is in an overload condition, LA4.0 Feature FRS 115241 (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 based on thresholds on processor occupancy. The rate at which new RRC
connections are rejected is controlled by the following parameters (not sent to the UE but used by eNB to
discard a rate of RRC Connection Req messages):
rrcCnxReqRejectRateMinor (ENBEquipment/Enb/OverloadControl): 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 (defined in the UE FGI) are all rejected using extendedWaitTimeDueToENB regardless of
the settings (LR13.1).
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 (LR13.1).
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.
Following parameters are used:
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 (LR13.1).
rrcCnxReqWaitTimeMajor: This parameter defines the waitTime value to be used when RRC Connection
Requests are rejected in Major 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 (LR13.1).

LR13.1 feature 115805: Overload Control phase 3
The RRC Connection Request are not rejected by the eNB in this case because the UE can wait longer.
extendedWaitTimeDueToENB (ENBEquipment/Enb/DedicatedConf/UeTimers; default=(100, 250, 500sec.) for
(Minor, Major, critical overload)): 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.

Setting parameter ecHighPriorityCallsFilteringCriticalOverload to True will allow emergency calls (LTE or CSFB)
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:
• 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 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 percentage of blocking (100% is the standard configuration), this new
RRC Connection Request handling mechanism introduced by activation of LR13.1 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.

3GPP TS 36.331
The UE performs an access barring check during connection establishment. This function provides a means to
control the load introduced by UE-originated traffic. There are separate means for controlling Mobile Originated
(MO) calls and MO signaling. On top of the regular access class barring, Service Specific Access Control (SSAC,
introduced in 3GPP Rel9) may be applied. SSAC facilitates separate control for MultiMedia TELephony (MMTEL)
voice and video calls. Most of the SSAC functionality is handled by upper layers.
In addition, separate access control exists to protect against E-UTRAN overload due to UEs accessing E-UTRAN
merely to perform CSFB to CDMA2000.
Each UE belongs to an Access Class (AC) in the range 0–9 (randomly allocated and stored in the SIM card). In
addition, some UEs may belong to one or more high-priority special ACs in the range 11–15 (stored also in the
SIM card), which are reserved for specific uses (e.g. security services, public utilities, emergency services, PLMN
staff). AC10 is used for emergency access. PLMN staff defines in which PLMN the high priority ACs apply. The UE
considers access to be barred if access is barred for all its applicable ACs. SIB2 may include a set of AC barring
parameters for MO calls and/or MO signaling.
This set of parameters comprises a probability factor and a barring timer for AC0–9 and a list of barring bits for
AC11–15. For AC0–9, if the UE initiates a MO call and the relevant AC barring parameters are included, the UE
draws a random number. If this number exceeds the probability factor, access is not barred. Otherwise access is
barred for a duration which is randomly selected centred on the broadcast barring timer value. For AC11–15, if
the UE initiates a MO call and the relevant AC barring parameters are included, access is barred whenever the
bit corresponding to all of the UE’s ACs is set. The behavior is similar in the case of UE-initiated MO signaling.
For cell (re)selection, the UE is expected to consider cells which are neither barred nor reserved for operator or
future use. In addition, a UE with an access class in the range 11–15 shall consider a cell that is (only) reserved
for operator use and part of its home PLMN (or an equivalent) as a candidate for cell reselection. The UE is
never allowed to (re)select a cell that is not a reselection candidate even for emergency access.

accessBarringForCsfbCalls object has been added in LR13.1 in order to be 3GPP Rel10 compliant.
For example, if accessBarringStatus= ‘originatingCallsOnly’ :

-The MO calls may be barred according to the algorithm: ‘MO Call Algorithm for Cell Access Barring’ (see next
slides). Some parameters used by the algorithm are located under accessBarringForOriginatingCalls object.
The same algorithm is used for Video Mmtel, Voice Mmtel and signaling.
-The emergency calls may be barred also if accessBarringForEmergencyCalls = ‘True’ according to the
algorithm: ‘Emergency Call Algorithm for Cell Access Barring’ (see next slides)

• In addition, SIB2 contains a set of parameters:
-A barring timer for AC0–9
-A probability factor for AC0-9
-A list of barring bits for AC11–15
Any RRC Cnx Request for MO Data calls of access classes 0-9 can be barred if accessBarringInformation IE is
broadcast is SIB2. If so then some RRC Cnx Req will be barred some other will not according to the Rand value
computed dynamically by the UE of an Access Class X between 0 and 9 that does not belong to any other Access
Class or for which the Access Classes 11-15 it also belongs to are all barred

accessProbabilityFactor parameter belongs to the object: accessBarringForOriginatingCalls
The same algorithm applies to :
-Voice Mmtel (object ssacBarringForVoiceMmtel)
-Video Mmtel (object ssacBarringForVideoMmtel)
-Signaling (object accessBarringForSignaling)
• If the UE initiates a non-emergency MO call and at least one of its ACs is barred in SIB2:
-UE draws a random number (0<=rand<1)
-For AC0-9, if rand < probability factor, access is not barred. Otherwise, access is barred during T303 (the
barring timer parameter is used to compute T303)
-For AC11-15, access is barred if all UE ACs are barred according to previous algorithm
• Case MO emergency calls. If AC10 is barred in SIB2:
-UEs with AC0-9 or without IMSI are not allowed for emergency calls
-UEs with AC11-15 are not allowed for emergency calls if the relevant AC11-15 are barred. Otherwise,
emergency calls are allowed for those Ues
The ACs [11-15] refer to high priority services and can still initiate non-emergency MO call even if their AC [0-
9] is barred (provided one of their AC [11-15] is not barred)

The ACs [11-15] refer to high priority services and UE can still initiate emergency call even if their AC [0-9] is
barred (provided one of their AC [11-15] is not barred)

LR13.1 L115805: Overload Control Phase3
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 MOData 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.
In LR13.1, access class barring defense is supported only on bCEM.
Note that in addition, an internal parameter in the eNB (not user configurable) is used by qualified Alcatel-Lucent
personnel to configure the percentage of blocking of RRC Connection Requests (default=100%) when the eNB is
in critical overload.

LR13.3 feature L166502 (Out Of Time-alignment User Support)
Before LR13.3 TAC (Time Alignment Command) transmission was unconditional , TAC was scheduled as long as
user was listening to PDCCH. LR13.3 introduces conditional TAC transmission based on user traffic.
Now UE time alignment timer can expire because of traffic inactivity. When so the eNB will not assign
PUCH/SRS resource to the UE.
Feature adds handling of RACH-back event for OOT users going back into Active state (triggered by the UL or
DL traffic arrival)

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. Modem then puts the user into OOT state and informs BRC CallP of
the user state transition to OOT.
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): RRC Connection request indicates the flag “from OOT to Active”.
Otherwise (i.e., “RRC re-establishment or UE RACH-back event” in Active state), no such indication in the
request. Now CallP decides to assign and send new PUCCH/SRS resource to user (RACH msg5 received).
Intermediate state Pending-Active (modem state only): user is time-aligned with eNB but has no
PUCCH/SRS resource (configured by eNB). It still listens to PDCCH (in Active time if inactivity-based DRX is
configured) and receives PDSCH. Pending-Active user needs to first send SR in order to send UL traffic
Modem resets and starts TATimer
If UE is in Pending Active from RRC connection re-establishment or call setup, modem start Guard Timer
Guard Timer is hardcoded to 100ms and introduced so UE can complete PUCCH/SRS reconfiguration, after
which UL Sched Sync monitoring can start.
After Guard Timer expiry UE transits to Active State
If the TATimer expires UE transits back to OOT State
Recall (see radio module for more details): timeAlignmentTimer (for common or dedicated channels) is sent
to the UE (via RRC message) and configures the max time between two TAC (sent by eNB) before the UE
considers the UL synchronization lost. 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. timingAlignmentCommandTimer = rounddown
(timeAlignmentTimer/2.5), in the unit of msec.

OOT-eligibility can be changed during a call. For example, a VoIP bearer (not OOT by default because of the
delay when coming back to the Active mode) is added.
Parameters:
• isOOTManagementEnabled (activationService) = True enables the OOT management
• isOOTAllowed (trafficRadioBearer; default= True for all non real time QCIs) allows to enable OOT operation for the
traffic radio bearer
CSFB Call:
Transition from Active to OOT is disabled for (e)CSFB call establishment.
DRX parameters used to perform IRAT measurements need to be reconfigured (in the modem) when
UE returns from OOT state to active state
EC or High Priority Access (HPA)
IF detected Emergency call or HPA( RRC establishment cause or special ARP value over S1 or X2.
transition to OOT state is disabled
PUCCH/SRS pool will be reserved for EC/HPA calls to limit the possibility of blocking
Commerical CA (Carrier Aggregation) :
OOT and CA are not allowed to coexist in LR13.3.
UE supporting CA will not be eligible to OOT if CA is activated
If feature is deactivated online the criterion is only checked when the UE call context is created in eNB
CallP

Overall Principle: There is a TAC generated by MAC layer every timingAlignmentCommandTimer but the TAC
is scheduled only under specific conditions (OOT-eligibility= FALSE or dataActivityFlag= TRUE). Otherwise it is
buffered.
Remark: When a user RACH-es back due to DL or UL TRB arrival, then if eNB finds there is no CAC capacity or
no PUCCH/SRS resource available for the user, the eNB releases the user to RRC idle.

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.
Engineering Recommendation: isRedirectionForOotEnabled : The default value of this parameter is False. It can
be changed to True if the
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.

Guaranteed Bit Rate (GBR)
Service will not experience congestion-related packet loss (provided that the user traffic is compliant to
the agreed GBR QoS parameters)
Established on demand because it blocks transmission resources by reserving them in the admission
control Function Precedence of service blocking over service dropping in congestion situation
Non-Guaranteed Bit Rate (NGBR)

Service must be prepared to experience congestion-related packet loss
Can remain established for long periods of time because it does not block transmission resources
Precedence of service dropping over service blocking in congestion situation

Each bearer is assigned one and only one QoS Class Identifier (QCI).
QCI is used within the access network as a reference to node-specific parameters that control packet-
forwarding treatment (e.g. scheduling weights, admission thresholds, queue management thresholds, link
layer protocol configuration such as ARQ and HARQ parameters, etc.)
The standardized QCI label characteristics describe the packet forwarding treatment through the network
based on the following parameters:
Resource Type (GBR or non-GBR)
Priority
Packet Delay Budget (PDB)
Packet Error Loss Rate (PLR)

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.

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 and listed in the
Table shown on the slide.
The Packet Delay Budget (PDB) is defined in 3GPP 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
traffic (the one-way packet delay between Europe and the US west coast is roughly 50 ms). Note that the 20
ms average is 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.

LR13.1 Feature 115644: On-line bearer modification is used to support an incident commander or other public
safety official to modify the ARP or QCI (LS30100-15 request) associated with a user’s bearer from the Computer
Aided Dispatch (CAD) console in Public Safety networks. The ARP and/or QCI change will be provisioned from
the CAD console to the PCRF. The PCRF triggers PGW to start PGW initiated bearer modification procedure.
• ARP value modification:

• Not applicable to emergency IMS calls (because emergency bearer contexts shall not be changed to non-
emergency bearer contexts and vice versa)
• QCI value modification:

• Applicable to non-GBR bearers
• Modification between non-GBR QCI values only i.e.within the range [6..9]
• Modification of a non-GBR QCI value to a GBR QCI value is not allowed by 3GPP (TS23.401)
• Not applicable to GBR bearers
• Modification between GBR QCI i.e.within the range [1..4] is not supported
• Modification of a GBR QCI value to a non-GBR QCI value is not allowed by 3GPP (TS23.401)
Remark: CAD is not always involved. The PCRF may e.g. decide to remap QCI and ARP, based on information
received lately from another RAT.

In this procedure, eNB receives S1AP E-RAB MODIFY REQUEST, with updated ARP and/or QCI. It sends
RRCConnectionReconfiguration including NAS PDU to the UE and after getting
RRCConnectionReconfigurationComplete it sends back E-RAB MODIFY RESPONSE to MME.

In order to simplify modem design in LR13.1, every QCI modification induces an Intra Cell Handover in this
release. As intra cell handover is already supported by eNB, a QCI change does not impact modem software.
Exchange between RLC UM and AM modes is not supported.

P-RNTI is the Paging Radio Network Temporary Identifier (defined as 0xFFFE)
The change of SysInfo only occurs during Modification Periods. Upon receiving a Paging with SysInfo change
notification, the UE knows that the current SysInfo is valid until the next Modification Period boundary. After
this boundary, the UE will re-acquire the concerned SysInfo.
For ETWS/CMAS, the UE is capable to acquire the content of the SysInfo immediately without waiting for the
next Modification Period boundary.

To receive paging messages from E-UTRAN, UEs in idle mode monitor the PDCCH channel for an RNTI value used to
indicate paging: the P-RNTI . The UE only needs to monitor the PDCCH channel at certain UE-specific occasions (i.e. at
specific subframes within specific radio frames). At other times, the UE may apply DRX, meaning that it can switch off its
receiver to preserve battery power.
The E-UTRAN configures which of the radio frames and subframes are used for paging. Each cell broadcasts a default
paging cycle. In addition, upper layers may use dedicated signalling (S1 Paging message with pagingDRX optional IE) to
configure a UE-specific paging cycle. If both are configured, the UE applies the lowest value. The UE calculates the radio
frame (the Paging Frame (PF)) and the subframe within that PF (the Paging Occasion (PO)), which E-UTRAN applies to page
the UE as shown in the formula of the slide.
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.
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, 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
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}. If for example
nB is set to 2T, there will be two paging occasions in each radio frame; if it is set to T/4, 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).
The sub-frame number of a given UE's paging occasion is retrieved from a table using the index i_s
defaultPagingCycle (ENBEquipment/Enb; default=32sf)

nB (ENBEquipment/Enb/LteCell; default=1T); recommendation: 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.

If the eNB is in an overload condition, Feature LA4.0 FRS 115241 (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 (depending on the processor load). The rate at which S1 paging requests are rejected
is controlled by two configuration parameters:
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.
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.

LR13.1 L115805 feature: Overload Control phase 3
In case of eNB critical overload, the MPS allows to discriminate amongst the different Paging and to send the
ones of highest priorities (up to 8 priorities can be defined).
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.

The Transport Admission Control is described in the transmission courses (LTE Network Capacity Monitoring
and Engineering ). Our scope here is the RAC.

The incoming Request is checked on CAC criteria: some or all of the listed criterias are checked, depending on
the type of incoming request (see table).
The incoming Request types are:
Incoming SRB for new call (RRC Connection Request)
Incoming DRB for new eRAB (VoIP, GBR, non-GBR)
eRAB Modification
Incoming existing bearers in handover
Incoming existing bearers for RRC re-establishment due to a radio link failure
Incoming emergency call
Philosophy behind the different actions taken when CAC limits are exceeded.
When CAC admits an incoming bearer, it does so before taking the action to preempt another bearer(s). So
there is a short period of time (between admittance of a new bearer and preemption of a lower priority
bearer) when a limit is exceeded.
Some limits, when exceeded, will still result in some spare capacity in the eNB/cell that will allow the new
bearer to be admitted before the preemption action is completed.
Other limits, however, result in no spare capacity available. The maxNbOfDataBearersPerCell is one such
limit. For these limits, rejection of the new bearer is the only possible option due to no spare capacity at all.

The incoming Request is checked on CAC criteria: some or all of the listed criterias are checked, depending on
the type of incoming request (see table).
The incoming Request types are:
Incoming SRB for new call (RRC Connection Request)
Incoming DRB for new eRAB (VoIP, GBR, non-GBR)
eRAB Modification
Incoming existing bearers in handover
Incoming existing bearers for RRC re-establishment due to a radio link failure
Incoming emergency call
Philosophy behind the different actions taken when CAC limits are exceeded.
When CAC admits an incoming bearer, it does so before taking the action to preempt another bearer(s). So
there is a short period of time (between admittance of a new bearer and preemption of a lower priority
bearer) when a limit is exceeded.
Some limits, when exceeded, will still result in some spare capacity in the eNB/cell that will allow the new
bearer to be admitted before the preemption action is completed.
Other limits, however, result in no spare capacity available. The maxNbOfDataBearersPerCell is one such
limit. For these limits, rejection of the new bearer is the only possible option due to no spare capacity at all.

Introduce the eNB, cell, bearer parameters that may cause an overload situation when receiving a new bearer
request. In the figure, 2 PLMNs are considered. The categories per cell per PLMN are introduced in LA5.0:
enhanced eUTRAN sharing is introduced (L115242) which enables the eNB to additionally perform admission
control on a per PLMN per cell basis when a cell is shared by multiple operators.
Also in LA5.0, PRB licensing is introduced which allows the eNB to additionally perform admission control on a
per band basis across all cells of the eNB if parameter flag isUnlimitedPRBLicenseAllowed = false

Concepts of UE off-loading and DRB release that will be used in Reactive Load Control

Access of high priority users (Access Classes 11 to 15, corresponding to “for PLMN Use”, “Security Services”,
“Public Utilities – e.g. water/gas suppliers”, “Emergency Services” and “PLMN Staff”) should be handled with
an equal or higher priority than emergency calls.
The LR13.3 feature 115860 (High Priority Access admission control) enables the eNB to identify High Priority
Access (HPA) either at RRC connection setup request or, in later phases, thanks to the specific High Priority
Access ARP of some of the user’s bearers. Specific priority processing is applied, especially under load
condition.
The HPA establishment Cause is not stored by eNB, therefore not used after RRC Connection Setup Complete.
A configurable HPA-ARP range can be used in post-connection establishment phases to indicate priority.
Emergency and HPA calls have separate configurable ARP parameters, allowing one or the other to have the
higher priority. In the proposed implementation they will be handled in the same fashion.
The Push-To-Talk-emergency is one specific use case for the Establishment Cause value defined in the
standards. The UE software triggers EstablishmentCause= HPA when user presses the PTT-emergency button.
A commercial provider with PS subscribers may use the dynamic access class barring feature instead of the
EstablishmentCause= HPA. This will ensure connections for users with Access Classes 11-15 during times of eNB
congestion. In these cases, the HPA-ARP range may be used at the eNB to identify a priority call after initial
attach.
Dedicated PS networks will typically use the RRC establishment cause=HPA for priority calls. AC barring shall
not be used, as all users in a PS network have AC 11-15. The PCRF will assigh a specific HPA-ARP for the
bearer.
The number of HPA users is assumed to remain small in a commercial network. Most likely HPA calls will be
VoLTE calls in the field.
The present feature supports originating calls but does not include terminating HPA calls (paging priority) that
is covered by L115805 (Paging priority)

Interactions with other features:
In order to secure GPS geo-location of HPA personnel, DRX shall be disabled for UEs having at least one HPA
bearer established.
HPA calls are not selected for carrier aggregation.
HPA calls will not be eligible to OOT, due to risk of release when coming back
out of OOT.
eUTRA sharing: The priority used to identify bearers set up for High Priority Access users must be defined on a
per-PLMN basis

Emergency calls may be either IMS VoIP EC or Emergency CSFB.
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.

The number of users per cell is supposed not to be shared here between several operators (PLMNs).

The parameter nbOfContextsReservedForEcAndHpaCalls 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

LR13.3 feature L166802 (Enb Software Capacity Configuration)
maxNbrOfUsers is the max nb of RRC Connected users per cell
maxNumberOfCallPerEnodeB is the max nb of active users per eNB

The nb of users per cell is shared between several operators (PLMNs).
For the case of IMS VoIP EC or CSFB EC, if the above limit nbOfContextsReservedForEcAndHpaCalls
is exceeded, then reactive load control may be triggered to manage congestion and to improve the chance of
admitting the EC call.
Example:
2 PLMNs with reservedNbrOfUsers (PLMN1)= 10 users; reservedNbrOfUsers (PLMN2)= 10;
maxNbrOfUsers= 30; nbOfContextsReservedForEcAndHpaCalls = 2
Nb of users shared by all PLMNs= 30 – 10 – 10 – 2= 8

The nb of Data Bearers per cell is not shared between operators (PLMNs)
Parameters maxGBRforVoIPserviceDl and maxGBRforVoIPserviceUl are new LA4.0.
Default value (for UL and DL) is 52 600 bits/sec. ALU recommends not to change this value.
The max nb of DRB per UE is a function of Bit7 and Bit20

A QCI group is a group of QCIs. One QCI may belong to only one group, and one group can contain all
supported QCIs. QCIs in a group can be non-continuous. For instance, you can create a group of non-GBR QCIs
or a group of GBR QCIs.
maxNbrOfDataBearersPerQciGroup parameter is a list of up to 32 limits, each limit corresponding to a given
QCI Group (the first element corresponds to QCI Group1, the second to QCI Group 2 and so on).
A VoIP data bearer is a bearer with qCI= qCIforVoipRtpRtcp=1 in LA4.0
maxNbOfVoIP parameter is new LA4.0

Maximum number of Low Priority data bearers that can be admitted per cell = admissionThresholdOnNbrOfDBs
(new LA4.0)
Maximum number of High Priority data bearers that can be admitted per cell =
admissionThresholdOnNbrOfDBs + deltaAdmissionThresholdOnNbrOfDBsForHighPrioReq (new LA4.0)

Parameter lowArpPriorityStart is new in LA4.0
ARP value 15 also cannot be pre-empted

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.

The nb of data bearers per cell is shared between several operators (PLMNs)
Note that reservedNbrOfDataBearersPerQciGroup (RadioCacCellPerPlm) is a list of up to 32 integers, each one defining a QCI
group
Example:
2 PLMNs with reservedNbrOfDataBearers (PLMN1)= 30 users; reservedNbrOfDataBearers (PLMN2)= 30;
admissionThresholdOnNbrOfDBs = 100
Nb of data bearers shared by all PLMNs= 100 – 30 – 30 = 40

The nb of PRB consumption per cell is not shared between several operators (PLMNs).
dl(ul)OverheadConsumption default values depend on the system bandwith (refer to LPUG).
The resource consumption for transmission of common channels refer in downlink to the BCH, PCH, CFICH,
PHICH, PDCCH channels and in uplink RACH1, RACH3, PUCCH channels. The values of these parameters are
offset values representing the minimal PRB consumption of the cell (i.e. PRB consumption of the cell in the
absence of radio traffic bearers).
Example in DL with CFI=1 on 5MHz: you have 1/14*25 000 PRBs per sec= 1786; you have then to substract the
RS and PSS/SSS signals as well as the BCCH channel (10%); the result will be around 1606
dl(ul)AdmissionThresholdOnPrb and deltaAdmissionThresholdOnPrbForHighPrioReq (RadioCacCell)

configure the percentage of the total PRB resource count for acceptance of low (resp. high) priority radio
bearer creation in the downlink and in the uplink. Range 0 to 100. Their values have to be divided by 100 to
get the percentage.

Calculation for 5MHz: you have 25 resource blocks per TTI of 1ms and thus 25 000 within 1 sec.

Parameter prbReservationFactor is new in LA4.0
In the calculation of PRB resources consumed by GBR DRBs, the GBR value (received from the S1-AP interface)
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, optional parameter
prbReservationFactor is defined as a percentage of GBR to be used in the calculation of the PRB resource
consumption. Range 0 to 100. Value to be divided by 100 to get the percentage.
GBR aggregation is the sum of all GBR DRB. It is expressed in Kbps and therefore the PRB consumption has also
to be expressed per Kbps.
The VAD is a state machine in the MAC layer monitoring the speech activity and consisting in counting the RLC
SDU sizes in UL and DL and comparing them to thresholds. Refer to the radio module of the course (module2)
Example:
DL/UL Total resource count: 25 000 PRB/s and modulation QPSK (2 bits per symbol)
S1AP GBR= 80 kbps= 80 000/12x14x2=238 PRB/s
Average PRB per second for GBR DL/UL (from modem)= 200
Average PRB per second per kbps for GBR DL/UL= 200/75
DL/UL PRB resources required by a GBR DBR= 200/75 x 80 x 0.65= 139

Recall on (T)LA3.0 mechanism for the calculation of the PRB consumption:
DL SRB consumption = Number of PRBs consumed per SRB in DL × Number of SRBs in the cell
DL GBR consumption = Sum of DL PRB consumption of all individual GBR bearers with DL PRB consumption
of an individual GBR bearer = GBRDL × Number of PRBs consumed per Kbps in DL
DL non-GBR consumption = Number of PRBs consumed per Kbps in DL × dlMinBitRateForBE × Number of
non-GBR bearers established in the cell
UL SRB consumption = Number of PRBs consumed per SRB in UL × Number of SRBs in the cell
UL GBR consumption = Sum of UL PRB consumption of all individual GBR bearers with UL PRB consumption
of an individual GBR bearer = GBRUL × Number of PRBs consumed per Kbps in UL
UL n-GBR consumption = Number of PRBs consumed per Kbps in UL × ulMinBitRateForBE × Number of n-
GBR bearers established in the cell

dl(ul)AdmissionThresholdOnPrb + deltaAdmissionThresholdOnPrbForHighPrioReq must be ≤ 100

LR13.3 feature L163172 Traffic Management Evolution

The PRB Consumption per cell is shared between several operators (PLMNs)
LA5.0 L115242 feature: eUTRAN Sharing: enhanced MOCN
RDL_PLMN is the consumption of existing resources on the concerned PLMN

The PRB license allocation algorithm is to share dynamically the UL and DL PRB resources among the cells.
(feature LA5.0 L110762). It is only performed when the flag isUnlimitedPRBLicenseAllowed is set to “False”
with the bCEM card. When this flag is set to “True”, full carrier bandwidth is allocated to each cell on each
supported band.
When isUnlimitedPRBLicenseAllowed = ‘False’, the PRB resources cannot be counted per cell but per band per
eNB
dlPrbLicensePerBand has a range = [0, 300] and expresses a nb of PRB per TTI (ms)

We have seen the conditions for an incoming UE to be accepted for Reactive load control. We now focus on
the Reactive load process itself: UE offloading and radio bearers release
reactiveLoadControlActionForBearerAdmission::action range is {outgoingMobility, callRelease}
In case of eUTRA sharing, this parameter is under another MO. Parameter PlmnIdentity::
reactiveLoadControlActionForEcAndHpaAdmission and reactiveLoadControlActionForBearerAdmission::action
define the action (release or offload UE) for Reactive Load Control triggered by IMS VoIP EC admission and
bearer admission. The PlmnIdentity object instance is obtained from TrafficRadioBearerConf::
ReactiveLoadControlActionforBearerAdmission::plmnId.

outgoingMobility means offload action

The preemptable candidate bearers are selected according to the criteria that triggered reactive load
control:
Criteria number of data bearers per eNB >> candidates from entire eNB
Criteria number of data bearers per cell >> candidates from the entire cell
Criteria PRB consumption >> candidates from the entire cell
Criteria number of data bearers per QCI group per cell >> candidates from QCI group in the cell
Criteria number of VoIP bearers per cell >> candidates from pool of VoIP bearers in the cell (selected in
order of higher to lower GBR)

This parameter must be high enough to make the Reactive Load Control efficient (that means to have a good
success rate to offload mobiles when receiving higher priority incoming requests). This can be measured
through counters. On the other hand, setting this parameter too high would consume too much processing.

The wording ‘LoadControlThreshold’ can be dl(ul)PreventiveLoadControlThresholdOnStaticPrb or
dl(ul)PreventiveLoadControlThresholdOnRealPrb depending on the use of feature 171232 (licensing:
isQoSBasedPreventiveLoadControlEnabled = True)
The wording ‘AdmissionThreshold’ can be dlAdmissionThresholdOnPrb (low priority) or
dlAdmissionThresholdOnPrb +
deltaAdmissionThresholdOnPrbFor{Medium,High,Top}PrioReq

Parameter isInterFreqLoadBalancingFeatureEnabled allows or disables all functions associated with feature
115223. This parameter can be set to 'true' only if licensing tokens are available for this load-based mobility
trigger. In addition, parameter isPreventiveLoadControlAllowed must be set to ‘true’ to enable UE off-
loading for preventive load control.
With LR13 FRS 155912, preventive offloading can also be performed towards UTRAN FDD macro cells that have
spare load capacity. With LR13 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.
isQoSBasedPreventiveLoadControlEnabled is LR13 only (feature 171232).
How to explain the figure: the cell on LTE freq1 is loaded and the target cell on LTE freq2 is not loaded.
Preventive load control is started towards LTE freq2 (offload). Once the LTE freq2 becomes loaded, the
offload is done towards the UMTS cell (having lower priority for offload than the LTE freq2).

DL and UL thresholds (per cell) are triggered based on semi-static PRB usage. The semi-static PRB usage is an
averaged PRB consumption per (on air) kbps for the non-GBR bearers. DL/UL total resources count are the
total resources of the system bandwidth in PRB/sec.
The newly admitted request is included in the calculation.
Observation: RadioCacCell::cellNbrOfUsersLoadControlThreshold is used if
RadioCacCell::isPerNeighborCarrierLoadControlEnabled = False, and
PreventiveOffload::cellNbrOfUsersLoadControlThreshold is used if
RadioCacCell::isPerNeighborCarrierLoadControlEnabled = True.

In LR13.3, the setting of parameter maxNbrOfActiveUsersPerCell with bCEM is defined by feature 166802.
In LR13.3, with feature 171232 (nGBR QoS based load balancing) the real PRB consumption (not based on
dlMinBitRateForBE ) of all non-GBR bearers is computed by the modem.
Rationale to add a level of QoS degradation in LR13.3 to trigger a preventive load control:
Only a single or just a few UEs may use the full PRB band, in which case the eNB should not consider that the
cell is congested. The eNB is then be able to estimate the average perceived downlink RLC throughput
performance for non-GBR bearers. The downlink scheduler reports the total RLC burst size and time (activity
duration) for each non-GBR QCI, which allows calculating the average downlink RLC user throughput per QCI.
A low average throughput for active non-GBR bearers is a symptom of congestion in the cell and is used as a
criterion to trigger load balancing.
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.
The differentiation between active and connected users is done with LR13.3 feature 166502 (Out of Time
Alignment OOT).

A confortable margin should be provisionned between the thresholds of preventive an reactive load control in
order load balancing effects operate.
If isQoSBasedPreventiveLoadControlEnabled = True, the real PRB consumption is considered. Another
condition on QoS must be satisfied.
The figure shows the case isFourLevelPrbCacEnabled = False for Reactive Load Control.

Rationale for this feature: preventive offload is a mechanism to detect the need to offload a specific layer
based on load criteria thresholds. Prior to this feature, all neighbor carriers (both LTE and WCDMA) use the
same set of preventive offload threshold.
More flexibility is brought by this feature in order to have different load criteria thresholds per carrier/RAT.
For instance, you may want to offload the UEs in priority towards one LTE carrier.
If RadioCacCell::isPerNeighborCarrierLoadControlEnabled = True, then some of the existing parameters in

RadioCacCell and TrafficRadioBearerConf no longer apply to offloading. Instead, preventive offload
thresholds for load balancing are specified in the new Mos: PreventiveOffload & QciConfForOffload
To be highlighted: each nonGRB QCI has its own dlBitRateThresholdForPreventiveLoadControl

The priority of the candidate carriers is based on QciPriorityConf::eMctaPriority or
MobilityPriorityTable::DefaultConnectedPriorityofFreq.
LA05 L115204 feature Enhanced Measurement Parameter Support for Mobility
The purpose is for eNB to have better chance to receive UE measurement report on a higher priority carrier first
and so UE may be off-loaded to a higher priority carrier.

Two new timers are introduced (under rrcMeasurementConf MO) to manage the offload between several
carriers with priority per carrier.

preventiveLoadControlHysteresisTimer 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.
The selection of Ues to offload stops when any of following condition is TRUE:
- For all criteria (PRB consumption per cell, UL or DL) that triggered preventive load control, loading will not be
exceeded after UEs are off-loaded.
- Max number of UE involved (RadioCacEnb::maxNbrOfUsersImpactedByPreventiveLoadControl) is reached.
- All UEs in the corresponding scope with priority lower than
RadioCacEnb::arpThresholdForPreventiveLoadControl are checked. This parameter is explained further.

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.
eNB 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.
Note that the mechanism of offloading is fully described in the Mobility module (eMCTA).

The value of parameter extraMarginNbUeSelectedPreventiveOffload is used only if
isOOTManagementEnabled = False

Use case for Load Balancing per band:
Other than the use of the RadioCacBand threshold parameters, the procedure (activation, UE criteria,
hysteresis timer) is the same as preventive load control on the cell basis
(feature LA5.0 L110762). It is only performed when the flag isUnlimitedPRBLicenseAllowed is set to “False”
with the bCEM card. When this flag is set to “True”, full carrier bandwidth is allocated to each cell on each
supported band.
When isUnlimitedPRBLicenseAllowed = ‘False’, the PRB resources cannot be counted per cell but per band per
eNB

Rationale of this feature: previous to this feature, VoIP users were not distinguished for load balancing
purposes. The load balancing had an impact on the VoIP end user quality of service.

isInterFreqLoadBalancingFeatureEnabled must be set to True in both eNBs. Then eNB1 will send the
RESOURCE STATUS REQUEST as soon as each X2 link operational state is Enabled.
Value of X2ResourceStatusResponseTimer is fixed (hardcoded) in this release.
The Criticality Diagnostics IE in X2 RESOURCE STATUS RESPONSE is sent by the eNB when parts of a received
message have not been comprehended or were missing, or if the message contained logical errors. When
applicable, it contains information about which IEs were not comprehended or were missing.
RESOURCE STATUS UPDATE messages periodically (period= value of x2ResourceReportPeriodicity

(eNbEquipment/eNB; default=5sec)
x2ResourceStatusMaxOverload (eNBEquipment/eNB; default=300sec) specifies the maximum duration for
which the eNodeB retains the resource status information of its neighboring eNodeBs as received on the X2
interface.

3GPP ts 36.423 (X2 Application Protocol)
The Cell Capacity Class Value IE indicates the value that classifies the cell capacity with regards to the other
cells. The Cell Capacity Class Value IE only indicates resources that are configured for traffic purposes. Value
1 shall indicate the minimum cell capacity, and 100 shall indicate the maximum cell capacity.
The Capacity Value IE indicates the amount of resources that are available relative to the total E-UTRAN
resources. The Capacity Value IE can be weighted according to the ratio of cell capacity class values, if
available. Value 0 shall indicate no available capacity, and 100 shall indicate maximum available capacity.
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:
Cell with 20 call capacity => cellCapacityClass value = 100 (%)
Cell with 5 call capacity => cellCapacityClass value = 25 (%)
In an operational network, cells having the same call handling capacity will be assigned the same
cellCapacityClass value.
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.

Case CompositeAvaliableCapacityGroup IE not present: Since an ALU eNB will populate this IE, this case may
only be relevant for a non-ALU neighbor eNB.
Case LTE HeNB: 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 are treated as ‘load
unknown’ for Serving Radio Monitoring, Reactive Load Control and Preventive Load Control.

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

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. When this serving cell
threshold is met, Callp will ask UEs to measure cells on other LTE carriers.
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.
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.
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).
The LteNeighboringFreqConf::isLoadEqualizationEnabled parameter allows to enable/disable load equalization

for each LTE neighbor carrier. It is not applicable to the serving carrier.
Remark: Load equalization was requested as a means to equalize early large load imbalance between their two
5MHz PCS carriers. For instance, if loading on PCS1 is 50% whilst the loading on PCS2 is 20%, they wanted UEs
to be sent from PCS1 to PCS2 pro-actively. Their initial request was more complex then what we ended up
implementing: they wanted us to monitor the load delta between 1 cell on PCS1 and 1 or multiple cells on PCS2
and only ask UEs to measure PCS2 if the load delta was above a configurable threshold. What we ended up
implementing is a simplified version, very similar to preventive offload only with an earlier threshold. Meaning we
ask UEs to measure the other carrier as soon as the serving cell load threshold is met, and filter out
measurement reports on the target carrier if the load delta is not met.
The result in LR13.1 is that we have two similar schemes that trigger at different loading threshold on the
serving cell, and that require different loading delta between serving and target cell/carrier.

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.
ThresholdRelativePreventiveOffload (ENBEquipment/Enb/RrmServices/RadioCacEnb; default=20%)

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.
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 to enable/ disable FDD/TDD redirection

for preventive offload. This activation flag will control whether or not FDD/TDD redirection for preventive
offload is activated or not. Not used in LR13.1.

LR13.1 feature L114538: Enhanced Load Balancing Criteria
Example of application of this feature: with spare bit#15 to perform offload towards eNB TDD (load information
not available in this case).
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.
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.
The eNB::spare15, bit0 parameter is used to activate/deactivate allowing blind inter frequency preventive
offloading, i.e. preventive offloading without load information on the neighbor cell. If the spare15, bit0 value is
“1”, this will trigger handover towards the best cell. If the spare15, bit0 value is “0”, then the UE measurement
report will be ignored.

LR13.3 166802 Enb Software Capacity Configuration in LR13.3
Note : the parameter cuLoadingThreshForEarlyOOTRelease, defined in RadioCacEnb, is used for both the cell
and the eNB. It is used as follows to derive the absolute threshold for early OOT release per cell and per eNB:
Per cell: Threshold for early OOT release = RadioCacCell::maxNbUser *
RadioCacEnb::cuLoadingThreshForEarlyOOTRelease/100
Per eNB: Threshold for early OOT release = RadioCacEnb::maxNbrOfRRCConnectedUsersPerEnb *
RadioCacEnb::cuLoadingThreshForEarlyOOTRelease/100

LA4.0 – Feature L110547.1
RoHC in eNB is fully implemented by 3rd party (Winpath2 firm). ALU can configure some aspects of RoHC
(fixed parameters) but cannot intervene with the RoHC operation.
One of the main functions of PDCP is header compression using the RObust Header Compression (ROHC)
protocol defined by the IETF (Internet Engineering Task Force). In LTE, header compression is very important
because there is no support for the transport of voice services via the Circuit-Switched (CS) domain. Thus, in
order to provide voice services on the Packet-Switched (PS) domain in a way that comes close to the
efficiency normally associated with CS services it is necessary to compress the IP/UDP/RTP header which is
typically used for Voice over IP (VoIP) services.
The IETF specifies in ‘RFC 4995’ a framework which supports a number of different header compression
‘profiles’ (i.e. sets of rules and parameters for performing the compression). This means that a UE may
implement one or more of these ROHC profiles (provided in ‘UE capabilities’). Notice that RFC 4995 is an
improvement (more robust) of RFC 3095 (supported by UMTS). The support of ROHC is not mandatory for the
UE, except for those UEs which support VoIP.
As noted above, the most important use case for ROHC is VoIP. Typically, for the transport of a VoIP packet
which contains a payload of 32 bytes, the header added will be 60 bytes for the case of IPv6 and 40 bytes for
the case of IPv4 – i.e. an overhead of 188% and 125% respectively. By means of ROHC, after the initialization
of the header compression entities this overhead can be compressed to four to six bytes, and thus to a
relative overhead of 12.5% to 18.8%. This calculation is valid during the active periods, but during silence
periods the payload size is smaller so the relative overhead is higher.

VoIP frame without RoHC compression

VoIP frame with RoHC compression

The eNodeB controls by RRC signalling which of the ROHC profiles supported by the UE are allowed to be
used. The ROHC compressors in the UE and the eNodeB then dynamically detect IP flows that use a certain IP
header configuration and choose a suitable compression profile from the allowed and supported profiles.
ROHC header compression operates by allowing both the sender and the receiver to store the static parts of
the header (e.g. the IP addresses of the sender/receiver), and to update these only when they change.
Furthermore, dynamic parts (as, for example, the timestamp in the RTP header) are compressed by
transmitting only the difference from a reference clock maintained in both the transmitter and the receiver.
As the non-changing parts of the headers are thus transmitted only once, successful decompression depends
on their correct reception. Feedback is therefore used in order to confirm the correct reception of
initialization information for the header decompression. Furthermore, the correct decompression of the
received PDCP PDUs is confirmed periodically, depending on the experienced packet losses.

Data packets: user IP data packet with its header being compressed according to its RoHC Context
information, plus the RoHC protocol overhead.
Control packets: control the RoHC protocol operation between compressor and decompressor.
RoHC context: created when a VoIP data flow (stream) has been identified for a particular profile.
Feedback packets: handle the RoHC packet loss and errors.
CID (Context Id): identifies an individual RoHC Context. Each RoHC Context has a profile set according to the
type of DRB traffic data flow. The CID value is assigned by WinPath2, and is not under ALU control.
Each RoHC channel multiplexes different IP packet streams that are compressed differently using different
profiles. These different streams are identified with different compression contexts. A context is identified
with a Context ID (CID) and is a set of parameters and static/dynamic information for an IP packet stream
having the same type of header. Each context corresponds to an individual compression profile, which has
different compression algorithms. Supported RoHC profiles are defined in the Introduction slide.

Parameter rohcMaxCid specifies the maximum CID number used for an RoHC channel. This is to be configured for both UE
and eNB. In LA4.0, both UE and eNB use the same Max_CID. The maximum number of CIDs used by UE/eNB will be Max_CID
+ 1 . One VoIP DRB is mapped to one RoHC UL and one RoHC DL Channel. ALU is requesting Winpath2 to use CID = 0 for the
RTP/UDP/IP profile (most common profile for VoIP), to save one byte of compressed header size for VoIP data packets.
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. Profile 0x0000 is compulsary 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
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. Only Bit1 and Bit2 are supported in LA4.0. If all bits are set to 0,
this indicates ‘no compression’.
Therefore:
TrafficRadioBearerConf with qCI=1: set rohcProfiles to 0x110000000
TrafficRadioBearerConf with qCI ≠ 1: set rohcProfiles to 0x000000000 (no RoHCcompression)

Document History
07 2013-12_11 Kine, Jean-Philippe Update for LR13.3


Page
1 Introduction 8
1.1 Mobility Overview 9
2 Mobility in Idle Mode 10
2.1 PLMN and Cell Selection in Idle mode 11
2.2 System Information for Mobility in Idle Mode 12
2.2.1 Neighbor Cells List and Priority 13
2.2.2 Blacklisted Neighbor Cells 14
2.3 PLMN Selection 15
2.4 What is measured by the UE for Cell (re)Selection 16
2.5 Cell Selection criterion (S-criterion) 17
2.5.1 Cell Selection Parameters 18
2.5.2 Focus on puMax 19
2.5.3 Focus on qRxLevMin 20
2.6 Cell Re-selection 23
2.6.1 Cells Measurements Occurence 24
2.6.2 Measurements Rules 25
2.6.3 Frequencies/RAT Evaluation 27
2.6.4 Cell Reselection Parameters 28
2.6.5 Cell Ranking 30
2.6.6 Cell-Reselection Algorithm 32
2.6.7 Example of Cells Measurements Period for Intra-freq 37
2.6.8 Exercise of Cell Ranking 38
2.6.9 Speed Dependant Scaling 39
2.6.10 Accessibility Verification 41
2.6.11 SIB3 Parameters Adjustment based on Cell Loading 43
2.6.11.1 Cell Loading Calculation 44
2.6.11.2 Delta Parameters Selection 46
2.7 Intra-LTE Cell Reselection Object Model 49
2.7.1 Inter-RAT Cell Reselection Object Model 50
3 RRC Measurements 51
3.1 What is measured by the UE? 52
3.2 How are the UE Measurements reported? 53
3.3 UE Measurements Usage 54
3.4 UE Triggered Events 55
3.5 eNB Mobility Software Architecture 56
3.6 UE Mobility State Diagram 57
3.7 CS Fallback Trigger 59
3.8 RRC Measurements 3GPP Object Model 60
3.9 RRC Measurements ALU Object Model 61
3.9.1 Example 62
3.9.2 measurementPurpose 63
3.10 General Diagram of an Event-triggered Measurement 64
3.10.1 reportConfig Common Parameters for all Events 65
3.10.2 measObject Common Parameters for all Events 66
3.11 Event A1 Triggering Conditions 67
3.11.1 Event A1 Diagram 68
3.16 Event B1 Triggering Conditions 77

Page
3.16.1 Event B1 Diagram 78

3.17 Event B2 Triggering Conditions 79
3.17.1 Event B2 Diagram 80
3.18 Mobility Measurements Parameters Enhancements 84
3.18.1 Simultaneous RSRP and RSRQ Measurements 85
3.18.2 Per-QoS Class Offset to UE Meas. Conf. Thresh. 86
3.18.3 UE Consecutive Measurements Configuration 91
4 Evolved Multi-Carrier Traffic Allocation (eMCTA) 94
4.1 eMCTA Overview 95
4.1.1 eMCTA Principle 96
4.2 eMCTA role among other eNB processes 97
4.3 Focus on eMCTA Process 98
4.4 eMCTA Filters 99
4.5 Object Model for eMCTA 100
4.5.1 MobilityPriorityTable 101
4.5.2 RAT/ carriers Configuration Rules 104
4.6 Measurements Gap Patterns 105
4.7 RRC Measurement Configuration Function 106
4.7.1 Truncation of RAT/carriers List 107
4.8 Use case: Serving Cell Event A2 Coverage Alarm Trigger 108
4.8.1 Matching the Inter-freq/RAT Neighbors 109
4.8.2 UE Capability Filter 110
4.8.3 Mobility Path Information Filter 111
4.8.4 Network Capability Filter 113
4.8.5 QCI-based Policy Filter 114
4.8.6 Frequency Load Filter 115
4.8.7 Example 116
4.9 Use case: Serving Cell Event A2 Floor Alarm Trigger 119
4.9.1 Summary of eMCTA and RRC MCF activities 120
4.10 Use case: Circuit-Switched Fallback Trigger 121
4.10.1 Matching the RAT/ Carriers Neighbors 122
4.10.3 Mobility Path Information Filter 124
4.10.4 Network Capability Filter 125
4.10.5 Service-based Filter 126
4.10.6 Frequency Load Filter 127
4.10.7 Example 128
4.11 Use case: Reactive Load Control 131
4.11.1 Reactive Load Control process in eNB 132
4.11.2 Matching the Inter-freq/RAT Neighbors 133
4.11.4 Other Filters 135
4.12 Use case: Preventive Load Control 138
4.13 Use Case: Load Equalization 142
4.14 Use case: ANR inter RAT/Carriers 143
5 Mobility Procedures (data flows) 145
5.1 Intra LTE Mobility (intra and inter-freq) 146
5.1.1 Introduction 147
5.1.2 Intra eNB Mobility 148
5.1.2.1 Intra eNB Mobility Data Flow 149
5.1.2.2 Intra eNB Mobility Parameters 151
5.1.2.3 Intra eNB Mobility with Carrier Aggregation 152
5.1.3 Inter eNB Mobility 153
5.1.3.1 Inter eNB Mobility over X2 interface 154
5.1.3.2 Inter eNB Mobility over S1 interface 158
5.1.3.3 Mobility Enhancement for Reserved Cells 163
5.1.3.4 CCM Overload and Mobility 164
5.1.3.5 FDD<>TDD Intra LTE Mobility 165
5.1.3.6 LTE Macro/Metro to HeNB Cell Mobility 167
5.1.3.7 Neighbor Cells Classification 173
5.1.3.8 Inter eNB Mobility with Carrier Aggregation 175

Page
5.2 LTE to UTRAN Mobility 182
5.2.2 LTE to UTRA Redirection 184
5.2.3 LTE to UTRA PS Handover 186
5.2.4 LTE to UTRA FDD HNB Cell Mobility 190
5.2.4.1 Mobility Procedures 191
5.2.4.2 Object Model 193
5.3 LTE to GERAN Mobility 196
5.3.2 Cell Change Order 198
5.4 LTE to HRPD Mobility 199
5.4.1 LTE to HDRP mobility - Redirection 200
5.5 CS Fallback 201
5.5.2 CS Fallback Activation 203
5.5.4 Enhanced CSFB, Redirection and PS HO 204
5.5.5 CS Fallback to UTRAN 205
5.5.6 CS Fallback to GERAN 207
5.5.7 RIM Procedure for UTRAN 209
5.5.7.1 System Information Transfer Initiation 211
5.5.7.2 System Information Update 213
5.5.7.3 System Information Update Stop 214
5.5.7.4 System Information Update End 215
5.5.8 RIM Procedure for GERAN 216
5.5.8.1 System Information Transfer Initiation 217
5.5.9 CSFB Procedure 219
5.5.9.1 CSFB Triggered By an Idle UE 221
5.5.9.2 CSFB Triggered By a Connected UE 222
5.5.9.3 CSFB to UTRA by PS Handover 223
5.5.9.4 CSFB to GERAN by Cell Change Order 225
5.5.9.5 CSFB to UTRAN/GERAN with Redirection 226
5.5.10 GERAN Dual Transfer Mode Capability 230
5.5.11 CSFB to 1xRTT 231
5.5.12 1xRTT Pre-registration 232
5.5.13 Authentication Challenge Parameters 233
5.5.14 SFBParametersResponseCDMA2000 234
5.5.16 CDMA2000ReferenceCellID Parameters 236
5.5.17 SIB8 Parameters for 1xRTT CSFB 237
5.5.18 SIB8 Parameters for 1xRTT Neighbors 239
5.5.19 SIB8 Parameters for 1xRTT Access Barring 240
5.5.20 Measurements for 1xRTT Configuration Model 241
5.5.21 1xRTT Measurements 242
5.5.22 1xCSFB Procedure Selection 244
5.5.23 Release 8 1xCSFB Procedure 245
5.5.24 Enhanced 1xCSFB Procedure 247
5.5.25 Dual Rx 1xCSFB 248
5.6 SRVCC Support to UTRA FDD/TDD 250
5.6.2 PS Handover versus SRVCC 253
5.6.3 SRVCC to UTRA FDD/TDD 254
5.7 Reverse Link Failure Monitoring 259
5.7.2 Handover too Early 261
5.7.3 Handover too Late 262
5.7.4 Handover to Wrong Cell 263

Mobility control in RRC_IDLE is UE-controlled (cell-reselection), while in RRC_CONNECTED it is controlled by the
E-UTRAN (handover).
If a UE were to access a cell which does not have the best radio link quality of the available cells on a given
frequency, it may create significant interference to the other cells. Hence, as for most technologies, radio link
quality (RSRP+RSRQ) is the primary criterion for selecting a cell on an LTE frequency.
When choosing between cells on different frequencies or RATs the interference concern does not apply. Hence,
for inter-frequency and inter-RAT cell reselection other criteria may be considered such as UE capability,
subscriber type and call type (this is managed by our eMCTA). As an example, UEs with no (or limited) capability
for data transmission may be preferably handled on GSM, while home customers or ‘premium subscribers’ might
be given preferential access to the frequency or RAT supporting the highest data rates. Furthermore, in some
LTE deployment scenarios, voice services may initially be provided by a legacy RAT only (as a Circuit-switched
(CS) application), in which case the UE needs to be moved to the legacy RAT upon establishing a voice call (also
referred to as CS fallback).
E-UTRAN provides a list of neighbouring frequencies and cells which the UE should consider for cell reselection
and for reporting of measurements. In general, such a list is referred to as a white-list if the UE is to consider
only the listed frequencies or cells – i.e. other frequencies or cells are not available; conversely, in the case of a
black-list being provided, a UE may consider any unlisted frequencies or cells. In LTE, white-listing is used to
indicate all the neighbouring frequencies of each RAT that the UE is to consider. On the other hand, E-UTRAN is
not required to indicate all the neighbouring cells that the UE shall consider. Which cells the UE is required to
detect by itself depends on the UE state as well as on the RAT.

When the UE is switched on, it selects a PLMN (details in next slide) and then performs cell selection – i.e. it searches for a suitable cell on
which to camp. Cell selection consists of the UE searching for the strongest cell on all supported carrier frequencies of each supported RAT
until it finds a suitable one.
The DL synchronization signals are sent to facilitate the cell search procedure, during which process the time and frequency synchronization
between the UE and the eNodeB is achieved and the cell ID is obtained. There are 168 cell-ID groups and 3 cell-ID index within a group
(total of 504=3*168 physical Cell-ID with cell-ID=3*cell-ID-group + cell-ID-index). There is a primary and a secondary synchronization
signals.
the primary SS identify the symbol timing and the cell-ID index={0,1 or 2}
the secondary SS identify the frame timing and the cell-ID-group={0 to 168}
While camping on the chosen cell, the UE acquires the system information that is broadcast. Subsequently, the UE registers its presence in
the tracking area, after which it can receive paging information which is used to notify UEs of incoming calls. The UE establishes an RRC
connection for attaching to the network, for example to establish a call or to perform a tracking area update.
When camped on a cell, the UE regularly verifies if there is a better cell; this is known as performing cell reselection.
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).
LTE cells are classified according to the service level the UE obtains on them: a suitable cell is a cell on which the UE obtains normal service.
If the UE is unable to find a suitable cell, but manages to camp on a cell belonging to another PLMN, the cell is said to be an acceptable cell,
and the UE enters a ‘limited service’ state in which it can only perform emergency calls – as is also the case when no USIM is present in the
UE. Finally, some cells may indicate via their system information that they are barred or reserved; a UE can obtain no service on such a cell.
A category called ‘operator service’ is also supported in LTE, which provides normal service but is applicable only for UEs with special access
rights.

System information is structured by means of System Information Blocks (SIBs), each of which contains a set of
functionally-related parameters. The SIB types that have been defined include:
The Master Information Block (MIB), which includes a limited number of the most frequently transmitted
parameters which are essential for a UE’s initial access to the network.
System Information Block Type 1 (SIB1), which contains parameters needed to determine if a cell is suitable
for cell selection, as well as information about the time domain scheduling of the other SIBs.
System Information Block Type 2 (SIB2), which includes common and shared channels information.
SIB3–SIB8, which include parameters used to control intra-frequency, inter-frequency and inter-RAT cell
reselection (SIB4 for eUTRA intrafreq, SIB5 for EUTRA interfreq, SIB6 for UTRA, SIB7 for GERAN and SIB8
for HRPD)
Three types of RRC message are used to transfer system information: the MIB message, the SIB1 message and
System Information (SI) messages.
SIB1/2/3 are mandatorily broadcasted in the cell, otherwise the cell state is set to disabled/failed.
SIB4 is supported in (T)LA4.0 and is used to:
broadcast qOffsetCell parameter (per neighbor cell) for LTE intra-frequency cell reselection (used during the
ranking process)
list the intra-frequency black-listed cells

The priority is provided per frequency (and not per cell) and is used for cell reselection. Note that the radio link
quality (per cell) is also measured by the UE to be able to perform cell reselection.
HRPD is 3GPP2 High Rate Packet Data (HRPD) and 1xRTT is cdma2000 1x Radio Transmission Technology.
1xRTT is referred to as 2.5G network and HRPD (or EV-DO) as 3G network. EV-DO provides data rates over 10
times faster than 1xRTT, the previous data technology for CDMA networks. Unlike other "1x" standards, EV-DO
only addresses data - not voice. It requires a dedicated slice of spectrum, separate from voice networks using
standards such as 1xRTT. There are currently two main versions of 1xEV-DO: "Release 0" and "Revision A".
Cell Reselection towards 1xRTT is a new LA4.0 feature (L76499)
LPUG recommendation (for LTE/UMTS/GERAN network):
The value 5 for cellReselectionPriority should be good.
With this value, we can build the following priority ranking cells:
LTE cells with the highest priority: 5
UMTS cells with a priority less high: 3 for example
GERAN cells with lowest priority: 2 for example

Support of SIB4 is in Features TLA3.0 103792, LA3.0 104002
E-UTRAN provides a list of neighbouring frequencies and cells which the UE should consider for cell reselection
and for reporting of measurements. In general, such a list is referred to as a white-list if the UE is to consider
only the listed frequencies or cells – i.e. other frequencies or cells are not available; conversely, in the case of a
black-list being provided, a UE may consider any unlisted frequencies or cells. In LTE, white-listing is used to
indicate all the neighbouring frequencies of each RAT that the UE is to consider. On the other hand, E-UTRAN is
not required to indicate all the neighbouring cells that the UE shall consider. Which cells the UE is required to
detect by itself depends on the UE state as well as on the RAT. Note that for GERAN, typically no information is
provided about individual cells. Only in specific cases, such as at country borders, is signalling provided to
indicate the group of cells that the UE is to consider – i.e. a white cell list.
BlackCellList is computed in IDLE mode for reselection (SIB4 for intrafreq, SIB5 for interfreq, SIB6/7/8 for
UTRAN/GERAN/HRPD) or in CONNECTED mode for measurements configuration used for handover and
redirection. BlackCellList can be used to list the black cells with parameters start and range.
Another way to list the black cells is to have parameter noHoOrReselection=‘True’ under the
LteNeighboringCellRelation MOI.
When a neighbor cell is defined for reselection, at least one instance of LteNeighboringCellRelation is created
containing mandatory parameters for cell reselection (qOffsetCell).
SIB IE ‘interFreqNeighCellList’ contains the neighboring cells that have attribute qOffsetCell set as non-zero, and
noHoOrReselection set as FALSE.
Notice that if more than 16 neighboring cells have to be defined in SIB4, only the 16 neighboring cells with the
highest absolute qOffsetCell are selected.

Refer to 3GPP ts 36.304 chapter 4.2 Functional division between AS and NAS in Idle mode and in ts 123.122
The MS in automatic mode has in its SIM card an ordered list of PLMN. The first one is the one matching the MCC+MNC
of the IMSI card. The next ones are the equivalent PLMNS. The first one is used at MS switch on for cell selection
if the MS does not find any suitable cell for selection (among the list of PLMN in its SIM card), it will search any cell with
any PLMN and receive a limited service (emergency)
the eNB forwards in SIB1 the primary PLMN as well as the equivalent PLMNs (an equivalent PLMN is a PLMN for which
the MS can perform cell reselection or HO in the same manner as with the primary PLMN)
A list a permitted and forbidden PLMN can be provided by the NAS level. During a roaming, the MS will look for the best
cell with its PLMN and do a TA update and know in return whether this PLMN is permitted or not.

LTE Reference Signal Received Power (RSRP)
The RSRP measurement provides a cell-specific signal strength metric. This measurement is used mainly to rank
different LTE candidate cells according to their signal strength and is used as an input for handover and cell
reselection decisions. RSRP is defined for a specific cell as the linear average over the power contributions (in
Watts) of the Resource Elements (REs) which carry cell-specific RS within the considered measurement
frequency bandwidth. Normally the RS transmitted on the first antenna port are used for RSRP determination,
but the RS on the second antenna port can also be used if the UE can determine that they are being
transmitted. If receive diversity is in use by the UE, the reported value is the linear average of the power values
of all diversity branches.
LTE Carrier Received Signal Strength Indicator (RSSI)
The LTE carrier RSSI is defined as the total received wideband power observed by the UE from all sources,
including co-channel serving and non-serving cells, adjacent channel interference and thermal noise within the
measurement bandwidth specified in 3GPP 36.133. LTE carrier RSSI is not reported as a measurement in its own
right, but is used as an input to the LTE RSRQ measurement described below.
LTE Reference Signal Received Quality (RSRQ)
This measurement is intended to provide a cell-specific signal quality metric. Similarly to RSRP, this metric is
used mainly to rank different LTE candidate cells according to their signal quality. This measurement is used as
an input for handover and cell reselection decisions, for example in scenarios for which RSRP measurements do
not provide sufficient information to perform reliable mobility decisions. The RSRQ is defined as the ratio N x
RSRP/(LTE carrier RSSI), where N is the number of Resource Blocks (RBs) of the LTE carrier RSSI measurement
bandwidth. The measurements in the numerator and denominator are made over the same set of resource
blocks. While RSRP is an indicator of the wanted signal strength, RSRQ additionally takes the interference level
into account due to the inclusion of RSSI. RSRQ therefore enables the combined effect of signal strength and
interference to be reported in an efficient way.

Features (T)LA3.0: 96760 and 108283 and feature LA4.0 114644
Cell selection consists of the UE searching for the strongest cell on all supported carrier frequencies of each supported RAT
until it finds a suitable cell. The main requirement for cell selection is that it should not take too long, which becomes more
challenging with the ever increasing number of frequencies and RATs to be searched. The NAS can speed up the search
process by indicating the RATs associated with the selected PLMN. In addition, the UE may use information stored from a
previous access.
The cell selection criterion is known as the S-criterion and is fulfilled when the cell selection receive level value Srxlev > 0 dB,
where:
Srxlev = Qrxlevmeas − (Qrxlevmin + Qrxlevminoffset) -Pcompensation
in which Qrxlevmeas is the measured cell receive level value, also known as the RSRP, and Qrxlevmin is the minimum
required receive level in the cell. Qrxlevminoffset is an offset which may be configured to prevent ping-pong between PLMNs,
which may otherwise occur due to fluctuating radio conditions. The offset is taken into account only when performing a
periodic search for a higher priority PLMN while camped on a suitable cell in a visited PLMN. Pcompensation can be used to
penalize low power UE.
The cell selection related parameters are broadcast within the SIB1 message.
For some specific cases, additional requirements are defined:
Upon leaving connected mode, the UE should normally attempt to select the cell to which it was connected. However,
the connection release message may include information directing the UE to search for a cell on a particular frequency.
When performing ‘any cell selection’, the UE tries to find an acceptable cell of any PLMN by searching all supported
frequencies on all supported RATs. The UE may stop searching upon finding a cell that meets the ‘high quality’ criterion
applicable for that RAT.
Note that the UE only verifies the suitability of the strongest cell on a given frequency. In order to avoid the UE needing to
acquire system information from a candidate cell that does not meet the S-criterion, suitability information is provided for
inter-RAT neighbouring cells.
Remarks:
S-Criterion is valid for LTE intra/inter freq (re)selection as well as reselection towards GERAN and HRPD. For reselection
towards UTRA and LTE, an other item (Squal) is added. If this item is missing in SIB3, only Srxlev will be considered
Pcompensation and Qrxlevminoffset are not used in (T)LA3.0

pCompensation is recommended to be set to zero for LTE (pMax= puMax= 23dBm)
qQualMin is not for UTRAN TDD
qRxLevMin and qRxLevMinOffset are not used for HRPD/1xRTT. S criteria can be written for HRPD/1xRTT as:
sNonServingCell >0 with sNonServingCell= -FLOOR (-20 x log10Ec/Io) in the unit of 0.5 dB. Ec/Io is the value
measured from the evaluated cell.

Hardcoded puMax values in LA4.0

qRxLevMin is a key optimization parameter to optimize the cell coverage in Idle mode.
Example: SIB6 broadcasted by the serving cell provides the list of UTRAN neighbor cells that the UE has to
monitor with for each the value of qRxLevMin. A UTRAN cell can be selected for cell selection (or reselection) if
the S-criteria is True.

Once the UE camps on a suitable cell, it starts cell reselection. This process aims to move the UE to the ‘best’ cell
of the selected PLMN and of its equivalent PLMNs, if any. The cell reselection between frequencies and RATs is
primarily based on absolute priorities. Hence, the UE first evaluates the frequencies of all RATs based on their
priorities (cell-specific default values of the priorities are provided via System Information, from 0 to 7).
Secondly, the UE compares the cells on the relevant frequencies based on radio link quality, using a ranking
criterion. Finally, upon reselecting to the target cell the UE verifies the cell’s accessibility. Further rules have also
been defined to allow the UE to limit the frequencies to be measured, to speed up the process and save battery
power.
The figure provides a high-level overview of the cell reselection procedure.
It should be noted that the UE performs cell reselection only after having camped for at least one second on the
current serving cell.

Paging principle (recall). UE in Idle mode monitors the PDCCH channel. The P-RNTI is used to scramble the
CRC of the Paging message. The UE needs only to monitor the PDCCH at certain UE-specific occasions (ie
specific subframes in specific radio frames). At other times, the UE may apply DRX, meaning that it can switch
off its receiver to preserve battery power. The Paging Frame (PF) refers to the radio frame and the Paging
Occasion refers to the subframe(s) in which the E-UTRAN can page the UE.
Paging reception. The UE determines the paging Discontinuous Reception (DRX) cycle and other relevant
paging parameters by processing the serving cell paging parameters broadcast by the serving cell. From this
point, and unless a UE is being paged or cell reselection occurs, the UE will periodically wake up on every paging
occasion to check for paging messages; at the same time, the UE can measure its serving cell quality. When the
LTE serving cell signal quality is poor (e.g. below a certain RSRP threshold) the UE risks losing service on the
serving cell, and it must attempt to identify and reselect a new suitable cell. Therefore, all possible networks
need to be searched and measured regardless of their relative priority, and the UE must camp on the highest
priority network which can be detected and meets the suitability criteria. Given that the serving cell quality is
poor and the risk of losing service is high, the search rate will be frequent (i.e. a small multiple of the paging
DRX period). If the serving cell quality is good enough, according to the S-criterion, then searching for lower
priority layers does not need to be performed. The UE still needs to search for cells in higher priority layers at a
reduced rate compared to the previous case and the UE must reselect a higher priority cell if it meets the cell
reselection criteria. Given that the quality of the received signal from the current serving cell is good and the UE
can be reached, the search rate can be far less frequent in order to reduce UE power consumption (typical
values under consideration are in the order of 60 s).
Cell reselection evaluation. On every paging occasion the cell reselection criterion is evaluated. If a
neighbour cell currently being measured meets the cell reselection criterion then cell reselection towards that cell
is initiated and the UE restarts the process named cell-specific configuration on the new cell.
Remark: details on the thresholds (‘poor’ and ‘good enough’) will be provided in the next slides.

Features (FDD+TDD) 96760 (LA3.0) and 114644 (LA4.0)
To enable the UE to save battery power, rules have been defined which limit the measurements the UE is
required to perform.
Firstly, the UE is required to perform intra-frequency measurements only when the quality of the serving cell is
below or equal to a threshold (‘SintraSearch’).
Furthermore, the UE is required to measure other frequencies/RATs of lower or equal priority only when the
quality of the serving cell is below or equal to another threshold (‘SnonintraSearch’).
The UE is always required to measure frequencies and RATs of higher priority.
The required performance (i.e. how often the UE is expected to make the measurements, and to what extent
this depends on, for example, the serving cell quality) is specified in 3GPP 36.133.
SintraSearch and SnonintraSearch are provided in SIB3.
The formula for intra frequency becomes:

Srxlev = Qrxlevmeas – ( Qrxlevmin + Qrxlevminoffset) – Pcompensation <= SintraSearch, or
RSRP <= Qrxlevmin + SintraSearch
Increasing sIntraSearch value will make UE to start intra-frequency neighbor search earlier.
The default value of SintraSearch is 62dB (the highest possible value)
SnonintraSearch default value is also 62dB.

Feature LA4.0 114644

E-UTRAN configures an absolute priority for all applicable frequencies of each RAT. In addition to the cell-specific
priorities which are optionally provided via system information, E-UTRAN can assign UE-specific priorities via
dedicated signalling. Of the frequencies that are indicated in the system information, the UE is expected to
consider for cell reselection only those for which it has priorities. Equal priorities are not applicable for inter-RAT
cell reselection.
The UE reselects to a cell on a higher priority frequency if the S-criterion of the concerned target cell exceeds a
high threshold (Threshx-high) for longer than a certain duration Treselection. The UE reselects to a cell on a
lower-priority frequency if the S-criterion of the serving cell is below a low threshold (ThreshServing-Low) while
the S-criterion of the target cell on a lower-priority frequency (possibly on another RAT) exceeds a low threshold
(Threshx-low) during the time interval Treselection, while no cell on a higher-priority frequency is available.
The Figure illustrates the condition(s) to be met for reselecting to a cell on a higher-priority frequency (red bar)
and to a cell on a lower priority frequency (violet bars).
When reselecting to a frequency, possibly on another RAT, which has a different priority, the UE reselects to the
highest-ranked cell on the frequency concerned.
Note that thresholds and priorities are configured per frequency, while Treselection is configured per RAT.
From Release-8 onwards, UMTS and GERAN support the same priority-based cell reselection as provided in LTE,
with a priority per frequency. Release-8 radio access networks will continue to handle legacy UEs by means of
offset-based ranking. Likewise, Release-8 UEs should apply the ranking based on radio link quality (with offsets)
unless UMTS or GERAN indicate support for priority-based reselection.
Remark: reselection towards higher priority frequency cells can be done whatever the level of Srxlev (serving
cell)

The value of s(Non)IntraSearch sent over the RRC interface is half the value configured and the UE then
multiplies the received value by 2.
If the field sIntraSearch is not present in SIB3, the UE takes an infinite value.
The two thresholds: threshXHigh / threshXLow as well as the priorities are provided per frequency while
tReselection is per RAT.

The value of s(Non)IntraSearch(P or Q) sent over the RRC interface is half the value configured and the UE then
multiplies the received value by 2.
If the field sIntraSearchP is not present, the UE takes an infinite value. If the field sIntraSearchQ is not present,
the UE takes 0dB.
The two thresholds: threshXHigh / threshXLow as well as the priorities are provided per frequency while
tReselection is per RAT.
threshXLowQ and threshXHighQ are not for UtranTDD.

Features (FDD+TDD): 96760, 108283, 103792
The UE ranks the intra-frequency cells and the cells on other frequencies having equal priority which fulfill the S-
criterion using a criterion known as the R-criterion. The R-criterion generates rankings Rs and Rn for the serving
cell and neighbour cells respectively:
For the serving cell: Rs = Qmeas,s + Qhyst,s
For neighbour cells: Rn = Qmeas,n + Qoff s,n
where Qmeas is the measured cell received quality (RSRP), Qhyst,s is a parameter controlling the degree of
hysteresis for the ranking, and Qoff s,n is an offset applicable between serving and neighbouring cells on
frequencies of equal priority (the sum of the cell-specific and frequency-specific offsets).
The UE reselects to the highest-ranked candidate cell provided that it is better ranked than the serving cell for at
least the duration of Treselection. The UE scales the parameters Treselection and Qhyst, depending on the UE
speed.
Current value of qHyst is 2dB. According to this value, the cell-reselection should be made with a neighboring
cell at RSRP > -88dBm considering: qRxLevMin (seen by the UE) =-100dBm, sIntraSearch=10dB, intra-
frequency mobility. Decreasing qHyst leads to do cell reselection earlier.

Cell2 becomes better than the Serving cell when Rn>Rs, i.e. RSRPn-qHyst>RSRPs+Qoffset

The neighbor cell is the best ranked cell for LTE intrafreq or interfreq towards a freq of same priority as the
serving frequency; for inter-freq/RAT of different priority than the serving, it is the best cell of the highest
frequency.
UTRA stands here for UTRA FDD or UTRA TDD.
CDMA stands here for CDMA 1xRTT or CDMA HRPD.
The other RATs cannot have the same priority as the serving (3GPP rule).

The assumption here is that threshXHighQ, thresXLowQ and thresServingLowQ are provided in SIB3. If not, the
algorithms for UE R8 capable are applicable. Notice that Qmeas= RSRP.

The assumption here is that thresServingLowQ are provided in SIB3. If not, the algorithms for UE R8 capable are
applicable.
CDMA stands here for CDMA 1xRTT or CDMA HRPD.

Assumption: Srxlev > 0 and Squal > 0 (for UTRAN Cell)
1- RSRP Serving decreases under (qRxLevMin + qRxLevMinOffset + pCompensation + sNonIntraSearchP): UE is
required to perform inter-freq/RATs measurements of equal or lower priority
2- RSRP Serving under thresServingLow but there is still no UTRAN candidate CPICH RSCP over threshXLow
3- An UTRAN candidate cell CPICH RSCP is over threshXLow and tReselectionUtra is started
4- The target UTRAN cell is selected for redirection

Assumption: Srxlev > 0 and Squal > 0 (for UTRAN Cell)
1- RSRQ Serving decreases under (qQualMin + qQualMinOffset + sNonIntraSearchQ): UE is required to perform
inter-freq/RATs measurements of equal or lower priority
2- RSRQ Serving under thresServingLowQ but there is still no UTRAN candidate CPICH Ec/N0 over threshXLowQ
3- An UTRAN candidate cell CPICH Ec/N0 is over threshXLowQ and tReselectionUtra is started
4- The target UTRAN cell is selected for redirection

The table is defined by 3GPP 36.133.
Default DRX cycle length=1.28sec.
The assumption is Srxqual > sIntraSearchQ.
When SrxLev > sIntraSearchP, the UE will only monitor higher priority carrier/RATs every
Tdetect,EUTRAN_intra=32sec.
When SrxLev <= sIntraSearchP, the UE will monitor intrafreq neighbor cells every Tmeasure,EUTRAN_intra=
1.28sec.
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
The same type of graph is applicable with the quality (sIntraSearchQ).
Other values of these timers are defined by 3GPP for UTRAN, GERAN, HRPD.

The priority is provided per frequency. Range 0 to 7 with 0 being the lowest priority.
Equal priorities are not applicable between frequencies of different RATs.

High and Low mobility UEs are distinguished thanks to the rate of Cell Reselection.
The UE scales the cell reselection parameters depending on its speed. This applies both in idle mode
(Treselection and Qhyst) and in connected mode (timeToTrigger). The UE speed is categorized by a mobility
state (high, medium and normal), which the UE determines based on the number of cell reselections/handovers
which occur within a defined period, excluding consecutive reselections/handovers between the same two cells.
The state is determined by comparing the count with thresholds for medium and high state, while applying some
hysteresis. For idle and connected modes, separate sets of control parameters are used, signalled in SIB3 and
within the measurement configuration respectively.

Feature (FDD+TDD):108283
The objective is to penalize the camping to micro cells for medium/high speed vehicule in order to force a
reselection towards a macro cell (larger and thus requiring less reselections)

Accessibility Verification
If the best cell on an LTE frequency is barred or reserved, the UE is required to exclude this cell from the list of cell reselection candidates.
In this case, the UE may consider other cells on the same frequency unless the barred cell indicates (by means of a broadcast bit in the SI)
that intra-frequency reselection is not allowed for a certain duration (except for Closed Subscriber Group (CSG) cells). If, however, the best
cell is unsuitable for some other specific reason (e.g. because it belongs to a forbidden tracking area or to another non-equivalent PLMN),
the UE is not permitted to consider any cell on the concerned frequency as a cell reselection candidate for a maximum of 300 s.
Cell Access Restrictions
Access barring is performed during connection establishment and provides a means to control the load introduced by UE-originated traffic.
There are separate means for controlling Mobile Originated (MO) calls and MO signalling. Each UE belongs to an Access Class (AC) in the
range 0–9. In addition, some Ues may belong to one or more high-priority ACs in the range 11–15, which are reserved for specific uses (e.g.
security services, public utilities, emergency services, PLMN staff). AC10 is used for emergency access. The UE considers access to be
barred if access is barred for all its applicable Acs. SIB2 may include a set of AC barring parameters for MO calls and/or MO signalling. This
set of parameters comprises a probability factor and a barring timer for AC0–9 and a list of barring bits for AC11–15. For AC0–9, if the UE
initiates a MO call and the relevant AC barring parameters are included, the UE draws a random number. If this number exceeds the
probability factor, access is not barred. Otherwise access is barred for a duration which is randomly selected centred on the broadcast
barring timer value. For AC11–15, if the UE initiates a MO call and the relevant AC barring parameters are included, access is barred
whenever the bit corresponding to all of the UE’s ACs is set. The behaviour is similar in the case of UE-initiated MO signalling.
For cell (re)selection, the UE is expected to consider cells which are neither barred nor reserved for operator or future use. In addition, a UE
with an access class in the range 11–15 shall consider a cell that is (only) reserved for operator use and part of its home PLMN (or an
equivalent) as a candidate for cell reselection. The UE is not even allowed to perform emergency access on a cell which is not considered to
be a candidate for cell reselection.
Any Cell Selection
When the UE is unable to find a suitable cell of the selected PLMN, it performs ‘any cell selection’. In this case, the UE performs normal idle
mode operation: monitoring paging, acquiring system information, performing cell reselection. In addition, the UE regularly attempts to find
a suitable cell on other frequencies or RATs (i.e. not listed in system information). The UE is not allowed to receive MBMS in this state.
Closed Subscriber Group
LTE supports the existence of cells which are accessible only for a limited set of UEs – a Closed Subscriber Group (CSG). In order to prevent
UEs from attempting to register on a CSG cell on which they do not have access, the UE maintains a CSG white list, i.e. a list of CSG
identities for which access has been granted to the UE. The CSG white list can be transferred to the UE by upper layers, or updated upon
successful access of a CSG cell. To facilitate the latter, UEs support ‘manual selection’ of CSG cells which are not in the CSG white list. The
manual selection may be requested by the upper layers, based on a text string broadcast by the cell.

LA5.0 FRS 115203 (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.
FRS 115203 supports up to 3 instances of CellReselectionAdaptation MO.

The four PRB consumption measurements (% PRB consumption in UL/DL per cell and per eNB) are originally
used by CAC in the eNB modem (since LA3.0) with measurement interval determined by
radioCacCell::periodMeasForPRBConsumption . 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.
Note that autoReselectMinInter must be a multiple k of periodMeasForPRBConsumption
PRB consumption i is the DL or UL PRB consumption per cell or per eNB in the ith period of
periodMeasForPRBConsumption (4 in total)

(feature LA5.0 L110762). It is only performed when the flag isUnlimitedPRBLicenseAllowed is set to “False” with
the bCEM card. When this flag is set to “True”, full carrier bandwidth is allocated to each cell on each supported
band. When isUnlimitedPRBLicenseAllowed = ‘False’, the PRB resources cannot be counted per cell but per band
per eNB.
The weights defined by the operator are based on which one is the bottleneck. For instance, if the bottleneck is the DL PRB consumption
per cell, weightDlPrbCell can have a value higher than 1.

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.

The delta value should be adjust in order parameter + delta remains in the range of the parameter values

TLA3.0 : LTE to UTRA TDD cell reselection only
LA4.0: LTE to UTRA FDD cell reselection only

RRC_Connected mode

Same measurements in RRC_Connected mode as in RRC Idle mode

Two different types of measurement reporting are specified in LTE:
Periodic reporting. Measurement reports are configured to be reported periodically according to the
measurement configuration parameters.
Event-triggered measurement reporting. In order to limit the amount of signalling to be sent back to the
eNodeB the measurement reporting activity can be configured to trigger measurement reports given that
some conditions are met by the measurements performed by the UE. Typically, the reporting conditions
relate to criteria used by the network to start neighbour cell measurements or trigger the execution of
handovers due to poor cell coverage or poor service quality. Once an event has been met, the UE can be
configured to report additional measurement information which is unrelated to the event condition. This
information is used by the eNodeB RRM algorithms to determine the most adequate handover command.

eMCTA is used to have a list of candidate cells in case of inter-freq or inter-RAT mobility.
Major functions of RRM Measurement Process:
1. Configure/de-configure UE for RF monitoring measurement (good RF condition, coverage alarm or bad RF condition).
Triggered at connection setup or when UE measurement reports for RF monitoring received in 4 indicating UE RF
condition changes
2. Configure/de-configure UE for mobility measurement. Configure Intra-frequency mobility measurement at call setup,
configure inter-frequency or inter-RAT mobility measurements when measurement based mobility candidate list is
received in 11, de-configure inter-frequency or inter-RAT mobility measurement when UE returns to good RF condition
in 4
3. Configure UE for CS fallback measurement (highest priority candidate). Triggered when for CS fallback candidate list
is received in 13
4. UE measurement reports for RF monitoring received. Configure/de-configure for RF monitoring measurement in 1,
request measurement based mobility candidate list in 8 when UE enters coverage alarm, or request blind redirection
candidate list request in 9 when UE enters bad RF condition
5. UE measurement reports for mobility received. Triggers intra-freq, inter-freq, inter-RAT mobility in 14, or 15
6. UE measurement reports for CS fallback received. Triggers CS fallback in 17
7. CS fallback triggered received. Triggers CS fallback candidate list request in 10
8. Measurement based mobility candidate list request. Triggered when UE enters alarm coverage area in 4.
9. Blind redirection candidate list request. Triggered when UE enters bad RF condition in 4.
10. CS fallback candidate list request. Triggered when CS fall back trigger is received in 7
11. Measurement based mobility candidate list response. Triggered when measurement based mobility candidate list is
requested in 8
12. Blind redirection candidate list response. Triggered when blind redirection candidate list is requested in 9
13. CS fallback candidate list response. Triggered when CS fallback candidate list requested in 10
14. Intra-freq mobility request. Triggered when UE measurement report for intra-freq mobility is received in 5.
15. Inter-freq or inter-RAT mobility request. Triggered when UE measurement report for inter-freq, inter-RAT mobility is
received in 5.
16. Blind redirection request. Triggered when blind redirection candidate list is received in 11. Highest priority candidate is
used
17. CS fallback request. Triggered when UE measurement report for CS fallback is received in 6

At connection setup, RRC Measurement Process actions:
Configure UE for UE event A3 ‘Mobility-Intra-Freq’ measurement
Configure UE for event A2 ‘Entering-Coverage-Alarm’ measurement
Configure UE for event A2 ‘Below-Serving-Floor’ measurement
When UE is in good RF condition:
If event A3 ‘Mobility-Intra-Freq’ measurement report is received, intra-freq handover will be triggered through the Mobility Procedures
If Event A2 ‘Entering-Coverage-Alarm’ report is received, it indicates UE has entered coverage alarm condition
When UE enters coverage alarm condition, RRC Measurement Process will:
De-configure UE for event A2 ‘Entering-Coverage-Alarm’ measurement
Configure UE for event A1 ‘Leaving-Coverage-Alarm’ measurement
Request eMCTA-framework for inter-frequency and inter-RAT candidates for measurement based mobility
After RRC Measurement Process receives inter-frequency and inter-RAT candidate list for measurement based mobility from eMCTA-framework:
Configure UE for event A5/A3 ‘Mobility-Inter-Freq-EUTRA’ measurement if inter-freq neighbor is in the candidate list
Configure UE for event B2 ‘Mobility-Inter-RAT-to-UTRA’ measurement if UTRA neighbor is in the candidate list, and/or configure UE for event B2 ‘Mobility-
Inter-RAT-to-GERAN’ measurement if GERAN neighbor is in the candidate list. Or configure UE for event B2 ‘Mobility-Inter-RAT-to-HRPD’ measurement if
HRPD neighbor is in the candidate list
Note: Which RAT/carrier(s) are selected for UE measurements and total number of inter-freq, inter-RAT candidates to be configured for inter-frequency or inter-
RAT measurements are controlled by eMCTA-framework. HRPD will not co-exist with either UTRA or GERAN.
When UE is in coverage alarm RF condition:
If event A3 ‘Mobility-Intra-Freq’ report is received, intra-freq handover will be triggered through the Mobility Procedures
If event A5/A3 ‘Mobility-Inter-Freq-EUTRA’ report is received, inter-frequency handover will be triggered through the Mobility Procedures
If event B2 ‘Mobility-Inter-RAT’ report is received, inter-RAT mobility (EUTRA to UTRAN PS handover, EUTRA to GERAN CCO or EUTRA to HRPD
measurement based redirection) procedure will be triggered through the Mobility Procedures
When UE is in coverage alarm RF condition:
If event A1 ‘Leaving-Coverage-Alarm’ measurement report is received, it indicates UE moves back to good RF condition.
If event A2 ‘Below-Serving-Floor’ report is received, it indicates UE enters bad RF condition.
When UE moves back from coverage alarm RF condition to good RF condition, RRC Measurement Process will:
De-configure UE for event A1 ‘Leaving-Coverage-Alarm’ measurement
Configure UE for event A2 ‘Entering-Coverage-Alarm’ measurement
De-configure UE for event A5/A3 ‘Mobility-Inter-Freq-EUTRA’ measurement if is configured.
De-configure UE for event B2 ‘Mobility-Inter-RAT-to-UTRA’ measurement if configured, and/or de-configure UE for event B2 ‘Mobility-Inter-RAT-to-GERAN’
or event B2 ‘Mobility-Inter-RAT-to-HRPD measurement if configured.
When UE enters bad RF condition, RRC Measurement Process will request blind redirection candidates from eMCTA-framework. Blind redirection will then be
triggered to the best RAT/carrier candidate through Mobility Procedures.

When RRC Measurement Process receives CS fallback trigger from MME:
It will request eMCTA-framework for CS fallback candidate list
Upon receiving CS fallback candidates from eMCTA-framework, RRC Measurement Process will configure UE
to perform event B1 measurement to the highest priority CS fallback RAT/carrier
Once the UE measurement report is received, RRC Measurement Process triggers CS fallback through
Mobility Procedures

Measurement Configuration:
The E-UTRAN can configure the UE to report measurement information to support the control of UE mobility. The following
measurement configuration elements can be signalled via the RRCConnectionReconfiguration message.
1. Measurement objects. A measurement object defines on what the UE should perform the measurements – such as
a carrier frequency. The measurement object may include a list of cells to be considered (white-list or black-list) as
well as associated parameters, e.g. frequency- or cell-specific offsets.
2. Reporting configurations. A reporting configuration consists of the (periodic or event-triggered) criteria which cause
the UE to send a measurement report, as well as the details of what information the UE is expected to report (e.g.
the quantities, such as RSCP for UMTS or RSRPfor LTE, and the number of cells).
3. Measurement identities. These identify a measurement and define the applicable measurement object and
reporting configuration.
4. Quantity configurations. The quantity configuration defines the filtering to be used on each measurement.
5. Measurement gaps. Measurement gaps define time periods when no uplink or downlink transmissions will be
scheduled, so that the UE may perform the measurements. The measurement gaps are common for all gap-
assisted measurements.
The details of the above parameters depend on whether the measurement relates to an LTE, UMTS, GERAN or CDMA2000
frequency. The E-UTRAN configures only a single measurement object for a given frequency, but more than one
measurement identity may use the same measurement object. The identifiers used for the measurement object and
reporting configuration are unique across all measurement types. In LTE it is possible to configure the quantity which triggers
the report (RSCP or RSRP) for each reporting configuration. The UE may be configured to report either the trigger quantity
or both quantities.
Measurement Report Triggering:
Depending on the measurement type, the UE may measure and report any of the following:
The serving cell;
Listed cells (i.e. cells indicated as part of the measurement object);
Detected cells on a listed frequency (i.e. cells which are not listed cells but are detected by the UE).

In each cell, the UE measurements configuration is provided by the MO RrcMeasurementConf.
Each measurement is defined by one instance of the MO MeasurementIdentityConf.
Each instance of the MeasurementIdentityConf together with associated MOs ReportConfig and MeasObject
form a complete configuration of one RRC measurement configuration.
One instance of the MO MeasurementIdentityConf is 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
(RrcMeasurementConf).
ReportConfigCDMA2000 and MeasObjectCDMA2000 are used for LTE FDD only.

Role of measurementPurpose: we may have for instance several A3 events running in parallel in the UE for intra-
freq mobility and for ANR and the measurementPurpose text can be displayed at NPO interface in order to
discriminate (per MeasurementIdentityConf) the purpose of the measurement
Report-CGI:
DRX (Discontinuous Reception) can be configured for a UE in RRC connected state so that it stops monitoring
the downlink PDCCH channel during the DRX period. The main purpose of DRX is for the UEs to go the sleep (to
save battery) after a period of inactivity when no data was sent or received.
When a UE is configured to ‘Report-CGI’ (to find ECGI: E-UTRAN Cell Global Identifier of a neighbor cell),
however, eNB forces UE into DRX through the DRX Command in MAC control element. During the DRX period in
DRX cycle, the UE listens to the PBCH of the neighbor cell to receive its ECGI, TCA and PLMN ID.
When a UE is forced into DRX, it will cause transmission gap noticeable by the end user of a voice call or of any
other services required guarantee bit rate (GBR). For this reason, eNB A will direct a UE for ECGI search only if it
is capable to support the ‘reportCGI’ procedure, and it does not have on going GBR bearers. For the same
reason, DRX length defined drxCycleForReportCGI should be set just long enough for the UE to listen to PBCH of
the neighbor cell to find its ECGI.

The UE triggers an event when one or more cells meets a specified ‘entry condition’. The E-UTRAN can influence
the entry condition by setting the value of some configurable parameters used in these conditions – for example,
one or more thresholds, an offset, and/or a hysteresis. The entry condition must be met for at least a duration
corresponding to a ‘timeToTrigger’ parameter configured by the E-UTRAN in order for the event to be triggered.
The UE scales the timeToTrigger parameter depending on its speed.
The Figure above illustrates the triggering of event A3 when a timeToTrigger and an offset are configured.
The UE may be configured to provide a number of periodic reports after having triggered an event. This ‘event-
triggered periodic reporting’ is configured by means of parameters ‘reportAmount’ and ‘reportInterval’, which
specify respectively the number of periodic reports and the time period between them. If event-triggered
periodic reporting is configured, the UE’s count of the number of reports sent is reset to zero whenever a new
cell meets the entry condition. The same cell cannot then trigger a new set of periodic reports unless it first
meets a specified ‘leaving condition’.
In addition to event-triggered reporting, the UE may be configured to perform periodic measurement reporting.
In this case, the same parameters may be configured as for event-triggered reporting, except that the UE starts
reporting immediately rather than only after the occurrence of an event.

Features: 96760, 92079
Hysteresis:
For Event A3: Tests field trial are shown best results, with the value of ‘hysteresis’ set to 2.0dB regarding RSRP measurements (triggerQuantity set to RSRP), and
eventA3offset set to 0dB. This means the two entry/exit criteria are at 2dB and -2 dB which means once UE triggers A3 for a neighbor that is 2dB above serving
RSRP.
We recommend set ‘hysteresis’ to 7.5 regarding RSRQ measurements, (triggerQuantity set to RSRQ).
For Event A2: Tests field trial are shown best results with the value of ‘hysteresis’ set to 3.0dB regarding RSRP measurements (triggerQuantity set to RSRP)
We recommend set ‘hysteresis’ to 7.5dB regarding RSRQ measurements, (triggerQuantity set to RSRQ).
reportAmount:
For ‘Intra-Frequency-Handover-Trigger’ and ‘Inter-Frequency-Handover-Trigger’ Event A3 trigger, the recommended value of reportAmount is ‘8’ . The main
reason to set reportAmount to ‘8’ for ‘Intra-Frequency-Handover- Trigger’ is to increase the handover successful rate when the source cell or the target cell is
congested. In this case, multiple handover triggers may increase the chance for the handover request to go through. Also, according to standards eNB can not
send HO command until SecurityMode is completed. Setting reportAmount to ‘r8’ in this case will increase the chance for HO command to be sent.
For ‘Below-Serving-Floor’ trigger, the recommended value of reportAmount is ‘8’. The reason to set to ‘8’ for ‘Below-Serving-Floor’ trigger is similar to the reason
given above for ‘Intra-Frequency-Handover-Trigger’. Also, since ‘Below-Serving- Floor’ trigger has lower priority than ‘Intra-Frequency-Handover-Trigger’, event
A2 measurement report will be dropped in case eNB is processing event A3 LTE intra-frequency handover measurement report. Setting reportAmount to ‘8’ in
this case will increase the chance for the event A2 measurement report to be processed.
For ‘Automatic-Neighbor-Relation’ trigger, the value of the corresponding reportAmount should be set to ‘4’.
The reason to set the reportAmount to ‘4’ is that with ANR feature, one PCI measurement report will trigger one ‘Report-CGI’ request. Multiple ‘Report-CGI’
requests may increase the chance for a UE to find the ECGI corresponding to a PCI reported.
For ‘Report-CGI’ trigger, the value of the corresponding reportAmount must be set to ‘1’.
timeToTrigger:
timeToTrigger is 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
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 ‘Mobility-Intra- Freq’.
For ‘Report-CGI’ trigger, timeToTrigger is not used but must not be left unset.
maxReportCells:
For ‘Mobility-Intra-Freq’, the default value of the corresponding maxReportCells is set to ‘1’. Setting the parameter to a value greater than ‘1’ will not be useful in
LA3.0/TLA3.0. This is because in the current target cell selection algorithm, only the best neighbor cell will be considered as the handover target. The setting of
the parameter will need to be updated once more candidate cells are considered in handover target selection.
For ‘Automatic-Neighbor-Relation’ trigger, the value of the corresponding maxReportCells should be set to the maximum value of ‘8’. This is to ensure UE to
report as many new neighbor cells as possible in a short time.
For ‘Report-CGI’ trigger, maxReportCells is not used but must not be left unset.
triggerTypeEutran:
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’, the recommended setting for triggerTypeEUTRA is ‘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 measurementPurpose = ‘Report-CGI’, triggerTypeEUTRA should be set to ‘periodicalReportCGI’

dlEARFCN = 10 × ( f 0,DL - FDL_low ) + NOffs-DL, where FDL_low and Noffs-DL are some constants which
various with E-UTRA Band using for radio. DL f 0, is the central carrier frequency of the bandwidth.

Feature 92079, 81872, 103792

Thresh_leaving_alarm= Event A1 leaving condition (Ms > thresholdEutranRsrp + hysteresis)
Thresh_entering_alarm=Event A2 entering condition (Ms < thresholdEutraRsrp – hysteresis)
For Event A2, different thresholds are set in different ReportConfig instances according to the triggerTypeEutra
and measurementPurpose

Features 96760, 81872, 108283
Offset = eventA3Offset for intra-frequency measurements

Feature 92079, 81872, 103792

Feature 92079
treshold2EutraRsrp/Rsrq parameters are used in the entering and leaving inequalities for Event A5 if
triggerQuantity is set to RSRP or RSRQ. It is used for measurementPurpose = ‘Mobility-Inter-Freq-to-EUTRA’ or
measurementPurpose = ‘Automatic-Neighbor-Relation’. ForANR purpose, event A3 is recommended to the
customers as the measurement report trigger. Event A4 and A5 are proposed for testing and trial purpose only
for ANR in LA3.0/TLA3.0

Features 76498, 84807, 84876, 92079, 96372, 92025
measObjectCdma2000 is used only in FDD. CS fallback to 1xRTT is not currently supported in LA3.0
measObjectUtra is used to configure a measurement when the associated measurementPurpose is set to
Mobility-Inter-RAT-To-UTRA. One and only one measObjectUtra is configured per UTRA carrier frequency.
Idem for Geran and Cdma2000.
thresholdUtraRscp corresponds to CPICH_RSCP in TS 25.133 for FDD and to P-CCPCH_RSCP in TS 25.123 for
TDD.
thresholdUtraEcN0 corresponds to CPICH_Ec/No in TS 25.133 for FDD, and is not applicable for TDD.

LA5.0 FRS 115204 : Enhanced Measurement Parameter Support for Mobility)
Simultaneous RSRP and RSRQ measurements was supported for event A3 in LA4.0 and extended to Events
A1, A2, A5 and B2 in LA5.0
Per-QoS class offset to UE measurement configuration thresholds: this is the capability to add an offset to
the thresholds on measurement events (based on RSRP or RSRQ) per QoS class to allow different cell
coverages for calls of different QoS classes
Consecutive configurations of UE off-loading mobility measurements based on carrier priority: this is the
capability to ask the UE in case of offloading to perform measurements first on the highest priority carriers

Simultaneous RSRQ and RSRP is not supported by ANR because ANR is looking for neighbors and RSRP is
enough for that purpose.
Event B1 is triggered when inter-RAT neighbor cell is better than a threshold that is neither RSRP nor RSRP.

M-QoS is not a 3GPP wording. It stands here for Measurements QoS. Prefix ‘M’ is used to differenciate from QoS
class identifier (QCI).
TTI bundling : Four redundancy versions (RV) of one frame are sent by the UE and the eNodeB waits for the
four versions before sending an ACK/NACK. Consequently RSRP and RSRQ thresholds in case of TTI bundling
VoIP can be lower than in case of VoIP.
What is the interest of having different cell coverages per QoS class? There is for instance a request from
Verizon (US) to prefer one band/carrier for VoIP calls. Different coverages per QoS class may help that need.

Whenever a call’s M-QoS class is changed due to a bearer is setup or release, or when TTI bundling is activated
or deactivated and UE has been configured with any of the above mentioned event triggered measurements,
eNB will reconfigure the UE with the measurement thresholds adjusted by the new offsets.
ReportConfigEUTRA::triggerTypeEUTRA is set to the event (eventA1, eventA2 etc)

ReportConfigEUTRA::triggerQuantity is set to rsrp or rsrq
Non-GBR use the basic parameters (without offset). Other QoS class may add offset on top of the basic
parameter.
Event B1 CSFB is not concerned because in case of CSFB, the call is classified into non-GBR and not impacted by
the offset parameter

If the inter-frequency and/or inter-RAT mobility measurements are for the purpose of off-load, eNB may request
UE to monitor multiple RAT/carriers. Before the introduction of lowToMediumPriorityThrehold and
mediumToHighPriorityThreshold parameters, when handover for offload was to be triggered, UE was configured
to measurement several candidate carriers simultaneously regardless of the priority of the carriers. The first
reported carrier by UE was the handover target which could be the lowest priority carrier for offloading.
LA5.0 FRS 115204 supports UE consecutive measurement configurations based on carrier priority if the
measurements are for off-load purpose. That is, eNB will first configure UE to perform measurement on the high
priority carriers and then on the medium priority carriers, and finally, on the low priority carriers. The purpose is
for eNB to have better chance to receive UE measurement report on a higher priority carrier first and so UE may
be off-loaded to a higher priority carrier.
Those two parameters are tuned according to the UE’s average priority (0 to 7) in the cell.

If the inter-frequency and/or inter-RAT mobility measurements are for the purpose of off-load, eNB may request
UE to monitor multiple RAT/carriers. eNB will first configure UE to perform measurements on the high priority
carriers and start the timer with value specified by timeOffsetForMediumPriorityCarriers. When the timer expires,
eNB will configure UE to perform measurements on medium priority carriers and start another timer with value
specified by timeOffsetForLowPriorityCarriers. When the timer expires, eNB
will configure UE to perform measurements on low priority carriers.
If there is no high priority carrier and no medium priority carrier, there must be low priority carrier if there is any
carrier.

RRC_Connected mode

eMTCA feature introduces a common mobility framework, E-MCTA, which is a proprietary ALU solution to
allocate the traffic efficiently for LTE sessions across multiple RAT and multiple LTE RF carriers during
handover and call admission control based on triggers and filters for the Mobility Domain, Services Domain,
and Capacity Domain.
When E-MCTA is triggered, it takes as an input neighboring RAT/carriers of the serving LTE cell, it applies
filters, and it provides as an output a sorted list of candidate RAT/carriers for RRC Measurements. This
functionality is part 1 of e-MTCA feature.
The RRC measurement configuration function relies on part 1 of the E-MCTA process since the list of
Measurement Objects towards which the UE performs measurements is the candidate RAT/carrier list
output of the E-MCTA process plus the mandatory intra-frequency measurements like A3 for intra-frequency
mobility or A2-floor for blind redirections.

The objective of the eMCTA is to optimize the traffic distribution both between layers and cells. The eMCTA
function is managed by the eNB.
To increase the network capacity, operators may deploy multi layer configurations with several layers structures:
Multi layers with equal coverage, hot spots, micro cells, hierarchical cells structure.
eMCTA works with many RAT/carriers (FDD or TDD). In LA5.0, only inter-RAT iso frame structure is allowed (i.e.
LTE TDD towards UMTS TDD and LTE FDD towards UMTS FDD)
The traffic distribution strategy may be based on:
load balancing (LA5.0)
service partitioning (LA3.0 and evolution in LA4.0)
UE speed (future)
Congestion management (LA4.0)
Mobility
ANR (LA4.0)
The introduction of LTE will be also progressive with hot spots and there is a need to redirect LTE capable
mobile towards LTE cells in order to offer the best services to the end user.
eMCTA allows to:
Improve network capacity by allocating radio resources preferably onto a certain layer according to:
Service Type
UE capability (R8, R9 etc)
Balancing load between cells of the different overlapping layers
Redirecting a UE to a unloaded cell on a CAC failure occurring in a serving cell
Improve network quality by avoiding call drop in case of loss of coverage on a certain layer

eMCTA is invoked only in case of LTE inter-freq mobility or in case of inter-RAT mobility. eMCTA is not invoked in
case of LTE intra-freq mobility.
Measurement report for event A2_floor requires an urgent mobility action without measurements: eMCTA is
invoked in order to provide the best RAT/carrier
Measurement report for event A2_CA (coverage alarm) requires a mobility action towards another LTE carrier or
another RAT with measurements. eMCTA will provide in this case an ordered list of RAT/carriers with the
associated measurement (A3/A5, B1/B2) to be configured before handover decision; the need to configure the
UE with measurement gap (yes/no) is also provided
In case of S1AP CS Fallback Indication received from MME, the eNB will perform a PS HO to UTRAN or Cell
Change Order to GERAN or a Redirection towards the best RAT/Carrier UTRAN/GERAN; measurement
configuration for event B2 or B1 is provided by eMCTA.
LA4.0 introduces the Reactive Load Control request (for congestion management) triggered by the call admission
control (CAC) in order to have inter RAT/carriers candidates for UE offload, as well as the ANR request for inter
RAT/carriers candidates.
eMCTA is invoked in case Preventive Load Control activated (LA5.0) to identify unloaded cells on another LTE
frequency to be monitored via Event A4

eMCTA can be invoked in LA4.0 on 5 events:
meas.report for event A2_CA
meas. Report for event A2_floor
MME message CS Fallback Indicator
Reactive Load Control request for offloading a UE to another target inter RAT/carrier cell
ANR request for inter RAT/cell measurements
When invoked, eMCTA:
takes the input ‘Neighbor RAT/Carrier List’ from the measurementIdentityConf (MeasObject and
reportConfig instances) provided by RRC Measurement Configuration function
applies filters on: UE capacity, mobility path information, network capacity, service-based policy and
QCI-based policy
provides the output measured or blind ‘Candidate RAT/Carrier Sorted List’
Evaluates Measurement Gap needs for each candidate RAT/carrier
Output ‘Candidate RAT/Carrier Sorted List’ indicates for each candidate RAT/carrier:
Target Measurement Configuration (B2/B1, A5/A3, A4 or none)
Priority (0-lowest through 7-highest)
Whether a Measurement Gap needs to be configured (yes, no)
B1/B2 are used for inter RAT measurements, A3/A5 for intra or interfreq measurements and A4 for ANR
interfreq

eMCTA applies filters to the RAT/Carrier neighbors of the LTE Serving Cell
Filters in LA4.0 are:
UE Capability Filter: based on UE Capabilities (bands and events supported)
Mobility Path Information Filter: based on RATs forbidden for HO coming from MME, forbidden PLMN, LAC
and TAC (provided in S1AP Handover Restriction List IE)
Network Capability Filter: based on other RAT network constraints like time synchro (HRPD) or RNC
availability (for CSFB to UTRA)
Service-based Policy Filter: CS fallback (4 different service types depending on the emergency of the call
and on the RRC state) may need a specific policy defined by the operator
QCI-based - policy: different levels of importance regarding mobility can be assigned per QCI

The RAT/Carrier neighbors configured in the LTE Serving Cell are an input to eMCTA

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’, defaultConnectedPriorityOfFreq is 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.
More generally, parameter defaultConnectedPriorityOfFreq is used to determine the RAT/carrier priority when:
isServiceBasedTrafficSegmentationAllowed= True and serviceType or qci not found, or
isServiceBasedTrafficSegmentationAllowed= False
ServiceTypePriorityConf object allows to allocate per RAT/carrier different priorities to the 4 different CSFB
services: CSFB/ emergency CSFB in RRC Idle/ Connected mode. Compared to LA3.0, VoIP service is not anymore
mamanged by this object.
There is one instance of QciPriorityConf configured for each qci in qciHierarchyForMultiQciCallList.
Parameter qciHierarchyForMultiQciCallList is 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 defaultConnectedPriorityOfFreq is 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.

ServiceTypePriorityConf (modified in LA4.0) is related to a given RAT/carrier:
Used for Service Based Policy for CSFB.
Service Based Policy requires setting parameter isServiceBasedTrafficSegmentationAllowed to True. This is a
licensed feature.
Each instance has a service type (serviceType) with an assigned priority (eMctaPriority).
Selection of measurement candidates for CSFB (from eMCTA) is based on the incoming request from the
S1AP interface

QciPriorityConf (new in LA4.0) is related to a given RAT/carrier:
Used for QCI-Based Policy for all LA4.0 triggers except CSFB and ANR.
There is one instance of qciPriorityConf per QCI listed in qciHierarchyForMultiQciCallList
QCI-Based Policy requires setting parameter isServiceBasedTrafficSegmentationAllowed to True.
Each instance has a QCI number (qci) with an assigned mobility priority (eMctaPriority).
Parameter qciHierarchyForMultiQciCallList lists the QCIs in order of importance (from most important to
least important) related to mobility considerations in this RAT/carrier
The priority assigned to a RAT/Carrier for a given call is the value of eMctaPriority of the qci of a mono or
multi RAB call representing the most important established QCI found in the list
qciHierarchyForMultiQciCallList
Measurement candidates (eMCTA) for a mobility procedure are selected based on the QCI designated as
“most important” of the UE’s established eRAB (s).
Example: live streaming (QCI=2) may be configured in GERAN with a low mobility priority (high eMctaPriority) in
order to favor the UTRA layer for high throughput data services

During RRC_CONNECTED mode, if the eNodeB decides that the UE needs to perform LTE inter-frequency and inter-RAT
monitoring activities, it will provide the UE with a measurement configuration which includes a monitoring gap pattern
sequence. During the monitoring gaps, UE reception and transmission activities with the serving cell are interrupted. The
main reason for using monitoring gap patterns is because the vast majority of UEs are single receiver and can not therefore
monitor two RATs simultaneously. Even if a UE has multiple receivers to perform inter-RAT monitoring activity (e.g. one LTE
receiver, one UMTS receiver and one GSM receiver) there are some band configurations for which monitoring gaps are still
required in the uplink direction. In particular these are useful when the uplink carrier used for transmission is immediately
adjacent to the frequency band which the UE needs to monitor. Rather than address each scenario (i.e. each pair of
frequency bands) with a specific solution, uplink gaps in LTE are configured in the same way for all scenarios.
LTE monitoring gap patterns contain gaps every N LTE frames (i.e. the gap periodicity is a multiple of 10 ms) and these gaps
have a 6 ms duration. A single monitoring gap pattern is used to monitor all possible RATs (inter-frequency LTE FDD and
TDD, UMTS FDD, GSM, TD-SCDMA, CDMA2000 1x and CDMA2000 HRPD).
Different gap periodicities are used to trade off between UE inter-frequency and inter- RAT monitoring performance, UE data
throughput and efficient utilization of transmission resources. In general, cell identification performance increases as the
monitoring gap density increases, while the ability of the UE to transmit and receive data decreases as the monitoring gap
density increases.
Most RATs (LTE, UMTS FDD, TD-SCDMA, CDMA2000) broadcast sufficient pilot and synchronization information to enable a
UE to synchronize and perform measurements within a useful period slightly in excess of 5 ms. This is because most RATs
transmit downlink synchronization signals with a periodicity no lower than 5 ms.
For example, in LTE the PSS and SSS symbols are transmitted every 5 ms. Therefore a 6 ms gap provides sufficient
additional headroom to retune the receiver to the inter-frequency LTE carrier and back to the serving LTE carrier and still to
cope with the worst-case relative alignment between the gap and the cell to be identified. The worst-case relative alignment
is depicted in the figure above, where the LTE PSS and SSS symbols are time-aligned with the gap edges.
However, GSM requires special treatment because synchronization information is organized differently in the time domain. A
monitoring gap pattern used for GSM monitoring must allocate time for three parallel activities: GSM RSSI measurements,
initial BSIC identification and BSIC reconfirmation. This can be achieved by, for example, allocating every third monitoring
gap to each one of the three activities.
Some ideas of magnitude:
Intra-freq measurement period is defined to be 200ms (even when monitoring gap patterns are activated the vast majority of
time (i.e. no less than 85–90% of the time) is available to perform intra-frequency monitoring)
For Inter-freq, for a 6 ms gap duration only 5 ms is available for inter-frequency monitoring once the switching time has
been removed. If the monitoring gaps repeat every 40 ms only 5/40 = 12.5% is available for inter-frequency monitoring. For
this reason LTE inter-frequency maximum cell identification time and measurement periods need to be longer than for the
intra-frequency case (at least x8 then).

RAT/Carriers configuration rules:
Equal priorities between RATs are not supported.
Equal priorities within GERAN are supported
Equal priorities - within UTRAN are supported
In case of equal priorities for radio reason:
E-MCTA upon coverage alarm: ENB configures all the possible measurements
E-MCTA upon below serving floor radio condition: ENB blindly redirects the call towards one of the randomly
selected highest priority carriers
In case of equal priorities for CSFB reason:
ENB configures one measurement for one of the randomly selected highest priority carriers

feature LA3.0 106136
The truncation of the eMCTA ‘Candidate RAT/Carrier Sorted List’ is performed in the RRC Connection
Configuration algorithm.
If the total number of measurements required by the eNodeB exceeds maxMeasIdForMultipleMonitoring, then
the eNodeB reduces to maxMeasIdForMultipleMonitoring this total number. The lowest priority measurements
are removed by this truncation. Prevailing measurements are the intra-frequency ones: for example with
measurement purpose set to Mobility-Intra-Freq; or Entering-Coverage-Alarm; or Leaving-Coverage-Alarm. It is
recommended that maxMeasIdForMultipleMonitoring be set to a value that will always accommodate the
essential intra-frequency measurements along with the anticipated inter-frequency/inter-RAT measurements at
the top of the eMCTA sorted list so that the eNodeB would need to remove only the lower priority inter-
frequency or inter-RAT measurements at the bottom of the eMCTA sorted list.
The algorithm also limits the number of allowed layers for multiple monitoring (requiring MG) to a maximum
called maxNbCarriersForMultipleMonitoringUsingMeasGaps which is configured by the Operator. In essence, this
parameter limits the number of RRC measurements needing a Measurement Gap (MG) which can be configured.
This could result in the lower priority RAT carriers in the ‘candidate RAT/Carriers Sorted List’ needing a MG to be
removed from the list, if the total number needing a MG in the Sorted List exceeds this parameter value.
Default=5

Mobility Path Information filter screens candidate neighboring RAT/Carriers based on the information contained
in the S1AP ‘Handover Restriction List’ IE.
This filter applies only to non-emergency calls.
The following information is checked:
RATsrestricted for handover (updated for 3GPP Rel9)
PLMNsallowed
Forbidden TACs
Forbidden LACs

Service-based filter (4) is not applicable for Event A2_CA

UE is currently connected on eUTRA f0.
For instance, with eUTRA f1, you will have 6 instances of qciPriorityConf (#0 to #5) with for each one the
parameters qci (1st column of Table1) and eMctaPriority (2nd column)
VoIP is configured to be managed with highest priority by eUTRAN f1, GBR real-time gaming by HRPD etc

Blind candidate RAT/Carrier list may potentially contain RAT/Carrier neighbors for which the UE does not support
measurements (this is the main difference between A2_Floor and A2_CA output candidate lists)

Possible values of serviceType : csfbByIdleUE, emergencyCsfbByIdleUE, csfbByConnectedUE,
emergencyCsfbByConnectedUE

The Mobility Path Information checks rely on the information contained in the S1AP Handover Restriction List IE.
In LA4.0, 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.

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 (UTRAFDD; 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.

In response to an Offload-UE-Upon-Reactive-Load-Control trigger, eMCTA builds for that UE the ‘Measured
candidate RAT/carriers sorted list’ with for each candidate the target measurement configuration (A4 or B2), the
priority and the measurement gap (if needed). This matched candidate list is passed through eMCTA filters.

The RRC Measurement Configuration for trigger Offload-UE-Upon-Reactive-Load-Control is similar to the Serving
Radio Monitoring case except:
event A4 (instead of event A5) is configured for EUTRA inter-freqency measurements.
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.

The concept of loaded cell is specified in the Session module of the course.

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

LR13.1 feature L114538: Enhanced Load Balancing Criteria
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.
ThresholdRelativePreventiveOffload (ENBEquipment/Enb/RrmServices/RadioCacEnb; default=20%)

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.
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 to enable/ disable FDD/TDD redirection for

preventive offload. This activation flag will control whether or not FDD/TDD redirection for preventive offload is
activated or not. Not used in LR13.1.

ANR may trigger eMCTA to select candidate LTE inter-frequency and inter-RAT carriers for ANR measurements.
In LA4.0, only UTRA-FDD neighboring carriers may be selected as inter-RAT candidates for 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 inter-RAT ANR
periodical measurements. The Mobility Priority Table is not used by eMCTA when triggered by ANR. Candidates
for ANR measurements are assigned a priority of 8 to ensure that they are of higher priority than any
measurement used by other mobility cases.

RRC_Connected mode

Intra-LTE handover does not need data forwarding.
The parameters above apply for RRC Idle and Connected modes.

The eNB may trigger an intra-LTE handover only after the default bearer is established and security activated

When the eNB receives a MeasurementReport it will decide if a handover procedure needs to be triggered.
In case of handover trigger, the eNB selects the target cell based on the UE measurement report and trigger an
intra-eNB handover procedure if the selected target cell belongs to the same eNB. If the selected target cell
belongs to a different eNB then trigger an inter-eNB handover procedure:
In case of intra-eNB handover, the eNB will:
Perform admission control
Setup L1/L2 resources in the target cell
Perform U-plane actions in the source cell.
Transmit the RRC CONNECTION RECONFIGURATION to the UE.
In LA3.0, in the meantime, up to 8 Bearers is supported per UE.
So, for handover, the up to 8 Bearer HO is also supported.
When the UE receives RRC CONNECTION RECONFIGURATION it is not aware whether an intra-eNB or inter-
eNB handover is to be executed. The UE has the same behaviour for both cases.
The UE stops receiving/transmitting from the source cell reconfigures its L1/L2 as requested in RRC
CONNECTION RECONFIGURATION.
The UE performs synchronization to the target cell and accesses it via a contention-based random access.
If the UE succeeds to access the target cell it will transmit RRC CONNECTION RECONFIGURATION COMPLETE.
When the eNB receives the RRC CONNECTION RECONFIGURATION COMPLETE, it will perform U-plane
actions in the target cell ALU and release UE resources in the source cell

If the internal defence timer RrcIntraEnbHo expires without RRCConnectionReconfigurationComplete reception,
the handover procedure is failed the eNB initiates the S1 UE context release procedure.Partial failure is
supported.
So, only when all TRBs fail CAC (i.e. no TRBs can be established at target cell) will lead to HO cancel.
If at least one TRB succeeds (and at least one TRB fails) in RRM in target cell, the HO execution will continue.
The TRB that was successful in RRM will be handed over to the target cell and the failed TRB will be released.
In case the eNB is requested to release a non-existent radio bearer Id or a duplicate request to delete the same
radio bearer Id, the eNB should respond back with an appropriate cause value to indicate this.
If any UL RRC messge is received with integrity verification failure, the procedure is aborted, and the eNB
initiates the S1 UE context release procedure.

DL Carrier Aggregation with up to 2 serving cells is supported in LR13.3. The UE only has one RRC connection
with the network at RRC connection establishment/ reestablishment/ handover, one serving cell provides the
NAS mobility information (e.g. TAI) and at RRC connection re-establishment/handover, one serving cell provides
the security input. This cell is referred to as the Primary Cell (PCell). One Secondary Cell (SCell) (in LR13.3) can
be aggregated with the PCell for increased bandwidth. UE that has a call configured with CA (CA being active or
not) supports intra LTE mobility, be it intra/ inter-eNB, intra/ inter-frequency, via X2 or via S1, with some
additional requirements in the handover procedure, Carrier Aggregation is deconfigured for Handover and then
reconfigured after Handover (CA configuration in target cell during Handover is not supported in this release).

According to 3GPP an intra-LTE handover should not be triggered until the security is activated (“the UE only
accepts a handover message when security is activated”).
The eNB may trigger an intra-LTE handover only after the default bearer is established and security
activated Applicable eNB procedures:
X2-AP Handover preparation procedure

X2-AP SN status transfer procedure only if PDCP SN status preservation applies for at least one of the Radio
Bearers handed over. This is applicable only to RB using RLC-AM mode
RRC Connection Reconfiguration (mobility) procedure
X2 U-plane data forwarding (if enabled via MIM configuration);
X2-AP UE CONTEXT RELEASE procedure
S1-AP path switch request procedure

Phase 1: handover preparation: This phase involves the Source eNB, the target eNB and finally the UE.
In case of inter-eNB handover trigger, the Source eNB will initiate the X2-AP handover preparation providing in
X2-AP HANDOVER REQUEST the necessary information to prepare the handover in the Target eNB.
If the data forwarding is enabled in the Source eNB then the Source eNB will propose to the target eNB to
perform DL data forwarding via X2.
The eligibility to DL forwarding of each supported QoS Label (QCI) is configured via MIM. If Integrity Protection
and Confidentiality services are enabled, AS security data is also included in the X2 HANDOVER REQUEST
message.
Target eNB prepares the handover based on the received request from the Source eNB and includes in
HANDOVER REQUEST ACKNOWLEDGE the RRC CONNECTION RECONFIGURATION message to be transmitted
transparently by the Source eNB to the UE.
If the data forwarding is enabled in the Target eNB then the Target eNB will accept the proposal from the
Source eNB to perform DL data forwarding via X2 by establishing the one DL X2 tunnel for each E-RAB subject
to forwarding.
The eligibility to DL forwarding of each supported QoS Label (QCI) is configured via MIM. After this step the
target eNB is ready to receive UL transmission from the UE and DL data forwarded over X2 from the Source eNB
if configured previously.
If AS security services are enabled, the target eNB also derives keys that will be used for integrity
protection and ciphering.

Phase 2: handover execution: This phase involves the UE, the Source eNB and the Target eNB
-If data forwarding was configured in the handover preparation phase, the Source eNB forwards over X2 the DL
PDCP SDUs numbered but not acknowledged by the UE (only applicable for RLC-AM DRBs) followed by fresh
REQUEST ACKNOWLEDGE reception and stops transmitting in the source cell the fresh unnumbered DL PDCP
SDUs.
-When the UE receives RRC CONNECTION RECONFIGURATION in the source cell it will stop
receiving/transmitting data in the source cell and will initiate synchronization to the target cell followed by
random access procedure as indicated in the received message. Both contention-based and non-contention
based random access is supported. If resources are available the eNB allocates a dedicated preamble to the UE.
Phase 3: handover completion: This phase involves the the Source eNB, the Target eNB end the ePC
When the Target eNB receives the RRC CONNECTION RECONFIGURATION COMPLETE it will send the S1-AP
PATH SWITCH REQUEST to the MME to inform the that the UE changed the cell After the transmission of S1-AP
PATH SWITCH REQUEST, the Target eNB is ready to receive DL data over S1 Upon request from the MME (at
reception of S1-AP PATH SWITCH REQUEST), the SGW switches the DL data path to the Target eNB. The SGW
sends one or more GTP-U End Marker per GTP-U tunnel through the old path (i.e. old S1 U-plane interface) to
the Source eNB and then release the U-plane resources and confirms the path switch to the MME which in turn
sends S1 PATH SWITH REQUEST ACKNOWLEDEGE to the Target eNB.
This message contains the security information for the NAS signalling messages that will have integrity
protection.
During the handover completion the UL data transmission occurs normally in the Source or the Target eNB
if DL data forwarding was configured, the Source eNB continue to forward via X2 interface the received DL S1
packets until reception of GTP-U End Marker or resources are released
DL data forwarding was configured, the Target eNB shall transmit the over the radio the DL X2 received
packets until reception of X2 GTP-U End Marker or resources are released. Only after that DL S1 packets are
transmitted.

The incoming handover fails in the target eNB at the level of the HO preparation phase :
1. If mobility is not enabled (i.e. configuration parameter isIntraFreqMobilityAllowed is not set to TRUE in MO
ActivationService) or if the cell is barred; in this case the Cause IE is set to Radio Network Layer Cause "Cell
not Available"
2. If the S1 link to the MME identified by the GUMMEI information element is down or the S1 Setup procedure
has not completed successfully; in this case the Cause IE is set to Radio Network Layer Cause "Cell not
Available"
3. If the GUMMEI is unknown; in this case the Cause IE is set to Radio Network Layer Cause "Invalid MME Group
ID" or "Unknown MME Code"
4. Or due to failure to establish the requested resources (admission control failure, eNB internal failure, RLC
mode is not the same, etc); in this case the Cause IE is set to Radio Network Layer Cause "Cell not
available"

The S1-handover procedure has been designed in a very similar way to the UMTS Serving Radio Network
Subsystem (SRNS) relocation procedure: it consists of a preparation phase involving the core network, where
the resources are first prepared at the target side, followed by an execution phase and
a completion phase.
Compared to UMTS, the main difference is the introduction of the ‘STATUS TRANSFER’ message sent by the
source eNodeB. This message has been added in order to carry some PDCP status information that is needed at
the target eNodeB in cases when PDCP status preservation applies for the S1-handover; this is in alignment with
the information which is sent within the X2 ‘STATUS TRANSFER’ message used for
the X2-handover. As a result of this alignment, the handling of the handover by the target eNodeB as seen from
the UE is exactly the same, regardless of the type of handover (S1 or X2) the network had decided to use.
The Status Transfer procedure is assumed to be triggered in parallel with the start of data forwarding after the
source eNodeB has received the ‘HANDOVER COMMAND’ message from the source MME. This data forwarding
can be either direct or indirect, depending on the availability of a direct path for the user plane data between the
source eNodeB and the target eNodeB.

The ‘HANDOVER NOTIFY’ message, which is sent later by the target eNodeB when the arrival of the UE at the
target side is confirmed, is forwarded by the MME to trigger the update of the path switch in the S-GW towards
the target eNodeB. In contrast to the X2-handover, the message is not acknowledged and the resources at the
source side are released later upon reception of a ‘RELEASE RESOURCE’ message directly triggered from the
source MME.

A timer , TS1RelocPrepForS1Handover, is introduced with S1 handover capability. This timer is started in
the source eNB when it sends the S1 HANDOVER REQUIRED message, and the timer is cancelled when the S1
HANDOVER COMMAND message is received from the MME. If the timer expires before the S1 HANDOVER
COMMAND message is received from the MME, then the source eNB sends an S1 HANDOVER CANCEL message
to the MME, and expects to receive an S1 HANDOVER CANCEL ACKNOWLEDGE message in response from the
MME.
The UE context is returned to its state prior to the handover trigger.
When the source eNB receives the S1 HANDOVER COMMAND from the MME, it starts timer
tS1RelocOverallForS1Handover. The timer is stopped when the source eNB receives the S1 UE CONTEXT
RELEASE COMMAND message from the MME. If the timer expires before the source eNB receives the S1 UE
CONTEXT RELEASE COMMAND message from the MME, then the source eNB sends an S1 UE CONTEXT
RELEASE REQUEST message. The expected result is that the MME will send an S1 UE CONTEXT RELEASE
COMMAND message to the source eNB, and the UE context will be released.

Feature 98841

LA5.0 feature L97980: Improvements over S1
This feature introduces the following improvements related to the S1 interface:

Support of partial failures of Path Switch Request procedure: In case the EPC failed to perform the user
plane path switch for at least one, but not all, of the eRABs, the eNodeB considers the Path Switch
procedure as successful and releases the data radio bearers corresponding to the failed eRABs.
Support of the incoming Error Indication message from MME: When Error Indication messages are received
from the MME, the eNodeB takes appropriate actions, such as release of resources associated to
inconsistent S1AP IDs, and abortion of ongoing procedures, depending on the ongoing procedure state and
on the type of detected error.
New counters to count received and sent Error Indication messages
Feature Benefits
This feature improves S1 error handling.

This feature LA5.0 L115458 supports the following major functionalities:
1. When ActivationService::isHoRetryToSecondBestCellAllowed is set to ‘True’, and the handover is not for the
purpose of offloading, eNB will support handover retry to the second best LTE cell when handover
preparation to the best LTE cell fails with the reason of ‘cell-not-available’ (cell is barred,
isIntraFreqMobilityAllowed is set to ‘False’, or isS1HoAllowed is set to ‘False’) or ‘ho-target-not-allowed’ (cell is
reserved for operator use, cell is disabled, S1 link to the MME anchoring the call is down, or target cell identity is
unknown to the eNB).
2. eNB will reject the incoming handover requests (including handover requests for emergency calls) to a cell
reserved for operator use in the PLMN serving the UE with cause ‘ho-target-not-allowed’ unless
ActivationService::isIncomingHoToReservedCellBasedOnSpidAllowed is set to ‘True’, and SPID (Subscriber Profile
ID) of the UE is specified in PlmnIdentity::spidAllowedInReservedCells. This parameter specifies the Subscriber
Profiles ID of the UEs allowed to be handover into a cell reserved for operator use.
Feature Benefits:
This feature enables Alcatel-Lucent's customers to perform handover testing with dedicated test UEs without
permitting commercial users to access the cells. This allows for performing parameter tuning prior to putting into
commercial service a newly deployed eNodeB or cluster of eNodeBs.

LA5.0 feature L115233
The operator has the choice to always deactivate data forwarding or (in case of an inactive user) to deactivate
data forwarding only in case of processor overload. Note that with iniactive users, the data forwarding is done
without PDCP PDU and then the gain of this feature is limited to the Control Plane processing.
PO stands for Processor Occupancy

If thrForPOToSkipHODataForwarding = 0, data forwarding will always be deactivated for inactive UEs,
regardless of the PO of the CCM board
If 0 < thrForPOToSkipHODataForwarding <= minorThresholdForPO, data forwarding will be deactivated for
inactive UEs if the PO of CCM board is in minor or above overload condition
If minorThresholdForPO < thrForPOToSkipHODataForwarding <= majorThresholdForPO, data forwarding
will be deactivated for inactive UEs if the PO of CCM board is in major or above overload condition
If thrForPOToSkipHODataForwarding > majorThresholdForPO, data forward will always be activated for all
UEs, regardless of the PO of the CCM board minorThresholdForPO and majorThresholdForPO are defined
under OverloadControl MO. If a UE does not have user plan activity for longer than
OverloadControl::inactivityTimerToSkipHODataForwarding, it is consider as inactive

LR13.1 feature L101815 : Intra-LTE FDD/TDD Handover
The HO procedure led by the eNodeB depends on UE capabilities that are initially provided by the UE, and then forwarded in the RAN.
During initial attachment, and after setup of intra Frequency measurements, an eNodeB requests UE capabilities using the
UECapabilityEnquiry message that contains at least RAT-Type=eutra. The UE responds with the UECapabilityInformation message and
returns UE-CapabilityRAT-ContainerList including UE-EUTRA-Capability. This IE itself contains a band parameter
SupportedBandEUTRA:bandEUTRA that provides carrier bands supported by the UE and that identify unambiguously TDD or FDD in
compliance with TS36.104:
- FDD bands = [1..14, 17..25]
- TDD bands = [33..43]
Further, featureGroupIndicators are used to validate Inter-Frequency UE Measurement Report Configurations. The featureGroupIndicators IE
contained in the UECapabilityInformation, in particular bits 13, 14, 25 and 30, inform the eNB about:
• Bit 13: Inter Frequency handover support within FDD or TDD bands
• Bit 14: Measurement event A5 (and A4) support
• Bit 25: Inter Frequency measurements and reporting support (when set to 1, ensures that FDD<->TDD measurements were validated by
the 3GPP rel8, rel9, or rel10 UE). If the UE supporting a future 3GPP release does not supply this optional IE, the eNB assumes that the UE
supports all these features, as allowed by TS36.331 annex B1
• Bit 30: Handover between TDD and FDD (can only be set to 1 when bit 13 = 1).
• 3GPP rel8 UEs are never mandated to set bit 30 to 1
• 3GPP rel9 and rel10 UEs may set bit 30 to 1
After capabilities retrieval and storage, the eNodeB continues the connection phase and setup Inter-Frequency measurements. Therefore:
• FDD->FDD HO – FGI bits 13 and 14 are all set to one
• FDD->TDD HO – FGI bits 13, 14, 25, 30 are all set to one
FDD-TDD Mobility is by 3GPP definition an Intra-LTE mobility. Feature 101815 as well introduces compatibility between FDD and TDD eNBs
via X2. In the X2 Setup Request/Response, Served Cell information contains FDD or TDD info, with per direction EARFCNs in FDD and a
single EARFCN for both directions in TDD. Therefore X2 based handover functions the same manner for FDD->FDD and FDD->TDD cases.
S1 messages for FDD->FDD and FDD->TDD handover are identical, therefore they function in the same manner.

The eNodeB cannot use the band information directly, and shall build an association between the band and
carrier frequencies in the uplink and downlink directions, which are identified by the E-UTRA Absolute Radio
Frequency Channel Number (EARFCN).
EARFCN values are the only MIM objects used for this determination.
• FDD bands: DL EARFCN in the range = 0 – 17999 and UL EARFCN in the range 18000 – 35999
• TDD bands: DL and UL EARFCN in the range = 36000 – 65535
The object model in LTE is the same for FDD and TDD

LR13.1 L134689 feature: Macro/Metro to HeNB Cell Mobility.
This feature introduces the mobility procedure from eNB (LTE macro/metro cells) to ALU/non- ALU HeNB open
cells. An HeNB open cell can be accessed by any UE with no access control imposed on MME. HeNB open cells
can have dedicated carriers or share carriers with LTE macro/metro cells and so eNB to HeNB mobility can be
intra-frequency or interfrequency.
Restrictions for LR13.1:
- only FDD eNB to FDD HeNB mobility is test verified
- eNB must be equipped with bCEM modems
Closed access mode (not supported in LR13.1): The HNB belongs to one or more specific Closed Subscriber
Groups (CSGs) identified by CSG Identifiers (CSG IDs). Only UEs which have the corresponding CSG ID
included in their CSG subscription list are allowed access.
The wording ‘Small cells’ includes the cells of the 3G UTRA Home NodeB (HNb), the LTE Home eNodeB (HeNb)
and the metro eNodeB. HNb and HeNb are Femto equipment connected to the Small Cell Gateway (or Femto
Gateway) while the metro eNodeB acts as a pico eNodeB and is connected to the MME.
The definitions of picocells and femtocells can be summarized as follows:
• A pico eNodeB (Alcatel-Lucent Metro eNB) usually controls multiple small cells which are planned by the
network operator in a similar way as the macrocells. Picocells are often mounted at low elevation and operate at
lower power than the macrocells. A HNB/HeNB controls only one cell and is deployed by the customer (the
registered owner), usually without planning.
• Femtocells are typically Closed Subscriber Group (CSG) cells accessible only to a limited group of users; in
contrast, picocells are usually open to all users (Open Subscriber Group (OSG)) but may offer preferential
treatment to some users, e.g. to the staff of a particular establishment.
• The transmission power of femtocells is lower, being designed typically to cover a house or apartment.
Picocells usually operate with a higher transmission power to cover an enterprise, mall or other hotzone, or
simply to extend macrocellular coverage.
• Femtocells do not necessarily have the same network interfaces as macro eNodeBs, whereas pico eNodeBs
follow the same logical architecture principles as macro eNodeBs.

The feature is enabled by a new parameter, ActivationService::isMobilityToHeNBEnabled together with the
existing intra-frequency or inter-frequency mobility enabling parameters:
• Intra-frequency mobility from eNB to HeNB is enabled if
ActivationService::isMobilityToHeNBEnabled = ‘True’ and ActivationService::isIntraFreqMobilityAllowed = ‘True’
• Inter-frequency mobility from eNB to HeNB is enabled if
ActivationService::isMobilityToHeNBEnabled = ‘True’ and
(ActivationService::isInterFreqEutraSameFrameStructureMobilityAllowed =
‘True’ or ActivationService::isInterFreqEutraOtherFrameStructureMobilityEnabled = ‘True’)
HeNB cells cannot share the PCIs used by LTE macro/metro cells. HeNB cells can only be assigned with the
dedicated PCIs defined in LteNeighboringOpenOrHybridHeNBCellLayerRelation::pCIList. On the other hand, LTE
macro/metro cells under the same carrier cannot be assigned with the PCIs dedicated for HeNB cells.
Unlike macro/metro cells where each of them will be assigned with a unique PCI, several HeNB cells in the same
coverage area are allowed to share the same PCI. For this reason, LTE macro/metro cells of an eNB will not
maintain per HeNB cell neighbor relation. Instead, information of all HeNB cells under a LTE frequency is
maintained under LteNeighboringOpenOrHybridHeNBCellLayerRelation.

X2 link is not supported between eNB and HeNB (eNB will not send X2 SETUP REQUEST message to HeNB, and will ignore the X2 SETUP
REQUEST message received from HeNB). For this reason, eNB will not receive cell load information from neighbor HeNB open cells. With
134689, the cell load status of a HeNB open cell and the carrier load status of its shared/dedicated carrier will be treated as ‘non-loaded’ by
eMCTA. HeNB open cells and their shared/dedicated carriers will pass the eMCTA Frequency Load Filter for mobility (for RF reason, for
reactive load control, and for preventive load control). The following mobility procedures are supported from eNB to HeNB open cells:
• Intra-frequency handover – This may happen if HeNB open cell shares the same frequency as eNB serving cell. If the HeNB open cell is
reported as the best cell in event A3 intra-frequency mobility measurement report and report-CGI measurement report is later received, eNB
to HeNB intra-frequency handover will be triggered
• Inter-frequency handover – This may happen if HeNB open cell has different frequency than the eNB serving cell. If HeNB open cell is the
reported best cell in event A5/event A3 inter-frequency mobility measurement report when UE enters A2_CA area and report-CGI
measurement report is later received, eNB to HeNB inter-frequency handover will be triggered
• Inter-frequency blind redirection – This may happen if a HeNB open cell has different frequency than the eNB serving cell when UE enters
A2_Floor area and the shared carrier is selected by eMCTA as the best carrier to perform blind redirection. Inter-frequency blind redirection
may seldom happen to HeNB open cell dedicated carriers since they are required to be set to have lower eMCTA priority
(QciPriorityConf::eMctaPriority or MobilityPriorityTable::DefaultConnectedPriorityofFreq)
• Reactive load control – If a UE is selected as a reactive offload candidate, and if a HeNB open cell dedicated or shared carrier is selected
by eMCTA as the reactive offloading candidate carrier, eNB will configure UE to perform event A4 measurement with measurementPurpose
= mobility-inter-Freq-to-EUTRA. When event A4 UE measurement report is received for reactive offloading, it is treated the same as an
event A3/event A5 interfrequency mobility measurement report for a HeNB dedidated/shared carrier
• Preventive load control – If a UE is selected as a preventive offload candidate, and if a HeNB open cell dedicated or shared carrier is
selected by eMCTA as preventive offloading candidate carrier, eNB will configure UE to perform event A4 measurement with
measurementPurpose = mobility-inter-Freq-to-EUTRA. When event A4 UE measurement report is received for preventive offloading, it is
treated the same as event A3/event a5 inter-frequency mobility measurement report for a HeNB dedicated/shared carrier.
Mobility related procedures that are not supported by HeNB open cells:
• ANR for HeNB open cell is not supported. When inter-freq ANR is activated, UE will not be configured to perform PCI search for the carriers
dedicated to HeNB open cells. This can be achieved by setting LteNeighborFreqConf::anrActiveAfterX2Setup to ‘True’ or by not to configure
ANR measurement for the dedicated carrier for HeNB open cell (not to configure MeasurementIdentigyConf instance with MeasObjectLink
points to MeasObject instance of the dedicated carriers for HeNB open cells and measurementPurpose set to ‘Automatic-Neighbor-Relation’).
When intra-freq ANR and inter-freq ANR are activated, for HeNB open cell shared carriers, if UE measurement report contains a PCI that is
belong to HeNB open cells (if the reported PCI belongs to the PCIs defined in LteNeighboringOpenOrHybridHeNBCellLayerRelation::pCIList),
the measurement report will be ignored and no HeNB open cell neighbor relation will be set up for this neighbor.

The parameters are provided per LTE layer and not per cells relationship because several HeNB cells can have
the same PCI.
LteNeighboringOpenOrHybridHeNBCellLayerRelation MO includes the following parameters:
• cellIndividualOffset – This parameter indicates the cell individual offset between the serving macro/metro cells
and the HeNB open neighbor cell. It is sent to the UE in RRCConnectionReconfiguration message to be used by
UE to evaluate the condition for measurement reporting.
• pCIList – This parameter indicates a list of PCIs dedicated for HeNB open cells under a LTE frequency. Max=32
• qOffsetCell – This parameter indicates the offset between the macro/metro serving cell and the HeNB open
neighbor cell. This parameter must be set if the HeNB open neighbor cells are to be included in SIB4 or SIB5 for
eNB to HeNB open cell reselection.
• s1HoTimersConfId – This parameter points to the instance of S1HoTimerConf used for eNB to HeNB open cell
handover. It can share the S1HoTimerConf instance used for handover between macro cells, or can have
dedicated instance used for eNB to HeNB open cell handover.

For event A3 configuration for intra-frequency mobility, event A3/event A5 configuration for inter-frequency
mobility, event A4 configuration for reactive load balance and preventive load balance, HeNB open cell
dedicated/shared carriers are treated the same by eMCTA as the eNB macro/metro dedicated carriers. However,
a HeNB open cell dedicated carrier should be assigned with a lower eMCTA priority. When an event A3/event
A5/event A4 UE measurement report is received with HeNB cell being the best reported cell, eNB will configure
UE to perform reportCGI measurement to obtain the ECGI of the HeNB cell if reportCGI is supported by UE and
eNB. The target cell ID contained in ECGI is to be included in the Handover Required message sent to MME. This
extra step is needed because eNB does not store per HeNB neighbor cell relation and so ECGI of a HeNB open
cell has to be obtained dynamically. Other steps in the handover procedure are the same as intra-
frequency/inter-frequency S1 handover procedures. X2 links are not supported between eNB and HeNB and so
X2 handover will not be triggered. eNB will configure UE to perform reportCGI measurement if all of the following
conditions are met:
• If mobility towards HeNB is enabled (refer to eNB to HeNB intra-frequency/inter-frequency mobility enable
rules)
• One of the following conditions is met:
o If UE supports using autonomous gaps to acquire SI of neighbor cell (UE EUTRA-Capability IE parameters
intraFreqSI-AcquisitionForHO-r9 is set to ‘supported’ and/or interFreqSI-AcquisitionForHO-r9 is set to
‘supported’), and eNB allows UE to use autonomous gaps for reportCGI measurement (Enb::spare15 bit 2 is set
to ‘1’), UE will be configured to use autonomous gaps to perform reportCGI measurement
o Otherwise, if UE supports using long DRX cycle for ANR measurements (FGI bit 5 is set, FGI bit 17 or FGI 18 is
set depending on whether it is for intra-frequency or inter-frequency reportCGI) and UE does not have VoIP
bearer or GBR bearer established, UE will be forced into DRX to perform reportCGI measurement

Step 1, UE is configured to perform intra-frequency event A3 measurement at cell entry or to perform inter-frequency event A5/event A3
measurement when UE enters A2_CA area, or to perform event A4 measurement for reactive offloading/preventive offloading. When UE is
configured to perform measurement on a HeNB open cell, the corresponding
LteNeighboringOpenOrHybridHeNBCellLayerRelation::cellIndividualOffset should be provided if it is not set to null.
Step 2, When UE measurement report is received:
• If the best reported cell is a macro/metro cell, eNB will proceed with existing handover procedures
• If the best reported cell is a HeNB open cell (reported PCI belongs to LteNeighboringOpenOrHybridHeNBCellLayerRelation::pCIList of the
corresponding frequency):
o If UE can be configured to perform reportCGI measurement , eNB will configure the UE to perform report CGI measurement on the
reported HeNB open cell
o Otherwise, if there is a macro/metro cell reported in the UE measurement report, eNB will proceed with the existing handover procedure
to perform handover to the macro/metro cell. If there is no macro/metro cell reported in the UE measurement report, the measurement
report is ignored
Step 3, if a HeNB open cell is reported as the best cell, and UE can be configured to perform reportCGI measurement, eNB will configure UE
to perform reportCGI measurement.
Step 4, UE acquires ECGI and TAC of the neighbor HeNB open cell.
Step 5, UE sends measurement report to eNB with ECGI and TAC of the neighbor HeNB open cell. If eNB fails to receive the reportCGI
measurement report, or the cgi-info IE received is incomplete, or csg-identity is included in the measurement report (indicating the target
cell is not an open cell), handover to HeNB open cell cannot proceed (remaining steps in the call flow will not be executed). In this case,
eNB will wait for the next UE measurement report triggered by the existing UE measurement configurations.
Step 6, HANDOVER REQUIRED message is sent to MME with target cell ID received from reportCGI measurement report. Since data
forwarding is not supported for handover from eNB to HeNB, Direct Forwarding Path Availability IE will not be set.
Step 7, HANDOVER REQUEST message is sent from MME to HeNB GW (If HeNB is directly connected to MME, MME directly sends
HANDOVER REQUEST message to HeNB).
Step 8, HANDOVER REQUEST message is forwarded to HeNB.
Step 9, HeNB responses with HANDOVER REQUEST ACKNOWLEDGE message (If HeNB is directly connected to MME, HeNB directly sends
HANDOVER REQUEST ACKNOWLEDGE message to MME.).
Step 10, HANDOVER REQUEST ACKNOWLEDGE message is forwarded to MME.
Step 11, HANDOVER COMMAND message is sent from MME to source eNB.
Step 12, RRCConnectionReconfiguration message is sent from source eNB to UE to trigger handover to the target HeNB open cell.

LR13.3 L170745 feature: Neighbor cell classification and mobility counters for HetNet
It is important to estimate the HO success rate per couple of cellKind for the network optimization.
lteCell::CellKind is used by the eNB when sending outgoing HO REQUEST

LR13.3 L170745 feature: Neighbor cell classification and mobility counters for HetNet

eNB supports inter eNB intra or inter frequency HO for radio reason of a call configured with CA, using existing
triggers
In the target cell, CA eligibility criteria are verified. If the candidate UE is eligible to CA, the UL criterion is
configured in the modem. UL criterion is used to configure or not CA in target cell.

UE resources are set-up assuming “legacy” single carrier operation
RRC Reconfiguration deconfigures SCell by setting of the SCell index to identify the SCell to be released
The handover is then executed and completed as for “legacy” non-CA UE.

CA configuration in the target cell upon fulfillment of UL criterion.

The event B2 measurement based redirection offers the guarantee to have selected a target cell offering good
radio condition (in contrast to blind redirection)
Compared to Redirection, PS handover from LTE to UTRAN has the advantage of allocating the resources in
UTRAN prior to the execution of PS handover

EXECUTION PHASE:
During the previous phase (selection of the control procedures for mobility), the source ENB has decided to
initiate a EUTRA-to-UTRA-FDD redirection to the target access network (UTRA-FDD).
The source ENB will give a command to the UE to re-select a cell in the target access network via the RRC
CONNECTION RELEASE. The RRCConnectionRelease message is used to command the release of an RRC
connection.
The eNodeB builds the RRCConnectionRelease message with the redirectionInformation, so that the UE
select a suitable cell on the UTRA-FDD frequency indicated by the redirectionInformation in accordance with the
usual cell selection process.
The eNodeB may provide IRAT/frequency priority information during RRCConnectionRelease message with
the redirectionInformation.
The eNodeB builds the RRCConnectionRelease message; with the idleModeMobilityControlInfo (optional) so
that the UE stores the cell reselection priority information provided by the idleModeMobilityControlInfo; or
without the idleModeMobilityControlInfo (optional) so that the UE applies the cell reselection priority information
broadcast in the system information
The source ENB sends an S1AP UE CONTEXT RELEASE REQUEST message to the source MME. This message
is sent by the eNB to request the release of the UE-associated S1-logical connection over the S1 interface: with
‘Cause IE’ set to ‘Inter-RAT redirection’ to indicate the reason for triggering the UE Context Release Request
procedure.
Upon receipt of the Redirection Information received in the RRC Connection Release message, the UE
leaves EUTRA-FDD old cell and start access UTRA-FDD new cell.

COMPLETION PHASE:
Upon receipt of the S1AP UE CONTEXT RELEASE REQUEST, the source MME sends a S1AP UE CONTEXT
RELEASE COMMAND message to the Source eNodeB.
The completion in the ENB ends upon receipt S1AP UE CONTEXT RELEASE COMMAND and sending by the ENB
to the source MME of a S1AP UE CONTEXT RELEASE COMPLETE of a or upon guard timer expiration.

Comparing with redirection mechanism,PS handover from LTE to UTRAN has the advantage of allocating
the resources in UTRAN prior to the execution of PS handover. Besides, PS handover has the capability of data
forwarding from source LTE to target UTRAN. It thus reduces the service interruption time and ensures better
performance to packet loss sensitive services, such as VoIP.
When eNB receives a UE event B2 or event B1 (for CS fallback) measurement report with measurement
purpose set to ‘Mobility-Inter-RAT-to-UTRA’, and with valid reported cells (reported PhysCellIdUTRA-FDD
Corresponds to UtraFddNeighboringCellRelation::physCellIdUTRA of an instance of UTRA neighbor), LTE to
UTRAN PS handover procedure will be triggered if all of the following conditions are satisfied:
PS handover to UTRAN is allowed for the eNB (ActivationService::isPsHoToUtraAllowed is set to ‘True’)

UE is capable to support PS handover to UTRAN
A RNC controlling one or more reported candidate cells (Controlling RNC is pointed to by
UtraFddNeighboringCellRelation::rncAccessId) is capable to support PS handover
(RncAccess::psHandoverUtraEnabled is set to ‘True’)

If PS handover is to be performed, eNB will select the best UTRA cell reported by the UE that are allowed to
be handover to as the PS handover target cell. The selected target cell should not in the
HandoverRestrictionList for the UE (received from MME) and the controlling RNC of the cell should have
RncAccess::psHandoverUtraEnabled set to ‘True’.
eNB will send a Handover Required message to the MME and start timer TS1relocprep with duration
PsHoToUtraTimersConf::tS1RelocPrepForPsHandoverToUtra (the PsHoToUtraTimersConf instance is
pointed to by the RncAccess::psHoToUrtaTimerConfId associated with the selected
UtraFddNeighboringCellRelation).

If UE Context Release Command is received from MME, PS handover is successful. eNB will send a UE
Context Release Complete to MME. eNB will stop timer TS1relocoverall and release UE context and associated
resources.
If timer TS1relocoverall expires, eNB considers the UE to have lost radio coverage and will trigger the
release of all UE associated resources by sending an UE Context Release Request to MME and release all UE
associated resources in eNB.

Feature 105474
If reservation of resources in the target UTRAN cell is successfully completed, MME will send a Handover
Command message to eNB. eNB will then stops the timer TS1relocprep and enter the handover execution
phase.
If timer TS1relocprep expired, or eNB receives a S1 handover Preparation Failure message, handover
preparation fails. In this case, if PS handover preparation was due to a CS fallback request, eNB will trigger a
measurement-based redirection to UTRAN. Otherwise, the UE measurement report will be ignored.
Some of the parameters included in the Handover Required message are populated from the configurable
parameters:
Target RNC-ID
Direct Forwarding Path Availability (RncAccess::directFwdPathAvailability)
Source to Target Transparent Container includes: Cell-ID (UtraFddNeighboringCellRelation::cId)

LR13.1 L115393 feature: LTE to UTRAN (FDD) Small Cell Mobility Support.
Remark: In the case of LTE macro/metro to HeNB, full mobility was requested to ensure service continuity for
VoIP, the HeNB is supposed to be VoIP capable; thus both idle and active mobility are supported. In 3G, the
small cells that we deploy do not support neither VCC nor VoIP.
This feature provides mobility from LTE layer (macro/metro eNB) towards WCDMA FDD HNB:
Redirection-based only
HNB Layer with reserved range of PSC. Supports co-channel and dedicated carrier
Open HNB: Triggered by radio condition and reactive offload
Closed HNB: Trigger by CSG Proximity indication (not supported in LR13.1)
Voice continuity (CSG/SRVCC) excluded
Closed access mode: The HNB belongs to one or more specific Closed Subscriber Groups (CSGs) identified by
CSG Identifiers (CSG IDs). Only UEs which have the corresponding CSG ID included in their CSG subscription
list are allowed access.
The wording ‘Small cells’ includes the cells of the 3G UTRA Home NodeB (HNb), the LTE Home eNodeB (HeNb)
and the metro eNodeB. HNb and HeNb are Femto equipment connected to the Small Cell Gateway (or Femto
Gateway) while the metro eNodeB acts as a pico eNodeB and is connected to the MME.
The definitions of picocells and femtocells can be summarized as follows:
• A pico eNodeB (Alcatel-Lucent Metro eNB) usually controls multiple small cells which are planned by the
network operator in a similar way as the macrocells. Picocells are often mounted at low elevation and operate at
lower power than the macrocells. A HNB/HeNB controls only one cell and is deployed by the customer (the
registered owner), usually without planning.
• Femtocells are typically Closed Subscriber Group (CSG) cells accessible only to a limited group of users; in
contrast, picocells are usually open to all users (Open Subscriber Group (OSG)) but may offer preferential
treatment to some users, e.g. to the staff of a particular establishment.
• The transmission power of femtocells is lower, being designed typically to cover a house or apartment.
Picocells usually operate with a higher transmission power to cover an enterprise, mall or other hotzone, or
simply to extend macrocellular coverage.
• Femtocells do not necessarily have the same network interfaces as macro eNodeBs, whereas pico eNodeBs
follow the same logical architecture principles as macro eNodeBs.

Support of mobility from LTE macro/metro cell to an ALU UTRAN FDD open small cell (resident or enterprise
Femto). An UTRAN FDD open small cell can be accessed by all UE without access control imposed in MME. To
enable mobility from LTE to UTRAN FDD open small cell,
ActivationService::isMobilityToUtranOpenSmallCellEnabled must be set to ‘True’.
Note that the LTE to UTRAN FDD CSG (Closed Subscriber Group) small cell is not supported in LR13.1.
UTRAN FDD small cells can have their own dedicated carriers or can share the carriers with UTRAN FDD macro
cells. A UTRAN FDD small cell can only be assigned to one of the PSC (Physical Cell-ID for Small Cell) dedicated
to UTRAN FDD small cells defined under UtraFddneighboringSmallCellLayerRelation::
pciUtraFddForOpenSmallCellList. Unlike UTRAN FDD macro cells where each of them uses a unique PSC, multiple
small cells in the same coverage area are allowed to share the same PSC. For this reason, a LTE cell does not
maintain per UTRAN FDD open small cell neighbor relation. Instead, information of all small cells under a UTRAN
FDD frequency is maintained in UtraFddNeighboringSmallCellLayerRelation MO. This will not cause a problem
since PS handover is not supported for mobility from LTE to UTRAN FDD small cells. Only redirection (blind or
measurement-based) is supported with L115393.

The mobility functionalities supported by L115393 for LTE to UTRAN FDD small cell carrier (dedicated or shared) include:
• Blind redirection when UE enters A2_Floor area: When UE enters below serving floor area (A2_Floor measurement report is received from the UE), if a UTRAN
FDD small cell dedicated carrier or a shared carrier is the best carrier selected by eMCTA, UE will be directed to perform blind redirection towards the carrier.
• Measurement based redirection when UE enters A2_CA area: When UE enters coverage alarm area (A2_CA measurement report is received from the UE),
eMCTA may select UTRAN FDD small cell dedicated carriers or shared carriers as IRAT candidates for UE to perform event B2 measurements with
measurementPurpose = mobility-inter-RAT-to-UTRA. If the call does not have a VoIP bearer and is not for preventive offloading, eNB will trigger the UE to
perform a redirection to the measured carrier (otherwise PS HO or SRVCC will be triggered to the first measured UTRAN FDD macro cell if possible)
• Measurement Based or Blind Redirection for reactive load balancing: If a UE is selected as a reactive off-load candidate, and if the small cell dedicated or
shared carriers are selected by eMCTA as reactive offloading measurement based candidate carriers, eNB will configure UE to perform event B1 (or event B2 if
UE does not support event B1) measurement with measurementPurpose = mobilit-inter-RAT-to-UTRA.
UE measurement report is treated similar to the case when UE enters A2_CA area and event B2 measurement report is received.
Following is a list of mobility functionalities that are not supported by L115393 for LTE to UTRAN FDD small cell.
• PS handover to UTRAN FDD small cell is not supported. If RncAccess::isSmallCellGateway = ‘True’, RncAccess::psHandoverUtraEnabled must be set to ‘False’
under the same instance of the MO.
• SRVCC to UTRAN FDD small cell is not supported. If RncAccess::isSmallCellGateway is set to ‘True’, RncAccess::srvccType must be set to ‘disabled’ under the
same MO.
• CSFB to UTRAN FDD small cell. CSFB to UTRAN FDD is not supported for small cell dedicated or shared carriers.
For each instance of UtraFddNeighboringFreqConf that includes an UtraFddNeighboringSmallCellLayerRelation MO, ServiceTypePriorityConf:: eMctaPriority must
be set to ‘serviceOrQci-notallowed-in-RAT-carrier’ for all settings of ServiceTypePriorityConf::serviceType including ‘csfbByIdleUE’, ‘emergencyCsfbByIdleUE’,
‘csfbByConnectedUE, and emergencyCsfbByConnectedUE’.
• RIM for system information and RIM for cell load procedures through small cell gateway are not supported. If RncAccess:: isSmallCellGateway is set to ‘True’,
both RncAccess::rimForUtraSiEnabled and RncAccess::rimForCellLoadEnabled must be set to ‘False’ under the same MO.
• Preventive offloading to small cell dedicated carrier is not supported. Since PS handover or SRVCC ‘PS and CS’ are used for preventive offloading to UTRAN FDD
carriers, eMCTA will not select an UTRAN FDD small cell dedicated carrier as preventive offloading candidate for the reason if RncAccess::isSmallCellGateway is
set to ‘True’, RncAccess::psHandoverUtraEnabled is set to ‘False’ and RncAccess::srvccType is set to ‘disabled’ under the same MO.
• Mobility of VoIP calls to UTRAN FDD small cell is not supported. Since a candidate for VoIP mobility must support either VoIP or SRVCC ‘PS and CS’, eMCTA will
not select UTRAN FDD small cell dedicated carriers for VoIP call mobility because they do not support VoIP
(UtraFddNeighboringSmallCellLayerRelation::voiceOverIpCapability is set to ‘incapable’) and they do not support SRVCC (If RncAccess::isSmallCellGateway is set
to ‘True’, RncAccess::srvccType must be set to ‘disabled’ under the same MO).
• UTRAN ANR for UTRAN FDD small cell is not supported. When UTRAN FDD ANR is activated, UE will not be configured to perform PCI search for the carriers
dedicated to UTRAN FDD small cells. This can be achieved by not configuring ANR measurement for the dedicated small cell frequency (not configuring
MeasurementIdentityConf instance with MeasObjectLink which points to MeasObject instance of dedicated small cell frequency and measurementPurpose set to
‘Automatic-Neighbor-Relation’). For UTRAN FDD small cell shared frequency, if UE measurement report contains a PSC that belongs to UTRAN FDD small cells (if
the reported PSC belongs to the list of UtraFddNeighboringSmallCellLayerRelation::pciUtraFddForOpenSmallCellList), the measurement report will be ignored and
no UTRAN FDD neighbor relation will be set up for this neighbor.

The parameters are provided per UTRA layer and not per cells relationship because several UTRA HNB cells can
have the same PSC.
UtraFddNeighboringSmallCellLayerRelation MO includes the following parameters:
• pciUtraFddForOpenSmallCellList: provides a list of UTRAN PCI (PSC) dedicated to UTRAN FDD small cells. This
parameter should be set only if UTRAN FDD small cells are deployed in the area with this frequency and
ActivationService::isMobilityToUtranOpenSmallCellEnabled is set to ‘True’. Max size=32
• rncAccessId
• ueTimerUtraFddSib3Acquisition (this parameter is used for UTRAN FDD CSG small cells, and is not used in this
release)
• voiceOverIpCapability: indicates the VoIP capability for the small cells under this layer.
Another new parameter related to the UTRAN FDD small cell neighbor, isSmallCellGateway, is added under the
RncAccess MO. This parameter indicates whether a rncAccess is a small cell gateway.

The event B2 measurement based redirection offers the guarantee to have selected a target cell offering good
radio condition (in contrast to blind redirection)
Compared to Redirection, CCO from LTE to Geran has the advantage of allocating the resources in Geran prior to
the execution of CCO

LTE to GERAN mobility is done through CCO. The PS HO is not supported. The HO Command is not sent by the
MME (as for PS HO) but by the eNB during the CCO procedure.
NACC procedure is optional during CCO. The eNB retrieves the System Information broadcasted in each of the
neighbor GERAN cell through MME. The information will be included in Cell Change Order sent to UE when it is
released from eNB and directed to GERAN. This procedure is to speed up the UE call setup in GERAN.
CCO is triggered by eNB receives event B2 Measurement (or B1 for CS fallback) report with measurement
purpose set to ‘Mobility-Inter-RAT-to-GERAN’. If CCO is activated in serving cell and supported by UE, CCO
procedure is launched, otherwise redirection to GERAN is triggered.
eNB sends Mobility From EUTRAN Command (carrierFreq, phyCellId, SysInfo) to UE and starts timer
tMobilityFromEutraCCO
If UE Context Release Command is received, CCO procedure is completed. Otherwise eNB sends a UE Context
Release Request to MME (eNB considers the UE to have lost radio coverage)

HRPD: High Rate Packet Data (CDMA)
(T)LA4.0 supports:
LTE to HRPD blind redirection and
event B2 measurement based based HRPD redirection
Measurement based redirection is more reliable than blind redirection because the target frequency has been
measured by the UE before the redirection. Blind redirection is used if UE does not support event B2 or if
measurement based is not available in the eNB.

Circuit switched (CS) fallback is a function that moves UE from LTE network to a different RAT (UTRAN, GERAN, 1xRTT) that
supports CS voice service when a CS voice call needs to be set up. Comparing with searching for a different RAT/carrier by a
UE on its own for CS voice call setup, CS fallback has the advantage to speed up UE for inter-RAT search. This is because the
CS fallback mobility procedures provide UE with more or less target RAT information before it is released from the source.
In LA3.0, three CS fallback features are supported in eNB. They are CS Fallback to UTRA for Voice Calls (FRS-92025), CS
Fallback to GERAN for Voice Calls (FRS92026) and Support of enhanced RRC Releases redirection for CSFB to UTRAN
(FRS116051). In LA4.0, a new enhanced redirection procedure is supported for CS fallback to either UTRAN or GERAN
(FRS114190, CSFB Enhancement to UTRAN/GERAN – Enhanced Redirection and PSHO).
The LA3.0 enhanced redirection is limited to be used for CS fallback to UTRAN and the system information provided to UE in
release/redirection has to be manually provisioned by operators. The enhanced redirection in LA4.0 can be used for all LTE to
UTRAN/GERAN redirections including CS fallback redirection and non-CS fallback redirection, except for the case when
redirection is triggered by event A2 ‘Below-Serv’ (blind redirection is used in this case)
To perform a CS fallback procedure, UE must be capable and be configured to use CS fallback. For a UE that supports CS
fallback and IMS, it can be configured to one of the following modes: ‘CS Voice only’, ‘CS Voice preferred and IMS PS Voice
as secondary’, ‘IMS PS Voice preferred and CS Voice as secondary’, or ‘IMS PS Voice only’. Based on the configuration setting
of the UE and whether the LTE network supports VoIP emergency calls (only a Release 9 network supports emergency VoIP
calls), UE may request CS fallback when a voice call is to be set up and one of the following conditions is true:
UE is set to ‘CS Voice preferred’ or ‘CS Voice only’ and needs to make a voice call or an emergency voice call.
UE is set to ‘IMS PS Voice preferred’, ‘CS Voice preferred’ or ‘CS Voice only’ and a mobile terminated CS voice call is to
be set up.
UE is set to ‘IMS PS Voice preferred’ and needs to make an emergency voice call, but the LTE network does not
support VoIP emergency calls.
If CS fallback is not possible (either UE or network does not support CS fallback, or UE fails to attach to LTE network) when
UE needs to set up a CS voice call, it will search for a different RAT that supports CS voice all without the help from the LTE
network.

The eNB is able to automatically retrieve system information from the neighbor UTRAN/GERAN cells through RIM
procedures when the enhanced redirection is enabled by
(ActivationService::isCsfbEnhancedRedirectionAndPsHoAllowed is set to ‘True’); this parameter replaces the
LA3.0 enhanced redirection (ActivationService::isCsfbEnhancedRedirectionEnabled must be set to ‘False’)
For enhanced redirection, since eNB will provide system information of the UTRAN/GERAN cells under the
redirected carrier to the UE when it is released from LTE and redirected to the UTRAN/GERAN carrier, UE does
not need to listen to the broadcast channels of the UTRAN/GERAN candidate cells. Call setup delay in the target
UTRAN/GERAN cell is thus reduced. The enhanced redirection is therefore preferred over the basic redirection
where system information is not provided when UE is released. Although only release 9 UE that supports e-
RedirectionUTRA-r9/e-RedirectionGERAN-r9 capability can make use of the system information of the
UTRAN/GERAN target cells, eNB will use enhanced redirection instead of basic redirection whenever system
information is available for redirection assistance. It does not check UE capability. For a UE that does not support
e-RedirectionUTRA-r9/e-RedirectionGERAN-r9 capability, it simply ignores the system information received.

LA4.0 L114190 – CSFB enhancement to UTRAN/GERAN, enhanced Redirection and PS Handover
This feature provides system information of the UTRAN/GERAN cells when it is released from LTE and redirected
to UTRAN/GERAN carrier. The enhanced redirection functionality can be used for CSFB redirection or non-CSFB
redirection from LTE to UTRAN/GERAN, except for the case when the redirection is triggered by event A2 ‘Below-
Serving-Floor’ (blind redirection is triggered in this case)
Only release 9 UE that supports e-RedirectionUTRA-r9/e- RedirectionGERAN-r9 capability can make use of
system information of UTRAN/GERAN cells. Release 8 UE will ignore the system information
eNB is able to automatically retrieve system information from the neighbor UTRAN/GERAN cells through RIM
procedures
Dependency:
To support Re-direction enhancement
UE to support enhanced re-direction behavior
ePC core and 2G/3G network to support System Information exchange procedure using RIM protocol
To support PSHO enhancement
ePC and 3G network to support CSFB and emergency indicator
UTRAN to support special admission handling based on CSFB and emergency indicator

You can for instance allow PSHO for CSFB only for Emergency call (basic or enhanced Redirection will be done
for non-emergency call)
You can also allow CSFB procedure based on UE state: when UE is Idle, Redirection will be done (basic or
enhanced) and PSHO will be done when UE is in Active state (existing on-going call before new voice call)

In case of on-going data session, the order is PS HO, enhanced redirection, basic redirection. If no data session,
the order will be enhanced redirection, PSH, basic redirection.

The SI update can be done for instance once a day during the night
RIM procedure is used to retrieve the System Information of a UTRAN neighbor cell to be included in the RRC
Connection Release message (during the Redirection procedure). It includes UTRAN SysInfo transfer
initiation/update/stop/end procedures.

Redirection assistance means that target cell System Information will be provided in the RRCConnectionRelease
message
The following conditions are pre-supposed:
At least one S1 link towards a MME supporting the PLMN of UTRAN cell is successfully setup
Administrative state of the RNC controlling the neighbor UTRAN cell is unlocked: administrativeState
is set to ‘unlocked’
(rncAccess)

After eNB sends S1-ENB Direct Information Transfer to the MME for system information of the neighbor UTRAN
cell (step 3), it will start a timer Trir with duration UtraSiTimersConf::tS1EnbDirectInfoTransferTrir waiting to
receive the S1-MME Direct Information Transfer.
If S1-MME Direct Information Transfer is received (step 8), eNB will store the received System Information of
the neighbor UTRAN cell and stop the timer Trir. eNB will start a new timer with duration
UtraSiTimersConf::timeToWaitForEnbDirectInfoTransfer waiting for the update of the System Information.
If Trir expires, eNB will retry the procedure for up to three times. If all tries fail, eNB will raise an alarm
indicating ‘UTRAN SYS info transfer initiation failure’.

After eNB initiates the RIM procedure, it expects the RNC controlling the neighbor UTRAN cell to send System
Information periodically or when System Information is modified in the RNC for the neighbor UTRAN cell
When S1-MME Direct Information Transfer is received with updated System Information, eNB will renew the
stored System Information and restart the timer with duration
utraSiTimersConf::timeToWaitForEnbDirectInfoTransfer

eNB may stop the initiated RIM procedure for the following reasons:
Enhanced redirection is deactivated (ActivationService::isCsfbEnhancedRedirectionAndPsHo is set to ‘false’)
RIM is disabled for the RNC controlling the neighbor UTRAN cell (RNCAccess::rimForUtraSiEnabled is set to
‘false’)
The neighbor UTRAN cell is removed from the UTRAN neighbor list or is removed from the UTRAN
neighbour list that supports enhanced redirection
(UtraFddNeighboringCellRelation::isCellIncludedForRedirectionAssistance is set to ‘false’)
Timer expires with duration UtraSiTimersConf::timeToWaitForEnbDirectInfoTransfer. In this case, the stored
System Information is considered out of date and eNB will restart the initiating procedure as described in
UTRAN System Information Initiation
When eNB is to stop the RIM procedure, it will stop timer with duration
UtraSiTimersConf::timeToWaitForEnbDirectInfoTransfer if it is running and remove the stored System
Information of the neighbor UTRAN cell.
eNB will then send a S1-eNB Direct Information Transfer to stop the RIM procedure, and start timer Trir waiting
to receive the S1-eNB Direct Information Transfer from MME in response to the request to stop the RIM
procedure
indicating ‘UTRAN SYS info update stop failure’

This procedure is used by the RNC controlling the neighbor UTRAN cell to stop the RAN Information Send
procedure initiated by the eNB. One possible trigger of this procedure is that a neighbor cell is deleted from the
UTRAN network.
When eNB receives the S1-MME Direct Information Transfer to end the RIM Information Send procedure (Figure
UTRAN System Information Update End), it will:
Stop the timer with duration UtraSiTimersConf::timeToWaitForEnbDirectInfoTransfer if it is running
Remove the stored system information of the neighbor UTRAN cell
Raise an alarm indicating ‘UTRAN SYS info update end’
Restart timer with duration UtraSiTimersConf::timeToWaitForEnbDirectInfoTransfer. When this timer
expires, eNB will restart the UTRAN System Information Transfer Initiation procedure.

The following conditions are pre-supposed:
At least one S1 link towards a MME supporting the PLMN of GERAN cell is successfully setup
Administrative state of the RNC controlling the neighbor GERAN cell is unlocked: administrativeState
is set to ‘unlocked’
(bscAccess)

After eNB sends S1-ENB Direct Information Transfer to the MME for system information of the neighbor GERAN
cell (step 3), it will start a timer Trir with duration NaccTimersConf::tS1EnbDirectInfoTransferTrir waiting to
receive the S1-MME Direct Information Transfer.
If S1-MME Direct Information Transfer is received (step 9), eNB will store the received system information of the
neighbor GERAN cell and stop the timer Trir. eNB will start a new timer with duration
NaccTimersConf::timeToWaitForEnbDirectInfoTransfer waiting for the update of the system information.
indicating ‘GERAN SYS info transfer initiation failure’.
The other procedures (SI Update, SI Update Stop and SI Update End) are similar to UTRAN and not described
here.

LTE natively supports VoIP only using IMS services. However, in case IMS services are not deployed from the
start, LTE also supports a Circuit-Switched FallBack (CSFB) mechanism which allows CS voice calls to be handled
via legacy RATs for UEs that are camped on LTE.
CSFB allows a UE in LTE to be handed over to a legacy RAT to originate a CS voice call. This is supported by
means of an interface, referred to as SGs, between the MME and the Mobile Switching Centre (MSC) of the
legacy RAT shown in Figure. This interface allows the UE to attach with the MSC and register for CS services
while still in LTE. Moreover it carries paging messages from the MSC for incoming voice calls so that UEs can be
paged over LTE. The network may choose a handover, cell change order, or redirection procedure to move the
UE to the legacy RAT.
The Figure shows the message flow for a CSFB call from LTE to UMTS, including paging from the MSC via the
SGs interface and MME in the case of UE-terminated calls, and the sending of an Extended Service Request NAS
message from the UE to the MME to trigger either a handover or redirection to the target RAT in the case of a
UE-originated call. In the latter case, the UE then originates the CS call over the legacy RAT using the procedure
defined in the legacy RAT specification.

CS fallback is a function that moves UE from LTE network to a different RAT (UTRAN, GERAN, CDMA) that
supports CS voice service when a CS voice call needs to be setup. UE may request CS fallback when a voice call
is to be set up and when CS voice call is preferred.
CS fallback utilizes the existing inter-RAT procedures including PS handover to UTRA, Cell Change Order (CCO)
to GERAN and measurement based/blind redirection to UTRA or GERAN to move UE from LTE to different
RAT/carriers for CS voice calls.
CS fallback starts when MME receives an Extended Service Request from the UE requesting CS fallback.
CS fallback will be triggered when eNB receives CSFallbackIndicator in:
Intitial Context Setup Request message at call setup
UE Context Modification Request during a data call

The decision on which candidate RAT/carrier to perform CS fallback is made by eMCTA framework based on
the priority of each RAT/carrier neighbor configured by the operator for csFallback or emergencyCallCsFallback
purpose.
A set of filters including UE capability filter, network capability filter, etc and HORestrictionList for the UE
(received from MME) are used to remove the RAT/carriers that are not supported by the UE or network for CS
fallback from the prioritized RAT/carrier neighbor list. The highest priority RAT/carrier after the filtering is
selected as the target RAT/carrier for CS fallback.
If the selected target carrier is a UTRA carrier:

eNB will configure the UE to perform event B1 or event B2 measurement to the UTRA carrier if UE supports
it. eNB will trigger a PS handover to UTRA after UE measurement report is received for CS fallback to UTRA.
Refer to CS Fallback Triggered by PS handover.
Otherwise, eNB will perform the LTE to UTRA blind redirection procedure to move the UE to UTRA for CS
fallback. CS Fallback Triggered by Redirection.
Whenever redirection from LTE to UTRA is performed for CS fallback except in the case when redirection is
triggered by UE entering ‘Below-Serving-Floor’ area, target cell System Information will be provided in the
RRCConnectionRelease message for redirection assistance if following conditions are met.

If a UTRAN carrier is selected by eMCTA as CS fallback target:
eNB will configure the UE to perform event B1 (or event B2 if UE does not support B1) measurement to the
UTRAN carrier
If a UE measurement report is received for CS fallback to UTRAN, PS handover will be triggered
Otherwise eNB will perform the LTE to UTRAN enhanced (SysInfo received) or blind redirection procedure to
move the UE to UTRAN for CS fallback
The Handover Required message provides info about the applicable inter-RAT UE capabilities as well as info
about the currently established bearers.
In case of CS fallback to Utran by PS handover, SRB2 and at least one DRB must be set up before triggering the
handover (it will already have been for a UE Context Modification Request, but not for an Initial Context Setup
Request)
(1) Security must be activated and SRB2 and at least one DRB must be set up before triggering the HO.
It will already have been for a UE context modification, but not for an initial context setup.
(2) UTRA capabilities will have to be requested in the case of CS FB triggered at initial context setup.

The mobility from LTE to GERAN is done through Cell Change Order (CCO). PS Handover is not supported. The
CCO can be network assisted (NACC – Network Assisted Cell Change) which consists in providing additional
SysInfo data in the Mobility From EUTRA Command. The difference between handover and CCO is that the
source eNodeB does not request the MME to prepare the handover but prepares it himself. Mobility to GERAN is
performed only after security has been activated.
If a GERAN carrier is selected by eMCTA as CS fallback target:
eNodeB will configure the UE to perform event B1 (or events B2 if UE does not support event B1)
measurement to the GERAN carrier
If a UE measurement report is received for CS fallback to GERAN, CCO will be triggered
Otherwise eNodeB will perform the LTE to GERAN enhanced or blind redirection procedure to move the UE
to GERAN for CS fallback.

CSFB Redirection is used in case of PS handover (UTRA) or CCO (GERAN) not applicable.
The MME will redirect the call to the GERAN network.
In case of enhanced Redirection, the RRC Connection Release includes information related to the SysInfo of the
target UTRAN/GERAN cell (retrieved during the RIM procedure)

Parameter dtmCapability (GeranNeighboringCellRelation)
This parameter is used to indicate whether a GERAN neighbor cell supports dual transfer mode (DTM). For a
GERAN cell that supports DTM, it allows simultaneous transfer of circuit switched voice and packet switched data
over the same radio channel
For CS fallback to GERAN with CCO, if both UE and target GERAN cell support DTM, in the UE-Context-Release-
Request sent to MME, eNB will include the cause ‘cs-fallback-triggered’. If either UE or the target GERAN cell
does not support DTM, in the UE Context Release Request sent to MME, eNB will include the cause ‘ue-not-
available-for-ps-service’
For CS fallback to GERAN with enhanced/basic redirection, if UE and at least one GERAN neighbor cell under the
redirected carrier support DTM, in the UE-Context-Release Request sent to MME, eNB will include the cause ‘cs-
fallback-triggered’. If either UE or all of GERAN neighbor cells under the redirected carrier do not support DTM,
in the UE Context Release Request sent to MME, eNB will include the cause ‘ue-not-available-for-ps-service’.
The big difference is that the MME identifies DTM as a CS + PS HO and sends the voice to the MSC and the PS
bearer to the SGSN. The MME does a lot more synchronization for DTM HO than for non-DTM HO.

CS fallback to 1xRTT enables the delivery of CS-domain services when a UE is being served by the E-UTRAN.
The UE initiates 1xCSFB (e.g. to perform a 1xCS call origination or accept a 1xCS call termination) by using NAS
signalling to send a CSFB indication to the MME. The MME then indicates to the eNB that 1xCSFB is required,
which triggers the eNB to execute one of the following 1xCSFB procedures depending on network support and
UE capability:
- Rel-8 1xCSFB, characterized by RRC connection release with redirection to 1xRTT; (LR13.1 feature 134791)
- enhanced 1xCSFB, characterized by 1xRTT handover signalling tunnelled between the UE and 1xRTT network;
(134791) or
-dual receiver 1xCSFB, characterized by RRC connection release without redirection information. (LA05 feature
92024)
To perform 1xCSFB, eNB will select one of the three procedures based on UE capabilities, whether UE can be
configured for 1xRTT measurement, whether measurement report is received, and the enabled/disabled status
of the procedures.
To support single Rx UE to perform 1xRTT measurement, 134791 has some additional requirements for the
setting of SIB8.
Pre-registration to 1xRTT is required for all UE to perform 1xCSFB procedures in order to establish CS services
(e.g. originating and terminating voice calls) in the 1xRTT network. 134791 adds the mechanism for eNB to
support single Rx UE to perform pre-registration to 1xRTT through EUTRAN. Pre-registration applies only to Rel-
8 1xCSFB and enhanced 1xCSFB.
Since 1xRTT measurement is required for the enhanced 1xCSFB procedure and is preferred for the Release 8
1xCSFB procedure, 134791 supports UE measurement configuration to 1xRTT.
To perform 1xCSFB, UE must pre-registrate to 1xRTT. A dual Rx UE is able to camp in 1xRTT while it is active in
EUTRAN and so is able to directly registrate to 1xRTT and to directly receive 1xRTT paging. A single Rx UE,
however, is unable to camp in 1xRTT when it is active in EUTRAN. Network will need to provide the mechanism
for a single Rx UE to pre-registrate to 1xRTT and to receive 1xRTT paging. eNB will advertise this capability of
the eUTRAN Network by including CSFB-RegistrationParam1xRTT IE in SIB8. After receiving SIB8, UE will
determine if 1xCS pre-registration should be performed.

After a single Rx UE decides to pre-registrate to 1xRTT, idle UE will go through the RRC connection setup procedure with
MME. Before 1xRTT pre-registration can be done, UE must first send the CSFBParametersRequestCDMA2000 message (step
1) to request for 1xRTT parameters used to generate the pre-registration message.
In step 2, eNB responses with CSFBParametersResponseCDMA2000 message that includes ‘rand’ and mobilityParameters
with Auth = ‘01’ (Authentication is required.). ‘rand’ is the Random Challenge value generated by eNB periodically. It is used
for 1xRTT authentication during 1xCS registration, handover from EUTRAN to 1xRTT for enhanced1xCSFB. Since ‘rand’ is
changed periodically, UE will request 1xRTT parameters prior to each 1xRTT registration. The parameters used by eNB to
generate ‘rand’ are contained in Enb MO. The parameters used to populate mobilityParameters are contained in
OneXRttMobilityParameters MO and in OneXRttRegistrationParameters MO respectively.
In step 3, UE sends ULInformationTransfer message to eNB that contains the dedicatedInfoCDMA2000-1xRTT IE carrying the
1x Registration Message.
In step 4, eNB sends UPLINK S1 CDMA2000 TUNNELING message that contains ‘rand’ generated in eNB and the CDMA2000-
PDU IE passing the 1x Registration Message to MME over S1 interface. In the message, eNB will include the CDMA2000
Reference Cell ID (msdId + cellId + sectorNumber) provisioned under OneXRttReferenceCell MO. MME then passes the 1x
Registration Message and ‘rand’ to 1x network through S102 interface to a 1xCS IWS selected based on CDMA2000
Reference Cell ID. Since the 1x signaling message contained in the ULInformationTransfer message and the UPLINK S1
CDMA2000 TUNNELING message is transparent to eNB, eNB does not start a timer waiting to receive DOWNLink S1
CDMA2000 TUNNELING message after it sends the UPLINK S1 CDMA2000 message.
In step 5, after MME receives the response to the 1x Registration Message from 1x network, it sends the DOWNLINK S1
CDMA2000 TUNNELING message passing the response eNB.
In step 6, eNB sends the DLInformationTransfer message to UE carrying the response to the 1x Registration Message
received through MME. If pre-registration to 1xRTT is successful, UE will be able to trigger the 1xCSFB procedures to make
CS calls through 1xRTT.
Remark: Unlike CSFB over SGs interfaces (MSC-MME), for S102 there is no concept of a combined attach. So S102 operates
in a tunnel mode vs. the proxy mode on SGs. So for GERAN/UTRAN, if a CSFB UE does an LTE TAU, it will trigger a
LocationUpdate over SGs, i.e. a form of registration by proxy. But for S102, the TAU does not update anything over S102, we
need the UE to send an explicit registration over the tunnel (UU->S1->S102->A1). Functionally, the 1x MSC/IWS needs the
tunneled registration so it knows the MME to which it shall send any network initiated signaling such as Paging and SMS.

The Authentication and Key Agreement (AKA) mechanism performs authentication and session key distribution in Mobile
Telecommunications System networks. AKA is a challenge- response based mechanism that uses symmetric cryptography.
AKA is typically run in a UMTS IM Services Identity Module (ISIM), which resides on a smart card like device that also
provides tamper resistant storage of shared secrets.
AKA operation in detail:
1. A shared secret K is established beforehand between the ISIM and the Authentication Center (AuC). The secret is stored
in the ISIM, which resides on a smart card like, tamper resistant device.
2. The AuC of the home network produces an authentication vector AV, based on the shared secret K and a sequence
number SQN. The authentication vector contains a random challenge RAND, network authentication token AUTN,
expected authentication result XRES, a session key for integrity check IK, and a session key for encryption CK.
3. The authentication vector is downloaded to a server. Optionally, the server can also download a batch of AVs, containing
more than one authentication vector.
4. The server creates an authentication request, which contains the random challenge RAND, and the network
authenticator token AUTN.
5. The authentication request is delivered to the client.
6. Using the shared secret K and the sequence number SQN, the client verifies the AUTN with the ISIM. If the verification
is successful, the network has been authenticated. The client then produces an authentication response RES, using the
shared secret K and the random challenge RAND.
7. The authentication response, RES, is delivered to the server.
8. The server compares the authentication response RES with the expected response, XRES. If the two match, the user has
been successfully authenticated, and the session keys, IK and CK, can be used for protecting further communications
between the client and the server.
Two parameters under Enb MO are used by eNB to generate the authentication challenge parameter (rand) sent to UE and
to 1xRTT network. The two parameters are:
• randUpdateInterval – This parameter specifies the rand update interval for 1xCSFB. This parameter must be configured
with the same value for all eNBs to allow synchronization in rand determination. This parameter must be set if
ActivationService::isRel8CsfbTo1XRttEnable is set to ‘True’.
• seed – This parameter specifies the seed value for 3G 1X authentication. The parameter must be configured to the same
value for all eNBs to allow synchronization in rand determination. This parameter must be set if
ActivationService::isRel8CsfbTo1XRttEnable is set to ‘True’. It is a write only parameter and should be stored securely.

These parameters are used to populate the MobilityParameters contained in
CSFBParametersResponseCDMA2000 message Parameters under OneXRTmobilityParameters MO.
Additional information:
Parameter: localTimeOffset
This parameter indicates the Local Time Offset from Coordinated Universal Time (UTC) in units of 0.5 hour
including the effect of time zone and daylight savings time. The possible range is -12.0 hour / +12.0 hour with
increment of 0.5 hour:
• For a positive value of Local Time Offset from UTC, set the parameter to 2 * Local Time Offset from UTC
• For a negative value, set parameter to 64 + (2 * Local Time Offset from UTC)
For example, during Eastern Standard Time, Washington DC has an offset of -0.5 hours from UTC, the
parameter should be set to 54. During Eastern Daylight Time, it has an offset is -4.0 hours from UTC and the
parameter should be set to 56.

Each LTE cell is required to configure a 1xRTT reference cell which is needed for MME to rount the CDMA2000
tunnelling messages to the correct target system node, IWS/MSC. The MSCID parameter of the 1x reference cell
id is used for the MME to route to the correct IWS.
The primary use of the reference cell is that it becomes the virtual accessed cell for setting up connections. So in
all the normal places where the accessed cell is used by the CallP (eNB software) of the legacy system for
eCSFB, the reference cell is used. For example, to map from PCI to CGI when determining handover candidates.
The 1xRTT reference cell related parameters are under OneXRttReferenceCell MO.

To support 1xCSFB, SIB8 should be broadcast with parameters properly populated. The related IEs to be
included in SIB8 are listed below:
• systemTimeInfo - This field is required for single Rx UE to perform 1xRTT measurement.
• searchWindowSize – This field is required for systemTimeInfo to be included in SIB8.
• parameters1xRTT – This IE is included if OneXRttNeighboring::oneXRttInfoConfigured is set to ‘True’. The
following IEs are new to support 1xCSFB and should be set properly:
o CSFB-RegistrationParam1xRTT – This IE is required to indicate whether the UE should perform a pre-
registration to 1xRTT if it does not have a valid pre-registration. The parameters in this IE are populated by the
parameters under OneXRttRegistrationParameters MO
o longCodeState1xRTT – This field is required for enhanced 1xCSFB operation. It is populated by the
longCodeState generated in eNB with the same algorithm used in CDMA network.

To perform enhanced 1xCSFB and Release 8 1xCSFB procedures, eNB will configure UE to perform 1xRTT
measurements. This requires the SIB8 to broadcast all 1xCSFB required parameters, information on 1xRTT
neighbors are entered, and parameters to configure UE for 1xRTT measurement are properly configured.
The BandClass, Frequency, pnOffset parameters are described in a previous slide.

In addition to the SIB8 IEs listed above that are required to support 1xCSFB, feature L134791 also supports
broadcasting AC-BarringConfig1XRTT-r9 IE in SIB8. This IE is not related to 1xCSFB. It is used to notify UE
under LTE coverage the access barring information of the 1xRTT network. Whether to broadcast it in SIB8 is
independent of the 1xCSFB activation flag (regardless the setting of
ActivationService::isRel8CsfbTo1XRttEnabled) but is controlled by OneXRttAccessBarring::acBarringStatus. The
fields in ACBarringConfig1XRTT- r9 are populated by the parameters included in OneXRttAccessBarring MO.
The parameters included in OneXRttAccessBarring MO are used to populate the fields in AC-BarringConfig1XRTT-
r9 IE of SIB8. There is no automatic method for eNB to retrieve load information from 1xRTT network, operators
will need to populate the parameters in
OneXRttAccessBarring MO in order for the access barring information to be broadcast through LTE.

To support 1xRTT measurement, the following parameters should be configured:
• One instance of ReportConfigCDMA2000 MO with:
o triggerTypeInterRAT set to ‘periodicalForCsfbTo1XRtt’
o reportAmount set to ‘r1’
o reportInterval: when reportAmount is set to ‘r1’, reportInterval is not used but should be set to any allowed
value
• One or multiple instances of MeasObjectCDMA2000 MO (The maximum number of MeasObjectCDMA2000
instances configured in a eNB is limited by eNB configuration model that allows up to 2 1xRTT bands and up to 3
frequencies per band to be configured for one LteCell) with:
o bandClass set to the value of ‘bandClass’ in an instance of OneXrttBandClassConf MO
o carrierFreq set to the value of ‘frequency’ in an instance of OneXRttNeighboringPerCarrier MO
• One or multiple instances of MeasurementIdentityConf MO with:
o measurementPurpose set to ‘Report-Strongest-Cells-For-CsfbTo1XRtt’
o measObjectLink pointing to an instance of MeasObjectCDMA2000 MO
o reportConfigLink pointing to an instance of ReportConfigCDMA2000 MO with triggerTypeInterRAT set to
‘periodicalForCsfbTo1XRtt’
• One instance of RrcMeasurementConf MO with:
o measurementIdentityConfList includes one or multiple instances of MeasurementIdentityConf MO with
measurementPurpose set to
‘Report-Strongest-Cells-For-CsfbTo1XRtt’
o measQuantityCDMA2000 set to ‘pilotPnPhaseAndPilotStrength’
o sMeasure set to ‘0’
o measurementGapsPattern is not used for CSFB (Refer to rule under the parameter for measurement gap
values used for CSFB)

eNB will configure UE to perform 1xRTT measurement when 1xCSFB request is received and all of the following
conditions are satisfied:
• SIB8 is broadcast with all required IEs to support 1xCSFB
• 1xRTT neighbor information properly entered
• UE supports 1xRTT periodical measurement
• UE supports enhanced 1xCSFB and eMCTA provides at least one 1xRTT candidate carriers for UE to measure
• UE does not support enhanced 1xCSFB but eMCTA provides more than one 1xRTT candidate carriers for UE to
measure and ActivationService::isRel8CsfbTo1xRttMeasurementBasedEnabled = ‘True’.
Remark: If there is only one frequency that is provided by eMCTA and Release 8 1xCSFB procedure is selected,
UE will not be configured to perform 1xRTT measurement. Blind redirection is used for 1xCSFB in this case. (It is
not worth measuring the Rx level of one carrier when that one is the only choice)
If any of the above conditions are not satisfied, eNB will not be able to configure UE to perform 1xRTT
measurement. In this case, enhanced 1xCSFB will not be selected. Blind redirection Release 8 1xCSFB procedure
or dual Rx 1xCSFB procedure will be performed instead.

To provide a list of 1xRTT bands/frequencies for UE to perform measurement for 1xCSFB, eMCTA will prioritize
all of 1xRTT bands/ frequencies configured in MeasObjectCDMACDMA2000 instances that are supported by the
UE based on their eMCTA priorities. The prioritized 1xRTT bands/frequencies will then go through eMCTA filters
to remove the bands/frequencies that cannot support a 1xCSFB or an emergency 1xCSFB call. Finally, the list is
truncated to include total number of bands/frequencies limited by Enb::
maxNumberOfCdmaChannelFor1xCsfbMeasurements in addition to the limitations of RrcMeasurementConf::
maxMeasIdForMultipleMonitoring and
RrcMeasurementConf::maxNbCarriersForMultipleMonitoringUsingMeasGaps.
For 1xCSFB, UE will be configured to perform periodical measurements for all 1xRTT bands/frequencies provided
by eMCTA (When UE is configured to perform 1xRTT measurement for 1xCSFB, all other measurements are de-
configured except for A2_Floor measurement.). A timer with value Enb::
maxTimeAllowedFor1xCsfbMeasrements is started when UE is configured to perform 1xRTT measurement. When
all UE measurement reports (one for each band/frequency) are received, eNB will trigger handover or
measurement based redirection to the strongest band/frequency. If eNB has not received all UE measurement
reports when the timer expires, it will trigger handover or measurement based redirection to the strongest
band/frequency of measurement reports it has received. If UE does not provide the optional IE of pilotPnPhase
in its measurement reports, eNB will not be able to perform enhanced 1xCSFB which is handover based. Instead,
Release 8 1xCSFB is performed.
If there is only one frequency that is provided by eMCTA and Release 8 1xCSFB procedure is selected, UE will
not be configured to perform 1xRTT measurement. Blind redirection is used for 1xCSFB in this case.
For a UE that requires measurement gaps for 1xRTT measurement,
ActivationService::isMeasurementGapsAllowed must be set to ‘True’ to configure the UE for 1xRTT
measurement. If UE supports DRX (FGI #5 is set), and if ActivationService::isForcedDrxForCsFallbackAllowed is
set to ‘True’, eNB will force UE into a DRX off period for 1xRTT measurement. This is to speed up inter-RAT
measurement and maximize the change for UE to send back measurement report. All DRX parameters are hard
coded internally for 1xCSFB measurement.

The characteristics of all three 1xCSFB procedures (UE originated/terminated non-emergency or emergency 1xCSFB when UE
is in idle state or in RRC connected state) are summarized as in the following:
• Enhanced 1xCSFB procedure:
o It is used for a single or dual Rx UE that supports both e-CSFB-1xRTTr9 capability and 1xRTT periodical measurement.
1xRTT measurement can be configured and measurement report has been received in eNB
o CSFB to 1xRTT is performed through measurement based handover
• Release 8 1xCSFB procedure:
o It is used for a single Rx UE if enhanced 1xCSFB procedure cannot be performed
o It is used for a dual Rx UE if both enhanced 1xCSFB procedure and dual receiver 1xCSFB procedure cannot be performed
o CSFB to 1xRTT is performed through measurement based redirection if eNB has received UE measurement report.
Otherwise, blind
redirection is used
• Dual receiver 1xCSFB procedure (92024):
o It is used for a dual Rx UE if enhanced 1xCSFB procedure cannot be performed
o CSFB to 1xRTT is performed through releasing the UE from LTE
The UE radio access capability parameters carried in UE-EUTRA-Capability IE that are checked by eNB when selecting a
1xCSFB procedure including:
• rx-Config1XRTT – the parameter is set to ‘single’ for a single Rx UE and set ‘dual’ for a dual Rx UE
• e-CSFB-1XRTT-r9 – the parameter is set to ‘supported’ if the UE supports enhanced 1xCSFB
• FeatureGroupIndicator – FGI#16 and FGI #24 are set to ‘1’ if the UE supports non- ANR periodical measurement on 1xRTT
• interRAT-NeedForGaps – the parameter indicates whether measurement gaps are needed for inter-RAT measurement
• SupportedBandList1xRTT – list of 1xRTT bandclass the UE supports
After eNB finds out whether UE is single Rx or dual Rx, and whether the UE supports e- CSFB-1xRTT-r9, it determines
whether periodical measurement to 1xRTT is possible if enhanced 1xCSFB or measurement based R8 1xCSFB procedure is
considered. If it is possible, eNB will configure UE to perform periodical measurement on 1xRTT. After UE measurement
report is received, final decision on the selection of 1xCSFB procedure is made based on the procedure enable/disable status.

When UE is in connected mode and attempts to initiate a CS call to 1xRTT, or to accept a mobile terminated CS
call on reception of a CS paging from 1xRTT through LTE network, UE will send a RRC UL Information Transfer
containing a Extended Service Request message. Source eNB will forward this message to MME through a S1AP
UPLINK NAS TRANSPORT message. MME will then send a UE Context Modification with CS Fallback Indicator set
to ‘CS fallback required’ or ‘CS fallback high priority’. This triggers the 1xCSFB procedures in eNB.
If UE measurements can be configured, eNB will configure UE to perform1xRTT measurements.
eNB will trigger a redirection to 1xRTT by sending the RRC Connection Release message with redirection
information filled with carrier information provided by eMCTA (blind redirection), or based on the received 1xRTT
measurement report.
For measurement based redirection, UE may be configured to perform measurements on several 1xRTT carriers,
the carrier reporting with a strongest pilotStrength will be selected as the 1xCSFB target carrier. If more than
one carriers have the same pilotStrength, the carrier with the highest eMCTA priority will be selected. If no
measurement report is received, on expiry of timer with duration Enb::maxTimeAllowedFor1xCsfbMeasurements,
blind redirection towards the carrier with the highest eMCTA priority will be performed.

When UE is in idle mode and attempts to initiate a CS call to 1xRTT, it will first initiate connection setup
procedure and initial context setup procedure. The optimization introduced in L92024 is applied for Rel-8 1xCSFB
if Enb::idle1xCsfbforDualRxUE is set to ‘Optimized-for-1xCSFB-KPIs’ and if UE measurement is not required.
The remaining steps of whether to configure UE to perform 1xRTT measurements and whether to perform a
blind redirection or a measurement based redirection is the same as in the case of Rel-8 1xCSB for mobile
originated CS fallback when UE is in connected mode or for mobile terminated CS fallback.
eNB supports CS fallback to 1xRTT for dual receivers (DRx) UE (92024.1). This type of UE is able to perform
1xRTT measurements and receive 1xRTT paging messages directly from 1xRTT paging channel with its second
receiver while it is in LTE RRC idle or connected state. When a 1xRTT CS fallback request is received from MME,
eNB will release the DRx UE instead of performing redirection. For this reason, eNB does not need to request UE
to perform target carrier measurements and so the latency added to 1xRTT voice call setup is minimized.

A network which advertises support for Rel-8 1xCSFB may also support enhanced 1xCSFB, in which case the eNB
determines to perform enhanced 1xCSFB based on UE capability. If enhanced 1xCSFB is to be performed, the
eNB optionally solicits 1xRTT measurements from the UE, and then sends it a
HandoverFromEUTRAPreparationRequest message. This triggers the UE to send the UL Handover Preparation
Transfer message containing 1xRTT dedicated information. The 1xRTT information is contained inside RRC and
S1-AP messages between the UE and MME and in a generic "transfer" message between MME and 1xRTT
network. The response from the 1xRTT network triggers the eNB to send a Mobility From EUTRA Command
message which includes a 1xRTT channel assignment message that causes the UE to acquire a traffic channel in
the 1xRTT access network.
The optimization of initial context setup procedure is never used regardless of the setting of
Enb::idle1xCsfbForDualRxUE and UE will always be configured to perform 1xRTT measurements.
For enhanced 1xCSFB, after UE measurement report is received, eNB will send a RRC
HandoverFromEutraPreparationRequest message to trigger UE to prepare for enhanced 1xCSFB to 1xRTT and
start a timer with duration Enb::maxTimeAllowedforCsfbMobilityAttempt
After eNB receives the RRC ULHandoverPreparationTransfer from UE tunneling the enhanced 1xCSFB related
CDMA2000 dedicated information, eNB will send Uplink S1 CDMA2000 Tunneling message to pass the
CDMA2000 dedicated information. The message also includes the list of measured 1xRTT pilot and their
strength, one way delay, etc.
If eNB receives DL S1 CDMA2000 Tunneling message from MME indicating enhanced 1xCSFB handover
preparation is successful (CDMA2000 Handover Status = HO Success, eNB will stop the timer with duration
Enb::maxTimeAllowedforCsfbMobilityAttempt and send a RRC MobilityFromEUTRACommand to direct UE to
perform 1xRTT handover. eNB will then start a timer with duration
Enb::maxTimeAllowedforCsfbReEstablishment to keep UE contents in case it fails to connect to target 1xRTT and
performs reestablishment. On timer expiry, the enhanced 1xCSFB procedure is considered as successful and eNB
will send a S1AP UE Context Release Request and release the UE contents.

The network advertises support for dual receiver 1xCSFB by broadcasting the dual receiver 1xCSFB support
indicator in system information (SIB8). The eNB determines to perform dual receiver 1xCSFB if the UE has a dual
Rx configuration according to UE capability, and enhanced 1xCSFB cannot be performed (i.e. because enhanced
1xCSFB is not supported by both network and UE). If dual receiver 1xCSFB is to be performed, the eNB sends an
RRC Connection Release message without including redirection information. The UE then performs the normal
1xCS call origination or termination procedure in the 1xRTT access network. A UE with dual Rx configuration
may initiate 1xCSFB to a network broadcasting 1xRTT pre-registration parameters but not broadcasting the dual
receiver 1xCSFB support indicator; in this case, the UE may receive an RRC Connection Release message with
redirection to 1xRTT.
• DRx UE is able to perform 1xRTT measurements and receive 1xRTT Paging messages directly from 1xRTT
Paging channel with its second receiver while it is in LTE RRC idle state or connected state
• Since eNB does not need to request DRx UE to perform target carrier measurement, the latency added to
1xRTT voice call setup is minimized

isCsfbTo1xRttForDrxUEAllowed (activationService; default=‘False’)
When this parameter is set to ‘true’, a Rel-9 IE, csfb-SupportedForDualRxUEs-r9, will be included in System
Information Block Type 8 (SIB).
The IE services as an indication to UE that the network supports DRx 1xCSFB. A DRx UE in RRC idle state or in
RRC connected state on LTE cell will then request CS fallback if a 1xRTT voice call or emergency voice call is to
be setup.
idle1xCsfbForDualRxUEAllowed (eNb; range={Optimized-for-1xCSFB-KPIs, Not-optimized-for-1xCSFB-KPIs};

default= ‘Optimized-for-1xCSFB-KPIs’ for a network that supports CDMA)
When UE is in RRC idle state and requests a 1xCSFB, if MME supports the optimized procedure (ALU MME
supports this procedure while other vendor’s MME may or may not support this procedure), if
Enb::idle1xCsfbForDualRxUE is set to ‘Optimized-for-1xCSFB-KPIs’, certain connection setup steps (Security
Mode Command, E-RAB setup and RRC Connection Reconfiguration) that are unnecessary to 1xCSFB are
skipped.
1xCSFB optimized procedure will reduce 1xRTT voice call setup latency and increase 1xCSFB successful rate by
eliminating the potential failures of unnecessary steps

SRVCC is specified in 3GPP TS 23.216
LA5.0 Feature ID: 92126.1: SRVCC to UTRA FDD/TDD
Single Radio Voice Call Continuity (SRVCC) is a functionality that allows an IMS call with VoIP bearers (QCI = 1)
in the LTE packet domain to be moved to the legacy circuit domain (UTRAN, GERAN or 1xRTT) when PS
handover for the VoIP bearers (QCI = 1) is not possible. This functionality is useful to keep voice call continuity
when a single transceiver UE is moving from a LTE network towards a legacy network that does not support
VoIP call.
SRVCC Voice calls anchored in the IMS even after HO to CS access in Target RAT means that, when the voice
call finishes and the mobile re-enters LTE coverage, the IMS packet sessions can be handed back to the LTE.
With CSFB (case LTE/UMTS/GSM networks), two scenarios are possible: camp on 3G (or 2G) network and HO to
LTE for high rate data sessions; or camp on LTE and use CSFB to manage the VoIP services.
With SR-VCC, two scenarios are possible: IMS on LTE network only and SRVCC is used for HO towards
GSM/UMTS; IMS on both LTE and UMTS and PS HO is used for LTE>UMTS mobility on voice and SRVCC is used
for LTE>GSM mobility for coverage extension of voice service

SRVCC (Single Radio Voice Call Continuity) is an LTE functionality that allows a VoIP/IMS call in the LTE packet
domain to be moved to a legacy voice domain (GSM/UMTS or CDMA 1x).
Consider a case where a new LTE network operator wants to move voice services to VoIP over IMS in
conjunction with the deployment of an LTE access network. SRVCC provides the ability to transition a voice call
from the VoIP/IMS packet domain to the legacy circuit domain.
As an SRVCC-capable UE engaged in a voice call (IMS) determines that it is moving away from LTE coverage, it
notifies the LTE network (events B1, B2). The LTE network determines that the voice call needs to be moved to
the legacy circuit domain (VoIP not supported in the target cell) . It notifies the MSC server of the need to switch
the voice call from the packet to the circuit domain and initiates a handover of the LTE voice bearer to the circuit
network. The MSC server establishes a bearer path for the mobile in the legacy network and notifies the IMS
core that the mobile’s call leg is moving from the packet to the circuit domain. The circuit-packet function in the
IMS core then performs the necessary inter-working functions. When the mobile arrives on-channel in the legacy
network, it switches its internal voice processing from VoIP to legacy-circuit voice, and the call continues. SRVCC
to UTRAN gives a CS-handover-like user experience.
If the legacy circuit network also has an associated packet capability and is capable of supporting concurrent
circuit/packet operations, the subscriber’s data sessions can be handed over to the legacy network in
conjunction with switching the voice call from the packet to the circuit domain. In this case when the voice call
finishes and the mobile re-enters LTE coverage, these packet sessions can be handed back to the LTE.
If operators look to limit LTE deployments to high traffic areas and at the same time wish to transition voice
service in those areas to VoIP, then SRVCC is exactly what they need. If on the other hand operators do not
plan to migrate their voice service to VoIP, then SRVCC is not for them.

When a UE with VoIP bearers (QCI = 1) is moving out of LTE coverage (or in case of overload in serving cell), if
VoIP is supported by the UTRAN target cell (UtraFddNeighboringCellRelation::voiceOverlpCapability is set to
‘Capable’) and PS handover is possible , PS handover for the call will be the first choice.
However, if either UTRAN target cell does not support VoIP (UtraFddNeighboringCellRelation::
voiceOverlpCapability is set to ‘Incapable’) or PS handover is not possible, SRVCC will be considered.
In addition to move the voice bearers to the UTRAN circuit domain with SRVCC, data bearers of the call
can also be handover to the UTRAN packet domain if PS handover is supported (SRVCC was triggered due
to the reason that UTRAN target cell did not support VoIP).
The MME and the UE must also support SRVCC to UTRAN (FPG bit 27 is set for UE)

If ubiquitous coverage of LTE is not available, it is possible that a UE involved in a VoIP call over LTE might then
move out of LTE coverage to enter a legacy RAT cell which only offers CS voice services. The Single Radio Voice
Call Continuity (SRVCC) procedure is designed for handover of a Packet Switched (PS) VoIP call over LTE to a CS
voice call in the legacy RAT, involving the transfer of a PS bearer into a CS bearer.
The Figure shows an overview of the functions involved in SRVCC. The eNodeB may detect that the UE is
moving out of LTE coverage and trigger a handover procedure towards the MME by means of an SRVCC
indication. The MME is responsible for the SRVCC procedure and also for the transfer of the PS E-RAB carrying
VoIP into a CS bearer. The MSC Server then initiates the session transfer procedure to IMS and coordinates it
with the CS handover procedure to the target cell. The handover command provided to the UE to request
handover to the legacy RAT also provides the information to set up the CS and PS radio bearers. The UE can
continue with the call over the CS domain on completion of the handover.

SRVCC to UTRAN call flow is similar to that of PS handover to UTRAN. If several candidate cells are reported in
event B2 (for RF reason) or event B1 (for offloading), UE measurement report and eNB determines to trigger
SRVCC, it will select the best candidate cell that supports SRVCC for the voice bearers transfer even if it supports
SRVCC ‘CS only’. eNB will not attempt to look for another candidate cell that will support SRVCC ‘PS and CS’.
When performing SRVCC to UTRA, in the S1-AP Handover Required message to the MME, eNB will set
the ‘SRVCC HO Indication’ IE as below:
Set to ‘CS only’ if one or multiple conditions below are true:
SRVCC type is restricted to CS only for the RNC controlling the UTRAN target cell (RncAccess::
srvccType is set to ‘restrictedCSonly’)
RNC controlling the UTRAN target cell is not activated PS handover
(RNCAccess::psHandoverUtraEnable is set to ‘False’)
PS handover is not activated in eNB (ActivationService::isPsHoToUtraAllowed is set to ‘False’)
Set to ‘PS and CS’ otherwise
As for PS handover to UTRAN, after serving eNB sends S1-AP Handover Required message to MME, it
will start timer TS1relocprep with duration SrvccToUtraTimersConf:: tS1RelocPrepForSrvccHandoverToUtra (the
SrvccToUtraTimersConf instance is pointed to by srvccToUtraTimersConfId in the RncAccess of the associated
selected UtraFddNeighboringCellRelation).
If TS1relocprep expires, or a S1-AP Handover Preparation Failure message is received from MME indicating
resource reservation in target UTRAN cell fails, serving eNB will abort the SRVCC to UTRAN procedure and sends
S1-AP Handover Cancel message with Cause ‘tS1relocprep-expiry’. eNB will return the UE call context to the
state before SRVCC was triggered. For a call with voice bearer, RRC Release/Redirection will not be used as a
mobility procedure for a VoIP call unless it is triggered by CS fallback or by A2_Below_Serving_Floor
measurement report.

S1-AP Handover Command message is received from MME before timer TS1relocprep expires
indicating resource reservation in the target UTRAN cell has successfully completed, serving eNB stops timer
TS1RELOCprep and starts timer TS1relocoverall with duration SrvccToUtraTimersConf::
tS1RelocOverallForSrvccHandoverToUtra. eNB will send a MobilityFromEutraCommand to the UE with purpose
set to ‘handover’ and targetRAT-Type set to ‘utra’. If ActivationService::isUtraDataForwardingAllowed is set to
‘True’, eNB will start data forwarding for each
E-RAB listed in E-RABSubjecttoDataForwardingList received in the S1-AP Handover Command message
from MME.
If UE Context Release Command is received from MME before timer TS1relocoverall expires, SRVCC to
UTRA is successful. eNB will send a UE Context Release Complete to MME, stop timer TS1relocoverall,
and release UE context and associated resources.
If timer TS1relocoverall expires, eNB considers the UE to have lost radio coverage and trigger the release
of all UE associated resources by sending an UE Context Release Request to MME and release all UE
associated resources in eNB.

LA5.0 FRS 115361 provides the radio link failure (RLF) monitoring mechanism to eNB. When a radio link failure
happens during intra-LTE intra-frequency handover (apply to both X2 and S1 handover), the failure reasons will
be classified into three categories: Handover Too Early, Handover Too Late, or Handover to Wrong Cell. PCMD
counts are pegged accordingly. Based on the PCMD counts, handover parameters can be fine tuned to improve
the handover successful rate. Activation/Deactivation of FRS 115361 is controlled by the parameter
ActivationService::isRlfMonitoringAllowed.

After target eNB receives RRCConnectionReconfigurationComplete message indicating a successful handover, it
starts timer with value LteCell::hoReportTimer and sends X2AP UE CONTEXT RELEASE to the source eNB. While
the timer is running, source eNB receives the RRCConnectionReestablishmentRequest from the UE. Since the
source eNB does not have UE context (released), it sends RRCConnectionReestablishmentReject to the UE and
sends X2AP RLF INDICATION to target eNB to report the RLF failure. Target eNB increments the ‘HoTooEarly’
counter and sends back X2AP HANDOVER REPORT indicating ‘HO Too Early’.
N310 is assumed to be set to 1 and T310 to 1000ms.

Before handover is initiated in source eNB, UE sends RRCConnectionReestablishmentRequeset to re-establish
radio link connection to a non-source cell. The controlling eNB of the cell sends
RRCConnectionReestablishmentReject because it does not have the UE context and sends X2AP RLF
INDICATION to source eNB to report RLF failure. Source eNB increments the ‘HoTooLate’ counter.

HO to wrong cell case 1: After source eNB sends the RRCConnectionReconfiguration to the UE to trigger intra-
eNB handover execution, it starts timer RrcIntraEnbHo timer. While the timer is running, the UE sends
RRCConnectionReestablishmentRequest to re-establish radio link connection with another cell controlling
by neighboring eNB. The neighboring eNB sends RRCConnectionReestablishmentReject to the UE because it
does not have UE context and sends X2AP RLF INDICATION to the source eNB to report RLF failure. Source eNB
increments ‘toWrongCell’ counter.

HO to wrong cell case 2: After source eNB receives the RRCConnectionReconfigurationComplete from the UE
indicating intra-eNB handover successful, it starts timer hoReportTimer. While the timer is running, the UE sends
RRCConnectionReestablishmentRequest to re-establish radio link connection with another cell controlling by
neighboring eNB. The neighboring eNB sends RRCConnectionReestablishmentReject to the UE because it does
not have UE context and sends X2AP RLF INDICATION to the source eNB to report RLF failure. Source eNB
increments ‘toWrongCell’ counter.

HO to wrong cell case 3: similar to HO to wrong cell case 1 except that it is an inter-eNB handover. Timer is
x2ReleaseTimer

HO to wrong cell case 4: similar to HO to wrong cell 2 except that it is an inter-eNB handover.

Document History
07 2013-12-11 Kine, Jean-Philippe LR13.3 update


Page
1 Automatic PCI (Physical Cell ID) 7

1.1 Overview 8
1.2 Physical Cell Identity 11
1.2 Physical Cell Identity (cont.) 12
1.3 Automatic PCI Locations 13
1.4 Centralized PCI Provisioning Algorithm 15
1.4.1 securedRadius 16
1.4.2 Algorithm Description 17
1.5 Centralized PCI Auto Correction Algorithm 19
1.5.1 Algorithm Description 20
1.6 Distributed PCI Allocation Algorithm 22
1.6.1 Conflicts Management 23
1.7 Automatic PCI for up to 6 Sectors and 9 Cells eNB 25
1.7.1 PCI mod3 Interference Rule 26
1.7.2 PCI mod3 Algorithm 27
1.7.3 PCI mod3 Alarm Generation 28
1.7.4 PCI Selection 29
1.8 Automatic PCI of Helnet Metro Cells 31
1.8.1 Sets of PCI mod3 Cumulated Neighbor’s Power 32
1.8.2 Distributed PCI Algorithm in Metro Cell 33
2 Automatic Neighbor Relation (ANR) 36
2.1 ANR Overview 37
2.2.1 Intrafreq ANR State Diagram 40
2.2.2 Intrafreq ANR in Active Phase 41
2.2.2.1 Intrafreq ANR Actions Diagram 44
2.2.2.2 LteNeighboringCellRelation 46
2.2.2.3 Intrafreq ANR Measurements Configuration 47
2.2.2.4 Setup X2 Links 51
2.2.2.4 Setup X2 Links 52
2.2.4 Intrafreq ANR in Dormant/Monitoring Phase 57
2.2.5 Intrafreq ANR in Wake-Up Phase 58
2.3 Interfreq ANR Activation 60
2.3.1 Interfreq ANR Activation and X2 Setup 61
2.3.2 Interfreq ANR Activation 62
2.4 UTRAN ANR Activation 66
2.4.1 UTRAN ANR State Diagram 67
2.4.2 UTRAN ANR in Active Phase 68
2.4.2.1 UtraFddNeighboringCellRelation 69
2.4.2.2 UTRAN ANR Measurements Configuration 71
2.4.3 End of UTRAN ANR Active Phase 72
2.4.4 UTRAN ANR in Dormant/Monitoring Phase 73
2.4.5 UTRAN ANR in Wake-up Phase 74
2.5 ANR Common Functions 78
2.5.1 DRX Configuration 79
2.5.2 ANR Dispatch Function 80
2.5.2.1 Example (1) 82
2.5.2.2 Example (2) 83
2.5.3 Garbage Collection 84
2.5.4 ANR Synchronization Function 85
2.5.5 ANR Reset Function 86
2.5.6 ANR Neighbor Replacement 89
3 Handover Optimization 93
3.1 Introduction 94
3.2 HO Optimization Parameters 95
3.3 HO Optimization Process 97

Page
3.4 General Parameters Adjustment 98

3.5 CIO Adjustment 100
3.6 Stopping the Adjustment Process 101
3.7 Resuming the Adjustment Process 102
4 Cell Outage Management 104
4.1 Cell Outage Detection 105
4.2 Cell Power Off when all S1 Down 106
4.3 Dynamic Coverage with Cell Shrink 107

The complexity of a network is increasing for every new release, due to multi technology environments, tight spectrum
usage, advanced radio interface features and parameterization. So, setting the parameters by hand and optimizing
them becomes a more and more time consuming task, resulting in enhanced costs for network operation.
In addition, manual parameter setting is a rather static way to control the network. The optimal network settings are
often time dependent, reflecting the changes of user behavior and location. Therefore, settings should be changed in a
fast way and as flexible as possible. The only way to cope with these requirements is to do these settings
autonomously.
So, the concept of Self Organizing Network (SON) was introduced from LTE Release 8 on in order to reduce OPEX and
to improve the network quality. The settings of network parameters are automated, supported by measurements of the
UE and eNBs.
The processes in SON are the following. After switching on the eNB, the so called Self Configuration starts. During this
time, the eNB is already physically connected with the network, but the RF is still switched off. An IP address and a
connection to an O&M is assigned to the eNB. After an authentication in the network, the eNB gets an association to
the MME and S-GW, and the connections to the core (S1) and to the neighbored eNBs (X2) are established. If available
there may be a software update. Also the physical cell identities (PCI) for all supported cells in the eNB are assigned
here, as these are required to go on air. Note that this assignment must be done without feedback from the UE.
After these basic setup procedures, the eNB gets the initial radio configuration. This is comprised by the initial neighbor
list, the coverage and capacity related parameter configuration like transmission power, antenna tilt, and all remaining
parameters for operation. These parameters are finally optimized at the next stage, the Self Optimization. This stage
starts by switching on the RF. Mobiles may now connect with the cells and return feedback to improve the initial radio
configuration and also to adopt them to (time dependent) traffic load or measured propagation conditions. For this
feedback, existing RRC measurements have been extended. In the case of a failure, the so called Self Healing applies.
Depending on the failure reason the eNB either switches to a spare part (if existing) in case of a hardware failure, or
reloads a former software when the failure was caused by a not properly running software update. When none of these
remedies work, the remaining eNBs change their settings in order to fill the coverage gap created by the failure. So,
with SON, rolling out new eNBs shall be a kind of Plug and Play system, having only a single site visit to install and
operate the station. All parameter settings, including the changes in the network neighbourhood, shall work in an
autonomous way.

ANR must be activated in the eNB in order the Neighbor Relation List is built from the actual UE
measurements.
The outage duration in LA4.0 on PCI change is one minute as it requires modem restart. In a future
version, the outage should be in the order of millisecond with proper release of the on-going calls.
In a scenario where eNB is introduced into a mature without PCI conflict, the newcomer eNB must run the
automatic PCI algorithm in order to choose the suitable PCIs of its cells being collision-free and confusion-
free with the network.
The list of possible PCIs for the new eNB is provided by OAM. It may for instance happen that there are
several layers (macro, micro, femto) in the network. The operator may wish to split the PCIs in several
ranges to each layer.

Modified LR13.3
PCI Collision: occurs when in a given location, the signals from two different cells radiating the same PCI
are received by a UE. In the worst situation, the UE may be unable to access either of the two cells due to
the interference generated. The coverage gap or blackout may be quite important. At best, the UE will be
able to access one of the cells but will be highly interfered.
PCI Confusion: appears when a given cell, has two neighbors sharing the same PCI. The UE reports
measurements from two cells having the same PCI. The eNB will not know which of the two cells the report
relates to. In the best case, the eNB may request the UE to report the ECGI before HO. In the worst case it
may lead to a high rate of HO failures. The two cells having the same PCI do not interfer as much as in
case of collision because they are far from each other.
A PCI collision is considered critical enough that it shall be addressed within one hour of detection. A PCI
confusion can wait until the next maintenance window to be addressed. To resolve the difficulty of ensuring
that a newcomer eNB modifies its PCI rather than a well-established eNB, two different time periods can be
defined. For example, a newcomer eNB would be required to perform a PCI modification within 15 minutes
of detection or beginning of the maintenance period, whereas a well-established eNB would do so in the
remaining part of the hour. Once one eNB has modified a conflicting PCI and communicated the change to
its neighbours, the need for the other eNB to change its PCI disappears.
In this way, our solution guarantees that a newcomer eNB will change its PCI before a well-established eNB
attempts to do so.

The Physical Cell Identifier or PCI is the identity of the cell as it appears on the radio to a UE
The physical cell identity is used, among other things, to identify a cell in interactions between eNB and
UE, in particular measurement configuration and Reporting
A physical cell identity must be unique within a given region and for a given frequency to avoid any collision
or confusion

Rule of PCI modulo 3:
The PCI is used in the generation of the cell-specific RS. The frequency shift pattern of the RS is also
derived from the PCI, but on modulo 3 (case two antennas MIMO; otherwise with one antenna it is modulo
6). Consequently, two cells that have different PCIs equal modulo 3 will radiate their RS at the same time-
frequency symbol (same shift). If they are radiating from the same radio mast, they will interfer a lot to
each other and the UE measured CQI will be poor. It is therefore strongly recommended that cells radiating
from the same radio mast must have PCI different modulo 3.

Automatic PCI architecture:
-Centralized Architecture: In this architecture, the algorithms are controlled by the O&M center.
Consequently, the execution speed is rather slow, however, a lot of eNBs can be used for the collection of
network information and the algorithms.
-Distributed Architecture: The SON entities are in the eNBs, with an information exchange over the X2 or
S1 interface. In this approach the number of involved eNBs may not be too high. The reaction time is much
shorter allowing a network reaction on changing environment conditions in a very fast way. In the limit of
having only one eNB, this architecture is also assigned as Localized Architecture.
-Hybrid Architecture: The combination of both architectures, where the algorithms are distributed between
the O&M and different eNBs.

Parameter pciAllowedList (ENBEquipment/Enb/SelfOrganizingNetwork/AutomaticPhysicalCellIdentity)
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 or some PCIs reserved for Femto etc).

The centralized PCI provisioning algorithm is fully dependent on the knowledge of eNB/cell positioning, thus
its accuracy depends on the correct entry of LteCell Latitude and Longitude information. These values
typically represent the location of the RRH or TRDU, and are expected to be near the antennas.
Engineering Recommendation: SecuredRadius

Even if SecuredRadius (computed in km) is modifiable by the operator (within PCI configuration wizard in
WPS), it is highly recommended to keep the default value (implying N = 4). In case securedRadius need to
be changed (due to customer and/or geographical constraints), it must be done carefully as it can have the
following negative effects:
a too low securedRadius will increase drastically the risk of PCI collision and confusion; on the other
hand
a too high securedRadius will increase the risk to have no free PCI available.
SecureRadius vs. cellRadius configuration:

The SecureRadius value can be directly modified in the WMS PCI Configuration wizard, or indirectly through
the cellRadius value. If SecureRadius need to be modified (to increase PCI algorithm precision), it is highly
recommended to directly change its value in the PCI Configuration wizard.
As it interacts with other features, the modification of cellRadius is not advisable. In Release LR13.3, the
max value of cellRadius is increased to 100 km due to the support of PRACH format 3

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.
If pciAllowedList is empty, then pciListTobeUsed = the Full PCI Range
This algorithm manages the conflict per eNB and not on the whole network
The rule PCI modulo 3 or 6 is applied within per eNB.

The algorithm for auto corrective PCI consists of checking then fixing all the potential PCI collisions and PCI
confusion. The algorithm 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. Also if there are some PCI
conflicts provoked by a cell without any neighbor relation, the algorithm can neither detect them nor fix
them.
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 the served cell and also the
neighbor cells.
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 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 is transmitted in the downlink in SystemInformationBlockType1.
2) EUTRAN Cell Identifier (ECI) uniquely identifies the cell within the network 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. This parameter
corresponds to the 20 leftmost bits of the ECI
relativeCellIdentity parameter, when associated with the macroEnbId, uniquely identifies a cell within
E-UTRAN. This parameter corresponds to the 8 rightmost bits of the ECI

For PCI Auto-Correction, the collision and confusion are solved: only the first level of neighbor cells is
required.
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 6”)

With the distributed algorithm, the operator may provide an initial PCI (using the pci parameter) or the eNB
may choose the initial PCIs for each of its cells from the list defined by the value of the pciAllowedList
parameter.
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
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 further)

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.
This is a licensed feature.
An eNB may detect a collision through served cell info in X2 or S1 message (one served cell of neighbor
eNB has the same PCI)
An eNB may detect a confusion through neighbor cells info in X2 or S1 message (one neighbor cell of the
neighbor eNB has the same PCI)
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.
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. To avoid simultanious resolution
attempts by 2 peer eNs, random timers are started before the update is actually made. The first eNB
that succeeds in changing the PCI value sends the information to the other eNB, and it will abort its
resolution attempt.

LR13.3 feature L115340 SON PCI with eNB with 9 cells and 6 sectors

The adjacencies are defined after sorting the cells by ascending azimuths values.
No alarm is sent to the SAM in case of ‘Less good case’. If none of ‘best case’ nor ‘less good case’ can be
reached, the algorithm will send an alarm to the SAM.

Remark: n is a circular value modulo N (from 1 up to 6). For instance, in case of N=6, if n=6, then n+1=1

LR13.3 L115966 feature related with Adaptation of automatic PCI assignment to HetNet with Metrocells
The MRO can be configured with several metro cells within the same eNB: the limitation here is to have one
site per metro cell.
The feature is limited to metro cells, as the main topic of this feature is the Interference between metro
cells and also between the macro cells and the metro cells that cover the same area. In such case, it is
better to change the metro cells PCI:
- Because just changing the macro cell PCI may not solve all the interference
- Because changing the metro cell has only local impact while change the macro cell may generate a wave
of changes in the network that would impact many users.
The feature is not compatible with PciMod3Maintained= enabled, this parameter implies that the PCI mod 3
cannot be modified, which is the opposite of the aim of this feature.
The young/mature status is taken into account, what means that the timer values related to this status are
used. Even if the main interferer of a metro is the macro, others metro may have impact. In such case,
better change first a young than a mature Metro cell.

What is counted is the number of times a specific neighbor appears in first place in the measurement report
(ANR or HO). We do not take into account the neighbor power value but the neighbors ordered by power.

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.
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.
PCI algorithm in the Metro cell:
• If total count of NR measurements ≥ interferenceMinMeasurements, calculation is done
• If (worst set power – best set power)/(total count of measurements) < interferenceThreshold , then
best, worst and middle are in the same group
• Else
• If (middle set power – best set power)/(total count of measurements) < interferenceThreshold,
then best and middle are in the same group, worst is in another group
• Else if (worst set power - middle set power)/(total count of measurements) <
interferenceThreshold, then worst and middle are in the same group, best is in another group
• Else best, worst and middle are each one in a separated group
• Note that the groups keep the ordered PCI mod 3 information meaning that information is:
• What is the best PCI mod3
• What are the PCI mod3 in the best group

ANR purpose is to relieve the operator from the burden of manually managing Neighbor Relations.
ANR function resides in managing autonomously the eNB configuration in terms of neighbor relations to be
available for mobility procedures, with the aim to be able to:
Build an initial neighbour list
Maintain up-to-date and optimize this list as eNB environment evolves
Main inputs for the ANR function are UE measurements reporting radio neighbourhood and X2 messages
received from neighbour eNBs. X2 messages are used for intra LTE ANR. For UTRAN ANR, only RRC
measurements are available.
This is where it is obvious that ANR and dynamic X2 configuration shall interact in order to optimize usage
and consistency of received information.
Information received through X2 interface is considered as the most reliable one in case of conflict between
the radio and the X2 information.
ANR behaviour shall in the meantime allow the operator to keep at least partial control on the neighbour
management (by OAM) by letting him the possibility to create or remove neighbour relations at any time.
ANR function can be activated on demand on a per eNB basis, even if optimized functioning will be
obtained when it is working on a whole set of neighbour eNBs.
UTRAN interfreq is new LA5.0
Definitions:
PCI is the Physical Cell Id extract from the Primary and Secondary Synchronization Signal of the neighbor
cell. 3GPP has defined 504 unique PCI. Its scope is local
ECGI (EUTRAN Cell Global Id) has a worldwide scope. Each cell has a unique ECGI in the world. ECGI is
used to fully identify cells on the S1-MME interface or on X2 interface. It is composed of PLM Id and a 28
bits EUTRAN Cell Id (20 bits for eNB and 8 bits for the cell inside the eNB)

ANR includes the following functions:
ANR neighbor relation creation function – builds up neighbor relations by requesting the UEs to search
for neighbor cells or by receiving the neighbor relations from neighbor eNBs. Information on X2
interface is used only by intrafreq ANR.
ANR neighbor relation maintenance function (aka garbage collection) – deletes the obsolete neighbor
relations and obsolete X2 links
ANR synchronization function – to provide automatic synchronization between eNB and OAM server
(SAM)
ANR reset function – allows testers to reset the internal counters and to delete neighbor relations
created by ANR or provisioned by operator so that testing can restart from the initial status

The signaling of the neighbor cell list to the UE is done either by SI brodcast in the serving cell (SIB4 for
intra-freq, SIB5 for inter-freq, SIB6 for UTRA, SIB7 for GERAN, SIB8 for CDMA2000) or within a dedicated
measurement configuration (‘RRC Connection Reconfiguration’ message)
In LTE, UEs do not need the network to broadcast physical cell identities in order to perform measurements
(in contrast to UTRAN or GERAN). The possibility nevertheless exists in order to allow for cell-specific
thresholds or offset to be applied. Therefore the eNB needs only to signal neighbours that have a non-zero
offset.
Neighbour cells that are discovered by the ANR feature will have their individual cell offset not set by
default (matching attributes in the model are optional). Once a discovered neighbour has been made visible
at SAM, the operator will be able to modify the cell individual offset. The eNB will only consider neighbour
cells with a non-zero individual offset for inclusion in SIB4 and Measurement Configuration (once again, as
the matching attributes are optional, if they are not provided, eNB behaviour will be similar as if they were
set to 0).
The number of cells that can be included in SIB4 and Measurement Configuration messages is limited (16
cells in SIB4 and 32 in Measurement Configuration). Preference will be then given to neighbour cells with
the biggest absolute value offset, and if a second criterion is needed, cells with the lowest PCI will be
preferred to cells with the highest PCI.
The eNB will also signal the black-listed cells.
The HO White List is composed of the neighbor relations with noRemove=true and noHOReselection=False
The HO Black List: noRemove=true and noHOReselection=true
In the same manner, there is also X2 White List, X2 Black List, X2 HO Black List (managed by the eNB and
not forwarded on the air)
LR13.1 update: nb of lteNeighboringCellRelations increased from 48 to 72 and X2Access from 32 to 48

(then to 72 in LR13.3).

The ANR feature activation (ActivationService::anrEnable) is controlled on per eNB basis. When ANR is
activated, each of its cells can be in one of the four phases independently: ANR active phase, ANR dormant
phase, ANR Monitoring and ANR wake-up phase. Since LTE intra/inter freq ANR and UTRAN ANR can be
activated independently, different ANR functions per cell (1 LTE intrafreq, several LTE interfreq, several
UTRAN) can be running in different phases concurrently. For this reason, an ANR measurement
dispatch function is introduced to allocate available UEs for different ANR measurements.
An ANR enabled eNB is able to detect intra-freq neighbor cells. Just after the startup of a cell (cell enters in
‘unlocked, enabled’ state), if the attribute LteCell::Lte{Intra,Inter}FrequecyAnrState is set to
‘notCompleted’, the detection of neighbor cells for the started cells is performed in an ‘accelerated’ way
during a transient period. During this period, all or part of the RRC connected UEs located in the cell will be
configured to perform ANR specific PCI measurements. This transient period is entitled ‘Active phase’ here.
The Active phase ends (and the Dormant phase starts) when a preconfigured amount of PCI related
measurements (regardless whether the PCI is newly or already measured) and PCI related measurements
without any new PCI are reported. In the Dormant phase, if a new PCI is detected upon e.g. regular RRC
connected UE measurements necessary for the HO control function an ANR Wake-up phase is launched
(UEs are configured with ANR specific measurements. Should the ECGI for the PCI be reported the process
of configuration is stopped). The Dormant phase is also left for the Monitoring phase regularly every hour
to check whether the PCI/ECGI association is still valid. In both Active and Wake-up phases, if a new PCI is
detected, the UE is then requested to report the associated ECGI to be read in the SIB1 of the detected
neighbour provided that it supports the function and it is not configured with GBR RB (the UE shall be put
in DRX mode in order to perform the ECGI measurement).

When Cell A is in ANR active phase, eNB A will send ANR measurement configuration to UEs in non-GBR
application that are in RRC connected state in Cell A to search for neighbor cells.
1. UE will send a measurement report on Event A3 with Cell B’s PCI when triggered by ANR
measurement configuration. The Offset of Event A3 is configured lower for ANR than for
regular Intra-freq HO.
2. If eNB A does not know the ECGI associated with the reported PCI, it will direct UE to read
from PBCH B to obtain the ECGI
3. After UE finds the ECGI of Cell B, it will report back to eNB A.
UE can detect Cell B’s PCI directly, but ID of eNB B used for X2 link setup is not contained in PCI but in
ECGI. If ECGI is not already known, eNB A will force the UE into DRX cycle in order for the UE to read
PBCH of Cell B to get its ECGI
After ECGI of Cell B is received, if X2 link does not already exist between eNB A and eNB B, ANR will
attempt to set up the X2 link

The active phase will have to run once during the first start up of the eNB or on cell addition. An evaluation
of the neighbor list is performed quickly.
When UE comes into RRC_CONNECTED state, it may be solicited by ANR to perform ANR measurements.
All potential neighbor cell that can be recognized by the UE and satisfying Event A3 (ANR) will be reported
by the UE.
PCI reported by an UE may consists in an ANR measurement report or an Intra-freq HO measurement
report.
X2 messages (X2-SetUp-req/resp or eNB-Configuration-Update) may be received from the neighbor eNB
either because X2 links have been configured by the operator or following ANR function of the neighbor
eNB
When this phase will be over (based on a set of criteria to be met defined previously), dedicated
measurements will no longer be performed. From then, active phase should never be run again. The eNB
then enters the Dormant phase.
The ANR decisions are notified regularly to OAM in order to provide overview and control to the operator.
A ‘potential’ neighbor cell is a cell (PCI/ECGI) discovered through RRC measurements or X2 interface which
has still not been been used for HO

ECGI (retrieved by the ANR function in the source cell) of the target cell is required to perform X2 or S1
handover

The number of cells the UE may report (maxReportCells) shall be set for ANR to the maximum value, in
other words 8, for best efficiency, but will however be configurable through dedicated configuration
parameter. The report configuration used to detect neighbour cells must be more aggressive than a regular
report configuration; in other words, the thresholds will need to be set lower than they usually are,
regardless of the trigger chosen for ANR-specific measurements. With lowered thresholds, cells will be
reported by UEs before the actual need for a handover, which may leave time enough to determine the
global cell identity of the neighbour cell before a handover is required.
Then, the eNB shall support an event A3 report (intra-freq) configuration for ANR purposes. This report
configuration shall be distinct from the one used to trigger handover procedure. A3, A4 and A5 events each
have pros and cons as ANR report configurations.
Event A3 is the one recommended in Alcatel-Lucent solution for handover purposes (reminder: event A3
means the neighbour cell is received offset better than the serving cell) and a natural candidate: with a
slightly lowered threshold, handovers are anticipated. One advantage is that detected cells are most
certainly real neighbours (these are cells towards which handovers may occur from the serving cell); one
disadvantage is that the neighbour cell must be received significantly better than the serving cell, which
means the cell will be reported by UEs much later than is possible through other triggering events.
Event A4 (neighbour is better than threshold) and event A5 (serving is lower than threshold1 and
neighbour is better than threshold2) are interesting alternatives that should be supported for trial purposes
and comparison. Of the three events, event A4 is the one that will detect neighbour cells the earliest, as it
has the loosest constraints; one drawback is that UEs may detect cells that will never meet the A3 criterion,
and therefore never be handover candidates. Event A5 is an interesting compromise between A3 and A4,
limiting the A4-type reporting (neighbour is better than threshold) to the outer border of the serving cell
(serving is lower than threshold). Event A3 is recommended for ANR in LA4.0/TLA4.0.
UE capabilities: bits 14, 17, 18 and 19 of the Feature Group Indicator. Bit 14 indicates if EventA4 and A5
are supported. Bit 17 indicates if ANR measurements are supported for intra-freq, bit 18 for inter-freq and
bit 19 for inter-RAT
offset = - eventA3Offset - cellIndividualOffset_s - offsetFreq_s + cellIndividualOffset_n + offsetFreq_n

When the eNB receives an ANR measurement report with one or several unknown PCI, it will request the
UE to report the ECGI of the best unknown PCI using a ‘report-CGI’ reporting configuration. The eNB will
first verify that the UE supports this by checking bit 17 of the FeatureGroupIndicator in the UE capabilities.

Setting up X2 link is essential to create a neighbor relation. This is because the direct X2 handover (with X2
link directly connected to two neighboring eNB) provides better performance than S1 handover in general
as S1 handover has to go through SGW which normally takes much longer time (it involves ePC).
X2 links are not intended to be pre-provisioned at the OAM.
IPV6 (128 bits address) and IPV4 (32 bits address) are supported.
In LR13.1, feature 159506, the X2Instance object is not created if the X2 IP address cannot be retrieved.

The IP address of the eNB hosting a cell that is considered as a neighbour candidate is retrieved through
two different S1 procedures involving the serving MME and the distant eNB itself. These procedures are
described in 3GPP TS 36.413. Here are different steps of the procedure:
1. New neighbour relation has been (partially) defined: only PCI and ECGI of the potential neighbour cell
are known. IP address of the hosting eNB needs to be acquired.
2. ENB CONFIGURATION TRANSFER message is built, including:

Target Global eNB Id and TAI (extracted from the cell ECGI)
Source Global eNB Id and TAI
SON Information Request IE set to “X2 TNL Configuration Info” to request X2 IP address
3. When the message is received by the MME, SON Configuration Transfer IE is transparently copied to
MME CONFIGURATION TRANSFER message that is sent to the eNB identified through received Target eNB-
ID.
4. When MME CONFIGURATION TRANSFER message is received by the target eNB,
5. this one sends back ENB CONFIGURATION TRANSFER message to the MME from which it received MME
CONFIGURATION TRANSFER message. Here, SON Information Reply IE, containing X2 TNL Configuration
Info that carries the IP address, is used.
6. As previously, when receiving the message, the MME transparently copies SON Configuration Transfer IE
into MME CONFIGURATION TRANSFER message that is sent to the source eNB.
7. Source eNB receives the message and extract target eNB IP address from it.

All three messages include two types of information lists:
Served cell information list : since the served cells of eNB 1 (sender of the messages) are the neighbor
cells of eNB 2 (receiver of the messages), eNB 2 will use the served cell information list received from
eNB 1 to update its own neighbor relation list.
neighbor cell information list : it is the neighbor list of the served cells in eNB 1. eNB 2 will store the
neighbor cell information list received from eNB B for future use: If the same PCI is later reported to
eNB 2 by a UE, the stored PCI/ECGI/X2 IP information received from eNB 1 is ready to be used to
create a new neighbor relation. eNB 2 will not need to request UE to search for ECGI in this case

Feature 81872
If either one of the thresholds is set too low, there is a risk of early ending of ANR active phase when the
neighbor relation creation is not yet completed. This will impact the handover successful rate as no
handover can be initiated to a PCI that is not in list of neighbor relations. If either one of the thresholds is
set too high, however, it may cause the ANR active phase to last longer than necessary. During the time,
the eNB will process more measurement reports without finding new PCI.
At the end of the Active phase of one cell of the eNB, the eNB shall send notification to the SAM indicating
the duration of the active phase, the total nb of measurement reports in the active phase, the total nb of
measurement reports without new PCI, the total nb of HO requests, the total nb of RRC reestablishment,
the total nb of call drops requests.

In Dormant phase, if a new PCI is reported as the strongest cell in a HO measurement report, ANR will
enter ANR wake-up phase and trigger the ECGI search (if not available) and eventually the X2 link setup.
The anrMonitoringPeriod (period for ANR to enter the Monitoring phase) is hardcoded 1hour and the
anrDispatchingPeriod (duration of the monitoring phase activities) is harcoded 15sec. Different ANR
functions including intra-frequency ANR, interfrequency ANR and inter-RAT ANR will be assigned by the
ANR Dispatch function to different time slots for entering the monitoring phase based on its RAT and the
created order of its frequency in the RAT.
The main purpose of the monitoring phase for inter-frequency ANR is to verify the known PCIs. When a
known PCI is reported by a UE with ‘Automatic-Neighbor-Relation’ measurement, the UE is configured to
perform ‘Report-CGI’ measurement to check whether there is PCI confusion. When PCI confusion is
detected, if ActivationService::isSonPciAllocationEnabled is set to ‘True’, a warning alarm is raised to notify
the operator of the issue. eNB will attempt to automatically correct the PCI confusion (refer to volume 5 of
LPUG for details). If ActivationService::isSonPciAllocationEnabled is set to ‘False’, however, a critical alarm
is raised to request operator intervention to solve the issue. In this case, eNB will not attempt to
automatically correct the PCI confusion.

In Wake-Up phase, the pool of UEs is larger and the time to discover the ECGI is longer in case of Wake-up
phase compared to the Monitoring phase: the chances to retrieve the missing CGI are bigger.
ECGI search in wake-up phase is performed as below:
Start a configurable timer, AutomaticNeighborRelation::dormantPhaseTimerForCgiDiscovery to limit the
duration of the ECGI search procedure. Setting this parameter to a larger number may increase the
chance to find the ECGI of a new neighbor cell during ANR wake-up phase. However, this will use
more eNB and UE resource since more UE may be configured for ANR measurement report or report-
CGI to find PCI and ECGI. The default value of this parameter is set to 5 minutes.
Request the UE to find ECGI for the unknown PCI
To increase the chance to find ECGI, before the timer is expired and until the ECGI is found:
Configure a number of capable UEs selected by dispatch function to perform ANR measurement. The
maximum number of UEs selected by the ANR dispatch function is limited by
LteIntraFrequencyAnr::uEContributionTargetInActivePhase divided by four
(remark: originally the ANR dispatch period was planned to be 1 minute in length and the range of
values allowed in the MIM was targeted with that in mind, but then it was shortened to 15 seconds in
the final design; this is why the value has to be divided by four)
Request the UEs that report the same unknown PCI to search for the associated ECGI
Once the ECGI is found, eNB will start the process to setup the X2 link if it does not already exist and if
LteNeighboringFreqConf::anrInitiateX2Setup is set to ‘True’.

Rule: Setting lteInterFrequencyAnrEnabled to ‘True’
1. lteIntraFrequencyAnrEnabled must be set preably to ‘True’ to be able to set
lteInterFrequencyAnrEnabled to ‘True’
2. For each cell of the eNB and each LTE neighboring frequency other than the serving frequency, one and
only one UE measurement must be configured with measurementPurpose set to ‘Automatic-Neighbor-
Relation’
3. For each cell of the eNB and each LTE neighboring frequency other than the serving frequency, one and
only one UE measurement must be configured with measurementPurpose set to ‘Report-CGI’

anrActivateAfterX2Setup specifies whether the interfreq ANR function on F1 eNB serving cell is allowed to
enter the active phase towards F2 eNB neighbor cells once X2 link (F1 eNB – F2 eNB) is setup. The
parameter must be set to ‘False’ for serving frequency. If set to ‘False’, the interfreq ANR on F1 eNB serving
cell may enter the Active phase towards F2 eNB cells whatever the status of the X2 link.
anrInitiateX2Setup specifies whether the serving F1 eNB should attempt to establish X2 connection towards
the neighbor F2 eNB handling the new neighbor cell after the cell is discovered by ANR (PCI-ECGI) and X2
link between the two eNBs has not been established. For a given frequency, this parameter must be set to
the same value across the network.
Exemple of usage: Frequency F1 has a broad deployment while frequency F2 is gradually introduced:
For F1 eNBs: anrActivateAfterX2Setup = ‘True’ for F2 neighbor cells so that interfreq ANR will not
enter the active phase before F2 is deployed in this area (X2 must be first setup). anrInitiateX2Setup=
‘True’
For F2 eNBs: anrActivateAfterX2Setup = ‘False’ and anrInitiateX2Setup= ‘True’ for F1 neighbor cells
so that:
interfreq ANR on F2 eNB cells will enter Active phase to find F1 eNB neighbor cells as soon as F2
eNB cells are operational
F2 eNB will establish the X2 connection towards F1 eNB
as soon as the X2 link comes up, interfreq ANR for F1 eNB cells will enter active phase to find F2
neighbor cells
Benefit: the UE camped on one F1 eNB cell will not be requested to measure the F2 eNB cells until the F2
eNB be operational
The scenario to set anrInitiateX2Setup to ‘False’ for F2 neighbor cells is when total number of X2
connections in the serving eNB is reaching its maximum allowed limit and the operator does not want inter-
frequency ANR to create additional X2 connections towards the neighboring inter-frequency eNB.

UE FGI bits for interfreq ANR:
It supports the measurement event type selected (FGI bit 14 is set if event A4 or A5 is selected by
operator for inter-frequency ANR measurement)
It supports ANR related inter-frequency measurement (FGI bit 18 is set) and inter-frequency
measurements in EUTRA connected mode (FGI bit 25 is set)

Similar to the intrafreq/interfreq ANR State Diagram. The update of the UTRAN neighbors is done through
radio interface only (there is no X2 interface between the LTE and UTRAN Base Stations)

UTRAN ANR discovers UTRAN neighbor cells of a given frequency through UE reporting. Since there is no
X2 interface between different RAT, UE reporting is the only way for UTRAN ANR to create and maintain
UTRAN neighbor relations. This is different from intra-frequency ANR. To create a UTRAN neighbor relation,
following information of a UTRAN neighbor cell needs to be discovered: PCI, CGI, LAC and RAC. The
discovery of a new UTRAN neighbor cell can be performed in two steps:
1. eNB will configure a number of UE (with maximum number defined by UtraAnr::
uEContributionTargetInActivePhase) selected by ANR measurement dispatch function to report the PCI of
the strongest UTRAN neighbor cell it detects on a given frequency with measurementPurpose of ‘report-
Strongest-Cells-For-SON’.
2. When UE measurement report for detecting the strongest UTRAN cell is received and the reported PCI of
the UTRAN neighbor cell is known, eNB will configure the UE with measurementPurpose of ‘report-CGI’ to
acquire the neighbor cell’s CGI (contained in SIB3), LAC and RAC (contained in SIB1) by listening to
broadcast channel of the UTRAN cell.

Neighbor relations discovered by UTRAN ANR are used to build the neighbor cells in
UtraFddNeighboringCellRelation MO. Some parameters in a neighbor relation are used by eNB to route the
handover request. Some parameters are used to build different types of neighbor lists to be included in SIB
and in RRCConnectionReconfiguration message to help UE with their neighbor cell search. This is to help
UE to avoid the useless measuring and reporting of the black cells that are forbidden to be used as
handover target cells.

When a UTRAN neighbor cell is discovered, UTRAN ANR will need to find out its controlling RNC in order for
the neighbor relation to be useful for outgoing handover to UTRAN. In LA4.0, the only supported method to
find the controlling RNC is through retrieving the RNC ID from CGI reported by the UE. Since including RNC
ID in CGI is not mandatory in standard, a parameter, UtraAnr::isRncidinUtraCgi, is used to indicate whether
RNCid can be extracted from the UTRAN CGI received in report-CGI measurement report.
If UtraAnr::isRncidinUtraCgi is set to ‘true’, when a ‘report-CGI’ measurement report is received from UE,
the identity of the controlling RNC is extracted. If an RncAccess instance with identical MCC/MNC/RNCid
(MCC and MNC are retrieved from cell CGI) already existed, reference to the RncAccess is added (through
UtraFddNeighboringCellRelation::rncAccessId). Otherwise, a new RncAccess instance is created.
If UtraAnr::isRncidinUtraCgi is set to ‘false’, when a ‘report-CGI’ measurement report is received from UE, if
an RncAccess instance with identical MCC/MNC/LAC/RAC exists, reference to the RncAccess is added
(through UtraFddNeighboringCellRelation::rncAccessId). Otherwise, no controlling RNC information will be
added to the UtraFddNeighboringCellRelation and the neighbor relation will be useful only for redirection
target. A notification will be sent to the operator to signal the issue.
Three new parameters added under RncAccess MO include:
noRemove – This parameter indicates whether the RncAccess MO can be deleted by UTRAN ANR
garbage collection function
RoutingArealocationAreaCode –This parameter indicates the Location Area Code supported by the
target RNC
RoutingAreacode –This parameter indicates the Routing Area Code supported by the target RNC

UTRAN ANR does not use event-triggered measurements (B1, B2) but periodical measurements.
If the UE needs to be configured for mobility measurements (HO), the UTRAN ANR measurement will be
configured in conjunction with the mobility measurements

If either one of the thresholds is set too low, there is a risk of early ending of UTRAN ANR active phase
when the neighbor relation creation is not yet completed. This will impact the handover successful rate as
no handover can be initiated to a PCI that is not in list of neighbor relations. If either one of the thresholds
is set too high, however, it may cause UTRAN ANR active phase to last longer than necessary. During the
time, the eNB will process more measurement reports without finding new PCI.

The Monitoring phase lasts 1 cycle of the Dispatch function (i.e. 15sec.). Then the UTRAN ARN function
goes either in Dormant or in Wake-up phase.

The pool of UEs (300 vs. 10) is larger and the time to discover the CGI is longer in case of Wake-up phase
compared to the Monitoring phase. The chances to retrieve the missing CGI are bigger.
Setting dormantPhaseTimerForEcgiDiscovery to a larger number may increase the chance to find the ECGI
of a new neighbor cell during ANR wake-up phase. However, this will use more eNB and UE resource since
more UE may be configured for ANR measurement report or report-CGI to find PCI and ECGI. The default
value of this parameter is set to 5 minutes.

1) Measurements gaps is used for ‘Automatic-Neighbor-Relation’ and ‘Report-Strongest-Cell’
measurements. Since only one measurement gap configuration is supported by the UE at a time, those
measurements share the same pattern used by inter-frequency/inter-RAT mobility measurement defined for
each RrcMeasurementConf::measurementGapsPattern .
2) DRX is used for ‘Report-CGI’ measurements:
For ANR intra LTE, the UE has up to 1 second (timer T321) to look up and report the ECGI (not an action
that will meet success every time). For intra-frequency global cell identity reporting, the UE uses "idle
periods"; it could represent measurement gaps, DRX periods, or an implementation-dependant mechanism.
The solution with measurements gap is not an interesting solution because the gaps are 6ms every 40ms
(or 80ms). This is too small to read the ECGI of a neighbor cell within 1sec (in SIB1).
eNB must create an idle period that is long enough to be able to read both MIB and SIB1. MIB provides the
SFN of the neighbor in order to derive the periods of SIB1 transmission.
MIB is broadcast with a period of 40ms and repeated every 10ms in SF0 of frames verifying SFN mod4=0
SIB1 is broadcast with a period of 80ms and repeated every 20ms in SF5 verifying SFN mod8=0.
It is then calculated that, in the worst case scenario (UE needs 4 transmissions of MIB and SIB1 to decode
the content), the max time needed is 145ms.
The solution is to force the UE into DRX for a period lower than 145ms (MAC configuration in RRC
Configuration Reconfiguration message)
The consequence is that ECGI reporting is hardly compatible with voice or GBR services >> Only the non
GBR UE will be requested to perform ECGI reporting (QCI between 5 and 9).
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.

At the beginning of each cycle, dispatch function performs the following:
1) For all ANR functions that are in dormant phase, check if ANR functions should enter the monitoring phase (once an
hour)
2) Build the list of ANR functions (one per eNB cell and per frequency intra-UTRAN) that need to have UEs to be
configured for ANR measurements. The ANR functions should meet both of the following conditions:
a. The ANR functions are in active phase, or in wake-up phase, or in monitoring phase
b. The number of UEs configured for the ANR measurement has not reached the corresponding maximum values in the
current cycle
3) Rank the list of ANR functions that need to have UE to be configured for ANR measurements:
a. The ANR function is in which ANR phase – Active phase has the highest priority followed by wake-up phase.
Monitoring phase has the lowest priority.
b. If multiple ANR functions are in the same phase, they will be ranked based on their frequency priority (frequency
priority is defined by MobilityPriorityTable::defaultConnectedPriorityOfFreq)
c. If two more ANR functions have the same frequency priority, they will be ranked randomly.
4) When a UE is available for ANR measurement, it will be configured for the first ANR function in the list that the UE is
capable to support. This goes on until the max number of UE configurations for the ANR is reached. eNB will then
configure all available UEs for the second highest priority ANR function. This goes on until one of the following
conditions becomes true:
a. All ANR functions have reached the required maximum number of UE required
b. No UE is available for ANR measurement
c. Dispatch cycle ends
5) At the end of each dispatch cycle, eNB will:
a. Build a list of ANR functions that has not reached max number of UE configurations as in 2 above
b. Rank the list as in 3 above
c. Configure available UEs from highest priority ANR function to lowest priority ANR function until no more UE is
available or a hard code limit (100 max UE configurations) is reached.

In the first example, target is set to configure 50 UEs for all ANR functions. In (a), based on the
assumption that there are 10 incoming UEs per second, by 5s, intra-frequency ANR has reached its target
of configuring 50 UEs. UEs start sending intra-frequency ANR measurement report at 5s. By 10s, all
configured UEs have sent intra-frequency ANR measurement reports. In (b), dispatch function starts
configure UEs for interfreq measurements at 5s after intra-frequency ANR reaches its UE configuration
target. By 8s, 30 UEs have been configured for interfreq ANR measurements and dispatch function continue
configuring UE for interfreq ANR measurements until it reaches the UE configuration target. In the mean
time, UEs configured earlier for interfreq ANR measurements starts sending measurement reports at 8s
(the total nb of current ANR meas. Conf. is stable because the 30 first UEs beginning to report their
measurements are compensated by the creation of the 20 new ANR meas conf). By 10s, interfreq ANR has
reached its target of configuring 50 UEs. By 13s, all configured UEs have sent interfreq measurement
reports. In c), dispatch function starts configure UEs for UTRAN measurements at 10s when both intra-
frequency ANR and interfreq ANR have reached their UE configuration targets. By 13s, 30 UEs have been
configured for UTRAN ANR measurements and dispatch function continues configuring UE for UTRAN ANR
measurements until it reaches UE configuration target. In the mean time, UEs configured earlier for UTRAN
ANR measurements starts sending measurement reports at 13s. By 15s, UTRAN ANR has reached its
target of configuring 50 UEs. By 18s, all configured UEs will have sent UTRAN measurement reports.

A PCI can have been measured at a point of time but never matched because the neighbor eNB has
changed it due to collision or confusion.
A neighbor relation could disappear due to a modification in the power settings of the target cell.
The two ‘noRemove’ flags mentioned above are used by operator to control whether a neighbor relation or
an X2 link can be deleted by the ANR garbage collection function regardless the neighbor relation or the X2
link is created by ANR or is provisioned by operator. When a neighbor relation or an X2 link is in the black
list (LteneighboringCellRelation::noHO is set to ‘true’ or X2Access::noX2HO is set to ‘true’), the
corresponding ‘noRemove’ flag should also be set to ‘true’. This is to avoid a noHO neighbor cell or noX2HO
X2 link becomes obsolete and be removed, and the neighbor cell is reported back by UE again as a new
neighbor cell or a new handover target candidate, or the X2 link is set up again.

LA5.0 L115149 and L115149.1 Support of Attribute Value Change Notifications allowing autonomous
synchronization of SAM DB on eNodeB configuration self-change

The ANR reset command through XMS GUI is not supported. Instead, ANR function can be reset by a NEM
command through the SNMP MIB browser.

LR13.1 Feature L159506: ANR Enhancements – Phase 3
Each cell maintains a neighbor list with a limited number of neighbor relations (NR). Prior to LR13.1, when the
maximum number of NRs is reached (48 in LA6.0, extended to 72 in LR13.1), no new neighbors could be added.
Beginning in LR13.1, existing neighbor relations that are rarely used may be replaced by new neighbor relations
that are more desired by UEs. This capability is called ANR neighbor replacement.
Neigbour replacement scope in LR13.1 is only for intra-frequency LTE ANR. ANR Neighbor replacement can be
launched in any state.
Neighbor replacement evaluation uses counts of the number of Measurement Reports (ANR and/or mobility,
depending on the configuration indicated by the parameter nRPriCountMode) received during a configurable
evaluation period (nRPriorityStatPeriod ) for each existing MIM neighbor and each new potential neighbor. At the
end of the evaluation period, if one or more potential neighbors have a higher Measurement Report (MR) count
than existing neighbors, then the existing ones are replaced with the potential neighbors that have the higher
counts (unless the parameter ‘NoRemove’ is set to false for the existing neighbor). If there is more than one NR
with the same count being considered to replace or be replaced, and if only one replace operation is possible,
then one will be picked randomly. An optional hysteresis factor nRReplaceHysteresis may be used to require that
the MR count for a potential neighbor be a higher than the existing neighbor by a given percentage before
performing the neighbor replacement.
Counting of measurement reports for a new potential NR will begin only after the ECGI of the NR is retrieved;
this condition avoids unnecessary counting in cases where the NRs cannot be used for replacement. If more
than one PCI is reported in a MR, only the best cell (the first PCI listed in the MR) is considered.

Activation of ANR neighbor replacement is controlled using the parameter nRPriorityStatPeriod. Setting the
parameter to a value between 1 and 2400 will enable ANR neighbor replacement; the length of evaluation period
is the parameter setting in hours. If the parameter is unset, ANR neighbor replacement is disabled. The
evaluation period starts as soon as nRPriorityStatPeriod is set, and does not depend on the ANR phase or
whether the NR limit is reached, as long as there is at least one neighbor relation defined in the MIM.
The operator may choose to base ANR neighbor replacement on counts of ANR MRs, counts of mobility MRs, or
the sum of the two counts. This selection is controlled by the parameter nRPriCountMode.
If the parameter nRReplaceHysteresis is set to a value greater than 0, a new NR must be nRReplaceHysteresis
percent greater than an existing neighbor in order to replace that neighbor. This option is available to avoid
ping-pong of the NR replacement.

To avoid removing neighbors based on unusual fluctuations in the MR counts, filtered values of the MR counts
are used to make replacement decisions. The following filter is used:
Fn= (1-a)*Fn-1 + a*Mn
Where:
- Mn is the latest NR priority (i.e. MR count within the latest evaluation period)
- Fn is the updated filtered NR priority. This value is used for evaluation of NR importance in NR replacement
- Fn-1 is the filtered NR priority from the previous evaluation period. F0 = M1. If the count Fn-1 began in the
middle of the evaluation period, it will not be input to the filter.
- a = 1/2exp(k/4), where k is the parameter filterCoefficentNRPriority
In the evaluation period n following a neighbor replacement, Fn-1 for the newly added NRs will be set to the
filtered NR priority from the previous period (when they were in the potential neighbor list).
K=0: F1= F0=10; F2=M2=16
K=1: F1=10; F2= (1-1/2exp(0.25))*10 + (1/2exp(0.25))*16=15.04 etc.
Low a value favors the latest evaluation period and high a value favors the last evaluation period.

The eNB detects sub-optimal intra-frequency handover behavior (HO Too Late, HO Too Early, HO To Wrong Cell,
and Ping Pong HO) and collects PM counters for each behavior. When the HO Optimization (MRO) feature is
enabled, the eNB uses these counters to identify parameter changes that could potentially reduce the sub-
optimal behaviors; the eNB then automatically changes a set of parameters. A new set of counters is collected
for the interval when the new parameters are used. Based on these counters, the parameter change is
automatically accepted if performance improves or rejected if performance degrades. The algorithm continues to
iterate in small steps until configurable thresholds are reached. If the change did not improve performance a
different parameter set may be changed and evaluated.

Note that usually cellIndividualOffset_s= offsetFreq_s=offsetFreq_n=0.
Then offset = - eventA3Offset + cellIndividualOffset_n

TTT: timeToTrigger; a3offset: eventA3Offset; CIO: cellIndividualOffset
The ‘general’ parameters are for all neighbor cells: timeToTrigger and eventA3Offset
If the value of TTT is unset, the HO Optimization algorithm will not adjust TTT
If a3OffsetMin=a3OffsetMax, the HO Optimization algorithm will not adjust a3Event
If cioMin=cioMax, the HO Optimization algorithm will not adjust CIO

When the feature is initially activated, if both general and CIO adjustment are allowed, then the system will
evaluate whether a general adjustment can be performed after reaching a minimum # of mobility events
summed over all neighbors, and if so will attempt the adjustment and evaluate the results.
After 1 general round is complete (on the 4 parameters change options), the system will evaluate whether a per
neighbor adjustment can be made and if so, will attempt the adjustment and evaluate the results.
The process then continues back to general adjustment and so on until eventually the criteria to stop the
algorithm is reached.

The counters are summed on all neighbor cells

General Parameter Adjustment Attempts:
If FasterTrigger > SlowerTrigger, the eNB may benefit from speeding up the HO trigger. There are four
parameter changes that could accomplish this goal:
• Decrease TTT, • Decrease A3offset, • Decrease both, • Increase TTT and decrease a3Offset
If SlowerTrigger > FasterTrigger, the eNB may benefit from slowing down the HO trigger. There are four
parameter changes that could accomplish this goal:
• Increase TTT, • Increase A3 offset, • Increase both, • Decrease TTT and increase A3 offset
In its given turn, a general parameter change will be attempted unless one or more of the following conditions is
met:
1. If the absolute value of the difference between FasterTrigger and SlowerTrigger is greater than or equal to
fasterSlowerMargin (you must adjust in one direction).
2. The adjustment was attempted in the immediately preceding round and was not accepted, or parameter
settings prevent any changes in the desired direction.
All four options for parameter changes will be tried, one at a time. The option which provides the lowest overall
MRO cost will be selected and becomes the new baseline.
If the conditions are met, the algorithm will change timeToTrigger and/or eventA3Offset in the appropriate
direction by the smallest allowable amount. It will use these values until the total number of mobility events
reaches the configurable threshold minMobilityEventsGeneral. The algorithm then computes the MRO cost for
the interval with the new parameters. If the new MRO cost is lower than the MRO cost associated with the
previous parameter settings, then the attempt is successful and these parameters become the new baseline. Any
remaining alternatives in the preferred directions are still attempted since some of these alternatives may further
improve performance. If the new MRO cost is higher than the baseline, then the attempt fails. If none of the
parameter choices in the preferred direction showed improvement in MRO cost, and if the configurable
parameter attemptOppositeDirection parameter is set to True, then the options in the opposite direction may be
attempted.

Since different neighbors can reach the minMobilityEventsPerNeighbor threshold at different times, the
algorithm must wait for some time after the first neighbor has met the threshold to allow additional neighbors
time to qualify. The configurable target cioBeginAdjustThreshold, expressed as a percentage, is used for this
purpose. The NR chosen for CIO adjustment will be the one of highest imbalance.
Increasing the CIO offset for a particular neighbor speeds up handover to that neighbor; decreasing CIO offset
delays handover to that neighbor.

Feature 103186 LA4.0
If a UE successfully connects with the cell while the sleeping cell alarm is set, then clear the alarm
If the value of parameter sleepingCellInactivityTimer is “0”, then the feature is disabled, and the timer is not
started
The value of the timer must be tuned for each cell, depending on the expected traffic levels. Initially set the
value to 0 and determine typical traffic levels for the cell. Once typical traffic levels are determined, change
parameter value to a level that does not lead to excessive false alarms. Value too low will cause alarms when
there is no fault. Value too high will lead to extended delays before problem conditions are alarmed.

Cell Barring Modification (AR 1-3563691)
When the last S1 link is lost, the eNB starts cellBarringHysteresisTimer and, if
isTurningRadioOffOnS1FailureEnabled =True, radioOffHysteresisTimer (enb; default=1sec) . If the first timer
expires without S1 link recovery, the eNB initiates recovery action . Once recovery action is triggered, the eNB
ceases to handle any calls including emergency calls.
Recovery actions:
Each cell of the eNB is barred (changing LteCell::cellBarred =‘barred’ in SIB1).
Problem: UEs served by neighbor cells can still “see” the cells of the eNB (in fact the Pilot to compute RSRP and
RSRQ), and may attempt HO (will be rejected in the preparation phase because all S1 links are down)
ALU Solution: Add an option to turn off the RF of all cells of the eNB when all S1 links are down
If isTurningRadioOffOnS1FailureEnabled = True and when radioOffHysteresisTimer expires, RF transmission
from cells of the eNB is gradually inhibited when all S1 links are down. No pilot is sent anymore by the cell.
When at least one S1 link becomes available, then the recovery action is undone and cells of eNB go back into
operation

LA5.0 feature L115217. This feature is an alternative of Cell Power Off when all S1 Down.
Upon detection of an S1 link outage the eNodeB will not only auto-bar each cell of the eNodeB but also reduce
the cell referenceSignalPower by a configurable offset (DynamicCoverageMgmt:: cellShrinkForS1LinksOutage
that can be up to 30 dB) to minimize inter-cell interference.
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.
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:
referenceSignalPower - cellShrinkForS1LinksOutage >= minRefSigPower
The value of the cellShrinkForS1LinksOutage parameter should be configured such that:

(a) Connected UEs in the edge of neighbor cell(s) would stop sending measurement reports for intra-LTE HO to
the outage eNB;
(b) Edge UEs previously served by the outage eNB in the coverage overlapping area would now get LTE service
from neighbor cell(s).

Document History
07 2013-12-11 Kine, Jean-Philippe LR13.3 update


Page
1 eUTRAN Sharing 7
1.1 Introduction 8
1.2 Broadcast of PLMN ID of Operators 9
1.3 MOCN License and OAM Impact 10
1.4 Gate Core Network (GWCN) Support 11
1.5 Object Model 12
1.6 Mobility Aspects 13
2 Commercial Mobile Alert System (CMAS) 17
2.1 CMAS Principle 18
2.2 Impacts of CMAS on the DL Scheduler 19
2.3 eNB CMAS Parameters 20
2.4 CMAS Evolution 21
3 Enhanced Multimedia Broadcast Multicast System (eMBMS) 24
3.1 eMBMS Principles 25
3.2 MBSFN Area 26
3.3 MBMS Service and MBSFN Synchronization Area 27
3.4 MBSFN Architecture (3GPP) 29
3.5 Alcatel-Lucent MBSFN Architecture 30
3.6 MBMS Session 31
3.7 MBMS Radio Channels 33
3.8 PMCH Scheduling 34
3.9 SIB2 and SIB13 Usage for MBMS 35
3.10 Management of Several MCH per MbsfnArea 36
3.11 MCCH and MSI Multiplexing 37
3.12 MCE Functions 38
3.12.1 MCE Distributed Architecture 39
3.12.2 Multi Vendors MCE 40
3.12.3 MCE Configuration 41
3.12.4 MBSFN Area Block Partitioning 45
3.12.5 Interaction with SPS 46
3.12.6 Interaction with OTDOA 47
3.13 Supported Bands for eMBMS 49
3.14 eMBMS Object Model 50
4 Location Based Services (LBS) 56
4.1 Positioning based on OTDOA 57
4.2 Positioning Reference Signal (PRS) 58

Page

Multi-Operator Core Network (MOCN)
LA4.0 features:
L104835 eUTRAN Sharing basics: MOCN with shared LTE spectrum
L104836 eUTRAN Sharing – Mobility
LA5.0 features:
L115244 (bCEM) and L115244.1 (eCEM) for GWCN Support
Dedicated spectrum is possible only with the bCEM modem (able to support multi-carrier configuration).
Note that 3GPP TS36.331 requires that all cells of an eNB have the same primary PLMN and to broadcast
this identity in SIB1.
The specific resources in a cell that can be awarded per operator (per PLMN per cell) are: nb of users, nb of
data bearers, nb of data bearers per QCI, nb of PRB in UL or DL
Feature LR13.1 L115680 (test only) 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.

MCC= Mobile Country Code
MNC= Mobile Network Code
For eNB, operators are distinguished by their PLMN (combination of MCC and MNC). Each operator (PLMN)
must provide its own core network including MME and ePC. The eUTRAN may be shared by up to four
operators.
The eNB modem is the eCEM board and the eNB controller is the eCCM board. For instance, the eNB can
have up to 3 eCEM and 1 eCCM per d2U cabinet.

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 eNB value of the isPrimary parameter
value for the associated PlmnIdentity instance to “True”. 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.
Each cell of the eNB will broadcast the list of PLMN identities in SIB1. The primary operator’s PLMN will be
broadcast first in the list. The same list will be broadcast by each cell of an eNB.
Note: Similarly, an LteNeighborPlmnIdentity object also has an isPrimary parameter value to indicate the
primary PLMN for an LTE neighbor cell.
Arrangements are provided in SAM so that each operator can view their own resources, but not see those
devoted to other operators

The eNB will provide the list of PLMN identities that are broadcast on the cells in messages that are
exchanged over the X2 and S1 interfaces: X2 Setup, X2 eNB Configuration Update, S1 Setup, 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. Cell barring applies to all PLMN
IDs, so it cannot be used when access is still available to one or more PLMN ID(s).
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.
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 reselection 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.

Definition: The equivalent PLMNs are treated by the UE as equivalent for the purposes of PLMN selection,
cell selection/reselection and handover.
The serving PLMN and the list of equivalent PLMNs for the call can be obtained from the
HandoverRestrictionList IE included in S1-AP Initial Context Setup Request, Handover Request or Downlink
NAS Transport messages from MME, or X2-AP Handover Request from source eNB at call setup or incoming
handover. The serving PLMN is to be used by the target cell and the list of equivalent PLMN is to be used
for subsequent outgoing mobility procedures (when no target cell is found on the serving PLMN).
eNB will select the best neighbor cell reported by the UE that supports the serving PLMN (to favor intra-
PLMN handover) as the handover target cell. If there is no intra-PLMN target cell available, eNB will select
the best neighbor cell as the target cell that supports one of the equivalent PLMNs. The selected target cell
should not be in the forbidden LAs included in HandoverRestrictionList. For inter-PLMN handover, S1
handover has to be performed no matter the target cell is controlled by the same eNB as the source cell or
is controlled by a different eNB. Target selection for both intra-LTE intra-frequency handover and intra-LTE
inter-frequency handover will take into consideration the supported PLMNs and forbidden LAs for the call.

There has been an interest to ensure that the public has the capability to receive timely and accurate alerts, warnings and critical
information regarding disasters and other emergencies irrespective of what communications technologies they use.
The high level requirements for the feature are summarized below:
PWS shall be able to broadcast Warning Notifications to multiple users simultaneously with no acknowledgement
PWS shall be able to support concurrent broadcast of multiple Warning Notifications.
Warning Notifications shall be broadcast to a Notification Area which is based on the geographical information.
PWS capable UEs (PWS-UE) in idle mode shall be capable of receiving broadcasted Warning Notifications.
An initial support for alerting end users was already included in LTE Release 8 known as the ETWS feature, i.e. Earthquake and
Tsunami Warning Systems. PWS extends the possibilities from ETWS in Rel.9 by providing:
support for multiple parallel warning notifications (up to 64)
support for replacing and cancelling a warning notification
support for repeating the warning notification with a repetition period as short as 2 seconds and as long as 24 hours
support for more generic "PWS" indication in the paging indication
The principle for notification of warning messages is maintained, i.e. the end user devices receives dedicated paging upon availability
or change of warning messages. The E-UTRAN performs scheduling and broadcasting of the ‘warning message content’ received from
the Cell Broadcast Center (CBC), which is forwarded to the EUTRAN by the MME. The warning messages itself is then broadcasted in
dedicated system information blocks. ETWS messages are included in SystemInformationBlockType10 and
SystemInformationBlockType11. The enhancement in LTE Release 9 is named CMAS developed for the delivery of multiple, concurrent
warning notifications. The CMAS warning notifications are broadcast in SystemInformationBlockType12.
Note that paging is used to inform CMAS capable UEs in both RRC_IDLE and RRC_CONNECTED state. If the UE receives a paging
message including the cmas-Indication, it shall start receiving the CMAS notifications according to schedulingInfoList contained in
SystemInformationBlockType1 (the UE will not wait for the next modification of the SIB12 but will acquire the SysInfo Block related to
CMAS immediately)
In order to satisfy the requirement of replacing or canceling warning messages new procedures between eNB and MME are
introduced. The Write-Replace procedure is initiated by the MME by sending Write-Replace Warning Request message containing at
least the message identifier, warning area list, information on how the broadcast should be performed, and the contents of the
warning message to be broadcast. The eNB responds with Write-Replace Warning Response message to acknowledge that the
requested PWS warning message broadcast was initiated. ETWS and CMAS are independent services and ETWS and CMAS messages
are differentiated over S1 in order to allow different handling.
The Kill procedure is used to stop the broadcasting of a PWS warning message. The procedure is initiated by the MME sending the Kill
Request message containing at least the message Identifier and serial number of the message to be killed and the warning area list
where it shall be killed. The eNB responds with a Kill Response message to acknowledge that the requested PWS message broadcast
delivery has actually been stopped.

From TS36.413, “Emergency Area ID may consist of several cells. Emergency Area ID is defined by the operator.”
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. 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
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 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.
A scheduling class for SIB12

Feature LA6.0 L134392 (CMAS Evolutions Step1) . This feature does not add any new configuration
parameters

MBMS (Multimedia Broadcast and Multicast Channels) is used to send the same information to all UEs
(broadcast) or to a given set of UEs (multicast) for services such as mobile TV.
Evolved MBMS (eMBMS) is defined by 3GPP Release 8 and 9. The goal is to increase spectral efficiency at
the cell edge up to 1bps/Hz while realizing a Single Frequency Network (SFN). In addition MBMS
capabilities are increased compared to 3G, by offering 20 TV channels at a data rate of 256 kbps in a 5 MHz
channel.
SFN (Single Frequency Network) is required to synchronize the eNBS: the eNBs of a given MBSFN area are
synchronized and the same info is broadcast on the same radio resource (PMCH) to several neighbor eNBs.
The M-frames are not acknowledged at MAC/RRC level (RLC Unacknowledged Mode).
PMCH shall not be transmitted in subframes 0 and 5 (required for unicast proper synchro and BCCH) and in
subframes 4 and 9 (0, 4, 5 and 9 can be used for Paging depending on the Paging cycle): Up to 6
subframes per radio frame can be allocated to MBSFN.
In order to enable a coherent demodulation at the terminal as well as proper channel estimation the use of
cell-specific reference signals is not sufficient. Thus reference signals for MBMS transmission have been
adopted. Each cell belonging to the MBSFN area will transmit the same MBSFN reference signal pattern at
the exact same time-frequency position. MBSFN Area Identity is broadcasted in SIB13.
You can configure the physical layer to have subframes with only M-frames or with a mix M-frames and
regular frames.
Mix PMCH and PDSCH configuration is supported. Mix configuration allows to keep regular control channels
(PDCCH, PCFICH, PHICH and also RS) even during the MBSFN subframes. In the subframes where PMCH is
transmitted, up to 2 first OFDM symbols of the subframe are reserved for control channels of non-MBSFN
data. Normal CP is used in the first 2 OFDM symbols. The others symbols are for MBSFN. Each PRB
contains a maximum payload of 102 REs for PMCH transmission. Extended cyclic prefix is used in the
MBSFN region.

To support the broadcast effect required for MBMS radio cells, that are supposed to transmit the same
content need to be synchronized. In that case the resulting signal will appear to a terminal as just one
transmission over a time-dispersive radio channel. This is understood as Multimedia Broadcast Single
Frequency Network (MBSFN). Radio cells that shall transmit the same content to multiple users will form a
so called MBSFN area. Multiple cells can belong to such an area, and every cell can be part of up to eight
MBSFN areas. There could be up to 256 different MBSFN areas defined, each one with an own identity.
Once defined, MBSFN areas will not change dynamically. Further it is not defined, that a terminal should
receive content from multiple MBSFN areas simultaneously.

•Content provider: In charge of delivering the media. (TV channels, radio channels, filedownload, etc.)
•The BM-SC (Broadcast/Multicast Service Center) has been already introduced with 3GPP Release 6 (with
UMTS). Its tasks are authentication, authorizing content provider, charging and the overall configuration of
the data flow through the core network.
•The MBMS Gateway (MBMS GW) is the logical node handling the multi-cast of IP packets from the BM-SC
to all LTE base station. The SYNC protocol (with frame timing info) is used to ensure that content is
synchronized for multicell MBSFN transmission. It further handles session control via the MME.
•Mobile Management Entity (MME) is not a MBMS-only related network element. In fact it is part of the
3GPP Release 8 network architecture. The MME handles all tasks, that are non-related to the air interface.
That means all Non-Access Stratum (NAS) protocols are terminated in the MME.
•Key element for MBMS in LTE is the MCE, the Multi-cell/Multicast Coordination Entity. This is a new node
designed to coordinate the transmissions from multiple cells, which would otherwise be difficult to achieve
in the flat architecture of LTE. The role of the MCE includes allocating the time/frequency radio resources
used by all eNodeBs in the MBSFN area, ensuring that the same resource blocks are used across the whole
MBSFN area for a given service, and deciding the radio configuration (modulation and coding scheme).
Thus for MBMS the radio scheduling and configuration roles which are normally the responsibility of the
eNodeBs are instead centralized. There are two ways of integrating the MCE to the network. Directly to the
LTE base station. This is very cost effective as it is in most cases only a simple software upgrade to the
existing hardware. The drawback is of course, that only cells that belong to that particular base station can
form a MBSFN area. To avoid this limitation the MCE can be added as separate network element to the
architecture.

New in LR13.3 (feature 167219): eMBMS Commercial with distributed MCE; provides the following benefits:
• Provide the eNodeB support of full 3GPP Rel9 and eMBMS function and Rel 10 for Interfaces
• MCE (Multi-cell/Multicast Coordination Entity) distributed and eNodeB integrated => coordinates the
radio resources in MBSFN areas.
• The MCE allocates radio resources semi-statically for eMBMS services according to the M3-AP
procedures (session start and session stop).
BPS: Broadcast Provisioning System (provision & control of eMBMS services)

BM-SC: Broadcast Multicast – Service Center
BM-SC –ADF: BM-SC / Associated Delivery Functions
• file repair, report, key delivery, …
BM-SC –MDF: BM-SC / Media Delivery Functions

• Control Plane functions:
• Control of eMBMS sessions: MBMS session start/update/stop (eMBMS bearer setup/update/release)
• User Plane functions:

• Content ingestion point (interface to file servers & encoders)
• eMBMS bearer content processing: FLUTE/FEC, SYNC
• Content distribution to MBMS-GWs
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.

The BM-SC may initiate multiple sub-sessions with different content, distinguished by flow identifiers. The
‘Session Start Request’ message from the BM-SC includes the following parameters: • QoS: Used for the
admission control and radio resource configuration in the MCE. • Service area: Used to decide to which
eNodeBs the session start signalling should be forwarded. • Session duration: Used by admission control in
the MCE. • Time to data transfer: Used by the MCE to ensure all UEs receive the control information in
time. • Access indicator: Indicates in which Radio Access Technologies (RATs) the service will be broadcast.
Upon receiving the session start request, the MCE performs admission control, allocates IP multicast
addresses, and allocates and configures the radio resources. The MCE provides the relevant session
parameters (e.g. the multicast address) to the eNodeB by means of the ‘Session Start Request’ message.
Likewise, the MCE transfers the radio resource configuration within a ‘scheduling information’ message to
the eNodeB. Upon receiving these messages, the eNodeB notifies the UEs about a change of MCCH
information and subsequently provides the updated MBMS radio resource configuration information within
the MBSFNAreaConfiguration message. The eNodeB also joins the transport network IP multicast address.
The MBMS control information is mainly carried by the MCCH; the BCCH merely carries the control
information needed to acquire the MCCH and to detect MCCH information changes. Transmission of MBMS
control information on the BCCH (i.e. in SIB13) is performed according to the usual procedures for SIBs.
The MBSFNAreaConfiguration on MCCH is repeated a configurable number of times within the modification
period.
When an MBMS session is started, E-UTRAN notifies the UEs about an MCCH information change. This
change notification is provided a configurable number of times per modification period, by means of a
message on the PDCCH using Downlink Control Information (DCI) Format 1C, using a special identifier, the
MBMS Radio Network Temporary Identifier (M-RNTI). This message indicates which of the configured
MCCHs will change. UEs that are interested in receiving an MBMS session that has not yet started should
try receiving the change notification a minimum number of times during the modification period. If the UE
knows which MBSFN area(s) will be used to provide the MBMS session(s) it is interested in receiving, it has
to meet this requirement only for the corresponding MCCH(s).

The System Information Block Type 2 (SIB Type 2) carries all relevant information about common and
shared channels in LTE. Due to this importance it is part of every single System Information (SI) message
in LTE. With 3GPP Release 9 it has been extended to provide also information on MBMS. The new
information element (IE) MBSFN-SubframeConfig defines which radio frames contain subframes, that can
be used for MBMS. These so called MBSFN subframes can be used by all MBSFN areas. First important
information are the radio frame allocation period and a radio frame allocation offset. This two information
now determines the periodicity when radio frames occur that contain MBSFN subframes. Further subframe
allocation mode is defined within SIB Type 2. It could be one radio frame or four consecutive radio frames
that allow MBSFN subframes. Subframes 0, 1,2,5,6,7 cannot be used for MBMS. Which of the possible
subframes are really used for MBMS is indicated by a bitmap.
As both, control and traffic channel (MCCH, MTCH) are mapped to the Multicast Channel (MCH), there is a
kind of ‘chicken-and-egg’ problem as the one channel (MCCH) contains information how the other channel
(MTCH) is organized and how to access it. This problem is solved while introducing the SIB Type 13, which
provides the following information:
MBSFN identity (MBSFN ID)
Non-MBSFN region length (1, 2 OFDM symbols)
MCCH configuration
The MCCH configuration provides information on the repetition period for the MCCH, the MCCH offset as
well as the actual subframe, where the MCCH is transmitted in as well as the MCS used for the MCCH.
Coming back to our previous example, all this information may lead to the shown scenario. Selected
repetition period of 32 means that every 32 radio frames the MCCH occurs in one of the MBSFN subframes.
Which one is also determined by information part of the SIB Type 13, including the used modulation coding
scheme. It is important to note that for the MCCH four modulation coding schemes are allowed: MCS index
2, 7 (both QPSK), 13 (16QAM), 19 (64QAM).

An instance of object MbsfnMtch needs to be generated for each MTCH logical channel and is identified by
MbsfnMtch::logicalChannelIdentity.
The configuration of the MBMS bearer that is mapped to the MTCH logical channel is defined in an instance
of object MbmsBearerService that is associated to that MBMS bearer.
The mapping between MTCH logical channel (i.e. the instance of MbsfnMtch identified by
MbsfnMtch::logicalChannelIdentity) and the MBMS bearer (i.e. the instance of MbmsBearerService
identified by MbmsBearerService::ServiceId) is achieved through parameter mbmsBearerServiceId.

Extract from 3GPP Rel’9-11 TS 36.300 sect. 15.1.1

Extract from 3GPP Rel’9-11 TS 36.300 sect. 15.1.1
only single eNB vendor per MBSFN area is supported

OTDOA: Observed Time Difference of Arrival
Position estimation is on measuring the Time Different Of Arrival (TDOA) on special reference signals (PRS: Positioning
Reference Signals), embedded into the overall downlink signal, received from different eNB’s. Each of the TDOA
measurement (timing difference between a subframe received from the neighboring cell j and corresponding subframe
from the serving cell i) describes a hyperbola, where the two focus points are the eNBs. The measurement needs to be
taken at least for three pairs of base station. The position of the device is the intersection of the three hyperbolas for
the three measured base stations (a-b, a-c, b-c). The results are reported back to the location server (LS), where the
calculation of the position happens.
A new PRS has been created by 3GPP R9 for positioning because the regular RS is not sufficient. The simple reason is
that the required high probability of detection could not be guaranteed. A neighbor cell with its synchronization signals
(Primary-/ Secondary Synchronization Signals) and reference signals is seen as detectable, when the Signal-to-
Interference-and-Noise Ratio (SINR) is at least -6 dB. Simulations during standardization have shown, that this can be
only guaranteed for 70% of all cases for the 3rd best-detected cell, means 2nd best neighboring cell. This is not
enough and has been assumed an interference-free environment, which can not be ensured in a real world scenario.
However, PRS have still some similarities with cell-specific reference signals as defined in 3GPP Release 8. It is a
pseudo-random QPSK sequence that is being mapped in diagonal patterns with shifts in frequency and time to avoid
collision with cell-specific reference signals and an overlap with the control channels (PDCCH).
PRS are defined by bandwidth N(PRS,RB), offset delta (PRS), duration N(PRS) = number of consecutive subframes and
periodicity T(PRS). Its worth to be noted, that PRS bandwidth is always smaller than the actual system bandwidth
N(DL,RB). PRS are always mapped around the carrier frequency, the unused DC subcarrier in the downlink. In a
subframe where PRS are configured, typically no PDSCH is transmitted. PRS can be muted on certain occasions to
further reduce inter-cell interference. All this information, means PRS configuration and PRS muting is provided via the
LPP protocol from the Location Server.
From a RAN perspective, the real issue is synchronizing all eNBs to a common reference signal (i.e.GPS), and then
aligning their downlink signals at the antenna. This allows the UE to make relative measurements of the arrival time.
The antenna path delay is to be entered to an accuracy of +/- 50 nsec (instead of the normal +/- 125 nsec).

The exact number of PRS-RBs is prsBandwidth RBs when the difference ( N(DL,RB) -prsBandwidth) is even
and (prsBandwidth +1) RBs when the difference is odd, where N(DL,RB) is the total number of RBs in the
bandwidth

All Rights Reserved © Alcatel-Lucent @@YEAR
@@COURSENAME - Page 1
All rights reserved © Alcatel-Lucent
Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent
All Rights Reserved © Alcatel-Lucent @@YEAR

@@COURSENAME - Page 2

TMO18315 - V7.0 SG ENLR13.3L Ed1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TMO18315 - V7.0 SG ENLR13.3L Ed1

Uploaded by

Copyright:

Available Formats

Passing on and copying of this document, use and communication of its

contents not permitted without written authorization from Alcatel-Lucent

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

PERMISSION TO USE CONTENT

COPYRIGHTS AND TRADEMARKS

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

1. 9400 LTE Radio Algorithms And Parameters Description

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Upon completion of this course, you should be able to:

Describe all the radio features until LR13.3 (FDD),

Your feedback is appreciated!

Please include the following training reference in your email:

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Edition Date Author Remarks

07 2013-12-11 Kine Jean-Philippe Update LR13.3

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

1 LTE RAN LA6 to LR13.3L delta Features 7

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Edition Date Author Remarks

01 YYYY-MM-DD Last name, first name First edition

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

1 MIMO and Transmission Mode 7

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

3.9.2 RACH Format 3 79

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.