深度解析 3GPP TS 38.423：8.3.14 Trace Start (双连接下的“联合诊断”)

本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“8.3.14 Trace Start”的核心章节。本文旨在为读者深入剖析在5G双连接（DC）场景下，网络运维人员如何通过XnAP协议启动对特定UE的联合信令与数据跟踪，揭示这一关键O&M（运维）功能的信令实现与工作原理。

1. 引言：定位“疑难杂症”的“CT扫描”

在之前的篇章中，我们遇到了电竞玩家“小张”的投诉：尽管处于双连接（DC）状态，他的云游戏依然会遭遇偶发的延迟抖动。我们的工程师小林在他的导师陈工的指导下，已经学会了分析MeasurementReport等信息，初步怀疑问题可能出在次节点（SN）侧的瞬时无线环境恶化。

“陈工，”小林有些苦恼地说，“测量报告给了我们一个方向，但这就像医生通过听诊器听到了杂音，我们仍然需要更精密的诊断工具来看到‘病灶’究竟是什么。我们能不能像给UE做一次‘CT扫描’一样，把他在主节点（MN）和次节点（SN）两侧的所有通信细节都记录下来，进行联合分析？”

“问得好！这正是专业网络优化的核心思路。”陈工赞许道，“对于双连接这种涉及多节点协同的复杂场景，单一节点的日志往往是‘盲人摸象’。要定位根源，我们必须启动一次联合跟踪（Joint Trace）。而指挥SN开启这次‘CT扫描’的命令，正是通过我们今天要学习的XnAP流程——Trace Start来下达的。”

陈工解释道：“Trace功能是网络运维的‘显微镜’。当运维人员需要对某个特定UE的‘疑难杂症’进行深度分析时，他们会从网管中心（O&M）发起一个Trace任务。这个任务指令会通过核心网下发给MN，如果UE处于双连接状态，MN就必须‘通知’它的‘副手’SN：‘总部命令，立即对这个UE开启跟踪，记录他的一举一动，并将报告直接上传！’。TRACE START流程，就是MN向SN传达这个‘最高指示’的信令通道。”

2. 8.3.14.1 General (概述) - 跨节点的“诊断指令”

The purpose of the Trace Start procedure is to allow the M-NG-RAN node to request the S-NG-RAN node to initiate a trace session for a UE. The procedure uses UE-associated signalling.

这段概述言简意赅，清晰地定义了流程的属性：

• 发起方 (Initiator)：M-NG-RAN node (主节点)。只有作为“总指挥”的MN，才有权命令SN启动跟踪。
• 接收方 (Recipient)：S-NG-RAN node (次节点)。
• 核心目的 (Purpose)：请求SN为某个特定的UE启动一个跟踪会话（initiate a trace session）。
• 信令性质 (Signalling Type)：UE关联信令（UE-associated signalling）。每一次跟踪都是精确到单个UE的，因此消息中必须包含UE的唯一标识。

3. 8.3.14.2 Successful Operation (成功操作) - “诊断书”的详细内容

TRACE START是一个Class 2流程。这表明它是一个命令式的、单向的通知。MN下达指令后，不等待SN的回复。这确保了跟踪指令能够被快速下发，SN可以立即开始记录，不错过任何关键的瞬间。

The Trace Start procedure is initiated by the M-NG-RAN sending the TRACE START message to the S-NG-RAN for that specific UE. Upon reception of the TRACE START message, the S-NG-RAN node shall initiate the requested trace session as described in TS 32.422.

MN向SN发送TRACE START消息，其中最核心的信息都封装在一个关键IE——Trace Activation中。这份“诊断书”的详细内容，都定义在这个IE里。

3.2.1 Trace Activation IE - “CT扫描”的参数配置

Trace Activation IE就像医生开具的CT扫描申请单，详细规定了这次检查的范围、深度和报告方式。它通常包含以下几个关键部分：

1. NG-RAN Trace ID: 这是本次跟踪任务的唯一“病历号”。它由发起跟踪的O&M系统生成，并一路透传下来。MN和SN在各自记录的跟踪日志文件中，都会标记上这个ID。这样，后台分析系统就可以根据这个ID，将来自不同节点的、关于同一个诊断事件的所有日志关联起来，进行联合分析。

2. Interfaces To Trace (要跟踪的接口): 这是一个位图（bitmap），用于指定SN需要“盯梢”哪些通信接口。例如：

• Uu接口: UE与SN之间的空中接口。勾选此项，SN就会记录所有与该UE相关的RRC消息、MAC/RLC层统计信息等。
• Xn-C/Xn-U接口: SN与MN之间的控制面和用户面接口。勾选此项，SN就会记录它与MN之间的所有XnAP消息和GTP-U数据包头信息。
• F1/E1接口: 如果SN是一个CU/DU分离架构，还可以指定跟踪CU和DU之间的接口。

场景代入：为了诊断小张的问题，运维人员希望看到SN侧的空口情况以及SN与MN的交互。因此，Interfaces To Trace的Uu和Xn位都会被设置为1。

3. Trace Depth (跟踪深度): 这是一个枚举值，定义了跟踪记录的详细程度。

• minimum: 只记录最关键的信令事件，如RRC消息类型。
• medium: 记录信令消息的主要内容。
• maximum: 记录最详尽的信息，包括完整的信令消息内容、底层协议的详细参数等。

场景代入：对于小张这种难以复现的延迟抖动问题，必须采用maximum深度，才能捕捉到可能导致问题的每一个细节。

4. Trace Collection Entity IP Address (跟踪采集实体IP地址): 这是“诊断报告”的“邮寄地址”。它是一个IP地址，指向网络中的一个中央日志服务器（Trace Collection Entity, TCE）。SN在执行跟踪并生成日志文件后，不会将文件回传给MN，而是直接通过这个IP地址，采用FTP、SFTP等协议，将日志文件上传到TCE。

陈工的解读：“小林，这是一个非常重要的架构设计。让SN直接向TCE上报，而不是通过MN中转，有两大好处：第一，减轻了MN的负担，MN无需处理海量的、可能高达几百MB的跟踪文件；第二，解耦了信令和数据，保证了Xn-C接口只用于轻量级的信令交互，而大文件的传输则通过标准的IP网络进行。”

3.2.2 与MDT的联动 - “CT扫描”中的“增强造影”

Trace Activation IE中还可以携带**MDT（Minimization of Drive Tests）**的配置。

If the Trace Activation IE includes

• the MDT Activation IE set to “Immediate MDT and Trace”, then the S-NG-RAN node shall if supported, initiate the requested trace session and MDT session as described in TS 32.422.
• the MDT Activation IE set to “Immediate MDT Only” or “Logged MDT only”, the S-NG-RAN node shall, if supported, initiate the requested MDT session…

陈工的解读：“MDT是网络优化的‘大数据’工具，通过收集大量用户的无线测量信息来绘制网络质量地图。而Trace通常是针对单个用户的‘小数据’深度诊断。Trace Start流程巧妙地将两者结合起来。”

• Immediate MDT (立即MDT)：MN可以请求SN不仅跟踪信令，还立即开始收集UE的详细无线测量（如L1的波束测量、L2的吞吐率统计等），并将结果实时或准实时地上报。这就像在做CT扫描时，注入了“造影剂”，可以更清晰地观察到无线链路的动态变化。
• Logged MDT (记录式MDT)：MN也可以请求SN配置UE进行记录式MDT。UE会在RRC_IDLE或RRC_INACTIVE状态下，周期性地进行测量并将结果记录在本地。当UE下次返回连接态时，再将日志上报。

场景代D入：为了彻底搞清楚小张的卡顿原因，运维人员决定启用Immediate MDT and Trace。这样，当延迟抖动发生时，分析系统不仅能看到当时的RRC信令和XnAP交互，还能看到精确到毫秒的、UE上报的物理层波束质量、CQI（信道质量指示）等信息，从而精准定位问题是由于干扰、波束切换失败还是其他无线原因。

4. 8.3.14.3 Abnormal Conditions (异常条件) - 指令的有效性

If the Trace Activation IE is not included in the TRACE START message, the S-NG-RAN node shall ignore the message.

陈工的解读：“这是协议健壮性的基本要求。TRACE START消息的‘灵魂’就是Trace Activation IE，它包含了所有的指令参数。如果一个TRACE START消息连这个核心IE都没有，那它就是一封‘空白圣旨’，没有任何意义。SN收到这样的无效指令，正确的做法就是直接忽略，以避免引发未知错误。”

对于其他异常，由于这是Class 2流程，SN不会向MN回复失败。如果SN因为内部原因（如内存不足、配置错误）无法启动跟踪，它会在本地记录错误日志，并通过告警上报给O&M系统。运维人员会从网管侧发现“指令已下发，但未收到日志”的现象，从而介入排查SN侧的问题。

5. 总结：双连接运维的“利器”

Trace Start流程是XnAP协议中一个纯粹的O&M功能，它不直接参与用户业务的建立和移动，但它为保障这些业务的质量和稳定性提供了不可或缺的诊断能力。

• 它是协同诊断的基石：首次在协议层面，实现了对双连接UE在MN和SN两侧的同步、联合跟踪，为端到端的故障定位提供了可能。
• 它是精细化监控的体现：通过灵活的接口选择和深度控制，运维人员可以按需定制跟踪范围，在信令开销和诊断需求之间取得平衡。
• 它是数据采集的桥梁：通过与MDT的联动，将传统的信令跟踪（Trace）与深度的无线测量（MDT）相结合，为网络优化提供了前所未有的数据维度。
• 它体现了架构的解耦：通过让SN直接向TCE上报日志，实现了信令平面与运维数据平面的分离，保证了核心信令网络的轻载和高效。

对于小林这样的开发者，理解Trace Start意味着要深入学习32系列的O&M规范（如TS 32.422），并确保协议栈能正确解析Trace Activation IE中的复杂参数。对于网络优化和故障处理工程师，熟练运用Trace工具，是他们从海量告警和KPI中抽丝剥茧、定位疑难杂症的“看家本领”。

FAQ

Q1：谁是Trace任务的最终发起者？是基站自己吗？ A1：不是。Trace任务的最终发起者通常是网络运维人员。他们通过O&M系统（也称网管）的图形界面或命令行，选择一个特定的UE（通过SUPI或GPSI等永久标识），并配置好跟踪参数（跟踪时长、深度、接口等），然后下发任务。O&M系统再通过核心网（AMF）将Trace指令下发给服务该UE的MN，最终由MN通过XnAP TRACE START将指令传递给SN。

Q2：TRACE START是一个Class 2流程，MN如何知道SN是否成功启动了跟踪？ A2：MN在XnAP层面不知道，也不关心。协议设计认为，这是一个可靠的命令。MN的任务是传达指令，SN的任务是执行。SN是否成功执行，是由O&M系统来监控的。O&M系统下发任务后，会期待在指定的时间内，从TCE（日志采集实体）那里收到来自MN和SN的、带有相同NG-RAN Trace ID的日志文件。如果只收到了MN的，而没有SN的，O&M系统就会产生告警，提示SN侧的Trace功能可能存在问题。

Q3：Deactivate Trace（8.3.15节）流程是用来做什么的？ A3：它是Trace Start的配对流程。当跟踪任务结束时（例如，达到了预设的时长，或者运维人员手动停止），O&M系统会下发停止指令。MN收到后，会向SN发送DEACTIVATE TRACE消息（同样是Class 2流程），通知SN停止为该UE记录日志。消息中会包含NG-RAN Trace ID，以确保停止的是正确的跟踪会话。

Q4：跟踪UE会影响UE的性能或功耗吗？ A4：通常影响很小。信令跟踪（Trace）主要是网络侧的行为，记录的是基站收发的信令，对UE本身是无感的。但如果启动了Immediate MDT，MN/SN会向UE下发RRC消息，配置UE进行额外的测量和上报。这会略微增加UE的信令处理负荷和上行传输，从而带来微小的功耗增加。但这种影响通常是短暂和可控的，并且是为了解决更严重性能问题所必需的代价。

Q5：Cell Traffic Trace（8.3.16节）和Trace Start有什么区别？ A5：Trace Start（以及Deactivate Trace）是针对特定UE的，我们称之为UE Trace或Signalling Trace。它的目的是对单个用户的信令交互进行深度分析。而Cell Traffic Trace是另一种类型的跟踪，它不针对特定UE，而是记录一个小区内所有UE或特定业务类型的总体行为和资源使用情况，通常用于小区的性能监控和话务模型分析，是另一种维度的O&M工具。两者在XnAP中都有定义，但目的和应用场景完全不同。