深度解析 3GPP TS 38.423：8.3.15 - 8.3.18 双连接下的故障诊断与善后
本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“8.3.15 Deactivate Trace”、“8.3.16 Cell Traffic Trace”、“8.3.17 SCG Failure Information Report”以及“8.3.18 SCG Failure Transfer”这四个核心章节。本文旨在将这些在双连接（DC）运维与故障处理中扮演关键角色的流程进行整合解读，为读者揭示5G网络如何实现精细化的故障诊断、数据收集与经验总结。
1. 引言：从“CT扫描”到“病理分析报告”
在上一篇文章中，为了解决电竞玩家“小张”的偶发性游戏卡顿问题，工程师小林在他的导师陈工的指导下，学习了如何使用Trace Start流程，为小张的UE启动了一次跨越主从节点（MN/SN）的、详尽的信令与数据“CT扫描”。
现在，预设的跟踪时长已经结束，或者运维人员已经成功捕捉到了几次卡顿事件。小林问道：“陈工，我们已经收集到了足够的数据。接下来该做什么？是不是应该让基站停止这种高负荷的记录工作了？另外，我们从Trace日志中发现，卡顿确实与次小区组（SCG）的瞬时链路失败有关。网络在失败发生后，会做些什么来‘复盘’和‘总结教训’吗？”
“非常好的问题，你已经触及了运维工作的完整闭环：诊断 → 停止诊断 → 分析 → 总结 → 优化。”陈工回答道，“Trace Start只是开启了‘CT扫描’，我们当然需要一个指令来结束它。这就是**Deactivate Trace。同时，除了针对个体的精密诊断，我们还有对小区‘群体健康’进行普查的工具，那就是Cell Traffic Trace**。”
“更重要的是，”陈工的语气变得严肃起来，“当一次SCG失败真实发生后，网络并不会‘假装无事发生’。MN和SN之间会上演一场‘事后复盘’。MN会向SN发出一份详细的‘事故报告’——SCG Failure Information Report，告诉SN‘你负责的这条链路出问题了，这是详细情况’，以便SN进行自我优化。在某些情况下，如果SN认为‘事故’的根本原因不在自己，它还会向MN发出一份‘申诉’——SCG Failure Transfer，暗示‘问题可能出在你那边或中间环节’。这些流程，共同构成了双连接故障后的‘病理分析’与‘责任厘清’机制。”
今天，我们就来学习这套完整的故障诊断与善后工具链，看看5G网络是如何从每一次失败中学习和成长的。
2. 8.3.15 Deactivate Trace - “CT扫描”的结束指令
这是Trace Start流程的必然配对。它的功能单一而明确：终止一次正在进行的跟踪会话。
2.1 8.3.15.1 General (概述)
The purpose of the Deactivate Trace procedure is to allow the M-NG-RAN node to request the S-NG-RAN node to stop the trace session for the indicated trace reference.
- 发起方：M-NG-RAN node。与启动指令一样，停止指令也必须由作为“总指挥”的MN下达。
- 目的：请求SN停止对特定UE的跟踪。
2.2 8.3.15.2 Successful Operation (成功操作) - 一封精确的“停止函”
DEACTIVATE TRACE是一个Class 2流程，MN发出指令后便认为任务完成。
The Deactivate Trace procedure is initiated by the M-NG-RAN by sending the DEACTIVATE TRACE to the S-NG-RAN for that specific UE. Upon reception of the DEACTIVATE TRACE message, the S-NG-RAN shall stop the trace session for the indicated trace reference in the NG-RAN Trace ID IE.
DEACTIVATE TRACE消息的核心IE：
NG-RAN Trace ID: 这是消息中唯一且至关重要的内容。它就是之前Trace Start时下发的那个“病历号”。SN收到后，会根据这个ID，精确地找到并停止对应的跟踪任务。这确保了不会“误关”其他正在进行的诊断任务。
SN在停止跟踪后，会整理并将其记录的日志文件，通过Trace Start消息中指定的Trace Collection Entity IP Address上传到中央日志服务器（TCE）。至此，SN侧的跟踪任务才算真正结束。
3. 8.3.16 Cell Traffic Trace - 从“个体”到“群体”的监控视角
在处理完小张的个案后，陈工决定拓宽小林的视野，介绍另一种重要的O&M工具。
3.1 8.3.16.1 General (概述)
The purpose of the Cell Traffic Trace procedure is to send the allocated Trace Recording Session Reference and the Trace Reference to the M-NG-RAN node.
陈工的解读：“Trace Start是针对单个UE的‘显微镜’，而Cell Traffic Trace则是针对整个小区的‘广角摄像头’。它不关心某个特定用户的信令，而是由SN主动将其记录的、匿名的、小区级别的流量和事件信息上报给MN。”
- 发起方：S-NG-RAN node。
- 目的：向MN上报小区级的跟踪会话信息。
- 驱动力：通常由SN的后台O&M配置触发，例如，为了进行小区话务模型分析、容量规划或MDT（最小化路测）数据收集。
3.2 8.3.16.2 Successful Operation (成功操作) - 匿名的“健康普查报告”
这是一个由SN发起的Class 2流程。SN在本地生成小区级的跟踪数据后，会通过CELL TRAFFIC TRACE消息将其发送给MN。MN收到后，可能会进一步汇总并上报给网管系统。
CELL TRAFFIC TRACE消息的核心IE：
Trace Recording Session Reference&Trace Reference: 这些是由O&M系统分配的标识，用于关联这次小区级跟踪任务。Privacy IndicatorIE:If the Privacy Indicator IE set to “Immediate MDT” is included in the message, the M-NG-RAN node shall take the information into account for anonymisation of MDT data as specified in TS 32.422. 这是一个关键IE。如果设置了此标志，它明确指示接收方（MN），这份报告属于MDT数据，需要进行匿名化处理。这意味着在数据上报给更上层的分析系统之前，必须脱去所有可能识别到具体用户的信息，以保护用户隐私。
Cell Traffic Trace为网络优化提供了宏观的、统计性的数据视角，与Trace Start的微观、个案诊断能力形成了完美的互补。
4. 8.3.17 & 8.3.18 SCG Failure Handling - 失败后的“复盘”与“申诉”
现在，让我们回到小张的案例。Trace日志已经确认，卡顿的根源是SCG链路失败。接下来，网络将自动启动“事后复盘”机制。
4.1 8.3.17 SCG Failure Information Report - MN发出的“事故调查报告”
当SCG链路失败后，UE会向MN发起RRC重建立流程。MN成功恢复UE的连接后，它就掌握了这次失败的第一手资料。
4.1.1 概述
The purpose of the SCG Failure Information Report procedure is to provide SCG mobility related information to the S-NG-RAN node.
陈工的解读：“这是MN发给SN的一份‘事后告知书’。MN作为‘总指挥’，有义务通知‘副手’SN：‘你负责的链路刚刚发生了故障，导致UE连接中断。这是我收集到的现场情况，供你进行根本原因分析（Root Cause Analysis, RCA）’。”
4.1.2 成功操作（信息传递）
这是一个由MN发起的Class 2流程。MN向SN发送SCG FAILURE INFORMATION REPORT消息。
SCG FAILURE INFORMATION REPORT的核心IE：
Failed PSCell CGI: 发生故障的那个次小区（PSCell）的全局ID。Source PSCell CGI&SN Mobility Information: 如果这次失败发生在一次PSCell变更（小区内切换）过程中，这里会包含源PSCell的信息，以及SN之前为这次变更提供的移动性参数。CPAC ConfigurationIE: 如果失败发生在一次条件PSCell变更（CPAC）中，这里会包含相关的配置信息。
SN收到这份“事故调查报告”后，会将其记录在案。通过分析大量的失败报告（例如，发现失败总是发生在某个特定邻区切换时，或者在某个特定区域），SN的SON（自组织网络）算法就可以进行自我优化，比如调整切换门限、修改邻区关系、调整波束配置等，以避免未来在同样的地方“再次跌倒”。
4.2 8.3.18 SCG Failure Transfer - SN发出的“责任转移声明”
在某些情况下，SN虽然经历了失败，但它有理由相信“锅”不在自己。
4.2.1 概述
The purpose of the SCG Failure Transfer procedure is to indicate to the M-NG-RAN node that the root cause of the SCG failure may have occurred in the other nodes.
陈工的解读：“这是SN的一种‘申诉’机制。SN通过这个流程告诉MN：‘我这边出现了SCG失败，但我自查后认为，根本原因可能不在我的空口，而是在其他地方，比如你（MN）与我之间的Xn传输链路出现了问题，或者你给我的配置本身就有问题。’ 这提醒MN需要从更全局的视角来排查故障。”
4.2.2 成功操作（信息传递）
这是一个由SN发起的、极为简单的Class 2流程。SN仅需向MN发送一个SCG FAILURE TRANSFER消息。这个消息本身不包含复杂的诊断信息，它的存在本身就是一个强烈的信号，触发MN启动更深层次、跨节点的故障排查。
4.3 两种失败报告的对比
| 流程 | SCG Failure Information Report (8.3.17) | SCG Failure Transfer (8.3.18) |
|---|---|---|
| 方向 | MN → SN | SN → MN |
| 目的 | 告知与复盘：MN向SN提供失败信息，供SN进行RCA和自优化。 | 申诉与提醒：SN告知MN，失败的根源可能在SN之外。 |
| 触发点 | UE在MN处成功恢复后，MN掌握了失败的详细信息。 | SN检测到SCG失败，但其内部RCA算法指向外部原因。 |
| 场景比喻 | 事故调查报告 | 责任转移或扩大调查范围的请求 |
这两个流程共同构成了一个完整的、双向的故障信息同步机制，确保了双连接的失败不仅能被恢复，更能被分析、被学习，从而驱动整个网络的持续优化。
5. 总结：从“连接”到“自愈”的智能网络
小林今天的学习，让他对5G网络的“智慧”有了全新的认识。双连接的管理，远不止于建立和拆除。Trace流程提供了深入问题根源的诊断能力，而Failure Report/Transfer流程则赋予了网络从失败中学习的自愈和自优化能力。
Deactivate Trace与Trace Start共同完成了对个体UE的精细化“望闻问切”。Cell Traffic Trace提供了对小区群体的宏观“健康普查”，并兼顾了用户隐私。SCG Failure Information Report建立了从MN到SN的**“经验教训”传递通道**。SCG Failure Transfer建立了从SN到MN的**“疑难问题”上报机制**。
正是这些看似“辅助”的O&M流程，将5G双连接从一个单纯的性能增强技术，提升为了一个具备强大自我监控、自我诊断和自我优化能力的智能化系统。要解决“电竞玩家小张”的问题，不仅要通过Trace找到瞬时故障，更要依靠网络对SCG Failure Information Report的长期学习和积累，最终通过RRM算法的自动优化，彻底根除这类问题的发生。
FAQ
Q1：Trace Start和Deactivate Trace都是Class 2流程，如何保证一个Trace任务一定会被停止？
A1：有多重保障机制。首先，底层SCTP保证了DEACTIVATE TRACE消息的可靠传输。其次，在Trace Activation IE中，可以配置一个跟踪时长（traceDuration）。即使DEACTIVATE TRACE消息意外丢失，SN侧的跟踪任务也会在达到预设时长后自动停止。最后，如果UE上下文被释放，与其相关的所有活动（包括Trace）也都会被一并清理。
Q2：Cell Traffic Trace上报的是匿名数据，它对网络优化还有用吗？
A2：非常有用。虽然它不包含具体UE的身份，但它包含了大量的统计信息，例如：特定区域（小区）内各种业务类型的话务模型、资源占用率、切换成功率统计、MDT测量（如RSRP/SINR的地理化分布图）等。这些宏观的、大数据的统计结果，是进行网络容量规划、覆盖优化、参数调整等工作的最重要依据。
Q3：当MN收到SCG Failure Information Report之后，SN会立即根据其中的信息调整自己的行为吗？
A3：不会立即针对单个事件调整。SN会将每一次的失败报告存储起来，作为其SON（自组织网络）算法的输入。SON算法会基于大量的历史数据和统计分析，来判断是否存在系统性的问题。例如，如果SN发现与某个特定邻区的切换失败率持续偏高，它可能会自动调整对该邻区的切换门限或偏移量。这是一个长期的、基于大数据的学习和优化过程，而非对单次事件的应激反应。
Q4：SCG Failure Transfer流程中，SN如何判断失败原因在“外部”？
A4：这依赖于SN强大的内部RCA（根本原因分析）能力。例如，SN检测到与UE的空口连接突然中断，但同时它检测到：1) UE上报的最后一次测量报告显示无线信号非常好；2) 与此同时，它与MN之间的Xn-U接口心跳包也出现了超时。在这种情况下，SN就有充分理由怀疑，问题不是出在空口，而是Xn传输链路的瞬时中断，于是它会向MN发起SCG Failure Transfer。
Q5：这些O&M流程会对网络的实时性能产生影响吗？ A5：影响非常小，并且是可控的。这些都是低优先级的背景信令流程。
Trace流程本身，如果只跟踪信令，对基站处理器的额外开销很小。如果开启了高强度的MDT测量和上报，才会对空口信令资源和UE功耗产生一些影响，但这通常是按需、短时开启的。Failure Report/Transfer和Notification流程都是在特定事件触发时才发送的单个消息，信令开销可以忽略不计。 这些流程的设计本身就充分考虑了与实时业务的隔离，确保在进行“诊断”和“复盘”时，不会影响到正在进行的“战斗”。