LTE RRC UE Capability Information

Message Fact Sheet

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

Full message name	LTE RRC UE Capability Information
Protocol	LTE-RRC
Technology	LTE
Direction	UE -> eNodeB
Interface	Uu
Signaling bearer / channel	SRB1 / UL-DCCH
Typical trigger	The UE responds to UECapabilityEnquiry by returning the requested capability information.
Main purpose	Transfers UE capability information so the network can build later LTE configuration that matches what the UE 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 Information in simple terms?

Uplink LTE RRC message used by the UE to report its capability information back to the eNodeB.

Transfers UE capability information so the network can build later LTE configuration that matches what the UE supports.

Why this message matters

UECapabilityInformation is the UE answer that tells the LTE network 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, UECapabilityInformation is the UE response that returns the requested support information.

Call flow position: UE response that carries the requested capability information back to the eNodeB.

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

Preconditions:

The eNodeB sent UECapabilityEnquiry.
The UE can assemble the requested capability information.

Next likely message: Capability-aware RRCConnectionReconfiguration or another network decision

Capability-aware reconfiguration

LTE capability-aware flow showing UECapabilityInformation before later RRCConnectionReconfiguration — When later LTE configuration depends on UE support, UECapabilityInformation becomes the capability input for the next reconfiguration decision.

Call flow position: Capability response the network uses before applying feature-dependent LTE configuration.

Typical state: UE is connected and the network is validating support before changing configuration.

Preconditions:

The network requested the relevant capability information.

Next likely message: RRCConnectionReconfiguration

Call flow position

Previous message(s): UECapabilityEnquiry

Next message(s): RRCConnectionReconfiguration, Capability-aware connected-mode network decision

Message direction and transport

Sender and receiver: UE -> eNodeB

Interface: Uu

Domain: Access-side radio control capability reporting

Signaling bearer: SRB1

Logical channel: UL-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 carried as protected dedicated signaling.

Message Structure Overview

UECapabilityInformation is the payload-carrying half of the LTE capability exchange.
The key reading path is which capability containers are present and whether the later network configuration matches the reported support.
This message should always be read together with the earlier UECapabilityEnquiry and the later RRCConnectionReconfiguration.

ASN.1 for LTE RRC UE Capability Information

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

UECapabilityInformation-r8-IEs ::= SEQUENCE {
  ue-CapabilityRAT-ContainerList UE-CapabilityRAT-ContainerList,
  lateNonCriticalExtension       OCTET STRING OPTIONAL,
  nonCriticalExtension           UECapabilityInformation-v8a0-IEs OPTIONAL
}

How to read this ASN.1

Most of the practical value is inside the returned capability container list. The useful reading path is what the UE reported and what the network did with it next.

LTE RRC UE Capability Information - Example Dump

UL-DCCH-Message
  message c1 : ueCapabilityInformation : {
    rrc-TransactionIdentifier 5,
    criticalExtensions c1 : ueCapabilityInformation-r8 : {
      ue-CapabilityRAT-ContainerList {
        {
          rat-Type eutra,
          ueCapabilityRAT-Container <E-UTRA UE Capability container>
        }
      }
    }
  }

How to read this dump

The returned capability container list is the main thing to inspect.
In practical traces, the capability container can be large and heavily nested, so parser confidence matters.
If later configuration fails, compare the network decision against what the UE actually reported here.

Important Information Elements

IE	Required	Description
`rrc-TransactionIdentifier`	Yes	Transaction identifier used to correlate the UE response with the preceding UECapabilityEnquiry.
`ue-CapabilityRAT-ContainerList`	Yes	List of capability containers returned by the UE for the requested RATs.
`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 UE response with the preceding UECapabilityEnquiry.

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-CapabilityRAT-ContainerList`

List of capability containers returned by the UE for the requested RATs.

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 follows UECapabilityEnquiry and uses SRB1 and UL-DCCH.
Verify the transaction identifier matches the preceding enquiry.
Inspect which capability containers are present.
Check whether the reported capability content is complete for the current scenario.
Correlate the message with the following RRCConnectionReconfiguration or later network action.

Common Issues and Troubleshooting

UECapabilityInformation is present but later feature configuration fails.

Likely cause: The network may have misread or misused the reported capability data, or the response may be incomplete for the intended feature.

What to inspect: Compare the returned capability information with the later RRCConnectionReconfiguration content.

Next step: Validate that the configured feature is actually declared as supported by the UE.

Capability reporting looks incomplete or missing expected containers.

Likely cause: The enquiry may not have requested the full set, the decoder may be incomplete, or the UE may not report the expected capability information.

What to inspect: Check UECapabilityEnquiry first, then compare the requested and returned capability scope.

Next step: Confirm whether the missing information is truly absent or simply not decoded by the current toolchain.

Capability exchange repeats.

Likely cause: The network may be revalidating capability context after procedure restart, context loss, or implementation-specific behavior.

What to inspect: Check whether the repeated exchange belongs to a new connected-mode context.

Next step: Correlate repeated capability transfer with the broader connected-mode procedure.

LTE / 5G / Variant Comparison

Compared with UECapabilityEnquiry

UECapabilityEnquiry asks for capability data. UECapabilityInformation carries the actual UE-reported capability information.

Compared with RRCConnectionReconfiguration

UECapabilityInformation reports what the UE supports. RRCConnectionReconfiguration later applies capability-dependent LTE configuration.

FAQ

What is UECapabilityInformation in LTE?

It is the uplink LTE RRC message the UE sends to report capability information back to the eNodeB.

What comes before UECapabilityInformation?

UECapabilityEnquiry normally comes immediately before it.

Why is UECapabilityInformation important?

It gives the network the capability data it needs to apply LTE configuration that the UE can actually support.

Does UECapabilityInformation affect later RRCConnectionReconfiguration?

Yes. The reported support often directly affects what the network configures next.

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.