5G SA网优案例：上行CCE分配失败导致无线接通率劣化分析与优化

简介这份资源是一份面向5G网络优化工程师与运维人员的实战案例文档聚焦SA网络上行CCE分配失败导致无线接通率劣化的排查与解决过程。内容从RRC建立成功率、QoS Flow建立成功率与上行CCE分配失败比例的一致性入手结合节能功能核查、CCE参数配置、用户分布及CHR错误码分析定位出远点用户占比升高引发CCE资源不足的根因并给出补充漏配邻区、压天线收缩覆盖、扩容CCE等具体措施及优化前后指标对比。资源包共1个docx文件约2.55MB内容完整、条理清晰适合需要积累网优排障思路的读者参考。目前已有864人学习下载可帮助读者掌握从指标异常到参数核查、根因定位再到方案落地的完整分析路径为5G网络质量提升提供可复用的经验。1. 从一次接通率跌破 93% 说起这份 SA 网优案例到底拆了什么后台指标巡检时某地一个 SA 小区的无线接通率突然掉到 93% 以下RRC 建立成功率和 QosFlow 建立成功率同步往下走。翻遍节能开关、覆盖、用户数最后落到一个容易被忽略的点上上行 CCE 分配失败。这份《5G网优案例上行CCE分配失败导致无线接通率劣化分析案例.docx》完整记录了这个从指标异常到根因定位、再到参数调整和效果验证的全过程属于典型的 SA 网络接入类优化案例。它适合正在做 5G 网优、被接通率劣化折腾过、或者想搞明白 CCE 资源到底怎么影响接入成功率的从业者。文档不是泛泛的理论科普而是带着错误码、参数名、修改命令和前后对比数据的实操记录拿来就能对着自己手上的小区排查。2. 指标劣化怎么锁定到 CCE从 RRC 到 QosFlow 的排查链路2.1 先看趋势一致性别急着改参数案例里最先做的事不是翻参数而是把三条曲线拉到同一张图上看RRC 建立成功率、QosFlow 建立成功率、上行 CCE 分配失败比例。结果很直观——三条线的劣化趋势几乎重合。这个动作看着简单但很多现场排查会跳过直接去查告警或改功率结果绕一大圈。为什么趋势一致性这么关键因为 RRC 和 QosFlow 建立都发生在接入阶段两者共享同一套控制信道资源。如果 CCE 分配失败比例上升意味着 UE 在发起接入时申请不到足够的控制信道单元RRC 连接建立就会卡住后续 QosFlow 自然也跟着失败。趋势重合基本可以把怀疑范围从“传输问题、核心网问题、干扰问题”收缩到“控制信道资源问题”。具体操作上我一般会按下面这个顺序拉数据# 从网管导出指定小区的接入类指标时间粒度选小时级 # 重点字段RRC建立成功率、QosFlow建立成功率、上行CCE分配失败次数、CCE分配失败比例 # 时间范围至少覆盖劣化前一周到劣化后一周方便看拐点拿到数据后用表格做一次对齐。案例中 2 月 1 日到 3 月 7 日的数据显示RRC 和 QosFlow 的劣化拐点与 CCE 分配失败比例的抬升拐点在同一天出现。这一步做完排查方向就明确了。2.2 排除法节能、用户数、覆盖逐个过一遍锁定 CCE 之后还要排除几个常见“背锅侠”。案例里做了三组对照第一组是节能功能。查询节能功能的生效时间发现和接入指标劣化的时间对不上。节能功能通常在低话务时段生效而这次劣化是持续性的时间窗口不吻合排除。第二组是用户数。用户数和接入指标呈反相关——用户越多成功率越低。但这只是表象真正的问题不是用户数本身而是用户分布。案例中远点用户比例TA 区间 5、6从 54% 增加到 78%最远覆盖到 1.8KM。远点用户接入时需要更多的重复传输和更高的聚合级别直接吃掉更多 CCE 资源。第三组是覆盖。压天线收缩覆盖后远点用户比例下降CCE 压力随之缓解。这也从侧面验证了根因。这三组排查做完根因基本清晰用户增加叠加远点用户占比上升导致 CCE 资源不足上行 CCE 分配失败最终拖垮接入指标。2.3 CHR 和信令里的实锤错误码与原因值指标趋势只能定位方向要拿到实锤还得看 CHR 和信令。案例中 CHR 分析显示RRC 和 QosFlow 建立失败大多由 CCE 分配失败导致错误码集中在 786644、786646、786648、786779。这几个码在 SA 网络里通常指向无线资源申请失败尤其是控制信道资源不足。更直接的是信令分析。案例抓了一次完整的接入信令UE 回复安全算法后基站发起了 INITCONTEXTSETUP FAIL携带原因值 RADIO-RSRC-NOT-AVAIL。这个原因值翻译过来就是“无线资源不可用”结合前面的 CCE 分配失败链路就闭合了。另外切换指标里还发现该小区存在邻区漏配。邻区漏配会导致切换不及时UE 在边缘区域反复尝试接入进一步加剧 CCE 资源紧张。这个问题在案例中被一并处理。提示CHR 里的错误码和信令原因值是定位接入类问题的关键证据建议排查时优先拉取不要只依赖汇总指标。3. CCE 扩容与参数调整具体命令和参数含义3.1 CCE 资源为什么不够先理解 Coreset0 和占用符号要改参数先得知道 CCE 资源从哪来。SA 网络里PDCCH 的控制信道资源以 CCE 为单位Coreset0 是公共控制资源集承载 RRC 建立、QosFlow 建立等公共信令。Coreset0 的 CCE 数量取决于两个维度频域上的 RB 数和时域上的符号数。案例中当前配置是 OccupiedSymbolNum1 SYMBOLCommonCtrlResRbNumRB48。1 个符号加 48 个 RB能提供的 CCE 数量有限。当远点用户增多、聚合级别升高时每个用户占用的 CCE 数增加资源很快见底。扩容思路有两条一是增加频域资源把 CommonCtrlResRbNum 从 RB48 提到 RB96二是增加时域资源把 OccupiedSymbolNum 从 1 调到 2。两条路都能增加 CCE 总数但代价不同——增加符号数会占用更多 PDSCH 资源可能影响下行吞吐增加 RB 数则受限于带宽配置。案例中两条都做了同时配合其他开关。3.2 参数修改清单逐条命令与作用案例给出的修改命令涉及多个 MO下面逐条拆开说。# 1. 打开上下行 CCE 比例自适应 MOD NRDUCELLPDCCH: NrDuCellIdxx, PdcchAlgoSwitchUL_DL_CCE_RATIO_ADAPT_SW-1; # 2. 打开预留开关为 CCE 扩容做准备 MOD NRDUCELLRSVDEXT00: NrDuCellIdxx, RsvdSwParam1 RSVDSWPARAM1_BIT14-1; MOD NRDUCellRsvd: NrDuCellIdxx, RsvdParam1491; # 3. 增加 Coreset0 的 CCE 资源 MOD NRDUCELLCORESET: NrDuCellIdxx, CommonCtrlResRbNumRB96; # 4. 关闭 PDCCH RM增加可用 CCE 个数 MOD NRDUCELLPDSCH: NrDuCellIdxx, RateMatchSwitchPDCCH_RATEMATCH_SW-0; # 5. 调整占用符号数和上行 CCE 比例 MOD NRDUCELLPDCCH: NrDuCellIdXX, UlMaxCcePct50, OccupiedSymbolNum2 Symbol;逐条解释第一条UL_DL_CCE_RATIO_ADAPT_SW 打开后上下行 CCE 比例可以根据实际负载动态调整。上行 CCE 紧张时系统可以借用下行 CCE 资源提升上行接入成功率。这个开关在上下行话务不对称的场景下特别有用。第二条和第三条是配套的预留开关RsvdSwParam1 的 BIT14 和 RsvdParam149 需要同时打开才能让后续的 Coreset0 扩容生效。不同版本的网管里预留参数的编号可能不同改之前先确认版本说明。第四条PDCCH_RATEMATCH_SW 关闭后PDCCH 不再做速率匹配可用的 CCE 个数会增加。代价是 PDSCH 的速率匹配灵活性下降但在 CCE 资源紧张的场景下优先保接入。第五条UlMaxCcePct50 把上行 CCE 的最大比例设为 50%OccupiedSymbolNum2 Symbol 把 PDCCH 占用符号数从 1 增加到 2。符号数增加直接翻倍了时域上的 CCE 容量是扩容效果最明显的一步。注意参数修改前务必确认小区当前带宽和 PDSCH 配置增加符号数可能挤占下行数据信道资源话务高峰时段要观察下行吞吐变化。3.3 配套措施邻区补充和天线调整参数调整不是全部。案例中还做了两件事一是补充漏配邻区。邻区漏配会导致切换失败UE 在边缘反复接入增加 CCE 消耗。补充邻区后切换成功率提升间接减轻了 CCE 压力。二是压天线收缩覆盖。把天线倾角下压收缩远点覆盖降低远点用户比例。这个动作见效快但会影响覆盖范围需要权衡。案例中压天线后远点用户比例下降CCE 分配失败比例随之降低。这两条措施和参数调整配合形成了“开源节流”的组合一边扩容 CCE一边减少不必要的 CCE 消耗。4. 避坑与排查这类案例里最容易翻车的几个点4.1 只看 RRC 成功率忽略 QosFlow 的联动现象RRC 建立成功率下降单独优化 RRC 相关参数后没有改善。 原因RRC 和 QosFlow 共享 CCE 资源QosFlow 建立失败会反向影响 RRC 的后续流程。只盯一个指标容易漏掉根因。 解决把 RRC、QosFlow、CCE 分配失败比例三条线一起看趋势一致时优先查 CCE。4.2 参数改了但没生效漏了预留开关现象CommonCtrlResRbNum 改成 RB96 后CCE 总数没有变化。 原因Coreset0 扩容依赖预留开关RsvdSwParam1 和 RsvdParam149 没打开时参数修改不生效。 解决改 Coreset0 之前先确认预留开关状态按顺序打开后再改 RB 数。4.3 盲目增加符号数下行吞吐掉坑现象OccupiedSymbolNum 从 1 调到 2 后接入指标改善但下行速率下降。 原因PDCCH 占用更多符号PDSCH 可用符号减少下行吞吐受影响。 解决调整后同时观察下行吞吐和接入指标必要时用 UlMaxCcePct 做折中不要一味加符号。4.4 忽略邻区漏配CCE 压力反复现象CCE 扩容后指标改善但过一段时间又劣化。 原因邻区漏配导致切换失败UE 在边缘反复接入持续消耗 CCE。 解决排查切换指标补充漏配邻区从源头减少无效接入。4.5 节能功能误判浪费时间现象接入指标劣化怀疑节能功能导致反复核查节能开关。 原因节能功能生效时间与劣化时间不吻合但排查时容易先入为主。 解决先做时间对齐确认节能生效窗口和劣化窗口是否重合不重合就快速排除。5. 效果验证与进阶技巧怎么确认优化真的到位了优化做完不是看一天数据就收工。案例中 3 月 10 日的数据显示RRC 建立成功率稳定在 99% 以上QosFlow 建立成功率从 92% 左右提升到 97%。这个提升幅度在接入类优化里算比较明显的但验证时要注意几个细节。第一观察周期至少覆盖三天包含工作日和周末。接入指标受用户行为影响大单天数据可能有偶然性。案例中给了 3 月 10 日的数据实际验证时建议拉一周趋势。第二分时段看。忙时和闲时的 CCE 分配失败比例可能差异很大。优化后忙时指标是否稳定比全天均值更有说服力。我一般会按小时粒度拉数据重点看忙时是否还有 CCE 分配失败的尖峰。第三对照邻区。同一个基站下其他小区的指标有没有同步变化可以排除外部因素干扰。如果只有目标小区改善说明调整确实起了作用。第四回看 CHR。优化后 CHR 里 786644、786646 等错误码的出现次数是否下降INITCONTEXTSETUP FAIL 是否消失。这些底层记录比汇总指标更可靠。进阶技巧方面CCE 资源优化不是一次性的。用户分布会变覆盖环境会变建议把 CCE 分配失败比例纳入日常巡检指标设置阈值告警。一旦比例超过基线提前介入不要等到接通率跌破 93% 再动手。另外UlMaxCcePct 的取值需要根据上下行话务比例调整。案例中设为 50%如果上行话务占比更高可以适当上调但要注意下行 CCE 是否够用。这个参数没有万能值得结合小区实际话务模型来定。还有一个容易忽略的点CCE 扩容后PDCCH 的聚合级别自适应策略也会影响资源利用率。远点用户聚合级别高占用 CCE 多如果能在覆盖上做优化减少远点用户比例比单纯扩容更经济。案例中压天线和扩容同时做就是这个思路。从那以后我每次处理接入类劣化都强制先拉 RRC、QosFlow、CCE 分配失败三条趋势线对齐再动参数。这个习惯帮我省了很多来回折腾的时间。希望帮到你。本文还有配套的精品资源点击获取