06 LTE1617 RLF Triggered Handover

LTE1617 RLF triggered handover
Telefonica UK – RL70 workshop

• Marek Bryłka
• 28-11-2014
1 © Nokia Solutions and Networks 2014

For internal use
Table of contents
Introduction Technical Inter – Benefits and Performance

Details dependencies Gains Aspects
Motivation and Feature Detailed Functionality Simulation, Lab and Field
Interdependencies with Counters and KPIs,
Overview Description Findings
other features and Feature Impact Analysis
Simulation, Lab and
functions and Verification
1 Field Findings

For internal use
Introduction
Table of contents

For internal use
Introduction
LTE1617 RLF triggered Handover in a nutshell
• LTE1617 RLF triggered handover provides enhancement in handling of Connection Re-establishment procedure
• According to 3GPP 36.331 requirements Connection Re-establishment procedure triggered by the UE side may only be
successful only if it is directed to prepared cell, so the cell having valid UE Context for such UE
Connection Re-establishment Connection Re-establishment

procedure may be successful procedure always rejected
prepared cell unprepared cell

(UE context available) (UE context not available)
• With the help of LTE1617 RLF triggered handover Connection Re-establishment request may be successful even if directed to
unprepared cell
Connection Re-establishment
procedure may be successful
initially unprepared cell due to functionality

provided by LTE1617 becomes a prepared
cell and finally Connection Re-establishment
procedure may be successful
For internal use
Introduction
RRC connection re-establishment procedure - basic information
• UE triggers RRC Connection re-establishment procedure upon detection of situations for which ongoing call does not work
correctly on air interface
• RRC Connection re-establishment is triggered upon detection of:

• radio link failure (RLF)
• T310 expiry as result of out-of-sync problems controlled by n310(LNCEL), n311(LNCEL), t310(LNCEL)
• upon random access problem indication from MAC
• upon indication from RLC that the maximum number of retransmissions has been reached
• handover failure due to t304 expiry applicable for intra LTE HOs controlled by t304IntraLte (LNCEL))
• mobility from E-UTRA failure due to t304 expiry applicable for inter-RAT handover types; controlled by
t304InterRAT(LNCEL) for PSHO and SRVCC to WCDMA, t304InterRatTd(LNCEL) for PSHO to TD-SCDMA;
t304InterRATGsm(LNCEL) for SRVCC to GSM, t304eNaccGsm(LNCEL) for eNACC to GSM)
• integrity check failure
• RRC connection reconfiguration failure

For internal use
Introduction
UE eNB
3GPP 36.331, chapter 7.3 Timers (Informative)

RLF, HO failure, mobility from E-UTRA failure,
integrity check failure, RRC connection Timer Start Stop At expiry
reconfiguration failure detected
T311
Upon initiating the
Cell selection process acc. to 36.304 Selection of a suitable
RRC connection re- Enter
T311 E-UTRA cell or a cell
establishment RRC_IDLE
using another RAT.
procedure
PRACH Random Access (Msg1)
PRACH Random Access Response (Msg2) Reception of

RRCConnectionReesta
Transmission of blishment or
RRCConnectionReestablishmentRequest (Msg3) RRCConnectionReest RRCConnectionReesta Go to
T301
abilshmentRequest blishmentReject RRC_IDLE
message message as well as
RRCConnectionReestablishment (Msg4)
T301 when the selected cell
becomes unsuitable
RRCConnectionReestablishmentComplete (Msg5)
t311 (LNCEL), default value 3000ms

t301 (LNCEL), default value 400ms
For internal use
Introduction
UE eNB
During cell selection process any LTE cell (not only the serving
RLF, HO failure, mobility from E-UTRA failure, one) may be selected by the UE as a target for re-establishment:
integrity check failure, RRC connection • for UEs without ongoing handover
reconfiguration failure detected • serving cell -> prepared cell
• neighbor cell of serving eNB -> unprepared cell
Cell selection process acc. to 36.304 • neighbor cell of other eNB -> unprepared cell
• for UEs with ongoing handover
PRACH Random Access (Msg1) • source cell -> prepared cell
Random • target cell -> prepared cell
Access • neighbor cell of source eNB -> unprepared cell
PRACH Random Access Response (Msg2) procedure • neighbor cell of target eNB -> unprepared cell
• neighbor cell of other eNB -> unprepared cell
RRCConnectionReestablishmentRequest (Msg3)
Exchange of RRC
messages for
RRCConnectionReestablishment (Msg4) execution of RRC This is why re-establishment directed to unprepared should
connection re- not be neglected
RRCConnectionReestablishmentComplete (Msg5) establishment
procedure

For internal use
Introduction
Successful handling of RRC connection re-establishment directed to unprepared cell
• LTE1617 RLF triggered handover provides mechanism, which allows for retrieving of UE Context from cell being prior
RRC connection re-establishment procedure a serving cell
cell A cell B
UE UE served by cell A Re-establishment directed to an unprepared
with valid UE Context cell B
with no UE Context valid for the UE
UE initially served by cell A UE Context provided from cell A to cell B;

as result cell B becomes prepared cell B
RLF, HO failure, mobility from E-UTRA failure,
integrity check failure detected by the UE triggers
re-establishment procedure
Unprepared cell B is selected during cell selection process + successfully Random Access to this cell is done
RRCConnectionReestablishmentRequest
LTE1617 RLF triggered handover functionality allows for retrieving the UE Context from cell A to
unprepared cell B which becomes a prepared cell suitable for accept re-establishment request
RRCConnectionReestablishment
RRCConnectionReestablishmentComplete

For internal use
Technical Details
Table of contents

For internal use
Technical Details
RRC connection re-establishment procedure to other cell of serving eNB (1617-A)
UE eNB
• RRC:RRCConnectionReestablishmentRequest
message is sent to cell B, other than the serving one
Cell A Cell B • Based on PCI, C-RNTI, short MAC-I included in
this message, eNB detects that requested cell is
UE initially served by cell A unprepared cell; eNB also detects that it handles
also serving cell
RLF, integrity check failure detected
• eNB initiates Intra-eNB handover from cell A
towards cell B
Cell B selected during cell selection process acc. to 36.304 • Initially unprepared cell B becomes the prepared
PRACH Random Access (Msg1) one and Connection Re-establishment may be
PRACH Random Access Response (Msg2)
handled successfully
(PCI, C-RNTI, short MAC-I X2AP: HANDOVER REQUEST* RLF triggered Intra-eNB handover
related to serving Cell)
Admission Control
X2AP: HANDOVER REQUEST ACKNOWLEDGE*

RRCConnectionReestablishmentComplete (Msg5) *Note: treat X2AP messages as internal ones,

because in fact intra-eNB HO does not use X2
10 © Nokia Solutions and Networks 2014 interface for message exchange
For internal use
Technical Details
UE eNB
• RLF triggered Intra-eNB handover may be
rejected by Admission Control
Cell A Cell B • If the Handover Preparation phase fails for any
with valid UE Context
reason (AC is the case), eNodeB shall stop
UE initially served by cell A processing the RLF triggered Handover
• As result RRC Connection re-establishment
procedure is completed by sending
RRC:RRCConnectionReestablishmentReject
Cell B selected during cell selection process acc. to 36.304 message from cell B towards the UE
related to serving Cell) rejected due to AC or other reasons
Admission Control
RRCConnectionReestablishmentReject (Msg4)
*Note: treat X2AP messages as internal ones,

because in fact intra-eNB HO does not use X2
11 © Nokia Solutions and Networks 2014 interface for message exchange
For internal use
Technical Details
• Activation of LTE1617-A
• Functionality defined by LTE1617-A does not need any additional parameter

configuration
• LTE1617-A is treated as an extension of basic feature LTE735 and available

by default after upgrade to RL70/RL55TD
• There is no dedicated feature activation flag for mechanism described by

LTE1617-A (successful handling of re-establishment towards unprepared cell of
serving eNB is possible without any additional parameterization)

For internal use
Technical Details
RRC connection re-establishment procedure to other eNB (1617-B)
UE Serving Other • RRC:RRCConnectionReestablishmentRequest sent
eNB eNB
by the UE to the cell B covers information about PCI,
Cell A Cell B C-RNTI, shortMAC-I used so far in serving cell A
with valid UE Context • Based on the received PCI value, Other eNB
UE initially served by cell A
recognizes that the so far serving cell A does not
belong to Other eNB
RLF, integrity check failure detected • This is the trigger for sending of X2AP: RLF
INDICATION by Other eNB
Cell B selected during cell selection process acc. to 36.304
• X2AP: RLF INDICATION message is sent to all
eNBs defined as neighbors and handling cells with
PCI the same as signaled in
PRACH Random Access Response (Msg2) RRC:RRCConnectionReestablishment
RRCConnectionReestablishmentRequest (Msg3) (the serving eNB is one of them); this may happen
(PCI, C-RNTI, short MAC-I
because PCI values 0…503 are repeated in the network
X2AP: RLF INDICATION RLF triggered Inter-
related to serving Cell) eNB handover

For internal use
Technical Details
UE Other neighbor eNB, Serving Other

having the cell eNB eNB
identified by the same
PCI as the PCI of Cell
Cell C, PCI=10 A of Serving eNB Cell A, PCI=10 Cell B
with valid UE Context Cell A, PCI=10
Cell C, PCI=10
defined as targets for
handover
(PCI=10, C-RNTI, shortMAC-I related to serving cell)
X2AP: RLF INDICATION

X2AP message ignored due to
(PCI=10, C-RNTI, shortMAC-I related to serving cell,
lack of UE Context identified ECGI of unprepared cell of Other eNB)
by C-RNTI
X2AP message received by Serving
(PCI=10, C-RNTI, shortMAC-I related to serving cell,
eNB with valid UE Context is a ECGI of unprepared cell of Other eNB)
trigger for inter-eNB HO, because
received C-RNTI and shortMAC-I
match the values of existing UE
Context
For internal use
Technical Details
UE Serving Other
eNB eNB
Cell A Cell B • X2AP: HANDOVER REQUEST message is

with valid UE Context sent towards Other eNB; this way UE Context is
UE initially served by cell A provided to Other eNB which handles Cell B,
selected by the UE as re-establishment target cell
• X2AP: HANDOVER REQUEST is directed to
Cell B selected during cell selection process acc. to 36.304 Other eNB based on the content of IE:Re-
PRACH Random Access (Msg1) establishment cell ECGI of the X2AP: RLF
INDICATION message
• Assuming that Admission Control does not reject
X2AP: HANDOVER REQUEST, initially
X2AP: RLF INDICATION RLF triggered Inter- unprepared cell B becomes a prepared cell (UE
eNB handover
X2AP: HANDOVER REQUEST Context is provided to other eNB) and re-
establishment procedure may be successfully
Admission Control
completed
X2AP: HANDOVER REQUEST ACKNOWLEDGE
X2AP: UE CONTEXT RELEASE


For internal use
Technical Details
UE Serving Other
eNB eNB • RLF triggered Inter-eNB handover may be
rejected by Admission Control
Cell A Cell B • If the Handover Preparation fails for any reason
(AC is the case), eNB stops processing the RLF
UE initially served by cell A triggered Handover, and sends X2AP:
HANDOVER PREPARATION FAILURE to
serving eNB
• As result RRC Connection re-establishment
Cell B selected during cell selection process acc. to 36.304 procedure is completed by sending
PRACH Random Access (Msg1) RRC:RRCConnectionReestablishmentReject
message from cell B towards the UE
X2AP: RLF INDICATION RLF triggered Inter-eNB handover

X2AP: HANDOVER REQUEST rejected due to AC or other reasons
Admission Control
X2AP: HANDOVER PREPARATION FAILURE
RRCConnectionReestablishment Reject(Msg4)

For internal use
Technical Details
UE Serving Other
eNB eNB • RRC Connection re-establishment procedure may
be suspended in Other eNB by certain time
Cell A Cell B controlled by T301 guard timer
• T301 guard is stared upon sending X2AP: RLF
UE initially served by cell A INDICATION and stopped upon receiving of
X2AP: HANDOVER REQUEST from Serving
eNB
• If T301 guard expires, the suspended RRC Re-
PRACH Random Access (Msg1) establishment procedure shall be resumed and
PRACH Random Access Response (Msg2) eNB rejects such request by sending
RRC:RRCConnectionReestablishmentReject
message to UE
X2AP: RLF INDICATION • T301 guard timer is controlled by parameter t301
X2AP: HANDOVER REQUEST T301 guard (LNCEL) - the same which is used to control timer
T301 on UE side
T301 Admission Control


For internal use
Technical Details
• Activation of LTE1617-B
• Functionality defined by LTE1617-B is activated by feature flag

actRLFbasedRCR (LNBTS)
• Feature flag has to be active on both Serving eNB and Other eNB
• This is also a must that X2 relations between Serving and Other eNB exists, are not
blacklisted and these relations are active for RLF triggered handover (this check
is defined by subfeature LTE1617-C

For internal use
Technical Details
RRC connection re-establishment with source UE-Identity to source eNB, target eNB or
other eNB during ongoing handover procedure (1617-D)
• In general the logic of LTE1617-D is the same as defined for LTE1617-A and LTE1617-B
• Re-establishment directed to unprepared cell of source eNB, target eNB, other eNB may be supported by retrieving of UE
Context from source cell
• The only difference is that any ongoing handovers, eNACC to GSM, SRVCC or CSFB via PSHO procedures are
cancelled before retrieving of UE Context from source eNB
• This is required due to fact that retrieving of UE Context uses intra-eNB HO or X2 based inter-eNB HO and it is not possible
to handle more than one HO procedures at the same time for a given UE
• LTE1617-D is activated with the same feature flag as LTE1617-B i.e. actRLFbasedRCR (LNBTS)

For internal use
Technical Details
Example: RCR triggered to Other eNB during ongoing inter-eNB HO via X2 (LTE1617-
D) UE Source Target Other
eNB eNB eNB
Cell A Cell C Cell B

Inter-eNB HO via X2 towards cell C ongoing
RLF, HO failure, mobility from E-UTRA failure, integrity check

failure, failure detected
Random Access procedure to Cell B of Other eNB, selected as target for re-establishment
RRCConnectionReestablishmentRequest
Inter-eNB HO via X2 cancellation

X2AP: HANDOVER REQUEST
Admission Control
RRCConnectionReestablishment
RRCConnectionReestablishmentComplete

For internal use
Technical Details
Configuration support for RCR to unprepared cells (1617-C)
• To allow RLF triggered Handover from Serving/Source eNB to Other eNB (with unprepared cell requested as re-establishment
target) feature flag actRLFbasedRCR(LNBTS) has to be set to value true in both eNBs
• Between these eNBs, X2 based neighbor relations must exist in both directions
• In Serving/Source eNB LNADJ instance identifying Other eNB has to be created and not blacklisted
• In Other eNB LNADJ instance identifying Serving/Source eNB has to be created and not blacklisted
• There is a parameter rlfBasedRCRsupported(LNADJ) introduced per each LNADJ instance which controls whether the
existing NR may be used for RLF triggered Handover purposes or not; if the neighbor eNB is supposed to support LTE1617
functionality it is reasonable that LNADJ instance indicated this neighbor eNB should be configured by
rlfBasedRCRsupported(LNADJ) = true
• If rlfBasedRCRsupported(LNADJ) = false this NR may be used for mobility triggered Handover but not for RLF triggered
handover
• For new LNADJ instances created by ANR functionality it is possible to define what should be the value of
rlfBasedRCRsupported(LNADJ); whether this parameter shall be set to true or false depends on the setting of parameter
rlfBasedRCRdefault(LNBTS)

For internal use
Technical Details
Configuration support for RCR to unprepared cells (1617-C)
eNB 2
X2 DB on eNB 2
eNB 1
actRLFbasedRCR(LNBTS) = true
rlfBasedRCRsupported(LNADJ for eNB 1) = true
DB on eNB 1
actRLFbasedRCR(LNBTS) = true eNB 3
X2
rlfBasedRCRsupported(LNADJ for eNB 3) = false
DB on eNB 3
actRLFbasedRCR(LNBTS) = true
• Despite LTE1617 is activated on eNB 1 and on eNB 3 (actRLFbasedRCR(LNBTS) = true on both eNBs) the re-establishment
towards unprepared cell supported by eNB 3 is not possible because LNADJ relation to eNB 3 is not active
(rlfBasedRCRsupported(LNADJ for eNB 3) = false in eNB 1 database) and RLF triggered handover between eNB 1 and eNB
3 is not possible

For internal use
Interdependencies
Table of contents

For internal use
Interdependencies
LTE735 RRC connection reestablishment:

extensions Some cases which was formerly be rejected will now be accepted
LTE533 MRO
Selected MRO related counters are also pegged by RLF triggered handover
LTE492 ANR, LTE556 ANR intra-LTE, inter-frequency - UE based, LTE882 ANR fully UE based:
The discovery of a new neighbor cell requires adding of new configuration parameters (enhanced
ANR profiles)

For internal use
Interdependencies
LTE53 Intra and inter eNB handover via X2:

limitations Ongoing intra and inter eNB handover via X2 is cancelled by X2AP: RLF INDICATION
X2AP: RLF INDICATION triggers a modified Intra and inter eNB handover via X2; the purpose is
providing of UE Context to unprepared cells, so only preparation phase is used in the context of
modified Intra and inter eNB handover via X2
LTE54 Intra-LTE handover via S1:
Ongoing intra-LTE handover via S1 is cancelled by X2AP: RLF INDICATION
LTE56 Inter RAT handover to WCDMA:
Ongoing inter RAT handover to WCDMA is cancelled by X2AP: RLF INDICATION
LTE898 IRAT HO to TD-SCDMA:
Ongoing inter RAT handover to TD-SCDMA is cancelled by X2AP: RLF INDICATION
LTE442 Network assisted cell change to GSM:
Ongoing eNACC procedure is cancelled by X2AP: RLF INDICATION

For internal use
Interdependencies
LTE872 SRVCC to WCDMA:

limitations Ongoing SRVCC to WCDMA is cancelled by X2AP: RLF INDICATION
LTE873 SRVCC to GSM:
Ongoing SRVCC to GSM is cancelled by X2AP: RLF INDICATION
LTE1127 Service based mobility trigger:
Ongoing service based handover is cancelled by X2AP: RLF INDICATION
LTE511 Intra cell handover:
Ongoing intra cell handover will be cancelled by an internal RLF indication

For internal use
Benefits and Gains
Table of contents

For internal use
Benefits and Gains
Main motivation for introducing LTE1617 RLF based handover
LTE1617 allows successful RRC connection re-establishment (RCR) to unprepared cells (which do not know the UE context)
what was not possible before
• To unprepared cells of serving eNB or source eNB (during HO with source UE-Identity) in a fully standard compliant way like
LTE735 - here intra-eNB RLF triggered handover provides the UE Context to unprepared cell, which than becomes a prepared
cell
• To unprepared cells of not the serving eNB and not the source eNB (during HO with source UE-Identity) in a proprietary way
based on a RLF triggered handover, by suspending the reestablishment procedure at requested eNB, triggering a X2 handover
preparation to it from serving eNB, and resuming the reestablishment procedure based on the prepared X2 handover.
The main aim of LTE1617 is a reduction of UE drop rate especially reduction of VoLTE drop rate.
• Without the LTE1617 feature re-establishment to unprepared cell always fails and finally the UE has to establish a new
connection; this new RRC connection and service requests causes more packet loss and may even break application protocols;
field test shows VoLTE connection will be lost in this case.
•Functionality of LTE1617-A is active on eNB by default, just after upgrade to RL70/RL55TD

For internal use
Performance
Aspects
Table of contents

For internal use
Performance Aspects
General information
• For the monitoring of the LTE1617 RLF Triggered Handover procedure set of measurements is defined M8027 - LTE Handover
(RLF Trigger)
• HO_RLF_PREP_ATT (M8027C0)
• HO_RLF_PREP_SUCC (M8027C1)
• HO_RLF_SUCC (M8027C2)
• RCR_UE_CONTEXT_RETR_ATT (M8027C3)
• RCR_UE_CONTEXT_RETR_SUCC (M8027C4)
• RCR_UE_CONTEXT_RETR_FAIL_TIM (M8027C5)
• Measurement granularity for counters from M8027 - LTE Handover (RLF Trigger) is controlled by new parameter mtHoRlf
(PMRNL)

For internal use
Performance Aspects
New Counters (updated on serving eNB)
Counter name Description

HO_RLF_PREP_ATT (M8027C0) This measurement provides the number of attempted Handover Preparations, which is
M8027 LTE Handover - RLF Trigger caused by the reception of a RLF Indication message.
Trigger event: 1. For re-establishment request directed to unprepared cell of serving or
source eNB (in case mobility based handover procedure is ongoing) this counter is
updated if internal handover preparation phase, triggered by internal RLF
Serving M8027C0 Other indication message, is started. 2. For re-establishment request directed to unprepared
eNB eNB cell of other eNB or target eNB (in case mobility based handover procedure is ongoing)
this counter is updated if X2AP:HANDOVER REQUEST message is sent by the
serving eNB as result of receiving X2AP:RLF INDICATION sent by other or target
eNB
Use case: counter HO_RLF_PREP_SUCC, together with HO_RLF_PREP_ATT may by
Admission Control used by KPI for controlling of ratio of successful preparation phase for RLF triggered
X2AP: HANDOVER REQUEST ACKNOWLEDGE handovers
Proposed (new) = HO_RLF_PREP_SUCC
×100%
KPI#1 HO_RLF_PREP_ATT

For internal use
Performance Aspects

HO_RLF_PREP_SUCC (M8027C1) This measurement provides the number of successful Handover Preparations, which is
M8027 LTE Handover - RLF Trigger caused by the reception of a RLF Indication message.
source eNB the counter is updated if internal handover preparation phase, triggered
by internal RLF indication message, is successfully completed. 2. Fore-establishment
Serving M8027C1 Other request directed to unprepared cell of other eNB or target eNB (in case mobility based
eNB eNB handover procedure is ongoing) this counter is updated if X2AP:X2AP:HANDOVER
REQUEST ACKNOWLEDGE message sent by other or target eNB is received by
the serving eNB
Use case: counter HO_RLF_PREP_SUCC, together with HO_RLF_PREP_ATT may by
used by KPI for controlling of ratio of successful preparation phase for RLF triggered
Admission Control handovers
Proposed (new) = HO_RLF_PREP_SUCC
×100%

For internal use
Performance Aspects

HO_RLF_SUCC (M8027C2) This measurement provides the number of successful Handovers, which is caused by the
M8027 LTE Handover - RLF Trigger reception of a RLF Indication message.
source eNB the counter is updated as result of reception of eNB-internal message in
case this message indicates the successful outcome of the RLF-triggered
Serving M8027C2 Other Handover2. For re-establishment request directed to unprepared cell of other eNB or
eNB eNB target eNB (in case mobility based handover procedure is ongoing) this counter is
updated if X2AP:UE CONTEXT RELEASE message sent by other or target eNB is
received by the serving eNB as result of successful RLF-triggered handover
Use case: counter HO_RLF_SUCC, together with HO_RLF_PREP_ATT may by used
by KPI to control the ratio of successful RLF triggered handovers
Admission Control
Proposed (new) = HO_RLF_SUCC
×100%

For internal use
Performance Aspects
New Counters (updated on eNB selected as target for re-establishment)

RCR_UE_CONTEXT_RETR_ATT This measurement provides the number of attempted UE Context Retrievals during RRC
(M8027C3) Connection Reestablishment procedure.
M8027 LTE Handover - RLF Trigger Trigger event: 1. For re-establishment request directed to unprepared cell of serving or
source eNB the counter is updated as result of sending internal RLF Indication
message 2. For re-establishment request directed to unprepared cell of other eNB or
Serving M8027C3 Other target eNB (in case mobility based handover procedure is ongoing) this counter is
eNB eNB updated as result of sending X2AP: RLF INDICATION message by other or target
eNB
X2AP: RLF INDICATION Use case: The counter RCR_UE_CONTEXT_RETR_SUCC together with
RCR_UE_CONTEXT_RETR_ATT may be used by KPI to control the ratio of
successful allocated UE Context in unprepared cell.
Admission Control
Proposed (new) = RCR_UE_CONTEXT_RETR_SUCC
×100%
KPI#3 RCR_UE_CONTEXT_RETR_ATT

For internal use
Performance Aspects

RCR_UE_CONTEXT_RETR_SUCC This measurement provides the number of successful UE Context Retrievals during RRC
(M8027C4) Connection Reestablishment procedure.
M8027 LTE Handover - RLF Trigger Trigger event: 1. For re-establishment request directed to unprepared cell of serving or
source eNB the counter is updated as result of Sending of eNB-internal message in
case this message indicates the successful allocation of the UE context as a result of a
Serving M8027C4 Other successful RLF-triggered Handover Preparation.
eNB eNB 2. For re-establishment request directed to unprepared cell of other eNB or target eNB (in
case mobility based handover procedure is ongoing) this counter is updated if of
X2AP:HANDOVER REQUEST ACKNOWLEDGE message is sent after the
allocation of the UE context at the requesting eNB as a result of a successful RLF-
X2AP: HANDOVER REQUEST triggered Handover Preparation.
Admission Control Use case: The counter RCR_UE_CONTEXT_RETR_SUCC together with
X2AP: HANDOVER REQUEST ACKNOWLEDGE RCR_UE_CONTEXT_RETR_ATT may be used by KPI to control the ratio of
X2AP: UE CONTEXT RELEASE successful allocated UE Context in unprepared cell.
Proposed (new) = RCR_UE_CONTEXT_RETR_SUCC

×100%
35 © Nokia Solutions and Networks 2014 KPI#3 RCR_UE_CONTEXT_RETR_ATT
For internal use
Performance Aspects

RCR_UE_CONTEXT_RETR_FAIL_TI This measurement provides the number of failed UE Context Retrievals during RRC
M (M8027C5) Connection Reestablishment procedure. The UE Context Retrieval failure is caused by
M8027 LTE Handover - RLF Trigger the expiration of the corresponding guard timer.
Trigger event: The counter is updated at expiry of the T301 guard timer which
controls UE context retrieval procedure during RLF-triggered Handover. As a
Serving M8027C5 Other result the pending RRC Connection Reestablishment procedure fails.
eNB eNB
X2AP: RLF INDICATION T301 guard

expiry

For internal use
Performance Aspects
Feature monitoring
Feature impact How to measure?
Following feature related counters and proposed for KPIs:
them KPIs, are recommended to verify feature usage
in the field. As proposed in section New Counters
If any of these counters or KPIs is pegged (>0) it Counters:
means that feature is enabled. - HO_RLF_PREP_ATT (M8027C0)
- HO_RLF_PREP_SUCC (M8027C1)
- HO_RLF_SUCC (M8027C2)
- RCR_UE_CONTEXT_RETR_ATT (M8027C3)
- RCR_UE_CONTEXT_RETR_SUCC (M8027C4)
- RCR_UE_CONTEXT_RETR_FAIL_TIM (M8027C5)

For internal use
Performance Aspects
Feature impact
Increased number of MRO early/late HO Counters:
counters For Late HO case
Basically the use case of the RLF Triggered
Handover procedure is to avoid the call drop due to a - MRO_LATE_HO (M8021C20)
failed or missing handover procedure. - MRO_LATE_HO_NB (M8015C16)
The RLF triggered handover procedure is invoked in
case that the UE tries to re-establish a RRC For Early HO Type2 case
Connection in an unprepared cell. - MRO_EARLY_TYPE2_HO (M8021C22)
This may occur either due to a Late HO (missing HO
Command) or due to an Early HO Type2 (sequence - MRO_EARLY_TYPE2_HO_NB (M8015C18)
of a successful random access in HO target followed
by failed Msg3 reception (attempted HO not
completed) followed by re-establishment request in
another cell). Therefore counters listed in the next
column are also pegged in case RFL triggered
handover

For internal use
Performance Aspects
Feature impact
The legacy counters for Handover Preparation and Counters of measurement types:
Handover Execution and Completion phase are not - M8009: LTE Intra eNB Handover
be pegged in case of a RLF Triggered Handover in
order to avoid the corruption of Handover KPIs - M8014: LTE Inter eNB Handover
being used for mobility threshold optimization by - M8015: LTE Neighbor cell related handover
the iSON Manager.
Therefore all counters of the Measurement types - M8021: LTE Handover
listed in the next column will not be pegged.
This is valid for all counters except

MRO_LATE_HO (M8021C20),
MRO_LATE_HO_NB (M8015C16),
MRO_EARLY_TYPE2_HO (M8021C22),
MRO_EARLY_TYPE2_HO_NB (M8015C18)
mentioned on previous slide

For internal use
For internal use
Copyright and confidentiality
The contents of this document are proprietary and be used in Nokia Solutions and Networks products and implied warranties of merchantability and fitness for a
confidential property of Nokia Solutions and Networks. This related specifications or other documentation. Accordingly, particular purpose, are made in relation to the accuracy,
document is provided subject to confidentiality obligations if the user of this document gives Nokia Solutions and reliability or contents of this document. NOKIA
of the applicable agreement(s). Networks Feedback on the contents of this document, Nokia SOLUTIONS AND NETWORKS SHALL NOT BE
Solutions and Networks may freely use, disclose, reproduce, RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS
This document is intended for use of Nokia Solutions and license, distribute and otherwise commercialize the feedback DOCUMENT or for any loss of data or income or any
Networks customers and collaborators only for the purpose in any Nokia Solutions and Networks product, technology, special, incidental, consequential, indirect or direct damages
for which this document is submitted by Nokia Solution and service, specification or howsoever caused, that might arise from the use of this
Networks. No part of this document may be reproduced or other documentation. document or any contents of this document.
made available to the public or to any third party in any
form or means without the prior written permission of Nokia Nokia Solutions and Networks operates a policy of ongoing This document and the product(s) it describes are protected
Solutions and Networks. This document is to be used by development. Nokia Solutions and Networks reserves the by copyright according to the
properly trained professional personnel. Any use of the right to make changes and improvements to any of the applicable laws.
contents in this document is limited strictly to the use(s) products and/or services described in this document or
specifically created in the applicable agreement(s) under withdraw this document at any time without prior notice. Nokia is a registered trademark of Nokia Corporation. Other
which the document is submitted. The user of this document product and company names mentioned herein may be
may voluntarily provide suggestions, comments or other The contents of this document are provided "as is". Except trademarks or trade names of their respective owners.
feedback to Nokia Solutions and Networks in respect of the as required by applicable law, no warranties of any kind,
contents of this document ("Feedback"). Such Feedback may either express or implied, including, but not limited to, the © Nokia Solutions and Networks 2014

For internal use
Technical Details
UE eNB Unsuccessful case
Cell A Cell B • A RLF triggered Intra-eNB handover may be rejected

with valid UE Context by Admission Control
• If the Handover Preparation fails for any reason (AC is
the case), eNodeB shall stop processing the RLF
RLF, integrity check failure detected triggered Handover
• As result RRC Connection re-establishment procedure
is completed by sending
RRC:RRCConnectionReestablishmentReject message
from cell B towards the UE
related to serving Cell) rejected due to AC or other reasons
Admission Control
RRCConnectionReestablishmentReject (Msg4)
*Note: treat X2AP messages as internal ones,

because in fact intra-eNB HO from definition does
42 © Nokia Solutions and Networks 2014 not happen physically via X2 interface
For internal use
Technical Details
UE requested eNB serving eNB EPC
• Successful RCR to other eNB without

T301 ongoing procedure in serving eNB
RRC: RRCConnectionReestablishmentRequest
(UE-Identity)
• No T301 on UE side nor T301
guard on Other eNB (requested
T301guard (PCI, ECGI, C-RNTI, shortMAC-I) eNB) side expire
par
X2AP: SN STATUS TRANSFER
T301
MSC.881:Completion of successful RCR
MSC.581: X2-Handover Completion

For internal use
Technical Details
UE requested eNB failure eNB MME
• Unsuccessful RCR to other eNB

(UE-Identity)
with no answer from serving eNB
T301guard (PCI, ECGI, C-RNTI, shortMAC-I) • No X2AP: HANDOVER
REQUEST from Serving
opt
LTE1617 not configured
eNB(failure eNB) received by
OR Other eNB(requested eNB)
triggered HO impossible
within T301 guard
RRC: RRCConnectionReestablishmenReject no action

For internal use
Technical Details
• Unsuccessful RCR to other eNB

(UE-Identity) due to rejected HO preparation
phase
T301guard
(PCI, ECGI, C-RNTI, shortMAC-I)
• X2AP: HANDOVER
REQUEST is received by
X2AP: HANDOVER REQUEST Other eNB(requested eNB)
within T301 guard, however
opt
HO admission not passed
requested inter-eNB handover
is rejected by Admission
RRC: RRCConnectionReestablishmenReject X2AP: HANDOVER PREPARATION FAILURE
Control of Other
eNB(requested eNB)
no action

For internal use
Technical Details
T301 • Unsuccessful RCR to other eNB with timeout

(UE-Identity) of T301 in UE
X2AP: RLF INDICATION • UE does not receive
T301guard (PCI, ECGI, C-RNTI, shortMAC-I)
RRC:RRCConnectionReestablishment
X2AP: HANDOVER REQUEST within T301
• Despite of
TX2RELOCoverall
TX2RELOCexec X2AP: HANDOVER REQUEST ACKNOWLEDGE RRC:RRCConnectionReestablishment is
RRC_IDLE sent to the UE it is not received because
the is already in IDLE mode
par
X2AP: SN STATUS TRANSFER
TX2RELOCexec TMinLifeTimeOfHalfOpenRrcConnection
RRC: RRCConnectionReestablishment
MSC.1237: TMinLifeTimeOfHalfOpenRrcConnection expiry
MSC.590:Timer TX2RELOCoverall expiry

For internal use
Deployment
Aspects
Network graphic boxes Network element boxes
Table of contents

For internal use
Due to RSRQ based condition for cell selection process
Deployment Aspects interfered serving cell is not selected as target for re-
establishment; there is a chance that other cell will be
RSRQ based condition for cell selection process selected during this process
• UE in RRC-Connected mode with relative high RSRP may be interfered what is reflected by
low RSRQ
• If no RSRQ based mobility procedure (RSRQ based better cell inter-frequency handover or
RSRQ based redirection) is triggered, such radio conditions may lead to out-of-sync issue
• If out-of-sync is detected by the RRC Connection Re-establishment procedure is triggered
by the UE
UE Rel.9 and higher
• As a initial step cell selection is done by the UE – in this context it is reasonable to define
both RSRP and RSRQ conditions:
RSRP > qrxlemin(LNCEL) AND RSRQ > qQualMinR9(LNCEL, cellSelectionInfoV920) serving Cell is highly interfered,
- This way at cell selection stage we can avoid selection of highly interfered serving eNB/cell leading to out-of-sync issue
as target for re-establishment; otherwise, if only RSRP based threshold qrxlemin(LNCEL)
controls cell selection conditions it is highly probable that the call will be dropped Note: RSRQ based condition may be
configured from RL50/RL35TD supported by
- With RSRQ based condition another cell than the serving one may be selected; even with basic feature LTE1036 RSRQ based
lower RSRP but with RSRQ high enough to maintain the call reselection; the only requirement to use such
solution are UE terminals Rel.9 or higher

For internal use

06 LTE1617 RLF Triggered Handover

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

06 LTE1617 RLF Triggered Handover

Uploaded by

Copyright:

Available Formats

LTE1617 RLF triggered handover

Telefonica UK – RL70 workshop

1 © Nokia Solutions and Networks 2014

Introduction Technical Inter – Benefits and Performance

2 © Nokia Solutions and Networks 2014

3 © Nokia Solutions and Networks 2014

Connection Re-establishment Connection Re-establishment

prepared cell unprepared cell

initially unprepared cell due to functionality

• RRC Connection re-establishment is triggered upon detection of:

5 © Nokia Solutions and Networks 2014

3GPP 36.331, chapter 7.3 Timers (Informative)

PRACH Random Access Response (Msg2) Reception of

t311 (LNCEL), default value 3000ms

7 © Nokia Solutions and Networks 2014

UE initially served by cell A UE Context provided from cell A to cell B;

8 © Nokia Solutions and Networks 2014

9 © Nokia Solutions and Networks 2014

X2AP: HANDOVER REQUEST ACKNOWLEDGE*

RRCConnectionReestablishmentComplete (Msg5) *Note: treat X2AP messages as internal ones,

PRACH Random Access Response (Msg2)

*Note: treat X2AP messages as internal ones,

• Functionality defined by LTE1617-A does not need any additional parameter

• LTE1617-A is treated as an extension of basic feature LTE735 and available

• There is no dedicated feature activation flag for mechanism described by

12 © Nokia Solutions and Networks 2014

13 © Nokia Solutions and Networks 2014

UE Other neighbor eNB, Serving Other

(PCI=10, C-RNTI, shortMAC-I related to serving cell)

X2AP: RLF INDICATION

Cell A Cell B • X2AP: HANDOVER REQUEST message is

X2AP: UE CONTEXT RELEASE

15 © Nokia Solutions and Networks 2014

X2AP: RLF INDICATION RLF triggered Inter-eNB handover

16 © Nokia Solutions and Networks 2014

X2AP: UE CONTEXT RELEASE

17 © Nokia Solutions and Networks 2014

• Functionality defined by LTE1617-B is activated by feature flag

18 © Nokia Solutions and Networks 2014

19 © Nokia Solutions and Networks 2014

Cell A Cell C Cell B

UE initially served by cell A

Inter-eNB HO via X2 towards cell C ongoing

RLF, HO failure, mobility from E-UTRA failure, integrity check

Cell B selected during cell selection process acc. to 36.304

X2AP: RLF INDICATION

Inter-eNB HO via X2 cancellation

20 © Nokia Solutions and Networks 2014

21 © Nokia Solutions and Networks 2014

22 © Nokia Solutions and Networks 2014

23 © Nokia Solutions and Networks 2014

LTE735 RRC connection reestablishment:

24 © Nokia Solutions and Networks 2014

LTE53 Intra and inter eNB handover via X2:

25 © Nokia Solutions and Networks 2014

LTE872 SRVCC to WCDMA:

26 © Nokia Solutions and Networks 2014

Benefits and Gains

27 © Nokia Solutions and Networks 2014

28 © Nokia Solutions and Networks 2014

29 © Nokia Solutions and Networks 2014

30 © Nokia Solutions and Networks 2014

Counter name Description