51学通信

深度解析 3GPP TS 23.273：6.3.2 & 6.3.3 解除“守护契约”：延迟定位的取消流程

19分钟阅读

深度解析 3GPP TS 23.273：6.3.2 & 6.3.3 解除“守护契约”：延迟定位的取消流程

本文技术原理深度参考了3GPP TS 23.273 V18.9.0 (2025-03) Release 18规范中，关于“6.3.2 Cancellation of Reporting of Location Events by a UE”和“6.3.3 Cancellation of Reporting of Location Events by an AF, an NF or External LCS Client or GMLC”的核心章节。本文将这两节内容合并解读，因为它们共同构成了延迟定位会话生命周期中至关重要的“终止”环节，分别从UE和网络两个相反的方向，阐述了如何优雅地、可靠地解除我们上一章所建立的“守护契约”。

1. 序章：当守护不再需要

在上一篇文章中，我们为巡检员“老王”的智能安全头盔成功部署了一套全天候的“守护契约”（延迟MT-LR流程），头盔化身为一个智能哨兵，在满足特定条件时主动上报位置，实现了低功耗下的高枕无忧。然而，任何一个有始有终的系统，都必须有一个清晰、可靠的“终止”机制。当巡检任务结束，或者监控需求改变时，我们如何通知“哨兵”解除警戒？

这就是6.3.2和6.3.3章节的核心议题——取消（Cancellation）。这不仅仅是简单地停止上报，更是一套严谨的信令流程，确保UE和网络双方都能就“任务结束”这件事达成共识，并干净利落地释放所有相关资源。

今天，我们将继续跟随老王的脚步，在他结束一天工作时，体验两种截然不同的“收工”场景：

  1. 主动收工：老王自己通过App点击“结束巡检”，由他的头盔主动向网络发起取消请求（UE-initiated Cancellation, 6.3.2）。
  2. 被动收工：老王忘记了点击结束，人已经到家休息。公司的安全监控中心后台系统检测到异常，决定远程为他结束巡检任务（Network-initiated Cancellation, 6.3.3）。

这两个场景，完美地诠释了延迟定位取消流程的双向性与对称性，让我们一探究竟。

2. 第一幕：我的任务我做主 (6.3.2 UE-Initiated Cancellation)

傍晚时分，老王完成了最后一基电塔的巡检，准备下山回家。他打开手机App，点击了“结束巡检”按钮。这个简单的动作，触发了一次由UE发起的、自下而上的取消流程。

Figure 6.3.2-1 summarizes a procedure to enable a UE to cancel a deferred 5GC-MT-LR procedure for periodic, or triggered location events (e.g. if the UE is powered off or if the UE cancels the location request based on user’s input).

规范开宗明义，点出了UE发起取消的典型场景：用户主动操作（如老王的“结束巡检”），或UE即将断电等。

2.1 核心动作：发出“解约函” (Steps 1 & 2)

“Figure 6.3.2-1: UE Cancellation of a Deferred 5GC-MT-LR…”清晰地展示了这封“解约函”的发出与传递过程。

  1. 建立连接 (Step 1)：如果老王的头盔为了省电已进入CM-IDLE状态，它会首先发起一次服务请求，与网络建立信令连接。

  2. 发送取消请求 (Step 2)：这是最关键的一步。头盔会构建一条Cancel Location请求消息，并将其封装在NAS消息中发送给AMF。

    2. The UE sends a Cancel Location request message to the LMF … The UE includes the deferred routing identifier … and the LDR reference number.

    为了让网络知道要取消的是哪一个“守护契约”，这封“解约函”上必须附上两个至关重要的“凭证”：

    • LDR参考号 (LDR reference number)：这是GMLC在任务建立之初分配的、整个会话唯一的“案件编号”。
    • 延迟路由标识符 (deferred routing identifier)：这是LMF在下发任务时给UE的“专属回邮地址”。

    AMF收到这个请求后，会像一个智能邮差，根据“回邮地址”将这封“解约函”精准地投递给当初负责此事的LMF。

2.2 网络的响应：层层确认，通知客户 (Steps 3-5)

LMF收到取消请求后，便开始逐级通知所有相关方，并最终通知服务的购买者——安全监控中心。

  1. In the case of roaming, the LMF selects a VGMLC. The LMF then invokes an Nlmf_Location_EventNotify service operation towards the selected VGMLC or (H)GMLC with an indication of the cancelation…
  2. The (H)GMLC uses the LDR reference number … and then forwards the cancel location to the external LCS client…
  1. LMF通知GMLC (Step 3)：LMF使用Nlmf_Location_EventNotify服务，向GMLC系统报告：“案件编号为XXX的守护任务，已被用户主动取消”。
  2. GMLC通知LCS客户端 (Step 5)：GMLC根据LDR参考号，找到对应的LCS客户端（安全监控中心），并将取消事件通知给它。监控中心的后台系统收到后，便在屏幕上将老王的状态从“守护中”更新为“已收工”。

2.3 最后的握手：给UE的确认回执 (Step 6)

为了形成一个完美的闭环，网络还需要给UE一个明确的答复。

  1. The LMF returns an acknowledgment to the UE via the serving AMF.

LMF在完成向上游的通知后，会向AMF发送一个确认消息。AMF再将这个**确认（Acknowledgment）**消息通过NAS信令回传给老王的头盔。头盔的App收到后，便可以在界面上弹出一个提示：“巡检任务已成功结束！”

这个确认机制非常重要，它为用户提供了明确的交互反馈，避免了用户不确定任务是否已真正取消的疑虑。

3. 第二幕：你的任务我做主 (6.3.3 Network-Initiated Cancellation)

现在，让我们切换到另一个场景。粗心的老王下班后忘记了点击“结束巡检”，他的头盔依然处于“守护”模式下。晚上9点，安全监控中心的后台系统通过其他方式（例如，打卡记录）得知老王早已安全到家。为了节省头盔电量和网络资源，系统决定远程为他结束守护任务。

Figure 6.3.3-1 summarizes a procedure to enable an AF, an NF or External LCS Client or GMLC to cancel a deferred 5GC-MT-LR procedure…

这是一个自上而下的、由网络侧发起的取消流程。

3.1 核心动作：下达“解约令” (Steps 1-5)

“Figure 6.3.3-1: Cancellation of a Deferred 5GC-MT-LR…”展示了这道“解约令”是如何层层下达到终端的。

  1. 客户端发起取消 (Step 1)：安全监控中心（AF）向GMLC发起一个Cancel Location请求。这个请求中必须包含它想要取消的那个任务的唯一凭证——LDR参考号。

  2. GMLC/AMF/LMF的寻址与转发 (Steps 2-5)：这是一条“找到你，并把命令交给你”的信令链。

    • GMLC → UDM → AMF (Step 2 & 4)：GMLC首先需要知道老王的头盔现在归哪个AMF管。它会像发起一次新的定位一样，向UDM查询UE当前的AMF地址。然后，它向这个AMF发送Namf_Location_CancelLocation服务请求，请求中附带了LDR参考号和LMF的身份信息（如果在建立会话时有记录）。
    • AMF → LMF (Step 5)：AMF根据GMLC的指令，向指定的LMF转发取消请求。LMF收到后，便在自己的会话列表中，终止了与该LDR参考号相关的任务，并释放了内部资源。

3.2 最终执行：将命令送达哨兵 (Steps 6-8)

核心网内部已经完成了“解约”，现在最关键的是要通知“哨兵”本人——老王的头盔。

  1. If the UE is not currently reachable (e.g. is using eDRX or PSM), the AMF waits for the UE to become reachable.
  2. The AMF sends the cancelation request to the target UE… The UE then releases all resources for the location request.

  1. AMF的“耐心等待” (Step 6)：这是一个非常重要的细节。如果老王的头盔正处于深度睡眠（eDRX或PSM）状态，AMF并不会因为联系不上就放弃。它会将这条Cancel指令缓存下来，耐心地等待UE下一次上线（例如，进行周期性TAU）。

  2. 送达“解约令” (Step 8)：一旦UE变得可达，AMF会立刻将Cancel Location的NAS消息发送给头盔。

  3. UE的响应：头盔收到这条指令后，立即停止了所有与该守护任务相关的本地监控活动（如周期计时、地理围栏监测），并清除了相关的上下文信息，释放了本地资源。

3.3 最后的连锁确认：逐级回传“任务完成” (Steps 9-12)

与UE发起的流程一样，网络侧发起的取消也需要一个完整的确认链，以保证命令被成功执行。

  1. The UE returns an acknowledgment to the AMF.
  2. The AMF responds to Namf_Location_CancelLocation, then … (H)GMLC releases all resources…
  3. [Conditional] … the cancelled location event is reported to external client, the NF or the AF (via NEF).
  1. UE → AMF (Step 9)：头盔向AMF返回一个确认Ack。
  2. AMF → GMLC (Step 10)：AMF向GMLC报告“取消成功”。
  3. GMLC → AF (Step 12)：GMLC最终通知安全监控中心“远程取消任务已执行完毕”。

至此，一次由网络侧发起的、完整的延迟定位取消流程宣告结束。

4. 总结：生命周期管理的闭环艺术

6.3.2和6.3.3共同构成了延迟定位服务生命周期管理中不可或缺的“终止”环节。它们的设计充满了对称性和严谨性，确保了这项强大的物联网功能是可控、可靠、可管理的。

  • 双向发起，殊途同归：无论是UE主动取消还是网络被动取消，流程的核心都是通过唯一的会话标识符（LDR参考号和延迟路由标识符），精准地定位并终止一个长期存在的定位会话。
  • 确认机制，保证闭环：两个流程都设计了端到端的确认机制。发起方（无论是UE还是AF）最终都能收到一个明确的“任务已取消”的回执，形成了完美的信令闭环，保证了状态的最终一致性。
  • 对移动性和休眠的鲁棒性：通过deferred routing identifier解决了UE移动带来的AMF变更问题；通过AMF的缓存和等待机制，解决了UE深度睡眠带来的不可达问题。

对于老王和他的“智能安全头盔”而言，这套完善的取消机制意味着他既拥有对自己隐私和设备功耗的自主控制权（主动取消），又能享受到后台系统智能化管理带来的便利（被动取消）。这正是5G定位服务在设计之初，就深入思考并解决的实际应用痛点，也是其能够支撑起未来亿万级物联网设备可靠运行的关键所在。

FAQ - 常见问题解答

Q1：为什么需要两套独立的取消流程（UE发起和网络发起）？ A1：因为取消的“决策权”来源不同。UE发起的取消（6.3.2）赋予了最终用户对自己服务的控制权，是保障用户自主权和隐私的重要体现。网络发起的取消（6.3.3）则赋予了服务提供商（App后台）或网络本身对资源的管理权，用于实现业务逻辑（如任务自动结束）、节省网络资源或执行新的隐私策略。两者方向相反，缺一不可。

Q2：在网络发起的取消流程中，如果UE一直不开机或始终在信号盲区，AMF会一直为它缓存取消指令吗？ A2：AMF的缓存时间是有限的。通常会有一个计时器（其时长由运营商配置）。如果在计时器超时之前UE都没有上线，AMF会放弃本次下发，并向上游（GMLC）报告一个失败，原因可能是“UE不可达”。GMLC可能会选择终止该会话，或者在后续的某个时机再次尝试取消。这是一种容错机制，防止资源被无限期地占用。

Q3：用户在手机上把App卸载了，这会触发延迟定位的取消流程吗？ A3：不会直接触发这里的LCS取消流程。App卸载是操作系统层面的行为，它并不会自动生成一条NAS信令去通知核心网取消LCS会话。这会导致一个“僵尸会话”：网络侧认为任务还在，并可能在UE上线时尝试下发取消指令（如果会话超时的话），而UE侧因为App已不存在，无法再触发任何事件上报。这是一个典型的应用层与网络层状态不一致的问题，通常需要LCS客户端（App后台）通过业务逻辑（如检测到用户长期不活跃）来主动发起网络侧的取消流程（6.3.3）来清理。

Q4：两个取消流程中都反复提到了LDR参考号和延迟路由标识符，能再通俗地解释一下它们的核心区别吗？ A4：当然可以。把一次延迟定位任务想象成一份邮购订单：

  • LDR参考号就是“订单号”。它由商家（GMLC）生成，客户（LCS Client）和商家都用它来指代这份唯一的订单。
  • 延迟路由标识符就是印在商品包装里的“退货专用地址标签”。它由仓库（LMF）提供，并交给了你（UE）。当你需要退货（上报事件或取消）时，你不需要知道仓库的复杂地址，只需把这个标签贴在包裹上，任何邮局（AMF）都能把它准确地寄回正确的仓库。

Q5：如果一个UE同时有好几个延迟定位任务（比如，一个来自安全头盔App，一个来自计步App），取消时会互相影响吗？ A5：不会。每个延迟定位任务在建立时都会被分配一个唯一的LDR参考号。当发起取消请求时，无论是UE还是网络，都必须明确指定要取消的是哪一个LDR参考号对应的任务。这保证了不同应用之间的定位服务是完全隔离、互不干扰的。你可以只取消计步App的后台定位，而保持安全头盔的守护任务继续运行。

关系图谱