CORESET 0 and SIB1 Scheduling in a Nutshell

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

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 \mathrm{mod}2=0\text{\hspace{1em}(1)}$$
  • 当以下条件成立时，CORESET 0 在奇数帧上传输：
    $$\lfloor (O\cdot 2^{\mu }+\lfloor i\cdot M\rfloor )/N_{\text{slot}}^{\text{frame},\mu }\rfloor \mathrm{mod}2=1\text{\hspace{1em}(2)}$$
    这里的 $O$ 是时隙偏移量， $i$ 是候选SS/PBCH块的索引， $M$ 是一个缩放因子， $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 )\mathrm{mod}{N}_{\text{slot}}^{\text{frame},\mu }\text{\hspace{1em}(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为例，对于 $\mu =1$（此时 $N_{\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

一旦关于 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（如在 此说明 中所示）。

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之后。

$K_0$ - 时隙偏移 (Slot Offset)

• 含义: 定义了PDSCH所在的时隙相对于调度它的PDCCH所在的时隙的偏移量。
• 在这张表中，所有$K_0$都为0，意味着PDSCH和调度它的PDCCH位于同一个时隙内。

$S$ - 起始符号 (Start Symbol)

• 含义: 定义了在一个时隙内，PDSCH传输开始的OFDM符号索引（从0开始）。
• 例如：在Row index = 1的第一种情况下，$S=2$，表示PDSCH从该时隙的第3个符号开始。

$L$ - 持续长度 (Length)

• 含义: 定义了PDSCH传输在时域上持续的OFDM符号数量。
• 例如：在Row index = 1的第一种情况下，$L=12$，表示PDSCH会持续12个符号。

// SIB1 消息体开始
SIB1 ::= SEQUENCE { 
    
    // --- 小区选择相关的基本门槛信息 ---
    cellSelectionInfo SEQUENCE {
        q-RxLevMin              Q-RxLevMin,       // 驻留该小区所需的最低接收电平(RSRP)
        q-RxLevMinOffset        INTEGER (1..8)    OPTIONAL,   // 计算小区重选时的电平偏移量
        q-RxLevMinSUL           Q-RxLevMin        OPTIONAL,   // SUL(补充上行链路)的最低接收电平
        q-QualMin               Q-QualMin         OPTIONAL,   // 驻留该小区所需的最低接收质量(RSRQ)
        q-QualMinOffset         INTEGER (1..8)    OPTIONAL    // 计算小区重选时的质量偏移量
    } OPTIONAL, 
    
    // --- 小区接入相关信息，最重要的部分之一 ---
    cellAccessRelatedInfo       CellAccessRelatedInfo,
    
    // --- 连接建立失败控制信息 ---
    connEstFailureControl       ConnEstFailureControl   OPTIONAL,
    
    // --- 其他系统信息(SIB2, SIB3等)的调度信息 ---
    // 告诉手机去哪里、什么时候接收其他SIB
    si-SchedulingInfo           SI-SchedulingInfo       OPTIONAL,
    
    // --- 服务小区的公共配置 ---
    // 包含下行BWP、初始上行BWP、TDD配置等核心信息
    servingCellConfigCommon     ServingCellConfigCommonSIB  OPTIONAL,
    
    // --- 是否支持IMS紧急呼叫 ---
    ims-EmergencySupport        ENUMERATED {true}           OPTIONAL,
    
    // --- 是否支持通过IMS的eCall(车载紧急呼叫系统) ---
    eCallOverIMS-Support        ENUMERATED {true}           OPTIONAL,
    
    // --- UE的定时器和常量 ---
    // 定义了如T300, T301等RRC连接相关的定时器
    ue-TimersAndConstants       UE-TimersAndConstants       OPTIONAL,
 
    // --- 统一接入控制(UAC)相关的“门禁”信息 ---
    // 用于在网络拥塞时，控制不同类型的UE发起接入
    uac-BarringInfo SEQUENCE {
        uac-BarringForCommon        UAC-BarringPerCatList     OPTIONAL, // 通用接入类型的限制
        uac-BarringPerPLMN-List     UAC-BarringPerPLMN-List   OPTIONAL, // 按不同运营商(PLMN)进行接入限制
        uac-BarringInfoSetList      UAC-BarringInfoSetList,             // 接入限制信息的集合
        uac-AccessCategory1-SelectionAssistanceInfo CHOICE {            // 对特定优先级接入的辅助信息
            plmnCommon                  UAC-AccessCategory1-SelectionAssistanceInfo,
            individualPLMNList          SEQUENCE (SIZE (2..maxPLMN))
                                            OF UAC-AccessCategory1-SelectionAssistanceInfo
        } OPTIONAL
    } OPTIONAL,
 
    // --- 是否使用完整的Resume ID ---
    // 用于RRC非激活态(INACTIVE)下的状态恢复
    useFullResumeID             ENUMERATED {true}   OPTIONAL,
    
    // --- 后续版本增加的非关键性扩展字段 ---
    lateNonCriticalExtension    OCTET STRING            OPTIONAL,
    
    // --- 非关键性扩展字段 ---
    // 用于后续协议版本增加新的参数
    nonCriticalExtension        SIB1-v1610-IEs      OPTIONAL

} // SIB1 消息体结束