5G接入时延飙到700ms？PDCCH资源饥饿的定位与排除

简介一份5G接入时延高解决优化案例面向网络优化工程师、5G运维人员及通信专业学生针对5G接入时延严重超标的问题提供完整排障思路与解决方案。资源包内为1个docx文档大小约300KB内容按问题描述、分析过程、解决措施、经验总结四部分组织。案例以某基站5G接入时延高达700ms为切入点通过信令跟踪定位到RRC建立阶段时延进而分析出PDCCH_RATEMATCH功能开启后导致PDCCH可用CCE资源不足限制多用户同时接入的原理并给出关闭该开关将时延降至87ms的优化措施。文档还总结了适用于用户较少站点的优化经验可帮助读者理解5G信令流程与资源调度机制。目前已有310人学习下载适合需要掌握接入时延优化方法的一线网络优化工程师参考。1. 接入时延超标到 700ms一次 PDCCH 资源饥饿的定位与排除做 5G 网络优化的人都有个直觉如果用户在站点近点测速下行速率稳定、CQI 也正常但PING 的 RRC 建立时延却动不动就跳到几百毫秒那大概率不是空口质量问题而是调度侧出了岔子。这份案例文档处理的正是这类问题——实测地点在西安某机房站点NR 接入时延高达 700ms而省内部署的 5GC 验收线是 120ms足足差了快六倍。问题不在覆盖、不在干扰根源在一个平时不怎么被留意的开关PDCCH_RATEMATCH。它本意是让 PDSCH 借走 PDCCH 占用的 RB 来提升下行速率却在特定 CCE 资源池配置下把接入通道给挤死了。全文适合刚接触 5G 参数优化的同行也适合被类似“近点好、时延差”问题卡过的后台工程师参考文末会给出可直接落地的排查思路和脚本命令。2. 拆解接入时延的构成为什么 RRC 建立会卡在 700ms2.1 时延口径与验收标准先搞懂测的是哪一段集团对接入时延的定义很明确空闲态 UE 对 FTP 服务器发起 PING从终端发出第一条 RACH preamble 开始到终端发出 RRC Connection Reconfiguration Complete 为止这段时间差作为接入时延。注意这里强调是“空闲态”意味着整个流程包含随机接入、RRC 建立、附着/注册更新和业务建立等一串信令交互。在实际单验中不同 5GC 部署方式对应的验收线不同5GC 为本省部署时按 120ms 验收5GC 控制面为大区制非本省部署时按 280ms 验收。原因是跨大区信令绕转会增加时延。案例中西安站点属于本省部署场景所以要盯 120ms 这条线。实测 700ms说明光 RRC 建立这一段就有大量等待时延不是单纯传输问题。跟踪信令时我一般会先把 RRCSetupRequest、RRCSetup、RRCSetupComplete 这几个关键消息打上时间戳这样可以快速定位时延花在哪一段。如果是 RRCSetupRequest 到 RRCSetup 之间卡顿问题大概率在基站侧调度如果是 RRCSetupComplete 之后卡那就要往核心网方向追。本案例是在 RRC 建立阶段就出现明显等待所以排查重点自然放到基站调度资源上。2.2 PDCCH 与 CCE 的对应关系RBNUM2 为什么只有 2 个下行 CCE分析 CELLTD537 跟踪发现大量公共信道 REG 资源调度不出来怀疑 PDCCH 资源分配受限。配置核查后发现该站点开了 PDCCH_RATEMATCH对应 RBNUM 参数设为 2单位是 12RB也就是让 PDSCH 借用 PDCCH 所在符号的 2 个 RBG 资源。这里有个关键换算链RBNUM2 对应 4 个 CCE 资源上下行各占 50%所以下行只有 2 个 CCE。当前调度版本中PDCCH 调度的最小 CCE 单位就是 2 个。这意味着 2 个下行 CCE 只能满足一个用户接入——如果一个用户已经占用了这 2 个 CCE后续用户必须等前一用户释放后才能接入。从机制上理解PDCCH RATE MATCH 是一种资源借用机制PDSCH 可以使用原本预留给 PDCCH 的符号位置下行速率提升比较可观。但代价是 PDCCH 可用资源变少公共搜索空间和专用搜索空间的调度余量都被压缩。问题在于如果站点用户数不多、下行 PRB 利用率不高这个功能带来的速率收益其实有限却把接入通道的 CCE 资源池掏空了。在实际操作里RBNUM 这个参数很重要它的取值直接决定了 PDCCH 资源被压缩到什么程度。类似场景下如果站点配置了更大的 RBNUM例如 6对应 12 个 CCE下行 6 个那么可以同时容纳 3 个用户出现时延问题的概率会低很多。但本案例站点是 RBNUM2极度紧缺。2.3 资源竞争导致接入流程串行化当站点已有用户占用了仅有的 2 个下行 CCE新用户发起 RRC 建立流程时基站无法及时下发调度指令。UE 侧表现就是等待 RRCSetup 的时间特别长甚至需要重发 RRCSetupRequest。跟踪信令里看到的就是 RRC 建立时延在 700ms 左右远超验收标准。这种现象在近点、远点都可能出现因为近点用户通常 CQI 高PDSCH 速率高PDSCH 占用率高PDCCH 被借走资源后被占用的概率也更大。反而是远点用户速率低CCE 占用不激烈。所以单验时常出现近点速率达标但时延不达标的诡异现象容易误导优化方向。节点资源竞争的另一个表现是关键信令消息的调度优先级不足。RRC 建立过程中Msg3 和 RRCSetupComplete 都需要 PDCCH 调度如果下行 CCE 长期被某个用户的上下行调度占据接入信令就会被排在队尾。此时看到的现象是整个小区“只能一个人玩”第二个用户一接入就卡。注意这里说的 CCE 指的是控制信道单元不是 PDCCH 符号数本身。同样是 2 个符号的 PDCCHRBNUM 配置不同可用 CCE 池的大小完全不同。3. 参数整改实操关闭 PDCCH_RATEMATCH 开关的完整过程3.1 关闭开关的指令与网管执行路径案例中给出的解决方案非常直接——关闭 PDCCH_RATEMATCH_SW 开关具体指令如下MOD NRDUCELLPDSCH: NrDuCellId1, RateMatchSwitchPDCCH_RATEMATCH_SW-0;参数说明NrDuCellIdNR 小区在 DU 内的编号该值与基站规划数据相关执行前需要先通过 LST NRDUCELL 确认目标小区 ID避免改错小区。RateMatchSwitch速率匹配开关当前只下发了 PDCCH_RATEMATCH_SW 一个子开关并将其置为 0关闭。这是华为网管的 MML 命令语法。实际操作时我一般先执行LST NRDUCELLPDSCH查看当前 RateMatchSwitch 状态和 RBNUM 配置确认后再执行修改避免直接改出问题。如果现场是其他厂商设备场景类似只是命令字与参数名不同。关闭开关后PDSCH 不再借用 PDCCH 所在符号的 RB 资源PDCCH 的 CCE 资源池恢复到完整状态下行公共控制信道的调度余量回归正常。这个改动不涉及发射功率、不涉及天线权值对覆盖和速率的影响需要另行评估但对接入时延的改善是立竿见影的。3.2 优化前后的信令验证对比关闭开关后重新跟踪西安防陵_12347998 张卜机房 B0103_NBMT 站点信令RRC 建立时延从 700ms 降到 87ms。这个结果直接反映在接入时延指标上结合案例给出的表格优化效果如下对比项优化前优化后接入时延700ms87ms达标情况不达标120ms达标120ms87ms 的结果在 120ms 验收线以内说明关闭开关后原来被 PDCCH 资源饥饿阻塞的接入流程恢复了正常。从这个数据也能看出时延超标的主因就是 CCE 资源不够不是无线环境问题。验证环节我一般会至少持续跟踪 3 轮完整 PING 业务观察每次的接入时延是否稳定。如果第一轮正常第二轮又出现高时延那说明还有其他用户抢占资源的问题需要进一步分析是否小区存在持续的大流量业务。本案例中从 700ms 降到 87ms说明资源饥饿问题比较集中不是偶发性的。3.3 完整的核查清单与操作步骤针对同类“接入时延高”的问题我建议按以下顺序核查避免漏掉隐藏原因确认识别验收标准确认 5GC 部署模式是本省部署还是大区制避免用错标准导致误判。核查 PDCCH_RATEMATCH 开关状态和 RBNUM 配置如果开关打开且 RBNUM 较小这是头号嫌疑。跟踪信令定位时延耗在哪个流程重点关注 RRCSetupRequest 到 RRCSetup 的时间间隔以及是否出现 Msg3 重发。观察公共信道 REG 资源调度情况如果大量调度不出说明 CCE 资源池不够优先检查 RATE MATCH 配置。执行开关关闭操作并再次跟踪信令验证修改后至少要测 3 次以上取平均值评估。这套步骤在这里工作的核心逻辑是先看资源池是否被压缩再看调度是否阻塞最后看参数调整后是否恢复正常。相比直接调整功率或波束参数这种方式更精准不会引入额外覆盖问题。4. 当 PDCCH_RATEMATCH 关闭后对速率和容量的影响评估4.1 关闭开关会不会明显拖低下行速率PDCCH_RATEMATCH 功能的本意是让 PDSCH 使用原本被 PDCCH 占用的 RB从而提升下行速率。从机制上看关闭开关后PDSCH 可用的最大 RB 数会减少理论峰值速率确实会有损失。但具体损失多少取决于 PDCCH 符号的配置情况、小区带宽和业务需求。以常见的 100MHz 带宽273 个 RB、4 个 PDCCH 符号为例如果其中 2 个符号被 PDSCH 借用那部分带宽从大约 20% 变成 PDSCH 可用的资源。关闭开关后这部分资源不再参与 PDSCH 调度速率理论上会下降。对于高速率单用户场景确有可能感觉到差异。但在实际优化中如果用户数少、PRB 利用率不高关闭开关带来的速率损失相当有限。本案例中的站点是典型的覆盖补盲站点用户量不大把 PDCCH 资源省下来提升速率的意义不大反而阻塞了接入流程。这种情况下关闭开关是划算的取舍。另外要注意PDCCH_RATEMATCH 并不是提升速率的唯一手段还可以通过调整 PDCCH 符号数、聚合级别、PDCCH 功率等参数来优化。关闭开关后如果发现速率明显下降可以从这些维度重新平衡。4.2 什么配置下不建议关闭 PDCCH_RATEMATCH凡是做优化都要讲适用边界。关闭 PDCCH_RATEMATCH 并不适合所有场景以下几个情况我会谨慎处理高容量热点区域如果小区用户数多、PRB 利用率高PDCCH 的调度本身就很紧张这时如果再关闭 RATE MATCHPDCCH 可用资源增加但 PDSCH 资源变少可能出现容量瓶颈。大包业务占比高的小区比如高清视频、FTP 下载等业务为主下行速率对用户体验非常关键关闭后速率下降影响感知。PDCCH 符号数本身已经很少的站点如果 PDCCH 只有 1~2 个符号CCE 池本来就小RATE MATCH 的借用效应相对有限关闭后收益不明显。在这些场景下更好的做法是保持 RATE MATCH 打开但调大 RBNUM例如把 RBNUM 从 2 改为 4 或 6保证下行 CCE 资源池有足够余量。不过 RBNUM 调大后PDSCH 可借用的资源减少速率又会降低所以这个参数需要结合实际速率需求来权衡。4.3 与运营商版本相关的 CCE 调度策略差异CCE 最小调度单位是最影响这个问题的关键因素。不同厂商、不同版本在实际调度时对 CCE 聚合级别的选择策略不同。有的版本支持聚合级别为 1 的调度也就是一个 CCE 就能完成一个用户的调度这样 RBNUM2 时下行 2 个 CCE 可以同时支持 2 个用户接入问题就不会那么严重。本案例中明确提到了当前版本“调度需要的 CCE 的最小单位就是 2 个”这是分析的核心前提。如果现场版本升级后调度策略发生了变化最小 CCE 单位变成 1那么同样的 RBNUM2 配置下能支持的并发用户数就会翻倍出现时延问题的概率大幅降低。所以排查这个问题时不要只看参数本身还要确认版本的调度策略。通常可以通过跟踪特定时间的下行 CCE 占用情况来判断例如观察一个 TTI 内是否只有一个用户的 DCI 被调度出来如果始终只有一个说明 CCE 资源确实被限制住了。参数或条件对时延的影响对速率的影响对容量的影响RATE MATCH 开启, RBNUM2最差2 个下行 CCE只够一个用户最好PDSCH 可借用 2 个 RBG最差并发用户数少RATE MATCH 开启, RBNUM6中等6 个下行 CCE可支持 3 个用户较好中等RATE MATCH 关闭最好CCE 池完整无额外增益最好5. 避坑指南执行接入时延优化时的常见问题与排查5.1 改了开关后时延没变问题出在哪现象是关闭 PDCCH_RATEMATCH 后重新测试接入时延仍保持在几百毫秒没有改善。原因有几种可能一是目标小区并不存在 CCE 资源饥饿问题在其他环节比如核心网侧的路由绕转或者终端问题二是修改开关后未生效参数下发失败了或需要重启小区才能生效三是测试时选择的终端位置和之前不同无线环境本身的时延差异影响了结果。解决方法是先重新跟踪信令看 RRCSetupRequest 到 RRCSetup 之间是否还有长时间空白。如果没有空白说明基站调度已经正常时延耗在核心网如果仍有空白就要确认参数是否已回读成功必要时重启该小区或联系研发确认版本行为。我一般会先执行LST NRDUCELLPDSCH确认 RateMatchSwitch 确实已经是关闭状态再进行下一步定位。5.2 明明是近点接入时延却比远点还高现象是近点无线环境好RSRP 和 SINR 都很好但接入时延反而比远点差用户感知明显恶劣。原因是在近点用户上报的 CQI 高下行调制编码方式高PDSCH 的调度资源需求也大。如果 PDCCH_RATEMATCH 开启且 RBNUM 小近点高调度量的用户很快占满 CCE 资源导致后续接入用户排队。远点用户速率低PDSCH 占用资源少PDCCH 调度反而不那么紧张。解决方法是不要被“近点正常的惯性思维”带偏。遇到近点时延高的场景优先核查 PDCCH 资源池的余量不要一上来就查核心网或传输。这个案例中的站点正是近点测试暴露的问题如果只按覆盖思路排查很难定位到 RATE MATCH 参数。5.3 只改了时延忽视了速率劣化带来的新投诉现象是关闭 RATE MATCH 后时延达标了但用户反馈下载速率变差出现新投诉。原因是关闭开关限制了 PDSCH 可用的 RB 数对高占用率的站点来说速率损失可能达到 5%~10%这时用户感知就会明显变差。尤其是原来本就不卡的小区关闭后速率下降容易被注意到。解决方法是在关闭开关前后各测一轮下行速率用数据说话。如果速率下降超过 8%就要重新考虑是否调整 RBNUM 而不是直接关掉开关。如果必须关闭可以同时评估 PDCCH 符号数能否增加补回控制信道容量。5.4 测试中偶发高时延普遍时延正常容易被忽略现象是后台指标统计的接入时延平均值正常但个别终端上报的接入时延偶发超标用户投诉个别位置上网卡顿。原因是偶发高时延往往和竞争相关比如某时刻恰好有用户做 FTP 下载占据下行 CCE或者发生了 Missed HARQ 重传导致调度时序拉长。这类偶发问题在统计平均数据中容易被平均掉。解决方法是把统计粒度收缩到小区级、分钟级并拉取最高时延的分位数比如看 P95 或 P99 值。另外在测试时多测几轮 PING每一轮都要记录不要只看平均值。发现偶发高时延的规律之后比如集中在某段时间或某个 TA 范围再针对性地核查调度参数。5.5 改了参数后没有回读确认后续操作被旧的配置误导现象是执行完修改后后续排查问题时在另一份配置表里看到的还是旧参数导致判断失误或者下一次改动基于错误的配置进行。原因是网管上保留的是修改前的备份或者修改后没有执行保存操作部分设备在重启后配置恢复为默认值。这个问题在新开站和版本升级后的站点中尤其常见。解决方法是每次修改参数后至少执行一次回读命令确认配置确实已刷新并且做一次配置保存。对于感知类投诉站点我更习惯把修改前、修改后的配置截个图存到工单附件里这样即使后续有人动了配置也能快速比对回溯。6. 把时延优化从“一次个案”变成“一套排查清单”两种实用打法6.1 建立“接入时延敏感参数核查表”批量筛查全网高危站点经过这个案例我的习惯是把这类问题沉淀为一套参数核查清单而不是只处理一个站。针对接入时延容易超标的高危参数我一般会重点核查以下配置参数名称核查重点建议策略PDCCH_RATEMATCH_SW开关状态用户少的站点建议关闭RBNUMRATE MATCH 借用的 RBG 数保持 PDCCH 的 CCE 资源池足够用户接入PDCCH 符号数每时隙控制符号数量过少时会导致公共信道调度不足最小调度 CCE 数版本/厂商调度策略需与 RBNUM 配置匹配用户数/利用率同时在线用户数与 PRB 利用率高利用率站点调整需额外测试速率这套清单的作用是把经验前置到日常维护中不需要等投诉来了才做分析。我是通过网络拓扑批量拉取这些配置筛出 RATE MATCH 开启且 RBNUM 小于等于 4 的站点生成一个待核查名单然后逐个跟踪信令确认是否真的存在 CCE 资源阻塞。每次核查的时间大约在 5 分钟一个站效率比故障驱动式的排查高很多。对于名单里确认存在问题的站点我会按统一策略处理用户数低于某个阈值时直接关闭开关用户数较高但时延超标时先调大 RBNUM 再观察效果。这种分批处理的方式可以避免因为盲目批量改动引起新问题。6.2 配合话务统计用“可接入用户数”验证优化效果单靠信令跟踪验证效果充分但不高效尤其是到了全网推广阶段不可能每个站都去跟踪信令。更靠谱的做法是用话务统计中的接入成功率和接入时延指标来做回归验证。常见做法是提取统计里的随机接入成功率、RRC 建立成功率、平均接入时延这几个指标至少观察一周对比参数调整前后的数据变化。如果接入成功率提升、时延均值下降说明改动有效如果时延下降但成功率没有变化说明站点原本就没有接入失败问题改进主要体现在速度上。我还会额外关注一个指标——RRC 建立请求次数和建立成功次数的差值。如果关闭 PDCCH_RATEMATCH 后建立失败次数明显减少说明原来确实因为 CCE 资源不足导致接不进。这个指标不直接反映时延但能作为资源饥饿问题的旁证比单纯看时延更可靠。6.3 遇到新版本时注意调度策略差异别把旧经验直接套用最后一个提醒同样的参数配置在不同的软件版本下表现可能完全不同。我遇到过某个站点升级后PDCCH 的 CCE 最小调度单位从 2 变成了 1时延问题自动消失了RATE MATCH 不再需要关闭。所以在做版本升级前后的对比中不要只盯切换成功率、掉线率这类指标建议把接入时延和 CCE 占用情况也纳入回归测试。如果升级后用户可同时接入数提升、接入时延下降说明新版本的调度算法对 CCE 的使用更高效之前的规避参数可以考虑回退。从那以后我处理 5G 接入时延问题时第一反应不再直接动功率或切换参数而是先把 PDCCH 资源池的状态摸清楚尤其是在任何站点做任何涉及 RATE MATCH 的参数调整时都会强制先保存一份基线配置再做改动然后对比优化前后的信令数据和话务统计。这个习惯帮我躲过了不少“时延好了但速率崩了”的坑希望帮到你。本文还有配套的精品资源点击获取