好的，我们继续解读TR 21.918的后续章节。
深度解析 3GPP TR 21.918：18.1 Edge Computing Phase 2 (边缘计算第二阶段) & 18.2 Architecture for enabling Edge Applications Phase 2 (使能边缘应用架构第二阶段)
本文技术原理深度参考了3GPP TR 21.918 V18.0.0 (2025-03) Release 18规范中，关于“18.1 Edge Computing Phase 2”和“18.2 Architecture for enabling Edge Applications Phase 2”的核心章节。本文将合并解读这两个高度相关的章节，旨在为读者深入剖析5G-Advanced如何从基础的“连接”到边缘，演进为精细化的“管理”和“协同”边缘，为构建一个开放、互通、高效的边缘计算生态系统奠定基础。
边缘计算（Edge Computing），通过将计算和存储能力从遥远的中心云，下沉到离用户更近的网络边缘，已成为引爆AR/VR、云游戏、工业自动化、车联网等低时延应用的关键引擎。3GPP在Rel-15/16中，通过定义UPF（用户面功能）的灵活部署和流量疏导（UL CL/LADN），为边缘计算提供了基础的“网络连接”能力。
然而，一个真正繁荣的边缘计算生态，远不止“连接”那么简单。它需要解决一系列更深层次的问题：
- 漫游与联邦: 当用户漫游到另一个运营商的网络时，他能否继续使用归属网络运营商提供的边缘应用服务？不同的运营商之间，能否共享边缘节点资源，形成一个“边缘联邦”？
- 服务的连续性: 当用户从一个边缘节点的覆盖区，移动到另一个边缘节点的覆盖区，甚至移动到没有边缘覆盖的中心云区域时，他的应用会话能否无缝迁移，不掉线、不卡顿？
- 动态发现与实例化: 应用能否根据用户的实时位置和网络状态，动态地在离他最近的边缘节点上，“一键拉起”一个应用实例？
为了应对这些挑战，3GPP在Release 18中启动了“边缘计算第二阶段”（EDGE_Ph2/EDGEAPP_Ph2）的演进。18.1章节主要从**核心网（SA2）和安全（SA3）的视角，定义了系统级的增强，而18.2章节则从应用层（SA6）**的视角，定义了使能这些高级功能的应用架构。
今天，我们的主角，是一位领先的云游戏平台CTO，孙博士。他正在规划其平台的下一代架构，目标是让玩家无论身处全球何地、使用哪个运营商的网络，都能获得一致的、低时延的云游戏体验。让我们跟随孙博士的探索，看看5G-Advanced是如何为他构建这个“全球边缘一张网”的梦想，提供标准化解决方案的。
1. 突破边界：漫游与联邦的支持 (解读 18.1 & 18.2)
孙博士的第一个挑战，就是漫游。他的一位VIP玩家，从中国（归属运营商HPLMN）漫游到了欧洲（拜访运营商VPLMN）。在传统漫游模式（如Home Routed）下，这位玩家的游戏数据流需要先绕回中国的UPF，再访问位于欧洲的游戏服务器，延迟高得无法接受。
1) In Rel-18 enhancements are done to specify following new features: Support for roaming and federation: Architecture for local breakout and home routed PDU session were specified. Procedures and information flows defined for ECS discovery and Service provisioning info retrieval.
Rel-18为此对漫游架构进行了深度增强，核心是支持**LBO（Local Breakout，本地分流）**模式下的边缘计算。
-
V-ECS（拜访网络边缘配置服务器）: 在拜访网络（VPLMN）中引入了V-ECS。当漫游用户发起边缘业务请求时，V-EASDF（拜访网络的边缘应用服务发现功能）会查询V-ECS，以发现在本地可用的边缘应用服务器（EAS）。
-
安全协同: 为了确保这个过程的安全性，Rel-18定义了一系列跨PLMN的安全机制。
- Security enhancement for edge computing… such as: • Authorization of PDU session to support local traffic routing to access an EHE in the VPLMN • Authorization between EESes • Security of EAS discovery procedure via V-EASDF in VPLMN
归属网络的EES（边缘使能服务器）与拜访网络的EES之间需要建立信任关系，并对跨网络的服务发现和会话授权进行严格的安全认证，确保只有合法的漫游用户，才能接入到拜访网络的边缘资源。
2) Edge node sharing: This feature is a special use case within federation.
更进一步，Rel-18还支持了边缘节点共享/联邦（Federation）。这意味着，不同的运营商或第三方边缘提供商，可以相互共享其边缘计算的物理资源，形成一个更广阔的“边缘资源池”，为孙博士的云游戏平台提供更广泛的覆盖。
2. “永不掉线”：ACR与服务连续性 (解读 18.2)
孙博士的第二个挑战，是移动中的服务连续性。一位玩家正坐着高铁，从一个由边缘节点A覆盖的城市，高速驶向由边缘节点B覆盖的城市。如何确保他的游戏会话，能够在这两个边缘节点之间无缝迁移？
6) ACR between EAS and Cloud: Architecture and procedures are enhanced to support service continuity to cloud.
18.2章节的核心，就是增强**ACR（Application Context Relocation，应用上下文迁移）**流程，以支持更复杂的场景。
- EAS to EAS (边缘到边缘): 当UE即将离开边缘节点A的覆盖区时，A节点的EAS（边缘应用服务器）可以将该玩家的游戏上下文（如游戏存档、会话状态等），“打包”并预先发送给目标边缘节点B的EAS。当UE真正切换到B的覆盖区后，B节点的EAS可以利用这个上下文，瞬间恢复游戏会话。
- EAS to Cloud (边缘到云): 当UE驶入一个没有任何边缘节点覆盖的区域时，其会话可以被无缝地迁移回中心云。虽然延迟会增加，但游戏不会中断。当UE再次进入另一个边缘节点的覆盖区时，会话又可以从云端迁移回新的边缘节点。
- Cloud to EAS (云到边缘): 反之亦然。
这一系列标准化的ACR流程，为孙博士的云游戏平台，提供了一套完整的“容灾”和“漫游”方案，确保了“游戏永不掉线”。
3. “一键拉起”：动态应用实例化 (解读 18.2)
挑战: 在一场大型电竞赛事中，孙博士需要为赛场区域，临时、动态地部署多个云游戏实例。他不可能提前在每个城市的边缘节点上都预装好他的游戏服务器。
4) Enhancements to dynamic EAS instantiation: During EAS discovery or ACR, the EES may fail to discover and select the EAS. The EES may trigger the ECSP management system to instantiate the EAS.
Rel-18为此增强了**动态EAS实例化（Instantiation）**的流程。
- 失败触发: 当一个UE请求边缘服务，但EES（边缘使能服务器）在其附近找不到一个“现成”的应用服务器实例时，这个“发现失败”事件，可以成为一个触发器。
- 联动MANO: EES会通知ECSP（边缘计算服务提供商）的管理系统（通常是MANO平台）。
- 按需“拉起”: 管理系统随即根据预先定义好的模板，在离UE最近的、可用的边缘节点上，**动态地、自动化地“拉起”**一个新的游戏服务器实例（例如，启动一个Docker容器或虚拟机）。
- 服务就绪: 实例启动并准备就绪后，再通知EES，EES最终将这个新实例的地址返回给UE。
这一“Just-in-Time”的动态实例化机制，使得边缘应用的部署，从“静态预置”演进为了“动态、按需、自动化”的云原生模式，极大地提升了资源利用率和业务的灵活性。
4. 开放与协同：面向未来的边缘生态
除了上述核心功能，18.1和18.2章节还引入了一系列重要的增强，旨在构建一个更开放、更智能的边缘生态。
- 3) Discovery of common EAS: …enables the participants of the same application specific group to discover same common EAS…
- 7) Bundle EASs: …EAS partners with other EASs – called linked bundled EASs.
- (18.2, Further…): Exposure of EAS Service APIs using CAPIF, … Usage of Edge Analytics.
- (18.3, Alignment with External Organizations): The EDGEAPP_EXT work item captures the alignment and deployment aspects of EDGEAPP… with ETSI MEC and GSMA OP architectures.
- 通用EAS发现: 允许多个属于同一群组的UE（例如，一个游戏战队的所有成员），能够被引导到同一个EAS实例上，以支持低时延的组内交互。
- 捆绑EAS: 支持多个不同但相互关联的应用（例如，游戏、语音、直播推流）以“捆绑”的形式提供，并支持它们之间的服务连续性。
- API开放与分析: 强调了使用CAPIF框架来开放边缘服务API，并引入了**边缘分析（Edge Analytics）**的概念，允许应用获取关于边缘节点负载、性能等分析数据。
- 与外部标准对齐:
18.3章节特别强调，3GPP的边缘计算架构，需要与ETSI MEC、GSMA Operator Platform等业界主流的边缘计算标准组织进行对齐和协同，以构建一个真正开放、互通的全球边缘生态。
总结
3GPP TR 21.918的18.1和18.2章节，标志着5G边缘计算的演进，已经成功地从“打通连接”的Phase 1，迈入了“深化协同、开放赋能”的Phase 2。
- 通过支持漫游与联邦（Roaming and Federation），5G边缘计算打破了单一运营商的边界，向着“全球一张网”的愿景迈出了坚实的一步。
- 通过增强应用上下文迁移（ACR），它为移动中的用户提供了“永不掉线”的服务连续性保障，解决了边缘计算移动性的核心痛点。
- 通过支持动态EAS实例化（Dynamic Instantiation），它将云原生的“按需、弹性”理念，成功地引入到了网络边缘，实现了资源的高效利用。
- 通过强调API开放、生态对齐、智能分析，它为构建一个开放、繁荣、智能的全球边缘计算生态系统，奠定了标准化的基础。
对于像孙博士这样的应用开发者，这些增强意味着他们可以构建出真正无国界、无缝隙、高度智能的下一代实时应用。他们不再需要为每个运营商、每个地区的边缘环境进行繁琐的定制开发，而是可以基于一套全球统一的标准，“一次开发，处处运行”。5G-Advanced，正在为引爆边缘计算的革命，提供最关键的“催化剂”。
FAQ - 常见问题解答
Q1：边缘计算中的“本地分流”（Local Breakout, LBO）在漫游场景下是如何工作的？ A1：在漫游LBO模式下，当一个漫游用户（例如，一个中国手机在德国）使用数据业务时，他的数据流不再需要绕回中国的归属网络核心网（HPLMN），而是直接在德国的拜访网络（VPLMN）内，通过本地的UPF接入互联网或本地的边缘应用服务器。具体到边缘计算场景，当这个用户请求一个边缘应用时，VPLMN的EASDF会发现这是一个边缘业务，并将其引导到VPLMN本地部署的边缘节点上。这大大降低了漫游用户的业务访问时延。要实现这一点，HPLMN和VPLMN之间需要有信任关系和策略协同，HPLMN需要授权VPLMN为自己的用户提供LBO服务。
Q2：应用上下文迁移（ACR）是如何保证游戏等实时应用“无感”切换的？ A2：ACR的“无感”核心在于**“预迁移”和“状态同步”。1）预迁移：当网络（通过AMF的移动性事件通知）预测到UE即将从边缘节点A的覆盖区移动到B区时，EES会提前**触发ACR流程。节点A的EAS会将当前的游戏上下文（内存状态、会话ID、安全密钥等）打包，通过后台网络发送给节点B的EAS。2）状态同步: 节点B的EAS收到上下文后，会预先“加载”好游戏环境。当UE的无线连接真正切换到节点B的基站后，其数据流会立即被导向这个已经“准备就绪”的游戏实例。由于游戏状态是同步的，对于玩家来说，他可能只会感觉到一瞬间的网络抖动（ping值的小幅波动），而不会出现游戏掉线、重连或状态丢失等情况。
Q3：什么是“边缘使能服务器”（EES）和“边缘配置服务器”（ECS）？它们在边缘计算架构中扮演什么角色？ A3：可以理解为“大堂经理”和“前台”。EES（Edge Enabler Server）是整个边缘计算生态的“大堂经理”和“业务入口”。所有来自UE、AF或第三方EES的边缘服务请求，都首先到达EES。它负责认证请求、解析请求、发现可用的边缘应用服务器（EAS）、触发ACR和动态实例化等核心的业务流程。而ECS（Edge Configuration Server）则更像是“前台”，它负责管理和下发边缘相关的UE策略。它会告诉UE：“在你所在区域，有哪些可用的边缘数据网络（EDN）”、“你应该如何发现边缘应用服务器”等配置信息。UE根据ECS下发的“地图”，才能准确地找到EES这个“大堂经理”。
Q4：3GPP的边缘计算架构和ETSI MEC有什么关系？它们是竞争还是合作？ A4：是深度合作与协同演进的关系。ETSI MEC更早地定义了一套通用的边缘计算架构和API，它更侧重于边缘平台本身的能力开放（如位置服务、无线网络信息API等），是一个通用的IaaS/PaaS层。而3GPP的边缘计算架构则更侧重于如何将5G核心网的独特能力（如移动性管理、QoS策略、切片等）与边缘计算深度融合，解决UE如何发现、接入、并在移动中连续使用边缘业务的问题。两者是互补的。Rel-18明确强调需要与ETSI MEC对齐，例如，3GPP的EES/ECS可以与ETSI MEC的MEO/MEPM进行接口互通，一个部署在ETSI MEC平台上的应用，可以被3GPP的UE通过标准流程发现和使用。
Q5：动态EAS实例化和我们熟知的云计算中的“弹性伸缩”（Auto Scaling）有什么异同？ A5：原理是相通的，都是云原生的核心理念，但触发机制和应用场景有所不同。弹性伸缩通常是基于负载的：当一个应用实例的CPU占用率超过80%时，系统会自动拉起一个新的实例来分担负载。而动态EAS实例化的触发机制更加多样化，它可以是：1）基于发现失败：如前所述，找不到可用实例时触发。2）基于移动性预测：当网络预测到一个用户即将移动到一个没有EAS实例的区域时，可以提前为他“预部署”一个实例。3）基于应用请求：AF可以直接请求在一个特定的边缘节点上，为特定的活动（如电竞赛事）动态地创建一批实例。可以说，动态EAS实例化是弹性伸缩理念在移动性和地理分布感知维度上的一个重要扩展。