CORESET & Search Spaces in 5G NR

1. The Bootstrapping Problem: Why Control Resources Come First

Almost everything in NR is scheduled. A UE receives downlink data because a DCI told it to; it transmits uplink data because a DCI granted it resources. The DCI arrives on PDCCH. So the first question any UE must answer, before it can participate in the cell at all, is: where in the resource grid is PDCCH, and when should I look?

That question cannot be answered by a grant, because a grant is the thing being looked for. It has to be answered by configuration, and the configuration has to arrive by a path that does not itself require a grant. NR solves this in three stages, each one bootstrapping the next:

Table 1. The three-stage bootstrap. Each stage's PDCCH configuration is delivered on a channel that the previous stage's PDCCH configuration made receivable.

The consequence is worth stating plainly, because it shapes every diagnosis in this document. A UE that cannot find PDCCH has no way to tell anyone. There is no negative acknowledgement for a missed monitoring occasion, no counter the UE reports, no measurement that captures it. The uplink itself depends on a grant. What the network sees is silence, and silence is indistinguishable from a UE that has gone away. This is why a misconfigured CORESET or search space presents as an unresponsive UE in perfect radio conditions, and why the fault is so often chased in the wrong layer.

1.1 What invokes this machinery

CORESET and search space configuration is re-evaluated, in whole or in part, at every one of these events -- which is a longer list than most readers expect, and each entry is a place where a stale or inconsistent configuration can take effect:

• Initial cell selection, from pdcch-ConfigSIB1 in the MIB.
• SIB1 acquisition, which installs PDCCH-ConfigCommon for the initial DL BWP.
• RRC setup, resume or reestablishment, which installs PDCCH-Config for each configured dedicated BWP.
• Any BWP switch -- by DCI BWP indicator, by bwp-InactivityTimer expiry, or by RRC. The CORESETs and search spaces of the new BWP replace those of the old one wholesale; nothing carries over. See the companion 02 Radio Frame Structure document for the BWP machinery.
• SCell addition or activation, each of which brings its own PDCCH-Config per BWP; cross-carrier scheduling changes which cell's CORESET carries which cell's grants (companion 29 Carrier Aggregation).
• Handover, where the target cell's PDCCH-Config arrives inside reconfigurationWithSync and takes effect at the same moment as the new C-RNTI.
• Search space group switching (Rel-16), which flips the UE between two sets of search spaces without an RRC message.
• Beam failure recovery, after which the CORESET's TCI state may be updated by MAC CE while the CORESET itself is unchanged.

2. The Unit Hierarchy: REG, REG Bundle and CCE

PDCCH is not allocated in resource elements, and not in resource blocks either. It is allocated in control channel elements, and a CCE is built from smaller units in a fixed hierarchy that every other number in this document depends on.

Table 2. The hierarchy, bottom to top. The DMRS fraction is fixed at one RE in four within every REG, which is why the usable-bits arithmetic in §11 uses 9 rather than 12 REs per REG.

2.1 The two arithmetic facts worth memorising

Because a CORESET's CCE count is N_PRB x duration / 6, the same CCE capacity can be bought in two shapes: wide and short, or narrow and long. They are not equivalent. A wide, one-symbol CORESET gives each CCE more frequency diversity and leaves symbols 1 and 2 free for PDSCH, but it forces the UE to buffer and process the whole carrier bandwidth in symbol 0. A narrow, three-symbol CORESET concentrates the control region in a small part of the band -- convenient for a beamformed FR2 cell -- but it delays the earliest possible PDSCH start to symbol 3 and caps the frequency diversity any single CCE can obtain.

3. ControlResourceSet, Field by Field

ControlResourceSet is a small IE -- nine fields, three of them optional -- and every one of them changes something observable. It appears in three places: controlResourceSetZero (as an index, not a structure), commonControlResourceSet inside PDCCH-ConfigCommon, and controlResourceSetToAddModList inside PDCCH-Config.

Table 3. ControlResourceSet, TS 38.331. The interleaved branch's three fields are absent when nonInterleaved is chosen -- they are inside the CHOICE, not siblings of it.

4. frequencyDomainResources: The 45-Bit Bitmap, Decoded

frequencyDomainResources is the single field most often mis-read, because three separate things about it are non-obvious: the granularity is six PRBs and not one, the bit order is most-significant-first, and the reference point is the bandwidth part rather than the carrier.

• Granularity: each bit enables a group of six consecutive PRBs. 45 bits x 6 PRBs = 270 PRBs, which covers the widest NR carrier (275 PRBs) to within one partial group.
• Order: the first, left-most, most significant bit corresponds to the lowest-frequency group. This is the opposite of the intuition most engineers bring from hex dumps, where bit 0 is the LSB.
• Reference point: grouping starts from the first RB group of the bandwidth part in which the CORESET is configured TS 38.331, `ControlResourceSet` field description. For CORESET#0 the reference is the lowest RB of CORESET#0 itself, since no wider BWP exists yet.
• Constraint: bits corresponding to a group not fully contained in the BWP must be set to zero. A CORESET therefore cannot start at an arbitrary PRB, and cannot straddle the BWP edge.

4.1 The decode, step by step

Nothing in the encoding requires the set bits to be contiguous. A bitmap of 0x21 00 00 00 00 00 -- b2 and b7 set -- gives a CORESET of two disjoint 6-PRB islands, 30 PRBs apart. That is legal and occasionally deliberate: it buys frequency diversity for a non-interleaved CORESET without widening the total allocation. It also makes the CCE count arithmetic (12 PRBs x duration / 6) easy to get wrong by eye, because the CORESET looks wider than it is.

4.2 Why groups of six

Six is not arbitrary. A CCE is six REGs, and at duration = 1 a CCE is therefore exactly six PRBs. Making the frequency granularity six PRBs guarantees that a one-symbol CORESET always contains a whole number of CCEs, with no remainder REGs to define away. At duration 2 and 3 the same bitmap yields 12 and 18 REGs per bit respectively, both multiples of six, so the property holds for every legal duration. It is also why a 45-bit bitmap suffices for a 275-PRB carrier: the last two PRBs of the widest carrier cannot form a full group, and are simply not addressable as control resources.

5. CCE-to-REG Mapping: Interleaved and Non-Interleaved

Having decided which REGs belong to the CORESET, something must say which of them make up CCE 0, which make up CCE 1, and so on. cce-REG-MappingType is that something, and the choice between its two branches is one of the few genuinely consequential PDCCH decisions a planner makes.

5.1 Why interleaving exists at all

Every other physical channel in NR can be adapted to the channel. PDSCH gets an MCS chosen from CSI feedback; PUSCH gets an MCS and a power command from measured SINR; even PUCCH has a closed power loop. PDCCH has none of that at the moment it matters. The gNB must transmit the grant before the UE has said anything about this slot, and in the worst case -- initial access, or a UE that has been silent through DRX -- before it has said anything at all. The only protections available are coding gain (more CCEs, §11) and frequency diversity.

Interleaving buys the second one. If a CCE's six REGs sit in six adjacent PRBs and the channel has a notch there, the whole CCE is lost and no amount of aggregation within that notch helps. Spread the same six REGs across the CORESET's whole bandwidth in bundles and a notch damages a fraction of the CCE, which the channel code can absorb. This is the same argument as frequency-hopping for PUSCH, applied to a channel that cannot hop because it has no feedback loop to hop away from anything.

5.2 The interleaver, computed by hand

The mapping is a block interleaver on bundle indices, followed by a cyclic shift TS 38.211 cl. 7.3.2.2:

Bundles:   N_bundle = N_REG / L          L = reg-BundleSize
Columns:   C        = N_REG / (L * R)    R = interleaverSize

f(x) = ( r*C + c + n_shift )  mod  N_bundle
  where x = c*R + r,   r = 0..R-1,   c = 0..C-1

CCE j is made of bundles  f(6j/L), f(6j/L + 1), ... , f(6j/L + 6/L - 1)

  n_shift = shiftIndex if present, else the physical cell identity
  6/L = bundles per CCE:  3 at L=2,  2 at L=3,  1 at L=6

5.3 Choosing between them

Table 4. The trade is diversity against selectivity, and the deciding question is whether the gNB knows anything useful about this UE's channel at the moment it must send the DCI.

6. Precoder Granularity, DMRS Scrambling and Beam Indication

6.1 precoderGranularity

PDCCH is demodulated from its own DMRS, carried in three of every twelve REs of every REG. Three pilots per REG is not many, so the UE wants to average across as many REGs as it legitimately can -- and the constraint on legitimately is that averaging is only valid where the transmitted precoder is constant. precoderGranularity is the network telling the UE how wide that span is:

Table 5. precoderGranularity, TS 38.211 cl. 7.3.2.2 and TS 38.214. With allContiguousRBs the UE may additionally assume the DMRS is present in every RB of the contiguous span, including RBs carrying no PDCCH for it -- which is where the extra pilots come from.

The pairing matters more than either value alone. allContiguousRBs with nonInterleaved mapping is a coherent design: one precoder, one contiguous CORESET, maximum pilot averaging, and the gNB steering the whole control region as a unit -- exactly what an FR2 cell with analogue beamforming wants. allContiguousRBs with interleaved mapping is legal but self-defeating: you have asked the UE to assume a constant precoder across a span while deliberately scattering each CCE across that same span, so you pay the diversity cost of interleaving and give up the beamforming freedom you interleaved to exploit.

6.2 pdcch-DMRS-ScramblingID

The PDCCH DMRS sequence is a pseudo-random sequence initialised from pdcch-DMRS-ScramblingID (0..65535) when the field is present, and from the physical cell identity when it is absent. Two facts follow, and both show up in diagnosis:

• It is a CORESET-level parameter, not a cell-level one. Two CORESETs in the same cell may use different scrambling ids, and CORESET#0 always uses the physical cell identity because there is nowhere to configure anything else.
• A mismatch is total, not gradual. Channel estimation using the wrong pilot sequence does not produce a degraded estimate; it produces noise. Every PDCCH in that CORESET fails, at every aggregation level, regardless of SINR. There is no partial failure mode.

6.3 tci-StatesPDCCH-ToAddList

In FR2, and increasingly in FR1 with many-antenna arrays, a CORESET is not received omnidirectionally -- it arrives on a beam, and the UE has to point its own receive beam at it. tci-StatesPDCCH-ToAddList gives the list of TCI state identities that may be activated for the CORESET; the active one is then chosen by a TCI States Indication for UE-specific PDCCH MAC CE TS 38.321 cl. 6.1.3.15, which is a MAC control element and not an RRC message.

Table 6. Beam indication on a CORESET. The configuration is RRC; the selection is MAC; the consequence is physical.

7. CORESET#0: The One You Get Before You Know Anything

CORESET#0 is the exception to everything in §3 and §4. It is not configured by a ControlResourceSet IE, it does not have a frequencyDomainResources bitmap, and its controlResourceSetId of 0 cannot be used by anything else. It exists because of the bootstrap problem in §1: the UE must monitor a PDCCH to receive SIB1, and SIB1 is where PDCCH configuration lives.

What the UE has instead is eight bits in the MIB. pdcch-ConfigSIB1 is a SEQUENCE of two INTEGER (0..15) fields: controlResourceSetZero and searchSpaceZero. Four bits index a row of a lookup table in TS 38.213 clause 13, selected by the SSB and CORESET#0 subcarrier spacing pair and the frequency range; the row gives the multiplexing pattern, the number of resource blocks, the number of symbols and the RB-level offset from the SSB. The other four bits index a second table giving the monitoring occasion in time. The companion 18 MIB and SIB1 IEs document owns the decode of pdcch-ConfigSIB1 and the table lookups; this section covers what the resulting CORESET is.

Table 7. CORESET#0 against a configured CORESET. Everything that would normally be a field is either a table lookup or a fixed value, because there is nowhere to signal it.

7.1 The multiplexing patterns

The table row also gives one of three SS/PBCH block and CORESET multiplexing patterns, which decide how the SSB and CORESET#0 share time and frequency TS 38.213 cl. 13:

Table 8. Multiplexing patterns. Pattern 1 is what almost every FR1 deployment uses; patterns 2 and 3 exist because at FR2 numerologies a TDM arrangement would cost too many symbols.

7.2 Why CORESET#0 keeps mattering after SIB1

It is tempting to treat CORESET#0 as scaffolding that gets discarded once dedicated configuration arrives. It does not. CORESET#0 remains the CORESET used for Type0-PDCCH in the initial DL BWP, which means it remains in use for SI acquisition and SI change monitoring; if the UE-specific configuration does not include a common search space for paging, it remains in use for paging as well. And because its controlResourceSetId is 0, it is by definition the lowest-id CORESET, which makes it the source of the default QCL assumption described in §6.3. A CORESET#0 that has become unreceivable therefore takes more with it than SIB1.

8. How Many CORESETs, and Where They Are Scoped

The counting rules are simple to state and easy to get wrong, because the two limits that apply have different scopes.

Table 9. The two scopes. Ids are unique per cell; the monitoring limits are per bandwidth part, so a cell with four BWPs may legally define more CORESETs than any one BWP can use.

The important asymmetry is this: controlResourceSetId is unique within the cell, but a CORESET is only usable in the BWP whose PDCCH-Config contains it. A dedicated CORESET is configured inside BWP-DownlinkDedicated -> pdcch-Config -> controlResourceSetToAddModList, so it belongs to that BWP. Two BWPs may each define a CORESET with id 2, and they are different CORESETs with different geometry. A search space in BWP 1 referring to controlResourceSetId 2 gets BWP 1's version, always.

8.1 The common CORESET

PDCCH-ConfigCommon may carry a single commonControlResourceSet, which is a full ControlResourceSet with an id in 1..11 -- never 0. Its purpose is to give the common search spaces a CORESET that is not CORESET#0, which matters in two situations: when the active BWP is not the initial BWP and CORESET#0 is outside it, and when the operator wants common signalling on a wider or better-placed control region than CORESET#0's table-derived geometry allows. It counts against the three-CORESETs-per-BWP budget.

8.2 What happens at a BWP switch

At a BWP switch the entire set of CORESETs and search spaces is replaced by the new BWP's set. This is not a merge and there is no inheritance: a CORESET configured only in BWP 1 does not exist while BWP 2 is active. Two practical consequences follow. First, every BWP that a UE can be switched into needs a complete, self-sufficient PDCCH-Config -- including a search space capable of carrying the DCI that would switch the UE back out again. Second, the switch is not instantaneous: the BWP switch delay TS 38.133 cl. 8.6 is a window during which the UE monitors neither BWP's CORESETs, and any DCI the gNB sends into that window is lost.

9. SearchSpace, Field by Field

If the CORESET is the where, the SearchSpace IE is the when and the how hard. It is the larger of the two IEs and the one with more ways to be quietly wrong, because most of its fields are optional and the defaults are not always what a reader assumes.

Table 10. SearchSpace, TS 38.331. nrofCandidates and searchSpaceType are the two fields that most often differ between what a planner intended and what the UE received.

9.1 The searchSpaceType CHOICE

searchSpaceType is a CHOICE with two branches, and each branch carries its own sub-structure declaring which DCI formats to expect. This is not decoration: the declared formats fix the DCI sizes the UE will attempt, and a UE does not attempt a size it has not been told to expect.

searchSpaceType CHOICE {
    common SEQUENCE {
        dci-Format0-0-AndFormat1-0 SEQUENCE { ... }        OPTIONAL,
        dci-Format2-0 SEQUENCE {                           -- SFI
            nrofCandidates-SFI SEQUENCE {
                aggregationLevel1  ENUMERATED {n1,n2}      OPTIONAL,
                aggregationLevel2  ENUMERATED {n1,n2}      OPTIONAL,
                aggregationLevel4  ENUMERATED {n1,n2}      OPTIONAL,
                aggregationLevel8  ENUMERATED {n1,n2}      OPTIONAL,
                aggregationLevel16 ENUMERATED {n1,n2}      OPTIONAL
            }, ...
        }                                                  OPTIONAL,
        dci-Format2-1 SEQUENCE { ... }                     OPTIONAL,
        dci-Format2-2 SEQUENCE { ... }                     OPTIONAL,
        dci-Format2-3 SEQUENCE { ... }                     OPTIONAL,
        dci-Format2-4-r16 SEQUENCE { ... }                 OPTIONAL,
        dci-Format2-5-r16 SEQUENCE { ... }                 OPTIONAL,
        dci-Format2-6-r16 SEQUENCE { ... }                 OPTIONAL,
        ...
    },
    ue-Specific SEQUENCE {
        dci-Formats ENUMERATED {formats0-0-And-1-0, formats0-1-And-1-1},
        ...
    }
}

Listing 1. Abridged from TS 38.331 SearchSpace. Each dci-Format2-x branch is present only if that group-common DCI is to be monitored in this search space; ... marks omitted members and extension markers.

Table 11. What each branch causes the UE to look for. A DCI the search space does not declare is not decoded even if it is transmitted perfectly -- the UE never attempts that size.

10. The Search Space Types: Type0 to Type3 and UE-Specific

There are two different numbering systems in play and they do not match, which is the single largest source of confusion in this area. TS 38.213 clause 10.1 defines search space types -- Type0-PDCCH, Type0A-PDCCH, Type1-PDCCH, Type2-PDCCH, Type3-PDCCH and the UE-specific search space -- as roles. TS 38.331 defines searchSpaceType as an ASN.1 CHOICE with two branches. Type0 through Type3 all encode as common. The type number appears nowhere in the RRC message.