简介：这份资源是一份面向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 数和时域上的符号数。
案例中当前配置是 OccupiedSymbolNum=1 SYMBOL，CommonCtrlResRbNum=RB48。1 个符号加 48 个 RB，能提供的 CCE 数量有限。当远点用户增多、聚合级别升高时，每个用户占用的 CCE 数增加，资源很快见底。
扩容思路有两条：一是增加频域资源，把 CommonCtrlResRbNum 从 RB48 提到 RB96；二是增加时域资源，把 OccupiedSymbolNum 从 1 调到 2。两条路都能增加 CCE 总数，但代价不同——增加符号数会占用更多 PDSCH 资源，可能影响下行吞吐；增加 RB 数则受限于带宽配置。案例中两条都做了，同时配合其他开关。
3.2 参数修改清单：逐条命令与作用
案例给出的修改命令涉及多个 MO，下面逐条拆开说。
# 1. 打开上下行 CCE 比例自适应 MOD NRDUCELLPDCCH: NrDuCellId=xx, PdcchAlgoSwitch=UL_DL_CCE_RATIO_ADAPT_SW-1; # 2. 打开预留开关，为 CCE 扩容做准备 MOD NRDUCELLRSVDEXT00: NrDuCellId=xx, RsvdSwParam1= RSVDSWPARAM1_BIT14-1; MOD NRDUCellRsvd: NrDuCellId=xx, RsvdParam149=1; # 3. 增加 Coreset0 的 CCE 资源 MOD NRDUCELLCORESET: NrDuCellId=xx, CommonCtrlResRbNum=RB96; # 4. 关闭 PDCCH RM，增加可用 CCE 个数 MOD NRDUCELLPDSCH: NrDuCellId=xx, RateMatchSwitch=PDCCH_RATEMATCH_SW-0; # 5. 调整占用符号数和上行 CCE 比例 MOD NRDUCELLPDCCH: NrDuCellId=XX, UlMaxCcePct=50, OccupiedSymbolNum=2 Symbol;逐条解释：
第一条，UL_DL_CCE_RATIO_ADAPT_SW 打开后，上下行 CCE 比例可以根据实际负载动态调整。上行 CCE 紧张时，系统可以借用下行 CCE 资源，提升上行接入成功率。这个开关在上下行话务不对称的场景下特别有用。
第二条和第三条是配套的预留开关，RsvdSwParam1 的 BIT14 和 RsvdParam149 需要同时打开，才能让后续的 Coreset0 扩容生效。不同版本的网管里，预留参数的编号可能不同，改之前先确认版本说明。
第四条，PDCCH_RATEMATCH_SW 关闭后，PDCCH 不再做速率匹配，可用的 CCE 个数会增加。代价是 PDSCH 的速率匹配灵活性下降，但在 CCE 资源紧张的场景下，优先保接入。
第五条，UlMaxCcePct=50 把上行 CCE 的最大比例设为 50%，OccupiedSymbolNum=2 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 分配失败三条趋势线对齐，再动参数。这个习惯帮我省了很多来回折腾的时间。希望帮到你。
本文还有配套的精品资源，点击获取
