简介面向5G网络优化与无线通信领域这份阶段性小结完整呈现了2.1G FDD NR上行质切试点成果可帮助网络优化工程师深入理解基于上行SINR的5G到4G切换机制解决NR边缘覆盖下用户上行速率受限、切换策略不合理等问题。文档从功能原理出发介绍NR TDD上行受限时如何启动NG-RAN至E-UTRAN系统间移动性方案并梳理门限设置、45G互操作参数关联及防止乒乓切换的限制条件同时说明其分两阶段实现的流程即先通过持续测量识别弱覆盖用户再触发切换或重定向。试点选取无锡居民区进行深度覆盖测试对比上行SINR门限为3dB、0dB、-3dB、-5dB下的表现给出RSRP与上行速率关系数据例如3dB时大于2Mbps的采样占比为88.13%-5dB时降至81.12%为门限配置提供量化依据。整份成果集中于1份docx文档压缩包大小1.67MB结构紧凑、数据详实已有105人学习下载适合从事5G网络优化、移动通信运维和参数调优的技术人员查阅。1. 上行质切试点在2.1G FDD NR上的价值从“弱信号硬扛”到“主动交出去”做2.1G FDD NR网络优化的都知道一个反常现象用户看着信号满格上传却卡成PPT发个原图转三圈VoNR通话偶尔字字断断续续。原因在于FDD NR下行覆盖远、上行覆盖近终端发射功率就那么大上行链路预算撑不到小区边缘。传统切换看下行RSRP对“下行好、上行差”这一票用户基本失灵。上行质切就是专门治这个毛病的——基站检测到上行质量恶化主动把这个用户交到覆盖更好的异频NR小区。这个标题里的“阶段性小结”本质上是一次参数类试点的半程复盘触发了什么、门限怎么定、指标动不动、坑在哪。适合网优工程师、NR维护人员和做VoNR与上行业务的优化同行往下看。2. 为什么上行质切总在2.1G FDD NR做从FDD对称频段的覆盖鸿沟说起2.1 FDD上下行对称为什么上行先“瘸腿”FDD是频分双工上行和下行各占一段对称频谱2.1G NRn1频段下行在2110MHz附近、上行在1920MHz附近带宽对称资源分配上不存在TDD那种“时隙偏向下行”的问题。既然频谱对称为什么上行反而成了短板链路预算不站在终端这边。基站侧发射功率通常是40W甚至更高加上天线增益和接收分集下行等效功率能到50dBm以上而手机最高也就23dBm左右还贴着头握着天线效率打折。一来一回上行覆盖半径只有下行的六到七成。这个差距在2.1G上比在3.5G上更刺眼——因为2.1G本来就是用来做广覆盖和深度覆盖的边缘用户占比天然高。实际网络里这类用户长这样下行RSRP还在-100dBm附近晃下行体验勉强可用但基站侧收到的上行SINR已经掉到0dB以下上行MCS被压到QPSK那一档BLER飙上去HARQ重传一多时延和吞吐一起崩。更麻烦的是UE的发射功率已经顶到PmaxPHR报告到了下限基站就算想调度也调不动了。此时换成任何下行事件触发都不好使因为下行信号没到需要切换的程度。这就是上行质切能精确覆盖的场景——它不是替代下行切换而是在下行事件“装睡”的时候拉一把。2.1G FDD NR在国内现网里多数是作为5G覆盖主力频段存在的与3.5G、2.6G形成频段互补。这给上行质切提供了天然的落地条件边缘有异频NR小区可切。如果全网只剩一个频段质切只能切给同频邻区效果有限。所以这个试点标题叫“2.1G FDD NR上行质切”背后逻辑链是完整的频段定位决定了用户分布用户分布决定了上行瓶颈异频组网决定了切换路径。2.2 上行质切与普通切換的本质区别评估对象反过来了普通异频切换看的是终端上报的服务小区RSRP/RSRQ触发A3/A4/A5事件上行质切看的是基站侧测到的上行质量。两者评估对象完全不同——一个是手机告诉基站“我这里信号好不好”一个是基站自己测“我收到你的信号好不好”。基站测上行的途径主要有三种SRS探测参考信号、DMRS解调参考信号、以及上行数据信道的BLER统计。2.1G FDD NR场景下我一般建议用上行RSRP/SINR评估为主、上行BLER为辅原因是BLER波动大拿来做事件触发容易误判RSRP和SINR相对平稳。实现上并没有发明新信令它复用的是现有异频切换框架先配置一个“服务小区质量差”的触发条件再配上“异频邻区质量好”的判决条件。放在NR事件模型里就是A2事件联合B2事件——A2负责发现本小区上行质量变差B2负责确认目标频点上有没有更好的小区。事件本身是现成的变的是把A2的评估对象从上行的某些指标或下行RSRP换成了上行RSRP/SINR。这类配置通常由网优平台下发落到NR小区级参数组。关键点在于上行质切不是把下行切换干掉而是给下行切换打补丁。实操中两者同时存在质切门限一般设置得比下行切换更“急迫”保证上行快扛不住的时候先走。如果两个事件同时满足基站会优先执行更紧急的流程——这个优先级在部分厂家的参数表里是可调的后面第3章会展开讲。明白了这一层再看试点设计就不会跑偏它不是一个新功能验证而是一组门限参数在特定频段场景下的适配过程。2.3 一条上行质切的完整决策链从上行测量到切换执行把一条上行质切拆开实际走的路是六步第一步基站给UE下发异频测量配置和A2事件门限第二步基站持续测量UE的上行质量SRS/DMRS同时UE按周期上报下行RSRP第三步上行质量跌破A2门限基站判定“本小区救不了”第四步基站下发B2测量让UE搜异频邻区顺便查邻区表里小区类型为NR的候选目标第五步目标小区RSRP满足B2门限基站做切换判决还要做目标小区准入和负荷检查第六步下发切换命令UE切到目标小区完成RACH和RRC重配。整条链路里有两个环节最容易成为瓶颈。第一个是上行测量周期——基站侧的上行质量统计窗口如果拉太长质量已经崩了还在等数据触发就慢半拍。第二个是异频测量GAP——UE必须停掉当前频点的收发去异频测一次GAP配置不合理测量结果出不来B2判决就悬着。这两个瓶颈叠加起来切换时延可能从几百毫秒放大到一秒以上用户已经卡完一轮了。所以做这个试点时我一般会同时调整三组参数而不是只动一组门限触发侧A2门限和上行测量周期、判决侧B2门限和TTT、执行侧GAP配置和切换策略组。参数之间是联动的单独调一组只是把问题从一处挪到另一处。这也是为什么“阶段性小结”里最值得看的不是某个门限值而是三组参数组合之后的行为变化。3. 上行质切参数配置A2/B2门限、迟滞与触发时延怎么给3.1 触发侧参数A2门限和上行质量统计周期A2事件的定义是“服务小区质量低于绝对门限”在上行质切里这个“质量”被替换成上行RSRP或上行SINR。起始门限怎么给我一般先拉试点小区前两周的MR数据看边缘用户的RSRP分布和对应的上行SINR分布取上行SINR开始明显恶化的那个拐点作为A2门限的初值。工程上常见做法是上行RSRP门限取-115dBm到-120dBm之间SINR门限取-5dB到0dB之间。别直接照抄厂家默认值——厂家默认值照顾的是全国全网对你的小区未必合适。上行质量统计周期也需要一起调。基站侧统计上行质量的滑动窗口短了波动大触发频繁窗口长了反应慢切换滞后。通常滑动窗设在100ms到320ms之间配合A2事件触发时延一起工作。时延不能设太短否则上行质量稍微跳一下就去触发建议从320ms起步如果试点期内发现质差时长变短但乒乓变多就往上加到480ms。# 从网管导出的NR小区配置XML里核对上行质切相关参数以通用参数名为例 grep -E ulRsrpA2Threshold|ulSinrA2Threshold|a2TimeToTrigger|ulMeasWindow nr_cell_config_2p1g.xml | head -50这段命令的作用是把网管导出的小区配置文件里和上行A2触发相关的参数一次性筛出来。实际网管上可能叫别的名字比如华为的UL_RSRP_THD、中兴的UplinkA2Threshold但字段逻辑是等价的。先核对参数名再改值能防止“改了个寂寞”——不少同事直接在网管页面上改后来发现配置没生效原因就是字段名对不上。这里的“head -50”限制只看前50条因为整个XML里会有大量重复字段你只需要看第一个小区的一组配置就够了。参数说明ulRsrpA2Threshold是上行RSRP的绝对门限低于它就上报A2ulSinrA2Threshold是上行SINR的绝对门限两者是“或”的关系还是“与”的关系取决于厂家的实现但多数是“或”——任一指标过差就触发a2TimeToTrigger是A2上报前的持续时间等于给质量抖动加一个防抖器ulMeasWindow是上行质量统计的滑动窗口长度影响稳定性。3.2 判决侧参数B2门限、迟滞和切换策略组A2触发了不等于马上切基站还要确认目标小区“值得去”。B2事件包含两个门限一个是服务小区质量门限同A2类似但可以和A2独立设置另一个是异频邻区的绝对门限。2.1G场景下我一般把B2的邻区RSRP门限设在-110dBm左右原因是目标小区如果信号比这个还差切过去行体验不会好转只是换了个地方继续差。这个门限宁可设严一点也不要放太松——切到弱小区再切回来一次切换的费用就跑两次。迟滞hysteresis和CIO小区个体偏置是第二个控制维度。上行质切里迟滞通常给到2dB到4dB作用是不让测量值在门限附近来回穿越。CIO是按邻区对设置的比如某两个小区之间因为地形原因切换容易翻车可以单独给这对邻区加0.5dB到1dB的偏置。注意CIO是双向配置——从A小区到B小区加了偏置不代表B小区到A小区也会加回切方向要单独设。切换策略组这个参数容易被忽略。它决定的是“有多个异频邻区同时满足B2时到底选哪个”。常见做法是分成两步选第一步按RSRP筛掉不达标的第二步在达标的里面按负荷排序优先选负荷低于50%的小区。NR现网里不少小区忙时负荷能到70%以上如果不加负荷排序质切用户全涌向信号最好但负荷最满的小区切换成功率直接被准入失败拉低。注意切换策略组不是加一个参数就完事它和MLB移动负载均衡有交互后面第5章专门讲。3.3 执行侧参数GAP配置与测量周期的取舍异频测量需要GAPUE在GAP期间暂停当前频点的收发去测异频。GAP有两种配置方式周期40ms测量6ms或者周期80ms测量6ms。周期短测量结果来得快但GAP开销大边缘用户本来吞吐就低再被GAP切一刀体验更差周期长吞吐保住了但B2测量结果更新慢切换决策延后。2.1G FDD NR试点里我一般从周期40ms起步——质切本来就是救急场景牺牲一点吞吐换切换及时性是值得的。如果试点小区实测吞吐掉幅超过15%再考虑放宽到80ms。需要留意一个现实情况支持双接收或双连接的终端可以不配GAP做异频测量但2.1G FDD NR现网里有大量单收终端GAP躲不掉。判断终端支不支持可以看网管里的终端能力统计也可以在切换记录里看“测量时延”这个字段如果普遍超过80ms多半就是单收配了GAP。这个细节决定了你的切换时延预算是否现实——终端不支持的话B2上报天然慢别指望靠压TTT来提速。下表是这三组参数的起始基线具体试点时按小区场景微调。参数名采用通用叫法不同厂商网管上的实际名称会有差异但逻辑一一对应。参数组参数名通用起始基线值调整方向说明触发侧A2上行RSRP门限-115dBm乒乓多就抬高切不出去就压低触发侧A2上行SINR门限-3dB同上建议和RSRP门限联动调触发侧上行质量统计窗口200ms触发频繁就加大到320ms判决侧B2异频邻区RSRP门限-110dBm目标小区质量优先别放太松判决侧TTT触发时延320ms质差时延长就减到240ms判决侧迟滞3dB测量值在门限附近抖动就加大执行侧GAP周期/间隔40ms/6ms吞吐下降超15%改80ms/6ms执行侧目标小区负荷门限50%切换失败率高就往下压4. 试点执行与数据对比对照小区怎么选、指标盯哪几个4.1 试点小区选取卡好边界条件别让数据“脏”掉选试点小区不能拍脑袋找几个“信号差的小区”就上。我一般卡四个条件第一边缘用户占比高——从MR数据看RSRP低于-105dBm的用户占比超过15%否则触发量太少数据不足第二上行质差投诉集中——有真实的用户反馈做指引好过自己猜第三周边有同覆盖的异频NR小区——最好是有2.1G邻区或3.5G邻区覆盖同一片区域不然切都没得切第四目标小区非忙时负荷在50%以下避免把试点做成负荷迁移。同时满足这四条一个小区才值得进试点组。试点组和对照组的数量怎么配我一般按1:1配试点组10个小区左右对照组挑特征相似的小区——同频段、同覆盖场景比如都是城中村覆盖或者都是高速沿线、同厂家设备、近一个月指标量级接近。对照组唯一的要求是不动参数、不参与试点完全当“背景板”。对照组不是用来证明切换成功率比之前高了而是用来排除气候、节假日、周边割接等外部因素的干扰——对照组指标也跟着变说明是环境变了只有试点组变才能归因到参数上。# 从性能统计数据里筛出试点小区和对照小区的日均指标用awk聚合 awk -F, $1PILOT_CELL || $1CTRL_CELL { cell[$1]$2; total[$1] } END { for (c in cell) print c, cell[c]/total[c] } perf_daily_report.csv | sort -k2 -n这段awk脚本做的事是从每日性能统计CSV里按小区分组累加指标并求平均。实际使用时$1是小区标识$2是你要对比的指标列比如上行BLER百分比PILOT_CELL和CTRL_CELL是你预先写进脚本里的试点组和对照组小区标记。输出会按平均值排序方便快速看两组之间有没有拉开差距。注意CSV列顺序每个网管导出不一样跑之前先head一眼文件头。这个步骤的关键是保证统计口径一致试点组和对照组的数据必须来自同一时段、同一报表模板不能试点组用A表、对照组用B表否则算出来的差异全是口径差。我见过最典型的翻车就是试点组用新模板的BLER统计、对照组用旧模板的两组数值差了好几个点实际是分母定义不同。4.2 指标看板区分“切换前”和“切换后”别只看全天均值上行质切的指标评估有个常见错误只看试点小区的全天指标均值。均值会被大量不受影响的用户稀释边缘用户的改善根本看不出来。正确的做法是先圈定发生上行质切的用户然后比较同一个用户切换前一段时间和切换后一段时间的指标。时间窗我一般取切换前后各5秒——太长会掺入其他事件的影响太短覆盖不了一次业务交互。重点盯五个指标上行BLER切换前后均值对比、上行MCS分布QPSK占比降了多少、Ping时延RTT均值与抖动、切换成功率质切本身有没有切失败、RRC重建率切换过程有没有导致掉线。其中切换成功率和RRC重建率是两个“安全指标”——前者保证试点没把用户切坏后者保证试点没让用户掉线。如果营业指标BLER、MCS、时延变好了但RRC重建率上升了说明切换过程有瑕疵参数要回调不能为了效果牺牲稳定性。import pandas as pd # 读取上行质切切换记录按用户和时间排序后做前后对比 df pd.read_csv(qc_switch_records.csv, parse_dates[ts]) df df.sort_values([ue_id, ts]) # 取切换时刻前后各5秒的上行BLER采样 result [] for ue, grp in df.groupby(ue_id): evt grp[grp[event] UPLINK_QC_HO] if evt.empty: continue t_ho evt.iloc[0][ts] before grp[(grp[ts] t_ho - pd.Timedelta(seconds5)) (grp[ts] t_ho)][bler].mean() after grp[(grp[ts] t_ho) (grp[ts] t_ho pd.Timedelta(seconds5))][bler].mean() result.append({ue_id: ue, bler_before: before, bler_after: after}) out pd.DataFrame(result) print(out[[bler_before, bler_after]].describe())这段Python脚本做的是按用户维度切分切换事件对比切换前后各5秒的上行BLER均值。核心逻辑是先用groupby按用户分组找到该用户发生的上行质切事件时间点然后各取前后5秒窗口计算均值最后用describe()看整体分布差异。注意事件字段名UPLINK_QC_HO要按网管实际导出值改如果网管导出的切换记录里没有区分质切和普通切换就要靠切换原因字段过滤。效果判断看两个维度均值变化说明整体状态好了多少5%分位和95%分位的变化说明边缘最差的用户有没有被捞起来。有时候均值改善不明显但95%分位大幅下降说明受益的是原来最惨的用户这种照样是有效果的——别只拿均值下结论。4.3 数据回填与“阶段性小结”的输出结构试点的每个参数调整动作都要留痕。我一般维护一张变更记录表列五列变更时间、小区组、参数项、原值、新值。这张表是你阶段性小结的骨架也是将来回退参数的后悔药。没有这张表两周后想复盘某个参数当时的改动理由全都靠回忆等于没有复盘。阶段性小结的正文最好像这样组织先写试点目标解决什么现象、预期改善什么指标再写试点范围选了哪些小区、对照组怎么设然后写参数变更记录一张表列清楚改了什么为什么改接着写指标对比结果对照组和试点组的关键指标变化附上面那种前后对比的数据最后写下一步计划哪些参数要调整、要不要扩大试点范围。注意别写“效果显著”这种没有数据支撑的话拿BLER、MCS分位数说话即可。5. 避坑手册上行质切试点里最常见的5个翻车现场每一项都是试点里真会踩到的坑按“现象→原因→解决”的格式写。新手照着避熟手也建议看一眼——参数联动的坑往往在扩大试点时才会爆出来。5.1 乒乓切换用户在两小区之间来回横跳RRC重建率飙升现象试点组小区切换次数比对照组高了三倍以上切换记录里能看到同一个用户几十秒内先切出再切回再切出再切回。上行BLER没有明显好转RRC重建率反而从0.5%涨到1.5%。原因A2门限设得过于“激进”上行质量稍微一抖就触发加上TTT太短比如160msB2门限两侧都满足切换没有迟滞保护。还有一个常见诱因是回切参数没配置用户切到目标小区后马上又触发回切两个小区互相“踢皮球”。解决把TTT从160ms调回320ms以上上行质量统计窗口加大到320ms给切换对的两个小区配置CIO偏置让切出去比切回来更难检查回切方向的事件门限确保目标小区的回切触发条件和源小区的切出条件之间有足够间隔一般建议至少5dB。配置改完后观察24小时内的切换次数曲线乒乓周期通常是分钟级的当天就能看到收敛。5.2 质差用户切不出去A2门限比实际质量分布还低事件永远不触发现象试点组的上行BLER并没有变化翻切换记录发现上行质切事件次数接近于零。有些质差用户上行SINR都到-8dB了依然没有触发切换。原因A2门限定得太保守。比如设了SINR门限-10dB但试点小区实际用户里最差的也就到-6dB门限形同虚设。门限值没有先看数据分布就拍脑袋设是经典翻车姿势。解决拉出试点小区两周MR数据统计上行SINR的累计分布取5%分位点作为A2门限的起点——意思是最差的那5%用户得能触发。例如5%分位点是-4dBA2门限就设在-4dB附近而不是-10dB。改完后再看触发量如果一天触发少于50次门限继续宽松1dB。5.3 目标小区负荷被打满切换成功率掉用户反而更快现象切换成功率从99%掉到95%以下网管上查目标小区准入失败次数增加忙时目标小区负荷从40%顶到90%以上。用户切过去后速率并没有变好因为新小区也满了。原因切换策略组里只按RSRP选目标小区信号最好的那个被所有人选中负荷直接打爆。这本质上是把覆盖问题变成了负荷问题。解决在切换策略组里把负荷排序加上目标小区负荷超过50%时自动选次优小区如果厂家参数不支持负荷排序就靠人工调整——把高负荷目标小区的CIO压低1dB让部分用户自然流向第二候选。更稳的做法是配合MLB做联动让质切触发的同时负荷均衡也跟着转移这需要协调两个功能模块的优先级。5.4 异频测量报告迟迟不来GAP配置和终端能力不匹配现象A2触发了但切换命令迟迟不下发从触发到切换完成的时延超过1秒。上行吞吐和时延反而比试点前更差。原因UE是单收终端异频测量依赖GAP而GAP配置周期太长比如80ms周期加上B2测量要等下一个GAP窗口来回一算就几百毫秒。部分老终端还有测量能力上报问题网管配了GAP但终端没按预期执行。解决先把GAP周期改到40ms观察切换时延分布一般能砍掉一半。改完GAP后必须做一次吞吐测试确认GAP开销没有把上行速率吃掉太多。如果时延还压不下来抓一次终端日志看测量上报是否正常——顺带说一句终端日志是个黑匣子能不开就不开开了就要一次抓够。5.5 参数被SON功能回改配置白天生效、晚上被覆盖现象上午改完参数下午查询配置发现被改回去一部分试点数据断档。网管告警里能看到CCO或ANR模块的自动调整记录。原因试点小区还在SON自优化网络的管辖范围内CCO覆盖和容量优化检测到“覆盖异常”就自动改了你的门限参数或者ANR调整了邻区关系把B2的候选小区删了。试点参数和SON目标打架系统按自己的逻辑“纠正”了你。解决试点期间把试点小区从CCO和ANR的自动调整范围里暂时剔除或者把相关参数锁定为“人工维护”。这个操作要在网管上单独申请权限注意剔除后要人工盯邻区关系的健康度别把ANR的活全停了结果漏配了邻区也不知道。试点结束确认参数基线后再把小区还给SON并将新的门限值同步到SON的基线库里免得恢复后又被改走。6. 阶段性小结的进阶用法把试点参数沉淀成可复用的配置基线阶段性小结写完不是终点真正有价值的是把它转成参数基线。推进方法很简单把试点小区里表现好的参数组合整理成“场景-门限”对照表再按地理场景套用到其他小区。比如城中村覆盖和高速沿线覆盖的A2门限就不该用同一个值——城中村用户密集、邻区多TTT要放大防乒乓高速场景用户移动快TTT要适当缩短、GAP周期要短不然切换追不上车速。基线的验证也有讲究。新场景下发时先跑一周回看三个关键指标切换次数是否落在管线区间内、RRC重建率有没有上升、上行MCS的QPSK占比有没有下降。任何一个指标爆了都要回到参数表逐项排查。我还养成了一个习惯任何试点参数都先写回退方案再下发出问题五分钟内恢复到上一版。有一轮试点只盯着切换成功率没看重建率直到扩大试点才暴露问题还好回退方案是现成的几分钟就救回来了。从那以后参数基线的第一步永远不是“怎么调”而是“怎么退”。希望帮到你。本文还有配套的精品资源点击获取