51学通信

深度解析 3GPP TS 23.558：8.8.2.5 S-EES主导的ACR (边缘“塔台”的远程指挥艺术)

18分钟阅读

深度解析 3GPP TS 23.558：8.8.2.5 S-EES主导的ACR (边缘“塔台”的远程指挥艺术)

本文技术原理深度参考了3GPP TS 23.558 V18.10.0 (2025-03) Release 18规范中，关于“8.8.2.5 S-EES executed ACR”的核心章节。这是服务连续性（ACR）系列中最能体现“网络智能”的场景。在之前的篇章中，我们见证了由客户端主导的ACR模式，现在，我们将把指挥权进一步上移，交给那个离网络心脏最近、对网络脉搏感知最敏锐的角色——边缘使能服务器（S-EES）。

引言：当“区域经理”成为“总指挥”

“智行一号”正在高速公路上飞驰。在之前的场景中，发起服务切换（ACR）的“发令枪”要么握在EEC（客户端）自己手中，要么握在S-EAS（应用服务器）手中。S-EES（源端边缘使能服务器）更多时候扮演的是一个忠实的“执行官”或“协调员”，它响应来自客户端或应用的指令。

但让我们思考一个问题：在整个边缘生态中，谁最懂网络？谁能最先、最直接地感知到UE移动性、用户面路径变化等底层网络事件？

答案无疑是S-EES。它作为3GPP核心网眼中的AF（应用功能），可以直接订阅NEF（网络能力开放功能）和PCF（策略控制功能）的事件，是网络信息汇聚到应用层的“第一前哨”。

那么，为何不将ACR的“侦察”和“决策”大权，也赋予这位最强大的“情报官”呢？

8.8.2.5场景正是基于这一思想构建的。它将S-EES从一个“区域经理”提升为了ACR行动的“总指挥”和“空中交通管制塔台”。在这个模式下，S-EES不仅执行ACR，它还主动检测需求、并最终做出决策。来自客户端EEC和应用服务器S-EAS的信号，都变成了向这个“塔台”发出的“请求”或“建议”。这是一场由网络智能驱动的、高度集中的“远程指挥”行动。

1. 战前准备：建立全方位情报网与授权链

要让S-EES成为“总指挥”，必须确保它拥有决策所需的一切情报，并且它的命令能够被各方（特别是客户端EEC）接收。

Pre-condition: 4. The S-EAS optionally subscribed to receive ACR management notifications for “ACR facilitation” events to the S-EES, in order to enable detection at S-EAS. 5. In case of EELManagedACR, the T-EAS has subscribed to receive ACT status notifications as described in clause 8.8.3.6.2.3.

S-EES的权力基础：

  1. 客户端监听就位: “智行一号”的EEC必须已向S-EES订阅了ACR信息通知。这是S-EES的“指挥权”能够触达终端的保证。
  2. （可选）应用方情报输入: S-EAS可以向S-EES订阅“ACR Facilitation”事件。这是一种反向的订阅，意味着S-EAS希望在ACR发生时，由S-EES来“推动”整个流程，并通知自己。
  3. （可选）EELManagedACR: 一种特殊的“全权委托”模式。S-EAS可以在启动时，向S-EES发起一个EELManagedACR请求，相当于说：“从现在起，这辆车（‘智行一号’）的ACR事宜，我全权委托给你了，请你主动侦测并处理，我只等你的行动通知。”

最重要的是，S-EES自身可以直接向3GPP核心网订阅底层网络事件，这是它最重要的情报来源，甚至可以不依赖于EEC和S-EAS。

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

规范原文中的“Figure 8.8.2.5-1: S-EES executed ACR”展示了这场由“塔台”S-EES精心调度的空中交接。

Figure 8.8.2.5-1: S-EES executed ACR

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

我们将看到，EEC和S-EAS的角色被进一步“简化”，而S-EES的职责则变得前所未有的强大和集中。

3. 阶段一 & 二：情报中枢的洞察与决断 (Detection & Decision)

这是S-EES作为“总指挥”智慧的体现。

3.1 阶段一：全知之眼 - S-EES的多元化情报来源 (Step 1, 2)

Phase I: ACR Detection 2. Detection entities (S-EAS, S-EES, EEC) detect that ACR may be required and identify the ACID and Predicted/Expected UE location…

S-EES成为了所有情报的汇聚点：

  • 来自客户端的情报: EEC检测到位置变化，它不再自己决策，而是向S-EES发送一个“ACR determination”请求，相当于“报告班长，我可能需要换防，请指示！”
  • 来自应用的情报: S-EAS基于业务逻辑或负载情况，也向S-EES发送一个“ACR determination”请求，相当于“报告总部，我这里快顶不住了/目标即将转移，请安排换防！”
  • 来自网络核心的情报: 这是本场景最独特之处！S-EES直接从核心网（NEF）收到了一个“用户面路径变更”的事件通知。这个情报来源最快、最底层。S-EES可以不依赖任何人，自己就发现了需要ACR的“战机”。

3.2 阶段二：中央决策 - S-EES的“一锤定音” (Step 3, 4)

Phase II: ACR Decision 3. The detection entity performs ACR launching procedure … with the ACR action indicating ACR determination… 4. The S-EES authorises the message if received. The S-EES decides to execute ACR…

无论情报来自何方，最终的决策权都收归于S-EES。

  1. 请求决策 (Step 3): EEC或S-EAS通过ACR启动流程，向S-EES正式提出“ACR决策请求”。
  2. 批准并执行 (Step 4): S-EES在授权该请求后，综合所有信息，做出最终决策：“批准ACR行动，由我全权指挥！”

从这一刻起，S-EES从一个信息中心，转变为整个ACR行动的唯一主导者。

4. 阶段三：雷霆行动 - “塔台”的精准调度 (ACR Execution)

S-EES现在将像一个空中交通管制塔台，有条不紊地向各个“单位”（EEC, EAS, T-EES, 核心网）下达一系列指令。

4.1 内部协调 (Step 5a, 5b, 6)

5a. The S-EES determines T-EES and T-EAS via the Discover T-EAS procedure… 5b. If required, the S-EES performs ACR parameter information procedure… 6. …S-EES initiates EEC Context Push relocation with the T-EES…

S-EES首先完成所有网络侧的内部准备工作：

  • 发现目标: S-EES亲自执行T-EAS发现流程，联系ECS，找到最合适的T-EES和T-EAS。
  • 参数同步: 如果是预测性切换，S-EES会将预测到达时间等关键ACR参数同步给T-EES。
  • 档案转移: S-EES执行EEC Context Push，将“智行一号”的档案推送给T-EES。

4.2 指挥各方 (Step 7, 8, 9, 10)

内部准备就绪后，S-EES开始向所有相关方下达指令：

  • 指令一：通知客户端 (Step 7 - Target information notification) S-EES向“智行一号”的EEC发送目标信息通知：“已为你选定新的服务器T-EAS-B，地址是…，待命切换！”

  • 指令二：调整网络路由 (Step 8 - Initiate application traffic influence) S-EES可以直接与核心网交互，影响AF流量路由，提前将网络路径导向T-EAS所在的EDN。

  • 指令三：命令源端应用 (Step 9 - ACR management notification) S-EES向S-EAS发送ACR管理通知，事件类型为“ACT start”，命令道：“立即开始向T-EAS-B转移‘智行一号’的应用上下文！”

  • 指令四：应用执行交接 (Step 10 - Application context is transferred) S-EAS遵照指令，与T-EAS完成应用上下文转移（ACT）。

在这场复杂的协同中，S-EES是唯一的发令者，所有其他实体都变成了指令的执行者。

5. 阶段四：收尾与确认 (Post-ACR Clean up)

  1. In case of EELManagedACR, once the ACT is successful, the T-EES sends an ACT status notification to the T-EAS…
  2. The S-EAS sends the ACR status update message to the S-EES…
  3. The T-EAS sends the ACR status update message to the T-EES…
  4. If the status in step 12 indicates a successful ACT …, the S-EES sends the ACR information notification (ACR complete) message immediately to the EEC…
  • 汇报战果: S-EAS和T-EAS分别向S-EES和T-EES汇报ACT的执行结果。
  • 最终通告: S-EES作为总指挥，在确认所有任务成功后，向最初的“利益相关方”——EEC，发送最终的“ACR完成通知”。

“智行一号”收到“换防完毕”的指令，执行最后的连接切换。一场由S-EES全程精准调度的、高效的ACR行动宣告结束。

总结：S-EES主导模型的终极优势

8.8.2.5场景将ACR的控制逻辑最大程度地集中化，放置在了离网络能力最近的S-EES身上。这种“中央集权”式的模型，带来了无可比拟的优势：

  1. 最快响应速度: S-EES能够直接从3GPP核心网获取最底层的移动性事件，无需等待EEC或EAS的“二手情报”。这使得它对网络变化的响应时延最低，特别适合对切换速度要求极为苛刻的业务。
  2. 逻辑最简化: 无论是客户端EEC还是应用端EAS，其关于ACR的逻辑都大大简化。它们只需扮演好“情报员”（上报检测事件）和“士兵”（执行指令）的角色即可，无需进行复杂的决策和跨域协调。
  3. 避免决策冲突: 在前几个场景中，EEC和EAS都可能成为决策者，这在复杂场景下可能引发决策冲突或信令竞争。S-EES主导模式通过设立唯一的决策中心，从根本上杜绝了这种可能性，保证了ACR流程的一致性和确定性。

当然，这也意味着S-EES的实现复杂度最高，对它的可靠性要求也最苛刻。它成为了整个区域ACR服务的中枢，一旦它出现故障，所有由网络侧发起的ACR都将停摆。

至此，我们已经完整学习了三种由不同实体主导的ACR场景：EEC主导、EEC委托S-EES协同、S-EAS主导以及S-EES主导。它们并非相互替代，而是构成了一个灵活的工具箱，让不同的应用可以根据自身的特点——对控制权的需求、对时延的敏感度、自身的智能化程度——来选择最适合自己的服务连续性保障方案。

FAQ

Q1：S-EES主导的ACR (8.8.2.5) 与 EEC委托S-EES执行的ACR (8.8.2.3) 最本质的区别是什么？ A1：最本质的区别在于**决策权（Decision-making）**的归属。

  • 在8.8.2.3中，S-EES是“高级代办”。虽然它执行了繁重的发现和协调任务，但“要不要做”以及“什么时候做”的最终决定权仍然在EEC手中。EEC是流程的发起者和决策者。
  • 在8.8.2.5中，S-EES是“总指挥”。它可以独立于EEC，基于从网络或EAS获取的信息，自主决定发起并执行ACR。EEC和其他实体更多地是作为情报来源和指令执行者。 简单来说，前者是“我（EEC）决定，你（S-EES）来办”，后者是“我（S-EES）决定，你们（EEC, EAS）都配合”。

Q2：什么是EELManagedACR？它和普通的S-EAS触发有什么不同？ A2：EELManagedACR可以理解为S-EAS对S-EES的一种**“全权委托”订阅**。普通的S-EAS触发（如在8.8.2.5的Step 2中）可能是一次性的事件，比如S-EAS检测到一次过载，于是请求S-EES处理一次ACR。而EELManagedACR是一种更长期的关系，S-EAS在启动时就向S-EES发起请求，相当于说：“这台车（‘智行一号’）的ACR以后都归你管了，你看着办，我只负责在接到你的‘ACT start’通知时执行数据转移。” 这种模式下，S-EAS的ACR逻辑可以做到最简化。

Q3：既然S-EES可以直接从核心网获取信息，为什么还需要EEC和S-EAS上报“ACR determination”请求？ A3：因为情报来源是多维度的，网络事件并不等同于业务需求。

  • 核心网事件（如用户面路径变化）只能告诉S-EES“可能”需要切换，但无法告诉它“业务是否允许”切换。
  • EEC的请求代表了用户侧的意图，它可能包含了AC的特定需求，比如“我虽然移动了，但我的应用可以容忍更高时延，暂时不用切换”。
  • S-EAS的请求代表了业务侧的意图，比如“虽然网络稳定，但我这边要维护了，必须切换”。 S-EES作为总指挥，需要综合来自“海陆空”三方的所有情报，才能做出最正确的决策。

Q4：在这个模型下，如果S-EES收到了来自EEC和S-EAS的相互矛盾的ACR请求，它会如何处理？ A4：这正是这个集中式决策模型的优势所在。S-EES作为唯一的仲裁者，可以根据预设的策略来处理冲突。例如，策略可以定义：

  • 优先级: S-EAS因“服务器即将崩溃”发起的请求，优先级高于EEC因“预测到轻微信号抖动”发起的请求。
  • 合并处理: 如果EEC和S-EAS几乎同时因为UE移动而发来请求，S-EES可以将它们合并为一次ACR事件处理，避免重复操作。
  • 否决权: S-EES可以根据自己从核心网获取的更权威的信息，否决掉一个它认为“不合理”或“不必要”的ACR请求。

Q5：到目前为止，我们讨论的都是从S-EAS切换到T-EAS。那从中心云CAS切换到EAS的场景（Cloud-to-Edge ACR）由谁主导呢？ A5：非常好的问题，这引出了ACR的另一个重要维度。从云到边的切换，通常也是由类似于本章的网络侧实体主导。规范在8.8.2B.3章节中对此有详细描述。通常，云端的**CES（Cloud Enabler Server）**会扮演类似于S-EES的角色。当CES发现“智行一号”驶入了边缘覆盖区，它会主动决策，为它发现一个合适的EAS，并协调CAS与EAS之间的上下文转移。这个流程的思想与S-EES主导的ACR高度一致，只是“战场”从“边到边”变成了“云到边”。

关系图谱