51学通信

深度解析 3GPP TS 23.273：6.10.4 无需UDM查询的多位置报告MT-LR流程

20分钟阅读

深度解析 3GPP TS 23.273：6.10.4 无需UDM查询的多位置报告MT-LR流程

本文技术原理深度参考了3GPP TS 23.273 V18.9.0 (2025-03) Release 18规范中，关于“6.10.4 5GC-MT-LR multiple location procedure without UDM Query”的核心章节。本文将继续上一篇的紧急救援故事，跟随被送往医院的游客“安娜”，为您终极揭秘5G监管类定位服务中，功能最强大、响应最迅速的“王者级”流程——无需UDM查询的多位置报告，看5G网络如何为移动中的生命线，提供“电影级”的实时无缝追踪。

1. 序章：城市动脉中的“生死时速”

在之前的篇章中，我们已经见证了5G网络为正在进行紧急通话的漫游游客“安娜”，开辟了一条“无需UDM查询”的定位绿色通道（6.10.2），使得PSAP（公共安全应答点）能够快速获取她的“快照式”位置。我们也探讨了当安娜乘坐车辆移动时，LCS会话如何在网络切换中保持连续性（6.10.3）。

现在，场景变得更加紧迫。安娜已被好心的路人送上救护车，正穿梭在交通拥堵的异国城市街道上，前往最近的创伤中心。她的紧急通话仍在继续，医疗人员正通过电话指导现场急救。此时，PSAP指挥中心的调度员“马丁”面临着一个终极挑战：他需要的不再是几分钟更新一次的位置“点”，而是一条平滑、实时、不间断的轨迹“线”。他需要预判救护车的行进路线，为其规划出最快、最通畅的“绿色通道”，并提前通知医院做好抢救准备。

如果马丁每隔10秒就发起一次6.10.2的“单点”定位请求，虽然可行，但这在操作上繁琐，且无法保证轨迹的平滑性。他需要的是一种“一次订阅，全程直播”的能力。

这正是6.10.4章节存在的意义。它将两个最强大的监管定位功能——多位置报告（6.1.3）的连续性 与 无需UDM查询（6.10.2）的极速性——完美地融合在了一起，创造出了5G紧急定位的“终极形态”。它专为追踪移动中的紧急目标而生，旨在将定位服务从“照片”彻底升级为“高清实时视频”。

2. 王者合体：两大核心能力的强强联合

在深入流程细节之前，我们必须清晰地认识到，6.10.4并非一个全新的发明，而是对已有能力的精妙组合与升华。

  • 能力一：多位置报告 (Multiple Location Reporting) 我们曾在6.1.3章节（城市追捕场景）中详细解析过，它通过引入“中间报告（INTERMEDIATE response）”和“LMF直推GMLC”的机制，实现了对移动目标的“会话式”连续追踪。

  • 能力二：无需UDM查询 (without UDM Query) 我们刚刚在6.10.2章节（安娜的初次定位）中看到，它利用在紧急会话建立之初生成的“关联信息（Correlation Information）”，绕过了耗时的（尤其是跨国）UDM查询，实现了对已建立紧急会话UE的极速定位。

6.10.4的本质，就是在6.10.2这条“绿色通道”上，跑起了6.1.3的“连续直播”业务。 它让PSAP不仅能快速找到目标，更能持续、平滑地“锁定”目标。

3. “直播”开启：一份增强版的“绿色通道”请求 (Step 1)

这场“生死时速”的直播，始于PSAP调度员马丁的一次点击。

“Figure 6.10.4-1: 5GC-MT-LR Multiple Location Procedure without UDM Query”为我们描绘了这场直播的幕后运作。

  1. Steps 1-3 for 5GC-MT-LR procedure without UDM Query in clause 6.10.2 are performed with the following differences:

流程的启动，建立在6.10.2的快速通道之上，但增加了几个至关重要的“直播条款”。

  • At step 1 in clause 6.10.2 the request from external emergency client (e.g. a PSAP) location services client may include the acceptance of INTERMEDIATE response and maximum response time.
  • At step 2 in clause 6.10.2 Namf_Location_ProvidePositioningInfo service operation invoked by GMLC may include the acceptance of INTERMEDIATE response and maximum response time, GMLC contact address and LIR reference number.
  • At step 3 in clause 6.10.2 Nlmf_Location_DetermineLocation service operation invoked by AMF may include the acceptance of INTERMEDIATE response and maximum response time, GMLC contact address, and LIR reference number.

让我们逐一拆解这些被注入到“绿色通道”请求中的新“魔法”。

3.1 增强一：明确的“直播”意图

  • 接受中间报告 (Acceptance of INTERMEDIATE response)：PSAP在请求中明确告知GMLC：“我需要一个持续的轨迹，请LMF不要等到最后才给我结果，有任何位置更新都请立即‘推送’给我。” 这个标志，是开启“直播模式”的总开关。
  • 最大响应时间 (Maximum response time)：PSAP为这次直播设定了一个总时长，例如“10分钟”。这既是业务需求（预计10分钟内能到达医院），也是对网络资源的保护，防止会话无限期存在。

3.2 增强二：建立“回传专线”

  • GMLC联系地址 (GMLC contact address)：GMLC在向AMF下发任务时，会附上自己的“家庭住址”。
  • LIR参考号 (LIR reference number)：GMLC为这次直播分配了一个唯一的“频道号”。

这两个信息将被AMF一路传递给最终的执行者LMF。这相当于GMLC给了LMF一张“特别通行证”和“专用上报热线”，授权并指示LMF在后续的直播中，绕过AMF，直接向GMLC的这个“热线”进行汇报，并报上“频道号”。

场景模拟 - 启动阶段：

  1. PSAP → GMLC/LRF (Step 1)：马丁点击“开始实时追踪”，PSAP向LRF（与GMLC合设）发起请求，请求中包含了：

    • 关联信息 (来自安娜的紧急呼叫)。
    • 接受中间报告 标志。
    • 最大响应时间：600秒。

  2. GMLC/LRF → AMF (Step 2)：

    • LRF利用“关联信息”本地查找到安娜的AMF地址，绕过了UDM。
    • GMLC分配了“LIR参考号：Rescue-Anna-01”。
    • GMLC向AMF发起的ProvidePositioningInfo请求中，包含了上述所有信息，以及GMLC自身的联系地址。

  3. AMF → LMF (Step 3)：AMF选择LMF后，将这份完整的、增强版的“军令状”原封不动地交给了LMF。

LMF收到这份命令后，立刻明白了它的双重使命：不仅要定位，更要持续直播。

4. 直播进行时：LMF的持续推送 (Step 2 in 6.10.4)

  1. LMF performs positioning procedures and determines multiple location estimates during the session. 2.1 This step is executed if INTERMEDIATE response is available. The LMF invokes an Nlmf_Location_EventNotify service operation towards GMLC and provides the INTERMEDIATE location… 2.2 This step is executed if step 2.1 was executed. The GMLC sends the INTERMEDIATE location … to external location services client.

这个阶段，是6.1.3和6.10.4共有的核心执行环节，也是“直播”得以实现的技术核心。

  • LMF的持续工作：LMF进入“会话模式”，不断地与安娜的手机和周围的基站进行交互，利用卡尔曼滤波等高级算法，持续估算救护车的实时位置、速度和方向。

  • 智能推送逻辑：LMF根据内部算法，在最合适的时机（如位置变化超过阈值、或固定时间间隔到达），将最新的位置估算作为“中间报告”推送出去。

  • 高效的“专线”上报：每一次推送，LMF都调用Nlmf_Location_EventNotify服务，将报告（携带LIR参考号Rescue-Anna-01）直接发送到GMLC的“专用热线”上。

  • GMLC的实时转发：GMLC收到后，根据“频道号”Rescue-Anna-01，立即将这个最新的位置点转发给PSAP。

场景模拟 - 直播中：

  • 10:15:05 - 救护车驶出隧道，GNSS信号恢复。LMF计算出高精度位置P1，立即推送。马丁的屏幕上，安娜的光点瞬间变得精确。
  • 10:15:08 - 救护车在路口右转。LMF根据连续的位置点，计算出速度和方向的变化，推送了新位置P2。马丁屏幕上的轨迹随之平滑右转。
  • 10:15:10 - … 直播流不间断地传来，马丁据此实时地为救护车规划着前方的交通信号灯，并通知沿途交警配合清空道路。

5. 直播结束：最终报告与资源释放 (Steps 3 & 4)

  1. Based on step 5 in clause 6.10.2 the LMF returns the Nlmf_Location_DetermineLocation Response towards the AMF to return the FINAL location of the UE…
  2. Steps 6-7 for 5GC-MT-LR procedure without UDM Query in clause 6.10.2 are performed with the following differences:
  • At step 7 the FINAL location is sent from GMLC to the external services client.

当救护车抵达医院，或者10分钟的maximum response time耗尽时，直播需要优雅地结束。

  • LMF的“结案陈词” (Step 3)：LMF会发送一份最终报告（FINAL location）。与中间报告不同，这份最终报告会沿着LMF → AMF → GMLC的“标准路径”传递。这就像直播结束后的正式“下播”信号，通知链条上的所有参与者（特别是AMF）可以释放为此会话保留的资源了。
  • GMLC的最终交付 (Step 4)：GMLC在收到这份FINAL报告后，将其发送给PSAP，标志着此次实时追踪任务的正式结束。

6. 四大监管MT-LR流程对比

至此，我们已经学习了5G中四种核心的、用于监管服务的MT-LR流程。它们就像一个工具箱，为不同的紧急场景提供了定制化的解决方案。

流程 (TS 23.273)核心特性典型用例UDM查询报告模式“王者”比喻
6.1.1标准单次定位对静态求救者（如登山失足）的首次定位。需要单次最终报告狙击手：一枪毙命，精准打击。
6.1.3标准多次定位对移动嫌疑人（如车辆追捕）的持续追踪。需要多次中间+一次最终侦察无人机：持续盘旋，全程监控。
6.10.2快速单次定位对正在通话中的紧急会话，进行按需的“快照”定位。无需单次最终报告特种兵：利用已有通道，快速渗透获取情报。
6.10.4快速多次定位对正在通话中的移动紧急目标，进行无缝的实时轨迹追踪。无需多次中间+一次最终空天一体战：卫星（IMS会话）提供引导，无人机（LMF）执行持续、实时的精确打击。

7. 总结：5G紧急定位能力的巅峰之作

6.10.4流程，无疑是3GPP为5G监管类定位服务设计的“巅峰之作”。它集极速响应、无缝连续、跨网兼容于一身，完美地解决了移动目标在紧急状态下的实时追踪难题。

  • 速度的极致：通过复用6.10.2的“关联信息”机制，它彻底消除了最耗时的跨国UDM查询瓶颈。
  • 连续性的极致：通过复用6.1.3的“中间报告推送”机制，它将定位服务从“点”的采集升级为“线”的描绘。
  • 架构的优雅：它并非推倒重来，而是巧妙地将已有流程的优点进行组合，并通过新增少量“契约参数”（如LIR参考号、GMLC地址），实现了1+1>2的系统能力涌现。

对于安娜，对于所有在危急时刻需要帮助的人们，这套流程意味着5G网络提供的生命线，不仅能被快速接通，更能如影随形，直至他们脱离险境。这，就是技术标准背后最温暖的人文关怀。

FAQ - 常见问题解答

Q1：既然6.10.4这么强大，为什么不把所有的紧急定位都用这个流程呢？ A1：因为“杀鸡焉用牛刀”。6.10.4是为“正在进行的、移动中的”紧急会话设计的，资源消耗相对较高（需要LMF维持长期会话）。对于一个静态的、只需要一次定位的求救者，使用更简单的6.1.1或6.10.2流程，可以更快地得到首次结果并释放网络资源，效率更高。工具箱里的工具，要用在最合适的场景。

Q2：LMF向GMLC推送中间报告的Nlmf_Location_EventNotify服务，和AMF向GMLC上报切换事件的Namf_Location_EventNotify服务，是同一个服务吗？ A2：它们的服务名称相同，都叫EventNotify，但它们的提供者和内容完全不同。前者是Nlmf_Location服务的一部分，由LMF提供，内容是UE的位置更新。后者是Namf_Location服务的一部分，由AMF提供，内容是UE的网络事件（如切换、会话释放）。5G服务化架构中，很多NF都会提供EventNotify操作，用于异步通知，需要根据其所属的服务（如Nlmf_Location或Namf_Location）来区分。

Q3：如果救护车在行驶过程中，发生了6.10.3中描述的5G到4G的切换，这个6.10.4的“直播”会中断吗？ A3：不会中断，而是会平滑过渡。这是一个非常好的、融合了多个流程的问题。当切换发生时，6.10.3的机制会被触发：源AMF会通知GMLC“主管换人了，新主管是MME-xyz”。GMLC更新档案后，会将下一个单次的、按需的MT-LR请求，发给新的MME。但是，由于这是一个多位置报告会话，GMLC在向MME发起请求时，会再次附上“接受中间报告”、“LIR参考号”等信息。MME会选择一个4G的E-SMLC，并将这些信息传递下去。E-SMLC接手后，便会开始向GMLC“推送”中间报告。虽然后台的执行者从5G-LMF换成了4G-E-SMLC，但对于最上层的PSAP而言，“直播”仍在继续。

Q4：这个流程图中只画了AMF、LMF、GMLC，那么UE和RAN（基站）在这个过程中做了什么？ A4：UE和RAN是“直播”内容的生产者。虽然在6.10.4这种高层流程图中它们被简化了，但实际上，在LMF执行定位的每一个循环中（Step 2），都在发生着6.11中定义的、与UE和RAN的复杂交互。LMF不断地通过AMF和RAN，向UE下发LPP指令（如请求GNSS测量），并从RAN收集UL-TDOA测量报告。UE和RAN是提供原始测量数据的“一线部队”。

Q5：为什么最终报告（FINAL location）一定要通过AMF，而不能也走LMF→GMLC的“专线”？ A5：这主要是为了确保会话状态的最终一致性和资源的可靠释放。AMF是UE在核心网的唯一“法定监护人”，它管理着UE的所有会话上下文。通过AMF来传递最终的、带有“结束”标志的报告，可以确保AMF能够明确地知道这个LCS会话已正式终结，从而安全地清理与此会话相关的所有内部资源。如果最终报告也绕过AMF，AMF可能会对会话是否已结束产生状态不一致，导致资源泄露。

关系图谱