Type 1 PDCCH Common Search Space is a subset of NR PDCCH Search Space that is dedicated to transmit the PDCCH with RA RNTI, TC-RNTI,C-RNTI on a primary cell. It means UE would monitor this search space during the whole period of RACH process. It means that UE searches this space in order to find DCIs for Msg2(PDSCH), Msg4(PDSCH) in the RACH process

Type1-PDCCH CSS is the common search space the UE relies on for receiving downlink control information associated with the random-access procedure on its primary cell. Without it being configured (via ra-SearchSpace), the UE has no way to detect the RA Response (RAR), MsgB, or TC-RNTI-based DCI in that cell.

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

• Purpose and Usage
• Configuration
• Fallback for C-RNTI
• 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

This search space is primarily used for random-access–related DCIs on the UE’s primary cell. Specifically, it carries downlink control information with CRCs scrambled by the RA-RNTI (Random-Access RNTI), the MsgB-RNTI (used for certain MsgB transmissions in multi-step random access), and the TC-RNTI (Temporary C-RNTI assigned during random access). Hence, it is crucial for receiving Random Access Response (RAR) messages and other initial-access or temporary signaling.

• It is primarily used for random-access–related DCIs on the UE’s primary cell. Specifically, it carries downlink control information with CRCs scrambled by:
• RA-RNTI (Random-Access RNTI)
• MsgB-RNTI (used for certain MsgB transmissions in multi-step random access)
• TC-RNTI (Temporary C-RNTI assigned during random access)
• Hence, this search space is crucial for receiving Random Access Response (RAR) messages and other initial-access or temporary signaling.

Those three RNTIs are not an arbitrary list. They correspond one-for-one to the points in the random access procedure where the network has to send the UE a downlink assignment - and at every one of those points, the UE does not yet have a C-RNTI to be addressed by. Laid against the RACH messages :

So the whole of Type1-PDCCH CSS exists to solve one problem : how does a network schedule a UE it cannot yet address? Everywhere else in NR the gNB puts a C-RNTI on the DCI CRC and the right UE picks it up. During random access there is no C-RNTI yet, so a different identity has to be used - and the search space those identities live in is this one.

The moment contention resolution succeeds, the TC-RNTI is promoted to a real C-RNTI, the UE gets its own UE specific search space, and it stops depending on Type1 for normal traffic. Type1-PDCCH CSS is the scaffolding, not the building.

How RA-RNTI and MsgB-RNTI are worked out

There is one more question hiding in the table above. If the UE has no identity yet, how do the UE and the gNB agree on what the RA-RNTI is? Neither can signal it to the other - signalling is the very thing that has not started.

The answer is that it is not assigned, it is calculated, by both sides independently, from the time and frequency position of the PRACH occasion the preamble was sent in :

  RA-RNTI = 1 + s_id + 14 x t_id + 14 x 80 x f_id + 14 x 80 x 8 x ul_carrier_id

     s_id            first OFDM symbol of the PRACH occasion      0 .. 13
     t_id            first slot of the PRACH occasion in a frame  0 .. 79
     f_id            index of the PRACH occasion in frequency     0 .. 7
     ul_carrier_id   0 for the normal uplink, 1 for SUL

  worked example :  preamble sent in symbol 0, slot 10, frequency occasion 0, normal UL
                    RA-RNTI = 1 + 0 + 14x10 + 0 + 0 = 141  (0x008D)

Because every term comes from where and when the preamble was transmitted, and both ends know that, the two arrive at the same number with nothing exchanged. The gNB is effectively addressing a PRACH occasion rather than a device. If two UEs pick the same occasion they compute the same RA-RNTI and both read the same RAR - which is exactly why contention resolution is needed afterwards.

MsgB-RNTI is the same expression with one extra term added :

  MsgB-RNTI = RA-RNTI  +  14 x 80 x 8 x 2
                       = RA-RNTI  +  17920

     RA-RNTI   range :      1 .. 17920      (0x0001 .. 0x4600)
     MsgB-RNTI range :  17921 .. 35840      (0x4601 .. 0x8C00)
                            ^
                     no overlap - the offset is exactly the size of the RA-RNTI space

That constant is not a random shift. 14 x 80 x 8 x 2 = 17920 is precisely the number of distinct RA-RNTI values, so the MsgB-RNTI block starts immediately above the RA-RNTI block and the two can never collide. A UE running 4-step and a UE running 2-step random access in the same cell, in the same PRACH occasion, will compute different RNTIs - and both still fit inside the valid RNTI range, which ends at 0xFFEF.

Configuration

This search space can be explicitely configured by ra-ControlResourceSet in PDCCH-ConfigCommon. The RRC Message or IE that can carry PDCCH-ConfigCommon are SIB1, BWP-DownlinkCommon, BWP-DownlinkDedicated. If the configuration for this search space is not explicitly configured in RRC message(ra-ControlResourceSet and ra-SearchSpace), UE will search the Type 1 PDCCH in Type 0 PDCCH Common Search Space.

• The network signals the presence and parameters of the Type1-PDCCH CSS through the ra-SearchSpace field in PDCCH-ConfigCommon.
• This signaling tells the UE where and when to monitor for DCI scrambled by RA-RNTI, MsgB-RNTI, or TC-RNTI on the primary cell.
• If the UE does not receive any ra-SearchSpace configuration (for instance, if it is omitted or set to null), it does not attempt to decode Type1-PDCCH CSS.

NOTE : the paragraph and the last bullet above look at first like they disagree - one says the UE falls back to searching Type 0, the other says the UE does not decode Type1-PDCCH CSS at all. Both are correct, and they are describing the same behaviour from two directions. If ra-SearchSpace is absent there is no Type1 search space to monitor, so in that sense the UE does not decode one. But the RA-RNTI and TC-RNTI DCIs still have to arrive somehow, and the specification says the UE looks for them in the Type0-PDCCH CSS instead. Nothing is lost ; the same DCIs are simply monitored in a different place.

This matters more than it sounds, because it means a cell can complete random access without ever configuring a Type1 search space. Many simple deployments do exactly that : one CORESET 0, one search space, and everything - SIB1, RAR, Msg4 - is monitored there. Configuring ra-SearchSpace separately is what you do when you want the random access traffic to have its own monitoring occasions rather than sharing Type0's.

Where the configuration arrives from also matters. Your list of carriers for PDCCH-ConfigCommon is worth reading in the order the UE actually meets them :

The consequence of the middle row is easy to miss : because ra-SearchSpace lives inside the per-BWP common configuration, switching bandwidth part can change where random access is monitored. A UE that does a BWP switch and then needs to run random access uses the new BWP's ra-SearchSpace, not the one it started with.

Fallback for C-RNTI

In certain fallback scenarios, when a UE has been assigned a C-RNTI but lacks other dedicated or more advanced search space configurations (e.g, namely the Type3-PDCCH CSS set, Type1A-PDCCH CSS set, or any UE-specific search space) it can leverage the Type1-PDCCH CSS set for unicast transmissions using the C-RNTI. Specifically, the UE may monitor this search space for DCI formats 0_0 and 1_0 that are CRC-scrambled by the C-RNTI, ensuring the continuation of unicast communication even in the absence of other configured search spaces.

• If the UE has not been provided:
• a Type3-PDCCH CSS set,
• or a Type1A-PDCCH CSS set,
• or any UE-specific search space (USS),
• and the UE has been assigned a C-RNTI and does have a Type1-PDCCH CSS set, the UE may also use this Type1-PDCCH CSS set to monitor DCI format 0_0 and 1_0 with CRC scrambled by the C-RNTI.

That condition is a list of four things that all have to be true at once, which makes it hard to read as prose. It is easier as a ladder - the UE takes the first rung that is available :

  where does the UE look for its C-RNTI DCI (formats 0_0 and 1_0) ?

     1.  UE-specific search space (USS)        configured ?  ->  use it
             |  no
             v
     2.  Type3-PDCCH CSS                       configured ?  ->  use it
             |  no
             v
     3.  Type1A-PDCCH CSS                      configured ?  ->  use it
             |  no
             v
     4.  Type1-PDCCH CSS  +  a C-RNTI assigned            ->  use this as the last resort
             |  no
             v
         nowhere to monitor unicast DCI

Rung 4 is the one this page is about, and the reason it exists is worth stating plainly : it stops a UE from being stranded. Consider a UE that has just finished random access. It has a C-RNTI - contention resolution gave it one - but the RRC messages that would configure a UE specific search space have not arrived yet, because those messages themselves need to be scheduled. Without this fallback the UE would hold a valid identity and have nowhere to listen for it.

Two details are worth noticing in the condition. It permits only DCI formats 0_0 and 1_0 - the fallback formats, fixed in size and interpretable without dedicated configuration, which is exactly right for a UE that by definition has none. And it is a may, not a shall : the specification allows this behaviour rather than mandating it, so whether you see it in a given log depends on the implementation.

Interaction With Other Search Spaces

Unlike Type0-PDCCH CSS (for System Information), Type2-PDCCH CSS (for Paging), or Type3-PDCCH CSS (for various common RNTIs, including TPC RNTIs, INT-RNTI, etc.), the Type1-PDCCH CSS is specifically linked to the random access process or, under certain fallback conditions, to unicast if no UE-specific or other common search spaces are available.

• Primarily focuses on random-access or fallback: Type1-PDCCH CSS is oriented toward RA-RNTI, MsgB-RNTI, and TC-RNTI, covering core random access needs or, in certain fallback conditions, unicast via C-RNTI.
• Contrast with Type0-PDCCH CSS: Type0 is allocated to system information (e.g., for SIB broadcasting).
• Contrast with Type2-PDCCH CSS: Type2 is dedicated to paging activities.
• Contrast with Type3-PDCCH CSS: Type3 is used for various “common” or specialized RNTIs (e.g., TPC, INT, SFI).
• Ensures essential RA or unicast: This design allows a UE to continue its random access procedures or unicast reception, even if other common or UE-specific search spaces are unavailable.

Since the section compares Type1 against the others, here is the whole family in one place. Every one of them is a common search space, meaning its content is not addressed to one specific UE by a dedicated identity :

Read the RNTI column downwards and the division of labour is obvious. Each common search space owns a stage of the UE's life : Type0 gets it the system information, Type1 gets it through random access, Type2 wakes it up when it is idle, Type3 carries group commands, and the UE specific search space takes over once it has a real identity. Type1 is the only one whose RNTIs are temporary by design - RA-RNTI is computed from a PRACH occasion and TC-RNTI is discarded the moment it is promoted.

NOTE : your fallback condition above also mentions a Type1A-PDCCH CSS set. That one is not part of the original Rel-15 set of common search spaces listed here, so if you are checking against an older copy of 38.213 - 10.1 you will not find it there.

Reference

• Type0-PDCCH common search space
• 3GPP TS 38.213 - 10.1 : the formal definition of every PDCCH search space type
• 3GPP TS 38.321 - 5.1.3 : RA-RNTI, and 5.1.3a : MsgB-RNTI
• 3GPP TS 38.321 - 7.1 : the full RNTI value ranges
• 3GPP TS 38.331 - PDCCH-ConfigCommon (ra-SearchSpace, ra-ControlResourceSet)