企业官网建设流程全解析

简介：这是一份面向5G网络优化工程师的实战案例文档，聚焦上行CCE（Control Channel Element）分配失败导致无线接通率劣化的典型问题。文档以某5G小区为对象，完整记录了从后台指标发现无线接通率劣化、RRC建立成功率与QoS Flow建立成功率关联分析、节能功能影响排查、CCE相关参数核查、CHR错误码定位到最终根因确认的全过程，并给出了补充漏配邻区、压天线收缩覆盖、打开上下行CCE比例自适应、增加Coreset0资源、关闭PDCCH Rate Matching、调整占用符号数等具体解决措施，以及优化前后RRC建立成功率稳定在99%以上、QoS Flow建立成功率从92%提升至97%的对比数据。资源为1个docx文档，包体大小2.55MB，包含关键指标分析、参数调整命令与效果验证，可直接作为网优排障案例模板。已有864人学习下载，适合从事5G网优、接入网性能优化及通信网络排障的工程师，用于建立系统性分析思路，提升处理同类无线接通率问题的效率。

1. 5G网优案例拆解：上行CCE分配失败拖垮无线接通率，这单问题出在哪

做5G网优的同行应该都见过这种工单：后台指标看板弹出某个SA小区无线接通率劣化到93%以下的告警，第一时间查干扰、查驻留、查核心网，折腾一圈找不到方向。这单达州达川区体育馆_SA_5G(1720972)_3小区的案例不太一样，它呈现出来的特征是RRC建立成功率和QoS Flow建立成功率同步下滑，两条曲线的劣化趋势与上行CCE分配失败比例高度重合。CCE是PDCCH资源调度的最小单位，上行CCE分配失败意味着控制信道上的资源在接入阶段就已经被耗尽，用户根本走不到数据承载建立那一步。这篇文章把这个案例从指标核查、CHR错误码分析到CCE扩容参数落地的完整过程拆开讲，适合正在做5G SA日常指标监控的网优工程师，也适合接到“接通率劣化但常规手段无效”这类工单的人照着排查。

2. 指标核查与根因定位：把RRC、QoS Flow和错误码串成一条线

2.1 RRC建立成功率与QoS Flow建立成功率：两条曲线为什么同步劣化

先给结论：RRC建立成功率负责空口侧第一道准入，QoS Flow建立成功率负责核心网到空口的数据承载建立，这两个指标一个在接入前半段、一个在接入后半段，但如果同步劣化，基本可以把核心网侧问题先排除掉，把视线聚焦到空口控制信道资源上。

这个小区从2月1日到3月7日的接入指标里，RRC建立成功率和QoS Flow建立成功率都在往下走，而且劣化的时间点、幅度和上行CCE分配失败比例的上升趋势几乎一致。RRC建立成功率劣化，可以理解为UE在随机接入后申请不到足够的PDCCH控制资源来继续走流程；QoS Flow建立成功率劣化，则是在INIT CONTEXT SETUP阶段基站拿不到无线资源，直接回了RADIO-RSRC-NOT-AVAIL。前者卡在接入前半段，后者卡在接入后半段，根源都在PDCCH的CCE分配。

排查时先看RRC和QoS Flow两个指标的趋势是否同步，如果同步劣化，就别再纠结核心网侧了，直接往空口控制信道方向查。这个判断在本案例里省掉了大量核接口和信令的功夫，后面的CHR分析也印证了这个方向是对的。

2.2 节能功能与CCE参数核查：先排除干扰项

拿到这种工单，还有一件事必须在早期做掉，就是排除节能功能的影响。我一般会先查小区上的节能配置，确认节能生效时段。这个案例里节能功能凌晨生效，而指标劣化是全天的，晚高峰尤其明显，两个时间轴对不上，节能功能从怀疑名单里划掉，不需要在节能门限、节能策略上反复来回试验浪费时间。

接下来查CCE相关参数。当前OccupiedSymbolNum设置的是1SYMBOL，含义是PDCCH只占用了时隙里的第1个符号；CommonCtrlResRbNum设置的是RB48，对应Coreset0的公共控制资源只有48个RB。这两个参数决定的是接入阶段公共搜索空间里的CCE容量，注意这里说的是公共控制资源，不是专用控制资源，随机接入响应、SIB1调度、MSG4这些接入流程全部走这个空间。

低负荷时段1SYMBOL、RB48配置够用，但随着小区用户数上涨，公共CCE是最先被打满的一层。我在排查时看到这两个参数的限制，心里基本已经锁定方向了，后面无非是再确认一下是不是真有大量CCE分配失败的报错。

2.3 CHR错误码786644/786646/786648/786779：失败都指向同一个原因

CHR（Call History Record，呼叫历史记录）分析是这单定位的关键证据。把失败记录的CHR调出来看，RRC和QoS Flow建立失败大多标记为CCE分配失败，错误码集中在786644、786646、786648、786779。这一组码的语义都是无线资源不可用，落在PDCCH域就是在申请CCE时没有空闲资源可用。

其中有一次接入信令非常典型：UE在接入阶段回复了安全算法之后，基站发起INIT CONTEXT SETUP FAIL，携带的原因值是RADIO-RSRC-NOT-AVAIL。这条信令说明UE侧流程全部正常，失败发生在gNB侧的资源接纳阶段。结合错误码再对照小区负荷，判断是概率性申请不到无线资源，负荷高了就频繁出现。

看到这种错误码组合，就不需要再猜是终端问题还是核心网问题了，问题就在PDCCH资源上。CHR里错误码是识别CCE类问题最直接的语言，建议做5G网优的手里留一张常见错误码对照表，排查时能省很多时间。

2.4 用户数与TA分布：远点用户比例从54%涨到78%

最后把用户维度的数据拉出来看，这个小区覆盖半径最远约1.8KM，TA区间5、6的远点用户比例从54%增加到了78%。TA（Timing Advance）区间反映UE到基站的传播时延，区间越大距离越远。远点用户多，意味着一大批UE处于小区边缘，这些UE上行信号本来就弱，基站想要维持调度需要通过下行控制信令反复做上行功控、重传调度和MCS调整，每一轮都在消耗CCE资源。

用户数与接入指标呈反相关，用户数上涨的那几天，RRC和QoS Flow建立成功率就往下掉。这里要理解准确点：不是用户太多把数据面塞满了，而是用户数增加、远点用户占比增加，导致PDCCH公共控制资源先于PDSCH/PUSCH被打满。根因一句话就能说清：CCE资源不足导致上行CCE分配失败，进而拖垮了无线接通率。

3. 组合拳解决CCE分配失败：补邻区、压覆盖、扩CCE的参数落法

3.1 补漏配邻区和压天线：先把无效接入请求降下来

这单里CCE扩容确实要做，但不应该作为唯一手段，我实际处理时先把两个非参数手段做掉了，很多同行容易忽视这一步。一是补充漏配邻区。切换指标分析发现这个小区存在邻区漏配，UE到了边缘发切换请求却找不到目标邻区，切换失败后UE要么重发RRC连接请求、要么回到本小区重新发起接入流程，等于把本该转走的边缘用户接入请求又压回本小区来。

补上漏配邻区后，边缘UE可以正常切换出去，本小区无效接入请求数量明显下降。第二个动作是压天线收缩覆盖，这个小区覆盖到了1.8KM，远点用户占比还在涨，通过压下天线倾角把覆盖收缩到合理范围，让TA区间5、6的远点用户不再大量驻留本小区消耗CCE。压天线要提醒一句，不是简单把倾角往下打就完事，要看周边邻区站点的覆盖情况，避免压完之后交接带出现空洞。

3.2 打开上下行CCE比例自适应：调度器层面先松绑

CCE资源存在上下行竞争问题。PDCCH承载的下行控制信息既包括下行调度授权，也包括上行调度授权，同一份CCE池子在上下行之间相互挤占。默认配置下上下行CCE比例是固定的，配置里下行CCE占多了，上行调度在忙时就会概率性分配失败；反过来也一样。

打开上下行CCE比例自适应开关后，gNB调度器按当前上下行业务比例动态调整CCE分配，忙时上行调度请求多，系统就多给上行分一点CCE，下行拥塞时就多给下行。这单的第一步命令是：

MOD NRDUCELLPDCCH: NrDuCellId=xx, PdcchAlgoSwitch=UL_DL_CCE_RATIO_ADAPT_SW-1;

NRDUCellId填具体的小区ID，这条命令解决的是CCE分配比例问题，不是CCE总数问题。资源池总量不变的情况下，自适应只能在现有池子里做平衡，所以只开这个开关不够，后面必须配合扩容动作。在网优社区里见过有同行把这条命令当唯一解药，实际效果是当时缓解、忙时又反弹，原因就是公共CCE总量并没有变多。

3.3 Coreset0扩容：公共控制资源从RB48提级到RB96

接下来动Coreset0。Coreset0承载的是接入阶段UE必须监听的公共搜索空间，包括SIB1调度、随机接入响应、寻呼的调度控制。CommonCtrlResRbNum从RB48扩到RB96，公共CCE数量直接翻倍，接入阶段的控制信道容量立刻变大。命令是：

MOD NRDUCELLCORESET: NrDuCellId=xx, CommonCtrlResRbNum=RB96;

Coreset0的RB数不是所有站点都能无脑调RB96，它受SSB子载波间隔、NR频段、小区带宽共同限制。实际做的时候先在网管上查一下站点支持的CORESET0配置范围，不支持的情况下命令提交会被网管直接拒绝。另外，Coreset0扩容后公共搜索空间的盲检次数会增加一点，UE侧功耗会有轻微上升，工程上一般可接受，但专项节能类项目要把这个因素记进账里。

3.4 关闭PDCCH Rate Match和调整OccupiedSymbolNum：把CCE数量顶上去

PDCCH和PDSCH之间存在速率匹配避让机制。RateMatchSwitch配置为PDCCH_RATEMATCH_SW-1时，PDSCH在速率匹配时会预留PDCCH占用的资源，低负荷时这种避让没有影响，忙时时相当于白白浪费掉了一部分可用的CCE资源。这单把RateMatchSwitch改为0，关闭PDCCH的速率匹配避让，把之前让给PDSCH避让的PDCCH可用CCE个数释放出来：

MOD NRDUCELLPDSCH: NrDuCellId=xx, RateMatchSwitch=PDCCH_RATEMATCH_SW-0;

同时把OccupiedSymbolNum从1SYMBOL改为2SYMBOL，PDCCH占用的OFDM符号翻倍，整个控制资源区域的CCE总数也跟着翻倍，再把UlMaxCcePct设为50，给上行CCE比例设定一个明确上限：

MOD NRDUCELLPDCCH: NrDuCellId=xx, UlMaxCcePct=50, OccupiedSymbolNum=2 Symbol;

这三个参数是连锁关系。OccupiedSymbolNum从1到2之后CCE池子变大，RateMatch关闭后不再有避让损耗，UlMaxCcePct=50保证上行忙时能从大池子里分到一半。单独调任何一个都出不来理想效果，这也是这类问题在参数核查阶段最容易被当成“单个参数有优化空间”的原因，实际要按组调。

4. 华为MML实操：六条命令的顺序与每个参数背后的逻辑

4.1 操作前准备与完整命令清单

实际执行MML命令前有一个绕不开的坑：先在华为网管上查小区对应的框号、槽位和NRDUCell实例。做5G网优的老手都遇到过这种情况，按小区名搜索出来一条记录，但这小区在一个多模基站的某块板卡上，不先定位清楚框号就执行命令，改错对象的后果比较难收拾。

我一般的操作顺序是先用LST命令把小区对应关系确认好，然后在夜间低峰窗口执行修改。正式修改建议逐条执行、逐条回查，不要一次性复制多条命令进去，后面出了问题不好定位是哪一条引起的。完整命令顺序整理如下：

REM 第1步：打开上下行CCE比例自适应 MOD NRDUCELLPDCCH: NrDuCellId=xx, PdcchAlgoSwitch=UL_DL_CCE_RATIO_ADAPT_SW-1; REM 第2步：打开CCE比例自适应的辅助开关 MOD NRDUCELLRSVDEXT00: NrDuCellId=xx, RsvdSwParam1=RSVDSWPARAM1_BIT14-1; MOD NRDUCellRsvd: NrDuCellId=xx, RsvdParam149=1; REM 第3步：Coreset0公共控制资源从48RB扩到96RB MOD NRDUCELLCORESET: NrDuCellId=xx, CommonCtrlResRbNum=RB96; REM 第4步：关闭PDCCH RateMatch，释放PDCCH避让占用的CCE MOD NRDUCELLPDSCH: NrDuCellId=xx, RateMatchSwitch=PDCCH_RATEMATCH_SW-0; REM 第5步：PDCCH占用符号数改为2，上行CCE比例上限设为50% MOD NRDUCELLPDCCH: NrDuCellId=xx, UlMaxCcePct=50, OccupiedSymbolNum=2 Symbol;

第1步解决的是分配比例问题，打开后调度器按上下行负载动态切分CCE资源。第2步的两个辅助开关要和第1步配合使用，某些版本下不打开这两条隐性开关，第1步的自适应其实不会真正生效，这点特别值得注意，网管上回查参数值已经显示为1，但实际调度行为没变化，多半就是辅助开关没打。第3步扩大公共搜索空间，直接影响随机接入和RRC连接建立阶段的CCE可用数量。第4步和第5步扩大整个PDCCH的CCE池子，属于容量侧扩容，这三组动作缺一不可。

提示：执行第5步前先确认小区当前负荷是否可以承受一次参数生效带来的调度短暂变化，如果小区处于高负荷时段，优先安排在凌晨操作。

4.2 参数调整后的效果对比

参数调整完，要留出观察窗口，不要第二天一看指标没变就急着回退。这个小区到3月10日的数据，RRC建立成功率稳定在99%以上，QoS Flow建立成功率从92%左右提升到97%，CHR里786644、786646、786648、786779这组错误码不再批量出现。无线接通率整体恢复到正常水平，指标明显改善。

写优化报告时要特别注意指标口径问题。我在复盘这个案例时提醒自己：劣化阶段说的“93%以下”是无线接通率整体值，而优化后说的“99%以上”是RRC建立成功率，两个指标不是一回事，报告里必须分开写，不能混成一个口径来对比。

4.3 调整后的风险观察点与回退预案

参数上调容易，参数回退要提前想清楚，我在处理这种调整时会给每个涉及参数做一份修改前配置备份，形成回退表。如果调整后三天内出现PDSCH误码率上升或者下行速率感知下降，优先怀疑RateMatch关闭后PDSCH避让减少带来的干扰变化，回退顺序是先回调第5步的OccupiedSymbolNum到1SYMBOL，再看第4步是否需要恢复RateMatch开关。

回查参数时还要注意，UL_DL_CCE_RATIO_ADAPT_SW和配套的RSVD开关全站批量对齐。曾经见过同一个规划区内，一个站打开了辅助开关、另一个站没打开的情况，忙时两站CCE分配行为不一致，指标表现一个正常一个异常。建议用MML批量导出全站配置逐项比对，不要手工一个一个站敲。

另外，打开上下行CCE比例自适应后，少数版本需要复位小区才能生效。夜间操作时如果看到参数值已经是1但调度没有变化，查一下是否需要激活态热加载。需要复位小区的话，先和周边小区确认不会引发批量切换失败，再挑低峰窗口操作，避免切完参数又搞出一轮新问题。

5. 避坑清单：CCE优化里最容易翻车的四个点

5.1 现象：改了UlMaxCcePct和OccupiedSymbolNum，错误码依然出现

原因：我先看到的是一份参数修改记录，只改了PDCCH占用符号和上行CCE比例，没有动CommonCtrlResRbNum。接入阶段走的是公共搜索空间，Coreset0还是RB48，占用符号从1变2对专用CCE有帮助，但公共CCE容量没变，随机接入和RRC建立还是挤在那48个RB上，786644这个码当然继续出现。解决：把CommonCtrlResRbNum从RB48提到RB96这一步不能省。CCE问题的核心是公共控制资源，专用CCE扩容是辅助动作，顺序从头到尾应该是先公共后专用，别把顺序搞反。这个案例里如果只做第4步和第5步，效果大概率打对折。

5.2 现象：节能功能先背锅，排障绕了弯路

原因：无线接通率一劣化，优先怀疑节能是很多人的第一反应。这个案例里节能功能生效时间和指标劣化时间明显对不上，可前期依然有人在节能门限上反复调了几天，指标动都不动。根因是用户数上涨加上TA区间5、6远点用户占比从54%涨到78%，节能开关根本不是主因。解决：定位初期花十分钟拉三根时间曲线，节能生效时段、接入指标劣化时段、用户数增长时段，三条线画在一起。时间轴重合再动节能，不重合直接排除。这个动作花不了多少时间，但能省掉好几天弯路，排查工单的效率全靠这里。

5.3 现象：UlMaxCcePct拉太高，上行指标好了，下行调度开始失败

原因：CCE池子总量不变时，把上行CCE比例上限从默认直接拉到60%甚至70%，等于把下行调度授权用的CCE挤掉了。上行CCE分配失败是少了，但PDSCH下行调度失败开始增多，数据面感知反而变差，用户投诉从“接不进去”变成“上网慢”。解决：UlMaxCcePct从50起步，观察一周上下行流量比例再微调。下行流量为主的站点50%都可能偏高，需要按站点的真实业务模型折中。每个站的上下行CCE比例不要全设成同一个值，忙时流量模型差别大的站一定要逐站评估。这个参数本质是在给上下行抢资源划界限，调节点是业务模型而不是某个固定数字。

5.4 现象：压天线收缩覆盖，压出覆盖空洞，用户投诉掉话

原因：这个坑是RF优化常见的翻车现场。为了降远点用户比例，只压了这个体育馆小区的天线，没看周边邻区站点覆盖能力。远点用户确实不在本小区了，但覆盖交接带出现了弱覆盖区，切换带断掉，掉话投诉反而增加。解决：压天线前先拉周边邻区的工参和切换统计，压天线角度每次不超过2度，分步调整。压完观察TA区间分布变化，确认覆盖交接带仍然连续。如果周边站点本来就覆盖不足，要联合周边小区一起调整，不能单站收割指标。

注意：CCE相关的参数调整和RF调整最好不要同一天做。RF调整后的覆盖收敛需要时间观察，同一天又改CCE参数，后面指标遇到波动时根本说不清是覆盖问题还是资源问题，复盘时容易变成一笔糊涂账。

6. 验证方法与后续观测：从一次优化到一套排查模板

6.1 三个指标判断CCE资源是否真够

优化完不能只看RRC成功率一条曲线，我一般盯着三个指标一起看：上行CCE分配失败比例、QoS Flow建立成功率、TA区间5、6的远点用户比例。这三个指标同时稳定，才算真的闭环。只恢复一个指标就下结论，下个忙时大概率还会翻车。

6.2 把这次排查流程沉淀成模板

这单做完后，我把排查顺序固定成了自己的例行模板，以后遇到SA小区接入类劣化工单，直接照这个顺序走一遍：先拉RRC与QoS Flow成功率判断劣化层面前后段，再拉上行CCE分配失败比例和CHR错误码做证，然后排节能时间轴，再核Coreset0和PDCCH参数，最后看用户数与TA分布变化。每一步都对应明确的判定动作和命令，而不是靠感觉翻参数。

从那以后，我每次接到5G SA小区无线接通率劣化的工单，第一件事不是改参数，而是先拉出上行CCE分配失败比例和TA分布两张图。CCE问题的难点往往不在参数怎么调，而在定位路径对不对。先把时间轴排清楚、错误码对照好，再动手调参数，这条路帮我少走了很多弯路。这份案例的完整MML命令和指标对比记录都可以直接拿去做模板，希望帮到你。

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