Radio Link Monitoring & Radio Link Failure in LTE 4G

Introduction

Radio Link Monitoring and Radio Link Failure are the survival instinct of a connected LTE UE. While in RRC_CONNECTED, the UE never stops asking one question about its serving cell: "can I still reliably hear this cell's control channel?" RLM is the physical-layer machinery that answers it; RLF is the RRC-layer decision to act when the answer is a sustained "no".

This matters because the radio link is the foundation everything else stands on. If the UE cannot decode PDCCH, it cannot receive scheduling grants, cannot send measurement reports, and often cannot even be handed over — the very report that would rescue it fails to get through. Without a bounded failure-detection mechanism, a UE could cling to a dead cell indefinitely, burning power and dropping data. RLM/RLF give the connection a clean, time-bounded way to notice the link has died and either repair it quickly (re-establishment) or fall back cleanly to idle.

The whole design is a two-layer, counter-then-timer state machine, and that structure is exactly what makes it debuggable. Physical layer emits discrete in-sync/out-of-sync events; RRC counts them with N310/N311 and races them against T310/T311/T301 (and the mobility timer T304). Knowing which counter or timer fired tells you immediately whether you are looking at a quality problem, an access problem, or a mobility problem.

Why RLM/RLF is needed

Concretely, RLM/RLF solve three problems at once. First, detection: the UE must notice degradation even in slots where it is not scheduled, which is why it monitors an always-on reference signal rather than actual traffic. Second, debouncing: momentary fades are normal, so the mechanism must distinguish a transient dip from a genuine failure — that is the job of the consecutive-event counters and the recovery timer. Third, bounded recovery: once failure is real, the UE must not thrash indefinitely, so a strict timer budget governs how long it may search for a cell and wait for a re-establishment answer before dropping to idle. The payoff is that a dropped connection becomes a predictable, well-timed event instead of an open-ended hang.

What RLM and RLF Are

While in RRC_CONNECTED, the UE continuously estimates how good the downlink of its serving cell is. If it stays good enough, nothing happens and you never hear about RLM. If quality degrades past a threshold and stays bad, the UE eventually declares that the radio link has failed and switches into a bounded recovery mode — trying to re-establish the connection on the best cell it can find, and only dropping to idle if that fails too.

Keep two layers cleanly separated in your head throughout this page. The physical layer only ever answers one question — "is the link good enough right now, yes or no?" — and it answers it as a stream of in-sync / out-of-sync events. The RRC layer is the decision maker: it counts those events, runs a set of timers, and decides whether a bad patch is a transient fade or a genuine Radio Link Failure that warrants tearing down and rebuilding the connection.

Radio Link Monitoring on the CRS

In LTE the reference for link quality is the cell-specific reference signal (CRS) — the always-on pilot symbols the cell radiates across its whole band, independent of whether the UE is being scheduled. The UE's physical layer measures the CRS and, from that measurement, estimates a hypothetical PDCCH block error rate: "if the cell had sent me a control channel right now, how likely am I to have failed to decode it?"

It is called hypothetical because the UE does not need an actual PDCCH transmission to run the check — it derives the estimate purely from reference-signal quality. This is deliberate: the UE must be able to judge the link even in slots where it is not scheduled, and the CRS is always there to measure. The choice of PDCCH as the yardstick is also deliberate: if you cannot reliably receive the control channel, you cannot receive scheduling grants, so the link is effectively useless regardless of how the data channel might have fared.

That estimated BLER is compared against two levels defined in TS 36.133:

The two thresholds are deliberately different (2% versus 10%). That gap is hysteresis: the link must genuinely recover to a good level before an in-sync is issued, so the UE does not flap between states on marginal, noisy conditions where the estimate hovers right at one threshold. PHY evaluates these estimates over defined monitoring periods (TS 36.133 specifies the evaluation windows) and passes only the resulting discrete in-sync / out-of-sync indications up to RRC. Crucially, RRC never sees the raw BLER number — it only ever sees the discrete events, one at a time.

The Counters and Timers

Everything RRC does with the in-sync/out-of-sync stream comes down to two counters and a small family of timers, all set per-UE by the network in the ue-TimersAndConstants IE (broadcast in SIB2 and/or given in dedicated signalling). The spec enumerates the allowed values rather than fixing a single number, so treat every figure below as an illustrative operator choice, not a constant.

Notice the shape of the design. N310 and N311 are counters of consecutive events — a lone out-of-sync followed by an in-sync resets the out-of-sync count to zero, so the counter only advances during a sustained bad patch. The timers, by contrast, bound how long the UE is willing to wait in each state before it moves on. Together the counter-then-timer pattern makes RLF a decision about a persistent problem measured over time, not a reaction to one bad measurement.

First Phase — Detecting the Problem

RRC does not panic on a single out-of-sync — momentary fades are completely normal as the UE moves through the environment. The first phase is entirely about deciding whether a bad patch is a real, sustained failure or just a transient dip, and it is driven by N310, T310 and N311.

Accumulate out-of-sync. Each time PHY reports out-of-sync, RRC increments an internal counter. When that counter reaches N310 consecutive out-of-sync indications, RRC starts the timer T310. Reaching N310 is the point at which RRC first admits "this might be real."

Recovery cancels it. While T310 is running, the UE keeps monitoring. If PHY starts reporting in-sync again and RRC counts N311 consecutive in-sync indications, it stops T310 immediately. The link is judged recovered, no failure is declared, and the connection continues exactly as before — the whole episode is invisible to the layers above RRC. Because N311 is typically small (often n1), recovery is quick to recognise once the link genuinely improves.

Expiry means failure. If T310 instead runs all the way to expiry without N311 in-syncs arriving, the UE declares Radio Link Failure. This is the classic, quality-driven path into RLF. Declaring RLF ends the first phase and begins the second.

Second Phase — Recovery or Idle

Declaring RLF does not immediately drop the UE to idle. The moment RLF is declared, the UE starts the timer T311 and stays in RRC_CONNECTED, giving itself a bounded window to rescue the connection rather than tearing everything down. This second phase is where re-establishment happens.

Cell selection under T311. During T311 the UE performs cell selection — searching for a suitable cell, which may be the original cell recovered, a neighbour on the same frequency, or a cell on another frequency or even another RAT. If T311 expires before any suitable cell is found, the UE gives up and goes to RRC_IDLE. From idle it must run the normal connection-setup procedure from scratch to get service again, so this outcome is the "connection lost" case.

Re-establishment under T301. If a suitable cell is found while T311 is still running, the UE stops T311, starts T301, and sends an RRCConnectionReestablishmentRequest on that cell. This message identifies the UE by its previous C-RNTI, the physical cell identity (PCI) of the cell it was on, and a shortMAC-I — a short authentication token that lets the target cell verify the UE is who it claims to be, because the security context is carried over. T301 now bounds the wait for a response:

• If the network accepts, it replies with RRCConnectionReestablishment; the UE stops T301, rebuilds SRB1 and its context, and continues in RRC_CONNECTED (typically followed by an RRCConnectionReconfiguration to restore the data radio bearers).
• If the network rejects with RRCConnectionReestablishmentReject, or if T301 expires with no valid response, the UE goes to RRC_IDLE.

Reading the RLF sequence in the logs

An RLF trace reads as a timeline of PHY indications and RRC timer events. The signature is a run of out-of-sync up to N310, T310 starting, and then either an N311 recovery or a T310 expiry that declares RLF and starts T311.

Representative UE log (quality-driven RLF → recovery) — illustrative, values vary by vendor/build:

T304 and Other Ways RLF Is Triggered

An expiring T310 is the classic, quality-driven path to RLF, but it is not the only one. RRC also declares radio link failure on failures reported from lower layers, and there is a related mobility timer, T304, whose expiry produces a very similar outcome.

Handover failure and T304. When the network hands the UE over, it sends an RRCConnectionReconfiguration that contains mobilityControlInfo (the handover command). On receiving it, the UE starts T304 and attempts to access the target cell via random access. If the UE completes the handover in time, it stops T304. If T304 expires before the handover succeeds, the UE declares a handover failure — and its response is to fall back to the same recovery machinery as RLF: it starts T311, performs cell selection, and attempts re-establishment. So T304 guards mobility the way T310 guards link quality; both funnel into the second phase.

The first three (T310 expiry, RACH problem, RLC max re-tx) are the three radio link failure causes proper — different symptoms (bad downlink, no uplink access, undeliverable data) of the same underlying condition: the link is no longer usable. T304 expiry is technically a handover failure rather than an RLF, but from the UE's point of view the reaction is identical: start T311 and try to re-establish. In all four cases, if re-establishment ultimately fails, the UE ends up in RRC_IDLE.

The RLF Report — Logging for Optimization

A radio link failure is not just handled and forgotten — it is logged. When the UE recovers (re-establishes, or reconnects after going idle), it holds a record of the failure and makes it available to the network, so operators can tell why the link broke and tune the network to prevent it happening again. This is part of Minimization of Drive Tests (MDT) and self-organizing-network (SON) mobility optimization.

The record is the rlf-Report (and its variants across releases, e.g. the connection-establishment-failure report). The UE sets an availability indicator, and the network retrieves the log by sending a UEInformationRequest with rlf-ReportReq set; the UE answers in a UEInformationResponse carrying the rlf-Report. Typical contents include:

• Measurement results around the failure — serving-cell and neighbour-cell RSRP/RSRQ, so the network sees whether a better neighbour existed.
• The identity of the cell where RLF occurred (the PCI / cell global identity) and the cell where re-establishment was attempted.
• The failure cause (t310-Expiry, random-access problem, RLC max re-transmission, or handover failure) and timing information such as how long the connection had lasted.
• Location information, where available, to place the failure geographically.

The optimization value is concrete. If many UEs report RLF on the same cell edge just before a neighbour became strong, the failure is a too-late handover — the operator lowers the handover threshold or trigger time. If failures cluster right after a handover into a cell, it may be a too-early or wrong-cell handover instead. The rlf-Report is what turns a single UE's bad experience into a network-wide tuning signal.

LTE ↔ NR

NR keeps the same two-phase RLM/RLF machinery but changes what the UE monitors and adds a beam-level layer beneath it.

Summary

RLM/RLF is a two-layer, counter-then-timer machine, and the fastest way to root-cause a drop is to walk it in order. PHY judges quality vs threshold on the always-on CRS (Qout ~10%, Qin ~2% hypothetical PDCCH BLER) and emits discrete in-sync/out-of-sync events. RRC turns those into a decision: N310 consecutive out-of-syncs start T310; N311 in-syncs cancel it (recovery), otherwise T310 expiry declares RLF. The second phase gives bounded recovery — T311 for cell selection, then T301 for the re-establishment answer — and if either expires or the cell rejects, the UE drops to RRC_IDLE.

Not all RLF is quality-driven: a MAC RACH problem, an RLC maxRetxThreshold, or a T304 handover-timer expiry all funnel into the same recovery phase. So the single most useful field in any drop trace is the RLF cause — it tells you whether to look at PHY coverage, MAC access, RLC delivery, or mobility. And when the link does break, the rlf-Report turns that one failure into a tuning signal (too-late / too-early / wrong-cell handover) for the whole network.