|
|
||
|
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.
Better note than mineBefore 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).
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 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 CORESETLet'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 CRSNow 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,PBCHBy 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 SignalWould 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.
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 CapabilitygNB 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:
BandNR ::= SEQUENCE { 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, ... }
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 ConfigurationThis 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 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) [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)
|
||
