5G SA性能优化实战：从无线接通率到掉话率排查指南

简介这是一份华为5G SA独立组网模式的性能优化指导手册主要面向5G网络优化与运维工程师系统梳理无线接通率、掉线率等关键KPI从接入性、移动性、保持性三个维度定位性能问题帮助保障5G网络稳定运行与用户体验。手册围绕小区接入性能给出完整排查流程先查操作日志与告警再做参数核查如SSB周期、SIB1周期、最小接收电平、前导传输次数等并排查射频通道与上行干扰同时针对空口未发起RRC_CONN_REQ、随机接入失败、RRC建立失败、NGSig建立异常四类典型场景给出原因分析与处理路径还涵盖核心网NAS过程异常的联合定位方法。资源包为1个docx格式文档大小2.32MB内容结构清晰、表格丰富可直接作为日常优化工作的参考模板。目前已有470人学习下载适合需要系统掌握5G SA性能问题分析和优化手法的网络技术人员。1. 一份 SA 性能手册能省掉多少现场返工SA 商用测试跑完真正让人头疼的不是测不到数据而是指标掉下来之后不知道该从哪一层下手。这份华为 5G 性能优化指导手册-SA 文档做的就是这件事把接入性、保持性、移动性、小区数传能力这几个维度拆成可以照着执行的规定动作从话统 Counter 一直追到参数和告警。它适合已经上手过 U2020/M2000 网管、能读懂 Probe 或信令跟踪的无线优化工程师也适合刚接触 SA 单模、想知道掉话率恶化时先看哪几个指标的维护人员。手册本身不是操作指导书它给的是一套排查顺序和指标关联逻辑用得好能少跑几趟站点用不好就变成挨个参数瞎改——差别就在你有没有按它的路子先做隔离。2. 接入性排查从无线接通率公式拆到四类失败分支SA 组网下终端接入 5G 网络涉及 RRC 连接、NG 接口逻辑信令连接、QoS Flow 建立三个环节任何一个环节掉链子都会拉低无线接通率。手册把接入问题分成规定动作和定位思路两层规定动作是让你把日志、告警、参数、射频通道过一遍定位思路是按失败点往细分支。这两层不能颠倒先做规定动作能排除掉大量非无线原因避免一上来就盯空口。2.1 无线接通率的三个乘数怎么拆无线接通率的公式是三个环节成功率的乘积RRC 连接建立成功率、Flow 建立成功率、NG 接口 UE 相关逻辑信令连接成功率。这种连乘结构有个特点——任何一个环节成功率下滑都会等比例拉低总值但话统里未必能一眼看出是哪个环节。实际取值时我一般会先把三个分项成功率各自拉出来看趋势而不是只看合成后的无线接通率。如果三个分项都在同一时间点恶化那大概率是有共同的外部原因比如站点批量改造、传输抖动或者核心网侧调整如果只有一个分项掉了问题就在那个环节特有的流程里。RRC 连接建立成功次数和请求次数可以从话统里直接取Flow 建立和 NG 逻辑信令的部分要注意统计口径是不是覆盖了切换入的场景。手册里把 NG 接口 UE 相关逻辑信令连接的建立成功与请求次数单独列出来就是为了把核心网侧的失败和基站侧的失败分开。常见做法是先按小时粒度拉一周数据对齐问题时间点再看恶化是突发的还是缓慢的。2.2 规定动作操作日志、告警、参数、射频四项规定动作的价值在于顺序。很多人一看到接通率掉了就去翻参数其实应该先看操作日志和告警因为这两项能快速证伪。操作日志主要排查问题时间点之前有没有做过影响接入的操作比如小区闭塞、NG-C 链路改动、AAU 通道校正规避。判断方法很直接——把问题时间点和操作时间点做相关性比对如果每次指标恶化前几十分钟都有操作记录那基本可以锁定人为因素。告警方面重点看小区不可用、X2/NG 接口故障、TRP 不可用这类会导致接入直接失败的告警还要确认这些告警在问题时间段内是否持续未恢复。参数核查环节手册列了几个关键参数我把它们和常见取值范围整理成表参数含义默认/建议值配置风险SsbPeriodSSB 周期20ms拉长可能导致部分终端无法接入Sib1PeriodSIB1 周期默认值拉长可能导致部分终端无法接入MaxPreambleTransCnt前导最大传输次数10 次减少可能降低接入成功率CellRadius小区半径按规划配置过小导致远点用户接入失败这里要提醒一句小区半径这个参数看着简单但它会影响生成 Preamble 序列用的 NCS 参数。配小了中远点用户直接进不来而且现场排查时很容易忽略因为弱覆盖和半径配置不足的现象在话统上长得差不多。射频通道排查主要看发射功率和上行干扰。上行干扰会拖累 SRS 和 PUSCH 解调性能正常底噪在 -116dBm 左右干扰跟踪可以在 M2000 的 Tracing Monitor 下 NR 的 CellPerformance Monitoring 里看。底噪明显抬高时先确认是外部干扰还是设备本身的问题别急着调功率。2.3 定位思路四类接入失败怎么分手册把接入失败分成空口未发起 RRC_CONN_REQ、NR 随机接入失败、RRC 建立失败、NGSig 建立异常四类这个分法基本对应了接入流程的先后顺序。空口未发起 RRC_CONN_REQ意思是基站侧压根没收到 RRCSetupRequest。这种情况重点不在空口而在终端和小区状态小区不可用或处于 BLOCK、NG-C 链路故障或未配置、AAU 通道校正失败、终端不支持对应 NR 频段都会导致终端根本不发起。排查时先确认小区状态和有没有基站侧故障告警再看终端侧有没有发起接入的动作记录。NR 随机接入失败的常见原因包括弱覆盖或干扰、超小区半径接入、PRACH 根序列索引规划不当、时隙配比和时隙结构不一致。PRACH 根序列索引这块容易被忽视——如果周边小区用了相同的根序列邻区会收到本小区的 Preamble 并下发 RAR对本小区形成下行干扰。时隙配比要求全网一致不一致会带来上下行干扰随机接入自然不稳定。RRC 建立失败要区分三种现象RRC Rej 是收到 RRCSetupRequest 但下发了 RRCSetupRejRRC NoReply 是下发了 RRCSetup 但等 RRCSetupComplete 超时或者下发后又立即下发 RRCRelRRC 丢弃是收到请求后直接丢弃不处理。前两种多半和下行覆盖、重选参数有关RRC 丢弃更倾向资源拥塞或设备异常。定位时结合 UU 口信令跟踪看具体是哪一种比只看话统 Counter 准得多。NGSig 建立异常要分基站侧和核心网侧。基站发了初始化 UE 消息但核心网没响应、核心网直接发 NG_RESET 释放单用户这两种需要联合核心网分析基站收到 MSG5 后 NG 链路被闭塞或内部异常导致没发初始化 UE 消息属于基站侧问题。判断的第一步就是看 NG 标口有没有初始化 UE 消息有就往核心网侧走没有就往基站侧走。3. 保持性排查掉话率恶化时先做哪五步隔离保持性问题的核心指标是无线掉话率但掉话率只是个结果直接盯着它看不出原因。手册给的思路是先定问题类型再做时间趋势、释放原因、TOP N、关联指标这几步隔离最后才落到覆盖、干扰、配置、切换、传输、小区故障这些具体方向。这套流程的价值在于它逼你先想清楚问题范围而不是见一个小区改一个参数。3.1 先分清四类 KPI 问题别用错动作掉话率问题常见四类指标突然恶化或某些时段恶化、指标缓慢变化逐渐变差、当前不达标需要提升到目标值、多区域对比找某区域差的原因。这四类的排查重点不一样。第一类突发恶化重点看操作日志和外部事件因为能导致突变的通常是有明确时间点的动作。第二类缓慢变化重点看时间趋势和关联指标可能是负荷增长或终端结构变化。第三类和第四类重点在 TOP N 分析和区域对比找出差异指标来隔离根因。用错动作的代价很实在拿突发恶化的排查方法去查缓慢劣化你会把时间全花在翻操作日志上而真正的原因可能是用户数一直在涨。3.2 时间趋势分析对齐周期和小区数时间趋势分析要看掉话率公式里各子 Counter 的变化趋势。先看总释放次数和异常释放次数的变化关系是异常增加还是正常减少导致掉话率抬升这两种情况的处理方向完全不同。异常释放增加要查无线或传输故障正常释放减少意味着用户行为或覆盖结构变了掉的可能是正常释放。分析恶化时间规律性时要区分持续缓慢下降、阶梯式下降、下降后恢复再下降。阶梯式下降要看是否固定发生在每天某些时段或者固定在周几、月初月末。天级指标对比要注意跨周对齐周末和周末比别拿周末和工作日比。还有个容易翻车的点分析时间段内小区个数是否稳定。话统数据不全或者采集中断导致小区数变化较大时KPI 趋势会被误判。发现小区数差异大先确认数据完整性符合预期就说明现网在新增或关站属于外部事件排查范畴。3.3 释放原因和 TOP N先把问题范围框住异常释放的原因话统里分无线层和传输层两个 CounterN.QosFlow.AbnormRel.RNL 和 N.QosFlow.AbnormRel.TNL。先看这两个的比例能初步判断是无线原因还是传输原因这一步能省掉大量两拨人互相扯皮的时间。TOP N 分析用来确认是 TOP 小区问题还是整网问题。做法是分别去掉 TOP10 的掉话率 TOP 小区和掉话次数 TOP 小区看整网指标有没有明显改善。改善明显就是 TOP 小区问题改善不明显就是整网问题。筛选 TOP 小区时有个坑总释放次数太少的小区偶尔几次异常释放就能算出很高的掉话率这种小区没有统计意义。建议按总释放次数不低于平均值 50%或者单小区每小时总释放次数不低于 1000 次来筛。TOP 小区如果是传输类问题要看这些小区所在站点的传输拓扑有没有规律比如是否共同接入某个传输子节点。这种规律性排查能快速把问题交给传输组处理而不是在无线侧空转。3.4 关联指标把正面证据和侧面证据都用上确认是空口原因掉话后手册建议做关联指标分析用切换成功率、误码、上行干扰、PRB 利用率、CCE 聚集级别、平均 CQI、平均 TA 值、平均用户数这些指标来互相印证。这些指标里切换成功率和掉话率关系最直接——切换成功率低说明 UE 无法切到最强小区容易掉话。误码相关指标的计算公式比较多下行 IBLER、重传率、RBLER 分别对应不同 QAM 阶数上的错误传输块统计。这里不建议手工一个个加常见做法是把公式整理成一个脚本或者 Excel 模板把话统导出的 Counter 值直接代进去算。下面这段 Python 用来说明下行 IBLER 的计算逻辑# 下行IBLER计算错误传输块数 / 总传输块数 # 先从话统导出各QAM阶数的Counter按列名填进对应的列表 qpsk_tb 12000 # N.DL.SCH.QPSK.TB qpsk_err 240 # N.DL.SCH.QPSK.ErrTB.Ibler qam16_tb 8000 # N.DL.SCH.16QAM.TB qam16_err 160 # N.DL.SCH.16QAM.ErrTB.Ibler qam64_tb 5000 # N.DL.SCH.64QAM.TB qam64_err 90 # N.DL.SCH.64QAM.ErrTB.Ibler qam256_tb 2000 # N.DL.SCH.256QAM.TB qam256_err 30 # N.DL.SCH.256QAM.ErrTB.Ibler total_tb qpsk_tb qam16_tb qam64_tb qam256_tb total_err qpsk_err qam16_err qam64_err qam256_err # 注意分母为0的情况话统导出为None或空时要先填0 dl_ibler (total_err / total_tb) * 100 if total_tb 0 else 0 print(f下行IBLER: {dl_ibler:.2f}%)这段脚本的关键是分母保护话统导出时某些 QAM 阶数可能没有数据直接算会报除零错误。另外要确认把同周期的各阶数数据放到同一行计算跨周期混算出来的是错的。平均 TA 值反映用户分布远近TA 分布越远说明用户大多在小边缘信道条件和 KPI 理论上都会差一些。平均用户数要和 PRB 利用率、干扰水平一起看用户增长会同时推高 PRB 利用率和邻区干扰这是 KPI 随用户数下降的主要原因之一。3.5 操作和外部事件别漏掉非技术因素站点新建或断站、翻频、RF 优化、全网参数修改、周边网元改造、重大活动、终端上市、版本升级这些都算外部事件。这些事件会导致拓扑结构、用户分布、负载和干扰水平变化最终影响 KPI。排查时建议把这些事件列成时间线和指标恶化时间点做叠图很多看起来像参数问题的指标恶化其实是站点关停后用户分流导致的负荷变化。4. 定位思路落地六类掉话根因的现场判据保持性问题隔离到空口之后手册给了覆盖、干扰、配置、切换、传输、小区故障六个方向。每个方向的现场判据不一样混在一起查效率很低。4.1 覆盖问题弱覆盖和重叠覆盖的信号特征弱覆盖导致的掉话终端侧 RSRP 低于 -120dBm 时就要警惕。当 RSRP 低于 A2 门限NRCELLNSADCCONFIG.PscellA2RsrpThld默认 -121时UE 会上报测量报告触发 gNodeB 释放这属于正常释放不计入掉话。所以看弱覆盖掉话时要确认是既低于门限又没走成正常释放流程还是压根没到门限就被迫掉话。重叠覆盖严重的问题特征是 UE 没有上报测量报告RSRP 不算特别差但突然收到网络侧释放命令终端侧能看到多个邻区信号强度和主服务小区相当甚至瞬时高 5dBSSB SINR 可能只有 -3。这种场景说明没有主服务小区需要先解决 RF 问题调参数是治标。还有一类特定位置点问题服务小区信号好、无邻区干扰但误码很高。手册里提到上行灌包时正常 UL Grant 应该有 380~400 次掉话前掉到 100 多次甚至更低说明存在 DCI 漏检。这类问题多半和无线环境多径复杂导致的频率选择性衰落有关排查时要结合位置和话统时间点一起看。4.2 配置问题RLC Polling 参数是典型翻车点手册里有个很典型的案例近点做下行灌包一会儿就掉话信号好、无邻区干扰、空口误码也不高信令显示是 5G 发起释放、原因值 UE LOST。19A 版本下 Cause 是 UE LOST 只可能是下行 RLC 重传达到最大次数。排查参数发现用的是 RLC 参数组 2其中 gNBAmByteThldForTrigPoll 和 gNBPduNumThldForTrigPoll 配成了 Infinity。按协议UE 只有在收到带 Polling 指示的 RLC PDU 或检测到 PDU 接收异常时才反馈状态报告。这两个参数配成无穷大后普通 PDU 不带 Polling而灌包场景下不存在缓存为空的尾包基站长时间收不到状态报告发送窗口滑不动。近 Polling 点灌包流量大RLC SN Size 只有 12bit很快发送窗口就满了基站判断 RLC 状态异常发起释放。解决措施是改用 RLC 参数组 3默认配置 UeAmByteThldForTrigPoll25、gNBAmByteThldForTrigPoll25、UePduNumThldForTrigPoll32 PDUs、gNBPduNumThldForTrigPoll32 PDUsDlRlcSnSize 和 UlRlcSnSize 都改成 18问题解决。这个案例说明配置类掉话光看覆盖和干扰指标是查不出来的必须对着参数组逐项核。4.3 切换失败和传输故障的判据切换失败的主要场景是 UE 向目标小区随机接入失败。NSA 组网下 LTE 发生切换时 5G 服务小区虽然不变但 UE 要做一次随机接入这个过程也可能失败。现场从 Probe 上看到 UE 上报 RAFail 事件然后发 SCGFailureInfo 后掉话Key Event 里能看到发了 Preamble 收不到 RAR连续发 10 次后上报随机接入失败。如果同时看到存在多个信号强度相当的邻区、掉话前有乒乓切换那本质是覆盖问题导致的切换失败得先优化覆盖。传输故障的判据是标口信令跟踪里释放命令携带原因值 transport-resource-unavailable。排查时先看有没有传输相关告警注意 GTPU 静态检测开关GTPU.STATICCHK没打开时不会上报传输告警这时可以打开开关继续观察或者用故障日志回溯之前的掉话原因。传输故障通常分传输拥塞丢包和收到核心网 GTPU Error 两种确认后转传输组处理。5. 避坑与排查这些现象别急着改参数现场排查最怕的是拿着手册当按钮说明书看见一个指标不对就调一个参数。下面这五条是实际执行时最容易翻车的地方每条都按现象、原因、解决来写。现象一接通率掉了改完小区半径反而更差。原因通常是没先看操作日志和告警直接跳到参数核查把本来配置合理的小区半径改小了中远点用户接入更差。解决是严格执行规定动作顺序先排除操作和告警再核参数改动前记录原值并留观察窗口。现象二掉话率 TOP 小区排查了半天没规律。原因是筛选 TOP 小区时没有排除总释放次数过少的样本导致 TOP 列表里混进了几个话务量极低、偶尔抖一下就上榜的小区。解决是按总释放次数不低于平均值 50% 或单小区每小时不低于 1000 次先过滤再做地理和拓扑规律分析。现象三时间趋势对了半天对不上。原因是没对齐周期拿周末数据和工作日比或者没注意分析时段内小区数发生了变化。解决是天级对比严格周对周、周末对周末同时拉出该时段小区数变化曲线数据不全先反馈确认。现象四干扰话统没显示就认为没干扰。原因是话统干扰粒度较粗没显示不代表没干扰。解决是话统看到有干扰基本可以确认存在但看到没有时要结合 U2000 干扰监测进一步确认特别是 TOP 小区。现象五RLC 相关掉话改了覆盖没效果。原因是这类掉话根因在 RLC Polling 参数组和 SN Size 配置信号和误码指标都正常覆盖优化无从下手。解决是对照参数组逐项核 gNBAmByteThldForTrigPoll、gNBPduNumThldForTrigPoll、RlcSnSize 这几项确认是否配成了 Infinity 或过小的 SN Size。6. 把手册变成话统模板三个自动化核对技巧手册内容不少真到现场一条条翻容易漏。我自己的习惯是把最常用的几组指标算好公式做成一个固定的话统核对模板每次问题排查先跑一遍把异常项标出来再深入。第一个技巧是把释放原因和 TOP N 做成一次性输出。下面的脚本用来说明思路读入话统导出的小区级数据先按总释放次数过滤再算掉话率并排序最后分别去掉 TOP10 后重新算整网指标。import pandas as pd # df需包含: cell_id, total_rel, abnorm_rel, rnl_rel, tnl_rel df pd.read_csv(kpi_hourly.csv) # 先过滤话务量过低的小区避免小样本误判 df df[df[total_rel] df[total_rel].mean() * 0.5].copy() # 掉话率按异常释放占比估算 df[drop_rate] df[abnorm_rel] / df[total_rel] # 整网掉话率 whole df[abnorm_rel].sum() / df[total_rel].sum() # 去掉掉话率TOP10和掉话次数TOP10后重新计算 top_rate_cells df.nlargest(10, drop_rate)[cell_id] top_cnt_cells df.nlargest(10, abnorm_rel)[cell_id] exclude set(top_rate_cells) | set(top_cnt_cells) df_trim df[~df[cell_id].isin(exclude)] trimmed df_trim[abnorm_rel].sum() / df_trim[total_rel].sum() print(f整网掉话率: {whole:.4%}, 去掉TOP后: {trimmed:.4%}) # 去掉后明显下降 - TOP小区问题; 无明显变化 - 整网问题这段脚本里过滤步的 0.5 是可以按现网话务水平调的单小区每小时不低于 1000 次的标准适合话务较重的城市网络偏远区域可以适当放宽。去掉 TOP 后指标明显下降就说明问题集中在少数小区转地理和传输拓扑分析没明显变化就往整网方向查负荷和干扰。第二个技巧是把 IBLER、重传率、CCE 聚集级别这些公式固化成一个参数说明表别每次现场翻手册。关键参数的含义和取值我一般会记这么几项A2 门限默认 -121低于它会触发测量报告正常释放上行底噪正常在 -116dBm 左右RLC 参数组 3 的 Polling 阈值是 25 字节/25 字节/32 PDU/32 PDUSN Size 18bit。这些值在现场比对时比公式本身更常用。第三个技巧是给参数核查做一份对照清单每次排查接入或掉话问题时逐项打勾。清单里的项包括小区状态是否可用、有无未恢复告警、操作日志有无时间相关性、SSB/SIB1 周期是否被拉长、小区半径和 PRACH 根序列是否按规划配置、RLC 参数组和 SN Size 是否匹配业务场景、GTPU.STATICCHK 是否打开。这份清单不复杂但能挡住大部分低级翻车。说实话我早期吃过一次亏某个站接入率突然掉了我直接上去调最小接收电平调完指标回来了一点就没再管结果一周后同一个站又掉翻操作日志才发现真正的起因是 AAU 通道校正失败没处理参数调整只是把现象压住了。从那以后我每次碰到接入或掉话问题都强制先把操作日志和告警这一遍走完再动任何参数。手册里说的规定动作真的是血泪换来的顺序。希望这份梳理能帮到你。本文还有配套的精品资源点击获取