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

CORESET 0 and SIB1 Scheduling in Detail

Type 0 PDCCH Common Search Space is a subset of NR PDCCH Search Space that is dedicated to transmit the PDCCH for SI message (SIB). Therefore, what I am going to explain on this page is related to transmitting/decoding SIB1 in SA(Standalone) mode.

•   Why we need a special procedure ?
•   Basic Questions
•   RRC Parameters defining CORESET 0
•   Example 01 >  pdcch-ConfigSIB1 = 0 (INTEGER). SSB SCS = 30 Khz, PDCCH SCS = 30 Khz
•   CORESET 0 Position in Time Domain
•   CORESET 0 Position in Frequency Domain
• Example 01 > SSB/PDCCH SCS = {30,30}, Index 10 in Table 13-4
• Example 02 > SSB/PDCCH SCS = {30,30}, Index 11 in Table 13-4
• Example 03 > SSB/PDCCH SCS = {30,30}, Index 12 in Table 13-4
•   CORESET 0 Transmission Slots
• Example 01 >  SSB/PDCCH SCS = {30,30}, SSB Index = 0, Table 13-11 = 4
• Example 02 > n0 , SSB/PDCCH SCS = {30,30}, SSB Index = 0, Table 13-11
• Example 03 >  SFNc , SSB/PDCCH SCS = {30,30}, SSB Index = 0, Table 13-11
• Example 04 >  SFNc for SSB/PDCCH SCS = {30,30}, Varrying SSB index, O/N Index in Table 13-11 = 4
• Example 05 >  n0 for SSB/PDCCH SCS = {30,30}, Varrying SSB index, O/N Index in Table 13-11 = 4
•   CORESET 0 Aggregation Level
•   Whole Table
•   Visual Summary
• Tips for CORESET0  Index Selection
• Time Domain Resource Allocation for SIB1 PDSCH
• Get the Test Procedure and Log / Amarisoft TechAcademy

Why we need a special procedure ?

SIB1 is carried by a PDSCH like any other user data (or other Over The Air message : OTA). Then, why we need a special algorithm for transmitting and decoding a PDSCH carrying SIB1 ?

Before answering the question, let's briefly summarize a mechanism in which other user data or downlink OTA message is scheduled and decoded. It goes as follows.

i) network defines a specific physical resources for transmitting DCI (CORESET)

ii) network defines a specific set of candidate physical resources that UE has to monitor (Search Space) to find scheduling information

iii) network defines a list of symbol allocation (TimeDomainResourceAllocation) for PDSCH

iv) Network notifies UE of all of these configuration information via RRC message (like SIB1, RRCSetup or RRCReconfiguration)

v) When the network want to send a specific PDSCH, it sends a DCI and transmits PDSCH as scheduled in the DCI.

The keyword for this process is RRC message. In case of user data or other OTA message, PDSCH is transmitted after all the detailed configuration information is informed to UE. But SIB1 transmission/decoding should happen before any RRC message is delivered to UE. The only RRC message delivered to UE before SIB1 transmission is MIB message. As you know, MIB can carry only a handful of information.. not enough space to carry all the detailed information mentioned above. Then how can UE figure out all the detailed information at this point ? A common technique to handle this kind of situation (i.e, letting UE know of the long/detailed information without relying on a lengthy RRC message) is to use some predefined table (predefined configuration) and algorithm known to both UE and NW by the specification. This is the basic idea of transmitting and decoding SIB1 in NR.

3GPP defined many of predefined tables and algorithms to process it and a few information elements in MIB specifies which of the predefined table should be used.

Basic Questions.

This process is very complicated and confusing. It would be good idea to have a set of clear questions in your mind. Followings are my own version of the questions that I have before reading the details.

• How Can we figure out physical resources for the CORESET ?  : How can we figure out how many RBs and OFDM symbols are assigned for the CORESET ? you can figure this out from controlResourceSetZero parameter expained in RRC Parameters defining CORESET 0 and CORESET 0 position in frequency domain. This plays the same role as coreset definition parameters in RRC message that is explained here.
• How Can we figure out which OFDM symbols to monitor to search the CORESET ? : You can figure it out from from searchSpaceZero parameter expained in RRC Parameters defining CORESET 0. More specifically, the first symbol index in table 13-11,13-12,13-13,13-14 tells you the starting symbol of the search space. This plays similar role as monitoringSymbolsWithinSlot as explained here.
• How Can we figure out on which slots the CORESET is transmitted ?  : You can figure it out from searchSpaceZero parameter as explained in CORESET 0 transmission slot section.

RRC Parameters defining CORESET 0

The Common Search Space is defined in 38.213 - section 13. This is long / complicated process. I will take some time for me to digest the process and update this page. One of the key parameter defining the common search space is MIB.pdcchConfigSIB1 (this corresponds to RMSI-PDCCH-Config defined in 38.213 - section 13 as stated below)

If a UE determines that a control resource set for Type0-PDCCH common search space is present, as described in Subclause 4.1, the UE determines a number of consecutive resource blocks and a number of consecutive symbols for the control resource set of the Type0-PDCCH common search space from the four most significant bits of RMSI-PDCCH-Config as described in Tables 13-1 through 13-10 and determines PDCCH monitoring occasions from the four least significant bits of RMSI-PDCCH-Config, included in MasterInformationBlock, as described in Tables 13-11 through 13-15

My translation for this statement is what I want to describe in this page.

The CORESET and PDCCH Occasion(time domain location for the PDCCH) are determined by a MIB parameter and many predefined tables as shown below.

                          NOTE : SCS stands for SubCarrier Spacing

NOTE 1 : You need to figure out which of the PDCCH Monitoring Occassion table (CORESET Multiplexing Pattern) to be used, by looking at FR or SSB SCS / PDCCH SCS which is given to you.

NOTE 2 : You need to figure out which of CORESET defintion table to be used, by looking at FR or SSB SCS / PDCCH SCS which is given to you

Since there are many tables associated with these two parameters, the size of permutations of these two parameters is huge as summarized in the following table.

NOTE : For working examples with simulation based on the configuration that you set, check out WebSim note in Sharetechnote

Example 01 >  pdcch-ConfigSIB1 = 0 (INTEGER). SSB SCS = 30 Khz, PDCCH SCS = 30 Khz

With the given condition of SSB SCS = 30 Khz, PDCCH SCS = 30 Khz and assume that the band is n78. From SSB SCS and PDCCH SCS, we can find two candidates Table 13-4 and Table 13-6. To find which of the two candidate to choose, we need additional information Min BW. This min BW varies depending NR band and the channel BW that are supported by the band. This is defined in 38.101-1 Table 5.3.5-1. From this table, you would notice the minimum Bandwidth that n78 support is 10Mhz.

In conclusion, you would know the CORESET table we need to look into is 38.213-Table 13-4.

With the conclusion above and MSB 4 bit of pdcch-ConfigSIB1 = 0000, we get to the conclusion that we need to use the CORESET configuration as shown below. From the values given in this table, you may visualize the CORESET as explained in this page.

From the conclusion above, we got a parameter that is necessry for the next step. It is 'SS/PBCH block and control resource set multiplexing pattern'. The multiplexing pattern for this case is '1'. Also from the fact that SSB SCS is 30 Khz, we can figure out that the frequency range is FR1 (Sub 6).

With all the information we got above (i.e, multiplexing patter = 1, frequency range = FR1), we can get to the conclusion that we need to look into 38.213-Table 13-11. And with the fact that LSB 4 bit of pdcch-ConfigSIB1 = 0000, we get to the conclusion that search space for PDCCH is defined as follows.

CORESET 0 Position in Time Domain

In regular CORESET (i.e, CORESETs other than CORESET 0), the time domain position is determined by the following two RRC IE(information element).

• SearchSpace -> monitoringSymbolsWithinSlot : Specifies the start position of the coreset
• ControlResourceSet -> duration : Specifies the symbol length of the coreset.

In case of CORESET 0, these two parameters are specified in predefined table as shown in previous sections.

• SearchSpace -> monitoringSymbolsWithinSlot : 'First symbol index' column from table 13-11 and onwards
• ControlResourceSet -> duration : 'Number of symbols' column from table 13-1 through table 13-11.

CORESET 0 Position in Frequency Domain

The CORESET 0 Location in frequency domain is determined based on following statement in 38.213.

The offset in Tables 13-1 through 13-10 is defined with respect to the SCS of the CORESET for Type0-PDCCH CSS set, provided by subCarrierSpacingCommon, from the smallest RB index of the CORESET for Type0-PDCCH CSS set to the smallest RB index of the common RB overlapping with the first RB of the corresponding SS/PBCH block

NOTE : Note that the subcarrier spacing in the parameters shown here differs depending on the situation as summarized below.

• k_ssb : always 15 Khz subcarrier spacing for FR1, 60 Khz subcarrier spacing for FR2 regardless of SSB subcarrier spacing.
• OffsetToPointA : the unit of this parameter is number of RB. Subcarrier spacing within this RB is always 15 Khz subcarrier spacing for FR1, 60 Khz subcarrier spacing for FR2 regardless of SSB subcarrier spacing.
• SSB Subcarrier Spacing : this varies depending on subCarrierSpacingCommon value in MIB. It can be summarized as follows.
• When subCarrierSpacingCommon = scs15or60,
• Subcarrier Spacing for FR1 = 15 Khz
• Subcarrier Spacing for FR2 = 60 Khz
• When subCarrierSpacingCommon = scs30or120,
• Subcarrier Spacing for FR1 = 30 Khz
• Subcarrier Spacing for FR2 = 120 Khz

Based on this statement, I illustrate the CORESET 0 position as shown below.

The whole of that picture is one chain of offsets, each one measured from the thing below it, and it is worth writing out as a single line because every frequency domain question about CORESET 0 is answered by it :

  Point A  ---- offsetToPointA (RBs) ---->  SSB's lowest RB  ---- k_SSB (subcarriers) ---->  SSB
                                            |
                                            |<---- Offset (RBs, from Table 13-1..13-10)
                                            |
                                     CORESET 0's lowest RB

  so :   CORESET 0 lowest RB  =  (SSB's lowest RB)  -  Offset

  and because the SSB's lowest RB is itself offsetToPointA above Point A :

         CORESET 0 lowest CRB  =  offsetToPointA  -  Offset

NOTE : mind the units in that last line, which is exactly the trap your note above warns about. offsetToPointA is counted in resource blocks of 15 kHz for FR1 and 60 kHz for FR2, while the Offset from Tables 13-1 to 13-10 is counted in resource blocks of the CORESET's own subcarrier spacing. The two numbers cannot be subtracted until they are expressed in the same units. Getting this conversion wrong is one of the most common ways to end up with a CORESET 0 that lands in the wrong place by a factor of two.

One more thing that is easy to miss in the illustration : the GSCN / SS_REF arrow points at the middle of the SSB, around RB9 and RB10, not at its bottom. The synchronization raster identifies the centre of the SSB, whereas every offset on this page is measured from the SSB's lowest RB. That is a 10 RB difference, and it is another place where an off-by-a-constant error creeps in.

NOTE : As you notice in this note, in most case the location of physical resource is determined with the reference to PointA(AbsoluteFrequencyPointA), but the location of CORESET 0 physical resource is determined with the reference to SSB(The lowest frequency of the SSB). Why ? It is because the PointA value is informed to UE via RRC message (e.g, SIB1, RRC Setup, RRC Reconfiguration), but at the time of CORESET 0 reception none of those RRC message is delivered to UE. The only information available to UE at this point is SSB and MIB. That is why CORESET 0 is expressed with the reference to SSB.

NOTE : All the values commented in the following example was calculated mannually for understanding purpose. But you may try out following pages if you just want to get the value quickly without worring about making mistake.

• Simulation on where to place coreset 0  : WebSim note in Sharetechnote
• 5G NR frequency band  : https://www.sqimway.com/nr_band.php
• NR Reference Point A : https://www.sqimway.com/nr_refA.php

NOTE : If you want to see the contents of full log with Amarisoft Log viewer, check out this tutorial of Amarisoft TechAcademy.

The three examples below are deliberately chosen to differ in only one thing at a time, so it is worth reading them as a set rather than separately. All three use the same band, the same channel bandwidth and the same table (38.213 Table 13-4), and all three land on a CORESET 0 of 48 RB x 1 symbol. What changes is where the SSB sits and which Offset the index brings with it - which is exactly the pair of variables that decides the answer.

Example 01 to 02 moves the SSB and changes the index together. Example 02 to 03 keeps the SSB exactly where it is and changes only the index. Between them they show both halves of the equation independently.

Example 01 > SSB/PDCCH SCS = {30,30},  Index 10 in Table 13-4

Following illustration is based on a SA log from Amarisoft. GSCN and Center Frequency is set as hardware configuration of the equipment.  

What this example shows : the simplest possible outcome. The MIB carries controlResourceSetZero = 10, which in Table 13-4 means a 48 RB, 1 symbol CORESET 0 with an Offset of 12 RB. Combined with the offsetToPointA that SIB1 later reports, those two numbers place the bottom of CORESET 0 exactly on Point A - the cleanest arrangement you can get, with the CORESET starting at the very first resource block of the carrier.

Working the numbers. Everything on the right hand side of that picture comes from the two boxed values on the left, plus the centre frequency the operator chose :

  the carrier
     carrierBandwidth 51 RB @ 30 kHz  = 51 x 12 x 30 kHz    = 18.36 MHz   (in a 20 MHz channel)
     Point A = centre - CBW/2         = 3489.42 - 18.36/2   = 3480.24 MHz

  where the SSB is
     offsetToPointA 24 RB @ 15 kHz    = 24 x 12 x 15 kHz    = 4.32 MHz
     SSB lowest RB = 3480.24 + 4.32                          = 3484.56 MHz
     SSB is 20 RB @ 30 kHz = 7.2 MHz, so its centre          = 3488.16 MHz
                                              which is GSCN 7838  - matches the log

  where CORESET 0 goes
     Offset 12 RB @ 30 kHz            = 12 x 12 x 30 kHz    = 4.32 MHz
     CORESET 0 lowest = 3484.56 - 4.32                       = 3480.24 MHz  = Point A

Now do the same thing in resource blocks instead of megahertz, because that is where the unit trap bites :

     offsetToPointA = 24 RB at 15 kHz   ->  12 RB at 30 kHz    (halve it)
     Offset         = 12 RB at 30 kHz

     CORESET 0 lowest CRB  =  12 - 12  =  0       -> starts at Point A

NOTE : if you forget to convert offsetToPointA from 15 kHz RBs to 30 kHz RBs, you would compute 24 - 12 = 12 and place CORESET 0 twelve resource blocks too high. This example is a good one to keep as a sanity check precisely because the correct answer is a round zero - any arithmetic slip is immediately visible.

Finally, the sanity check that matters in practice : CORESET 0 is 48 RB at 30 kHz = 17.28 MHz, and the carrier is 18.36 MHz wide. It starts at Point A and ends 17.28 MHz later, comfortably inside the channel. This is the "valid" case from the Tips section further down.

Example 02 > SSB/PDCCH SCS = {30,30}, Index 11 in Table 13-4

Following illustration is based on a SA log from Amarisoft. GSCN and Center Frequency is set as hardware configuration of the equipment.  

What this example shows : the SSB has moved up by one step on the synchronization raster, and the index has changed with it. controlResourceSetZero = 11 gives the same 48 RB, 1 symbol CORESET 0 but with an Offset of 14 instead of 12. This time the two numbers do not cancel, and CORESET 0 ends up sitting slightly above Point A rather than exactly on it.

What changed from Example 01, and why the two changes are really one :

     GSCN            7838  ->  7839        one step up the sync raster
     that step is                                3489.60 - 3488.16 = 1.44 MHz

     offsetToPointA    24  ->  32 RB @ 15 kHz
     that change is              (32 - 24) x 12 x 15 kHz = 1.44 MHz     the same number

That is not a coincidence, and it is the most useful thing in this example. 1.44 MHz is exactly the FR1 synchronization raster step above 3 GHz. Move the SSB by one GSCN and offsetToPointA must move by precisely the same distance, because offsetToPointA is nothing more than the gap between Point A and the SSB. The carrier did not move - only the SSB inside it did.

And now the placement :

     offsetToPointA = 32 RB at 15 kHz   ->  16 RB at 30 kHz
     Offset         = 14 RB at 30 kHz

     CORESET 0 lowest CRB  =  16 - 14  =  2       -> two RBs above Point A

     in frequency :  3480.24 + 2 x 0.36 MHz  =  3480.96 MHz

Look back at the picture and you can see it - the bottom of the red CORESET 0 bar no longer touches the Point A line, there is a small gap. Two resource blocks of the carrier sit below CORESET 0 and are simply not used by it.

NOTE : one label in this illustration is worth double-checking. It shows SSB_Low = 3484.56 MHz, which is the value from Example 01. With offsetToPointA now 32 RB, two independent routes both give 3486.00 MHz : Point A + offsetToPointA = 3480.24 + 5.76, and GSCN centre - half the SSB = 3489.60 - 3.60. The 3484.56 looks like it was carried over from the previous picture. Everything else in the illustration is consistent.

Example 03 > SSB/PDCCH SCS = {30,30}, Index 12 in Table 13-4

Following illustration is based on a SA log from Amarisoft. GSCN and Center Frequency is set as hardware configuration of the equipment.  

What this example shows : the cleanest comparison of the three. The SSB is in exactly the same place as Example 02 - same GSCN, same offsetToPointA - and the only thing that changes is the index, controlResourceSetZero = 12, which brings an Offset of 16 instead of 14. So this example isolates the Offset completely : one number changes, and you can see precisely what it does.

Only the index moved :

     GSCN                7839      unchanged from Example 02
     offsetToPointA        32 RB   unchanged from Example 02
     Offset                14  ->  16 RB @ 30 kHz     the only difference

     offsetToPointA = 32 RB at 15 kHz   ->  16 RB at 30 kHz
     CORESET 0 lowest CRB  =  16 - 16  =  0       -> back to Point A

Two extra resource blocks of Offset pulled CORESET 0 down by exactly two resource blocks, from CRB 2 back to CRB 0. That is the whole behaviour of the Offset field in one observation : a larger Offset moves CORESET 0 further down in frequency, away from the SSB.

Putting the three examples side by side, notice that Examples 01 and 03 reach the identical answer - CORESET 0 starting at Point A - from completely different inputs :

     Example 01 :  offsetToPointA 12 RB@30k  -  Offset 12  =  0
     Example 03 :  offsetToPointA 16 RB@30k  -  Offset 16  =  0

This is why you cannot judge an index in isolation. controlResourceSetZero = 10 is not inherently better or worse than 12 - the right index depends entirely on where the SSB happens to sit on the raster for that carrier. It is the difference of the two numbers that has to land inside the channel bandwidth, which is exactly what the Tips section further down is about.

NOTE : the same SSB_Low label question from Example 02 applies here too - this illustration shares the SSB position with Example 02, so its SSB_Low should also read 3486.00 MHz.

CORESET 0 Transmission Slots

The transmission and monitoring is defined by the 3GPP TS 38.213 - Section 13.  This process involves determining the timing and slot positions for CORESET 0 transmission in relation to theSSB blocks, using multiplexing pattern. It ensures that the UE can efficiently monitor the PDCCH in the correct slots and symbols, based on parameters like slot offsets, scaling factors, and numerology, enabling successful initial access and synchronization with the 5G network.

NOTE : Coreset0, SearchSpace0, DCI for SIB1, PDSCH for SIB1 are all in the same slot, because SearchSpace0 is within Coreset 0 and DCI for SIB1 is within the SearchSpace0 and DCI & the scheduled PDSCH is in the sameslot (i.e, k0=0). Therefore, Coreset 0 transmission slot also means the transmission slot of SearchSpace0, DCI for SIB1, PDSCH for SIB1

NOTE :Simply put, n₀ indicates the offset in the unit of slot between SSB and the corresponding coreset 0.  n₀=0 means that SSB(PBCH/MIB) and Coreset 0(SearchSpace0, DCI for SIB1, PDSCH for SIB1) are all in the same slot.. n₀!=0 means SSB and Coreset0 are in different slots

NOTE :You can get many visualized example of n₀calculation at this Amarisoft Tech-Academy Tutorial

The overall logic of determining the Coreset 0 transmission is illustrated as below

Let’s break down the process.

PDCCH monitoring for Type0-PDCCH CSS (Common Search Space) set is associated with SS/PBCH blocks and CORESET multiplexing pattern. The key points are:

• CORESET 0 Transmission Timing:
  • CORESET 0 is transmitted in even frames when [(O · 2^μ + ⌊i · M⌋) / N_slot^frame,μ] mod 2 = 0.
  • CORESET 0 is transmitted in odd frames when [(O · 2^μ + ⌊i · M⌋) / N_slot^frame,μ] mod 2 = 1.
  Here, O is the slot offset, i is the candidate SS/PBCH block index, M is a scaling factor, N_slot^frame,μ is the number of slots in a radio frame for subcarrier spacing (SCS) configuration μ, and μ is the numerology index (related to SCS).

• Slot Index for Monitoring:
• The slot index n₀ where the UE monitors PDCCH is given by:
• n₀ = (O · 2^μ + ⌊i · M⌋) mod N_slot^frame,μ
• The UE monitors two consecutive slots starting from slot n₀, i.e., slots n₀ and n₀ + 1.

The imprtant point of this process (calculation) is to figure out n_0.  n₀represents the starting slot index within a radio frame where the UE begins monitoring the PDCCH for the Type0-PDCCH Common Search Space (CSS) set, which is associated with CORESET 0

Practically, n₀ determines the exact timing (in terms of slots) within a radio frame where the UE should look for CORESET 0, which contains the PDCCH. With 38.213 Table 13-11, as an example, for μ = 1 (where N_slot^frame,μ = 20), O = 0, and M = 1/2, the values of n₀ are calculated as 0, 1, 2, and 3 for SS/PBCH block indices i = 0, 2, 4, 6, respectively. This means the UE monitors slots 0 and 1 for i = 0, slots 1 and 2 for i = 2, and so on. This slot index ensures that the UE aligns its monitoring with the network’s transmission schedule for CORESET 0, which is tied to the SS/PBCH block transmissions.

Example 01 >  SSB/PDCCH SCS = {30,30}, SSB Index = 0, Table 13-11 = 4

This example is the case where FR1 and Pattern 1 is used, SSB index is 0 (the first SSB) and the index within the table 13-11 is 4 (This index is configured by the IE SearchSpaceZero in MIB).

According to the calculation shown below, CORESET 0 is scheduled at slot 10 in the radio frame that meets the SFNc criteria.

According to following calculation, CORESET 0 is scheduled to be every EVEN radio frame. (This determined the radio frame where the SSB is transmitted)

Example 02 > n0 , SSB/PDCCH SCS = {30,30}, SSB Index = 0, Table 13-11

Followng table lists the calculated n0 for every indexes of Table 13-11. You may try calculating n0 on your own as explained above. Just for practice.

Example 03 >  SFNc , SSB/PDCCH SCS = {30,30}, SSB Index = 0, Table 13-11

Followng table lists the calculated SFNc for every indexes of Table 13-11. You may try calculating n0 on your own as explained above. Just for practice.

Example 04 >  SFNc for SSB/PDCCH SCS = {30,30}, Varrying SSB index, O/M Index in Table 13-11 = 4

Following table shows the SFNc for every SSB burst in FR1 assuming that the index in Table 13-11 (i.e, the IE SearchSpaceZero in MIB) is configured to be 4. For practice, try to make table when SearchSpaceZero in MIB is configured to different value.

Example 05 : n0 for SSB/PDCCH SCS = {30,30}, Varrying SSB index, O/M Index in Table 13-11 = 4

Following table shows the n0 for every SSB burst in FR1 assuming that the index in Table 13-11 (i.e, the IE SearchSpaceZero in MIB) is configured to be 4. For practice, try to make table when SearchSpaceZero in MIB is configured to different value.

CORESET 0 Aggregation Level

What is the aggregation level that are applicable to CORESET 0 for SIB1 decoding ? I haven't found any explicit statement yet from the specification, but I guess that at least following aggregation levels would be applicable to CORESET 0 as per 38.213 - Section 10.

< 38.213 - Table 10.1-1: CCE aggregation levels and maximum number of PDCCH candidates per CCE aggregation level for CSS sets configured by searchSpaceSIB1 >

Your instinct here is right, and the specification does let you pin it down - just not in one sentence. The table above tells you what the UE would monitor, and the CORESET 0 dimensions from Tables 13-1 to 13-10 tell you what will physically fit. Put the two together and the answer falls out.

A CCE is 6 REGs, and a REG is one resource block in one OFDM symbol. So a CORESET carries :

        number of CCEs  =  N_RB  x  N_symbol  /  6

Every CORESET 0 shape that appears anywhere in Tables 13-1 to 13-10 therefore has a fixed CCE budget, and an aggregation level simply cannot be monitored if the CORESET does not contain that many CCEs :

Two things in that table are worth pausing on.

The small shapes cannot host AL 16 at all. A 24 RB / 2 symbol CORESET 0 has 8 CCEs, and an aggregation level 16 candidate needs 16 - there is simply nowhere to put it. So on a narrow CORESET 0 the UE's most robust candidate is AL 8, and SIB1 coverage is correspondingly worse. If you are choosing an index for a cell that has to reach the edge of a large sector, this is the argument for spending the extra bandwidth on a 48 RB or 96 RB CORESET 0 rather than the smallest one that fits.

The largest shape fits everything exactly. Add up the table above it - 4 candidates at AL 4, 2 at AL 8, 1 at AL 16 - and you get 4x4 + 2x8 + 1x16 = 48 CCEs, which is precisely the capacity of a 96 RB / 3 symbol CORESET 0. That is almost certainly not a coincidence : the biggest CORESET 0 in the specification is sized so that every candidate the UE is asked to monitor can sit in its own CCEs with no overlap at all.

Whole Table

All of the following tables are from 38.213 v15.7

Table 13-1: Set of resource blocks and slot symbols of CORESET for Type0-PDCCH search space set when {SS/PBCH block, PDCCH} SCS is {15, 15} kHz for frequency bands with minimum channel bandwidth 5 MHz or 10 MHz

Index	SS/PBCH block and CORESET multiplexing pattern	Number of RBs CORESETNRB	Number of Symbols CORESETNsymb	Offset (RBs)
0	1	24	2	0
1	1	24	2	2
2	1	24	2	4
3	1	24	3	0
4	1	24	3	2
5	1	24	3	4
6	1	48	1	12
7	1	48	1	16
8	1	48	2	12
9	1	48	2	16
10	1	48	3	12
11	1	48	3	16
12	1	96	1	38
13	1	96	2	38
14	1	96	3	38
15	Reserved

Table 13-2: Set of resource blocks and slot symbols of CORESET for Type0-PDCCH search space set when {SS/PBCH block, PDCCH} SCS is {15, 30} kHz for frequency bands with minimum channel bandwidth 5 MHz or 10 MHz

Table 13-3: Set of resource blocks and slot symbols of CORESET for Type0-PDCCH search space set when {SS/PBCH block, PDCCH} SCS is {30, 15} kHz for frequency bands with minimum channel bandwidth 5 MHz or 10 MHz

Table 13-4: Set of resource blocks and slot symbols of CORESET for Type0-PDCCH search space set when {SS/PBCH block, PDCCH} SCS is {30, 30} kHz for frequency bands with minimum channel bandwidth 5 MHz or 10 MHz

Table 13-5: Set of resource blocks and slot symbols of CORESET for Type0-PDCCH search space set when {SS/PBCH block, PDCCH} SCS is {30, 15} kHz for frequency bands with minimum channel bandwidth 40MHz

Table 13-6: Set of resource blocks and slot symbols of CORESET for Type0-PDCCH search space set when {SS/PBCH block, PDCCH} SCS is {30, 30} kHz for frequency bands with minimum channel bandwidth 40MHz

Table 13-7: Set of resource blocks and slot symbols of CORESET for Type0-PDCCH search space set when {SS/PBCH block, PDCCH} SCS is {120, 60} kHz

Table 13-8: Set of resource blocks and slot symbols of CORESET for Type0-PDCCH search space set when {SS/PBCH block, PDCCH} SCS is {120, 120} kHz

Table 13-9: Set of resource blocks and slot symbols of CORESET for Type0-PDCCH search space set when {SS/PBCH block, PDCCH} SCS is {240, 60} kHz

Table 13-10: Set of resource blocks and slot symbols of CORESET for Type0-PDCCH search spaceset when {SS/PBCH block, PDCCH} SCS is {240, 120} kHz

Table 13-11: Parameters for PDCCH monitoring occasions for Type0-PDCCH CSS set - SS/PBCH block and CORESET multiplexing pattern 1 and FR1

Table 13-12: Parameters for PDCCH monitoring occasions for Type0-PDCCH CSS set - SS/PBCH block and CORESET multiplexing pattern 1 and FR2

Table 13-13: PDCCH monitoring occasions for Type0-PDCCH CSS set - SS/PBCH block and CORESET multiplexing pattern 2 and {SS/PBCH block, PDCCH} SCS {120, 60} kHz

Table 13-14: PDCCH monitoring occasions for Type0-PDCCH CSS set - SS/PBCH block and CORESET multiplexing pattern 2 and {SS/PBCH block, PDCCH} SCS {240, 120} kHz

Table 13-15: PDCCH monitoring occasions for Type0-PDCCH CSS set - SS/PBCH block and CORESET multiplexing pattern 3 and {SS/PBCH block, PDCCH} SCS {120, 120} kHz

Visual Summary

It would not be easy to get some big picture (intuitive understandings) peneterating through all the tables listed above. To help with this, I tried to get some intuitive image consolidating all the tables as shown below. I hope this helps rather than confusing further :)

Following is the summary of Number of RB and Symbol Length of Coreset. The frequency span for each case would vary depending on subcarrier spacing.

Following is the summary of possible Offset value from SSB.

Those two pictures are the right mental model for FR1, which is where most people meet CORESET 0. There are three things in the tables that they deliberately simplify away, and they are worth knowing before you apply the pictures to an FR2 problem.

1. There is a ninth shape. The bar chart shows eight combinations - 24 RB with 2 or 3 symbols, and 48 and 96 RB with 1, 2 or 3. There is one more : 24 RB with 1 symbol, which appears only in Table 13-10, the {240,120} kHz FR2 case. It is the smallest CORESET 0 in the whole specification at just 4 CCEs, which as the aggregation level section above shows can carry nothing beyond AL 4.

2. In FR2 the offset can be negative. Both pictures draw CORESET 0 at or below the SSB in frequency, and for FR1 that is always true. In the FR2 tables it is not :

  Table 13-8  ({120,120} kHz)  index 4 :  pattern 3, 24 RB, 2 symbols, offset = -20 if k_SSB = 0, -21 otherwise
  Table 13-10 ({240,120} kHz)  index 4 :  pattern 2, 24 RB, 1 symbol, offset = -41 if k_SSB = 0, -42 otherwise

A negative offset means CORESET 0 sits above the SSB rather than below it. This only happens with SS/PBCH block and CORESET multiplexing patterns 2 and 3, which exist only in FR2 - and those are exactly the patterns where the CORESET shares symbols with the SSB burst instead of being time multiplexed after it. If you have only ever worked in FR1 you will never have seen this, because FR1 uses pattern 1 throughout.

3. Some offsets depend on k_SSB. Look at the two rows quoted above : the offset is not a single number but a pair, chosen by whether k_SSB is zero. The second picture, which lists a clean set of offsets per CORESET width, is showing you the FR1 case where that never happens.

And one observation the second picture makes very well - the granularity of the offset gets coarser as CORESET 0 gets wider. 24 RB offers every integer from 0 to 8, 48 RB offers even numbers, and 96 RB offers only a handful of widely spaced values. That is a sensible trade rather than an arbitrary one : a wide CORESET 0 already covers most of the carrier, so there is little left to slide it around in, and spending precious MIB bits on fine positioning it would be wasted. The 4 bits of controlResourceSetZero have to encode shape and position in 16 combinations, so the wider the CORESET, the more of that budget goes on shape and the less is left for position.

Tips for CORESET0  Index Selection

Even if you got overall understanding on what has been explained above, you may have difficulties with selecting a proper CORESET 0 index if you are asked to pick for a specific case. My tip for picking up a appropriate the index is illustrated below. Just try to remove the index that may fall into the invalid cases shown below and pick one from the remaining indices. It is highly likely that your selection is correct.

The three invalid cases in that picture are not three separate rules - they are three different ways of failing the same single test :

   the whole of CORESET 0 must lie inside the carrier's channel bandwidth

     lowest RB of CORESET 0  =  offsetToPointA  -  Offset      (in the same SCS units)

     need :   lowest RB of CORESET 0   >=  the carrier's first RB
     and  :   lowest RB + N_RB         <=  the carrier's last RB + 1

The last two rows are the same arithmetic failing for different reasons, and that is exactly why the picture draws them separately. When you hit it in practice the fix depends on which one you are actually looking at : if the Offset is large you can choose a different index and be done, but if the SSB is simply too near the edge of the channel then every index with a non-zero offset will fail and you have to move the SSB instead.

NOTE : this is the single most common configuration error in bringing up a new NR cell, and it has a very characteristic symptom - the UE finds the cell, decodes PSS, SSS and the MIB perfectly, and then never sends a PRACH. It has decoded pdcch-ConfigSIB1, worked out where CORESET 0 should be, found that the answer lies outside the carrier, and stopped. Everything up to the MIB looks flawless in the log, which is why the fault is so often looked for in the wrong place.

Time Domain Resource Allocation for SIB1 PDSCH

Once all the information about CORESET 0 is determined, UE need to figure of PDSCH resource informtion from DCI. The DCI for SIB1 PDSCH is DCI 1_0 explained here. From the DCI, UE need to figure out the frequency and time domain resource information of the SIB1 PDSCH. There is no problem with figuring out the frequency domain resource information since it is directly encoded in the DCI, but there is problem with figuring out the time domain resource information since it is not directly encoded in the DCI. The time domain resource information is indicated by an index value pointing to a special form of table (called PDSCH-TimeDomainResourceAllocation). Usually this table is informed to UE via RRC message as explained in this note, but at the point of SIB1 decoding these RRC message has not been delivered to UE yet. So there should be some predefined table known to UE by 3GPP specification. In SIB1 PDSCH case, the table 38.214 -Table 5.1.2.1.1-2 (shown in this note) is used.

Reference

[1] Type0-PDCCH common search space

[2] 3GPP TSG RAN WG1 Meeting AH 1801 -  R1-1800230 : Summary of Offline Discussion on RMSI      

[3] 3GPP TSG RAN WG1 Meeting #92bis - R1-1805600 : Summary of Offline Discussion on RMSI