7.2.4.5 PDCCH物理层的处理流程

本节课程视频
前面的内容,我们讨论了PDCCH的总体概念,以及手机侧如何进行盲检------盲检的时候需要考虑到哪些因素,比如不同类型的RNTI、不同的聚合等级、搜索空间,以及不同的DCI格式。正因为要综合考虑这么多种可能性,所以盲检的次数会非常多。这些因素既是手机需要考虑的,也是基站需要考虑的------虽然从最终呈现的角度看,很多都是物理层需要实现的内容(例如按不同聚合等级、以CCE的倍数在CORESET资源上做检测),但从系统实现的角度看,这一切首先是要在基站侧的MAC层调度器当中完成调度决策的。

我们此前反复强调,PDCCH本身只是PDSCH和PUSCH调度信息的"传递通道",真正的调度决策是在基站MAC层的调度器中完成的。调度器做出决策后,需要把这些决策"告诉"手机,告诉的方式就是通过DCI。因此,本节要讨论的是物理层的处理流程------需要明确的一点是:物理层的所有处理流程,都是以MAC层事先已经完成的调度决策为前提的。也就是说,MAC层需要先把资源位置、聚合等级、格式等各项调度参数都考虑清楚,才能形成一条DCI;这条DCI再经过物理层的一整套处理流程,最终在物理信道上呈现出来,供手机从物理层的角度去做盲检。此前我们讨论过的所有盲检因素(RNTI、聚合等级、格式),最终都要体现在这套物理层处理流程当中。本节就来具体看看,物理层里面这些处理流程,是如何体现PDCCH盲检那几个重要参数的。

一、盲检规则回顾:为什么需要如此复杂的搜索机制

为什么手机对PDCCH的检测被称为"盲检"?因为对于手机来说,在每一个调度时刻(比如某一个时隙内),它都面临着三个未知:

未知 具体问题
有没有 有没有调度我的PDCCH?
在哪里 如果有,它在CORESET资源池里的哪个具体位置?
是什么格式 这个PDCCH用的是哪一种DCI格式?(例如,是调度下行的DCI 1_1,还是调度上行的DCI 0_1?)

为了解决这三个未知,协议设计了一整套复杂的"搜索规则":系统会通过RRC信令为手机配置搜索空间,搜索空间定义了手机应当在哪些时隙、哪个CORESET里、以什么样的方式去尝试解码PDCCH。这个尝试过程,本质上是按照一个标准化的公式,计算出所有可能的PDCCH候选位置------公式中综合考虑了聚合等级、时隙号、RNTI、载波ID等多种因素。手机需要在这些候选位置上,尝试所有可能的DCI格式(用相应的RNTI去解扰CRC),逐一进行解码。

这就像在一个大房间里,有多个可能藏有指令的抽屉(候选位置),每个抽屉里可能放着不同格式的指令(DCI格式)。手机需要逐个打开抽屉,检查里面指令的格式是否正确,并且指令上的"暗号"(RNTI掩码)是否对得上------对上了,就找到了属于自己的调度指令。这个过程计算量很大,因此协议也对手机每时隙的盲检次数做了限制;网络侧的调度器在分配PDCCH资源时,也会尽量让不同用户的PDCCH分布在不同的候选位置上,避免冲突。基于上述需求,规范定义了PDCCH资源与UE盲检过程的完整公式(TS 38.213 §10.1):

图7.2.4.5-1 3GPP TS 38.213 §10.1 PDCCH候选位置计算公式(原讲义配图)

具体的公式推导过程与详细规则分析,本课程将在第16章第16.3.3节中做专门展开,此处不再赘述。

二、PDCCH物理层处理总体流程

一条DCI指令究竟是如何变成无线电波发送出去的?搞清楚这一点,能帮助我们更深入地理解PDCCH的可靠性从何而来。整个过程是一条标准的发射链,如下图所示:

图7.2.4.5-2 PDCCH物理层处理总体流程图:CRC添加→RNTI掩码→交织→Polar编码→子块交织→速率匹配→加扰→QPSK调制→RE映射→预编码(原讲义配图)

到达物理层的DCI,类似于业务信道中的TB(传输块),具有一定的、量化的字段大小,这些量化的比特数量与PDCCH所采用的具体格式直接相关。DCI到达物理层之后,需要针对不同的格式和字段大小,做一系列物理层的码字处理,包括CRC添加、信道编码、加扰、符号调制等。图中所示的流程可以归纳为以下几个关键环节:

处理环节 作用简述
CRC attachment (CRC添加) 为DCI净荷附加24比特CRC校验码,是实现寻址与差错检测的关键第一步
RNTI masking (RNTI掩码/局部加扰) 利用相应场景的RNTI对CRC校验码的后16位做加扰,实现PDCCH的"寻址"功能
Interleaving (交织)与Polar coding(Polar编码) Polar码在短码长场景下性能接近香农极限,非常适合控制信道这种信息量不大但要求极高可靠性的场景
Sub-block interleaving (子块交织)与Rate matching(速率匹配) 将编码后的码流适配到实际可用的物理资源(CCE)数量上
Scrambling (加扰)与QPSK modulation(QPSK调制) 对比特流做总体的随机化加扰,再统一采用QPSK方式完成符号调制
CCE indexing / CCE-to-REG mapping / RE mapping / Precoding 将调制后的符号,依据CCE与REG的映射关系,最终映射到具体的物理资源单元(RE)上,并完成预编码

在这一整套流程中,最值得我们重点关注、也与此前所讲内容密切相关的,是CRC添加与RNTI掩码这两个环节------它们直接体现了PDCCH盲检机制在物理层的具体实现方式。

三、DCI的CRC添加

CRC添加的作用,是对收到的DCI进行循环冗余校验,确认接收结果是否存在错误。手机在接收端解出DCI之后,无论是净荷(Payload)部分还是校验(Parity Bits)部分,只要存在任何错误,CRC循环校验都不会通过------这正是CRC机制存在的根本目的:让接收端能够自主判断解码结果是否可信。

图7.2.4.5-3 3GPP TS 38.212 §7.3.2 CRC attachment原文:CRC校验码的生成规则与RNTI加扰过程定义(原讲义配图)

根据3GPP规范原文的定义,整个DCI净荷由比特a₀, a₁, a₂, ⋯, a_{A-1}构成(A为净荷长度),校验比特为p₀, p₁, ⋯, p_{L-1}(L为校验比特数,此处固定为24)。计算校验码时,规范会构造一个辅助比特序列:先设置L个初始比特全部为"1",随后依次拼接上原始净荷比特,再代入生成多项式g_CRC24C(D)进行运算,最终得到24位的CRC校验码。校验码生成后,直接附加在原始净荷(A个比特)之后,构成总长度为K=A+L的完整比特序列。

图7.2.4.5-4 CRC24C生成多项式g_CRC24C(D)的具体表达式(原讲义配图)

下面结合一张流程示意图,更直观地梳理这一CRC生成过程:

图7.2.4.5-5 CRC校验码生成流程示意:从DCI净荷到附加24位校验码的完整过程(原讲义配图)

如图所示,原始净荷a₀至a_{A-1}被保留在序列末端;序列开头则先设置L(24)个全"1"的比特,构成辅助序列a'₀至a'{A+L-1};将这一辅助序列代入CRC24生成函数g_CRC24(D),即可运算得出校验比特p₀至p{L-1};最后,将原始净荷比特与校验比特依次拼接,形成最终附加了CRC的完整序列b₀至b_{B-1}(其中B=A+L)。这一过程虽然涉及具体的多项式运算细节,但工程实践中只需按照规范定义的标准步骤执行即可,不必深究其背后的数学推导原理。

四、基于RNTI的局部加扰

紧随CRC添加之后的下一步,是基于RNTI的局部加扰(RNTI Masking)。这一步的目的,是去区分不同用途、不同目的DCI的身份标识,需要特别说明的是:这一加扰过程与物理层后续对PDCCH整体信道所做的加扰(Scrambling)没有直接关系,二者是两个独立的处理环节。

DCI的RNTI加扰与业务信道的加扰方式有明显不同:加扰的范围并不涉及净荷(Payload)本身,而只涉及24位校验比特(Parity Bits)中的最后16位。这16位基于RNTI的掩码(Masking)操作,本质上是通过异或(XOR)运算,修改校验比特的后16位内容------在接收端做盲检时,手机会用自己所期望的那个RNTI取值,与接收到的这16位做异或的反向运算,再做CRC校验:如果校验成功,就说明这次接收所使用的RNTI与基站发送时所用的RNTI恰好一致,即证明了这个PDCCH确实是发给自己的;同时CRC本身的校验结果,也验证了接收内容本身没有传输错误。

图7.2.4.5-6 基于RNTI的局部加扰示意:CRC校验比特(b_A至b_23)与16位RNTI(x_rnti)做异或运算,生成新的比特序列c_A至c_23(原讲义配图)

从图中可以清楚地看到:完整的CRC附加后序列(b₀至b_{A-1}为原始净荷,b_A至b_{A+7}为CRC校验码的前8位,b_{A+8}至b_23为CRC校验码的后16位)中,只有最后16位(b_{A+8}至b_23)会与16比特的RNTI取值(x_rnti)做异或运算,生成新的16位结果;其余部分(原始净荷与CRC校验码的前8位)则原封不动地保留,不做任何修改。运算完成后,得到最终附加了RNTI掩码的完整序列c₀至c_{K-1}。

由此可见,PDCCH的CRC循环校验与RNTI的盲检,实际上是在同一个过程中一并完成的------手机每尝试一种RNTI,都是在做一次"RNTI反向异或+CRC校验"的组合验证:只有RNTI取值正确、且传输过程无误码,这次校验才会成功。这正是本节反复强调的核心机制:RNTI盲检并非独立于CRC校验之外的另一套流程,而是与CRC校验紧密耦合、共同实现的同一个验证步骤。

五、PDCCH的调制和信道编码

完成CRC添加与RNTI掩码之后,接下来便是正式的信道编码环节。PDCCH采用Polar码进行信道编码,Polar码在短码长场景下的性能表现十分接近香农极限,非常适合控制信道这种信息量不大、但对可靠性要求极高的应用场景。Polar信道编码的目的,是实现自动纠错,并通过添加不同程度的冗余,来实现抗干扰能力与对动态无线环境的自适应均衡。

图7.2.4.5-7 Polar编码输入输出关系及相关配置参数示意(原讲义配图):输入序列c₀至c_{K-1},输出编码序列d₀至d_{N-1}

调制方式方面,PDCCH统一采用QPSK调制------请特别注意,PDCCH固定使用QPSK,这一设计是为了在恶劣信道条件下依然能够保证控制信息的可靠解调,以牺牲一定的频谱效率为代价,换取更强的抗干扰鲁棒性。既然调制方式是固定不变的,那么PDCCH的实际码率(即抗干扰能力的强弱),就体现在不同的聚合等级(AL)与不同的格式选择上------这与我们此前小节所讨论的内容是完全一致的:资源映射时,调制后的符号被映射到控制信道单元CCE上,1个CCE等于6个资源单元组(REG),1个REG是12个子载波×1个符号;PDCCH的码率调整并非通过改变调制方式实现,而是通过改变所占用的CCE数量(即聚合等级)来实现------信道条件差时,就采用更高的聚合等级(更多CCE),相当于更低的码率、更多的冗余,从而获得更强的抗干扰能力。

Polar码的码率虽然可以动态调整,但其最终输出必须与被分配到的、物理层搜索空间中实际的CCE数量完整对应------这正是速率匹配(Rate Matching)这一环节所承担的职责:把信道编码之后、经调制得到的比特/符号数量,精确适配到目标CCE聚合所对应的RE数量上。若信道编码原始输出的码流长度超过目标RE数量,就需要截短或打孔(删减部分比特);若不足,则可以对码流做适当的重复。

此外,PDCCH格式中所包含的比特数量,应当与Polar码编码器输入码块大小的具体需求相匹配,因此在某些格式配置下,会看到需要额外填充(Padding)比特的情况------这正是为了让实际的DCI比特数量,能够满足Polar编码器对输入码块长度的规范要求。

六、本节小结

本节围绕PDCCH的物理层处理流程展开,系统梳理了从DCI净荷到最终物理信道传输的完整链条。我们首先回顾了PDCCH盲检的三个核心未知(有没有、在哪里、是什么格式)及其背后依托的候选位置计算公式;随后结合原讲义中的总体流程图,逐一介绍了CRC添加、RNTI掩码、交织、Polar编码、速率匹配、加扰、QPSK调制、RE映射、预编码等各个处理环节;重点深入剖析了CRC添加与RNTI局部加扰这两个与盲检机制直接相关的关键步骤------结合3GPP规范原文与流程示意图,说明了24位CRC校验码的生成方法,以及RNTI如何通过异或运算,对CRC校验码的后16位做局部加扰,从而实现PDCCH盲检与CRC校验"合二为一"的核心机制;最后介绍了Polar信道编码与QPSK固定调制的设计考量,以及聚合等级如何通过速率匹配,实现DCI码率与实际CCE资源数量之间的精确对应。

至此,我们已经从总体概念、盲检规则,一路深入到物理层具体的处理流程,较为完整地建立起了对PDCCH这一"总调度员"信道的系统性认识。关于PDSCH信道的总体概念、分类,以及本节中未详细展开的Polar编码具体细节,本教材将在后续相应章节中做进一步介绍。

相关推荐
阿钱真强道19 天前
58 极物科技 | KNX总线 - TP1物理层与拓扑特性解析
物理层·楼宇自动化·极物·极物智能·极物科技·knx协议·tp1
意法半导体STM3222 天前
【官方原创】LAT1709STM32C5硬件CRC值的计算话题
stm32·单片机·嵌入式硬件·mcu·crc·微控制器·stm32c5
Gnail32 个月前
7.2.4.1 PDCCH的基本概念和目的分类
dci·pucch·pdcch·rnti·盲检·coreset0
Gnail32 个月前
7.2.4.2 PDCCH 盲检与 RNTI 标识机制
pdcch·rnti·盲检
未来侦察班4 个月前
网络协议物理层,“地基“是怎么练成的
网络·物联网·网络协议·物理层·tcpip
DeeplyMind4 个月前
Linux 内核模块符号版本不匹配问题排查指南
linux·crc·module.symvers
嵌软小白呗5 个月前
Autosar-SecOC功能详解(一)
e2e·can·autosar·crc·secoc
zmj3203246 个月前
CAN FD CRC17 真实完整示例 + CRC15 / CRC17 详细对比
网络·crc·canfd
rqtz7 个月前
【嵌入式】探索基于ESPIDF的乐动LD14P激光雷达驱动与数据通信
crc·espidf·ld14p