5G/NR - Type 3 PDCCH Common Search Space

 

 

 

Type 3 PDCCH Common Search Space

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

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.

What Type 3 actually carries

The answer to this is already on the page - it is sitting in the ASN.1 in the next section, and it is worth pulling out before reading the rest. Look at what appears under searchSpaceType.common :

   searchSpaceType CHOICE {
       common SEQUENCE {
           dci-Format0-0-AndFormat1-0   ...     <-- fallback unicast
           dci-Format2-0                ...     <-- slot format
           dci-Format2-1                ...     <-- pre-emption
           dci-Format2-2                ...     <-- power control, PUCCH / PUSCH
           dci-Format2-3                ...     <-- power control, SRS
       },
       ue-Specific SEQUENCE { ... }
   }

Those four 2_x formats are Type 3. You do not configure "a Type 3 search space" by naming it - you configure a common search space that declares one or more of these DCI formats, and that is what makes it Type 3. Written out :

DCI format RNTI What it does

2_0

SFI-RNTI

Tells a group of UEs the slot format - which symbols in the coming slots are downlink, uplink or flexible. Essential in TDD, where the pattern can change dynamically

2_1

INT-RNTI

Pre-emption indication : "the resources I gave you a moment ago were taken away and used for someone's URLLC traffic - discard them before you try to decode"

2_2

TPC-PUSCH-RNTI
TPC-PUCCH-RNTI

Transmit power control commands for PUSCH and PUCCH, for many UEs in one message

2_3

TPC-SRS-RNTI

The same idea for SRS power control

0_0 / 1_0

C-RNTI, MCS-C-RNTI,
CS-RNTI

Ordinary unicast scheduling in the fallback formats. This is the rung above Type1 in the fallback ladder on the Type1 page

What ties those together is the word "group-common", and it does not mean broadcast. This is the distinction that makes Type 3 click. A broadcast message says the same thing to everybody. A group-common DCI is one message containing many separate answers, and each UE is told in advance which part of it to read :

   one DCI 2_2, sent once, read by many UEs

   +--------+--------+--------+--------+--------+--------+ ...
   | TPC #0 | TPC #1 | TPC #2 | TPC #3 | TPC #4 | TPC #5 |
   +--------+--------+--------+--------+--------+--------+
        ^                 ^
        |                 |
     UE A was told        UE B was told
     tpc-Index = 0        tpc-Index = 2
     so it reads          so it reads
     only this block      only this block

Every one of the 2_x formats works this way, and the RRC configuration always gives the UE a pointer into the message :

DCI The field that points into it Configured in

2_0

positionInDCI

SlotFormatIndicator, per serving cell

2_1

positionInDCI

DownlinkPreemption

2_2

tpc-Index, tpc-IndexPCell

PUSCH-TPC-CommandConfig, PUCCH-TPC-CommandConfig

2_3

startingBitOfFormat2-3

SRS-TPC-CommandConfig

So the efficiency argument for Type 3 is concrete. Sending a power control command to fifty UEs individually would cost fifty PDCCHs. Sending one DCI 2_2 that fifty UEs each read one slice of costs one. That is the whole reason this search space exists.

A cross-check against the other pages in this series

A few statements in the sections above are worth reconciling with the Type1 and Type2 pages, because the three pages currently allocate a couple of jobs differently :

Job Said here Per 38.213 - 10.1 RNTI that settles it

Random Access Response

Type2

Type1

RA-RNTI - and the Type1 page describes exactly this

Paging

given as a
Type3 example

Type2

P-RNTI = 0xFFFE, and no other search space uses it

System information

opening paragraph
says Type3

Type0 / Type0A

SI-RNTI = 0xFFFF. The Interaction section below says this correctly

The RNTI column is what makes these easy to settle in practice. Each of those identities is used by exactly one search space type, so whatever a DCI is scrambled with tells you unambiguously which search space it belongs in - and none of RA-RNTI, P-RNTI or SI-RNTI is ever monitored in Type 3.

NOTE : one small terminology point while we are here - RMSI is usually expanded as Remaining Minimum System Information rather than Required. "Remaining" because the MIB carries the first slice and RMSI (SIB1) carries what is left.

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

            }

Two things in that ASN.1 are worth a second look.

The first is that Type 3 has no dedicated pointer field. Every other common search space is found by a named field - searchSpaceZero for Type0, ra-SearchSpace for Type1, pagingSearchSpace for Type2. There is no "type3SearchSpace". Instead, a search space becomes Type 3 by declaring the group-common DCI formats inside searchSpaceType.common. It is defined by its contents rather than by a label, and that is why the network can configure several of them.

The second is dci-Format0-0-AndFormat1-0. That entry is what allows a common search space to carry ordinary unicast scheduling with a C-RNTI. It is the mechanism behind the fallback ladder on the Type1 page - when a UE has a C-RNTI but no UE specific search space yet, a Type 3 CSS with this field present is where it can still be scheduled.

The other fields in the SearchSpace IE are common to every search space type, not just this one :

Field What it fixes

controlResourceSetId

Which CORESET this search space lives in - the frequency resources and symbol count

monitoringSlotPeriodicityAndOffset

How often the UE wakes to look, and in which slot of the period

duration

How many consecutive slots the monitoring continues once it starts

monitoringSymbolsWithinSlot

A 14 bit map - which symbols inside the slot carry the monitoring occasion

nrofCandidates

How many blind decodes to attempt at each aggregation level

NOTE : the dummy1 and dummy2 fields you can see inside dci-Format2-3 are genuinely called that in 38.331. They are placeholders left behind when the design changed during standardisation, kept in the ASN.1 so that the encoding stays backward compatible. If you have ever wondered whether you are misreading the specification when you meet them - you are not.

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.

Here is the whole family in one place, which also makes the point your Interaction section is driving at :

Search space Found via RNTIs Serving cell

Type0 / 0A

searchSpaceZero,
searchSpaceOtherSystemInformation

SI-RNTI

Primary cell only

Type1

ra-SearchSpace

RA-RNTI, MsgB-RNTI,
TC-RNTI

Primary cell only

Type2

pagingSearchSpace

P-RNTI

Primary cell only

Type3

no dedicated field - any SearchSpace whose searchSpaceType is common

SFI, INT, TPC-*,
and C-RNTI

Not restricted to the primary cell

USS

searchSpaceType = ue-Specific

C-RNTI and friends

Any serving cell

That last column is a real difference and not a detail. Types 0, 0A, 1 and 2 all exist to get a UE onto the network - find the cell, read the system information, do random access, be paged - and all of that happens on the primary cell by definition. Type 3 does none of those jobs. It carries slot format, pre-emption and power control, which are things a UE needs on every carrier it is using. So it is the only common search space that naturally belongs on a secondary cell as well.

Your point about differentiation is the key one, and the RNTI is what carries it. A UE may be monitoring a Type 3 CSS and its own USS in the very same CORESET, in the same slot. It separates them by trying each candidate against each RNTI it holds - and because SFI-RNTI, INT-RNTI, the TPC-RNTIs and its C-RNTI are all different values, whichever one produces a passing CRC also tells the UE what kind of message it just found.

Reference