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

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-15 3 changes

In Release 15, the CORESET (Control Resource Set) function was newly introduced as a fundamental component for physical downlink control channel (PDCCH) transmission. The release specifically defined CORESET#0 for initial access and introduced the capability to use CORESET#0 within a dedicated downlink bandwidth part (BWP). It also established quasi-co-location (QCL) assumptions for CORESETs other than CORESET#0.

  • CR on using CORESET#0 in dedicated DL BWP TS 38.213CR0017
  • CR on QCL assumption for a CORESET other than 0 TS 38.213CR0030
  • CORESET#0 TS 38.300CR0111
Rel-16 1 change

In Release 16, a correction was made to the procedure for simultaneous multi-component carrier Transmission Configuration Indicator (TCI) state indication for a Control Resource Set (CORESET). This addressed specific signaling aspects to ensure the reliable and unambiguous configuration of quasi-co-location reference signals across multiple carriers for a single CORESET.

  • Correction on simultaneous multi-CC TCI indication for CORESET TS 38.213CR0233
Rel-18 3 changes

In Release 18, the key new development for CORESET was the introduction of QCL-TypeD priorities to manage overlapping CORESETs in Multi-DCI/Multi-TRP (M-DCI/M-TRP) operations. This enhancement provides a mechanism to resolve conflicts when multiple transmission points configure overlapping control resources. The release also included corrections to the TCI states applied for both CORESET 0 and other CORESETs during LTM (likely a typographical placeholder, as the full term is not provided in the context).

  • Introduction of QCL-TypeD priorities for overlapping CORESETs in M-DCI/M-TRP operation [QCL-TypeD CORESET priority for M-TRP] TS 38.213CR0569
  • Correction on TCI state applied for CORESET 0 in LTM TS 38.213CR0621
  • Correction on TCI state applied for CORESETs other than CORESET 0 in LTM TS 38.213CR0645

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
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.