LTE RRC UE Capability Enquiry

Message Fact Sheet

Protocol	lte-rrc	Network	lte
Spec	3GPP TS 36.331	Spec Section	5.6.1, 6.2.2, Annex B
Direction	eNodeB -> UE	Message Type	Capability Exchange

Full message name	LTE RRC UE Capability Enquiry
Protocol	LTE-RRC
Technology	LTE
Direction	eNodeB -> UE
Interface	Uu
Signaling bearer / channel	SRB1 / DL-DCCH
Typical trigger	The network needs UE capability details before applying feature-dependent radio configuration such as mobility, measurements, carrier support, or advanced connected-mode behavior.
Main purpose	Requests the UE capability containers the network needs so later LTE configuration decisions match what the UE actually supports.
Main specification	3GPP TS 36.331, 5.6.1, 6.2.2, Annex B
Release added	Release 8
Procedures where used	UE Capability Transfer, Connected-mode Capability Discovery, Capability-Aware Reconfiguration

What is LTE RRC UE Capability Enquiry in simple terms?

Downlink LTE RRC message used by the eNodeB to request UE capability information before applying capability-dependent radio configuration.

Requests the UE capability containers the network needs so later LTE configuration decisions match what the UE actually supports.

Why this message matters

UECapabilityEnquiry is the LTE network asking the UE what radio features and capabilities it supports.

Where this message appears in the call flow

UE capability transfer

LTE capability exchange flow showing UECapabilityEnquiry followed by UECapabilityInformation — In the main capability-transfer path, UECapabilityEnquiry asks for UE support details and the next expected step is UECapabilityInformation.

Call flow position: Network request that starts the LTE capability exchange.

Typical state: UE is in RRC_CONNECTED and can send protected DCCH signaling.

Preconditions:

SRB1 and connected-mode signaling are active.
The network needs UE capability data before the next decision.

Next likely message: UECapabilityInformation

Capability-aware reconfiguration

LTE capability-aware flow showing UECapabilityEnquiry, capability response, and later RRCConnectionReconfiguration — When later configuration depends on UE support, capability exchange sits before the reconfiguration decision.

Call flow position: Capability request used before feature-dependent LTE reconfiguration.

Typical state: UE is in connected mode and the network is preparing configuration that depends on UE support.

Preconditions:

The network has not yet confirmed the needed capability details.

Next likely message: UECapabilityInformation followed by capability-aware RRCConnectionReconfiguration

Call flow position

Previous message(s): SecurityModeComplete, Connected-mode LTE RRC signaling

Next message(s): UECapabilityInformation, RRCConnectionReconfiguration

Message direction and transport

Sender and receiver: eNodeB -> UE

Interface: Uu

Domain: Access-side radio control capability handling

Signaling bearer: SRB1

Logical channel: DL-DCCH

Transport / encapsulation: RRC over DCCH on SRB1 during connected-mode capability exchange

Security context: Typically exchanged after LTE AS security is active, so it is normally part of protected dedicated signaling.

Message Structure Overview

UECapabilityEnquiry is a request message. It asks for capability information but does not carry the capability itself.
The practical reading path is the requested capability scope, the later UECapabilityInformation, and the reconfiguration that depends on it.
When later feature configuration fails, capability exchange is one of the first places to inspect.

ASN.1 for LTE RRC UE Capability Enquiry

UECapabilityEnquiry ::= SEQUENCE {
  rrc-TransactionIdentifier RRC-TransactionIdentifier,
  criticalExtensions CHOICE {
    c1 CHOICE {
      ueCapabilityEnquiry-r8 UECapabilityEnquiry-r8-IEs,
      spare3 NULL,
      spare2 NULL,
      spare1 NULL
    },
    criticalExtensionsFuture SEQUENCE {}
  }
}

UECapabilityEnquiry-r8-IEs ::= SEQUENCE {
  ue-CapabilityRequest     UE-CapabilityRequest,
  lateNonCriticalExtension OCTET STRING OPTIONAL,
  nonCriticalExtension     UECapabilityEnquiry-v8a0-IEs OPTIONAL
}

How to read this ASN.1

The key practical field is the capability request itself, because it tells you what the eNodeB expects the UE to report next.

LTE RRC UE Capability Enquiry - Example Dump

DL-DCCH-Message
  message c1 : ueCapabilityEnquiry : {
    rrc-TransactionIdentifier 5,
    criticalExtensions c1 : ueCapabilityEnquiry-r8 : {
      ue-CapabilityRequest present
    }
  }

How to read this dump

The main next step is normally UECapabilityInformation on UL-DCCH.
If later configuration fails, check whether the network requested the right capability scope and whether the UE returned a matching response.
This message is mainly valuable as part of the larger capability exchange, not as an isolated decode.

Important Information Elements

IE	Required	Description
`rrc-TransactionIdentifier`	Yes	Transaction identifier used to correlate the enquiry with the UE response.
`ue-CapabilityRequest`	Yes	Capability request content telling the UE what capability information the network expects next.
`lateNonCriticalExtension`	Optional	Extension container for later release evolution.
`nonCriticalExtension`	Optional	Forward-compatible extension branch for later additions.

Detailed field explanation

`rrc-TransactionIdentifier`

Transaction identifier used to correlate the enquiry with the UE response.

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.

`ue-CapabilityRequest`

Capability request content telling the UE what capability information the network expects next.

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.

`lateNonCriticalExtension`

Extension container for later release evolution.

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`

Forward-compatible extension branch for later additions.

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 is sent on SRB1 and DL-DCCH after connected-mode security is active.
Check what capability information the network is asking for.
Correlate the transaction identifier with the following UECapabilityInformation.
Check whether later reconfiguration assumes support the UE did not actually report.
If the exchange repeats, verify whether the wider procedure changed.

Common Issues and Troubleshooting

UECapabilityEnquiry is sent but no capability response follows.

Likely cause: The UE may fail to process the request, the response may be missing from the trace, or the procedure may be interrupted.

What to inspect: Check transaction pairing, UL-DCCH activity, and whether the capability exchange completed.

Next step: Move forward to see whether the exchange stalled or the trace is incomplete.

Later LTE reconfiguration fails after capability exchange.

Likely cause: The network may have built configuration from incorrect, incomplete, or misread UE capability information.

What to inspect: Compare UECapabilityEnquiry, the UE response, and the following RRCConnectionReconfiguration.

Next step: Validate that the later feature configuration matches the reported UE support.

Capability exchange repeats unexpectedly.

Likely cause: The network may be re-requesting capabilities because context was lost or the procedure restarted.

What to inspect: Check whether the connection path changed, restarted, or entered a new capability-dependent branch.

Next step: Correlate repeated enquiries with the broader connected-mode procedure instead of treating them as isolated duplicates.

LTE / 5G / Variant Comparison

Compared with UECapabilityInformation

UECapabilityEnquiry is the network request. UECapabilityInformation is the UE response carrying the reported capability data.

Compared with RRCConnectionReconfiguration

UECapabilityEnquiry asks what the UE supports. RRCConnectionReconfiguration later applies capability-dependent configuration.

FAQ

What is UECapabilityEnquiry in LTE?

It is the downlink LTE RRC message the eNodeB sends to request UE capability information.

What comes after UECapabilityEnquiry?

The UE normally responds with UECapabilityInformation.

Does UECapabilityEnquiry contain the UE capability itself?

No. It only requests the capability information. The UE reports the actual capability in UECapabilityInformation.

Why is UECapabilityEnquiry important?

It helps the network avoid applying feature-dependent LTE configuration that the UE does not support.

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.