CORESET in a Nutshell

PDCCH has to be found before anything else can happen, and the UE has to find it without being told where it is. A CORESET is the region the network sets aside for that search. The box below states what it is made of, and the sections after it take the structure apart one level at a time.

CORESET in Detail

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 Region
• Parameters for CORESET / Structure of CORESET
• Example
• A Special Coreset : CORESET 0
• What 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 ?
• Example
• UE Cappability
• Reference
• UE 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.

Two bounds are worth carrying forward from the listing further down. A CORESET is identified by a number rather than by its position, and the count of them is limited per serving cell rather than per bandwidth part.

• The identifier is small on purpose : ControlResourceSetId is INTEGER (0..maxNrofControlResourceSets-1), and that constant is 12. A serving cell holds at most twelve.
• Release 16 extended the range : ControlResourceSetId-v1610 continues above the original ceiling. A cell can therefore hold more than Release 15 allowed.
• The frequency bitmap is coarse, not per block : frequencyDomainResources is BIT STRING (SIZE (45)). One bit stands for a group of six resource blocks.
• Duration is at most three symbols : duration is INTEGER (1..maxCoReSetDuration) and that constant is 3.

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

The drawing above shows where the two differ in shape. What it cannot show is where the information comes from, and that is the second difference. LTE carried its control region size on a physical channel of its own, and NR carries the whole description in RRC.

• LTE signalled the duration in every subframe : the control format indicator arrived on PCFICH. The UE learned the region size by decoding a channel before it.
• NR signals the region once, in RRC : frequencyDomainResources and duration arrive in ControlResourceSet and stay until they are reconfigured.
• LTE had no frequency parameter to signal : the control region always spanned the whole channel bandwidth, so there was nothing to describe.
• The NR region is bounded by the bandwidth part : a CORESET sits inside one. A UE never has to receive outside the part it is configured for.

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

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.

The RRC parameters defining the CORESET are as follows. The listing below is the current one, and three of its fields changed after the Release 15 form this page originally carried.

Following is based on 38.331 v19.3.0 (Release 19)

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)   OPTIONAL   -- Need S
        },
        nonInterleaved                      NULL
    },
    precoderGranularity                 ENUMERATED {sameAsREG-bundle, allContiguousRBs},
    tci-StatesPDCCH-ToAddList           SEQUENCE(SIZE (1..maxNrofTCI-StatesPDCCH)) OF TCI-StateId  OPTIONAL,   -- Cond NotSIB-initialBWP
    tci-StatesPDCCH-ToReleaseList       SEQUENCE(SIZE (1..maxNrofTCI-StatesPDCCH)) OF TCI-StateId  OPTIONAL,   -- Cond NotSIB-initialBWP
    tci-PresentInDCI                    ENUMERATED {enabled}                              OPTIONAL,   -- Need S
    pdcch-DMRS-ScramblingID             INTEGER (0..65535)                                OPTIONAL,   -- Need S
    ...,
    [[
    rb-Offset-r16                       INTEGER (0..5)                                    OPTIONAL,   -- Need S
    tci-PresentDCI-1-2-r16              INTEGER (1..3)                                    OPTIONAL,   -- Need S
    coresetPoolIndex-r16                INTEGER (0..1)                                    OPTIONAL,   -- Need S
    controlResourceSetId-v1610          ControlResourceSetId-v1610                        OPTIONAL    -- Need S
    ]],
    [[
    followUnifiedTCI-State-r17          ENUMERATED {enabled}                              OPTIONAL    -- Need R
    ]],
    [[
    applyIndicatedTCI-State-r18         ENUMERATED {first, second, both,  none}           OPTIONAL    -- Cond FollowUTCI
    ]]
}

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

The single field above became a pair after Release 15. The listing now carries tci-StatesPDCCH-ToAddList and tci-StatesPDCCH-ToReleaseList, which is the add and release form used throughout 38.331. Both are conditional on the CORESET not being the one from SIB1 in the initial bandwidth part.

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. The drawing below carries the whole chain in one picture. It runs from the bandwidth part down to the numbered REGs, and then to the table that turns them into CCEs.

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.

CORESET 0 is needed before RRC exists, and that circularity has a specific solution. CORESET 0 is described by a four bit index rather than by a set of parameters, and the index is small enough to fit in the MIB.

• The whole configuration is one number : ControlResourceSetZero is INTEGER (0..15), so sixteen codepoints cover every CORESET 0 a network may use.
• The index expands through a table, not through RRC : each codepoint maps to a bandwidth, a duration and an offset. The UE can therefore build the CORESET before any dedicated configuration exists.
• It belongs to the initial bandwidth part only : controlResourceSetZero sits in PDCCH-ConfigCommon, marked Cond InitialBWP-Only. It cannot be configured elsewhere.
• A search space arrives with it : searchSpaceZero is carried the same way and under the same condition. A CORESET with nothing monitoring it would be useless.

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

NOTE : For the concept of all search space and comparision among different types of search space, refer to this note.

A search space is configured separately from the CORESET it uses, and the two are joined by an identifier. That separation lets several search spaces share one region, each monitoring it on a different schedule.

• A search space names its CORESET : SearchSpace carries controlResourceSetId. The region and the schedule for searching it are two objects, not one.
• Forty of them fit in a serving cell : SearchSpaceId is INTEGER (0..maxNrofSearchSpaces-1), and maxNrofSearchSpaces-1 is 39.
• The type is a CHOICE, not a flag : searchSpaceType selects between common and ue-Specific, and the common arm names the DCI formats it covers.
• Candidates are counted per aggregation level : nrofCandidates gives a separate count for levels 1, 2, 4, 8 and 16, and each may be n0.

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

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.

Aggregation Level 1

• 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)

Aggregation Level 2

• 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)

Aggregation Level 4

• 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)

Aggregation Level 8

• 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)

Aggregation Level 16

• 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)

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.

CORESETs are configured per bandwidth part, in two places each. The cell total is the per part limit across the parts, capped by the serving cell bound.

The tree above answers the question by counting the places a CORESET can be configured. Read each leaf as a limit on one bandwidth part, and remember that a serving cell carries several bandwidth parts.

• The common configuration holds one CORESET : commonControlResourceSet in PDCCH-ConfigCommon is a single ControlResourceSet, not a list.
• The common configuration holds four search spaces : commonSearchSpaceList is SEQUENCE (SIZE(1..4)) OF SearchSpace.
• The dedicated configuration holds three and ten : controlResourceSetToAddModList is SIZE (1..3) and searchSpacesToAddModList is SIZE (1..10).
• Release 16 added two more dedicated CORESETs : controlResourceSetToAddModListSizeExt-v1610 is SIZE (1..2). A bandwidth part can reach five, not the three the drawing shows.
• The serving cell total is the real ceiling : maxNrofControlResourceSets is 12 and maxNrofSearchSpaces is 40 for the whole serving cell, however the parts are divided.
• Configured is not the same as monitored : a UE has one active downlink bandwidth part at a time. It searches only the CORESETs on that part.
• The initial part is counted separately : the tree gives InitialDownlinkBWP its own pdcch-ConfigCommon and pdcch-Config, beside the added parts.

How many RBs do you need for CORESET ?

The answer to this question is dependent on following factors as follows : Each factor multiplies the one before it, so the four together fix the smallest CORESET that can carry the traffic. The example after them works the arithmetic through with numbers.

• 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

Following is based on 38.331 v19.3.0 (Release 19)

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

Following is based on 38.331 v19.3.0 (Release 19)

ControlResourceSet ::=              SEQUENCE {
    ...
    duration                            INTEGER (1..maxCoReSetDuration),          -- maxCoReSetDuration = 3
    cce-REG-MappingType                 CHOICE {
        interleaved                         SEQUENCE {
            reg-BundleSize                      ENUMERATED {n2, n3, n6},
            ...
        },
        ...
    },
    ...
}

Example 01 >

The four factors above are given values here, and the smallest workable CORESET follows from them. The case is deliberately the most demanding one. A single candidate at the largest aggregation level needs the most resource blocks.

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.

Illustrative configuration for this example. The values are chosen to make the arithmetic concrete, and this is not specification text.

SearchSpace {
    ...
    nrofCandidates {
        aggregationLevel1                       n0,
        aggregationLevel2                       n0,
        aggregationLevel4                       n0,
        aggregationLevel8                       n0,
        aggregationLevel16                      n1
    }                                                                           OPTIONAL,   -- Cond Setup
    ...
}

Illustrative configuration for this example. The values are chosen to make the arithmetic concrete, and this is not specification text.

ControlResourceSet {
    ...
    frequencyDomainResources            11111111111111110000....
    duration                            1,
    cce-REG-MappingType                 interleaved {
            reg-BundleSize                      n6,
            ...
    },
    ...
}

UE Cappability

Not every CORESET arrangement can be assumed. Configuring more than one CORESET on a bandwidth part is a capability the UE reports, so a network that has not read the capability cannot rely on it. The listing below is the field that carries the report.

Following is based on 38.331 v19.3.0 (Release 19)

Phy-ParametersFRX-Diff ::=          SEQUENCE {
    ...
    multipleCORESET                     ENUMERATED {supported}                            OPTIONAL,
    ...,
    [[
    -- Release 17, the same capability reported separately by a RedCap UE
    multipleCORESET-RedCap-r17          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.

One field decides whether the arrangement in the section above is available at all. The capability is reported per frequency range, which is why it sits in the FRX-Diff structure rather than in the common one.

• The capability is about the count, not the feature : multipleCORESET reports whether more than one CORESET per bandwidth part is supported.
• It is reported per frequency range : the field sits in Phy-ParametersFRX-Diff, so a UE can support it on one frequency range and not on another.
• Release 17 gave RedCap its own field : multipleCORESET-RedCap-r17 reports the same capability separately. A reduced capability UE is not assumed to match a normal one.
• Absent means one : the field is OPTIONAL. A UE that does not report it gets the single common CORESET only.

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.