ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

2.6G低速率小区优化实战:从判定标准到NR参数调优落地

2.6G低速率小区优化实战:从判定标准到NR参数调优落地 简介一份面向网络优化工程师的《2.6G低速率小区优化》专题文档聚焦上行低于2Mbps、下行低于100Mbps且连续七天满足工作日与周末门限的小区识别和性能提升。文档先给出低速率小区判定标准随后按商用参数基线逐项核查现网配置围绕上行256QAM开关、上下行CCE配比自适应、SRS与PMI权自适应、PUSCH/PUCCH功控、MU-MIMO配对、下行Rank自适应和邻区CSI-RS干扰避让等27个关键参数对比默认值与商用场景推荐值并注明32T/64T等设备形态的适用建议。整个资源为1个docx文件压缩包约101KB结构清晰适合从事4G/5G网络优化、参数策略配置及KPI攻关的工程师参考。目前已有136人学习下载读者可获取低速率小区判定标准、27个关键参数的默认值与推荐值对照以及不同设备形态下的开关设置建议方便逐项核对现网参数基线直接用于低速率小区整治和上下行速率提升方案落地。1. 从“两天工作日一个周末”说起2.6G低速率小区到底怎么判定的早上打开网管看到一张表几十个小区被打上“2.6G低速率”的标签。很多人第一反应是“覆盖不行”“干扰大”但真要动手优化第一步不是猜原因而是把定义搞清楚。2.6G低速率小区的判定标准是上行低于2Mbps、下行低于100Mbps取连续7天数据5个工作日中出现2天及以上低速率且2个周末中出现1天及以上低速率才算数。这套规则卡的其实是“稳定性”——偶尔一天速率低可能是突发干扰但连续工作日出问题基本能说明小区存在系统性短板。这份《2.6G低速率小区优化》讲的就是从识别到参数落地的一整套打法适合后台网优、参数规划以及一线投诉处理的同事。下面按“先基线、再专项、后避坑”的顺序过一遍。2. 先过基线核查这关九个关键开关与上下行吞吐的底层逻辑2.1 为什么是“先基线后专项”低速率小区的共性病灶基线核查是这份优化文档里的第一优先级动作。商用参数基线是集团针对现网场景下发的一套标准配置现网参数如果跟基线不一致哪怕只差一个开关上下行速率都会受影响。低速率小区里相当一部分不是覆盖问题而是参数配置走了样。底层逻辑有三点。第一256QAM是速率天花板上行不开256QAM调制阶数停在64QAM速率上限直接锁死下行同理。第二SRS是信道估计的眼睛SRS周期太长或自适应关闭基站拿到的信道信息就滞后波束赋形和MU配对都会打折。第三功控是双刃剑发功太低远点用户解调失败发功太高干扰抬升整网一起遭殃。所以优化动作必须从基线核查开始而不是一上来就调切换门限、改功控参数。先让现网回到“标准状态”再谈针对性优化。我经手的低速率小区里差不多有三成是“改完基线开关速率就恢复了一半”连专项优化都不用做。这就是基线冗余的价值。2.2 一张表看懂九个关键开关调制、SRS与功控参数 MO参数名称默认值商用场景推荐值作用说明NRDUCELLALGOSWITCHUl256QamSwitchUL_256QAM_OFFUL_256QAM_FIXED开启上行256QAM提高上行调制阶数NRDUCELLALGOSWITCHDl256QamSwitchOFFON开启下行256QAM提高下行峰值速率NRDUCELLPDCCHUL_DL_CCE_RATIO_ADAPT_SWoffon上下行CCE配比自适应提升CCE利用率NRDUCellSrsUSER_CHARACTER_SRS_ADAPT_SW视场景低速低频TDD开启基于用户特征自适应SRS周期NRDUCellAlgoSwitchDL_PMI_SRS_ADAPT_SWONON下行SRS权与PMI权自适应NRDUCELLULPCCONFIGPUCCH_OUTER_LOOP_SW11上行PUCCH外环功控NRDUCELLULPCCONFIGPUCCH_INNER_LOOP_SW11上行PUCCH闭环功控NRDUCELLALGOSWITCHDL_SU_MULTI_LAYER_SWonon下行单用户多流开关NRDUCELLALGOSWITCHUL_MU_MIMO_SW / DL_MU_MIMO_SW0132T/64T建议开启PUSCH/PDSCH配对开关这九个开关是基线核查的重点。Ul256QamSwitch和Dl256QamSwitch决定了调制阶数天花板不开256QAM小区速率再优化也到不了预期CCE配比自适应解决的是重载场景PDCCH资源分配问题SRS相关开关直接影响信道估计质量进而拖累MU配对和波束赋形功控开关则决定了远点用户能不能发够功率。另外还有几个Rank相关参数也属于基线调整范围DlRankAdaptLayerGapThld默认15改13DlRankAdaptSpctEffCoeff默认8改14Rank2/3抬升频谱效率门限从1改成1095Rank3/4下调门限从1改成10150。这套参数的作用是让Rank自适应更激进在信道条件允许时尽量往Rank2/3抬。改完后看下行平均Rank和IBLER如果IBLER上去了说明抬过头要回调。2.3 基线核查执行清单导出、比对、下发三步操作分三步走。第一步导出现网配置用网管MML命令把相关参数捞出来。我一般用以下命令批量导出// 导出小区算法开关相关参数 LST NRDUCELLALGOSWITCH:; // 导出上行功控参数 LST NRDUCELLULPCCONFIG:; // 导出下行Rank相关参数 LST NRDUCELLDLRANK:; // 导出PDCCH相关参数 LST NRDUCELLPDCCH:;这几条命令会把整站所有小区的算法开关、功控参数、Rank参数、PDCCH参数全部列出来。实际执行时建议加上小区过滤器比如LST NRDUCELLALGOSWITCH:NrDuCellId1001;避免一次性输出几百条结果看花眼。第二步拿导出的配置跟集团商用基线表逐一比对。重点对256QAM开关、SRS自适应开关、CCE配比自适应、功控开关这几类找出所有“非基线”配置项。比对的时候注意有些参数是枚举值比如AGGLVL8、AGGLVL_16有些是开关值0/1格式别弄混。第三步对不符合基线的参数做修改典型命令如下// 上行256QAM固定开启 MOD NRDUCELLALGOSWITCH: NrDuCellIdxx, Ul256QamSwitchUL_256QAM_FIXED; // 下行256QAM开启 MOD NRDUCELLALGOSWITCH: NrDuCellIdxx, Dl256QamSwitchON; // 上下行CCE配比自适应开启 MOD NRDUCELLPDCCH: NrDuCellIdxx, PdcchAlgoSwitchUL_DL_CCE_RATIO_ADAPT_SW-1; // 下行单用户多流功率控制开关 MOD NRDUCELLALGOSWITCH: NrDuCellIdxx, DL_SU_MULTI_LAYER_PWR_CTRL_SWSuMimoMultipleLayerSw1;参数说明NrDuCellId是小区ID实际操作时替换成具体小区号UL_256QAM_FIXED是固定开启256QAMPdcchAlgoSwitch里的-1表示开关打开-0表示关闭。整套命令可以在网管批量执行但一定要在业务低峰期操作。下发完至少观察24小时确认无掉话率恶化、无RRC重建率异常再进入下一阶段。注意LST查完再MOD不要直接MOD有些参数在部分版本里不支持直接改会报错。3. 上行速率优化实操256QAM、功控调优与波形自适应3.1 上行256QAM不是开了就完事SRS自适应与信道质量上行256QAM的开关值有两个UL_256QAM_OFF和UL_256QAM_FIXED。固定开启后上行调制阶数提到256QAM理论上单流峰值速率能提升约33%。但256QAM对信道估计质量要求很高SRS SINR不够的话开满反而会因为MCS误判导致BLER上升速率不升反降。所以文档里在开启256QAM的同时要求把基于用户特征的SRS自适应开关USER_CHARACTER_SRS_ADAPT_SW打开低速低频TDD场景尤其明显。原理是低速用户信道时变慢SRS自适应可以把周期拉长降低导频开销把资源让给数据信道高速用户则缩短周期保持信道跟踪精度。这套机制能保证SRS SINR稳定256QAM才开得稳。// 开启上行256QAM MOD NRDUCELLALGOSWITCH: NrDuCellIdxx, Ul256QamSwitchUL_256QAM_FIXED; // 开启基于用户特征的SRS自适应与老架构SRS_PERIOD_ADAPT_SW互斥 MOD NRDUCELLSRS: NrDuCellIdxx, SrsAlgoSwitchSRS_PERIOD_ADAPT_SW-0USER_CHARACTER_SRS_ADAPT_SW-1;这里有个细节SRS_PERIOD_ADAPT_SW是老的SRS周期自适应开关和新架构USER_CHARACTER_SRS_ADAPT_SW互斥必须先把老的关掉否则新架构起不来。SRS新架构还有配套的干扰协调开关SRS_INTRF_COORD_S_SLOT_SW-1和17倍频分SrsWideBandIndexCsrs63这两个属于降干扰的进阶操作低速率小区可以一并打上但建议先确认设备版本支持。3.2 上行功控调优中点降功率关不关先看RSRP分布上行功控里最容易翻车的是中点降功率开关PUSCH_MIDPOINT_RP_SW。默认是on中点用户要降功率发送。逻辑是防干扰但对低速率小区来说中点用户降功率意味着MCS上不去上行感知速率被压住。文档给的数据很实在杭州验证关闭中点降功率后上行感知速率提升11%但上行干扰恶化1.3dB。这个代价能不能接受取决于小区底噪和用户分布。判断依据是PUSCH RSRP低于-120dBm的用户比例话统指标N.UL.PUSCH.RSRP.Index0-11是否高于30%。高于30%说明远点用户多关掉中点降功率、让远点用户发功抬升收益大于干扰损失远点用户少的小区关了反而白挨干扰。// 关闭中点降功率配置非基线 MOD NRDUCELLULPCCONFIG: NrDuCellIdxx, UlPwrCtrlAlgoSwitchPUSCH_MIDPOINT_RP_SW-0; // 打开PUSCH近点功率保护开关 MOD NRDUCELLULPCCONFIG: NrDuCellIdxx, UlPwrCtrlAlgoSwitchPUSCH_NEARPOINT_PWR_PROTECT_SW-1;近点功率保护的目的是保住近点大包用户的峰值速率和关闭中点降功率是配套动作。下发后要盯上行干扰如果平均干扰抬升超过1.5dB建议回退或用PUSCH降干扰方案替代。PUSCH降干扰就是把PO值整体压下来PoNominalPusch-43、PoSrs-43、PuschRsrpThld-86、NearPointPuschSinrThldOfs4。文档给的验证效果是上行平均干扰下降0.32dB用户上行平均感知速率提升18%。注意PuschRsrpThld建议最低用-86设置太低终端发功会异常反而影响上行速率。// PUSCH降干扰参数下发 MOD NRDUCELLULPCCONFIG: NrDuCellIdxx, PoNominalPusch-43, PoSrs-43, PuschRsrpThld-86, NearPointPuschSinrThldOfs4;3.3 上行波形自适应远点用户用DFT-S-OFDM但小心TOP终端上行波形自适应UL_WAVEFORM_ADAPT_SW是文档里标注“上行低速率小区均可以开启”的开关。原理不复杂远点用户上行改用DFT-S-OFDM发送相比CP-OFDM发射功率能抬升上行覆盖和速率都受益。这对上行受限的小区是直接补强。坑在于不按协议上市的TOP终端可能不兼容导致小区掉线率恶化。所以集团要求配套黑名单。文档里给的示例是Redmi Note 10 pro的特征值。黑名单命令要保证UeInfoIndex没被占用否则白名单不生效。// 打开上行波形自适应 MOD NRDUCELLALGOSWITCH: NrDuCellIdxx, AdaptiveEdgeExpEnhSwitchUL_WAVEFORM_ADAPT_SW-1; // 配置波形选择SINR门限 MOD NRDUCELLPUSCH: NrDuCellIdxx, SinrThldforWaveformSel100; // 添加终端特征值 ADD GNBUEINFO: UeInfoIndex3, UeInfoTypeUE_FEATUREVALUE, UeFeatureValueContentec7fee769ff7e0fff0, UeFeatureValueMaskFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF, UeTypeDescRedmi Note 10 pro; // 下发黑名单控制 ADD GNBUECOMPAT: UeInfoIndex3, BlacklistCtrlSwitchUL_WAVEFORM_ADAPT_SW_OFF-1, ParamCtrlTypeTYPE_TDD;参数说明SinrThldforWaveformSel100是触发波形选择的SINR门限配置成100基本等于“所有远点用户都切成DFT-S-OFDM”。黑名单两条命令必须成对下发UeInfoIndex要一致而且不能跟现网已有的Index冲突——不同Index同时存在时系统会先生效Index小的那个冲突了黑名单就白配了。另外执行波形自适应后RRC重配次数会增多掉线率有恶化风险建议分批次开启先开一个小区的试点。4. 下行与重载场景优化CCE利用率、MU配对与RANK调优4.1 重载场景CCE优化上行多调一、比例自适应与节流重载场景下速率起不来很多时候是PDCCH的CCE不够用了。调度器要发DCIDCI要占CCECCE被占满后面的用户就排不上队速率自然上不去。文档里给了三个组合拳PDCCH上行多调一、上下行CCE比例自适应、CCE节流。上行多调一DCI_EXTEND_UL_CONGEST_SW-1的含义是用更多的下行子帧资源去调度上行相当于给上行调度借资源。代价是涉及在线用户k1、k2值空口重配远点差用户有掉话风险。上下行CCE比例自适应UL_DL_CCE_RATIO_ADAPT_SW-1则根据上下行DCI实际发送需求动态分配CCE比例重载时把上行CCE最大占比提到60%。CCE节流则是通过降低聚合级别来提升CCE利用效能。// 上行多调一 MOD NRDUCELLPUSCH: NrDuCellIdxx, UlPuschAlgoSwitchDCI_EXTEND_UL_CONGEST_SW-1; // 提升上行CCE最大占比至60% MOD NRDUCELLPDCCH: NrDuCellIdxx, UlMaxCcePct60; // 上下行都重载时按比例优化CCE MOD NRDUCELLPDCCH: NrDuCellIdxx, HeavyLoadUlCceAdjPolicyRATIO_OPT; // 上下行CCE比例自适应开启 MOD NRDUCELLPDCCH: NrDuCellIdxx, PdcchAlgoSwitchUL_DL_CCE_RATIO_ADAPT_SW-1; // 不使用PUSCH DTX做PDCCH外环降低CCE开销 MOD NRDUCELLPDCCH: NrDuCellIdxx, PdcchAlgoEnhSwitchPUSCH_DTX_AGG_LVL_ADAPT_SW-0; // PDCCH边缘功控基于CSI上报限制最大聚合级别 MOD NRDUCELLPDCCHALGO: NrDuCellIdxx, PdcchEdgePwrCtrlPolicyBASED_ON_CSI_RPT, PdcchMaxAggLevelAGG_LVL_8_16_ADAPT; // PDCCH连续3次DTX只调1阶 MOD NRDUCELLPDCCH: NrDuCellIdxx, PdcchAlgoEnhSwitchPDCCH_AGG_LVL_OPT_SW-1; // PDCCH聚合级别自适应策略 MOD NRDUCELLPDCCH: NrDuCellIdxx, PdcchAggLvlAdaptPolSEPARATE_ADAPT;这些命令不要一次性全下发。建议先开比例自适应观察CCE分配失败率有没有下降同时盯掉线率变化再逐步上节流组合。PdcchAggLvlAdaptPolSEPARATE_ADAPT是把上行和下行聚合级别分开自适应比JOINT_ADAPT更灵活但对覆盖差的边缘小区要谨慎聚合级别太低会放大PDCCH漏检。PDCCH边缘功控策略BASED_ON_CSI_RPT相比BASED_ON_AGG_LVL是把功率倾向前导质量好的用户重载场景收益最明显。4.2 MU-MIMO参数拉齐基线轻载无效重载才见真章MU-MIMO是低速率小区优化里“看起来很美”的部分。文档里明说“轻载无明显变化”这类参数的价值在重载高负荷场景才体现。所以别指望改完MU参数轻载小区速率就飞起来重点是拉齐基线、等重载场景验证。先拉齐基线UL_MU_MIMO_SW和DL_MU_MIMO_SW从0改成132T/64T建议开启。然后配套参数一起上。// 开启PUSCH配对开关 MOD NRDUCELLALGOSWITCH: NrDuCellIdxx, UL_MU_MIMO_SWMuMimoSwitch1; // 开启PDSCH配对开关 MOD NRDUCELLALGOSWITCH: NrDuCellIdxx, DL_MU_MIMO_SWMuMimoSwitch1; // DMRS配置为TYPE1 MOD NRDUCELLPDSCH: NrDuCellIdxx, DlDmrsConfigTypeTYPE1; // 时域相关性低的用户参加MU配对 MOD NRDUCELLPDSCH: NrDuCellIdxx, DlLowTimeCorrMuSwON; // 下行MU/SU自适应 MOD NRDUCELLDLMIMO: NrDuCellIdxx, DLMuMimoSchSupplementSwDL_SE_SU_MU_MIMO_ADAPT_SW; // 上行MU生效RB比例门限 MOD NRDUCELLULMIMO: NrDuCellIdxx, MuRbRatioThld40;参数说明DlDmrsConfigTypeTYPE1是为了避免下行导频TYPE1/2冲突导致无法配对。DlLowTimeCorrMuSwON是让时域相关性低的用户也参与MU配对流程这个开关在32T/64T下强烈建议打开文档原话是“该项会严重影响高负荷场景下行MU配对率”。下行MU/SU自适应让系统在MU和SU之间动态切换比固定MU更稳。注意DMRS Type改动会影响现网所有配对行为需要跟邻区协同拉齐不然会互相干扰。4.3 室分2T小区RANK调优RI虚高怎么破室分2T小区有个典型问题单路覆盖一根天线被遮挡或馈线接反终端上报RI虚高以为信道能支持Rank2/3但实际SINR根本扛不住结果下行MCS被拉低、IBLER偏高用户感知速率反而差。这个现象在室分场景很常见而且很难通过常规干扰排查发现。文档给的方案是打开基于SRS功率差值选择Rank的开关SRS_DIFF_BASED_RANK_SELECT_SW-1同时把下行Rank自适应流间差异门限从默认15改到20。这样当天线间功率差明显时网络主动压Rank宁可单流也要保住MCS。// 打开基于SRS功率差值选择Rank开关 MOD NRDUCELLALGOSWITCH: NrDuCellIdxx, RankSelectAlgoSwSRS_DIFF_BASED_RANK_SELECT_SW-1; // 流间差异门限放宽到20dB MOD NRDUCELLDLRANK: NrDuCellIdxx, DlRankAdaptLayerGapThld20;这里门限的单位是dB20dB意味着SRS功率差达到20dB才降Rank比默认15更保守。改完后话统里下行平均RANK会下降但用户下行感知速率会提升这属于“指标下降但体验变好”的反直觉优化。如果直接固定Rank1速率基本持平无恶化风险但灵活性差不建议作为首选。另外室分低速率还要查CSI配置。如果室分和宏站CSI资源没对齐宏站的CSI-RS信号会干扰室分小区导致slot0/slot10高误码。整改方案2T/4T/8T的CSI周期配置为SLOT10、CSI资源数1个32T/64T配置为SLOT40、资源数4个。// 2T/4T/8T小区CSI周期SLOT10资源数1 MOD NRDUCELLCSIRS: NrDuCellIdxx, CsiPeriodSLOT10, CsirsCellResourceNum1_RESOURCE; // 32T/64T小区CSI周期SLOT40资源数4 MOD NRDUCELLCSIRS: NrDuCellIdxx, CsiPeriodSLOT40, CsirsCellResourceNum4_RESOURCE; // 8T小区开启邻区CSI-RS干扰避让 MOD NRDUCELLCSIRS: NrDuCellIdxx, NCellCsirsIntrfAvoidP_CELL;5. 避坑指南参数下发顺序与KPI恶化的血泪经验5.1 现象PUCCH RB自适应一改小区直接重建有天凌晨我按参数表下发MOD NRDUCELLPUCCH: PUCCH_RBRES_ADAPTIVE_SWITCHPucchAlgoSwitch1命令执行成功但小区随即自动重建正在进行的业务全部中断。原因是PUCCH RB自适应参数修改涉及PUCCH资源配置重算系统触发小区重建来加载新配置。这个坑在文档里写得很清楚“参数修改会导致小区自动重建切记一定要凌晨规范操作”。从那以后凡是PUCCH相关的RB自适应调整我都提前看告警确认凌晨两点之后再动下发后马上盯小区状态重建完成再验证参数是否生效。5.2 现象上行波形自适应白名单下发后不生效按文档配了Redmi Note 10 pro的黑名单过了两天发现终端还在用CP-OFDM发送上行速率没改善。查了一圈问题出在UeInfoIndex上。现网已经有Index3的特征值系统按Index从小到大生效导致新配的黑名单没进去。解决方法是执行前用LST GNBUEINFO确认要用的UeInfoIndex没被占用两条命令的UeInfoIndex必须一致否则黑名单控制开关找不到对应特征值。文档里有句备注特别关键“要确保上面的两个UeInfoIndex现网没有用过不然会先生效Index低的导致配下去也没用。”把这个习惯固化到流程里之后再没翻过车。5.3 现象关闭中点降功率后上行干扰平均涨了1.3dB按参数基线把PUSCH_MIDPOINT_RP_SW从on改成off上行感知速率确实涨了11%但话统里上行平均干扰从-112dBm涨到-110.7dBm旁边小区的上行速率跟着掉。原因就是关闭中点降功率后中点用户发功偏高对邻区造成干扰抬升。这里有个判断条件下发前先看N.UL.PUSCH.RSRP.Index0-11PUSCH RSRP-120dBm的用户比例高于30%才建议关。如果干扰敏感改用PUSCH降干扰方案PoNominalPusch-43替代既保远点用户速率又能控制干扰。如果客户更关注上行感知速率可以降低RSRP门限选小区但务必在方案里写清干扰恶化风险。5.4 现象2.6G和700M同时调异频切换门限结果出现乒乓2.6G侧把A1门限调到-100、A2门限调到-104700M侧只调了A5结果用户在两个频段之间反复切换掉线率没改善反而增加。原因是A1/A2/A5门限不匹配触发条件重叠。文档里有句提醒很到位“调整时700M与2.6G同时调整防止出现乒乓”。集团给的参数范围2.6G的A1门限-100~-90、A2门限-105~-95、A5触发门限1为-113~-108、触发门限2为-108~-90700M侧对应为-100~-90、-105~-95、-100~-90、-110~-106。每改一组都要检查覆盖切换统计里的乒乓比例2.6G和700M成对看不能各调各的。6. 效果验证三板斧从话统KPI反推优化是否到位6.1 先看平均感知速率与MCS分布优化效果最直观的验证是第一板斧对比优化前后的小区用户平均感知速率。上行看小区用户上行平均感知速率下行看小区用户下行平均感知速率。同时打开MCS分布话统看MCS是否整体右移。如果速率提升但MCS分布纹丝不动说明速率提升来自调度次数增加或重传减少MCS本身没提上去还有进一步优化空间。6.2 再看干扰与掉线率第二板斧是看干扰和掉线率。上行平均干扰电平有没有抬升掉线率、RRC重建率有没有恶化。关闭中点降功率、PUCCH功控参数优化都会影响干扰所以验证时必须把干扰电平一起看。如果干扰抬升超过1.5dB即使速率涨了也要评估是否值得。6.3 最后看用户分布与TA第三板斧是看用户分布和平均TA。平均TA大于20说明存在越区覆盖和超远覆盖建议先下压电倾角如果电倾角已经超过9度SSB功率偏置回退为-3。这部分属于覆盖层面的收尾验证参数再完美覆盖不合理速率也保不住。从那以后我每次做完低速率小区优化都强制走一遍“先基线、再专项、后验证”的流程三个指标一起看缺一不可。尤其是列表里那些标着“配置非基线”的参数每个都记录下发时间、下发前指标、下发后指标宁可多花半小时标记也不等出了问题再回头查。希望帮到你。本文还有配套的精品资源点击获取
返回列表