LTE Quick Reference

Go Back To Index

Home : www.sharetechnot

Radio Link Failure (RLF)

To be honest I don't think I saw any clear/explicit definition of this term. My personal definition of Ra
"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 ?". Un
don't have any clear answer to this question either. So detailed detection implementation is up to UE
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 detec
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
subframe ?

No, it is not. In most case, this kind of problem should happen for a certain period of time consecutiv
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 eNod
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 ReEsta

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

For your understanding, the definition of Radio Link Failure is simply "Physical Layer
(especially low PHY) break" and in most case this failure is unintentional.
Firstly the question is "How UE or eNodeB can detect this kind of Radio Link Failure?"
you can refer to 3GPP TR 36.133 and TR 36.213, among the spec of TR 36.133
Requirements for support of radio resource management and chapter 7.6 Radio Link
Monitoring, the standards says,

The UE shall monitor the downlink link quality based on the cell-specific reference signal
in order to detect the downlink radio link quality of the PCell as specified in [3]. The UE
shall estimate the downlink radio link quality and compare it to the thresholds Qout and
Qin for the purpose of monitoring downlink radio link quality of the PCell.

Unfortunately, the detailed detection implementation is up to UE chipset maker and

eNodeB maker, but we can think of several guidelines.
UE may assume that Radio Link is broken in the following sections.

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 up to the chipset implementation.

eNodeB may assume that that Radio Link is broken in the following sections.

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.

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.

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.

Then the next question is "What UE does when it detects Radio Link Failure ?"
The most typical procedure is to go through RRC Connection Reestablishment
procedure.

As the above picture, RACH is used for recovering from radio link failure.
LTE RACH is used to achieve uplink time synchronization for a UE which either has not
yet acquired, or has lost, its uplink synchronization. Once uplink synchronization is
achieved for a UE, the eNodeB can schedule orthogonal uplink transmission resources
for it.
The LTE random access procedure comes in two forms, allowing access to be either
contention-based or contention-free.
A UE initiates a contention-based random access procedure for radio link failure. In this
procedure, a random access preamble signature is randomly chosen by the UE, with the
result that its possible for more than one UE simultaneously to transmit the same
signature,leading to a need for a subsequent contention resolution process.
for the use-cases, new downlink data and handover, the eNodeB has the option of
preventing contention occurring by allocating a dedicated signature to a UE, resulting in
contention-free access. This is faster than contention-based access a factor which is
particularly important for the case of handover, which is time-critical.

RLM, RLF and RRC re-establishment

Leave a reply

Radio Link Monitoring (RLM) is one of the important procedures in LTE. It is used to keep
track of the radio link condition so that appropriate steps can be taken if Radio Link
Failure (RLF) is declared. The figure below (taken from T-doc R2-133859) captures the
RLM process:

From the same T-doc:

PCell radio link monitoring is to determine whether the PCell radio link should be
considered as failed (i.e. radio link is worse than Qout for time period determined by
N310). If so, UE performs two actions; 1) stopping autonomous uplink transmission by
releasing SPS, CQI, SRS, SR and 2) starting cell selection procedure to find a cell
providing acceptable radio link.

There are several reasons why a session may drop in LTE. However, whether
the session is dropped or not depends on the particular vendor
implementation. That is, the drop may be caused by a UE message or by
measurements carried out by the eNodeB.
Both the UE and the eNodeB may check if the radio link is in-synch. In this
blog, we will describe the activities that the UE carries out to determine if
the radio link is in-synch and their consequences. Part 2 of this blog, will
present the activities that the eNodeB may carry out to determine if the radio
link is in-synch or not.
So. When is the Radio Link in-synch?
The UE is expected to monitor the RS in the downlink. Based on the signal
strength of the Reference Signals (i.e., the RSRP), the UE will determine if it
can decode the PDCCH based on a certain set of parameters that are
provided in the specs. Each UE will have a different RSRP threshold in which
it will assume it cannot read the PDCCH. If the Reference signals have
enough strength such that the UE can decode consistently the PDCCH, then
the link is In-Synch.
How do we determine if the Radio Link is out of Synch?
The full procedure for determining if the link has failed due to being out of
sync is shown in the figure below. In the picture, there are three parameters
shown:
n310: This parameter indicates the number of 200 ms intervals when the UE
is unable to successfully decode the PDCCH due to low RSRP detected. That
is, this parameter indicates the number of times in which the UE cannot
successfully decode 20 consecutive frames in the downlink.
t310: It is a timer, in seconds, used to allow the UE to get back in
synchronization with the eNodeB.
n311: This parameter indicates the number of 100 ms intervals that the UE
must successfully decode the PDCCH to be back in-synch with the eNodeB.
That is, this parameter indicates the number of times in which the UE must
successfully decode 10 consecutive frames in the downlink in order for the UE
to assume the radio link is in-synch.
If the UE detects n310 consecutive out-of-sync indications, it starts the t310
timer. If the timer expires, the link has failed. If the UE detects n311
consecutive in-sync indications prior to the t310 timer expiring, then the timer
is stopped and the link has not failed.

So what happens after the UE detects that the link failed?

If the UE determines that the Radio Link fails, the UE will try to reconnect with
an RRC Connection Reestablishment Request message. There are a number
of cases that could occur based on vendor implementation.
What if the eNodeB does not support RRC Connection
Reestablishment?
The case shown in the figure below is the simplest case where the eNB does
not support RRC Connection reestablishment. In this case, the eNB responds
with an RRC Connection Reestablishment Reject message. Simultaneously,
the eNB will realize that the radio link has failed and request the connection to
be release to the MME. It first requests to drop the UE Context or the
connection to the UE. The cause value is set to Radio Connection with UE
Lost. The MME will respond with a UE Context Release Command. At this
point, the eNodeB will respond with the UE Context Release Complete
message to the MME and will release the RRC connection with the UE by
sending an RRC Connection Release to the UE. Depending on the RF
conditions, the UE may or may not receive this message.

What if the eNodeB does support RRC Connection Reestablishment?

If the eNodeB supports RRC connection Reestablishment,
and assuming that the eNodeB finds both the UL and DL in synch when it
receives the RRC connection reestablishment request message, two
scenarios may occur: RRC connection reestablishment success and failure.
In the case of an RRC connection reestablishment success, the following
signaling is carried exchanged.

If the RRC connection gets successfully reestablished, then the session does
not get dropped.
If the RRC connection reestablishment procedure fails in one of its steps, then
the eNodeB will send the UE context release request message to the MME.
Note that the RRC connection reestablishment process may fail in several
steps. Below, in the figure, only one case is shown.

If the RRC connection reestablishment fails, then the session is dropped.

Yes, you are right!! But think in the consequences first!
If you increase the power of the RS, If you increase n310, if you increase t310
or if you decrease n311 to its minimum value, the then the number of drop
calls will decrease.

In the previous blog, we described the activities that the UE carries out to
evaluate the condition of the radio link to determine if it was in-synch or out of
synch. Depending on the vendors implementation, an out of synch indication
may result in a drop session.
In this blog, we will concentrate on the activities carried out by the eNodeB
when it detects that the radio link has failed.
The types of failure that the eNodeB may detect (again, these may be vendor
specific) are:
a) DL failure (RLC failures)
b) UL failure (Physical layer failure).

DL Failure at the RLC layer:

The RLC Layer has a failure when data or signaling that is sent over the air is
unsuccessful and the RLC Layer stops trying. When data is sent over the air,
but is received incorrectly, the receiver will send a NACK. Also, the transmitter
can send a request for an acknowledgement of all received packets, by
setting the poll bit. The receiver will then send a list of all received packets. If
a sent packet is not received, it is considered lost. In either case, the
transmitter will retransmit. See figure below.

This procedure can repeat, but at some point the transmitter will give up on

the packet. If that happens, the transmitter declares that the radio link has
failed and starts the procedures to communicate that to the other side.
The parameter MaxRetxThreshold determines the number of times a packet
is retransmitted at the RLC layer in the downlink. If this number is reached,
the eNodeB declares a DL RLC failure and kills the context as shown in the
picture below.

UL Failure at the Physical layer:

Not all vendor implementation support this type of failure detection. It
essentially consists in measuring the power of the sounding reference signals
(SRS) sent by the UE in the UL. If the power is below a given SINR threshold,
a timer gets started. If the SINR remains under the stated SINR threshold for
the entire duration of the timer, then the eNodeB declares the UL as out of
synch and proceeds to kill the context. If the SINR of the SRS goes above a
second specified threshold during the timer duration, the UL is said to be insynch and no actions are carried out.
Below, the actions carried out by eNodeB are shown when an UL Physical
Layer failure is detected.

Yes, you are right!!! But think about the consequences again!
Yes, increasing the value of maxretxthreshold may result in a decrease in the
number of drop sessions due to RLC DL failures.
However, to avoid a large number of drops, the best thing to do is to clean the
RF environment in your network.