Radio Link Failure in LTE

Triggering points of RLF

upon indication from RLC that the maximum number of re transmissions has been reached

upon expiry of Timer T310 (this timer is started when physical layer problems are detected i.e. upon receiving N310 consecutive out-of-sync indications
from lower layers)

upon random access problem indication from MAC while neither T300, T301, T304 nor T311 is running

Actions when RLF is detected

UE shall initiate RRC Connection Re-establishment procedure. (click here to know about the RRC CONNECTION RE-ESTABLISHMENT procedure in

detail)

if AS security has not been activated then inform upper layers about the release of RRC connection with release cause 'other'

In-sync Indications (N311) received:

1. UE will stop T310
2. UE maintains the RRC connection (no configurations are changed)
N311 is triggered when in-sync indications are received. Once when the condition of N311 is fulfilled, UE won't go for RLF. Upon expiry of this constant, UE will
UE maintains the entire radio resource configuration
Timers and constants used in RLF:

Transmission of
RRCConnectionReestabilshmentRequest
Upon detecting physical layer problems i.e.
upon receiving N310 consecutive out-ofT310
sync indications from lower layers
Upon initiating the RRC connection reT311
establishment procedure
Maximum number of consecutive "out-ofN310 (constant) sync" indications received from lower
layers
Maximum number of consecutive "in-sync"
N311 (constant)
indications received from lower layers
T301

LTE Quick Reference

Go Back To Index

Home : www.sharetechnote.com

Radio Link Failure (RLF)

To be honest I don't think I saw any clear/explicit definition of this term. My personal definition of Radio Link Failure
is "Physical Layer(especially low PHY) break" and in most case this failure is unintentional.
When UE Report RLF ?
Then the next question would be "How UE or eNodeB can detect this kind of Radio Link Failure ?". Unfortunately we
don't have any clear answer to this question either. So detailed detection implementation is up to UE maker and
eNodeB maker, but we can think of several guidelines.
UE may assume that Radio Link is broken in the following setuation.
The measured RSRP is too low (under a certain limit)
It failed to decode PDCCH due to power signal quality (e.g, low RSRP, RSRQ)
It failed to decode PDSCH due to power signal quality (e.g, low RSRP, RSRQ)
However, detailed mechanism to RLF is upto the chipset implementation. So the individual RLF detection mechanism
may vary chipset-to-chipset.
eNodeB may assume that that Radio Link is broken in the following setuation.
SRS Power (SINR) from UE is much lower than what eNB configured for the UE
eNodeB couldn't detect (see) any NACK nor ACK from UE for PDSCH.
Does UE or eNodeB declare "Radio link Failure" whenever it sees the problem described above, even for only one
subframe ?
No, it is not. In most case, this kind of problem should happen for a certain period of time consecutively and a couple
of timers and parameters are involved in the criteria setup. (See T311, n310)

What UE tries to do when RLF Happens ?

Then the next question would be "What UE does when it detects Radio Link Failure ?" or "What eNodeB does when it
detects Radio Link Failure ?".
The most typical procedure is to go through RRC Connection Restablishement procedure.
< Attemp to recover Radio Link while Out of SYNC (Radio Link Failure) - RRC Connection ReEstablishment >

< When UL Data arrives from higher layer while Out of SYNC (Radio Link Failure) >

T310

Note 1 : one "Out of Sync Indication" in this diagram means "20 subframes of consecutive PDCCH decoding failure.
Note 2 : one "In Sync Indication" in this diagram means "10 subframes of consecutive PDCCH decoding success.

LTE Quick Reference

Go Back To Index

Home : www.sharetechnote.com

RRC Connection ReEstablishment

< What is this >
It is a kind of mechanism to make a recovery when radio link got broken for some reason. (See "When it
happens"section for these reason)

< How it work >

it works in three steps as shown below (refer to 36.331 5.3.7 RRC connection re-establishment for the details)
i) UE --> NW : RRCConnectionReestablishmentRequest
ii) UE <-- NW : RRCConnectionReestablishment
iii) UE --> NW : RRCConnectionReestablishmentComplete
I think most of those who read this page may be pretty familiar with LTE protocol, so just by looking at the contents
of these RRC messages, they would figure out a lot of details without much explanation.
RRCConnectionReestablishmentRequest
c1: rrcConnectionReestablishmentRequest (0)
rrcConnectionReestablishmentRequest
criticalExtensions: rrcConnectionReestablishmentRequest-r8 (0)
rrcConnectionReestablishmentRequest-r8
ue-Identity
c-RNTI: 0000 [bit length 16, 0000 0000 0000 0000 decimal value 0]
physCellId: 0
shortMAC-I: 0000 [bit length 16, 0000 0000 0000 0000 decimal value 0]
reestablishmentCause: reconfigurationFailure /handoverFailure/otherFailure/ spare1
spare: 00 [bit length 2, 6 LSB pad bits, 00.. .... decimal value 0]

RRCConnectionReestablishment (An example based on 36.508 - RRCConnectionReestablishment)

c1: rrcConnectionReestablishment (0)

rrcConnectionReestablishment
rrc-TransactionIdentifier: 0
criticalExtensions: c1 (0)
c1: rrcConnectionReestablishment-r8 (0)
rrcConnectionReestablishment-r8
radioResourceConfigDedicated
srb-ToAddModList: 1 item
Item 0
SRB-ToAddMod
srb-Identity: 1
rlc-Config: defaultValue (1)
defaultValue: NULL
logicalChannelConfig: defaultValue (1)
defaultValue: NULL
mac-MainConfig: explicitValue (0)
explicitValue
ul-SCH-Config
maxHARQ-Tx: n5 (4)
periodicBSR-Timer: sf20 (3)
retxBSR-Timer: sf320 (0)
..0. .... ttiBundling: False
drx-Config: release (0)
release: NULL
timeAlignmentTimerDedicated: sf750 (1)
phr-Config: setup (1)
setup
periodicPHR-Timer: sf500 (5)
prohibitPHR-Timer: sf200 (5)
dl-PathlossChange: dB3 (1)
physicalConfigDedicated
pdsch-ConfigDedicated
p-a: dB-3 (2)
pucch-ConfigDedicated
ackNackRepetition: release (0)
release: NULL
pusch-ConfigDedicated
betaOffset-ACK-Index: 9
betaOffset-RI-Index: 6
betaOffset-CQI-Index: 6
uplinkPowerControlDedicated
p0-UE-PUSCH: 0dB
deltaMCS-Enabled: en0 (0)
..1. .... accumulationEnabled: True
p0-UE-PUCCH: 0dB
pSRS-Offset: 3
filterCoefficient: fc4 (4)
cqi-ReportConfig
cqi-ReportModeAperiodic: rm30 (3)
nomPDSCH-RS-EPRE-Offset: 0dB (0)
soundingRS-UL-ConfigDedicated: setup (1)
setup
srs-Bandwidth: bw0 (0)
srs-HoppingBandwidth: hbw0 (0)
freqDomainPosition: 0
..1. .... = duration: indefinite
srs-ConfigIndex: 20
transmissionComb: 0
cyclicShift: cs0 (0)
antennaInfo: explicitValue (0)
explicitValue
transmissionMode: tm3 (2)
codebookSubsetRestriction: n2TxAntenna-tm3 (0)
n2TxAntenna-tm3: c0 [bit length 2, 6 LSB pad bits, 11.. .... decimal value 3]
ue-TransmitAntennaSelection: release (0)
release: NULL
schedulingRequestConfig: setup (1)
setup
sr-PUCCH-ResourceIndex: 60
sr-ConfigIndex: 30
dsr-TransMax: n4 (0)
nextHopChainingCount: 0

HEX string : 00 12 9B 3E 86 03 B5 79 E8 96 6C 30 64 99 80 20 A0 28 68 3C 1E 00

< When it happens >

There are several cases where this process get triggered. According to 36.331 5.3.7.2, there are several cases as
described below.
Case 1 : When radio link failure happened
Case 2 : when Handover failure happened
Case 3 : when mobility from E-UTRA failure happened
According to 36.331 5.4.3.5 Mobility from E-UTRA failure,
revert back to the configuration used in the source PCell, excluding the configuration configured
by the physicalConfigDedicated, mac-MainConfig and sps-Config;
initiate the connection re-establishment procedure as described in How it works and Common
UE side Process
Case 4 : when integrity check failure indication was received from lower layers
Case 5 : when RRC connection reconfiguration failure happened
< Common UE side Process >
Whatever the case is, overall process on UE side is similar as follows. (36.331 5.3.7.5)
i) stop timer T301
ii) consider the current cell to be the PCell
iii) re-establish PDCP for SRB1
iv) re-establish RLC for SRB1
v) perform the radio resource configuration procedure in accordance with the
receivedradioResourceConfigDedicated
vi) resume SRB1