Telecom engineering reference for protocols, messages, call flows, troubleshooting, releases, and tools.
Menu
LTE RRCLTEUE -> eNodeB3GPP TS 36.331
LTE RRC UE Information Response r9
Uplink LTE RRC message used by the UE to return the diagnostic information requested by UEInformationRequest-r9, including random access details, radio link failure context, or both.
Message Fact Sheet
Protocol
lte-rrc
Network
lte
Spec
3GPP TS 36.331
Spec Section
5.6.5, 6.2.2
Direction
UE -> eNodeB
Message Type
Diagnostic Report
Full message name
LTE RRC UE Information Response r9
Protocol
LTE-RRC
Technology
LTE
Direction
UE -> eNodeB
Interface
Uu
Signaling bearer / channel
SRB1 / UL-DCCH
Typical trigger
The UE receives UEInformationRequest-r9 and has one or more requested report blocks available to return.
Main purpose
Carries the actual UE-side diagnostic report blocks requested by the network so the eNodeB can read UE-side random access history, radio link failure context, or later extension-based report data.
Main specification
3GPP TS 36.331, 5.6.5, 6.2.2
Release added
Release 9
Procedures where used
UE information procedure, Radio link failure investigation, Random access investigation
What is LTE RRC UE Information Response r9 in simple terms?
Uplink LTE RRC message used by the UE to return the diagnostic information requested by UEInformationRequest-r9, including random access details, radio link failure context, or both.
Carries the actual UE-side diagnostic report blocks requested by the network so the eNodeB can read UE-side random access history, radio link failure context, or later extension-based report data.
Why this message matters
UE Information Response r9 is the LTE UE sending back the diagnostic information the network asked for in UEInformationRequest-r9.
Where this message appears in the call flow
UE information procedure
In the basic LTE UE information procedure, UE Information Response r9 returns the requested report blocks after the earlier network request.
Call flow position: Uplink report-carrying message that completes the basic LTE UE information exchange.
Typical state: UE is in connected mode and returns the requested report blocks on SRB1.
Preconditions:
UEInformationRequest-r9 was received.
The UE has one or more requested report blocks available.
Next likely message: Later connected-mode diagnostic or recovery handling
Radio link failure investigation
In the radio link failure investigation path, UE Information Response r9 returns UE-side RLF context if the UE has the requested information stored.
Call flow position: Diagnostic response that returns UE-side RLF context after the network asks for it.
Typical state: The network is analyzing an earlier failure path and the UE returns stored RLF information if available.
Preconditions:
UEInformationRequest-r9 requested rlf-Report-r9.
The UE has relevant radio link failure information stored.
Next likely message: RLF interpretation or broader recovery analysis
Random access investigation
In the random access investigation path, UE Information Response r9 returns UE-side access details after the network requests them.
Call flow position: Diagnostic response that returns UE-side random access details after the network requests them.
Typical state: The network is analyzing earlier access behavior and the UE returns random access information if available.
Preconditions:
UEInformationRequest-r9 requested rach-Report-r9.
The UE has relevant random access information stored.
Next likely message: Access-history interpretation or later troubleshooting
Next message(s): Later connected-mode analysis, recovery interpretation, or investigation handling
Message direction and transport
Sender and receiver: UE -> eNodeB
Interface: Uu
Domain: Access-side radio control diagnostics
Signaling bearer: SRB1
Logical channel: UL-DCCH
Transport / encapsulation: RRC over DCCH on SRB1 as the report-carrying response to UEInformationRequest-r9 in protected connected mode
Security context: This message is sent in protected connected-mode LTE RRC signaling after successful AS security activation and after the network has requested diagnostic information.
Message Structure Overview
UEInformationResponse-r9 is the report-carrying counterpart to UEInformationRequest-r9.
The useful reading path is which report blocks are actually present and whether they match the earlier request.
In base Release 9 scope, the main returned blocks are random access information and radio link failure information.
The main read is not every nested field. Start by checking which report blocks are present, then compare them with the earlier UEInformationRequest-r9.
Start by checking whether rach-Report-r9, rlf-Report-r9, or both are present.
The transaction identifier should match the earlier UEInformationRequest-r9.
The practical value comes from the returned report content and how it fits the wider recovery or access path.
Important Information Elements
IE
Required
Description
rrc-TransactionIdentifier
Yes
Transaction identifier matching the earlier UEInformationRequest-r9.
criticalExtensions
Yes
Versioned wrapper carrying the UEInformationResponse-r9 payload.
rach-Report-r9
Optional
Returned random access report block when the network requested random access information and the UE has it available.
rlf-Report-r9
Optional
Returned radio link failure report block when the network requested RLF information and the UE has it available.
nonCriticalExtension
Optional
Extension branch used by later releases for additional returned UE information blocks.
Detailed field explanation
rrc-TransactionIdentifier
Transaction identifier matching the earlier UEInformationRequest-r9.
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.
criticalExtensions
Versioned wrapper carrying the UEInformationResponse-r9 payload.
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.
rach-Report-r9
Returned random access report block when the network requested random access information and the UE has it 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.
rlf-Report-r9
Returned radio link failure report block when the network requested RLF information and the UE has it 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.
nonCriticalExtension
Extension branch used by later releases for additional returned UE information blocks.
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 UEInformationRequest-r9.
Verify the transaction identifier matches the earlier request.
Check which report blocks are actually present.
Compare the returned blocks with the requested report types in UEInformationRequest-r9.
Correlate the returned diagnostic data with earlier access, failure, or recovery behavior.
Common Issues and Troubleshooting
UE Information Response r9 appears but the expected report block is missing.
Likely cause: The UE may not have had the requested report information available even though the network requested it.
What to inspect: Check the earlier UEInformationRequest-r9 and compare the requested flags with the returned blocks.
Next step: Treat the missing report block as a clue about what diagnostic context the UE did or did not store.
The response returns RLF data, but the failure path is still unclear.
Likely cause: The returned report needs to be correlated with the earlier failure, re-establishment, and connected recovery sequence.
What to inspect: Read the returned rlf-Report-r9 alongside re-establishment, release, or recovery behavior.
Next step: Use the response as supporting evidence rather than reading it in isolation.
The response returns random access details unexpectedly.
Likely cause: The network is investigating an earlier access issue that is not obvious from the current message position alone.
What to inspect: Read the returned rach-Report-r9 together with earlier access, paging return, or recovery behavior.
Next step: Move backward into the earlier access sequence and compare it with the UE-side report.
LTE / 5G / Variant Comparison
Compared with UEInformationRequest-r9
UEInformationRequest-r9 asks for diagnostic information. UEInformationResponse-r9 carries the actual returned report blocks.
Base Release 9 scope versus later extensions
The base Release 9 message mainly returns random access and radio link failure reports. Later releases extend the response through the non-critical extension branch.
FAQ
What is UE Information Response r9 in LTE?
It is the uplink LTE RRC message the UE sends to return the diagnostic information requested by UEInformationRequest-r9.
What comes before UE Information Response r9?
The normal previous message is UEInformationRequest-r9 from the eNodeB.
What does UE Information Response r9 carry?
It can carry random access report data, radio link failure report data, or both, depending on what the network requested and what the UE has available.
What should I inspect first in a trace?
Start with the transaction identifier, then check which report blocks are present and whether they match the earlier request.
Why is UE Information Response r9 useful?
It provides UE-side diagnostic evidence that can explain earlier access problems or radio link failure behavior that is not fully visible from network-side signaling alone.
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.
