PDCCH解不出来业务全完蛋。我做过好几次5G NR外场排障UE上行失步、RRC重建风暴、VoNR挂断追到根因十有八九都落在PDCCH这条链路上——要么是CORESET配置和实际资源对不上要么是DCI尺寸模糊导致UE盲检直接失败。5G NR的PDCCH和LTE完全不是一个玩法引入CORESET和Search Space之后灵活性大幅提升但排障和优化的复杂度也上来了。这篇文章就把PDCCH从头到尾拆一遍从DCI格式、CORESET配置、Search Space设计到UE侧的盲检流程和现网排障经验全部讲清楚。不管你是刚接触5G协议栈的研发、测试工程师还是做无线网优的同事这条链路里的细节都值得花时间吃透。文章里的参数都是实际配置和协议里能查到的值我会把每个关键选择背后的逻辑也讲明白方便你直接用到项目里。1. PDCCH在5G NR物理层中的定位与整体架构1.1 从LTE到NR为什么PDCCH设计要彻底重构LTE时代的PDCCH占满整个载波带宽的前1到3个OFDM符号UE在每个子帧都要在系统带宽上盲检。带宽只有20MHz的时候这个方案问题不大但NR最大支持400MHz载波带宽如果沿用全带宽盲检的思路UE的基带处理复杂度和功耗都会被拖垮调度灵活性也受限于时域符号位置。NR最终采用了CORESET加Search Space的解耦设计。CORESET控制资源集用来限定PDCCH在频域上占用的PRB集合和时域上占用的OFDM符号数Search Space则在CORESET的基础上进一步限定UE应该在哪些时域位置、用哪些聚合等级、盲检哪些候选PDCCH。这样PDCCH不再固定在频带边缘或前几个符号而是可以散布在带宽内任意一段连续的PRB上。基站可以按需把控制信道放在频带中间以缩短调度时延也可以放在边缘以换取频率分集增益。这个设计也直接影响了5G对URLLC等低时延场景的支持。URLLC要求调度周期极短PDCCH如果能紧贴PDSCH/PUSCH所在的时隙和符号调度信令的传输时延就能压得很低。LTE那种固定在子帧首部的PDCCH做不到这一点所以NR把时域位置交给Search Space灵活控制允许PDCCH出现在时隙内的不同符号位置。1.2 资源单位梳理REG、CCE、聚合等级PDCCH相关的资源单位有这样几个层级搞清楚它们的关系再往下看就不会乱REGResource Element Group资源元素组。1个REG对应频域1个PRB、时域1个OFDM符号也就是12个RE。CCEControl Channel Element控制信道单元。1个CCE等于6个REG即72个RE。一个PDCCH按照聚合等级占用不同数量的CCE。聚合等级Aggregation Level有1、2、4、8、16五档分别对应1、2、4、8、16个CCE。聚合等级的含义可以理解为重复次数。AL1表示用最少的资源承载一份DCI开销小但抗干扰能力弱AL16表示用16个CCE承载一份DCI冗余度极高适合边缘覆盖场景。实际网规中小区边缘用户通常会配置AL8或AL16中心用户用AL1或AL2就够了。需要特别注意CCE到REG的映射不是简单的一对一连续映射而是由CORESET里的cce-REG-MappingType决定采用交织还是非交织方式。这个细节我在第3章详细讲它是理解PDCCH资源分布的关键。1.3 PDCCH的RE映射与DMRS设计PDCCH使用QPSK调制和PDSCH支持的256QAM相比效率低很多但这是为了换取控制信道的可靠性。控制信道一旦解错整个时隙的调度信息就丢了所以宁可用低阶调制保证误码率。每个REG的12个RE里有4个RE固定放DMRS用于信道估计。DMRS在REG内的位置有两种图样对于单符号CORESETDMRS占用REG内第1、5、9个RE编号从0算起的话是0、4、8对于双符号CORESET第一个符号用同样的位置第二个符号会多一套DMRS。UE靠这些已知的DMRS做信道估计然后对数据RE做QPSK解调。如果DMRS位置估计错了后面Polar译码性能会明显下降这也是排查PDCCH BLER误块率偏高时要重点检查的环节之一。2. DCI格式全解从内容到尺寸2.1 DCI格式分类与各自的使用场景DCIDownlink Control Information下行控制信息是PDCCH承载的载荷。NR定义了0_0、0_1、1_0、1_1、2_0、2_1、2_2、2_3等格式比LTE丰富很多。其中调度普通业务数据主要用0_x和1_x2_x系列是特殊用途。0_0回退模式的上行调度授权UL grant格式短不依赖UE专有配置因此Msg3和RRC重配前的上行传输都用它。0_1非回退模式的上行调度授权字段丰富支持BWP切换指示、载波指示、SRS资源指示等依赖RRC配置普通业务的上行调度都用它。1_0回退模式的下行调度分配DL assignment同样格式短用于SIB1、RAR、寻呼等公共信道的调度。1_1非回退模式的下行调度分配字段丰富支持多天线传输、BWP切换、PDSCH聚合等。2_0时隙格式指示SFI告诉UE一个时隙里哪些符号做下行、哪些做上行、哪些是灵活符号。2_1抢占指示用于URLLC场景告知UE某块资源被高优先级业务抢占。2_2PUCCH和PUSCH的TPC命令。2_3SRS的TPC命令或SRS请求。从UE的角度看2_x系列在公共搜索空间里盲检0_x和1_x在UE专用搜索空间里盲检但也有例外比如回退格式0_0和1_0在公共搜索空间和UE专用搜索空间都可以出现取决于实际配置。2.2 核心DCI字段解析0_0/1_0与0_1/1_1对比回退格式1_0的关键字段包括频域资源分配在初始BWP内指示PDSCH占用的RB集合。时域资源分配通过一个索引指向高层配置的时域资源分配表。VRB到PRB映射指示是否交织映射。调制编码方案MCS、HARQ进程号、NDI、RV这组字段和PDSCH传输的具体编解码、重传相关。TPC命令用于调整PUCCH的发射功率。PDSCH到HARQ反馈定时指示PDSCH解调后多少毫秒反馈ACK/NACK。PUCCH资源指示告诉UE用哪个PUCCH资源上报。这些字段里时域资源分配是一个索引值比如4bit的索引指向RRC配置的pdsch-TimeDomainAllocationList列表里每个条目包含起始符号位置S、时域长度L、PDSCH映射类型。UE拿到这个索引后再查表就知道PDSCH落在哪几个符号上了。0_1和1_1比回退格式多了载波指示、BWP指示、天线端口、SRS请求、CSI请求、下行分配指示DAI等字段。多了这些字段DCI长度变长在相同聚合等级下占用更多资源。但非回退格式带来的收益是调度灵活性和频谱效率的提升尤其是BWP指示可以让UE在同一个DCI里完成带宽切换不用额外走RRC重配。2.3 DCI尺寸对齐与模糊性问题这里有一个实际工作中绕不过去的坎DCI尺寸对齐DCI size alignment和尺寸模糊size ambiguity。NR协议要求在同一个搜索空间里0_0和1_0的DCI尺寸必须对齐。如果配置下来两者长度不同协议规定要在短的DCI前面补零直到两者一样长。同样0_1和1_1也要对齐。这样做的目的是减少UE盲检时对DCI格式的判断次数——UE在某个候选位置解出一个DCI后不需要先判断它是0格式还是1格式因为两种格式长度相同用RNTI解掩码后自然就知道是哪一种。这带来一个新问题如果0_0和1_0对齐后的尺寸恰好和0_1或1_1对齐后的尺寸一样UE就无法从长度上区分回退格式和非回退格式。协议里要求避免这种冲突但在实际配置中尤其是一些工具自动生成的参数里很容易出现尺寸碰撞。一旦发生UE可能把1_1的DCI当成1_0去解析字段全部错位结果就是PDSCH调度错乱、HARQ异常。我在第6章会给出一个实际排查案例。3. CORESET配置实战频域、时域与映射方式3.1 CORESET关键参数解读CORESET是PDCCH资源的基本容器配置在RRC的ControlResourceSet IE中。核心参数有这几个controlResourceSetIdCORESET的ID0号CORESET有特殊含义后面讲。frequencyDomainResources频域资源位图48bit。每1bit对应6个PRB从带宽的起始频点开始按序编号。位图里1表示该6个PRB属于这个CORESET。6个PRB不是随意定的这是协议在均衡配置粒度和信令开销后选出来的值。duration时域连续符号数取值1、2、3。CORESET不能跨时隙。cce-REG-MappingTypeCCE到REG的映射方式交织或非交织。reg-BundleSizeREG捆绑大小。交织映射时取2或6非交织映射时固定取6。interleaverSize交织器大小取值2、3、6。shiftIndex交织偏移量用于打散不同小区的PDCCH干扰。配置一个CORESET本质上是把这几个参数组合起来决定PDCCH在哪个频段、占几个符号、以及CCE怎么分布。实际配置时frequencyDomainResources的位图往往是最容易出错的点。比如带宽100MHz、子载波间隔30kHz时总共有273个PRB位图48bit每bit管6个PRB总共只能覆盖288个PRB的位置。如果想把CORESET放在第100到第150个PRB就需要把位图中对应的bit置1但很多配置工具会把bit偏移算错导致CORESET落到了完全不同的频段上。3.2 REG到CCE的映射逻辑交织与非交织CCE到REG的映射是PDCCH资源分配的核心。非交织映射时一个CCE的6个REG在频域上连续排列交织映射时REG会按一定规则打散到整个CORESET内。为什么需要两种映射方式非交织的好处是资源集中一个PDCCH占用的REG集中在连续的PRB上实现简单时延低适合信道质量好的用户和URLLC场景交织的好处是把REG打散到整个CORESET一个PDCCH的REG分散在不同频段可以获取频率分集增益抗频选衰落能力强适合边缘用户和公共信令。参数选择上协议规定非交织映射的reg-BundleSize只能取6意味着一个REG bundle就是6个REG恰好对应一个CCE。交织映射的reg-BundleSize可为2或6。取2时打散程度更高取6实现相对简单。interleaverSize决定了交织器的列数和CORESET里REG bundle的总数有关REG bundle总数为interleaverSize的整数倍时交织映射最干净否则会有RE级别或REG bundle级别的填充。从实现角度看UE做去交织映射时需要先根据CORESET的时域符号数、频域PRB数、交织器参数按协议公式计算出每个REG bundle的编号再确定每个CCE对应的REG位置。这个计算在DSP或FPGA上有一套固定流程但不同厂商的实现细节差异很大跨厂商联调时经常因为交织参数理解不一致而对不上。3.3 CORESET 0初始接入的关键配置CORESET 0是TYPE0-PDCCH公共搜索空间对应的控制资源集是UE在初始接入阶段唯一能用的CORESET。它的配置不通过RRC下发而是从MIB里的pdcch-ConfigSIB1字段获取。pdcch-ConfigSIB1一共8bit前4bit用于配置CORESET 0后4bit用于配置Search Space 0。为什么CORESET 0要用MIB携带而不是靠RRC因为在UE读SIB1之前RRC连接还没有建立UE需要一个固定的、不依赖高层信令的资源来接收SIB1的调度信息。MIB在这个阶段是UE唯一能解出来的高层信令所以CORESET 0和Search Space 0的配置必须由MIB直接携带。UE根据这4bit索引去查协议表得到CORESET 0的频域位置、符号数、REG bundle大小等参数。这套表格在TS 38.213里定义不同频段、不同子载波间隔对应不同的配置组合。实际排障中如果UE一直读不到SIB1第一步要检查SSB和CORESET 0的频域位置是否一致。协议里CORESET 0主要落在SSB所在的频段内或紧邻SSB的位置具体由表项决定。如果小区配置了多个SSB位置或使用了C-Band的某些子载波间隔CORESET 0的默认位置容易和SSB不匹配导致UE在初始接入阶段直接失败表现为终端驻留不上、随机接入前导发了一次又一次但收不到RAR。4. Search Space与PDCCH盲检机制4.1 公共搜索空间与UE专用搜索空间的职责划分Search Space搜索空间定义了PDCCH候选集的时域位置、聚合等级分布和监听周期。NR把搜索空间分成公共搜索空间Common Search SpaceCSS和UE专用搜索空间UE-specific Search SpaceUSS两大类。公共搜索空间承载的是多用户共享的控制信息比如SIB1调度、随机接入响应RAR、寻呼、时隙格式指示等。UE在里面用SI-RNTI、RA-RNTI、P-RNTI、TC-RNTI等公共RNTI去盲检。公共搜索空间的配置是小区级的所有UE都能监听。UE专用搜索空间则用于承载针对该UE的上下行调度用C-RNTI、CS-RNTI、MCS-C-RNTI等UE级RNTI盲检配置是UE级的每个UE可以有不同的搜索空间。TYPE0-PDCCH CSS用于调度SIB1TYPE0A-PDCCH CSS用于调度SIB2及后续SIBTYPE1-PDCCH CSS用于随机接入响应TYPE2-PDCCH CSS用于寻呼TYPE3-PDCCH CSS和USS用于调度常规业务数据。这里有个容易混淆的点USS和TYPE3 CSS在时域上可以重叠UE需要同时盲检两种搜索空间里的候选集总盲检次数要在协议规定的预算内。4.2 聚合等级、候选集与盲检预算每个搜索空间对应一组聚合等级和候选集数量。协议规定一个PDCCH候选集可以配置的聚合等级包括AL1、AL2、AL4、AL8、AL16每个聚合等级下的候选集个数在SearchSpace的nrofCandidates里配置。典型配置如下聚合等级每聚合等级候选集数量AL10或6AL20或6AL40或4AL80或2AL160或1候选集数量乘以聚合等级决定了这个搜索空间在每个监听机会上占用的CCE总数。比如AL1有6个候选、AL2有6个候选、AL4有4个候选、AL8有2个候选时总CCE占用为6×16×24×42×850个CCE。如果CORESET在时域上只有1个符号频域上配置了48个PRB可用的CCE总数是48×1÷68个CCE一个符号上一个CCE占用6个PRB那显然放不下50个CCE。所以CORESET的频域大小和搜索空间的候选集配置必须匹配否则盲检时很多候选集会落到CORESET之外UE解不到DCI。盲检预算方面协议规定UE在每个时隙、每个服务小区上最多做44次PDCCH盲检。这里的一次指在某个候选位置上对某一种DCI尺寸做一次译码尝试。如果搜索空间里同时配置了CSS和USS每种搜索空间又有多个聚合等级候选44次预算很容易被耗尽。配置超过预算时UE会按照协议规则跳过一部分USS监听这就是为什么业务体验变差时先查搜索空间配置是否过载是一个有效的排障方向。4.3 Search Space配置实操一个完整的SearchSpace配置是这样的以RRC参数为例SearchSpace :: SEQUENCE { searchSpaceId SearchSpaceId, controlResourceSetId ControlResourceSetId OPTIONAL, monitoringSlotPeriodicityAndOffset CHOICE { sl1 NULL, sl2 INTEGER (0..1), sl4 INTEGER (0..3), sl8 INTEGER (0..7), sl10 INTEGER (0..9), sl16 INTEGER (0..15), sl20 INTEGER (0..19), sl40 INTEGER (0..39), sl80 INTEGER (0..79), sl160 INTEGER (0..159), sl320 INTEGER (0..319), sl640 INTEGER (0..639), sl1280 INTEGER (0..1279), sl2560 INTEGER (0..2559) }, duration INTEGER (2..2559) OPTIONAL, monitoringSymbolsWithinSlot BIT STRING (SIZE (14)) OPTIONAL, nrofCandidates SEQUENCE { aggregationLevel1 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8}, aggregationLevel2 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8}, aggregationLevel4 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8}, aggregationLevel8 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8}, aggregationLevel16 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8} }, searchSpaceType CHOICE { common SEQUENCE { dci-Format0-0-AndFormat1-0 SEQUENCE { ... } OPTIONAL, ... }, ue-Specific SEQUENCE { dci-Formats ENUMERATED {formats0-0-And-1-0, formats0-1-And-1-1} } } }实际配置时最常踩的坑是monitoringSymbolsWithinSlot的位图长度。这个字段是14bit位图对应一个时隙里14个符号普通CP下1表示在该符号上开始监听PDCCH。很多配置里直接复制了其他小区的配置位图出现了多个不连续的1但CORESET的duration是2个符号一个时隙里如果有两个监听机会且间隔很近就会导致监听机会重叠增加盲检压力。时域周期上公共搜索空间通常用sl1也就是每个时隙都监听UE专用搜索空间为了省电可以配置sl2或sl4。时延敏感业务可以配sl1URLLC还会配置跨时隙调度让PDCCH提前于PDSCH几个符号或一个时隙下发留出解调时间。5. PDCCH接收流程与UE侧实现要点5.1 从高层参数到物理信道的完整处理链UE接收PDCCH的完整流程可以从协议栈角度梳理成下面这条链RRC解析CORESET和SearchSpace配置建立PDCCH资源地图。根据搜索空间配置计算当前时隙内需要监听的所有候选PDCCH位置。对每个候选位置进行资源解映射提取CCE对应的RE。用DMRS做信道估计对数据RE做QPSK软解调得到LLR软比特。解扰、解速率匹配然后做Polar译码。对译码结果用候选RNTI做CRC校验CRC通过则DCI解出成功。这六步里第1步到第3步是UE高效接收的关键。传统LTE在固定位置盲检NR因为CORESET和交织映射的引入每次监听都要重新计算候选位置和REG分布。这个计算如果有缓存机制UE功耗可以压得很低如果每次盲检都重新算一遍基带功耗会明显上升。5.2 RNTI加扰与CRC校验PDCCH的DCI在编码前先要在CRC上叠加RNTI。具体做法是用目标RNTI去扰码CRC的校验比特然后再做Polar编码。UE译码后用同样一组候选RNTI去解CRC解出来校验通过就说明这次DCI是发给自己的。这个过程可以类比为一封信的信封上盖了不同的邮戳UE收到一堆信先看邮戳是不是自己认识的那几个不是就扔掉。5G里一个UE同时要监听C-RNTI、TC-RNTI、SI-RNTI、P-RNTI、RA-RNTI、CS-RNTI、MCS-C-RNTI等好几种RNTI每种RNTI对应不同的调度场景。排障时如果UE收不到某个特定信道比如收不到RAR除了看PDCCH资源还要确认UE在盲检时有没有把RA-RNTI纳入候选RNTI集合。RA-RNTI的值由随机接入前导传输的时频位置计算得出如果基站配置的PRACH时机和UE计算RA-RNTI的基准不一致也会出现UE一直在盲检但CRC永远解不出来的情况。5.3 一次成功的PDCCH调度闭环拿初始接入里最典型的SIB1调度来串一遍UE上电后先做小区搜索读取SSB里的PSS/SSS完成时频同步再读PBCH得到MIB。MIB里的pdcch-ConfigSIB1告诉UE CORESET 0的频域位置符号数和Search Space 0的监听时机。UE在约定时频位置去解PDCCH用SI-RNTI做CRC校验。校验通过后拿到DCI 1_0里面携带了SIB1的频域资源分配、时域资源分配、MCS等信息。UE按这个DCI的指示去解PDSCHCRC通过后就拿到了SIB1的全部内容。后续UE发起随机接入基站回复RAR同样用DCI 1_0调度RNTI是RA-RNTI。RAR里带上临时C-RNTIUE之后用TC-RNTI在CSS里监听竞争解决消息。竞争解决成功后TC-RNTI升级为C-RNTIUE开始在USS里监听DCI 0_1和1_1走正式的业务调度流程。整个过程中PDCCH的盲检策略是逐级演进的最开始只有CORESET 0和Search Space 0UE只做极少量盲检拿到SIB1后知道更多CORESET和Search Space盲检范围扩大进入RRC_CONNECTED后完全按RRC配置的搜索空间监听。所以配置PDCCH时要特别关注初始接入阶段的可靠性——如果CORESET 0配置不佳后续一切免谈。6. 常见问题与排障实录6.1 UE收不到PDCCH先按这个顺序排查实际排障中UE收不到PDCCH的原因集中在以下几类。我按出现频率从高到低列一下排查顺序先确认CORESET和SearchSpace有没有关联好。很多配置里SearchSpace的controlResourceSetId指向了一个不存在的CORESETUE直接放弃这个搜索空间。这种问题在手工配置RRC参数时尤其常见。再查frequencyDomainResources位图。确认CORESET的频域范围确实覆盖了期望的PRB。外场测试时常见配置是CORESET的48bit位图只配了低16bit为1结果CORESET只占64个PRB但搜索空间候选集计算的CCE范围超越了实际频域范围。查监听时机。monitoringSymbolsWithinSlot如果配置的符号位置和SSB冲突或者在一个时隙内监听次数过多会导致部分盲检被跳过。查DCI尺寸冲突。两个RNTI映射到同一尺寸的DCI且格式不同时UE可能解错格式。这种问题在日志里表现为PDCCH CRC连续失败但信号质量很好。6.2 DCI尺寸模糊问题的实际案例我之前在一个项目里遇到这样的情况UE驻留正常但业务速率极低基站侧统计PDCCH BLER在20%以上。无线环境没问题RSRP和SINR都很好BLER却居高不下。抓日志分析后定位到UE的搜索空间里同时监听了1_0和1_1两种DCI格式。配置检查发现1_0经过补零对齐后的尺寸和1_1的尺寸恰好相同。UE盲检时在某个候选位置解出了一个DCICRC用C-RNTI解掩码通过但UE按1_0解析实际基站发的是1_1。字段全部错位频域资源指示、MCS、HARQ信息全部取错PDSCH解出来CRC失败重传率飙升。解决办法是通过RRC参数调整在1_0或1_1里补一个比特让两种格式尺寸错开。具体做法可以给1_0配置一个PDSCH的聚合因子或者在1_1里增加一个新字段比如配置2个载波指示位人为增加1bit打破尺寸相等。但要注意改字段不能影响正常调度补的bit要在接收端解析时忽略或者作为固定填充。6.3 PDCCH BLER过高时的定位思路PDCCH BLER高可能是物理层问题也可能是配置问题。先从物理层看SINR差、多径时延扩展大、DMRS信道估计不准都会导致Polar译码失败。这类问题可以通过提高聚合等级改善比如把AL4的候选换成AL8覆盖增益大约等效于3dB。再从配置层面看CORESET配置过窄PDCCH集中在某个频段遇到强干扰时就整个失效。可以考虑把CORESET扩展到更宽的频域范围并打开交织映射让PDCCH的REG分布在更宽的频带上获得频率分集。注意交织映射的reg-BundleSize配置为2时频率分集更好但去交织计算复杂度更高。还有一个经常被忽略的点PDCCH的功率分配。NR里PDCCH的发射功率由PDSCH的功率参数和CORESET内REG的数量决定REG越少平均到每个RE的功率越高。如果CORESET配得过大PDCCH的功率谱密度会被摊薄边缘用户解调性能下降。所以大带宽场景下与其把CORESET配得非常宽不如配一个适中的宽度加高聚合等级功率集中和频率分集都能兼顾。6.4 5G全网排障里PDCCH日志怎么看现网里做全网级别排障时光看KPI不够必须配合日志。基站侧可以看PDCCH调度的发射功率、聚合等级分布、BLER统计。UE侧可以用协议分析工具抓L2日志看PDCCH盲检命中的聚合等级、DCI格式、RNTI类型、解调所用的相关系数。具体操作上我习惯这样看先看UE在多少候选位置做了盲检实际命中几次命中率过低说明候选集配置和信道环境不匹配。再看命中的Polar译码迭代次数分布如果大量DCI要用到最大迭代次数才译码成功说明链路余量不足。最后看同一时隙内多个搜索空间的盲检次数占比排查有没有搜索空间配置冗余地占用盲检预算尤其要关注有没有两个不同RNTI在一个时隙里都要监听大量候选的场景。跨厂商对接时这个日志尤其有价值。我遇到过基站按SIB1里的CORESET 0配置发射PDCCH但UE按另一套表解析两边对不上始终解不出SIB1。抓日志后从UE侧解析出的CORESET 0的频域位置和频点直接跟基站配置对比差异一目了然。6.5 车联网与低时延场景下的PDCCH优化心得最后聊一下车联网这类对调度时延敏感的场景。V2X业务对时延要求极低PDCCH的监听周期和调度模式要专门设计。实际项目中我做过这样几项优化把USS的监听周期配置为sl1保证每个时隙都能被调度把PDCCH放在时隙前部的符号给PDSCH和HARQ反馈留出更多处理时间不用跨时隙调度用同一时隙内调度降低整体时延。同时要注意时延和可靠性的平衡。靠前的符号如果出现干扰PDCCH失败后整个时隙都浪费了。因此低时延场景的PDCCH建议配AL4和AL8混合的候选集在时延和覆盖之间取折中。URLLC场景下还可以打开2_1抢占指示让低优先级业务让出资源给高优先级控制信令。这套思路在5G公用网络的切片方案里也能复用属于典型的配置调优经验。PDCCH是整个NR调度链路的前置关卡CORESET、Search Space、DCI格式、RNTI加扰这些环节任何一个节点的配置失配都会直接表现为用户面异常。我个人的经验是遇到调度类问题永远先从PDCCH盲检成功率和DCI解码情况查起与其在那里猜PDSCH的解调参数不如先把控制信道这条链路走通。日志里一个PDCCH CRC pass胜过一堆其他参数的推测。最后分享一个我自己的排障习惯每次配置完PDCCH相关参数我都会在UE侧抓一份PDCCH解调日志确认该时隙里UE实际监听的候选位置、RNTI列表、DCI格式和配置预期一致。这一步只要做了大概能砍掉一半以上的物理层疑难杂症。PDCCH链路这东西配置完不算完测过了才算数。