PDCCH Common refers to the parameters specified in PDCCH-ConfigCommon and it define how various common search spaces (e.g., for system information, paging, and random access) are signaled in NR (Refer to this page if you want to know of the details of various search space).
The highlights of the configurations are as follows. If the network omits any of these optional fields, the UE does not attempt to decode the corresponding common search space in that particular DL BWP. Every field in the list is marked OPTIONAL in the ASN.1, ra-SearchSpace included.
controlResourceSetZero : Interpreted in the same way as the MIB parameter pdcch-ConfigSIB1. Although it is only explicitly configured in the initial DL BWP (BWP#0), it may still be referenced by search spaces in other DL BWPs.commonControlResourceSet : Provides an extra CORESET for Random Access Response (RAR), paging, or additional system information. If configured, the network assigns it a non-zero ControlResourceSetId.searchSpaceZero : Mirrors the bits from pdcch-ConfigSIB1 in the MIB. Like controlResourceSetZero, it is configured in the initial BWP but can also be utilized in other DL BWPs.commonSearchSpaceList : A collection (size 1–4) of additional common search spaces, each assigned a non-zero SearchSpaceId, for purposes such as paging or system information reception.searchSpaceSIB1 : Designates a search space ID for SIB1. If absent, the UE does not monitor for SIB1 in this BWP.searchSpaceOtherSystemInformation : Designates a search space ID for other system information (SIB2 and beyond). If absent, the UE does not monitor for those SIBs in this BWP.pagingSearchSpace : Points to the search space ID where paging DCI is found. If absent, the UE does not monitor for paging on this BWP.ra-SearchSpace : Specifies the search space ID for receiving the Random Access Response (RAR). The field is mandatory present in the DL BWP(s) only when the conditions of 38.321 clause 5.15 are met, so it is conditional rather than always present.
Even though CORESET #0 and SearchSpace #0 are initially defined in the MIB, the specification allows (and sometimes requires) these same parameters to be signaled again through controlResourceSetZero and searchSpaceZero in PDCCH-ConfigCommon. In other words, the duplication ensures that the same MIB-defined parameters for CORESET #0 and search space #0 can be referenced or tweaked at the RRC layer and reused across BWPs, rather than being tied solely to the initial-access settings from the MIB.
The main reasons are:
Reusability in Other BWPs : MIB settings primarily apply to the initial downlink bandwidth part (BWP) for early access. By copying them into controlResourceSetZero and searchSpaceZero, the network can explicitly reuse—or reference—those same CORESET #0 and search space #0 definitions in additional BWPs if needed.RRC-Based Configuration : MIB transmission has strict payload limits and mainly provides “bootstrap” information. More comprehensive or revised signaling occurs via RRC. Placing controlResourceSetZero and searchSpaceZero within PDCCH-ConfigCommon lets the network adjust or reconfirm these parameters at the RRC level, rather than being locked into only what is signaled in the MIB.Consistency and Future Changes : By carrying over the same CORESET #0 and search space #0 definitions into PDCCH-ConfigCommon, the UE has a single, well-defined configuration source for all BWPs (not just the initial one). If the network ever needs to reconfigure aspects of CORESET #0 or search space #0, it can do so through RRC messages, without changing the MIB. This design also maintains consistency across different bandwidth parts and operational scenarios.
This is stated in 38.331 but I think this would need some interpretation. To me, it is a little bit ambiguous.
- controlResourceSetZero : Parameters of the common CORESET#0 which can be used in any common or UE-specific search spaces. The values are interpreted like the corresponding bits in MIB pdcch-ConfigSIB1. Even though this field is only configured in the initial BWP (BWP#0) controlResourceSetZero can be used in search spaces configured in other DL BWP(s) than the initial DL BWP if the conditions defined in TS 38.213, clause 10 are satisfied.
- searchSpaceZero : Parameters of the common SearchSpace#0. The values are interpreted like the corresponding bits in MIB pdcch-ConfigSIB1. Even though this field is only configured in the initial BWP (BWP#0) searchSpaceZero can be used in search spaces configured in other DL BWP(s) than the initial DL BWP if the conditions defined in TS 38.213, clause 10 are satisfied.
The statement mentions about a specific condition 'if the conditions defined in TS 38.213 , clause 10 are satisfied'. What would it mean ?
My guess is it refers to the following statement of TS 38.213-10.1
If the active DL BWP and the initial DL BWP for a UE have same SCS and same CP length and the active DL BWP includes all RBs of the CORESET with index 0, or the active DL BWP is the initial DL BWP, or the active DL BWP includes all RBs of an MBS frequency resource provided by cfr-ConfigMCCH-MTCH as described in clause 18, the CORESET configured for Type0-PDCCH CSS set has CORESET index 0 and the Type0-PDCCH CSS set has search space set index 0.
This can be interpreted as follows
There are specific technical requirements—mostly around subcarrier spacing, cyclic prefix type, and frequency coverage—that must be met before CORESET #0 (originally defined in the initial BWP) can be validly reused in another DL BWP. These conditions ensure that the same CORESET #0 resources (i.e., frequency and time allocations) make physical sense in the new bandwidth part.
- For example, clause 10 in TS 38.213 describes that, to reuse CORESET #0 in another BWP:
- The active DL BWP must have the same subcarrier spacing and CP length as the initial BWP.
- The active DL BWP must cover all the RBs (resource blocks) used by CORESET #0.
- Certain additional checks (e.g., for broadcast or MBS usage) may apply.
RRC Parameters
Everything on this page is configured through one information element, and reading it in full is the quickest way to see which search spaces a BWP can carry. Each common search space is referenced by a SearchSpaceId rather than defined here. This IE therefore decides which roles exist in the BWP, and SearchSpace decides how each one is monitored.
The listing below is the whole IE as it now stands, not just the Release 15 core. Everything after the
Following is based on
PDCCH-ConfigCommon ::= SEQUENCE {
controlResourceSetZero ControlResourceSetZero OPTIONAL, -- Cond InitialBWP-Only
commonControlResourceSet ControlResourceSet OPTIONAL, -- Need R
searchSpaceZero SearchSpaceZero OPTIONAL, -- Cond InitialBWP-Only
commonSearchSpaceList SEQUENCE (SIZE(1..4)) OF SearchSpace OPTIONAL, -- Need R
searchSpaceSIB1 SearchSpaceId OPTIONAL, -- Need S
searchSpaceOtherSystemInformation SearchSpaceId OPTIONAL, -- Need S
pagingSearchSpace SearchSpaceId OPTIONAL, -- Need S
ra-SearchSpace SearchSpaceId OPTIONAL, -- Need S
...,
[[
firstPDCCH-MonitoringOccasionOfPO CHOICE {
... -- one alternative per SCS and paging cycle fraction, INTEGER (0..139) up to (0..17919)
} OPTIONAL -- Cond OtherBWP
]],
[[
commonSearchSpaceListExt-r16 SEQUENCE (SIZE(1..4)) OF SearchSpaceExt-r16 OPTIONAL -- Need R
]],
[[
sdt-SearchSpace-r17 CHOICE {
newSearchSpace SearchSpace,
existingSearchSpace SearchSpaceId
} OPTIONAL, -- Need R
searchSpaceMCCH-r17 SearchSpaceId OPTIONAL, -- Need R
searchSpaceMTCH-r17 SearchSpaceId OPTIONAL, -- Need S
commonSearchSpaceListExt2-r17 SEQUENCE (SIZE(1..4)) OF SearchSpaceExt-v1700 OPTIONAL, -- Need R
firstPDCCH-MonitoringOccasionOfPO-v1710 CHOICE {
... -- adds the 480 kHz alternatives
} OPTIONAL, -- Need R
pei-ConfigBWP-r17 SEQUENCE {
pei-SearchSpace-r17 SearchSpaceId,
firstPDCCH-MonitoringOccasionOfPEI-O-r17 CHOICE {
... -- one alternative per SCS, INTEGER (0..139) up to (0..71679)
}
} OPTIONAL -- Cond InitialBWP-Paging
]],
[[
followUnifiedTCI-State-v1720 ENUMERATED {enabled} OPTIONAL -- Need R
]],
[[
applyIndicatedTCI-State-r18 ENUMERATED {first, second, both, none} OPTIONAL, -- Cond FollowUTCI
commonSearchSpaceListExt-r18 SEQUENCE (SIZE(1..4)) OF SearchSpaceExt-v1800 OPTIONAL, -- Need R
searchSpaceMulticastMCCH-r18 SearchSpaceId OPTIONAL, -- Need R
searchSpaceMulticastMTCH-r18 SearchSpaceId OPTIONAL -- Need S
]],
[[
commonSearchSpaceListExt-r19 SEQUENCE (SIZE(1..4)) OF SearchSpaceExt-v1800 OPTIONAL, -- Need R
pagingAdaptFirstPDCCH-MonitoringOccasionOfPO-r19 CHOICE {
... -- as firstPDCCH-MonitoringOccasionOfPO, extended for paging adaptation
} OPTIONAL, -- Cond OtherBWP
pagingAdaptFirstPDCCH-MonitoringOccasionOfPEI-O-r19 CHOICE {
... -- as firstPDCCH-MonitoringOccasionOfPEI-O-r17, extended for paging adaptation
} OPTIONAL -- Cond InitialBWP-Paging
]]
}
ControlResourceSetZero ::= INTEGER (0..15)
SearchSpaceZero ::= INTEGER (0..15)
- 38.331 states ID of the search space for SIB1 message. If the field is absent, the UE does not receive SIB1 in this BWP.
-
38.213-10.1 states : For a DL BWP, if a UE is not provided searchSpaceSIB1 for Type0-PDCCH CSS set by PDCCH-ConfigCommon, the UE does not monitor PDCCH candidates for a Type0-PDCCH CSS set on the DL BWP. The Type0-PDCCH CSS set is defined by the CCE aggregation levels and the number of PDCCH candidates per CCE aggregation level given in Table 10.1-1.
|
CCE Aggregation Level |
Number of Candidates |
|---|---|
|
4 |
4 |
|
8 |
2 |
|
16 |
1 |
The fields below arrived after Release 15, inside the extension groups. They matter here because each one adds a further role that a common search space can be given, which is the same job the Release 15 fields do.
Reference
[1] Type0-PDCCH common search space