Search space — Where a device looks for a DCI, and how often
Procedures over time
Where it sits
What it is
What it is. A set of PDCCH candidates — positions and aggregation levels — that a device monitors. TS 38.213 clause 10.1. A CORESET says where control may be; a search space says which of those positions this device should try, and in which slots.
Common search space — shared by many devices, carrying what everyone needs: system information, paging, random-access responses. Its candidates are at fixed positions so a device with no configuration can find them.
UE-specific search space — derived from the device's own C-RNTI, so different devices try different candidates and rarely collide.
Why a device must search at all. There is no address field in a DCI (ref-modulation §6) and no field saying how long it is. So a device takes each candidate, assumes an aggregation level, decodes it as a polar codeword, descrambles the CRC with an RNTI it owns, and checks. A pass means the message was for it; a fail means try the next. This is blind decoding, and it is the price of having deleted the address.
The price is bounded, and the bound is in the specification. TS 38.213 clause 10.1 caps the number of candidates and the number of non-overlapping CCEs a device must handle per slot, per numerology — because without a cap the search would grow without limit as the control region grew. That cap is why a scheduler cannot simply give every device its own private candidate set.
Read on
This concept was first written up in ref-channels, which reads the whole group as one argument.
Before this concept, the hierarchy says to learn the following — the full chain, in order: