5G NR PDCCH CCE Aggregation & Search Space configurations

Based on 3GPP TS 38.213 (10.1) specifications, I have put together below details on 5G-NR PDCCH CCE Aggregation and Search Space configurations.

• PDCCH is used to carry the DCI(Downlink Control Information ).
• DCI message indicates the DL/UL resource's for PDSCH/PUSCH.
• Successful decoding of PDCCH will enable UE to read the DCI info which provides the scheduling resources allocation to the UE on the PDSCH & PUSCH.
• For example, if the UE is scheduled data by gNB, UE needs to know where the data is located on PDSCH(in terms of PRB's and Slot/symbols) .
• If UE fails to decode the PDCCH, then UE will not know the location of the PDSCH resources and it will keep attempting to decode the PDCCH using a different set of PDCCH candidates(aggregation level) in the upcoming PDCCH monitoring occasion (This is kind of LinkAdaptation on PDCCH).
• If UE fails to decode the PDCCH by "N310" attempts and on expiry of T310 timer UE will declate it as Radio Link Failure(RLF) due to "physical layer problem detected".

To overcome PDCCH decoding issues (Phy layer problems), Configuring Search Spaces for efficient PDCCH detection and decoding plays a major role (explained below).

NR DCI Formats: Below are the types of DCI Format's used in 5G NR for enabling DL/UL Data Transmissions--> Ref 38.212, 7.3.1-1

 --> Fallback format by design is a default scheduling option which has non configurable fields and supports basic NR operations

--> Non-Fallback format by design is flexible to accommodate the NR features.

--> Fall Back format is smaller in size compared to a Non Fall Back format.

PDCCH CCE Aggregation level: The number of Resource Elements (RE's) of a CORESET that are required to carry a PDCCH DCI message is called Aggregation level, It is expressed in terms on CCE's (control channel elements).

Number of REG's/CCE's that compose a PDCCH candidate is determined by the CCE Aggregation level, Aggregation level and number of CCE's per aggregation are matched one to one.

Control Resource Set(CORESET) Resource Configuration:

Based on the above configuration below is an example applying CCE Aggregation level for a DCI format.

1REG = 12SC's X 1symbol = 12 RE's

1CCE = 6 REG's = 72 RE's (54REs are used for PDCCH, 18RE's are used for DMRS)

Total PRBs in the CORESET = 48

Total number of CORESET Resource elements = 576

Number of DMRS REs = 18 * 8 = 144

PDCCH RE's = 576 - 144 = 432 (meaning In this case PDCCH candidate up to maximum Aggregation level 8 can be configured, Aggregation Level 16 is not possible in this case).

 Following are 5 different PDCCH CCE aggregation levels supported in 5G NR, Aggregation Level 1, 2, 4 , 8 & 16 Each of these aggregation numbers specify the number of CCE's (RE's) that are required to carry a PDCCH DCI message --> Referenced from 3GPP TS 38.213

• Number of bits (Payload) of the DCI formats are less than the number of bits per each CCE aggregation level (as shown above).
• For example, Size of DCI format 1_1 scrambled with a C-RNTI for FR2 100Mhz (66RBs), the total number of bits after packing all the fields is 79 bits (referenced 38.212, 7.3.1.2.2) and after adding the 24 bit CRC, total payload size of the DCI 1_1 is 103 bits, shown in below snap shot.

• In above example since DCI Format 1_1 is scrambled with a C-RNTI, assuming Aggregation level 2 is applied, meaning 103 bits payload of the DCI Format 1_1 is rate matched and bloated to 216 bits (applied aggregation level 2 = 2 CCE’s) giving a very good forward error correction protection for efficient decoding of PDCCH and derive the DCI message bits successfully.
• As per specification it mandates all DCI's scrambled with a Common RNTI such as SI, RAR, Paging etc that have PDCCH candidates allocated in Common search space should always use highest Aggregation level 4 or 8.
• DCI's scrambled with C-RNTI that have PDCCH candidates in UE Specific search space could use lower Aggregation level, This information is communicated to the UE via RRC Reconfigure message. (explained below in detail).

Search Space configuration:Typically a UE does not attempt to decode each and very PDCCH candidate. To keep minimum restrictions on the scheduler and at the same time to maintain less number of blind decoding attempts by the UE, There are search spaces configured.

• Search Space are indicated by a set of contiguous CCEs the UE is supposed to monitor for scheduling assignments/grants relating to a certain component carrier.
• Below are two types of search spaces used in NR-PDCCH to control each component carrier.
• Common Search Space (CSS):
• DCI CRC is Scrambled with a SI-RNTI (System Information), RA-RNTI (Random Access),TC-RNTI(Temp Cell RNTI), P-RNTI (Paging ), INT-RNTI (Interruption ), SFI-RNTI (Slot Format Indication), TPC-PUCCH-RNTI (Tx Pwr Ctrl), TPC-PUSCH-RNTI, TPC-SRS-RNTI, C-RNTI (Cell RNTI), CS-RNTI (Configured Scheduling), For all common procedures
• UE-Specific Search Space(USS):
• DCI CRC is Scrambled with a C-RNTI (Cell RNTI), CS-RNTI (Configured Scheduling), these are specifically targeted to individual UE.
• A common search space (CSS) is shared across all UEs and a UE-specific search space (USS) is used per UE basis (meaning this SS is specific for a UE).
• As per 3GPP specification 38.212, UEs decode the PDCCH using the 4 UE-specific search space Aggregation levels (1,2,4,& 8) and 2 common search space Aggregation Levels (4 & 8).as shown in below table.

• For each component carrier, Number of available resource element group (REG) are determined and on top of that available RE's are segregated into CCE's --> 1CCE = 6REGs = 72 RE's.
• The PDCCH candidates per carrier component are transmitted using a number of the CCEs, The number of CCEs used for a PDCCH candidate may be 1, 2, 4 or 8 , which is equivalent to the Aggregation Level.
• Each search space comprises a group of consecutive CCEs which could be allocated to a PDCCH called a PDCCH candidate.
• A UE will decode all the PDCCH candidates in these two search spaces to discover that UE's downlink control information (DCIs).
• For example, The UE may decode the DCI to get the scheduled UL grants info on the PUSCH and DL resources on the PDSCH.
• The common search space and the UE-specific search space for different UEs are multiplexed at the CCE level.
• REG/CCE region is specific for Each search space , That is different RNTI's may be treated different , so the location of the REG/CCE depends on the identity of the entity (RNTI).
• In order to minimize conflicts and efficiently utilize the resources, CCE Multiplexing is adopted between the search spaces, meaning the same REG/CCE resources may be shared across all search spaces but each search space can hash to a different range of CCEs.
• In other words, the REG/CCEs for each scheduling RNTI may be uniquely defined to avoid conflicts providing search space coordination among the different scheduling entities.
• As per 38.213, 10.1, Below are RNTI's mapped to PDCCH Search Space Types.

As Per 38 213 V15.2.0, 10.1 I put together below example of calculating CCE Index for PDCCH candidate's per slot in a Search Space.

Overview of PDCCH Blind decoding:

•  The UE generally does not know the number of CCEs occupied by the current PDCCH, what DCI format information is transmitted , and where the information it needs is located.
• However the UE knows what information it is expecting and UE is aware of the RNTI value, For Example , In Idle state UE would be expecting Paging or SI information, After initiating Random Access UE expects a RACH Response, When there is uplink data in the buffer waiting to be sent UE expects UL Grant, etc…
• For different expected information , The UE uses the corresponding RNTI to perform CRC check on the received TB that has the CRC scrambled with the respective RNTI.
• If the CRC check is successful, Then the UE knows that this information is what it needs, and will further derive the content of the DCI message, This is called PDCCH Blind decoding process.

Common Search Space (CSS) PDCCH blind decoding procedure (Common RNTI's are mandated to use AL4, AL8,AL16)

• Based on the above CSS nested CCE tree PDCCH blind decoding is performed based on following sequence, 4 CCEs (perform Blind decoding for 4 PDCCH Candidates), Then 8 CCEs(perform blind decoding for 2 PDCCH candidates) and Then, Finally 16 CCEs(perform Blind decoding for 1 PDCCH candidate).
• Before starting to perform PDCCH blind decoding, Based on the DMRS, Channel estimation need to be performed.
• The number of PDCCH DMRS used to perform channel estimation depends on the size of PDCCH, As shown in above CCE Aggregation calculations (For 1CCE 18RE's are used for DMRS, For 4CCE's 72 RE's are used for DMRS and so on..),
• Channel Estimation & Blind decoding: For CCE Aggregation Level4, Channel estimation is performed on the first candidate consisting of 4CCEs and then UE decodes the PDCCH to see whether RNTI matches with the RNTI scrambled with the DCI CRC. If it does not match then channel estimation is performed on the 2nd candidate on next 4 CCEs and then again UE decodes PDCCH of the 2nd candidate and checks for a match with RNTI, this is repeat two more times total 4 Blind decoding attempts for 4 candidates.
• If RNTI does not match with any of the 4 candidates in AL4, then CCE Aggregation Level8 is considered, Channel estimation is performed for the 1st candidate consisting 8CCE's and then UE performs PDCCH decoding and checks for RNTI matching, if does not match then channel estimation and PDCCH decoding is performed for 2nd Candidate consisting of next 8CCE's.
• If RNTI does not match with any of the 2 candidates in AL8, Then finally CCE Aggregation Level16 is considered, Channel estimation and PDCCH decoding is performed on the 16CCE’s and finally if RNTI match the DCI CRC scrambled RNTI then UE will get to know that DCI is allocated for that UE and it will drive the DCI Info to get the DL/UL scheduling information.

Below is an overview of UE-Specific Search PDCCH REG/CCE Resources allocation when 3 UE's are scheduled simultaneously.