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 在偶数帧上传输:
⌊(O⋅2μ+⌊i⋅M⌋)/Nslotframe,μ⌋mod 2=0(1) \lfloor(O \cdot 2^\mu + \lfloor i \cdot M \rfloor)/N_{\text{slot}}^{\text{frame},\mu}\rfloor \mod 2 = 0 \tag{1} ⌊(O⋅2μ+⌊i⋅M⌋)/Nslotframe,μ⌋mod2=0(1) - 当以下条件成立时,CORESET 0 在奇数帧上传输:
⌊(O⋅2μ+⌊i⋅M⌋)/Nslotframe,μ⌋mod 2=1(2) \lfloor(O \cdot 2^\mu + \lfloor i \cdot M \rfloor)/N_{\text{slot}}^{\text{frame},\mu}\rfloor \mod 2 = 1 \tag{2} ⌊(O⋅2μ+⌊i⋅M⌋)/Nslotframe,μ⌋mod2=1(2)
这里的 OOO 是时隙偏移量, iii 是候选SS/PBCH块的索引, MMM 是一个缩放因子, Nslotframe,μN_{\text{slot}}^{\text{frame},\mu}Nslotframe,μ 是在子载波间隔(SCS)配置 μ\muμ 下一个无线电帧中的时隙数量,而 μ\muμ 是与SCS相关的参数集索引。
- 当以下条件成立时,CORESET 0 在偶数帧上传输:
-
用于监听的时隙索引:
- UE监听PDCCH的时隙索引 n0n_0n0 由以下公式给出:
n0=(O⋅2μ+⌊i⋅M⌋)mod Nslotframe,μ(3) n_0 = (O \cdot 2^\mu + \lfloor i \cdot M \rfloor) \mod N_{\text{slot}}^{\text{frame},\mu} \tag{3} n0=(O⋅2μ+⌊i⋅M⌋)modNslotframe,μ(3) - UE从时隙 n0n_0n0 开始,在两个连续的时隙中监听PDCCH,即时隙 n0n_0n0 和 n0+1n_0 + 1n0+1。
- UE监听PDCCH的时隙索引 n0n_0n0 由以下公式给出:
这个过程(计算)的重点是找出 n0n_0n0。n0n_0n0 代表了在一个无线电帧内,UE开始监听与CORESET 0相关联的Type0-PDCCH公共搜索空间集(CSS)的起始时隙索引。
实际上, n0n_0n0 决定了在一个无线电帧内,UE应该寻找包含PDCCH的CORESET 0的确切时机。以38.213 表13-11为例,对于 μ=1\mu=1μ=1(此时 Nslotframe,μ=20N_{\text{slot}}^{\text{frame},\mu}=20Nslotframe,μ=20),当 O=0O=0O=0 和 M=1/2M=1/2M=1/2 时,对于SS/PBCH块索引 i=0,2,4,6i=0, 2, 4, 6i=0,2,4,6, n0n_0n0 的计算值分别为 0,1,2,30, 1, 2, 30,1,2,3。这意味着UE在 i=0i=0i=0 时监听时隙 000 和 111,在 i=2i=2i=2 时监听时隙 111 和 222,依此类推。这个时隙索引确保了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之后。