UE Capability Transfer in LTE 4G

Introduction

UE Capability Transfer is the RRC procedure by which the eNB learns, once and precisely, what a given UE's radio can do — its category, its supported bands and carrier-aggregation combinations, its MIMO layers, its modulation orders, and dozens of smaller optional features. It is the single input that bounds every throughput decision the scheduler will ever make for that device.

It runs early in the RRC connection, on SRB1, typically right after RRCConnectionSetup and after AS security is active but before the eNB configures data bearers or carrier aggregation. Security first is deliberate: the capability set can help fingerprint a device, so the network waits until the exchange is ciphered and integrity-protected before asking. The answer is then cached in the core (the MME) so it need not be fetched again on every future connection.

It matters because getting it wrong is expensive in both directions. Over-configure — enable a band combination or a modulation order the UE cannot handle — and the link breaks or the UE misbehaves. Under-configure — miss a supported CA combination — and an expensive flagship device crawls at single-carrier rates. Reading the capability exchange correctly is the difference between a device that performs to its spec sheet and one that silently underdelivers.

Why UE capability transfer is needed

Every UE is different. A budget IoT module and a flagship handset both attach to the same eNB, but one might top out at a few Mbps on a single carrier while the other handles five aggregated carriers, four MIMO layers and 256QAM. The eNB cannot guess — it has to be told, precisely, what each connected UE can do before it configures the radio bearers and starts scheduling. The concrete purpose is to let the eNB size everything it provisions — DL/UL peak rates, RLC/PDCP buffers, CA setup, transmission mode, modulation order — to what the UE actually supports, and to bound the throughput the scheduler can ever deliver to this device.

What UE Capability Transfer Is

Every UE is different. A budget IoT module and a flagship handset both attach to the same eNB, but one might top out at a few Mbps on a single carrier while the other handles five aggregated carriers, four MIMO layers and 256QAM. The eNB cannot guess — it has to be told, precisely, what each connected UE can do before it configures the radio bearers and starts scheduling. Getting this wrong in either direction is expensive: over-configure and the link breaks; under-configure and an expensive device crawls.

The Procedure — Enquiry and Information

The exchange is a simple two-message request/response on the dedicated control channel (DCCH, using SRB1), typically run right after RRC connection setup and security activation, and before the eNB configures the UE's data bearers. Security first matters: capabilities can identify a device, so the network waits until the messages are ciphered and integrity-protected before asking. Both messages are ordinary dedicated RRC PDUs — scheduled on PDSCH/PUSCH by a PDCCH whose CRC is scrambled with the UE's C-RNTI in the UE-specific search space.

1. Enquiry. The eNB sends UECapabilityEnquiry, which contains a ue-CapabilityRequest — a list of the Radio Access Technologies whose capabilities it wants. Each entry is a RAT-Type: eutra for LTE itself, and optionally utra (3G), geran-cs / geran-ps (2G), cdma2000-1XRTT, and — the key addition for 5G non-standalone — eutra-nr and nr. Those last two let a UE advertise EN-DC (E-UTRA–NR Dual Connectivity) capability so the LTE anchor can add a 5G NR leg.

2. Information. The UE replies with UECapabilityInformation, carrying a UE-CapabilityRAT-ContainerList — one container per requested RAT, each tagged with its rat-Type. Inside the E-UTRA container sits the star of the show, the UE-EUTRA-Capability IE. The eutra-nr container carries the combined EN-DC band combinations, and the nr container carries the standalone NR capabilities encoded per TS 38.331.

Reading the exchange in the logs

On an RRC trace the procedure is two lines — the downlink enquiry naming the requested RATs and any band filter, and the uplink information carrying the container list. The fields to line up are the requested vs returned RAT-Types, the reported category, and the size of the returned message.

Representative eNB/UE RRC log — illustrative, values vary by vendor/build:

Inside the UE-EUTRA-Capability IE

The UE-EUTRA-Capability IE (defined in TS 36.331, with peak-rate meanings in TS 36.306) is a large, extensible structure. It has grown release by release, so newer capabilities live in nested ...-vXYZ extension containers appended to the end — a UE that supports a Release-13 feature carries it in a Release-13 sub-container, while a legacy reader simply ignores what it does not understand. The headline fields a fresher should recognise:

• Access-stratum release — accessStratumRelease tells the eNB which 3GPP release the UE conforms to (rel8, rel9, … rel15+), which gates everything else.
• UE category — ue-Category (and the release-specific ue-CategoryDL / ue-CategoryUL). This anchors the UE's peak DL/UL data rates, the number of supported soft-channel bits, and the buffer sizes the network provisions.
• RF parameters — rf-Parameters holds supportedBandListEUTRA (the individual bands) and, in its extensions, supportedBandCombination — the exact CA combinations that actually enable carrier aggregation.
• Feature Group Indicators — featureGroupIndicators, a bitmap where each bit signals support for a specific bundle of optional features (defined in the TS 36.331 annexes).
• PDCP, RLC, MAC and physical-layer parameters — pdcp-Parameters, phyLayerParameters (e.g. ue-TxAntennaSelectionSupported), ROHC profiles, and supported CSI/measurement features.
• Measurement parameters — measParameters lists inter-frequency and inter-RAT band lists and whether measurement gaps are needed.

UE Category — the Peak-Rate Anchor

The UE category is the number everyone quotes ("it's a Cat 4 modem"). Each category in TS 36.306 fixes an approximate peak downlink and uplink rate together with the supporting buffer sizes: the maximum number of DL-SCH transport-block bits per TTI, the total number of soft-channel bits (the HARQ soft buffer), and the maximum number of supported spatial layers. These are theoretical maxima on reference configurations — real throughput depends on bandwidth, MIMO, modulation and the scheduler — but the category caps what is even possible.

Notice how peak DL climbs steeply — Cat 6 and up require carrier aggregation to reach their numbers, which is why the supportedBandCombination list matters as much as the category itself. From Release 11 onward the single ue-Category was split into separate ue-CategoryDL and ue-CategoryUL fields (using a distinct DL/UL category numbering), because DL and UL capability no longer moved in lockstep — a device might be Cat 12 in the downlink but only Cat 5 in the uplink. For backward compatibility a legacy ue-Category value (capped at 8) is still signalled alongside the newer split fields.

Supported Band Combinations & CA Bandwidth Classes

Carrier aggregation is where the reported capability gets genuinely intricate. It is not enough to know a UE supports "3-carrier CA" — the eNB needs to know which specific bands it can aggregate together, how wide the aggregated block in each band may be, and how many MIMO layers it can run per band in that combination. All of this lives in supportedBandCombination, a list where each entry is itself a list of per-band parameters.

Each band inside a combination is described by a BandParameters structure naming the bandEUTRA, a CA bandwidth class (ca-BandwidthClassDL / ca-BandwidthClassUL), and the supported MIMO capability for that band in that combination (supportedMIMO-CapabilityDL). The bandwidth class encodes both how much aggregated bandwidth and how many contiguous component carriers the UE can handle within a single band:

A full band-combination entry therefore reads like a recipe: for example CA_1C means "band 1, bandwidth class C" — two contiguous carriers in band 1 — while CA_3A-7A means "one carrier in band 3 aggregated with one carrier in band 7." The eNB reads these to decide exactly which SCells it may add and how wide each may be. Newer releases add bandCombinationParameters extensions carrying per-combination flags such as 256QAM support, cross-carrier scheduling, and the number of layers allowed — because a UE that manages 4 layers on a single carrier might only manage 2 per band once three carriers are aggregated.

Feature Group Indicators (FGI)

Beyond the category and band lists, LTE needs a compact way to advertise dozens of small optional behaviours — things like "I support periodic CQI reporting on PUCCH," "I support inter-frequency handover," or "I support TTI bundling." Enumerating each as a named ASN.1 field would bloat the message, so early LTE used Feature Group Indicators: featureGroupIndicators, a fixed-length bitmap where each bit position corresponds to a predefined group of features listed in the annexes of TS 36.331.

A "1" at a given bit means the UE supports the whole feature group at that position; a "0" means it does not (or, for some groups, that support is mandatory and the bit is fixed). The mapping is release-anchored: the base 32-bit bitmap was defined for Release 8/9, and later releases added featureGroupIndRel9Add, featureGroupIndRel10 and further extension bitmaps as new optional features appeared. The eNB reads these bits before enabling the corresponding behaviour — it will not, for instance, configure a feature whose FGI bit is clear.

Low-End Categories: Cat 0, Cat M1 and NB-IoT

Not every device wants a gigabit. Machine-type and IoT devices care about cost, coverage and battery life, so 3GPP defined deliberately stripped-down categories at the bottom of the range. These are reported through the same UE-EUTRA-Capability IE but signal drastically reduced capability.

• Category 0 (Release 12) — the first MTC-oriented category, cutting peak rate to ~1 Mbps and allowing a single receive antenna and optional half-duplex operation, to lower modem cost.
• Category M1 (eMTC, Release 13) — operates in a narrow 1.4 MHz bandwidth regardless of the cell's actual bandwidth, adds Coverage Enhancement modes (repetitions), and supports Power Saving Mode and extended DRX for multi-year battery life.
• Category NB1 / NB2 (NB-IoT, Release 13/14) — an even narrower 180 kHz (one PRB) design with its own physical channels (NPDCCH, NPDSCH, NPUSCH), reported via a separate NB-IoT capability structure rather than the full E-UTRA IE.

For these devices the network still runs a capability exchange, but the reported values tell the eNB to fall back to the reduced-bandwidth, high-repetition, low-throughput configurations these categories are built around. The principle is identical to the high end: the eNB configures exactly to what the UE reports — it just happens to report far less.

Caching, Growth and Filtering

Re-running the enquiry on every RRC connection would waste air-time, so the network caches it. Once the eNB has received UECapabilityInformation, it forwards the encoded capabilities to the MME in the S1AP UE Capability Info Indication message. The MME stores this as the UE Radio Capability against the UE's context.

On a subsequent transition to connected — for example when the UE is paged or initiates a new connection — the MME hands the stored UE Radio Capability back to the (possibly different) eNB inside the S1AP Initial Context Setup Request. The eNB now has everything it needs to configure bearers and CA without ever sending a UECapabilityEnquiry. It only re-enquires if the stored capabilities are absent or a network policy forces a refresh.

There is a real scaling problem lurking here. As carrier aggregation matured, the number of band combinations a flagship UE supports exploded into the hundreds or thousands — every allowed pairing, triple and quadruple of bands, each with its bandwidth classes and MIMO options. A fully enumerated supportedBandCombination list can run to tens of kilobytes, which is expensive to send over the air and to store. 3GPP's answer is capability filtering: the eNB includes a UECapabilityEnquiry filter (the requestedFrequencyBands / UE-CapabilityRequestFilterCommon) telling the UE to report only the combinations relevant to the bands this network actually operates. The UE then omits everything else, keeping the message small.

Summary

UE Capability Transfer is the early, once-per-connection RRC exchange that tells the eNB exactly what a device's radio can do. The eNB sends UECapabilityEnquiry naming the RATs it wants (and, ideally, a band filter); the UE answers with UECapabilityInformation carrying one container per RAT, the E-UTRA one holding the big UE-EUTRA-Capability IE — category, bands, supportedBandCombination, MIMO, modulation and FGI. It runs after AS security and before bearer/CA setup, and the MME caches the result as the UE Radio Capability so later connections skip the enquiry.

The practical takeaways: the category sets the ceiling (TS 36.306) but the band combinations and modulation decide how close you get; DL and UL categories are separate from Rel-11; FGI is a legacy bitmap that NR replaced with featureSets; and capability filtering exists because unfiltered combination lists grew to tens of kilobytes. When throughput or CA underperforms, read the exchange log-in-hand: confirm the RAT containers, the reported categories, and the specific band combination the cell needs.