What is a CORESET?
A Control Resource Set (CORESET) is a defined region of time and frequency where the UE looks for PDCCH — the Physical Downlink Control Channel that carries scheduling assignments. Think of it as a designated noticeboard: the network tells the UE exactly which RBs and which symbols to watch, and the UE only searches for control information there.
CORESET#0 is special — it is the only CORESET configured via MIB (before RRC connection). All other CORESETs (1–11) are configured later via RRC signalling. CORESET#0 must exist so the UE can find SIB1, which provides the full cell configuration needed to connect.
Step 1 — Select the correct table
TS 38.213 Section 13 provides Tables 13-1 through 13-10. The correct table depends on the SSB subcarrier spacing and the PDCCH subcarrier spacing (from subCarrierSpacingCommon in MIB).
| SSB SCS | PDCCH SCS | FR | Table |
|---|---|---|---|
| 15 kHz | 15 kHz | FR1 | Table 13-1 |
| 15 kHz | 30 kHz | FR1 | Table 13-2 |
| 30 kHz | 30 kHz | FR1 | Table 13-4 ← our case |
| 120 kHz | 60 kHz | FR2 | Table 13-7 |
| 120 kHz | 120 kHz | FR2 | Table 13-8 |
Step 2 — Table 13-4 lookup
Our controlResourceSetZero index = 3 (from MIB bits [12:15] = 0011). Looking up row 3 in Table 13-4:
| Index | Number of RBs | Number of symbols | Offset (RBs) |
|---|---|---|---|
| 0 | 24 | 2 | 0 |
| 1 | 24 | 2 | 2 |
| 2 | 24 | 2 | 4 |
| 3 ← ours | 24 | 2 | 2 |
| 4 | 24 | 3 | 0 |
| 5 | 24 | 3 | 2 |
| 6 | 48 | 1 | 0 |
| 7 | 48 | 1 | 4 |
| 8 | 48 | 2 | 0 |
| 9 | 48 | 2 | 4 |
Step 3 — Calculate Point A
The offset in the table is relative to Point A — the absolute frequency reference derived from the MIB field ssb-SubcarrierOffset (k_SSB = 2). This was derived from the MIB — see MIB fields:
// Point A (from Module 3 MIB parsing): f_SSB_center = 3498.24 MHz f_SSB_low = 3498.24 − 60 × 0.030 = 3496.44 MHz Point_A = 3496.44 − k_SSB × SCS = 3496.44 − 2 × 0.030 = 3496.38 MHz // CORESET#0 frequency position: // Offset = 2 RBs = 2 × 12 subcarriers × 30 kHz = 720 kHz CORESET0_start = Point_A + offset × 12 × SCS = 3496.38 + 2 × 12 × 0.030 = 3496.38 + 0.720 = 3497.10 MHz // Width: CORESET0_width = 24 RBs × 12 SC × 30 kHz = 8.64 MHz CORESET0_end = 3497.10 + 8.64 = 3505.74 MHz // Time domain: CORESET0_symbols = 2 (symbols 0 and 1 of each monitoring slot)
Step 4 — Visualise the position
Let's place CORESET#0 in context against the SSB and the 100 MHz channel:
CORESET internal structure — CCEs and REGs
Inside CORESET#0, the UE needs to know how control channel elements are organised in order to perform blind decoding. The building blocks are:
A Resource Element Group (REG) = 1 RB × 1 OFDM symbol = 12 REs. A Control Channel Element (CCE) = 6 REGs. The PDCCH uses 1, 2, 4, 8, or 16 CCEs — this is the aggregation level (AL). Higher aggregation = more robust coding = used for weak signal UEs.
// CORESET#0 dimensions: Width = 24 RBs Duration = 2 symbols // REG count: Total REGs = 24 RBs × 2 symbols = 48 REGs // CCE count: Total CCEs = 48 REGs / 6 REGs per CCE = 8 CCEs (CCEs numbered 0–7) // Aggregation levels available: AL=1: 1 CCE → can fit 8 candidates → typically not used for SIB1 AL=2: 2 CCEs → can fit 4 candidates AL=4: 4 CCEs → can fit 2 candidates → used for SIB1 AL=8: 8 CCEs → can fit 1 candidate → used for SIB1 AL=16: exceeds CORESET#0 size → not applicable here
CCE-to-REG mapping — interleaved vs non-interleaved
The mapping of CCEs to REGs can be either non-interleaved (CCEs map to contiguous REGs — good for beamforming) or interleaved (CCEs spread across the CORESET — provides frequency diversity). For CORESET#0, the mapping type is determined by the table and is typically non-interleaved.