本文技术原理深度参考了3GPP TS 38.413 V18.5.0 (2025-03) Release 18规范中，关于“9.2.9 NRPPa Transport Messages”, “9.2.10 Trace Messages”和“9.2.11 Location Reporting Messages”的核心章节，旨在为读者提供一个关于5G网络如何通过NG-C接口，为其“侦察”与“感知”能力（定位、追踪、位置服务）构建具体信令“指令书”的深度洞察。
深度解析 3GPP TS 38.413：9.2.9 - 9.2.11 网络的“侦察兵”：NRPPa、Trace与位置上报消息
大家好，欢迎回到3GPP规范的深度解析系列！在前几期文章中，我们已经系统地学习了NGAP协议中用于“建连”、“通话”、“上网”和“移动”的核心消息。今天，我们将把目光转向一组同样重要，但更偏向于“观察”和“感知”的消息类型。这些消息构成了网络自身的“侦察兵”体系，使其能够精确地定位用户、深度地诊断问题，并提供丰富的基于位置的服务。
我们将聚焦于三组在概念上紧密相连的“传输类”消息，它们都体现了AMF作为一个“信令中转枢纽”的核心作用：
- NRPPa传输消息 (NRPPa Transport Messages)：为5G的高精度定位协议NRPPa搭建的专用“快递通道”。
- Trace消息 (Trace Messages)：网络运维人员用于故障诊断的“显微镜”，启动、停止和管理对特定用户的信令追踪。
- 位置上报消息 (Location Reporting Messages)：网络根据上层应用的需求，对用户进行位置追踪的“指令系统”。
为了生动地理解这些消息的结构和用途，我们将引入一位新的主角——现场服务工程师Ben。他正佩戴着一副AR（增强现实）眼镜，在一个巨大的自动化工厂中，对一台复杂的机器人进行远程维护。
- UE: Ben的AR眼镜（内置5G模组）。
- 应用: 远程专家指导系统，需要将机器的3D数字模型精确叠加在Ben的现实视野中。
- 网络节点:
AMF-Factory，覆盖工厂的gNB-Factory-01，以及负责定位的LMF和负责运维的O&M中心。
我们将跟随Ben的维护工作，来剖析这三组消息是如何协同工作的：
- 场景一：Ben进入工厂，系统需要知道他的大致位置，以引导他前往故障设备区。这将触发**位置上报（Location Reporting）**流程。
- 场景二：Ben到达设备旁，AR应用需要厘米级的精度来对齐数字模型。这将触发**NRPPa传输（NRPPa Transport）**流程，进行高精度定位。
- 场景三：在维护过程中，Ben的AR眼镜突然出现画面卡顿。后台的运维团队决定对他发起一次Trace，以捕获问题根源。
通过这个层层递进的场景，我们将深入到这些消息的比特层面，看懂网络是如何实现其强大的“感知”能力的。
1. 9.2.9 NRPPa Transport Messages (NRPPa传输消息)
我们在8.10节的流程解析中已经知道，NRPPa是LMF（定位管理功能）与gNB之间沟通的“定位语言”，而NGAP的NRPPa传输流程，就是承载这种语言的“信使”。现在，我们来拆解这些“信件”本身。
1.1 DOWNLINK UE ASSOCIATED NRPPA TRANSPORT (下行UE关联NRPPa传输)
这是LMF向gNB下达针对特定UE的定位指令的“信封”。
9.2.9.1 DOWNLINK UE ASSOCIATED NRPPA TRANSPORT This message is sent by the AMF and is used for carrying NRPPa message over the NG interface.
场景引入：
Ben已到达故障机器人旁，AR应用请求厘米级定位。LMF决定启动一次基于PRS（定位参考信号）的下行到达时间差（DL-TDOA）测量。它需要命令gNB-Factory-01向Ben的AR眼镜提供必要的测量信息。
LMF生成一个NRPPa PDU，其内容是“请为该UE提供DL-TDOA测量辅助信息”。然后，AMF将这个PDU封装在DOWNLINK UE ASSOCIATED NRPPA TRANSPORT消息中，发往gNB。
表格 9.2.9.1-1: DOWNLINK UE ASSOCIATED NRPPA TRANSPORT 消息内容
| IE/Group Name | Presence | Range | IE type and reference | Semantics description | Criticality | Assigned Criticality |
|---|---|---|---|---|---|---|
| Message Type | M | 9.3.1.1 | YES | ignore | ||
| AMF UE NGAP ID | M | 9.3.3.1 | YES | reject | ||
| RAN UE NGAP ID | M | 9.3.3.2 | YES | reject | ||
| Routing ID | M | 9.3.3.13 | YES | reject | ||
| NRPPa-PDU | M | 9.3.3.14 | YES | reject |
核心IE深度解码：
AMF UE NGAP ID/RAN UE NGAP ID: 明确了这条指令是针对Ben的AR眼镜的。Routing ID: 这个ID至关重要，它在这里代表了LMF的身份标识。gNB在收到这条指令后，就知道后续的响应应该回送给哪个LMF。在一个可能存在多个LMF实例的网络中，Routing ID确保了信令的正确闭环。NRPPa-PDU: 这就是那个透明的“包裹”。AMF完全不关心里面是什么，只是将其原封不动地传递。gNB收到后，会解开这个包裹，交由其内部处理NRPPa协议的模块来执行。
1.2 UPLINK UE ASSOCIATED NRPPA TRANSPORT (上行UE关联NRPPa传输)
这是gNB将定位测量结果上报给LMF的“回信信封”。
9.2.9.2 UPLINK UE ASSOCIATED NRPPA TRANSPORT This message is sent by the NG-RAN node and is used for carrying NRPPa message over the NG interface.
场景演绎：
gNB-Factory-01执行了LMF的指令，并将测量结果打包成一个NRPPa PDU。然后，它将这个PDU封装在UPLINK UE ASSOCIATED NRPPA TRANSPORT消息中，通过AMF发往LMF。消息结构与下行类似，同样包含了双方UE ID、Routing ID和NRPPa-PDU。AMF根据Routing ID，就能准确地将这份“测量报告”送达正确的LMF。
注：规范还定义了Non UE Associated的NRPPa传输消息，用于LMF和gNB之间交换非针对特定用户的通用定位信息，例如广播PRS辅助数据等，其消息结构类似，但不包含UE相关的ID。
2. 9.2.10 Trace Messages (Trace消息)
当网络出现疑难杂症时，运维人员需要启动Trace来捕获详细的信令交互。Trace Messages就是执行这一系列“侦察”任务的指令集。
2.1 TRACE START (启动Trace)
这是运维人员通过AMF向gNB下达的“开始记录”指令。
9.2.10.1 TRACE START This message is sent by the AMF to initiate a trace session for a UE.
场景引入：
Ben的AR眼镜出现卡顿，运维中心的Morpheus决定对他的连接进行一次深度追踪。O&M系统通过AMF，向gNB-Factory-01发送了TRACE START消息。
表格 9.2.10.1-1: TRACE START 消息内容
| IE/Group Name | Presence | Range | IE type and reference | Semantics description | Criticality | Assigned Criticality |
|---|---|---|---|---|---|---|
| Message Type | M | 9.3.1.1 | YES | ignore | ||
| AMF UE NGAP ID | M | 9.3.3.1 | YES | reject | ||
| RAN UE NGAP ID | M | 9.3.3.2 | YES | reject | ||
| Trace Activation | M | 9.3.1.14 | YES | ignore |
Trace Activation IE深度解码：
这个IE是Trace任务的详细“配置单”，其内部包含了：
NG-RAN Trace ID: 本次Trace任务的唯一ID。Interfaces to Trace: 要追踪的接口（Uu, Xn, NG等）。Trace Depth: 追踪的详细程度（minimum, medium, maximum）。Trace Collection Entity IP Address: 记录数据的上报地址。
gNB收到后，就会开始对Ben的AR眼镜在指定接口上的所有信令进行捕获和上报。
2.2 Trace生命周期管理的其他消息
TRACE FAILURE INDICATION(9.2.10.2): 如果gNB无法启动或维持Trace会话（例如，因为UE正在切换），它会通过此消息向AMF报告失败，并说明原因。DEACTIVATE TRACE(9.2.10.3): AMF在需要停止Trace时，会发送此消息。消息中只需包含之前下发的NG-RAN Trace ID，gNB就会停止对应的Trace任务。CELL TRAFFIC TRACE(9.2.10.4): gNB在成功启动Trace后，会通过此消息向AMF报告其内部为该Trace会话分配的Trace Recording Session Reference。这用于在gNB和AMF两侧建立对同一次Trace会话的关联，便于联合排障。
3. 9.2.11 Location Reporting Messages (位置上报消息)
这些消息用于AMF根据上层业务需求，对UE进行事件驱动的位置追踪。
3.1 LOCATION REPORTING CONTROL (位置上报控制)
这是AMF向gNB下达“追踪指令”的消息。
9.2.11.1 LOCATION REPORTING CONTROL This message is used by the AMF to request the NG-RAN node to report the location of the UE.
场景引入：
Ben刚进入工厂时，工厂的管理系统（通过核心网）需要知道他的大致位置，以便在地图上显示并规划路线。AMF向gNB-Factory-01发送LOCATION REPORTING CONTROL消息。
表格 9.2.11.1-1: LOCATION REPORTING CONTROL 消息内容
| IE/Group Name | Presence | Range | IE type and reference | Semantics description | Criticality | Assigned Criticality |
|---|---|---|---|---|---|---|
| Message Type | M | 9.3.1.1 | YES | ignore | ||
| AMF UE NGAP ID | M | 9.3.3.1 | YES | reject | ||
| RAN UE NGAP ID | M | 9.3.3.2 | YES | reject | ||
| Location Reporting Request Type | M | 9.3.1.65 | YES | ignore |
Location Reporting Request Type IE深度解码：
这个IE定义了gNB需要执行的追踪模式和上报条件，例如：
direct: 立即上报一次当前位置。change of serving cell: 每当UE发生小区切换时，就上报一次位置。UE presence in the area of interest: 当UE进入或离开一个预定义的“感兴趣区域”（由Area of Interest ListIE定义）时，上报一次。
3.2 LOCATION REPORT (位置上报) 和 FAILURE INDICATION (失败指示)
LOCATION REPORT(9.2.11.3): 这是gNB执行CONTROL指令后的“汇报”消息。当触发条件满足时（例如，Ben切换到了工厂的另一个小区），gNB就会发送此消息，其中包含User Location InformationIE，告知AMF UE的最新位置（CGI）。LOCATION REPORTING FAILURE INDICATION(9.2.11.2): 如果gNB无法执行AMF的指令（例如，AMF请求监控的“感兴趣区域”中的小区不属于该gNB），它会通过此消息报告失败。
场景演绎：
- 控制: AMF发送
LOCATION REPORTING CONTROL，要求gNB在Ben发生小区切换时上报位置。 - 上报: Ben从工厂A区走到B区，手机从Cell-A切换到Cell-B。
gNB-Factory-01立即向AMF发送LOCATION REPORT，报告Ben的新位置是Cell-B。工厂管理系统随即更新了地图上的Ben的图标。 - 停止: Ben到达目的地后，系统不再需要追踪。AMF发送一个新的
CONTROL消息，Request Type设置为"cancel location reporting for the UE"，gNB随即停止了该任务。
FAQ
Q1: NRPPa Transport, Trace 和 Location Reporting 这三组消息都是关于获取UE信息的，它们的核心区别是什么？
A1: 它们服务于完全不同的目的和网络功能，可以从“谁关心”和“要什么”两个维度来区分：
NRPPa Transport: 谁关心？ → LMF（定位管理功能）。要什么？ → 原始的、高精度的无线测量值，用于计算UE的地理坐标（经纬度）。它是一个底层技术流程。Trace: 谁关心？ → O&M（运维中心）。要什么？ → 完整的、详细的信令交互过程，用于诊断网络故障。它是一个运维工具流程。Location Reporting: 谁关心？ → AMF（代表上层应用或LCS服务）。要什么？ → UE的逻辑位置（小区ID）或在一个区域内的状态（进入/离开）。它是一个上层业务触发的事件报告流程。
Q2: Routing ID在NRPPa传输中如此重要，它是在哪里定义的？gNB如何知道该填什么？
A2:
Routing ID用于在AMF这个“多对多”的枢纽中，唯一地标识一个信令的端点，在这里通常是LMF。它的值和格式由运营商在网络规划时配置。gNB并不知道该填什么，它只需要“回显”即可。
流程是这样的：当LMF通过AMF向gNB发起一个下行NRPPa请求时（DOWNLINK UE ASSOCIATED NRPPA TRANSPORT），它会在消息中包含自己的Routing ID。gNB收到并保存这个ID。当gNB需要回复这个请求时（UPLINK UE ASSOCIATED NRPPA TRANSPORT），它会将之前保存的那个Routing ID原封不动地填回去。这样，AMF收到上行消息后，一看Routing ID，就知道应该把这个消息转发给哪个LMF了。
Q3: TRACE START消息是一个单向指令，gNB不会回复确认吗？AMF如何知道Trace任务是否成功启动了？
A3:
TRACE START本身是一个Class 2的单向流程，gNB在NGAP层面不需要回复ACK。AMF在发送后就认为指令已下达。然而，整个Trace机制有闭环：
- 成功闭环: gNB成功启动Trace后，会向AMF发送
CELL TRAFFIC TRACE消息，报告其内部的Trace会话引用。AMF收到这个消息，就间接确认了Trace已成功启动。 - 失败闭环: 如果gNB启动失败，它会向AMF发送
TRACE FAILURE INDICATION消息，明确告知失败。 通过这两个由gNB主动发起的后续消息，AMF可以确切地知道Trace任务的执行状态。
Q4: AMF在LOCATION REPORTING CONTROL中可以定义一个由多个不连续的小区组成的“感兴趣区域”吗？
A4:
可以的。Area Of Interest List IE中包含的是一个小区列表（Area of Interest Cell List）。这些小区可以是任意组合，无需在地理上连续。例如，一个零售商可以在一个城市的不同商场中，将其所有分店所在的小区都定义为一个“感兴趣区域”。当订阅了该服务的用户（如会员）进入任何一家分店的覆盖范围时，网络都能检测到并通知商家后台，触发优惠券推送等营销活动。这为基于位置的精准营销提供了强大的网络能力。
Q5: 这些“侦察”流程会消耗大量网络资源吗？
A5: 这些流程本身都是信令面的，消耗的带宽资源极小。但它们可能触发的行为会消耗资源：
- NRPPa可能会触发gNB进行密集的PRS信号广播，这会占用一定的空口时频资源。
- Trace（特别是
maximum深度）会要求gNB进行大量的信令记录和上报，这会消耗gNB的处理能力和到TCE的传输带宽。 - Location Reporting（特别是
change of serving cell模式）会在UE频繁切换时，产生较多的LOCATION REPORT信令消息。 因此，这些功能都是“按需开启”的。网络运维人员和上层应用开发者需要明智地使用它们，只在必要时、在必要的范围内启动，并在任务完成后立即停止，以在获取宝贵信息和节约网络资源之间取得平衡。