UE Capabilities

JM. Pugeat
20-11-2020

1 © 2018 Nokia
Contents

What purpose do the UE Capabilities serve?

Mandatory and optional capabilities
Acquisition and storage of UE Capabilities
Size issues and solutions
UE categories
Band combinations and feature sets
Fallback combinations
Differentiated support on FDD/TDD and FR1/FR2

2 © 2018 Nokia
What purpose do the UE Capabilities serve?

Their first purpose is to inform the RAN of the basic functionalities the UE supports:
• The bands the UE supports
• The maximum DL throughput the UE supports
• The maximum uplink power (UE power class)
• The 3GPP release the UE is based on (accessStratumRelease)
• etc.

Their second purpose is to inform the RAN of which optional features or capabilities the UE
supports. There are also mandatory features covered by capability bits, more on this later

Their third purpose is to provide a mechanism to ensure backwards compatibility on the RRC
interface. This last point is worth a little explanation

3 © 2018 Nokia
How are UE Capabilities involved in backwards compatibility?

Assume both the UE and network are based on Release 15, and the network wants to enable a feature that was
added as an extension to Release 15, for example in 15.5.0
If there is no capability bit for this feature, how can the network know that the UE has understood and will apply
the configuration? If the UE has not implemented the ASN.1 that comes with 15.5.0, it will not understand what
has been configured; it will only be able to skip it (ASN.1 extensions are encoded as length + value so that they
may be skipped over)
If there wasn’t a capability bit for each feature added in an extension of a 3GPP release, the UE would need a
proper way to reject a configuration, and the network would probably need a way to indicate if part of a
configuration can be ignored or if it must be rejected if the UE does not understand it. Something like this exists
on the network interfaces (X2, Xn, Ng, etc.): the Criticality attribute which is attached to each high-level
Information Element. However this significantly increases message size and is not too adapted to the air interface
where every bit counts
An alternative mechanism would be for the UE to indicate the exact version of a 3GPP release it supports in the
accessStratumRelease capability, so R15.5.0 instead of just R15. However a lot of features that are introduced as
extensions are optional for the UE to support and they would still require a capability bit. So in the end it is just
as simple to have the accessStratumRelease indicate R15 and have a capability bit for each new introduced
feature. But this means that capability bits are part of the backwards compatibility mechanisms
4 © 2018 Nokia
Takeaway information

UE Capabilities serve three purposes:

They inform the network of the basic functionalities supported by the UE
They inform the network of the optional functionalities supported by the UE
They participate in the backwards compatibility of the RRC interface

5 © 2018 Nokia
Mandatory and optional capabilities

There are UE capability bits for both mandatory and optional features. Whether a feature is
mandatory or optional for UEs to support is indicated by the column “M” in the tables of 38.306. Yes
means the feature is mandatory, No means it is Optional, “CY” means it is conditional mandatory, in
other words mandatory under certain conditions that are normally provided in the definitions column
Why do some features that are mandatory to support for the UE, require a capability bit?
This is in recognition of the fact it would take very long for a UE vendor to implement all of the
mandatory features and that this would delay the launch of a new technology or a new 3GPP release.
Having these capability bits allows UE vendors to have a stepped approach, and to indicate support of
the mandatory features gradually as they are implemented and tested. They are sometimes referred to
as IOT bits (or IODT, for Inter Operability Device Testing), as they will be set to 1 once sufficient
IOT testing has been performed with network vendors
The network doesn’t have this problem, since it usually controls which features are enabled or not on
the radio interface. In the rare cases where it is needed, a “network capability bit” may be added to the
System Information; this is the way of letting the UE know that a given feature is supported by the
network
6 © 2018 Nokia
Why not just make all features optional?

3GPP bodies want to keep the notion that some features are mandatory to support for UEs, while
others are optional. So once a reasonable amount of time has been left to UE vendors to implement
the mandatory functionalities, the capability bits must mandatorily be set to “supported” by UEs
starting with a given 3GPP release
Let’s take an example from LTE. In Release 8, mandatory features Long DRX cycle and DRX MAC
Control Element were tied to a capability bit, Feature Group Indicator bit 5:

In Release 9, support of these features became fully mandatory. This means a UE that is Release 9 or
higher must set this bit to 1 to indicate the features are supported

7 © 2018 Nokia
Should mandatory capabilities be managed differently?

We will likely be implementing functionalities and their associated capability checks before they become
officially mandatory in 3GPP (i.e. before the note that says “shall be set to 1” is introduced in TS38.306)
In theory, once a functionality becomes completely mandatory in a given 3GPP release, we could remove
the capability check for UEs of a release equal or higher to the one where the functionality becomes fully
mandatory
In practice, we don’t really want to do this:
- For one thing, it would require us to make a change to our software
- If there is a “rogue” UE that declares itself of the right 3GPP release but signals that it doesn’t
support the feature, we will get blamed, and we will need to deliver a “fix” for the problem
So for all purposes, from a gNB perspective, we should consider all of these mandatory capabilities as
optional and not bother with the distinction mandatory/optional
The only exceptions are functionalities that are mandatory in some conditions and optional in other ones:
for example mandatory for NSA and optional for SA, or the reverse. We will only check the bits for the
case where they are declared optional

8 © 2018 Nokia
Takeaway information

“Mandatory” capabilities exist to allow a step by step implementation by UEs. They are often referred
to as “IOT” or “IODT” bits, as they will be set to 1 by a UE vendor once sufficient inter-operability
testing has been performed with network vendors

From a gNB perspective, it is safest to consider all capabilities as optional and to check them before
making use of the corresponding functionality

The only exception is capabilities that are mandatory to support in one case but optional in the other
(i.e. NSA vs. SA or FDD vs. TDD)

9 © 2018 Nokia
Acquisition and storage of UE Capabilities

The RAN needs to know the UE’s capabilities for any call that is more than a simple signaling call, in
other words any call that involves setting up a data radio bearer (DRB). This is the majority of calls
(voice, email, web browsing, social media etc.)
In order to avoid any latency due to querying the UE for its capabilities, they are stored in the Core
Network (MME or AMF) and provided to the RAN (eNB or gNB) at every connection. UE
Capabilities are also now quite big, so this also avoids cluttering the radio interface
This works as follows:
The first time the UE connects to the network (4G Attach Request or 5G Registration Request), the
Core Network (MME or AMF) will not have its capabilities stored. It will therefore not include them
in the S1/Ng Initial Context Setup Request message, and the RAN (eNB or gNB) will then have to
query them from the UE with a UE Capability Enquiry procedure. Once the UE has sent its
capabilities, the RAN will forward them to the Core Network for storage
At the next connection, the Core Network will provide them to the RAN. In 5G the AMFs can also
forward UE Capabilities to each other as the UE moves from one area to another

10 © 2018 Nokia
Size issues

The total UE Capabilities must fit within a single RRC message, which is limited in size by the max
PDCP SDU size (8188 bytes in LTE, 9000 bytes in NR) (*)
In LTE, the size of the UE Capabilities was threatening to explode because of the Carrier Aggregation
band combinations (the UE was expected to report all of the band combinations it supported,
regardless of whether those bands were in use in the network), so a mechanism was introduced in
Release 11 allowing the eNB to indicate which bands it wanted the UE to indicate the supported band
combinations for. In Release 13 this mechanism was enhanced to allow the eNB to indicate the max
number of uplink and downlink component carriers it wanted the UE to indicate the supported band
combinations for (this avoided the UE reporting larger band combinations that were not supported by
the network)
These mechanisms have been re-used and improved upon for NR, and a few more have been added
(*) Release 16 has introduced RRC segmentation of UE Capabilities to allow bigger sizes. There is
also a mechanism to avoid storing multiple times the same capabilities

11 © 2018 Nokia
Takeaway information

UE Capabilities are requested by the RAN node at the first Attach / Registration procedure, and stored
afterwards in the Core Network (MME or AMF). From then on the Core Network provides them to
the RAN node at every new connection

UE Capabilities can grow to large sizes and consume a lot of memory in both RAN and Core
Network nodes, so there are several mechanisms to keep their size small

Release 16 has introduced mechanisms to allow segmentation of very large UE capabilities, and to
avoid storing multiple times the same capabilities (for UEs of the same make from the same vendor).
These mechanisms are part of an ongoing FSY

12 © 2018 Nokia
Current solutions to the size issues

A set of mechanisms were put in place in NR to reduce the total size of UE capabilities:
- The requested frequency band list, used to filter the reported band combinations supported by
the UE, so that only those that are meaningful to the network get reported. As part of this filter, the
network may also indicate the max bandwidth and the max number of carriers, UL and DL, it is
interested in
- The feature sets, which avoid repeating capabilities which are common to many band
combinations
- The fallback band combinations, which avoid signaling band combinations whose support can
be deduced from other band combinations which include them
- The UE capabilities were split in to two separate capabilities, the standalone capabilities and the
dual connectivity capabilities. This avoids reporting the dual connectivity capabilities if the
network is standalone only; and if the network supports dual connectivity, if needed the
capabilities could be queried in two steps to avoid exceeding the maximum PDCP size

13 © 2018 Nokia
Requested frequency bands

In LTE the eNB had to first request the full UE capabilities, and if the UE supported the requested
frequency bands mechanisms it could then issue a new query with the list of bands that were
meaningful to it. The UE would only partially filter the list of band combinations (for example, all 2-
band band combinations were reported, regardless of the requested frequency band list)
In NR, use of the requested frequency bands by the gNB is mandatory. The UE uses this list to fully
filter the list of band combinations it supports, and then includes it in the UE capabilities it reports. A
gNB will then know from this list of requested frequency bands how the band combinations have
been filtered, and may then request new UE capabilities with a different list if some of the frequencies
it manages were left out of the band combinations by the UE (the bands supported by the UE are
reported without filtering)
The list of requested frequency bands may also include for some or each band the maximum
bandwidth and the maximum number of carriers, both uplink and downlink, that the UE needs to
report

14 © 2018 Nokia
Band combinations and feature sets

Another mechanism used to keep the size of UE capabilities in check is the feature set. The idea is
that many capabilities are hardware dependent (“baseband” capabilities) and will be common at least
in part to many band combinations. By taking these out of the parameters of a band in a band
combination and listing them separately (with pointer from one list to the other), the maximum
theoretical size of the UE capabilities was brought down from 32 exabytes (10 18) to a little over 100
Mbytes
For EN-DC the list of features sets that the UE reports must be the same in the LTE capabilities and in
the NR MR-DC capabilities. If the MeNB queries the LTE, NR, and NR MR-DC capabilities in
several steps (for example to avoid message size issues), it must use the same frequency band filter
for each query in order to ensure that the feature set IDs referenced in band combinations are the same
across the different UE capabilities

15 © 2018 Nokia
Fallback combinations
See TS38.306
A fallback band combination is a band combination that results from another one by releasing at least
one SCell or the UL of one SCell. If the UE supports a band combination with n1, n5, n40 and n79, it
does not need to signal a band combination with n1, n5 and n40
A fallback per band feature set is a feature set per band with the same or lower values than a reported
feature set per band for a given band
A fallback per component carrier feature set is a feature set per component carrier with a lower
number of MIMO layers and bandwidth but with the same numerology and other parameters as a
reported feature set per CC

Note: Qualcomm is signaling fallback combinations in order to indicate some restrictions, so there
may not be so much gain on the UE capabilities size in this case

16 © 2018 Nokia
Structure of the UE Capabilities

NR capabilities are split into two parts:

- The “Standalone and Common” NR capabilities (UE-NR-Capability): part of these are specific to
the Standalone mode (the supported band combinations for Carrier Aggregation, the feature set
combinations for the CA band combinations, the supported LTE carriers) while others are
common to SA and NSA (the PDCP, MAC, RLC, and Mobility parameters, but also the feature
sets)
- The Dual Connectivity NR capabilities (UE-MRDC-Capability), which contain only capabilities
related to EN-DC or MR-DC: a few miscellaneous parameters, but mostly the supported band
combinations for Dual Connectivity and the feature set combinations for the DC band
combinations (the feature set combinations point to the list of feature sets provided in the UE-NR-
Capability)

17 © 2018 Nokia
Takeaway information

There are 4 mechanisms to keep the size of UE Capabilities within reason:

The UE reports only band combinations that the network is interested in

The UE does not report “fallback” capabilities (the network can deduce that the UE supports
configurations using less capabilities than an explicitly signaled supported configuration)

Feature sets allow to regroup functionalities that are shared among multiple band combinations and
therefore to avoid repeating them

NSA and SA capabilities are split into two separate structures in order to have something smaller to
deal with

18 © 2018 Nokia
Standalone and MR-DC Capabilities
UE-NR-Capability
PDCP
UE-MRDC-Capability
RLC
Mobility
MAC
PHY
PHY
RF
RF ∟ Supported band combinations for DC
∟ Supported bands ∟ Applied filter
∟ Supported band combinations for CA
∟ Applied filter
Split bearer parameters
Mobility
FDD/TDD & FR1/FR2 additional features
FDD/TDD & FR1/FR2 additional features
Feature set combinations for DC
Feature sets (for CA and DC)
PDCP
Feature set combinations for CA
Inter-RAT parameters

19 © 2018 Nokia
What are the characteristics of a band combination?

With NR, a band combination consists of:

• A list of bands: a list of NR-only (CA and NR-DC) or LTE and NR bands (EN-DC, NGEN-DC
and NE-DC). The list may have only one element in the case of intra-band contiguous CA
To each band in the list is associated a bandwidth class, which indicates how many component
carriers (CC) and the maximum aggregated bandwidth the UE supports for the given band
• A feature set combination: a table with as many rows as there are bands in the list of bands, and
where the columns contain the feature set per band. A feature set per band is a pair of either LTE
or NR UL and DL feature sets. A feature set contains the parameters that are global to the band in
the band combination, and at least one per-CC feature set (several if the UE supports intra-band
contiguous CA on the band). The per-CC feature set contains the supported numerology,
bandwidth, modulation order and number of MIMO layers
• A bandwidth combination set: one or several sets of bandwidths supported for each band, for
that given band combination
See next slide for an illustration

20 © 2018 Nokia
 Legend
Band combinations and feature sets BC# Band Combination Id
Bx Band Number
Bwc Bandwidth class
Band combinations (list)
FSC# Feature Set Combination Id
BC# Bx, Bwc Bx, Bwc Bx, Bwc FSC#, BCS BCS Bandwidth Combination Set

BC# Bx, Bwc Bx, Bwc Bx, Bwc Bx, Bwc FSC#, BCS The FSC# points to one feature set combination

1st band Same number of “rows”

BC# Bx, Bwc Bx, Bwc Bx, Bwc FSC#, BCS as there are bands in the
2nd band
band combination that
BC# Bx, Bwc Bx, Bwc FSC#, BCS 3rd band points to this FSC

One combination of per-band feature sets that is

applicable to the band combination

1st band

2nd band The “cells” of the feature set combination “matrix”

contain the feature sets per band (FSPB)

21 © 2018 Nokia
Band combinations and feature sets
FSPB

A feature set per band is a pair of either LTE or NR: OR

- DL feature set Id
- UL feature set Id DL LTE feature set Id DL NR feature set Id

(the “Id” is the position of the feature set in the list of DL UL LTE feature set Id
LTE feature sets are specified in TS36.331
UL NR feature set Id

or UL feature sets. Value 0 is used to signal that the

carrier is not supported, typically for Supplementary UL
or DL)
Feature Set (UL or DL)
UL and DL feature sets have the same structure:
- Some global parameters, for example the scalingFactor . scalingFactor

to be used for the max data rate calculation, or the . intraBandFreqSeparation

intraBandFreqSeparation . crossCarrierScheduling-otherSCS
- A list of per-CC (Component Carrier) feature sets (the
. Etc.
list has more than one feature set if the UE supports
Per-CC feature set
intra-band contiguous carrier aggregation for this band, List of per-CC feature sets
Per-CC feature set
otherwise it has only one) indicating the supported . supportedSubcarrierSpacing
Per-CC feature set
. supportedSubcarrierSpacing
numerology, bandwidth, modulation order and number . supportedBandwidth
. supportedSubcarrierSpacing
of MIMO layers for the CC . supportedBandwidth
. maxNumberMIMO-Layers
. supportedBandwidth
. maxNumberMIMO-Layers
. supportedModulationOrder
. maxNumberMIMO-Layers
. supportedModulationOrder
. supportedModulationOrder
22 © 2018 Nokia
Bandwidth combination sets
A mechanism for phased deployment of bandwidth combinations
Bandwidth combination sets were introduced in LTE to manage two needs:
- Some operators wanted to deploy carrier aggregation very early, even if it meant having a smaller
aggregated bandwidth due to UE chipset limitations. For example, the B3/B5 band combination
was planned to support 30 MHz aggregated bandwidth, but UE chipsets were limited to 20 MHz.
As a result, two bandwidth combination sets (BCS) were created: BCS “0” for bandwidth
combination sets with a 30 MHz total aggregated bandwidth, and BCS “1” for bandwidth
combination sets with a 20 MHz total aggregated bandwidth
- To be able to extend existing band combinations to new total aggregated bandwidths (B1/B5
initially defined for 20MHz aggregated bandwidth, was extended with BCS “1”to include a 30
MHz total aggregated bandwidth) or to add a new possible bandwidth for one of the bands (B3/B7
was extended with BCS “1” to allow 5MHz on band B7)
A bandwidth combination set indicates for each band the bandwidth(s) that may be combined with the
other bands of the band combination

23 © 2018 Nokia
Example of bandwidth combination sets

Initially, most band combinations had a single bandwidth combination set. Now there are a few band
combinations that have two. Here is one example from EN-DC
The two bandwidth combination
sets only differ by the NR 50MHz
bandwidth that is supported in
BCS 1
For BCS 0, when the LTE carrier is
lower than the NR carrier, the
supported bandwidths are 20+40,
20+60, 20+80 and 20+100 MHz
BCS1 supports one more
combination of bandwidths,
20+50 MHz

24 © 2018 Nokia
UE category / maximum throughput and buffer size

In LTE the UE capabilities contained a parameter called UE category, which among other things
defined what was the maximum throughput the UE supported, and the size of its L2 buffers
In NR this concept is replaced by a calculation that must be done for each supported band
combination and associated feature set, the details of which are specified in TS38.306 section 4.1:

(scaling factor, numerology, number of MIMO layers, modulation order and bandwidth are all inputs
for this calculation)

25 © 2018 Nokia
Differentiated support on FDD/TDD and FR1/FR2

3GPP allows the UE to support a feature only in one mode (FDD or TDD) or in one frequency range
(FR1 or FR2). There may even be a different indication for when the UE is configured with a mixed
FR1 + FR2 band combination. Such a feature will then have multiple capability bits, all bearing the
same name. What will differentiate them is the information element they are contained in
Take for example the dynamicSFI capability:
• UE-NR-Capability.phy-Parameters.phy-ParametersXDD-Diff.dynamicSFI = supported => supported on FDD and TDD
• UE-NR-Capability.phy-Parameters.phy-ParametersFRX-Diff.dynamicSFI = supported => supported on FR1 and FR2
• UE-NR-Capability.fdd-Add-UE-NR-Capabilities.phy-ParametersXDD-Diff.dynamicSFI = supported => supported on FDD
• UE-NR-Capability.tdd-Add-UE-NR-Capabilities.phy-ParametersXDD-Diff.dynamicSFI = supported => supported on TDD
• UE-NR-Capability.fr1-Add-UE-NR-Capabilities.phy-ParametersFRX-Diff.dynamicSFI = supported => supported on FR1
• UE-NR-Capability.fr2-Add-UE-NR-Capabilities.phy-ParametersFRX-Diff.dynamicSFI = supported => supported on FR2
• (there is one more place where this dynamicSFI capability can be found, but this is discussed later)
When you look at the full path name of a parameter, it is the most limiting part of it that indicates what it applies to. ‘fr1’ is more limiting than ‘FRX’,
‘fdd’ is more limiting than ‘FRX’, etc.

26 © 2018 Nokia
How to check for support of a capability with differentiated support?
See section 4.2.1 Introduction of 38.306
Capabilities that are supported in common for FDD and TDD (resp. FR1 and FR2) are signaled in the
“common” structure, the one that has neither FDD nor TDD in its name (resp. FR1 and FR2)
The UE will only include the FDD or TDD specific structure (resp. FR1 or FR2) if there is a
capability that it supports only for one or the other of the modes (resp. the frequency ranges)
So the logic is as follows:
If the capability is indicated as supported in the common part, it is supported for both FDD and TDD
(resp. FR1 and FR2)
Else
If the FDD (resp. FR1) specific structure is present and the capability is indicated as supported within, it is
supported for FDD (resp. FR1)
If the TDD (resp. FR2) specific structure is present and the capability is indicated as supported within, it is
supported for TDD (resp. FR2)

27 © 2018 Nokia
The special case of “fr1-fr2-Add”
When both poor naming and “code reuse” leads to misunderstandings
The dynamicSFI capability can also be found in the following structure: UE-NR-
Capability.nonCriticalExtension.nonCriticalExtension.fr1-fr2-Add-UE-NR-Capabilities.phy-ParametersFRX-Diff.dynamicSFI
Contrarily to what its name suggests, the fr1-fr2-Add-UE-NR-Capabilities structure does not contain additional
capabilities supported for FR1+FR2 band combinations: it contains restrictions to capabilities which are supported
on both FR1 and FR2, but which are not supported when FR1+FR2 carrier aggregation is configured. A better name
in this case would have been fr1-fr2-Restrict-UE-NR-Capabilities as it would have avoided confusion with the real
“-Add-” capabilities
Another trap here is that instead of defining a separate type to contain only the capabilities that can be restricted for
FR1+FR2, RAN2 re-used the UE-NR-CapabilityAddFRX-Mode type which contains many capabilities, among
which the dynamicSFI capability. So can this capability be restricted for FR1+FR2 combinations? The answer is
no, only csi-RS-IM-ReceptionForFeedback, csi-RS-ProcFrameworkForSRS and csiReportFramework can be
restricted, as indicated by the following note:

28 © 2018 Nokia
The “ENUMERATED {supported} OPTIONAL” explanation

Many of the UE capabilities are defined using this special syntax

The “OPTIONAL” indication consumes one bit, a presence bit that is added at the beginning of the
structure containing the definition. The presence bit is set to 1 if the IE is present and to 0 otherwise
The “ENUMERATED {supported}” part consumes 0 bits. The reason is that 3GPP uses Packed
Encoding Rules (PER) for ASN.1 encoding, and for PER the minimum number of bits required to
encode an information is used. The enumerate has only one value possible and therefore it is not
necessary to encode this value, it is already known
All in all, an “ENUMERATED {supported} OPTIONAL” definition therefore consumes a single bit, and
if the IE is present it means that the capability is supported
Why use this form instead of an “ENUMERATED {notSupported, supported}” syntax with a mandatory
IE? It would also consume a single bit, for which value 1 would mean the capability is supported,
similarly to the other syntax
The explanation is that since the capability bits are all about indicating if the UE supports a given
capability, the UE should only include the indication if it supports the capability. The network therefore
only needs to check for presence of the capability bits
29 © 2018 Nokia