LTE RRC UE Information Request r9

Message Fact Sheet

Protocol	lte-rrc	Network	lte
Spec	3GPP TS 36.331	Spec Section	5.6.5, 6.2.2
Direction	eNodeB -> UE	Message Type	Diagnostic Control

Full message name	LTE RRC UE Information Request r9
Protocol	LTE-RRC
Technology	LTE
Direction	eNodeB -> UE
Interface	Uu
Signaling bearer / channel	SRB1 / DL-DCCH
Typical trigger	The network wants UE-side evidence about random access behavior, radio link failure context, or both.
Main purpose	Starts the LTE UE information reporting step so the network can request UE-side diagnostic information and then read the returned report in UEInformationResponse-r9.
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 Request r9 in simple terms?

Downlink LTE RRC message used by the eNodeB to ask the UE for stored diagnostic information such as random access details or radio link failure context.

Starts the LTE UE information reporting step so the network can request UE-side diagnostic information and then read the returned report in UEInformationResponse-r9.

Why this message matters

UE Information Request r9 is the LTE network asking the UE to send back stored random access information, radio link failure information, or both.

Where this message appears in the call flow

UE information procedure

Call flow position: Downlink request message that starts the LTE UE information reporting step.

Typical state: UE is in connected mode and can return protected diagnostic information on SRB1.

Preconditions:

AS security activation has already completed successfully.
The network expects the UE to have useful diagnostic information available.

Next likely message: UEInformationResponse-r9

Radio link failure investigation

Call flow position: Diagnostic request used when the network wants UE-side radio link failure context after recovery or failure analysis begins.

Typical state: The network is investigating an earlier failure path and wants stored UE-side context.

Preconditions:

The UE may have stored RLF information.
Connected-mode signaling is available for the diagnostic exchange.

Next likely message: UEInformationResponse-r9 carrying rlf-Report-r9 if available

Random access investigation

Call flow position: Diagnostic request used when the network wants details about the last successfully completed random access procedure.

Typical state: The network wants UE-side access history rather than only network-side traces.

Preconditions:

The UE has relevant random access information available.
The diagnostic branch is active in connected mode.

Next likely message: UEInformationResponse-r9 carrying rach-Report-r9 if requested

Call flow position

Previous message(s): SecurityModeComplete, Connected-mode signaling before diagnostics start

Next message(s): UEInformationResponse-r9, Later connected-mode recovery or failure analysis

Message direction and transport

Sender and receiver: eNodeB -> UE

Interface: Uu

Domain: Access-side radio control diagnostics

Signaling bearer: SRB1

Logical channel: DL-DCCH

Transport / encapsulation: RRC over DCCH on SRB1 in connected mode after successful AS security activation

Security context: This message is part of protected connected-mode LTE RRC signaling after successful AS security activation.

Message Structure Overview

UEInformationRequest-r9 is a request-only message. It does not carry the report itself.
The useful reading path is which request flags are set and what later appears in UEInformationResponse-r9.
In base Release 9 scope, the main branches are random access information and radio link failure information.

ASN.1 for LTE RRC UE Information Request r9

UEInformationRequest-r9 ::= SEQUENCE {
  rrc-TransactionIdentifier RRC-TransactionIdentifier,
  criticalExtensions CHOICE {
    c1 CHOICE {
      ueInformationRequest-r9 UEInformationRequest-r9-IEs,
      spare3 NULL,
      spare2 NULL,
      spare1 NULL
    },
    criticalExtensionsFuture SEQUENCE {}
  }
}

UEInformationRequest-r9-IEs ::= SEQUENCE {
  rach-ReportReq-r9    BOOLEAN,
  rlf-ReportReq-r9     BOOLEAN,
  nonCriticalExtension UEInformationRequest-v930-IEs OPTIONAL
}

UEInformationRequest-v930-IEs ::= SEQUENCE {
  lateNonCriticalExtension OCTET STRING OPTIONAL,
  nonCriticalExtension     UEInformationRequest-v1020-IEs OPTIONAL
}

How to read this ASN.1

The core read is simple: check whether the network requested random access information, radio link failure information, or both, then correlate the request with the later response.

LTE RRC UE Information Request r9 - Example Dump

DL-DCCH-Message
  message c1 : ueInformationRequest-r9 : {
    rrc-TransactionIdentifier 4,
    criticalExtensions c1 : ueInformationRequest-r9 : {
      rach-ReportReq-r9 true,
      rlf-ReportReq-r9  true
    }
  }

How to read this dump

Start with the flag combination because that tells you what the network wants next.
The next useful read is whether UEInformationResponse-r9 follows and what report blocks it returns.
If both flags are false, the request is not operationally meaningful.

Important Information Elements

IE	Required	Description
`rrc-TransactionIdentifier`	Yes	Transaction identifier used to match the request with the later UEInformationResponse-r9.
`rach-ReportReq-r9`	Yes	Boolean field showing whether the UE shall return random access information.
`rlf-ReportReq-r9`	Yes	Boolean field showing whether the UE shall return radio link failure information.
`nonCriticalExtension`	Optional	Extension branch for later release additions such as logged measurements, connection-establishment failure reporting, and other UE-side information requests.

Detailed field explanation

`rrc-TransactionIdentifier`

Transaction identifier used to match the request with the later UEInformationResponse-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.

`rach-ReportReq-r9`

Boolean field showing whether the UE shall return random access information.

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.

`rlf-ReportReq-r9`

Boolean field showing whether the UE shall return radio link failure information.

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.

`nonCriticalExtension`

Extension branch for later release additions such as logged measurements, connection-establishment failure reporting, and other UE-side information requests.

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 appears after successful AS security activation.
Check whether rach-ReportReq-r9 is set.
Check whether rlf-ReportReq-r9 is set.
Correlate the transaction identifier with the later UEInformationResponse-r9.
Verify that the requested report type matches the active investigation path.
If the response is missing, keep following the UL-DCCH sequence before treating the request itself as the end of the branch.

Common Issues and Troubleshooting

UE Information Request r9 appears but no UEInformationResponse-r9 follows.

Likely cause: The diagnostic branch may have been interrupted, the trace may be incomplete, or the UE may not have returned the requested information.

What to inspect: Check the transaction identifier, later UL-DCCH activity, and whether the connected diagnostic path continued.

Next step: Keep reading forward in the trace and confirm whether the response was missing or only delayed.

The network requests RLF information but the returned response has little or no useful report data.

Likely cause: The UE may not have stored relevant radio link failure context.

What to inspect: Check whether an actual RLF event existed and whether the later response contains rlf-Report-r9.

Next step: Correlate the request with re-establishment, recovery, or earlier failure history.

The network requests random access information unexpectedly.

Likely cause: The network is investigating an earlier access or recovery path that is not obvious from the current trace position alone.

What to inspect: Check the preceding access, recovery, and re-establishment branches and the returned rach-Report-r9 content.

Next step: Treat the request as a clue about the suspected failure domain and read backward into the earlier access path.

LTE / 5G / Variant Comparison

Compared with UEInformationResponse-r9

UE Information Request r9 asks for the report. UEInformationResponse-r9 carries the actual returned report blocks.

Base Release 9 scope versus later extensions

The base Release 9 message asks for random access and radio link failure information. Later release extensions add more diagnostic request types through the non-critical extension branch.

FAQ

What is UE Information Request r9 in LTE?

It is the downlink LTE RRC message the eNodeB sends when it wants UE-side diagnostic information such as random access details, radio link failure context, or both.

Who sends UE Information Request r9?

The eNodeB sends UE Information Request r9 to the UE.

What comes after UE Information Request r9?

The normal follow-up is UEInformationResponse-r9 from the UE.

Does UE Information Request r9 contain the report itself?

No. It only tells the UE which diagnostic information the network wants returned.

What should I inspect first in a trace?

Start with rach-ReportReq-r9, rlf-ReportReq-r9, the transaction identifier, and whether UEInformationResponse-r9 follows.

Related message pages

Related Procedures

Related Tools

Use This Reference in Practice

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.