PDCCH is a downlink control channel.
It carries control information DCI of PUSCH and PDSCH.
In LTE PDCCH occupies the entire bandwidth in frequency domain and first 1-3 symbols in each subframe in time domain.
In 5G NR, as the bandwidth is more, it will be waste of resources. Hence in 5G NR PDCCH will be in BWP and in time domain it does not occupy fixed time slot.
To decode time-frequency resources of PDCCH, we need to understand search space and CORESET.
In previous article, we have learnt about CORESET, in this chapter we shall understand Search Space and how it is related to CORESET.
Search Space is used to get the area in the downlink frame where PDCCH might be transmitted.
This area will be monitored by UE to search for PDCCH carrying data.
Search space is divided into 2 types: CSS: Common Search Space and USS: UE Specific Search Space.
Different CSS will have different meaning and is discussed below.
Below are the different types of Search Space
As seen from above image, different types will have PDCCH scrambled by different RNTIs.
When UE wants to look for PDCCH, RRC layer will provide parameter to indicate search space.
PDCCH-configCommon In SIB1, to configure the cell specific common search space:
PDCCH-config for UE specific search space:
Search space will contain the following information from TS 38.331:
Parameters related to time domain position of PDCCH:
> monitoringSlotPeriodicityAndOffset
> Duration
> monitoringSymbolsWithinSlot
> controlResourceSetId
A search space can only correspond to a unique CORESET.
In summary:
> When UE wants to find PDCCH, the search space indicated from RRC parameter will indicate the time domain and offset of the search space, number of time slots, start symbol for monitoring each time slot of CORESET time domain.
> With the help of time domain and resource size, CORESET0 can be determined. So that UE can detect PDCCH from it.
> CORESET0 will also inform the UE of the decoding PDCCH information, such as the size of the REG bundle.