5G/NR - DSS  

 

 

 

What is DSS (Dynamic Spectrum Sharing) ?

What is DSS ? It is just as it stands for : Dynamic Spectrum Sharing.  Spectrum Sharing implies 'multiple radio access technology shares the same spectrum (i.e, same frequency span)'.

What are the multiple radio access technologies that wants to share a spectrum. Theoretically, they can be any technologies, but in practice we usually mean NR(5G) and LTE(4G). So, simply put, 'Spectrum Sharing' in DSS would mean Spectrum Sharing between LTE and NR.

Then let's think of 'Dynamic' part in DSS. What would this mean ? It implies 'They are sharing a radio channel with the specific bandwidth, but how much of the channel is allocated to which radio technology (NR or LTE) is not static(fixed). It changes dynamically meaning changing in very short interval. You may say it changes 'in real time' or 'instantenously'. What would 'real time' or 'instantaneous' mean ? Theoretically, it would mean the minimum scheduling time granularity of the two technology that share the spectrum. Assuming LTE and NR, the minimum scheduling time granularity of LTE is one subframe(1 ms) and the minimum scheduling time granularity of NR is a slot (the length of slot in time varies depending on numerology). In most numerology, LTE minimum time scheduling granularity is 1 ms and NR minimum time scheduling granularity is much smaller than 1 ms in most numerology. So the minimum time scheduling granularity that can apply to both NR and LTE is determined by LTE (coarse of the two). Therefore, it would be reasonable to think that the timing granularity (i.e, meaning of 'Dynamic') of the shared spectrum of NR and LTE would be 1 ms. This does not mean that NR slot timing changes or slot structure should change. It just mean that the minimum time interval for spectrum sharing configuration change would be 1 ms.

Followings are the list of the topics I will go through in this note. DSS is a huge topic and I don't think I have full-detailed understanding at the time of the first writing (Jul 2020) and it would not be possible to write everything in short period. This list would get longer as I spend more time to study.

NOTE : There are many documents and discussions using the term 'Spectrum Sharing'. In some case, I get confused by the terminology. At early stage, there has been some discussion on 'Spectrum Sharing especially with Unlicensed Specturm' which is well illustrated in this Qualcomm presentation but this obviously not much relations to what I am going to talk in this note (DSS). You may have heard of another terminology more in 3GPP community called 'NR-LTE Co-existence'. Actually this is more relevent to DSS and in some cases 'NR-LTE Co-existence' is used interchangeably with DSS. My interpretation is that 'NR-LTE Coexistence' has broader meaning and DSS is only option(technology) for implementing 'NR-LTE Coexistence'. This is just my interpretation, depending on person or context DSS and LTE-NR coexistence can be used as similar meaning or different meaning. For example, when I was reading 3GPP TDoc R1-1701618 (Ref [6]), I didn't notice much of DSS concept there, but looking into a Mediatek white paper (Ref [1]), it sounds like they use LTE-NR coexistence interchangeablly with DSS.

Better note than mine

Before I start talking technical details on this topic, I want to introduce an excellent whitepaper on this topic, which is 5G NR and 4G LTE Coexistence (Mediatek Whitepaper) and Dynamic Spectrum Sharing(SamSung Whitepaper).  I don't think I can write better than the paper on this topic and to be honest I don't have such a detailed knowledge as the writers of the paper. If you read the paper and turn it into your own understanding, you may not need to read my note. I am just trying to do is to draw a big picture on this topic in a little bit shorter version so that you can refresh memory and concept later.

How to share ?

Then let's think of how we can share the same spectrum between LTE and NR 'Dynamically'. Conceptually it would be simple and anybody would come out with this type of logic. Following illustration shows some of the possible options (NOTE : The term 'Option' in this illustration is just my personal labelling, it is not from any specification).

In this illustration, it is assumed that Network scheduler determine the spectrum sharing configuration at every LTE subframe (1ms). Also, in this illustration I assumed that NR slot length is 1 ms as well but in reality the NR slot length and the number of slots within the 1 ms varies depending on numerology (subcarrier spacing).

The first option is the case where the Network schedules both LTE and NR in the same time period in different frequency location. Since the frequency domain location of LTE and NR does not collide each other, both technology can coexists.

The second option is the case where the Network schedules NR only in the time period.

The third option is also the case where the Network schedules NR only in the time period. The difference between the option 2 and option 3 is that option 3 case the time period is in a special called called 'MBSFN'.

The fourth option is the case where the network schedules NR only, but it does not take all the time domain resources. It uses only a small portions time domain resources (i.e, only a small numbers of OFDM symbols).

NOTE : All of these options would sound simple conceptionally, but in real implementation there are some details for every options that can be considered and worked out very carefully. I will talk about this next section.

NOTE :  When NR is using Regular subframe as in Option 1 and 2, it should not overwrite the LTE critical resource elements like PCFICH/HICH/PDCCH region or CRS.  For this reason, usually NR does not use the first n symbols (usually 2 or 3 symbols) to make it sure it is not overwriting LTE control region and does ratematching around LTE CRS RE. It mean that NR SearchSpace should start after LTE control region.

Would it be really as simple as it sound ?

Now let's take a look at some aspect of real implementation. While I have been working in engineering, one most important thing that I learned is 'Nothing goes as textbook says' and 'you don't know what's going to happen before you really try'. This applies to DSS as well. Most of tricky things that make situation complicated is related to the fact that this new technology SHOULD NOT impact on the operation / functionality of existing billions of LTE devices which are already out there. It means that this new techology should guarantee 100% backward compatibility.

In this section, I will talk about some aspects / factors to be considered in terms of DSS implementation in order to guarantee the backward compatibility.

Shifting NR CORESET

Let's think of the idea that we allocate LTE and NR in the same time slot as shown below (at high level, this belongs to Option 1 mentioned in previous section). Would this work ?

At the first glance, it may look it works, but having a second thought you would realize that there is some obvious problems. The first problem you may notice right away is that NR CORESET location collides with the LTE control channel location. Why this is problem ? That area is not the region that is asigned to the current LTE user.

It is not true. Even though only a portion of the frame (in frequency domain) is scheduled to the LTE device, the control channel area should be visible across full frequency range to every LTE device regardless of how much portion is allocated for PDSCH.

Rate Matching around LTE CRS

Now let's think of a modified scenario of the previous case. In this scenario, I put the NR CORESET out side of the LTE control region to avoid the collision between LTE control channel and NR resource allocation. To make this possible, NR specification should allow the control channel (NR CORESET/PDCCH) to be located none-zero symbol (the third symbol in this case) of the slot. OK, we can avoid the control channel collision between LTE and NR in this scenario, then would this work ?

Unfortunately the answer is still NO. Why not ? This would not work because NR PDSCH is overlapping the LTE CRS(Cell Refernce Signal). Like control channel in LTE, CRS should be visible to all the device across the full frequency band regardless of the size of PDSCH area. So blocking LTE CRS by NR PDSCH would lead to PDSCH decoding failure on LTE device.

OK, now let's modify the previous scenario a little bit further as below. How about this ? In this scenario, NR PDSCH is punctured (rate matches) around NR CRS and LTE CRS now visible to the mobile device across the full frequency span. It seems (at least to me) that there is no problem and this scenario would work.

To apply this trick, UE need to support following capability (in UE capability information)

    RF-Parameters ::= SEQUENCE {

        supportedBandListNR         SEQUENCE (SIZE (1..maxBands)) OF BandNR,

        ....

    }

     

    BandNR ::= SEQUENCE {

        ...

        rateMatchingLTE-CRS         ENUMERATED {supported} OPTIONAL,

        ...

    }

If UE support this capability, Network can configure the ratematching in such a way that NR cell can avoid LTE CRS.

    ServingCellConfig ::= SEQUENCE {

       ...

       lte-CRS-ToMatchAround              SetupRelease { RateMatchPatternLTE-CRS } OPTIONAL,

       rateMatchPatternToAddModList    SEQUENCE (SIZE (1..maxNrofRateMatchPatterns)) OF RateMatchPattern,

       ...

    }

     

    RateMatchPatternLTE-CRS ::= SEQUENCE {

       carrierFreqDL                       INTEGER (0..16383),

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

       mbsfn-SubframeConfigList      EUTRA-MBSFN-SubframeConfigList OPTIONAL,

       nrofCRS-Ports                      ENUMERATED {n1, n2, n4},

       v-Shift                                ENUMERATED {n0, n1, n2, n3, n4, n5}

    }

In addition to previous configuration, NW may need to configure proper xOverhead via following IE for stable PDSCH decoding.

    PDSCH-ServingCellConfig ::= SEQUENCE {

        codeBlockGroupTransmission        SetupRelease { PDSCH-CodeBlockGroupTransmission } ,

        xOverhead                                ENUMERATED { xOh6, xOh12, xOh18 } OPTIONAL,

        nrofHARQ-ProcessesForPDSCH      ENUMERATED {n2, n4, n6, n10, n12, n16},

        pucch-Cell                                ServCellIndex OPTIONAL,

        ...,

    }

Rate Maching Around LTE PSS,SSS,PBCH

By the same logic mentioned above, if NR slot is allocated in the subframe where LTE PSS,SSS,PBCH is transmitted, the NR data should be punctured around these LTE signal as well.  This situation would applies in the case where LTE subframe 0 or subframe 5 is shared with NR.

In this case, the easiest way is for NR to avoid allocating the whole 6 RBs occupied by PSS,SSS,PBCH. In other words, NR does RB level rate maching around the RBs carrying PSS,SSS,PBCH. It would waste a little bit more resources comparing with RE level rate maching, but it would be simpler to implement.

To apply this trick, UE has to support the RB level rate matching. That capability is informed by following UE capability Information IE.

    Phy-ParametersCommon ::= SEQUENCE {

       ....

       rateMatchingResrcSetSemi-Static          ENUMERATED {supported} OPTIONAL,

       rateMatchingResrcSetDynamic               ENUMERATED {supported} OPTIONAL,

       ....

    }

If UE support the RB level rate matching, Network can configure the Rate maching patterns using following IEs.

    PDSCH-Config ::= SEQUENCE {

        ...

        rateMatchPatternToAddModList    SEQUENCE (SIZE (1..maxNrofRateMatchPatterns)) OF RateMatchPattern,

        rateMatchPatternToReleaseList    SEQUENCE (SIZE (1..maxNrofRateMatchPatterns)) OF RateMatchPatternId,

        rateMatchPatternGroup1             RateMatchPatternGroup

        ...

    }

     

    RateMatchPattern ::= SEQUENCE {

       rateMatchPatternId          RateMatchPatternId,

       patternType CHOICE {

          bitmaps SEQUENCE {

             resourceBlocks        BIT STRING (SIZE (275)),

             symbolsInResourceBlock CHOICE {

                oneSlot            BIT STRING (SIZE (14)),

                twoSlots           BIT STRING (SIZE (28))

             },

          periodicityAndPattern CHOICE {

             n2                    BIT STRING (SIZE (2)),

             n4                    BIT STRING (SIZE (4)),

             n5                    BIT STRING (SIZE (5)),

             n8                    BIT STRING (SIZE (8)),

             n10                   BIT STRING (SIZE (10)),

             n20                   BIT STRING (SIZE (20)),

             n40                   BIT STRING (SIZE (40))

       } OPTIONAL, -- Need S

       ...

       },

       controlResourceSet ControlResourceSetId

       },

       subcarrierSpacing SubcarrierSpacing OPTIONAL,

       dummy ENUMERATED { dynamic, semiStatic },

       ...,

       [[

       controlResourceSet-r16 ControlResourceSetId-r16 OPTIONAL -- Need R

       ]]

    }

Scheduling Symbols not cliding with any of LTE Reference Signal

Would there be any way to transmit NR PDSCH without worrying too much about puncturing around LTE reference signal ? One of the characteristics of NR is that it allows symbol level scheduling. If Network schedule only a few OFDM symbols where there is no LTE Reference signal, the NR PDSCH can be transmitted without worrying about overriding the LTE reference signal. Of course, this type of scheduling can be a limiting factor for throughput, but it can be useful way depending on situation.

What I mentioned in this section is the most crucial part of implementing DSS, but there would be additional things to consider for DSS implementation. All of those items to be considered for DSS implementation is well summarized in RP-182635 (Ref [5]) as below. You see some of the items are related to handling LTE reference signal that I mentioned above.

  • 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

How to deal with SSB ?

In case of NR PDSCH transmission in DSS mode, most of the problems (especially problems of collision with LTE frame structure) were resolved by tweaking NR side (like punctuation/rate matching of NR data). How about SSB ? We can easily guess that there would be the case where SSB resource allocation collides with LTE reference signal. Can we resolve this collision in the same way as PDSCH case (i.e, by punctuation/rate matching) ? Unfortunately it is not possible. It is so fundantal signal in NR. Changing the structure of SSB can cause various other problems. So the only option is to find the space which the SSB can squeeze into without changing anything in the SSB. The most critical constraints is that NR SSB requires 4 consecutive OFDM symbols.

Let's think of a few possible cases as illustrated below. The yellow area in the illustraton is to represent the four consecutive NR OFDM symbols and it also shows how the time domain span can overlap with various configuration of LTE subframe structure (e.g, MIMO scheme, MBSFN vs Regular subframe).

In < Case 1 > where NR SSB numerology is 15 Khz, in this case you would not be able to find any time domain space that gives you 4 consecutive space which does not carry any reference signal in it except MBSFN subframe.

In < Case 2 > and < Case 3> where NR SSB numerology is 30 Khz, you can find multiple area that can accommodate four consecutive NR OFDM symbols. The number of candidates (the space that can accommodate four consecutive NR OFDM symbols) varies depending on antenna configuration.

Once you indentified these candiate, you can turn on only those SSB bursts that can faill into these candidate area.

This is overall logic of setting the SSB transmission pattern (bitmap) under DSS environment. If you want to see some specific examples SSB burst settings, refer to Mediatek White Paper(Ref [1]). Once you understand this logic, it would be easiear to understand what they say in the white paper.

How to deal with DMRS ?

In previous sections, I mentioned that the key factors for implementing DSS is to figure out how to apply this technology without impacting the operation of existing LTE device (i.e, backward compatibility). To maintain the backward compatibility, it is reasonable to reconfigure the new technology (i.e, NR) rather than the old technology(i.e, LTE) since there are already so many old technology devices in the field and it is not possible to those existing devices to accommodate this kind of new features.

Under this context, I talked about how to handle PDSCH resource allocation and how to handle SSB configuration. Now a natural question would pop up in your mind. What about NR PDSCH DMRS ?

Let's first think of what kind of problem would happen with NR PDSCH DMRS. < Case 1 > in the following illustration shows a case where all the possible PDSCH DMRS is enabled (i.e, one detault DMRS and three additional DMRS). For other possibe DMRS locations refer to this note and table). You would see that the DMRS at symbol 11 in SCS 15 Khz resource grid collides with LTE CRS.

How can we avoid this collision ? we may think of two possibility. First option is that we configure/shift the freuquency location of DMRS in such a way that they are not colliding with LTE CRS, but this is a little bit tricky because LTE CRS location in frequency domain changes depending on physical cell ID (refer to this page if you want some further details) and NR DMRS location in frequency domain changes depending on antenna port (refer to this note if you want further details). Second option that we can think of is to shift the NR PDSCH DMR in time domain. Since only the NR PDSCH DMRS at position 11 collides with LTE CRS, it would be easier to shift only that DMRS as shown in < Case 2 >.

UE Capability

gNB checks on UE capability information before it applies/configures DSS. If UE does not notify the specific UE capability required for DSS, gNB would not apply DSS.

The key IEs related to Dynamic Spectrum Sharing (DSS) in this capability information are:

rateMatchingLTE-CRS : Indicates whether the UE supports rate matching around LTE CRS patterns when NR is deployed in-band with LTE. This is important for DSS to allow NR to rate match around LTE reference signals.

 

BandNR : The NR bands specified here would indicate the bands supported for DSS deployment by the UE.

 

BandNR ::=  SEQUENCE {

    bandNR                          FreqBandIndicatorNR,

    modifiedMPR-Behaviour           BIT STRING (SIZE (8))                       OPTIONAL,

    mimo-ParametersPerBand          MIMO-ParametersPerBand                      OPTIONAL,

    extendedCP                      ENUMERATED {supported}                      OPTIONAL,

    multipleTCI                     ENUMERATED {supported}                      OPTIONAL,

    bwp-WithoutRestriction          ENUMERATED {supported}                      OPTIONAL,

    bwp-SameNumerology                  ENUMERATED {upto2, upto4}               OPTIONAL,

    bwp-DiffNumerology                  ENUMERATED {upto4}                      OPTIONAL,

    crossCarrierSchedulingDL-SameSCS        ENUMERATED {supported}              OPTIONAL,

    crossCarrierSchedulingUL-SameSCS        ENUMERATED {supported}              OPTIONAL,

    pdsch-256QAM-FR2                ENUMERATED {supported}                      OPTIONAL,

    pusch-256QAM                    ENUMERATED {supported}                      OPTIONAL,

    ue-PowerClass                   ENUMERATED {pc2, pc3}                       OPTIONAL,

    rateMatchingLTE-CRS             ENUMERATED {supported}                      OPTIONAL,

    ...

}

 

Phy-ParametersCommon ::=    SEQUENCE {

    csi-RS-CFRA-ForHO                   ENUMERATED {supported}          OPTIONAL,

    dynamicPRB-BundlingDL               ENUMERATED {supported}          OPTIONAL,

    sp-CSI-ReportPUCCH                  ENUMERATED {supported}          OPTIONAL,

    sp-CSI-ReportPUSCH                  ENUMERATED {supported}          OPTIONAL,

    nzp-CSI-RS-IntefMgmt                ENUMERATED {supported}          OPTIONAL,

    type2-SP-CSI-Feedback-LongPUCCH     ENUMERATED {supported}          OPTIONAL,

    precoderGranularityCORESET          ENUMERATED {supported}          OPTIONAL,

    dynamicHARQ-ACK-Codebook            ENUMERATED {supported}          OPTIONAL,

    semiStaticHARQ-ACK-Codebook         ENUMERATED {supported}          OPTIONAL,

    spatialBundlingHARQ-ACK             ENUMERATED {supported}          OPTIONAL,

    dynamicBetaOffsetInd-HARQ-ACK-CSI   ENUMERATED {supported}          OPTIONAL,

    pucch-Repetition-F1-3-4             ENUMERATED {supported}          OPTIONAL,

    ra-Type0-PUSCH                      ENUMERATED {supported}          OPTIONAL,

    dynamicSwitchRA-Type0-1-PDSCH       ENUMERATED {supported}          OPTIONAL,

    dynamicSwitchRA-Type0-1-PUSCH       ENUMERATED {supported}          OPTIONAL,

    pdsch-MappingTypeA                  ENUMERATED {supported}          OPTIONAL,

    pdsch-MappingTypeB                  ENUMERATED {supported}          OPTIONAL,

    interleavingVRB-ToPRB-PDSCH         ENUMERATED {supported}          OPTIONAL,

    interSlotFreqHopping-PUSCH          ENUMERATED {supported}          OPTIONAL,

    type1-PUSCH-RepetitionMultiSlots    ENUMERATED {supported}          OPTIONAL,

    type2-PUSCH-RepetitionMultiSlots    ENUMERATED {supported}          OPTIONAL,

    pusch-RepetitionMultiSlots          ENUMERATED {supported}          OPTIONAL,

    pdsch-RepetitionMultiSlots          ENUMERATED {supported}          OPTIONAL,

    downlinkSPS                         ENUMERATED {supported}          OPTIONAL,

    configuredUL-GrantType1             ENUMERATED {supported}          OPTIONAL,

    configuredUL-GrantType2             ENUMERATED {supported}          OPTIONAL,

    pre-EmptIndication-DL               ENUMERATED {supported}          OPTIONAL,

    cbg-TransIndication-DL              ENUMERATED {supported}          OPTIONAL,

    cbg-TransIndication-UL              ENUMERATED {supported}          OPTIONAL,

    cbg-FlushIndication-DL              ENUMERATED {supported}          OPTIONAL,

    dynamicHARQ-ACK-CodeB-CBG-Retx-DL   ENUMERATED {supported}          OPTIONAL,

    rateMatchingResrcSetSemi-Static     ENUMERATED {supported}          OPTIONAL,

    rateMatchingResrcSetDynamic         ENUMERATED {supported}          OPTIONAL,

    bwp-SwitchingDelay                  ENUMERATED {type1, type2}       OPTIONAL,

    ...

}

RRC Configuration

This is a part of RRCConfiguration message which are related to DSS configuration. When DSS is implemented in MBSFN subrames MBSFN related IEs are used and when it is implmented in regular subframe (i.e, non-MBSFN subframe), lte-CRS-ToMatchAround, rateMatchPatternToAddModList are used.

 

ServingCellConfigCommon ::= SEQUENCE {

    physCellId                  PhysCellId  

    downlinkConfigCommon        DownlinkConfigCommon,

    uplinkConfigCommon          UplinkConfigCommon 

    supplementaryUplinkConfig   UplinkConfigCommon  

    n-TimingAdvanceOffset        ENUMERATED { n0, n25600, n39936 }

    ssb-PositionsInBurst        CHOICE {

        shortBitmap               BIT STRING (SIZE (4)),

        mediumBitmap              BIT STRING (SIZE (8)),

        longBitmap                BIT STRING (SIZE (64))

    }   OPTIONAL, -- Need R,

    ssb-periodicityServingCell      ENUMERATED { ms5, ms10, ms20, ms40, ms80, ms160,

                                                 spare2, spare1 }OPTIONAL,  -- Need S

    dmrs-TypeA-Position             ENUMERATED {pos2, pos3},

    lte-CRS-ToMatchAround           SetupRelease { RateMatchPatternLTE-CRS } OPTIONAL,  

    rateMatchPatternToAddModList    SEQUENCE (SIZE (1..maxNrofRateMatchPatterns)) OF

                                             RateMatchPattern   

    rateMatchPatternToReleaseList   SEQUENCE (SIZE (1..maxNrofRateMatchPatterns)) OF

                                              RateMatchPatternId 

    ssbsubcarrierSpacing          SubcarrierSpacing   

    tdd-UL-DL-ConfigurationCommon   TDD-UL-DL-ConfigCommon   

    ss-PBCH-BlockPower              INTEGER (-60..50),

    ...

}

 

RateMatchPatternLTE-CRS ::= SEQUENCE {

    carrierFreqDL                   INTEGER (0..16383),

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

    mbsfn-SubframeConfigList        EUTRA-MBSFN-SubframeConfigList OPTIONAL,

    nrofCRS-Ports                   ENUMERATED {n1, n2, n4},

    v-Shift                         ENUMERATED {n0, n1, n2, n3, n4, n5}

}

 

RateMatchPattern ::= SEQUENCE {

    rateMatchPatternId RateMatchPatternId,

    patternType CHOICE {

        bitmaps SEQUENCE {

        resourceBlocks              BIT STRING (SIZE (275)),

        symbolsInResourceBlock CHOICE {

            oneSlot                 BIT STRING (SIZE (14)),

            twoSlots                BIT STRING (SIZE (28))

        },

        periodicityAndPattern CHOICE {

            n2                      BIT STRING (SIZE (2)),

            n4                      BIT STRING (SIZE (4)),

            n5                      BIT STRING (SIZE (5)),

            n8                      BIT STRING (SIZE (8)),

            n10                     BIT STRING (SIZE (10)),

            n20                     BIT STRING (SIZE (20)),

            n40                     BIT STRING (SIZE (40))

        } OPTIONAL, -- Need S

        ...

    },

        controlResourceSet          ControlResourceSetId

    },

        subcarrierSpacing           SubcarrierSpacing OPTIONAL, -- Cond CellLevel

        mode                        ENUMERATED { dynamic, semiStatic },

    ...

}

 

EUTRA-MBSFN-SubframeConfigList ::=

            SEQUENCE (SIZE (1..maxMBSFN-Allocations)) OF EUTRA-MBSFN-SubframeConfig

 

EUTRA-MBSFN-SubframeConfig ::= SEQUENCE {

    radioframeAllocationPeriod          ENUMERATED {n1, n2, n4, n8, n16, n32},

    radioframeAllocationOffset          INTEGER (0..7),

    subframeAllocation CHOICE {

        oneFrame                        BIT STRING (SIZE(6)),

        fourFrames                      BIT STRING (SIZE(24))

    },

    subframeAllocation-v1430 CHOICE {

        oneFrame-v1430                  BIT STRING (SIZE(2)),

        fourFrames-v1430                BIT STRING (SIZE(8))

    } OPTIONAL, -- Need R

    ...

}

Reference

[1] 5G NR and 4G LTE Coexistence (Mediatek Whitepaper) 

[2] Ericsson Spectrum Sharing

[3] Breakthrough 5G data call using dynamic spectrum sharing to accelerate nationwide 5G deployments

[4] Ericsson Mobility Report : 5G Insights by 2023  

[5] RP-182635 : 3GPP TSG-RAN #82  Spectrum sharing and corresponding UE capabilities

[6] R1-1701618 : 3GPP TSG RAN WG1 Meeting#88 - Discussion on NR-LTE Co-existence  

Reference : YouTube

[1]  Demystifying 5G 5G NR coexistence with LTE based on dynamic spectrum sharing (DSS)