🗂️ RRC — Radio Resource ControlAdvanced

Radio Link Monitoring & Radio Link Failure in 5G NR

How the UE watches the link (in-sync / out-of-sync on RLM-RS), the N310/T310/N311 counters, what declares Radio Link Failure, and the T311 re-establishment that follows.

📚 3GPP-basedTS 38.331TS 38.213

Everything else in NR assumes the UE can hear PDCCH. Scheduling, HARQ feedback, timing advance maintenance, measurement reporting and handover commands all arrive as PDCCH-scheduled downlink. If that assumption quietly stops being true, a UE will sit there behaving perfectly and receiving nothing, while the network schedules into a void. Radio link monitoring exists to put a bound on how long that state can persist before the UE takes matters into its own hands.

Contents

01What Radio Link Monitoring Is For, and Where It Runs
02The RLM Reference Signals
03Qin, Qout, and the Hypothetical PDCCH
04Out-of-Sync and In-Sync Indications, and Their Evaluation Periods
05The N310 / T310 / N311 Machine
06The Other Ways RLF Is Declared
07What Happens the Instant RLF Is Declared
08T311: Cell Selection With a Context in Hand
09RRCReestablishmentRequest: the 48 Bits That Do the Work
10T301, and the Two Ways the Network Can Answer
11The RLF Report
12SCG Failure and MCG Failure: the Dual-Connectivity Variants
13RLF Versus Handover Failure
14Timers, Counters and Parameter Reference
15Failure Modes and What Each One Means
16Configuration Reference (ASN.1)
17Illustrative Message Traces
18Release Deltas: Rel-15 to Rel-18
19Reading RLM and RLF in Logs: A Checklist
20Glossary
21References

1. What Radio Link Monitoring Is For, and Where It Runs

RLM runs on the SpCell — the PCell of the master cell group, and the PSCell of a secondary cell group if there is one TS 38.213 cl. 5. It does not run on SCells. That asymmetry is deliberate and worth holding onto: an SCell is a bandwidth accessory, and losing it costs throughput. An SpCell carries the control plane, and losing it costs the connection.

Cell	RLM?	Beam failure detection?	What its loss costs	What the UE does
PCell	Yes	Yes	The whole connection: control plane, all bearers	Declares RLF and attempts re-establishment (§7-§10)
PSCell (in NR-DC)	Yes	Yes	The secondary leg's throughput and any SCG-terminated bearers	Declares SCG failure and reports it on the MCG (§12) — no re-establishment
SCell	No	Yes (Rel-16 onward)	That carrier's throughput only	Nothing at the RRC level. Rel-16 SCell BFR reports the beam problem; the network decides. See the companion 12 Beam Failure Recovery document.

Table 1. RLM scope. The middle column is the reason a UE can be losing an SCell entirely and show no RLM activity at all.

💡

Key Point

RLM is a PHY-to-RRC pipeline, and the layers do different jobs. The physical layer decides whether the link is good or bad and says so, repeatedly. RRC counts those statements, runs a timer, and decides whether the connection is dead. Neither layer does the other's job: PHY never declares failure, and RRC never looks at a measurement. Every confusing RLM log is easier once you know which layer produced each line.

2. The RLM Reference Signals

The UE needs something to measure. RadioLinkMonitoringConfig in ServingCellConfig supplies it, through the same failureDetectionResourcesToAddModList used for beam failure detection, with a purpose field on each entry selecting the use:

purpose value	Feeds	Threshold(s) applied	Typical use
rlf	The out-of-sync / in-sync counters only	`Q_out` and `Q_in`	An SSB that represents the cell as a whole rather than the current beam
beamFailure	The `BFI_COUNTER` only	`Q_out` only	A CSI-RS or SSB that is the QCL Type-D source of a monitored CORESET
both	Both counters, simultaneously and independently	`Q_out` for beam failure; `Q_out` and `Q_in` for RLM	The common case in FR1, where there is often only one sensible RS to measure

Table 2. RadioLinkMonitoringRS.purpose, TS 38.331. One reference signal with purpose = both produces two independent streams of indications from one set of measurements.

If no list is configured, the UE derives the RLM-RS set implicitly, the same way it derives the BFD-RS set: from the reference signals that are the QCL Type-D sources of the active TCI states of the CORESETs the UE monitors for PDCCH. The companion 12 Beam Failure Recovery document has the derivation chain drawn out in full; it applies verbatim here.

Two limits apply. The ASN.1 list is bounded at maxNrofFailureDetectionResources, which is 10. Separately, TS 38.213 clause 5 caps the number of reference signals the UE is required to evaluate for RLM, as a function of the maximum number of SSBs in a half frame — a small number, and much smaller than 10. Configuring a long list does not make the UE monitor all of it.

⚠️

Common Pitfall

RLM-RS choice interacts with beamforming in a way that catches people out. If the RLM-RS is a beam-specific CSI-RS, then RLM is effectively measuring the current beam, and it will report out-of-sync for a blockage that beam failure recovery is about to fix — which is fine, because recovery is much faster than T310, but it means out-of-sync indications are not evidence of a cell-level problem. If the RLM-RS is an SSB, RLM measures something closer to the cell, and out-of-sync indications mean more. Read the RLM-RS configuration before drawing conclusions from out-of-sync counts.

3. Qin, Qout, and the Hypothetical PDCCH

This section contains the single most misunderstood point in the whole topic, so it gets stated plainly before anything else: RLM thresholds are block error rates, not received powers.

💡

Key Point

Q_out and Q_in are defined as the block error rate the UE would experience decoding a hypothetical PDCCH TS 38.133. The UE takes the SINR it estimates from the RLM reference signal, maps it through a reference PDCCH configuration — a specified DCI payload size, aggregation level, CCE count and coding rate — and asks what BLER that combination would produce. The thresholds are:

Q_out = 10% hypothetical PDCCH BLER -> report out-of-sync

Q_in = 2% hypothetical PDCCH BLER -> report in-sync

No RSRP value appears anywhere in that definition. A UE at -85 dBm in heavy interference can be persistently out-of-sync; a UE at -115 dBm in a clean, empty cell can be persistently in-sync. If you are correlating out-of-sync indications against RSRP and finding no relationship, that is the mechanism working as designed, not a measurement fault.

Two consequences follow. First, RLM is sensitive to the CORESET configuration the reference PDCCH is derived from, so two cells with identical coverage and different control-channel configurations can have different out-of-sync behaviour. Second, the gap between 10% and 2% is deliberate hysteresis: without it the link would chatter between in-sync and out-of-sync at a single boundary, and T310 would start and stop constantly. The asymmetry is also deliberate — it takes a four-to-five times better error rate to declare recovery than it took to declare trouble.

	Out-of-sync	In-sync
Threshold	Quality worse than `Q_out`	Quality better than `Q_in`
Default value	10% hypothetical PDCCH BLER	2% hypothetical PDCCH BLER
Counted by	N310	N311
Counting rule	Consecutive; one in-sync resets the run	Consecutive; one out-of-sync resets the run
Effect of reaching the count	Start `T310`	Stop `T310` — only meaningful while `T310` is running
Alternative thresholds	`rlmInSyncOutOfSyncThreshold` in `ServingCellConfig`, when present, selects the alternative threshold pair defined in TS 38.133	Same field; the pair moves together

Table 3. The two thresholds and their counters. Note the last row: the two thresholds are configured as a pair, not individually.

4. Out-of-Sync and In-Sync Indications, and Their Evaluation Periods

The physical layer does not produce an indication per reference signal occasion. It evaluates the radio link quality over a sliding evaluation period and reports the result of that evaluation, periodically, to higher layers. The evaluation period is what makes RLM stable — a single bad SSB cannot produce an out-of-sync indication — and it is also the part that people leave out of their detection-time arithmetic.

Quantity	What it is	What it depends on	Why it matters
Out-of-sync evaluation period	The window over which the quality must be worse than `Q_out` for the UE to report out-of-sync	The RLM-RS periodicity, the frequency range, and — significantly — the DRX cycle in use TS 38.133	Nothing can be detected faster than this. It is a floor on RLF detection time that no `N310` or `T310` setting can go below.
In-sync evaluation period	The equivalent window for `Q_in`	Same inputs; shorter than the out-of-sync period	Recovery is detected faster than failure, which is the right asymmetry for a mechanism whose job is to avoid unnecessary failures.
Indication interval	How often the result of the sliding evaluation is reported to RRC	Commonly quoted as 10 ms for SSB-based RLM at FR1	This is the number people multiply `N310` by. It is correct as far as it goes, but it starts after the first evaluation period has elapsed.
DRX scaling	A lengthening of both evaluation periods when the UE is in a long DRX cycle	The configured DRX cycle length TS 38.133	A power-saving profile with a long `drx-LongCycle` makes RLF detection substantially slower. See the companion 11 DRX document.

Table 4. The four quantities that decide when the first out-of-sync indication can possibly arrive. Only the third is usually included in back-of-envelope estimates.

🧮

Worked Calculation

For SSB-based RLM without DRX, the out-of-sync evaluation period is on the order of 200 ms and the in-sync period about half that, both lower-bounded by a multiple of the SSB periodicity TS 38.133. Taking those as the shape of the requirement:

SSB periodicity 20 ms

out-of-sync evaluation period ~ max(200, 10 x 20) = 200 ms

SSB periodicity 40 ms (a common power-saving choice)

out-of-sync evaluation period ~ max(200, 10 x 40) = 400 ms

So doubling the SSB periodicity doubles the floor on RLM detection. With N310 = n4 at a 10 ms indication interval and T310 = ms1000:

naive estimate = (4 x 10) + 1000 = 1040 ms

20 ms SSB = 200 + (3 x 10) + 1000 = 1230 ms

40 ms SSB = 400 + (3 x 10) + 1000 = 1430 ms

The naive estimate is out by 20% to 40%, always in the optimistic direction. Values here are illustrative and rounded; the exact requirements are in TS 38.133.

5. The N310 / T310 / N311 Machine

RRC's half of the pipeline is three parameters and one timer, and it is specified in about six lines TS 38.331 cl. 5.3.10. Every one of those lines matters.

Figure 1. The machine in full, including the gate at the top that most summaries omit. T310 is not started while any of the establishment, handover, resume or re-establishment timers are running.

Event	Precondition	Action	Why the precondition exists
`N310` consecutive out-of-sync indications for the SpCell	None of `T300`, `T301`, `T304`, `T311`, `T319` running	Start `T310` for that SpCell	During establishment, handover, resume or re-establishment there is already a timer bounding the outcome. Starting `T310` as well would produce two failures for one event.
`N311` consecutive in-sync indications for the SpCell	`T310` running	Stop `T310`	In-sync indications outside a running `T310` have nothing to stop; the UE is not in trouble.
`T310` expiry	--	Declare radio link failure (PCell) or SCG failure (PSCell)	The grace period is over.
`RRCReconfiguration` with `reconfigurationWithSync` received	`T310` running	Stop `T310`	A handover command supersedes the failure: the network has already decided to move the UE. `T304` takes over.
Re-establishment initiated for any reason	`T310` running	Stop `T310`	The UE is already recovering.
`T310` configured as `ms0`	--	`T310` expires immediately, so `N310` out-of-syncs declare RLF with no grace period at all	A legal configuration, and occasionally a deliberate one for very latency-sensitive deployments. Almost never what someone meant.

Table 5. The complete T310 state table. The last row is a real misconfiguration: ms0 is in the enumeration and behaves exactly as written.

Figure 2. Two runs that are identical for 240 ms and end differently. N311 = n1 means one good indication is enough; N311 = n10 would have required ten consecutive good indications and this UE would have failed.

⚠️

Common Pitfall

Both counters count consecutive indications. A UE that alternates out-of-sync, in-sync, out-of-sync, in-sync forever never reaches N310 and never declares RLF, no matter how bad the average quality is. This is correct — it can evidently still decode sometimes — but it produces a characteristic log signature: hundreds of out-of-sync indications, no T310 start, and a user complaining bitterly about throughput. The fix is not in N310; it is in the radio or in a handover threshold.

Sizing the pair is a straight fail-fast versus fail-safe decision. A short T310 recovers quickly from genuine failures and re-establishes unnecessarily during recoverable fades — a tunnel, a lift, a train crossing a bridge. A long T310 rides out those fades and leaves a UE with a dead link doing nothing for up to two seconds. Because the whole outage is dominated by T310 (§14), this one enumeration choice is worth more than every other parameter in this document put together.

Figure 3. The outage broken down. T310 is roughly three quarters of it, and it is the only part that is purely a configuration choice — T311 and T301 are budgets that the UE usually does not spend.

6. The Other Ways RLF Is Declared

T310 expiry is the classic path and the only one that involves RLM at all. There are four others TS 38.331 cl. 5.3.10.3, and in a real network they are not rare. A UE that declares RLF has not necessarily seen a single out-of-sync indication.

Figure 4. Five sources, one declaration, three outcomes. The middle band is the gate: it applies to the T310 start and to the Random Access problem indication, which is why a handover failure does not also become an RLF.

Trigger	Detected by	Reached when	Gated by the timers?	Release
`T310` expiry on the PCell	RRC, from PHY indications	The RLM machine of §5 runs to completion	Yes — not started while `T300`, `T301`, `T304`, `T311` or `T319` runs	Rel-15
Random Access problem indication from MCG MAC	MAC -> RRC	`preambleTransMax` preambles transmitted with no usable response. See the companion 03 Random Access document	Yes — the same gate, which is why a handover RACH failure is a handover failure	Rel-15
MCG RLC reaching `maxRetxThreshold`	RLC -> RRC	An AM RLC entity has retransmitted one PDU `maxRetxThreshold` times without an acknowledgement	No	Rel-15
Consistent uplink LBT failure on the SpCell	MAC -> RRC	`lbt-FailureInstanceMaxCount` LBT failures inside `lbt-FailureDetectionTimer` on an unlicensed carrier	Partly — not while `T304` is running	Rel-16 (NR-U)
BH RLF indication received on the BAP entity	BAP -> RRC	An IAB-node's parent has told it the backhaul link has failed	No	Rel-16 (IAB)

Table 6. All five RLF triggers with their gating. Only the first involves RLM; only the first three exist in Rel-15.

💡

Key Point

The RLC trigger is the one that surprises people, because it can fire on a link whose downlink is perfect. maxRetxThreshold is reached when RLC AM has retransmitted the same PDU that many times without an ACK — which on the uplink means the gNB is not receiving, and on the downlink means the UE's status reports are not getting through. Either way, RLM sees nothing wrong, because RLM only looks at the downlink control channel. A UE that declares RLF with zero out-of-sync indications in the log has almost always come this way, and the diagnosis is an uplink problem: coverage-limited uplink, power headroom, or a timing advance that has drifted. See the companion 04 Timing Advance document.

📘

Spec Detail

MAC never declares RLF. It reports a Random Access problem, and RRC decides what that means from the context — connection establishment failure, handover failure, SCell release, or RLF. The gate in the table above is exactly that decision expressed as a precondition. Reading a burst of preamble retries as an RLF without checking which timers were running is the commonest misreading in this whole area.

7. What Happens the Instant RLF Is Declared

RLF does not automatically mean re-establishment. The UE has three possible responses, and which one it takes depends on how far the connection had got before it broke TS 38.331 cl. 5.3.10.3:

Condition at the moment of failure	What the UE does	Release cause recorded	Consequence
AS security has not been activated	Go directly to RRC_IDLE	other	There is no context worth preserving and no key to authenticate a re-establishment request with. A fresh `RRCSetup` is the only option.
AS security activated, but SRB2 and at least one DRB have not been set up	Go directly to RRC_IDLE	RRC connection failure	The connection was still being built. Re-establishing a half-built connection costs more than rebuilding it.
AS security activated and SRB2 and at least one DRB set up	Initiate the RRC connection re-establishment procedure	--	The expensive parts — security context, bearer configuration, NAS registration — are worth carrying to another cell (§8).

Table 7. The three outcomes of an RLF declaration. Only the third involves T311, cell selection, or an RRCReestablishmentRequest.

When the third branch is taken, the UE does a great deal of work before it transmits anything TS 38.331 cl. 5.3.7.2:

Suspend all radio bearers except SRB0. SRB0 is CCCH and needs no context; everything else is frozen where it stands, not released.
Reset MAC. HARQ buffers flushed, all timers stopped, timeAlignmentTimer considered expired, any pending SR or BSR cancelled.
Release spCellConfig and every MCG SCell. The UE keeps its PDCP and RLC state and its security context, and throws away everything cell-specific.
Start T311 and begin cell selection per TS 38.304 — the same procedure an idle UE uses, with the same suitability rules.

🔍

What You See In Logs

The MAC reset is why re-establishment is expensive even when it succeeds quickly. Every HARQ process is flushed, so any transport block in flight is lost and must be recovered by RLC; the timing advance is gone, so the new cell's RACH is a full timing acquisition; and any semi-persistent scheduling or configured grant is released. The RRC exchange is three messages, but the user-plane cost is closer to a cold start.

8. T311: Cell Selection With a Context in Hand

T311 bounds the search, not the exchange. It runs from the moment re-establishment is initiated until the UE has selected a suitable cell — NR or E-UTRA — and it is generous, up to 30 seconds, because a UE that has just lost its serving cell may be somewhere with very little to choose from. What the UE is looking for is a cell that is suitable in the TS 38.304 sense: the right PLMN, not barred, not in a forbidden tracking area, and above the cell selection quality thresholds.

Outcome of cell selection	T311	T301	What the UE sends	Then
A suitable NR cell is found	Stopped	Started	`RRCReestablishmentRequest` on CCCH of that cell (§9)	Wait for `RRCReestablishment` or `RRCSetup` (§10)
A suitable E-UTRA cell is found	Stopped	--	Nothing on NR — the UE moves to E-UTRA	Go to RRC_IDLE on the NR side; connect via LTE. The RLF report survives and can be delivered over E-UTRA (§11).
`T311` expires with nothing suitable found	Expired	--	Nothing	Go to RRC_IDLE with release cause `RRC connection failure`; set `noSuitableCellFound` in the RLF report

Table 8. What T311 can end in. The middle row is easy to forget and shows up as an unexplained inter-RAT move immediately after an RLF.

🔍

What You See In Logs

The selected cell does not have to be a different cell. Re-establishing on the same PCI the UE just failed on is completely legal and common — a tunnel exit, a lift door, a body-blocking hand. In a log this looks alarming and is usually the cheapest possible recovery, because the target gNB already holds the UE context and no Xn retrieval is needed at all.

9. RRCReestablishmentRequest: the 48 Bits That Do the Work

The request goes out on SRB0, on CCCH, in MSG3 of a contention-based Random Access procedure at the selected cell. It has no security protection of its own — SRB0 has none — so it has to prove the UE's identity and its right to the context in the payload itself, in 48 bits total.

Figure 5. The complete message. Three fields do all the work: the C-RNTI and PCI say which UE, at which cell, and the shortMAC-I proves the sender knew the source cell's integrity key.

Field	Width	Value	What the target cell does with it
c-RNTI	16 bits	The C-RNTI the UE held in the source cell	Half of the key used to look up the UE context. Meaningless in the target cell's own RNTI space.
physCellId	10 bits	The PCI of the source cell	The other half of the lookup key. Tells the target which neighbour to ask over Xn.
shortMAC-I	16 bits	The 16 least significant bits of a MAC-I computed over `VarShortMAC-Input`	Authenticates the request. Verified by the source cell, which is the only node holding the source `K_RRCint`.
reestablishmentCause	2 bits	`reconfigurationFailure`, `handoverFailure`, `otherFailure`, `spare1`	Diagnostic and policy input. `handoverFailure` tells the target this was a mobility problem, not a coverage one.
spare	1 bit	0	Padding to the 48-bit CCCH size.
CHOICE header	3 bits	`UL-CCCH-Message` type selector	Distinguishes this from `RRCSetupRequest`, `RRCResumeRequest` and `RRCSystemInfoRequest`.

Table 9. RRCReestablishmentRequest fields, TS 38.331. Total exactly 48 bits — which is exactly the width of the UE Contention Resolution Identity MAC CE that echoes it back in MSG4.

9.1 What shortMAC-I is computed over

shortMAC-I is what makes re-establishment safe. Without it, anyone who observed a C-RNTI and a PCI could claim another UE's context.

VarShortMAC-Input ::= SEQUENCE {
    sourcePhysCellId       PhysCellId,       -- PCI of the source PCell
    targetCellIdentity     CellIdentity,     -- 36-bit CellIdentity of the
                                             -- cell the UE is asking
    sourceC-RNTI           RNTI-Value        -- C-RNTI in the source cell
}

shortMAC-I = the 16 least significant bits of the MAC-I computed over
             VarShortMAC-Input, using:
               - the K_RRCint key of the SOURCE PCell
               - the integrity algorithm of the SOURCE PCell
               - all input bits for COUNT, BEARER and DIRECTION set to 1

Listing 1. VarShortMAC-Input, TS 38.331. Note that the target cell identity is an input, which is what stops a captured request being replayed at a different cell.

📘

Spec Detail

shortMAC-I binds the request to one specific target cell. The target cell identity goes into the computation, so a shortMAC-I valid at cell A is invalid at cell B. This is why the UE must complete cell selection before it can build the message, and why a re-establishment attempt cannot be prepared in advance. It is also a useful diagnostic: a shortMAC-I verification failure at the source cell means either a genuine mismatch of security context, or that the UE and the network disagree about the target's CellIdentity — which happens when SIB1 has been reconfigured and the UE is working from a cached copy.

10. T301, and the Two Ways the Network Can Answer

T301 starts when the UE selects a suitable cell and initiates the request, and it bounds the exchange. Two answers end it successfully, and they mean very different things.

Figure 6. Both outcomes. Note that the Xn context retrieval happens before the branch: the target always asks, and the branch is decided by whether it gets a usable answer.

Answer	Meaning	What survives	What the UE does
`RRCReestablishment` on SRB1	The source cell had the context and the `shortMAC-I` verified	Security context (re-keyed via `nextHopChainingCount`), bearer configuration, PDCP and RLC state, NAS registration	Re-establish PDCP for SRB1, resume SRB1, derive a new `K_gNB`, send `RRCReestablishmentComplete`. SRB2 and the DRBs stay suspended until the `RRCReconfiguration` that follows.
`RRCSetup` on CCCH	The context could not be retrieved, or the `shortMAC-I` did not verify	Nothing at the AS level	Treat it as a fresh connection establishment: apply the default configuration, and inform upper layers that the re-establishment failed, so NAS runs registration again. See the companion 01 Registration Process document.
RRCReject	The target is under load and is refusing	Nothing	Go to RRC_IDLE with release cause `RRC connection failure`.
Nothing, until `T301` expires	The request was not heard, or the answer was not	Nothing	Go to RRC_IDLE with release cause `RRC connection failure`.

Table 10. The four ways T301 can end. The second row is the fallback-to-setup path, and it is the one that quietly costs a NAS registration.

Figure 7. The same information as an RRC state trajectory. Two of the four leaves keep the bearers; the other two do not.

⚠️

Common Pitfall

RRCReestablishment restores SRB1 only. SRB2 and every DRB remain suspended until the network sends an RRCReconfiguration, which it does immediately afterwards. In a trace this means RRCReestablishmentComplete is not the end of the outage — user-plane data does not flow until the reconfiguration completes, typically tens of milliseconds later. Measuring recovery time to the RRCReestablishmentComplete understates the outage.

🧮

Worked Calculation

Total outage, N310 = n4, T310 = ms1000, 20 ms SSB periodicity:

out-of-sync evaluation period .................... 200 ms

3 further out-of-sync indications at 10 ms ....... 30 ms

T310 runs to expiry ............................ 1000 ms

---- RLF declared at 1230 ms ----

MAC reset, cell selection (illustrative) ......... 250 ms

RACH + RRCReestablishmentRequest ............... 25 ms

Xn context retrieval + RRCReestablishment ...... 40 ms

RRCReestablishmentComplete ..................... 15 ms

---- SRB1 up at 1560 ms ----

RRCReconfiguration restoring SRB2 and DRBs ..... 40 ms

---- user plane restored at ~1600 ms ----

T310 alone is 1000 of the 1600 ms, or 63%. Halving it to ms500 takes the total to ~1100 ms; setting it to ms200 takes it to ~800 ms. Nothing else in the chain offers anything like that leverage — and the price is paid in re-establishments during recoverable fades.

Figure 8. The same arithmetic across five configurations. The gold bar is the evaluation-period floor, which no configuration can go below.

11. The RLF Report

Everything above happens inside one UE, in a few hundred milliseconds, with the network unable to observe most of it. The RLF report is the mechanism that closes that gap: the UE records what it saw, carries the record to whichever cell it eventually connects to, and hands it over on request. For anyone doing log analysis on a live network this is the single most valuable object in this document, because it is the only source of the UE's side of the failure.

11.1 How it is stored and retrieved

The UE keeps the report in VarRLF-Report, one report at a time — a new failure overwrites the previous one. The retrieval sequence is:

1. The UE detects RLF or handover failure and populates VarRLF-Report.

2. The UE connects somewhere — by re-establishment, by a fresh RRCSetup, or by resuming from RRC_INACTIVE — and sets rlf-InfoAvailable inside UE-MeasurementsAvailable in the corresponding *Complete message (RRCSetupComplete, RRCReestablishmentComplete, RRCResumeComplete or RRCReconfigurationComplete).

3. The network, if it wants the report, sends UEInformationRequest with rlf-ReportReq set.

4. The UE returns UEInformationResponse carrying rlf-Report, and then discards it.

5. If nobody asks, the UE keeps the report for 48 hours from the failure and then discards it. It survives cell reselection, RRC state changes and power cycling of the connection — and can be delivered over E-UTRA if the UE ended up on LTE.

⚠️

Common Pitfall

The report is only available if somebody asks for it. A network that never sends UEInformationRequest with rlf-ReportReq has no visibility into UE-side failures at all, and the RLF counters in its own statistics are only the failures it noticed. If you are investigating a coverage complaint and the operator's tooling shows no RLF reports, check whether the request is enabled before concluding there were no failures.

11.2 What is in it

Field	Type	What it carries	What to do with it
measResultLastServCell	cell and per-beam results	RSRP, RSRQ and SINR of the failed serving cell at the moment of failure, per cell and per SSB/CSI-RS index, plus the `ssbRLMConfigBitmap` naming which SSBs were configured for RLM	The first thing to read. Strong RSRP here means the failure was not coverage — look at SINR, then at §6's non-RLM triggers.
measResultNeighCells	NR and E-UTRA lists	The neighbour measurements the UE had at the moment of failure	If a neighbour was strong and no handover had been commanded, this is a mobility configuration problem: too-late handover. Compare against the A3 offset and time-to-trigger in the companion 20 Measurements and Events document.
c-RNTI	16-bit RNTI	The C-RNTI the UE held in the failed cell	The join key to the gNB-side logs. Without it, correlating a UE report with a network trace is guesswork.
previousPCellId	NR or E-UTRA CGI	The PCell the UE was on before the one that failed	Reveals ping-pong and too-early handover: if the previous cell is also the reconnect cell, the handover into the failed cell was a mistake.
failedPCellId	CGI, or PCI + ARFCN	The cell that failed. CGI when the UE had read SIB1; PCI plus frequency when it had not	A PCI-and-ARFCN-only report means the UE never read SIB1 there — which on a handover target points at the handover itself.
reconnectCellId	NR or E-UTRA CGI	The cell the UE eventually got service on	Together with `failedPCellId` this gives the geometry of the failure.
reestablishmentCellId	CGI	The cell the re-establishment attempt was made on, when there was one	If it differs from `reconnectCellId`, the first attempt failed.
timeConnFailure	0..1023, x 100 ms	Time from the last handover initialisation until the failure	The too-late / too-early handover discriminator. A small value means the UE failed shortly after arriving — too-early or wrong-cell handover. A large value means the handover was fine and the failure is unrelated.
timeSinceFailure	seconds	How long ago the failure happened, at the moment of reporting	Lets you place the report on a timeline even when it arrives hours later. Also the field that tells you the report is stale.
connectionFailureType	rlf or hof	Whether this was a radio link failure or a handover failure	Read this before anything else. The two have completely different causes and completely different fixes (§13).
rlf-Cause	enumerated	`t310-Expiry`, `randomAccessProblem`, `rlc-MaxNumRetx`, `beamFailureRecoveryFailure`, `lbtFailure`, `bh-rlfRecoveryFailure`	Maps directly onto §6. `rlc-MaxNumRetx` points at the uplink; `randomAccessProblem` at PRACH or coverage; `t310-Expiry` at the downlink control channel.
noSuitableCellFound	true, or absent	Present if `T311` expired without finding a suitable cell	A coverage hole, not a failure of the failed cell. The interesting question becomes why no neighbour was usable.
ra-InformationCommon	RACH details	The RACH attempt details of the recovery: preamble indices, powers, number of attempts, whether contention was detected	Feeds RACH optimisation, and tells you whether the recovery RACH was itself in trouble.
locationInfo	GNSS, optional	GNSS position and velocity, if the UE had them and was allowed to report them	Turns a report into a map point. Usually absent, and never something to rely on.

Table 11. RLF-Report contents, TS 38.331 (Rel-16 nr-RLF-Report). The three rows to read first are connectionFailureType, rlf-Cause and measResultLastServCell — in that order.

🧮

Worked Calculation

timeConnFailure = 47:

actual value = 47 x 100 ms = 4.7 seconds

So the failure happened 4.7 s after the last handover was initiated. With connectionFailureType = rlf and a strong measResultNeighCells entry, that reads as a too-late handover: the UE arrived, the source became unusable, and the network did not move it on in time.

Contrast timeConnFailure = 3, i.e. 0.3 seconds: the UE failed almost immediately after arriving. With the previous PCell strong in the neighbour list, that is a too-early handover — the network moved it into a cell it could not hold.

The field is absent entirely if there had been no handover, which is itself informative: the failure is not a mobility problem.

🔍

What You See In Logs

The RLF report is the closest thing NR has to a black box, and it is underused. Two fields alone — connectionFailureType and timeConnFailure — separate the four classical mobility failure categories (too late, too early, wrong cell, and unrelated coverage) without any network-side correlation at all. If you build one query against RLF reports, build that one.

12. SCG Failure and MCG Failure: the Dual-Connectivity Variants

In dual connectivity the UE has two cell groups and two SpCells, and the machinery of §5 runs independently on each. What differs is the consequence, because a UE with a working MCG has a signalling path available and does not need to re-establish anything.

	MCG failure (classic RLF)	SCG failure	MCG failure with fast recovery (Rel-16)
Detected on	PCell	PSCell	PCell
Precondition	--	The MCG is working	`mcg-FastRecovery` configured and the SCG is available
What the UE sends	`RRCReestablishmentRequest` on a newly selected cell, on CCCH	`SCGFailureInformation` on the MCG, on SRB1	`MCGFailureInformation` via the SCG (SRB3, or split SRB1)
Timer that bounds it	`T311` then `T301`	None on the UE side	T316
Failure type reported	`rlf-Cause` in the RLF report, later	`failureType` in `FailureReportSCG`: `t310-Expiry`, `randomAccessProblem`, `rlc-MaxNumRetx`, `synchReconfigFailureSCG`, `scg-reconfigFailure`, `srb3-IntegrityFailure`, plus Rel-16 `scg-lbtFailure`, `beamFailureRecoveryFailure`, `t312-Expiry`, `bh-RLF`	`failureType` in `FailureReportMCG`, same shape
What the UE suspends	All RBs except SRB0	SCG transmission only; the MCG carries on	MCG transmission; the SCG carries on
Recovery	Re-establishment, or fall back to `RRCSetup`	The network reconfigures, releases or changes the PSCell	The network sends an `RRCReconfiguration` over the SCG; on `T316` expiry the UE falls back to ordinary re-establishment
Cost	Full outage, MAC reset, possible NAS re-registration	SCG throughput only	Much lower than re-establishment — the whole point of the feature

Table 12. The three failure flavours. Rel-16 fast MCG recovery turns what used to be a full re-establishment into a reconfiguration, provided the UE has a second leg to talk over.

🔍

What You See In Logs

SCGFailureInformation carries measResultFreqList and measResultSCG-Failure alongside the failure type — measurements taken at the moment of failure, delivered immediately rather than 48 hours later on request. For diagnosing PSCell problems this is far more useful than the RLF report, because it arrives in real time and identifies the candidate the network should have moved to.

13. RLF Versus Handover Failure

The two end up in the same place — re-establishment — and are constantly conflated. They are different events with different causes, and the protocol distinguishes them carefully.

	Radio link failure	Handover failure
Triggered by	One of the five sources in §6	`T304` expiry during a `reconfigurationWithSync`
What was happening	The UE was operating normally on its serving cell	The UE had been commanded to a target cell and could not complete access to it
Is `T310` involved?	In the classic path, yes	No — `T310` is not started while `T304` is running, and any running `T310` is stopped by the handover command (§5)
Is a Random Access problem an RLF?	Yes, if none of the gating timers is running	No — during `T304` the same MAC indication is a handover failure, and `T304` continues to run
`connectionFailureType` in the RLF report	rlf	hof
`reestablishmentCause` in the request	`otherFailure`, or `reconfigurationFailure`	handoverFailure
What it usually points at	Coverage, interference, uplink limitation, or an unrecovered beam problem	Mobility configuration: thresholds, time-to-trigger, or a target that was never viable
Special case	--	With DAPS the UE reverts to the source cell instead of re-establishing — see the companion 25 Conditional HO and DAPS document

Table 13. RLF and handover failure side by side. The third and fourth rows are the mechanism that keeps them apart; the fifth is how you tell them apart afterwards.

💡

Key Point

A UE that fails a handover and then re-establishes on the source cell is the textbook too-early-handover signature. The RLF report will show connectionFailureType = hof, a small timeConnFailure, and a reconnectCellId equal to previousPCellId. That combination is worth alerting on: it is unambiguous and it is fixable in the mobility configuration. See the companion 22 Handover Overview document.

14. Timers, Counters and Parameter Reference

Parameter	Where	Values	Typical	What it does
n310	`UE-TimersAndConstants` in SIB1; overridable per cell group by `rlf-TimersAndConstants`	n1, n2, n3, n4, n6, n8, n10, n20	n1 or n4	Consecutive out-of-sync indications needed to start `T310`. Higher = more tolerant of brief fades and slower to detect real failure.
t310	as above	ms0, ms50, ms100, ms200, ms500, ms1000, ms2000	ms1000	The grace period. Dominates the whole outage (§10). `ms0` means no grace period at all and is almost always a mistake.
n311	as above	n1, n2, n3, n4, n5, n6, n8, n10	n1	Consecutive in-sync indications needed to stop `T310`. Higher = harder to recover from a fade the UE has actually survived.
t311	`UE-TimersAndConstants`; `t311-v1530` in `rlf-TimersAndConstants`	ms1000, ms3000, ms5000, ms10000, ms15000, ms20000, ms30000	ms3000	Bounds cell selection during re-establishment. A budget, not a duration — shortening it only makes the UE give up sooner in poor coverage.
t301	UE-TimersAndConstants	ms100, ms200, ms300, ms400, ms600, ms1000, ms1500, ms2000	ms1000	Bounds the re-establishment exchange from request to `RRCReestablishment` or `RRCSetup`.
t300	UE-TimersAndConstants	same list as `t301`	ms1000	Bounds initial connection establishment. Relevant here only as one of the timers that gates the `T310` start.
t304	ReconfigurationWithSync	ms50 .. ms10000	ms1000	Bounds handover execution. Gates the `T310` start and turns a Random Access problem into a handover failure (§13).
t319	UE-TimersAndConstants	same list as `t301`	ms1000	Bounds resume from RRC_INACTIVE. Another gating timer.
t316	`rlf-TimersAndConstants` (Rel-16)	ms50, ms100, ms200, ms300, ms400, ms600, ms1000, ms1500, ms2000	ms1000	Bounds fast MCG recovery. On expiry the UE falls back to ordinary re-establishment (§12).
rlmInSyncOutOfSyncThreshold	ServingCellConfig	`n1` or absent	absent	Selects the alternative `Q_in` / `Q_out` threshold pair of TS 38.133 (§3).
maxRetxThreshold	RLC-Config	t1, t2, t3, t4, t6, t8, t16, t32	t8 to t32	RLC AM retransmissions before RLC declares failure to RRC — an RLF trigger in its own right (§6).
preambleTransMax	RACH-ConfigGeneric	n3, n4, n5, n6, n7, n8, n10, n20, n50, n100, n200	n10	Preamble transmissions before MAC reports a Random Access problem — another RLF trigger (§6).
`lbt-FailureInstanceMaxCount`, `lbt-FailureDetectionTimer`	`LBT-FailureRecoveryConfig` (Rel-16)	see TS 38.331	--	Define consistent LBT failure on unlicensed carriers, an RLF trigger from Rel-16.

Table 14. RLM and RLF parameters. The first three plus t311 and t301 are broadcast in SIB1 for every UE in the cell, and can be overridden per cell group by rlf-TimersAndConstants in CellGroupConfig — so an SCG can fail on a completely different schedule from the MCG.

⚠️

Common Pitfall

n310, t310, n311 and t311 exist in two places: broadcast in SIB1's UE-TimersAndConstants, and per cell group in rlf-TimersAndConstants inside CellGroupConfig. The dedicated values win when present. A UE whose observed T310 does not match the SIB1 value is not broken — check the cell group configuration in the last RRCReconfiguration before assuming a UE bug.

15. Failure Modes and What Each One Means

Failure	Detected by	What the UE does	Diagnostic pointer
RLF declared with no out-of-sync indications anywhere in the log	RRC, from a non-RLM trigger	Re-establishes normally	One of the four non-`T310` triggers of §6. `rlf-Cause` in the RLF report names which. `rlc-MaxNumRetx` is the commonest and points at the uplink.
Hundreds of out-of-sync indications and `T310` never starts	Nobody	Nothing — the link is intermittently usable	The out-of-syncs are not consecutive. Correct behaviour (§5). The fix is a handover threshold or the radio, not `n310`.
`T310` starting and stopping repeatedly	Nobody	Recovers each time; the user sees stalls	The link is oscillating around `Q_out`. Consider whether the RLM-RS is beam-specific (§2) and whether beam failure recovery should be handling this instead.
`T310` configured as `ms0`	Nobody	Declares RLF the instant `N310` is reached	A very distinctive signature: RLF with no measurable gap after the `N310`th out-of-sync. Check `UE-TimersAndConstants` and `rlf-TimersAndConstants`.
RLF declared but no `RRCReestablishmentRequest` sent	RRC	Goes straight to RRC_IDLE	Not a fault: security was not active, or SRB2 and a DRB were not up (§7). Read the release cause — `other` versus `RRC connection failure` tells you which.
`T311` expiry	UE RRC	Goes to RRC_IDLE, sets `noSuitableCellFound` in the RLF report	A coverage hole. The failed cell is a red herring; the question is why no neighbour was suitable. Check the neighbour measurements in the report.
`RRCSetup` received in answer to a re-establishment request	UE RRC	Establishes a fresh connection; DRBs are gone; NAS re-registers	Either the target could not reach the source over Xn, or the `shortMAC-I` failed to verify (§9.1). The two are distinguishable on the network side and identical from the UE's.
`shortMAC-I` verification failure at the source cell	Source gNB	Sees only the `RRCSetup` fallback	Mismatched security context, or a `CellIdentity` disagreement caused by a stale cached SIB1 at the UE (§9.1).
`T301` expiry	UE RRC	Goes to RRC_IDLE with cause `RRC connection failure`	The request or the answer was lost. Look at the recovery RACH in `ra-InformationCommon`: if it took many preambles, the target's uplink is the problem.
Re-establishment succeeds and data still does not flow	Nobody	Waits for the `RRCReconfiguration`	`RRCReestablishment` restores SRB1 only (§10). If the reconfiguration is slow or lost, SRB2 and the DRBs stay suspended and the UE looks connected while carrying nothing.
RLF reports never arriving at the network	Nobody	Stores them and discards after 48 hours	The network is not sending `UEInformationRequest` with `rlf-ReportReq`. A tooling gap, not a UE one (§11.1).
Repeated RLF on the same cell with strong RSRP in the report	Nobody	Re-establishes each time	Not coverage. Look at SINR and at interference, then at the uplink — `rlc-MaxNumRetx` and `randomAccessProblem` both produce this picture.
`T310` and a BFR RACH racing each other	Nobody	Whichever finishes first produces the failure	Compare `T310` against the BFR `preambleTransMax` budget. RLF statistics compared across cells with different `t310` values are partly comparing configurations. See the companion 12 Beam Failure Recovery document.

Table 15. RLM and RLF failure modes. Note how many are diagnosed from the RLF report rather than from anything observable on the network side — which is §11's argument, restated as a table.

💡

Key Point

Two of these are not faults and are frequently reported as such: out-of-syncs that never reach N310, and an RLF that goes straight to RRC_IDLE without a re-establishment attempt. Both are the specification working exactly as written. The two that always deserve attention are RRCSetup fallback — because it silently costs a NAS registration — and repeated RLF with strong RSRP, because it means the thing you were about to blame is not the cause.

16. Configuration Reference (ASN.1)

UE-TimersAndConstants ::= SEQUENCE {
    t300      ENUMERATED {ms100,ms200,ms300,ms400,ms600,ms1000,ms1500,ms2000},
    t301      ENUMERATED {ms100,ms200,ms300,ms400,ms600,ms1000,ms1500,ms2000},
    t310      ENUMERATED {ms0, ms50, ms100, ms200, ms500, ms1000, ms2000},
    n310      ENUMERATED {n1, n2, n3, n4, n6, n8, n10, n20},
    t311      ENUMERATED {ms1000, ms3000, ms5000, ms10000, ms15000,
                          ms20000, ms30000},
    n311      ENUMERATED {n1, n2, n3, n4, n5, n6, n8, n10},
    t319      ENUMERATED {ms100,ms200,ms300,ms400,ms600,ms1000,ms1500,ms2000},
    ...
}

RLF-TimersAndConstants ::= SEQUENCE {     -- per cell group, overrides SIB1
    t310      ENUMERATED {ms0, ms50, ms100, ms200, ms500, ms1000, ms2000},
    n310      ENUMERATED {n1, n2, n3, n4, n6, n8, n10, n20},
    n311      ENUMERATED {n1, n2, n3, n4, n5, n6, n8, n10},
    ...,
    [[ t311-v1530  ENUMERATED {ms1000, ms3000, ms5000, ms10000, ms15000,
                               ms20000, ms30000} ]]
}

RadioLinkMonitoringConfig ::= SEQUENCE {
    failureDetectionResourcesToAddModList
        SEQUENCE (SIZE(1..maxNrofFailureDetectionResources)) OF
                                     RadioLinkMonitoringRS       OPTIONAL,
    beamFailureInstanceMaxCount  ENUMERATED {n1,n2,n3,n4,n5,n6,n8,n10}
                                                                 OPTIONAL,
    beamFailureDetectionTimer    ENUMERATED {pbfd1,...,pbfd10}    OPTIONAL,
    ...
}

RadioLinkMonitoringRS ::= SEQUENCE {
    radioLinkMonitoringRS-Id     RadioLinkMonitoringRS-Id,
    purpose                      ENUMERATED {beamFailure, rlf, both},
    detectionResource            CHOICE {
        ssb-Index                    SSB-Index,
        csi-RS-Index                 NZP-CSI-RS-ResourceId
    },
    ...
}

Listing 2. Timers, constants and the RLM reference signal configuration, abridged from TS 38.331. ... marks omitted members and extension markers.

RRCReestablishmentRequest-IEs ::= SEQUENCE {
    ue-Identity            ReestabUE-Identity,
    reestablishmentCause   ReestablishmentCause,
    spare                  BIT STRING (SIZE (1))
}

ReestabUE-Identity ::= SEQUENCE {
    c-RNTI                 RNTI-Value,        -- 16 bits, SOURCE cell
    physCellId             PhysCellId,        -- 10 bits, SOURCE cell
    shortMAC-I             ShortMAC-I         -- BIT STRING (SIZE (16))
}

ReestablishmentCause ::= ENUMERATED {
    reconfigurationFailure, handoverFailure, otherFailure, spare1 }

RRCReestablishment-IEs ::= SEQUENCE {
    nextHopChainingCount   NextHopChainingCount,
    lateNonCriticalExtension  OCTET STRING                      OPTIONAL,
    nonCriticalExtension      SEQUENCE {}                       OPTIONAL
}

Listing 3. The re-establishment exchange. RRCReestablishment carries almost nothing: one chaining count, from which the UE derives a fresh K_gNB. Everything else is restored by the RRCReconfiguration that follows.

RLF-Report-r16 ::= CHOICE {
    nr-RLF-Report-r16  SEQUENCE {
        measResultLastServCell-r16   MeasResultRLFNR-r16,
        measResultNeighCells-r16     SEQUENCE {
            measResultListNR-r16         MeasResultList2NR-r16    OPTIONAL,
            measResultListEUTRA-r16      MeasResultList2EUTRA-r16 OPTIONAL
        }                                                        OPTIONAL,
        c-RNTI-r16                   RNTI-Value,
        previousPCellId-r16          CHOICE {
            nr-PreviousCell-r16          CGI-Info-Logging-r16,
            eutra-PreviousCell-r16       CGI-InfoEUTRALogging
        }                                                        OPTIONAL,
        failedPCellId-r16            CHOICE {
            nr-FailedPCellId-r16         CHOICE {
                cellGlobalId-r16             CGI-Info-Logging-r16,
                pci-arfcn-r16                SEQUENCE {
                    physCellId-r16               PhysCellId,
                    carrierFreq-r16              ARFCN-ValueNR
                }
            },
            eutra-FailedPCellId-r16      CHOICE { ... }
        },
        reconnectCellId-r16          CHOICE { ... }              OPTIONAL,
        timeUntilReconnection-r16    TimeUntilReconnection-r16   OPTIONAL,
        reestablishmentCellId-r16    CGI-Info-Logging-r16        OPTIONAL,
        timeConnFailure-r16          INTEGER (0..1023),  -- x 100 ms
        timeSinceFailure-r16         TimeSinceFailure-r16,
        connectionFailureType-r16    ENUMERATED {rlf, hof},
        rlf-Cause-r16                ENUMERATED {t310-Expiry,
                                        randomAccessProblem,
                                        rlc-MaxNumRetx,
                                        beamFailureRecoveryFailure,
                                        lbtFailure-r16,
                                        bh-rlfRecoveryFailure, ...},
        locationInfo-r16             LocationInfo-r16            OPTIONAL,
        noSuitableCellFound-r16      ENUMERATED {true}           OPTIONAL,
        ra-InformationCommon-r16     RA-InformationCommon-r16    OPTIONAL,
        ...
    },
    eutra-RLF-Report-r16 SEQUENCE { ... }
}

Listing 4. RLF-Report, abridged from TS 38.331 (Rel-16). Field presence is conditional: timeConnFailure only appears when there had been a handover, and noSuitableCellFound only when T311 expired.

17. Illustrative Message Traces

🔍

About These Traces

Illustrative trace. Field names and encodings follow 3GPP; the values are constructed for this document and are not a capture from any deployed or lab network.

17.1 The configuration the UE starts from

[RRC] SIB1 UE-TimersAndConstants + RLM configuration

SIB1
 ue-TimersAndConstants
  t300 ......................... ms1000
  t301 ......................... ms1000
  t310 ......................... ms1000
  n310 ......................... n4
  t311 ......................... ms3000
  n311 ......................... n1
  t319 ......................... ms1000

RRCReconfiguration
 masterCellGroup
  rlf-TimersAndConstants setup                 -- overrides SIB1 for the MCG
   t310 ........................ ms1000
   n310 ........................ n4
   n311 ........................ n1
   t311-v1530 .................. ms3000
  spCellConfig / spCellConfigDedicated
   radioLinkMonitoringConfig setup
    failureDetectionResourcesToAddModList
     [0] radioLinkMonitoringRS-Id .. 0
         purpose .................. both        -- feeds RLM AND beam failure
         detectionResource ssb-Index 2
    beamFailureInstanceMaxCount ... n4
    beamFailureDetectionTimer ..... pbfd2

-- derived by the UE, not signalled:
--   RLM-RS  = SSB 2, evaluated against Q_out (10%) and Q_in (2%)
--   BFD-RS  = SSB 2, evaluated against Q_out only
--   one measurement stream, two independent counters

Listing 5. purpose = both in action: one SSB driving the RLM counters and the beam failure counter at the same time, against different threshold sets.

17.2 A fade the UE survives

[PHY/RRC] out-of-sync run, recovered by N311

-- C-RNTI 0x4C7A, PCI 231, 30 kHz SCS

11:03:52.410  [PHY] RLM eval  SSB2 hyp-PDCCH BLER 1.1%  -> better than Q_in
              -> in-sync indication
11:03:52.640  [PHY] entering underpass, SSB2 SINR falling
11:03:52.840  [PHY] RLM eval  SSB2 hyp-PDCCH BLER 22%   -> worse than Q_out
              -> out-of-sync indication #1
11:03:52.850  [PHY] out-of-sync #2
11:03:52.860  [PHY] out-of-sync #3
11:03:52.870  [PHY] out-of-sync #4
11:03:52.870  [RRC] N310 (n4) reached, no gating timer running
              -> start T310 (ms1000), expires 11:03:53.870
11:03:52.910  [PHY] out-of-sync #5 .. #17    (T310 unaffected)
11:03:53.080  [PHY] RLM eval  SSB2 hyp-PDCCH BLER 1.6%  -> better than Q_in
              -> in-sync indication #1
11:03:53.080  [RRC] N311 (n1) reached while T310 running
              -> stop T310  (had run 210 ms of 1000 ms)
11:03:53.080  [RRC] no RLF; connection continues on PCI 231

-- 17 out-of-sync indications and no failure. With N311 = n10 this UE
-- would have needed 10 consecutive in-syncs and would have failed.

Listing 6. The hysteresis doing its job. Note that out-of-sync indications 5 to 17 change nothing — T310 is already running and only an in-sync run can stop it.

17.3 The same fade, not survived

[RRC/MAC] T310 expiry to restored user plane

11:14:08.120  [PHY] out-of-sync #1 .. #4
11:14:08.150  [RRC] N310 (n4) reached -> start T310 (ms1000)
11:14:08.150  [PHY] out-of-sync continuing, no in-sync at all
11:14:09.150  [RRC] T310 EXPIRY
11:14:09.150  [RRC] AS security activated: yes
                    SRB2 established: yes    DRB(s) established: 2
              -> RADIO LINK FAILURE, initiate re-establishment
11:14:09.150  [RRC] suspend all RBs except SRB0
11:14:09.150  [MAC] MAC reset: HARQ buffers flushed, timeAlignmentTimer
                    considered expired, SR and BSR cancelled
11:14:09.151  [RRC] release spCellConfig; release 1 MCG SCell
11:14:09.151  [RRC] start T311 (ms3000); begin cell selection

11:14:09.398  [RRC] cell selection complete: PCI 118, ARFCN 632628 suitable
11:14:09.398  [RRC] stop T311 (used 247 of 3000 ms); start T301 (ms1000)
11:14:09.400  [MAC] RA initiated  trigger=rrcReestablishment  CBRA
11:14:09.418  [MAC] MSG3 on PUSCH, TC-RNTI 0x2E14, 6 octets (48 bits)
              RRCReestablishmentRequest
                ue-Identity
                  c-RNTI ................. 0x4C7A     -- from PCI 231
                  physCellId ............. 231        -- the failed cell
                  shortMAC-I ............. 0x9E41
                reestablishmentCause ..... otherFailure
                spare .................... 0

11:14:09.432  [RRC-DL] RRCReestablishment on SRB1
                rrc-TransactionIdentifier .. 1
                nextHopChainingCount ....... 3        -> derive new K_gNB
11:14:09.432  [RRC] stop T301; re-establish PDCP for SRB1; resume SRB1
              -- SRB2 and both DRBs remain SUSPENDED
11:14:09.447  [RRC-UL] RRCReestablishmentComplete
                ue-MeasurementsAvailable
                  rlf-InfoAvailable ........ true
11:14:09.489  [RRC-DL] RRCReconfiguration
                radioBearerConfig: srb2, drb1, drb2 resumed
11:14:09.501  [RRC-UL] RRCReconfigurationComplete
              -- user plane restored; outage from 11:14:08.150 = 1351 ms

Listing 7. The full sequence with the timers annotated. The outage is measured to the reconfiguration, not to the RRCReestablishmentComplete — SRB2 and the DRBs are suspended until then.

17.4 The RLF report handed over afterwards

[RRC] UEInformationRequest / Response with rlf-Report

11:14:14.020  [RRC-DL] UEInformationRequest
                rlf-ReportReq ............ true
                ra-ReportReq ............. true

11:14:14.061  [RRC-UL] UEInformationResponse
  rlf-Report  nr-RLF-Report
    measResultLastServCell
      cellResults resultsSSB-Cell
        rsrp ......................... 41       -- RSRP-Range -> -116 dBm
        rsrq ......................... 18       -- -31.5 dB
        sinr ......................... 22       -- -12.0 dB
      rsIndexResults resultsSSB-Indexes
        ssbIndex 2  rsrp 41 | ssbIndex 5  rsrp 38 | ssbIndex 9  rsrp 33
      ssbRLMConfigBitmap ............ 0x0400000000000000  -- SSB 2 only
    measResultNeighCells measResultListNR
      [0] physCellId 118  rsrp 62   -- -95 dBm, the cell we reconnected on
      [1] physCellId 407  rsrp 44   -- -113 dBm
    c-RNTI ........................... 0x4C7A
    previousPCellId nr-PreviousCell
      plmn-Identity ... (operator)   cellIdentity 0x00A1B4C21
    failedPCellId nr-FailedPCellId cellGlobalId
      plmn-Identity ... (operator)   cellIdentity 0x00A1B4C33   -- PCI 231
    reconnectCellId nr-Reconnect
      plmn-Identity ... (operator)   cellIdentity 0x00A1B4C41   -- PCI 118
    reestablishmentCellId ............ 0x00A1B4C41
    timeConnFailure .................. 47       -- x100 ms = 4.7 s
    timeSinceFailure ................. 5        -- seconds
    connectionFailureType ............ rlf
    rlf-Cause ........................ t310-Expiry
    ra-InformationCommon
      numberOfPreamblesSentOnSSB ..... 2
      contentionDetected ............. false

-- reading: RSRP -116 dBm and SINR -12 dB on the failed cell, neighbour
-- PCI 118 at -95 dBm, and timeConnFailure 4.7 s. The UE arrived on PCI 231
-- 4.7 s earlier, the cell degraded, a 21 dB better neighbour was visible,
-- and no handover was commanded: a TOO-LATE HANDOVER, not a coverage hole.

Listing 8. A complete RLF report, decoded, with the conclusion spelled out. The neighbour measurement and timeConnFailure together are what make the diagnosis unambiguous.

17.5 A failure path: RLF with no RLM involvement at all

[RLC/RRC] RLF from maxRetxThreshold

-- no out-of-sync indications anywhere in this window

13:22:41.008  [RLC-UL] DRB1 AM: PDU SN 412 retransmitted, RETX_COUNT 1
13:22:41.096  [RLC-UL] DRB1 AM: PDU SN 412 retransmitted, RETX_COUNT 2
13:22:41.184  [PHY-UL] PUSCH power 23.0 dBm (P_CMAX) -- headroom exhausted
                       ... retransmissions 3..7 elided, all at P_CMAX ...
13:22:41.712  [RLC-UL] DRB1 AM: PDU SN 412 retransmitted, RETX_COUNT 8
13:22:41.712  [RLC-UL] RETX_COUNT = maxRetxThreshold (t8)
13:22:41.712  [RLC]    -> indicate max retransmissions reached to RRC
13:22:41.712  [RRC]    MCG RLC max retransmissions
              -> RADIO LINK FAILURE  (no gating timer applies to this trigger)
13:22:41.712  [RRC]    security active, SRB2 + DRBs up -> re-establish

-- and in the RLF report delivered later:
    connectionFailureType ............ rlf
    rlf-Cause ........................ rlc-MaxNumRetx
    measResultLastServCell
      rsrp ........................... 68       -- -89 dBm, HEALTHY
      sinr ........................... 68       -- +11.0 dB, HEALTHY

-- the downlink was fine throughout. This is an UPLINK failure: the UE was
-- at P_CMAX and its PDUs were not arriving. Look at power headroom and at
-- timing advance, not at downlink coverage.

Listing 9. The trigger that produces an RLF with a perfect downlink. The RLF report's own measurements are what rule out the obvious explanation.

🔍

What You See In Logs

17.5 is the trace to remember. Every downlink indicator in it is healthy, there is not one out-of-sync indication, and the connection still fails. If your first move on an RLF is to look at RSRP, this is the case that will waste your afternoon — and rlf-Cause would have told you in one field. Read rlf-Cause first, always.

18. Release Deltas: Rel-15 to Rel-18

Release	Change	Why it matters when reading RLM and RLF
Rel-15	RLM on the SpCell with `Q_in` / `Q_out`; `N310`/`T310`/`N311`; RLF from `T310` expiry, Random Access problem and RLC `maxRetxThreshold`; re-establishment with `T311` and `T301`; `SCGFailureInformation`	The baseline. Everything in §1 to §10 and §13 is Rel-15.
Rel-15	`RadioLinkMonitoringConfig` with `purpose` = `rlf`/`beamFailure`/`both`	One reference signal can drive two independent state machines (§2).
Rel-16	RLF report (`RLF-Report`, `VarRLF-Report`, `rlf-ReportReq`, `rlf-InfoAvailable`)	NR gains a black box. Before Rel-16 the UE's side of a failure was simply unavailable (§11).
Rel-16	Fast MCG recovery: `MCGFailureInformation`, `T316`, `mcg-FastRecovery`	An MCG failure no longer always means re-establishment, if the UE has a working SCG (§12).
Rel-16	Consistent uplink LBT failure as an RLF trigger, with `lbt-FailureInstanceMaxCount` and `lbt-FailureDetectionTimer`	An RLF can now be a channel access failure on unlicensed spectrum, with no radio problem at all (§6).
Rel-16	BH RLF for IAB: RLF declared on a BAP-layer backhaul failure indication	An IAB-node can declare RLF because its parent lost a link, not because of anything on its own access link.
Rel-16	`T312` and conditional handover; `t312-Expiry` added to the SCG and MCG failure types	A new way for a mobility procedure to fail, reported alongside the classic ones.
Rel-16	SCell beam failure recovery, and `beamFailureRecoveryFailure` as a reported failure type	Beam-level and cell-level failure become explicitly linked in the reporting. See the companion 12 Beam Failure Recovery document.
Rel-17	RedCap: reduced antennas and relaxed RRM requirements; extended DRX	Evaluation periods lengthen substantially, so the same `n310` and `t310` give much slower detection on a RedCap UE (§4).
Rel-17	NTN: very long propagation delays and relaxed timers	`T310` and `T311` sized for terrestrial geometry do not transfer to a satellite deployment.
Rel-17	RLF report extensions for SON and MDT, including further mobility-failure discrimination	More of the too-early / too-late / wrong-cell classification is available directly from the report.
Rel-18	L1/L2-triggered mobility (LTM), network energy saving (cell DTX/DRX), further SON/MDT enhancements	A cell that is deliberately not transmitting reference signals looks like a fading cell to RLM. Check for cell DTX before believing a coverage story. See the companion 11 DRX document.

Table 16. RLM and RLF changes by release. The Rel-16 RLF report is the one that changed day-to-day practice; confirm support against the UE capability exchange — see the companion 26 UE Capability document.

19. Reading RLM and RLF in Logs: A Checklist

1. Read rlf-Cause before anything else. It tells you in one field whether you are looking at a downlink problem (t310-Expiry), an uplink problem (rlc-MaxNumRetx), an access problem (randomAccessProblem), a channel-access problem (lbtFailure) or a backhaul problem (bh-rlfRecoveryFailure). Everything downstream is interpreted differently (§6, §17.5).

2. Then read connectionFailureType. rlf and hof have different causes and different fixes. Do not aggregate them (§13).

3. Then timeConnFailure. Small means the failure followed a handover closely — too-early or wrong-cell. Large means the handover was fine. Absent means there was no handover at all (§11.2).

4. Check the serving-cell measurements in the report against your assumption. Strong RSRP with a failure is the signal to stop looking at coverage. Look at SINR next, then at the uplink.

5. Do not correlate out-of-sync indications with RSRP. The thresholds are hypothetical PDCCH BLER, not power (§3). Correlate with SINR and with PDCCH decode statistics.

6. Check whether the out-of-syncs were consecutive. Hundreds of non-consecutive out-of-syncs never start T310 and are not a fault (§5).

7. Find out which t310 and n310 were actually in force. SIB1 and rlf-TimersAndConstants can disagree, and the dedicated values win (§14).

8. Add the evaluation period to your detection-time arithmetic. N310 x 10 ms + T310 understates detection by 200 ms or more, and by considerably more under long DRX cycles or long SSB periodicities (§4).

9. Check which gating timers were running. A Random Access problem while T304 runs is a handover failure, not an RLF; while T300 runs it is a connection establishment failure (§6).

10. Confirm the outcome branch. An RLF that went straight to RRC_IDLE is correct behaviour if security was not active or SRB2 and a DRB were not up. Read the release cause (§7).

11. Measure the outage to the RRCReconfiguration, not to the RRCReestablishmentComplete. SRB2 and the DRBs are suspended until then (§10).

12. Look for RRCSetup in answer to a re-establishment request. It silently costs a NAS registration and it means either an Xn context retrieval failure or a shortMAC-I mismatch (§9.1, §10).

13. Verify that RLF reports are being collected at all. If nothing sends UEInformationRequest with rlf-ReportReq, the UE side of every failure is being discarded after 48 hours (§11.1).

20. Glossary

Term	Expansion	Meaning in this document
RLM	Radio Link Monitoring	The continuous PHY evaluation of the SpCell downlink against `Q_in` and `Q_out`, and the indications it produces (§1-§4).
RLF	Radio Link Failure	The RRC-level declaration that the connection is unusable, from any of five triggers (§6).
Q_out	--	10% hypothetical PDCCH BLER. Crossing it produces an out-of-sync indication (§3).
Q_in	--	2% hypothetical PDCCH BLER. Crossing it produces an in-sync indication.
Hypothetical PDCCH	--	A reference PDCCH configuration defined in TS 38.133 against which the UE predicts a BLER. RLM is defined on it, not on RSRP — §3.
`N310` / `N311`	--	Counts of consecutive out-of-sync / in-sync indications needed to start / stop `T310`.
T310	--	The grace period between reaching `N310` and declaring RLF. Dominates the outage (§10).
T311	--	The budget for cell selection during re-establishment (§8).
T301	--	The budget for the re-establishment exchange itself (§10).
T316	--	Rel-16: the budget for fast MCG recovery over the SCG (§12).
shortMAC-I	--	16 bits proving the sender knew the source cell's integrity key, bound to a specific target cell (§9.1).
Re-establishment	--	The procedure that moves an existing connection to a new cell, keeping the security context and bearer configuration.
Fallback to setup	--	Receiving `RRCSetup` in answer to a re-establishment request: the UE connects, but with nothing preserved (§10).
RLF report	--	`VarRLF-Report`, retrieved by `UEInformationRequest`. The UE's account of the failure, kept for 48 hours (§11).
timeConnFailure	--	Time from the last handover initialisation to the failure, in units of 100 ms. The too-early / too-late discriminator (§11.2).
HOF	Handover Failure	`T304` expiry during a `reconfigurationWithSync`. Reported as `connectionFailureType = hof` (§13).
SpCell	Special Cell	The PCell of the MCG or the PSCell of an SCG — the only cells RLM runs on (§1).

21. References

3GPP TS 38.331 — RRC protocol specification. Clause 5.3.7 (RRC connection re-establishment, T311, T301, cell selection, the RRCSetup fallback), 5.3.10 (radio link failure related actions: the N310/T310/N311 machine and the five RLF triggers), 5.3.10.3 (RLF declaration and its three outcomes), 5.7.3 (UEInformationRequest / UEInformationResponse), 5.7.10 (RLF report contents and the 48-hour retention rule); IEs UE-TimersAndConstants, RLF-TimersAndConstants, RadioLinkMonitoringConfig, RadioLinkMonitoringRS, ReestabUE-Identity, VarShortMAC-Input, RLF-Report, FailureReportSCG, FailureReportMCG.
3GPP TS 38.213 — Physical layer procedures for control. Clause 5 (radio link monitoring: the RLM-RS determination, implicit derivation, and the cap on how many RLM-RS the UE must evaluate).
3GPP TS 38.133 — Requirements for support of radio resource management. The hypothetical PDCCH used to define Q_in and Q_out, the threshold pairs, and the out-of-sync and in-sync evaluation periods including their scaling with DRX and reference signal periodicity.
3GPP TS 38.321 — NR MAC protocol specification. Clause 5.1.4 (Random Access problem indication), the MAC reset actions performed on re-establishment, and the Rel-16 consistent LBT failure detection and recovery procedure.
3GPP TS 38.322 — NR RLC protocol specification. maxRetxThreshold and the indication to RRC that the maximum number of retransmissions has been reached.
3GPP TS 38.304 — UE procedures in Idle and Inactive. The cell selection and cell suitability rules the UE applies during T311.
3GPP TS 38.340 — Backhaul Adaptation Protocol. The BH RLF indication that triggers RLF on an IAB-node.
3GPP TS 38.300 — NR overall description. Clause 9.2.7 and the radio link failure overview, and the place of re-establishment in the mobility picture.

Companion documents in this set

01 Registration Process — what the UE has to redo when re-establishment falls back to RRCSetup.
03 Random Access — the CBRA that carries RRCReestablishmentRequest, and the preambleTransMax exhaustion that is itself an RLF trigger.
04 Timing Advance — a drifted or lost timing advance is a common cause of the uplink failures that reach maxRetxThreshold.
11 DRX — long DRX cycles lengthen the RLM evaluation periods and so slow RLF detection.
12 Beam Failure Recovery — the beam-level layer that usually prevents T310 from ever expiring, and the shared reference signals and thresholds.
13 RRC Overview / 15 RRC Procedures — where re-establishment sits among the other RRC procedures.
14 RRC States — the state transitions of §10 in their wider context.
17 System Information / 18 MIB and SIB1 IEs — where UE-TimersAndConstants is broadcast.
20 Measurements and Events — the neighbour measurements in the RLF report, and the A3 thresholds that should have produced a handover.
22 Handover Overview / 25 Conditional HO and DAPS — handover failure, T304, and the DAPS case where the UE reverts to the source instead of re-establishing.
26 UE Capability — where RLF report, fast MCG recovery and NR-U support is declared.