前几天有人把一段路测日志甩给我说某个小区里终端反复上报PDCCH解码失败可SSB的RSRP明明有-85dBmPDSCH也一切正常唯独控制信道这条线一直飘红。这种场景在5G NR的现场排障里出现得相当频繁因为PDCCHPhysical Downlink Control Channel以及它承载的DCIDownlink Control Information就是整条空口链路的总调度台——调度台一哑业务立刻停摆和信号强弱没有半点关系。很多人把注意力全放在PDSCH的MCS、BLER上却忽略了所有下行数据、所有上行授权、甚至时隙格式和功率控制指令都是从PDCCH上那几条规定动作里发出来的。这篇内容我打算把5G NR里PDCCH和DCI这条线从头到尾捋一遍先讲清楚DCI到底装了什么、PDCCH在时频资源上是怎么落点的再把DCI格式体系、盲检机制、size对齐这些容易被跳过的细节摊开讲最后落到现场排障和参数配置的取舍上。适合已经了解NR基本帧结构、想看调度细节的优化工程师和协议栈开发人员也适合刚接手基站侧配置、想弄明白这些参数到底影响什么的运维同学。文中涉及的算例我都在纸面上走了一遍数字可以直接照着复现。1. 一条DCI从生成到被解出PDCCH到底在管什么1.1 PDCCH是搬运工DCI才是那张工单很多资料把这两个概念混着讲其实分工很清楚PDCCH是物理信道负责把比特送到空口上DCI是信息本体是基站写给某个终端或某一组终端的一纸指令。打个比方PDCCH像小区楼下的快递柜DCI是柜格里那张取件码纸条真正的包裹用户数据在PDSCH里或者需要终端自己往PUSCH上送的寄件任务也写在纸条上。终端开机后做的第一件事不是解数据而是在约定好的若干个柜格里挨个试看看哪一格里有写给自己的纸条。这就解释了为什么PDCCH一挂业务会瞬间全断而不是变慢。数据信道即使信道质量差也能靠降阶重传硬扛一段时间控制信道如果解不出来终端连这一时隙有没有我的数据、在哪个PRB、用什么码率都不知道接收机根本不知道该往哪个方向使劲。NR的控制信道是单端口、无HARQ重传、也没有反馈的发错了就是发错了只能靠基站侧调整聚合等级再试一次。1.2 DCI里到底装了哪些零件一条典型的下行分配DCI比如DCI 1_1里最少要装这么几类信息频域资源分配告诉终端数据占了哪些PRB、时域资源分配起始符号和持续长度以及DCI到PDSCH之间的时隙偏移k0、调制编码方案5bit对应MCS表里的某一阶、HARQ进程号和NDI/RV重传合并靠这几个字段、天线端口与DMRS相关指示、传输配置指示TCI决定这一波用哪个波束、以及回传HARQ-ACK用的PUCCH资源指示和k1偏移。上行授权DCI0_0/0_1的构成思路类似只是把接收换成发送频域位置、跳频指示、MCS、DMRS、功率控制命令、SRS请求、以及DCI到PUSCH的时隙偏移k2。把这些字段摆在一起看就会发现一条DCI本质上是这次传输的一整套配方终端拿到它就能独立完成一次收发不需要基站再额外通知任何东西这也是NR自包含时隙设计的核心支撑。1.3 k0、k1、k2三个偏移量把控制和数据串成一条链刚接触调度的人最容易忽略这三个参数但它们决定了整条时序能不能对上。k0是DCI所在时隙到PDSCH所在时隙的偏移k1是PDSCH结束到终端发HARQ-ACK的时隙偏移k2是DCI到PUSCH的时隙偏移。基站通过DCI里的指示字段告诉终端该用哪一组值k1和k2通常在DCI里直接带3bit左右k0通过时域资源分配表的索引间接给出。为什么要留这些偏移因为终端需要处理时间。解出DCI、做信道估计、解调PDSCH、生成ACK这一串动作需要满足N1的处理时间约束上行方向还要算上TA提前量和N2的约束。配置得太紧终端来不及处理就会直接丢弃配置得太松调度时延又上去了对时延敏感的业务就不友好。实际工程里这几个值往往是RRC消息里一组一组下发的候选集合DCI只负责在集合里点一个这样既灵活又省比特。顺带说一句切换流程里也绕不开这条线。RRCReconfiguration里带reconfigurationWithSync的时候终端会启动T304切换期间目标小区能不能把调度指令及时送到直接决定T304会不会超时导致重建。所以看切换问题时别光盯着测量报告和邻区添加参数PDCCH的覆盖和CORESET配置同样得看一眼。2. CORESET和搜索空间PDCCH在时频资源上的落脚点2.1 从REG到CCE先把这套计量单位换算清楚PDCCH不占用整个符号的全部带宽而是被限制在若干个CORESET里。一个CORESET有两个维度频域以6个RB为一个粒度配置里是45bit的位图对应BWP内最多270个RB时域占1到3个OFDM符号。资源的最小单位是REG定义很简单——频域1个RB、时域1个符号里面固定有3个RE被DMRS占用也就是说一个REG实际能承载数据的是9个RE。再往上就是CCE一个CCE固定等于6个REG。PDCCH的聚合等级AL指的就是这条PDCCH用掉几个CCE可以是1、2、4、8、16。这个换算关系决定了CORESET能塞下多少条控制信令算一遍就很直观假设配了一个24RB、2符号的CORESETREG总数是24×248折合CCE就是48/68个。这8个CCE可以拆成8条AL1的PDCCH也可以合并成1条AL8的PDCCH或者1条AL4加2条AL2怎么分取决于调度器当下想给谁多高的可靠性。参数取值说明CORESET频域粒度6 RB通过45bit位图配置CORESET时域长度1至3个符号越长容量越大但占用数据区REG构成1 RB × 1 符号内含3个DMRS REREG bundle大小2、3或6影响信道估计的插值范围CCE构成6个REG固定关系聚合等级1、2、4、8、16个CCE由基站根据链路质量选择REG bundle这个参数值得单独说一句。终端做PDCCH解调时要先做信道估计估计得越准解调门限越低。但相邻REG上的信道响应不一定相同尤其是用了波束赋形或者频选调度的时候。REG bundle把若干个相邻REG绑成一组约定这一组内用同一个预编码终端就能在这一组内做联合信道估计再用估计结果去解整条PDCCH。bundle越大信道估计越准代价是资源分配的颗粒度变粗调度灵活性下降。2.2 交织映射和非交织映射选错了覆盖会吃亏CCE到REG的映射分两种。交织映射会把构成同一个CCE的REG打散散布到整个CORESET的频域上好处是抗频率选择性衰落——某一段频域深衰落也不会把整条PDCCH全埋掉坏处是终端做信道估计时要跨越大段带宽反而更难估准而且在波束赋形场景下每个REG的等效信道差异更大。非交织映射则把REG连续地拼在一起适合配合波束赋形和频选调度使用信道估计简单、增益高但一旦这段频域被干扰打掉整条PDCCH就废了。工程上比较常见的做法是覆盖受限、需要高聚合等级的场景比如小区边缘、高频段用交织映射把可靠性摊开容量优先、用户信道条件好的场景用非交织配上2或6的REG bundle让信道估计更精确。还有个容易忽略的细节——precoderGranularity这个参数决定了预编码是按REG bundle粒度还是按整个CORESET统一配成sameAsREG-bundle时bundle大小就必须和实际波束赋形的粒度匹配否则终端估计出来的信道和实际发射的对不上误码率会莫名其妙地高。2.3 CORESET#0终端开机第一个要啃的硬骨头CORESET#0是所有CORESET里最特殊的一个因为它的配置不在RRC消息里而是压在了MIB的pdcch-ConfigSIB1字段里只有8bit终端必须靠这8bit反推出CORESET的频域位置、时域符号数、以及搭载SIB1的PDCCH的监听时机。规范里为此定义了好几套表格8bit的高4位选表复用Pattern低4位给索引不同的复用图样对应的RB数和符号数都不一样。这里最容易踩的坑是频域偏移。CORESET#0的频域位置是相对于SSB来算的不同的复用图样Pattern 1/2/3对应不同的offset取值范围一旦基站侧把offset配错了——尤其是和实际发射的SSB位置对不上——终端就会在错误的位置上盲检结果就是永远解不出DCI 1_0SI-RNTI加扰的那条SIB1自然拿不到接入流程直接卡死在第一步。现场判断的方法很简单抓开机的信令流程如果终端能收到MIB、能解出SSB但迟迟不发起SIB1的接收或者反复重试基本就是这个方向的问题。3. DCI格式全景不同格式到底解决什么问题3.1 回退格式0_0/1_0和常态格式0_1/1_1的职责边界NR的DCI格式命名规则是先分上下行0系列管上行授权1系列管下行分配再分回退和常态。回退格式0_0和1_0的字段数量固定、位宽小、不依赖太多RRC先验配置专门用于几个关键场景SIB1的调度SI-RNTI、随机接入响应RA-RNTI、寻呼P-RNTI、竞争解决消息msg4TC-RNTI以及RRC重配置过程中那些兜底的调度。1_1和0_1则是常态格式字段多、可配置性强支持BWP切换、多天线端口指示、TCI状态、CBG级重传、SRS请求等一大堆高级功能。基站通常在UE进入连接态、RRC配置齐全之后切到常态格式做日常调度。这个设计的意图很明确在配置还没建立、或者需要极致可靠的时候用一套双方都闭着眼睛也能对上的格式把流程推下去。有个必须记住的规则在同一个搜索空间里DCI 0_0和DCI 1_0的大小必须完全一致通过补零对齐。为什么因为终端盲检时是先按长度去猜的如果两个格式长度不同盲检次数就会翻倍终端复杂度受不了。这个对齐规则也是后面要讲的size对齐问题的源头。3.2 2_x系列不调度数据但管着整个时隙的规矩2_x系列格式比较特殊它们不调度任何用户数据而是给一组终端广播各种资源使用规则。DCI 2_0用于时隙格式指示SFI-RNTI加扰告诉终端接下来若干个时隙里哪些符号是下行、哪些是上行、哪些是灵活符号——这对TDD场景下的干扰控制极其关键也是动态TDD能跑起来的前提。DCI 2_1是下行抢占指示INT-RNTI当URLLC业务需要插队时基站用它告诉已经排好队的eMBB终端你刚才那部分资源被抢了别费劲译码了。DCI 2_2和2_3分别是PUSCH/PUCCH和SRS的功率控制命令TPC-PUSCH-RNTI、TPC-PUCCH-RNTI、TPC-SRS-RNTI加扰。再往后上行取消指示CI-RNTI用于让终端紧急撤销已经发出或准备发出的上行传输省电相关的唤醒信号PS-RNTI用于在DRX周期外唤醒终端。较新的版本里还引入了通过PDCCH指示来切换搜索空间组、临时跳过PDCCH监听的机制本质上是让终端在没业务的时候少看几眼控制信道把功耗降下来。这些格式的存在说明一件事PDCCH不只是调度台还是整个小区的资源秩序维护者。DCI格式典型RNTI主要用途所在搜索空间1_0SI-RNTI / RA-RNTI / P-RNTI / TC-RNTI / C-RNTI回退下行分配、SIB1、RAR、寻呼公共搜索空间为主0_0C-RNTI / TC-RNTI回退上行授权公共与UE专属1_1C-RNTI / MCS-C-RNTI / CS-RNTI常规下行分配UE专属搜索空间0_1C-RNTI / CS-RNTI常规上行授权UE专属搜索空间2_0SFI-RNTI时隙格式指示公共搜索空间2_1INT-RNTI下行抢占指示公共搜索空间2_2TPC-PUSCH-RNTI / TPC-PUCCH-RNTI上行功控命令公共搜索空间2_3TPC-SRS-RNTISRS功控命令公共搜索空间3.3 字段位宽不是固定的得看配置初学者常以为DCI的字段位宽是死的其实除了MCS5bit、NDI1bit、RV2bit、HARQ进程号通常4bit、TPC2bit这几个比较稳定之外其他字段的位宽都是配置相关的。频域资源分配的位宽取决于BWP大小和分配类型时域资源分配取决于配置了几种候选0到4bit载波指示在跨载波调度时才出现0或3bitTCI字段的存在与否取决于是否配了tci-PresentInDCI。字段典型位宽备注频域资源分配取决于BWP大小类型1时约为log2(N(N1)/2)时域资源分配0至4 bit索引到RRC配置的表MCS5 bit对应38.214的MCS表HARQ进程号4 bit影响最大并发进程数新数据指示NDI1 bit用于区分新传与重传冗余版本RV2 bit与重传合并相关TPC命令2 bit闭环功控PUCCH资源指示3 bit从16个资源里选一个PDSCH到HARQ的时序0至3 bit索引到k1候选集合这就带来一个很现实的工程问题基站侧改一个RRC配置DCI的长度可能就变了如果终端侧的解析逻辑没跟着更新就会出现解出来全是乱码的情况。做协议栈联调的时候DCI长度不匹配几乎是最常见的低级失误。3.4 拿一条FDRA走一遍数字光讲公式容易飘拿个例子算一遍就清楚了。频域资源分配类型1用的是RIVResource Indication Value编码把起始RB和连续长度合并成一个整数。公式是当长度为L、起始位置为RBstart、BWP大小为N时如果L-1不大于N/2则RIV N×(L-1) RBstart否则RIV N×(N-L1) (N-1-RBstart)。假设初始下行BWP是100个RB基站想给某个终端分配从第20个RB开始、连续30个RB的资源。这里L-129N/250满足第一种情况于是RIV 100×29 20 2920。反过来终端拿到2920怎么解先看它是否小于N(N1)/25050是的话取L-1 floor(2920/100) 29也就是L30RBstart 2920 mod 100 20。两边对上了。这个例子看着简单但实际排障时特别有用如果你在日志里看到FDRA的原始值可以按这个公式反推出终端实际占用的PRB再去和基站侧的调度记录比对就能判断是终端解析错了还是基站本来就调度成这样。省掉这一步很多时候会白折腾半天。4. 盲检终端在不知道位置的情况下怎么把DCI捞出来4.1 聚合等级、候选数和每时隙的盲检预算终端并不知道基站在哪个位置给自己发了DCI只能按约定的规则去试。这里有三层参数同时起作用聚合等级1/2/4/8/16、每个聚合等级下的候选PDCCH个数、以及搜索空间集合的监听周期。基站配置搜索空间时会给出一组聚合等级到候选数的映射比如AL1给6个、AL2给6个、AL4给2个、AL8给2个那么终端每个监听时机就要尝试662216次盲检。但终端的计算能力是有上限的规范里给了每时隙的盲检次数和CCE数预算。超出部分终端可以合法地不检这就意味着一张配置得很花哨的搜索空间表实际可能有一部分根本没被监听过。子载波间隔每时隙最大盲检次数每时隙最大CCE数15 kHz445630 kHz365660 kHz2248120 kHz2032这张表解释了为什么高频段配置PDCCH要格外小心120kHz下每时隙只有20次盲检机会稍微多配几个搜索空间集合就会触顶。做毫米波站点优化时经常看到的现象就是配置写了5个搜索空间实际只生效3个根源就在这个预算上。4.2 哈希函数与位置随机化为什么同一条DCI每时隙位置都在变如果所有终端都固定在CORESET的同一批候选位置上找自己的DCI那么对某个位置的争夺就会非常激烈——这就是阻塞。NR用哈希函数把候选位置随机化公式是Y(p,n) (Ap × Y(p,n-1)) mod D其中D取65537Ap按CORESET索引取39827、39829、39839这样的值UE专属搜索空间用RNTI做初值。因为初值不同不同终端算出来的候选位置序列就不同冲突概率大幅下降。公共搜索空间的处理不一样它的候选位置是固定的所有终端都在同样几个位置找。这没法避免因为SI-RNTI、RA-RNTI这些本来就是一组终端共用的只能靠基站侧错开不同公共消息的发送时机来缓解。实际遇到某个时隙控制信道突然全乱的问题时可以看看是不是多个公共消息挤在了一起。4.3 DCI size对齐一类看着琐碎但很致命的规则终端盲检时按DCI长度去匹配长度种类越多盲检负担越重。规范因此设了几条硬性约束第一同一个搜索空间里的0_0和1_0必须同长度靠补零实现第二一个小区内终端需要处理的DCI长度种类不能超过4种其中用C-RNTI加扰的最多3种第三如果配置后超了就按规则对特定格式补零再超就丢弃一部分搜索空间集合。这个规则我在联调里见过不止一次翻车基站侧给某个UE同时配了1_0、0_0、1_1、0_1四种格式BWP又开得比较大算下来长度种类直接超了终端按规范丢掉了部分搜索空间表现就是某些场景下调度指令收不到但换个BWP大小又正常。碰到这种配置看起来没问题、行为却很随机的故障先把DCI长度种类数算一遍往往能直接锁定。4.4 监听时机的配置决定终端什么时候睁眼搜索空间里有一组参数专门描述监听时机周期和偏移monitoringSlotPeriodicityAndOffset、持续时隙数duration、以及时隙内监听哪几个符号monitoringSymbolsWithinSlot14bit位图。终端把这些参数和SFN、时隙号一起代入公式才能确定哪些时隙、哪些符号是自己的PDCCH occasion。多波束场景下还有一层关联UE专属的PDCCH需要配置至少一个TCI状态否则终端在物理层根本不知道用什么接收波束去收。实践中经常出现的现象是RRC配置里CORESET和搜索空间都配了TCI状态也配了但激活的TCI状态和当前SSB波束对不上——终端用波束1去收本该用波束3发的PDCCH结果就是持续的CRC校验失败。这种问题看日志很难直接看出来要结合基站侧的波束调度记录一起比对。5. 现场问题排查PDCCH/DCI异常的分层定位思路5.1 第一步先分清解不出还是解出来但不对PDCCH相关的问题表现很像但根因可能完全不在一个层面上所以排查第一步永远是分类。第一类是物理层解不出来日志里能看到盲检尝试了、但CRC全失败或者干脆没有任何DCI上报。第二类是解出来了但字段解析有偏差终端确实做了调度动作只是资源位置、MCS或者时序和基站预期不一致表现为HARQ合并失败、PDSCH解调错误率高。第三类是高层的配置问题搜索空间没配、监听周期配成了0、BWP切换过程中配置还没生效。分类的方法很简单看日志里的层次。物理层日志里DCI的数量和CRC结果最直接MAC层日志能看到调度了多少TB、用了什么MCSRRC日志能看到配置是否成功下发。很多人一上来就去改功率、改下倾角其实问题在RRC配置里改天馈是白费功夫。5.2 PDCCH解不出来的常见根因清单现象可能的根因快速验证方式开机解不出SIB1的DCICORESET#0频域偏移或复用图样配错比对MIB字段与实际SSB位置接入后偶发DCI丢失聚合等级偏低、覆盖不足查看平均AL与上行功率余量换波束后PDCCH全丢TCI状态未激活或与SSB波束不一致比对波束调度记录信道质量好但误码率高DMRS加扰ID或REG bundle配置不匹配核对pdcch-DMRS-ScramblingID特定终端一直调度不上DCI长度种类超限被丢弃统计该小区的DCI长度种类数控制信道质量整体偏差CORESET频域位置落在干扰强的RB上扫频确认干扰分布挑两个展开说说。DMRS加扰ID这个参数配置里如果给了pdcch-DMRS-ScramblingID基站和终端必须用同一个值生成加扰序列用的是这个ID而不是小区ID配置不一致时终端解出来的DMRS序列和实际发射的完全不同信道估计直接跑偏CRC当然过不了。这种问题在新站开通、参数批量下发时特别容易出现因为两边用的默认值可能不一样。再比如CORESET频域位置落在干扰区的情况。PDCCH不像PDSCH有灵活的频选调度能力它的频域位置是相对固定的一组RB如果正好压在邻区的参考信号或者某些干扰源上整片小区的控制信道质量都会受影响。做全网排障时把每个小区的CORESET频域位置在地图上标出来看看有没有扎堆或者压着干扰源往往能发现批量性的问题。5.3 聚合等级长期高位说明什么基站调度器会根据PDCCH的传输结果动态调聚合等级这部分不是协议强制的各厂家实现不同但思路大同小异连续几次失败就上调AL连续稳定就下调。AL调上去可靠性提高了代价是消耗更多CCE。所以看到平均AL长期停在8或者16至少说明两件事之一要么覆盖确实差链路本身需要这么高的冗余要么CCE资源不够调度器被迫用高AL来抢资源。怎么量化统计单位时间内的CCE占用率也就是实际使用的CCE数除以CORESET能提供的CCE总数。这个值超过70%就要警惕了说明控制信道容量开始吃紧再往上走必然出现想调度但没资源的情况。解决办法有两条一是扩CORESET的时频资源加频域RB数或者加符号数二是把搜索空间的配置精简一下去掉那些实际用不上、白白占预算的候选。5.4 用日志把一条DCI逐字段还原出来这一步是真正能提升排障效率的技能。拿到一条DCI的日志先看长度判断格式再看加扰用的RNTI判断消息类型然后按格式的定义逐字段拆。以DCI 1_1为例顺序大致是载波指示、BWP指示、频域资源分配、时域资源分配、VRB到PRB映射、PRB bundling、速率匹配指示、ZP CSI-RS触发、MCS、NDI、RV、HARQ进程号、天线端口、TCI、SRS请求、TPC、PUCCH资源指示、PDSCH到HARQ的时序。拆完之后做两件事验证一是按FDRA的RIV公式反推实际PRB和基站调度记录对二是按k1和PUCCH资源指示算出终端应该在第几个时隙的哪个PUCCH资源上回ACK和实际抓到的上行信号对。两边都能对上说明链路是通的问题在上层对不上问题基本就在解析或者配置上。这套流程我走过很多遍比盲目改参数高效得多。6. 工程配置取舍CORESET和搜索空间怎么配才顺手6.1 频域宽度、符号数与调度灵活性三者之间的取舍CORESET的频域越宽能容纳的CCE越多容量越大代价是占用了本来可以给PDSCH用的资源尤其在时隙开头这几个符号上。时域长度也一样1个符号的CORESET容量小但给数据留的空间大3个符号的CORESET容量大但数据区被切掉一块。选几个符号本质上是在控制信道容量和数据信道效率之间划线。配置取向频域宽度符号数适用场景容量优先宽48至96 RB2至3用户密集、调度频繁效率优先窄12至24 RB1数据吞吐为主覆盖优先中等2边缘用户多、AL偏高我的经验是不要在开局时就按最大值配。先按中等规模起步跑一段时间看CCE占用率和平均AL再决定往哪个方向调。一次性配太宽后面发现数据吞吐上不去再回来改改配置会引起BWP和搜索空间的连锁调整麻烦得多。6.2 监听周期和终端功耗之间的平衡搜索空间的监听周期直接决定终端多久看一次控制信道。周期越短调度时延越低终端功耗越高。对时延不敏感的业务比如一些固定安装的CPE设备、物联网终端完全可以把周期配长一点让终端大部分时间处于省电状态对时延敏感的业务周期短一些但要注意别让搜索空间集合的总预算超限。这里有个容易忽略的点一个终端可以同时配多个搜索空间集合各自周期不同比如一个1时隙周期的小集合负责URLLC一个5时隙周期的大集合负责常规调度。这样做的好处是终端不必每个时隙都用最大的搜索范围去找平均功耗能降下来。配置时要注意所有集合加起来的盲检次数不能超过预算表里的上限否则超出的部分会被静默丢弃。6.3 多载波和多小区场景下的额外注意点载波聚合场景下每个小区的PDCCH是独立配置的但终端的能力是共享的——盲检预算按小区分别计算处理能力却是一套硬件在跑。做多载波配置时别按单载波的思路给每个小区都配上满配的搜索空间很容易出现某些小区实际上配了但没监听到的情况表现出来就是辅载波调度成功率明显偏低。跨载波调度是另一个坑。开启之后某个辅载波的数据可以在主载波的PDCCH上调度DCI里会出现载波指示字段。这个配置能省下辅载波的控制信道开销但也意味着主载波的PDCCH容量压力更大而且主载波一旦覆盖变差连带的辅载波调度也会受影响。做小区合并或者载波聚合方案时这一层的依赖关系要提前想清楚。6.4 一套可以照着起步的配置思路我给一套起步配置的思路具体数值需要按现场情况调。主CORESET配在时隙前2个符号频域给24到48个RB映射方式选交织REG bundle取6这样在覆盖和容量之间比较均衡另配一个小的CORESET放在靠后的符号上专门给低时延业务用。搜索空间方面UE专属集合的监听周期先配1个时隙候选数按AL1给4个、AL2给4个、AL4给2个、AL8给2个起步总盲检次数控制在12次左右留出余量给后续新增的集合公共搜索空间按规范要求的固定配置走不要额外改动。配完之后要做的验证动作有三个一是统计一周内的CCE占用率看看有没有逼近70%二是统计平均聚合等级的分布如果AL8以上的占比超过三成说明覆盖或者容量有问题三是抽查若干条DCI的解析日志确认字段和基站调度记录能对上。这三项都正常这套配置就可以稳定用下去了。调这套东西踩过的坑不算少最想提醒的是别把PDCCH当成配好就不管的部分。它的参数和业务量、用户分布、干扰环境都强相关开局时合适的配置半年后用户翻倍了可能就不够用了。我个人的习惯是每个季度回看一次CCE占用率和平均聚合等级这两个指标一旦出现趋势性变化就说明该动配置了等到用户投诉上来再改往往已经晚了。