深度解析 3GPP TS 23.558：8.8.2B 边云协同ACR (升级版：云端使能的无缝交融)

本文技术原理深度参考了3GPP TS 23.558 V18.10.0 (2025-03) Release 18规范中，关于“8.8.2B Scenarios for ACR between EAS and CAS with CES”的核心章节。在上一篇中，我们探讨了“智行一号”在驶出边缘覆盖区后，如何通过DNS等传统方式“战略撤退”到中心云（CAS）。然而，那更像是一种优雅的“应急预案”。本章，我们将见证一次真正的“军种协同”：当中心云也拥有了自己强大的“使能指挥部”（CES）时，边云切换将如何从一次简单的“回退”，升华为一场真正意义上的、双向无缝的“阵地交融”。

引言：从“应急后方”到“云端指挥部”

在8.8.2A的场景中，“智行一号”在发现前方无边缘可用时，它的AC应用不得不亲自下场，通过DNS查询找到了远在天边的CAS，完成了一次有状态的“撤退”。整个过程中，边缘使能层（EEL）对于CAS的存在几乎是“盲”的，CAS就像一个不使用我方标准电台的“友军”，通信联络基本靠“吼”（DNS）。

这种模式虽然保证了服务的连续性，但终究不够“原生”，不够“智能”。特别是，当“智行一号”从乡村公路再次驶入另一座智慧城市时，如何从CAS平滑地切换回新的EAS？之前的架构并未给出完美的答案。

为了解决这个问题，3GPP引入了一个至关重要的角色——CES (Cloud Enabler Server)。

8.8.2B.1 General Service continuity between CAS and EAS is supported with CES, corresponding to the architecture options described in clause 6.2d. The EES of the source EDN may interact with the CES via ECI-4 reference point and application context is transferred from source EAS to the CAS. Later, if the UE is moving to an area with edge coverage, the CES may interact with the EES in the target EDN via ECI-4 reference point and application context is transferred from the CAS to target EAS.

CES，可以被理解为EES在中心云的“孪生兄弟”。它是一个功能完备的、遵循TS 23.558规范的云端使能服务器。它的出现，彻底改变了游戏规则：

1. CAS不再“孤单”: CAS现在有了自己的“贴身管家”CES，能够深度融入边缘使能层的生态体系。
2. 建立了“外交关系”: EES与CES之间，通过一条标准的“热线”——ECI-4接口——建立了直接的通信。
3. 实现了“双向奔赴”: 整个架构变得对称。不仅支持从边到云（Edge-to-Cloud）的ACR，更原生支持了从云到边（Cloud-to-Edge）的ACR。

“智行一号”的旅程，将不再有“撤退”一说，取而代之的是在边缘指挥部（EES）和云端指挥部（CES）之间的无缝“防务交接”。

---

1. 边到云ACR（Edge to Cloud）：一场有预案的阵地交接 (8.8.2B.2)

本节描述了在拥有CES的情况下，“智行一号”如何从边缘切换到云端。规范的描述非常凝练，它指出这些场景与之前“边到边”的场景基本相同，只是目标发生了变化。我们将深入解读这些“不同之处”。

1.1 核心变化：T-EES的终极替代者——CES

所有8.8.2B.2的子场景（由EEC发起、由S-EES执行等），其核心逻辑都遵循一个简单的替换规则：将之前流程中所有的“T-EES”，替换为“CES”。

这意味着，当ACR流程中的任何一方（EEC, S-EAS, S-EES）在发现目标区域没有可用的T-EAS后，它们不再认为ACR失败，而是将CAS/CES作为理所当然的下一个目标。

1.2 以“EEC经由S-EES执行ACR”为例 (基于8.8.2B.2.3 & 8.8.2A.3)

让我们以“智行一号”的EEC委托S-EES进行切换的场景为例，看看流程发生了哪些质变。

8.8.2B.2.3 EEC executed ACR via S-EES The scenario described in clause 8.8.2A.3 applies with the following differences:

• After step 4, the S-EES relocates context to the CES. The relocation procedure re-uses the procedure described in clause 8.9.2.3 where T-EES is replaced by CES.
• During post-ACR clean up, the CAS triggers ACR status update towards the CES in order to finish ACR.

流程再现：

1. 侦察与决策: “智行一号”的EEC检测到即将驶出边缘覆盖区，并决定发起ACR。
2. 委托发现: EEC向S-EES发起ACR请求，请求其代为发现新目标。
3. 发现失败与转向: S-EES向ECS查询后，发现目标区域没有任何可用的T-EES。（转折点！） 在旧流程中，S-EES会向EEC报告失败。但现在，S-EES知道它还有一个“B计划”——中心云。它随即将CES作为ACR的目标。
4. 档案的“跨级”转移: S-EES不再是联系一个平级的T-EES，而是通过ECI-4接口，向“上级”CES发起一次 EEC Context Push 操作，将“智行一号”的EEC上下文推送到云端。
5. 灵魂的“远程交接”: S-EAS在S-EES的协调下，与中心云的CAS完成应用上下文转移（ACT）。
6. 收尾: 切换完成后，CAS会向它自己的管理者CES汇报ACT状态，完成云端的流程闭环。

通过这个流程，我们可以看到，由于CES的存在，整个边云切换过程被完美地纳入了标准的ACR框架之内，不再需要AC去进行额外的DNS查询。一切都在边缘使能层（EEL）的内部协同下完成，对AC完全透明。

---

2. 云到边ACR（Cloud to Edge）：王者的归来 (8.8.2B.3)

这是8.8.2B章节带来的最大亮点，它填补了之前架构的最后一块拼图。当“智行一号”在乡村公路上依赖CAS行驶了一段距离后，它即将进入下一座智慧城市。一场从云端“回归”边缘的ACR即将上演。

2.1 谁来打响“回归”的第一枪？

8.8.2B.3.1 General The following clauses describe ACR scenarios from cloud to edge.

“回归”的触发者同样可以是客户端或网络侧。

• 客户端EEC触发 (8.8.2B.3.2): “智行一号”的EEC在后台一直保持着“警惕”。它会定期（或在检测到网络位置发生重大变化时）执行服务开通流程，向ECS“打探”当前区域是否有可用的边缘服务。一旦它发现前方有可用的EES，它就会主动发起从CAS到EAS的ACR。
• 网络侧CAS/CES触发 (8.8.2B.3.4, 8.8.2B.3.5): 这是更智能的模式。CES作为云端指挥部，可以向核心网订阅“智行一号”的位置事件。当它发现车辆已进入边缘覆盖区时，它可以主动决策，认为这是一个将计算任务从昂贵的中心云“卸载”回高效的边缘节点的好时机，从而主动发起ACR。

2.2 以“CAS主导的ACR”为例 (基于8.8.2B.3.4)

让我们聚焦于最能体现云端智能的CAS主导场景。

8.8.2B.3.4 CAS decided ACR The scenario described in clause 8.8.2.4 applies with the following differences:

• The CES replaces the S-EES and the CAS replaces the S-EAS.
• The CAS subscribes to CES with ACR management events with “ACR monitoring” for ACR detection and step 3 T-EAS discovery is skipped.

“智行一号”的回归之旅：

1. 云端决策: “智行一号”的AC正与CAS通信。CAS通过调用CES的能力（例如，订阅了UE位置），检测到车辆已经进入了边缘覆盖区，并决定发起“回归”边缘的ACR。
2. 云端寻路: CAS向它的管理者CES发出指令：“为‘智行一号’在它当前的位置，寻找一个合适的V2X边缘服务器！”
3. 跨级联络: CES通过ECI-4接口，向目标区域的T-EES发起一个“Discover T-EAS”请求。
4. 远程交接: 一旦选定了T-EAS，CES便开始协调整个交接流程：
   • 档案下放: CES将“智行一号”的EEC上下文Push给T-EES。
   • 灵魂回归: CAS将应用上下文转移给T-EAS。
   • 通知终端: CES通过网络（或经由T-EES）向“智行一号”的EEC发送目标信息通知，告知新的T-EAS已准备就绪。
5. 切换与收尾: EEC收到指令后，引导AC将连接从CAS切换到T-EAS。T-EAS向T-EES汇报状态，完成收尾。

“智行一号”的AR导航界面上，原本略有延迟的虚拟路标，瞬间变得无比跟手、精准——它知道，自己已经从“远征军总部”成功交接给了“前线精锐部队”。

---

总结：对称之美，边云一体的终极形态

8.8.2B章节通过引入CES和ECI-4接口，将边缘计算的服务连续性版图，从“平面”的边到边，扩展到了“立体”的边云一体。

CES带来的核心价值：

1. 架构的对称性: 云到边和边到云的ACR，遵循着几乎完全镜像的逻辑流程。这使得整个架构在概念上无比优雅，在实现上也大大降低了复杂性。
2. 流程的标准化: 所有的边云交互，都被纳入了标准的ACR框架。无论是上下文的迁移还是状态的通知，都使用统一的信令和接口，彻底告别了8.8.2A中需要应用自己处理DNS等“土办法”的时代。
3. 真正的云原生边缘: CES的引入，使得中心云不再是边缘的“备胎”，而是整个分布式计算体系中一个平等的、功能完备的“超级节点”。这使得应用可以在云和边之间，根据负载、成本、时延等因素，进行动态、智能、双向的调度和迁移。

“智行一号”的旅程至此再无“边界”。无论是穿梭于高楼林立的边缘城市，还是行驶在广袤无垠的数字旷野，它的服务都将在边缘使能层的这只“无形之手”的托举下，如行云流水般，在云和边之间自由流淌。

FAQ

Q1：CES和CAS是什么关系？它们总是需要一起部署吗？ A1：CES是CAS的“使能者”和“管家”。CAS是业务应用本身，而CES是遵循TS 23.558规范，为CAS提供与边缘使能层（EEL）交互能力的标准化组件。在一个理想的“云原生边缘”部署中，它们应该是一起部署的。ASP在将其应用部署到中心云时，不仅部署业务逻辑（CAS），也部署一个CES实例，并将其注册到3GPP的边缘生态中。

Q2：ECI-4接口是EES和CES之间的接口，它和EDGE-9（EES和EES之间的接口）有什么异同？ A2：两者功能高度相似，都是为了在不同的“使能服务器”之间迁移EEC上下文和协调ACR。

• 相同点: 它们都承载着EEC Context Push/Pull和ACR协调等核心信令。
• 不同点: 它们连接的实体不同。EDGE-9是平级的EES之间的接口，用于“边到边”的切换。而ECI-4是跨级的EES与CES之间的接口，用于“边到云”和“云到边”的切换。可以把EDGE-9看作“省内高速”，ECI-4看作连接省会和首都的“国家级干线”。

Q3：在云到边ACR中，如果CES发现了多个可用的EAS，它会如何选择？ A3：CES的选择逻辑与EES类似，它会综合多种因素：

• EAS Profile: 选择最匹配AC需求的EAS。
• 网络KPI: CES可以通过向T-EES查询，或从核心网获取信息，来评估不同EAS的网络路径质量。
• 负载状态: T-EES可以向CES上报其下辖EAS的负载情况，CES会优先选择较为空闲的节点。
• 运营商策略: 可能存在成本或商业合作上的考量，例如，优先切换到某个成本更低的边缘区域。 最终，这是一个基于多维信息的智能决策过程。

Q4：有了CES这么完美的方案，8.8.2A中那种没有CES的“土办法”还有存在的意义吗？ A4：非常有意义。它的存在是为了向后兼容和降低改造成本。世界上存在着海量的、已经部署在中心云的“传统”应用，让它们全部进行改造以支持CES是不现实的。8.8.2A提供了一条“低成本”的路径，让这些传统应用几乎无需改动，就能被纳入到ACR的体系中，享受到“有状态”的边云切换能力。而8.8.2B则是为全新的、“云原生边缘”应用设计的“理想蓝图”。两者并存，体现了标准的务实与前瞻。

Q5：整个ACR流程中，应用上下文（ACT）的转移似乎总是最后几步，这样不会因为数据量大而导致切换延迟吗？ A5：这是ACR流程设计的精妙之处，特别是与“服务连续性规划”结合时。

• 控制面先行: 所有的“文书工作”，如发现、决策、认证、上下文创建等控制面信令，都会提前进行。
• 数据面预热: 在ACT阶段，S-EAS和T-EAS之间可以建立连接，并开始预传输应用上下文。
• 增量同步: 在UE真正到达切换点之前，S-EAS可以持续地将增量的上下文变化同步给T-EAS。
• 最后一跃: 当UE到达切换点，ACR complete通知发出时，可能只需要同步最后几毫秒的数据，甚至T-EAS已经完全就绪。 通过这种“控制面先行，数据面预热+增量同步”的机制，即使应用上下文很大，也能将最终切换时刻的中断时间缩短到毫秒级，实现无感切换。