简介这是一份面向新入职网络优化工程师的爱立信5G SA接入性能分析优化指导书聚焦独立组网场景下终端从空闲态进入连接态的完整流程包括随机接入、无线资源控制连接建立、初始上下文建立以及可选的协议数据单元会话建立与修改。文档对随机接入响应、接入请求与建立消息、准入检查、安全算法配置等关键步骤进行逐步拆解并给出接入成功率、响应时延等优化切入点适合从事5G网络优化与接入问题排查的初中级工程师阅读。资源为单个PDF文件大小约1.44MB结构紧凑可直接对照现网信令使用。目前已有296人学习下载结合爱立信设备实践可帮助读者理解SA接入信令交互、定位接入失败原因并制定针对性优化措施是一份实用的入门与进阶参考资料。1. 为啥 5G SA 接通率上不去你差的不只是参数表接入性能分析这活儿最怕的不是指标差而是指标差在哪儿都说不清。爱立信 5G SA 环境里一次终端从空闲态到建立 PDU 会话要穿过随机接入、RRC 连接建立、NGAP 初始上下文建立、RNAS 会话建立四道关卡任何一道出问题落到 KPI 上都是同一句话接入成功率低。可你要拿着这个结论去跟核心网对线、跟 RF 对簿、跟参数组吵架就必须把「低」拆成「RRC 建立失败占比 XX%、NG 建立失败占比 XX%、会话建立失败占比 XX%」。这篇文章就是一份能照着做的 SA 接入性能分析与优化操作手册从 gNB 侧信令和计数器怎么读开始到覆盖、干扰、波束、参数怎么一层层排查最后给你一套可复用的分析闭环。适合 5G SA 网络优化、系统性能工程和爱立信设备维护的同事新手能按步骤走老手可以直接跳去确认自己的排查路径有没有漏掉那一环。2. 接入失败的第一现场gNB 侧计数器与 NGAP 信令流程2.1 先建立流程坐标系接入一次呼叫要过几道门爱立信 5G SA 的接入性能分析起点不是打开 KPI 报表而是把一条完整接入流程在脑子里立起来。终端发起初始接入gNB 侧依次经历随机接入终端发 PRACH PreamblegNB 回 Random Access Response终端再发 Msg3gNB 回 Msg4竞争解决完成RRC 连接建立终端发 RRCSetupRequestgNB 回 RRCSetup终端回 RRCSetupComplete到这里空口侧基本就绪但注意RRCSetupComplete 里带着初始 NAS 消息Registration Request 或 Service RequestNAS 还没送出去呼叫就不算真正开始NGAP Initial Context SetupgNB 把 NAS 透传发给核心网AMF 回 Initial Context Setup Request 或直接在 Initial UE Context Setup 里带上 PDU Session 建立信息gNB 此时才去建立 UE 上下文会话建立gNB 收到 PDU Session Resource Setup Request 后执行空口 DRB 建立和 NG-U 通道建立返回响应接入才算终了。做接入性能分析时必须把失败段切分到上述某一道门上。切分依据来自两部分一是网管侧的呼叫级别计数器二是 NGAP 信令里的 Cause 值。爱立信 gNB 的计数器体系里RRC 建立相关、NG 建立相关、PDU Session 建立相关是分开统计的不要混着看。提示接入失败分析最常见的误区是拿 RRCSetupComplete 之后的指标代表整条链路。实际上RRC 建立成功但 NAS 没送出去、核心网不回响应的情况相当常见只盯 RRC 建立成功率会漏掉一大半问题。2.2 用计数器拆解失败环节一张表看清计入时点计数器组建议观察的计数器计入时点失败常见原因随机接入每个波束/小区的 Preamble 发送次数、RA Success Rate终端发 Preamble 开始收到竞争解决结束覆盖不足、前导冲突、干扰抬高底噪RRC 建立RRC Setup Attempts / RRC Setup Complete 次数Attempts 在收到 RRCSetupRequest 计入Complete 在收到 RRCSetupComplete 计入空口质量差导致 RRCSetup 丢失、终端无响应NGAP 初始上下文建立Initial Context Setup Success / Failure按 Cause 细分收到 AMF 的 Initial Context Setup Request 开始AMF 响应超时、切片不可用、鉴权失败PDU 会话建立PDU Session Resource Setup Success / Failure收到核心网 PDU Session Resource Setup Request 开始UPF 不可达、QoS 参数配置错误、切片资源不足把四组计数器的 Attempts 和 Success 做差值就能得到每一道门的绝对失败量。再拿失败量除以整条链路的总尝试数得到的是「该环节导致的总接入失败占比」这是后续排优先级的关键数字。我一般会把这四个数字放到同一张表里按小时粒度出先看趋势再看总量。2.3 把原始性能文件交给脚本Python 快速汇总接入 KPI爱立信性能文件导出后通常是 CSV 或 XML 格式字段名随版本略有差异。下面给一个通用的 Python 处理思路重点在按计数器名聚合。import csv from collections import defaultdict # 假设性能文件字段cell, counter_name, granularity, value # 实际网管导出的字段名可能不同按你的导出模板调整列索引 counter_map { RRC_SETUP_ATTEMPTS: rrc_att, RRC_SETUP_COMPLETE: rrc_comp, INITIAL_CONTEXT_SETUP_REQ: ng_req, INITIAL_CONTEXT_SETUP_SUCC: ng_succ, PDU_SESSION_SETUP_REQ: pdu_req, PDU_SESSION_SETUP_SUCC: pdu_succ, } agg defaultdict(lambda: defaultdict(int)) with open(perf_data.csv, newline) as f: reader csv.DictReader(f) for row in reader: counter row[counter_name] if counter in counter_map: cell row[cell] agg[cell][counter_map[counter]] int(row[value]) for cell, c in sorted(agg.items()): rrc_att c.get(rrc_att, 0) rrc_comp c.get(rrc_comp, 0) rrc_rate (rrc_comp / rrc_att * 100) if rrc_att else 0 print(f{cell}: RRC成功率 {rrc_rate:.2f}%, fNG成功率 {(c.get(ng_succ,0)/c.get(ng_req,1)*100):.2f}%, fPDU成功率 {(c.get(pdu_succ,0)/c.get(pdu_req,1)*100):.2f}%)代码逻辑很简单先把计数器名映射到统一语义再用嵌套字典按小区聚合最后计算每道门成功率。注意ng_req分母为 0 时要置 1 避免除零实际生产环境建议用 try-except 兜底。这个脚本的价值不在算法而在帮你快速把几百个小区四道门的成功率一次性算出来直接导出排序省得在网管 Web 页面翻来翻去。2.4 NGAP Cause 值定位核心网侧还是无线侧的关键当 Initial Context Setup 或 PDU Session Setup 失败时NGAP 响应里会携带 Cause 值。爱立信 gNB 侧的诊断通常能看到两类Radio Network Layer 的 Cause 和 Transport Layer 的 Cause。Radio Network Layer 下常见的是radio-connection-with-ue-lost空口断链导致上下文下发失败和unspecifiedTransport Layer 常见的是transport-resource-unavailableNG 链路或传输资源问题。提示不要把radio-connection-with-ue-lost简单归因于覆盖差。它可能是 UE 在高层移动过程中上下文还未建立、gNB 没来得及下发测量控制导致的失步。要结合 RRCSetupComplete 是否已经收到来判断没收到就是空口问题收到了再失步就要往移动性参数和波束切换时机去找。3. 无线侧三大瓶颈的量化评估覆盖、干扰与波束对齐3.1 SSB 覆盖评估别只看 RSRP要看接入时刻的 SS-RSRPSA 接入性能骨子里被无线环境卡着。第一步量化评估是 SSB 覆盖因为接入用的是 SSB 波束不是 CSI-RS。SS-RSRP 低于 -100 dBm 的区域终端在竞争随机接入阶段就可能因为 Preamble 检测概率下降而反复重传。实际操作中我会把 MR 数据爱立信网管可以导出基于 SSB 的测量报告按小区、按 SSB 索引聚合看每个波束的 SS-RSRP 分布。重点观察低百分位比如 CDF 5% 和 10% 值而不是平均值。平均值好看但低百分位难看的场景往往是小部分区域覆盖严重不足终端在这些区域反复尝试接入把 RRC 建立成功率拉低。# 假设 MR 文件为 CSV字段含 ssb_index, ss_rsrp, cell # 用 awk 按 SSB 索引计算 P5 值 awk -F, NR1 { if ($3 ~ /^-/) { count[$2]; sum[$2]$3; values[$2]values[$2] $3 } } END { for (ssb in values) { nsplit(values[ssb], arr, ); # 简单排序后取 5% 分位生产中建议用 Python 分位数计算 for (i1; in; i) for (ji; jn; j) if (arr[i] arr[j]) { tmparr[i]; arr[i]arr[j]; arr[j]tmp } idx int(n*0.05); if (idx 1) idx 1; printf SSB %s: P5 %.1f dBm (样本数 %d)\n, ssb, arr[idx], count[ssb] } } mr_data.csv这段 awk 的用途是先过滤掉非法值然后按 SSB 索引聚合做一次简单排序取 P5。注意 awk 排序在样本量大的时候效率差几百 MB 的 MR 文件建议直接用 Python 的 pandas 分位数awk 适合快速验证小样本。SSB P5 明显低于周边波束 6 dB 以上时优先检查该波束的水平和垂直覆盖角度大概率是下倾角或方位角配置与场景不匹配。3.2 干扰分层判断是外部干扰还是覆盖重叠SA 接入失败的第二大元凶是干扰但干扰要分清楚类。SS-SINR 低于 0 dB 但 SS-RSRP 不差的小区通常是外部干扰也可能是同频邻区重叠覆盖SS-SINR 差且 RSRP 也差基本是覆盖问题。区分方法很直接看非连续接收时间段的底噪。外部干扰通常是持续占用频谱的覆盖重叠导致的 SINR 差会在业务量低谷明显改善。gNB 侧可以通过 PRB 级干扰统计来观察底噪分布。爱立信系统里上行 PRB 干扰统计能按 RB 粒度看到哪段频谱被抬起。判断外部干扰时看干扰带是不是落在特定 RB 区间且持续存在判断重叠覆盖干扰时干扰带会随邻区业务量起伏。现象可能原因下一步动作SS-SINR 差、RSRP 好、底噪持续高出 -110 dBm外部干扰源扫频定位协调关停或调整频谱使用SS-SINR 差、RSRP 好、底噪随业务波动同频重叠覆盖调波束、降功率、优化邻区关系SS-SINR 差、RSRP 也差覆盖不足补站/调倾角/增加发射功率SS-SINR 正常、RRC 建立仍失败参数/容量/核心网转向计数器分析环节这张表不是金科玉律但它给了你一个判断优先级的方式先看 RSRP再看底噪趋势最后看 SINR。三者组合起来能覆盖绝大多数接入侧空口问题的归类。3.3 波束对齐终端的波束选择影响初始接入的成败在多层波束配置下终端接入时选哪个 SSB 波束是终端自主决定的。爱立信 gNB 的波束场景Beam Scenario配置决定了 SSB 波束的数量和形状。常见的波束配置有单波束、宽波束、多波束几种多波束能提升覆盖但会增加测量和切换开销。接入性能分析里需要观察每个 SSB 索引的接入尝试数和成功率。如果发现特定 SSB 索引的接入失败率显著高于其他波束首先要确认该波束是否对应一个弱覆盖方向再确认波束配置里该波束的功率权重是否过低。提示调波束配置时不要一次性把波束数量改大。波束数量增加后SSB 的时域位置变多终端测量量增加反而可能拖慢初始接入。常规做法是先在弱覆盖方向增加波束权重或者微调波束倾角波束数量不变。4. 从指标到参数SA 接入优化调整清单与验证闭环4.1 随机接入参数前导数量、功率攀升与重传上限随机接入是接入链路的第一个环节也是最容易通过参数调整见效的环节。爱立信 gNB 的随机接入相关参数核心是 PRACH Preamble 的 Format、前导数量、功率攀升步长和最大重传次数。参数方向当前值示例调整建议适用场景Preamble 重传最大次数8提升至 12~16弱覆盖区域终端首次 Preamble 很难被检到功率攀升步长2 dB提升至 3~4 dB上行路径损耗大Preamble 功率不够前导检测门限默认适当降低底噪高Preamble 检测率上不去的地方RAR 窗口长度默认适当延长下行干扰导致 RAR 丢失率高的场景调整逻辑是弱覆盖场景先加重传次数让终端有更多尝试机会再调功率攀升步长让终端更快达到目标功率。但如果干扰是主因调门前载重传只会增加干扰占用时间。先确认干扰源再决定要不要动这一步。4.2 RRC 建立相关定时器与容量参数RRC 建立失败中有一类原因是 gNB 在 RRCSetupRequest 之后没收到 RRCSetupComplete这往往不是覆盖问题而是 RRC 建立定时器过短或者小区 RRC 连接数达到上限导致建立请求被拒。RRC 建立相关的核心定时器是 T300控制 UE 等待 RRCSetup 的时间。T300 过短在无线环境一般、信令时延抖动大的场景会导致 UE 提前判失败T300 过长又会拖慢终端转 IDLE 的时机。实际优化中我会先看 RRC Setup Attempts 的失败原因分布如果大量是「UE 无响应」类才考虑调整 T300。容量方面观察 RRC Connected 用户数是否在接入失败时段达到 gNB 规格上限。爱立信 gNB 每小区 RRC Connected 上限一般在数千级别但如果开通了大规模 mMTC 业务连接数可能很快触顶。此时调参数无效应该扩容或优化连接释放策略。4.3 调整后的验证闭环15 分钟粒度与双重对比参数调整最怕的是「调完了看整体指标发现没变化然后不了了之」。我的做法是固定一个验证模板调整前收集 3 天同一时段的接入 KPI按小时粒度存底调整后第 1 个小时开始按 15 分钟粒度观察 RRC 建立成功率、NG 建立成功率、随机接入成功率对比时看两个维度调整前后均值差异以及关键失败原因的计数变化。import pandas as pd # 加载调整前后两个时段的 KPI 数据 before pd.read_csv(kpi_before.csv) # 字段: time, cell, rrc_rate, ng_rate, pdu_rate, ra_succ after pd.read_csv(kpi_after.csv) # 按小区聚合计算调整前后的成功率均值差 cmp pd.merge( before.groupby(cell)[[rrc_rate, ng_rate]].mean().add_suffix(_before), after.groupby(cell)[[rrc_rate, ng_rate]].mean().add_suffix(_after), oncell ) cmp[rrc_diff] cmp[rrc_rate_after] - cmp[rrc_rate_before] cmp[ng_diff] cmp[ng_rate_after] - cmp[ng_rate_before] # 输出改善 1pp 以上的小区和恶化 0.5pp 以上的小区 improved cmp[cmp[rrc_diff] 1.0] degraded cmp[cmp[rrc_diff] -0.5] print(f改善小区数: {len(improved)}, 恶化小区数: {len(degraded)})代码里 merge 的 key 是 cellbefore/after 各自按小区求均值再 Join最终得到差分。注意这里只对比均值是不够的还要看恶化小区有没有共性——是集中在同一站点、同一 TA还是同一波束场景。如果恶化小区集中在某个站点优先怀疑是单站参数覆盖不全而不是整体策略失败。4.4 参数回滚与批量操作的规避顺序批量调整参数时最后一步是明确回滚条件。我的习惯是每次只调整一类参数比如这一轮只动随机接入参数下一轮只动 T300不要一次性混合调整。回滚条件要提前写死调整后 2 小时内接入成功率下降超过 2pp或者随机接入冲突率上升超过 3pp立即回滚。提示爱立信网管支持参数修改的导入导出批量操作前务必导出当前配置留档。回滚时不要手动逐条改回直接导入留档配置避免遗漏。5. 接入性能专项分析的正确打开方式用一场「手术式」定位演示完整打法最后一章给一个具体的分析技巧用分钟级信令跟踪快速定位「RRC Setup Complete 缺失」和「Initial Context Setup 无响应」这两类中间态问题。这是接入性能分析里最容易被绕晕的地方因为两类问题的表象都是成功率上不去但排查路径完全不同。先做一版时间对齐的多维归因。取从网管导出的信令跟踪文件爱立信 gNB 的跟踪数据可以导出为 PCAP 或类似格式先用 tshark 按 NGAP 过滤把每个 UE 的 Initial UE Message、DL NAS Transport、Initial Context Setup Request/Response 提取出来按 UE ID 和请求时间排序找出哪一步丢失。tshark -r ngap_trace.pcap -Y ngap -T fields \ -e frame.time_relative -e ngap.ProcedureCode -e ngap.UEID \ -E headery -E separator, ngap_procedures.csv过滤逻辑是取所有 NGAP 过程的相对时间、过程码和 UE 标识输出 CSV 后按 UE ID 分组检查每个 UE 是否出现了完整的「Initial UE Message → Initial Context Setup Request → Initial Context Setup Response」。如果 Request 发出后迟迟没有 Response再回无线侧看同一时刻的 RRC 质量如果连 Request 都没有问题大概率在 AMF 侧或传输链路。实战中我发现一个高价值的判断方式把 RRCSetupComplete 的到达时间和 Initial Context Setup Request 的到达时间做差。这个差值通常落在几十毫秒到几百毫秒之间。如果大量样本的差值超过 1 秒说明核心网处理时延过高即使空口侧一切正常用户感知也上不去。这个差值指标建议纳入常规接入 KPI 监控比单一的成功率更能反映端到端健康状况。最后一次提示接入性能优化没有银弹。所有分析都要落到「哪一道门、哪类 Cause、哪个波束、哪个时间段」这四件事上。看完这篇你可以拿自己手上一个接入成功率低的小区按照第 2 章的计数器拆解 → 第 3 章的无线侧量化 → 第 4 章的参数调整 → 本章的分钟级定位走一遍完整流程基本能把问题定位在半小时以内。本文还有配套的精品资源点击获取 5G SA接入成功率分析：从计数器到参数优化实战
简介这是一份面向新入职网络优化工程师的爱立信5G SA接入性能分析优化指导书聚焦独立组网场景下终端从空闲态进入连接态的完整流程包括随机接入、无线资源控制连接建立、初始上下文建立以及可选的协议数据单元会话建立与修改。文档对随机接入响应、接入请求与建立消息、准入检查、安全算法配置等关键步骤进行逐步拆解并给出接入成功率、响应时延等优化切入点适合从事5G网络优化与接入问题排查的初中级工程师阅读。资源为单个PDF文件大小约1.44MB结构紧凑可直接对照现网信令使用。目前已有296人学习下载结合爱立信设备实践可帮助读者理解SA接入信令交互、定位接入失败原因并制定针对性优化措施是一份实用的入门与进阶参考资料。1. 为啥 5G SA 接通率上不去你差的不只是参数表接入性能分析这活儿最怕的不是指标差而是指标差在哪儿都说不清。爱立信 5G SA 环境里一次终端从空闲态到建立 PDU 会话要穿过随机接入、RRC 连接建立、NGAP 初始上下文建立、RNAS 会话建立四道关卡任何一道出问题落到 KPI 上都是同一句话接入成功率低。可你要拿着这个结论去跟核心网对线、跟 RF 对簿、跟参数组吵架就必须把「低」拆成「RRC 建立失败占比 XX%、NG 建立失败占比 XX%、会话建立失败占比 XX%」。这篇文章就是一份能照着做的 SA 接入性能分析与优化操作手册从 gNB 侧信令和计数器怎么读开始到覆盖、干扰、波束、参数怎么一层层排查最后给你一套可复用的分析闭环。适合 5G SA 网络优化、系统性能工程和爱立信设备维护的同事新手能按步骤走老手可以直接跳去确认自己的排查路径有没有漏掉那一环。2. 接入失败的第一现场gNB 侧计数器与 NGAP 信令流程2.1 先建立流程坐标系接入一次呼叫要过几道门爱立信 5G SA 的接入性能分析起点不是打开 KPI 报表而是把一条完整接入流程在脑子里立起来。终端发起初始接入gNB 侧依次经历随机接入终端发 PRACH PreamblegNB 回 Random Access Response终端再发 Msg3gNB 回 Msg4竞争解决完成RRC 连接建立终端发 RRCSetupRequestgNB 回 RRCSetup终端回 RRCSetupComplete到这里空口侧基本就绪但注意RRCSetupComplete 里带着初始 NAS 消息Registration Request 或 Service RequestNAS 还没送出去呼叫就不算真正开始NGAP Initial Context SetupgNB 把 NAS 透传发给核心网AMF 回 Initial Context Setup Request 或直接在 Initial UE Context Setup 里带上 PDU Session 建立信息gNB 此时才去建立 UE 上下文会话建立gNB 收到 PDU Session Resource Setup Request 后执行空口 DRB 建立和 NG-U 通道建立返回响应接入才算终了。做接入性能分析时必须把失败段切分到上述某一道门上。切分依据来自两部分一是网管侧的呼叫级别计数器二是 NGAP 信令里的 Cause 值。爱立信 gNB 的计数器体系里RRC 建立相关、NG 建立相关、PDU Session 建立相关是分开统计的不要混着看。提示接入失败分析最常见的误区是拿 RRCSetupComplete 之后的指标代表整条链路。实际上RRC 建立成功但 NAS 没送出去、核心网不回响应的情况相当常见只盯 RRC 建立成功率会漏掉一大半问题。2.2 用计数器拆解失败环节一张表看清计入时点计数器组建议观察的计数器计入时点失败常见原因随机接入每个波束/小区的 Preamble 发送次数、RA Success Rate终端发 Preamble 开始收到竞争解决结束覆盖不足、前导冲突、干扰抬高底噪RRC 建立RRC Setup Attempts / RRC Setup Complete 次数Attempts 在收到 RRCSetupRequest 计入Complete 在收到 RRCSetupComplete 计入空口质量差导致 RRCSetup 丢失、终端无响应NGAP 初始上下文建立Initial Context Setup Success / Failure按 Cause 细分收到 AMF 的 Initial Context Setup Request 开始AMF 响应超时、切片不可用、鉴权失败PDU 会话建立PDU Session Resource Setup Success / Failure收到核心网 PDU Session Resource Setup Request 开始UPF 不可达、QoS 参数配置错误、切片资源不足把四组计数器的 Attempts 和 Success 做差值就能得到每一道门的绝对失败量。再拿失败量除以整条链路的总尝试数得到的是「该环节导致的总接入失败占比」这是后续排优先级的关键数字。我一般会把这四个数字放到同一张表里按小时粒度出先看趋势再看总量。2.3 把原始性能文件交给脚本Python 快速汇总接入 KPI爱立信性能文件导出后通常是 CSV 或 XML 格式字段名随版本略有差异。下面给一个通用的 Python 处理思路重点在按计数器名聚合。import csv from collections import defaultdict # 假设性能文件字段cell, counter_name, granularity, value # 实际网管导出的字段名可能不同按你的导出模板调整列索引 counter_map { RRC_SETUP_ATTEMPTS: rrc_att, RRC_SETUP_COMPLETE: rrc_comp, INITIAL_CONTEXT_SETUP_REQ: ng_req, INITIAL_CONTEXT_SETUP_SUCC: ng_succ, PDU_SESSION_SETUP_REQ: pdu_req, PDU_SESSION_SETUP_SUCC: pdu_succ, } agg defaultdict(lambda: defaultdict(int)) with open(perf_data.csv, newline) as f: reader csv.DictReader(f) for row in reader: counter row[counter_name] if counter in counter_map: cell row[cell] agg[cell][counter_map[counter]] int(row[value]) for cell, c in sorted(agg.items()): rrc_att c.get(rrc_att, 0) rrc_comp c.get(rrc_comp, 0) rrc_rate (rrc_comp / rrc_att * 100) if rrc_att else 0 print(f{cell}: RRC成功率 {rrc_rate:.2f}%, fNG成功率 {(c.get(ng_succ,0)/c.get(ng_req,1)*100):.2f}%, fPDU成功率 {(c.get(pdu_succ,0)/c.get(pdu_req,1)*100):.2f}%)代码逻辑很简单先把计数器名映射到统一语义再用嵌套字典按小区聚合最后计算每道门成功率。注意ng_req分母为 0 时要置 1 避免除零实际生产环境建议用 try-except 兜底。这个脚本的价值不在算法而在帮你快速把几百个小区四道门的成功率一次性算出来直接导出排序省得在网管 Web 页面翻来翻去。2.4 NGAP Cause 值定位核心网侧还是无线侧的关键当 Initial Context Setup 或 PDU Session Setup 失败时NGAP 响应里会携带 Cause 值。爱立信 gNB 侧的诊断通常能看到两类Radio Network Layer 的 Cause 和 Transport Layer 的 Cause。Radio Network Layer 下常见的是radio-connection-with-ue-lost空口断链导致上下文下发失败和unspecifiedTransport Layer 常见的是transport-resource-unavailableNG 链路或传输资源问题。提示不要把radio-connection-with-ue-lost简单归因于覆盖差。它可能是 UE 在高层移动过程中上下文还未建立、gNB 没来得及下发测量控制导致的失步。要结合 RRCSetupComplete 是否已经收到来判断没收到就是空口问题收到了再失步就要往移动性参数和波束切换时机去找。3. 无线侧三大瓶颈的量化评估覆盖、干扰与波束对齐3.1 SSB 覆盖评估别只看 RSRP要看接入时刻的 SS-RSRPSA 接入性能骨子里被无线环境卡着。第一步量化评估是 SSB 覆盖因为接入用的是 SSB 波束不是 CSI-RS。SS-RSRP 低于 -100 dBm 的区域终端在竞争随机接入阶段就可能因为 Preamble 检测概率下降而反复重传。实际操作中我会把 MR 数据爱立信网管可以导出基于 SSB 的测量报告按小区、按 SSB 索引聚合看每个波束的 SS-RSRP 分布。重点观察低百分位比如 CDF 5% 和 10% 值而不是平均值。平均值好看但低百分位难看的场景往往是小部分区域覆盖严重不足终端在这些区域反复尝试接入把 RRC 建立成功率拉低。# 假设 MR 文件为 CSV字段含 ssb_index, ss_rsrp, cell # 用 awk 按 SSB 索引计算 P5 值 awk -F, NR1 { if ($3 ~ /^-/) { count[$2]; sum[$2]$3; values[$2]values[$2] $3 } } END { for (ssb in values) { nsplit(values[ssb], arr, ); # 简单排序后取 5% 分位生产中建议用 Python 分位数计算 for (i1; in; i) for (ji; jn; j) if (arr[i] arr[j]) { tmparr[i]; arr[i]arr[j]; arr[j]tmp } idx int(n*0.05); if (idx 1) idx 1; printf SSB %s: P5 %.1f dBm (样本数 %d)\n, ssb, arr[idx], count[ssb] } } mr_data.csv这段 awk 的用途是先过滤掉非法值然后按 SSB 索引聚合做一次简单排序取 P5。注意 awk 排序在样本量大的时候效率差几百 MB 的 MR 文件建议直接用 Python 的 pandas 分位数awk 适合快速验证小样本。SSB P5 明显低于周边波束 6 dB 以上时优先检查该波束的水平和垂直覆盖角度大概率是下倾角或方位角配置与场景不匹配。3.2 干扰分层判断是外部干扰还是覆盖重叠SA 接入失败的第二大元凶是干扰但干扰要分清楚类。SS-SINR 低于 0 dB 但 SS-RSRP 不差的小区通常是外部干扰也可能是同频邻区重叠覆盖SS-SINR 差且 RSRP 也差基本是覆盖问题。区分方法很直接看非连续接收时间段的底噪。外部干扰通常是持续占用频谱的覆盖重叠导致的 SINR 差会在业务量低谷明显改善。gNB 侧可以通过 PRB 级干扰统计来观察底噪分布。爱立信系统里上行 PRB 干扰统计能按 RB 粒度看到哪段频谱被抬起。判断外部干扰时看干扰带是不是落在特定 RB 区间且持续存在判断重叠覆盖干扰时干扰带会随邻区业务量起伏。现象可能原因下一步动作SS-SINR 差、RSRP 好、底噪持续高出 -110 dBm外部干扰源扫频定位协调关停或调整频谱使用SS-SINR 差、RSRP 好、底噪随业务波动同频重叠覆盖调波束、降功率、优化邻区关系SS-SINR 差、RSRP 也差覆盖不足补站/调倾角/增加发射功率SS-SINR 正常、RRC 建立仍失败参数/容量/核心网转向计数器分析环节这张表不是金科玉律但它给了你一个判断优先级的方式先看 RSRP再看底噪趋势最后看 SINR。三者组合起来能覆盖绝大多数接入侧空口问题的归类。3.3 波束对齐终端的波束选择影响初始接入的成败在多层波束配置下终端接入时选哪个 SSB 波束是终端自主决定的。爱立信 gNB 的波束场景Beam Scenario配置决定了 SSB 波束的数量和形状。常见的波束配置有单波束、宽波束、多波束几种多波束能提升覆盖但会增加测量和切换开销。接入性能分析里需要观察每个 SSB 索引的接入尝试数和成功率。如果发现特定 SSB 索引的接入失败率显著高于其他波束首先要确认该波束是否对应一个弱覆盖方向再确认波束配置里该波束的功率权重是否过低。提示调波束配置时不要一次性把波束数量改大。波束数量增加后SSB 的时域位置变多终端测量量增加反而可能拖慢初始接入。常规做法是先在弱覆盖方向增加波束权重或者微调波束倾角波束数量不变。4. 从指标到参数SA 接入优化调整清单与验证闭环4.1 随机接入参数前导数量、功率攀升与重传上限随机接入是接入链路的第一个环节也是最容易通过参数调整见效的环节。爱立信 gNB 的随机接入相关参数核心是 PRACH Preamble 的 Format、前导数量、功率攀升步长和最大重传次数。参数方向当前值示例调整建议适用场景Preamble 重传最大次数8提升至 12~16弱覆盖区域终端首次 Preamble 很难被检到功率攀升步长2 dB提升至 3~4 dB上行路径损耗大Preamble 功率不够前导检测门限默认适当降低底噪高Preamble 检测率上不去的地方RAR 窗口长度默认适当延长下行干扰导致 RAR 丢失率高的场景调整逻辑是弱覆盖场景先加重传次数让终端有更多尝试机会再调功率攀升步长让终端更快达到目标功率。但如果干扰是主因调门前载重传只会增加干扰占用时间。先确认干扰源再决定要不要动这一步。4.2 RRC 建立相关定时器与容量参数RRC 建立失败中有一类原因是 gNB 在 RRCSetupRequest 之后没收到 RRCSetupComplete这往往不是覆盖问题而是 RRC 建立定时器过短或者小区 RRC 连接数达到上限导致建立请求被拒。RRC 建立相关的核心定时器是 T300控制 UE 等待 RRCSetup 的时间。T300 过短在无线环境一般、信令时延抖动大的场景会导致 UE 提前判失败T300 过长又会拖慢终端转 IDLE 的时机。实际优化中我会先看 RRC Setup Attempts 的失败原因分布如果大量是「UE 无响应」类才考虑调整 T300。容量方面观察 RRC Connected 用户数是否在接入失败时段达到 gNB 规格上限。爱立信 gNB 每小区 RRC Connected 上限一般在数千级别但如果开通了大规模 mMTC 业务连接数可能很快触顶。此时调参数无效应该扩容或优化连接释放策略。4.3 调整后的验证闭环15 分钟粒度与双重对比参数调整最怕的是「调完了看整体指标发现没变化然后不了了之」。我的做法是固定一个验证模板调整前收集 3 天同一时段的接入 KPI按小时粒度存底调整后第 1 个小时开始按 15 分钟粒度观察 RRC 建立成功率、NG 建立成功率、随机接入成功率对比时看两个维度调整前后均值差异以及关键失败原因的计数变化。import pandas as pd # 加载调整前后两个时段的 KPI 数据 before pd.read_csv(kpi_before.csv) # 字段: time, cell, rrc_rate, ng_rate, pdu_rate, ra_succ after pd.read_csv(kpi_after.csv) # 按小区聚合计算调整前后的成功率均值差 cmp pd.merge( before.groupby(cell)[[rrc_rate, ng_rate]].mean().add_suffix(_before), after.groupby(cell)[[rrc_rate, ng_rate]].mean().add_suffix(_after), oncell ) cmp[rrc_diff] cmp[rrc_rate_after] - cmp[rrc_rate_before] cmp[ng_diff] cmp[ng_rate_after] - cmp[ng_rate_before] # 输出改善 1pp 以上的小区和恶化 0.5pp 以上的小区 improved cmp[cmp[rrc_diff] 1.0] degraded cmp[cmp[rrc_diff] -0.5] print(f改善小区数: {len(improved)}, 恶化小区数: {len(degraded)})代码里 merge 的 key 是 cellbefore/after 各自按小区求均值再 Join最终得到差分。注意这里只对比均值是不够的还要看恶化小区有没有共性——是集中在同一站点、同一 TA还是同一波束场景。如果恶化小区集中在某个站点优先怀疑是单站参数覆盖不全而不是整体策略失败。4.4 参数回滚与批量操作的规避顺序批量调整参数时最后一步是明确回滚条件。我的习惯是每次只调整一类参数比如这一轮只动随机接入参数下一轮只动 T300不要一次性混合调整。回滚条件要提前写死调整后 2 小时内接入成功率下降超过 2pp或者随机接入冲突率上升超过 3pp立即回滚。提示爱立信网管支持参数修改的导入导出批量操作前务必导出当前配置留档。回滚时不要手动逐条改回直接导入留档配置避免遗漏。5. 接入性能专项分析的正确打开方式用一场「手术式」定位演示完整打法最后一章给一个具体的分析技巧用分钟级信令跟踪快速定位「RRC Setup Complete 缺失」和「Initial Context Setup 无响应」这两类中间态问题。这是接入性能分析里最容易被绕晕的地方因为两类问题的表象都是成功率上不去但排查路径完全不同。先做一版时间对齐的多维归因。取从网管导出的信令跟踪文件爱立信 gNB 的跟踪数据可以导出为 PCAP 或类似格式先用 tshark 按 NGAP 过滤把每个 UE 的 Initial UE Message、DL NAS Transport、Initial Context Setup Request/Response 提取出来按 UE ID 和请求时间排序找出哪一步丢失。tshark -r ngap_trace.pcap -Y ngap -T fields \ -e frame.time_relative -e ngap.ProcedureCode -e ngap.UEID \ -E headery -E separator, ngap_procedures.csv过滤逻辑是取所有 NGAP 过程的相对时间、过程码和 UE 标识输出 CSV 后按 UE ID 分组检查每个 UE 是否出现了完整的「Initial UE Message → Initial Context Setup Request → Initial Context Setup Response」。如果 Request 发出后迟迟没有 Response再回无线侧看同一时刻的 RRC 质量如果连 Request 都没有问题大概率在 AMF 侧或传输链路。实战中我发现一个高价值的判断方式把 RRCSetupComplete 的到达时间和 Initial Context Setup Request 的到达时间做差。这个差值通常落在几十毫秒到几百毫秒之间。如果大量样本的差值超过 1 秒说明核心网处理时延过高即使空口侧一切正常用户感知也上不去。这个差值指标建议纳入常规接入 KPI 监控比单一的成功率更能反映端到端健康状况。最后一次提示接入性能优化没有银弹。所有分析都要落到「哪一道门、哪类 Cause、哪个波束、哪个时间段」这四件事上。看完这篇你可以拿自己手上一个接入成功率低的小区按照第 2 章的计数器拆解 → 第 3 章的无线侧量化 → 第 4 章的参数调整 → 本章的分钟级定位走一遍完整流程基本能把问题定位在半小时以内。本文还有配套的精品资源点击获取