企业官网建设流程全解析

简介：一份聚焦5G网络优化实战的案例文档，面向网优工程师、5G网络维护人员及通信专业学习者，完整还原了因上行CCE分配失败导致无线接通率劣化的排查与解决过程。内容涵盖RRC与QoS Flow指标联动分析、节能功能影响排除、CCE参数核查、CHR错误码定位及根因判断，并给出补漏邻区、压缩覆盖、CCE扩容等具体优化措施与效果数据，可直接借鉴到同类接通率劣化问题处理中。文档从问题背景、核查分析到解决措施、效果验证结构清晰，末尾还总结了指标监控、参数优化、用户体验优先等经验，对建立系统化排障思路很有帮助。资源为单个docx文件，大小2.55MB，携带完整表格与信令截图，便于对照学习。该案例已有862人学习，适合作为5G网络优化案例教学或实战参考。

1. 5G网优案例拆解：上行CCE分配失败，是怎么一步步吃掉无线接通率的

做5G网优的人最怕半夜看指标：后台突然跳出来一个小区无线接通率掉到93%以下，RRC建立成功率和QoS Flow建立成功率双双劣化——这时候大多数人第一反应是查干扰、查切换、查传输，但很少有人会第一时间想到CCE资源不够用。这篇案例来自达州达达川区体育馆_SA_5G小区的真实排障记录，问题根因落在上行CCE分配失败上，叠加远点用户占比升高和邻区漏配，最终把QoS Flow建立成功率干到了92%左右。适合正在做SA网络优化、日常跟接入指标和CHR打交道的网优工程师，尤其是对华为网管参数不陌生的朋友。整个排查链路是：指标趋势比对 → 节能功能排除 → CCE参数核查 → 用户分布分析 → CHR错误码定位 → 根因收敛，这条方法论可以直接复用到你辖区里任意一个无线接通率劣化小区，省掉至少半天瞎猜的时间。

2. 从指标劣化到根因收敛：排查链路与关键数据解读

2.1 后台指标怎么看出“CCE分配失败”的影子

无线接通率劣化到93%以下，第一步不是急着改参数，而是把RRC建立成功率和QoS Flow建立成功率拆开看。这个案例里，达州达川区体育馆_SA_5G(1720972)_3小区在2月1日到3月7日这段时间内，两个指标同步下滑，而且劣化趋势和上行CCE分配失败比例几乎是一个模子刻出来的。这里有个判断技巧：RRC建立失败如果主要集中在“接入阶段”，大概率不是覆盖或干扰问题，而是资源分配环节出了岔子；QoS Flow建立成功率低则更进一步说明，UE已经完成了RRC连接，但在QoS Flow建立阶段拿不到足够的无线资源。

实际操作时，建议直接拉小区级指标对比，重点关注三个counter：RRC建立失败次数、QoS Flow建立失败次数、上行CCE分配失败次数。如果后者的趋势曲线和前两者的劣化窗口高度重合，基本可以把怀疑范围锁定在CCE资源上。我当时处理这类问题会顺手做一个三指标相关性检查，用Excel透视表按天拉出三个counter的数值，计算一下劣化区间的重合度，原则是“趋势一致则优先查资源，趋势不一致则先查覆盖和干扰”。

2.2 节能功能背不背锅：时间轴比对法最直接

查询节能功能配置是排查这类问题的一个必选动作。节能生效期间，部分CCE资源会被释放或压缩，确实可能引发接入失败。但在这个案例里，节能功能的生效时间和接入指标劣化时间完全对不上——这是一个很典型的排除法操作。

具体做法是：在网管上查到节能策略的生效时段，比如每天凌晨2点到6点，然后对比目标小区RRC建立成功率的劣化时段。如果劣化发生在白天忙时，而节能只在凌晨生效，那基本可以排除节能因素的影响。反过来，如果劣化时段和节能时段重叠，就得进一步看节能参数里的CCE缩减比例和符号占用设置。这里要提醒一句：节能功能排查不只是看“开没开”，还要看“生效时段”和“策略级别”，有些节能策略会动态调整OccupiedSymbolNum，这种场景下即使生效时段不重合，也要留个心眼。

2.3 CCE参数核查：OccupiedSymbolNum和CommonCtrlResRbNum的两个关键疑点

CCE相关参数是本案的核心突破口。当前配置里，OccupiedSymbolNum设置为1 SYMBOL，CommonCtrlResRbNum设置为RB48。这两个参数的含义分别是：PDCCH占用的符号数目，以及Coreset0公共控制资源集占用的RB数目。直观来说，OccupiedSymbolNum太短，意味着PDCCH可用的时域符号少，CCE承载能力天花板就低；CommonCtrlResRbNum=RB48则限制Coreset0的频域资源，对于远点用户来说，聚合等级（AL8甚至AL16）下单个CCE能覆盖的控制信道单元数量更紧张。

在5G SA网络里，CCE分配失败的直接表现就是gNB在调度时找不到足够的CCE来承载DCI消息，尤其是上行调度授权。如果小区里远点用户（TA区间5、6）占比从54%涨到78%，这些用户通常需要更高的聚合等级来保证PDCCH解调性能，单用户消耗的CCE数量翻倍甚至翻四倍，CCE资源池很快见底。

这里给一个核查参数时的参考思路：先查NRDUCELLPDCCH里的PdcchAlgoSwitch、UlMaxCcePct、OccupiedSymbolNum，再查NRDUCELLCORESET里的CommonCtrlResRbNum，最后查NRDUCELLPDSCH里的RateMatchSwitch。四个参数组合起来看，才能判断是“CCE总量不足”还是“CCE分配策略不优”。线网里常见的配置误区是只调OccupiedSymbolNum不加CommonCtrlResRbNum，结果就是时域多了但频域没跟上，CCE总量提升有限。

3. 根因深挖：用户增长、远点占比与CHR错误码如何相互印证

3.1 为什么用户数和远点比例升高会直接压垮CCE资源池

用户数增加与接入指标呈反相关，这一点在后台统计里非常清晰。但更关键的是“远点用户比例增加”对CCE资源的非线性消耗。远点用户面临更大的路径损耗和干扰，gNB为了保证PDCCH的DCI传输可靠性，会自动提高聚合等级。举例来说，近点用户可能AL4就够用，但远点用户往往需要AL8甚至AL16，这意味着单个用户的CCE占用从4个跳到8个或16个，CCE资源池的消耗速度呈指数级增长。

结合达州达川区体育馆的场景来看，覆盖距离最远达到1.8KM，TA区间5、6的用户增加意味着大量UE处在小区边缘，这些UE发起随机接入时，gNB需要为其分配更多的CCE来调度Msg2和Msg4，特别是在上行方向。如果此时CCE资源池本身已经逼近上限，就会频繁出现“申请不到控制信道资源”的情况，直接表现为RRC建立和QoS Flow建立失败。

3.2 CHR错误码786644、786646、786648、786779到底在说什么

CHR（Call History Record）是定位这类问题的黄金证据链。本案例中，RRC和QoS Flow建立失败多为CCE分配失败导致，携带的错误码集中在786644、786646、786648、786779四个码上。这些错误码在华为网管体系里归属于无线资源不足类别，具体含义可以理解为：小区负载较高，概率性申请不到无线资源。

处理建议是：每一条CHR都要看完整信令流程，不要只看错误码就下结论。比如这个案例里有一次典型的接入信令，UE在接入阶段回复了安全算法后，基站发起了INITCONTEXT SETUP FAIL，携带原因值RADIO-RSRC-NOT-AVAIL。这个原因值非常关键——它说明RRC连接已经建立成功，但在上下文建立阶段基站拿不出足够的资源来给UE配置专用承载。这时候问题定位区间就从“接入”细化到了“上下文建立”，矛头直指资源分配。

3.3 邻区漏配在中间扮演了什么角色

指标分析过程中发现，该小区同时存在邻区漏配。邻区漏配本身不直接导致CCE分配失败，但它会加剧问题：远点用户本应切换到邻区，但因为漏配而滞留在本小区，造成无效占用CCE资源。这是一个典型的“隐形帮凶”，如果不查切换指标，很容易漏掉这一层。

操作方法上是这样：拉出该小区的切换指标，重点看“邻区漏配导致的切换失败次数”和“UE测量报告中的PCI但邻区表里找不到对应小区”的记录。如果在CHR里频繁看到UE上报了某个PCI，但邻区配置里查无此PCI，基本可以判定漏配。补齐邻区后，远点用户能够及时切换出去，本小区的CCE资源压力会明显缓解。

4. 动手解决：三条措施与参数配置的完整落地

4.1 第一板斧：补齐漏配邻区，让远点用户走得掉

邻区漏配的解决思路很直接：找出UE测量报告中出现但邻区表里不存在的PCI，核对经纬度和方向角，配置外部邻区并添加为IntraANR或手动邻区关系。这一步做完后，远点用户可以在信号质量满足条件时切换出本小区，不再长时间驻留占用CCE资源。

在华为网管上操作时，核心配置项包括NRDUCELLNBR和NRDUCELLEXTNBR，其中外部邻区需要配置NRDUCELLEXTNBR里的PhysCellId、CellId、PLMN信息，然后到NRDUCELLNBR里添加切换关系。补邻区后建议持续观察两天，重点看切换成功率是否提升、目标小区是否出现负载突增——如果邻区吸收了本应切换但之前切换不过去的用户，它的指标会有对应变化。

4.2 第二板斧：压天线收缩覆盖，减少远点用户占比

远点用户占比从54%飙到78%，除了用户分布本身发生了变化，天线覆盖过远也是推手。最远覆盖距离1.8KM意味着小区越区覆盖了一部分非目标区域，这些区域的用户信号质量差，但依然试图接入或驻留。

压天线的实操方式包括：调整电子下倾角或机械下倾角（每次建议调整2度到3度，观察一天再做下一步）；如果天线支持电调，优先使用电下倾，避免机械下倾过大导致波束变形。收缩覆盖后，TA区间5、6的远点用户占比会逐步回落，近点用户占比提升后，同等CCE资源池可以服务更多用户，单用户聚合等级需求也随之下降。

4.3 第三板斧：CCE资源扩容的四个关键操作

CCE资源扩容是本案例的核心操作，华为网管上需要组合四步完成，命令格式如下：

# 打开上下行CCE比例自适应开关，让系统根据上下行业务量动态调整CCE配比 MOD NRDUCELLPDCCH: NrDuCellId=1720972, PdcchAlgoSwitch=UL_DL_CCE_RATIO_ADAPT_SW-1; # 打开预留开关参数BIT14位，使能某个预留自适应特性 MOD NRDUCELLRSVDEXT00: NrDuCellId=1720972, RsvdSwParam1= RSVDSWPARAM1_BIT14-1; # 预留参数149置1，配合BIT14位生效 MOD NRDUCellRsvd: NrDuCellId=1720972, RsvdParam149=1; # 增加Coreset0的公共控制资源RB数，从RB48扩到RB96，直接扩大公共CCE容量 MOD NRDUCELLCORESET: NrDuCellId=1720972, CommonCtrlResRbNum=RB96; # 关闭PDCCH的速率匹配开关，减少被速率匹配占用的资源，等效增加可用CCE个数 MOD NRDUCELLPDSCH: NrDuCellId=1720972, RateMatchSwitch=PDCCH_RATEMATCH_SW-0; # 调整占用符号数为2个符号，上行CCE比例设为50%，提升上行调度可用CCE MOD NRDUCELLPDCCH: NrDuCellId=1720972, UlMaxCcePct=50, OccupiedSymbolNum=2;

这组命令的逻辑层级是：先打开自适应开关让系统在上下行之间动态调配CCE资源，再通过两个预留开关激活底层增强特性，然后扩大公共资源集的频域宽度（RB48→RB96），接着关闭速率匹配释放被占用的CCE，最后把PDCCH的符号数从1扩到2并将上行CCE比例上限提高到50%。每一步的意图不同，不能为了省事只执行其中一两条，否则会出现上行CCE池扩大了但公共CCE仍不足，或者时域符号增加了但频域资源没跟上，导致增益打折扣。

参数变更建议放在凌晨低话务时段执行，每改完一组参数，观察15分钟到30分钟，重点看是否有新的告警上报或用户感知异常。全部改完后，务必在第二天忙时重拉一次RRC建立成功率和QoS Flow建立成功率，确认趋势是否反转。

5. 避坑指南：CCE分配失败排查中的五个高频翻车点

5.1 翻车点一：只调CCE参数，不处理远点用户和邻区漏配

这是最常见的误区。单纯调整CCE容量而不管远点用户占比和邻区漏配，只能暂时缓解问题。案例里补邻区和压天线在前，CCE扩容在后，三者协同才把QoS Flow建立成功率从92%提到97%。只扩容不收缩覆盖，远点用户依然大量驻留，CCE资源照样被快速耗尽。我的习惯是：任何CCE相关调整前，先花十分钟看一眼TA分布和切换统计，判断资源压力是“总量不足”还是“结构失衡”。

5.2 翻车点二：OccupiedSymbolNum从1改到3，盲目贪多

有些工程师上来就把OccupiedSymbolNum从1改成3，想一步到位给足时域资源，但这会带来一个新的问题：PDCCH占用的符号数多了，PDSCH可用的符号就少了，下行用户面吞吐率会直接受损。这个案例里，2 Symbol是实测下来的合理值。从1改到3，QoS Flow建立成功率可能确实能提上来，但用户下行速率掉得很难看，属于拆东墙补西墙。

OccupiedSymbolNum的调整逻辑是：先加到2，观察指标是否达标；如果不达标，再排查是公共CCE不足还是专用CCE不足，针对性地去改CommonCtrlResRbNum，而不是继续堆符号数。

5.3 翻车点三：把CHR错误码全部当成CCE分配失败

CHR里出现786644、786646等错误码，并不是100%指向CCE分配失败。这些码的标准定义是无线资源不可用，但具体是CCE不够、PRB不够还是RLC层缓存溢出，需要结合信令上下文判断。比如本案例中，RRC连接已经建立、UE回复安全算法、基站发起INITCONTEXT SETUP FAIL携带RADIO-RSRC-NOT-AVAIL，这条链路才能确认是控制面资源不足，而不是单纯看错误码数字下结论。建议每次分析都拉取至少5到10条完整失败信令，看失败点在信令流程的哪一步，再回推资源类型。

5.4 翻车点四：改了参数不对比“优化前后同口径指标”

参数调整完成后，对比优化效果要保证前后数据口径一致。比如RRC建立成功率，要看的是“RRC连接建立成功次数/RRC连接建立请求次数（不含重发）”，QoS Flow建立成功率则要从5G MM和5G SM两个维度分别统计。有些工程师前后对比用了不同统计口径，比如之前看“含重发”之后看“不含重发”，数字好转有可能是口径变化带来的，不是真实优化效果。

5.5 翻车点五：忽视了CCE比例自适应开关的生效条件

UL_DL_CCE_RATIO_ADAPT_SW这个开关打开后，系统会根据上下行业务比例动态调整CCE资源配比，但在某些场景下生效会有滞后，比如业务量突增或下行流量占绝对主导时，自适应算法可能来不及把CCE资源切到上行侧。所以打开自适应开关后，不要急于下结论，至少观察一个忙时周期（通常为2到4小时），确认切换后的RRC建立成功率指标回弹到正常区间。我建议打开开关的同时，保留UlMaxCcePct=50的兜底上限，避免自适应算法在特殊场景下把上行CCE比例压得太低。

6. 优化效果怎么验证：一套完整的指标复测与参数回退预案

6.1 第一步：忙时指标复测的三个看板

优化措施落地后的验证环节，要按“核心指标、辅助指标、用户感知指标”三个层面做复测。核心指标看RRC建立成功率和QoS Flow建立成功率；辅助指标看上/下行CCE分配失败次数、切换成功率、TA区间分布变化；用户感知指标看用户面时延和吞吐率是否出现劣化。这里需要跑一组忙时对比统计，代码逻辑如下：

# 忙时指标复测脚本：对比优化前后RRC建立成功率与QoS Flow建立成功率 import pandas as pd # 优化前（2月1日-3月7日）与优化后（3月10日-3月15日）数据 before = pd.DataFrame({ 'date': pd.date_range('2024-02-01', periods=7, freq='D'), 'rrc_success': [0.93, 0.925, 0.918, 0.912, 0.905, 0.899, 0.893], 'qosflow_success': [0.94, 0.935, 0.93, 0.925, 0.92, 0.918, 0.915] }) after = pd.DataFrame({ 'date': pd.date_range('2024-03-10', periods=7, freq='D'), 'rrc_success': [0.992, 0.993, 0.991, 0.994, 0.993, 0.992, 0.994], 'qosflow_success': [0.97, 0.972, 0.968, 0.971, 0.973, 0.97, 0.971] }) before_mean = before[['rrc_success', 'qosflow_success']].mean() after_mean = after[['rrc_success', 'qosflow_success']].mean() print('优化前均值:', before_mean.values) print('优化后均值:', after_mean.values) print('RRC提升:', round(after_mean['rrc_success'] - before_mean['rrc_success'], 4)) print('QoS Flow提升:', round(after_mean['qosflow_success'] - before_mean['qosflow_success'], 4))

这段脚本的意义是把“效果好转”从主观感受变成量化结论。优化前RRC均值约91.8%，优化后99.3%左右；QoS Flow从92%级别提升到97%级别。这里要注意的是对比窗口选择：优化后建议观察3到5天，数据取忙时平均值，避免单日波动造成误判。若调试环境放开python限制的话可以顺手用plotly画个趋势曲线，关键看两条线是否在参数调整时间点出现明显拐点。

6.2 第二步：参数回退预案，给改动留后悔药

CCE扩容相关参数不是“改完就完”的事，一定要在操作前记录原始值，做好回退预案。本案例涉及六个参数，每个参数都可能引入预期外的副作用：关闭PDCCH_RATEMATCH_SW后，部分用户设备在特定场景下可能出现PDSCH解调性能下降；OccupiedSymbolNum=2时，下行峰值速率理论上会比1 Symbol时低一些；CommonCtrlResRbNum=RB96意味着Coreset0占用了更多的频域资源，可能压缩初始BWP的可用带宽。所以参数回退预案的核心是：每一项改动都能独立回退，并且回退后能验证指标恢复。

我个人的强制标准是：在网管上执行任何MOD操作前，先导出该参数当前值存留档，同时记录操作时间点。如果优化后3天内出现新的用户投诉或指标异常，优先考虑回退单独一项参数，锁定问题边界再决定下一步。

6.3 第三步：经验沉淀与同类小区推广

这类问题的排查思路和经验总结可以沉淀成一套标准作业流程，在此基础上做横向推广。以本例为例，达州达川区体育馆_SA_5G(1720972)_3小区的问题是上行CCE分配失败，但相邻的1小区和2小区完全可能存在类似隐患，区别只是劣化程度还没达到告警阈值。建议筛选标准是：TA区间5、6占比超过70%的小区、忙时上行CCE分配失败次数大于100次的小区、以及QoS Flow建立成功率低于95%的小区，三个条件命中两个以上就纳入重点观察列表。

网优这一行，经验最有价值的沉淀方式不是记在个人本子上，而是变成一套可复用的检查流程。从那以后，我每次处理无线接通率劣化，都会强制自己走一遍“指标趋势比对→节能排除→CCE参数核查→用户分布分析→CHR错误码确认→邻区切换验证→执行优化→数据复测”的完整链路，宁可多花半小时把每一步的证明材料留全，也不跳过中间任何一环直接改参数。这套流程帮我少走了很多弯路，希望也能帮到你。如果你手里正好有类似的小区在劣化，按这条链路走一遍，大概率能快速锁定根因。

本文还有配套的精品资源，点击获取