4 Ltelayer3analysispart2 160408140151

4.
LTE Layer 3 Analysis (Part 2)
Author : Ray Khastur

Title : LTE Optimization Consultant MobileComm Professionals, Inc MobileComm Professionals, Inc
Consulting | Training | Research

Company Confidential - Pinnacle Learning Center
4.1 LTE MOBILE TERMINATED CSFB
CALL

Mobile Terminating CSFB -> GERAN
Based on the capabilities of UEs and networks, five fallback mechanisms are available for an eNodeB to perform CSFB to
GERAN:
R8 PS Redirection
R9 PS Redirection (Flash CSFB)
CCO
After receiving a CS Fallback Indicator, the eNodeB sends a MobilityFromEUTRACommand message containing information
about a target GERAN cell to the UE, and instructs the UE to access the target cell. The UE needs to be synchronized to the
specified cell, obtains system information about the target cell, and accesses the cell to initiate CS services.
CCO with NACC
When the LTE-to-GSM RIM procedure is enabled, which indicates that NACC is enabled, the eNodeB delivers system
information about the target cell when triggering CCO. The UE directly initiates access and a CS service to the target cell and
does not need to read system information about the target cell, shortening delays.
PS Handover
MobileComm Professionals, Inc

1 to 3. An UE in an LTE cell receives a paging message.
Upon detecting that the UE is in idle mode, the eNodeB sends a Paging request
message carrying an SAE-temporary mobile subscriber identity (S-TMSI) or
international mobile subscriber identity (IMSI), to the UE.
Upon detecting that the UE is in connected mode, the eNodeB sends a CS Paging
Notification message to the UE.
4. The UE sets up a radio resource control (RRC) connection and sends an
Extended Service Request message that carries the "CS Fallback Indicator" IE to
inform the MME to initiate CSFB.
5. The MME sends an SGs Service Request message to stop the MSC from
resending paging messages over the SGs interface.
6. The MME sends an Initial UE Context Setup message carrying the CS Fallback
Indicator IE to instruct the eNodeB to migrate the UE to a GSM cell.
7. The eNodeB selects a target GSM cell for the UE based on the measurement
result or LTE network configuration.
8. (Optional) If both the GSM and LTE networks support the RIM procedure, the
eNodeB starts the RIM procedure.
9. The eNodeB instructs the UE to access the target GSM cell as follows:
9a. If both the UE and the network support PS handovers, the eNodeB initiates an
LTE-to-GSM PS handover.
9b. If both the UE and the network support LTE-to-GSM CCO instead of PS
handovers, the eNodeB sends a MobilityFromEUTRACommand message to the
UE. The MobilityFromEUTRACommand message indicates that the purpose is
cellChangeOrder. If the LTE-to-GSM eNACC procedure is used, the
MobilityFromEUTRACommand message carries the GSM cell ID and the SI
(including SIB1, SIB3, and SIB13). If this procedure is not used, the message
carries only the GSM cell ID.
9c. If the UE or the network supports neither LTE-to-GSM CCO nor PS handovers,
the eNodeB sends an RRC connection release message to redirect the UE to a
GSM cell.
10. The eNodeB releases the S1 UE Context.

11. The UE sends a Channel Request message to the BSC.
If the LA changes, the BSC proceeds with step 13.
If the LA remains unchanged and CSFBIDENTIFYMTSW(BSC6900,BSC6910) is
set to ON(On), the BSC identifies the CSFB MTC based on the cause value
contained in the Channel Request message.
NOTE :
This process is referred to as CSFB MTC identification. According to 3GPP TS
44.018 v8.9.0, depending on the Paging Indication value contained in the paging
message from the GSM network, the called UE contains any cause value (except
the value corresponding to "Any channel") in the Channel Request message. On
the LTE network, however, the paging message from the eNodeB does not
contain the Paging Indication IE, and a UE that falls back to the GSM network
contains the cause value corresponding to "Any channel" in the Channel Request
message
12. (Optional) If the CSFBIMMASSENSW parameter involved in the GBFD-

160203 CSFB QoS feature is set to ON(On), the BSC starts the TCH immediate
assignment procedure. For details about the CSFB QoS, seeCSFB QoS Feature
Parameter Description.
13. (Optional) If the LA changes after the UE accesses the GSM cell, the UE
performs an LAU procedure or combined RAU/LAU procedure.
The BSC determines whether the call is a CSFB call based on the value of circuit
switched fallback mobile terminated call (CSMT) in the "Additional update
parameters" IE contained in the RAU or LAU message.
If the call is not a CSFB call, the BSC processes the call following the common call
access procedure.
If the call is a CSFB call and SUPPORTCSFB(BSC6900,BSC6910) has been set
to SUPPORT(Support), the BSC proceeds with subsequent steps.
If the call is a CSFB call but SUPPORTCSFB(BSC6900,BSC6910) has been set
to UNSUPPORT(Not Support), the BSC rejects the call.

If a UE cannot report the "Additional update parameters" IE, it uses the paging-
based CSFB call identification function to identify a CSFB MTC.
When CSFBPagingIdentifySw(BSC6900,BSC6910) is set to ON(On), if the BSC
receives a paging message from the MSC:
The BSC buffers the paging message carrying the temporary mobile subscriber
identity (TMSI).Upon receiving a paging response message from the UE, the BSC
will match the paging response message and the buffered paging message.
Based on the matching result, the BSC determines whether the MTC is a CSFB
MTC.
If the paging response message and the buffered paging message match,
the BSC determines that the MTC is not a CSFB MTC.
If the paging response message and the buffered paging message do not
match, the BSC determines that the MTC is a CSFB MTC. This is
because the paging message of a CSFB call is not included in buffered
paging messages but delivered from the LTE network.
If the LA changes, the UE performs an LAU or combined RAU/LAU
procedure before initiating a call. In this case, the BSC needs to determine
whether the UE initiates an MTC based on the subsequent call procedure.
If the UE initiates an MTC, and the paging response message and the
buffered paging message match, the BSC determines that the call is not a
CSFB MTC. Otherwise, the BSC determines that the call is a CSFB MTC.
The BSC does not buffer the paging message carrying the IMSI.If such a call
cannot be identified based on the CSMT or using the very early identification
mode, the BSC determines that the call is not a CSFB MTC.
When CSFBPagingIdentifySw(BSC6900,BSC6910) is set to OFF(Off), the BSC
processes the call following the common call access procedure.
14 to 17. (Optional) If the UE is processing PS services before initiating a

call, and neither the UE nor the network supports Dual Transfer Mode
(DTM), the UE suspends the PS services.
18 and 19. The UE sends a paging response message to the MSC through
the BSS.
The BSC determines whether the call is a CSFB call based on the value of
CSMT in the "Additional update parameters" IE carried inProfessionals,
MobileComm the paging Inc
response message. The determination process is the same as that
described in step 13. Consulting | Training | Research
In MSC pool networking mode, after receiving a message in response to the
CSFB paging message from a UE accessing a GSM cell, the BSC performs either
of the following operations:
If the CSFB paging response message delivered by the eNodeB carries the
Temporary Mobile Subscriber Identity (TMSI), the BSC obtains the DSP of the
MSC according to the NRI in the TMSI information and sends a paging response
message to the MSC.
If the CSFB paging response message delivered by the eNodeB carries the IMSI
(International Mobile Subscriber Identity): When
the CSFBPAGRSPBCSWITCH(BSC6900,BSC6910) parameter is set
to YES(namely, the MSC supports Roaming Retry), the BSC randomly selects an
MSC from the MSC pool and sends the paging response message to the MSC.
When theCSFBPAGRSPBCSWITCH(BSC6900,BSC6910) parameter is set
to NO (namely, the MSC does not support Roaming Retry), the BSC discards the
CSFB paging response message.
20 to 22. (Optional) If the UE does not register with the MSC or the UE is not
allowed to access the LA, the MSC rejects the paging response and releases the
A interface links. The BSC then releases the signaling channel over the Um
interface. After the signaling channel over the Um interface is released, the UE
obtains the location area identity (LAI) and performs an LAU procedure.
23. The MSC initiates a CS call setup procedure.
If a UMTS network is available,
set SendUtranECSCFlag(BSC6900,BSC6910) to YES(Yes) to allow UEs to
proactively report 3G classmarks to the BSC. However, Classmark reporting
increases the call setup delay. To shorten this delay,
set UTRANCMDELAYFORCSFBSW(BSC6900,BSC6910) to ON(On) for CSFB
calls. This setting prohibits UEs from reporting 3G classmarks to the BSC. If an
early assignment procedure is used, the BSC proactively queries 3G classmarks
after the alerting procedure. If a late assignment procedure is used, the BSC
proactively queries 3G classmarks after assignment is complete.
24. (Optional) The UE performs an LAU or combined RAU/LAU procedure.
If the GBFD-511312 Fast LTE Reselection at 2G CS Call Release feature is
enabled, the UE quickly returns to an LTE cell. If there are suspended PS
services, the UE restores the PS services in the LTE cell.
If the GBFD-511312 Fast LTE Reselection at 2G MobileComm
CS Call ReleaseProfessionals,
feature is Inc
disabled, the UE continues to camp on the GSM cell. If there are suspended PS
Company Confidential - Pinnacle
services, the Learning
UE initiates Center
an RAU in the GSM cell to restore the PS services.
Paging Notification

EMM Extended
Service Request

RRCConnectionReconfiguration

Offset Event A3
Hysterisis Event A3

A1 Thd
A2 Thd
B1 Thd

Current RSRP bigger

than A1 Thd
Measurement Report

List of Registered
GSM ARFCN
RRCConnectionRelease

U2000 Configuration to add GERAN BCCH target only

to DCS1800 or PCS1900

Location Update
Request

BSC buffer TMSI
The TMSI was not match from LTE and GSM. So If the
Channel Request paging response message and the buffered paging message do
with Paging not match, the BSC determines that the MTC is a CSFB MTC. This
is because the paging message of a CSFB call is not included in
Response buffered paging messages but delivered from the LTE network.

Immediate
Assignment

Immediate
Assignment
Extended

System Information Type 6

(Redirection Info)

Location Update
Accept

Call Process
CS Call
Establishment
Procedure

Call Process
CS Call
Establishment
Procedure

Call Process
CS Call
Establishment
Procedure

Call Process
CS Call
Establishment
Procedure

CSFB to GERAN
has time stamp
from Extended
Service Request
on LTE Network
until CS Call of
target ringing
CSFB Call Setup

Complete

CSFB to GERAN Call

Setup Duration
Extended SR : 23:14.844
CC Alerting : 23.21.544
Duration =6.700ms

In this signaling flow explain detail MTC Ultra-
Flash CSFB 2G
1a to 3a. A UE initiates voice services in an LTE cell. The
eNodeB triggers an LTE-to-GSM SRVCC handover for the
UE.
NOTE:
In the MTC Ultra-Flash CSFB procedure, the MSC sends the
Paging request or CS Paging Notification message to the UE
before the UE sends the Extend Service Request message to the
MME.
3b. After receiving the SRVCC handover request from the
MSC, the BSC identifies the Ultra-Flash CSFB call and
prepares CS resources for the call.
The BSC checks whether the configurations of MCC, MNC,
LAC, and SAC in the service area identifier (SAI) for a call
are consistent with those configured on the MSC server. If
they are, the BSC determines the call is an Ultra Flash
CSFB call. If they are not, the BSC determines that the UE
performed a UMTS-to-GSM inter-RAT handover.
The MCC, MNC, LAC, and SAC can be configured using
parameters in
the GCELLCSFBPARA or GSAIFORLTE MO. The details
are as follows:
MCC: UltraFlashCSFBSAIMCC(BSC6900,BSC6910) (GCE
LLCSFBPARA MO)
or SAIMCC(BSC6900,BSC6910) (GSAIFORLTE MO)
MNC: UltraFlashCSFBSAIMNC(BSC6900,BSC6910) (GCE
LLCSFBPARA MO)
or SAIMNC(BSC6900,BSC6910) (GSAIFORLTE MO)
LAC: UltraFlashCSFBSAILAC(BSC6900,BSC6910) (GCEL
LCSFBPARA MO)
or SAILAC(BSC6900,BSC6910) (GSAIFORLTE MO)
MobileComm Professionals, Inc(GCE
SAC: UltraFlashCSFBSAISAC(BSC6900,BSC6910)
LLCSFBPARA MO)
or SAISAC(BSC6900,BSC6910)
Company Confidential - Pinnacle Learning Center (GSAIFORLTE MO)
Flash CSFB 2G
In the MME pool or MOCN scenarios, if a BSC is connected
to multiple MSC servers, which are configured with different
SAI values, the BSC also needs to be configured with
multiple SAI values. The GCELLCSFBPARAMO can only
be used to configure one set of SAI parameters. To add
more SAI values, the GSAIFORLTE MO can be used. The
MCC, MNC, LAC, and SAC on the BSC are the combination
of the GCELLCSFBPARA MO and GSAIFORLTE MO.
NOTE:
When no SAI parameter has been configured through
the GCELLCSFBPARA MO, the GSAIFORLTE MO can also be
used to configure multiple sets of SAI parameters
4. The CN sends the Handover Command message to the
eNodeB, and the eNodeB sends the message to the UE.
5. The UE is handed over to the GSM network.
6 to 9. The UE establishes CS services on the GSM
network.
Signaling is carried by traffic channels (TCHs), accelerating
signaling transmission.
In the MOC Ultra-Flash CSFB and MTC Ultra-Flash CSFB
procedures, before sending or receiving the Alerting
message, the MSC sends the UE a Disconnect message,
instructing the UE to release a default session generated
during the SRVCC handover. This mechanism helps prevent
interference on subsequent session establishment. After the
UE is handed over to a GSM cell, if the UE sends the
Disconnect message to the MSC to release the default
session, the MSC does not send the Disconnect message to
the UE before sending or receiving the Alerting message

Flash CSFB 2G
Ultra-Flash CSFB eliminates the dimmed signaling
procedures shown in Figure 3-3 and Figure 3-4. The
following details the reasons why these signaling procedures
are eliminated:
AuthenticationThe UE has been authenticated on the LTE
side before it is handed over from an LTE cell to a GSM cell.
EncryptionThe UE has performed encryption as instructed
during the SRVCC handover.
IMEI queryThe MME has sent the IMEI to the MSC during
the preparation for the SRVCC handover.
CS resource establishmentThe GSM network has prepared
CS resources during the SRVCC handover procedure and
the UE does not need to reestablish CS resources after the
SRVCC handover.

Mobile Originating CSFB -> UTRAN
Based on the capabilities of UEs and networks, three fallback mechanisms are available for an eNodeB to perform CSFB to
UTRAN:
R8 PS Redirection
After receiving a CS Fallback Indicator, the eNodeB sends an RRC Connection Release message containing frequency
information about the target UTRAN to the UE. Based on the received frequency information, the UE searches for a UTRAN cell,
obtains the system information of the UTRAN cell, and initiates initial access and CS services.
R9 PS Redirection (Flash CSFB)

After receiving a CS Fallback Indicator, the eNodeB sends an RRC Connection Release message containing information about a
target UTRAN frequency as well as system information about multiple target cells to the UE. Based on the received frequency
information, the UE searches for a UTRAN cell. As the UE obtains system information about the target cell, the UE initiates initial
access and CS services in the target cell, thereby reducing voice delay.
PS Handover
The UE is handed over to the UMTS network through the PS handover procedure between the eNodeB and the UMTS network.
After the handover, the UE initiates CS services in the target cell.

Mobile Terminating CSFB -> UTRAN
In this signaling flow

explain detail on LTE
side

DL Information Transfer

EMM CS Service Notification


EMM Extended Service Request


Target 3G Cell
Freq & SC
RRC Conn Rcfg (B1)


RRC Conn Rcfg

CMP MobileComm Professionals, Inc

Measurement
Report MobileComm Professionals, Inc

In this information, UE was
redirection to 3G Network with
Scrambling Code 252 with 3G
Freq 10612
RRC Connection
Release MobileComm Professionals, Inc

SIB1
SIB3
SIB5
SIB7
SIB11
Master
Information Block
3G

The RNC sends SIB19 messages to UEs if the

cell to be enabled with this feature is
configured with information about the
frequencies of neighboring LTE cells and
the SIB19 check box under the SIB
Switchparameter is selected. The SIB19
message contains the neighboring LTE cell
list and LTE cell reselection parameters
SIB19 optional
SB 1 3G

SIB Type 1 3G

SIB Type 3 3G

SIB Type 5 3G

SIB Type 5 3G

SIB Type 7 3G
The UL interference IE in SIB7 is one of the factors that determine the UE initial access level. The value of this IE
frequently changes with the network traffic conditions. To prevent a large amount of system information update
procedures caused by uplink interference, the RNC always sends the eNodeB the value of -105 dBm as the value of
the UL interference IE. It is worth noting that this may decrease the RRC connection setup success rate when the
UMTS uplink load is heavy.
For details about definition on the UMTS cell identity, see section 9.2.1.61 "Source Cell Identifier" in 3GPP TS 25.413
V10.3.0. For details about the types of RAN system information contained in the RIM Application Identity IE, see section MobileComm Professionals, Inc
10.2.48a "System Information Container" in 3GPP TS 25.331 V11.3.0.
Its contain
IntraFreq
Neighbor List
SIB Type 11 3G

SIB Type 12 3G

RRC Connection Procedure



UL Direct Transfer (Paging

Response)

Authentication, Security,
LAU, RAU Procedure

DL Direct Transfer (CC Setup)

DL Direct Transfer (CC Call Confirm)

RAB Assignment Procedure

CSFB to UTRAN
has time stamp
from Extended
Service Request
on LTE Network
until CS Call of
target ringing
RAB Assignment Procedure

UL Direct Transfer ( CC Alerting)

CSFB to UTRAN Call

Setup Duration
Extended SR : 25:14.545
CC Alerting : 25.20.430
Duration : 5.8 s

In this signaling flow explain detail on 3G side
(CSFB with R9 Ultra Flash CSFB)
Step 1 through step 4: A UE in the LTE network initiates or
receives a voice service request. Therefore, the eNodeB
initiates an LTE-to-UMTS handover of combined services
through SRVCC. Using a mechanism, the MME and MSC
ensure the successful LTE-to-UMTS handover.
Step 5: When ULTRA_FLASH_CSFB_SWITCH under
the PROCESSSWITCH2(BSC6900,BSC6910) parameter in
the MML command SET URRCTRLSWITCH is selected, the
RNC identifies the Ultra-Flash CSFB process based on the
CSFB information IE in the CS domain's relocation request
message that is sent as a response to the SRVCC-based
handover request. To ensure quick transfer of NAS
messages during admission after the UE is handed over to a
UMTS cell, the SRB rate of the UE can be specified by
the UltraFlashCSFBSRBRate(BSC6900,BSC6910) parame
ter in the MML command SET UFRC.
Step 6: The CN sends a handover command to the eNodeB,
and the eNodeB delivers the handover command to the UE.
Step 7: The UE is handed over to a UMTS cell.
Step 8 through step 9: The RNC and UE implement the
security mode and processes such as UTRAN mobility
information.
Step 10 through step 13: The UE and MSC exchanges NAS
messages with each other to set up a CS service.
Step 14: The SRB rate is reconfigured to 3.4 kbit/s after the
CS service is set up to save UMTS resources.

In this signaling flow explain detail on 3G side
(CSFB with R9 Ultra Flash CSFB)
AuthenticationThis procedure is not required because the
UE has been authenticated on the LTE side before it is
handed over from an LTE cell to a UMTS cell.
EncryptionThis procedure is not required after a CSFB
because the UE has implemented encryption according to
the handover command during the SRVCC handover.
IMEI queryThis procedure is not required after a handover
is complete because the MME has sent the IMEI to the
MSC during the SRVCC handover preparation.
CS resource establishmentThis procedure is not required
after a handover is complete because CS resources have
been prepared on the UMTS side during the SRVCC
procedure. This section only describes how Ultra-Flash
CSFB is implemented on the RAN side.

4.2 Mobile Initiated Termination CSFB
from GERAN
(Cell Reselection)

Related Concept : SI2 Quarter
The System Information 2quater (SI2quater) is sent on the Broadcast Control Channel (BCCH) to all MSs in a cell. SI2quater
contains the parameters related to the measurement of neighboring GSM and LTE cells and the measured results.
There are 504 Physical Layer Cell Identities (PCIDs) in an LTE network. The SI2quater contains the LTE frequencies and the
prohibited PCIDs if any corresponding to each frequency. All these frequencies and PCIDs are recorded in the LTE Cell
Reselection List, which contains a maximum of eight frequencies.
Priorities of neighboring cells are also broadcast to MSs through the SI2quater. The priority information is used for the priority-
based GSM or LTE cell reselection. The priority of neighboring GSM cells is determined
by NCELLPRI(BSC6900,BSC6910) for neighboring GSM cells in the neighboring cell relationship; the priority of neighboring
LTE cells is determined byNCELLPRI(BSC6900,BSC6910) for neighboring LTE cells in the neighboring cell relationship. The
priority of neighboring GSM cells must be different from that of neighboring LTE cells
The information about neighboring LTE cells can be split and transmitted through multiple consecutive SI2quaters. A start flag
is marked in the first SI2quater containing the neighboring LTE cell information, and an end flag is marked in the last SI2quater
containing the neighboring LTE cell information. In this way, the MS can decode these consecutive SI2quaters together to
obtain the complete information about neighboring LTE cells. This accelerates the cell reselection.
The information about neighboring LTE cells and network priorities is carried in the SI2quater when the
parameter LTECELLRESELEN(BSC6900,BSC6910) is set to YES(Yes).
When SI2QUATEROPTFORLTESW(BSC6900,BSC6910) is set to ON(On), the BSC sends MSs the neighboring LTE cell list
in SI2Quater and Measurement Information using a dense coding scheme. This decreases the number of delivered SI2quater
messages and shortens the PS service interruption duration.
NOTE:
As specified in 3GPP protocols, the BSC can send external neighboring cell information to MSs by using a maximum of 16 SI2Quater
messages. If the number of external neighboring cells configured for a cell exceeds the maximum number of neighboring cells that can
be contained in SI2Quater, the BSC will not send SI2Quater to MSs. Therefore, it is recommended
that SI2QUATEROPTFORLTESW(BSC6900,BSC6910) be set to ON(On) to allow SI2Quater to contain information about more external
neighboring cells

Related Concept : Measurement of Neighboring LTE Cells
The purpose of measuring neighboring LTE cells is to obtain the signal quality of neighboring LTE cells, ensuring that the MS
can select a proper cell for cell reselection and handover.
To facilitate MS performing GSM/LTE inter-RAT cell reselection and handover, related system information (SI) is required. It
contains a list of neighboring LTE cells and parameters related to LTE cell reselection and handover, based on which the MS
measures the signal quality of neighboring cells and performs cell reselection and handover. The SI is the SI2quater sent on
the BCCH.
The MSs in a GSM cell measure the signal quality of both neighboring GSM cells and neighboring inter-RAT cells. Neighboring
inter-RAT cells include neighboring UMTS and LTE cells. In this document, however, only neighboring LTE cells are described.
To reduce unnecessary measurements and power consumption of MSs, the BSS controls the neighboring cell measurement
using the parameter THRPRISEARCH(BSC6900,BSC6910).
The MS determines whether to measure neighboring LTE cells based on THRPRISEARCH(BSC6900,BSC6910) and receive
level of the serving cell. The condition for triggering the measurement differs with the value
of THRPRISEARCH(BSC6900,BSC6910).
If THRPRISEARCH(BSC6900,BSC6910) is set to a value ranging from 0 to 14, the measurement is triggered when the
receive level of the serving cell is lower thanTHRPRISEARCH(BSC6900,BSC6910).
If THRPRISEARCH(BSC6900,BSC6910) is set to 15, MSs always measure the neighboring LTE cell information.

Related Concept : Reporting of Neighboring LTE Cells
Information
An MS reports the measured neighboring LTE cell information to the BSC. The BSC then appropriate neighboring LTE cell
frequencies to the MS for cell reselection or handover.
As specified in 10.5.2.20 Measurement Results in 3GPP TS 44.018 V10.8.0:
When a cell is configured with neighboring LTE cells, the cell can be configured with a maximum of (31 Number of
neighboring LTE cell frequencies) neighboring GSM cell frequencies. If the number of configured neighboring GSM cell
frequencies exceeds the preceding specifications, the MS will fail to report neighboring LTE cell information.
To refrain the number of neighboring GSM cell frequencies from exceeding the protocol specifications,
set CELL2GBA1OPTSW(BSC6900,BSC6910) andCELL2GBA2OPTSW(BSC6900,BSC6910) to ON(On) to allow the BSC to
check the number of neighboring GSM cell frequencies. Table 3-1 lists the specifications of the number of neighboring GSM
cell frequencies.
Table Specifications of the number of neighboring GSM cell frequencies

IRAT Cell Reselection Between GSM & LTE
GSM/LTE cell reselection involves the cell reselection from GSM to LTE and the cell reselection from LTE to GSM. Cell
reselection is mainly performed by MSs.
For an MS in idle mode, if the MS camps on a GSM cell, it can reselect an LTE cell; if the MS camps on an LTE cell, it
can reselect a GSM cell. The MS measures the information about neighboring LTE cells, and then decides whether to
reselect an LTE cell according to cell reselection parameters.
For MSs in packet transfer mode, cell reselection modes include network-controlled mode 0 (NC0), network-controlled
mode 1 (NC1), and external network-controlled mode 2 (eNC2). The MS can reselect an LTE cell for PS services. NC0
cell reselection and NC1 cell reselection are performed by MSs without the intervention of the BSS. In eNC2 cell
reselection, the BSS sends signaling to steer MSs towards desired camping cells.
The LTECELLRESELEN(BSC6900,BSC6910) parameter specifies whether to enable GSM/LTE inter-RAT cell
reselection. WhenLTECELLRESELEN(BSC6900,BSC6910) is set to NO(No), the BSS does not send the neighboring
LTE cell list and the parameters related to GSM/LTE cell reselection. In this case, MSs in a GSM cell cannot reselect an
LTE cell.
When the GBFD-171210 Flexible Camp Strategy Based on SPID feature is enabled, the BSS categorizes MSs by their
characteristics based on subscriber profile IDs (SPIDs) and customizes GSM/LTE cell reselection policies based on MS
categories. For details, see Flexible User Steering Feature Parameter Description.
When the GBFD-171209 IMSI-based Mobility Management for Multiple Operators feature is enabled, the BSS
categorizes MSs by their operators based on international mobile subscriber identities (IMSIs) and customizes GSM/LTE
cell reselection policies based on MS categories.

LTE to GSM Cell Reselection
When a UE in idle or connected mode moves from an LTE coverage area to a GSM coverage area, it may reselect a
GSM cell.
After reselecting a GSM cell, the UE initiates the location update and route area update in the GSM network. The GSM
network handles the location update and route area update regardless of whether the UE is from an LTE cell or a GSM
cell.
GSM to LTE Cell Reselection

This section describes the feature GBFD-511301 Cell Reselection Between GSM and LTE.
This feature is introduced in 3GPP Release 8
1. The BSC is configured with the following priority information for the cell reselection based on cell
priority:LTE frequency priority, involving the
parameter EUTRANPRI(BSC6900,BSC6910) or NCELLPRI(BSC6900,BSC6910).
LTE frequency thresholds, involving
parameters THRPRISEARCH(BSC6900,BSC6910),EUTRANQRXLEVMIN(BSC6900,BSC6910), T
HREUTRANHIGH(BSC6900,BSC6910),THREUTRANLOW(BSC6900,BSC6910), HPRIO(BSC690
0,BSC6910), and TRESEL(BSC6900,BSC6910).
GSM serving cell priority, involving the GERANPRI(BSC6900,BSC6910) parameter.
GSM serving cell threshold, involving the THRGSMLOW(BSC6900,BSC6910) parameter.
where
EUTRANPRI(BSC6900,BSC6910)is the common priority of LTE cells.
NCELLPRI(BSC6900,BSC6910) is the common priority of LTE cells in neighboring relationship data.
THRPRISEARCH(BSC6900,BSC6910) is the threshold for priority-based inter-RAT cell search. If the receive level of
the serving cell is higher than this threshold, MSs do not search for neighboring LTE cells whose priority is lower than
that of the GSM serving cell. MobileComm Professionals, Inc

EUTRANQRXLEVMIN(BSC6900,BSC6910) is used to calculate the RSRP of the target cell during a GSM-
to-LTE cell reselection decision:
RSRP = Measured RSRP EUTRANQRXLEVMIN(BSC6900,BSC6910)
THREUTRANHIGH(BSC6900,BSC6910) is the upper threshold for priority-based GSM-to-LTE cell
reselections. MSs can reselect a neighboring LTE cell whose EUTRANPRI(BSC6900,BSC6910) is greater
than GERANPRI(BSC6900,BSC6910) and whose RSRP is greater
than THREUTRANHIGH(BSC6900,BSC6910).
THREUTRANLOW(BSC6900,BSC6910) is the lower threshold for priority-based GSM-to-LTE cell
reselections. If the receive levels of the serving cell and its neighboring GSM cells are lower
than THRGSMLOW(BSC6900,BSC6910), MSs can reselect a neighboring LTE cell
whose EUTRANPRI(BSC6900,BSC6910) is smaller than GERANPRI(BSC6900,BSC6910) and whose
RSRP is greater than THREUTRANLOW(BSC6900,BSC6910).
HPRIO(BSC6900,BSC6910) is the level hysteresis for priority-based cell reselections. The MS is allowed to
reselect a neighboring cell in UTRAN or EUTRAN whose priority is lower than the GERAN priority when all
the following conditions are met:
The receive levels of the serving cell and all neighboring GSM cells are lower than THRGSMLOW(BSC6900,BSC6910).
The measured RSCP value of no neighboring UTRAN cell is higher than THRUTRANHIGH(BSC6900,BSC6910), and
the measured RSRP value of no neighboring EUTRAN cell is higher than THREUTRANHIGH(BSC6900,BSC6910).
The measured RSCP (or RSRP) value of one or more neighboring UTRAN (or EUTRAN) cells exceeds the measured
receive level of the serving cell by at least the decibel value corresponding to the value of HPRIO(BSC6900,BSC6910).

2. The MS has obtained the priority information for inter-RAT cell reselection.MSs in a GSM cell obtain the
neighboring LTE cell list and cell reselection priorities from SI2quater, and then measure neighboring
LTE cells according to the list and priorities. MSs in idle and packet transfer modes use the same GSM-
to-LTE NC0/NC1 cell reselection mechanism.
3. The MS supports priority-based GSM-to-LTE cell reselection.GSM/LTE dual-mode MSs always support
priority-based GSM-to-LTE cell reselection.
The target cell in a priority-based GSM-to-LTE cell reselection is selected as follows:
If within the period specified by TRESEL(BSC6900,BSC6910), multiple neighboring LTE cells meet the condition
ofEUTRANPRI(BSC6900,BSC6910) > GERANPRI(BSC6900,BSC6910) and RSRP
>THREUTRANHIGH(BSC6900,BSC6910), the MS selects the neighboring LTE cell with the highest priority. If
multiple cells have the highest priority, the MS selects the cell with the highest RSRP from these cells.
If within the period specified by TRESEL(BSC6900,BSC6910), the serving GSM cell is lower
thanTHRGSMLOW(BSC6900,BSC6910) of the serving GSM cell and all measured neighboring GSM cells, the
MS reselects an LTE cell according to the following rules:If multiple neighboring LTE cells meet the conditions
of EUTRANPRI(BSC6900,BSC6910) <GERANPRI(BSC6900,BSC6910) and RSRP
> THREUTRANLOW(BSC6900,BSC6910) for the period specified byTRESEL(BSC6900,BSC6910), the MS
selects the neighboring LTE cell with the highest priority. If multiple cells have the highest priority, the MS selects
the cell with the highest RSRP from these cells.
If no neighboring cells meet the preceding condition, the MS selects the neighboring LTE cell whose RSRP is
greater than the receive level of the serving GSM cell plus HPRIO(BSC6900,BSC6910). If there are multiple cells
whose RSRP is greater than the receive level of the serving GSM cell plus HPRIO(BSC6900,BSC6910), the MS
When EUTRANPRI(BSC6900,BSC6910) is greater than GERANPRI(BSC6900,BSC6910),

and THREUTRANHIGH(BSC6900,BSC6910) is small, the condition for priority-based GSM-to-LTE cell reselection is easy to
meet. This decreases the number of MSs that camp on GSM cells

Activation
On the BSC LMT, perform the following steps:
Run the ADD GEXTLTECELL command to add an external LTE cell. In this step, set EUTRAN Cell Type according to
onsite requirements.
Run the SET GCELLHOBASIC command with LTE Cell Reselection Allowed set to YES(Yes) for the target GSM cell.
Run the SET GCELLPRIEUTRANSYS command with GERAN Priority set to a value less than that of EUTRAN
Priority.
Run the ADD GLTENCELL command to add a neighboring LTE cell. In this step, set the parameters as follows:
Set Source Cell Index to the index of the cell to be verified.
Set Neighbor Cell Index to the index of the added LTE cell.
Set Support Cell Reselection to SUPPORT(SUPPORT).
Run the SET OTHSOFTPARA command with Support Sent 2QUATER set to YES(Yes).
MML Command Examples

//Adding an external LTE cell
ADD GEXTLTECELL: EXTLTECELLID=8048, EXTLTECELLNAME="cell", MCC="460", MNC="188",
ENODEBTYPE=HOME, CI=0, TAC=1, FREQ=2, PCID=3, EUTRANTYPE=FDD;
//Enabling LTE cell reselection
SET GCELLHOBASIC: IDTYPE=BYID, CELLID=0, LTECELLRESELEN=YES;
//Setting the cell priority and the parameters about E-UTRAN system information
SET GCELLPRIEUTRANSYS: IDTYPE=BYID, CELLID=0, GERANPRI=1, EUTRANPRI=7, THREUTRANHIGH=2,
EUTRANQRXLEVMIN=10;
//Enabling cell reselection from a GSM cell to a specific neighboring LTE cell
ADD GLTENCELL: IDTYPE=BYID, SRCLTENCELLID=0, NBRLTENCELLID=8048, SPTRESEL=SUPPORT;
//Enabling the sending of System Information 2Quater
SET OTHSOFTPARA: Send2QuterFlag=YES;
Case 1 : SI2Quarter appear after CC Disconnect
CC Alerting

No 3G Cell Reselection
LTE Cell Reselection

Criteria
CC Connect Acknowledge

No 3G Cell Reselection

Criteria
CC Disconnect

CC Release

CC Release

RR Measurement
Information

After Channel Release, there is no redirection info RR Channel

to EUTRAN or UTRAN (with no RWR/Fast Return)
Release - IDLE

UTRAN Reselection Criteria SI2 Quarter-Index 0

UTRAN Reselection Criteria SI2 Quarter-Index 1

EUTRAN & UTRAN SI2 Quarter-Index 2

Reselection Criteria

EUTRAN Reselection Criteria SI2 Quarter-Index 3

EUTRAN Reselection Process LTE SIB Type 1

EUTRAN TAU Process LTE Reselection

Case 2 : SI2Quarter appear before CC
Disconnect & with Fast Return

Criteria
UTRAN Reselection Criteria SI2Quarter Index 1


Criteria
EUTRAN Reselection Criteria SI2Quarter Index 1


Criteria
CC Setup


Criteria
CC Alerting


Criteria
CC Disconnect


Criteria
CC Release


Criteria
CC Release Complete


Criteria
CC Channel Release


Criteria
SI Type 6


Criteria
LTE SIB Type 1


Criteria
UE Cap Enquiry

from GERAN (Fast Return)

Overview
When GSM and LTE networks cover the same area, a UE terminating a call on the GSM network will camp on a GSM cell.
When the conditions for reselection to a neighboring LTE cell are met, the UE reselects to an LTE cell. This process takes a
long time because the UE initiates GSM-to-LTE cell reselection only after receiving certain system messages and performing
cell reselection calculations.
Definition : Fast LTE Reselection at 2G CS Call Release allows a UE terminating a call on a GSM network to camp on an
LTE network based on the "cell selection indicator after release" information element (IE) in the Channel Release message.
This feature provides the following benefits:

Improves user experience.UEs camp on an LTE cell without performing cell reselection calculation, accelerating cell
reselection. The GSM-to-LTE cell reselection delay decreases to 1s to 2s.
Increases operator revenues.UEs can camp on an LTE cell for a long period, increasing operator revenues from LTE
networks.
With Fast LTE Reselection at GSM CS Call Release (referred to as Fast Return in this document), the BSC uses a Channel
Release message to send a proper neighboring LTE frequency to a UE upon a call release, and the UE reselects the
neighboring LTE cell working on the frequency.
This feature is used for circuit switched fallback (CSFB) and single radio voice call continuity (SRVCC) calls. They follow
similar Fast Return procedures.
CSFB calls If an LTE network cannot provide voice services in voice over IP (VoIP) mode, UEs initiating voice call services are
handed over from the LTE network to a GSM network using the CSFB procedure. CSFB calls include common CSFB calls and
Ultra-Flash CSFB calls.
SRVCC calls If an LTE network can provide voice services in VoIP mode, at the LTE coverage edge or in heavily-loaded LTE
coverage areas, VoIP calls are handed over to the GSM network using the SRVCC procedure.

4.3.1 Measurement Based Fast Return
Measurement-based Fast Return requires that UEs support LTE frequency measurement, and that both of the following
switches be set to ON(On):
FASTRETURNMEASSPT(BSC6900,BSC6910) for CSFB calls
SRVCCRapidSelSw(BSC6900,BSC6910) and SRVCCRapidSelMeasOptSw(BSC6900,BSC6910) for SRVCC calls

1. The BSC reports frequencies and measurement parameters of a neighboring LTE cell, to the UE.After a traffic channel
(TCH) is established, the BSC sends a Measurement Information (MI) message to a UE. This message contains the
frequencies and measurement parameters of a neighboring LTE cell with SPTRAPIDSEL(BSC6900,BSC6910) set
toSUPPORT(SUPPORT).

2. The UE measures LTE frequencies and identifies appropriate LTE cells.The UE measures all the neighboring cells that
work on the received LTE frequencies reported. Based on measurement parameters, the UE identifies Mproper
neighboring LTE cells and uses a Measurement Report message to send information about the identified cells to the BSC.
The value of M is specified by EUTRANFREQCNUM(BSC6900,BSC6910).
The UE identifies proper neighboring LTE cells as follows:
The UE identifies neighboring LTE cells whose signal strength is stronger than the reference signal received power (RSRP)
threshold for triggering a fast reselection to an LTE cell. Based on the calculated signal strength, the UE sequences the
neighboring LTE cells in descending order, selects the first M cells, and reports them to the BSC.
Calculated signal strength = Signal strength measured by UEs + LTE FDD Report Offset
For details about the configuration, see the following table
3. After a call is complete, the UE releases the call.The UE sends a Disconnect message on the fast associated control
channel (FACCH). The MSC sends a Clear Command Message to the BSC, instructing the BSC to release the call.
4. If a CSFB call is performed, the BSC identifies whether to perform a common CSFB call or an Ultra-Flash CSFB call.
Common CSFB calls
If DecodeCSFBInd(BSC6900,BSC6910) has been set to ON(On), the BSC determines if the current call is a common
CSFB call based on the "CSFB indication" IE in the Clear Command message, and allows only CSFB calls to quickly
return to an LTE cell upon a call release.
If this parameter is set to OFF(Off), the BSC allows all dual-mode UEs supporting GSM and LTE networks to quickly return
to LTE cells upon a call release, without determining whether the current call is a common CSFB call.
Ultra-flash CSFB calls
The BSC checks whether configurations of the mobile country code (MCC), mobile network code (MNC), location area
code (LAC), and service area code (SAC) in the service area identifier (SAI) for an Ultra-Flash CSFB handover are
consistent with those of the MSC server. If they are, the BSC identifies the call as an Ultra-Flash CSFB call.

5. The BSC delivers a Channel Release message to the UE. This message contains frequencies of neighboring LTE cells.
The UE selects a suitable LTE cell based on the contents of this message.The sources of neighboring cell frequencies in a
Channel Release message are as follows:
If LTEFastReturnFrqSendOptSw(BSC6900,BSC6910) has been set to ON(On), the BSC filters received MRs,
sequences MRs by frequency priority, filters out frequencies with a lower priority than the GSM frequency priority. Then,
the BSC delivers LTE frequencies in multiple MRs to the UE. Number of Frequencies Carried in a Channel Release
Message describes the number of LTE frequencies that can be sent.To prevent the UE from selecting a frequency that
has not been reported in an MR for some period (for example, if the UEs are far away from the frequency coverage
range and cannot access the network), the LTEFastResMaxMRMissCount parameter is used to specify whether to
send such a frequency. If the number of times this neighboring LTE cell frequency is not reported in an MR is greater
than the value ofLTEFastResMaxMRMissCount, this frequency will not be included in a Channel Release message to
be delivered to the UE. TheLTEFastResMaxMRMissCount parameter takes effect only when MrIntrplOptSwitch is set
to NO(No).
If LTEFastReturnFrqSendOptSw(BSC6900,BSC6910) has been set to OFF(Off), the BSC does not filter received
MRs. Instead, it delivers the LTE frequency of the best-quality cell to the UE.
signaling messages for

Fast LTE Reselection at
GSM CS Call Release

4.3.2 Configuration Based Fast Return
A CSFB call performs configuration-based Fast Return to a frequency if either of the following conditions is met:
FASTRETURNMEASSPT(BSC6900,BSC6910) is set to ON(On), and a UE does not support LTE frequency
measurement.CSFBFastReturnBaseCfgSw(BSC6900,BSC6910) is set to ON(On).
FASTRETURNMEASSPT(BSC6900,BSC6910) is set to OFF(Off).
An SRVCC call performs configuration-based Fast Return to a frequency only when both of the following conditions are met:
Conditions of measurement-based Fast Return are not met. For example, a UE does not support neighboring LTE cell
measurement.
SRVCCRapidSelBaseCfgSw(BSC6900,BSC6910) is set to ON(On).
Configuration-based Fast
Return process

4.3.2 Configuration Based Fast Return

Fast Return Configuration Based
CC Disconnect

CC Release, contain call duration

CC Release Complete

SI 5 : Optional

RR Measurement Report,
There is no LTE measurement report here, so the BSC was configure with Config
Base Fast Return

RR Channel Release,
We can see that BSC send EUTRAN target freq as target Redirection to LTE
Network

SIB Type 1 LTE

As the indication of entering LTE Radio Network

from UTRAN
4.4.1 (Cell Reselection)

Overview
Cell reselections between UMTS and LTE include LTE-to-UMTS cell reselections, UMTS-to-LTE cell reselections, and UMTS-to-
LTE quick cell reselections.
When the LTE network is initially deployed, LTE coverage is weak or unavailable in some spots, but UMTS coverage is already
complete. The LTE network needs to support LTE-to-UMTS cell reselection so that UEs can reselect UMTS cells after finishing
services on the LTE network. LTE-to-UMTS cell reselection enables UEs to make full use of the existing UMTS network and reduce
load on the LTE network.
After finishing services on the UMTS network, UEs are transitioned to the CELL_PCH/URA_PCH state or idle mode within the
period specified by a timer. In this case, the UMTS-to-LTE cell reselection function enables UEs to reselect and camp on LTE cells
with better signal quality. UMTS-to-LTE cell reselections enable UEs to better experience high-speed services on the LTE network
and reduce load on the UMTS network.
To improve user experience, the UMTS-to-LTE fast cell reselection function can be enabled so that UEs can be quickly transitioned
to the CELL_PCH/URA_PCH state or idle mode and initiate UMTS-to-LTE cell reselections.
RAN17.1 introduced the function of UMTS-to-LTE cell reselection for UEs in the CELL_FACH state. That is, after performing a state
transition from CELL_PCH/CELL_DCH/IDLE to CELL_FACH, a UE can perform a cell reselection to the LTE network based on the
absolute priority of frequencies.
When a UE finishes its services and stays in the CELL_PCH, URA_PCH state, or idle mode on the UMTS network, it performs cell
reselections to the LTE network based on information element SIB19. Information element SIB19 carries the absolute priorities of
the serving UMTS cell and EARFCNs. After receiving SIB19, the UE will trigger measurements if measurement triggering conditions
are met. Based on the measurement results, the UE uses reselection to camp on a suitable cell.
To use the UMTS-to-LTE cell reselection function in a cell, SIB19 must be broadcast in the cell. To enable SIB19 broadcasting in a
cell, select SIB19 under theSibCfgBitMap(BSC6900,BSC6910) parameter in the ADD UCELLSIBSWITCH or MOD
UCELLSIBSWITCH command. SIB19 only contains the neighboring LTE frequencies
withFreqUsePolicyInd(BSC6900,BSC6910) set to Idle_Only or Both.
To enable absolute priority-based cell reselection to LTE for UEs in the CELL_FACH state, which is introduced in RAN17.1,
set CellFachPrioReselSwitch(BSC6900,BSC6910) to ON.
If the CN sends an Iu Release Command message containing an "Out Of Utran" IE to the RNC after the UE in the
CELL_PCH/CELL_FACH state performs UMTS-to-LTE cell reselection, the RNC directly releases internal resources without
sending a RADIO BEARER RELEASE message or RRC CONNECTION RELEASE message to the UE. This function is supported
when OPTI_REL_UE_AFTER_IRAT_RESEL_SWITCH under OptimizationSwitch6(BSC6900,BSC6910) is selected.

Overview
In LTE-preferred camping scenarios, the RNC of RAN18.0 sends MLB-based dedicated priorities to UEs that have performed LTE-
to-UMTS MLB handovers to prevent these UEs from reselecting to LTE cells again within a short period, ensuring proper load
balancing between LTE and UMTS. The implementation is as follows: After identifying a UE as being handed over from an LTE cell
to a UMTS cell due to the load reason, the RNC carries an MLB-based dedicated priority and an effective timer
(T322ForLoadBalance(BSC6900,BSC6910)) in the Utran Mobility Information message to the UE.
To support this mechanism, the SIB19 must be broadcast in the UMTS cell and the MLB-based dedicated priorities are sequenced
based on the absolute priority in the SIB19 so that the priorities of LTE frequencies are always lower than the priorities of UMTS
frequencies. If a LTE cell reselection is triggered for a UE before the effective timer expires, the UE cannot reselect to any LTE cell
because the MLB-based dedicated priority is effective. After the timer expires, UMTS-to-LTE cell reselections can be performed
based on the absolute priority.
This mechanism takes effect when L2U_MLB_HO_IN_DED_PRIO_SWITCH under HoSwitch2(BSC6900,BSC6910) is selected.
NOTE:
When the SPID-based or IMSI-based dedicated priority takes effect, the SPID-based or IMSI-based dedicated priority takes precedence over the
MLB-based dedicated priority and is preferentially carried in the Utran Mobility Information message.
As specified in 3GPP TS 25.331, frequencies of different RATs cannot be configured with the same priority. If frequencies of different RATs are
configured with the same priority, MLB-based dedicated priorities will not be delivered.
Frequencies supported by a UE are sequenced in descending order of MLB-based dedicated priority as follows: frequencies of the UMTS serving
cell > frequencies of other UMTS cells > LTE frequencies > GSM frequencies. Meanwhile, frequencies of non-UMTS serving cells (frequencies of
other UMTS cells, LTE frequencies, and GSM frequencies) are separately sequenced in descending order of absolute priority

Criteria for Starting Measurement
Information element SIB19 carries the absolute priority SPriority(BSC6900,BSC6910) of the serving UMTS cell, the absolute
priorities NPriority(BSC6900,BSC6910) of EARFCNs, and cell reselection thresholds. Different radio access technologies (RATs)
must have different priorities. Upon receipt of information element SIB19, the UE performs inter-RAT measurement according to
specific criteria, as shown in the following figure:
Parameters and variable involved in the preceding measurement

criteria are as follows:
ThdPrioritySearch1(BSC6900,BSC6910)
Qrxlevmin(BSC6900,BSC6910)
ThdPrioritySearch2(BSC6900,BSC6910)
Qqualmin(BSC6900,BSC6910)
Thigher_priority_search: According to section 4.2.2
"Requirements" in 3GPP TS 25.133 (V11.5.0), the value of
Thigher_priority_search (measured in seconds) equals the
number of frequencies multiplied by 60.
When absolute priority-based cell reselection to LTE is enabled for

UEs in the CELL_FACH state, which is introduced in RAN17.1, SIB19
carries the CELL_FACH state measurement indication. The
measurement indicator is specified by
the CellFachMeasLayer(BSC6900,BSC6910) parameter:
When this parameter is set to HIGH_PRIO_LAYERS, UEs only
measure frequencies that have higher absolute priorities than
the frequency of the serving cell. Therefore, only the LTE
frequencies that meet the preceding criteria and have higher
absolute priorities than the frequency of the serving cell are
measured.
When this parameter is set to ALL_LAYERS, UEs measure all
frequencies. Therefore, all LTE frequencies that meet the
preceding criteria are measured.

Criteria for Triggering Cell Reselection
SIB19 carries the absolute priority of the serving UMTS cell, the absolute priorities of the LTE frequencies, and the cell reselection
thresholds. The UE performs cell reselection based on the absolute priorities.
"Absolute priority based criteria for inter-frequency and inter-RAT cell reselection" in 3GPP TS 25.304 V11.3.0 specifies five sets of
criteria for cell reselection based on the absolute priorities. Criteria set 2 applies to intra-RAT inter-frequency cell reselections.
Criteria sets 1, 3, 4, and 5 apply to UMTS-to-LTE reselections. Criteria sets 1 and 3 use the reference signal received power (RSRP) to
evaluate signal quality, while criteria sets 4 and 5 use the reference signal received quality (RSRQ).
The RSRQSwitch(BSC6900,BSC6910) parameter in the ADD UCELLNFREQPRIOINFO or MOD UCELLNFREQPRIOINFO command

controls whether the UE performs cell reselection based on the RSRQ of the LTE frequency. When RSRQSwitch is set to TRUE and the
UE supports the RSRQ-based measurement, the UE performs cell reselection based on the RSRQ. Otherwise, the UE performs cell
reselection based on the RSRP.
RSRP NOTE:
If RSRQSwitch is set to the same
value for different LTE frequencies,
you can set NPriorityto the same
value for these LTE frequencies.
If RSRQSwitch is set to different
values for different LTE
frequencies, NPriority cannot be set
to the same value for these LTE
frequencies.
RSRQ




To summarize:
If the criteria in criteria set 1 or 4 are met, the UE performs reselection to a cell working at an LTE frequency with a higher absolute
priority.
If the criteria in criteria set 3 or 5 are met, the UE performs reselection to a cell working at an LTE frequency with a lower absolute
priority.
If the criteria in neither criteria set are met, the UE remains on the UMTS network.
If multiple cells fulfill a set of criteria, the UE performs reselection to the cell with the greatest SrxlevnonServingCell value.
RSRP NOTE:
If RSRQSwitch is set to the same
value for different LTE frequencies,
you can set NPriorityto the same
value for these LTE frequencies.
If RSRQSwitch is set to different
values for different LTE
frequencies, NPriority cannot be set
to the same value for these LTE
frequencies.
RSRQ

from UTRAN
4.4.2 (Quick Cell Reselection)

Overview
A UMTS/LTE multimode UE camping on the UMTS network can initiate UMTS-to-LTE cell reselection after finishing service processing.
In RAN14.0 and earlier versions, state transitions to the CELL_PCH or idle state are slow because the state transitions are triggered only
when the UE has not transmitted or received service data for a period of time specified by an inactivity timer.
To accelerate the UMTS-to-LTE cell reselection, you need to enable the UMTS-to-LTE quick cell reselection function by
selecting FAST_RETURN_LTE_BY_CELL_SELECT_SWITCH under PROCESSSWITCH4 in the SET URRCTRLSWITCH command.
When the UMTS-to-LTE quick cell reselection function is enabled, whether a UE transits from the CELL_DCH state to the
CELL_PCH state or idle mode is specified
by UL_DUAL_MODE_UE_D2P_OR_D2I_SWITCH under PROCESSSWITCH4(BSC6900,BSC6910) in the SET
URRCTRLSWITCH command. When UL_DUAL_MODE_UE_D2P_OR_D2I_SWITCH is deselected, the UE transits from the
CELL_DCH state to the CELL_PCH state. When this switch is selected, the UE transits from the CELL_DCH state to idle mode.
UL_DUAL_MODE_UE_D2P_OR_D2I_SWITCH under PROCESSSWITCH4(BSC6900,BSC6910) is deselected by default.
SelectUL_DUAL_MODE_UE_D2P_OR_D2I_SWITCH if some UEs in the network do not support CELL_DCH-to-CELL_PCH state
transitions.
Changing the value
of PsInactTmrForFstDrmDch(BSC6900,BSC6910) or PsInactTmrForFstDrmFach(BSC6900,BSC6910) affects this function and
the Enhanced Fast Dormancy feature.

Overview
The following table lists the inactivity timers that are used and state transitions that are triggered before and after the UMTS-to-LTE quick
cell reselection function is enabled.

from UTRAN
4.4.3 (MFBI based Cell Reselection)

Overview
A multi-band LTE cell refers to an LTE cell whose working frequencies belong to multiple frequency bands. For example, if a cell
operating on a 10 MHz bandwidth in Band 17 is reconfigured as a multi-band cell working in Band 17 and Band 12, UEs supporting
Band 17 and Band 12 can access the multi-band cell. The mapping between LTE frequencies and frequency band is defined in 5.5
Operating Bands of 3GPP TS 36.101.
When the LTE cell works on multiple frequency bands, UEs camping on the UMTS network and can reselect the multi-band LTE cell
if they support these frequency bands. This function is enabled by selecting HO_U2L_SUPPORT_MULTI_BAND_SWITCH under
theHoSwitch2(BSC6900,BSC6910) parameter. The master and slave frequency bands of the multi-band LTE cell configured by the
RNC must be consistent with those on the LTE network.
When SlaveBandIndicator(BSC6900,BSC6910) is set to D0, the neighboring frequency is not used by any multi-band cells. The
RNC sends the master frequency and slave frequency band list in SIB19 or Utran Mobility Information messages. If the master
frequency or slave frequency band list are supported by the UE, the UE can initiate a cell reselection procedure. If the UE does not
support the primary frequency but supports the slave frequency band, the RNC sends the first frequency in the slave frequency
band to the UE.
For frequencies configured with SPID/IMSI/ML-specific cell-reselection priorities, if the UE transits to the idle mode before the timer
expires, cell reselections are performed based on the frequencies and related reselection parameters in SIB19 and the priorities in
Utran Mobility Information.

from UTRAN
(Fast Return)

Overview
In an area jointly covered by UMTS and LTE networks, a UE accesses a UMTS cell due to CSFB. When the UE finishes all services in
the UMTS cell, it releases the RRC connection. In versions earlier than RAN14.0, if the absolute priority of a neighboring LTE cell's
frequency is higher than that of the UMTS cell's frequency, the RRC CONNECTION RELEASE message does not contain the frequency
information about neighboring LTE cells. As a result, the UE camps on a UMTS cell. If a neighboring LTE cell fulfills the cell reselection
conditions, the UE reselects the neighboring LTE cell. Before initiating UMTS-to-LTE cell reselection, a UE needs to perform the following
operations, which consume much time:
Receiving system information (MIB/SIB1/SIB3/SIB5/SIB7/SIB19) of the UMTS cell
Performing decision on cell reselection based on certain criteria
The Fast Return from UMTS to LTE feature is introduced to reduce the time and improve user experience.
This feature applies to the areas that are jointly covered by UMTS and LTE networks and where the LTE network signal quality is
satisfactory.
If the LTE network signal quality is poor, for example, when an RRC CONNECTION RELEASE message contains information about n (a
positive integer) LTE frequencies whose signal quality is poor:
UEs complying with a version earlier than 3GPP Release 10 select a suitable LTE cell from the LTE cells using n LTE frequencies.
The selection lasts for at most 10 seconds. If no suitable LTE cell is found, these UEs select a suitable LTE cell from the LTE cells
using frequencies supported by these UEs. If a suitable LTE cell is still not found, these UEs randomly camp on a suitable cell. For
details, see section 8.5.2 Actions when entering idle mode from connected mode in 3GPP TS 25.331 V10.8.0.
UEs complying with 3GPP Release 10 or later select a suitable LTE cell from the LTE cells using n LTE frequencies. The selection
lasts for at most n seconds. If no suitable LTE cell is found, these UEs select a suitable LTE cell from the LTE cells using
frequencies supported by these UEs. The selection lasts for 4 seconds. If a suitable LTE cell is still not found, these UEs randomly
camp on a suitable cell. For details, see section 8.5.2 "Actions when entering idle mode from connected mode" in 3GPP TS 25.331
V10.9.0
Note that the UE cannot process CS or PS services or CS+PS combined services while searching for a suitable LTE cell.
When PERFENH_FAST_RETURN_OPT_SWITCH under PerfEnhanceSwitch7(BSC6900,BSC6910) is selected, a fast return to the LTE network can be triggered by the
first AMR release of a UE that has been handed over to the UMTS network through CSFB. If this switch is turned off, a fast return can be triggered by any AMR
release of the CSFB UE as long as an RRC connection is live for the UE. In continuous LTE coverage scenarios, it is recommended that this switch be turned off. In
discontinuous LTE coverage scenarios, it is recommended that this switch be turned on to avoid invalid measurement.
The Fast Return from UMTS to LTE feature enables a UE that moves from an LTE cell to a UMTS cell through CSFB to quickly return to the LTE network after the CS
service is finished.

Overview
In an area jointly covered by UMTS and LTE networks, a UE accesses a UMTS cell due to CSFB. When the UE finishes all services in
the UMTS cell, it releases the RRC connection. In versions earlier than RAN14.0, if the absolute priority of a neighboring LTE cell's
frequency is higher than that of the UMTS cell's frequency, the RRC CONNECTION RELEASE message does not contain the frequency
information about neighboring LTE cells. As a result, the UE camps on a UMTS cell. If a neighboring LTE cell fulfills the cell reselection
conditions, the UE reselects the neighboring LTE cell. Before initiating UMTS-to-LTE cell reselection, a UE needs to perform the following
operations, which consume much time:
Receiving system information (MIB/SIB1/SIB3/SIB5/SIB7/SIB19) of the UMTS cell
Performing decision on cell reselection based on certain criteria
The Fast Return from UMTS to LTE feature is introduced to reduce the time and improve user experience.
This feature applies to the areas that are jointly covered by UMTS and LTE networks and where the LTE network signal quality is
satisfactory.
If the LTE network signal quality is poor, for example, when an RRC CONNECTION RELEASE message contains information about n (a
positive integer) LTE frequencies whose signal quality is poor:
UEs complying with a version earlier than 3GPP Release 10 select a suitable LTE cell from the LTE cells using n LTE frequencies.
The selection lasts for at most 10 seconds. If no suitable LTE cell is found, these UEs select a suitable LTE cell from the LTE cells
using frequencies supported by these UEs. If a suitable LTE cell is still not found, these UEs randomly camp on a suitable cell. For
details, see section 8.5.2 Actions when entering idle mode from connected mode in 3GPP TS 25.331 V10.8.0.
UEs complying with 3GPP Release 10 or later select a suitable LTE cell from the LTE cells using n LTE frequencies. The selection
lasts for at most n seconds. If no suitable LTE cell is found, these UEs select a suitable LTE cell from the LTE cells using
frequencies supported by these UEs. The selection lasts for 4 seconds. If a suitable LTE cell is still not found, these UEs randomly
camp on a suitable cell. For details, see section 8.5.2 "Actions when entering idle mode from connected mode" in 3GPP TS 25.331
V10.9.0
Note that the UE cannot process CS or PS services or CS+PS combined services while searching for a suitable LTE cell.
When PERFENH_FAST_RETURN_OPT_SWITCH under PerfEnhanceSwitch7(BSC6900,BSC6910) is selected, a fast return to the LTE network can be triggered by the
first AMR release of a UE that has been handed over to the UMTS network through CSFB. If this switch is turned off, a fast return can be triggered by any AMR
release of the CSFB UE as long as an RRC connection is live for the UE. In continuous LTE coverage scenarios, it is recommended that this switch be turned off. In
discontinuous LTE coverage scenarios, it is recommended that this switch be turned on to avoid invalid measurement.
The Fast Return from UMTS to LTE feature enables a UE that moves from an LTE cell to a UMTS cell through CSFB to quickly return to the LTE network after the CS
service is finished.

Function and Selection Procedure
This feature incorporates the following functions:
UMTS-to-LTE Fast Return
Enhanced UMTS-to-LTE Fast Return
LTE Measurement-Based Fast Return
RSCP Measurement-Based Fast Return
Virtual Grid-Based Fast Return
The UMTS-to-LTE Fast Return function and Enhanced UMTS-to-LTE Fast Return function are both based on blind redirection. That
is, neither UMTS-to-LTE Fast Return nor Enhanced UMTS-to-LTE Fast Return requires measurement. After the UE finishes the CS
service, the RNC immediately sends an RRC release message to redirect the UE to the LTE network. Before enabling the
Enhanced UMTS-to-LTE Fast Return function, you must enable the UMTS-to-LTE Fast Return function. However, before enabling
the UMTS-to-LTE Fast Return function, you do not need to enable the Enhanced UMTS-to-LTE Fast Return function.
RAN17.1 introduces two types of measurement-based fast return: LTE measurement-based fast return and RSCP measurement-
based fast return.
When LTE measurement-based fast return is enabled, the RNC triggers inter-RAT measurement of LTE after a CS service is
finished and delivers an RRC release message or handover command to redirect or hand over the UE to LTE only if the measured
LTE signal quality meets the handover threshold. Compared with blind redirection-based fast return, this type of fast return prevents
the out-of-service problem of UEs due to LTE coverage holes.
The RSCP measurement-based fast return function is applicable where UMTS and LTE networks share a site. This function starts
RSCP measurement of the UMTS serving cell during the CS service of a CSFB UE. If the measured RSCP value reaches a specific
threshold, blind redirection-based fast return can be performed after the CS service is complete, which improves the success rate of
blind redirections and reduces the impact of LTE measurement in compressed mode.
When virtual grid-based fast return is enabled, the RNC checks the LTE coverage in the grid based on the success rate of grid-level
UMTS-to-LTE handovers and redirections, and determines whether to perform fast return. In grids with good LTE coverage, blind
redirection-based fast return is performed. In grids with poor LTE coverage, fast return is not performed, which increases the
success rate of blind redirections and reduces the impact of LTE measurement in compressed mode.



In the preceding figure, optimization of the UMTS-to-LTE fast return process and enhanced UMTS-to-LTE fast return process refers to that the RNC delivers
the RRC CONNECTION RELEASE message immediately after receiving an IU RELEASE COMMAND message from the CS domain.

UMTS to LTE Fast Return
At the cell level, this function is controlled by the HO_UMTS_TO_LTE_FAST_RETURN_SWITCH under
theFastReturnToLTESwitch(BSC6900,BSC6910) parameter in the MOD UCELLHOCOMM command.
At the RNC level, this function is controlled by the HO_UMTS_TO_LTE_FAST_RETURN_SWITCH under
the HoSwitch(BSC6900,BSC6910)parameter in the SET UCORRMALGOSWITCH command. When this function is configured at both
the RNC and cell levels, the cell-level configuration takes effect.
This function works as follows:

1. The RNC first determines that a UMTS/LTE UE is a CSFB UE if the UE meets either of the following conditions:
When the UE is moving from an LTE cell to a UMTS cell through a PS handover, the RELOCATION REQUEST
message contains a "cause" information element (IE) whose value is "CS Fallback triggered (268)" or a "CSFB
Information" IE whose value is "CSFB" or "CSFB High Priority."
When the UE is moving from an LTE cell to a UMTS cell through a redirection, the RRC CONNECTION REQUEST
message does not contain the "Pre-redirection info" IE. (For details, see section 8.1.3.3 "RRC CONNECTION
REQUEST message contents to set" in 3GPP TS 25.331 V9.4.0.) The first service that the UE processes after
accessing the UMTS cell is a CS service.
2. If the UE is identified as a CSFB UE and the UE does not perform a PS service after finishing the CS service in the
UMTS cell, the RNC triggers the RRC connection release procedure.
3. The RNC includes the information about LTE frequencies in an RRC CONNECTION RELEASE message. For the
method of selecting LTE frequencies contained in the message, see 5.2.6 Selecting Frequencies to Be Carried in the
RRC CONNECTION RELEASE Message. Upon receiving the message, the UE selects a target cell based on the
information and attempts to camp on this cell. (For details about suitable LTE cell selection, see section 8.5.2 Actions
when entering idle mode from connected mode in 3GPP TS 25.331 V9.4.0.

Fast Return
CC Alerting

Fast Return
CC Connect

Fast Return
CC Connect Acknowledge

Fast Return
CC Release

Fast Return
CC Release Complete

Fast Return
RRC Connection Release

Fast Return

Complete

Fast Return

Fast Return

Complete

Fast Return

Fast Return
SIB Type 1

Fast Return

Fast Return
LTE TAU Request

Fast Return
RRC Connection Request

Fast Return
RRC Connection Setup

Fast Return
RRC Connection Setup

Complete

Enhanced UMTS to LTE Fast Return
At the cell level, this function is controlled by PERFENH_PS_FAST_RETURN_LTE_SWITCH under
theFastReturnToLTESwitch(BSC6900,BSC6910) parameter in the ADD UCELLHOCOMM command. At the RNC level, this function is
controlled by PERFENH_PS_FAST_RETURN_LTE_SWITCH under the PerfEnhanceSwitch3(BSC6900,BSC6910) parameter in
the SET UCORRMPARAcommand. When this function is configured at both the RNC and cell levels, the cell-level configuration takes
effect.
The RNC first determines that a UMTS/LTE UE is a CSFB UE if the UE meets any of the following conditions:
When the UE is moving from an LTE cell to a UMTS cell through a PS handover, the RELOCATION REQUEST message contains a
"cause" IE whose value is "CS Fallback triggered (268)" or a "CSFB Information" IE whose value is "CSFB" or "CSFB High Priority."
When the UE is moving from an LTE cell to a UMTS cell through a redirection, the RRC CONNECTION REQUEST message does
not contain a "Pre-redirection info" IE. (For details, see section 8.1.3.3 "RRC CONNECTION REQUEST message contents to set" in
3GPP TS 25.331 V9.4.0.) After the RNC receives an RRC Connection Setup Complete message, the UE successfully sets up a CS
service within 10 seconds.
When the UE is moving from an LTE cell to a UMTS cell through a redirection, the RRC CONNECTION REQUEST message
contains a "CSFB Indication" IE. (For details, see section 8.1.3.3 "RRC CONNECTION REQUEST message contents to set" in
3GPP TS 25.331 V9.10.0.)
After the UE finishes its CS service in a UMTS cell, an IU RELEASE COMMAND message from the CN to the RNC contains an
"End Of CSFB" IE. (For details, see section 8.5.2 "Successful Operation" in 3GPP TS 25.413 V10.4.0.)
After the UE is identified as a CSFB UE and the UE finishes its CS service in the UMTS cell, the RNC triggers the RRC connection
release procedure regardless of whether or not the UE has a PS service ongoing. The RNC includes the information about LTE
frequencies in an RRC CONNECTION RELEASE message. For the method of selecting LTE frequencies to be carried in the RRC
CONNECTION RELEASE message, see 5.2.6 Selecting Frequencies to Be Carried in the RRC CONNECTION RELEASE Message.
Upon receiving the message, the UE selects a suitable LTE cell based on the carried LTE frequency information and attempts to camp on
this cell.
In most cases, if there is a PS service ongoing when the UE finishes its CS service, the RNC does not deliver the RRC Connection Release
message until the CS RAB is released. To shorten the time taken by the fast return of a CSFB UE to LTE, a mechanism is introduced so that the
RNC delivers the RRC Connection Release message immediately after receiving an IU RELEASE COMMAND message from the CS domain. This
mechanism takes effect when U2L_CSFB_FAST_RETURN_PROC_OPTI_SWITCH under
the OptimizationSwitch6(BSC6900,BSC6910)parameter is selected.

LTE Measurement Based Fast Return
Overview
The following figure shows the principle of LTE measurement-based fast return.
1. Trigger phase: The RNC decides whether to trigger an LTE measurement-based fast return.
2. Measurement phase: The RNC decides whether to start an LTE measurement. If an LTE measurement is needed, it delivers the
measurement control message and handles the measurement result.
3. Execution phase: The RNC decides which procedure to trigger to implement the fast return, measurement-based redirection or
handover.

Triggering
If a CSFB UE still has a PS service ongoing after it finishes a CS service, the RNC triggers an LTE measurement-based fast return when
the following conditions are met:
The UE is identified as a CSFB UE on the UMTS side.
The UMTS-to-LTE Fast Return feature is enabled.
Measurement-based fast return after a CSFB UE finishes its voice service is enabled.
To ensure that an LTE measurement-based fast return to the LTE network can be triggered for a CSFB UE that has no PS service
ongoing after it finishes a CS
service, PERFENH_CS_ONLY_MEAS_FAST_RETURN_SWITCH under PerfEnhanceSwitch7(BSC6900,BSC6910) must be set
to ON in addition to the preceding conditions.
For a cell enabled with the MOCN feature, when PERFENH_CS_ONLY_MEAS_FAST_RETURN_SWITCH under
thePerfEnhanceSwitch7(BSC6900,BSC6910) parameter is selected, each operator can independently
deselectPERFENH_CS_ONLY_MEAS_FAST_RETURN_SWITCH under U2LAlgoSwitch(BSC6900,BSC6910) corresponding to
theirCnOpIndex(BSC6900,BSC6910)so that CSFB UEs that are not performing PS services after finishing their voice services will not
perform measurement-based fast return to LTE, without affecting UEs of other operators.
A UE is considered as a CSFB UE by the following mechanism only when it meets any of conditions 1 to 3
For the measurement-based fast return of a CSFB UE after releasing a voice service, there is an RNC-level switch and a cell-level switch.
The RNC-level switch is HO_CSFB_BASED_MEAS_FAST_RETURN_SWITCH under HoSwitch1(BSC6900,BSC6910). The cell-level
switch isHO_CSFB_BASED_MEAS_FAST_RETURN_SWITCH under FastReturnToLTESwitch(BSC6900,BSC6910). When both the
RNC-level and cell-level switches are configured, the setting of the cell-level switch takes precedence.

Measurement
If the UE supports LTE measurement in connected mode, LTE measurement is triggered in this phase. If the UE does not support LTE
measurement in connected mode, the process is terminated.
The measurement control message sent by the RNC contains the following LTE-specific information:
Reporting mode of measurement reportsSimilar to service-based UMTS-to-LTE PS redirection or handover, the measurement
report is sent using event 3C.
Information about the neighboring cell or frequency to be measured.
Measured itemSame as service-based UMTS-to-LTE PS redirection or handover.
Measurement event-related parameters:
If no PS service is ongoing after the voice service is complete:The RSRP- or RSRQ-based decision threshold is specified
by SigTargetRatThdRSRP(BSC6900,BSC6910) or SigTargetRatThdRSRQ(BSC6900,BSC6910). Other parameters
related to measurement events are the same as those used for service-based UMTS-to-LTE PS redirection or handover. If
there is a PS service ongoing after the voice service is complete:All measurement event related parameters are the same
as those used for service-based UMTS-to-LTE PS redirection or handover.
If no PS service is ongoing after the voice service is complete, the LTE measurement duration is specified
by U2LTESigMeasTime(BSC6900,BSC6910). If there is a PS service ongoing after the voice service is complete, the LTE measurement
duration is specified by U2LTEMeasTime(BSC6900,BSC6910).
The method of processing the measurement result is the same as that used for service-based UMTS-to-LTE PS redirection or handover.

Execution
After receiving a 3C measurement report, the RNC determines whether to perform a redirection or handover according to the following
rules:
If there is no PS service after the voice service is complete or the non-neighboring-cell frequency-based redirection switch
(HO_U2L_REDIR_BASED_ABSOLUTE_FREQ_SWITCH under theHoSwitch1(BSC6900,BSC6910) parameter) is turned on, the
RNC performs a redirection.If the measurement report contains multiple cells and the UMTS-to-LTE connected mode priority switch
(HO_U2L_CONN_PRIO_SWITCH under the HoSwitch1(BSC6900,BSC6910) parameter) is turned on, frequencies are sequenced
in a descending order of priority. If two frequencies have the same priority, they are sequenced in a descending order of signal
quality. If the UMTS-to-LTE connected mode priority switch is turned off, frequencies are sequenced in a descending order of signal
quality. When the UL Unified Overload Control feature is enabled, the RNC filters out LTE frequencies carrying heavy traffic. Finally,
a maximum of four FDD LTE frequencies and four TDD LTE frequencies ranking at the top of the list are selected.
If the switch for triggering non-neighboring-cell frequency-based redirection when there is a PS service ongoing after completion of a
voice service is turned off, the RNC checks whether
HO_HANDOVER_FAST_RETURN_TO_LTE_SWITCH under HoSwitch1(BSC6900,BSC6910) is selected:
If this switch is turned on and the UE supports UMTS-to-LTE handover, the RNC performs a handover.If the measurement
report contains multiple cells and the UMTS-to-LTE connected mode priority switch
(HO_U2L_CONN_PRIO_SWITCH under the HoSwitch1(BSC6910,BSC6900) parameter) is turned on, frequencies are
sequenced in a descending order of priority. If two frequencies have the same priority, they are sequenced in a descending
order of signal quality. When the UL Unified Overload Control feature is enabled, the RNC filters out cells carrying heavy
traffic. If the UMTS-to-LTE connected mode priority switch is turned off, frequencies are sequenced in a descending order of
signal quality. The cell corresponding to the frequency that is ranked at the top of the list is selected as the target cell of
handover.
Note:
During a cross-Iur UMTS-to-LTE handover:
When selecting target cells, if the switch for considering connected-mode priorities during UMTS-to-LTE handovers or redirections is
turned on, frequencies of the neighboring LTE cells on the DRNC side are considered to have the lowest priorities.
If the SRNC does not obtain the PCI and TAC information of a neighboring LTE cell under the DRNC, it will not initiate a handover to the cell

Execution
If this switch is turned off or the UE does not support UMTS-to-LTE handover, the RNC performs a redirection. If the
measurement report contains multiple cells and the UMTS-to-LTE connected mode priority switch
(HO_U2L_CONN_PRIO_SWITCH under the HoSwitch1 parameter) is turned on, frequencies are sequenced in a
descending order of priority. If two frequencies have the same priority, they are sequenced in a descending order of signal
quality. If the UMTS-to-LTE connected mode priority switch is turned off, frequencies are sequenced in a descending order
of signal quality. When the UL Unified Overload Control feature is enabled, the RNC filters out cells carrying heavy traffic.
Finally, a maximum of four FDD LTE frequencies and four TDD LTE frequencies ranked at the top of the list are selected.
Note:
After LTE measurement is triggered by fast return, the RNC directly releases the RRC connection if the PS service is released before the RNC
receives an LTE measurement report from the UE.
An SRVCC UE's fast return to the LTE network requires a measurement report. Therefore, a 3C measurement report of an LTE cell may be
sent during the location area update (LAU) procedure. After receiving the 3C measurement report, the RNC terminates the LAU procedure
and triggers a UMTS-to-LTE fast return. After being handed over or redirected to an LTE cell, the UE performs combined attach. Hence, the
LAU success rate on the CN side is not affected by SRVCC UEs' fast return to the LTE network.

4.6 LTE S1 Handover

Overview
S1 Protocol Stacks
UE connections between eNB and EPC are as follows: In the control plane, each users signaling between eNB and MME is
provided through S1 Application Protocol (S1AP) signaling connection1, and identified by {eNB UE S1AP ID, MME UE S1AP
ID}. In the user plane, each users S1 bearer between eNB and S-GW is provided through GTP (GPRS Tunneling Protocol)
tunnel, and identified by {DL S1 TEID (S1 eNB TEID), UL S1 TEID (S1 S-GW TEID)}.

Overview
S1AP Procedures and Messages Relating to Handover
Handover Required message: This message is used during the handover preparation phase. It is sent by the source eNB to MME, and includes information about the
target eNB and the radio resources at the source cell.
Handover Request message: This message is used during the handover preparation phase. It is sent by MME to the target eNB, and includes the users UE context.
Handover Request Acknowledge message: This message is used during the handover preparation phase. It is sent by the target eNB to MME when the resource
allocation for the UE is successfully completed at the target eNB. The target eNB allocates DL S1 TEID for S1 bearer to be used after the handover, and DL S1 TEID for S1
bearer (indirect tunnel) to be used for DL packet delivery during the handover, and then forwards them as included in the message.
Handover Command message: This message is used during the handover preparation phase, and is sent by MME to the source eNB. It includes the information
required when the UE accesses the target eNB (e.g. Target C-RNTI, Target eNB AS Security algorithm, DRB ID, etc.), and UL S1 TEID for S1 bearer (indirect tunnel) to be
used by S-GW for DL packet delivery during the handover.
eNB Status Transfer message: This message is used during the handover execution phase, and is sent by the source eNB to MME. It indicates from which packet the
target eNB should receive or send.
MME Status Transfer message: This message is used during the handover execution phase, and is sent by MME to the target eNB. It indicates from which packet the
target eNB should receive or send.
Handover Notify message: This message is used during the handover completion phase, and is sent by the target eNB to MME. It indicates that the UE has completed
the handover to the target eNB.
UE Context Release Command message: This message is used during the handover completion phase, and is sent by MME to the source eNB to request release of the
UE context.
UE Context Release Complete message: This message is used during the handover completion phase, and is sent by the source eNB to MME to inform that the UE
context has been released.
S1 Handover Procedure
Before S1 Handover
In the figure above, the UE is being served through
eNB A (a serving cell in eNB A, to be more exact)
that it has connected to. When the UE detects a
measurement event, it sends a Measurement
Reportmessage to eNB A.
S1 Handover Preparation
The source eNB (i.e. eNB A in the figure) chooses a
target eNB (i.e. eNB B in the figure) to handover to,
based on the neighbor cell list information it has
kept and the information on the signal strength of
the neighbor cells included in the Measurement
Report message. Next, it, realizing a handover to
the target eNB through the X2 connection is not
possible, decides to perform a S1 handover instead,
and prepares to perform one through MME. Both
eNBs communicate with the MME through S1AP
signaling. At this time, the target eNB allocates
radio resource in advance to ensure the same
services currently provided by the source eNB are
also available at the target eNB. The MME also
provides the source eNB with the information
required for the UE to access the target cell.

In the meantime, the target eNB and S-GW allocate
resources needed to create an indirect tunnel
through which DL packets arriving at the source
eNB are forwarded to the S-GW and finally to the
target eNB while a handover is being performed, as
follows:
The source eNB sends the information about the
target eNB, as included in a Handover
Requiredmessage, to the MME ().
The MME then sends a Handover Request message
that includes AS security information required for
the target eNB to create the AS security base key
along with the UE Context to the target eNB ().
Target eNB
establishes an UL S1 bearer through which to
forward UL packets after the handover by using the
S1 S-GW TEID obtained from the MME, and
allocates S1 target eNB TEID for a DL S1 bearer
().
allocates S1 target eNB TEID for the tunnel
connecting the S-GW and the target eNB (this
tunnel is a part of the indirect tunnel2 connecting
all the way from the source eNB, S-GW and the
target eNB) to be used for forwarding DL packets
while the UE attempts to access (i.e. perform a
handover to) the target eNB.
configures a Handover Command message that
includes information needed for the UE to access
the target cell (e.g. Target C-RNTI, Target DRB ID,
etc.).
and sends the information to the MME by
including it in a Handover Request Ack message
().

The MME, upon receiving the message, includes
the S1 target eNB TEID that the target eNB has
allocated for the indirect tunnel in a Create Indirect
Data Forwarding Tunnel Request message, and
sends the message to the S-GW ().
S-GW
Creates an indirect tunnel connecting the target
eNB ().
allocates S1 S-GW TEID for the tunnel connecting
the source eNB and the S-GW (this tunnel is a part
of the indirect tunnel connecting all the way from
the source eNB, S-GW and the target eNB), and
sends it to the MME through a Create Indirect Data
Forwarding Tunnel Response message.
The MME includes i) the S1 S-GW TEID that the S-
GW has allocated for the indirect tunnel, and ii) the
information required for the UE to access the target
cell, in a Handover Command message, and sends
the message to the source eNB ().
Then, the source eNB creates an indirect tunnel
connecting to the S-GW ().
Through Steps and , the entire indirect

tunnel connecting all the three entities, the source
eNB, S-GW and target eNB, is created.

S1 Handover Execution
Now the two eNBs are ready to perform a
handover, it is time to command the UE to perform
one.
Source eNB
commands the UE to perform a handover to the
target cell by sending a Handover
Commandmessage that includes all the information
needed for the UEs access to the target cell ().
informs the MME about from which UL/DL
packet it should receive/send from/to the UE by
sending an eNB Status Transfer message ().
sends the DL packets received from the S-GW on
to the target eNB through the indirect tunnel
connected to the target eNB via the S-GW ().
The MME informs the target eNB about from which
UL/DL packet it should send/receive to/from the UE
by sending an MME Status Transfer message ().
The UE disconnects from the source eNB, and
connects to the target eNB ().
Once the UE is successfully accessed to the target
eNB, it becomes immediately capable of sending or
receiving packets ().

S1 Handover Completion
As the MME already knew that the UE was about to
perform a handover, the target eNB, unlike in X2
handover, does not request the MME for path
modification. Instead, the target eNB sends the
MME aHandover Notify message to indicate the UE
has completed the handover once the UE is
connected to the target eNB.
As soon as the UE is connected, the target eNB
sends the MME a Handover Notify message to
inform about the completed handover ().
Then, the MME requests the S-GW for S1 bearer
modification (). The S-GW modifies the DL S1
bearer path to connect to the target eNB, as
requested ().
The S-GW changes the bearer path as follows:
It stops DL packet delivery by sending an End
Marker (EM) packet through the DL S1 bearer
connected to the source eNB.
Then it creates a DL S1 bearer that connects to
the target eNB, and resumes DL packet delivery to
the target eNB.
The target eNB sends DL packets to the UE as
follows:
It sends DL packets arriving through the indirect
tunnel to the UE until an EM packet arrives.
Once an EM packet arrives, it sends the UE the
ones arriving through the new path.
The MME:
requests the source eNB to release S1 resources
related to the source eNB and the UE Context it has
by sending an UE Context Release
Command message ().
request the S-GW to release resources
associated with the indirect tunnel by sending
a Delete Indirect Data Forwarding Tunnel
Request message ().
UE State and Connection Information
Before and After S1 Handover
Before S1 Handover
The UE stays in EMM-Registered and ECM/RRC-
Connected and keeps all the resources allocated by
E-UTRAN and EPC.
During S1 Handover
Even during the handover phase, the UEs state on
the NAS layer remains unchanged. Both the source
and target eNBs are connected to the MME
through the S1 signaling connection established
over the S1-MME interface. They are also
connected to the S-GW through the indirect tunnel
created over the S1-U interface for DL packet
forwarding. In Figure 3, Step 2) shows the
connections and states while the handover is
interrupted during the handover execution phase.
During this period, no radio link connection is
active, but the UE still remains Connected.
After S1 Handover
The UE remains in EMM-Registered and ECM/RRC-
Connected states. The E-RAB (DRB + S1 bearer)
path is switched to connect to a new eNB in the
user plane while a new RRC connection is
established in the control plane.

Before Handover
1) [UE eNB] Measurement Report
As a measurement event is triggered,4 the UE
measures the signal strength of neighbor cells, and
sends a Measurement Report message to its
associated eNB (serving cell).
Handover Preparation
2) [Source eNB] Handover Decision
The source eNB selects a target eNB based on the
information included in the Measurement
Reportmessage sent by the UE, and the neighbor
cell list information it has kept. Becoming aware
that no X2 connection is available for a handover
between two eNBs, the source eNB decides to
perform an S1 handover.
3) [Source eNB MME] Requesting a Handover

The source eNB sends a Handover
Required message to the MME, requesting a
handover to the target eNB. The information
included in the message is as follows:

4) [MME] Deriving Security Context to Forward
to the Target eNB
The MME derives the Security Context {NCC, NH} so
that the target eNB can derive the AS security base
key5. NCC increases by 1 starting from the initial
NCC value (NCC0=0), and NH is derived from the
initial NH value (NH0) and KASME.
NCC1 = NCC0 + 1 = 1
NH1 = KDF(NH0, KASME)
5) [Target eNB MME] Requesting the Target

eNB for a Handover
The MME sends a Handover Request message to
the target eNB, requesting a handover on behalf of
the source eNB. The information included in the
message is as follows:

6) [Target eNB] Preparing S1 handover
Upon receiving the Handover Request message, the
target eNB begins the handover preparation to ensure
seamless service provision for the UE.
(i) New S1 bearer resource allocation: The target
eNB, based on the E-RAB to be setup information,
checks if the same QoS provided by the source eNB is
available at the target eNB as well. If available, it
establishes an UL S1 bearer connecting to S-GW, by
using the UL S1 bearer information (S1 S-GW TEID[A])
stored at the source eNB. Then it allocates S1 Target
eNB TEID[B] to prepare a DL S1 bearer to be used after
the handover.
(ii) Indirect tunnel resource allocation: While the UE
is performing a handover (i.e. after it disconnects from
the source eNB, until it connects to the target eNB),
there should be an indirect tunnel for rerouting DL
packets arriving at the source eNB to the target eNB
via the S-GW. For this, the target eNB allocates S1
Target eNB TEID[C] so that the S-GW can establish an
indirect tunnel connecting to the target eNB.
(iii) Allocation of resource to be used by UE over
radio link: Based on the E-RAB QoS information, the
target eNB reserves RRC resources to be used by the
UE over the radio link (e.g. DRB ID allocation, etc.), and
allocates C-RNTI.
(iv) KeNB* derivation: It derives KeNB* by using the
security context information (NCC1, NH1)6 it received
from the MME for handover, and then obtains AS
security keys (KRRCint, KRRCenc, KUpenc). Shortly after, when
the UE connects to the target eNB, the two can
communicate with each other securely over the radio
link by using these key values. Figure 5 shows how
KeNB* is derived. We can see that KeNB* is derived from
NH1, the target cells Physical Cell ID (PCI) and
frequency (E-UTRA Absolute Radio Frequency Channel
Number-Downlink (EARFCN-DL)).
7) [Target eNB MME] Notifying the MME of

Preparation Completion
The target eNB sends the MME all the information
about the resources prepared in Step 6), as included in
a Handover Request Ack7 message. The information in
the message is as follows

8) [MME S-GW] Requesting for Creation of S1
Bearer for DL Packet Delivery
The MME sends the S-GW a Create Indirect Data
Forwarding Tunnel Request message, requesting
creation of an indirect tunnel for delivering DL packets
while the UE is performing a handover. This message
includes GTP TEID (S1 Target eNB TEID[C]) that the
target eNB has allocated for the tunnel.
9) [MME S-GW] Notifying that S1 Bearer is

Created for DL Packet Delivery
The S-GW, upon receiving the Create Indirect Data
Forwarding Tunnel Request message, creates an
indirect tunnel connecting to the target eNB. It then
allocates S1 S-GW TEID[D], forwards it through
the Create Indirect Data Forwarding Tunnel
Response message to the MME so that the source eNB
can create an indirect tunnel connecting to the S-GW.
10) [Source eNB MME] Notifying of the

Completed Handover
The MME sends the source eNB a Handover
Command message that includes i) the S1 S-GW
TEID[D]received from the S-GW in Step 9), and ii)
the Handover Command information received from
the target eNB in Step 7).
The source eNB learns from the Handover
Command message that the target eNB and EPC are
ready for UE handover.

11) [UE Source eNB] Commanding UE
to Perform a Handover
Once the source eNB becomes ready for
a handover, it commands the UE to
perform a handover by sending
a Handover Command message.
The Handover Command message is
delivered to the UE, as included in
an RRC Connection
Reconfiguration message.
12) [UE] Executing a Handover

Once the UE obtains, from the
received Handover Command message,
C-RNTI and DRB ID to be used at the
target cell, and detaches from the source
eNB. Now, all packet exchanges between
the UE and the source eNB are stopped,
and the handover interruption
time9 begins.
13) [UE] AS Security Setup

The UE derives AS security keys to be
used over the radio link of the target
eNB. First it derives KeNB*, the AS base
key, (the relevant key derivation
functions are as seen in Figure 5), then it
derives AS security keys (KRRCint, KRRCenc,
KUPenc) by using the AS security
algorithms that the target eNB selected.

14) ~ 15) [Source eNB MME,
MME target eNB] Notifying the No.
of the Packet to Send/Receive
The source eNB sends an eNB Status
Transfer message that includes DL Count
and UL Count to the MME, which then
forwards the same information through
an MME Status Transfer message to the
target eNB. This was the target eNB
knows from which packet it should send
to (or receive from) the UE. Here, the
count values are PDCP PDU Counts, and
each Count is a 32-bit value consisting of
Hyper Frame Number (HFN) and PDCP
Sequence Number (SN). The information
After sending the eNB Status

Transfer message, the source eNB begins
to forward DL packets arriving from S-
GW to the target eNB through the
indirect tunnel established over the S1
interface. The target eNB buffers the
packets and waits for completion of the
UEs access.

16) ~ 18) [UE, Target eNB] UE UEs
Access to the Target eNB
16) The UE detects the synchronization
signal from the target eNB to perform
synchronization to the target eNB. Once
synchronized, the UE initiates non-
contention based random
access. 17) The target eNB sends the UE
the timing alignment information and UL
Grant. 18) The UE sends the target eNB
a Handover Confirm message as
included in the RRC Connection
Reconfiguration Completemessage.
Now, the UE can send/receive packets

to/from the target eNB, and the
handover interruption time is ended.
19) [UE ~ Target eNB] Secure

Communication over the Radio Link
All RRC signaling messages and user
packets sent over the radio link between
the UE and the target eNB are now
securely delivered using the AS security
keys. RRC signaling messages are
integrity protected and encrypted while
user packets are encrypted before being
sent.

20) [Target eNB] Resuming DL Packet
Delivery to the UE
As the UE is successfully connected to
the target eNB, the target eNB resumes
to send the buffered DL packets to the
UE through the following path (See [A] in
Figure 6):
S5 bearer (P-GW to S-GW) S1

bearer (S-GW to source eNB) S1
bearer (source eNB to S-GW) S1
bearer (S-GW to target
eNB) DRB (target eNB to UE)
In case packets are sent by the UE, the

target eNB checks if the UL packets are
received in the correct order, and then
forwards them to the S-GW through the
following path (See [B] in Figure 6):
DRB (UE to target eNB) S1

bearer (target eNB to S-GW) S5
bearer (S-GW to P-GW)

21) [Target eNB MME] Requesting
the EPS Bearer (S1 Bearer) Path Switch
Once the UE is accessed, the target eNB
notifies EPC (MME) that the UE has
successfully finished the S1 handover by
sending a Handover Notify message that
includes its ECGI and TAI.
22) ~ 27) Modifying the EPS Bearer

The MME forwards the S1 Target eNB
TEID[B] that was allocated by the target
eNB to the S-GW by sending a Modify
Bearer Request message. This way it
requests the S-GW to modify the bearer
path. Then the S-GW establishes a DL S1
bearer connecting to the target eNB, as
requested. Some S-GWs, according to
the options set during UEs initial attach,
are required to report if the UEs serving
cell is changed. In such case, the S-GW
sends a Modify Bearer Request message
to P-GW, having the P-GW report to
PCRF, according to the EPS session
modification procedure, that the UEs
serving cell has been changed.
28) ~ 29) [S-GW] Modifying the EPS

Bearer (S1 Bearer) Path
The S-GW switches the DL packet
delivery path into the DL S1 bearer that
is connected to the target eNB. For this,
first it sends End Marker (EM) to indicate
the last packet to the DL S1 bearer
connected to the source eNB. Then, it
sends DL packets to the target eNB
through the modified DL S1 bearer.

30) [Target eNB] Packet Re-ordering
Now the target eNB receives DL packets
forwarded from the source eNB through
the indirect tunnel AND those sent from
the S-GW through the newly modified
path. So, it should be able to deliver them
to the UE in the correct order. First, the
target eNB forwards the DL packets
received through the indirect tunnel to the
UE. Then when EM arrives, it knows that
the packet was the last one from this path,
and thereafter it sends the DL packets
received from the new path to the UE.
31) ~ 32) [Source eNB MME]

Releasing the UE Context and S1
Resources Stored at the Source eNB
The MME informs the source eNB that it
may release the resources (S1 bearer and
indirect tunnel) it has kept over the S1
interface and the UE Context by sending
an UE Context Release Commandmessage.
The source eNB then releases the UE
Context and S1 resources, and informs the
MME of such release by sending
an UE Context Release Complete message.
33) ~ 34) [MME S-GW] Releasing

the Indirect Tunnel
The MME sends the S-GW a Delete Indirect
Data Forwarding Tunnel Request message,
requesting for release of the indirect
tunnel.
Upon the request, the S-GW releases the
indirect tunnel, and informs the MME of
such release by sending a Delete Indirect
Data Forwarding Tunnel
Response message.
End of Section
EPS Entity Information: Before/After S1 Handover

As, in an intra-LTE environment, the information elements stored at EPS entities before and after S1 handover are the same as in
X2 handover, see our previous document [1] for the details (For EPS entities information, see below).
Information on handover-related AS Security context may vary depending on the types of handover, e.g. X2 or S1. Handover
security is however out of the scope of this document, and hence was not presented here in details.
Information elements stored at EPS entities during the handover procedure are pretty similar but can be different depending on the
types of handover. Those generated during handover and then deleted were not presented.
Closing
Unlike X2 handover, in S1 handover, EPC already knows about UEs handover even before an actual handover is performed. Thus, EPC
is involved in the handover procedure from the handover preparation phase. It performs a handover in cooperation with the source eNB
and target eNB, and forwards DL packets arriving at the source eNB during the handover interruption time to the target eNB through the
indirect tunnel that passes the S-GW, preventing packet loss.

S1 Handover Signaling Flow
Measurement Report

RRC Connection
Reconfiguration

RRC Connection Reconfiguration

PRACH Config Contention

Free

RRC Connection
Reconfiguration Complete

MAC RACH Trigger

4.6 LTE X2 Handover

Overview
X2 Protocol Stacks
X2 handover is performed between a source eNB and a target eNB through the X2 interface. In an LTE network, these two eNBs can directly
communicate with each other via the X2 interface, which differentiates the network from its precedents (2G and 3G). In a 2G or 3G network, the only
way an eNB could learn of the status of its neighboring eNB was through control by packet core nodes. However, now LTE networks allow eNBs to
directly exchange status information with each other via the X2 interface, and to independently perform handovers without any intervention by EPC
nodes. Figure 1 shows the protocol stacks over the X2 interface in control and user planes.
In the control plane, two eNBs provide multiple users with X2 Application Protocol (X2AP) signaling through a single Stream Control Transmission
Protocol (SCTP) connection. In the X2AP layer, users are identified by eNB UE X2AP ID (Old eNB UE X2AP ID, New eNB UE X2AP ID)1. In the data plane,
the two eNBs are connected through a GPRS Tunneling Protocol (GTP) tunnel, as in S1/S5 bearer. A unique GTP tunnel is generated for each user2, and
each tunnel is identified by its allocated Tunnel Endpoint Identifiers (TEIDs).

Overview
X2AP Function
X2AP signaling information can be roughly classified into two kinds, the one related to load/interference (i.e. Load Management function in the table)
and the one related to handover (i.e. Mobility Management, Mobility Parameter Management, Mobility Robustness Optimization functions in the
table).
Among the X2AP functions listed in Table 1, those related to SON are as follows:
Load Management: enhances the interception performance among cells by exchanging load and interference information between two eNBs
eNB Configuration Update: performs automatic eNB configuration
Mobility Parameters Management: negotiates on handover triggering setting information among peer eNBs and uses the information for handover
optimization
Mobility Robustness Optimization: provides information on a handover failure event
Energy Saving: help eNBs to consume less energy by exchanging information on cell activation/deactivation

Overview
X2 Messages Relating to Mobility Management Function
Handover Request message: This message is used during the handover preparation phase. It is delivered by a source eNB to a target eNB, and includes
a users UE context.
Handover Request Acknowledge message: This message is used during the handover preparation phase. It is delivered by the target eNB to the source
eNB if resource allocation is successfully completed by the target eNB.
Handover Preparation Failure message: This message is used during the handover preparation phase. It is delivered by the target eNB to the source
eNB if resource allocation at the target eNB fails.
SN Status Transfer message: This message is used during the handover execution phase. The source eNB delivers it to the target eNB to indicate from
which packet it should receive or send.
UE Context Release message: This message is used during the handover completion phase. The target eNB sends it to the source eNB, to request
release of the UE context.
Handover Cancel message4: This message is used during the handover preparation phase. The source eNB sends it to the target eNB when it needs to
cancel a handover in preparation.

X2 Handover Procedure
Before X2 Handover
In the figure above, the UE is
being served through eNB A (a
serving cell in eNB A, to be more
exact) that it has accessed to.
When the UE detects a
measurement event, it sends
a Measurement Report message
to eNB A.

X2 Handover Preparation
The source eNB (i.e. eNB A in the figure) chooses a target
eNB (i.e. eNB B in the figure) to handover to, based on the
neighbor cell list information it has kept and the
information on the signal strength of the neighbor cells
included in the Measurement Report message.5 Next, it
prepares an X2 handover with the target eNB through X2
signaling. In the meantime, the target eNB allocates
resources in advance so that the same services currently
available to the user at the source eNB are readily available
at the target eNB as well. Also, to ensure a fast handover,
the target eNB sends all the information needed for the
user to connect to the target cell (e.g. C-RNTI) to the
source eNB, which then forward the same to the UE,
initiating the handover execution phase. The target eNB
allocates resources as follows:
When the source eNB sends the target eNB a Handover
Request message that includes the users UE context (),
The target eNB:
obtains S1 bearer information (S1 S-GW TEID) to
establish an UL S1 bearer through which to transport UL
packets ().
allocates TEID for the X2 transport bearer (GTP-U
tunnel) through which to receive DL packets while UE
attempts to access the target eNB.
allocates DRB resources and C-RNTI to be used by UE in
the target cell.
sends a Handover Request Ack message to the source
eNB ().
Upon receiving the message, the source eNB establishes
an X2 transport bearer through which to send DL packets
().

X2 Handover Execution
Once handover preparation between the two eNBs is
completed, it is time to have the UE perform a handover.
The source eNB:
instructs the UE to perform a handover to the target cell
by sending it a Handover Command message that includes
all the information needed to access the target cell ().
informs from which UL/DL packet the target eNB should
receive or send when communicating with the UE by
sending the target eNB an SN Status Transfer message
().
forwards the DL packets received from S-GW to the
target eNB through the X2 transport bearer established
between itself and the target eNB ().
The UE detaches from the source eNB and accesses to the
target eNB ().
The target eNB becomes capable of sending and receiving
packets once the UE has successfully accessed ().

X2 Handover Completion
As seen so far, all the procedures performed during the
handover execution phase (i.e. after the source eNB
decided to perform a handover, and until the UE finally
was connected to the target eNB) were just between the
two eNBs, and no information about the handover was
reported to EPC (MME). Now that the handover is
completed, the target eNB informs EPC as follows:
Once the UE has accessed, the target eNB informs EPC and
sends a Path Switch Request message to MME so that the
EPS bearer path can be modified accordingly ().
When receiving the message, the MME becomes aware of
the UEs new serving cell. Then, it requests S-GW for S1
bearer modification ().
Upon the request, the S-GW establishes a DL S1 bearer (S1
Target eNB TEID) that connects to the target eNB. Then it
stops sending DL packets to the source eNB, and begins to
send them to the target eNB through the newly
established DL bearer ().
The MME informs the target eNB that the DL S1 bearer
path has been modified ().
The target eNB sends the source eNB a UE Context
Release message, allowing the source eNB to release the
UE context ().
After X2 Handover
The UE is now being served through eNB B (the serving cell
at eNB B, to be more exact) that it has accessed.

UE State and Connection Information Before
and After X2 Handover
Before X2 Handover
The UE stays in EMM-
Registered and ECM/RRC-Connected and
keeps all the resources allocated by E-UTRAN
and EPC.
During X2 Handover
Even during the handover phase, the UEs
state in the NAS layer remains unchanged, and
an X2 bearer6 and X2 signaling connection are
established over the X2 interface. In Figure 3,
Step 2) shows the connections and states
while the handover is interrupted during the
handover execution phase. During this period,
no radio link connection is active, but the UE
still remains Connected.
After X2 Handover
The UE remains in EMM-
Registered and ECM/RRC-Connected states.
The E-RAB (DRB + S1 bearer) path is switched
to access to a new eNB in the user plane while
a new RRC connection and S1 signaling
connection (eNB(B) S1AP UE ID) are
established in the control plane.

Before Handover
1) [UE eNB] Measurement
Report
As a measurement event is
triggered,8 the UE measures the
signal strength of neighbor cells, and
sends a Measurement
Report message to its associated
eNB (serving cell).
Handover Preparation
2) [Source eNB] Handover
Decision
The source eNB selects a target eNB
based on the information included in
the Measurement Report message
sent by the UE, and the neighbor cell
list information it has kept. In actual
handovers, there can be more than
one target eNB candidate, or a
neighbor cell other than the one(s)
reported by UE may be selected as a
target cell. However, we will assume
that only one eNB where the cell
included in the Measurement
Report message belongs is selected
as a target eNB in this document.

3) [Source eNB] Deriving the AS
Security Base Key (KeNB*) to be
Used by the Target eNB
When a handover takes place, the
serving eNB of a UE is switched.
During this switch, RRC signaling
messages and user packets still have
to be delivered seamlessly and
securely. Over the radio link, it is AS
security keys that ensure secured
delivery of such data. AS security
keys are derived from KeNB, the AS
security base key9. KeNB is derived
from KASME by MME after user
authentication, and sent to eNB10.
However, because X2 handover is
performed between two eNBs
without any intervention by EPC
(MME), the target eNB cannot
obtain KeNB* (KeNB to be used by the
target eNB) from MME. So, the
source eNB derives it and sends to
the target eNB.
For this reason, once the source eNB
decides to perform a handover, it
derives KeNB* first, as seen in Figure
5. We can see that KeNB* is derived
from KeNB (the AS security base key
of the source eNB), and the target
cells Physical Cell ID (PCI) and
frequency (E-UTRA Absolute Radio
Frequency Channel Number-
Downlink (EARFCN-DL)).

4) [Source eNB Target eNB]
Requesting X2 Handover
The source eNB requests a handover
by sending a Handover
Request message to the target eNB.
Through this message, it delivers the
UE context information it has stored,
and the UE history which shows the
cells that the UE has connected to
prior to the last handover to the
target cell. The information included
in the message is as follows:

5) [Target eNB] Preparing X2
Handover
Upon receiving the Handover
Request message, the target eNB begins
handover preparation to ensure
seamless service provision for the UE.
(i) First, it derives AS security keys
(KRRCint, KRRCenc, KUPenc) from KeNB* it
received from the source eNB. Using
these keys, the target eNB can
communicate securely with the UE over
the radio link when the UE accesses.
(ii) Next, the target eNB, based on the
E-RAB to be setup information, checks if
the same QoS provided by the source
eNB is available at the target eNB as
well. If available, it establishes an UL S1
bearer connecting to S-GW, by using the
UL S1 bearer information (S1 S-GW
TEID) stored at the source eNB.
(iii) Then, based on the E-RAB QoS
information, the target eNB reserves
RRC resources to be used by the UE over
the radio link (e.g. DRB ID allocation,
etc.), and allocates C-RNTI.
(iv) While the UE is performing a
handover (i.e. after it disconnects from
the source eNB, until it connects to the
target eNB), DL packets arriving at the
source eNB need to be forwarded to the
target eNB. For this, the target eNB
allocates X2 Target eNB TEID (DL TEID of
X2 GTP tunnel) so that the source eNB
can establish an X2 transport bearer
(GTP tunnel).

Notifying the Source eNB of
Preparation Completion
The target eNB sends the source eNB all
the information about the resources
prepared in Step 5), as included in
a Handover Request Ack11 message. The
included information is as follows:
7) [Source eNB] Establishing X2

Transport Bearer for DL Packets
Delivery
Upon receipt of the Handover Request
Ack message, the source eNB knows the
target eNB can serve the UE. Then, using
the X2 Target eNB TEID, it begins to
establish an X2 transport bearer so that
DL packets can be forwarded to the
target eNB during the handover
execution phase.

8) [UE Source eNB] Commanding a
Handover
Once the source eNB completes the
handover preparation with the target
eNB, it orders the UE to perform a
handover by sending a Handover
Command message.
9) [UE] Executing a Handover

The UE, from the received Handover
Command message, obtains C-RNTI and
DRB ID to be used at the target cell, and
detaches from the source eNB. Now, all
packet delivery between the UE and the
source eNB is stopped, and the
handover interruption time13 period
begins.
10) [UE] AS Security Setup

The UE derives AS security keys to be
used over the radio link of the target
eNB. First it derives KeNB* (AS base key
for the target eNB) from the source
eNBs KeNB, the target cells PCI and
frequency (the relevant key derivation
functions are as seen in Figure 5). Next,
it derives AS security keys for the target
eNB (KRRCint, KRRCenc, KUPenc) by using the
AS security algorithms that the target
eNB selected.

Notifying the No. of the Packet to
Send/Receive
The source eNB informs the target eNB
from which packet it should send to (or
receive from) the UE by sending a SN
Status Transfer message that includes
DL Count and UL Count. Here, the count
values are PDCP PDU Counts, and each
Count is a 32-bit value consisting of
Hyper Frame Number (HFN) and PDCP
Sequence Number (SN). The information
After sending the SN Status

Transfer message to the target eNB, the
source eNB begins to forward DL
packets arriving from S-GW to the target
eNB through the X2 transport bearer
(GTP tunnel) established over the X2
interface. The target eNB buffers the
packets and waits for completion of the
UEs access.

12) ~ 14) [UE, Target eNB] UEs Access
to the Target eNB
12) The UE detects the synchronization
signal from the target eNB to perform
synchronization to the target eNB. Once
synchronized, the UE initiates non-
contention based random
access. 13) The target eNB sends the UE
the timing alignment information and
UL Grant. 14) The UE sends the target
eNB a Handover Confirm message as
included in the RRC Connection
Reconfiguration Complete message.
Now, the UE can send/receive packets
to/from the target eNB, and the
handover interruption time period is
ended.
15) [UE - Target eNB] Secure

Communication over the Radio Link
All RRC signaling messages and user
packets sent over the radio link between
the UE and the target eNB are now
securely delivered using the AS security
keys. RRC signaling messages are
integrity protected and encrypted while
user packets are encrypted before being
sent.

16) [Target eNB] Resuming DL Packet
Delivery to the UE
As the UE is successfully connected to
the target eNB, the target eNB starts to
send the buffered DL packets to the UE
through the following path (See [A] in
Figure 6):
S5 bearer S1 bearer (@source
eNB) X2 bearer DRB (@target eNB)
In case packets are sent by the UE, the

target eNB checks if the UL packets are
received in the correct order, and then
forwards them to S-GW through the
following path (See [B] in Figure
behind):
DRB (@target eNB) S1 bearer
(@target eNB) S5 bearer

X2 Handover Completion
17) [Target eNB MME] Requesting the EPS Bearer
(S1 Bearer) Path Switch
The target eNB notifies EPC (MME) that the UEs
serving cell is switched by sending a Path Switch
Request message, and requests for switch of EPS
bearer path.
18) ~ 23) Modifying the EPS Bearer

The MME forwards the S1 Target eNB TEID that was
allocated by the target eNB to the S-GW by sending
a Modify Bearer Request message. This way it
informs the S-GW that the DL S1 bearer has been
switched, and asks to switch the bearer path
accordingly. Then the S-GW establishes a DL S1
bearer connecting to the target eNB, as requested.
Some S-GWs, according to the options set during UEs
initial attach, are required to report if the UEs serving
cell is changed while an EPS session is created. In such
case, the S-GW sends a Modify Bearer
Request message to P-GW, having the P-GW report
to PCRF, according to the EPS session modification
procedure, that the UEs serving cell has been
changed.
24) [S-GW] Modifying the EPS Bearer Path and

Sending EM Packets
Now that the DL S1 bearer path is modified, the S-GW
switches the DL packet delivery path into the DL S1
bearer that is connected to the target eNB. For this,
first it sends End Marker (EM) to indicate the last
packet to the DL S1 bearer connected to the source
eNB. Then, it sends DL packets to the target eNB
through the modified DL S1 bearer.

EPS Entity Information: Before X2 Handover

EPS Entity Information: After X2 Handover

End of Section
We have so far discussed the X2 handover procedure performed in an intra-LTE environment where
neither MME nor S-GW is changed after the procedure. X2 handovers are performed by source and
target eNBs without EPCs intervention. We also learned that DL packets are forwarded through the
X2 transport bearer during the handover interruption time, to prevent packet loss.

X2 Handover Signaling Flow
Measurement Report

RRC Connection
Reconfiguration

C-RNTI
RRC Connection
Reconfiguration

PRACH Config

RRC Connection
Reconfiguration Complete

Target C-RNTI

Thank You

Author
Ray Khastur, ST.
Educational Background :
Bachelor of Telecommunication Engineer, Telkom Institute of Technology (2006
2010) JPPA-N Acceleration
Professional Experience :
PI.Works, RAN Consultant (2014 ~ Present)
China JIESAI, LTE Optimization Consultant (2014)
Lintas Media Telekomunikasi, LTE RF Team Leader (2013 ~ 2014)
HUAWEI Tech Investment, CWiL RNP/O Engineer (2011 ~ 2013)
Transdata Global Network, CDMA RNO Engineer (2010 ~2011)
Achievements :
RF Network Design & Planning First Commercial LTE Network in Indonesia (BOLT!
Super 4G LTE)-2013 HUAWEI
NPI & Post Launch Optimization BOLT! Super 4G LTE - 2014 PI.Works
LTE Technical Expert for HUAWEI Environment
LTE Planning & Optimization Trainer Floatway Certified-2013
LTE HUAWEI Trainer for Subcont-2016


4 Ltelayer3analysispart2 160408140151

Uploaded by

Copyright:

Available Formats

4 Ltelayer3analysispart2 160408140151

Uploaded by

Document Information

Original Description:

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

4 Ltelayer3analysispart2 160408140151

Uploaded by

Copyright:

Available Formats

4.

LTE Layer 3 Analysis (Part 2)

Author : Ray Khastur

Consulting | Training | Research

Company Confidential - Pinnacle Learning Center

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

12. (Optional) If the CSFBIMMASSENSW parameter involved in the GBFD-

MobileComm Professionals, Inc

Consulting | Training | Research

14 to 17. (Optional) If the UE is processing PS services before initiating a

Consulting | Training | Research

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

Current RSRP bigger

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

U2000 Configuration to add GERAN BCCH target only

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

BSC buffer TMSI

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

System Information Type 6

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

CSFB Call Setup

MobileComm Professionals, Inc

Consulting | Training | Research

CSFB to GERAN Call

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc