当前位置：首页 > news >正文

CORESET 0 and SIB1 Scheduling in a Nutshell

news 2025/7/11 7:12:13

为什么我们需要一个特殊的流程？

SIB1 和其他任何用户数据（或空中下载信息 OTA）一样，都是由 PDSCH 承载的。那么，为什么我们需要一个特殊的算法来传输和解码承载 SIB1 的 PDSCH 呢？

在回答这个问题之前，让我们先总结一下其他用户数据或下行 OTA 消息是如何调度和解码的。其过程如下：

i) 网络为传输 DCI 定义了特定的物理资源 (CORESET)
ii) 网络定义了一组 UE 必须监控的候选物理资源 (Search Space)，以寻找调度信息
iii) 网络为 PDSCH 定义了一个符号分配列表 (TimeDomainResourceAllocation)
iv) 网络通过 RRC 消息（如 SIB1、RRCSetup 或 RRCReconfiguration）将所有这些配置信息通知给 UE

v) 当网络想要发送一个特定的 PDSCH 时，它会发送一个 DCI，并按照该 DCI 中调度的信息来传输 PDSCH。

这个过程的关键词是 RRC 消息。对于用户数据或其他 OTA 消息，PDSCH 是在所有详细配置信息被告知给 UE 之后才进行传输的。但是 SIB1 的传输/解码必须在任何 RRC 消息被传递给 UE 之前发生。在 SIB1 之前，UE 唯一收到的 RRC 消息是 MIB 消息。如你所知，MIB 只能承载非常少的信息，没有足够的空间来承载所有详细信息。那么，在这种情况下，UE 如何能找出所有的详细信息呢？处理这种情况（即，让 UE 在不依赖冗长的 RRC 消息的情况下找出长期的/详细的信息）的一个常用技术是使用一些 UE 和网络（NW）双方都预先知晓的预定义表格（预配置，predefined configuration）和算法。这就是在 NR 中传输和解码 SIB1 的基本思想。

3GPP 定义了许多预定义的表格和算法来处理它，并在 MIB 中用少量信息元素来指明应该使用哪一个预定义的表格。

基本问题

这个过程非常复杂和令人困惑。在阅读细节之前，在脑海中有一系列清晰的问题会是个好主意。以下是我在阅读细节之前，我自己版本的问题。

我们如何能找出 CORESET 的物理资源？

我们如何能计算出为 CORESET 分配了多少个 RB 和 OFDM 符号？你可以从在 定义 CORESET 0 的 RRC 参数 中解释的 controlResourceSetZero 参数，以及在 频域中的 CORESET 0 位置 中解释的内容里找到答案。这扮演了与 RRC 消息中 coreset 定义参数相同的角色。

我们如何能找出应该监控哪些 OFDM 符号来搜索 CORESET？

你可以从在 定义 CORESET 0 的 RRC 参数 中解释的 searchSpaceZero 参数中找出答案。更具体地说，表格 13-11、13-12、13-13、13-14 中的第一个符号索引（first symbol index）告诉了你搜索空间的起始符号。这扮演了与在这里解释的 monitoringSymbolsWithinSlot 类似的角色。

我们如何能找出 CORESET 是在哪些时隙 (slots) 上传输的？

你可以从在 CORESET 0 传输时隙 章节中解释的 searchSpaceZero 参数中找出答案。

定义 CORESET 0 的 RRC 参数

公共搜索空间 (Common Search Space) 在 38.213 - 第13节中定义。这是一个漫长/复杂的过程。我将花一些时间来消化这个过程并更新这个页面。定义公共搜索空间的关键参数之一是 MIB.pdcchConfigSIB1 (这对应于 38.213 - 第13节中定义的 RMSI-PDCCH-Config，如下所述)。

如果一个 UE 确定存在一个用于 Type0-PDCCH 公共搜索空间的控制资源集，如子条款 4.1 中所述，那么该 UE 会根据 RMSI-PDCCH-Config 的四个最高有效比特，从表 13-1 到 13-10 中确定用于 Type0-PDCCH 公共搜索空间的控制资源集的连续资源块数量和连续符号数量，并根据 RMSI-PDCCH-Config 的四个最低有效比特（包含在 MasterInformationBlock 中），从表 13-11 到 13-15 中确定 PDCCH 的监听时机，如表 13-11 到 13-15 所述。

CORESET 和 PDCCH Occasion（PDCCH 在时域上的位置）是由一个 MIB 参数和许多预定义的表格决定的，如下所示。

注 1：你需要通过查看给你的 FR 或 SSB SCS / PDCCH SCS，来找出应该使用哪个 PDCCH 监听时机表 (CORESET 复用模式)。

注 2：你需要通过查看给你的 FR 或 SSB SCS / PDCCH SCS，来找出应该使用哪个 CORESET 定义表。

在这里插入图片描述

CORESET 0 在时域中的位置

在常规的 CORESET（即 CORESET 0 以外的 CORESET）中，其时域位置是由以下两个 RRC IE（information element，信息元素）决定的：

SearchSpace -> monitoringSymbolsWithinSlot：指定了 coreset 的起始位置。
ControlResourceSet -> duration：指定了 coreset 的符号长度。

在 CORESET 0 的情况下，这两个参数是在预定义的表格中指定的，如前面章节所示：

SearchSpace -> monitoringSymbolsWithinSlot：由表 13-11 及后续表格中的 ‘First symbol index’ 列决定。
ControlResourceSet -> duration：由表 13-1 到 13-11 中的 ‘Number of symbols’ 列决定。

CORESET 0 在频域中的位置

CORESET 0 在频域中的位置是基于 38.213 中的以下陈述来确定的：

The offset in Tables 13-1 through 13-10 is defined with respect to the SCS of the CORESET for Type0-PDCCH CSS set, provided by subCarrierSpacingCommon, from the smallest RB index of the CORESET for Type0-PDCCH CSS set to the smallest RB index of the common RB overlapping with the first RB of the corresponding SS/PBCH block

注意：注意，此处所示参数中的子载波间隔根据情况而异，总结如下：

k_ssb：SSB 子载波间隔，对于 FR1 总是 15 Khz，对于 FR2 总是 60 Khz。
OffsetToPointA：此参数的单位是 RB 的数量。这些 RB 内的子载波间隔对于 FR1 总是 15 Khz，对于 FR2 总是 60 Khz。
SSB 子载波间隔：这个值根据 MIB 中的 SubCarrierSpacingCommon 值而变化，总结如下：
- 当 SubCarrierSpacingCommon = scs15or60
  - FR1 的子载波间隔 = 15 Khz
  - FR2 的子载波间隔 = 60 Khz
- 当 SubCarrierSpacingCommon = scs30or120
  - FR1 的子载波间隔 = 30 Khz
  - FR2 的子载波间隔 = 120 Khz

基于以上陈述，我将 CORESET 0 的位置图示如下。

Example 01 > SSB/PDCCH SCS = {30,30}, Index 10 in Table 13-4

在这里插入图片描述

Number of Symbols：这是 CORESET #0 在时域上的长度，单位是OFDM符号 (Symbol)

在这里插入图片描述

CORESET 0 传输时隙

其传输和监听由 3GPP TS 38.213 - 第13节所定义。这个过程涉及到根据SSB块，使用复用模式来确定 CORESET 0 传输的时机和时隙位置。它确保了 UE（用户设备）能够基于时隙偏移、缩放因子和参数集（numerology）等参数，在正确的时隙和符号上高效地监听 PDCCH，从而实现与5G网络的成功初始接入和同步。

pdcch-ConfigSIB1 是一个8比特（bit）的字段，低4位 (LSB)：这正是您需要的答案。这4个比特组成的数值（0到15）就是用来查询Table 13-11到13-14的索引（Index），以确定PDCCH的监听时机。确定 Coreset 0 传输的总体逻辑图示如下：

在这里插入图片描述

Type0-PDCCH CSS（公共搜索空间）集的PDCCH监听与SS/PBCH块和CORESET复用模式相关联。其关键点如下：

CORESET 0 传输时机：
- 当以下条件成立时，CORESET 0 在偶数帧上传输：
  $\lfloor(O \cdot 2^\mu + \lfloor i \cdot M \rfloor)/N_{\text{slot}}^{\text{frame},\mu}\rfloor \mod 2 = 0 \tag{1}$
- 当以下条件成立时，CORESET 0 在奇数帧上传输：
  $\lfloor(O \cdot 2^\mu + \lfloor i \cdot M \rfloor)/N_{\text{slot}}^{\text{frame},\mu}\rfloor \mod 2 = 1 \tag{2}$
  这里的 $O$ 是时隙偏移量， $i$ 是候选SS/PBCH块的索引， $M$ 是一个缩放因子， $Nslotframe,μN_{\text{slot}}^{\text{frame},\mu}$ 是在子载波间隔（SCS）配置 $μ\mu$ 下一个无线电帧中的时隙数量，而 $μ\mu$ 是与SCS相关的参数集索引。
用于监听的时隙索引：
- UE监听PDCCH的时隙索引 $n_0$ 由以下公式给出：
  $n_0 = (O \cdot 2^\mu + \lfloor i \cdot M \rfloor) \mod N_{\text{slot}}^{\text{frame},\mu} \tag{3}$
- UE从时隙 $n_0$ 开始，在两个连续的时隙中监听PDCCH，即时隙 $n_0$ 和 $n_0 + 1$ 。

这个过程（计算）的重点是找出 $n_0$ 。 $n_0$ 代表了在一个无线电帧内，UE开始监听与CORESET 0相关联的Type0-PDCCH公共搜索空间集（CSS）的起始时隙索引。

实际上， $n_0$ 决定了在一个无线电帧内，UE应该寻找包含PDCCH的CORESET 0的确切时机。以38.213 表13-11为例，对于 $μ=1\mu=1$ （此时 $Nslotframe,μ=20N_{\text{slot}}^{\text{frame},\mu}=20$ ），当 $O = 0$ 和 $M = 1/2$ 时，对于SS/PBCH块索引 $i = 0, 2, 4, 6$ ， $n_0$ 的计算值分别为 $0, 1, 2, 3$ 。这意味着UE在 $i = 0$ 时监听时隙 $0$ 和 $1$ ，在 $i = 2$ 时监听时隙 $1$ 和 $2$ ，依此类推。这个时隙索引确保了UE的监听与网络的CORESET 0传输时间表保持一致，而这个时间表又是与SS/PBCH块的传输相关联的。

在这里插入图片描述

为 SIB1 PDSCH 分配时域资源

一旦关于 CORESET 0 的所有信息都确定了，UE（用户设备）就需要从 DCI（下行控制信息）中找出 PDSCH（物理下行共享信道）的资源信息。用于 SIB1 PDSCH 的 DCI 是在这里解释的 DCI 1_0。从这个 DCI 中，UE 需要找出 SIB1 PDSCH 的频域和时域资源信息。找出频域资源信息没有问题，因为它被直接编码在 DCI 中；但找出时域资源信息是有问题的，因为它没有被直接编码在 DCI 中。时域资源信息是由一个索引值指示的，该索引指向一个特殊形式的表格（称为 PDSCH-TimeDomainResourceAllocation）。通常，这张表格是通过 RRC 消息告知给 UE 的，如在 此说明 中所解释。但是在解码 SIB1 的这个时间点，这些 RRC 消息还没有被传递给 UE。因此，应该有一个由 3GPP 规范定义的、UE 已知的预定义表格。在 SIB1 PDSCH 的情况下，使用的是 38.214 - Table 5.1.2.1.1-2（如在 此说明 中所示）。

Time Domain Resource Allocation for SIB1 PDSCH

在这里插入图片描述

SI-RNTI 是 System Information Radio Network Temporary Identifier 的缩写，其中 SI-RNTI (System Information-RNTI)，这是一个公共的、固定的ID，专门用于调度系统信息块（SIB），尤其是SIB1。

Type0-PDCCH Common Search Space (Type0 common)
唯一用途：专门用于承载SIB1 (系统信息块1) 的调度信息。
重要性：这是手机在完成初始同步后，为了接入网络而必须找到的第一个、最关键的搜索空间。没有它，手机就无法读取SIB1，也就无法进行后续的随机接入等所有流程。

Type0A-PDCCH Common Search Space (Type0A common)
用途：专门用于承载除SIB1以外的其他系统信息 (Other SIBs)，例如 SIB2, SIB3, SIB4 等。
重要性：这些“其他SIB”包含了小区间切换、测量等更详细的配置信息，虽然也很重要，但优先级在SIB1之后。

在这里插入图片描述