深度解析 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（应用上下文重定位）流程已经启动。无论是EEC的自主决策，还是网络侧的远程指挥，ACR Launching这一“总攻号角”已经吹响。然而，对于身处驾驶舱的EEC（客户端）来说，此刻它可能正处于“信息黑洞”中——它发出了指令，但并不知道前线战况如何。T-EAS是否已找到？档案（EEC Context）是否已交接？灵魂（Application Context）是否已转移？
如果说“开战三部曲”定义了如何开始一场ACR，那么本章要探讨的后续流程，则定义了如何管理和结束这场ACR。它们是确保整个“换防”过程透明、可控、最终确认的“神经系统”和“汇报机制”。
我们将深入ACR的“战情室”，学习四项关键的战术程序：
- ACR信息订阅：建立“指挥部”（EEC）与“前线”（EES）之间的实时战情通报热线。
- EELManagedACR：一种特殊的“托管模式”，应用方（EAS）将ACR指挥权完全交由边缘使能层（EEL）的专业团队。
- 选定T-EAS声明：当“前线指挥官”（S-EAS）自行选定接防部队时，如何向“总参谋部”（S-EES）进行正式备案。
- ACR状态更新：战斗结束后，各参战方如何向上级汇报战果，完成最终的流程闭环。
1. 战术动作四：ACR Information Subscription (订阅战情通报) (8.8.3.5)
这是为“指挥官”EEC建立“千里眼”和“顺风耳”的关键流程。当ACR由网络侧主导时（如S-EAS或S-EES决定），EEC需要一种机制来被动接收战役的进展。
Figure 8.8.3.5.2-1 illustrates the ACR information subscription procedure between the EEC and the EES.
“智行一号”的场景再现： “智行一号”的EEC非常智能，它希望在S-EES主导ACR时，能实时了解进展。因此，在与S-EES建立连接后，它就预先发起了一次“ACR信息订阅”。
1.1 订阅 (Subscribe - 8.8.3.5.2)
EEC向S-EES发送ACR information subscription request，请求中明确了它关心的“军情”类型：
- Target information notification (目标信息通知): “一旦你们选定了新的T-EAS，请立刻告诉我它是谁、在哪里。”
- ACR complete events (ACR完成事件): “整个换防行动结束后，无论成功还是失败，请给我一个最终的战果报告。”
S-EES收到订阅后，便为“智行一号”建立了一个“战情专线”，并返回一个订阅ID。
1.2 通知 (Notify - 8.8.3.5.3)
现在，当S-EES主导的ACR流程进行到关键节点时，它就会通过这条“战情专线”向EEC发送通知。
-
发送“目标信息通知”: 当S-EES在自己的ACR流程中，成功发现了T-EAS后，它会立刻向EEC发送一个
Target information notification。EEC收到后，虽然还不能切换，但已经可以提前进行一些准备，比如预解析T-EAS的域名。关键点：EEC收到此通知后，会暂时“按兵不动”，避免自己再发起一次重复的ACR。 -
发送“ACR完成通知”: 当S-EES确认所有交接工作（EEC上下文推送、ACT等）都已完成后，它会向EEC发送
ACR complete notification。这条通知是最终的“行动指令”。EEC收到后，才真正引导AC将数据流切换到T-EAS。
这个订阅/通知机制，确保了即使在网络侧主导的ACR中，客户端也始终保持着“知情权”和最终的“执行权”。
2. 特殊战术：EELManagedACR (全权委托作战) (8.8.3.6)
这是一种非常特殊的、高度抽象的ACR模式，专为那些希望将移动性管理“完全外包”给边缘使能层的“懒人”应用（S-EAS）而设计。
This clause introduces a procedure for ACR performed by the Edge Enabler Servers. When S-EES receives a request for EELManagedACR from S-EAS, the S-EES performs the service operations for the service continuity…
核心理念：应用“甩手掌柜”，EEL“一条龙服务”
在EELManagedACR模式下，S-EAS在“智行一号”首次连接时，就向S-EES发起一个EELManagedACR service request，相当于签署了一份“全权委托协议”。
这份协议的核心内容是：“这辆车（‘智行一号’）的移动性，从现在起由你（S-EES）全权负责。我（S-EAS）不再关心侦察、决策、发现等任何细节。我只做一件事：等你的通知。” S-EAS甚至可以提供一个共享存储地址，让S-EES可以直接访问和转移它的应用上下文。
流程的独特之处：
- ACT状态订阅 (ACT status subscription - 8.8.3.6.2.3): 在这个模式下，由于S-EAS是“甩手掌柜”，它不知道T-EAS是谁。因此，当S-EES为S-EAS选定了接班人T-EAS后，T-EAS需要主动向其管理者T-EES订阅“ACT状态通知”。它在等待S-EES将“灵魂”（应用上下文）转移过来。
- ACT状态通知 (ACT status notification - 8.8.3.6.2.4): 当S-EES完成上下文的准备/转移后，T-EES会通知T-EAS：“‘智行一号’的上下文已经准备好，你可以来接管了。”
EELManagedACR是最高级的“托管”服务，它将应用从复杂的移动性管理中彻底解放出来，让开发者可以100%聚焦于业务逻辑。
3. 战术动作五：Selected T-EAS Declaration (向总部备案) (8.8.3.7)
这个流程用于解决一个特定的“权限与信息同步”问题。在S-EAS主导的ACR（8.8.2.4）场景中，是由S-EAS自己发现了T-EAS。但S-EAS只是一个“应用”，它无权直接指挥T-EES进行EEC上下文迁移等操作。
因此，S-EAS在做出选择后，必须向它的管理者S-EES进行一次正式的“备案”。
Figure 8.8.3.7-1 illustrates the interactions between the S-EAS and the S-EES for the selected T-EAS declaration.
流程再现：
- S-EAS发送声明: S-EAS向S-EES发送一个
Selected target EAS declaration request，内容很简单：“报告长官，经过我的侦察，我已选定T-EAS-B作为接替者。” - S-EES确认备案: S-EES收到后，确认了S-EAS的选择。从这一刻起，S-EES才正式接管了ACR的协调执行权，它现在知道了目标是谁，可以开始启动EEC上下文推送、通知EEC等后续步骤。
这个“备案”流程，是S-EAS主导的“决策阶段”和S-EES协调的“执行阶段”之间，一个必不可少的“权力交接”环节。
4. 战术动作六：ACR Status Update (战果汇报) (8.8.3.8)
这是所有ACR流程的最后一步，是确认“灵魂转移”（ACT）是否成功的“官方汇报”。
Figure 8.8.3.8-1 illustrates the procedure for ACR status update, which is triggered by the S-EAS or the T-EAS.
流程再现： 在ACT完成后：
- 旧岗哨汇报: S-EAS向其管理者S-EES发送
ACR status update，报告：“我已经成功将‘智行一号’的应用上下文交接出去。” - 新岗哨汇报: T-EAS向其管理者T-EES发送
ACR status update，报告：“我已成功接收‘智行一号’的应用上下文，随时可以接管服务。”
为什么需要双向汇报？
- S-EES需要知道: S-EES收到S-EAS的成功报告后，它才能放心地向EEC发送
ACR complete通知，并准备清理旧的会话资源。 - T-EES需要知道: T-EES收到T-EAS的成功报告后，它才知道应用层已经就绪。这可能会触发它更新EEC上下文的状态，或者完成对EEC的“隐式注册”（Implicit Registration）。
这个双向的状态更新，确保了**应用层（EAS）和使能层（EES）**在ACR完成后，状态是完全同步的，构成了ACR流程最坚固的“闭环”。
总结：构建ACR的“反馈控制系统”
如果说“开战三部曲”是ACR的“前馈”控制，那么本章介绍的这几个流程，则共同构成了ACR的“反馈控制系统”。它们确保了ACR这个复杂、分布式的流程，始终处于被监控、被管理、被确认的状态下。
- ACR信息订阅，为客户端提供了实时的“战场态势感知”能力。
- EELManagedACR，提供了一种“省心”的托管模式，体现了架构的高度抽象和服务化能力。
- 选定T-EAS声明，解决了S-EAS决策场景下的“权力交接”问题，保证了指挥链的清晰。
- ACR状态更新，构成了最终的“确认闭环”，保证了所有参与方在流程结束时状态一致。
通过这些精密的“战术手册”，3GPP为“智行一号”的每一次“换防”，都提供了从“计划”到“执行”，再到“反馈”的全流程标准化保障。在下一篇文章中，我们将继续探讨8.8.3章中的最后几个“高级战术”，看看如何应对ACR过程中的动态变化，以及如何处理更特殊的ACR场景。
FAQ
Q1：ACR Information Subscription和之前在8.6.3学习的ACR Management Events订阅有什么区别？
A1：订阅的主体和目的完全不同。
ACR Management Events(8.6.3) 的订阅者是EAS，目的是为了检测ACR需求。EAS订阅的是“用户面路径变更”等底层网络事件，用于触发ACR决策。ACR Information Subscription(8.8.3.5) 的订阅者是EEC，目的是为了监控ACR进展。EEC订阅的是“目标信息已确定”、“ACR已完成”等上层流程事件，用于配合网络侧主导的ACR执行。 简而言之，前者是EAS的“情报网”，后者是EEC的“指挥频道”。
Q2：EELManagedACR场景下，S-EAS如何信任S-EES会妥善处理它的应用上下文？
A2：这依赖于多重信任机制：1) 商业协议: ASP（应用提供商）和ECSP（边缘服务提供商）之间会有服务等级协议（SLA），规定了数据的处理方式和安全责任。2) 安全机制: 规范要求S-EES在访问应用上下文时，必须经过严格的认证和授权。S-EAS提供的“共享存储地址”通常会附加一个有时效性的、加密的访问令牌。3) 数据加密: 最重要的是，S-EAS在将应用上下文放入共享存储之前，会由应用自身进行加密。S-EES在“搬运”这个加密数据包时，是无法看到其内容的。只有最终的T-EAS拥有解密的密钥。这保证了端到端的业务数据安全。
Q3：为什么需要一个独立的Selected T-EAS Declaration流程？S-EAS在Discover T-EAS之后，直接告诉S-EES不就行了吗？
A3：Selected T-EAS Declaration正是这个“告诉”动作的标准化体现。将它定义为一个独立的、有名字的流程，有几个好处：1) 明确意图: 它清晰地将“发现”阶段和“决策确认”阶段分开。S-EES收到这个请求，就知道S-EAS已经做出了最终选择，可以启动不可逆的执行流程了。2) 接口清晰: 为这个动作定义了标准的信息元素（IEs），确保了S-EAS和S-EES之间的信息传递不会有歧义。3) 可审计性: 作为一个标准流程，它的每一次调用都可以被记录和审计。
Q4：ACR Status Update中，为什么S-EAS和T-EAS要分别向S-EES和T-EES汇报？为什么不是直接互相通知？ A4：这是为了维持清晰的管理层级和职责边界。在边缘使能层的架构中，EES是EAS的直接“管理者”。
- EAS只负责自己的业务逻辑和ACT的执行，它不应该关心复杂的EES间通信。
- EES则负责处理所有网络层面的协调，包括EES之间的通信（EDGE-9）、与ECS的通信、与核心网的交互等。 让EAS向自己的EES汇报，符合这种分层管理的原则。然后由EES层面再去处理后续的跨域通知和流程同步，使得整个架构更加清晰、解耦。
Q5：如果在ACR Status Update时，T-EAS报告成功，但S-EAS报告失败（比如数据交接后源端清理失败），会发生什么？
A5：这是一个典型的分布式系统异常场景。S-EES作为总协调官，会收到来自S-EAS的失败报告。此时，ACR的整体状态就是失败或部分成功。S-EES在向EEC发送ACR complete通知时，会明确指出ACR失败，并附上失败原因。同时，S-EES会进入一个补偿/回滚逻辑。例如，它可能会通知T-EES“放弃本次切换，请清理已接收的上下文”，或者记录一条告警，等待运维人员手动处理S-EAS上的残留数据。健壮的ACR实现必须包含对这类异常的补偿处理机制。