Telecom engineering reference for protocols, messages, call flows, troubleshooting, releases, and tools.
Menu
RRC5GUE -> gNB3GPP TS 38.331
5G NR - UE Information Response
UE Information Response is the NR RRC message the UE uses to return requested diagnostic information such as RLF data, connection establishment failure data, logged measurements, mobility history, random access reports, or idle and inactive measurement information.
Message Fact Sheet
Protocol
rrc
Network
5g
Spec
3GPP TS 38.331
Spec Section
5.6, 6.2.2
Direction
UE -> gNB
Message Type
Diagnostic / Reporting
Full message name
5G NR - UE Information Response
Protocol
RRC
Technology
5G
Direction
UE -> gNB
Interface
Uu
Signaling bearer / channel
SRB1 / UL-DCCH
Typical trigger
Sent after the UE receives UE Information Request and has one or more requested report types available to return.
Main purpose
Returns UE-side diagnostic or historical information requested by the network so failures, mobility behavior, measurement history, or access issues can be analyzed.
Main specification
3GPP TS 38.331, 5.6, 6.2.2
Release added
Release 15
Procedures where used
Radio Link Failure Investigation, Connection Establishment Failure Investigation, Mobility Diagnostics, Random Access Diagnostics
Related timers
UE Information Response itself is usually correlated with the earlier request and the surrounding failure or mobility event, Engineers generally troubleshoot the request-response exchange rather than a single dedicated timer
Related cause values
UE Information Response does not carry reject causes, Problems are inferred from missing report contents, empty responses, unsupported report types, or mismatch with the expected diagnostic scenario
What is UE Information Response in simple terms?
UE Information Response is the NR RRC message the UE uses to return requested diagnostic information such as RLF data, connection establishment failure data, logged measurements, mobility history, random access reports, or idle and inactive measurement information.
Returns UE-side diagnostic or historical information requested by the network so failures, mobility behavior, measurement history, or access issues can be analyzed.
Why this message matters
UE Information Response is the UE sending back the diagnostic information the network asked for so failures, mobility, access, or measurement issues can be analyzed.
Where this message appears in the call flow
Radio Link Failure Investigation
Call flow position: Returned after the network requests UE-side failure information.
Typical state: UE is connected or reconnected and able to return stored diagnostic context.
Preconditions:
UE Information Request was received.
Relevant RLF-related information is available in the UE.
Next likely message: No dedicated mandatory follow-up; the network interprets the returned diagnostic data
Mobility and Measurement Diagnostics
Call flow position: Returned when the network asks for logged measurements, mobility history, or idle/inactive measurement information.
Typical state: UE is connected and able to return available history or measurement data.
Preconditions:
UE Information Request requested one or more relevant report types.
Next likely message: Later mobility or optimization decision outside the message itself
Random Access and Connection Failure Analysis
Call flow position: Returned when the network wants UE-side access or setup-failure context.
Typical state: UE is connected and diagnostic investigation is active.
Preconditions:
Requested access or failure data exists in the UE.
Next likely message: Further troubleshooting action rather than a fixed signaling response
Call flow position
Previous message(s):UE Information Request, Failure recovery or diagnostic investigation context, Connected-mode RRC signaling continuity
Next message(s):RRC Reconfiguration, Continued connected-mode signaling, No immediate dedicated follow-up if the network only needed diagnostic data
Message direction and transport
Sender and receiver: UE -> gNB
Interface: Uu
Domain: Access-side RRC diagnostics and failure analysis
Signaling bearer: SRB1
Logical channel: UL-DCCH
Transport / encapsulation: Dedicated RRC signaling on SRB1 over DCCH in connected mode
Security context: Sent as protected connected-mode RRC signaling after AS security activation, usually in reply to UE Information Request.
Message Structure Overview
UE Information Response is a container for one or more returned report types.
Unlike UE Information Request, which only sets request flags, this message carries the actual diagnostic content if the UE has it available.
The message is best interpreted by first checking which report blocks are present and then matching them to the earlier request.
The practical focus is not every nested ASN.1 branch, but which returned report blocks are present and whether they match the earlier UE Information Request.
The returned blocks depend entirely on what the UE had available and what the network requested.
An empty or partial-looking response is not automatically wrong; the UE may simply not have every requested report.
The first question is whether the returned report types align with the earlier UE Information Request.
Important Information Elements
IE
Required
Description
rlf-Report
Optional
Carries radio link failure related information when requested and available.
connEstFailReport
Optional
Carries connection establishment failure information when requested and available.
logMeasReport
Optional
Carries logged measurement information from the UE.
mobilityHistoryReport
Optional
Carries UE mobility history information.
ra-Report-r16
Optional
Carries random access related diagnostic information.
idleModeMeasurementReport-r16
Optional
Carries idle or inactive measurement information when requested and available.
Detailed field explanation
rlf-Report
Carries radio link failure related information when requested and available.
Presence: Optional
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.
connEstFailReport
Carries connection establishment failure information when requested and available.
Presence: Optional
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.
logMeasReport
Carries logged measurement information from the UE.
Presence: Optional
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.
mobilityHistoryReport
Carries UE mobility history information.
Presence: Optional
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.
ra-Report-r16
Carries random access related diagnostic information.
Presence: Optional
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.
idleModeMeasurementReport-r16
Carries idle or inactive measurement information when requested and available.
Presence: Optional
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
Confirm the message follows a real UE Information Request.
Match the returned report blocks with the flags requested earlier.
Check whether the returned data type fits the real problem under investigation, such as RLF, mobility, or random access.
If a requested report is missing, verify whether the UE would realistically have stored that information.
Correlate returned data with surrounding traces, especially reestablishment, measurement, paging, or initial access traces.
Treat the returned reports as supporting evidence and correlate them with network-side traces before drawing conclusions.
Common Issues and Troubleshooting
UE Information Response is missing.
Likely cause: The UE may not support the requested path, may not stay connected long enough, or the response may be absent from the trace.
What to inspect: Check request-response timing, UE support, and radio continuity.
Next step: Correlate with the failure recovery path before assuming the request was ignored.
UE Information Response is present but one expected report block is missing.
Likely cause: The UE may not have stored that report, or the requested condition may not have occurred.
What to inspect: Check the earlier request flags and whether the underlying event actually happened.
Next step: Validate the scenario assumption before classifying the response as incomplete.
Returned report content does not explain the observed failure.
Likely cause: The root cause may sit outside the specific diagnostic block returned by the UE.
What to inspect: Correlate with measurement, mobility, access, and network-side traces.
Next step: Use the response as one evidence source, not the whole diagnosis.
LTE / 5G / Variant Comparison
UE Information Response versus UE Information Request
UE Information Request tells the UE what reports to send. UE Information Response carries the actual returned diagnostic content.
UE Information Response versus Measurement Report
Measurement Report is normal UE radio feedback for configured events. UE Information Response is on-demand diagnostic data returned after an explicit network request.
FAQ
What is UE Information Response in 5G NR?
It is the NR RRC message the UE sends to return requested diagnostic information such as RLF, connection establishment failure, logged measurements, mobility history, or random access reports.
Who sends UE Information Response?
The UE sends UE Information Response to the network.
What comes before UE Information Response?
UE Information Request.
Does UE Information Response always contain every requested report?
No. It includes only report information the UE actually has available.
Why is UE Information Response useful in troubleshooting?
Because it returns UE-side evidence that can help explain failures, mobility behavior, measurement history, or access issues.
Is UE Information Response the same as Measurement Report?
No. Measurement Report is event-driven radio feedback, while UE Information Response is a diagnostic reply to an explicit request.
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.