5G NR 的调度逻辑全都压在一条信道上就是 PDCCH——物理下行控制信道。终端每次收发数据之前得先在这儿拿到一张写着去哪儿收、用什么调制编码、占多少 RB、什么时候反馈 HARQ的条子这张条子就是 DCIDownlink Control Information。基站侧做调度器、终端侧做物理层解析甚至做路测和故障排查的人只要跟 NR 打交道就绕不开 PDCCH 和 DCI 这两个词。很多刚转过来的同行会觉得它比 PDSCH 难啃PDSCH 好歹有 CSI 反馈兜底PDCCH 完全靠盲检位置事先不知道格式还一堆尺寸还有对齐规则。这篇文章我打算把 PDCCH DCI 从它是什么一路讲到参数怎么配、脚本怎么算、出问题怎么查把 CORESET、REG、CCE、聚合等级、搜索空间、盲检、DCI 格式、尺寸对齐、链路处理这些碎块拼成一张完整的图。不管你是刚上手 NR 协议栈的工程师还是做外场优化的看完至少能对着配置和日志说出个所以然。1. 从一条调度指令说起PDCCH 和 DCI 到底是什么关系1.1 用车站广播打个比方我一般跟新人这么解释PDSCH、PUSCH 是月台上的旅客PDCCH 是候车厅的广播喇叭DCI 就是广播里念出来的那条具体内容——某某乘客请到 3 号站台14:05 发车行李限额 20 公斤。广播本身只是载体真正有价值的信息全在那条内容里而广播喇叭用的频段、音量、语速就是 PDCCH 的物理层参数。这个比方能解释很多设计选择广播得让所有人都能听清所以广播CSS公共搜索空间用的功率和聚合等级都偏保守而针对某个人的私信USS终端专属搜索空间可以省着点用资源。同时广播的覆盖范围有限这也对应了 PDCCH 天然比 PDSCH 更早遇到覆盖瓶颈的现象。从协议分层看DCI 属于物理层信令它不做重传、不做 ARQ一次发出去就是一次UE 没解出来就当作没收到。这一点决定了 PDCCH 的可靠性设计思路和 PDSCH 完全不同PDSCH 可以靠 HARQ 重传补回来PDCCH 只能靠提高聚合等级、加大功率、多配候选位置来提高一次成功的概率。理解了这一层后面所有的参数取舍都好理解了——为什么远点要往上抬聚合等级为什么搜索空间超配要按优先级丢本质都是在一次就得成功这个约束下做资源分配。1.2 PDCCH 占的是时频网格上哪块地NR 和 LTE 在控制信道的位置安排上走了完全不同的路。LTE 把 PDCCH 摊在整带宽的前 1 到 3 个符号里全带宽铺开好处是简单坏处是窄带终端也得听全带宽。NR 换了个思路控制信道的时频资源被容器化了这个容器就叫CORESETControl Resource Set控制资源集合。一个 CORESET 在频域上占若干组 PRB以 6 个 RB 为一个粒度用 45 bit 的位图描述最多覆盖 275 个 RB在时域上占连续的 1 到 3 个 OFDM 符号。UE 只在自己被配置的 CORESET 里去找 PDCCH不需要盯着整个带宽看。这个设计带来几个直接好处。第一UE 的接收带宽可以收窄省电这对物联网类终端很关键。第二同一个载波里不同业务、不同参数集可以配不同的 CORESET切片和业务隔离做起来自然。第三频域位置可以灵活避让遇到干扰可以选择在哪个 RB 段上放控制信道。代价是复杂度上来了。LTE 时代 UE 知道PDCCH 就在前 3 个符号里NR 时代 UE 得先知道我的 CORESET 长什么样。所以就有了一个鸡生蛋的问题UE 刚开机、还没建立任何 RRC 连接的时候怎么知道 CORESET 配置答案是CORESET#0它的配置在 MIB 里通过pdcch-ConfigSIB1这个 8 bit 的字段携带高 4 bit 是 CORESET#0 的索引低 4 bit 是搜索空间#0 的索引两者分别查协议里预定义的表格38.213 第 13 章那一堆表得到具体的时频资源。这就是为什么做小区初搜的人必须把那张表背下来。1.3 谁在发、谁在听、听多久发送侧永远是网络也就是 gNB。接收侧是所有被调度到的 UE。这里有个容易忽略的点PDCCH 是一对多的广播式信道但 DCI 内容是一对一的。基站把多个 UE 的 DCI 拼在同一个 CORESET 里发出去每个 UE 靠什么区分哪条是自己的靠RNTIRadio Network Temporary Identifier加扰 CRC。基站在计算 DCI 的 CRC 时把目标 UE 的 RNTI 混进去UE 收到后拿自己手里的 RNTI 去解 CRC对得上才认为这条 DCI 是给自己的。这个机制很巧妙UE 不需要在 DCI 里额外传一个 16 bit 的地址字段省了开销又天然实现了寻址。常见的 RNTI 有那么几类。系统消息用 SI-RNTI取值固定为 FFFF寻呼用 P-RNTI取值 FFFE随机接入过程用 RA-RNTI 和 TC-RNTI正常业务用 C-RNTI还有半静态调度和免调度用 CS-RNTI语音这类业务的 MCS 专用 C-RNTI 等。剩下的 0001 到 FFEF 这个区间是动态分配给各种用途的。搞清 RNTI 的归属很重要因为在抓包分析的时候第一步往往就是这条 DCI 是哪类 RNTI 加扰的它直接决定了 DCI 用什么格式、字段怎么解。听多久这件事也得说清楚。UE 不是一直在听。什么时候听由搜索空间配置里的monitoringSlotPeriodicityAndOffset监控的时隙周期和偏移、duration连续监控多少个时隙、monitoringSymbolsWithinSlot14 bit 位图指定时隙内哪些符号上开始听三个参数共同决定。周期可以配成每 1、2、4、5、8、10、16、20、40、80、160、320、640、1280、2560 个时隙监控一次。周期越长越省电但调度灵活性越差、时延越大。做物联网或省电特性的时候这个参数是重点调优对象。2. DCI 格式族谱不同场景该拿哪张条子2.1 上下行调度的主力0_x 与 1_x 两大家族DCI 格式多但归类其实很简单。0_x 系列管上行调度 PUSCH1_x 系列管下行调度 PDSCH数字后面的横杠代表版本或复杂度档位。0_0 和 1_0 是回退格式字段少、尺寸固定用在初始接入、公共消息调度、以及 RRC 重配期间的过渡阶段。0_1 和 1_1 是功能完整的调度格式支持多天线端口、多传输块、带宽部分切换、载波聚合指示等全套能力是连接态业务的主力。Rel-16 又加了 0_2 和 1_2 两个精简版字段更少、尺寸更小专门服务于低时延高可靠和对功耗敏感的终端——字段少意味着终端解析快、省电代价是调度灵活性下降。区分上下行还有个不起眼但很关键的位置DCI 的第一个比特。对 0_x 和 1_1 这些格式来说DCI 里有一个叫Identifier for DCI formats的 1 bit 字段取 0 表示上行、取 1 表示下行。做解析脚本的时候如果你的格式判断逻辑搞错了这一个 bit 会让后面所有字段全错位症状就是解出来的东西看起来是乱数。我踩过这个坑当时排查了半小时才发现是格式判断分支写反了。2.2 回退格式为什么必须一直保留有人会问既然 0_1/1_1 功能那么全为什么还要留一套功能残缺的回退格式这背后是可靠性兜底的设计哲学。设想一下UE 和基站之间对于完整格式的字段配置产生了理解偏差——比如 RRC 重配正好在切换的临界点或者某个可选字段网络侧以为配了、终端侧以为没配。这时候如果只有完整格式双方就彻底失联了只能靠重连。而回退格式的字段数量和含义是协议硬性规定的不依赖任何 RRC 可选配置双方一定能对齐。只要还能解出回退格式的 DCI链路就有恢复的可能。这个思路的实操价值在于排查UE 突然收不到调度的问题时先确认回退格式的调度是否正常。如果回退格式能调通、完整格式调不通那基本可以锁定是 RRC 配置理解不一致的问题方向就明确了。如果连回退格式都收不到那问题在更底层——覆盖、CORESET 配置、加扰参数这些。这个二分法我用了很多次非常省时间。2.3 不带调度的 2_x/3_x那些管理类指令2_x 系列和 3_x 系列不是用来调度数据传输的它们承载的是控制面信息。简单梳理一下DCI 格式承载内容加扰 RNTI典型用途2_0时隙格式指示SFISFI-RNTI动态告诉 UE 本时隙哪些符号是上行、下行、灵活2_1下行抢占指示INT-RNTI高优先级业务抢占资源时通知低优先级 UE 别解了2_2PUCCH/PUSCH 功控命令TPC-PUCCH-RNTI / TPC-PUSCH-RNTI组播式功控一条 DCI 带多个 UE 的 TPC2_3SRS 功控命令TPC-SRS-RNTI同上针对探测参考信号2_4上行取消指示CI-RNTIRel-16 引入通知 UE 撤回已发或待发的上行传输2_5可用性指示AI-RNTIRel-17 引入配合网络节能特性2_6节能指示PS-RNTIRel-16 引入指示 UE 在下一个 DRX 周期是否需要监听3_0 / 3_1侧行链路调度SL-RNTI / SL-CS-RNTIV2X 场景这张表建议直接存一份在手边。做外场排查的时候UE 明明没被调度数据为什么它的接收状态在变这类现象很多时候就是 2_0 的时隙格式指示或者 2_6 的节能指示在起作用跟业务调度没关系。2.4 拿 DCI format 1_1 做一次字段级拆解理论说再多不如把字段列出来。以最常见的 DCI format 1_1 为例它的字段构成大致是这样具体位数随配置变化字段位数说明格式标识1固定为 1表示下行载波指示0 或 3只有配置了跨载波调度时才有带宽部分指示0 / 1 / 2指示切换到哪个下行 BWP频域资源分配可变决定用哪种资源分配类型位数随 BWP 大小变化时域资源分配0 到 4索引到 RRC 配置的时域资源分配表VRB 到 PRB 映射0 或 1交织还是非交织PRB 捆绑尺寸指示0 或 1影响信道估计的粒度速率匹配指示0 / 1 / 2指示哪些 RE 要打孔ZP CSI-RS 触发0 / 1 / 2触发零功率参考信号MCSTB15调制编码等级NDITB11新数据指示用于判断是新传还是重传RVTB12冗余版本MCS/NDI/RVTB28双码字场景才有HARQ 进程号4指示用的是哪个 HARQ 进程下行分配索引0 / 1 / 2 / 4主要是给载波聚合下的 HARQ 反馈定序PUCCH 功控命令2PUCCH 资源指示3决定 HARQ 反馈用哪个 PUCCH 资源PDSCH 到 HARQ 反馈定时3即 K1决定几个时隙后反馈天线端口4 / 5 / 6DMRS 端口和 CDM 组传输配置指示0 到 3即 TCI波束指示SRS 请求2 或 3触发非周期 SRSDMRS 序列初始化1优先级指示1Rel-16 引入用于业务优先级区分看这张表能明白一件事DCI 里最值钱的三个字段是频域资源分配、时域资源分配、MCS。频域和时域资源分配决定了 UE 去哪个时频位置收数据MCS 决定了用什么调制编码。这三个字段一旦译错UE 就会到错误的位置用错误的速率去解调结果必然是解不出来。而这三个字段里频域资源分配的位数是动态的、最容易被搞错的因为它取决于 BWP 的 PRB 数量。顺便说个链路自适应上的差别PDSCH 的 MCS 有 CSI 反馈做依据网络侧知道信道质量但PDCCH 的聚合等级没有直接的 CSI 反馈支撑只能靠上行 RSRP/SINR 估计加上 HARQ 的统计做外环调整。这个差别是做 PDCCH 优化时最重要的一条认知——它意味着 PDCCH 的链路自适应天然比 PDSCH 迟钝需要留更大的余量。3. 把 PDCCH 的资源掰开算CORESET、REG、CCE 与聚合等级3.1 CORESET先给控制信道划一块地CORESET 的配置项不多但每一项都直接影响容量和覆盖。频域用 45 bit 位图描述每个 bit 对应 6 个 RB从 BWP 的起始位置开始数。这个粒度限制意味着 CORESET 的频域资源数一定是 6 的倍数最小时 6 个 RB。时域用duration描述取值 1 到 3 个符号。Rel-15 里每个下行 BWP 最多配 3 个 CORESET、10 个搜索空间这个数字在做密集调度和频谱效率优化的时候经常成为瓶颈。CORESET 的时域长度怎么选1 个符号的控制信道开销最小但如果小区覆盖半径大、需要多个符号做更长的编码3 个符号更合适。我一般的经验是密集城区、小站、室内覆盖1 到 2 个符号把资源留给数据广覆盖、高铁、远海这类场景2 到 3 个符号优先保控制信道的可靠解调。另外符号数还影响 REG 捆绑尺寸的取值——1 个和 2 个符号时可取 2 或 63 个符号时可取 3 或 6这个后面细说。还有两个容易被忽略的配置项precoderGranularity决定 UE 在做信道估计时能不能假设整个 REG 捆绑内用同一套预编码sameAsREG-bundle还是所有连续 RB 都用同一套allContiguousRBs。选前者信道估计精度更高但资源调度灵活度受限选后者相反。另一个是pdcch-DMRS-ScramblingID也就是 PDCCH 的加扰 ID不配就默认用小区 ID。这个参数的坑在于如果网络侧配了、终端侧没收到或者反过来那 UE 解出来的就是一堆噪声而且从日志上看不出任何异常只会表现为盲检全失败。做参数核查时这是必查项。3.2 从 REG 到 CCE一个 CCE 到底能装多少比特这部分的账一定要算清楚不然没法评估 PDCCH 容量。最小的资源单位是REG1 个 PRB × 1 个 OFDM 符号共 12 个 RE。这 12 个 RE 里有 3 个要拿去做解调参考信号剩下 9 个 RE 才承载控制信息。PDCCH 固定用 QPSK 调制每个 RE 装 2 个比特所以1 个 REG 能装 18 个比特。往上一层是CCE1 个 CCE 等于 6 个 REG也就是 108 个比特。再往上是聚合等级Aggregation LevelAL就是这条 PDCCH 用几个 CCE 来发。NR 支持 AL 1、2、4、8、16 五档。这么一算各档的编码后比特数就出来了聚合等级 ALCCE 数REG 数数据 RE 数编码后比特数 E极化码 N116541081282212108216256442421643251288484328645121616968641728512这张表是整个 PDCCH 容量分析的基石。比如你想知道一个 2 符号、20 个 RB 的 CORESET 里能塞多少条 AL4 的 PDCCH那就先算这个 CORESET 总共有几个 CCE频域 20 个 PRB 按 6 的倍数向下取整是 18 个 PRB也就是 3 个 REG 束位每个 6 RB时域 2 个符号所以总 REG 数是 3 × 2 6 个前后……不对这里要按 REG 算18 个 PRB × 2 个符号 36 个 REG除以 6 得 6 个 CCE。那么理论上最多能放 1 条 AL4 加 1 条 AL2或者 6 条 AL1。这就是这个 CORESET 的容量上限。3.3 聚合等级的选型逻辑与三个约束聚合等级本质上是用资源换可靠性。AL 越大编码后的冗余越多抗噪能力越强但占用的 CCE 也越多能同时服务的 UE 越少。选型要同时满足三个约束。第一个约束是覆盖。信道质量差的时候必须抬 AL。工程上的粗略估计是AL1 适合 SINR 较好的近点AL2 到 AL4 适合中点AL8 和 AL16 给小区边缘。但这不是绝对标准还要看 CORESET 的时域符号数和 REG 捆绑尺寸因为频率分集的效果不一样。第二个约束是容量。CORESET 里的 CCE 总数有限如果所有 UE 都抬到 AL8一个 CORESET 只能服务一两条 PDCCH调度器立刻被憋死。所以实际网络里都有一个聚合等级分布的目标比如近点 50% 在 AL1/2中点 35% 在 AL4边缘 15% 在 AL8/16。这个分布偏离太多通常意味着链路自适应参数有问题。第三个约束是候选位置数。搜索空间里每个 AL 配几个候选nrofCandidates如果某个 AL 只配了 1 个候选那这个 AL 在同一时隙内只能发一条 PDCCH多用户冲突时调度器会排队。我见过一个现场的配置AL8 只配了 1 个候选结果小区边缘用户一多就开始出现调度时延抖动把 AL8 候选加到 2 个就缓解了。这种问题看 KPI 是看不出来的得看配置。3.4 CCE-to-REG 映射交织映射带来的频率分集CCE 和 REG 之间怎么对应有两种方式。非交织映射就是把 REG 束按顺序编号CCE 依次占用相邻的 REG 束映射关系接近恒等映射。这种方式的优点是实现简单、基站侧调度自由度高缺点是同一条 PDCCH 占的 RB 都挤在一起如果这段频率正好遇到衰落整条 PDCCH 就废了。交织映射则是通过一个交织矩阵交织器尺寸 R 取 2、3 或 6再加一个 shiftIndex 偏移把 REG 束打散到整个 CORESET 频域上让一条 PDCCH 跨越较宽的带宽从而获得频率分集增益。选择依据很直接覆盖受限的场景用交织映射容量受限的场景用非交织映射。为什么因为交织映射要求 UE 在整个 CORESET 带宽上都保持较好的信道估计质量终端需要更宽带的参考信号处理而且在某些情况下交织映射会限制基站把 REG 束分给不同 PDCCH 的灵活性。反过来在小区边缘频率分集带来的增益比灵活性更重要。有一个实操细节值得记一笔非交织映射时REG 束的编号是束内连续CCE 之间的对应关系相对直接而交织映射涉及一个二维矩阵的行列读写过程做链路级仿真的时候这一步很容易写错。我自己写仿真代码时是先拿协议里的示例数值手工验算一遍矩阵结果确认无误再往上搭这个习惯省了很多返工时间。4. 搜索空间与盲检UE 不知道位置怎么找到自己的 DCI4.1 哈希函数把候选位置定下来UE 不知道自己的 DCI 在 CORESET 的哪几个 CCE 上它只能试。试的位置不能随便定否则基站就不知道往哪儿发。协议给出的解法是用一个哈希函数把候选位置算出来基站和终端各自算一遍算出来的结果必须一致。对于公共搜索空间CSS这个哈希值恒为 0也就是说 CSS 的候选位置是固定的每个时隙都一样——这正是 SIB1、寻呼、随机接入这些公共消息能被可靠接收的基础。对于终端专属搜索空间USS哈希值随每个时隙变化Y(p, n) (A_p × Y(p, n-1)) mod D 其中 Y(p, -1) n_RNTI D 65537 A_p 39827 当 (p mod 3) 0 39829 当 (p mod 3) 1 39839 当 (p mod 3) 2 p 是 CORESET 的索引n 是帧内的时隙号算出 Y 之后第 m 个候选占用的 CCE 编号是L × { (Y floor(m × N_CCE / (L × M)) n_CI) mod floor(N_CCE / L) } i 其中 L 是聚合等级M 是该聚合等级下的候选数 N_CCE 是 CORESET 里的 CCE 总数n_CI 是载波指示i 取 0 到 L-1这套机制的作用是随机化如果两个 UE 的候选位置总是撞在一起会持续冲突随时隙变化的哈希让冲突在时间上被打散。理解了这一点就能解释一个现象——为什么同一个小区的两个 UE一个偶尔调度时延大、另一个很稳定很有可能就是 RNTI 的哈希值让其中一个总是撞在同一个候选上。4.2 盲检次数的上限是怎么算出来的盲检是终端的计算负担大头所以要设上限。协议按子载波间隔规定了每时隙、每服务小区最多监控的 PDCCH 候选数和 CCE 数子载波间隔μ最大候选数/时隙最大非重叠 CCE 数/时隙15 kHz0445630 kHz1365660 kHz22248120 kHz32032这张表有两层约束候选数是一层CCE 数且要求非重叠是另一层。为什么还要限制 CCE 数因为终端做盲检时解码的主要成本是极化码译码和 CRC 校验而一条 AL16 的候选消耗的计算量和资源量是 AL1 的 16 倍。只限制候选数不够还得限制总资源量。实际配置时把所有搜索空间的候选数加起来不应该超过表里的值。举个常见配置USS 里 AL1 配 4 个、AL2 配 4 个、AL4 配 2 个、AL8 配 1 个合计 11 个候选占用 CCE 数 4×1 4×2 2×4 1×8 28 个。距离 44 和 56 还有余量属于比较健康的配置。我见过有现场把 AL1 配到 6 个、AL2 配到 6 个加起来虽然没超但因为频繁的 AL1 调度让终端的活跃度上去了功耗测试数据不好看——盲检次数和终端功耗是直接相关的。4.3 搜索空间超配时的丢弃优先级如果配置的候选数或 CCE 数超了上限怎么办总不能要求终端超能力工作。协议的做法是按优先级丢弃低优先级的搜索空间终端只监控排在前面的那些。优先级的大致顺序是索引为 0 的公共搜索空间承载 SIB1 调度、寻呼、随机接入这些最不能丢的消息索引不为 0 的公共搜索空间对应 SI-RNTI、RA-RNTI、TC-RNTI、P-RNTI 这类索引不为 0 的公共搜索空间对应 C-RNTI、CS-RNTI 等终端专属搜索空间具体到每个级别内部的排序规则和丢弃算法还是要对着 38.213 第 10.1 节逐条核对因为里面还涉及 CSS 和 USS 之间的 CCE 重叠判定等细节。这个优先级机制给我们的启示是不要把关键业务的调度全压在 USS 上。如果一个现场配置里 USS 塞得满满当当同时又要保证时延敏感业务的可靠性那可以在 Type3 公共搜索空间里也配置一些 C-RNTI 的监控机会做备份。代价是多占一点控制信道资源收益是关键业务在超配丢弃时依然有调度通道。4.4 DCI size 对齐3 种和 4 种两条红线这是 PDCCH 里最烧脑的一块但也是最容易出低级错误的地方。问题是这样的终端不知道收到的 DCI 是什么格式只能按自己配置的每种可能的尺寸去试。如果网络侧配置了很多不同的 DCI 尺寸终端的盲检组合数会爆炸。所以协议设了两条红线用 C-RNTI 加扰的终端专属搜索空间里不同的 DCI 尺寸不超过 3 种所有 DCI 尺寸合计不超过 4 种。超过红线怎么办靠尺寸对齐把数量压下来。基本手段有两条。第一条是回退格式强制对齐DCI format 0_0 和 1_0 的尺寸必须相同小的一方补零。这样一对上下行回退格式只算一种尺寸。第二条是完整格式之间对齐如果 USS 里同时配了 0_1 和 1_1它们的尺寸要凑成一样同样是小的补零。而且回退格式的大小不能超过完整格式的大小超了就截断。此外回退格式的尺寸还被限制在一组固定的档位上大约 12、14、16、20、24、26、32、40、44、56 比特这几个级别如果实际算出来的尺寸不落在这些档位上就补零凑到最近的档位。这一条我建议你对着手上的 38.212 第 7.3.1.0 节再确认一遍具体表格不同版本在细节上可能有补充说明。这些规则带来一个很实际的后果DCI 里会存在一些填充比特或预留比特它们不承载任何信息。做 DCI 解析脚本的时候必须把这些位算进去否则字段偏移会错。我见过一个团队的解析工具就是因为漏掉了 0_0 对齐补的零导致在某个配置下解出来的 MCS 总是比实际值小 4排查了两天才定位到。5. 端到端走一遍从 RRC 配置到空口上解出 DCI5.1 发送链路全景CRC、极化码、加扰、QPSK、REG 映射一条 DCI 从比特到空口要过这么几道工序尺寸对齐与补零按前面说的规则把 DCI 载荷补齐到最终尺寸 A。CRC 附着计算 24 bit 的 CRC 并附在载荷后面同时 CRC 要跟 RNTI 绑定——UE 侧用自己手里的 RNTI 去解这个 CRC能对上就说明这条 DCI 是给自己的。这个设计同时完成了检错和寻址两件事非常经济。极化编码NR 的 PDCCH 用极化码Polar Code。编码前先根据码长和码率确定母码长度 N2 的幂次最大 512做信道极化、子信道映射、以及基于可靠度排序的信息位选择最后按 E 的长度做速率匹配子块交织加上循环缓冲区的比特选择。加扰对编码后的 E 个比特做伪随机加扰加扰序列由 RNTI 和加扰 ID 共同决定。这一步的作用是让不同 UE 的 PDCCH 在统计上看起来像随机序列降低相互干扰。QPSK 调制固定 QPSK不做高阶调制。为什么因为控制信道要保可靠用低阶调制换取解调余量是划算的。层映射与预编码PDCCH 只用一个天线端口端口号固定为 2000多天线场景下靠波束赋形而不是空间复用来提升性能。REG 映射按 CCE-to-REG 映射规则把调制符号填到 CORESET 的 REG 上同时避开 DMRS 占用的那 3 个 RE。把这七步走通一遍你对 PDCCH 的理解就会有质的提升。做链路仿真的人最容易被卡住的是第三步的速率匹配和第七步的映射因为这两步涉及比较多的索引运算。5.2 用脚本把每个聚合等级的 E 和 N 算清楚手工算上面那张表容易出错写个脚本一劳永逸import math def pdcch_coded_bits(al): 返回某聚合等级下 PDCCH 编码后的比特数 E regs 6 * al # 1 个 CCE 6 个 REG data_re regs * 9 # 每个 REG 12 个 RE其中 3 个给 DMRS return data_re * 2 # QPSK每 RE 2 bit def polar_mother_n(E, n_min5, n_max9): 根据 E 反推极化码母码长度 N 2^n n1 math.ceil(math.log2(E)) if E (9 / 8) * 2 ** (n1 - 1): n1 - 1 n1 max(n_min, min(n1, n_max)) return 1 n1 for al in (1, 2, 4, 8, 16): E pdcch_coded_bits(al) N polar_mother_n(E) print(fAL{al:2d} E{E:5d} bit N{N:4d} 有效码率 K/N 参考值)跑出来的结果跟前面那张表一致。有了这个脚本你在评估某个 AL 能不能装下某条特定尺寸的 DCI时就有底了DCI 载荷加上 24 bit CRC 得到 KK 除以 N 就是实际码率。码率超过 0.8 左右的时候译码性能会明显下降这时候要么抬聚合等级要么精简 DCI 字段。这个经验阈值在链路预算的时候很好用。顺便提醒一个细节当 DCI 载荷尺寸很小比如小于等于 11 比特的时候协议里还有额外的重复处理目的是保证极化码有足够的输入长度、维持分集效果。这一段的具体处理规则建议直接翻 38.212 的第 7.3.2 到 7.3.3 小节不同格式的处理顺序不完全一样。5.3 加扰序列与 DMRS 序列的生成细节这两个序列的初值公式经常被搞混我把它们写在一起对比PDCCH 数据加扰序列初值 c_init (n_RNTI × 2^16 n_ID) mod 2^31 其中 n_ID 优先取 pdcch-DMRS-ScramblingID未配置时取物理小区 ID PDCCH 解调参考信号序列初值 c_init (2^17 × (N_slot_symbol l 1) × (2 × n_ID 1) 2 × n_ID) mod 2^31 其中 N_slot_symbol 是时隙内的符号数常规 CP 下为 14 l 是当前符号在时隙内的编号注意数据加扰的初值里带了 RNTI而 DMRS 的初值里没带——这是一个很关键的差别。它意味着即使两个 UE 的 RNTI 不同只要它们在同一个 CORESET 的同一个符号上DMRS 序列是一样的。同一时隙内不同符号的 DMRS 不同靠的是l这个变量。所以在做干扰分析的时候如果发现两个小区的 DMRS 序列总是相同那就要检查它们的加扰 ID 是不是都用了同一个小区 ID——邻近小区配相同的加扰 ID 会造成 DMRS 之间的持续碰撞信道估计精度会掉。5.4 一份可以直接抄的 CORESET / SearchSpace 配置下面是一份 FR1、30 kHz 子载波间隔下的参考配置一个 2 符号、60 个 RB 的 CORESET加一个每时隙监控的终端专属搜索空间controlResourceSetToAddModList { controlResourceSetId 2, -- 45 bit 位图每 bit 对应 6 个 RB前 10 个 bit 置 1 表示占 60 个 RB frequencyDomainResources 111111111100000000000000000000000000000000000, duration 2, -- 2 个 OFDM 符号 cce-REG-MappingType interleaved { interleaved { reg-BundleSize n6, -- REG 捆绑尺寸 6 interleaverSize n2, -- 交织器尺寸 R 2 shiftIndex 0 } }, precoderGranularity sameAsREG-bundle, pdcch-DMRS-ScramblingID 511, tci-StatesPDCCH-ToAddList { 3 } } searchSpacesToAddModList { searchSpaceId 3, controlResourceSetId 2, monitoringSlotPeriodicityAndOffset { sl1: NULL }, -- 每个时隙都监控 duration 1, monitoringSymbolsWithinSlot 10000000000000, -- 时隙内第 0 个符号 nrofCandidates { aggregationLevel1 n4, aggregationLevel2 n4, aggregationLevel4 n2, aggregationLevel8 n1, aggregationLevel16 n0 }, searchSpaceType ue-Specific { dci-Formats formats0-1-And-1-1 } }这份配置里的候选数合计 11 个占用 CCE 数为 4×1 4×2 2×4 1×8 28都在上限之内。CORESET 的容量算一下60 个 RB 除以 6 得 10 个频域 REG 束位乘以 2 个符号得到 20 个 CCE。这个容量支撑 11 个候选、28 个 CCE 的配置是够的但如果同一时隙要调度的用户数再多就得考虑扩容或者把部分用户挪到另一个 CORESET。几个配置上的心得。第一monitoringSymbolsWithinSlot选第 0 个符号是最省时的做法控制信道越早发UE 越早开始解 PDSCH但符号 0 也可能被用于同步信号等场景要看具体帧结构。第二reg-BundleSize选 6 时 REG 束跨 2 个符号、共 6 个 REG这种时频二维捆绑能同时获得时间和频率分集但要求信道在 2 个符号内基本不变高速移动场景要谨慎。第三shiftIndex在同一小区的不同 CORESET 之间最好不要一样能进一步降低小区内碰撞概率。5.5 三组对比实测聚合等级与 PDCCH 开销的变化下面这组数字是我在一次室内衰减可控的对比测试里记下来的测试方式是把终端放在不同衰减档位上跑满缓冲业务统计 PDCCH 的聚合等级分布和控制信道开销占比。测试档位主要聚合等级分布PDCCH 控制开销占比平均盲检次数/时隙观察到的现象近点低衰减AL1 约 55%、AL2 约 35%8% 到 12%4 到 6调度连续几乎无丢包中点中等衰减AL2 约 30%、AL4 约 50%、AL8 约 20%15% 到 20%6 到 9偶尔出现调度时延抖动远点高衰减AL8 约 40%、AL16 约 45%22% 到 30%8 到 12控制信道成为覆盖瓶颈绝对值一定跟设备、带宽、帧结构、业务模型有关但趋势是普遍成立的聚合等级每抬一档控制信道占用的资源大致翻倍。这就解释了一个常见的容量问题——小区边缘用户比例一高PDCCH 的开销会非线性上升因为边缘用户既要用高聚合等级又因为速率低而占用更多的调度机会。这时候光调 PDSCH 的 MCS 是没用的得从控制信道入手增加 CORESET 的符号数、扩容 CCE 数、或者调整聚合等级分布的目标。还有一个细节值得分享远点场景下 AL16 用到 45% 这个比例偏高我后来把外环调整的目标 BLER 从 1% 放宽到 2% 到 3%AL16 的占比明显下降整体吞吐反而有改善。原因是 PDCCH 虽然有保护但过高的聚合等级吃掉了本可以给数据用的资源。PDCCH 的目标 BLER 不一定要死守 1%具体取值要看业务对控制面可靠性的需求这个后面还会再说。6. 排查实录PDCCH/DCI 出问题时从哪儿下手6.1 UE 一直检不到 DCI 的五个方向这是最常见也最让人头大的问题。终端侧表现为随机接入过不去或者连上了但一直没数据。我一般按下面的顺序倒推从最可能到最不可能第一加扰 ID 是否一致。网络侧配了pdcch-DMRS-ScramblingID终端侧如果没拿到或者拿了默认值解出来就是纯噪声。这个问题的特点是完全没有规律——不是概率性失败而是百分之百失败。排查方法是对比两侧的配置或者临时把这个参数去掉让双方都用小区 ID 试试。第二CORESET 的频域位图是否一致。45 bit 位图一个 bit 错了UE 就会在错误的 RB 上找控制信道。这个问题在跨厂家对接的时候特别容易出因为位图的组织方式从 BWP 起始还是从载波起始位序方向在不同实现里可能有细微差别。第三搜索空间配置是否对得上。包括监控周期、时隙内监控符号的位置、每个聚合等级的候选数。如果这些不一致UE 就会在错误的时间点去看错误的候选位置表现也是完全收不到。第四RNTI 是否匹配。尤其是 CS-RNTI、MCS-C-RNTI 这类需要专门分配的 RNTI如果分配过程出了问题UE 手上没有正确的值CRC 永远校验不过。第五覆盖是否真的不够。前面四项都排除了才会怀疑覆盖。这时候看的是 RSRP/SINR 和配置的聚合等级是否匹配——有时候是调度器给的聚合等级太低UE 在边缘用 AL1 硬扛失败率自然高。这个顺序的价值在于它是从确定性问题到概率性问题的排列。前四项错了一个就是百分百失败跟概率无关第五项才是概率性的。先把确定性问题排干净效率最高。6.2 DCI 检到了但字段全乱尺寸与字段顺序的坑比检不到更隐蔽的问题是DCI 解出来了CRC 也过了但字段值是错的。CRC 能过说明前面的加扰、解调、译码、RNTI 都是对的问题一定在比特到字段的映射上。可能的原因有三个。第一个是尺寸对齐的补零位置搞错。补零是在 DCI 载荷的末尾补不是在开头也不是插在中间。有些实现习惯性地在开头补零结果整个字段序列偏移。第二个是可选字段的存在性判断错。DCI format 1_1 里有一堆0 或 1 或 2 比特的可变字段它们的实际位数取决于 RRC 配置比如是否配了载波聚合、带宽部分指示的比特数取决于配了几个 BWP、速率匹配指示的比特数取决于配了几个速率匹配图案。如果解析脚本硬编码了位数换个配置就崩。这就是为什么解析器一定要跟配置绑定。第三个是字段的排列顺序记错。协议里每个格式的字段顺序是固定的而且不同格式之间差距不小。比如上行格式里有 SRS 资源指示、预编码信息这些下行没有的字段下行格式里有 PUCCH 功控、HARQ 反馈定时这些上行没有的。建议的做法是先写一张格式到字段列表的配置表解析时按表逐字段推进偏移量而不是把偏移量写死在代码里。# 以 format 1_0 为例把字段定义成表解析时逐项推进 FIELDS_1_0 [ (format_flag, 1), (fdra, None), # None 表示位数需要按 BWP 大小算 (tdra, 4), (vrb_to_prb, 1), (mcs, 5), (ndi, 1), (rv, 2), (harq_id, 4), (dai, 2), (tpc_pucch, 2), (pucch_res_ind, 3), (k1, 3), ] def fdra_bits(n_rb): import math return math.ceil(math.log2(n_rb * (n_rb 1) / 2)) def parse_dci(bits, fields, n_rbNone): pos, out 0, {} for name, width in fields: if width is None: # 动态位数的字段 width fdra_bits(n_rb) out[name] int(bits[pos:pos width], 2) pos width return out, pos这段代码的核心思路是字段定义和解析逻辑分离。换个 DCI 格式改一下字段表就行不用动解析函数。字段表里的None表示需要运行时计算的动态位数这个设计能避免硬编码带来的隐患。6.3 覆盖优先还是容量优先聚合等级的现场取舍这个问题没有标准答案但有几个判断依据。看业务类型。eMBB 业务对时延不敏感控制信道可以省着点用让聚合等级分布尽量往低调URLLC 业务要求一次成功宁可多占资源也要保证可靠性聚合等级往上抬是合理选择。看小区边缘用户比例。如果边缘用户占比高PDCCH 开销会急剧上升这时候单纯抬聚合等级会形成恶性循环——边缘用户占用大量 CCE导致控制信道拥塞调度时延上升边缘用户感知更差。破解办法是扩容 CORESET增加符号数或频域 RB 数先把池子做大。看终端的盲检能力。增加候选数能提高调度灵活度但也增加终端计算量和功耗。测试机和商用机的盲检能力差别很大配置的时候要按商用机的规格来。我自己的经验参数是PDCCH 的控制开销占比控制在 15% 以内比较健康超过 25% 就要警惕了。这个值可以在基站侧统计也可以在路测仪上直接读出来。另外我通常会盯着AL16 占比这一个指标它超过 20% 基本就说明控制信道的覆盖或容量已经出问题了。还有前面提到的那条目标 BLER 不一定非要 1%。PDCCH 是一次性的但业务本身有 HARQ 兜底偶尔漏检一条 DCI 无非是这次调度浪费了下个时隙重新调就是。把目标 BLER 从 1% 放宽到 2% 到 3%可以让聚合等级分布整体往下走一档省下来的资源给数据信道整体吞吐通常是涨的。这个调整需要观察端到端的时延和吞吐指标变化不能只看 PDCCH 自己的成功率。6.4 PDCCH 问题速查表把前面这些整理成一张速查表出问题的时候按顺序过一遍现象可能性最高的原因首选排查动作完全收不到任何 DCI加扰 ID 不一致对比两侧 pdcch-DMRS-ScramblingID临时置空重试完全收不到任何 DCICORESET 频域位图错逐 bit 核对 45 bit 位图与 RB 对应关系收不到专属调度、但公共消息正常USS 配置错检查搜索空间 ID、监控周期、DCI 格式组合DCI CRC 过不了RNTI 不匹配核对 RNTI 分配流程和取值DCI 能解但字段值全错尺寸对齐补零位置错检查补零是否在载荷末尾、预留位是否计入偏移DCI 能解但个别字段错可变位数字段硬编码把位数改成按 RRC 配置动态计算边缘用户调度时延抖动高聚合等级候选数不足检查 AL8/AL16 的 nrofCandidates 是否只有 1整体吞吐上不去、控制开销高聚合等级分布偏高统计 AL 分布复核目标 BLER 设置终端功耗测试不达标盲检次数过多核算候选总数与 CCE 总数精简 USS 配置同小区两用户表现差异大哈希碰撞检查两用户 RNTI 是否导致候选位置长期重叠这张表用起来有个技巧先把完全收不到和能收到但不对分开。前者的问题百分百在物理层和配置层后者的问题基本在解析层和尺寸规则层。分成两大类之后排查范围直接砍一半。前面几节里我埋了不少以你手上的协议版本为准的提醒不是客套话。NR 的协议从 Rel-15 到 Rel-17 一直在演进DCI 格式有新增2_4、2_5、3_0、3_1盲检能力有增强Rel-16 按不同的监控能力分档搜索空间的配置约束也在变。我自己做方案的时候有个固定习惯凡是涉及位数和取值的结论都要在当前的协议版本里再确认一遍尤其是跨版本对接的场景。曾经有一次就是因为一方按 Rel-16 的盲检能力算容量、另一方按 Rel-15 的规矩配对接时才发现两边的候选数上限对不上白折腾了一轮。做 PDCCH 这一块资源账算得细不细最后都会反映在调度器的自由度和终端的实测指标上这个功夫省不得。