51学通信

深度解析 3GPP TS 23.558：8.8.2.7-9 ACR for EAS bundle (复杂应用的“集团军”式无感切换)

17分钟阅读

深度解析 3GPP TS 23.558：8.8.2.7-9 ACR for EAS bundle (复杂应用的“集团军”式无感切换)

本文技术原理深度参考了3GPP TS 23.558 V18.10.0 (2025-03) Release 18规范中，关于“8.8.2.7”至“8.8.2.9”中关于EAS捆绑包（EAS bundle）服务连续性的核心章节。在前几篇文章中，我们已经深入探讨了单个应用（EAS）在移动过程中的多种ACR切换模式。然而，现代的复杂边缘应用，早已不是“单兵作战”的时代。本文将带领大家进入一个更宏大、更真实的战场：当“智行一号”依赖的不再是单个服务，而是一个由多个微服务组成的“特种部队”时，我们如何指挥这支“集团军”完成一次整体的、无感知的战略转移？

引言：从“单兵突进”到“集团军协同”

“智行一号”的自动驾驶能力再次升级。它现在搭载了一套“沉浸式AR导航”系统。这套系统不仅仅是简单的路线指引，它能在前挡风玻璃上，通过增强现实技术，实时地将导航指令、危险预警、兴趣点信息，完美地叠加到真实的道路环境中。

然而，实现如此炫酷的功能，背后并非单个“超级英雄”式的EAS，而是一个各司其职、紧密协作的EAS微服务“集团军”，我们称之为EAS捆绑包（EAS bundle）：

  • EAS-Map: 负责提供厘米级的高精动态地图。
  • EAS-Render: 负责处理海量的AR渲染计算，将虚拟信息叠加到摄像头捕捉的实时视频流上。
  • EAS-V2X: 负责与周边车辆和设施进行V2X通信，获取超视距信息。

这三者缺一不可。“智行一号”的AC（应用客户端）需要同时与它们保持连接。现在，当“智行一号”高速驶向下一个边缘节点时，一个前所未有的挑战出现了：如何确保这支“集团军”能够作为一个整体，同步地、无缝地完成“换防”？如果EAS-Map切换成功了，但EAS-Render却掉队了，整个AR导航系统就会瞬间崩溃。

为此，3GPP在8.8.2.7至8.8.2.9章节中，将我们之前学到的ACR模型进行了“升维”，专门定义了针对EAS bundle的协同切换流程。

1. 捆绑包的核心：Main EAS 与 Affinity (参考 8.8.1.6)

在深入流程之前，我们必须先理解“集团军”的两个核心概念。

a main EAS may be used and a main EES is used correspondingly. The main EAS or EES is responsible for ACR detection and initiation in the network side.

  • 主EAS (Main EAS): 这是“集团军”的司令官。在一个EAS bundle中，通常会指定一个EAS作为“主EAS”。在由网络侧发起的ACR场景中，由它来统一负责整个bundle的ACR决策和发起。
  • 主EES (Main EES): 这是“集团军”的总参谋部。通常是主EAS所注册的那个EES。它负责协调整个bundle的跨区域发现和上下文迁移。

NOTE 1: ASP can have requirement of the dependencies between bundled EAS(s) … and indicate whether the affinity between them as strong (co-deployment is essential) or weak (co-deployment is only “nice to have”).

  • 亲和性 (Affinity): 这是“集团军”的部署法则。应用提供商（ASP）在定义bundle时，可以声明其“亲和性”：
    • 强亲和性 (strong): 要求bundle内的所有EAS必须部署在同一个边缘数据网络（EDN）中。这是最高要求，保证了它们之间的内部通信时延最低。
    • 偏好亲和性 (preferred): 最好部署在同一个EDN中，但如果条件不允许，也可以接受部署在不同的EDN。
    • 弱亲和性 (weak): 对是否在同一个EDN中没有要求。

这个“亲和性”要求，是后续ACR中T-EAS发现流程必须遵守的核心约束。

2. 场景一：EEC主导的“集团军”换防 (8.8.2.7 ACR for direct EAS bundle, executed by EEC)

这是对8.8.2.3场景的扩展。“智行一号”的EEC依然是“最高指挥官”，但它现在指挥的是整个“集团军”。

In this scenario, the EEC executes necessary ACR for AC-EAS service session(s) in a bundle, and it follows the scenario described in clause 8.8.2.3 with the following differences:

  • all T-EAS(s) in a bundle requiring service continuity are discovered and selected during step 3. If the affinity is set to strong, then T-EASs are from the same EDN.
  • all bundled T-EAS endpoints are sent to the corresponding S-EES(s) in the ACR request…

核心区别与流程再现：

  1. 侦察与决策: 与单EAS场景一样，由EEC检测到移动性需求并做出ACR决策。
  2. 委托发现: EEC向S-EES发起发现请求。关键不同在于，这次请求的目标不再是单个EAS，而是整个bundle（通过Bundle ID或EASID列表来标识）。S-EES（及其背后的ECS）在寻找目标时，必须遵守bundle的亲和性约束，找到一个能够同时满足所有EAS部署要求的目标位置。
  3. 发起总攻: EEC在获取到所有T-EAS的信息后，向S-EES（们）发起ACR启动请求。关键不同在于，请求中包含了所有T-EAS的端点信息。
  4. 集体交接: S-EES（们）协调所有S-EAS与对应的T-EAS进行应用上下文转移（ACT）。
  5. 集体确认: 只有当所有EAS的切换都完成后，S-EES（们）才会向EEC发送最终的“ACR complete”通知。

在这个场景中，EEC的“指挥”负担加重了，它需要管理整个“集团军”的目标信息。

3. 场景二：S-EAS主导的“集团军”换防 (8.8.2.8 ACR for EAS bundle, executed by S-EAS)

这是对8.8.2.4场景的扩展。“集团军司令官”——主EAS（Main EAS）——亲自下达了战略转移的命令。

In this scenario, the main S-EAS executes and triggers necessary ACR for all AC-EAS service session(s) in a bundle. This scenario description is same as described for figure 8.8.2.4-1 except for the following clarifications…

核心区别与流程再现：

  1. 司令决策: 主S-EAS（例如，AR导航的渲染服务器EAS-Render）通过业务逻辑或从其主S-EES获取的情报，检测到需要为整个bundle进行ACR，并做出决策。
  2. 参谋寻路: 主S-EAS向主S-EES发起对整个bundle的T-EAS发现请求。主S-EES负责找到一个能容纳整个“集团军”的新阵地。
  3. 内部通报: 主S-EES将选定的T-EAS信息通知给所有关联的S-EES（因为bundle中的不同EAS可能由不同的EES管理）。
  4. 集体行动: 各个S-EES分别协调自己旗下的S-EAS，与对应的T-EAS进行ACT。
  5. 逐级汇报: 各个S-EES将执行结果汇总到主S-EES，再由主S-EES统一向EEC发送“ACR complete”通知。

在这个场景中，ACR的复杂性被很好地封装在了网络侧。EEC无需关心bundle的内部构成，它只需听从“总参谋部”（主S-EES）的最终指令。

4. 场景三：S-EES主导的“集团军”换防 (8.8.2.9 ACR for EAS bundle, executed by S-EES)

这是对8.8.2.5场景的扩展，是网络智能的极致体现。“总参谋部”——主S-EES——成为了整个行动的最高统帅。

In this scenario, a main S-EES (serving a main S-EAS) executes and triggers necessary ACR for AC-EAS service session(s) in a bundle.

核心区别与流程再现：

  1. 统帅洞察: 主S-EES直接从核心网获取情报，或综合来自EEC、主S-EAS的信息，自主决策为整个bundle发起ACR。
  2. 统筹规划: 主S-EES亲自执行T-EAS发现，为整个bundle寻找新阵地。
  3. 统一指挥: 主S-EES向所有关联的S-EES、S-EAS以及EEC下达一系列的指令：
    • 通知关联S-EES准备上下文推送。
    • 通知S-EAS们准备ACT。
    • 通知EEC新目标的信息，待命切换。
  4. 统一收官: 主S-EES收集所有执行单位的战果报告，并向EEC发出最终的“ACR完成”通知。

这个模式将ACR的指挥权高度集中在主S-EES，实现了最高效、最协同的“集团军”式作战。客户端和应用端的逻辑都达到了最简化。

总结：从“单点”到“体系”，ACR架构的扩展性

8.8.2.7至8.8.2.9这三个场景，完美地展示了3GPP边缘应用架构的可扩展性和系统性。它们并非重新发明轮子，而是在单个EAS的ACR流程基础上，通过引入“主实体（Main Entity）”和“协同通信”的概念，优雅地将ACR能力从“单点”扩展到了“体系”。

ACR 模式 (Bundle)侦察/决策 主导方T-EAS发现 协调方核心优势“集团军”作战类比
EEC主导 (8.8.2.7)EECS-EES (受EEC委托)客户端控制力最强，能自主决策集团军司令（EEC）亲自制定计划，并命令各军种（EESs）协同执行。
S-EAS主导 (8.8.2.8)主S-EAS主S-EES业务驱动，决策与应用逻辑结合最紧密陆军司令（主S-EAS）根据战况决定转移，由联合参谋部（主S-EES）协调海空军。
S-EES主导 (8.8.2.9)主S-EES主S-EES网络感知最快，响应时延最低，协同效率最高联合参谋部（主S-EES）通过卫星情报发现战机，直接指挥陆海空三军进行战略部署。

对于“智行一号”的“沉浸式AR导航”这类复杂应用，服务连续性不再是一个单点问题，而是一个系统工程。TS 23.558提供的这套“集团军”协同作战方案，确保了无论战况如何变化，这支由多个微服务组成的“特种部队”，都能够作为一个有机的整体，实现无缝的战略机动，为“智行一号”提供永不间断的、沉浸式的驾驶体验。

FAQ

Q1：EAS Bundle中的“Main EAS”是如何确定的？ A1：Main EAS通常由**应用服务提供商（ASP）**在定义和部署EAS bundle时指定。ASP会根据应用的内在逻辑来选择。例如，在一个C/S架构的代理模式（Proxy Bundle）中，那个直接与AC交互的EAS，很自然地就成为了Main EAS。在“沉浸式AR导航”的例子中，ASP可能会将负责核心逻辑和渲染的EAS-Render指定为主EAS。这个信息会在EAS向EES注册时，在其EAS Profile中进行声明。

Q2：如果一个Bundle的亲和性（Affinity）是“strong”，但在目标区域找不到一个能同时容纳所有EAS的EDN，会发生什么？ A2：ACR将会失败。亲和性是一个硬性约束。如果定义为“strong”，那么在T-EAS发现阶段，S-EES/ECS在搜索时，必须找到一个能满足“共同部署”条件的EDN。如果找不到，发现流程就会返回失败或空结果。相应的，整个ACR流程也会提前终止，并向发起方（如EEC或S-EAS）报告失败，原因可能是“No suitable target found”（未找到合适的目标）。

Q3：在一个Bundle ACR中，所有S-EAS到T-EAS的应用上下文转移（ACT）是并行发生的吗？ A3：是的，规范的设计意图是让它们并行发生以缩短总的切换时间。在网络侧主导的场景中（S-EAS或S-EES主导），主实体在协调ACT时，会向所有相关的S-EAS（或通过它们的S-EES）同时下达“ACT start”的指令。然后，它会等待所有并行的ACT都完成，并收到各自的“成功”状态更新后，才会进行下一步。

Q4：为什么需要区分“Main EES”和“associated S-EESs”（关联S-EES）？一个Bundle里的EAS不能都注册到同一个EES吗？ A4：在理想的简单部署下，一个bundle的所有EAS可以注册到同一个EES。但规范考虑了更复杂的、大规模的部署场景：

  • 资源分散: 运营商可能将不同类型的边缘资源（如GPU密集型、存储密集型）划分给不同的EES集群来管理。一个复杂的bundle可能需要跨集群部署。
  • 第三方服务集成: bundle中的某个EAS（例如，一个地图服务）可能是由第三方合作伙伴提供的，它会注册到属于该合作伙伴的EES上。 在这种情况下，主EES就需要扮演“跨部门总协调”的角色，与这些管理着其他bundle成员的“关联EES”进行通信，共同完成ACR。

Q5：这些Bundle ACR流程，是不是意味着单个EAS的ACR场景就不再重要了？ A5：完全不是。单个EAS的ACR场景是基础和默认。Bundle ACR是建立在其之上的“高级功能”。对于大量简单的、只依赖单个EAS的边缘应用来说，8.8.2.2到8.8.2.6中定义的流程已经完全足够。Bundle ACR流程的价值在于，它证明了这套ACR架构具有强大的扩展性，能够平滑地从支持简单应用，演进到支持未来日益复杂的、基于微服务架构的边缘原生应用。

关系图谱