51学通信

深度解析 3GPP TS 23.273：6.9 非3GPP接入定位(Part 2 - 跨PLMN的决策风暴)

20分钟阅读

深度解析 3GPP TS 23.273：6.9 非3GPP接入定位(Part 2 - 跨PLMN的决策风暴)

本文技术原理深度参考了3GPP TS 23.273 V18.9.0 (2025-03) Release 18规范中，关于“6.9.2 MT-LR Procedures when a UE is served by Different PLMNs for 3GPP Access and Non-3GPP Access”的核心章节。本文将通过一个争分夺秒的跨国医疗救援场景，为您深度剖析当一个5G终端同时连接到两个不同运营商网络（一个通过蜂窝，一个通过Wi-Fi）时，5G核心网的“最高指挥部”——HGMLC，是如何进行一场复杂的决策风暴，以选择最佳路径，完成“不可能完成”的定位任务。

1. 序章：跨越重洋的“生命之心”

在上一篇文章中，我们见证了5G定位服务如何在一个统一的框架下，无缝支持Wi-Fi等非3GPP接入。然而，当我们将“非3GPP接入”与“漫游”这两个复杂的场景叠加时，挑战将呈指数级增长。

今天，我们的主角是一只肩负着神圣使命的5G智能温控箱——“生命速运-C01”。它的内部，是一颗等待移植的心脏，正从欧洲（我们称之为归属地网络 HPLMN）被紧急空运至中国（到访地网络 VPLMN）。温控箱内置了双接入能力的5G模组，它既能连接到中国运营商的5G漫游网络（3GPP Access），也能连接机场货运站提供的、与该运营商5G核心网深度融合的高速Wi-Fi网络（Non-3GPP Access）。

飞机刚刚落地，温控箱被卸载到了一个巨大的、信号环境复杂的室内货运站。在停机坪另一侧，一支心脏移植医疗队已焦急等候。此时，“全球器官匹配与运输协调中心”（扮演LCS客户端/AF）需要立即获取温控箱在货运站内的亚米级精准位置，以便引导地面团队以最快速度完成交接。

这就是6.9.2章节所要应对的终极挑战：一个漫游中的UE，同时在两个不同的网络（归属地HPLMN的漫游服务 vs 到访地VPLMN的Wi-Fi服务）中拥有“身份”，负责定位的归属地GMLC（HGMLC）该如何抉择？这场看不见的“决策风暴”，直接关系到一颗心脏的“黄金救援时间”。

2. 核心挑战：一个UE，两个“管家”

在常规场景下，一个UE在同一时间只会向一个AMF注册，由这个唯一的AMF管理其移动性和连接。但当漫游与非3GPP接入结合时，情况发生了根本性的变化。

“生命速运-C01”落地后：

  • 通过3GPP接入（蜂窝网络），它以漫游的方式，在中国运营商（VPLMN）的网络中注册，其服务由VPLMN中的一个AMF-1管理。
  • 同时，它扫描到机场强大的Wi-Fi信号，通过非3GPP接入，也向同一个VPLMN的核心网进行了注册，而这一次，服务它的可能是另一个AMF-2。

这意味着，对于“生命速运-C01”这同一个UE，在VPLMN中可能同时存在两个AMF在为它服务！这就像一个跨国公司的员工，同时向总部的HR和分公司的HR汇报工作。当总部的CEO（HGMLC）想要找到他时，他该问谁？

这个“双重身份”问题，正是6.9.2流程必须解决的核心。

3. 总指挥官的“情报网”：UDM的关键角色 (Steps 1-3)

“Figure 6.9.2-1: MT-LR positioning procedures when UE is served by the two VPLMNs”为我们描绘了这场复杂决策的作战地图。（注：规范图标题中的“two VPLMNs”在上下文中应理解为“一个UE在VPLMN中通过两种接入方式由可能不同的AMF服务”，而非两个不同的VPLMN）。

3.1 第一、二步：常规的请求发起

  1. The step is same as step 1 in clause 6.1.1 or clause 6.3.1.
  2. The step is same as step 2 in clause 6.1.1 or clause 6.3.1.

流程的起点与标准MT-LR无异。位于欧洲的“协调中心”（AF）向其归属运营商（HPLMN）的HGMLC发起了对“生命速运-C01”的高精度定位请求。HGMLC随即对AF进行授权，并准备向UDM查询UE的隐私和路由信息。

3.2 第三步：UDM返回的“爆炸性”情报

这是整个流程的第一个、也是最具颠覆性的转折点。

  1. The step is same as step 3 in clause 6.1.1 or clause 6.3.1 with the difference that when the UE is served by more than one AMF the UDM provides to the HGMLC for each access type,
  • serving AMF identity with the corresponding PLMN Id,
  • possibly a VGMLC address.

当HGMLC向HPLMN的UDM查询温控箱的路由信息时，UDM返回的不再是一个简单的AMF地址，而是一份包含“爆炸性”情报的列表：

  • 接入类型 3GPP：服务AMF = AMF-1，所属PLMN = VPLMN-China，关联VGMLC = VGMLC-A。
  • 接入类型 Non-3GPP：服务AMF = AMF-2，所属PLMN = VPLMN-China，关联VGMLC = VGMLC-B。

这份列表，正式将“一个UE，两个管家”的复杂局面摆在了总指挥官HGMLC的面前。它现在知道，它有两条独立的路径可以尝试去定位这个温控箱。

4. 决策风暴：HGMLC的“兵棋推演” (Step 4)

手握这份“情报列表”，HGMLC进入了流程的核心——决策。它不能再像过去一样简单地转发请求，而必须扮演一名运筹帷幄的指挥官，根据多维度的信息，进行一场“兵棋推演”，以决定首先尝试哪条路径。

  1. When the HGMLC identifies that the UE is served by different PLMNs according to the returned information from the UDM in step 3 it may retrieve the CM state(s) per Access Type from the candidate AMFs… The HGMLC selects one access type and its associated AMF based on the UDM returned information in step 3, QoS requirement, CM state(s) per Access type of the UE, PLMN identity and/or the locally configured operator policy.

HGMLC的决策依据堪称一场“多方会审”：

  1. 连接状态 (CM state per Access type)：这是最重要的依据。HGMLC可能会向两个AMF（AMF-1和AMF-2）发起查询，获取UE在两种接入方式下的连接状态。

    • AMF-1（3GPP）汇报：“目标当前在我这处于 CM-IDLE 状态，信号很弱。”
    • AMF-2（Non-3GPP）汇报：“目标当前在我这通过Wi-Fi处于 CM-CONNECTED 状态，信号极强。”

  2. QoS要求 (QoS requirement)：请求要求亚米级精度。HGMLC知道，在室内环境下，高精度的Wi-Fi定位（如RTT）远比蜂窝定位更有可能满足这个要求。

  3. 运营商策略 (Operator policy)：HPLMN与VPLMN之间的漫游协议可能规定，优先使用VPLMN提供的本地接入服务（Wi-Fi），以降低漫游结算成本。

HGMLC的推演结论： “目标需要高精度，当前处于室内，Wi-Fi连接活跃且信号强，而蜂窝连接空闲且信号弱。策略也鼓励使用本地接入。决策：首次尝试，选择Non-3GPP接入路径！”

这场决策风暴，体现了5G核心网的智能化。它不是盲目地轮询，而是基于对UE状态的深刻洞察，做出的最优路径选择。

5. 首次尝试：经由VPLMN的Wi-Fi定位路径 (Steps 5-9)

决策既定，HGMLC立即执行。

  1. The HGMLC forwards the location request to the VGMLC-1 and may include the V-AMF-1 identity received in step 3 and the target UE identity (e.g. SUPI).
  2. The VGMLC-1 invokes the Namf_Location_ProvideLocation_Request service operation to forward the location request to the V-AMF-1.
  3. This step is same as step 2-3 of the Common Positioning Procedures in clause 6.9.1.
  1. HGMLC → VGMLC (Step 5)：HGMLC将定位请求转发给VPLMN中负责非3GPP接入的VGMLC-B。
  2. VGMLC → AMF (Step 6)：VGMLC-B再将请求转发给服务于Wi-Fi接入的AMF-2。
  3. 执行通用定位流程 (Step 7)：接下来，AMF-2和其选择的V-LMF-2启动了我们上一篇文章分析的6.9.1通用定位流程。它们会选择最高效的Wi-Fi定位方法（如Wi-Fi RTT），与温控箱进行交互，并计算出位置。
  4. 结果返回 (Steps 8-9)：V-LMF-2将结果返回给V-AMF-2，再经由VGMLC-B，最终送达HGMLC。

6. 结果的审判与“备用计划” (Steps 10-11)

HGMLC收到了首次尝试的结果。此时，它需要扮演“法官”的角色，对这份结果进行审判。

  1. For a request for an immediate location, if the HGMLC identifies that the location service response from the chosen PLMN meets required LCS QoS, it returns the results to the LCS Client directly. Otherwise, the HGMLC may forward the location request to another AMF (in another PLMN) so as to obtain the positioning result which can meet required LCS QoS shown as step 11.

这里出现了流程的第二个关键分叉点：

6.1 场景一：首次尝试成功

V-LMF-2通过Wi-Fi RTT成功计算出位置，精度高达1.5米。HGMLC将这个结果与请求的亚米级QoS一比较，“审判”通过！

  • 流程结束：HGMLC立即将这个高精度位置结果（Steps 12-13）发送给“协调中心”。“协调中心”的屏幕上，温控箱被精准标记在“货运站B区-3号泊位”。医疗队立即前往。整个流程高效结束。

6.2 场景二：首次尝试失败 → 启动备用计划

现在，让我们假设一个意外情况：温控箱所在的那个货运泊位，Wi-Fi信号虽然强，但AP设备老旧，不支持高精度的RTT定位。V-LMF-2只能回退到Wi-Fi指纹定位，最终返回给HGMLC一个精度只有20米的结果。

  • “审判”失败：HGMLC将20米精度与请求的亚米级QoS一比较，“审判”不通过！

  • 启动备用计划 (Step 11)：HGMLC并不会就此放弃。它从“情报列表”中拿出了第二套方案——通过3GPP蜂窝网络进行定位。

    11. This step obtains the immediate positioning information or requests a deferred location from another PLMN, the details are the same as steps 5-9.

    HGMLC现在会重复Steps 5-9的流程，但这次，它会将请求发送给服务于3GPP接入的VGMLC-A和AMF-1。AMF-1和V-LMF-1会尝试使用蜂窝定位技术（如UL-TDOA或E-CID）再次进行定位。

7. 终章：殊途同归，使命必达 (Steps 12-13)

无论第二次尝试的结果如何（可能成功，也可能因为信号太弱而再次失败），HGMLC都会将它所拥有的、最接近QoS要求的结果，返回给“协调中心”。

12-13. The HGMLC returns a location service response to the LCS client. For a request for immediate location, if the positioning result from the other PLMN meets the QoS requirement, the HGMLC returns it to the LCS client. Otherwise, the HGMLC returns final location service response without including any positioning result.

最终，“协调中心”收到了来自第二次尝试的、精度为8米的蜂窝定位结果。虽然不如预期的亚米级，但这已经足够引导医疗队找到正确的区域。一场与时间的赛跑，在5G网络智能、鲁棒的定位决策支持下，赢得了胜利。

8. 总结：多维决策下的极致可靠性

6.9.2章节为我们展示了一幅极其复杂的、却又逻辑严密的“跨网协同定位”画卷。它不仅是漫游和非3GPP接入的简单叠加，更是一套全新的、基于多维信息智能决策的迭代式、容错性定位框架。

  • 决策的中心化：将复杂的路径选择决策权，统一收归到HGMLC。HGMLC基于从UDM获取的全局视图，扮演了无可替代的“总指挥官”角色。
  • 情报的全面性：决策不再依赖单一信息，而是综合了接入类型、连接状态、QoS要求、运营商策略等多维度情报，实现了真正的智能决策。
  • 流程的迭代性：引入了“首次尝试-审判-二次尝试”的迭代机制。这使得定位服务不再是一次性的“赌博”，而是一个具备容错和备份能力的、追求“使命必达”的可靠流程。
  • 架构的模块化：整个复杂流程，巧妙地复用了标准的MT-LR流程（6.1.2）和通用的非3GPP定位流程（6.9.1），体现了3GPP标准设计的高度模块化和可重用性。

对于“生命速运-C01”这样的关键任务物联网设备，这套流程意味着无论它身处多么复杂的网络环境中，5G系统总能竭尽所能，通过“ Plan A”和“ Plan B”，为它找到最优的、最可靠的定位路径。这正是5G网络迈向高可靠、智能化服务的坚实一步。

FAQ - 常见问题解答

Q1：为什么需要HGMLC来做决策，而不是让UE自己选择一个网络来上报位置？ A1：这是一个中心化控制与分布式决策的经典问题。由HGMLC中心化决策有几大优势：1) 全局最优：HGMLC拥有来自UDM的全局信息和运营商的全局策略，能做出比单个UE更明智的决策。2) 功耗节省：如果让UE自己去评估两个网络的定位能力，需要UE进行额外的测量和信令交互，会增加功耗。3) 安全可控：中心化的决策点便于运营商进行统一的策略管理、计费和安全监控。4) 能力屏蔽：对上层AF屏蔽了UE侧复杂的双连接状态，简化了应用的开发。

Q2：在Step 4，HGMLC向两个AMF查询CM State，这个查询本身会不会很慢，影响定位的实时性？ A2：不会。5G核心网的服务化接口（SBI）是基于HTTP/2等现代化协议构建的，一次简单的状态查询，其信令交互时延通常在毫秒级。相比于后续需要与UE进行多轮无线交互的定位流程（可能耗时数秒），这个决策阶段的开销几乎可以忽略不计，但它为后续选择正确路径带来的收益是巨大的。

Q3：如果UE同时连接的3GPP和非3GPP接入分属两个不同的VPLMN（例如，手机卡是运营商A的，在B国漫游，连接的是C国的机场Wi-Fi），这个流程还适用吗？ A3：适用。这正是这个流程设计的强大之处。在Step 3，UDM会返回两个分属不同PLMN ID的AMF地址。HGMLC在Step 4进行决策时，PLMN Identity也是其考虑的重要因素之一。它会根据与这两个VPLMN的漫游协议、结算成本等策略，来决定优先尝试哪一个。流程的本质——迭代和决策——保持不变。

Q4：整个6.9.2流程对UDM提出了什么新的要求？ A4：UDM的角色得到了极大的增强。它不再仅仅是一个存储用户静态签约数据的数据库。它必须能够：1) 存储和管理UE在多种接入类型下的注册信息，即能够将一个SUPI关联到多个（AMF ID, Access Type, PLMN ID）的元组。2) 实时更新这些注册信息。3) 能够响应来自HGMLC的、针对特定UE多种接入信息的复杂查询。UDM真正成为了UE多接入状态的“权威事实来源（Source of Truth）”。

Q5：在这个流程中，如果首次尝试（Wi-Fi定位）返回的结果精度已经满足了QoS，HGMLC还会不会去尝试第二次（蜂窝定位）？ A5：不会。规范在Step 10明确指出，只要HGMLC判定收到的结果满足了要求的QoS，它就会直接将结果返回给LCS客户端，整个流程随即成功结束。只有在“审判不通过”的情况下，才会启动“备用计划”（Step 11）。这体现了流程的效率原则——以最快、最低成本的方式达成目标。

关系图谱