UE Capability Transfer in 5G NR
How the network learns what the UE supports, and feature-set / band-combination signalling.
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
- 01Why the Network Has to Ask
- 02When the Enquiry Happens, and When It Does Not
- 03UECapabilityEnquiry: the Request
- 04UECapabilityInformation: the Response and Its Containers
- 05Inside UE-NR-Capability: the Top-Level Structure
- 06Band Combinations
- 07The Feature Set Indirection
- 08A Worked Dereference, End to End
- 09What the Network Actually Does With It
- 10Capability Filtering, and Why It Is Not Optional
- 11Message Size, Segmentation and Growth
- 12EN-DC and NR-DC: UE-MRDC-Capability
- 13Capability Caching: NGAP, the AMF and RACS
- 14Mandatory, Optional, and the accessStratumRelease Trap
- 15ASN.1 Reference
- 16Parameter and Limit Reference
- 17Failure Modes and What Each One Means
- 18Illustrative Message Traces
- 19Release Deltas: Rel-15 to Rel-18
- 20Reading Capability in Logs: A Checklist
- 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.
| Dimension | Spread across real devices | Where it is declared | What happens if the network assumes wrong |
|---|---|---|---|
| Downlink MIMO layers per carrier | 1, 2, 4 or 8 | maxNumberMIMO-LayersPDSCH in FeatureSetDownlinkPerCC | Every high-rank grant fails. Looks like a coverage problem, but the BLER is flat against SINR. |
| Highest downlink modulation | QPSK, 64QAM, 256QAM, 1024QAM (Rel-17) | supportedModulationOrderDL in FeatureSetDownlinkPerCC | The UE cannot demodulate the high MCS rows, so throughput collapses exactly when radio conditions are best. |
| Channel bandwidth per carrier | 5 MHz to 100 MHz on FR1, up to 400 MHz on FR2 | supportedBandwidthDL / UL in FeatureSetDownlinkPerCC | RRCReconfiguration is rejected with a failure, or the UE silently cannot receive part of the BWP. |
| Carriers aggregated | 1 to 16 | bandList plus the CA bandwidth class, and the length of featureSetListPerDownlinkCC | SCell addition fails, or succeeds and then the SCell never carries data. |
| Supported bands | 1 band on a RedCap sensor, 40+ on a flagship | supportedBandListNR in RF-Parameters | The 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 other | Individual ENUMERATED {supported} fields throughout the containers | The 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 generation | rlc-Parameters, pdcp-Parameters | Bearer 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.
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.
| Occasion | Why then | What is typically requested |
|---|---|---|
| Immediately after AS security activation, during initial context setup | The gNB needs the capability before it can configure anything beyond SRB1 and a default DRB | nr alone in an SA-only deployment; nr and eutra-nr where EN-DC is offered |
| Not at all, because the AMF supplied a cached container | The 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, filtered | The first unfiltered response was too large to be worth storing or re-fetching | nr with a frequencyBandList naming only the deployed bands |
| On PLMN change | Capabilities may legitimately differ per PLMN, and a previously cached container may not apply | everything relevant to the new PLMN |
| When adding a RAT the network did not previously ask about | e.g. NR-DC or EN-DC becomes relevant only after the UE is already connected | eutra-nr or eutra in a later enquiry |
| After the UE indicates its capability has changed | Rare, 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.
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
| IE | Type | Presence | What it does |
|---|---|---|---|
rrc-TransactionIdentifier | INTEGER (0..3) | Mandatory | Matched 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-Request | Mandatory | One 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 entry | Selects which capability structure the UE must encode into the corresponding container. |
capabilityRequestFilter | OCTET STRING containing UE-CapabilityRequestFilterNR | Optional | Per-RAT filter. For nr it carries frequencyBandList and srs-SwitchingTimeRequest. Absent means tell me everything. |
ue-CapabilityEnquiryExt | OCTET STRING containing UECapabilityEnquiryExt-IEs | Optional | Wrapper for capabilityRequestFilterCommon, which applies across all requested RATs rather than to one. |
capabilityRequestFilterCommon | mfbi-IndicatorNR, omitEN-DC | Optional | omitEN-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-Type | Container the UE returns | Contains | Requested when |
|---|---|---|---|
nr | UE-NR-Capability | Everything NR-only: bands, band combinations, feature sets, per-layer parameters | Always. 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 parameters | Where EN-DC or NR-DC is offered |
eutra | UE-EUTRA-Capability (defined in TS 36.331) | The LTE capability, unchanged from LTE | Where EN-DC is offered, or for inter-RAT mobility to LTE |
utra-fdd | UE-CapabilityRAT-Container for UTRA FDD | Legacy 3G capability | Almost 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.
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
| IE | Presence | What is in it | Why you care |
|---|---|---|---|
accessStratumRelease | Mandatory | ENUMERATED {rel15, rel16, rel17, rel18, ...} | The highest release the UE claims. It gates nothing on its own -- see §14. |
pdcp-Parameters | Mandatory | ROHC profiles, maxNumberROHC-ContextSessions, uplinkOnlyROHC-Profiles, out-of-order delivery support | Get this wrong and the bearer fails at establishment, not later. |
rlc-Parameters | Optional | am-WithShortSN, um-WithShortSN, um-WithLongSN | SN length must match on both sides or the RLC entity resets in the first window wrap. |
mac-Parameters | Optional | LCP restrictions, skipUplinkTxDynamic, recommended bit rate, multiple-config support | Affects scheduling and the LCP behaviour in 09 LCP. |
phy-Parameters | Mandatory | The largest single grab-bag: PUCCH formats, CSI reporting, dynamic SFI, PTRS, DMRS, precoding, split across FR1/FR2 and FDD/TDD sub-IEs | Almost every PHY configuration decision reads from here. |
rf-Parameters | Mandatory | supportedBandListNR, supportedBandCombinationList, appliedFreqBandListFilter | This is where the size lives. §6. |
measAndMobParameters | Optional | Measurement and mobility support: numbers of measurement objects, handover flavours, CSI-RS RRM, SFTD | Read together with 20 Measurements and 21 Measurement Gaps. |
fdd-Add-UE-NR-Capabilities / tdd-Add-... | Optional | Duplex-specific differences from the values above | A 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-... | Optional | Frequency-range-specific differences | Same trap, different axis. |
featureSets | Optional | featureSetsDownlink, featureSetsUplink, featureSetsDownlinkPerCC, featureSetsUplinkPerCC -- each up to 1024 entries | The value tables that everything else indexes into. §7. |
featureSetCombinations | Optional | Up to 1024 combinations, each a per-band list of feature-set index pairs | The 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.
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.
| IE | Range | What it means | Note |
|---|---|---|---|
bandList | 1 .. 32 entries (maxSimultaneousBands) | The bands in this combination, each with a CA bandwidth class for DL and UL | Ordered. The order is load-bearing -- featureSetCombination entries align with it positionally. |
ca-BandwidthClassDL-NR / UL-NR | A, B, C, ... (TS 38.101-1) | How many contiguous carriers on this band and the aggregated bandwidth class | Bounds the carrier count; the exact count comes from the length of featureSetListPerDownlinkCC. |
featureSetCombination | INTEGER (0 .. 1023) | A 0-based index into UE-NR-Capability.featureSetCombinations | The one field that turns a list of bands into a set of numbers. §7. |
ca-ParametersNR | structure | CA-wide limits: maxNumberOfServingCells, cross-carrier scheduling, simultaneous Rx/Tx, dual PA, SCell without SSB | These are combination-wide ceilings that sit on top of the per-CC feature set values. |
mrdc-Parameters | structure | Only present in an MRDC band combination: single-uplink operation, dynamic power sharing, ul-SharingEUTRA-NR | Its 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 apply | An RF constraint layered on top of everything else; frequently overlooked. |
powerClass | pc1, pc2, pc3, ... (extension) | Per-combination power class | A 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.
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.
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:
| Identifier | ASN.1 range | Base | Value 0 means |
|---|---|---|---|
FeatureSetCombinationId | INTEGER (0 .. maxFeatureSetCombinations-1) | 0-based | the first entry of featureSetCombinations |
FeatureSetDownlinkId | INTEGER (0 .. maxDownlinkFeatureSets) | 1-based | not supported -- the UE has no downlink capability for this band in this combination |
FeatureSetUplinkId | INTEGER (0 .. maxUplinkFeatureSets) | 1-based | not supported -- no uplink on this band here |
FeatureSetDownlinkPerCC-Id | INTEGER (1 .. maxPerCC-FeatureSets) | 1-based | cannot occur -- 0 is outside the range, so there is no "absent" value |
FeatureSetUplinkPerCC-Id | INTEGER (1 .. maxPerCC-FeatureSets) | 1-based | cannot occur |
Table 7. Mixed indexing in one dereference chain. maxFeatureSetCombinations, maxDownlinkFeatureSets, maxUplinkFeatureSets and maxPerCC-FeatureSets are all 1024.
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.
| Structure | Max entries | Typical on a flagship | What one entry costs to reference |
|---|---|---|---|
supportedBandCombinationList | 65 536 | 1 000 - 3 000 | n/a -- this is the thing being enumerated |
featureSetCombinations | 1 024 | 100 - 600 | 10 bits (one FeatureSetCombinationId) |
featureSetsDownlink | 1 024 | 20 - 150 | 11 bits (one FeatureSetDownlinkId) |
featureSetsDownlinkPerCC | 1 024 | 10 - 60 | 10 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.
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:
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 featureSetsDownlinkPerCCCarriers 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.
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
| Capability | What it gates | Symptom if the network ignores it |
|---|---|---|
maxNumberMIMO-LayersPDSCH | DL rank in DCI, CSI codebook configuration, maxRank in PUSCH-Config | Flat 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 / UL | BWP width, locationAndBandwidth | RRCReconfigurationComplete never arrives, or arrives and the UE cannot receive outside its real bandwidth. |
supportedSubcarrierSpacingDL | Numerology of the serving cell configuration | Reconfiguration failure. Usually caught immediately. |
ca-ParametersNR.maxNumberOfServingCells | How many SCells may be added | SCell 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 time | Uplink loss on one band whenever the other is receiving. Looks like interference. |
rlc-Parameters.am-WithShortSN | sn-FieldLength in RLC-Config | Bearer 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-Config | PDCP header decompression failure; IP packets discarded silently. |
measAndMobParameters handover flavours (DAPS, CHO) | Whether daps-Config or conditionalReconfiguration may be sent | Handover failure at execution rather than at preparation. See 25 Conditional HO and DAPS. |
| 2-step RACH support | msgA-* configuration in RACH-ConfigCommon or dedicated | The 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 symbols | Missed PDCCH, appearing as scheduling gaps with no corresponding radio degradation. |
powerClass per band combination | Uplink power headroom assumptions and link budget | Uplink 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.
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.
| Filter | Where it sits | Effect on the response | Caveat |
|---|---|---|---|
frequencyBandList in UE-CapabilityRequestFilterNR | capabilityRequestFilter inside each UE-CapabilityRAT-Request | The UE omits every band, and every band combination containing a band, not named in the list | It 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 / UL | Per entry of frequencyBandList | Bounds combinations to those within the requested bandwidth and carrier count | Useful on a cell that will never aggregate more than two carriers. |
omitEN-DC in capabilityRequestFilterCommon | ue-CapabilityEnquiryExt | Every EN-DC band combination is left out | On 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 separately | A modest saving, but free. |
srs-SwitchingTimeRequest | UE-CapabilityRequestFilterNR | Asks the UE to include SRS antenna-switching timing, which it otherwise omits | This 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.
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
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.
| Item | Value | Note |
|---|---|---|
| Maximum PDCP SDU | 9000 octets | The hard threshold above which RRC segmentation is required. |
| Uplink RRC segmentation | Rel-16, ULDedicatedMessageSegment on UL-DCCH | Gated by a UE capability. A Rel-15 UE cannot segment an uplink RRC message at all, so filtering is its only option. |
| Downlink RRC segmentation | Rel-15 for RRCReconfiguration, DLDedicatedMessageSegment | The 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, lastSegment | Reassembly 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.
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.
| IE | Lives in | What it adds | Why it is separate |
|---|---|---|---|
rf-ParametersMRDC.supportedBandCombinationList | UE-MRDC-Capability | Band combinations that mix EUTRA and NR BandParameters | An 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 combinations | The 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 themselves | UE-NR-Capability only | The actual featureSetsDownlink / PerCC tables | There 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 BandCombination | singleUL-Transmission, dynamicPowerSharing, ul-SharingEUTRA-NR, ul-SwitchingTimeEUTRA-NR, tdm-Pattern | These describe how the two uplinks coexist, which has no NR-only equivalent. |
measAndMobParametersMRDC | UE-MRDC-Capability | Inter-RAT measurement and SFTD capability | Needed 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.
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.
UECapabilityEnquiry in a log means something unusual happened.| Mechanism | Release | Where the container lives | What it buys | What it costs |
|---|---|---|---|---|
NGAP UE RADIO CAPABILITY INFO INDICATION + the UE Radio Capability IE | Rel-15 | The AMF, for the lifetime of the UE's registration | No enquiry on subsequent connections within the same AMF and registration | Lost on AMF change and on deregistration. Also carries the filter it was fetched under, implicitly. |
UE Radio Capability for Paging | Rel-15 | The AMF, alongside the full container | Lets the AMF give the RAN just enough capability information to page efficiently, without the full container | A separate, smaller structure that must be kept consistent with the full one. See 19 Paging. |
RACS: UE Radio Capability ID + the UCMF | Rel-16 | The UCMF, a network function outside the RAN; the UE holds only the ID | The container survives AMF change, deregistration and even a change of serving network, and is fetched by ID | Requires 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.
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.
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:
| Class | How it appears | What absence means | Example |
|---|---|---|---|
| Mandatory without capability signalling | Not signalled at all | Nothing -- every UE of that release must support it, so there is nothing to report | Basic 4-step Random Access; CP-OFDM downlink |
| Mandatory with capability signalling | A field that is always present for a UE of that release | A protocol error, or a UE of an earlier release | accessStratumRelease, pdcp-Parameters, phy-Parameters |
| Optional with capability signalling | An OPTIONAL field, usually ENUMERATED {supported} | Not supported. This is the normal case and the reason the containers are so full of optional fields | daps-Config support, 2-step RACH, scellWithoutSSB |
| Conditionally mandatory | Mandatory if another capability is claimed | Depends on the condition; read the TS 38.306 note for the field | Several 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.
| Assumption | Is it safe? | Why |
|---|---|---|
"rel16 means the UE supports 2-step RACH" | No | 2-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" | Yes | A 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" | No | Nothing 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 yes | It 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" | No | You 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.
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.
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 / field | Value or range | Typical | Effect |
|---|---|---|---|
maxBandComb | 65 536 | 1 000 - 3 000 declared | Ceiling on supportedBandCombinationList. Nothing approaches it, but it is why the length field is wide. |
maxSimultaneousBands | 32 | 2 - 5 | Bands in one combination, and therefore entries in one FeatureSetCombination. |
maxFeatureSetsPerBand | 128 | 1 - 4 | Alternative feature sets offered for one band within one combination. |
maxFeatureSetCombinations | 1 024 | 100 - 600 | Ceiling on the middle layer of the indirection. |
maxDownlinkFeatureSets / maxUplinkFeatureSets | 1 024 | 20 - 150 | Ceiling on featureSetsDownlink / featureSetsUplink. |
maxPerCC-FeatureSets | 1 024 | 10 - 60 | Ceiling on the per-carrier value tables. |
maxBands | 1 024 | 1 - 45 | Ceiling on supportedBandListNR. |
maxNrofServingCells | 32 | 2 - 8 | Bounds featureSetListPerDownlinkCC, i.e. carriers per band. |
maxRAT-CapabilityContainers | 8 | 1 - 3 | RATs per enquiry and per response. |
accessStratumRelease | rel15 .. rel18 plus spares | rel16 or rel17 | Bounds which non-critical extensions may be present. Gates nothing on its own (§14). |
maxNumberMIMO-LayersPDSCH | twoLayers, fourLayers, eightLayers | fourLayers on FR1 | Per carrier. Multiply by carriers for the aggregate. |
supportedModulationOrderDL | bpsk-halfpi, bpsk, qpsk, qam16, qam64, qam256 | qam256 | Selects the MCS table the network may use. See 08 Scheduling. |
scalingFactor | f0p4, f0p75, f0p8 (absent = 1) | absent | The f term in the TS 38.306 peak-rate formula. Easy to miss and worth up to 60 %. |
intraBandFreqSeparationDL | FreqSeparationClass i, ii, iii | class i | How far apart intra-band non-contiguous carriers may be. An RF constraint expressed inside a feature set. |
| PDCP SDU limit | 9 000 octets | -- | The segmentation threshold (§11). |
segmentNumber | 0 .. 15 | 0 - 5 | At 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
| Failure | Detected by | What happens | Diagnostic pointer |
|---|---|---|---|
| Filter omits a band the network actually deploys | Nobody | The UE never reports the band; the gNB concludes it is unsupported and redirects or releases | Compare 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 filter | Nobody | Same effect as above, but only in some cells -- so it looks like a cell-specific fault | Key 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 RRC | The UE cannot send the response at all; the procedure times out | A 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 retransmitted | Nobody -- there is no reassembly timer | The gNB waits indefinitely for lastSegment; the capability is never available | Count 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 chain | Nobody | Wrong bandwidth, rank or modulation is configured; every grant using it fails | Re-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 ignored | Nobody | A capability valid on FDD is configured on a TDD carrier | Resolve fdd-Add- / tdd-Add- / fr1-Add- / fr2-Add- before using any top-level value. |
Feature gated on accessStratumRelease instead of its own field | Nobody | The feature is configured and silently not used, or used and fails | Affects a subset of one device model. Check the specific capability field, not the release (§14.1). |
| Stale cache after a firmware update | Nobody | The network configures against capabilities the device no longer declares | Fleet-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 activation | UE RRC -- the procedure is not permitted | The UE does not respond, or responds and the exchange is a privacy violation | Check the ordering against SecurityModeComplete. See 27 AS Security Mode. |
MRDC combination index resolved against the NR container's featureSetCombinations | Nobody | Completely wrong capability attributed to an EN-DC combination | The two containers have separate combination lists and share only the FeatureSets tables (§12). |
RRCReconfiguration rejected after a capability decode | gNB, on RRCReconfigurationFailure or a missing Complete | Reconfiguration failure and, depending on the gNB, re-establishment | The 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.
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
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
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
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 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
-- 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
-- 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
| Release | Change | Why it matters when reading a capability |
|---|---|---|
| Rel-15 | UECapabilityEnquiry / UECapabilityInformation; UE-NR-Capability; band combinations; the feature set indirection; UE-MRDC-Capability | The baseline. Everything in §3 to §9 is Rel-15 and unchanged. |
| Rel-15 | capabilityRequestFilter (frequencyBandList) and capabilityRequestFilterCommon (omitEN-DC) | Filtering existed from the start, which tells you the size problem was foreseen. |
| Rel-15 | NGAP UE Radio Capability caching at the AMF; UE Radio Capability for Paging | The reason many connections show no enquiry at all. |
| Rel-15 | Downlink RRC segmentation for RRCReconfiguration | The downlink direction was solved first; uplink had to wait. |
| Rel-16 | Uplink RRC segmentation -- ULDedicatedMessageSegment, gated by a UE capability | Before this, an unfiltered enquiry to a large device simply could not be answered. |
| Rel-16 | RACS -- UE Radio Capability ID, the UCMF, and manufacturer- or network-assigned IDs | Capability containers now live outside the RAN and outside the AMF, and survive mobility and roaming. |
| Rel-16 | rat-Type utra-fdd; NR-DC capabilities; RRC segmentation capability signalling | More RAT containers in one exchange. |
| Rel-17 | RedCap capability signalling; reduced band combination and feature set expectations for RedCap devices | A RedCap container is small enough that filtering is often unnecessary, which changes what "normal" looks like. |
| Rel-17 | 1024QAM downlink for FR1; extended ModulationOrder handling | The modulation order field now reaches beyond qam256 in extensions, not in the root enumeration. |
| Rel-17 | eDRX, paging subgrouping and PEI capabilities | Support for the mechanisms in 19 Paging is declared here. |
| Rel-18 | Further band combination growth; network energy saving capabilities; AI/ML-related capability reporting frameworks | The 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
| Term | Expansion | Meaning 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. |
| RACS | Radio Capability Signalling optimisation | Rel-16 mechanism replacing the container with a short UE Radio Capability ID resolved via the UCMF. |
| UCMF | UE radio Capability Management Function | The 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 PER | Packed Encoding Rules, unaligned variant | The 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 LTEUECapabilityEnquirythat 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, theUE Radio Capability,UE Radio Capability IDandUE Radio Capability for PagingIEs, andINITIAL 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
supportedModulationOrderDLselects 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-ParametersLCP 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
measAndMobParametersgates. - 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.