企业官网建设流程全解析

简介：这是一份面向新入职网络优化工程师的爱立信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 Preamble，gNB 回 Random Access Response，终端再发 Msg3，gNB 回 Msg4，竞争解决完成；
• RRC 连接建立：终端发 RRCSetupRequest，gNB 回 RRCSetup，终端回 RRCSetupComplete，到这里空口侧基本就绪，但注意，RRCSetupComplete 里带着初始 NAS 消息（Registration Request 或 Service Request），NAS 还没送出去，呼叫就不算真正开始；
• NGAP Initial Context Setup：gNB 把 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 用计数器拆解失败环节：一张表看清计入时点

把四组计数器的 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}%, " f"NG成功率 {(c.get('ng_succ',0)/c.get('ng_req',1)*100):.2f}%, " f"PDU成功率 {(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（空口断链导致上下文下发失败）和unspecified，Transport Layer 常见的是transport-resource-unavailable（NG 链路或传输资源问题）。

提示：不要把radio-connection-with-ue-lost简单归因于覆盖差。它可能是 UE 在高层移动过程中上下文还未建立、gNB 没来得及下发测量控制导致的失步。要结合 RRCSetupComplete 是否已经收到来判断：没收到就是空口问题，收到了再失步就要往移动性参数和波束切换时机去找。

3. 无线侧三大瓶颈的量化评估：覆盖、干扰与波束对齐

3.1 SSB 覆盖评估：别只看 RSRP，要看接入时刻的 SS-RSRP

SA 接入性能骨子里被无线环境卡着。第一步量化评估是 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',' 'NR>1 { if ($3 ~ /^-/) { count[$2]++; sum[$2]+=$3; values[$2]=values[$2]" "$3 } } END { for (ssb in values) { n=split(values[ssb], arr, " "); # 简单排序后取 5% 分位（生产中建议用 Python 分位数计算） for (i=1; i<=n; i++) for (j=i; j<=n; j++) if (arr[i] > arr[j]) { tmp=arr[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 区间且持续存在；判断重叠覆盖干扰时，干扰带会随邻区业务量起伏。

这张表不是金科玉律，但它给了你一个判断优先级的方式：先看 RSRP，再看底噪趋势，最后看 SINR。三者组合起来，能覆盖绝大多数接入侧空口问题的归类。

3.3 波束对齐：终端的波束选择影响初始接入的成败

在多层波束配置下，终端接入时选哪个 SSB 波束是终端自主决定的。爱立信 gNB 的波束场景（Beam Scenario）配置决定了 SSB 波束的数量和形状。常见的波束配置有单波束、宽波束、多波束几种，多波束能提升覆盖但会增加测量和切换开销。

接入性能分析里，需要观察每个 SSB 索引的接入尝试数和成功率。如果发现特定 SSB 索引的接入失败率显著高于其他波束，首先要确认该波束是否对应一个弱覆盖方向，再确认波束配置里该波束的功率权重是否过低。

提示：调波束配置时不要一次性把波束数量改大。波束数量增加后，SSB 的时域位置变多，终端测量量增加，反而可能拖慢初始接入。常规做法是先在弱覆盖方向增加波束权重，或者微调波束倾角，波束数量不变。

4. 从指标到参数：SA 接入优化调整清单与验证闭环

4.1 随机接入参数：前导数量、功率攀升与重传上限

随机接入是接入链路的第一个环节，也是最容易通过参数调整见效的环节。爱立信 gNB 的随机接入相关参数，核心是 PRACH Preamble 的 Format、前导数量、功率攀升步长和最大重传次数。

调整逻辑是：弱覆盖场景先加重传次数，让终端有更多尝试机会；再调功率攀升步长，让终端更快达到目标功率。但如果干扰是主因，调门前载重传只会增加干扰占用时间。先确认干扰源，再决定要不要动这一步。

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"), on="cell" ) 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 是 cell，before/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 header=y -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 章的参数调整 → 本章的分钟级定位，走一遍完整流程，基本能把问题定位在半小时以内。

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