深度解析 3GPP TS 23.558：8.8.3 Service Continuity Procedures (Part 2 - ACR的高级战术：参数修改与状态宣告)
本文技术原理深度参考了3GPP TS 23.558 V18.10.0 (2025-03) Release 18规范中，关于“8.8.3 Procedures”中服务连续性核心流程的后半部分。在上一篇“开战三部曲”中，我们学习了ACR行动发起前的侦察、联络与宣战。战斗的号角已经吹响，但一场复杂的“换防战役”不能只有“冲锋”，更需要精密的“战场管理”：如何根据瞬息万变的战况，动态调整作战计划？如何确保各个参战方之间的信息完全同步？如何进行最终的战果确认？
引言：从“打响战斗”到“赢得战争”
“智行一号”的ACR（应用上下文重定位）流程已经启动。无论是通过“战场侦察”（Discover T-EAS）锁定了目标，还是通过“总攻号角”（ACR Launching）下达了行动指令，一场旨在保障服务连续性的精密“换防”已经拉开序幕。
然而，任何基于预测的行动都充满了不确定性。如果说“开战三部曲”定义了如何开始一场ACR，那么本章要探讨的后续流程，则定义了如何管理和结束这场ACR。它们是确保整个“换防”过程能够适应动态变化、信息透明、最终确认的“神经系统”和“汇报机制”。
我们将深入ACR的“战情室”，学习四项至关重要的高级战术程序，看一看“智行一号”的作战参谋们是如何：
- 动态调兵：当“智行一号”因堵车而延迟到达时，如何通知“预备队”（T-EAS）调整等待时间？（
ACR parameter information procedure） - 正式照会：在决定“战略撤退”至中心云时，最后的边缘哨所（EES）如何向“大后方”（CAS）发送一份包含“返回地址”的正式照会？（
Selected EES declaration） - 内部备案：当“前线指挥官”（S-EAS）自行选定接防部队时，如何向“总参谋部”（S-EES）进行正式备案，以统一指挥权？（
Selected T-EAS declaration） - 战果确认：战斗的核心阶段结束后，各参战方如何向上级汇报战果，完成最终的流程闭环？（
ACR status update procedure）
掌握这些“战场管理”的艺术，是理解ACR如何从一个僵硬的流程，蜕变为一个智能、健壮、有弹性的服务保障体系的关键。
1. 战术动作四：ACR Parameter Information Procedure (动态调整作战计划) (8.8.3.9)
这是为“服务连续性规划”（Predicted ACR）量身定做的“动态修正”机制。它解决了“计划赶不上变化”这一永恒的难题。
Figure 8.8.3.9-1 illustrates the procedure for sending ACR parameters from S-EES to the T-EES and T-EAS. The procedure may be used by the S-EES at the beginning of the ACR execution to provide ACR parameters, e.g. prediction expiration time, to the T-EES and T-EAS. The procedure may also be used during an ongoing ACR to update ACR parameters.
“智行一号”的意外旅程： S-EES根据EEC的预测，已经为“智行一号”在10分钟后将到达的B路口，准备好了T-EAS，并通知T-EAS“目标将于10分钟内抵达”。然而，A路口发生了交通事故，“智行一号”被堵在了路上，预计到达时间推迟到了30分钟后。
如果不通知T-EAS，它可能会在10分钟的等待超时后，认为ACR已取消，从而释放掉为“智行一号”预留的宝贵资源。当“智行一号”30分钟后姗姗来迟时，将面临无服务可用的窘境。
“ACR参数信息流程”正是为了避免这种情况而设计的“实时战情更新”通道。
规范原文中的“Figure 8.8.3.9-1: ACR parameter information procedure”描绘了这次“计划变更”的通报过程。
流程再现：
- S-EES发起请求 (Step 1): S-EES在得知预测变化后（可能由EEC上报，或自己通过网络分析得知），向T-EES发送一个
ACR parameter information request。请求的核心内容是更新后的ACR参数，最典型的就是新的Prediction expiration time（预测过期时间）。 - T-EES处理并转发 (Step 2, 3): T-EES收到请求并授权后，它需要将这个重要的变更通知给最终的执行者T-EAS。它通过一个
ACR management notification（“ACT start”事件）将更新后的参数转发给T-EAS。 - T-EAS确认 (Step 4): T-EAS收到更新后的参数后，会进行确认。例如，它会更新内部的上下文超时定时器。它也可能会拒绝，比如新的等待时间过长，超出了它的策略允许范围。T-EAS会将它的“回执”发送给T-EES。
- T-EES最终响应 (Step 5): T-EES将T-EAS的处理结果汇总后，向S-EES返回最终的响应。
核心要点：
- 发起者: 通常是S-EES（作为协调中心）。
- 目标: T-EES和T-EAS。
- 核心目的: 在一个已经启动但尚未完成的预测性ACR流程中，动态更新与时间、位置等预测相关的参数，保证目标端（T-EAS）的准备工作与客户端（UE）的实际状态保持同步。
2. 战术动作五：Selected EES Declaration (边云切换的“正式照会”) (8.8.3.10)
这个流程非常特殊，它专用于**EAS-to-CAS（边到云）的ACR场景，是为未来的Cloud-to-EAS（云到边）**切换埋下的一个至关重要的“伏笔”。
The selected EES declaration request is triggered when an ACR is performed from EAS to CAS. Figure 8.8.3.10-1 illustrates the interactions between the EES and the CAS for the selected EES declaration.
“智行一号”的场景再现： “智行一号”即将驶出边缘覆盖区，ACR流程已经启动，目标是中心云的CAS。EES-C是它在边缘世界联系的最后一个“联络官”。在帮助“智行一号”完成向CAS的交接后，EES-C需要向CAS发送一份“外交照会”。
流程再现 (Figure 8.8.3.10-1)：
- EES发送声明 (Step 1): 在ACR流程中，当EES-C确认切换目标是CAS后，它会向CAS发送一个
Selected EES declaration request。这份“照会”的核心内容是：- 我是谁: EES-C的ID和地址（
Selected EES ID,Selected EES Endpoint）。 - 关于谁的: 这份照会是关于“智行一号”的（
UE ID,ACID）。
- 我是谁: EES-C的ID和地址（
- CAS备案 (Step 2): CAS收到这份声明后，会在自己的记录中添加一条关键信息：“用户‘智行一号’在边缘世界的最后一个联系人是EES-C。”
- CAS响应 (Step 3): CAS向EES-C返回确认响应。
这份“照会”的深远意义何在？——为“王者归来”提供“返回地址” 当“智行一号”在中心云服务下行驶了一段时间，再次接近另一座城市的边缘覆盖区时，CAS如何知道该联系哪个EES来为“智行一号”寻找新的边缘服务呢？它就可以查阅这份“备案”，找到“最后一个联系人”EES-C，或者通过EES-C找到其上级的ECS，从而启动一次精准的Cloud-to-Edge ACR。
没有这份“正式照会”，CAS在未来想把服务切回边缘时，将面临“联络无门”的窘境。
3. 战术动作回顾：状态的宣告与确认
为了形成一个完整的“战场管理”闭环，我们在此快速回顾并巩固一下上一篇文章中介绍的两个与“状态宣告”相关的流程。
3.1 Selected T-EAS Declaration (内部指挥权的交接备案) (8.8.3.7)
- 目的: 在S-EAS主导的ACR中，当S-EAS自行完成了T-EAS的发现和选择后，它必须通过此流程，向其管理者S-EES进行“备案”。
- 意义: 这是一个内部指挥权的交接。S-EAS完成了决策，并将执行协调权正式移交给S-EES。S-EES只有在收到这份“备案”后，才知道目标是谁，才能开始协调EEC Context Push等后续的执行动作。
3.2 ACR Status Update (最终战果的确认) (8.8.3.8)
- 目的: 在ACT（应用上下文转移）完成后，由S-EAS和T-EAS分别向各自的管理者S-EES和T-EES汇报ACT的执行结果（成功或失败）。
- 意义: 这是ACR流程的最终闭环。它是协调者（如S-EES）判断ACR是否成功的核心依据。只有收到了来自“前线”（EAS）的成功报告，“指挥部”（EES）才能放心地向客户端EEC宣布“换防胜利”，并安全地清理战场。
总结：从“执行”到“精细化管控”的升华
8.8.3章后半部分的这些“高级战术”，让我们看到了ACR流程设计的精细与完备。它不再是一个“一冲到底”的简单流程，而是一个具备了动态调整、状态同步、明确闭环能力的智能系统。
- ACR参数信息流程，赋予了预测性ACR适应变化的能力，使其从一个僵硬的“定时炸弹”变成了一个可以远程调时的“智能闹钟”。
- Selected EES/T-EAS声明，通过标准化的“备案”和“照会”机制，确保了在分布式决策的复杂场景下，信息流和指挥权能够清晰、无歧义地传递和交接。
- ACR状态更新，为整个ACR的最终成败提供了权威的、来自应用层的确认，构建了最坚实的反馈闭环。
通过这套完整的“作战技能”和“管理程序”，“智行一号”的每一次服务连续性保障，都从一场充满不确定性的遭遇战，升华为一场计划周密、过程可控、结果可期的精密战术行动。
至此，我们已经学完了8.8.3中定义的所有核心流程（Procedures）。我们知道了ACR的每一个动作“是什么”以及“为什么”。在下一篇文章中，我们将进入规范最细节、最硬核的部分——8.8.4 Information flows，我们将戴上“显微镜”，详细剖析在这些流程中传递的每一个信息元素（IEs），看看这些“作战指令”和“战情报告”的具体内容究竟是什么。
FAQ
Q1：ACR Parameter Information Procedure只能用来更新时间吗？还能更新其他参数吗？
A1：虽然Prediction expiration time是最典型的例子，但这个流程的设计是可扩展的。它可以用来更新任何在ACR启动后可能发生变化的预测性参数。例如，如果EEC最初预测UE会从高速的A出口驶出，但后来导航更新为从B出口驶出，那么这个流程就可以用来更新目标位置信息。S-EES收到后，可能会需要重新执行一次T-EAS发现，为新的目标位置寻找服务器。
Q2：Selected EES Declaration是由“最后一个EES”发给CAS的。如果“智行一号”在切换到云端后，又在没有边缘覆盖的区域行驶了很长时间，这个“最后一个EES”的信息会不会过时了？
A2：确实可能会过时。但这依然是一个非常有价值的“起点”。当CAS决定要将服务切回边缘时，即使EES-C本身已经不再适合服务“智行一号”，但CAS可以：1) 联系EES-C的上级ECS: CAS可以从EES-C的配置信息中推断出其所属的ECS。ECS拥有全局的、最新的EES部署图，CAS向ECS查询，总能找到当前位置最合适的EES。2) 利用联邦关系: EES-C可能与其他区域的EES有联邦关系，CAS可以通过它，找到一个更接近“智行一号”当前位置的联邦伙伴EES。所以，这个“最后的联系人”就像一张旧名片，即使地址变了，上面的公司信息和联系方式依然能帮你找到组织。
Q3：为什么EELManagedACR场景下，T-EAS要去订阅ACT状态，而不是等S-EES直接通知它？
A3：这是因为在EELManagedACR这个“全权委托”模式下，S-EAS（应用）将上下文的访问和管理权都交给了S-EES。S-EES可能不会直接将上下文“推送”给T-EAS，而是将其放置在一个中立的、共享的存储位置，然后通知T-EAS“你的‘外卖’（上下文）已经放在X号柜子里了，请凭令牌自取”。T-EAS订阅ACT status notification，正是在等待这个“取餐通知”。这种通过共享存储解耦的方式，进一步降低了S-EAS和T-EAS之间的直接耦合。
Q4：ACR状态更新（8.8.3.8）这个流程，如果T-EAS向T-EES报告了成功，但EEC最终没有切换过来（比如UE突然掉线了），会发生什么？ A4：T-EAS和T-EES会认为ACR的应用层部分已经就绪，并进入等待状态。但T-EES为这次切换所建立的EEC上下文（无论是新建的还是迁移来的）会有一个超时定时器。如果T-EES在预定时间内没有收到来自EEC的任何通信（如新的注册请求或业务请求），它会认为客户端切换失败，并自动清理为本次ACR创建的所有资源，包括通知T-EAS清理应用上下文。这是一个确保资源不会被无限期占用的“兜底”机制。
Q5：到目前为止，我们学习的所有ACR流程，都假设ACR是成功的。如果ACR的任何一个环节失败了，会怎样？ A5：所有这些流程的响应消息中，都定义了失败响应（Failure response）和原因代码（Cause）。ACR的任何一个环节失败（如发现T-EAS失败、上下文迁移失败、安全验证失败），协调者（如S-EES）都会终止整个流程，并向上游的发起者（如EEC或S-EAS）返回一个明确的失败响应和原因。发起者收到后，就可以根据失败原因决定下一步的行动：是重试、是选择一个备用目标、还是彻底放弃ACR并切换到中心云。健壮的错误处理和反馈机制，是这套复杂分布式流程能够可靠运行的根本保障。