深度解析 3GPP TS 23.558：8.8.2A 边云协同ACR (当边缘不再，云如何接力？)
本文技术原理深度参考了3GPP TS 23.558 V18.10.0 (2025-03) Release 18规范中，关于“8.8.2A Scenarios for ACR between EAS and CAS”的核心章节。在之前的“集团军”式切换中，我们见证了边缘世界内部高效的协同作战。但再强大的军队也有其作战边界。当“智行一号”驶出所有边缘节点的覆盖范围，进入一片“边缘真空地带”时，服务难道就此终结吗？本文将为您揭晓3GPP设计的终极保障方案——边云协同ACR。
引言：驶向“边缘的尽头”
“智行一号”的“沉浸式AR导航”系统，依赖于边缘计算“集团军”（EAS Bundle）的强大支持，在城市中游刃有余。每一次跨区域移动，都在S-EAS、S-EES、EEC的精密协同下，完成了神不知鬼不觉的无感切换。
然而，旅程总有终点。车载导航显示，“智行一号”即将驶离智慧城市示范区，进入一片广袤的乡村公路。这里的5G信号依然满格，但网络边缘并未部署它所依赖的高算力EAS节点。
这是一个决定性的考验。如果服务连续性方案只考虑了“边到边”（Edge-to-Edge）的切换，那么此刻，“智行一号”的AR导航系统将不可避免地黑屏、崩溃。这对于一个高度依赖持续信息输入的应用来说是致命的。
幸运的是，3GPP的架构师们早已预见到了这一天。他们明白，边缘计算不是要取代中心云，而是要与中心云形成一张高低搭配、远近协同的计算网络。8.8.2A章节，正是为这种“边云协同”的服务连续性，制定了详细的“战略撤退与阵地交接”预案。
它定义了当边缘不再可用时，如何将服务平滑地、有状态地从最后一个边缘节点（S-EAS）“接力”给远在天边的中心云“大后方”——CAS（Cloud Application Server）。这不再是一次简单的连接失败和重连，而是一次有组织的、保持上下文的战略转移。
1. 边云协同ACR的核心思想 (8.8.2A.1 General)
在深入具体流程之前，我们必须理解边云协同ACR的两个核心出发点。
Service continuity between CAS and EAS is supported without CES, corresponding to the architecture options described in clause 6.2c. The ACR can be triggered by a change or expected change in UE location or in case of an overload situation or maintenance aspects in the S-EAS or EDN if no suitable target EAS is found as described in clause 8.8.1.1 depending on the scenario.
-
触发条件：无路可走时的必然选择 边云ACR的根本触发点，是所有“边到边”切换尝试的失败。无论是EEC、S-EAS还是S-EES主导的ACR，当它们在执行T-EAS发现后，返回的结果都是“空”——在目标区域，找不到任何一个能够满足应用需求的EAS。此刻，系统便知道，唯一的选择就是退守中心云。
-
架构前提：简化版的协同 (Without CES) 本节（8.8.2A）所讨论的所有场景，都有一个重要的前提：不依赖CES（Cloud Enabler Server）。CES是EES在云端的“镜像”，一个功能完备的云端使能服务器。在没有CES的场景下，意味着中心云的CAS可能是一个较为“传统”的应用，它没有深度集成到3GPP的边缘使能层体系中。 这使得“边云协同”的难度增加，更多的协调责任落在了客户端EEC和源端S-EES身上。它们需要使用一些“传统”的方法（如DNS）来找到CAS，但同时又要努力遵循ACR的“灵魂”——保持上下文。
To facilitate future ACRs from the CAS back to EAS, the EEC may request and receive an AF-specific UE ID or Edge UE ID from the S-EES as described in clause 8.6.5…
一个深谋遠慮的设计：为“王者归来”做准备 在“撤退”到云端之前，规范还设计了一个巧妙的伏笔。EEC可以在离开最后一个S-EES之前，向它申请一个Edge UE ID。这个ID是具有隐私保护特性的UE标识。EEC会带着这个ID去连接CAS。未来，当“智行一号”再次驶入边缘覆盖区，需要从云切换回边缘时，CAS就可以凭借这个ID，向网络侧发起EAS发现，精准地找到为“智行一号”服务的EES。这为“王者归来”的Cloud-to-Edge ACR埋下了重要的种子。
2. 场景一：EEC主导的“战略撤退” (8.8.2A.2)
这是对8.8.2.2（EEC自主发起ACR）场景的直接扩展，描绘了“智行一号”在发现前方无边缘可用时，如何自主完成向云端的回退。
规范原文中的“Figure 8.8.2A.2-1: Enabling ACR with CAS - Initiation by EEC using regular EAS Discovery”是这次“战略撤退”的行动指南。
2.1 阶段一 & 二：发现“无人区”与决定“撤退”
Phase I: ACR Detection
- Same as step 1 described for figure 8.8.2.2-1. Phase II: ACR Decision
- Same as step 2 described for figure 8.8.2.2-1.
这两个阶段与“边到边”切换完全相同。EEC通过移动性感知或AC的预测，发现需要切换，并做出执行ACR的决策。
2.2 阶段三：失败的“前线侦察”与成功的“后方联络”
这是整个流程最关键的转折点。
Phase III: ACR Execution 3. The EEC performs Service Provisioning … this procedure results in unavailability of T-EESs that are relevant to the supplied applications and the new location of the UE. 4. … the EEC informs the AC of the unavailability of a suitable EDN for the new location of the UE. 5. The AC triggers the UE to perform DNS resolution for the CAS relevant for the AC.
“智行一号”的行动：
- 前线侦察失败 (Step 3): EEC按照标准流程，向ECS发起服务开通请求，试图寻找前方乡村公路区域的T-EES。然而，ECS的返回结果是“空”或“失败”。EEC的所有“边到边”切换尝试，在此宣告失败。
- 向指挥部报告 (Step 4): EEC立刻将这个坏消息通知给上层应用AC：“报告！前方已是边缘无人区，无法找到任何可用的边缘节点！”
- 启动B计划 (Step 5): AC收到消息后，立即启动了它的Fallback（回退）机制。它不再依赖边缘使能层，而是回归到最传统的互联网方式——DNS查询。它向DNS服务器查询其中心云CAS的域名（例如
cas.myautodrive.com），并成功获取到了CAS的IP地址。 - 通知ACR启动 (Step 6, 7): 尽管目标是CAS，但为了“优雅地”断开与S-EAS的连接并转移上下文，EEC依然需要遵循ACR流程。它向S-EES发起ACR启动请求，但这次的目标信息（T-EAS Endpoint）里，填写的正是刚刚通过DNS查到的CAS的地址。
- 上下文转移 (Step 8): S-EAS在接到S-EES的指令后，与远在中心云的CAS之间，完成了**应用上下文（ACT）**的转移。
2.3 阶段四：完成“阵地交接”
Phase IV: Post-ACR Clean up 9. Same as step 9 described for figure 8.8.2.2-1. 10. Same as step 11 described for figure 8.8.2-1.
S-EAS向S-EES汇报ACT状态，S-EES最终向EEC发送“ACR完成通知”。“智行一号”的AC随即断开与S-EAS的连接，与CAS建立新的连接。
体验的变化： 对于驾驶员来说，AR导航服务依然可用，但可能会感觉到一些变化：之前叠加在路面上的实时AR特效，响应速度似乎变慢了一些。这是因为数据往返于中心云，时延从边缘的几毫秒，增加到了几十甚至上百毫秒。但是，服务没有中断，状态没有丢失。这是一次成功的、有管理的“优雅降级”。
3. 其他协同模式：当决策权在网络侧
与“边到边”ACR一样，“边云协同”ACR也支持由网络侧主导的模式。这些场景（8.8.2A.3 - 8.8.2A.6）的逻辑与之前类似，核心区别在于谁最先发现“无路可走”并决定“退守云端”。
3.1 8.8.2A.3 (EEC via S-EES)
- 流程: EEC委托S-EES寻找T-EAS。S-EES执行发现后，发现找不到，于是向EEC报告失败。后续流程与8.8.2A.2相同，由EEC触发AC去进行DNS查询。
- 类比: “前线指挥官”（EEC）命令“参谋长”（S-EES）去找援军，参谋长回报“周边已无友军”，指挥官于是决定呼叫“后方总部”（CAS）。
3.2 8.8.2A.4 (S-EAS decided)
- 流程: S-EAS自己决定需要切换（例如，为了将低优先级任务卸载到成本更低的中心云）。它自己执行DNS查询找到CAS，然后向S-EES发起ACR，目标直指CAS。
- 类比: “业务部门主管”（S-EAS）决定进行战略调整，直接联系了“后方总部”（CAS），并命令“参谋长”（S-EES）协调执行。
3.3 8.8.2A.5 (S-EES decided)
- 流程: S-EES作为“总指挥”，在尝试为某个事件（如UE移动）寻找T-EAS失败后，自主决定退守云端是唯一选择。它随即指令S-EAS启动向CAS的切换。
- 类比: “参谋长”（S-EES）发现所有前线路径都已不通，于是当机立断，直接指挥部队向“后方总部”（CAS）转移。
总结：边云协同，为边缘计算装上“安全阀”
8.8.2A章节所定义的边云协同ACR，是整个服务连续性架构中不可或缺的弹性保障和容错机制。它如同一道“安全阀”，确保了边缘计算服务不会因为边缘覆盖的不连续性而彻底崩溃。
- 保证了服务的普遍性: 它将边缘服务的边界，从“有覆盖”的区域，逻辑上扩展到了“无覆盖”的区域，保证了用户无论身在何处，都能获得持续的服务体验。
- 实现了优雅降级: 它定义的不是粗暴的失败，而是一次有状态、有管理的切换。虽然性能（时延）可能会下降，但功能和数据得以保留，避免了应用重启和用户数据丢失。
- 体现了架构的兼容性: 它巧妙地将3GPP定义的边缘使能层流程，与传统的互联网DNS机制结合起来，展示了对现有“云原生”应用的良好兼容性。
“智行一号”的旅程仍在继续。它在乡村公路上，虽然失去了边缘的超低时延，但它的AR导航依然在工作，持续为它提供着来自云端的智慧。它知道，当它再次驶入下一座智慧城市时，另一场从“云”到“边”的“王者归来”式ACR，将再次上演。这，正是3GPP TS 23.558所构建的，一个真正无处不在、永不掉线的智能应用世界。
FAQ
Q1：在这些“无CES”的场景中，CAS（云应用服务器）需要做什么特殊改造来支持ACR吗？ A1：需要，但改造相对较轻。CAS至少需要支持：1) 接收应用上下文: 它需要提供一个接口（可能是私有的API），让S-EAS能够将应用上下文数据推送给它。2) 加载应用上下文: 它需要在收到数据后，有能力解析这些数据，并恢复“智行一号”的服务状态。相比于需要深度集成CES、支持EDGE-x接口的“云原生边缘应用”，这种改造的侵入性较小，更容易让现有的云应用快速适配边云协同场景。
Q2：为什么发现CAS通常使用DNS，而不是像发现EAS一样通过ECS/EES？ A2：这是由它们不同的服务属性决定的。
- EAS是动态的、本地的：它的最佳选择与UE的实时位置强相关。因此需要一套复杂的、基于位置的发现机制（ECS/EES）来动态匹配。
- CAS是静态的、全局的：它通常部署在大型数据中心，拥有一个全局可达的、固定的入口。对于这种服务，DNS是最成熟、最高效、最通用的全球服务发现机制。 规范的设计正是利用了两种机制各自的优点。
Q3：边云切换（EAS to CAS）与边边切换（EAS to EAS）相比，哪一步的耗时会显著增加？ A3：主要有两个阶段：
- 应用上下文转移（ACT）: 数据的传输距离显著变长，从边缘到边缘（可能几十公里）变成了边缘到中心云（可能几百上千公里）。广域网的带宽和时延都会导致ACT的时间增加。
- 切换后的应用交互: 这是对用户体验影响最大的部分。切换完成后，AC与CAS的每一次交互，都需要经历一个完整的“端到云”的往返时延（RTT），这个时延通常是“端到边”的数倍甚至数十倍。
Q4：如果S-EAS和CAS分属不同的公司，应用上下文的转移如何保证安全和隐私？ A4：这正是应用层需要解决的问题。规范强调ACT是“out of scope”，其中一个原因就是它涉及到应用自身的安全和数据模型。通常，S-EAS和CAS之间会建立一个安全的通道（如VPN或TLS加密的API）。应用上下文数据本身在离开S-EAS之前，应该由应用自身进行加密，只有拥有密钥的CAS才能解密。这保证了即使在传输过程中，中间的网络实体（包括运营商）也无法窥探到用户的业务数据。
Q5：既然可以退守到CAS，那是否意味着边缘节点的覆盖就不那么重要了？ A5：恰恰相反，边云协同的存在，更加凸显了边缘覆盖的价值。CAS是“底线保障”，保证服务“不断”。而EAS是“体验升级”，保证服务“好用”。正是因为有了边缘节点，“智行一号”才能在城市中实现那些对时延极度敏感的高阶自动驾驶功能。边云协同ACR的存在，使得运营商可以根据业务热点和价值，更灵活地、循序渐进地部署边缘节点，而不用担心因为局部覆盖不全而导致整个边缘业务无法落地。它让边缘部署从一个“0和1”的问题，变成了一个“从1到N”的平滑演进过程。