|
|
|||||||||||||||||||||||||||||||||||||||||||
|
A Search Space is a predefined region where the UE looks for control information on the PDCCH. The network does not send control messages directly to a fixed location known by the UE. Instead, it places the control information in certain candidate locations within this search space. In 5G, the PDCCH carries Downlink Control Information. This includes scheduling assignments, paging indication, and various control commands. However, the exact position of this information is not fixed. It can vary in time and frequency depending on configuration. The Search Space defines a set of possible locations where the UE should attempt to decode control information. These locations are called PDCCH candidates. Each candidate corresponds to a specific aggregation level and a specific Control Channel Element mapping. The UE does not know in advance which candidate actually contains the message intended for it. Therefore, it performs blind decoding. This means the UE tries multiple decoding attempts across different candidates and different formats. For each candidate, the UE attempts to decode the signal and checks whether the decoded information is valid. This validation is done using CRC, which is masked with a specific RNTI. If the CRC check passes with the UE’s RNTI (or a common RNTI like P-RNTI for paging), the UE knows that the message is intended for it. This process is repeated across all configured candidates in the search space. Once a valid match is found, the UE stops further decoding and processes the received control information. The Search Space configuration is provided by higher layer signaling such as RRC. It defines parameters like monitoring periodicity, duration, aggregation levels, and number of candidates. From UE perspective, the behavior is systematic. UE wakes up at the configured monitoring occasion. UE scans the configured search space. UE performs blind decoding on each candidate. UE checks CRC with relevant RNTIs. If a match is found, UE processes the message. If not, UE stops monitoring and returns to sleep. This mechanism provides flexibility to the network. The gNB can dynamically place control information without needing a fixed mapping for every UE. At the same time, the UE can still reliably find its messages through controlled blind decoding. In simple terms, the Search Space is a set of possible locations where messages may exist. The UE checks each possible location until it finds the one that belongs to it. Common vs UE specific Search SpaceIn 5G, search spaces are divided into two main types. These are Common Search Space and UE-specific Search Space. This separation is important because the UE behavior changes depending on its connection state. The Common Search Space is used for signals that are relevant to all UEs or to UEs that are not yet fully connected. This search space is configured in a way that every UE in the cell can monitor it without needing dedicated signaling. It is mainly used during initial access and for broadcast or system-level information. For example, when a UE is trying to access the network, it uses the Common Search Space to detect control information related to SIB1 or RACH procedures. During the random access process, the UE monitors PDCCH in the Common Search Space to detect DCI such as Msg2 or Msg4 scheduling. Also, paging indication using P-RNTI is typically detected in this common region. Because the UE does not yet have a dedicated configuration, the Common Search Space acts as a shared monitoring area. Every UE knows where to look based on predefined or broadcast configuration. The UE-specific Search Space is different. This search space is dedicated to a particular UE. It is configured through RRC signaling after the UE establishes a connection with the network. This means the UE must be in RRC_CONNECTED state to receive and use this configuration. In UE-specific Search Space, the gNB assigns a customized set of PDCCH candidates for that UE. This allows more efficient and flexible scheduling. The network can optimize control signaling for each UE individually, reducing unnecessary blind decoding and improving performance. From UE perspective, the usage is state-dependent. Before connection establishment, the UE relies only on Common Search Space. It monitors shared control regions to receive essential system information and complete access procedures. After connection establishment, the UE also uses UE-specific Search Space for dedicated control signaling. This separation improves overall system efficiency. Common Search Space ensures that all UEs can receive essential information without prior configuration. UE-specific Search Space enables optimized and targeted communication once the UE is connected. In simple terms, Common Search Space is like a public notice board that everyone can read. UE-specific Search Space is like a private mailbox assigned to each UE after it becomes fully connected.
Summary Table of Search Space TypesThis table provides a high-level map of how different PDCCH search space types are used in 5G. It shows that the network does not use a single search method for all control messages. Instead, it defines several search space categories, and each category is associated with a specific purpose, a specific RNTI, and a specific stage of UE operation. Some search spaces are common and are meant for all UEs, especially during system information reading, random access, and paging. Others are UE-specific and are used after dedicated configuration is established for an individual UE. Overall, the table helps explain how 5G organizes control-channel monitoring in a structured way so that the UE knows where to look for different kinds of signaling depending on its state and the type of message being delivered. < Summary of Search Space Type, based on 38.213 - 10.1 >
< Summary of Search Space Type and RRC Configuration, based on 38.213 - 10.1 >
Examples
Example 01The RRC examples show here illustrate the transition of a UE from "listening to the general public announcements" to "having its own private conversation" with the network. The interplay here is essentially a handover of configurations: as the UE moves from an Idle state to a Connected state (and potentially switches bandwidth), the network updates the "where and how" of monitoring the control channel. The high level structure of this example is as follows : Stage A is the public entry phase of control-channel configuration. At this stage, SIB1 provides the basic control information that every UE needs immediately after entering the cell. It defines the initial BWP and points the UE to the common search space that should be used before any dedicated configuration exists. In other words, this stage tells the UE where to look first for essential control information, including paging-related monitoring and random access related signaling.
Stage B represents the transition to a fully connected and personalized phase. After RRC Setup, the UE is no longer relying on shared control resources. Instead, the network provides UE-specific configuration, including a dedicated search space and associated CORESET. This allows the gNB to send control information tailored specifically to that UE, enabling more efficient and targeted scheduling that other UEs cannot interpret.
Stage C is the more advanced phase where the network moves the UE into an additional BWP and gives it a richer control-channel structure. At this point, the UE is no longer operating only with the initial common setup or a single dedicated search space. Instead, it receives both common and UE-specific control configurations within the new BWP. This means the UE must monitor shared control information for system-level events while also tracking its own dedicated control signaling for private traffic, making the operation more flexible and more sophisticated.
SIB 1 :------------------------------------------------------------------------ pdcch-ConfigCommon setup: { commonSearchSpaceList { { controlResourceSetId 0, monitoringSlotPeriodicityAndOffset sl1: NULL, monitoringSymbolsWithinSlot '10000000000000'B, nrofCandidates { aggregationLevel1 n0, aggregationLevel2 n0, aggregationLevel4 n4, aggregationLevel8 n0, aggregationLevel16 n0 }, dci-Format0-0-AndFormat1-0 { } } } }, },
RRCSetup without Additional BWP :------------------------------------------------------------------------ pdcch-Config setup: { controlResourceSetToAddModList { { controlResourceSetId 2, frequencyDomainResources '111111111111111110000000000000000000000000000'B, duration 1, cce-REG-MappingType nonInterleaved: NULL, precoderGranularity sameAsREG-bundle } }, searchSpacesToAddModList { { controlResourceSetId 2, monitoringSlotPeriodicityAndOffset sl1: NULL, monitoringSymbolsWithinSlot '10000000000000'B, nrofCandidates { aggregationLevel1 n0, aggregationLevel2 n4, aggregationLevel4 n0, aggregationLevel8 n0, aggregationLevel16 n0 }, dci-Formats formats0-1-And-1-1 } } } },
RRCSetup with Additional BWP :------------------------------------------------------------------------ spCellConfig { spCellConfigDedicated { initialDownlinkBWP { pdcch-Config setup: { controlResourceSetToAddModList { { controlResourceSetId 2, frequencyDomainResources '111111100000000000000000000000000000000000000'B, duration 1, cce-REG-MappingType nonInterleaved: NULL, precoderGranularity sameAsREG-bundle } }, searchSpacesToAddModList { { controlResourceSetId 2, monitoringSlotPeriodicityAndOffset sl1: NULL, monitoringSymbolsWithinSlot '10000000000000'B, nrofCandidates { aggregationLevel1 n0, aggregationLevel2 n4, aggregationLevel4 n1, aggregationLevel8 n0, aggregationLevel16 n0 }, dci-Formats formats0-1-And-1-1 } } } }, pdsch-Config setup: { dmrs-DownlinkForPDSCH-MappingTypeA setup: { ... }, tci-StatesToAddModList { ... }, resourceAllocation resourceAllocationType1, rbg-Size config1, prb-BundlingType staticBundling: { bundleSize wideband }, zp-CSI-RS-ResourceToAddModList { ... } }, downlinkBWP-ToAddModList { { bwp-Id 1, bwp-Common { genericParameters { locationAndBandwidth 28875, subcarrierSpacing kHz30 }, pdcch-ConfigCommon setup: { commonSearchSpaceList { { controlResourceSetId 0, monitoringSlotPeriodicityAndOffset sl1: NULL, monitoringSymbolsWithinSlot '10000000000000'B, nrofCandidates { aggregationLevel1 n0, aggregationLevel2 n4, aggregationLevel4 n2, aggregationLevel8 n1, aggregationLevel16 n0 }, dci-Format0-0-AndFormat1-0 { } } } } }, pdsch-ConfigCommon setup: { ... }, bwp-Dedicated { pdcch-Config setup: { controlResourceSetToAddModList { { controlResourceSetId 4, frequencyDomainResources '111111111111111110000000000000000000000000000'B, duration 1, cce-REG-MappingType nonInterleaved: NULL, precoderGranularity sameAsREG-bundle } }, searchSpacesToAddModList { { controlResourceSetId 4, monitoringSlotPeriodicityAndOffset sl1: NULL, monitoringSymbolsWithinSlot '10000000000000'B, nrofCandidates { aggregationLevel1 n0, aggregationLevel2 n4, aggregationLevel4 n1, aggregationLevel8 n0, aggregationLevel16 n0 }, dci-Formats formats0-1-And-1-1 } } } }, pdsch-Config setup: { dmrs-DownlinkForPDSCH-MappingTypeA setup: { ... }, tci-StatesToAddModList { ... }, resourceAllocation resourceAllocationType1, ... }, zp-CSI-RS-ResourceToAddModList { ... } } } }, RRC Parameters
The RRC structure for Following is based on 38.331 v15.3.0 SearchSpace ::= SEQUENCE { searchSpaceId SearchSpaceId, controlResourceSetId ControlResourceSetId OPTIONAL,-- Cond Setup Only monitoringSlotPeriodicityAndOffset CHOICE { sl1 NULL, sl2 INTEGER (0..1), sl4 INTEGER (0..3), sl5 INTEGER (0..4), sl8 INTEGER (0..7), sl10 INTEGER (0..9), sl16 INTEGER (0..15), sl20 INTEGER (0..19), sl40 INTEGER (0..39), sl80 INTEGER (0..79), sl160 INTEGER (0..159), sl320 INTEGER (0..319), sl640 INTEGER (0..639), sl1280 INTEGER (0..1279), sl2560 INTEGER (0..2559) } monitoringSymbolsWithinSlot BIT STRING (SIZE (14)) OPTIONAL, -- Cond Setup nrofCandidates SEQUENCE { aggregationLevel1 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8}, aggregationLevel2 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8}, aggregationLevel4 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8}, aggregationLevel8 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8}, aggregationLevel16 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8} } OPTIONAL, -- Cond Setup searchSpaceType CHOICE { common SEQUENCE { dci-Format0-0-AndFormat1-0 SEQUENCE { ... } OPTIONAL, -- Need R dci-Format2-0 SEQUENCE { nrofCandidates-SFI SEQUENCE { aggregationLevel1 ENUMERATED {n1, n2} OPTIONAL, -- Need R aggregationLevel2 ENUMERATED {n1, n2} OPTIONAL, -- Need R aggregationLevel4 ENUMERATED {n1, n2} OPTIONAL, -- Need R aggregationLevel8 ENUMERATED {n1, n2} OPTIONAL, -- Need R aggregationLevel16 ENUMERATED {n1, n2} OPTIONAL -- Need R }, ... } OPTIONAL, -- Need R dci-Format2-1 SEQUENCE { ... } OPTIONAL, -- Need R dci-Format2-2 SEQUENCE { ... } OPTIONAL, -- Need R dci-Format2-3 SEQUENCE { monitoringPeriodicity ENUMERATED {n1, n2, n4, n5, n8, n10, n16, n20 } nrofPDCCH-Candidates ENUMERATED {n1, n2}, ... } OPTIONAL -- Need R }, ue-Specific SEQUENCE { dci-Formats ENUMERATED {formats0-0-And-1-0, formats0-1-And-1-1}, ... } } OPTIONAL -- Cond Setup } Value 0 identifies the common CORESET configured in MIB and in ServingCellConfigCommon Values 1..maxNrofControlResourceSets-1 identify CORESETs configured by dedicated signalling Followings are the highlevel grouping/summary of the RRC parameters The when: time domain control
The first role of SearchSpace is to define when the UE should monitor the PDCCH. This is done mainly by
The effort: blind decoding and nrofCandidatesThe second role of SearchSpace is to define how hard the UE must search for control information. The UE does not know the exact PDCCH location beforehand. Because of this, it performs blind decoding. This means it tries multiple possible PDCCH candidates until one of them produces a valid result.
The parameter
If a certain aggregation level is configured with zero candidates, the UE skips that level completely. This reduces processing burden and saves power. If several candidates are configured, the UE must try each one. Therefore,
The what: SearchSpaceType
The third role of SearchSpace is to tell the UE what type of control information to expect. This is determined by For Common Search Space, the UE expects messages that are relevant to all UEs or to UEs that do not yet have dedicated configuration. This includes paging, system information, and random access related control. In this case, the UE checks common RNTIs such as P-RNTI for paging or SI-RNTI for system information. The DCI formats used here are generally simpler and more robust. For UE-specific Search Space, the UE expects control messages intended only for itself. This is typically used after RRC connection is established. In this case, the UE mainly uses C-RNTI or other UE-specific identifiers, and the DCI formats can support more advanced scheduling features such as MIMO operation and BWP-specific control. So this parameter tells the UE what “language” is being spoken in that monitoring region.
The where: CORESET linkage
The fourth role of SearchSpace is to identify where in frequency the UE should look. This is done through In other words, SearchSpace says when to look, and CORESET says where to look in the spectrum. The UE first determines the slot and symbol from the SearchSpace configuration, and then it follows the linked CORESET to know which resource blocks and which control region structure to monitor. Without the CORESET link, the timing information alone would not be enough.
How these parameters work together
These parameters operate together as one coordinated receiver rule set. The UE first uses SearchSpace timing parameters to determine the monitoring slot and symbol. Then it uses the linked CORESET to determine the frequency resources for PDCCH. After that, it uses the SearchSpace type to decide which DCI formats and which RNTIs are relevant. Finally, it uses So the overall logic is straightforward. SearchSpace defines when to monitor. CORESET defines where to monitor. SearchSpaceType defines what kind of message to expect. nrofCandidates defines how much effort the UE should spend to find it.
Why this mattersThis configuration is important because PDCCH monitoring is one of the most sensitive parts of UE receiver operation. If monitoring is too frequent or too broad, battery consumption increases. If monitoring is too narrow or too infrequent, the UE may miss important control information. SearchSpace configuration is therefore a balance between detection reliability, scheduling flexibility, and power efficiency.
Reference[1] Type0-PDCCH common search space
|
|||||||||||||||||||||||||||||||||||||||||||