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.

-      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.

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

-      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 CombinationThis 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.

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-ParametersfeatureSetCombinations 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

5G NR: DSS - Dynamic Spectrum Sharing


1.            Introduction to DSS

Dynamic Spectrum Sharing widely known as DSS or LTE-NR co-existence. 

When introduced, earlier generation technologies such as 3G and LTE took several years to rollout due to all new ingredients like new spectrum, new RF, new underlying physical layer technology, and new antenna technology etc. Same is applicable for 5G deployments in FR1 mid-bands and FR2 (mmWave). In addition, delayed spectrum auctions further delays 5G deployment in many countries. In this case, the operators have no choice but to use existing LTE spectrum to deploy 5G.

Spectrum sharing helps faster 5G rollout by enabling spectrum, RF and antenna sharing between LTE and 5G. The network operators can deploy 5G using their existing LTE lower frequency bands, typically below 1 GHz. Initial 5G deployments using spectrum sharing would use NSA mode with an LTE anchor operating in the mid-band (1GHz - 3GHz).

Another equally important aspect where spectrum sharing is much needed is the coverage. To enjoy higher 5G data rates (eMBB), higher bandwidths are needed. Higher bandwidths are primarily possible with FR1 mid-bands (e.g., n78) and FR2. Operations in such high-frequency spectrum obviously shrinks the coverage.

In order to provide wide-area NR coverage, NR should be operated in low frequency spectrum i.e., providing a coverage layer for NR at lower frequencies. However, most of the lower frequency spectrum is already occupied by existing technologies, mostly LTE. This leads to one and only solution of deploying 5G on existing LTE frequency bands.

-      On a side note, re-farming of existing LTE low band spectrum for 5G (with or without spectrum sharing) would enable the operators to smoothly transition towards standalone mode (SA) as lower bands could provide a coverage layer for NR.

By making use of spectrum sharing, operators can upgrade the existing 4G RF units in the field to enable fast rollout of 5G coverage and access to 5G services.

There are two possible solutions to LTE-NR co-existence on low frequency bands which are already used by LTE: Static Spectrum Sharing and Dynamic Spectrum Sharing.

With Static Spectrum Sharing, part of the existing LTE band is allocated to NR as shown below. 


Both NR and LTE technologies use different carriers within the same band. This mechanism of spectrum sharing is the most spectrum in-efficient due to the following;

-      In the beginning, the 5G device penetration is expected to be low and most of the traffic will still be on LTE. Since part of the spectrum is dedicated to NR, the available spectrum for LTE is reduced and becomes too congested. This means that 4G carrier is fully loaded and 5G carrier is unloaded which leads to low spectrum utilization as shown below.

-      Furthermore, neither LTE nor NR can enjoy maximum bandwidth from that specific band hence reduce peak throughput.

 

With Dynamic Spectrum Sharing mechanism, LTE and NR would be dynamically sharing the spectrum. This allows network operators to dynamically adjust the bandwidth on LTE and NR depending upon the current traffic demand on the corresponding technology, see below picture. Moreover, this mechanism guarantees full bandwidth and therefore maximises peak data rate on each technology.


Note that, existing LTE protocols/users are unaffected by DSS i.e., only 5G devices will be made aware of the fact that DSS is being used on the corresponding NR band i.e., DSS guarantees 100% backward compatibility.

DSS technology is mainly relevant for FDD spectrum (600 – 2600 MHz).

 

 

2                       How does DSS work? 

DSS requires a very tight co-ordination between eNB and gNB to achieve reliable synchronization in time- and frequency-domains.

Based on the current load and traffic demand on each of the technologies, the network decides how much bandwidth should be given to LTE and NR devices. As shown below, the network can change/re-schedule the resource allocation at a Transmission Time Interval (TTI = 1 ms) granularity. 




















A proper coordination between 5G and 4G packet schedulers would ensure that the same resource is not allocated to both systems at a given time.

It is important to note that both 15 kHz and 30 kHz numerologies are supported with DSS while LTE transmissions using 15 kHz subcarrier spacing. However, initial DSS deployments aim at NR operating at the same SCS as LTE (15 kHz).

 

2.1    Co-Existence in the Uplink:

Achieving LTE-NR co-existence in the uplink is much simpler and straight forward as compared to downlink. 

LTE and NR packet schedulers must co-ordinate and allocate uplink resources in such a way that NR PUSCH and LTE PUSCH transmissions won’t collide. Similar care should be taken when allocating resources for uplink control signalling e.g., PUCCH. 

Another aspect when it comes to co-existence of LTE and NR is time synchronization in the uplink i.e., it is important to align the timing advances applied by LTE and NR uplink transmissions.

-      The gNB provides the UE with the necessary Timing Advance Offset value using the field n-TimingAdvanceOffset within RRCReconfiguration or SIB1 message. The UE adds this offset to TA command provided by the base station and adjust its uplink accordingly. This field/IE is separately discussed in section 5.

When it comes to frequency domain synchronization in the uplink, the orthogonality between LTE and NR uplink carriers have to be guaranteed.

-      The fundamental difference between LTE and NR uplink waveforms is that, LTE doesn’t transmit any data on the DC carrier whereas DC carrier can be used for uplink data in NR. This means that a 7.5 kHz frequency shift is applied on LTE SC-FDMA waveform whereas NR waveform doesn’t have to apply this frequency shift. 

-      In LTE-NR co-existence situation (DSS), this leads to a frequency difference between NR and LTE uplink subcarrier mapping of 7.5 kHz which will cause inter-carrier interference. To mitigate for the ICI caused by this frequency shift, the gNB can instruct a UE to apply 7.5 kHz frequency shift using the field frequencyShift7p5khz within RRCReconfiguration or SIB1 message. It is mandatory for a DSS supporting UE to support 7.5 kHz frequency shift.

-      So, in DSS case, the network makes sure that LTE and NR uplink transmissions are aligned in the frequency domain by configuring the field frequencyShift7p5khz. With this 7.5 kHz frequency shift, LTE and NR can co-exist within the same frequency/RB/RE grid.

 

2.2    Co-Existence in the Downlink:

For LTE-NR co-existence in the downlink time domain synchronization is needed for radio frame synchronization between LTE and NR. The time domain synchronization between LTE and NR could easily be derived at the base station by making use of GPS for example.

For frequency domain synchronization in the downlink, the base stations can make use of a common frequency reference when generating baseband signal.

As discussed already, LTE doesn’t transmit any data on the DC carrier whereas DC carrier can be used for data in NR. This in general means that LTE and NR RB grids are not aligned. It is the responsibility of the base station scheduler to avoid overlapping RB allocation.

The core requirement for the DSS is that, LTE and NR time and frequency resources are scheduled/shared in such a way that existing LTE “non-scheduled” resources used for PSS/SSS/PBCH and CRS are not affected. To ensure backward compatibility, it is not possible to change the (sort of) fixed allocation defined for these LTE signals.

For DSS in the downlink, the main challenge is that the LTE is transmitting CRS in 4 or 6 non-contiguous OFDM symbols of each subframe (4 OFDM symbols for CRS when using 1 or 2 antenna ports whereas 6 OFDM symbols when using 4 antenna ports). The NR time and frequency allocation in the downlink has to be designed to not collide with CRS to avoid performance degradation to LTE users.

LTE CRS structure when using 2 antenna ports is shown below; 







SSB transmission: 

-      When NR is using 30 kHz SCS, it is straight forward to time multiplex SSB between two CRS symbols. With 30 kHz SCS, a resource element would occupy half the duration to that of LTE’s 15 kHz SCS. This means that just two (LTE) symbols are good enough for SSB transmission (4 NR OFDM symbols) and two consecutive symbols are always available between the two CRS occupied symbols irrespective of number of antenna ports.

-      The tricky bit is when using 15 kHz numerology for NR; as can be seen from the above picture, there are only 3 contiguous OFDM symbols without any CRS transmissions but NR SSB requires 4 symbols with 15 kHz SCS. So, it is not possible to transmit SSB. An alternate approach would be for the eNB to use MBSFN subframes.

-      In MBSFN subframes, the last 12 OFDM symbols are reserved for eMBMS and these reserved symbols can be used for NR signals instead of eMBMS. This topic is further discussed in section 3.

5G PDSCH Transmission:

-      For NR PDSCH channel transmission, rate matching can be used to avoid the REs occupied by LTE CRS.

-      In this case, NR PDSCH can be spread around LTE CRS both in time and frequency domain by making use of PDSCH rate matching around REs occupied by LTE CRS.

-      In order to be able to properly receive such a rate-matched PDSCH, the gNB provides the UE with required LTE-CRS configuration using the IE RateMatchPatternLTE-CRS (discussed in section 5)

-      It is important to note that rate matching around LTE CRS is only possible for the 15kHz SCS.

·        For 30 kHz SCS, multiplexing of LTE CRS and NR PDSCH in frequency domain is not possible due to mismatch in bandwidth of subcarriers, hence only time domain multiplexing is possible.

-      Rate matching around the LTE PSS/SSS and PBCH can be done by defining reserved resources according to bitmaps which are configured by the network. This rate matching pattern is configured using RRC IE rateMatchPatternToAddModList.

 

3                       LTE MBSFN subframes for NR SSB Transmissions

As discussed already, in LTE-NR co-existence scenario the main challenge with 15 kHz NR numerology is that there are only 3 contiguous OFDM symbols without any CRS transmissions but NR SSB requires 4 OFDM symbols with 15 kHz SCS. Since the initial DSS deployments would use 15 kHz NR SCS, this is a serious issue for DSS.

If NR SSB is transmitted in those LTE OFDM symbols in which LTE CRS is transmitted (around LTE CRS REs), the synchronization based on SSB and downlink measurements might be inaccurate. So, it is important to completely avoid those LTE symbols in which LTE CRS is transmitted.

LTE MBSFN subframes could be used to transmit NR SSB as discussed below in detail;

LTE MBSFN stuff: 

LTE MBSFN is used in LTE for evolved Multimedia Broadcast Multicast Services (eMBMS).

As of Release 14, in a radio frame, the network can configure any of subframes #1, #2, #3, #4, #6, #7, #8, and #9 as MBSFN subframes for FDD case, and for TDD case, subframes #3, #4, #7, #8, and #9 can be MBSFN subframes. This configuration is conveyed to the UE using LTE SIB2.

Within MBSFN subframes and depending upon downlink channel bandwidth, starting 1 or 2 OFDM symbols carries information such as PCFICH, PDCCH, CRS, and PHICH. The other symbols within the MBSFN subframe cannot be used for LTE data transmissions and are strictly reserved for eMBMS purpose.

Utilizing LTE MBSFN subframes for SSB transmissions in DSS:

As discussed already, for 15 kHz SCS, in regular LTE subframe, there are only 3 contiguous OFDM symbols without any CRS transmissions but NR SSB requires 4 symbols with 15 kHz SCS. So, it is not possible to transmit SSB in regular LTE subframes. 

It is important to note that only the first 1 or 2 OFDM symbols within MBSFN subframes carries LTE CRS. This opens the door for DSS utilizing MBSFN subframes for NR SSB transmissions as there are more than 3 consecutive OFDM symbols without CRS transmissions available in those MBSFN subframes.

In summary, DSS can utilize MBSFN region (except first OFDM symbol) within MBSFN subframe to transmit NR data mainly NR SSBs as SSBs won’t collide with LTE CRS. On the other hand, LTE devices in the cell are unaffected as those devices understand from SIB2 MBSFN configuration that the respective subframe is not meant for regular LTE data transmissions.

However, if a lot of LTE subframes are converted to MBSFN subframes, LTE only users will experience lower throughputs as those subframes are unavailable for LTE data transmissions. Hence a better approach would be to use MBSFN subframes for NR SSB transmissions and non-MBSFN (regular) LTE subframes for NR data by using DSS.

Which SSBs to transmit in MBSFN subframes?

As discussed already, utilizing MBSFN subframes for SSB transmissions is mainly related to 15 kHZ SCS.

As explained in the post NR: SSB and in section 4.1, 38.213; within a 5ms half frame, the starting OFDM symbol index for a candidate SSB within SS burst set depends upon subcarrier spacing (SCS) and carrier frequency/band. With NR carrier frequencies below 3GHz and SCS=15 kHz, the starting OFDM symbol index for SSBs within SS burst set = {2,8,16,22} => only 4 SSBs are possible to be transmitted in symbols 2, 8, 16 and 22.

With 15kHz SCS, one NR slot = one LTE/NR subframe = 1ms. This means in a given half frame (5ms), there are 5 NR slots or 5 NR subframes or 5 LTE subframes. So, SSB#0 and SSB#1 are transmitted in subframe#0 (starting symbol #2 and #8), SSB#2 is transmitted in subframe#1 (starting symbol number = 16 mod 14 (total no. of symbols) = 2) and SSB#3 is transmitted in subframe#1 (starting symbol number = 22 mod 14 (total no. of symbols) = 8).

As discussed already, MBSFN can’t be configured in subframes #0 and #5, this means transmitting SSB #0 and SSB#1 is not possible as they fall in subframe #0 which cannot be configured as an MBSFN subframe. This leaves with only SSB #2 and SSB#3 in subframe #1.

Since default periodicity of SSB is 20ms, configuring one MBSFN subframe is good enough (subframe #1) once in every 20ms.

As an example, a typical network DSS deployment scenario is considered. The network provides the following MBSFN configuration within lte-CRS-ToMatchAround via NR RRCReconfiguration message.

-      The parameter subframeAllocation1 = fourFrames is a bitmap indicating MBSFN subframe allocation in four consecutive radio frames; (for FDD) starting from the first radio frame, the allocation applies to subframes #1, #2, #3, #6, #7, and #8 within each radio frame.

-      Thus, the given subframe allocation can be split into 6 bits each: 110000 000000 100000 000000 and each 6 bit represents a radio frame. Here, first two subframes #1 and #2 in the 1st radio frame and subframe #1 in the 3rd radio frame are MBSFN subframes.

-      As illustrated below, this configuration repeats once every 4 radio frames as the configured allocation periodicity = 4 frames (radioframeAllocationPeriod).



Finally, within the MBSFN subframe #1 (1st and 3rd radio frames), SSB #2 and/or SSB #3 can be transmitted as shown below. This also aligns with the SSB periodicity of 20ms.

It is worth noting that NR PDSCH, NR DMRS could also be part of this MBSFN subframe. 













As discussed above, it is possible to use SSB#2 and/or SSB#3 within MBSFN subframes. However, networks might choose to transmit only one SSB due to the following reasons. 

-      Beam forming on low DSS bands might not be significant.

-      As the initial DSS deployments are based on software upgrade of existing LTE equipment, beam forming might not be supported.

 

4                       UE Capabilities and NR Features required for DSS

LTE CRS rate matching is the key feature for DSS, the UE should know the LTE CRS pattern that it shall rate match around when receiving DL transmissions on a cell sharing LTE and NR.

Other NR UE features to also consider important for an efficient operation of DSS:

-      NR PDCCH in symbol 2

-      Rate matching pattern to map around LTE PSS/SSS and PBCH

-      TRS in symbol 6 and 10

-      Flexible CSI-RS placement

-      Alternative PDSCH DM-RS pattern when LTE CRS rate matching is configured

-      7.5 kHz UL shift

Some of the above items are discussed in detail below.

NR PDCCH in symbol 2:

-      It is important to note that NR PDCCH cannot be transmitted on those symbols where LTE CRS is being transmitted. LTE CRS is present in 1st OFDM symbol in case of 2 antenna ports and 1st and 2nd OFDM symbols in case of 4 antenna ports.

-      Since NR allows PDCCH transmission on any symbol, it is possible to transmit PDCCH on any symbol that doesn’t contain LTE CRS. The network can inform the UE about the starting OFDM symbol(s) in which PDCCH is transmitted by making use of the field monitoringSymbolsWithinSlot.

Rate matching pattern to map around LTE PSS/SSS and PBCH

-      Rate matching around the LTE PSS/SSS and PBCH can be done by defining reserved resources according to bitmaps which are configured by the network. This rate matching pattern is configured using RRC IE rateMatchPatternToAddModList.

7.5 kHz UL shift

-      As discussed already, the fundamental difference between LTE and NR uplink waveforms is that LTE doesn’t transmit any data on the DC carrier whereas DC carrier can be used for uplink data in NR. This means that a 7.5 kHz frequency shift is applied on LTE SC-FDMA waveform whereas NR waveform doesn’t have to apply this frequency shift. 

-      In LTE-NR co-existence situation (DSS), this leads to a frequency difference between NR and LTE uplink subcarrier mapping of 7.5 kHz which will cause inter-carrier interference. To mitigate for the ICI caused by this frequency shift, the gNB can instruct a UE to apply 7.5 kHz frequency shift using the field frequencyShift7p5khz within RRCReconfiguration or SIB1 message. It is mandatory for a DSS supporting UE to support 7.5 kHz frequency shift.

Alternative PDSCH DM-RS pattern when LTE CRS rate matching is configured

-      When PDSCH time-domain duration is 13 or 14 OFDM symbols and if only one additional DMRS is configured, the DMRS is located at the 11th OFDM symbol. In the case of DSS, this DMRS symbol coincides with LTE CRS symbol. Hence, for additional DMRS symbol, OFDM symbol 12 is used instead of OFDM symbol 11.

-      By including the field additionalDMRS-DL-Alt, the UE indicates its support for using OFDM symbol 12 for additional DMRS. It is applied to 15kHz SCS and one additional DMRS case only.

 

5                       Summary of DSS related IEs/Fields

 

5.1    UE Capability Information

The following information is conveyed in the UECapabilityInformation message from the UE to the network.

rateMatchingLTE-CRS:

-     For NR PDSCH transmission, rate matching can be used to avoid the REs occupied by LTE CRS. In this case, NR PDSCH can be spread around LTE CRS both in time and frequency domain by making use of PDSCH rate matching around REs occupied by LTE CRS.

-     The field rateMatchingLTE-CRS indicates whether the UE supports receiving PDSCH with resource mapping that excludes the REs configured by LTE CRS.

-     The UE indicates the support individually for each band.

-     This is the most important field. Based on the presence of this field, the network can determine whether a UE supports DSS or not.


UE-NR-Capability -> rf-Parameters -> BandNR

. . .


rateMatchingLTE-CRS

ENUMERATED  {supported}

. . .



Additionaldmrs-DL-Alt:

As discussed in section 4, this field indicates whether the UE supports the alternative additional DMRS position for co-existence with LTE CRS. It is applied to 15kHz SCS and (only) one additional DMRS case only;

-     When PDSCH time-domain duration is 13 or 14 OFDM symbols and if only one additional DMRS is configured, the DMRS is located at the 11th OFDM symbol. In the case of DSS, this DMRS symbol coincides with LTE CRS symbol. Hence, for additional DMRS symbol, OFDM symbol 12 is used instead of OFDM symbol 11.

  FeatureSetDownlink-v1540

. . .


additionalDMRS-DL-Alt

ENUMERATED  {supported}

. . .



5.2    DSS related information in Downlink

lte-CRS-ToMatchAround: 

-     This IE is used to configure the UE with a pattern to rate match around LTE CRS and is configured as part of RRCReconfiguration or SIB1.

lte-CRS-ToMatchAround = RateMatchPatternLTE-CRS

carrierFreqDL

INTEGER (0..16383)

carrierBandwidthDL

ENUMERATED {n6, n15, n25, n50, n75, n100, spare2, spare1}

mbsfn-SubframeConfigList

EUTRA-MBSFN-SubframeConfigList

nrofCRS-Ports

ENUMERATED {n1, n2, n4}

v-Shift

ENUMERATED {n0, n1, n2, n3, n4, n5}


        -   Example below;

    

frequencyShift7p5khz: 

-      As discussed in section 5, to mitigate for the ICI caused by the underlying LTE and NR waveform frequency shift, the gNB can instruct a UE to apply 7.5 kHz frequency shift using the field frequencyShift7p5khz within RRCReconfiguration or SIB1 message. 

-      It is mandatory for a DSS supporting UE to support 7.5 kHz frequency shift.

 ServingCellConfigCommon  or  ServingCellConfigCommonSIB

. . .


frequencyShift7p5khz

ENUMERATED  {true}

. . .



n-TimingAdvanceOffset: 

-      When it comes to co-existence of LTE and NR is time synchronization in the uplink i.e., it is important to align the timing advances applied by LTE and NR uplink transmissions.

-      The gNB provides the UE with the necessary Timing Advance Offset value using the field n-TimingAdvanceOffset within RRCReconfiguration or SIB1 message. The UE adds this offset to TA command provided by the base station and adjust its uplink transmission timing accordingly.

 ServingCellConfigCommon  or  ServingCellConfigCommonSIB

. . .


n-TimingAdvanceOffset

ENUMERATED  {n0, n25600, n39936}

. . .




-      This field values are provided in 38.133 table 7.1.2-2 and are presented below.


 

monitoringSymbolsWithinSlot:

-      As discussed already, NR PDCCH cannot be transmitted on those symbols where LTE CRS is being transmitted. LTE CRS is present in 1st OFDM symbol in case of 2 antenna ports and 1st and 2nd OFDM symbols in case of 4 antenna ports.

-      Since NR allows PDCCH transmission on any symbol, it is possible to transmit PDCCH on any symbol that doesn’t collide with LTE CRS. The network can inform the UE about the starting OFDM symbol(s) in which PDCCH is transmitted by making use of the field monitoringSymbolsWithinSlot.

-      This field is configured as part of PDCCH-Config.

rateMatchPatternToAddModList:

-      Rate matching around the LTE PSS/SSS and PBCH can be done by defining reserved resources according to bitmaps which are configured by the network. This rate matching pattern is configured using RRC IE rateMatchPatternToAddModList within PDSCH-Config.

 

Reference: 3GPP TS 38.331 (v16.2.0), 38.133 (v16.3.0), 38.306 (v16.0.0), and Tdoc RP-182635