>
Home5G NRRRC — Radio Resource ControlUE Capability
🗂️ RRC — Radio Resource ControlIntermediate

UE Capability Transfer in 5G NR

How the network learns what the UE supports, and feature-set / band-combination signalling.

📚 3GPP-basedTS 38.331TS 38.306

NR is not one radio. It is a very large space of options, and a device occupies a small and idiosyncratic corner of it. Two handsets from the same year, on the same band, in the same cell, may differ in how many MIMO layers they can receive, whether they can demodulate 256QAM, how wide a bandwidth part they can tune, how many carriers they can aggregate, whether they support 2-step Random Access, whether they can do DAPS handover, and how long they need between an SRS switch and the next transmission. Nothing in the physical layer reveals any of this.

Contents
  1. 01Why the Network Has to Ask
  2. 02When the Enquiry Happens, and When It Does Not
  3. 03UECapabilityEnquiry: the Request
  4. 04UECapabilityInformation: the Response and Its Containers
  5. 05Inside UE-NR-Capability: the Top-Level Structure
  6. 06Band Combinations
  7. 07The Feature Set Indirection
  8. 08A Worked Dereference, End to End
  9. 09What the Network Actually Does With It
  10. 10Capability Filtering, and Why It Is Not Optional
  11. 11Message Size, Segmentation and Growth
  12. 12EN-DC and NR-DC: UE-MRDC-Capability
  13. 13Capability Caching: NGAP, the AMF and RACS
  14. 14Mandatory, Optional, and the accessStratumRelease Trap
  15. 15ASN.1 Reference
  16. 16Parameter and Limit Reference
  17. 17Failure Modes and What Each One Means
  18. 18Illustrative Message Traces
  19. 19Release Deltas: Rel-15 to Rel-18
  20. 20Reading Capability in Logs: A Checklist
  21. 21Glossary and References

1. Why the Network Has to Ask

NR is not one radio. It is a very large space of options, and a device occupies a small and idiosyncratic corner of it. Two handsets from the same year, on the same band, in the same cell, may differ in how many MIMO layers they can receive, whether they can demodulate 256QAM, how wide a bandwidth part they can tune, how many carriers they can aggregate, whether they support 2-step Random Access, whether they can do DAPS handover, and how long they need between an SRS switch and the next transmission. Nothing in the physical layer reveals any of this.

The consequence is sharper than it sounds. The gNB does not merely lose performance by guessing wrong -- it breaks the link. A UE told to receive four spatial layers when it has two antennas does not decode at reduced rate; it fails every transport block on that grant. A UE configured with an RLC sequence-number length it does not support cannot even establish the bearer. Capability signalling exists because almost every configuration choice the network makes is a hard constraint rather than a soft one.

DimensionSpread across real devicesWhere it is declaredWhat happens if the network assumes wrong
Downlink MIMO layers per carrier1, 2, 4 or 8maxNumberMIMO-LayersPDSCH in FeatureSetDownlinkPerCCEvery high-rank grant fails. Looks like a coverage problem, but the BLER is flat against SINR.
Highest downlink modulationQPSK, 64QAM, 256QAM, 1024QAM (Rel-17)supportedModulationOrderDL in FeatureSetDownlinkPerCCThe UE cannot demodulate the high MCS rows, so throughput collapses exactly when radio conditions are best.
Channel bandwidth per carrier5 MHz to 100 MHz on FR1, up to 400 MHz on FR2supportedBandwidthDL / UL in FeatureSetDownlinkPerCCRRCReconfiguration is rejected with a failure, or the UE silently cannot receive part of the BWP.
Carriers aggregated1 to 16bandList plus the CA bandwidth class, and the length of featureSetListPerDownlinkCCSCell addition fails, or succeeds and then the SCell never carries data.
Supported bands1 band on a RedCap sensor, 40+ on a flagshipsupportedBandListNR in RF-ParametersThe UE cannot be served in the cell at all -- and this is the one case the network finds out about immediately.
Optional procedures (2-step RACH, DAPS, CHO, SDT, eDRX)present or absent, independently of each otherIndividual ENUMERATED {supported} fields throughout the containersThe procedure is configured and then never used, or is used and fails. The UE is required to ignore what it cannot do, which makes this fail silently.
RLC / PDCP parameters (SN length, ROHC profiles, out-of-order delivery)varies by chipset generationrlc-Parameters, pdcp-ParametersBearer establishment failure, or an RLC stall a few seconds into the session.

Table 1. What actually varies, and why capability signalling is a correctness requirement rather than an optimisation. Note that several rows fail silently.

⚠️
Common Pitfall

The security algorithms the UE supports are not in UE-NR-Capability. The UE's 5G security capabilities travel in the NAS Registration Request and reach the gNB in the NGAP UE Security Capabilities IE, which is why AS Security Mode Command can be sent before any capability enquiry has happened. If you are looking for NEA/NIA support and cannot find it in the capability container, that is why -- see the companion 27 AS Security Mode document.

2. When the Enquiry Happens, and When It Does Not

The enquiry is a two-message RRC procedure TS 38.331 cl. 5.6.1 and the network chooses when to run it. There is one hard rule: it may not be sent before AS security has been activated. The capability container is a near-unique fingerprint of a device model, and sending it in clear would let a passive observer identify the handset. So the ordering is always SecurityModeComplete first, UECapabilityEnquiry after.

OccasionWhy thenWhat is typically requested
Immediately after AS security activation, during initial context setupThe gNB needs the capability before it can configure anything beyond SRB1 and a default DRBnr alone in an SA-only deployment; nr and eutra-nr where EN-DC is offered
Not at all, because the AMF supplied a cached containerThe AMF holds UERadioCapability from a previous connection, or resolved a UE Radio Capability ID (§13)nothing -- there is no UECapabilityEnquiry in the log at all
A second time, filteredThe first unfiltered response was too large to be worth storing or re-fetchingnr with a frequencyBandList naming only the deployed bands
On PLMN changeCapabilities may legitimately differ per PLMN, and a previously cached container may not applyeverything relevant to the new PLMN
When adding a RAT the network did not previously ask aboute.g. NR-DC or EN-DC becomes relevant only after the UE is already connectedeutra-nr or eutra in a later enquiry
After the UE indicates its capability has changedRare, but a UE may signal a capability change (for example on a temporary capability restriction)a full re-enquiry

Table 2. When you should and should not expect to see the exchange. The second row is the one that surprises people: an absent enquiry is usually a cache hit, not a fault.

💡
Key Point

The network may send more than one UECapabilityEnquiry in a connection, and each one is a fresh, independent request -- there is no delta mechanism. The UE re-encodes and re-sends everything the filter allows. That is why a filtered second enquiry is a deliberate design choice and not a retry: it costs one round trip and buys a container small enough to cache and reuse.

3. UECapabilityEnquiry: the Request

UECapabilityEnquiry and UECapabilityInformation, Field by FieldUECapabilityEnquiry and UECapabilityInformation, Field by FieldTS 38.331 clause 6.2.2Downlink request -- DL-DCCH on SRB1UECapabilityEnquiryrrc-TransactionIdentifier + criticalExtensionsue-CapabilityRAT-RequestList1 .. 8 entries, one per RAT asked forue-CapabilityEnquiryExtOCTET STRING, Rel-15 late additionUE-CapabilityRAT-Requestrat-Type: nr | eutra-nr | eutra | utra-fddcapabilityRequestFilterCommonmfbi-IndicatorNR, omitEN-DCcapabilityRequestFilterfrequencyBandList, srs-SwitchingTimeRequestUplink response -- UL-DCCH on SRB1UECapabilityInformationsame rrc-TransactionIdentifier as the enquiryue-CapabilityRAT-ContainerListrat-Type + an opaque OCTET STRING per RATappliedFreqBandListFilterechoed back inside RF-ParametersThe RAT container is an OCTET STRING, not a nested SEQUENCE. It is separately encoded, which is what lets an NRcapability travel inside an LTE RRC message in EN-DC -- and what forces a decoder to make two passes.
Figure 1. The request and the response side by side. The filter lives two levels down inside the request; the applied filter is echoed back three levels down inside the response.
IETypePresenceWhat it does
rrc-TransactionIdentifier
INTEGER (0..3)MandatoryMatched by the response. With two enquiries in flight this is the only way to tell which answer belongs to which question.
ue-CapabilityRAT-RequestList
1 .. 8 entries of UE-CapabilityRAT-RequestMandatoryOne entry per RAT being asked about. The UE returns one container per entry it supports, and silently omits entries it does not.
rat-Type
ENUMERATED {nr, eutra-nr, eutra, utra-fdd, ...}Mandatory per entrySelects which capability structure the UE must encode into the corresponding container.
capabilityRequestFilter
OCTET STRING containing UE-CapabilityRequestFilterNROptionalPer-RAT filter. For nr it carries frequencyBandList and srs-SwitchingTimeRequest. Absent means tell me everything.
ue-CapabilityEnquiryExt
OCTET STRING containing UECapabilityEnquiryExt-IEsOptionalWrapper for capabilityRequestFilterCommon, which applies across all requested RATs rather than to one.
capabilityRequestFilterCommon
mfbi-IndicatorNR, omitEN-DCOptionalomitEN-DC tells the UE to leave every EN-DC band combination out, which on many devices is more than half the message.

Table 3. UECapabilityEnquiry IEs, TS 38.331 clause 6.2.2. The two filter mechanisms are at different levels and are not alternatives -- a well-formed enquiry usually uses both.

rat-TypeContainer the UE returnsContainsRequested when
nr
UE-NR-Capability
Everything NR-only: bands, band combinations, feature sets, per-layer parametersAlways. This is the container this document is mostly about.
eutra-nr
UE-MRDC-Capability
Multi-RAT dual connectivity: which NR and LTE bands can be used together, and the MRDC-specific parametersWhere EN-DC or NR-DC is offered
eutra
UE-EUTRA-Capability (defined in TS 36.331)The LTE capability, unchanged from LTEWhere EN-DC is offered, or for inter-RAT mobility to LTE
utra-fdd
UE-CapabilityRAT-Container for UTRA FDDLegacy 3G capabilityAlmost never; added in Rel-16 for completeness

Table 4. RAT types and their containers. A UE that does not support a requested RAT simply omits that container -- absence is the answer, not an error.

4. UECapabilityInformation: the Response and Its Containers

The response carries a list of containers, one per RAT, and each container is an OCTET STRING -- not a nested ASN.1 SEQUENCE. The capability structure inside it is separately encoded in unaligned PER and then wrapped as opaque octets.

That is not accidental. It is what allows an NR capability to travel inside an LTE RRC message during EN-DC setup, where the eNB has no NR ASN.1 definitions at all and must forward the octets untouched. It is also why decoding a capability message takes two passes: the outer message decodes to a container of octets, and the container must then be decoded against a different ASN.1 module, chosen by rat-Type.

The First Two Octets of Every UE-NR-Capability ContainerThe First Two Octets of Every UE-NR-Capability ContainerUnaligned PER: one extension bit, eleven optional-presence bits, then the first mandatory field -- exactly 16 bitsbit76543210Oct 1extrlcParammacParammeasAndMobfddAddtddAddfr1Addfr2AddOct 2featureSetsfsComblateExtnonCritExtextaccessStratumRelease001 = rel16UE-NR-Capability has eleven OPTIONAL root components, so its PER preamble is 1 + 11 = 12 bits. accessStratumRelease isan extensible ENUMERATED with eight root values, so it costs 1 + 3 bits. Nothing after bit 16 can be located withoutcounting these first -- which is why a single misread presence bit garbles the entire container.
Figure 2. The start of an NR container. Unaligned PER puts a presence bitmap before the first field, so the position of every subsequent field depends on those twelve bits -- there is no self-describing tag to resynchronise on.
⚠️
Common Pitfall

Unaligned PER has no field tags and no lengths on fixed-size fields. If a decoder gets one presence bit wrong, everything after that point is garbage that still decodes to plausible-looking values -- band 47 becomes band 261, four layers become two. A capability decode that produces almost sensible output is more dangerous than one that throws. See the companion 13 RRC Overview for the PER rules themselves.

5. Inside UE-NR-Capability: the Top-Level Structure

IEPresenceWhat is in itWhy you care
accessStratumRelease
MandatoryENUMERATED {rel15, rel16, rel17, rel18, ...}The highest release the UE claims. It gates nothing on its own -- see §14.
pdcp-Parameters
MandatoryROHC profiles, maxNumberROHC-ContextSessions, uplinkOnlyROHC-Profiles, out-of-order delivery supportGet this wrong and the bearer fails at establishment, not later.
rlc-Parameters
Optionalam-WithShortSN, um-WithShortSN, um-WithLongSNSN length must match on both sides or the RLC entity resets in the first window wrap.
mac-Parameters
OptionalLCP restrictions, skipUplinkTxDynamic, recommended bit rate, multiple-config supportAffects scheduling and the LCP behaviour in 09 LCP.
phy-Parameters
MandatoryThe largest single grab-bag: PUCCH formats, CSI reporting, dynamic SFI, PTRS, DMRS, precoding, split across FR1/FR2 and FDD/TDD sub-IEsAlmost every PHY configuration decision reads from here.
rf-Parameters
MandatorysupportedBandListNR, supportedBandCombinationList, appliedFreqBandListFilterThis is where the size lives. §6.
measAndMobParameters
OptionalMeasurement and mobility support: numbers of measurement objects, handover flavours, CSI-RS RRM, SFTDRead together with 20 Measurements and 21 Measurement Gaps.
fdd-Add-UE-NR-Capabilities / tdd-Add-...OptionalDuplex-specific differences from the values aboveA capability declared once at the top can be overridden per duplex mode. Missing this is a classic misread.
fr1-Add-UE-NR-Capabilities / fr2-Add-...OptionalFrequency-range-specific differencesSame trap, different axis.
featureSets
OptionalfeatureSetsDownlink, featureSetsUplink, featureSetsDownlinkPerCC, featureSetsUplinkPerCC -- each up to 1024 entriesThe value tables that everything else indexes into. §7.
featureSetCombinations
OptionalUp to 1024 combinations, each a per-band list of feature-set index pairsThe middle layer of the indirection. §7.

Table 5. UE-NR-Capability root components. Note that eleven of the fifteen are OPTIONAL, which is exactly the presence bitmap in the figure above.

⚠️
Common Pitfall

The XDD-Mode and FRX-Mode add-on structures are differences, not replacements. A UE may declare 256QAM at the top level and then override it downward inside tdd-Add-UE-NR-Capabilities. If you read only the top-level value you will configure something the UE supports on FDD and not on the TDD carrier it is actually camped on. Always resolve the duplex-mode and frequency-range overlays before believing a top-level capability.

6. Band Combinations

supportedBandCombinationList is a list of every simultaneous combination of carriers the UE can operate. Not every band it supports -- that is supportedBandListNR -- but every set it can use at once, with the aggregation class for each. This is the structure whose length drives the whole size problem: maxBandComb is 65 536.

IERangeWhat it meansNote
bandList
1 .. 32 entries (maxSimultaneousBands)The bands in this combination, each with a CA bandwidth class for DL and ULOrdered. The order is load-bearing -- featureSetCombination entries align with it positionally.
ca-BandwidthClassDL-NR / UL-NRA, B, C, ... (TS 38.101-1)How many contiguous carriers on this band and the aggregated bandwidth classBounds the carrier count; the exact count comes from the length of featureSetListPerDownlinkCC.
featureSetCombination
INTEGER (0 .. 1023)A 0-based index into UE-NR-Capability.featureSetCombinationsThe one field that turns a list of bands into a set of numbers. §7.
ca-ParametersNR
structureCA-wide limits: maxNumberOfServingCells, cross-carrier scheduling, simultaneous Rx/Tx, dual PA, SCell without SSBThese are combination-wide ceilings that sit on top of the per-CC feature set values.
mrdc-Parameters
structureOnly present in an MRDC band combination: single-uplink operation, dynamic power sharing, ul-SharingEUTRA-NRIts presence is how you tell an EN-DC combination from an NR-only one.
supportedBandwidthCombinationSet
BIT STRING (1..32)Which bandwidth combination sets from TS 38.101 applyAn RF constraint layered on top of everything else; frequently overlooked.
powerClass
pc1, pc2, pc3, ... (extension)Per-combination power classA UE may be power class 2 in one combination and class 3 in another. Affects uplink coverage, not throughput.

Table 6. BandCombination fields. Three separate levels of ceiling apply at once: the RF class, the combination-wide ca-ParametersNR, and the per-CC feature set.

💡
Key Point

The number of combinations grows combinatorially, not linearly. A device supporting n bands with up to three-carrier downlink aggregation has, nominally, n + C(n,2) + C(n,3) candidate sets before duplex, class and uplink variants multiply it further. At n = 20 that is 1 350 before variants; at n = 40 it is 11 480. Chipsets declare a curated subset, but the subset still runs into the thousands, and every entry has to be encoded and transmitted.

7. The Feature Set Indirection

If you take one thing from this document, take this section. Nothing in a band combination states a bandwidth, a subcarrier spacing, a MIMO rank or a modulation order. Those numbers exist exactly once each, in a shared table, and everything refers to them by index. The chain is four hops deep and each hop uses a different indexing convention.

The Feature Set Dereference Chain, Followed OnceThe Feature Set Dereference Chain, Followed OnceFour index hops between "the UE supports n78 + n1" and "the UE can receive 220 MHz"1. supportedBandCombinationListbandList[0] n78, class C [1] n1, class AfeatureSetCombination= 12 (a 0-based index)2. featureSetCombinations [12]entry [0] -> n78FeatureSet{nr}: downlinkSetNR 5, uplinkSetNR 3entry [1] -> n1downlinkSetNR 9, uplinkSetNR 73. featureSetsDownlinkfeatureSetsDownlink [5]featureSetListPerDownlinkCC = [ 2, 2 ] -- two CCs[9]featureSetListPerDownlinkCC = [ 4 ] -- one CC4. featureSetsDownlinkPerCCPerCC [2]30 kHz | 100 MHz | 4 layers | 256QAMPerCC [4]15 kHz | 20 MHz | 2 layers | 256QAM5. Configurable resultn78: 2 x 100 MHz @ 4 layers + n1: 20 MHz @ 2 layers220 MHz aggregated, 10 downlink MIMO layers, ~4.9 Gbps peakpositionalindex 12id 5id 9id 2, twiceid 4Nothing in the band combination itself says how wide, how many layers or which modulation. Those live once infeatureSetsDownlinkPerCC and are referenced by index from everywhere, which is why the message is compressible andunreadable in equal measure.
Figure 3. The chain followed once, with real indices. Read it top to bottom: each box is only a pointer until the last row but one.

7.1 The four levels

1. BandCombination.featureSetCombination -- a 0-based index into UE-NR-Capability.featureSetCombinations. One integer per combination.

2. featureSetCombinations[i] -- a FeatureSetCombination, which is a list of FeatureSetsPerBand, one per band, positionally aligned with the combination's bandList. Each FeatureSetsPerBand is itself a list of alternatives, each an NR or EUTRA FeatureSet carrying a downlink id and an uplink id.

3. featureSets.featureSetsDownlink[d] -- reached by the downlink id. Holds per-band, per-combination properties (intraBandFreqSeparationDL, scalingFactor, pdcch-MonitoringAnyOccasions, timeDurationForQCL, scellWithoutSSB) and, crucially, featureSetListPerDownlinkCC -- one entry per aggregated carrier.

4. featureSets.featureSetsDownlinkPerCC[c] -- reached by each per-CC id. This is where the actual numbers live: supportedSubcarrierSpacingDL, supportedBandwidthDL, maxNumberMIMO-LayersPDSCH, supportedModulationOrderDL.

7.2 The indexing conventions, which are not the same

This is where hand-decoding goes wrong, and it goes wrong quietly. Three different identifier types with three different base conventions appear in the same chain:

IdentifierASN.1 rangeBaseValue 0 means
FeatureSetCombinationId
INTEGER (0 .. maxFeatureSetCombinations-1)0-basedthe first entry of featureSetCombinations
FeatureSetDownlinkId
INTEGER (0 .. maxDownlinkFeatureSets)1-basednot supported -- the UE has no downlink capability for this band in this combination
FeatureSetUplinkId
INTEGER (0 .. maxUplinkFeatureSets)1-basednot supported -- no uplink on this band here
FeatureSetDownlinkPerCC-Id
INTEGER (1 .. maxPerCC-FeatureSets)1-basedcannot occur -- 0 is outside the range, so there is no "absent" value
FeatureSetUplinkPerCC-Id
INTEGER (1 .. maxPerCC-FeatureSets)1-basedcannot occur

Table 7. Mixed indexing in one dereference chain. maxFeatureSetCombinations, maxDownlinkFeatureSets, maxUplinkFeatureSets and maxPerCC-FeatureSets are all 1024.

⚠️
Common Pitfall

A downlinkSetNR of 0 is not "the first downlink feature set" -- it means the UE cannot receive on that band in that combination. This is how a uplink-only or downlink-only carrier is expressed. An off-by-one that reads 0 as an index produces a combination that looks supported and then fails when configured; an off-by-one in the other direction discards a combination the UE actually supports and costs the user a carrier. Both have been shipped.

7.3 Why it was built this way

The indirection is a compression scheme. A flagship declares thousands of band combinations, but they draw on perhaps a few dozen distinct per-CC capability profiles -- "100 MHz at 30 kHz, four layers, 256QAM" appears in almost all of them. Storing that profile once and referencing it by a ten-bit index instead of repeating it costs about two octets per reference instead of about twenty. Without it, UECapabilityInformation would be megabytes rather than tens of kilobytes.

StructureMax entriesTypical on a flagshipWhat one entry costs to reference
supportedBandCombinationList
65 5361 000 - 3 000n/a -- this is the thing being enumerated
featureSetCombinations
1 024100 - 60010 bits (one FeatureSetCombinationId)
featureSetsDownlink
1 02420 - 15011 bits (one FeatureSetDownlinkId)
featureSetsDownlinkPerCC
1 02410 - 6010 bits per carrier

Table 8. The pyramid. Thousands of combinations resolve onto tens of per-carrier profiles, which is why the indirection pays for itself many times over.

8. A Worked Dereference, End to End

Take band combination 37 out of a capability container and follow it all the way to a data rate. This is the exercise you will actually have to do when someone asks why a UE is not getting the throughput its datasheet claims.

🧮
Worked Calculation

Step 1 -- the band combination

supportedBandCombinationList[37]

bandList[0] = n78, ca-BandwidthClassDL-NR = c

bandList[1] = n1, ca-BandwidthClassDL-NR = a

featureSetCombination = 12 (0-based)

Step 2 -- the feature set combination

featureSetCombinations[12]

[0] -> n78 : FeatureSet{nr} downlinkSetNR = 5, uplinkSetNR = 3

[1] -> n1 : FeatureSet{nr} downlinkSetNR = 9, uplinkSetNR = 7

(entry order matches bandList order -- there is no band field here)

Step 3 -- the per-band downlink feature sets (1-based)

featureSetsDownlink[5].featureSetListPerDownlinkCC = [ 2, 2 ]

-> two downlink carriers on n78, both using per-CC set 2

featureSetsDownlink[9].featureSetListPerDownlinkCC = [ 4 ]

-> one downlink carrier on n1, using per-CC set 4

Step 4 -- the per-CC values (1-based)

featureSetsDownlinkPerCC[2]

supportedSubcarrierSpacingDL .. kHz30

supportedBandwidthDL ......... fr1: mhz100 -> 273 PRB

maxNumberMIMO-LayersPDSCH .... fourLayers

supportedModulationOrderDL ... qam256 -> Q_m = 8

featureSetsDownlinkPerCC[4]

supportedSubcarrierSpacingDL .. kHz15

supportedBandwidthDL ......... fr1: mhz20 -> 106 PRB

maxNumberMIMO-LayersPDSCH .... twoLayers

supportedModulationOrderDL ... qam256 -> Q_m = 8

Answer: 2 x 100 MHz on n78 at 4 layers, plus 20 MHz on n1 at 2 layers.

Aggregated bandwidth = 220 MHz. Total downlink MIMO layers = 10.

8.1 Carrying it through to a peak rate

TS 38.306 clause 4.1.2 gives the approximate peak data rate as a sum over aggregated carriers. Everything in it except the overhead constants comes from the dereference above:

TS 38.306 cl. 4.1.2, approximate peak data rate
data rate (Mbps) = 1e-6 x SUM over carriers j of
     v_Layers(j) x Q_m(j) x f(j) x R_max
        x N_PRB(BW(j), mu) x 12 / T_s(mu)
        x (1 - OH(j))

  R_max   = 948 / 1024 = 0.9258            (highest code rate)
  T_s(mu) = 1e-3 / (14 x 2^mu)             (OFDM symbol duration)
  OH      = 0.14 FR1 DL, 0.08 FR1 UL, 0.18 FR2 DL, 0.10 FR2 UL
  f(j)    = scalingFactor from FeatureSetDownlink: 1, 0.8, 0.75 or 0.4
  v_Layers, Q_m, N_PRB  -- all from featureSetsDownlinkPerCC
🧮
Worked Calculation

Carriers 1 and 2 (n78, 100 MHz, 30 kHz so mu = 1, 273 PRB, 4 layers, Q_m = 8, f = 1):

T_s = 1e-3 / (14 x 2) = 35.71 us

4 x 8 x 1 x 0.9258 = 29.63

29.63 x 273 x 12 = 97 063

97 063 / 35.71e-6 = 2.718e9

x (1 - 0.14) = 2.337e9 -> 2 337 Mbps per carrier

Carrier 3 (n1, 20 MHz, 15 kHz so mu = 0, 106 PRB, 2 layers, Q_m = 8):

T_s = 1e-3 / 14 = 71.43 us

2 x 8 x 0.9258 = 14.81

14.81 x 106 x 12 = 18 841

18 841 / 71.43e-6 = 2.638e8

x 0.86 = 2.269e8 -> 227 Mbps

Total = 2 337 + 2 337 + 227 = 4 901 Mbps, about 4.9 Gbps.

Now change one field: if featureSetsDownlinkPerCC[2] had said twoLayers instead of fourLayers, the n78 carriers halve to 1 169 Mbps each and the total falls to 2.6 Gbps -- a 47 % reduction from a single three-bit enumeration four index hops away from the band combination.

📘
Spec Detail

scalingFactor in FeatureSetDownlink is the f term in that formula and it is easy to miss: a UE may declare f0p75, in which case its real peak on that feature set is three quarters of what the per-CC values alone suggest. It lives one level up from the numbers it scales, which is exactly the kind of split that makes this message hard to read.

9. What the Network Actually Does With It

What the gNB derives from a capability messageWhat the gNB Decides From One Capability MessageTwo independent passes: the band and feature-set chain sets the ceilings, the presence tests gate the optionsUECapabilityInformationreassembled and decodedIntersect supportedBandListNRwith this cell's bandBandsupported?noCannot serve this UEhere -- release orredirectChoose a BandCombinationwhose bandList matchesthe intended carriersyesDereferencefeatureSetCombination-> FeatureSets -> PerCCPer-CC ceilings: bandwidth,SCS, MIMO layers,modulation orderFor each optional feature:is its own capabilityfield present?in parallelpresentMayconfigure itabsentDo notconfigure itEmit RRCReconfiguration:ServingCellConfig, BWPs,CSI, MCS tables, CA / DCThe left branch decides whether the UE can be served at all, the middle branch decides how fast, the right branch decideswhich features may be switched on. accessStratumRelease is never a substitute for the presence test on the right.
Figure 4. Two independent passes over the same message. The presence tests on the right do not need the dereference chain at all, which is why a partially-decoded capability can still be enough to configure basic service.
CapabilityWhat it gatesSymptom if the network ignores it
maxNumberMIMO-LayersPDSCH
DL rank in DCI, CSI codebook configuration, maxRank in PUSCH-ConfigFlat high BLER on high-rank grants regardless of SINR. CQI looks fine; throughput does not improve with radio conditions.
supportedModulationOrderDL
mcs-Table in PDSCH-Config (qam256 / qam64LowSE)All grants above the 64QAM MCS rows NACK. Throughput peaks at mid-SINR and then falls.
supportedBandwidthDL / ULBWP width, locationAndBandwidthRRCReconfigurationComplete never arrives, or arrives and the UE cannot receive outside its real bandwidth.
supportedSubcarrierSpacingDL
Numerology of the serving cell configurationReconfiguration failure. Usually caught immediately.
ca-ParametersNR.maxNumberOfServingCells
How many SCells may be addedSCell addition succeeds and the SCell is then never usable; or the reconfiguration fails outright.
simultaneousRxTxInterBandCA
Whether uplink and downlink on different bands may overlap in timeUplink loss on one band whenever the other is receiving. Looks like interference.
rlc-Parameters.am-WithShortSN
sn-FieldLength in RLC-ConfigBearer establishes, then resets at the first sequence-number wrap -- seconds to minutes in, which makes it look like a stability problem.
pdcp-Parameters.supportedROHC-Profiles
ROHC configuration in PDCP-ConfigPDCP header decompression failure; IP packets discarded silently.
measAndMobParameters handover flavours (DAPS, CHO)Whether daps-Config or conditionalReconfiguration may be sentHandover failure at execution rather than at preparation. See 25 Conditional HO and DAPS.
2-step RACH supportmsgA-* configuration in RACH-ConfigCommon or dedicatedThe UE ignores the MSGA configuration and uses 4-step, which is harmless -- one of the few benign cases. See 03 Random Access.
pdcch-MonitoringAnyOccasions
Search space configuration with monitoring outside the first three symbolsMissed PDCCH, appearing as scheduling gaps with no corresponding radio degradation.
powerClass per band combinationUplink power headroom assumptions and link budgetUplink coverage shortfall in exactly one band combination. See 10 BSR, PHR, SR.

Table 9. Capability, what it gates, and the diagnostic signature when the network gets it wrong. The pattern worth memorising: capability mismatches produce failures that are flat against radio conditions.

💡
Key Point

That last observation is the most useful diagnostic in this document. A radio problem gets better when the UE moves closer to the cell. A capability mismatch does not. If throughput or BLER refuses to respond to SINR, stop looking at the radio and go and read the capability container against the configuration that was sent.

10. Capability Filtering, and Why It Is Not Optional

An unfiltered enquiry asks a flagship handset to enumerate every band combination it supports, including combinations involving bands that do not exist anywhere in the operator's spectrum and EN-DC combinations in a network with no LTE anchor. The answer is tens of kilobytes of information the network can never use. Filtering is how the network says what it actually needs.

FilterWhere it sitsEffect on the responseCaveat
frequencyBandList in UE-CapabilityRequestFilterNRcapabilityRequestFilter inside each UE-CapabilityRAT-RequestThe UE omits every band, and every band combination containing a band, not named in the listIt is a whitelist. Forget to name a band you deploy and the UE will never report it -- looking exactly like a UE that does not support it.
maxBandwidthRequestedDL / UL, maxCarriersRequestedDL / ULPer entry of frequencyBandListBounds combinations to those within the requested bandwidth and carrier countUseful on a cell that will never aggregate more than two carriers.
omitEN-DC in capabilityRequestFilterCommon
ue-CapabilityEnquiryExt
Every EN-DC band combination is left outOn many devices this alone is more than half the message. Essential in an SA-only deployment.
mfbi-IndicatorNR in capabilityRequestFilterCommon
ue-CapabilityEnquiryExt
Tells the UE the network understands multi-frequency-band indicators, so overlapping bands need not be enumerated separatelyA modest saving, but free.
srs-SwitchingTimeRequest
UE-CapabilityRequestFilterNR
Asks the UE to include SRS antenna-switching timing, which it otherwise omitsThis one adds to the response. A filter is not only a reduction.

Table 10. Filtering mechanisms. Note the direction of each: most subtract, srs-SwitchingTimeRequest adds.

The UE echoes what it applied. RF-Parameters.appliedFreqBandListFilter in the response repeats the filter the UE actually used, which is the only way the network can tell the difference between the UE does not support band n41 and we did not ask about band n41. Any tool that caches capability containers must key them on the applied filter, not on the device.

⚠️
Common Pitfall

A cached container fetched under a filter is only valid for the bands in that filter. Reusing a container filtered to [n78, n3, n1] in a cell on n41 will convince the network that the UE does not support n41 -- and the UE will be released or redirected from a cell it could perfectly well have used. Check appliedFreqBandListFilter before trusting a cache, and re-enquire when the filter does not cover the serving band.

11. Message Size, Segmentation and Growth

Why Filtering Exists: Encoded Size Against Device ClassWhy Filtering Exists: Encoded Size Against Device ClassOrder-of-magnitude figures; the exact size depends on how many band combinations the chipset declares020406080100Encoded UECapabilityInformation (kB, approximate)1.21.1RedCap / IoT9.43.2Mid-tier8 bands34.04.1Smartphone20 bands96.05.6Flagship40 bands + EN-DCUnfiltered enquiryFiltered to 3 NR bands, omitEN-DCAbove 9 kB the message no longer fits one PDCP SDU and must be segmented. Three of the four unfiltered bars areabove that line; none of the filtered ones are.
Figure 5. The size problem made concrete. Filtering does not shave a percentage off the message -- it changes its order of magnitude, because it removes combinations rather than fields.

RRC messages travel on SRB1 or SRB3 over PDCP, and PDCP has a maximum SDU size of 9000 octets TS 38.323 cl. 4.3.1. RLC will happily segment an RLC SDU across many transport blocks, so the air interface is not the limit -- the PDCP SDU size is. When an RRC message exceeds it, RRC itself must segment.

ItemValueNote
Maximum PDCP SDU9000 octetsThe hard threshold above which RRC segmentation is required.
Uplink RRC segmentationRel-16, ULDedicatedMessageSegment on UL-DCCHGated by a UE capability. A Rel-15 UE cannot segment an uplink RRC message at all, so filtering is its only option.
Downlink RRC segmentationRel-15 for RRCReconfiguration, DLDedicatedMessageSegmentThe downlink direction was solved first, because a full RRCReconfiguration for CA is also large.
segmentNumber
INTEGER (0 .. 15)So at most 16 segments, i.e. roughly 144 kB of reassembled message. A genuine ceiling, not a soft one.
rrc-MessageSegmentType
notLastSegment, lastSegmentReassembly ends on lastSegment; a lost final segment leaves the receiver waiting forever with no timer to save it.

Table 11. Segmentation facts. Cross-reference the companion 13 RRC Overview for the segmentation procedure itself.

🧮
Worked Calculation

From the two transfers in Figure 1: 41 700 octets for 2 940 band combinations, and 3 100 octets for 46.

marginal cost per combination

= (41 700 - 3 100) / (2 940 - 46)

= 38 600 / 2 894

= 13.3 octets per band combination

implied fixed part (bands, PHY/MAC/RLC/PDCP parameters, feature sets)

= 3 100 - (46 x 13.3) = 3 100 - 612 = ~2.5 kB

combinations that fit in one PDCP SDU

= (9 000 - 2 500) / 13.3 = ~490 combinations

So a device declaring more than roughly five hundred band combinations cannot answer an unfiltered enquiry in a single PDCP SDU. Every flagship is well past that. Segmentation and filtering are not optimisations; one of the two is mandatory.

Growth over releases has been steady and in one direction. Each release adds bands, each new band multiplies the combination count, and each new feature adds fields to the per-CC and per-feature-set structures. There is no mechanism for shrinking a capability container, and no delta encoding: every transfer is a full transfer. RACS (§13) exists because that trend has no natural end.

12. EN-DC and NR-DC: UE-MRDC-Capability

Multi-RAT dual connectivity asks a different question. It is not "what can you do on NR" and "what can you do on LTE" -- it is "what can you do on both at the same time", which is a strictly smaller set. A UE may support LTE band 3 and NR band n78 individually and not be able to transmit on both simultaneously without an uplink sharing arrangement.

IELives inWhat it addsWhy it is separate
rf-ParametersMRDC.supportedBandCombinationList
UE-MRDC-Capability
Band combinations that mix EUTRA and NR BandParametersAn NR-only combination list cannot express an LTE band, so MRDC needs its own list.
featureSetCombinations
UE-MRDC-Capability
Its own list of feature set combinationsThe indices in an MRDC band combination point into this list, not into the NR container's. Mixing them up is a common decoder bug.
FeatureSets themselvesUE-NR-Capability onlyThe actual featureSetsDownlink / PerCC tablesThere is exactly one copy, in the NR container, and both containers index into it. You cannot fully resolve an MRDC capability without the NR container.
mrdc-Parameters
Each MRDC BandCombinationsingleUL-Transmission, dynamicPowerSharing, ul-SharingEUTRA-NR, ul-SwitchingTimeEUTRA-NR, tdm-PatternThese describe how the two uplinks coexist, which has no NR-only equivalent.
measAndMobParametersMRDC
UE-MRDC-Capability
Inter-RAT measurement and SFTD capabilityNeeded before the network can ask for LTE measurements from an NR-connected UE.
pdcp-ParametersMRDC
UE-MRDC-Capability
pdcp-DuplicationMCG-OrSCG-DRB
Split-bearer and duplication behaviour only exists in DC.

Table 12. UE-MRDC-Capability. The third row is the important one: the feature set tables are shared, the combination lists are not.

📘
Spec Detail

In EN-DC the whole exchange happens over LTE RRC. The eNB sends an LTE UECapabilityEnquiry requesting rat-Type nr and eutra-nr, and the UE returns NR and MRDC containers as opaque OCTET STRINGs inside an LTE UECapabilityInformation. The eNB forwards them to the gNB over X2 without decoding them. This is precisely why the containers are OCTET STRINGs and not nested SEQUENCEs -- and it means an EN-DC capability problem can be invisible in the LTE log and invisible in the NR log while being perfectly visible in the X2 message between them.

13. Capability Caching: NGAP, the AMF and RACS

Re-transferring 40 kB every time a UE connects is indefensible for a device that connects dozens of times a day. Two mechanisms remove it, one from Rel-15 and one from Rel-16.

Capability Caching: the AMF, the UCMF, and the Enquiry That Never HappensCapability Caching: the AMF, the UCMF, and the Enquiry That Never HappensCache hitCache missUEgNBAMFUCMFNAS Registration Requestcarries a UE Radio Capability ID (Rel-16 RACS)1Resolve the capability IDNucmf_UECapabilityManagement service2UE Radio Capability containerthe same octets the UE would have sentNGAP INITIAL CONTEXT SETUP REQUESTUE Radio Capability IE present3capability already known -> no UECapabilityEnquiry sent at allno ID, or an ID the UCMF cannot resolveUECapabilityEnquirythe full exchange of Figure 1 runs4UECapabilityInformationNGAP UE RADIO CAPABILITY INFOINDICATIONAMF stores it for the lifetime of the UE context5Assign a UE Radio Capability IDnetwork-assigned, or a manufacturer-assigned IDis registeredNAS Registration Accept / UEConfiguration Updatedelivers the new ID to the UE for next timeRACS moves the cost of a 40 kB transfer from the air interface to a one-off registration with a network function. It is alsowhy an empty capability enquiry log is not evidence that nothing happened.
Figure 6. Cache hit and cache miss. In a mature network with RACS the top half is the normal case, and a UECapabilityEnquiry in a log means something unusual happened.
MechanismReleaseWhere the container livesWhat it buysWhat it costs
NGAP UE RADIO CAPABILITY INFO INDICATION + the UE Radio Capability IERel-15The AMF, for the lifetime of the UE's registrationNo enquiry on subsequent connections within the same AMF and registrationLost on AMF change and on deregistration. Also carries the filter it was fetched under, implicitly.
UE Radio Capability for Paging
Rel-15The AMF, alongside the full containerLets the AMF give the RAN just enough capability information to page efficiently, without the full containerA separate, smaller structure that must be kept consistent with the full one. See 19 Paging.
RACS: UE Radio Capability ID + the UCMFRel-16The UCMF, a network function outside the RAN; the UE holds only the IDThe container survives AMF change, deregistration and even a change of serving network, and is fetched by IDRequires UE, AMF and UCMF support, plus ID lifecycle management. IDs may be network-assigned or manufacturer-assigned.

Table 13. Capability caching mechanisms. RACS is the only one that survives a change of AMF, which is why it matters most for high-mobility and roaming devices.

🔍
What You See In Logs

An empty capability enquiry log is not evidence that nothing happened. In a network with caching working correctly, most connections show no UECapabilityEnquiry at all -- the container arrived in the NGAP INITIAL CONTEXT SETUP REQUEST. If you are trying to read a UE's capability from a log and cannot find the RRC exchange, look at the NGAP message instead.

⚠️
Common Pitfall

A stale cache is worse than no cache. If a UE's firmware changes what it reports -- an update that adds a band, or drops a feature after a bug fix -- and the AMF or UCMF still holds the old container, the network will configure against capabilities the device no longer has. The observable symptom is a fleet-wide failure that correlates with a firmware rollout and not with any network change. RACS defines ID versioning to handle this; caches that key only on the subscriber do not.

14. Mandatory, Optional, and the accessStratumRelease Trap

TS 38.306 classifies every capability parameter, and the classification determines what the network may infer from silence:

ClassHow it appearsWhat absence meansExample
Mandatory without capability signallingNot signalled at allNothing -- every UE of that release must support it, so there is nothing to reportBasic 4-step Random Access; CP-OFDM downlink
Mandatory with capability signallingA field that is always present for a UE of that releaseA protocol error, or a UE of an earlier releaseaccessStratumRelease, pdcp-Parameters, phy-Parameters
Optional with capability signallingAn OPTIONAL field, usually ENUMERATED {supported}Not supported. This is the normal case and the reason the containers are so full of optional fieldsdaps-Config support, 2-step RACH, scellWithoutSSB
Conditionally mandatoryMandatory if another capability is claimedDepends on the condition; read the TS 38.306 note for the fieldSeveral FR2 beam-management capabilities, mandatory only for FR2 UEs

Table 14. Capability classes. For the overwhelming majority of interesting fields, absence means not supported -- there is no "unknown".

14.1 The accessStratumRelease trap

accessStratumRelease states the highest 3GPP release whose access stratum the UE implements. It is a single enumeration, it is mandatory, and it is the first field in the container -- which makes it very tempting to use as a feature gate. It is not one.

AssumptionIs it safe?Why
"rel16 means the UE supports 2-step RACH"No2-step RACH is optional in Rel-16. A Rel-16 UE may support none of the optional Rel-16 features. Read the feature's own field.
"rel15 means the UE cannot do anything from Rel-16"YesA UE reporting rel15 does not encode the Rel-16 extension containers at all, so there is nowhere for a Rel-16 capability to be declared.
"A higher accessStratumRelease implies at least the same capabilities as a lower one"NoNothing forbids a newer device from dropping an optional feature an older one had. Feature support is not monotonic in release.
"accessStratumRelease tells me which ASN.1 version to decode against"Broadly yesIt bounds which non-critical extensions can be present, which is what it is genuinely useful for.
"If accessStratumRelease is rel17 I can send a Rel-17 IE"NoYou can send it without breaking the decode -- the UE will ignore extensions it does not understand -- but the feature will not work and nothing will tell you.

Table 15. What accessStratumRelease does and does not license. Two of the five wrong assumptions produce silent failures.

⚠️
Common Pitfall

The failure this produces is the nastiest in this document, because it affects a subset of one device model -- the units whose firmware declares rel17 but omits the optional feature. The network configures the feature, the UE ignores it, and the resulting behaviour is neither a clean failure nor correct operation. Gate on the field, always. If the field is absent, the feature is absent.

15. ASN.1 Reference

The messages first, abridged to the fields that matter:

UECapabilityEnquiry-IEs ::= SEQUENCE {
    ue-CapabilityRAT-RequestList    UE-CapabilityRAT-RequestList,
    lateNonCriticalExtension        OCTET STRING                OPTIONAL,
    ue-CapabilityEnquiryExt         OCTET STRING (CONTAINING
                                        UECapabilityEnquiryExt-IEs) OPTIONAL,
    nonCriticalExtension            SEQUENCE {}                 OPTIONAL
}

UE-CapabilityRAT-RequestList ::= SEQUENCE (SIZE (1..maxRAT-CapabilityContainers))
                                     OF UE-CapabilityRAT-Request
    -- maxRAT-CapabilityContainers INTEGER ::= 8

UE-CapabilityRAT-Request ::= SEQUENCE {
    rat-Type                        RAT-Type,
    capabilityRequestFilter         OCTET STRING                OPTIONAL,
    ...
}

RAT-Type ::= ENUMERATED { nr, eutra-nr, eutra, utra-fdd-v1610, ... }

UE-CapabilityRequestFilterNR ::= SEQUENCE {
    frequencyBandList               FreqBandList                OPTIONAL,
    nonCriticalExtension            UE-CapabilityRequestFilterNR-v1540-IEs
                                                                OPTIONAL
}

UE-CapabilityRequestFilterCommon ::= SEQUENCE {
    mfbi-IndicatorNR                ENUMERATED {true}           OPTIONAL,
    omitEN-DC                       ENUMERATED {true}           OPTIONAL,
    ...
}

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

UE-CapabilityRAT-Container ::= SEQUENCE {
    rat-Type                        RAT-Type,
    ue-CapabilityRAT-Container      OCTET STRING   -- separately encoded
}

Listing 1. Abridged from TS 38.331 clause 6.2.2. ... marks extension markers and omitted members.

Then the container itself, and the indirection:

UE-NR-Capability ::= SEQUENCE {
    accessStratumRelease            AccessStratumRelease,
    pdcp-Parameters                 PDCP-Parameters,
    rlc-Parameters                  RLC-Parameters              OPTIONAL,
    mac-Parameters                  MAC-Parameters              OPTIONAL,
    phy-Parameters                  Phy-Parameters,
    rf-Parameters                   RF-Parameters,
    measAndMobParameters            MeasAndMobParameters        OPTIONAL,
    fdd-Add-UE-NR-Capabilities      UE-NR-CapabilityAddXDD-Mode OPTIONAL,
    tdd-Add-UE-NR-Capabilities      UE-NR-CapabilityAddXDD-Mode OPTIONAL,
    fr1-Add-UE-NR-Capabilities      UE-NR-CapabilityAddFRX-Mode OPTIONAL,
    fr2-Add-UE-NR-Capabilities      UE-NR-CapabilityAddFRX-Mode OPTIONAL,
    featureSets                     FeatureSets                 OPTIONAL,
    featureSetCombinations          SEQUENCE (SIZE (1..maxFeatureSetCombinations))
                                        OF FeatureSetCombination OPTIONAL,
    lateNonCriticalExtension        OCTET STRING                OPTIONAL,
    nonCriticalExtension            UE-NR-Capability-v1530-IEs  OPTIONAL
}

AccessStratumRelease ::= ENUMERATED {rel15, rel16, rel17, rel18,
                                     spare4, spare3, spare2, spare1, ...}

RF-Parameters ::= SEQUENCE {
    supportedBandListNR             SEQUENCE (SIZE (1..maxBands)) OF BandNR,
    supportedBandCombinationList    BandCombinationList         OPTIONAL,
    appliedFreqBandListFilter       FreqBandList                OPTIONAL,
    ...
}

BandCombination ::= SEQUENCE {
    bandList                    SEQUENCE (SIZE (1..maxSimultaneousBands))
                                    OF BandParameters,
    featureSetCombination       FeatureSetCombinationId,
    ca-ParametersEUTRA          CA-ParametersEUTRA              OPTIONAL,
    ca-ParametersNR             CA-ParametersNR                 OPTIONAL,
    mrdc-Parameters             MRDC-Parameters                 OPTIONAL,
    supportedBandwidthCombinationSet BIT STRING (SIZE (1..32))  OPTIONAL,
    powerClass-v1530            ENUMERATED {pc2}                OPTIONAL,
    ...
}

FeatureSetCombination ::= SEQUENCE (SIZE (1..maxSimultaneousBands))
                              OF FeatureSetsPerBand
FeatureSetsPerBand    ::= SEQUENCE (SIZE (1..maxFeatureSetsPerBand))
                              OF FeatureSet

FeatureSet ::= CHOICE {
    eutra   SEQUENCE { downlinkSetEUTRA FeatureSetEUTRA-DownlinkId,
                       uplinkSetEUTRA   FeatureSetEUTRA-UplinkId },
    nr      SEQUENCE { downlinkSetNR    FeatureSetDownlinkId,
                       uplinkSetNR      FeatureSetUplinkId }
}

FeatureSets ::= SEQUENCE {
    featureSetsDownlink       SEQUENCE (SIZE (1..maxDownlinkFeatureSets))
                                  OF FeatureSetDownlink        OPTIONAL,
    featureSetsDownlinkPerCC  SEQUENCE (SIZE (1..maxPerCC-FeatureSets))
                                  OF FeatureSetDownlinkPerCC   OPTIONAL,
    featureSetsUplink         SEQUENCE (SIZE (1..maxUplinkFeatureSets))
                                  OF FeatureSetUplink          OPTIONAL,
    featureSetsUplinkPerCC    SEQUENCE (SIZE (1..maxPerCC-FeatureSets))
                                  OF FeatureSetUplinkPerCC     OPTIONAL,
    ...
}

FeatureSetDownlink ::= SEQUENCE {
    featureSetListPerDownlinkCC SEQUENCE (SIZE (1..maxNrofServingCells))
                                    OF FeatureSetDownlinkPerCC-Id,
    intraBandFreqSeparationDL   FreqSeparationClass             OPTIONAL,
    scalingFactor               ENUMERATED {f0p4, f0p75, f0p8}  OPTIONAL,
    scellWithoutSSB             ENUMERATED {supported}          OPTIONAL,
    csi-RS-MeasSCellWithoutSSB  ENUMERATED {supported}          OPTIONAL,
    type1-3-CSS                 ENUMERATED {supported}          OPTIONAL,
    pdcch-MonitoringAnyOccasions ENUMERATED {withoutDCI-Gap,
                                            withDCI-Gap}       OPTIONAL,
    ...                            -- plus several deprecated dummy fields
}

FeatureSetDownlinkPerCC ::= SEQUENCE {
    supportedSubcarrierSpacingDL SubcarrierSpacing,
    supportedBandwidthDL         SupportedBandwidth,
    channelBW-90mhz              ENUMERATED {supported}         OPTIONAL,
    maxNumberMIMO-LayersPDSCH    MIMO-LayersDL                  OPTIONAL,
    supportedModulationOrderDL   ModulationOrder                OPTIONAL,
    ...
}

SupportedBandwidth ::= CHOICE {
    fr1  ENUMERATED {mhz5, mhz10, mhz15, mhz20, mhz25, mhz30, mhz40,
                     mhz50, mhz60, mhz80, mhz100},
    fr2  ENUMERATED {mhz50, mhz100, mhz200, mhz400}
}
MIMO-LayersDL  ::= ENUMERATED {twoLayers, fourLayers, eightLayers}
ModulationOrder ::= ENUMERATED {bpsk-halfpi, bpsk, qpsk, qam16,
                                qam64, qam256}

FeatureSetCombinationId    ::= INTEGER (0..maxFeatureSetCombinations-1)
FeatureSetDownlinkId       ::= INTEGER (0..maxDownlinkFeatureSets)
FeatureSetUplinkId         ::= INTEGER (0..maxUplinkFeatureSets)
FeatureSetDownlinkPerCC-Id ::= INTEGER (1..maxPerCC-FeatureSets)
FeatureSetUplinkPerCC-Id   ::= INTEGER (1..maxPerCC-FeatureSets)

Listing 2. Abridged from TS 38.331 clause 6.3.3. The last five lines are the whole of §7.2 in ASN.1 form -- note the three different lower bounds.

📘
Spec Detail

FeatureSetDownlink and several other structures contain members literally named dummy, dummy1 through dummy7. They are placeholders for capabilities that were defined and then withdrawn during Rel-15 standardisation, kept because removing a member would shift the PER encoding of everything after it. Decoders show them; they mean nothing; and their presence bits still occupy space in the preamble.

16. Parameter and Limit Reference

Constant / fieldValue or rangeTypicalEffect
maxBandComb
65 5361 000 - 3 000 declaredCeiling on supportedBandCombinationList. Nothing approaches it, but it is why the length field is wide.
maxSimultaneousBands
322 - 5Bands in one combination, and therefore entries in one FeatureSetCombination.
maxFeatureSetsPerBand
1281 - 4Alternative feature sets offered for one band within one combination.
maxFeatureSetCombinations
1 024100 - 600Ceiling on the middle layer of the indirection.
maxDownlinkFeatureSets / maxUplinkFeatureSets1 02420 - 150Ceiling on featureSetsDownlink / featureSetsUplink.
maxPerCC-FeatureSets
1 02410 - 60Ceiling on the per-carrier value tables.
maxBands
1 0241 - 45Ceiling on supportedBandListNR.
maxNrofServingCells
322 - 8Bounds featureSetListPerDownlinkCC, i.e. carriers per band.
maxRAT-CapabilityContainers
81 - 3RATs per enquiry and per response.
accessStratumRelease
rel15 .. rel18 plus sparesrel16 or rel17Bounds which non-critical extensions may be present. Gates nothing on its own (§14).
maxNumberMIMO-LayersPDSCH
twoLayers, fourLayers, eightLayersfourLayers on FR1Per carrier. Multiply by carriers for the aggregate.
supportedModulationOrderDL
bpsk-halfpi, bpsk, qpsk, qam16, qam64, qam256qam256Selects the MCS table the network may use. See 08 Scheduling.
scalingFactor
f0p4, f0p75, f0p8 (absent = 1)absentThe f term in the TS 38.306 peak-rate formula. Easy to miss and worth up to 60 %.
intraBandFreqSeparationDL
FreqSeparationClass i, ii, iiiclass iHow far apart intra-band non-contiguous carriers may be. An RF constraint expressed inside a feature set.
PDCP SDU limit9 000 octets--The segmentation threshold (§11).
segmentNumber
0 .. 150 - 5At most 16 segments per RRC message.

Table 16. Capability limits and the fields that most often matter. The "typical" column is observational and varies widely by device class.

17. Failure Modes and What Each One Means

FailureDetected byWhat happensDiagnostic pointer
Filter omits a band the network actually deploysNobodyThe UE never reports the band; the gNB concludes it is unsupported and redirects or releasesCompare appliedFreqBandListFilter in the response against the cell's band. This is the single most common capability configuration error.
Cached container reused in a cell outside its filterNobodySame effect as above, but only in some cells -- so it looks like a cell-specific faultKey the cache on the applied filter. Check whether the failing cells share a band absent from the filter.
Message exceeds 9 000 octets and the UE cannot segment (Rel-15)UE RRCThe UE cannot send the response at all; the procedure times outA UECapabilityEnquiry with no answer, from a Rel-15 UE, with no filter. Add a filter -- there is no other fix.
A segment is lost and never retransmittedNobody -- there is no reassembly timerThe gNB waits indefinitely for lastSegment; the capability is never availableCount ULDedicatedMessageSegment PDUs against segmentNumber. RLC AM should prevent this, so its occurrence points at an RLC or PDCP problem.
Decoder off-by-one in the feature set chainNobodyWrong bandwidth, rank or modulation is configured; every grant using it failsRe-walk the chain by hand (§8) and check the base convention of each id (§7.2). A downlinkSetNR of 0 read as an index is the classic.
Duplex-mode or FR overlay ignoredNobodyA capability valid on FDD is configured on a TDD carrierResolve fdd-Add- / tdd-Add- / fr1-Add- / fr2-Add- before using any top-level value.
Feature gated on accessStratumRelease instead of its own fieldNobodyThe feature is configured and silently not used, or used and failsAffects a subset of one device model. Check the specific capability field, not the release (§14.1).
Stale cache after a firmware updateNobodyThe network configures against capabilities the device no longer declaresFleet-wide degradation correlating with a firmware rollout and with no network change. Flush the cache and re-enquire one device to compare.
Enquiry sent before AS security activationUE RRC -- the procedure is not permittedThe UE does not respond, or responds and the exchange is a privacy violationCheck the ordering against SecurityModeComplete. See 27 AS Security Mode.
MRDC combination index resolved against the NR container's featureSetCombinationsNobodyCompletely wrong capability attributed to an EN-DC combinationThe two containers have separate combination lists and share only the FeatureSets tables (§12).
RRCReconfiguration rejected after a capability decodegNB, on RRCReconfigurationFailure or a missing CompleteReconfiguration failure and, depending on the gNB, re-establishmentThe one loud failure in this table. Diff the configuration sent against the capability field by field.

Table 17. Capability failure modes. Ten of the eleven are detected by nobody, which is why capability problems are usually found by someone comparing two devices rather than by an alarm.

💡
Key Point

The recurring pattern: capability faults do not raise errors, because both sides believe they are behaving correctly. The UE ignores what it cannot do, and the specification requires it to. If you need a signal, you have to build it -- compare the configuration the gNB emitted against the capability it received, field by field, and alert on any configuration that exceeds a declared ceiling.

18. Illustrative Message Traces

🔍
About These Traces

Illustrative trace. Field names and encodings follow 3GPP; the values are constructed for this document and are not a capture from any deployed or lab network.

18.1 An unfiltered enquiry and its consequences

Capability Enquiry and Transfer, With Segmentation and a Filtered RetryCapability Enquiry and Transfer, With Segmentation and a Filtered RetryUnfilteredFilteredCachedUEgNBAMFAS security has already been activated -- SecurityModeComplete has beenreceived. The network is not permitted to enquire before this point,because the answer is privacy-relevant.NGAP INITIAL CONTEXT SETUP REQUESTno UE Radio Capability IE -- nothing cached1UECapabilityEnquiry #1ue-CapabilityRAT-RequestList = [ nr ], no filter2ULDedicatedMessageSegment 0 .. 441 700 octets > 9000-octet PDCP SDU limit -> RRC segmentation3ULDedicatedMessageSegment 5 (last)rrc-MessageSegmentType = lastSegmentreassembled: 2 940 band combinations, 41.7 kBsix segments, ~30 ms of SRB1UECapabilityEnquiry #2 (filtered)frequencyBandList = [n78, n3, n1] | omitEN-DC = true4UECapabilityInformation3 100 octets, one PDCP SDU, 46 band combinations5NGAP UE RADIO CAPABILITY INFO INDICATIONthe AMF caches the container for next time6the UE's next connection, in any cell of this AMFNGAP INITIAL CONTEXT SETUP REQUESTUE Radio Capability IE present -> no enquiry at allThe second enquiry is not a retry after a failure -- the first one succeeded. It is a deliberate second pass that costs oneround trip and saves 38 kB on every subsequent transfer.
Figure 7. The exchange the traces below describe, including the segmentation the unfiltered response needs and the caching that follows the filtered one.
[RRC] unfiltered enquiry and segmented response
10:22:04.118  [RRC-DL] UECapabilityEnquiry
                rrc-TransactionIdentifier ....... 1
                ue-CapabilityRAT-RequestList
                 [0] rat-Type .................. nr
                     capabilityRequestFilter ... (absent)   -- ** no filter **
                ue-CapabilityEnquiryExt ......... (absent)

10:22:04.142  [RRC-UL] ULDedicatedMessageSegment
                rrc-MessageSegmentNumber ........ 0
                rrc-MessageSegmentType .......... notLastSegment
                rrc-MessageSegmentContainer ..... 8 800 octets
10:22:04.151  [RRC-UL] ULDedicatedMessageSegment  1  notLastSegment  8 800
10:22:04.159  [RRC-UL] ULDedicatedMessageSegment  2  notLastSegment  8 800
10:22:04.168  [RRC-UL] ULDedicatedMessageSegment  3  notLastSegment  8 800
10:22:04.176  [RRC-UL] ULDedicatedMessageSegment  4  notLastSegment  5 100
10:22:04.181  [RRC-UL] ULDedicatedMessageSegment  5  lastSegment     1 400

10:22:04.182  [RRC]    reassembled UECapabilityInformation, 41 700 octets
                rrc-TransactionIdentifier ....... 1     -- matches
                ue-CapabilityRAT-ContainerList
                 [0] rat-Type .................. nr
                     ue-CapabilityRAT-Container . 41 612 octets

-- 63 ms of SRB1 occupied, six PDCP SDUs, for a container in which the
   gNB will use fewer than 50 of the 2 940 band combinations.

Listing 3. The unfiltered case. Note that segmentation is working correctly here -- the problem is not a failure, it is the cost.

18.2 The filtered enquiry

[RRC] filtered enquiry and response
10:22:04.240  [RRC-DL] UECapabilityEnquiry
                rrc-TransactionIdentifier ....... 2
                ue-CapabilityRAT-RequestList
                 [0] rat-Type .................. nr
                     capabilityRequestFilter
                      UE-CapabilityRequestFilterNR
                       frequencyBandList
                        [0] bandInformationNR  bandNR 78
                              maxCarriersRequestedDL ... 2
                        [1] bandInformationNR  bandNR 3
                        [2] bandInformationNR  bandNR 1
                ue-CapabilityEnquiryExt
                 UECapabilityEnquiryExt-IEs
                  capabilityRequestFilterCommon
                   omitEN-DC ..................... true
                   mfbi-IndicatorNR .............. true

10:22:04.268  [RRC-UL] UECapabilityInformation   (3 100 octets, unsegmented)
                rrc-TransactionIdentifier ....... 2
                ue-CapabilityRAT-ContainerList
                 [0] rat-Type .................. nr

-- decoded container, top level:
     accessStratumRelease ................ rel17
     pdcp-Parameters
       supportedROHC-Profiles .......... profile0x0104, profile0x0106
       maxNumberROHC-ContextSessions ... cs16
     rlc-Parameters
       am-WithShortSN .................. supported
       um-WithLongSN ................... supported
     rf-Parameters
       supportedBandListNR ............. n1, n3, n78    (3 of 41 reported)
       supportedBandCombinationList .... 46 entries
       appliedFreqBandListFilter ....... n78, n3, n1    -- echo of the filter
     featureSets
       featureSetsDownlink ............. 11 entries
       featureSetsDownlinkPerCC ........ 6 entries
       featureSetsUplink ............... 9 entries
       featureSetsUplinkPerCC .......... 5 entries
     featureSetCombinations ............ 18 entries

-- 46 combinations resolving onto 6 downlink per-CC profiles: the pyramid
   of S7.3, at small scale.

Listing 4. The same device, filtered. appliedFreqBandListFilter is what makes this container safe to cache -- and unsafe to reuse in an n41 cell.

18.3 Walking the dereference in a log

[gNB internal] capability resolution
-- gNB internal trace of the capability resolution for SCell addition

10:22:04.291  [CAP] intended carriers: n78 100 MHz + n78 100 MHz + n1 20 MHz
10:22:04.291  [CAP] searching supportedBandCombinationList for bandList
                    { n78 classC, n1 classA } ... hit at index 37
10:22:04.291  [CAP] bandCombination[37].featureSetCombination = 12
10:22:04.291  [CAP] featureSetCombinations[12]
                      [0] nr: downlinkSetNR=5  uplinkSetNR=3   -- band n78
                      [1] nr: downlinkSetNR=9  uplinkSetNR=7   -- band n1
10:22:04.292  [CAP] featureSetsDownlink[5].featureSetListPerDownlinkCC
                      = [ 2, 2 ]                         -- 2 CCs on n78
                    featureSetsDownlink[5].scalingFactor = (absent) -> f = 1
10:22:04.292  [CAP] featureSetsDownlink[9].featureSetListPerDownlinkCC
                      = [ 4 ]                            -- 1 CC on n1
10:22:04.292  [CAP] featureSetsDownlinkPerCC[2]
                      supportedSubcarrierSpacingDL ... kHz30
                      supportedBandwidthDL ........... fr1: mhz100
                      maxNumberMIMO-LayersPDSCH ...... fourLayers
                      supportedModulationOrderDL ..... qam256
10:22:04.292  [CAP] featureSetsDownlinkPerCC[4]
                      supportedSubcarrierSpacingDL ... kHz15
                      supportedBandwidthDL ........... fr1: mhz20
                      maxNumberMIMO-LayersPDSCH ...... twoLayers
                      supportedModulationOrderDL ..... qam256
10:22:04.293  [CAP] ca-ParametersNR.maxNumberOfServingCells = 4
                    -> 3 requested <= 4, ok
10:22:04.293  [CAP] resolved: 220 MHz aggregated, DL layers 4+4+2,
                    mcs-Table qam256 permitted on all three carriers
10:22:04.294  [RRC-DL] RRCReconfiguration  (SCellToAddModList: 2 entries)

Listing 5. The dereference of §8 as a gNB would log it. Every line is an index lookup; the numbers appear only in the last two.

18.4 A capability ignored

[gNB] rank configured beyond the declared capability
-- a gNB that gated on accessStratumRelease instead of the capability field

11:40:12.002  [CAP] accessStratumRelease = rel17
11:40:12.002  [CAP] featureSetsDownlinkPerCC[1].maxNumberMIMO-LayersPDSCH
                      = twoLayers                         -- ** two, not four **
11:40:12.003  [SCHED] rank adaptation enabled, max rank 4  (from release)
11:40:12.010  [RRC-DL] RRCReconfiguration
                 csi-ReportConfig  codebookConfig  maxNumberOfLayers .. 4
11:40:12.041  [RRC-UL] RRCReconfigurationComplete       -- accepted!

11:40:13.220  [PHY-DL] DCI 1_1  rank 4  MCS 22  -> HARQ NACK
11:40:13.224  [PHY-DL] DCI 1_1  rank 4  MCS 22  -> HARQ NACK  (RV1)
11:40:13.228  [PHY-DL] DCI 1_1  rank 4  MCS 22  -> HARQ NACK  (RV2)
11:40:13.232  [PHY-DL] DCI 1_1  rank 4  MCS 22  -> HARQ NACK  (RV3)
11:40:13.236  [MAC]    max HARQ retransmissions reached, TB discarded
11:40:13.240  [PHY-UL] CSI report: RI = 2, CQI 14, SINR 24.8 dB
                       -- excellent radio, RI never above 2

-- signature: 100 % BLER on rank-3 and rank-4 grants, 0 % on rank-1 and
   rank-2, at 25 dB SINR. Moving the UE closer changes nothing.
-- the UE accepted the reconfiguration because it is required to ignore
   a codebook configuration it cannot use. Nothing failed loudly.

Listing 6. The characteristic signature of a capability mismatch: failure that is flat against SINR, and a reported rank that never reaches the configured maximum.

18.5 A cache reused outside its filter

[NGAP/RRC] cached capability outside its filter
-- UE moves from an n78/n3/n1 cluster into a cell on n41

14:05:31.700  [NGAP-DL] INITIAL CONTEXT SETUP REQUEST
                UE Radio Capability ....... present, 3 100 octets
14:05:31.702  [CAP] using cached container, no enquiry
14:05:31.702  [CAP] appliedFreqBandListFilter = n78, n3, n1
14:05:31.702  [CAP] serving cell band = n41
14:05:31.702  [CAP] n41 not in supportedBandListNR
14:05:31.703  [RRC-DL] RRCRelease
                redirectedCarrierInfo ..... (n78 carrier)

-- the UE supports n41 perfectly well. Nobody asked.
-- correct behaviour: appliedFreqBandListFilter does not cover the serving
   band, so the cache is not applicable and a fresh enquiry is required.

Listing 7. Why appliedFreqBandListFilter exists. The cache was valid, the decode was correct, and the conclusion was wrong.

19. Release Deltas: Rel-15 to Rel-18

ReleaseChangeWhy it matters when reading a capability
Rel-15UECapabilityEnquiry / UECapabilityInformation; UE-NR-Capability; band combinations; the feature set indirection; UE-MRDC-CapabilityThe baseline. Everything in §3 to §9 is Rel-15 and unchanged.
Rel-15capabilityRequestFilter (frequencyBandList) and capabilityRequestFilterCommon (omitEN-DC)Filtering existed from the start, which tells you the size problem was foreseen.
Rel-15NGAP UE Radio Capability caching at the AMF; UE Radio Capability for PagingThe reason many connections show no enquiry at all.
Rel-15Downlink RRC segmentation for RRCReconfigurationThe downlink direction was solved first; uplink had to wait.
Rel-16Uplink RRC segmentation -- ULDedicatedMessageSegment, gated by a UE capabilityBefore this, an unfiltered enquiry to a large device simply could not be answered.
Rel-16RACS -- UE Radio Capability ID, the UCMF, and manufacturer- or network-assigned IDsCapability containers now live outside the RAN and outside the AMF, and survive mobility and roaming.
Rel-16rat-Type utra-fdd; NR-DC capabilities; RRC segmentation capability signallingMore RAT containers in one exchange.
Rel-17RedCap capability signalling; reduced band combination and feature set expectations for RedCap devicesA RedCap container is small enough that filtering is often unnecessary, which changes what "normal" looks like.
Rel-171024QAM downlink for FR1; extended ModulationOrder handlingThe modulation order field now reaches beyond qam256 in extensions, not in the root enumeration.
Rel-17eDRX, paging subgrouping and PEI capabilitiesSupport for the mechanisms in 19 Paging is declared here.
Rel-18Further band combination growth; network energy saving capabilities; AI/ML-related capability reporting frameworksThe size trend continues; the mitigations are all on the caching and filtering side, not the encoding side.

Table 18. Capability-relevant changes by release. Note that the encoding has never been redesigned -- every mitigation has been about asking for less or transferring less often.

20. Reading Capability in Logs: A Checklist

1. Find out whether an enquiry happened at all. If there is no UECapabilityEnquiry, look for the UE Radio Capability IE in the NGAP INITIAL CONTEXT SETUP REQUEST. A cache hit is the normal case in a mature network (§13).

2. Read the applied filter before anything else in the container. appliedFreqBandListFilter tells you what the UE was allowed to report. Everything absent from the container is either unsupported or outside that filter, and you cannot tell which without it (§10).

3. Check the access stratum release, then ignore it as a feature gate. Use accessStratumRelease only to bound which extension containers can be present. Every individual feature has its own field (§14.1).

4. Resolve the duplex and frequency-range overlays. Apply fdd-Add-, tdd-Add-, fr1-Add- and fr2-Add- differences before quoting any top-level value (§5).

5. Count the four structures. Band combinations, feature set combinations, downlink feature sets, per-CC feature sets. The ratios tell you immediately whether the container is a small filtered one or a full flagship dump (§7.3).

6. Walk the chain by hand for the combination in question. Band combination to featureSetCombination to featureSetsDownlink to featureSetsDownlinkPerCC. Watch the base convention at each hop, and remember that a downlink or uplink set id of 0 means not supported (§7.2).

7. Do not forget the two outer ceilings. scalingFactor and ca-ParametersNR both sit above the per-CC values and can lower them further (§8.1, §6).

8. Diff the configuration against the capability. Take the RRCReconfiguration the gNB actually sent and check every rank, bandwidth, SCS, modulation and SN length against the resolved ceilings. This is the only reliable way to catch a capability fault, because nothing raises an error (§17).

9. When throughput or BLER is flat against SINR, suspect capability. A radio problem improves as the UE approaches the cell. A capability mismatch does not (§9).

10. For EN-DC, get the container from the X2 or Xn message. The NR capability travels through the eNB as opaque octets and may not appear decoded in either RAT's own log (§12).

11. If a fleet-wide problem correlates with a firmware rollout, flush the capability cache. A stale cached container behaves exactly like a network misconfiguration and is invisible in every RRC log (§13).

21. Glossary and References

TermExpansionMeaning in this document
UE-NR-Capability
--The NR-only capability container. Carried as an OCTET STRING inside ue-CapabilityRAT-ContainerList.
UE-MRDC-Capability
--The dual-connectivity container: which NR and LTE bands may be used together, and how their uplinks coexist.
Band combination--A set of bands the UE can operate simultaneously, each with a CA bandwidth class. Not the same as the list of supported bands.
Feature set--A shared table entry holding per-band-per-combination or per-carrier capabilities, referenced by index from band combinations.
Feature set combination--The middle layer: a per-band list of downlink and uplink feature set ids, aligned positionally with a band combination's bandList.
PerCC feature set--FeatureSetDownlinkPerCC / FeatureSetUplinkPerCC. The only place bandwidth, SCS, MIMO layers and modulation order are actually stated.
Capability filter--frequencyBandList, omitEN-DC and friends. A whitelist that bounds what the UE may report.
appliedFreqBandListFilter
--The UE's echo of the filter it applied. Determines the validity domain of a cached container.
accessStratumRelease
--The highest release the UE implements. Bounds extension presence; gates no individual feature.
RACSRadio Capability Signalling optimisationRel-16 mechanism replacing the container with a short UE Radio Capability ID resolved via the UCMF.
UCMFUE radio Capability Management FunctionThe 5GC function that stores capability containers against IDs.
RRC segmentation--Splitting an RRC message across up to 16 ...DedicatedMessageSegment PDUs when it exceeds the 9000-octet PDCP SDU limit.
Unaligned PERPacked Encoding Rules, unaligned variantThe bit-level encoding of RRC messages. No tags, no lengths on fixed-size fields, presence bitmaps before every extensible SEQUENCE.
scalingFactor
--The f term of the TS 38.306 peak-rate formula, declared one level above the values it scales.

References

  • 3GPP TS 38.331 -- RRC protocol specification. Clause 5.6.1 (UE capability transfer), clause 5.7.7 (RRC message segmentation), clause 6.2.2 (UECapabilityEnquiry, UECapabilityInformation, ULDedicatedMessageSegment), clause 6.3.3 (UE-NR-Capability, RF-Parameters, BandCombination, FeatureSets, FeatureSetDownlink, FeatureSetDownlinkPerCC, UE-CapabilityRequestFilterNR, UE-CapabilityRequestFilterCommon), and the maximum-value constant definitions.
  • 3GPP TS 38.306 -- UE radio access capabilities. Clause 4.1.2 (approximate maximum data rate), clause 4.2 (per-parameter definitions and their mandatory/optional classification). This is the normative meaning of every field in the container.
  • 3GPP TS 36.331 -- E-UTRA RRC. UE-EUTRA-Capability, and the LTE UECapabilityEnquiry that carries NR containers in EN-DC.
  • 3GPP TS 38.323 -- PDCP specification. Clause 4.3.1 (maximum supported PDCP SDU size, 9000 octets -- the segmentation threshold).
  • 3GPP TS 38.413 -- NGAP. UE RADIO CAPABILITY INFO INDICATION, the UE Radio Capability, UE Radio Capability ID and UE Radio Capability for Paging IEs, and INITIAL CONTEXT SETUP REQUEST.
  • 3GPP TS 23.501 -- System architecture. Clause 5.4.4a (RACS and the UCMF), and the capability-related aspects of registration.
  • 3GPP TS 23.502 -- Procedures for the 5G System. UE radio capability ID allocation and the UCMF service operations.
  • 3GPP TS 38.101-1 / 38.101-2 -- UE radio transmission and reception. Clause 5.3A (CA bandwidth classes and bandwidth combination sets), power classes, and the RF constraints that band combinations encode.
  • 3GPP TS 38.214 -- Physical layer procedures for data. The MCS tables that supportedModulationOrderDL selects between, and the PRB counts per channel bandwidth used in the §8.1 arithmetic.

Companion documents in this set

  • 03 Random Access -- 2-step RACH, one of the clearest examples of an optional capability that must be declared before it can be configured.
  • 08 Scheduling -- the MCS tables and rank adaptation that per-CC capabilities bound.
  • 09 LCP -- what mac-Parameters LCP restrictions gate.
  • 11 DRX -- capability-gated DRX and eDRX behaviour.
  • 13 RRC Overview -- unaligned PER, SRB1, and the RRC segmentation procedure this document's largest message depends on.
  • 15 RRC Procedures -- RRCReconfiguration, the message that spends what the capability allows.
  • 19 Paging -- UE Radio Capability for Paging, and the Rel-17 paging features declared here.
  • 20 Measurements / 21 Measurement Gaps and SMTC -- what measAndMobParameters gates.
  • 22-25 Handover documents -- DAPS and conditional handover, both optional and both capability-gated.
  • 27 AS Security Mode -- why the enquiry must come after security activation, and where the UE's security capabilities actually live.