CORESET

Control Resource Set

Physical Layer →
Introduced in Rel-15

CORESET is a dedicated time-frequency resource region in 5G NR where a UE monitors for PDCCH transmissions to receive downlink control information.

Category
Physical Layer
Introduced
Rel-15
Where
Radio Access Network › NG-RAN (5G)
Specifications
12 specs
CORESET Description Purpose Related Classification Detected Changes Specifications

Description

The Control Resource Set (CORESET) is a foundational physical layer concept in 5G New Radio (NR) that defines a specific, configurable set of physical resource blocks (PRBs) and OFDM symbols within a slot where a User Equipment (UE) must monitor for Physical Downlink Control Channel (PDCCH) candidates. Unlike the fixed control region in LTE, a CORESET provides immense flexibility. It is characterized by several key parameters: its frequency-domain location (a set of contiguous or non-contiguous PRBs), its time-domain duration (1 to 3 OFDM symbols), its mapping type (interleaved or non-interleaved), and its associated PDCCH demodulation reference signal (DM-RS) configuration. A single UE can be configured with multiple CORESETs, each potentially linked to a different search space set, allowing for sophisticated control channel resource management.

Architecturally, a CORESET is configured for a UE via Radio Resource Control (RRC) signaling, specifically within the PDCCH-Config information element. The configuration includes the CORESET ID, frequency domain resources (given by a bitmap), duration in symbols, and the precoder granularity. A critical component is the Control-Channel Element (CCE), which is the basic unit for PDCCH transmission. A CORESET is composed of a set of Resource Element Groups (REGs), where a REG equals one resource block in one OFDM symbol. REGs are grouped into REG bundles, and CCEs are formed from these REG bundles. The mapping of CCEs to physical resources within the CORESET can be interleaved (providing frequency diversity) or non-interleaved (providing localized transmission for beamforming).

In operation, the UE uses the configured CORESET parameters to blind decode PDCCH candidates within its associated search space sets. The gNodeB transmits DCI by mapping the encoded DCI bits to one or more CCEs (aggregation levels 1, 2, 4, 8, or 16) within the configured CORESET resources. The UE's monitoring behavior—such as periodicity and timing—is governed by the linked search space, while the CORESET strictly defines the physical 'where' to look. This separation of the resource definition (CORESET) from the monitoring rule (Search Space) is a key 5G innovation. CORESETs play a vital role in enabling features like ultra-reliable low-latency communication (URLLC) by allowing very short, front-loaded control regions, and in supporting beamformed control channels by being associated with specific Transmission Configuration Indicator (TCI) states for quasi-co-location (QCL) reference.

Purpose & Motivation

CORESET was created to address the inflexibility of the LTE control channel design, which used a fixed, cell-specific control region at the start of every subframe. This rigid structure was ill-suited for the diverse service requirements of 5G, such as varying latencies, bandwidths, and use cases like massive IoT and mission-critical communications. The primary problem CORESET solves is enabling dynamic and efficient control channel resource allocation that can adapt to different deployment scenarios, channel conditions, and UE capabilities.

Historically, LTE's static control region led to inefficiencies, especially in wideband carriers or low-traffic scenarios, as control overhead was always present. The motivation for CORESET was to decouple control signaling from a fixed time-frequency structure, allowing network operators to tailor control resources precisely. This enables superior support for wide bandwidth operation (e.g., up to 400 MHz), where it is inefficient to monitor the entire band for control; instead, a CORESET can be configured in a specific bandwidth part (BWP). It also fundamentally enables low latency by allowing the control region to be placed immediately before the scheduled data (mini-slot operation), a stark contrast to LTE's subframe-bound scheduling.

Furthermore, CORESET is essential for advanced antenna systems and beam management in 5G NR. By associating a CORESET with specific QCL assumptions (via TCI states), the network can transmit PDCCH using beamforming, directing control signals to specific UEs or areas. This addresses the limitation of LTE's cell-wide, broadcast-style control channel, which did not efficiently support high-frequency bands (like mmWave) where beamforming is mandatory for coverage. Thus, CORESET provides the physical layer framework for scalable, efficient, and adaptable control signaling that underpins all 5G NR data scheduling and system operations.

Classification

Part ofPDCCH
Specific typesCCEPDCCHREG

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (134 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-15 26 changes

In Release 15, the CORESET function was introduced as a foundational component for NR PDCCH, defining the time-frequency resources where a UE monitors for control information. Key corrections and clarifications were made regarding its configuration, including the use of CORESET#0 in a dedicated downlink bandwidth part and rules for PDCCH monitoring in overlapped CORESETs. Additionally, specific Quasi-Co-Location (QCL) assumptions for receiving PDCCH, including for Random Access Response and for CORESETs other than ID 0, were defined to ensure proper beam-based reception.

  • CR on PDSCH mapping to virtual resource blocks TS 38.211CR0006
  • Correction on physical resource mapping for PUSCH with configured grant TS 38.211CR0008
  • Correction to frequency-domain starting position for SRS resource mapping TS 38.211CR0009
  • Correction on mapping from virtual to physical resource blocks TS 38.211CR0012
  • Correction on PDSCH resource allocation scheduled by PDCCH in Type 0 common search space TS 38.211CR0018
  • Correction of wrong implementation on frequency domain resource assignment bitwidth TS 38.212CR0006

+ 20 more changes

Rel-16 29 changes

In Release 16, a key enhancement for CORESET was the introduction of a procedure for simultaneous multi-CC TCI indication, allowing a single Transmission Configuration Indicator state to be applied across multiple component carriers. This was accompanied by specific corrections to the UE procedure for determining PDCCH assignment for the Rel-16 PDCCH monitoring capability. Furthermore, the release clarified PDCCH monitoring behavior for scenarios like DAPS Handover and for cells configured with Rel-15 monitoring capability.

  • Correction on RIM RS resource and set ID mapping TS 38.211CR0069
  • RRC IE name fix to dynamic frequency domain resource allocation type selection (Rel-15 origin) TS 38.212CR0056
  • Correction on SRS resource set configuration in TS 38.212 TS 38.212CR0070
  • Correction on SRS resource set configuration for DCI format 0_2 in TS 38.212 TS 38.212CR0072
  • CR on Power Control for NR-DC TS 38.213CR0128
  • CR on correction on PDCCH monitoring for DAPS HO TS 38.213CR0132

+ 23 more changes

Rel-17 36 changes

In Release 17, specific enhancements were made to CORESET and PDCCH monitoring, including corrections for multi-slot PDCCH monitoring in NR-DC and CA scenarios with mixed capability types and for monitoring in the FR2-2 spectrum. Furthermore, the release introduced clarifications for PDCCH monitoring when overlapping with a rate matching pattern and defined procedures for broadcast PDCCH monitoring in the active DL BWP.

  • CR on the description of the SRS resource set indication for PUSCH repetition TS 38.212CR0117
  • Corrections on resource pool index TS 38.212CR0124
  • CR on PDCCH repetition with SSSG switching TS 38.213CR0332
  • Correction on the tables for determining Type0 PDCCH monitoring occasions TS 38.213CR0337
  • CR on the clarification of PUCCH resource determination in 38.213 TS 38.213CR0339
  • Correction on multi-slot PDCCH monitoring in NR-DC and CA scenarios with mixed capability types TS 38.213CR0342

+ 30 more changes

Rel-18 33 changes

In Release 18, a key enhancement for CORESET was the introduction of QCL-TypeD priorities for overlapping CORESETs in M-DCI/M-TRP operation, which helps manage beamforming reference signals when a UE is configured with multiple transmission/reception points. Additionally, corrections were made regarding the TCI state applied for CORESET 0 and other CORESETs during Link Task Management (LTM) operations.

  • Introduction of Rel-18 network controlled repeaters TS 38.212CR0150
  • Introduction of Network Controlled Repeaters TS 38.213CR0506
  • Introduction of QCL-TypeD priorities for overlapping CORESETs in M-DCI/M-TRP operation [QCL-TypeD CORESET priority for M-TRP] TS 38.213CR0569
  • Introducing support for Network-Controlled Repeaters to 38.300 TS 38.300CR0685
  • Corrections to NR Network-controlled Repeaters TS 38.211CR0118
  • Correction on mapping PSFCH to physical resources TS 38.211CR0141

+ 27 more changes

Rel-19 10 changes

In Release 19, the key enhancement for CORESET was the introduction of PDCCH repetitions specifically for the Type0-PDCCH Common Search Space (CSS) set in Terrestrial Networks (TNs). This builds on earlier work for Non-Terrestrial Networks (NTN) by extending common PDCCH repetition to improve control channel reliability in terrestrial deployments. Additionally, parameters were aligned for intra-slot PDCCH repetition to ensure consistent implementation.

  • Introduction of PDCCH repetitions for Type0-PDCCH CSS set in TNs [Common_PDCCH_Rep_TN] TS 38.213CR0748
  • Introduction of control parameters for on-demand posSIB request [OdPosSIB_Req] TS 38.300CR1009
  • Introducing SR resources in LTM cell switch MAC CE [LTM_enh_SR] TS 38.300CR1054
  • Introduction of common PDCCH repetition (Rel-19 NTN) for TN [Common_PDCCH_rep_TN] TS 38.300CR1058
  • Correction on PDSCH resource mapping TS 38.211CR0178
  • Correction on PDCCH candidates skipping for receiving RAR when overlapping with candidate SSB TS 38.213CR0755

+ 4 more changes

Explore further

Broader topics and technologies where CORESET plays a role.

Defining Specifications

3GPP specifications that define or reference CORESET, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 38.133 vj20 5G UE Radio Requirements for RRC_IDLE Mobility Rel-19
TS 38.174 vj10 NR Integrated Access and Backhaul Radio Spec Rel-19
TS 38.176 vj20 IAB Conformance Testing Specification Rel-19
TS 38.211 vj10 NR Physical Channels and Modulation Rel-19
TS 38.212 vj10 NR Multiplexing and Channel Coding Rel-19
TS 38.213 vj10 NR Physical Layer Control Procedures Rel-19
TS 38.300 vj00 NG-RAN Overall Description Rel-19
TS 38.523 vj20 5G NR UE Conformance Testing: Idle/Inactive Rel-19
TR 38.808 vh00 Study on NR above 52.6 GHz to 71 GHz Rel-17
TR 38.833 vh00 NR Demodulation Performance Enhancement Rel-17
TR 38.869 vi00 Study on low-power wake up signal and receiver for NR Rel-18
TR 38.878 vi40 Technical Report on Advanced Receiver for MU-MIMO Rel-18