Telecom engineering reference for protocols, messages, call flows, troubleshooting, releases, and tools.
Menu
RRC5GUE -> gNB3GPP TS 38.331
5G NR - Failure Information
Failure Information is the NR RRC message the UE uses to inform the network that it has detected a failure, especially an RLC bearer failure associated with an MCG or SCG bearer.
Message Fact Sheet
Protocol
rrc
Network
5g
Spec
3GPP TS 38.331
Spec Section
5.7.5, 6.2.2
Direction
UE -> gNB
Message Type
Failure Reporting / Bearer Diagnostics
Full message name
5G NR - Failure Information
Protocol
RRC
Technology
5G
Direction
UE -> gNB
Interface
Uu
Signaling bearer / channel
SRB1 or SRB3 / UL-DCCH
Typical trigger
Sent when the UE detects a bearer-related failure and needs to inform the network of the failing logical channel and cell-group context.
Main purpose
Provides the network with UE-detected failure information so bearer, mobility, and dual-connectivity issues can be diagnosed and handled.
Failure Information is the NR RRC message the UE uses to inform the network that it has detected a failure, especially an RLC bearer failure associated with an MCG or SCG bearer.
Provides the network with UE-detected failure information so bearer, mobility, and dual-connectivity issues can be diagnosed and handled.
Why this message matters
Failure Information is the UE telling the network that a specific bearer failed and identifying where that failure happened.
Where this message appears in the call flow
Bearer Failure Reporting
Call flow position: Sent when the UE needs to report a detected bearer failure toward the network.
Typical state: UE is connected and a bearer failure has been identified.
Preconditions:
AS security is active.
The UE can identify the failing bearer and associated cell group.
Next likely message: Network-side recovery or reconfiguration action
MR-DC Failure Handling
Call flow position: Relevant when the failure concerns an SCG bearer and transport may require SRB3 or ULInformationTransferMRDC handling.
Typical state: UE is in a dual-connectivity related context where MCG and SCG bearer ownership matters.
Preconditions:
The failing bearer belongs to the relevant MCG or SCG context.
Next likely message: Recovery signaling, bearer reconfiguration, or later release/correction action
Next message(s):RRC Reconfiguration, Bearer recovery action, Continued failure handling or mobility correction
Message direction and transport
Sender and receiver: UE -> gNB
Interface: Uu
Domain: Access-side failure reporting and bearer continuity diagnostics
Signaling bearer: SRB1 or SRB3
Logical channel: UL-DCCH
Transport / encapsulation: Dedicated RRC signaling over SRB1 or SRB3, or embedded in ULInformationTransferMRDC when required by MR-DC transport handling
Security context: Sent as protected connected-mode RRC signaling after AS security is active and usually interpreted together with bearer and cell-group context.
Message Structure Overview
Failure Information is a compact UE-to-network reporting message.
Its practical value is not in complex nesting, but in clearly telling the network which bearer failed, in which cell group, and what failure type was detected.
When used in MR-DC scenarios, the transport path itself becomes part of the engineering interpretation because SRB1, SRB3, or ULInformationTransferMRDC may be involved.
The ASN.1 is small. The main engineering task is to map the reported cellGroupId and logicalChannelIdentity back to the actual bearer and recovery context.
cellGroupId tells you whether the failing bearer belongs to the relevant MCG or SCG context.
logicalChannelIdentity is the first key field to correlate with the configured bearer map.
The message by itself reports the failure; the root cause still needs correlation with RLC, bearer, and mobility traces.
Important Information Elements
IE
Required
Description
failureInfoRLC-Bearer
Yes
Core payload describing the failing bearer.
cellGroupId
Yes
Identifies whether the failing bearer belongs to the relevant MCG or SCG context.
logicalChannelIdentity
Yes
Identifies the logical channel of the failing bearer.
failureType
Yes
Indicates the type of detected failure, such as rlc-failure.
Detailed field explanation
failureInfoRLC-Bearer
Core payload describing the failing bearer.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
cellGroupId
Identifies whether the failing bearer belongs to the relevant MCG or SCG context.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
logicalChannelIdentity
Identifies the logical channel of the failing bearer.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
failureType
Indicates the type of detected failure, such as rlc-failure.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
What to check in logs and traces
Check whether the failure was reported on SRB1, SRB3, or through MR-DC wrapping logic.
Map logicalChannelIdentity to the actual bearer configuration.
Verify which cell group the bearer belongs to through cellGroupId.
Correlate the reported failure with recent RRC Reconfiguration history and bearer changes.
Inspect RLC behavior and any preceding bearer stall, retransmission exhaustion, or continuity break.
If the issue occurs in MR-DC, check whether the failure belongs to MCG or SCG and whether transport of the report matches that context.
Common Issues and Troubleshooting
Failure Information is sent repeatedly.
Likely cause: The underlying bearer issue may persist and recovery may not have resolved it.
What to inspect: Check the same logical channel and bearer configuration over time.
Next step: Correlate with RLC behavior and the network's attempted recovery action.
Failure Information appears, but no useful recovery action follows.
Likely cause: The network may receive the indication but not map it correctly to the right bearer or recovery workflow.
What to inspect: Check cellGroupId, logicalChannelIdentity, and later network response.
Next step: Validate bearer mapping and reconfiguration logic.
The reported bearer does not match the engineer's expectation.
Likely cause: The active bearer map may have changed or the wrong bearer is assumed in analysis.
What to inspect: Check recent RRC Reconfiguration history and the live logical-channel mapping.
Next step: Rebuild the bearer context before concluding the message is wrong.
LTE / 5G / Variant Comparison
Failure Information versus UE Information Response
Failure Information immediately reports a detected failure. UE Information Response returns broader diagnostic information when the network explicitly requests it.
Failure Information versus RRC Reestablishment Request
RRC Reestablishment Request is about recovering the RRC connection after failure. Failure Information reports a detected bearer failure while connected.
FAQ
What is Failure Information in 5G NR?
Failure Information is the NR RRC message the UE uses to inform the network that it detected a failure, especially a bearer-related failure.
Who sends Failure Information?
The UE sends Failure Information to the network.
What is the most important IE in Failure Information?
failureInfoRLC-Bearer, because it identifies the failing bearer context.
Does Failure Information carry a reject cause?
No. The practical failure indicator is the reported failing bearer information and failureType.
Is Failure Information the same as RRC Reestablishment Request?
No. Failure Information reports a detected bearer failure, while RRC Reestablishment Request is used to recover the RRC connection after certain failures.
Why is Failure Information useful in troubleshooting?
Because it tells engineers which bearer failed, in which cell group, and helps anchor deeper RLC and bearer continuity analysis.
Decode this message with the 3GPP Decoder, inspect the related message database, or open the matching call flow to see where this signaling step fits in the full procedure.