5G/NR - Type 0 PDCCH Common Search Space               Home : www.sharetechnote.com

 

 

 

 

 

Type 0 PDCCH Common Search Space (CORESET 0)/SIB1 Scheduling and Decoding

 

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 ?

 

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

 

 

 

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.

38.213-Table

Index Range

Multiplex Pattern

38.213-Table

Index Range

Permutations

13-1

0~14

1

13-11

0~15

240

13-2

0~13

1

13-11

0~15

224

13-3

0~8

1

13-11

0~15

144

13-4

0~15

1

13-11

0~15

256

13-5

0~8

1

13-11

0~15

144

13-6

0~9

1

13-11

0~15

160

13-7

0~7

1

13-12

0~13

112

8~11

2

13-13

0

4

13-8

0~3

1

13-12

0~13

14

4~7

3

13-15

0

4

13-9

0~3

1

13-12

0~14

56

13-10

0~3

1

13-12

0~14

56

4~7

2

13-14

0

4

Total Permutations

1,418

 

 

 

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 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,
        • SSB Subcarrier Spacing for FR1 = 15 Khz
        • SSB Subcarrier Spacing for FR2 = 60 Khz
      • When subCarrierSpacingCommon = scs30or120,
        • SSB Subcarrier Spacing for FR1 = 30 Khz
        • SSB Subcarrier Spacing for FR2 = 120 Khz

     

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

 

     

    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.

 

 

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.  

 

 

 

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.  

 

 

 

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.  

 

 

 

 

CORESET 0 Transmission Slots

 

 

 

 

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

 

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.

 

 

 

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

 

index

O

M

n0

0

0

1

0

1

0

1/2

0

2

2

1

4

3

2

1/2

4

4

5

1

10

5

5

1/2

10

6

7

1

14

7

7

1/2

14

8

0

2

0

9

5

2

10

10

0

1

0

11

0

1

0

12

2

1

4

13

2

1

4

14

5

1

10

15

5

1

10

 

 

 

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

 

index

O

M

SFNc

0

0

1

0

1

0

1/2

0

2

2

1

0

3

2

1/2

0

4

5

1

0

5

5

1/2

0

6

7

1

0

7

7

1/2

0

8

0

2

0

9

5

2

0

10

0

1

0

11

0

1

0

12

2

1

0

13

2

1

0

14

5

1

0

15

5

1

0

 

 

 

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

 

SSB index

O

M

SFNc

0

5

1

0

1

5

1

0

2

5

1

0

3

5

1

0

4

5

1

0

5

5

1

0

6

5

1

0

7

5

1

0

 

 

 

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

 

SSB index

O

M

n0

0

5

1

10

1

5

1

11

2

5

1

12

3

5

1

13

4

5

1

14

5

5

1

15

6

5

1

16

7

5

1

17

 

 

 

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 >

 

 

 

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

 

 

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

 

 

 

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