5G NR: UE capability Information - FeatureSets and FeatureSetCombinations

1.            Introduction

At the time of registration for instance and before the UE would be able to perform data transfer or make/receive voice calls, the network needs to understand UE’s capabilities so that it can configure the UE accordingly.

The network requests for UE capabilities typically during registration procedure and stores it locally. This means that the UE doesn’t need to send UE capabilities every time RRC connection is established or re-established. However, the network can request the UE to send its capabilities at any time during RRC connected state.

Additionally, if the UE changes its radio capabilities, it will initiate a Tracking Area Updating procedure and include the IE UE radio capability information update needed in the TAU REQUEST message. The network would then request for new UE capabilities from the UE.

UE capability Information message size concerns

When LTE was introduced, the size of the UE capability Information message used to be fairly manageable. With the introduction of CA and LTE-Advanced features, the size of this message has grown to enormously, which is mainly due to multiple CA bands and UE capabilities defined per band and per band combination.

With the introduction of 5G NR and with NSA, the LTE UE capability message size would grow further as the UEs have to indicate EN-DC capabilities too.

Several optimisations have been introduced in 3GPP LTE standards to reduce the size of UE capability message (a couple of those are given below).

-      Within the UE capability enquiry message, the network may include the IE requestedFrequencyBands to request the supported CA band combinations and non-CA bands specifically for a set of bands.

-      Within the UE capability enquiry message, the network may include the maximum number of componentcarriers for which it needs to know the supported CA band combinations and non-CA bands. The IE requestedMaxCCsDL is corresponds to downlink and requestedMaxCCsUL corresponds to uplink.

-      For UEs supporting (NG)EN-DC or NE-DC, the network may provide a list of NR and/or E-UTRA frequency bands for which the UE is requested to provide its supported NR CA and/or MR-DC band combinations. The IE requestedFreqBandsNR-MRDC is used for this purpose.

These kinds of optimizations are also proposed and implemented in NR. For instance, the network mandatorily includes frequency band list for which it needs capabilities from the UE. Here, the network needs a filtered UE capability in which the UE is requested to provide supported bands and band combinations. This procedure is optional in LTE.

Another important optimization introduced in NR and LTE Release-15 is the concept of Feature Sets. Feature sets concept is thoroughly discussed in the following section.

2                       Concept of Feature Sets and Feature Set Combinations

For UEs supporting (NG) EN-DC or NE-DC, the size of UE capability information would be enormous if the UE has to report capabilities separately per each reported band in the corresponding band combination.

5G NR and LTE (from Release 15) onwards introduced so-called Feature Sets to overcome this problem.

-      A Feature Set stores a set of UE capabilities and features.

-      An ID is given to each Feature Set.

-      Using Feature Set ID, a Feature Set can be linked/associated with one or more bands within the corresponding band combination.

-      Using Feature Set ID, a Feature Set can be linked/associated within more than one band combinations.

-      The Feature Sets mechanism makes sure that each Feature Set is reported only once to avoid duplication.

-      A Feature Set contains a pair of feature sets for UL and DL separately.

-      A Feature Set can either be NR feature set or E-UTRA feature set.

Since a set of capabilities/features using Feature Set are reported only once, and any Feature Set can be re-used with any band(s) in each band combination and also with multiple band combinations, the size of the UE capability Information message is drastically reduced.

Feature Set Combination is a two-dimensional matrix containing Feature Set entries. A Feature Set Combination refers to the IDs of the feature set(s) that the UE supports in that Feature Set Combination.

Finally, each Band Combination entry in the Band Combination List is linked/associated with a Feature Set Combination. This is done by indicating the ID of the Feature Set Combination that the UE supports for that band combination.

This is discussed in detail below with an example illustrations.

Step-1: Define Feature Sets

-      The IE FeatureSets is used to provide pools of downlink and uplink features sets. The IE structure is given below.

FeatureSets
featureSetsDownlink	A list of FeatureSetDownlink for up to 1024 DL FeatureSets
featureSetsDownlinkPerCC	A list of up to 1024 CC-specific DL FeatureSets
featureSetsUplink	A list of FeatureSetDownlink(s) for up to 1024 UL FeatureSets
featureSetsUplinkPerCC	A list of up to 1024 CC-specific UL FeatureSets
. . .

-      The IE FeatureSetDownlink or FeatureSetUplink indicates a set of features that the UE supports on the carriers corresponding to one band entry in a band combination. This IE also contains a respective sub-IE structure (featureSetListPerDownlinkCC or featureSetListPerUplinkCC) indicating which features the UE supports on the individual DL/UL carriers of the feature set.

 

Step-2: Define Feature Set Combination (s)

This is an important step in which the Feature Sets created in Step-1 would be used to create a Feature Set Combination. 

The IE FeatureSetCombination is a two-dimensional matrix of FeatureSet entries.

A Feature Set Combination is defined such that each entry could be mapped to a band within the corresponding Band Combination. 

-      Each entry is referred to as FeatureSetsPerBand  which contains a list of feature sets applicable to the carrier(s) of one band entry of the associated Band Combination.

-      The number of FeatureSetsPerBands in a Feature Set Combination must have an equal number of band entries in an associated Band Combination. The first FeatureSetPerBand applies to the first band entry of the band combination, and so on.

-      In case of NR, the actual feature sets for UL and DL are defined in the FeatureSets IE (discussed in Step-1) and referred to by their ID, i.e., their position in the featureSetsUplink/featureSetsDownlink  list in the FeatureSet IE.

-      In case of E-UTRA, the feature sets referred to from this list are defined in TS 36.331 and conveyed as part of the UE-EUTRA-Capability container.

FeatureSetCombination IE is structure is shown below.

The following example shows the mapping between a Band Combination and Feature Set Combination.

Step-3: Assigning and ID to a Feature Set Combination

The IE FeatureSetCombinationId identifies a FeatureSetCombination. 

The FeatureSetCombinationId of a FeatureSetCombination is the position of the FeatureSetCombination in the featureSetCombinations list (in UE-NR-Capability or UE-MRDC-Capability). 

-      The FeatureSetCombinationId = 0 refers to the first entry in the featureSetCombinations list (in UE-NR-Capability or UE-MRDC-Capability).

The BandCombination entries in the BandCombinationList then indicate the ID of the FeatureSetCombination that the UE supports for that band combination.

 

Step-4: Linking a Feature Set Combination to a Band Combination

The Band Combination entries in the Band Combination List indicate the ID of the Feature Set Combinationthat the UE supports for that band combination. As shown in the below BandCombination IE structure, FeatureSetCombinationId  is assigned to featureSetCombination IE.

BandCombination
bandList	List of BandParameters for all bands in this band combination
featureSetCombination	FeatureSetCombinationId
ca-ParametersEUTRA	CA-ParametersEUTRA
ca-ParametersNR	CA-ParametersNR
mrdc-Parameters	MRDC-Parameters
. . .

Linking of a Feature Set Combination to a Band Combination is illustrated in the below example.

3                       UE Radio Capability Size estimation 

For LTE, the primary overhead introduced by Rel-15 parameters is FeatureSetsEUTRA-r15. The theoretical overhead of FeatureSetsEUTRA-r15 can exceed 10 kbytes.

In practical deployment, the size of featureSetsEUTRA-r15 is variable depending on the number of DL/UL feature sets per band and the number of DL/UL feature sets per CC, in some cases the size offeatureSetsEUTRA-r15 can be several kbytes, and the total size of UE-EUTRA-Capability can be ~4 kbytes with realistic assumptions.

For NR and EN-DC, based on the newly introduced structure for UE capability in Rel-15, the size of the UE capability is dominated by rf-Parameters, featureSetCombinations and featureSets. The estimated theoretical maximum size of UE radio capabilities for NR or EN-DC (based on the maximum sizes in ASN.1) can approximate to 10000 kbytes, 

In practical deployment, the supported bands/band combinations for a device is limited, and the eNB/gNB can for example request the UE to provide UE radio capabilities for a restricted set of band combinations. According to LTE experience and analysis of the NR capability, the estimated practical size of rf-Parametersis about 11~12 kbytes based on ~1024 band combinations and up to 4 bands per band combination.

The size of featureSetCombinations is highly variable depending on the number of feature set combinations and the number of feature sets per band, the size of featureSets is variable depending on the number of DL/UL feature sets per band and the number of DL/UL feature sets per CC. However, in some cases either the size of featureSetCombinations or featureSets can significantly exceed the size limitation of PDCP PDU. For example, with 256 feature set combinations, 8 feature sets per band, and 4 bands per band combination, the feature set combination list occupies ~22 kbytes.

Reference: 3GPP TS 38.331, 36.331, and 37.873

LTE: Carrier Aggregation - SCell Activation and Deactivation Timings

Use the below calculator for understanding the timing of several actions upon SCell Activation or Deactivation

SCell Activation/Deactivation Details

Activation or Deactivation Activation Deactivation by MAC CE sCellDeactivationTimerExpiry         SFN         subframe 0 1 2 3 4 5 6 7 8 9   

    

If the UE receives an Activation/Deactivation MAC CE in subframe #n activating the SCell, the UE shall apply the below defined actions no earlier than subframe #n+8 and no later than subframe #n+24 or subframe #n+34 (as defined in section 7.7.2 of 36.133)

    ― Transmit SRS on the SCell in case if UL CA and SRS on the SCell is configured;

    ― PDCCH monitoring on the SCell;

    ― PDCCH monitoring for the SCell (Cross Carrier Scheduling);

    ― Start or restart the sCellDeactivationTimer associated with the SCell;

    ― Trigger PHR

    ― CSI reporting for the SCell: The UE should start transmitting valid CSI report no later than subframe #n+24 or #n+34 (as defined in section 7.7.2 of 36.133) but it can report out of range (CQI index = 0) values from subframe #n+8, otherwise the eNodeB has to do blind decoding of PUSCH (if scheduled) from subframe #n+8 till subframe #n+24 or #n+34

If the UE receives an Activation/Deactivation MAC CE in subframe #n deactivating the SCell or if the sCellDeactivationTimer associated with the activated SCell expires in subframe #n, the UE shall deactivate the SCell no later than subframe #n+8.

If the SCell is deactivated, the UE shall apply the following actions:

    ― SRS shall not be transmitted in case if UL CA and SRS on the SCell is configured

    ― The UE shall not transmit UL-SCH on the SCell (UL CA)

    ― PDCCH on/for the SCell shall not be monitored.

    ― The UE shall flush all HARQ buffers associated with the SCell.

    ― The UE shall not transmit RACH on the SCell

    ― Stop the sCellDeactivationTimer associated with the SCell (if running);

    ― The UE shall stop reporting CSI from subframe #n+8 if the sCellDeactivationTimer associated with the SCell expires in subframe #n or if the UE receives an Activation/Deactivation MAC CE in subframe #n deactivating the SCell

Reference: 3GPP TS 36.321, 36.213, 36.331, 36.133, and 36.300

LTE: Carrier Aggregation based ICIC

In a Heterogeneous network (HetNet), terminals in Cell Range Extension (CRE), zone would experience severe interference from the aggressor cells. Aggressor cell could be a macro cell in case of macro-pico or a femto cell in case of macro-femto scenario. A number of features added to the 3GPP LTE specifications to mitigate the above mentioned interference problem in HetNets with small cells. Inter-cell interference coordination (ICIC) has the task to manage radio resources such that inter-cell interference is kept under control.

ICIC is discussed in detail in the earlier post. It is introduced in 3GPP Release-8 specifications to mitigate interference on traffic channels only. Moreover, only frequency domain ICIC was prioritized which manages PRBs, such that multiple cells coordinate use of frequency domain resources. The major problem here is the interference introduced by downlink control channels.

The enhanced ICIC (eICIC) is introduced in 3GPP LTE Release-10 to deal with interference issues in HetNets, and mitigate interference on traffic and control channels. The major change in eICIC is the addition of time domain ICIC. Time domain ICIC is realized through the use of Almost Blank Subframes (ABS). For the detailed discussion, check the post eICIC.

Another approach is based on carrier aggregation (CA) with cross-carrier scheduling which is mainly frequency domain ICIC. The main difference as compared to frequency domain ICIC introduced in Release-8 is that the CA based ICIC would work with control channels (PCFICH, PHICH, and PDCCH) as well.

Carrier Aggregation based ICIC

Carrier aggregation (CA) is one of the most important LTE-Advanced features introduced in Release-10. With CA, two or more component carriers (CCs) are aggregated in order to support wider transmission bandwidths up to 100MHz. A UE may simultaneously receive or transmit on one or multiple CCs depending on its capabilities.

When CA is configured, the UE only has one RRC connection with the network. The serving cell managing the UE’s RRC connection is referred to as the Primary Cell (PCell). Depending on UE capabilities, Secondary Cells (SCells) can be configured to form together with the PCell a set of serving cells.

In CA, a UE may be scheduled via PDCCH over multiple serving cells simultaneously. Cross-carrier scheduling with the Carrier Indicator Field (CIF) allows the PDCCH of a serving cell to schedule resources on another serving cell. In other words, a UE receiving a downlink assignment on one CC may receive associated data on another CC.

Cross-carrier scheduling is an important feature in HetNets where inter-cell interference is significant when the cells within HetNet are deployed on the same carrier frequency. It is discussed in detail in the post cross-carrier scheduling.

A number of HetNet deployment scenarios are presented by means of CA based ICIC. A promising approach is explained below by using a macro-pico example. The basic idea is to split the available spectrum into two downlink CCs denoted as CC1 (f1) and CC2 (f2), both CCs are available in both Macro and Pico layers. Macro layer configures PCell on f1 and SCell on f2 whereas, pico cell configures PCell on f2 and SCell on f1.

As shown in the figure above, three regions are of interest for control signalling (PCFICH, PDCCH, and PHICH); macro cell-center region, pico cell’s CRE region, and pico cell-center region. In the macro cell-center region, both f1 and f2 can carry control signalling. In the CRE region, macro-cell wouldn’t transmit control signalling on f2 i.e., scheduling assignments for SCell are carried by PCell on f1. So, interference caused by control signalling is minimized on f2 in CRE region.

Now, let us look at how pico cell is transmitting. Similar to macro cell, in the pico cell-center region, control signalling is transmitted on both f1 and f2. In the pico cell’s CRE region, pico cell would be transmitting control signalling only on f2 (PCell) and no transmission of control signalling on f1. i.e., scheduling assignments for SCell are carried by PCell on f2. This minimizes the interference in CRE zone which is caused by control signalling from pico cell on f1.

The downside with cross-carrier scheduling is that it will increase the load in the control region of the cell that is scheduling for another cell. This is due to the fact that the scheduling cell has to accommodate resource allocation for PDCCH for both PCell and SCell. In Release-11, a new channel known as Enhanced Physical Downlink Control Channel (EPDCCH) is introduced. This increases the control channel capacity as EDPCCH uses the same resources as PDSCH instead of control region. The EPDCCH could be used for resource allocation within each SCell without using cross-carrier scheduling. Moreover, by applying frequency domain ICIC, the reliability of receiving EPDCCH could be increased as in the case of PDSCH.

So far, the discussion was about control channels only. For data channel (PDSCH) both carriers (f1 and f2) are available in all three regions discussed above. The interference between macro and pico layers is handled by conventional ICIC method which is based on X2 signaling of RNTP between macro and pico eNBs as discussed in the post ICIC.

LTE: Multiple Timing Advances for uplink Carrier Aggregation

The Timing Advance related concepts are discussed very much in detail in the post Timing Advance and Time Alignment Timer.

For a UE configured with multiple serving cells in Release-10, the same uplink transmission timing is applied in all serving cells, based on the timing advance on the PCell. This means that base station transceivers of different CCs should be at the same physical location (collocated) to avoid different propagation delays.

In a heterogeneous network (HetNet) for example (as shown below), PCell and a remote radio head (RRH) which are located at different locations (non-collocated) may experience different propagation delays. So, the use of single TA is not practical.

From Release-11 onwards, it is possible to handle CA with CCs requiring different timing advances, for example combining CC from eNodeB with CC from RRH (as shown above) to support non-collocated cells.

Also, support of different uplink transmission timings on different serving cells address the deployment scenario where the propagation delays are different on different serving cells due to e.g. frequency selective repeaters.

It is not practical to maintain TA for each serving cell; instead, it would make sense to group a set of collocated serving cells, so that, the same TA is maintained across all the serving cells belonging to that group. Also, it is very important to have a timing reference cell for the entire group.

In Release-11, Timing Advance Group (TAG) was introduced. A TAG consists of one or more serving cells with the same uplink TA and same downlink timing reference cell. Each TAG contains at least one serving cell with configured uplink, and the mapping of each serving cell to a TAG is configured by RRC.

The TAG containing PCell is called as pTAG (Primary Timing Advance Group). For the pTAG, the UE uses PCell as timing reference.

If a TAG contains only SCells(s), and no PCell, then it is called as sTAG (Secondary Timing Advance Group). In a sTAG, the UE may use any of the activated SCells of this TAG as a timing reference cell, but should not change it unless necessary.

The UE has a configurable timer called timeAlignmentTimer per TAG. This TAG specific timeAlignmentTimer is provided by RRC at the time of sTAG configuration.

E-UTRAN adds or releases sTAG with the help of stag-ToAddModList-r11 and stag-ToReleaseList-r11 respectively and are part of mac-MainConfig in Release-11. 

Configuration of an sTAG includes stag-Id which indicates the TAG of an SCell and a TAG specific timeAlignmentTimer (timeAlignmentTimerSTAG-r11) as shown below.

At the time of SCell addition, the E-UTRAN may optionally indicate the STAG identity for the corresponding SCell.  MAC-MainConfigSCell-r11 is introduced for this purpose and as shown below it only contains STAG-id.

If the field stag-Id is not configured for an SCell (e.g. absent in MACMainConfigSCell), then the SCell is considered to be part of the pTAG.

The number of TAGs that can be configured depends on the TAG capability of the UE.

The UE indicates its support of multiple timing advances using multipleTimingAdvance-r11 under BandCombinationParameters during UE capability transfer procedure.

Initial Uplink Timing Alignment for a sTAG

The initial timing alignment on PCell (or pTAG) can be obtained via UE or eNodeB initiated Random Access (RA) procedure. But the initial UL timing alignment of sTAG is obtained only by an eNodeB initiated RA procedure.

As shown below, the SCell in a sTAG can be configured with RACH resources at the time of SCell addition. These parameters are part of UL configuration under RadioResourceConfigCommonSCell-r10.

In order to establish timing advance for a sTAG, the eNodB may initiate a non-contention based random access (RA) procedure with a PDCCH order that is sent on a scheduling cell of an activated SCell of the sTAG. i.e., the PDCCH order can be received on the same SCell (non-cross carrier scheduling) or on the scheduling cell (cross carrier scheduling with CIF).

It is worth noting that for the pTAG, the PDCCH order reception is and PRACH preamble transmission are only supported on the PCell.

The RA procedure on an SCell shall only be initiated by a PDCCH order which means that UE MAC sublayer cannot initiate RA procedure on SCell in order to obtain TA or for the case of ‘UL data arrival’.

As of Release-11, contention based RA procedure is not supported on SCell.

Upon receiving the PDCCH order, the UE transmits PRACH preamble on the SCell for which the PDCCH order is intended.

The RAR reception takes place on PCell using RA-RNTI in common search space. The grant received in RAR is valid for the SCell on which PRACH preamble was transmitted.

When the UE receives RAR for an SCell, the UE applies the TA Command received in the RAR to the sTAG to which the SCell belongs. As usual, the UE starts or restarts the TimeAlignmentTimer associated with this sTAG.

It is very important to note that the RACH initiation by PDCCH order is only supported for an activated SCell.

When SCell is deactivated, the ongoing Random Access procedure on the SCell, if any, is aborted.

Another difference as compared to the RA procedure on PCell is that, the UE, after transmitting PRACH preamble for maximum number times, shall not indicate RA problem to upper layers and it just considers that the RA procedure was unsuccessful.

Timing Advance Command MAC CE

The timing advance for a TAG (pTAG or sTAG) can also be obtained by means of Timing Advance Command MAC CE. For this purpose, the existing Timing Advance Command MAC CE has been enhanced to signal different TA values for different TAGs.

As shown below, previously reserved values are now modified to indicate a new 2-bit Timing Advance Group Identity (TAG Id). The 6-bit Timing Advance Command field is unchanged compared to Release-8.

Since the TAG Id field is 2-bits, it can only indicate values from 0 to 3. The TAG containing the PCell has TAG Identity 0. So, at most three sTAGs can be configured.

Upon reception of a timing advance command (via RAR or MAC CE) for a TAG, the UE shall adjust uplink transmission timing for PUSCH/SRS for all the serving cells in that TAG. Additionally, if the TAG contains the PCell, then uplink transmission timing for PUCCH on the PCell shall also be adjusted.

Maintenance of Uplink Time Alignment

As explained above, the UE maintains TimeAlignmentTimer per TAG. The TimeAlignmentTimer is used to control how long the UE considers the Serving Cells belonging to the associated TAG to be uplink time aligned.

The UE shall start or restart the TAG associated timeAlignmentTimer when a Timing Advance Command is received in a RAR or MAC CE for the corresponding TAG.

The synchronization status of the UE follows the synchronization status of the pTAG. When the timer associated with pTAG is not running, the timer associated with a sTAG shall not be running.

When the timeAlignmentTimer associated with the pTAG is expired, the UE shall:

-      flush all HARQ buffers for all serving cells belonging to pTAG as well as sTAG;
-      notify RRC to release PUCCH/SRS for all serving cells
-      clear any configured downlink assignments and uplink grants (applicable for PCell only);
-      consider that all the running timeAlignmentTimers (timers for sTAG as well) as expired.

When the TimeAlignmentTimer associated with the sTAG is expired, the UE shall:

-      flush all HARQ buffers for all the serving cells belonging to this sTAG;
-      notify RRC to release SRS for all the serving cells belonging to this sTAG.

The UE shall not perform any uplink transmission on a Serving Cell except the RA Preamble transmission when the TimeAlignmentTimer associated with the TAG to which this Serving Cell belongs is not running.

When the timeAlignmentTimer associated with the pTAG is not running, the UE shall not perform any uplink transmission on any Serving Cell except the RA Preamble transmission (only) on the PCell.

Reference: 3GPP TS 36.300, 36.321, 36.213 and 36.331