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

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} ⌊(O2μ+iM⌋)/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} ⌊(O2μ+iM⌋)/Nslotframe,μmod2=1(2)
      这里的 OOO 是时隙偏移量, iii 是候选SS/PBCH块的索引, MMM 是一个缩放因子, Nslotframe,μN_{\text{slot}}^{\text{frame},\mu}Nslotframe,μ 是在子载波间隔(SCS)配置 μ\muμ 下一个无线电帧中的时隙数量,而 μ\muμ 是与SCS相关的参数集索引。
  • 用于监听的时隙索引:

    • 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=(O2μ+iM⌋)modNslotframe,μ(3)
    • UE从时隙 n0n_0n0 开始,在两个连续的时隙中监听PDCCH,即时隙 n0n_0n0n0+1n_0 + 1n0+1

这个过程(计算)的重点是找出 n0n_0n0n0n_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=0M=1/2M=1/2M=1/2 时,对于SS/PBCH块索引 i=0,2,4,6i=0, 2, 4, 6i=0,2,4,6n0n_0n0 的计算值分别为 0,1,2,30, 1, 2, 30,1,2,3。这意味着UE在 i=0i=0i=0 时监听时隙 000111,在 i=2i=2i=2 时监听时隙 111222,依此类推。这个时隙索引确保了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之后。

在这里插入图片描述

http://www.dtcms.com/a/272341.html

相关文章:

  • 论文阅读笔记:VI-Net: Boosting Category-level 6D Object Pose Estimation
  • RocketMQ安装(Windows环境)
  • 上线节点固定,项目进度紧张,如何合理压缩工期
  • NGINX系统基于PHP部署应用
  • 实验作业1+整理笔记截图
  • 实训八——路由器与交换机与网线
  • 栈题解——有效的括号【LeetCode】两种方法
  • 硬件基础------电感
  • Matplotlib-绘制训练曲线指南
  • 力扣刷题记录(c++)06
  • HTML应用指南:利用GET请求获取全国永辉超市门店位置信息
  • Unity3D iOS闪退问题解决方案
  • PyTorch仿射变换:原理与实战全解析
  • 深入理解Java虚拟机:Java内存区域与内存溢出异常
  • 【运维架构】云计算运维架构师与基础设施,技术路线,Linux证书(标准化/定制化/CNCF,公有云/混合云/私有云)
  • 【图像处理基石】如何入门图像校正?
  • (6)机器学习小白入门 YOLOv:图片的数据预处理
  • 机器学习 YOLOv5手绘电路图识别 手绘电路图自动转换为仿真软件(如LT Spice)可用的原理图,避免人工重绘
  • Spring MVC 1
  • C++中的list的学习
  • Go语言教程-变量、常量、命名规则
  • 亚矩阵云手机破解Maio广告平台多账号风控:从“生存焦虑”到“规模化增长”的终极方案
  • 电路研究9.4——合宙Air780EP的LuatOS、CSDK跟标准AT
  • 基于开源AI大模型AI智能名片S2B2C商城小程序源码的私域流量新生态构建
  • 独立服务器选择Rocky Linux还是CentOS
  • 【数据结构】顺序表(sequential list)
  • 学习中断配置的一天(第五天)
  • 安装nginx+php环境
  • OpenCV探索之旅:多尺度视觉与形状的灵魂--图像金字塔与轮廓分析
  • 无人机识别比赛记录与分析