简介本资源是爱立信官方发布的《SA接入性能分析优化指导书》专为新入职网络优化工程师设计系统梳理5G NR独立组网SA场景下从空闲态到连接态的完整接入信令流程与关键优化点。内容覆盖随机接入、RRC连接建立、初始上下文建立及PDU会话管理四大阶段深入解析msg1-msg5交互机制、RA响应窗口、准入检查逻辑、NAS/AS安全配置协同等实操难点并给出参数调优、资源分配与流程时延压缩等落地建议。资源为单文件PDF文档大小1.44MB结构清晰、图文结合含32页技术指南与修订记录便于快速查阅与现场参考。目前已有296人学习下载适合具备5G基础理论知识、正参与现网优化或备考相关认证的中初级工程师系统掌握SA接入性能分析方法论与排障思路。1. 为什么一份 PDF 指导书成了 5G SA 网络交付现场的“救命文档”不是所有 PDF 都叫《爱立信 SA 接入性能分析优化指导书》。它不讲 5G 原理不堆协议栈图更不教你怎么写 PPT——它只干一件事当基站刚开通、用户连不上、KPI如 RRC 建立成功率、ERAB 建立成功率、初始接入时延突然掉到 70% 以下而你手握爱立信 MINI-LTE/5G 网管ENM、TRACE 工具和一堆原始信令日志却卡在“知道有问题但不知道从哪下手”的黑匣子时刻——这份文档就是你打开第一个过滤条件、敲下第一条 CLI 命令、定位第一个异常字段的起点。它面向的是现网交付工程师、无线优化工程师、核心网协同支撑人员不是实验室研究员。它的价值不在理论深度而在把爱立信 5G SA 架构下AMF/MME 双域共存、NGAP/S1AP 协议栈分层、UE 状态机迁移路径的接入失败拆解成可逐层抓包、可按字段比对、可对照阈值调整的 12 类典型根因比如 AMF 侧 NG Setup Failure、UE 侧 Security Mode Reject、gNB 侧 QoS Flow Setup Fail并给出每类对应的 ENM 告警码、TRACE 过滤关键字、关键 IE 字段含义及推荐参数修改范围。它不是说明书是故障树手册不是教程是经验压缩包。2. 从 ENM 抓取原始数据不是点“导出”而是选对视图、设准时间窗、过滤掉噪声接入性能问题必须基于真实话务场景还原不能靠“感觉”。爱立信 ENMEricsson Network Manager是唯一权威数据源但默认视图全是聚合 KPI对根因分析毫无价值。真正有用的是原始计数器Raw Counters与信令跟踪Trace Data的组合使用。下面是我在线网中反复验证过的最小可行路径。2.1 用 Raw Counter 定位“哪一层先崩了”三组必查计数器不要一上来就查 RRC 建立成功率。先看底层承载是否建立成功再看上层信令是否触发。我习惯按如下顺序查 ENM 中的 Raw Counter路径ENM → Monitoring → Performance → Raw Counters计数器名称ENM 内部 ID物理意义正常阈值参考关键解读rrcConnEstabAttUE 发起 RRC Connection Request 次数无绝对值看趋势若此值骤降说明 UE 根本没发请求 → 查覆盖、终端能力、PLMN 配置ngapInitUeMsgRecdgNB 收到 NG Setup Request 次数即 AMF 已介入应 ≈rrcConnEstabSucc× 0.95若远低于rrcConnEstabSucc说明 RRC 成功但 NG 流程未启动 → 查 NG 接口配置、AMF 可达性、TAI 列表匹配ngapUeContextRelCmdSentgNB 主动向 AMF 发送 UE Context Release Command 次数0 且突增即异常若此值激增说明 AMF 或 gNB 主动释放上下文 → 查 AMF 日志中的 Release Cause如Radio Network Unspecified、Protocol Error提示Raw Counter 必须设置为15 分钟粒度且时间窗严格对齐问题发生时段±2 分钟。我吃过亏用 1 小时粒度看“平均值”掩盖了凌晨 3:17–3:22 的集中失败爆发。2.2 用 Trace 抓取“失败会话全链路”三层过滤法锁定单条失败信令Raw Counter 只告诉你“坏了”Trace 才告诉你“怎么坏的”。在 ENM 中启动 Trace路径ENM → Monitoring → Trace → Start New Trace关键不是抓多少而是怎么过滤# 第一层按接口类型过滤必须选 - Interface: NGAP (gNB ↔ AMF) - Interface: S1AP (gNB ↔ MME, 仅双注册场景需开) - Interface: RRC (UE ↔ gNB, 必开) # 第二层按事件类型过滤避免海量无关消息 - Event Type: Initial UE Message (RRC Connection Request 触发点) - Event Type: UE Context Release Request (失败终点) - Event Type: Security Mode Command / Security Mode Complete (鉴权环节) # 第三层按失败原因码精准捕获最省时间 - Filter Expression (NGAP): ngap.cause.present radioNetwork ngap.cause.radioNetwork unspecified - Filter Expression (RRC): rrc.cause failureInRadioInterfaceProcedure逻辑说明第一层确保覆盖控制面全链路RRC→NGAP→S1AP不漏环节第二层聚焦初始接入和释放两个关键状态跃迁点跳过重配、测量等干扰消息第三层直接命中高频失败原因比如radioNetwork: unspecified在爱立信系统中实际多指 AMF 侧资源分配失败或 QoS 协商超时而非空口问题——这能立刻排除扫频、邻区漏配等传统优化手段。参数说明Trace Duration 建议设为10 分钟Buffer Size 设为2GBENM 默认 512MB 容易丢包。若目标小区话务量高务必勾选 “Include only messages matching filter” —— 否则 10 分钟 Trace 可能生成 8GB 原始文件解析崩溃。3. 解析 TRACE 日志不是读英文字段而是盯住 4 个关键 IE 和它们的时序关系拿到.pcap或.trc文件后Wireshark 是标配但爱立信自有工具如 Ericsson Trace Analyzer, ETA对私有 IE 解析更准。无论用哪个核心不是通读全文而是盯住以下 4 个 IEInformation Element及其出现顺序3.1 RRCConnectionRequest 中的ue-Identity确认 UE 是否被网络识别字段位置RRCConnectionRequest →ue-Identity→s-TMSI或randomValue若ue-Identity为randomValue随机数说明 UE 是首次接入或 TMSI 失效 → 此时后续流程必须走完整的 NAS 流程包括 Identity Request/Response若为s-TMSI但 AMF 无法解析查 AMF 日志可见Invalid s-TMSI说明 MME/AMF 间 TMSI 同步异常或 UE 保存了过期 TMSI → 需检查amf配置一致性及tmsi-reuse-timer参数。血泪经验某次深夜割接后大量接入失败Trace 显示 RRC 成功但 NG Setup 失败。最终发现是 AMF 的tmsi-reuse-timer从 30min 错配成 30s导致 UE 持有 TMSI 在 30 秒后即失效AMF 拒绝解析 —— 调回 1800s 立解。3.2 NGSetupRequest 中的GUAMI和Supported TA ListAMF 是否“认得”这个 gNB字段位置NGSetupRequest →GUAMIGlobal Unique AMF Identifier Supported TA ListTracking Area ListGUAMI必须与 gNB 配置的amf-name完全一致区分大小写Supported TA List中的 TAITracking Area Identity必须包含 gNB 所属 TA —— 若缺失AMF 直接返回NG Setup FailureCause unknown-plmn常见错误gNB 配置 TA 为222-01-000001但 AMF 中录入为222-01-1省略前导零导致匹配失败。3.3 SecurityModeCommand 中的securityAlgorithms加密/完整性算法协商失败的隐形杀手字段位置SecurityModeCommand →selectedSecurityAlgorithmgNB 发送的SecurityModeCommand中selectedSecurityAlgorithm字段必须在 UE 能力列表内由 UE 在UECapabilityEnquiry后上报若 UE 上报支持NEA0空加密但 gNB 强制要求NEA1则 UE 回SecurityModeRejectCause unspecified爱立信默认开启NEA1/NEA2但老旧终端如部分 Cat-M1 模组仅支持NEA0→ 需在 gNB 配置中显式允许NEA0参数securityAlgorithmConfig.nea0Allowed true。3.4 InitialContextSetupRequest 中的QosFlowSetupRequestListQoS 协商失败的终极陷阱字段位置InitialContextSetupRequest →QosFlowSetupRequestList→ 每个 QoS Flow 的qosFlowIdentifierqosParameters这是接入流程最后一步也是最容易被忽略的失败点若 AMF 请求的 QoS Profile如 5QI9在 gNB 本地策略中未定义qosProfile.5qi9未配置或qosProfile.5qi9.gbr设置为 0gNB 返回InitialContextSetupFailureCause radioNetwork: unspecified注意该失败不会触发 RRC 重建立UE 直接掉线KPI 统计为 ERAB 建立失败 —— 但 Raw Counter 中erabEstabAtt仍会计数导致成功率计算失真。玄学排查技巧当 Trace 中看到InitialContextSetupRequest发出但无InitialContextSetupResponse且无任何 Release 消息大概率是 gNB 侧 QoS 策略缺失。此时不要查 AMF 日志直接登录 gNB CLI 执行print qosProfile—— 确认所需 5QI 是否存在print qosPolicy—— 确认该 5QI 是否绑定到对应 DNN 或切片。4. 避坑接入优化中最常踩的 4 个“看似合理实则致命”的配置陷阱这份指导书的价值一半在教你怎么查一半在提前告诉你哪些“标准操作”会翻车。以下是我在 17 个局点交付中被重复踩过、且文档明确标注的 4 类高危配置4.1 “启用 NSA 回退”开关反而杀死 SA 接入现象SA 用户接入时延飙升至 8–12 秒RRC 建立成功但 NG Setup 失败率 100%。原因gNB 同时开启 NSAEN-DC和 SA 模式时若nsaFallbackEnabled truegNB 会在 RRC Connection Setup 后插入SCG-Addition流程即使 UE 不支持 NSA导致 RRC 连接挂起超时后主动释放。该流程与 SA 的 NG Setup 并行竞争资源且无优先级控制。解决纯 SA 网络必须设置nsaFallbackEnabled false并在 ENM 中确认enDcSupport disabled。注意该参数在 gNB 软件 R22 版本中默认为 false但 R21 及之前版本默认 true。4.2 “TAC 配置一致”不等于“TAI 列表一致”现象NG Setup Failure 频发Cause 显示unknown-plmn但 gNB 和 AMF 的 PLMN 配置完全相同。原因TACTracking Area Code是 16-bit 整数但 TAITracking Area Identity由 MCCMNCTAC 三元组构成。常见错误是AMF 中录入 TAI 为460-00-0001TAC1而 gNB 配置 TAC 为0001字符串或1整数ENM 内部解析时因格式不一致导致匹配失败。解决统一使用4 位十六进制字符串格式如0001并在 AMF 和 gNB 配置界面中手动输入禁止粘贴、禁止用 Excel 自动补零。4.3 “增大 RRC 连接定时器”治标不治本反致信令风暴现象RRC 建立成功率低工程师将rrcConnectionSetupTimer从 100ms 改为 500ms。原因该定时器仅控制 gNB 等待 UE 发送RRCConnectionSetupComplete的时长。若失败主因是空口质量差BLER 高延长定时器只会让 UE 在弱信号下反复重传 RRC 消息占用 PRB 资源加剧拥塞导致其他 UE 接入也失败。解决先查pdschBlerr和puschBlerrRaw Counter若 15%优先优化覆盖或调整 MCS 表而非改定时器。定时器仅用于排除短暂同步偏差非根本解。4.4 “关闭 X2 接口”以简化拓扑却阻断关键切换准备现象SA 用户在移动中频繁掉话Trace 显示 Handover Required 后无响应。原因即使纯 SA 网络X2 接口仍承担 gNB 间切换准备Handover Preparation、上下文转发UE Context Transfer等关键功能。关闭 X2 后gNB 无法预同步目标小区导致切换失败率陡升。解决X2 接口必须开启且x2LinkStatus在 ENM 中显示UP。若因传输限制无法全量互通至少保证相邻 gNB 间 X2 链路可达并配置x2BlackList排除非邻区。5. 验证优化效果不用等 24 小时 KPI用 3 个实时指标 15 分钟内闭环优化不是改完参数就结束。真正的闭环是在改参后 15 分钟内用三个可实时观测的指标交叉验证而不是苦等第二天的日报。这是爱立信一线工程师的硬核习惯。5.1 实时信令成功率用 ENM 的 “Live Trace” 功能秒级观测ENM 提供 Live Trace路径ENM → Monitoring → Trace → Live Trace无需启动完整 Trace即可实时查看指定接口的信令收发成功率启动 Live TraceFilter 设为InterfaceNGAP,Event TypeInitial UE Message观察右上角 “Success Rate” 曲线默认统计最近 60 秒优化前成功率在 40%–60% 波动优化后15 秒内应稳定升至 95%且无尖峰跌落为什么可信Live Trace 统计的是原始消息级成功收到Initial UE Message且后续有UE Context Setup响应绕过 KPI 计算引擎的聚合延迟与异常过滤是真正的“第一手心跳”。5.2 UE 状态驻留时间分布用 Raw Counter 的ueStateDuration揭露隐性问题查 Raw CounterueStateDuration单位秒按 UE 状态分组RRC_IDLE, RRC_INACTIVE, RRC_CONNECTED优化前RRC_CONNECTED的平均驻留时间 30 秒说明接入后很快掉线优化后RRC_CONNECTED平均驻留时间应 ≥ 120 秒且RRC_INACTIVE比例显著上升表明 Inactive 状态保持成功关键看分布若RRC_CONNECTED时间集中在 1–5 秒区间说明InitialContextSetup或PDU Session Establishment层失败 —— 需回溯查 QoS 或 SMF 配置。5.3 AMF 侧 “UE Context Created” 与 gNB 侧 “RRC Connected” 的数量比揪出跨网元丢帧在 ENM 中同时打开两个 Raw Counter 视图gNB 侧rrcConnEstabSuccRRC 连接成功数AMF 侧ueContextCreatedAMF 创建 UE Context 次数正常比值应为0.97–0.995因少量 UE 在 RRC 成功后立即发起 Service RequestAMF 未及时创建 Context若比值 0.9说明 AMF 侧大量 UE Context 创建失败 → 查 AMF 日志中的ueContextCreationFailureCause常见为insufficientResources或plmnNotAllowed若比值 1.0说明 gNB 侧虚报 RRC 成功如空口误检→ 查rrcConnEstabFail中的failureInRadioInterfaceProcedure子类我坚持一个原则任何优化动作必须在这三个指标中至少两个达成预期才算真正生效。单看 KPI 报表等于蒙眼开车——报表里“成功率 98%”可能只是把失败用户均匀摊到 24 小时里而真实业务高峰时段仍是 60%。用实时指标才能把优化钉死在“此刻”。希望帮到你。本文还有配套的精品资源点击获取