尧图网页设计 
简介《SDCU NSA移动性能分析优化指导书》面向5G网络优化工程师与移动性分析人员聚焦NSA非独立组网场景下的切换性能问题由爱立信专家Cassie Song编制。内容从3GPP规定的NSA切换信令流程与爱立信实现机制切入系统梳理切换KPI定义、NR侧counters打点机制、锚点关系与NR邻区关系参数配置并延伸至前台空口信令解析、常见问题解决措施及网管侧切换性能分析流程涵盖外部数据定义不一致、邻区参数设置错误、NR邻区漏配等典型失败原因。资源为1个PDF文件压缩包约5.07MB结构按修订记录、信令流程、指标定义、参数说明、信令分析、网管分析等章节编排便于按模块查阅。已有203人学习。读者可借此掌握NSA切换的完整分析链路与参数调优方法用于日常性能监控、问题定位与故障排查提升网络稳定性与用户感知。1. 从一份 51 页的 NSA 移动性文档说起它到底能解决什么做 5G 网优的同行大概率都经历过这种场景NSA 组网下用户从 A 站移动到 B 站LTE 侧切换成功了但 NR 侧的辅节点变更死活起不来或者变更成功率突然从 99% 掉到 70% 多查了一整天 counters 也没定位到根因。这份《SDCU NSA 移动性能分析优化指导书》就是冲着这类问题来的——它把 NSA 切换的信令流程、KPI 定义、counter 打点机制、参数配置、前台信令解析、网管侧分析流程和典型案例串成了一条完整的排查链路。文档面向具备 NR 基础知识的 NDO 优化人员针对 MTR20.37 基站版本网络编写覆盖锚点关系、NR 邻区关系、X2 链路、外部数据一致性等核心问题域。如果你正在做 NSA 移动性优化或者被 SN 变更成功率、PSCell 变更失败这类指标卡住这份材料值得逐页拆一遍。2. NSA 切换信令流程从 3GPP 到爱立信实现2.1 三种移动性场景的信令差异NSA 的移动性和纯 LTE 最大的区别在于UE 同时挂在 LTE 主节点和 NR 辅节点上移动时可能只换主站、只换辅站、或者两个一起换。文档把 3GPP 37.340 第 10.5 和 10.7 章节定义的流程拆成了三类。第一类是 MN 触发的 SgNB 变更。源 MN 先通过 SgNB Addition Request 向目标 SN 申请资源目标 SN 回复 Acknowledge 并提供转发地址然后 MN 发起源 SN 释放接着通过 RRCConnectionReconfiguration 把目标 SN 的 NR RRC 配置下发给 UE。UE 应用新配置后回复 CompleteMN 再通过 SgNB Reconfiguration Complete 通知目标 SN。后续还有 SN Status Transfer、数据转发、路径更新等步骤。第二类是 SN 触发的 SgNB 变更。区别在于第一步是源 SN 主动发 SgNB Change Required 给 MN消息里带目标 SN ID 和测量结果。MN 收到后走类似的 SgNB Addition 流程后续步骤和 MN 触发的场景基本一致。第三类是 MN 间切换。源 MN 通过 X2 发起 Handover Request目标 MN 决定是保留 SN 还是变更 SN。如果保留目标 MN 向同一个 SN 发 SN Addition Request如果变更则向目标 SN 发请求。切换完成后目标 MN 启动 S1 Path Switch源 MN 发起 UE Context Release。这三类流程的差异直接决定了你在 counters 上看到的现象不同。比如 MN 间切换失败问题可能在 X2 链路SN 变更失败问题更可能在 NR 邻区关系或锚点关系配置上。2.2 爱立信实现中的两个关键分支文档第 2.2 节把爱立信的具体实现分成了 LTE 覆盖触发和 NR 覆盖触发两条路径。LTE 覆盖触发的流程是eNodeB 收到 A3 或 A5 事件上报 → 发起 SN 释放含 SCG 释放→ 执行 LTE 内同频或异频切换 → 如果目标 LTE 小区支持 EN-DC配置 B1 测量 → 收到 B1 上报 → 发起 SN 添加。这个流程的核心逻辑是LTE 锚点先切过去NR 辅节点先释放再重建。NR 覆盖触发的流程是gNodeB 通过 eNodeB 转发收到 NR A3 事件 → 服务 SN 启动 PSCell 更改。这里有两个硬性条件目标小区必须在服务 SN 中配置了邻区关系且 NRCellRelation.isHoAllowed 必须为 true。如果 A3 上报的 PCI 没有对应邻区关系或者 isHoAllowed 为 falsePSCell 更改就无法启动。此时系统根据 ReportConfigA3.endcActionA3EvalFail 的设置决定行为设为 IGNORE 则保持现有 EN-DC 配置不变设为 RELEASE 则触发 SN 释放并让 eNodeB 配置 B1 测量。注意NR 邻区关系可以手动配置也可以通过 ANR 自动添加。当前版本开启 ANR 时需要先配置锚点站与 NR 站之间的 X2 链路否则 ANR 无法正常工作。3. 切换 KPI 与 Counter 打点指标异常时先看哪里3.1 切换 KPI 的定义与计算逻辑NSA 切换相关的 KPI 主要围绕 SN 变更成功率和 MN 切换成功率展开。文档第 3.1 节给出了 KPI 定义核心指标包括SN 变更尝试次数、SN 变更成功次数、SN 变更成功率、MN 切换尝试次数、MN 切换成功次数等。这些指标的分母和分子直接对应 NR 侧和 LTE 侧的 counter 打点。实际优化中最常盯的是 SN 变更成功率。这个指标低可能的原因域很宽邻区漏配、锚点关系漏配、参数不合理、X2 链路故障、无线环境恶化。所以单看 KPI 数值不够必须下钻到 counter 级别。3.2 NR 侧 counters 的打点机制文档第 3.2 节详细说明了 NR 侧切换相关 counters 及打点机制。这些 counter 分布在不同的信令节点上对应切换流程的各个步骤。比如 SgNB Addition Request 的发送和响应、RRCConnectionReconfiguration 的下发和完成、随机接入过程的结果等每个环节都有对应的 counter 记录成功或失败。排查时的基本思路是先看 SN 变更成功率的整体趋势然后按 counter 逐层下钻。如果 SgNB Addition Request 的失败次数高问题可能在目标 SN 的资源分配或 X2 链路如果 RRCConnectionReconfiguration 完成率低问题可能在空口质量或 UE 侧配置冲突如果随机接入失败率高问题可能在目标小区的覆盖或干扰。提示文档第 6.1.1 节列出了问题定位常用的 CTR Events这些事件是网管侧分析的核心工具。建议先把这些 Event 的触发条件和对应信令节点搞清楚再去查 counters效率会高很多。4. 参数配置与邻区关系锚点、NR 邻区、X2 链路4.1 锚点关系与 NR 邻区关系参数文档第 4 章把 NSA 切换相关参数分成了锚点关系和 NR 邻区关系两大类。锚点关系决定了 LTE 小区和 NR 小区之间的绑定关系。在 NSA 组网中UE 必须通过 LTE 锚点站才能接入 NR 辅节点。如果锚点关系漏配UE 移动到新区域后无法建立 EN-DC表现为 SN 添加失败或 SN 变更无法发起。NR 邻区关系参数定义了 NR 小区之间的相邻关系。核心参数是 NRCellRelation 对象下的 isHoAllowed它控制是否允许向该邻区发起切换。如果 isHoAllowed 为 false即使 UE 上报了 A3 事件PSCell 更改也不会启动。文档第 4.2 节还提到了 NRCellRelation 的 MO 结构NRCellRelation 是 NRCellCU 的子 MO站内关系指向本站另一个 NRCellCU站间关系指向 ExternalNRCellCU。这个结构决定了你在配置邻区时需要在哪个层级操作。4.2 外部数据定义一致性与 X2 链路检查外部数据定义不一致是 NSA 切换失败的常见原因之一。具体来说当源侧和目标侧对同一个 NR 小区的 PCI、频点、TAC 等参数定义不一致时切换流程会在信令交互阶段就失败。文档第 6.2.1 节把这个问题单独列出来说明它在现网中出现的频率不低。X2 链路问题同样关键。NSA 架构下LTE 锚点站和 NR 站之间需要 X2 接口传递切换信令。如果 X2 链路不通或者质量差站间 SN 变更就会失败。文档第 6.2.7 节和第 7.4 节的 Case1 都涉及 X2 接口问题导致站间变更失败。检查 X2 链路的基本步骤# 在网管侧检查 X2 链路状态以常见操作路径为例 # 1. 查看 X2 接口的建立状态 x2_link_status --localenodeb_A --peergnodeb_B # 2. 检查 X2 链路的传输质量指标 x2_link_quality --localenodeb_A --peergnodeb_B --metricslatency,packet_loss # 3. 如果链路异常查看告警和日志 alarm_list --neenodeb_A --filterx2上面命令是示意性的操作路径实际网管命令取决于你使用的 OSS 平台。核心逻辑是先确认 X2 链路是否建立再看传输质量是否达标最后查告警确认是否有硬件或配置问题。5. 前台信令分析与网管侧排查从现象到根因5.1 空口信令解析的关键节点文档第 5.1 节讲空口信令解析这是前台优化的基本功。NSA 切换过程中空口上最关键的信令节点包括测量报告A3/B1、RRCConnectionReconfiguration、RRCConnectionReconfigurationComplete、随机接入前导和响应。看空口信令时重点确认几件事UE 是否上报了正确的测量事件、eNodeB 是否下发了重配置消息、UE 是否成功应用了新配置、随机接入是否在目标小区完成。如果某个环节断了问题就定位在那个节点上。文档第 5.2 节列出了常见问题及解决措施把空口信令分析和具体措施对应起来。比如 UE 上报了 A3 但 PSCell 更改没启动就要去查 NR 邻区关系和 isHoAllowed 参数重配置消息下发后 UE 没回复 Complete就要查空口质量和 UE 侧配置。5.2 网管侧切换问题常规分析流程文档第 6.1 节给出了网管侧切换问题的常规分析流程。基本步骤是确认问题现象哪个 KPI 异常、什么时间段、影响范围→ 提取相关 counters 和 CTR Events → 关联信令流程定位失败节点 → 检查参数配置和外部数据 → 输出根因和解决方案。文档第 6.2 节把常见切换失败原因归纳为八类外部数据定义不一致、邻区参数设置错误、NR 邻区漏配、锚点关系漏配、切换参数设置不合理、无线环境引起的切换异常、X2 链路问题、NSA 与 SA 边界问题。每一类都有对应的排查方法和解决措施。提示文档第 8 章附录 1 给出了基于 5G CTR 数据分析站间变更失败的完整操作流程建议在实操时对照这个附录一步步走能少走很多弯路。6. 避坑与常见问题那些文档里没明说但一定会遇到的坑6.1 锚点关系漏配导致变更成功率低现象SN 变更成功率突然下降但 counters 显示 SgNB Addition Request 的失败次数并不高失败集中在后续步骤。原因锚点关系漏配。UE 移动到新区域后LTE 锚点站和 NR 站之间的绑定关系没有配置导致 SN 添加或变更流程在中间步骤失败。解决检查源侧和目标侧的锚点关系配置确认所有涉及切换的 LTE 小区和 NR 小区之间都有正确的锚点关系。文档第 7.1 节的 Case1 就是这个问题排查时重点看锚点关系 MO 是否完整。6.2 NR 邻区漏配导致不发起 SN 变更现象UE 上报了 NR A3 事件但 PSCell 更改始终不启动SN 变更尝试次数为零。原因目标 NR 小区没有配置邻区关系或者 NRCellRelation.isHoAllowed 为 false。文档第 2.2 节明确说了这两个条件必须同时满足才能启动 PSCell 更改。解决检查 NRCellRelation 配置确认目标小区的邻区关系存在且 isHoAllowed 为 true。如果是站间关系还要确认 ExternalNRCellCU 的定义是否正确。文档第 7.3 节的 Case1 就是 NR 邻区漏配导致不发起 SN 变更。6.3 外部数据定义不一致导致变更失败现象切换流程在信令交互阶段就失败counters 显示 SgNB Addition Request 被拒绝或超时。原因源侧和目标侧对同一个 NR 小区的 PCI、频点、TAC 等参数定义不一致。文档第 6.2.1 节和第 7.2 节的 Case1 都涉及这个问题。解决逐项核对源侧和目标侧的外部数据定义确保 PCI、频点、TAC、小区标识等参数完全一致。这类问题在跨厂家组网时尤其常见。6.4 X2 链路问题导致站间变更失败现象站内切换正常站间切换失败率明显偏高。原因X2 链路不通、传输质量差、或者 X2 接口的配置参数不匹配。文档第 7.4 节的 Case1 就是 X2 接口问题导致站间变更失败。解决检查 X2 链路的建立状态和传输质量指标确认没有告警。如果链路正常但切换仍失败检查 X2 接口的应用层配置比如端点地址、端口号、协议版本等。6.5 NSA 与 SA 边界问题现象在 NSA 和 SA 覆盖边界区域切换成功率下降UE 可能出现掉话或重建。原因NSA 和 SA 的移动性管理机制不同边界区域的参数配置如果没有协调好UE 在两种模式之间切换时容易出问题。文档第 6.2.8 节提到了这个问题。解决检查边界区域的 NSA 和 SA 参数配置确保切换门限、邻区关系、锚点关系等参数协调一致。必要时调整边界区域的覆盖或切换策略。7. 从 CTR 数据到根因定位一个可复用的分析套路文档第 8 章附录 1 给出了基于 5G CTR 数据分析站间变更失败的操作流程这是整份文档里最实操的部分。我把它提炼成一个可复用的分析套路配合具体操作步骤。第一步提取 CTR 数据。在网管侧按时间段和小区范围提取 SN 变更相关的 CTR Events。重点关注的 Event 包括SgNB Addition Request、SgNB Addition Request Acknowledge、RRCConnectionReconfiguration、RRCConnectionReconfigurationComplete、Random Access Procedure。第二步按信令节点统计失败分布。把 CTR 数据按信令节点分组看失败集中在哪个环节。如果失败集中在 SgNB Addition Request问题可能在目标 SN 或 X2 链路如果集中在 RRCConnectionReconfigurationComplete问题可能在空口或 UE 侧。# 示意性代码按信令节点统计失败分布 # 实际数据格式取决于网管导出格式这里用通用结构演示 ctr_events [ {event: SgNB_Addition_Request, result: success, count: 1200}, {event: SgNB_Addition_Request, result: fail, count: 45}, {event: RRC_Reconfig, result: success, count: 1180}, {event: RRC_Reconfig, result: fail, count: 65}, {event: Random_Access, result: success, count: 1150}, {event: Random_Access, result: fail, count: 95}, ] # 按事件类型汇总失败率 from collections import defaultdict stats defaultdict(lambda: {success: 0, fail: 0}) for e in ctr_events: stats[e[event]][e[result]] e[count] for event, s in stats.items(): total s[success] s[fail] fail_rate s[fail] / total * 100 if total 0 else 0 print(f{event}: 失败率 {fail_rate:.1f}% ({s[fail]}/{total}))这段代码的逻辑是按信令节点汇总成功和失败次数计算每个节点的失败率。参数说明ctr_events 是从网管导出的 CTR 数据实际使用时需要根据导出格式做字段映射。输出结果能快速告诉你哪个信令节点的失败率最高从而缩小排查范围。第三步关联参数配置和外部数据。根据失败集中的信令节点检查对应的参数配置。如果失败在 SgNB Addition Request检查目标 SN 的邻区关系和锚点关系如果失败在 Random Access检查目标小区的覆盖和干扰。第四步输出根因和解决方案。把排查结果整理成文档包括问题现象、影响范围、根因分析、解决方案和验证结果。文档第 7 章的四个典型案例就是很好的参考模板。从那以后我每次遇到 NSA 切换问题都强制走一遍这个流程先提 CTR 数据再按信令节点统计失败分布然后关联参数配置最后输出根因。这套方法不一定能解决所有问题但至少能保证排查过程是可复现的不会漏掉关键环节。希望帮到你。本文还有配套的精品资源点击获取 NSA移动性优化实战：SN变更成功率与切换失败根因分析
简介《SDCU NSA移动性能分析优化指导书》面向5G网络优化工程师与移动性分析人员聚焦NSA非独立组网场景下的切换性能问题由爱立信专家Cassie Song编制。内容从3GPP规定的NSA切换信令流程与爱立信实现机制切入系统梳理切换KPI定义、NR侧counters打点机制、锚点关系与NR邻区关系参数配置并延伸至前台空口信令解析、常见问题解决措施及网管侧切换性能分析流程涵盖外部数据定义不一致、邻区参数设置错误、NR邻区漏配等典型失败原因。资源为1个PDF文件压缩包约5.07MB结构按修订记录、信令流程、指标定义、参数说明、信令分析、网管分析等章节编排便于按模块查阅。已有203人学习。读者可借此掌握NSA切换的完整分析链路与参数调优方法用于日常性能监控、问题定位与故障排查提升网络稳定性与用户感知。1. 从一份 51 页的 NSA 移动性文档说起它到底能解决什么做 5G 网优的同行大概率都经历过这种场景NSA 组网下用户从 A 站移动到 B 站LTE 侧切换成功了但 NR 侧的辅节点变更死活起不来或者变更成功率突然从 99% 掉到 70% 多查了一整天 counters 也没定位到根因。这份《SDCU NSA 移动性能分析优化指导书》就是冲着这类问题来的——它把 NSA 切换的信令流程、KPI 定义、counter 打点机制、参数配置、前台信令解析、网管侧分析流程和典型案例串成了一条完整的排查链路。文档面向具备 NR 基础知识的 NDO 优化人员针对 MTR20.37 基站版本网络编写覆盖锚点关系、NR 邻区关系、X2 链路、外部数据一致性等核心问题域。如果你正在做 NSA 移动性优化或者被 SN 变更成功率、PSCell 变更失败这类指标卡住这份材料值得逐页拆一遍。2. NSA 切换信令流程从 3GPP 到爱立信实现2.1 三种移动性场景的信令差异NSA 的移动性和纯 LTE 最大的区别在于UE 同时挂在 LTE 主节点和 NR 辅节点上移动时可能只换主站、只换辅站、或者两个一起换。文档把 3GPP 37.340 第 10.5 和 10.7 章节定义的流程拆成了三类。第一类是 MN 触发的 SgNB 变更。源 MN 先通过 SgNB Addition Request 向目标 SN 申请资源目标 SN 回复 Acknowledge 并提供转发地址然后 MN 发起源 SN 释放接着通过 RRCConnectionReconfiguration 把目标 SN 的 NR RRC 配置下发给 UE。UE 应用新配置后回复 CompleteMN 再通过 SgNB Reconfiguration Complete 通知目标 SN。后续还有 SN Status Transfer、数据转发、路径更新等步骤。第二类是 SN 触发的 SgNB 变更。区别在于第一步是源 SN 主动发 SgNB Change Required 给 MN消息里带目标 SN ID 和测量结果。MN 收到后走类似的 SgNB Addition 流程后续步骤和 MN 触发的场景基本一致。第三类是 MN 间切换。源 MN 通过 X2 发起 Handover Request目标 MN 决定是保留 SN 还是变更 SN。如果保留目标 MN 向同一个 SN 发 SN Addition Request如果变更则向目标 SN 发请求。切换完成后目标 MN 启动 S1 Path Switch源 MN 发起 UE Context Release。这三类流程的差异直接决定了你在 counters 上看到的现象不同。比如 MN 间切换失败问题可能在 X2 链路SN 变更失败问题更可能在 NR 邻区关系或锚点关系配置上。2.2 爱立信实现中的两个关键分支文档第 2.2 节把爱立信的具体实现分成了 LTE 覆盖触发和 NR 覆盖触发两条路径。LTE 覆盖触发的流程是eNodeB 收到 A3 或 A5 事件上报 → 发起 SN 释放含 SCG 释放→ 执行 LTE 内同频或异频切换 → 如果目标 LTE 小区支持 EN-DC配置 B1 测量 → 收到 B1 上报 → 发起 SN 添加。这个流程的核心逻辑是LTE 锚点先切过去NR 辅节点先释放再重建。NR 覆盖触发的流程是gNodeB 通过 eNodeB 转发收到 NR A3 事件 → 服务 SN 启动 PSCell 更改。这里有两个硬性条件目标小区必须在服务 SN 中配置了邻区关系且 NRCellRelation.isHoAllowed 必须为 true。如果 A3 上报的 PCI 没有对应邻区关系或者 isHoAllowed 为 falsePSCell 更改就无法启动。此时系统根据 ReportConfigA3.endcActionA3EvalFail 的设置决定行为设为 IGNORE 则保持现有 EN-DC 配置不变设为 RELEASE 则触发 SN 释放并让 eNodeB 配置 B1 测量。注意NR 邻区关系可以手动配置也可以通过 ANR 自动添加。当前版本开启 ANR 时需要先配置锚点站与 NR 站之间的 X2 链路否则 ANR 无法正常工作。3. 切换 KPI 与 Counter 打点指标异常时先看哪里3.1 切换 KPI 的定义与计算逻辑NSA 切换相关的 KPI 主要围绕 SN 变更成功率和 MN 切换成功率展开。文档第 3.1 节给出了 KPI 定义核心指标包括SN 变更尝试次数、SN 变更成功次数、SN 变更成功率、MN 切换尝试次数、MN 切换成功次数等。这些指标的分母和分子直接对应 NR 侧和 LTE 侧的 counter 打点。实际优化中最常盯的是 SN 变更成功率。这个指标低可能的原因域很宽邻区漏配、锚点关系漏配、参数不合理、X2 链路故障、无线环境恶化。所以单看 KPI 数值不够必须下钻到 counter 级别。3.2 NR 侧 counters 的打点机制文档第 3.2 节详细说明了 NR 侧切换相关 counters 及打点机制。这些 counter 分布在不同的信令节点上对应切换流程的各个步骤。比如 SgNB Addition Request 的发送和响应、RRCConnectionReconfiguration 的下发和完成、随机接入过程的结果等每个环节都有对应的 counter 记录成功或失败。排查时的基本思路是先看 SN 变更成功率的整体趋势然后按 counter 逐层下钻。如果 SgNB Addition Request 的失败次数高问题可能在目标 SN 的资源分配或 X2 链路如果 RRCConnectionReconfiguration 完成率低问题可能在空口质量或 UE 侧配置冲突如果随机接入失败率高问题可能在目标小区的覆盖或干扰。提示文档第 6.1.1 节列出了问题定位常用的 CTR Events这些事件是网管侧分析的核心工具。建议先把这些 Event 的触发条件和对应信令节点搞清楚再去查 counters效率会高很多。4. 参数配置与邻区关系锚点、NR 邻区、X2 链路4.1 锚点关系与 NR 邻区关系参数文档第 4 章把 NSA 切换相关参数分成了锚点关系和 NR 邻区关系两大类。锚点关系决定了 LTE 小区和 NR 小区之间的绑定关系。在 NSA 组网中UE 必须通过 LTE 锚点站才能接入 NR 辅节点。如果锚点关系漏配UE 移动到新区域后无法建立 EN-DC表现为 SN 添加失败或 SN 变更无法发起。NR 邻区关系参数定义了 NR 小区之间的相邻关系。核心参数是 NRCellRelation 对象下的 isHoAllowed它控制是否允许向该邻区发起切换。如果 isHoAllowed 为 false即使 UE 上报了 A3 事件PSCell 更改也不会启动。文档第 4.2 节还提到了 NRCellRelation 的 MO 结构NRCellRelation 是 NRCellCU 的子 MO站内关系指向本站另一个 NRCellCU站间关系指向 ExternalNRCellCU。这个结构决定了你在配置邻区时需要在哪个层级操作。4.2 外部数据定义一致性与 X2 链路检查外部数据定义不一致是 NSA 切换失败的常见原因之一。具体来说当源侧和目标侧对同一个 NR 小区的 PCI、频点、TAC 等参数定义不一致时切换流程会在信令交互阶段就失败。文档第 6.2.1 节把这个问题单独列出来说明它在现网中出现的频率不低。X2 链路问题同样关键。NSA 架构下LTE 锚点站和 NR 站之间需要 X2 接口传递切换信令。如果 X2 链路不通或者质量差站间 SN 变更就会失败。文档第 6.2.7 节和第 7.4 节的 Case1 都涉及 X2 接口问题导致站间变更失败。检查 X2 链路的基本步骤# 在网管侧检查 X2 链路状态以常见操作路径为例 # 1. 查看 X2 接口的建立状态 x2_link_status --localenodeb_A --peergnodeb_B # 2. 检查 X2 链路的传输质量指标 x2_link_quality --localenodeb_A --peergnodeb_B --metricslatency,packet_loss # 3. 如果链路异常查看告警和日志 alarm_list --neenodeb_A --filterx2上面命令是示意性的操作路径实际网管命令取决于你使用的 OSS 平台。核心逻辑是先确认 X2 链路是否建立再看传输质量是否达标最后查告警确认是否有硬件或配置问题。5. 前台信令分析与网管侧排查从现象到根因5.1 空口信令解析的关键节点文档第 5.1 节讲空口信令解析这是前台优化的基本功。NSA 切换过程中空口上最关键的信令节点包括测量报告A3/B1、RRCConnectionReconfiguration、RRCConnectionReconfigurationComplete、随机接入前导和响应。看空口信令时重点确认几件事UE 是否上报了正确的测量事件、eNodeB 是否下发了重配置消息、UE 是否成功应用了新配置、随机接入是否在目标小区完成。如果某个环节断了问题就定位在那个节点上。文档第 5.2 节列出了常见问题及解决措施把空口信令分析和具体措施对应起来。比如 UE 上报了 A3 但 PSCell 更改没启动就要去查 NR 邻区关系和 isHoAllowed 参数重配置消息下发后 UE 没回复 Complete就要查空口质量和 UE 侧配置。5.2 网管侧切换问题常规分析流程文档第 6.1 节给出了网管侧切换问题的常规分析流程。基本步骤是确认问题现象哪个 KPI 异常、什么时间段、影响范围→ 提取相关 counters 和 CTR Events → 关联信令流程定位失败节点 → 检查参数配置和外部数据 → 输出根因和解决方案。文档第 6.2 节把常见切换失败原因归纳为八类外部数据定义不一致、邻区参数设置错误、NR 邻区漏配、锚点关系漏配、切换参数设置不合理、无线环境引起的切换异常、X2 链路问题、NSA 与 SA 边界问题。每一类都有对应的排查方法和解决措施。提示文档第 8 章附录 1 给出了基于 5G CTR 数据分析站间变更失败的完整操作流程建议在实操时对照这个附录一步步走能少走很多弯路。6. 避坑与常见问题那些文档里没明说但一定会遇到的坑6.1 锚点关系漏配导致变更成功率低现象SN 变更成功率突然下降但 counters 显示 SgNB Addition Request 的失败次数并不高失败集中在后续步骤。原因锚点关系漏配。UE 移动到新区域后LTE 锚点站和 NR 站之间的绑定关系没有配置导致 SN 添加或变更流程在中间步骤失败。解决检查源侧和目标侧的锚点关系配置确认所有涉及切换的 LTE 小区和 NR 小区之间都有正确的锚点关系。文档第 7.1 节的 Case1 就是这个问题排查时重点看锚点关系 MO 是否完整。6.2 NR 邻区漏配导致不发起 SN 变更现象UE 上报了 NR A3 事件但 PSCell 更改始终不启动SN 变更尝试次数为零。原因目标 NR 小区没有配置邻区关系或者 NRCellRelation.isHoAllowed 为 false。文档第 2.2 节明确说了这两个条件必须同时满足才能启动 PSCell 更改。解决检查 NRCellRelation 配置确认目标小区的邻区关系存在且 isHoAllowed 为 true。如果是站间关系还要确认 ExternalNRCellCU 的定义是否正确。文档第 7.3 节的 Case1 就是 NR 邻区漏配导致不发起 SN 变更。6.3 外部数据定义不一致导致变更失败现象切换流程在信令交互阶段就失败counters 显示 SgNB Addition Request 被拒绝或超时。原因源侧和目标侧对同一个 NR 小区的 PCI、频点、TAC 等参数定义不一致。文档第 6.2.1 节和第 7.2 节的 Case1 都涉及这个问题。解决逐项核对源侧和目标侧的外部数据定义确保 PCI、频点、TAC、小区标识等参数完全一致。这类问题在跨厂家组网时尤其常见。6.4 X2 链路问题导致站间变更失败现象站内切换正常站间切换失败率明显偏高。原因X2 链路不通、传输质量差、或者 X2 接口的配置参数不匹配。文档第 7.4 节的 Case1 就是 X2 接口问题导致站间变更失败。解决检查 X2 链路的建立状态和传输质量指标确认没有告警。如果链路正常但切换仍失败检查 X2 接口的应用层配置比如端点地址、端口号、协议版本等。6.5 NSA 与 SA 边界问题现象在 NSA 和 SA 覆盖边界区域切换成功率下降UE 可能出现掉话或重建。原因NSA 和 SA 的移动性管理机制不同边界区域的参数配置如果没有协调好UE 在两种模式之间切换时容易出问题。文档第 6.2.8 节提到了这个问题。解决检查边界区域的 NSA 和 SA 参数配置确保切换门限、邻区关系、锚点关系等参数协调一致。必要时调整边界区域的覆盖或切换策略。7. 从 CTR 数据到根因定位一个可复用的分析套路文档第 8 章附录 1 给出了基于 5G CTR 数据分析站间变更失败的操作流程这是整份文档里最实操的部分。我把它提炼成一个可复用的分析套路配合具体操作步骤。第一步提取 CTR 数据。在网管侧按时间段和小区范围提取 SN 变更相关的 CTR Events。重点关注的 Event 包括SgNB Addition Request、SgNB Addition Request Acknowledge、RRCConnectionReconfiguration、RRCConnectionReconfigurationComplete、Random Access Procedure。第二步按信令节点统计失败分布。把 CTR 数据按信令节点分组看失败集中在哪个环节。如果失败集中在 SgNB Addition Request问题可能在目标 SN 或 X2 链路如果集中在 RRCConnectionReconfigurationComplete问题可能在空口或 UE 侧。# 示意性代码按信令节点统计失败分布 # 实际数据格式取决于网管导出格式这里用通用结构演示 ctr_events [ {event: SgNB_Addition_Request, result: success, count: 1200}, {event: SgNB_Addition_Request, result: fail, count: 45}, {event: RRC_Reconfig, result: success, count: 1180}, {event: RRC_Reconfig, result: fail, count: 65}, {event: Random_Access, result: success, count: 1150}, {event: Random_Access, result: fail, count: 95}, ] # 按事件类型汇总失败率 from collections import defaultdict stats defaultdict(lambda: {success: 0, fail: 0}) for e in ctr_events: stats[e[event]][e[result]] e[count] for event, s in stats.items(): total s[success] s[fail] fail_rate s[fail] / total * 100 if total 0 else 0 print(f{event}: 失败率 {fail_rate:.1f}% ({s[fail]}/{total}))这段代码的逻辑是按信令节点汇总成功和失败次数计算每个节点的失败率。参数说明ctr_events 是从网管导出的 CTR 数据实际使用时需要根据导出格式做字段映射。输出结果能快速告诉你哪个信令节点的失败率最高从而缩小排查范围。第三步关联参数配置和外部数据。根据失败集中的信令节点检查对应的参数配置。如果失败在 SgNB Addition Request检查目标 SN 的邻区关系和锚点关系如果失败在 Random Access检查目标小区的覆盖和干扰。第四步输出根因和解决方案。把排查结果整理成文档包括问题现象、影响范围、根因分析、解决方案和验证结果。文档第 7 章的四个典型案例就是很好的参考模板。从那以后我每次遇到 NSA 切换问题都强制走一遍这个流程先提 CTR 数据再按信令节点统计失败分布然后关联参数配置最后输出根因。这套方法不一定能解决所有问题但至少能保证排查过程是可复现的不会漏掉关键环节。希望帮到你。本文还有配套的精品资源点击获取