深度解析 3GPP TS 23.273：6.10.2 无需UDM查询的MT-LR：紧急会话的“绿色通道”

本文技术原理深度参考了3GPP TS 23.273 V18.9.0 (2025-03) Release 18规范中，关于“6.10.2 5GC-MT-LR Procedure without UDM Query”的核心章节。本文将通过一名游客在异国他乡拨打紧急电话的场景，为读者深度剖析5G网络如何为正在进行的紧急会话，开辟一条“免检”的、极致高效的定位绿色通道。

1. 序章：异国街头的紧急呼叫

在上一篇文章中，我们见证了当车辆eCall系统自动触发紧急会话时，AMF如何主动发起NI-LR定位。那个流程解决了“从无到有”的问题——在紧急事件发生的初始时刻，网络主动获取一次位置。然而，在真实的救援场景中，一次性的位置“快照”往往不够。

今天，我们的主角是游客“安娜”。她正在一个陌生的国家旅行（位于VPLMN），而她的手机签约归属于自己的国家（HPLMN）。她在街头目睹了一场严重的交通事故，并立即拨打了当地的紧急号码（如112）。电话迅速接通了本地的公共安全应答点（PSAP）。

在电话中，PSAP接线员需要安娜描述事故现场的具体位置。但安娜身处异国，语言不通，根本无法说清自己在哪条街道。此时，接线员需要在通话过程中，反复、按需地获取安娜的实时位置，以引导最近的警力和救护车。

这个“通话中，按需定位”的请求，如果走标准的MT-LR流程（6.1.1），VPLMN的GMLC需要跨越重洋，去查询安娜HPLMN中的UDM，以找到她当前在VPLMN的服务AMF。这个跨国查询无疑会增加宝贵的延迟。

为了应对这一挑战，3GPP设计了6.10.2 无需UDM查询的MT-LR流程。它利用一个在紧急呼叫建立之初就已生成的“秘密武器”——关联信息（Correlation Information），彻底绕过了耗时的UDM查询，为正在进行的紧急会话，开辟了一条定位的“绿色通道”。

2. 核心魔法：关联信息 (Correlation Information)

在深入流程之前，我们必须理解这个“秘密武器”的来源和作用。

Figure 6.10.2-1 illustrates a location request for an emergency services session, where an emergency services client (e.g. a Public Safety Answering Point) identifies the target UE and the serving LRF using correlation information that was previously provided to it by the IMS Core.

这段原文揭示了魔法的核心：

1. 来源：correlation information是在安娜发起紧急呼叫的初始阶段，由网络（IMS核心网、AMF）生成，并主动提供给PSAP的。
2. 作用：它像一个临时的“案件编号”或“会话令牌”，将安娜的这次IMS语音通话，与她在5G核心网中的数据上下文（特别是她当前的服务AMF地址）牢牢地绑定在了一起。

这是如何发生的？ 实际上，当安娜的紧急呼叫被建立时，网络已经悄悄地为她执行了一次我们上篇文章分析的NI-LR（6.10.1）流程。在那次流程中（Step 5），AMF不仅将安娜的初始位置通知给了GMLC/LRF，更重要的是，它将自己的地址以及一个用于关联本次紧急会话的ID，一并报告了上去。GMLC/LRF将这个“案件编号”和AMF地址缓存下来，并将“案件编号”提供给了PSAP。

现在，PSAP、GMLC/LRF、AMF三方，都拥有了同一个“案件编号”。这张无形的网络，为后续的快速定位铺平了道路。

3. “绿色通道”详解：一场免检的极速定位

“Figure 6.10.2-1: 5GC-MT-LR Procedure without UDM Query”为我们展示了这条“绿色通道”的运行图。

3.1 第一步：手持“令牌”的请求

1. The external emergency services client (e.g. a PSAP) sends a request to the LRF for a location for the target UE and includes correlation information identifying the target UE.

PSAP的接线员在屏幕上点击“定位报案人”按钮。PSAP的系统立即向之前收到的地址（GMLC/LRF）发起定位请求。这个请求与标准MT-LR最大的不同在于，它的核心身份凭证不再是安娜的SUPI或GPSI，而是那个独一无二的“关联信息”（案件编号）。

这就像是手持一张VIP通行证，直接走向了绿色通道的入口。

3.2 第二步：绕过UDM的“抄近路”

这是整个流程的灵魂所在。

2. The LRF/GMLC determines the AMF by associating the correlation information received from the external client with other information received previously from the AMF as described in step 5 of clause 6.10.1… The GMLC invokes the Namf_Location_ProvidePositioningInfo service operation towards the AMF…

当GMLC/LRF收到这个携带“令牌”的请求后，它执行了一个极其高效的动作：

1. 本地查找：它在自己的缓存中，以“关联信息”为索引，进行了一次本地查找。
2. 信息匹配：它迅速找到了在紧急呼叫建立之初（NI-LR流程中）由AMF上报并缓存的那条记录。这条记录里，包含了安娜当前服务AMF的地址。
3. 直接转发：GMLC/LRF立即将定位请求，直接转发给了这个已知的AMF地址。

UDM被完美地绕过了！ 对于身为漫游用户的安娜，这意味着VPLMN的GMLC无需再进行任何跨国信令交互，直接在本地就找到了正确的执行者。救援的“黄金时间”被最大程度地节省了下来。

3.3 第三至第七步：熟悉的标准执行路径

一旦AMF被找到，后续的流程便回归到了我们熟悉的、最高效的监管类定位执行路径。

3. The AMF selects an LMF…
4. The LMF performs one or more of the positioning procedures…
5. The LMF returns the Nlmf_Location_DetermineLocation Response towards the AMF…
6. The AMF returns the Namf_Location_ProvidePositioningInfo Response towards the GMLC/LRF…
7. The LRF sends the location service response to the external emergency services client.

这个过程与6.10.1中的执行部分几乎完全一样：

• AMF选择最合适的LMF。
• LMF执行高精度的混合定位（如GNSS+UL-TDOA）。
• LMF将结果返回给AMF。
• AMF将结果返回给GMLC/LRF。
• GMLC/LRF最终将结果呈现给PSAP。

PSAP的接线员可以在通话过程中，根据救援的实时需要，多次发起这样的“免检”定位请求，每一次都能通过这条绿色通道，得到安娜最新的、高精度的位置。

4. 谁是最大的受益者？漫游者与“无卡”求救者

这个看似简单的流程优化，对于两类特殊的紧急求救者，具有里程碑式的意义。

This scenario therefore supports location of emergency sessions from roamers and USIM-less and other non-registered UEs…

4.1 漫游者 (Roamers)

正如安娜的案例所示，对于漫游用户，其签约数据（包括隐私、AMF注册信息等）都存储在归属国的HPLMN UDM中。标准的MT-LR必须通过跨国信令查询HPLMN UDM，延迟高且可能因网络问题失败。而6.10.2流程将“寻找AMF”这个关键步骤完全本地化在了VPLMN内部，极大地提升了对漫游用户紧急定位的速度和可靠性。

4.2 无USIM卡/未注册的UE (USIM-less / Non-registered UEs)

许多国家和地区的法规要求，即使手机里没有SIM卡，或者因为欠费等原因未在网络中正常注册，也必须能够拨打紧急电话。

• 身份缺失：对于这些UE，网络中可能根本没有它们的SUPI，UDM中也没有它们的完整档案。
• 会话即身份：在这种情况下，那个在紧急通话建立时生成的“关联信息”，就成为了唯一能够将这个“匿名”的通话设备与其在核心网中的临时上下文（如服务AMF）联系起来的纽带。

如果没有6.10.2流程，对这类“无卡”求救者的按需定位将几乎无法实现。正是这套基于会话关联的机制，确保了无论求救者是谁，只要他的电话还在通话中，他的位置就能被持续追踪。

5. 总结：NI-LR与MT-LR的“二重奏”

6.10.2流程并非孤立存在，它与6.10.1的NI-LR流程共同构成了一场完美的“紧急定位二重奏”：

• 第一乐章（NI-LR）：当紧急呼叫发起时，由AMF演奏的“主动快板”。它以最快速度，主动获取并上报一次初始位置，同时，悄悄地在PSAP、GMLC和AMF之间，建立起一个基于“关联信息”的隐形契约。

• 第二乐章（无UDM查询的MT-LR）：在紧急呼叫进行中，由PSAP按需发起的“精准慢板”。它利用第一乐章建立的契约，通过“绿色通道”，反复、高效地获取目标位置，为救援指挥提供持续的、精细的“炮火引导”。

这套“先主动、再按需、全程高速”的组合拳，将5G网络的监管类定位服务能力推向了一个新的高峰。它不仅是技术的精进，更是3GPP标准对“生命至上”这一社会承诺的深刻践行。

---

FAQ - 常见问题解答

Q1：这个“无需UDM查询”的流程，与标准MT-LR（6.1.1）相比，究竟快了多少？ A1：在非漫游场景下，节省的时间是一个UDM查询的往返时延（通常是几十到几百毫秒）。但在漫游场景下，节省的时间是一次跨国的UDM查询时延，这可能长达数百毫秒甚至数秒，并且避免了跨国链路可能出现的不稳定性。对于分秒必争的紧急救援，这点时间至关重要。

Q2：如果安娜在通话过程中移动，导致服务AMF发生了改变，这个流程会失败吗？ A2：不会失败，这正是5G移动性管理的强大之处。当AMF发生变更时（Inter-AMF Handover），旧AMF会将包括紧急会话上下文和“关联信息”在内的所有信息，全部转移给新AMF。GMLC/LRF与AMF之间的关联也会被更新。因此，下一次PSAP发起定位请求时，GMLC/LRF的本地缓存会指向新的AMF，流程依然可以无缝继续。

Q3：这个流程中提到了LRF，它和GMLC到底是什么关系？ A3：LRF（位置检索功能）是IMS紧急呼叫架构中的一个关键实体，专门负责关联语音呼叫和位置信息。GMLC是LCS架构中的核心，负责处理定位请求。在实际部署中，LRF的功能常常与GMLC**合设（co-located）**在一起，形成一个统一的紧急定位网关。因此，规范中常写作GMLC/LRF，表示这个实体既懂IMS呼叫，又懂LCS定位。

Q4：“关联信息”是一次性的吗？紧急通话结束后还能用吗？ A4：它是与紧急会话生命周期绑定的，可以认为是“会话级”的。在紧急通话期间，PSAP可以凭此信息多次发起定位。但一旦紧急通话结束，相关的会话上下文（包括这个关联信息）就会在网络中被清除（如6.10.1的Step 8所描述）。之后，PSAP如果再使用这个过期的“令牌”来请求定位，将会失败。

Q5：为什么这么高效的流程，不应用在商业定位（如外卖追踪）上呢？ A5：因为它有一个不可或缺的前提：存在一个正在进行的、由网络深度参与的、最高优先级的“会话”（即紧急呼叫）。商业定位场景通常不具备这样的前提。此外，商业定位的核心是隐私保护，每一次请求都必须经过UDM的隐私审查，这是不能被“抄近路”绕过的。而紧急定位的最高原则是救助生命，因此可以牺牲常规的查询流程，换取极致的速度。