SCGFailureInformation in 5G NSA: Secondary Cell Group Failure Diagnosis

SCGFailureInformation is the LTE RRC message that reports a 5G NR secondary cell group failure in EN-DC (E-UTRA NR Dual Connectivity) mode. It is the definitive evidence of a 5G connection failure in NSA deployments — and the starting point for diagnosing why the 5G NR leg was lost.

Unlike Radio Link Failure on the LTE master, an SCG failure does not immediately interrupt service: the UE retains its LTE connection and falls back to LTE-only while the eNB decides what to do next. Understanding the failureType and the measurement results inside SCGFailureInformation is the fastest path to root cause analysis for 5G instability in NSA deployments.

Technical Reference

SCGFailureInformation Message Structure

SCGFailureInformation-v1590-IEs (3GPP TS 38.331 §6.3.4)
├── criticalExtensions
│   └── c1
│       └── scgFailureInformation
│           ├── failureType                  -- WHY the SCG failed
│           │   ENUMERATED {
│           │     t310-Expiry,              -- RLF timer expired on NR
│           │     randomAccessProblem,      -- RACH failed on NR PSCell
│           │     rlcMaxNumRetx,            -- RLC gave up on NR
│           │     scg-ChangeFailure,        -- NR PSCell change failed
│           │     scg-lbtFailure,           -- NR-U LBT failure
│           │     beamFailureRecoveryFailure -- mmWave beam recovery failed
│           │   }
│           └── measResultSCG               -- NR measurements at failure time
│               ├── measResultServingCell   -- NR PSCell measurements
│               │   ├── ss-RSRP
│               │   └── ss-SINR
│               └── measResultNeighCells    -- NR neighbors at failure time

Failure Type 1: t310-Expiry — NR Coverage Loss

The most common SCG failure type. Timer T310 is started when the UE detects N310 consecutive out-of-sync indications (OOS) from the NR PSCell’s Physical Downlink Control Channel (PDCCH). If in-sync indications (N311) are not received before T310 expires, the UE declares NR Radio Link Failure and sends SCGFailureInformation with failureType = t310-Expiry.

Standard values (3GPP TS 38.331): N310 = 1 to 20, T310 = 0 to 2000 ms, N311 = 1 to 10.

What to look for in the log:

• measResultSCG shows NR PSCell SS-RSRP significantly below serving threshold (typically < -110 dBm) at the time of failure
• NR PDCCH BLER (Block Error Rate) in the NR PHY log shows rapid degradation preceding the SCGFailureInformation

Root cause scenarios: UE moved out of NR coverage (NR cell edge). NR beam handover failed (mmWave deployment). Inter-cell handover on the NR layer failed (PSCell change).

Failure Type 2: randomAccessProblem — RACH Failure on NR

The UE attempted random access on the NR PSCell — during the initial SCG addition (after B1 event), during a Scheduling Request on NR, or during beam failure recovery — and the maximum number of RACH attempts (preambleTransMax) was reached without receiving a Random Access Response (RAR).

What to look for in the log:

• SCGFailureInformation sent shortly after the LTE RRC Reconfiguration that added the NR SCG (< 1 second after SCG config)
• NR RACH log (if available): multiple preamble transmissions with no RAR received
• measResultSCG shows NR PSCell SS-RSRP in the acceptable range (> -100 dBm) but SS-SINR is poor (< 0 dB), suggesting interference rather than coverage loss

Root cause scenarios: NR PRACH configuration mismatch (preamble format, root sequence index). NR cell is not actually transmitting (configuration error at gNB). Uplink interference on the NR layer preventing RAR reception.

Failure Type 3: rlcMaxNumRetx — NR Channel Persistent Errors

The NR RLC (Radio Link Control) layer reached the maximum number of retransmissions (maxRetxThreshold in the AM RLC configuration) for an NR PDCP/RLC PDU without receiving an acknowledgment. This means the NR uplink channel has persistent errors that the HARQ and RLC retransmission mechanisms cannot correct.

What to look for in the log:

• SCGFailureInformation arrives later in the call (not immediately after SCG addition) — channel degraded over time
• NR PDSCH BLER in the NR MAC log shows sustained high BLER (> 30%) before the failure
• measResultSCG shows gradual SS-RSRP decline preceding the failure

Root cause scenarios: UE moved to the edge of NR coverage over time. Interference grew (new interfering device, time-of-day change). NR beam switched to a weaker beam without successful beam management.

Failure Type 4: beamFailureRecoveryFailure — mmWave Beam Loss

Specific to FR2 (mmWave) and some FR1 deployments with narrow beamforming. When the UE detects sustained low PDCCH quality from the serving beam (beam failure declaration), it attempts beam failure recovery by selecting a candidate beam and triggering a RACH attempt. If the maximum number of beam failure recovery attempts is reached without success (maxNumIter-BFR), the UE sends SCGFailureInformation with beamFailureRecoveryFailure.

What to look for in the log:

• NR Beam Management log: multiple candidateBeamRS attempts before failure
• measResultSCG: SS-SINR very poor (< -5 dB) despite the NR cell being present (SS-RSRP may still be detectable)
• Rapid signal drops typical of mmWave blockage (body blockage, moving objects)

Step-by-Step Field Diagnosis

Step 1 — Confirm SCGFailureInformation in the LTE RRC log. In the LTE UL-DCCH log, locate the SCGFailureInformation message. Record the failureType IE value — this identifies the failure category immediately.

Step 2 — Read measResultSCG at failure time. Extract SS-RSRP and SS-SINR of the NR PSCell from the measResultSCG IE. Apply the conversion formula (SS-RSRP: raw value - 157 dBm, SS-SINR: raw value / 2 - 23 dB). This gives the NR signal level at the moment of failure.

Step 3 — Correlate with NR RF Monitor. Cross-reference measResultSCG values with the NR RF Monitor time series at the same timestamp. A sudden drop in NR SS-RSRP immediately before SCGFailureInformation confirms coverage loss (t310-Expiry). A sustained poor SS-SINR suggests interference (rlcMaxNumRetx).

Step 4 — Check what preceded the failure. Scan backward in the LTE RRC log:

• If SCGFailureInformation follows immediately after an LTE RRC Reconfiguration adding the SCG: randomAccessProblem or scg-ChangeFailure (setup failure)
• If the SCG was active for seconds or minutes before failure: t310-Expiry, rlcMaxNumRetx, or beamFailureRecoveryFailure (runtime failure)

Step 5 — Observe eNB response. After SCGFailureInformation, the LTE eNB may send: (a) a new RRC Reconfiguration re-adding the SCG (eNB decided to retry), (b) an RRC Reconfiguration removing the SCG without reoffer (eNB gave up on NR), or (c) no response (eNB deferred the retry decision). The eNB’s decision reveals whether the failure was treated as transient or persistent.

SCGFailureInformation vs. SCGFailureInformationNR

3GPP TS 36.331 (LTE RRC) defines SCGFailureInformation — the LTE UL-DCCH message sent to the eNB for NR SCG failures in EN-DC. 3GPP TS 38.331 (NR RRC) defines SCGFailureInformationNR — a related message used in NR-NR dual connectivity (NR master + NR secondary) for secondary cell group failures. In the field, EN-DC (NSA) deployments use the LTE variant exclusively. SCGFailureInformationNR appears only in 5G SA multi-RAT dual connectivity scenarios.

Capturing SCGFailureInformation in the Field

SCGFailureInformation is captured in the LTE RRC OTA log. Look for UL-DCCH messages on LTE SRB1 with message type SCGFailureInformation. The failureType and measResultSCG IEs are decoded as ASN.1 PER structure. Simultaneously, capture the NR PDCCH/PDSCH log (NR PHY OTA) for BLER and RACH attempt data to cross-reference with the failure type.

Related Messages

• MeasurementReport (B1 event) — the LTE trigger for SCG addition that precedes a successful EN-DC connection
• RRC Reconfiguration (NR SCG config) — the message that adds the NR leg, after which SCGFailureInformation may appear
• RRC Reconfiguration (SCG release) — the eNB’s response after acknowledging the SCG failure
• RLF-Report — sent after LTE master cell Radio Link Failure (distinct from SCG failure which keeps LTE active)