Radio Link Failure (RLF)

Radio Link Failure (RLF) in LTE occurs when the quality of the connection between the User Equipment (UE) and the network degrades beyond recovery. This node will describe how the UE detects and manages physical layer problems in RRC_CONNECTED and the subsequent RLF.

Let's follow one failure from start to end. First the UE decides that the link is lost. Then it tries to recover the connection, and it keeps a record of what happened. Finally the network collects that record and uses it to tune its handover parameters. The sections below follow the same order.

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)

The out-of-sync indication itself has a precise definition in 36.133 clause 7.6. Layer 1 measures the downlink quality on the cell-specific reference signal and compares it with two thresholds. Qout is the level at which a hypothetical PDCCH, DCI format 1A, would have a 10% block error rate. Qin is the level at which a hypothetical PDCCH with DCI format 1C would have a 2% block error rate. Without DRX, layer 1 evaluates Qout over the last 200 ms and Qin over the last 100 ms. Two successive indications are at least 10 ms apart. So the PDCCH decoding failure in the list above is a hypothetical one, and the UE does not need a real PDCCH to fail. The same clause also requires the UE to turn off its transmitter within 40 ms after T310 expires.

Conditions for Declaring RLF

Out-of-sync indications and timers only measure the link. RRC still needs a rule that turns a weak link into a formal failure, and 36.331 gives a closed list of events for it. Every event in the list below ends in the same state, RLF detected for the MCG, and the UE then starts its recovery.

The UE declares RLF under the following circumstances (as per 5.3.11.3 of 3GPP TS 36.331):

T310 Expiry:

After N310 consecutive "out-of-sync" indications and the subsequent expiry of T310, the UE declares RLF.

T312 or T318 Expiry:

If T312 (started by a triggered measurement report while T310 is running) or T318 (NTN, started when the UE begins to acquire SystemInformationBlockType31) expires.

Random Access Problem:

The UE experiences a random access problem while no higher-layer timers (e.g., T300, T301, T304, or T311) are running.

Maximum Retransmissions Reached:

The MAC or RLC layer indicates that the maximum number of retransmissions for an SRB or DRB has been reached.

T312 and T318 need a word of explanation, based on 36.331 v19.3.0. T312 is not an SCG timer. The UE starts T312 when a measurement report is triggered for a measurement identity with useT312 set to true, while T310 is already running. This makes T312 a shorter version of T310, and the UE can give up early when a handover is clearly needed. T318 is not a DAPS timer either. It belongs to NTN, and RLF is declared when T318 expires before SIB31 is acquired. The current release also adds one more trigger, reaching t-Service when t-Service is broadcast.

Reporting Conditions

Declaring RLF and reporting it are two separate events. The UE stores the failure first, in the UE variable VarRLF-Report. It can report the failure only after it has a working connection again. The list below gives the conditions, and the section on the RLF report later on this page gives the exact message sequence.

The UE only reports RLF when:

Re-establishment Succeeds:

If the UE successfully re-establishes its connection, the RLF report is sent to the network.

The UE Returns to the Same Network:

The RLF report is sent if the UE connects to the same PLMN or its equivalent PLMNs after the failure.

If the UE cannot re-establish a connection:

The RLF report is not sent, as there is no signaling interface to communicate with the network.

In the last case, "not sent" means "not sent yet". The UE keeps VarRLF-Report for up to 48 hours. If it later sets up a new connection in a PLMN from the stored plmn-IdentityList, it indicates rlf-InfoAvailable in RRCConnectionSetupComplete, and the network can still collect the report.

Example Reporting Scenarios

The three scenarios below differ in where the failure happens and in which message carries the news. In the first two, the MCG fails, so the report can travel only after re-establishment. In the third, only the SCG fails. The MCG stays up, and the UE reports the failure at once.

Normal Operation: The UE experiences poor signal quality, declares RLF, and re-establishes the connection. It sends the RLF report to inform the network about the issue.
Handover Failure: The UE fails to connect to the target cell during a handover, declares RLF, and provides the report during re-establishment.
Dual Connectivity: If SCG RLF occurs, the UE sends an SCG-specific failure report to assist in improving the network configuration.

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 ?".

When Radio Link Failure (RLF) occurs, the User Equipment (UE) initiates specific recovery and fallback actions to restore or maintain service continuity. The actions depend on the scenario (e.g., idle mode, connected mode, handover, or multi-connectivity)

Connection Re-Establishment Attempt

The most typical procedure is to go through RRC Connection Restablishement procedure. The UE tries to reconnect to the network by initiating the RRC Connection Re-Establishment Procedure:

Triggering Re-Establishment:

The UE sends an RRCConnectionReestablishmentRequest message to the network.
This message is sent to:

The last serving cell if it is still accessible.
A neighboring cell that supports the same PLMN (if the serving cell is not accessible).

Wait for Response:

If the target cell accepts the request, the network sends an RRCConnectionReestablishment message.
The UE applies the reconfiguration and resumes the connection.

Successful Re-Establishment:

The UE resumes its previous radio bearers.
It indicates that an RLF report is available (rlf-InfoAvailable) in the RRCConnectionReestablishmentComplete message.

Two details in this list need a closer look. First, the UE does not choose between the last serving cell and a neighbour cell by itself. It starts T311 and runs ordinary cell selection, and it sends the request to the suitable E-UTRA cell it finds. The request succeeds only if that cell is prepared, which means that the cell holds a valid UE context. Second, the RRCConnectionReestablishment message resumes SRB1 only. The other radio bearers stay suspended until the eNB sends the next RRCConnectionReconfiguration.

< Attemp to recover Radio Link while Out of SYNC (Radio Link Failure) - RRC Connection ReEstablishment >

RRC connection re-establishment over the RACH procedure while out of sync, msg1 to msg5

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

RACH procedure triggered by uplink data arrival while out of sync, msg3 with C-RNTI

In the re-establishment flow, msg3 on PUSCH carries RRCConnectionReestablishmentRequest, and msg4 on PDSCH carries RRCConnectionReestablishment. Finally, msg5 carries RRCConnectionReestablishmentComplete, and the UE is back in sync.
In the UL data arrival flow, msg3 carries the C-RNTI of the UE, and msg4 is a PDCCH with DCI 0 addressed to that C-RNTI. No RRC message is exchanged, because the RRC connection still exists.
So "Out of SYNC" in the UL data arrival flow means lost uplink timing alignment, not RLF. The UE only has to regain its timing advance, and a failure of that random access would be one of the RLF triggers listed earlier.

Initiating Connection Establishment - if Re-Establishment Fails

Re-establishment has its own timers, and they decide when the UE gives up. T311 limits the search for a suitable cell, and T301 limits the wait for the answer of the eNB. When either timer expires, or the eNB answers with RRCConnectionReestablishmentReject, the UE leaves RRC_CONNECTED with release cause "RRC connection failure".

If re-establishment fails (e.g., the target cell rejects the request or the UE cannot find a suitable cell), the UE:

Moves to the RRC_IDLE state.

Initiates a full RRC Connection Establishment Procedure with a new cell:

Performs cell selection or reselection.
Sends an RRCConnectionRequest to the selected cell.

Handling in Handover Scenarios

A handover failure is not an RLF in the sense of 36.331 clause 5.3.11.3, but the UE handles it in almost the same way. T304 starts when the UE receives the handover command, and T304 expiry is the handover failure. The UE stores the failure in the same VarRLF-Report, with connectionFailureType set to hof instead of rlf.

In the case of a handover, the UE:

Reverts to the source cell configuration if the target cell cannot be accessed (e.g., T304 expiry).
Initiates connection re-establishment on the cell that cell selection finds. This can be the source cell, but it does not have to be.

The revert is not complete. When attemptCondReconf is not configured, the UE keeps the source PCell configuration except physicalConfigDedicated, mac-MainConfig and sps-Config. For those three, re-establishment then applies the default configurations. With a DAPS bearer, the rule changes again. If the source link has not failed, the UE simply falls back to the source PCell and reports a DAPS handover failure, without re-establishment.

Handling in Multi-Connectivity - EN-DC, NE-DC

With dual connectivity the UE monitors two links, the PCell of the MCG and the PSCell of the SCG. A failure of the SCG alone does not need re-establishment, because the MCG still carries SRB1. T313 is the SCG timer of LTE DC. In (NG)EN-DC the SCG is an NR cell group, and 38.331 detects its RLF with the NR procedure instead.

If dual connectivity is configured:

SCG Failure (Secondary Cell Group):

If RLF is detected on the SCG (e.g., T313 expiry):

The UE reports SCG failure using the SCGFailureInformation message.
It continues communication over the MCG (Master Cell Group).

MCG Failure:

If RLF is detected on the MCG, the UE initiates re-establishment.

Since Release 16, an MCG failure can also avoid re-establishment. In (NG)EN-DC with T316 configured, and with the SCG active, the UE sends MCGFailureInformation over the SCG and starts T316. The network can then move the UE with a handover or a release. The UE falls back to re-establishment only when T316 expires.

Information Retention and Reporting

The stored record is what makes an RLF useful to the network after the fact. The UE keeps it in VarRLF-Report, and the list below gives its main contents. The UE may discard the record 48 hours after the failure, upon power off or upon detach. That is why the list also talks about retention.

If RLF occurs:

The UE stores the following information in VarRLF-Report:

Global cell ID of the failed cell.
Measurements (RSRP, RSRQ) of the failed cell and neighboring cells.
Timing information about the failure.

This information is retained for 48 hours or until:

The UE powers off.
The UE detaches from the network.
The UE switches to another RAT (for NB-IoT).

Actions Upon Reconnection

Reconnection here means a successful re-establishment, not a new RRC connection from RRC_IDLE. The difference matters for the bearers. After re-establishment only SRB1 runs at first, and the other bearers wait for the next RRCConnectionReconfiguration.

When the UE successfully reconnects after RLF:

It resumes any ongoing data or signaling sessions.
It reports the RLF to the network (if the connection is re-established within the same PLMN).
It may receive updated configurations to improve link stability

Fallback Scenarios

Fallback is the last branch of the procedure. When re-establishment fails, the RRC connection is gone, and the UE continues in RRC_IDLE like any other idle UE. Upper layers then decide whether the UE needs a new connection.

If the UE fails to re-establish the connection:

It falls back to RRC_IDLE state.
It may perform cell reselection to find a new suitable cell.
For specific services (e.g., emergency calls), the UE may attempt access on a different RAT (e.g., GERAN, UTRAN).

How does the network get the RLF report ?

The UE detects the failure, but the network has to remove its cause. A coverage hole or a handover threshold that is set too late keeps producing the same failure. So the network wants the record of the UE, and 36.331 defines a fixed exchange to collect it.

The report never travels on its own. First the UE announces that it has one. It sets rlf-InfoAvailable in RRCConnectionReestablishmentComplete, RRCConnectionSetupComplete or RRCConnectionReconfigurationComplete. It does this only when the current RPLMN is in the plmn-IdentityList stored with the report. Then the eNB decides whether it wants the report. If it does, it sends UEInformationRequest with rlf-ReportReq set to true. The UE answers with UEInformationResponse, which carries rlf-Report. Figure 1 shows the three steps.

Figure 1. Retrieval of the RLF report. The UE only flags that a report exists, and the eNB pulls the report when it wants it.

The report describes the failure from the side of the UE. The main fields of RLF-Report-r9 in 36.331 v19.3.0 are listed below.

measResultLastServCell-r9 : RSRP and, if available, RSRQ of the PCell, based on measurements up to the moment of the failure.
measResultNeighCells-r9 : the best measured neighbour cells, per RAT, with the best cell first.
failedPCellId-r10 : the global cell identity of the cell where the failure was detected. When the CGI is not available, the UE gives the PCI and the carrier frequency instead.
connectionFailureType-r10 : rlf or hof. One report format covers both radio link failure and handover failure.
previousPCellId-r10 and timeConnFailure-r10 : the cell that sent the last handover command, and the time from that command to the failure. The time is counted in steps of 100 ms, and 1023 means 102.3 s or longer.
rlf-Cause-r11 : t310-Expiry, randomAccessProblem, rlc-MaxNumRetx or t312-Expiry-r12.
reestablishmentCellId-r10 : the global cell identity of the cell the UE selected for re-establishment.

The eNB uses these fields for Mobility Robustness Optimisation, described in 36.300 clause 22.4.2. Each failure falls into one of three cases. A Too Late Handover is an RLF after the UE has stayed in the cell for a long time, followed by re-establishment in a different cell. A Too Early Handover is an RLF shortly after a successful handover, or a handover failure, followed by re-establishment in the source cell. A Handover to Wrong Cell is the same early failure, followed by re-establishment in a third cell. The field timeConnFailure separates "shortly after" from "a long time", and the cell identities show which cells were involved.

RLF is the result of a timer, not of one bad subframe : layer 1 reports out-of-sync against a 10% hypothetical PDCCH BLER. RRC declares RLF only after N310 indications and T310 expiry, or after another listed trigger.
Re-establishment needs a prepared cell : the UE selects any suitable cell, and the request succeeds only where the network holds the UE context.
The network pulls the report : the UE only flags rlf-InfoAvailable, and the eNB fetches the report with UEInformationRequest.
One report covers RLF and handover failure : connectionFailureType separates rlf from hof, and timeConnFailure places the failure relative to the last handover.

Reference

36.331 : 3GPP - E-UTRA Radio Resource Control (RRC); Protocol specification, v19.3.0. Clauses 5.3.5.6, 5.3.7, 5.3.11, 5.6.5, the RLF-Report-r9 IE and Table 7.3-1.
36.133 : 3GPP - E-UTRA Requirements for support of radio resource management, v19.5.0. Clause 7.6, Radio Link Monitoring.
36.300 : 3GPP - E-UTRA and E-UTRAN Overall description; Stage 2, v19.2.0. Clause 22.4.2, Support for Mobility Robustness Optimisation.