企业官网建设流程全解析

简介：这是一份华为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 不可用这类会导致接入直接失败的告警，还要确认这些告警在问题时间段内是否持续未恢复。

参数核查环节手册列了几个关键参数，我把它们和常见取值范围整理成表：

这里要提醒一句，小区半径这个参数看着简单，但它会影响生成 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 但下发了 RRCSetupRej；RRC NoReply 是下发了 RRCSetup 但等 RRCSetupComplete 超时，或者下发后又立即下发 RRCRel；RRC 丢弃是收到请求后直接丢弃不处理。前两种多半和下行覆盖、重选参数有关，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：先把问题范围框住

异常释放的原因话统里分无线层和传输层两个 Counter：N.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 不算特别差，但突然收到网络侧释放命令，终端侧能看到多个邻区信号强度和主服务小区相当甚至瞬时高 5dB，SSB 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，默认配置 UeAmByteThldForTrigPoll=25、gNBAmByteThldForTrigPoll=25、UePduNumThldForTrigPoll=32 PDUs、gNBPduNumThldForTrigPoll=32 PDUs，DlRlcSnSize 和 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 PDU，SN Size 18bit。这些值在现场比对时比公式本身更常用。

第三个技巧是给参数核查做一份对照清单，每次排查接入或掉话问题时逐项打勾。清单里的项包括小区状态是否可用、有无未恢复告警、操作日志有无时间相关性、SSB/SIB1 周期是否被拉长、小区半径和 PRACH 根序列是否按规划配置、RLC 参数组和 SN Size 是否匹配业务场景、GTPU.STATICCHK 是否打开。这份清单不复杂，但能挡住大部分低级翻车。

说实话，我早期吃过一次亏：某个站接入率突然掉了，我直接上去调最小接收电平，调完指标回来了一点就没再管，结果一周后同一个站又掉，翻操作日志才发现真正的起因是 AAU 通道校正失败没处理，参数调整只是把现象压住了。从那以后我每次碰到接入或掉话问题，都强制先把操作日志和告警这一遍走完，再动任何参数。手册里说的规定动作，真的是血泪换来的顺序。希望这份梳理能帮到你。

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