简介这是一份面向5G网络优化工程师的实战案例文档聚焦上行CCEControl 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失败都指向同一个原因CHRCall 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.8KMTA区间5、6的远点用户比例从54%增加到了78%。TATiming 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: NrDuCellIdxx, PdcchAlgoSwitchUL_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: NrDuCellIdxx, CommonCtrlResRbNumRB96;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: NrDuCellIdxx, RateMatchSwitchPDCCH_RATEMATCH_SW-0;同时把OccupiedSymbolNum从1SYMBOL改为2SYMBOLPDCCH占用的OFDM符号翻倍整个控制资源区域的CCE总数也跟着翻倍再把UlMaxCcePct设为50给上行CCE比例设定一个明确上限MOD NRDUCELLPDCCH: NrDuCellIdxx, UlMaxCcePct50, OccupiedSymbolNum2 Symbol;这三个参数是连锁关系。OccupiedSymbolNum从1到2之后CCE池子变大RateMatch关闭后不再有避让损耗UlMaxCcePct50保证上行忙时能从大池子里分到一半。单独调任何一个都出不来理想效果这也是这类问题在参数核查阶段最容易被当成“单个参数有优化空间”的原因实际要按组调。参数对象参数项调整前调整后作用NRDUCELLPDCCHPdcchAlgoSwitch关闭UL_DL_CCE_RATIO_ADAPT_SW-1上下行CCE比例自适应NRDUCELLPDCCHUlMaxCcePct默认50上行CCE占用上限NRDUCELLPDCCHOccupiedSymbolNum1 Symbol2 SymbolPDCCCH占用符号翻倍NRDUCELLCORESETCommonCtrlResRbNumRB48RB96公共CCE数量翻倍NRDUCELLPDSCHRateMatchSwitch开启PDCCH_RATEMATCH_SW-0关闭避让释放CCE4. 华为MML实操六条命令的顺序与每个参数背后的逻辑4.1 操作前准备与完整命令清单实际执行MML命令前有一个绕不开的坑先在华为网管上查小区对应的框号、槽位和NRDUCell实例。做5G网优的老手都遇到过这种情况按小区名搜索出来一条记录但这小区在一个多模基站的某块板卡上不先定位清楚框号就执行命令改错对象的后果比较难收拾。我一般的操作顺序是先用LST命令把小区对应关系确认好然后在夜间低峰窗口执行修改。正式修改建议逐条执行、逐条回查不要一次性复制多条命令进去后面出了问题不好定位是哪一条引起的。完整命令顺序整理如下REM 第1步打开上下行CCE比例自适应 MOD NRDUCELLPDCCH: NrDuCellIdxx, PdcchAlgoSwitchUL_DL_CCE_RATIO_ADAPT_SW-1; REM 第2步打开CCE比例自适应的辅助开关 MOD NRDUCELLRSVDEXT00: NrDuCellIdxx, RsvdSwParam1RSVDSWPARAM1_BIT14-1; MOD NRDUCellRsvd: NrDuCellIdxx, RsvdParam1491; REM 第3步Coreset0公共控制资源从48RB扩到96RB MOD NRDUCELLCORESET: NrDuCellIdxx, CommonCtrlResRbNumRB96; REM 第4步关闭PDCCH RateMatch释放PDCCH避让占用的CCE MOD NRDUCELLPDSCH: NrDuCellIdxx, RateMatchSwitchPDCCH_RATEMATCH_SW-0; REM 第5步PDCCH占用符号数改为2上行CCE比例上限设为50% MOD NRDUCELLPDCCH: NrDuCellIdxx, UlMaxCcePct50, OccupiedSymbolNum2 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这组错误码不再批量出现。无线接通率整体恢复到正常水平指标明显改善。指标优化前2月8日优化后3月10日说明无线接通率劣化至93%以下恢复至99%以上整体接通率回到正常区间RRC建立成功率随劣化趋势下行99%以上接入前半段恢复稳定QoS Flow建立成功率约92%约97%提升约5个百分点CHR CCE分配失败错误码频繁出现不再批量出现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命令和指标对比记录都可以直接拿去做模板希望帮到你。本文还有配套的精品资源点击获取