CORESET
|
Resource Allocation Unit in NR is similar to LTE case, but a few new units (e.g, REG bundle, CORESET) are introduced in NR. Basic definition of these units and relationship among these units are described in 38.211 - 7.3.2.2 Control-resource set (CORESET)
What is CORESET ?NR CORESET vs LTE Control RegionParameters for CORESET / Structure of CORESETExampleA Special Coreset : CORESET 0What is SearchSpace ?How many bits can be carried by a Search Space ?How many CORESET and SearchSpaces in a Channel Band ?How many RBs do you need for CORESET ?ExampleUE Capability
What is CORESET ?
CORESET is a set of physical resources(i.e, a specific area on NR Downlink Resource Grid) and a set of parameters that is used to carry PDCCH/DCI. It is equivalent to LTE PDCCH area (the first 1,2,3,4 OFDM symbols in a subframe). But in LTE PDCCH region, the PDCCH always spread across the whole channel bandwidth, but NR CORESET region is localized to a specific region in frequency domain.
Some background of adopting this kind of design is briefly described in IV-A of this paper as follows
Legacy LTE control channels are always distributed across the entire system bandwidth, making it difficult to control
intercell interference . NR PDCCHs are specifically designed to transmit in a configurable control resource set (CORESET). A CORESET is analogous to the control region in LTE but is generalized in the sense that the set of RBs and the set of OFDM symbols in which it is located are configurable with the corresponding PDCCH search spaces. Such configuration flexibilities of control regions including time, frequency, numerologies, and operating points enable NR to address a wide range of use cases.
NR CORESET vs LTE Control Region
As mentioned above, CORESET in NR is equivalent to the Control Region in LTE. The main difference between CORESET and LTE Control Region can be illustrated as follows.
As you may notice, the control region in LTE spreaded across the whole channel band width(CBW) and NR CORESET is localized within each BWP.
Frequency Domain Parameter : Since Control Region in LTE is always spreaded across the whole channel band width, there is no parameters defining the frequency domain region for LTE control region, but in NR we need a parameter defining the frequency domain width for CORESET since the frequency domain width can be set in any value in the multiples of 6 RBs.
Time Domain Parameter : Both NR CORESET and LTE Control Region can vary in time domain length. So we need the parameter for time domain length both in LTE in NR. In LTE, the time domain length of control region is defined by the physical channel called PCFICH but in NR the time domain length of CORESET is defined by the RRC parameter (ControlResourceSet.duration).
Parameters for CORESET / Structure of CORESET
A CORESET is made up of multiple levels of sub-structures illustrated below. Roughly speaking, you may say 'A CORESET can accommodate multiples of Aggregation Level. An Aggregation Level is made up of N CCE. A CCE is made up of 6 REGs. A REG is made up of 1 RB and 1 OFDM Symbol.'
NOTE : Non-Used region is the region that is not covered by Aggregation Levels. There may or may not be such a non-used region depending on configuration. The number of Aggregation Leves for each size can be 0 or multiples and it is specified by Rrc Parameter nrofCandidates
I got another figure that visualize well the mapping between PDCCH and CORESET from Understanding the Heart of the 5G Air Interface: An Overview of Physical Downlink Control Channel for 5G New Radio (NR) . Basically this shows the samething as my diagram shown above. One major difference is that this shows the case of interleaving whereas my diagram shown above is assumed for the case of non-interleaving.
Followings are basic terminilogies that you need to understand the CORESET resource allocation and monitoring process.
Resource Element : This is same as LTE. It is the smallest unit of the resource grid made up of one subcarrier in frequency domain and one OFDM symbol in time domain.
Resource Element Group (REG) : One REG is made up of one resource block (12 resource element in frequency domain) and one OFDM symbol in time domain. For clarification, I quote 38.211-7.3.2.2 as below :
A control-channel element consists of 6 resource-element groups (REGs) where a resource-element group equals one resource block during one OFDM symbol.
REG Bundles : One REG bundle is made up of multiple REGs. The bundle size is specified by the parameter 'L'. The L is determined by the RRC parameter reg-bundle-size.
Control Channel Element(CCE) : A CCE is made up multiple REGs. The number REG bundles within a CCE varies.
Aggregation Level : Aggregation Level indicates how many CCEs are allocated for a PDCCH. Aggregation Level and the number of allocated CCE is defined in following table. (LTE has similar mapping between Aggregation Level and the Number of CCEs as described here )
< 38.211-Table 7.3.2.1-1: Supported PDCCH aggregation levels. >
Aggregation Level | Number of CCEs |
1 | 1 |
2 | 2 |
4 | 4 |
8 | 8 |
16 | 16 |
Control Resource Set(CORESET): A CORESET is made up of multiples resource blocks (i.e, multiples of 12 REs) in frequency domain and '1 or 2 or 3' OFDM symbols in time domain. Defined in 38.211 - 7.3.2.2 Control-resource set (CORESET). CORESET is equivalent to the control region in LTE subframe. In LTE, the frequency domain of the control region is always same as the total system bandwidth, so no parameter is needed to define the frequency domain region for LTE control region. Time domain region can be {1,2,3} which is determined by PCFICH. However, in NR both frequency region and time domain region can be defined by RRC signaling message.
Parameter | Description |
| Number of RBs in frequency domain in a CORESET. Determined by RRC Parameter CORESET-freq-dom |
| Number of symbols in time domain in a CORESET. Determined by RRC Parameter CORESET-time-dur. This can be 1 or 2 or 3, but 3 is possible only when DL-DMRS-typeA-pos = 3 |
| Number of REGs in a CORESET |
L | REG Bundle Size, set by CORESET-REG-bundle-size |
The RRC parameters defining the CORESET are as follows (based on 38.331 v15.3.0) :
ControlResourceSet ::= SEQUENCE {
controlResourceSetId ControlResourceSetId,
frequencyDomainResources BIT STRING (SIZE (45)),
duration INTEGER (1..maxCoReSetDuration),
//maxCoReSetDuration = 3
cce-REG-MappingType CHOICE {
interleaved SEQUENCE {
reg-BundleSize ENUMERATED {n2, n3, n6},
interleaverSize ENUMERATED {n2, n3, n6},
shiftIndex INTEGER(0..maxNrofPhysicalResourceBlocks-1)
},
nonInterleaved NULL
},,
precoderGranularity ENUMERATED {sameAsREG-bundle, allContiguousRBs},
tci-StatesPDCCH SEQUENCE(SIZE (1..maxNrofTCI-StatesPDCCH)) OF TCI-StateId
tci-PresentInDCI ENUMERATED {enabled} OPTIONAL
pdcch-DMRS-ScramblingID BIT STRING (SIZE (16)) OPTIONAL
}
controlResourceSetId : this corresponds to L1 parameter 'CORESET-ID'
- Value 0 identifies the common CORESET configured in MIB and in ServingCellConfigCommon
- Values 1..maxNrofControlResourceSets-1 identify CORESETs configured by dedicated signalling
- The controlResourceSetId is unique among the BWPs of a ServingCell.
frequencyDomainResources: Frequency domain resources (this should be within BWP assigned to UE). This corresponds to L1 parameter L1 parameter 'CORESET-freq-dom'.
- Each bit corresponds a group of 6 RBs, with grouping starting from PRB 0, which is fully contained in the bandwidth part within which the CORESET is configured.
- The most significant bit corresponds to the group of lowest frequency which is fully contained in the bandwidth part within which the CORESET is configured, each next subsequent lower significance bit corresponds to the next lowest frequency group fully contained within the bandwidth part within which the CORESET is configured, if any. Bits corresponding to a group not fully contained within the bandwidth part within which the CORESET is configured are set to zero.
duration : Contiguouse time duration of the CORESET in number of symbols
cce-reg-MappingType : Mapping method of Control Channel Elements (CCE) to Resource Element Groups (REG).
reg-BundleSize : The number of REGs within a REG Bundle. Corresponds to L1 parameter 'CORESET-REG-bundle-size'
interleaveSize : Corresponds to L1 parameter 'CORESET-interleaver-size'
shiftIndex : Corresponds to CORESET-shift-index
precoderGranularity: Precoder granularity in frequency domain. It corresponds to L1 parameter 'CORESET-precoder-granuality.
tci-StatesPDCCH : Reference to a configured TCI State providing QCL configuration/indication for PDCCH
tci-PresentInDCI : Corresponds to L1 parameter 'CORESET-precoder-granuality'
pdcch-DMRS-ScramblingID : PDCCH DMRS scrambling initalization
Example 01>
Here is an example showing to procedure to map from RE to CCE. For simplicity, I assume that interleaving is not applied.
A Special Coreset : CORESET 0
The coreset described above is normal coreset and those coreset are configured by RRC. But there is a special type of coreset called CORESET 0. This coreset is the one transmitting PDCCH for SIB1 scheduling. As you would notice above, there are many parameters involved in defining those coreset and those parameters are specified by RRC message (e.g, LTE RRC Connection Reconfiguration for ENDC, SIB1 or RRC Setup in SA). However, CORESET 0 cannot be specified by RRC since it should be used before any RRC is transmitted. It implies that CORESET 0 should be configured by some predefined process and predefined parameters. These predefined process and parameters are summarized as follows.
Parameters | Predefined value or process |
Frequency/Time Resourece Allocation | MIB pdcch-ConfigSIB1 (38.213-13) |
Interleaving | Assumed Interleaving (38.211-7.3.2.2) |
L (REG Bundle Size) | 6 (38.211-7.3.2.2) |
R (Interleaver Size) | 2 (38.211-7.3.2.2) |
n_shift (Shiftindex) | N_cellID (38.211-7.3.2.2) |
Cyclic Prefix | Normal (38.211-7.3.2.2) |
Precoding | Same Precoding used in REG Bundle (38.211-7.3.2.2) |
What is Search Space ?
Search Space is an area within a CORESET that UE should monitor to detect a specific PDCCH/DCI. There are two large categories of Search Space(SS) called CSS (Common Search Space) and USS(UE specific Search Space). Which SearchSpace UE has to monitor is defined by RNTI type or RRC configuration summarized below. This summary is based on 38.213-10.1
SS Type | PDCCH Type | RRC Configuration | RNTI Type |
CSS | pdcch-ConfigSIB1 in MIB searchSpaceSIB1 in PDCCHConfigCommon searchSpaceZero in PDCCH-ConfigCommon | SI-RNTI | |
Type0A-PDCCH | searchSpaceOtherSystemInformation in PDCCH-ConfigCommon | SI-RNTI | |
ra-SearchSpace in PDCCH-ConfigCommon | RA-RNTI,TC-RNTI | ||
Type2-PDCCH | pagingSearchSpace in PDCCH-ConfigCommon | P-RNTI | |
Type3-PDCCH | SearchSpace in PDCCH-Config with searchSpaceType = common | INT-RNTI, SFI-RNTI, TPC-PUSCH-RNTI, TPC-PUCCH-RNTI, TPCSRS-RNTI, C-RNTI, MCS-C-RNTI, or CS-RNTI | |
USS | SearchSpace in PDCCH-Config with searchSpaceType = ue-Specific | C-RNTI, MCS-C-RNTI, SP-CSI-RNTI,CS-RNTI |
How many bits can be carried by a Search Space ?
The answer .. it depends on the size of the SearchSpace. The size of a search space is determined by aggregation level. As in LTE, there are multiple different types of aggregation level, the size of each aggregation level in the unit of CCE is defined in 3GPP as shown below.
< 38.211-Table 7.3.2.1-1: Supported PDCCH aggregation levels. >
Aggregation Level | Number of CCEs |
1 | 1 |
2 | 2 |
4 | 4 |
8 | 8 |
16 | 16 |
Now the question is how big is a search space in the unit of 'bits', not in the unit of CCE. To get the answer for this, we need to understand the detailed resource element structure and some calculation. I found a good note written by Naveen Chelikani and he kindly allowed me for me to share his writing here.
- Number of CCE = 1 (6 REG)
- Size of 1 REG in RE = 12
- Total Number of available RE = 12 subcarriers x 1 symbols x 6 REG = 72
- Total number of available PDCCH RE = 72 - 18 = 54 (18 REs are used for DMRS)
- Total number of available bits for the aggregation level = 54 x 2 = 108 bits (2 comes from bits / QPSK)
- Number of CCE = 2 (12 REG)
- Size of 1 REG in RE = 12
- Total Number of available RE = 12 subcarriers x 1 symbols x 12 REG = 144
- Total number of available PDCCH RE = 144 - 36 = 108 (36 REs are used for DMRS)
- Total number of available bits for the aggregation level = 108 x 2 = 216 bits (2 comes from bits / QPSK)
- Number of CCE = 4 (24 REG)
- Size of 1 REG in RE = 12
- Total Number of available RE = 12 subcarriers x 1 symbols x 24 REG = 288
- Total number of available PDCCH RE = 288 - 72 = 216 (72 REs are used for DMRS)
- Total number of available bits for the aggregation level = 216 x 2 = 432 bits (2 comes from bits / QPSK)
- Number of CCE = 8 (48 REG)
- Size of 1 REG in RE = 12
- Total Number of available RE = 12 subcarriers x 1 symbols x 48 REG = 576
- Total number of available PDCCH RE = 576 - 144 = 432 (144 REs are used for DMRS)
- Total number of available bits for the aggregation level = 432 x 2 = 864 bits (2 comes from bits / QPSK)
- Number of CCE = 16 (96 REG)
- Size of 1 REG in RE = 12
- Total Number of available RE = 12 subcarriers x 1 symbols x 96 REG = 1152
- Total number of available PDCCH RE = 1152 - 288 = 864 (288 REs are used for DMRS)
- Total number of available bits for the aggregation level = 864 x 2 = 1728 bits (2 comes from bits / QPSK)
Aggregation Level 1
Aggregation Level 2
Aggregation Level 4
Aggregation Level 8
Aggregation Level 16
How many CORESET and SearchSpaces in a Channel Band ?
The number of CORESETs within a Channel Band (CBW) depends on how many CORESET/SearchSpaces are configured in a BWP and how many BWPs are configured in the CBW. Followings are ASN structure that I summarized with focus on CORESET/SearchSpace in ENDC.
How many RBs do you need for CORESET ?
The answer to this question is dependent on following factors as follows :
- What is the maximum number of DCIs/PDCCHs do you want to allow to send in a slot ? ==> This is determined by the none zero value (i.e, the value other than n0) in SearchSpace.nrofCandidates as shown below.
- How large search space you want to allocate for each DCI/PDCCH ? ==> this is determined by the aggregationLevel with the none zero numbers in SearchSpace parameter.
- How many RBs you want to allocate for each REG/CCE ? ==> This is determined by reg-BundleSize (CCE Size) in ControlResourceSet parameter
- How many number of OFDM symbols you want allocate for CORESET ? ==> This is determined by 'duration' in ControlResourceSet parameter
SearchSpace ::= SEQUENCE {
...
nrofCandidates SEQUENCE {
aggregationLevel1 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8},
aggregationLevel2 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8},
aggregationLevel4 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8},
aggregationLevel8 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8},
aggregationLevel16 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8}
} OPTIONAL, -- Cond Setup
...
}
ControlResourceSet ::= SEQUENCE {
...
duration INTEGER (1..maxCoReSetDuration),
//maxCoReSetDuration = 3
cce-REG-MappingType CHOICE {
interleaved SEQUENCE {
reg-BundleSize ENUMERATED {n2, n3, n6},
...
},
...
},,
...
}
Example 01 >
Number of DCI/PDCCH = 1
Size of a SearchSpace Candidates (AggregationLevel) = 16
Number of SearchSpace Candidates = 1
Number of OFDM Symbols for CORESET = 1
Then minimum number of PRB would be 16 CCE(=16 x 6=96 PRB) within one OFDM symbol and a possible RRC Setting would be as follows.
SearchSpace ::= SEQUENCE {
...
nrofCandidates SEQUENCE {
aggregationLevel1 n0,
aggregationLevel2 n0,
aggregationLevel4 n0,
aggregationLevel8 n0,
aggregationLevel16 n1
} OPTIONAL, -- Cond Setup
...
}
ControlResourceSet ::= SEQUENCE {
...
frequencyDomainResources 11111111111111110000....
duration 1,
cce-REG-MappingType CHOICE {
interleaved SEQUENCE {
reg-BundleSize n6,
...
},
...
},,
...
}
UE Cappability
Phy-ParametersFRX-Diff ::= SEQUENCE {
....
multipleCORESET ENUMERATED {supported} OPTIONAL,
...
}
multipleCORESET : Indicates whether the UE supports configuration of more than one PDCCH CORESET per BWP in addition to the CORESET with CORESET-ID 0 in the BWP. It is mandatory with capability signaling for FR2 and optional for FR1.
Reference
[1] 3GPP TSG RAN WG1Meeting NR-AH#3 : R1-1716542 Configuration of CORESET and search space design
[2] 3GPP TSG RAN WG1 Meeting NR#3 : R1-1716564 - Discussion on the CORESET configuration
[3] 3GPP TSG RAN WG1 Meeting NR#3 : R1-1716477 Frequency-first REG bundling for multi-symbol CORESETs
[4] 3GPP TSG RAN WG1 Meeting NR#3 : R1-1716475 Remaining issues related to CORESET configuration
[5] 3GPP TSG RAN WG1 Meeting NR #3 : R1-1716044 Common CORESET design for RMSI scheduling
[6] 3GPP TSG RAN WG1 Meeting NR#3 : R1-1715842 RMSI delivery and CORESET configuration
[7] Understanding the Heart of the 5G Air Interface: An Overview of Physical Downlink Control Channel for 5G New Radio (NR)
- by Kazuki Takeda‡, Huilin Xu‡, Taehyoung Kim§, Karol Schober∧, and Xingqin Lin#
‡Qualcomm Inc., §Samsung Electronics,∧Nokia, #Ericsson Inc.
No comments:
Post a Comment
If You have any concern you are free to message/comment me.