深度解析 3GPP TS 23.273：6.11.3 & 6.11.4 非UE关联数据与用户面定位

本文技术原理深度参考了3GPP TS 23.273 V18.9.0 (2025-03) Release 18规范中，关于“6.11.3 Obtaining Non-UE Associated Network Assistance Data”和“6.11.4 Positioning Procedure over User Plane”的核心章节。本文将这两部分内容合并解读，旨在为读者揭示5G定位“工具箱”中另外两种独特的、面向特定场景的“利器”：如何为网络自身“体检”，以及如何将定位信令从拥挤的“信令高速”分流到宽阔的“数据国道”上。

1. 序章：智慧城市的“幕后英雄”

在之前的篇章中，我们的焦点始终围绕着一个核心问题：“如何找到UE？” 然而，一个强大、智能的定位系统，不仅需要知道终端在哪，还需要深刻地理解其所处的物理环境。基站并非凭空存在，它们的精确坐标、天线朝向、发射功率等“基础设施数据”，是所有高精度网络侧定位算法的基石。

同时，随着5G应用向低时延、大带宽的领域（如云游戏、AR/VR协作）深度渗透，传统的、承载在控制面（Control Plane）上的定位信令，有时会面临拥塞和优先级挑战。能否为这些对时延极度敏感的商业应用，开辟一条更直接、更宽阔的定位交互通道？

今天，我们将通过两个场景，来解答这两个“幕后”问题：

• 场景一：网络的“自我体检” 运营商的网络维护中心需要定期获取其部署在城市各处的新5G基站的精确地理信息，以更新其定位数据库。这些数据与任何特定的用户UE无关，是纯粹的网络侧信息。我们将跟随一位网络工程师“李工”，看LMF如何执行一次非UE关联的网络辅助数据获取（Non-UE Associated Network Assistance Data）。

• 场景二：AR电竞的“超低时延”定位 电竞选手“小驰”正在参加一场户外AR（增强现实）电竞比赛。游戏中，他的位置需要以毫秒级的频率进行更新，以保证虚拟角色与现实世界的精确同步。我们将跟随小驰，体验**用户面定位（Positioning Procedure over User Plane）**如何为他提供极致流畅的定位体验。

2. 网络的“CT扫描”：非UE关联数据获取 (6.11.3)

李工的任务，是验证一座刚刚开通的、位于CBD楼顶的5G微基站（gNB-123）的位置信息是否准确。他通过后台系统，触发了一次针对这个网络设备的特殊请求。

Figure 6.11.3-1 shows a procedure which may be used by an LMF to support network assisted and network based positioning. This procedure is not associated with a UE location session. It is used to obtain network assistance data from a NG-RAN node…

这段原文开宗明义，点出了6.11.3流程的本质：它与任何具体的用户UE无关，其目标是获取网络基础设施自身的辅助数据。这就像医生给网络做的一次“CT扫描”，旨在了解网络自身的“骨骼”信息。

“Figure 6.11.3-1: Procedure for Obtaining Non-UE Associated Network Assistance Data”为我们展示了这次“体检”的流程。

2.1 核心特点：绕过UE，直达网络

与我们之前熟悉的所有流程都不同，这里的信令链条中完全没有UE的身影。主角变成了LMF、AMF和NG-RAN。

2.2 “体检”流程详解

1. LMF发起“体检单” (Step 1)：李工在后台系统中发起的请求，最终被送达到了LMF。LMF构建了一份非UE关联的网络定位消息（使用NRPPa协议），并通过Namf_Communication_NonUeN2MessageTransfer服务，发送给了AMF。

   1. The LMF invokes the Namf_Communication_NonUeN2MessageTransfer service operation towards the AMF to request the transfer of a Network Positioning message to a NG-RAN node… The service operation includes the Network Positioning message and the target NG-RAN node identity.

   这个请求的特殊之处在于，它的目标不再是一个UE ID（如SUPI），而是一个明确的基站ID（target NG-RAN node identity），即gNB-123。请求的内容可能是：“请提供你的精确地理坐标、小区覆盖范围信息等。”

2. AMF扮演“智能路由” (Step 2 & NOTE 1)：AMF在这里的角色非常关键。

   NOTE 1: It is not required that serving AMF to be used in this procedure. To support location service in the PNI-NPN, local AMF is used instead of serving AMF, as defined in clause 5.13.

   由于这个请求与特定UE无关，因此任何一个AMF理论上都可以处理它。LMF可以将请求发送给它知道的任何一个AMF。AMF收到后，会根据目标基站的ID，查询网络拓扑，找到管理gNB-123的那个AMF（可能就是它自己，也可能是另一个AMF），然后将NRPPa消息通过N2接口转发给目标基站。在我们在6.1.3章节中分析过的PNI-NPN（与公网集成的非公网）场景下，这个AMF甚至可以是部署在企业园区的本地AMF，以实现最低时延的本地网络信息交互。

3. 基站的“自我报告” (Step 3)：gNB-123收到请求后，会从自身的配置或通过内置的GNSS接收器，获取所请求的信息。

4. “体检报告”的返回 (Step 4 & 5)：gNB-123将信息封装在NRPPa消息中，通过AMF返回给LMF。李工的后台系统上，gNB-123的精确坐标点被成功更新。

2.3 6.11.3流程的意义

这个看似简单的流程，对于维持一个高精度定位系统的健康至关重要：

• 数据库自动化：它为LMF自动地、远程地构建和更新其“基站地图”数据库提供了标准化的手段，取代了传统的人工勘测和手动录入。
• 支持高精度定位：所有网络侧定位方法（如E-CID, TDOA）的精度，都直接取决于LMF所掌握的基站坐标的精度。6.11.3是保证这些高级定位算法能够正确运行的“幕后英雄”。
• 网络自优化：通过定期获取基站的真实环境信息，LMF可以动态地调整其定位算法的参数，实现网络的自优化。

3. 定位的“高速公路”：用户面定位 (6.11.4)

现在，让我们切换到AR电竞选手小驰的场景。比赛中，他的每一次微小的移动、每一次转身，都需要被实时地捕捉并反映在虚拟世界中。如果使用传统的控制面（Control Plane）传输定位消息，可能会面临以下挑战：

• 信令拥塞：控制面是网络的心脏和大脑，承载着移动性、会话管理等最高优先级的信令。大量的、高频的定位消息可能会对其造成拥塞。
• 优先级抢占：在网络繁忙时，控制面信令需要排队。商业应用的定位消息，其优先级通常低于寻呼、切换等信令，可能会遭遇时延抖动。

为了解决这个问题，3GPP为商业应用开辟了一条新的通道——用户面（User Plane）。

The flow below shows a positioning procedure used by an LMF and/or UE over User Plane. The procedure is based on use of the LPP protocol defined in TS 37.355 between the LMF and UE. Prerequisite of this procedures is User Plane establishment between UE and LMF described in in clause 6.18.

3.1 核心思想：从“信令”到“数据”的转变

用户面定位的核心，就是将原本封装在NAS信令中的LPP消息，转而封装在IP数据包中，通过常规的用户面数据通道（PDU会话）进行传输。这就像将一封紧急的信件，从传统的邮政信件系统（控制面），改用最高级别的快递专线（用户面）来发送。

3.2 前提条件：建立“定位专用高速公路”

要使用用户面定位，必须先打通一条从UE到LMF的“高速公路”。这个过程在6.18章节中有详细定义，其核心是：

1. UE与网络协商：UE与AMF/LMF协商，确认双方都支持用户面定位。
2. 建立专用PDU会话：UE会建立一个专门用于定位的PDU会话。这个会话可能有一个专用的DNN（数据网络名称），并被SMF路由到一个特殊的UPF（用户面功能）。
3. UPF直连LMF：这个特殊的UPF，可以直接或通过少数几跳转发，将IP数据包路由到LMF的用户面IP地址。

一旦这条“高速公路”建成，6.11.4的流程就可以启动了。

3.3 “高速公路”上的LPP交互 (Figure 6.11.4-1)

“Figure 6.11.4-1: Positioning Procedure over User Plane”为我们展示了这个极其简洁的流程。

1. LPP消息的IP封装 (Step 1)：LMF或UE将一份LPP消息（例如，LMF请求UE上报传感器数据，或UE主动上报GNSS位置），不再交给AMF，而是直接将其作为IP数据包的载荷。
2. 通过UPF/RAN传输：这个IP数据包沿着建立好的专用PDU会话，经过RAN和UPF，被直接路由到另一端（LMF或UE）。
3. 双向自由交互 (Step 1, 2, 3)：规范指出，步骤1, 2, 3（发送请求、处理、发送响应）可以按任何顺序、顺序或并发发生。这体现了用户面传输的高度灵活性。LMF和UE可以在这条“高速公路”上，进行自由、高频、低时延的双向LPP消息交换，就像在进行一次UDP或TCP通信。

对于小驰而言，这意味着他的AR头盔可以以每秒数十次的频率，将自己的姿态和位置数据，通过这条用户面“专线”，实时地发送给LMF（或直接发送给部署在边缘云上的游戏服务器，如果该服务器扮演了LMF的角色）。这保证了他的虚拟角色能够与他的真实动作完美同步，毫无延迟感。

4. 总结：工具箱的最后两块拼图

6.11.3和6.11.4，为LMF的“技术工具箱”补上了最后两块关键的拼图，使其能力更加全面和立体。

• 非UE关联数据获取 (6.11.3)：它赋予了LCS系统一种**“内省”和“自检”**的能力。这使得LMF不再是一个被动使用静态数据的“黑盒”，而是一个能够主动感知和学习其所处物理网络环境的“智能体”。这是实现网络自动化运维和定位能力自优化的基础。

• 用户面定位 (6.11.4)：它为对时延和带宽有特殊要求的商业应用，提供了一个**“旁路”控制面的高性能选项**。通过将定位信令“数据化”，利用5G用户面的低时延和高带宽特性，完美地满足了AR/VR、云游戏、车联网协同驾驶等前沿应用对极致定位体验的需求。

这两项技术，一个“向内求索”，一个“向外开放”，共同拓展了5G定位服务的边界，使其不仅能服务于“人”，更能服务于“网络”本身，并为最前沿的“应用”铺平道路。

---

FAQ - 常见问题解答

Q1：非UE关联数据获取流程（6.11.3）可以用来定位普通的UE吗？ A1：不可以。这个流程是严格限定用于获取网络节点（如gNB）自身信息的。它的NRPPa消息中，目标标识符是网络节点ID，而非UE ID。如果要定位普通UE，必须使用6.11.1或6.11.2中定义的、与UE关联的流程。

Q2：用户面定位（6.11.4）和控制面定位，在定位精度上会有差异吗？ A2：不会。定位精度主要取决于所使用的定位方法（如GNSS, TDOA）和算法，而与承载LPP消息的通道是控制面还是用户面无关。用户面定位的核心优势在于时延更低、带宽更高、与控制面信令解耦，从而能提供更“实时”、更“流畅”的定位更新，尤其适合高频定位场景。

Q3：既然用户面定位这么好，为什么不把所有的定位都改用用户面呢？ A3：因为“好”是相对的，需要看场景。

• 资源开销：建立和维持一条专用的用户面PDU会话，本身就需要消耗网络资源（如IP地址、UPF会话表项）。对于不频繁的、低速率的定位，这种开销是不划算的。
• 可靠性与优先级：控制面信令通常拥有比普通用户面数据更高的网络传输优先级和可靠性保障。对于监管类服务（如紧急定位），必须使用最可靠的控制面通道。
• UE状态：用户面定位通常要求UE处于CM-CONNECTED状态。对于需要从CM-IDLE状态唤醒的定位，依然需要控制面的寻呼流程来启动。 因此，用户面定位是作为一种补充和增强，而非替代，主要面向对时延敏感的特定商业应用。

Q4：在使用用户面定位时，AMF是不是就完全“失业”了？ A4：不是。AMF在用户面定位的“生命周期管理”中依然扮演着关键角色。首先，建立用户面定位能力的初始协商过程（6.18章节），需要UE与LMF通过AMF进行信令交换来完成。其次，AMF可能需要订阅LMF关于这条用户面连接的状态，以便在UE发生移动性事件（如切换）时，能够通知LMF进行相应的处理。所以，AMF从“搬运工”转变成了“管理员”。

Q5：非UE关联数据获取（6.11.3）流程，是否也需要像定位UE一样，考虑隐私问题？ A5：不需要。因为这个流程的目标是网络设备，而非个人用户终端。网络设备（基站）被视为运营商的资产和基础设施的一部分，获取其自身的信息不涉及个人隐私。这也是为什么这个流程被命名为“Non-UE Associated”的原因。