51学通信

深度解析 3GPP TS 23.273：6.18 & 6.16 开启“VIP专线”：用户面定位流程

22分钟阅读

深度解析 3GPP TS 23.273：6.18 & 6.16 开启“VIP专线”：用户面定位流程

本文技术原理深度参考了3GPP TS 23.273 V18.9.0 (2025-03) Release 18规范中，关于“6.18 Procedures of User Plane Connection between UE and LMF”和“6.16 Periodic and Triggered 5GC-MT-LR Procedure with User Plane”的核心章节。本文将这两章合并解读，因为它们共同构成了一个完整的、不可分割的技术闭环，旨在为读者揭示5G定位服务如何为特定应用开辟一条“VIP专线”——用户面定位，实现极致的低时延与高吞吐量。

1. 序章：AR电竞的“毫秒之争”

在之前的篇章中，我们探讨的所有定位流程，其信令（LPP消息）都承载在控制面（Control Plane）之上。控制面是网络的中枢神经，负责移动性管理、会话建立、安全认证等最高优先级的核心信令。将定位消息放在控制面，保证了其可靠性和普适性。

然而，当5G的应用场景进入“毫秒之争”的时代，控制面这条“国道”有时会显得拥挤。今天，我们的主角是职业电竞选手“Geek-Player-One”。他正在参加一场城市级的大型户外AR（增强现实）射击锦标赛——“CyberClash 2025”。

在这场比赛中，Geek-Player-One需要佩戴AR眼镜，在真实的城市街道中，与虚拟的敌人和队友进行实时互动。他的每一次移动、每一次瞄准，都需要被他头顶的定位无人机“鹰眼”（扮演UE）以每秒30次以上的频率进行捕捉，并将高精度的位置和姿态数据，实时发送给部署在边缘云上的游戏服务器（扮演LCS客户端/AF，并融合了LMF的部分功能）。

挑战是前所未有的：

  1. 极高频率：每秒数十次的定位更新，会产生海量的LPP消息。
  2. 超低时延：任何超过几十毫秒的延迟，都会导致虚拟影像与现实世界的“脱节”，严重影响比赛公平性。

如果这些高频、低时延的数据流全部涌入控制面，不仅会与寻呼、切换等核心信令“抢道”，造成网络拥堵，其自身的传输时延也难以得到保障。

为此，3GPP为这类“性能怪兽”级的应用，设计了一条全新的“数据高速公路”——用户面定位（Positioning over User Plane）。6.18和6.16章节，正是这张“高速公路”的“建设图纸”和“交通规则”。

2. “高速公路”的建设：用户面连接建立流程 (6.18)

在让数据“跑起来”之前，必须先把“路”修好。6.18章节的核心，就是定义了如何在UE（“鹰眼”无人机）与LMF（游戏服务器）之间，建立起一条专用的、安全的、端到端的用户面连接。

Clause 6.18 describes the management of the user plane connection between UE and LMF. LMF or UE may trigger the establishment of the user plane connection.

这条“路”不是普通的上网通道，而是一条为定位量身定制的专用PDU会话。它的建立，可以由**网络侧（LMF）发起，也可以由终端侧（UE）**发起。

2.1 网络发起的“邀请函”：LMF Initiated User Plane Connection (6.18.1)

当比赛开始，游戏服务器（LMF）需要为Geek-Player-One建立定位专线时，它会主动发起连接。

“Figure 6.18.1-1: Positioning via a User Plane Connection between UE and LMF initiated by LMF”展示了这场由网络主导的“建路”过程。

  1. LMF的决策与“邀请” (Step 1-3)：

    2. [Conditional] If LMF decides to utilize user plane for positioning …, LMF invokes Namf_communication_N1N2MessageTransfer service operation to send the user plane information to AMF… 3. [Conditional] When AMF receives the user plane information from LMF in step 2, AMF sends it to UE via a DL NAS TRANSPORT message.

    • 游戏服务器（LMF）分析比赛需求，决定必须使用用户面定位。
    • 它向AMF发送一条特殊的NAS消息，其中包含了LMF的用户面地址（IP地址或FQDN）和一把临时的“钥匙”——LCS-UP绑定ID。这份消息，就像一封发送给“鹰眼”无人机的“邀请函”。
    • AMF将这封“邀请函”透明地转发给无人机。

  2. UE的“赴约” (Step 4)：

    4. [Conditional] …UE uses the URSP as defined in TS 23.503 which includes user plane positioning related PDU session parameters, e.g. a dedicated DNN and S-NSSAI, to establish the PDU session… UE establishes a secured user plane connection with LMF.

    • “鹰眼”无人机收到邀请后，会根据其内部的URSP（UE路由选择策略）规则，启动一个专用的PDU会话建立流程。这个流程可能会使用一个专为游戏定位设定的DNN（数据网络名称，如”esports.lcs”）和S-NSSAI（网络切片标识）。
    • 这个PDU会话会被SMF智能地路由到离游戏服务器最近的UPF（用户面功能），建立起一条从UE到LMF的低时延数据路径。
    • 路径建立后，无人机与游戏服务器之间会建立一个安全的TLS隧道。
    • 最关键的一步：无人机通过这个刚刚建好的安全隧道，将之前收到的那把“钥匙”（LCS-UP绑定ID）发送给游戏服务器。

  3. “钥匙”配对，连接确认 (Step 4-8)：

    …the UE sends the LCS-UP binding ID received in step 3 to LMF via the secured user plane connection to enable LMF to perform the correlation of the UE with the secured user plane connection.

    • 游戏服务器（LMF）收到这把“钥匙”后，将其与自己之前发出的“钥匙”进行匹配。配对成功！ 它现在确信，这个刚刚建立的TLS隧道的另一端，正是它邀请的那个“鹰眼”无人机。
    • 这个“绑定”过程，完美地解决了“如何在不可信的用户面，将一个匿名的IP连接，与一个可信的、拥有SUPI身份的UE关联起来”的核心安全问题。
    • 之后，UE会通过控制面（经由AMF）向LMF发送一个最终的确认消息，告知“高速公路已建成并通车”。

2.2 终端发起的“申请”：UE Initiated User Plane Connection (6.18.2)

反之，也可以由UE主动发起。例如，Geek-Player-One在比赛大厅连接上游戏App的瞬间，App就可以驱动无人机主动申请建立定位专线。

“Figure 6.18.2-1: Positioning via a User Plane Connection between UE and LMF, initiated by UE”展示了这个过程。

  1. UE sends a user plane connection establishment request to AMF via NAS Message…
  2. [Conditional] … AMF selects an LMF which capable to establish a user plane session…
  3. [Conditional] The AMF sends a Nlmf_Location_UPConfig Request towards LMF…

这个流程与LMF发起的类似，但方向相反：

  1. UE → AMF：无人机向AMF发送一个“用户面连接建立请求”的NAS消息。
  2. AMF → LMF：AMF为这个请求，选择一个支持用户面定位的LMF（游戏服务器），并向其发送一个UPConfig Request，意为：“有个玩家想和你建一条专线，你同意吗？”
  3. LMF → AMF → UE：LMF同意后，同样返回自己的用户面地址和一把“钥匙”（LCS-UP绑定ID），由AMF转发给无人机。
  4. 后续流程：与6.18.1中UE“赴约”的步骤完全相同。

无论是“邀请”还是“申请”，最终的结果都是一样的：一条为“鹰眼”无人机和游戏服务器量身定制的、安全的、低时延的“定位高速公路”被成功建立。

3. “高速公路”的交通规则：用户面事件报告 (6.16)

“路”修好了，现在轮到“车”上路了。6.16章节，正是定义了定位数据这些“货车”，该如何在这条高速公路上行驶。

Figure 6.16.1-1 shows a procedure for event reporting from a UE to an LCS Client or AF when a User Plane connection is established directly from the UE to the LCS Client or AF.

3.1 增强版的“守护契约”

这个流程依然基于我们熟悉的“延迟MT-LR”（6.3）。游戏服务器（AF/LCS Client）在比赛开始前，会向GMLC发起一个针对“鹰眼”无人机的周期性定位请求（例如，每33毫秒上报一次）。但这份“契约”与众不同。

  • At step 1, the LCS Client or AF includes a request for user plane reporting in the LCS Service Request and may include a user plane address of the LCS Client or AF and security information…
  • At step 16, the LMF includes the request for user plane reporting, the user plane address, the security information … in the supplementary services LCS Periodic-Triggered Invoke Request sent to the target UE.
  1. AF的明确要求：游戏服务器在初始请求中，就明确包含了“请求使用用户面报告”的标志，并可能提供了自己的用户面地址和安全信息。
  2. LMF的授权下发：这个“特殊要求”会一路被传递到LMF。LMF在向无人机下发最终的“守护契约”（Invoke Request）时，会明确地“授权”它：“你可以、也应该通过用户面来上报后续的事件报告，这是服务器的地址和安全凭证。”

3.2 端到端的“数据直传” (Steps 2-7)

  1. The UE sends an Event Report to the LCS Client or AF over the secure user plane connection established at step 2.

“契约”生效后，比赛正式开始。

  1. UE本地定位 (Step 4a)：无人机的高性能定位模块（集成了GNSS、IMU等），以极高频率计算自身的精确位置和姿态。
  2. 数据直传 (Step 5)：无人机将这些定位数据打包成事件报告，然后直接通过那条已经建立好的、端到端的TLS安全隧道（用户面），发送给了游戏服务器。这个过程，完全绕过了AMF、GMLC等核心网控制面实体！
  3. 直接确认 (Step 6)：游戏服务器收到报告后，也直接通过该隧道，向无人机返回一个确认Ack。

这个“UE ←> AF/LMF”的端到端直接交互，就是用户面定位的“快”之精髓。它省去了所有控制面的中间转发环节，实现了最低的传输时延。

3.3 “控制面”的“安全绳”：累积事件报告 (Step 8)

用户面如此高效，是否意味着控制面就彻底“无事可做”了？并非如此。控制面还需要扮演“安全监督员”的角色。

  1. The UE monitors the criteria received at step 1 for sending of cumulative event reports. … When the cumulative event report timer expires …, the UE sends a cumulative event report … to the LMF, H-GMLC and LCS Client or AF over the control plane portion…
  1. 为何需要？：用户面连接是UE与AF之间的“私下约定”。如果这条连接因为某种原因（如UPF故障、AF服务器宕机）中断了，核心网的控制面（GMLC、LMF）可能对此一无所知。它们维护的那个延迟定位“会话”，可能会因为长期收不到任何消息而超时、被错误地释放。
  2. “安全绳”机制：为了解决这个问题，LMF在下发“契约”时，还会约定一个“累积事件报告”的规则，例如：“每隔1分钟，请通过控制面，向我简单汇报一下你这1分钟在用户面上的工作总结。”
  3. 执行：无人机在通过用户面高频发送数据的同时，内部还维护着一个计时器。每当计时器（如1分钟）到时，它就会生成一份“工作总结”（例如，“在过去60秒内，我通过用户面成功发送了1800份报告”），然后通过传统的控制面路径（经由AMF），上报给LMF和GMLC。

这份来自控制面的“心跳”，向核心网证明了“用户面会话依然健康存活”，从而避免了会话的意外中断。它就像系在高速飞驰的赛车手身上的一根安全绳，虽然平时感觉不到，但在关键时刻保证了整个系统的稳定和可靠。

4. 总结：为极致性能而生的“双轨制”

6.18和6.16共同为5G定位服务构建了一套完美的“双轨制”系统：

  • 控制面轨道：作为普适、高可靠的默认轨道，承载所有监管类定位和大部分常规商业定位。它确保了服务的广覆盖和稳定性。
  • 用户面轨道：作为一条按需建设、极致性能的“VIP专线”或“F1赛道”，专门服务于对时延、频率、带宽有极端要求的特定商业应用。

这套“双轨制”的核心思想是业务驱动、按需分离：

  • 连接的建立由控制面保障：用户面这条“高速公路”的建设申请、审批和安全认证（6.18），依然需要通过最可靠的控制面信令来完成，确保了其建立过程的安全可控。
  • 数据的传输由用户面加速：一旦建立，高频、海量的定位数据（6.16）便可以在这条“专线”上自由驰骋，享受最低时延和最高吞吐量。
  • 状态的监督由控制面维持：通过“累积事件报告”这根“安全绳”，控制面依然对用户面会话的健康状态保持着宏观的监督，确保了系统的整体鲁棒性。

对于Geek-Player-One，这套“双轨制”意味着他在虚拟世界中的每一个动作，都能在现实世界中得到毫秒级的响应。这不仅是技术的胜利，更是5G网络从“提供连接”到“提供确定性体验”的一次关键跃迁。

FAQ - 常见问题解答

Q1：用户面定位（Positioning over UP）和我们之前讲的UE-Based定位有什么关系？ A1：它们是两个正交维度的概念。UE-Based vs UE-Assisted vs Network-Assisted是关于“谁来计算位置”的划分。而Control Plane vs User Plane是关于“定位消息（LPP）走哪条路”的划分。这两者可以任意组合。例如，一个UE-Based的定位，LPP消息（包含了UE自己算好的位置）既可以通过控制面传输，也可以通过用户面传输。但通常，需要用户面传输的，都是些高频、低时延的场景，这些场景下的定位计算也往往在UE侧完成（UE-Based），以追求极致的端到端时延。

Q2：建立用户面定位专线，需要特殊的SIM卡或签约吗？ A2：是的。规范在6.16.1中明确提到“The H-GMLC verifies that both the target UE and the LCS Client or AF are subscribed to user plane reporting.” 这意味着，“允许使用用户面定位”是UE和LCS客户端的一项签约属性，存储在UDM和GMLC中。普通用户默认可能没有这个权限。这使得运营商可以将用户面定位，作为一种高级的、可单独售卖的增值服务。

Q3：这个用户面连接是UE直接和AF的公网IP通信吗？安全性如何保障？ A3：是的，它最终会建立一个UE与AF（或LMF）用户面IP地址之间的端到端连接。其安全性由多重机制保障：1) 连接建立的授权：如前所述，整个连接的建立过程由核心网的控制面（AMF, GMLC）严格授权和控制。2) 隧道安全：在IP层之上，规范要求建立一个安全的TLS隧道，所有传输的LPI消息都在这个加密隧道内，防止被窃听或篡改。3) 绑定ID机制：通过LCS-UP绑定ID的交换，确保了隧道的两端是经过核心网认证的、合法的通信方。

Q4：为什么累积事件报告（Cumulative Event Report）要走控制面，而不也走用户面？ A4：因为它汇报的对象和目的不同。用户面上的实时报告，其接收方是AF/LCS Client，目的是为了业务应用。而累积事件报告的接收方，还包括了H-GMLC和LMF，其核心目的是向核心网控制面证明“我还活着，用户面会话还正常”，以维持控制面会话的存活。如果它也走用户面，控制面将依然对用户面的状态一无所知，这根“安全绳”就失去了意义。

Q5：如果用户面连接中断了，定位服务会怎么样？ A5：如果用户面连接因网络原因中断，UE会检测到。此时，一个设计良好的UE协议栈会自动回退（Fallback）到使用控制面来发送事件报告。虽然时延和频率会受影响，但保证了定位服务的基本可用性。同时，累积事件报告的超时也会让核心网（GMLC/LMF）感知到异常，GMLC可能会通知AF，或者在后续的某个时机，尝试重新建立用户面连接。

关系图谱