The Type-3 PDCCH Common Search Space is a critical element in 5G NR for broadcasting system information and ensuring network accessibility. Its configuration and interaction with other search spaces provide a balanced approach to resource utilization while catering to both common and dedicated signaling requirements. This setup ensures a robust and scalable mechanism for control channel operations in diverse network conditions.

NOTE : For formal description of this type of search space, refer to 38.213-10.1

• Purpose and Usage
• Configuration
• Interaction With Other Search Spaces

NOTE : For the concept of all search space and comparision among different types of search space, refer to this note.

Purpose and Usage

Type 3 PDCCH common search space is a group-common search space used to carry control information that is intended for either all UEs or a specific group of UEs within a cell.

Type 3 PDCCH common search space in 5G NR is a flexible, RRC-configured group-common resource that the network uses to transmit control information intended for multiple UEs simultaneously. It complements the other common search space types (0, 0A, 1, 2) by offering a way to broadcast or group-schedule messages that do not fall under the initial access or random access procedures.

• Group-Common or Broadcast Messages
• It is typically used when the gNB (the 5G base station) needs to send control information or downlink grants in a “group-common” fashion.
• Examples include paging occasions, system information updates (beyond RMSI), and other control messages that multiple UEs may need to read simultaneously.
• RRC-Configured
• Unlike type0 or type1 (commonly used for RMSI or SIB1), the type3 search space is often configured via RRC signaling.
• The network can flexibly configure or reconfigure the type3 search space parameters depending on system load, deployment scenarios, or changes to broadcast scheduling.
• CORESET Association
• Like all PDCCH search spaces, type3 search space is associated with one or more CORESET(s) (Control Resource Sets).
• The configuration tells the UE in which CORESET and at which time/frequency occasions it must monitor for type3 PDCCH.
• Not for Random Access Response
• Random Access Responses (RAR) typically use type2 CSS.
• RMSI (Required Minimum System Information) typically uses type0 or type0A.

Configuration

The gNB signals one or more search spaces to the UE (either broadcast via system information or dedicated via RRC messages). Each search space is associated with:

• A CORESET (which defines the physical resources in the frequency-time domain).
• Monitoring periodicity, offset, and duration (when and for how many slots the UE should monitor).
• Aggregation levels and the number of PDCCH candidates (how many possible control channel candidates the UE tries to decode in each search space).
• Search space type (common or UE-specific). For a common search space, the RRC indicates which “type” (Type0, Type1, Type2, Type3, etc.) is being configured.

 

PDCCH-Config ::= SEQUENCE {

...

searchSpacesToAddModList SEQUENCE(SIZE (1..10)) OF SearchSpace OPTIONAL, -- Need N

...

}

SearchSpace ::= SEQUENCE {

searchSpaceId SearchSpaceId,

controlResourceSetId ControlResourceSetId OPTIONAL, -- Cond SetupOnly

monitoringSlotPeriodicityAndOffset CHOICE {

...

} OPTIONAL, -- Cond Setup4

duration INTEGER (2..2559) OPTIONAL, -- Need S

monitoringSymbolsWithinSlot BIT STRING (SIZE (14)) OPTIONAL, -- Cond Setup

nrofCandidates SEQUENCE {

...

} 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 {

dummy1 ENUMERATED {sl1, sl2, sl4, sl5, sl8, sl10, sl16, sl20} OPTIONAL, -- Cond Setup

dummy2 ENUMERATED {n1, n2},

...

} OPTIONAL -- Need R

},

ue-Specific SEQUENCE {

...

}

} OPTIONAL -- Cond Setup2

}

Interaction With Other Search Spaces

Type-3 Common Search Space (CSS) is one of several common PDCCH search spaces in 5G NR, each designed for different broadcast or group-common purposes. It generally serves as a configurable resource for group-oriented or broadcast messages beyond the initial and random-access procedures handled by other search space types. Below is an overview of how Type-3 CSS interacts with other search spaces:

• UE-Specific Search Spaces (USS)
• Dedicated Control: UE-Specific Search Spaces (USS) carry downlink control information addressed to individual UEs (via C-RNTI, for example).
• Coexistence: A UE in connected mode may simultaneously monitor:
• A common search space (like Type-3) for group or broadcast messages.
• Its own UE-specific search space for dedicated scheduling or commands.
• Differentiation: UEs distinguish among different search spaces by their IDs, controlResourceSetId, and the RNTI used in DCI messages.
• Control Channel Prioritization
• Resource Allocation: While there is no universal rule that “Type-3 always has highest priority,” the gNB can configure different priorities and resource allocations per search space to avoid conflicts.
• Essential Broadcast: Critical system info (like SIB1) typically resides in Type-0/Type-0A/Type-1 CSS rather than Type-3. However, Type-3 can still carry important group-oriented signaling when so configured by the network.
• Scheduling Overlaps: If Type-3 CSS overlaps with a UE-specific search space, the UE relies on RNTI and DCI format to discern which messages apply. Operators manage these overlaps to ensure reliable decoding.

Reference