深度解析 3GPP TS 23.558：8.8.2.4 S-EAS主导的ACR (当“云端大脑”开始思考)

本文技术原理深度参考了3GPP TS 23.558 V18.10.0 (2025-03) Release 18规范中，关于“8.8.2.4 S-EAS decided ACR scenario”的核心章节。这是服务连续性（ACR）系列中的又一个关键场景。在前文中，我们看到了由客户端EEC主导的“孤军奋战”和与S-EES协同的“双人舞”。现在，我们将见证一次权力的彻底交接：当决策的大脑从终端转移到云端，由边缘应用服务器（S-EAS）亲自操刀，上演一场运筹帷幄的“远程指挥”。

引言：从“被动响应”到“主动出击”

“智行一号”正在城市的车流中穿梭，它的EEC模块像一个尽职的管家，时刻关注着车辆的位置，并与S-EES默契配合，为可能到来的服务切换做着准备。在前两个场景中，无论是EEC“亲力亲为”还是“智能委托”，ACR的发令枪，始终握在客户端EEC的手中。网络侧的S-EAS和S-EES，更多的是扮演着“被动响应者”和“协调执行者”的角色。

然而，在某些情况下，远在边缘云端的S-EAS，可能比身处车内的EEC拥有更广阔的“战场视野”和更深刻的“业务洞察力”：

• 负载预警: S-EAS感知到自身计算资源已接近饱和，它主动希望将“智行一号”等一部分负载“分流”给邻近的空闲服务器。
• 维护计划: S-EAS即将在5分钟后进行一次计划内的软件升级，它需要主动、平滑地将所有在线车辆迁移出去。
• 业务逻辑驱动: “智行一号”正在参与一个车队编队行驶任务，作为“主脑”的S-EAS根据整个车队的整体路线预测，判断需要为整个车队进行一次“集体换防”。

在这些场景下，等待客户端发起ACR显然是不够的。边缘应用的大脑——S-EAS——必须具备“主动出击”的能力。8.8.2.4场景，正是为这种由网络侧应用服务器主导的ACR模式，提供了标准化的行动指南。

---

1. 战前准备：建立情报网络

要让S-EAS能够“运筹帷幄”，前提是它必须能够“耳听八方”。因此，本场景的前置条件，核心就是为S-EAS建立一个强大的情报网络。

Pre-conditions:

1. The S-EAS may depend on the receipt ACR management events from the S-EES, e.g. “user plane path change” events or “ACR monitoring” events as described in clause 8.6.3, to detect the need for an ACR…
2. The EEC has subscribed to receive ACR information notifications for target information notification events and ACR complete events from the S-EES, as described in clause 8.8.3.5.2.

“智行一号”的V2X服务器S-EAS所做的准备：

1. 订阅网络情报: S-EAS不再仅仅是一个服务者，它更是一个情报的“订阅者”。它会向它的管理者S-EES订阅我们之前在8.6.3节学到的ACR管理事件。这意味着，只要网络侧感知到任何与“智行一号”移动性相关的风吹草动（如用户面路径变更），S-EES就会立刻将情报通报给S-EAS。
2. 客户端保持监听: 虽然决策权上移，但客户端EEC并非完全“掉线”。它必须预先向S-EES订阅ACR信息通知，确保自己能够接收到来自网络侧的最终“行动指令”和“战果通报”。

这个准备阶段，构建了一个S-EAS→S-EES→核心网的情报上行链路，以及S-EES→EEC的情报下行链路，是整个S-EAS主导模式得以运转的基础。

---

2. ACR行动四个阶段：拆解Figure 8.8.2.4-1

规范原文中的“Figure 8.8.2.4-1: S-EAS decided ACR”为我们描绘了这场由“云端大脑”指挥的作战行动。

(NOTE: This is a placeholder for the explanation of Figure 8.8.2.4-1)

我们将看到，虽然流程框架依旧，但每一步的“主角”都发生了耐人寻味的变化。

---

3. 阶段一 & 二：网络侧的“先知”与“统帅” (Detection & Decision)

发令枪正式从客户端转移到了网络侧。

3.1 阶段一：S-EAS的“未卜先知” (Step 1: Detection)

Phase I: ACR Detection

1. The S-EAS either receives ACR management notifications from source Edge Enabler Sever indicating that ACR may be required (“ACR monitoring” event), or self detects the need for ACR (e.g. upon receipt of a “user plane path change” event or UE location notification).

S-EAS的情报来源：

• 外部情报 (Receives notifications): S-EES向S-EAS通报：“‘智行一号’的用户面路径已变更，根据我的分析，它已进入T-EAS-B的潜在服务区。”
• 内部洞察 (Self detects): S-EAS通过分析自身的业务数据，做出判断。例如：“我的CPU使用率已经连续5分钟超过90%，必须进行负载迁移。” 或者 “根据‘智行一号’导航目的地，它将在2分钟后离开我的服务范围。”

3.2 阶段二：S-EAS的“果断决策” (Step 2: Decision)

Phase II: ACR Decision 2. The S-EAS makes the decision to perform the ACR.

基于收集到的情报，S-EAS作为“战区总司令”，正式下达了“执行ACR”的命令。它决定了是否切换以及何时切换。这个决策过程完全在网络侧内部完成，此时的“智行一号”对此毫不知情，仍在安稳地与S-EAS通信。

---

4. 阶段三：一场高效的“内部协同战” (ACR Execution)

决策一旦做出，一场主要在网络实体之间进行的、高效的内部协同作战便拉开帷幕。

4.1 发现新大陆：由S-EAS驱动的T-EAS发现 (Step 3: T-EAS Discovery)

3. The S-EAS discovers the T-EAS as described in clause 8.8.3.2.

与8.8.2.3类似，发现任务不再由EEC承担。但这里的发起者，从S-EES更进了一步，变成了S-EAS。 S-EAS会向其管理者S-EES发起一个“Discover T-EAS”请求，请求中包含了它对目标T-EAS的所有期望（如目标位置、服务能力等）。S-EES接到“老板”的指令后，再去执行具体的发现流程（如查询ECS）。

4.2 昭告天下：向S-EES“备案” (Step 4: Selected T-EAS declaration)

4. The S-EAS sends selected T-EAS declaration message to S-EES, to inform S-EES the determined T-EAS to use…

在选定了目标T-EAS后，S-EAS会向S-EES发送一个“选定T-EAS声明”。这一步至关重要，它相当于S-EAS在告诉它的“总协调官”S-EES：“我已经选好了接班人，就是T-EAS-B。接下来，请你来协调后续所有的交接事宜。” 这一步正式将ACR的执行协调权，从S-EAS交还给了S-EES。

4.3 下达指令：S-EES通知EEC (Step 5, 6, 7)

从这里开始，S-EES接管了流程的主导权，开始执行一系列的“交接”和“通知”任务。

5. If the T-EES is different than the S-EES …, the S-EES initiates EEC Context Push relocation with the T-EES…
6. Based on the T-EAS selection information received from the S-EAS, the S-EES sends the target information notification to the EEC…
7. The S-EAS transfers the application context to the T-EAS selected in step 3.

• Step 5 (EEC Context Push): S-EES负责将“智行一号”的EEC上下文从S-EES推送到T-EES。这是“档案”的交接。
• Step 6 (Target information notification): 这是本场景中，客户端第一次“收到风声”。S-EES向“智行一号”的EEC发送“目标信息通知”。通知的内容是：“我们已经为你安排好了新的服务器T-EAS-B，它的地址是…，请做好切换准备。” 此时，EEC从一个“不知情者”变成了“待命的执行者”。
• Step 7 (Application Context Transfer): 与此同时或稍后，S-EAS与T-EAS之间完成应用上下文的转移。这是“灵魂”的交接。

可以看到，整个执行阶段，EEC的角色变得极为被动。它不再需要发起任何请求，只是安静地等待着来自S-EES的“命令”。

---

5. 阶段四：收官 (Post-ACR Clean up)

8. The S-EAS sends the ACR status update message to the S-EES…
9. The T-EAS sends the ACR status update message to the T-EES…
10. ACR complete notify

收尾工作与之前的场景类似，核心是状态的确认与同步。

• Step 8 & 9 (Status update): S-EAS和T-EAS分别向自己的EES汇报ACT的结果。
• Step 10 (ACR complete notify): S-EES在确认所有步骤成功后，向EEC发送最终的“ACR完成通知”。

EEC收到这条消息后，便知道可以正式执行网络连接的切换了。

---

总结：S-EAS主导模型的价值与意义

8.8.2.4场景的引入，是边缘计算架构从“客户端智能”向“网络智能”演进的关键一步。它带来的价值是巨大的：

1. 全局优化与主动管理: 网络侧（特别是与业务紧密结合的EAS）能够基于更宏观的视角（如全网负载、运维计划）来主动发起和优化资源调度，而不仅仅是被动地响应客户端的请求。这使得运营商能够对边缘资源进行更精细化的管理。
2. 客户端极致轻量化: 在这个模型下，EEC的逻辑被简化到了极致。它甚至可以不需要具备复杂的移动性预测和决策能力，只需扮演一个“听令者”的角色，接收并执行来自网络的指令。这对于资源极其受限的IoT设备、或希望将控制逻辑集中在云端的应用来说，是绝佳的选择。
3. 业务驱动的连续性: 切换的决策依据，不再仅仅是物理的位置，而可以是更上层的业务逻辑。这使得服务连续性与应用的实际需求结合得更紧密，例如，在游戏的不同关卡之间、视频的不同码率之间进行“无感”的服务器切换。

当然，这种模式也意味着客户端让渡了大部分控制权。对于像“智行一号”这样需要对自身行为有绝对掌控的复杂终端，它可能会更倾向于采用前两种EEC主导的模式。但对于海量的、更简单的边缘设备，S-EAS主导模式无疑指明了一条通往更智能、更易于管理的未来之路。

FAQ

Q1：S-EAS主导的ACR和S-EES主导的ACR（将在后续章节讲解）有什么区别？ A1：两者都是网络侧主导，但“大脑”的位置不同。

• S-EAS主导 (8.8.2.4): 决策的大脑在应用服务器。触发条件更多与业务相关（如应用负载、业务逻辑）。S-EAS是“司令”，S-EES是“参谋长”，负责执行司令的决策。
• S-EES主导 (8.8.2.5): 决策的大脑在边缘使能服务器。触发条件更多与网络相关（如S-EES从核心网收到的底层事件）。S-EES自己既是“司令”也是“参谋长”。 S-EAS主导模式将决策权交给了最懂业务的人，而S-EES主导模式将决策权交给了最懂网络的人。

Q2：在Step 6，S-EES通知EEC准备切换。如果此时“智行一号”的AC正忙于一次紧急避障，不希望被切换打扰，它能拒绝吗？ A2：规范本身没有为EEC定义一个明确的“拒绝”信令。然而，AC和EEC作为客户端的智能体，可以有一定的自主处理能力。一种可能的实现是：

1. EEC收到通知后，先不立即执行切换，而是先通知AC。
2. AC根据自身状态，可以告诉EEC“请稍等3秒”。
3. 在AC完成紧急任务后，再通知EEC“现在可以切换了”。 虽然信令流程是网络主导的，但最终的连接切换动作仍然在UE侧执行，这为客户端保留了一定的缓冲和自主决策空间。

Q3：S-EAS是如何知道“智行一号”的EEC已经向S-EES订阅了ACR通知的（Pre-condition 2）？ A3：这是一个信息协同的过程。当EEC向S-EES订阅ACR通知时，S-EES在建立这个订阅关系的同时，可以将这个“订阅状态”作为EEC上下文的一部分，并以某种方式（例如，通过EES的能力开放API）让服务于该EEC的S-EAS知晓。这样，S-EAS在决定发起ACR之前，就可以确认“通信线路是畅通的”，它知道自己后续的决策是能够被有效传达给客户端的。

Q4：如果S-EAS在Step 3发现T-EAS失败了，会发生什么？ A4：如果S-EAS向S-EES发起的T-EAS发现请求，最终没有返回任何可用的T-EAS，那么S-EAS的决策就是“ACR无法执行”。整个流程会在Step 3就提前终止。S-EAS可以决定是继续在当前过载的情况下服务，还是启动备用方案，比如将“智行一号”切换到中心云的CAS。无论如何，后续的步骤都不会被执行。

Q5：这个场景对于“服务连续性规划”的支持如何？ A5：这个场景与服务连续性规划的结合堪称完美。因为决策的大脑S-EAS本身就可以是预测的源头。例如，S-EAS通过分析“智行一号”上传的导航目的地，可以提前几分钟甚至几十分钟就预测到未来的切换需求。然后，它可以不慌不忙地启动整个ACR流程（T-EAS发现、上下文预部署和同步）。所有的准备工作都在后台悄无声息地完成。当“智行一号”真正到达切换点时，只需执行最后一步网络连接切换即可，真正实现了“运筹帷幄之中，决胜千里之外”的无感体验。