Type2-PDCCH CSS is a common search space specifically allocated for paging. It is configured by the network via the pagingSearchSpace parameter in PDCCH-ConfigCommon on the primary cell (PCell) of the UE’s master cell group.

Type2-PDCCH CSS is the dedicated search space for paging in 5G NR. By configuring the pagingSearchSpace parameter, the network instructs UEs to monitor for paging messages in a specific CORESET region at defined monitoring occasions, ensuring that UEs can be reached efficiently when they are not in active data transmission.

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

• Purpose and Usage
• When does the UE actually wake up ?
• 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

Type2-PDCCH CSS serves as the dedicated common search space for paging. Its primary role is to carry paging-related downlink control information (DCI) with CRC scrambled by the P-RNTI (Paging-RNTI). In other words, when the network needs to inform a UE in RRC Idle or RRC Inactive states about incoming data or system reconfiguration, it broadcasts paging messages using this CSS. Because every UE in the cell potentially needs to monitor paging, the Type2-PDCCH CSS ensures a standardized way of broadcasting those messages across all UEs.

• Type2-PDCCH CSS is specifically designated for paging.
• It carries DCI with CRC scrambled by the P-RNTI, enabling paging messages to reach UEs in RRC Idle or Inactive states.
• Because paging is broadcast to all UEs, this common search space ensures a standardized mechanism for distributing paging notices.

Two things are worth adding to that, because they are what you actually meet in a log.

P-RNTI is a constant. Unlike a C-RNTI, it is never assigned to anybody - it is fixed in the specification, exactly like SI-RNTI :

     P-RNTI   = 0xFFFE   (65534)      paging
     SI-RNTI  = 0xFFFF   (65535)      system information

It has to be a constant, for the same reason SI-RNTI does : the message is addressed to everyone, including UEs the network has never spoken to. There is nobody to signal an RNTI to in advance.

Paging is a two stage affair. Finding a DCI with P-RNTI does not mean the UE is being paged - it only means somebody in the cell is :

   stage 1   PDCCH   DCI format 1_0, CRC scrambled with P-RNTI
                        found in the Type2-PDCCH CSS
                              |
                              v
   stage 2   PDSCH   the Paging message, carrying a pagingRecordList
                              |
                              v
             the UE looks for its own identity in that list
                 - not there  -> go back to sleep, this was for someone else
                 -     there  -> start random access and respond

So on a busy cell a UE may decode paging PDSCHs regularly and answer almost none of them. The first stage costs it very little ; the second is where the real filtering happens.

And sometimes there is no second stage at all. The DCI itself carries a small payload called the Short Message, and a 2 bit indicator that says what is present :

The short message itself is 8 bits, and the two that matter most are systemInfoModification - the system information is about to change, go and re-read it - and etwsAndCmasIndication - an earthquake, tsunami or public warning is being broadcast.

That is a genuinely useful piece of design. Telling every UE in a cell "the SI has changed" needs no data at all, so NR lets it ride entirely inside the paging DCI. If you are watching a log and see a P-RNTI DCI with no paging PDSCH following it, this is almost always why - and nothing is broken.

NOTE : paging comes from two different places and both arrive here. CN paging reaches a UE in RRC_IDLE and identifies it by its 5G-S-TMSI ; RAN paging reaches a UE in RRC_INACTIVE and identifies it by its I-RNTI. Both are carried by a DCI with P-RNTI in the Type2-PDCCH CSS - the difference is inside the paging record, not in how the UE finds it.

When does the UE actually wake up ?

The section above says the network configures "monitoring occasions", and that is the part worth unpacking, because it is the whole reason paging works at all. A UE in idle cannot keep its receiver on - it would flatten the battery in hours. So it sleeps, and wakes up at a small number of precisely agreed instants. The agreement has to be reached with no signalling, because the UE is asleep, so it is done by formula.

38.304 - 7.1 defines the two numbers the UE needs : which radio frame to wake in (the Paging Frame) and which occasion inside it (the Paging Occasion) :

   Paging Frame :   (SFN + PF_offset) mod T  =  (T div N) x (UE_ID mod N)

   Paging Occasion: i_s = floor(UE_ID / N) mod Ns

      T          the UE's paging cycle, in radio frames   32 / 64 / 128 / 256
      N          how many paging frames exist within T    T, T/2, T/4, T/8, T/16
      Ns         paging occasions per paging frame        1, 2 or 4
      PF_offset  offset applied to the frame calculation
      UE_ID      5G-S-TMSI mod 1024

Everything turns on that last line. The UE's wake-up time is derived from its own identity. Nobody tells it when to wake ; it works it out, and the network - which knows the same identity - works out the same answer independently. Exactly the same trick as the RA-RNTI on the Type1 page, used for a different purpose.

A worked example makes it concrete. Take a fairly typical configuration :

   defaultPagingCycle = rf128     ->  T  = 128 radio frames = 1.28 s
   nAndPagingFrameOffset quarterT ->  N  = 32,  PF_offset = 0
   ns = one                       ->  Ns = 1
   this UE's 5G-S-TMSI mod 1024   ->  UE_ID = 300

   Paging Frame :
       (SFN + 0) mod 128 = (128 div 32) x (300 mod 32)
                         = 4 x 12
                         = 48
       -> SFN = 48, 176, 304, 432 ...        i.e. once every 128 frames

   Paging Occasion :
       i_s = floor(300 / 32) mod 1 = 0      the only occasion in that frame

So this UE opens its receiver once every 1.28 seconds, for a couple of slots, and sleeps the rest of the time. That is the entire idle mode power story in one calculation.

And the spreading is deliberate. Change nothing but the identity and the answer moves :

     UE_ID = 300   ->  wakes at SFN 48, 176, 304 ...
     UE_ID = 301   ->  wakes at SFN 52, 180, 308 ...
     UE_ID = 302   ->  wakes at SFN 56, 184, 312 ...

   with N = 32, the 1024 possible UE_ID values spread across 32 different paging frames,
   four frames apart, so the cell's paging load is smeared evenly across the cycle
   instead of every UE waking at once

That is why N exists as a separate parameter from T. T decides how often each UE wakes - a battery and latency trade. N decides how widely the population is spread - a capacity trade. A large cell with many idle UEs wants a large N so that no single frame has to carry everyone's paging records.

Configuration

The network enables Type2-PDCCH CSS through the pagingSearchSpace parameter in PDCCH-ConfigCommon. This parameter specifies how many PDCCH candidates a UE should monitor for paging, along with the monitoring occasions and aggregation levels. If the UE is not signaled any pagingSearchSpace setting (for instance, if it is omitted), the UE does not monitor for paging DCI in that bandwidth part. The pagingSearchSpace thus explicitly instructs the UE where and when in the core resource set (CORESET) it should decode for paging messages.

• The network activates Type2-PDCCH CSS through the pagingSearchSpace parameter in PDCCH-ConfigCommon.
• This parameter defines the monitoring periodicity, offset, and PDCCH candidates (including aggregation levels) to be used for paging detection.
• If the UE does not receive any pagingSearchSpace configuration, it does not monitor for paging DCI in that bandwidth part.

Those monitoring parameters do not live in the search space itself - they come from PCCH-Config, which SIB1 carries alongside it. These are the fields that feed the formulas in the section above :

NOTE : the UE's own cycle can be shorter than the cell's. If upper layers have given the UE a UE specific DRX cycle, T is the smaller of that and defaultPagingCycle. So defaultPagingCycle is a ceiling for the cell, not necessarily the value every UE uses.

One distinction worth keeping sharp in your last bullet, because two different configurations produce two different behaviours and only one of them is "no paging" :

The middle row is common in simple deployments, and it is worth recognising in a log : if you see paging DCIs arriving in the same CORESET as SIB1, nothing is wrong - pagingSearchSpace is just set to 0.

Interaction With Other Search Spaces

Because Type2-PDCCH CSS is reserved for P-RNTI paging messages, it operates independently from other CSS types—Type0-PDCCH CSS (system information), Type1-PDCCH CSS (random access), and Type3-PDCCH CSS (various common RNTIs such as TPC or INT). UEs typically monitor paging alongside any other configured search spaces, but paging messages remain confined to the Type2-PDCCH CSS. In other words, while the UE may also be monitoring Type0 for SI or Type1 for random-access responses, it looks specifically to the Type2-PDCCH CSS for paging DCI.

• Paging in Type2-PDCCH CSS is independent of other CSS types—e.g., Type0 for system information, Type1 for random access, and Type3 for TPC or INT-related RNTIs.
• UEs may monitor multiple CSSs concurrently, but paging always appears in Type2-PDCCH CSS (scrambled by the P-RNTI).
• No overlap in RNTI usage occurs with other CSS sets, thus preventing confusion or collisions in control information

It is worth asking why paging needed a search space of its own rather than sharing one. Two properties make it genuinely different from everything else :

• Its audience is every UE in the cell, including ones the network has no connection to. That rules out any UE specific search space immediately.
• It is the only downlink control channel a UE monitors while it is asleep. Everything else on this list is monitored by a UE that is awake and doing something. Paging has to work on a duty cycle measured in seconds, which is why its monitoring occasions are computed from an identity rather than configured.

Put the family side by side and the division of labour is clear :

Your last bullet - that there is no overlap in RNTI usage - is the property that makes all of this safe. Because P-RNTI is 0xFFFE and nothing else uses it, a UE that finds a passing CRC in the Type2 occasions knows without any further check that what it has is paging. The search space tells it where to look ; the RNTI tells it what it found. Neither alone would be enough.

Reference