51学通信

深度解析 3GPP TS 23.558：6 Application layer architecture (应用层体系架构)

23分钟阅读

深度解析 3GPP TS 23.558：6 Application layer architecture (应用层体系架构)

本文技术原理深度参考了3GPP TS 23.558 V18.10.0 (2025-03) Release 18规范中，关于“Chapter 6 Application layer architecture”的核心章节，旨在为读者完整呈现边缘应用世界的“角色全家福”与“交互关系网”。在这里，我们将深入了解边缘使能层的每一个功能实体，以及它们之间错综复杂又井然有序的通信接口。

引言：边缘世界的演员与舞台

在上一章中，我们学习了构建边缘世界的“宪法”——一系列必须遵守的架构要求。这些法规则为我们描绘了一个安全、可靠、开放的系统蓝图。现在，是时候为这个蓝图注入灵魂了——我们将正式认识舞台上的每一位“演员”，并揭示他们之间对话的“剧本”。

规范的第六章“Application layer architecture”，正是整部TS 23.558规范的核心与灵魂。它将第五章的抽象要求具象化，定义了边缘使能层（EEL）中每一个功能实体（Functional Entity）的职责，并精心设计了它们之间的通信接口（Reference Point）和交互模式。

我们的老朋友“智行一号”，在学完了边缘世界的“法律法规”后，现在将拿到一份详细的“组织架构图”和“通信录”。它将清晰地看到，自己车载系统中的EEC模块，将如何与网络中的ECS、EES协同，最终与EAS“会师”，完成一次次完美的边缘计算任务。本章内容是理解后续所有具体流程的基础，让我们一起进入这个精彩纷呈的边缘世界。

1. 宏伟蓝图：四种视角，同一架构 (6.2 Architecture)

为了全面地描述这个复杂的应用层架构，规范别出心裁地从四种不同的视角来进行描绘。这如同从不同角度观察一座宏伟的建筑，让我们能更立体地理解其内部结构。

This clause describes the architecture for enabling edge applications in the following representations:

  • A service-based representation…
  • A service-based representation as specified in 3GPP TS 23.501…
  • A service-based representation, where the Core Network Northbound APIs … are utilized … via CAPIF core function…
  • A reference point representation…

这四种视角分别是：边缘内部的服务化视图、与5G核心网（5GC）对接的服务化视图、通过CAPIF框架利用北向能力的视图，以及最经典的参考点（点对点接口）视图。

1.1 视角一：边缘内部的服务化视图 (Figure 6.2-1)

这是理解边缘使能层内部运作的主要视角。规范原文中的“Figure 6.2-1: Architecture for enabling edge applications - service-based representation”展示了这种关系。

在这个视图里，ECS和EES不再仅仅是“一个盒子”，而是作为服务提供者，向其他授权的功能实体暴露其服务。例如，EES向EEC提供“EAS发现服务”，ECS向EEC提供“服务开通服务”。这种面向服务的架构（SBA）思想，是现代通信系统设计的核心，它带来了极大的灵活性和可扩展性。

对“智行一号”而言，这意味着它的EEC无需关心EES的物理位置或实现细节，只需像调用一个Web API一样，去“消费”EES提供的标准化服务即可。

1.2 视角二：与5G核心网的互动视图 (Figure 6.2-2)

边缘使能层并非孤立存在，它需要与强大的5G核心网协同。这张图揭示了边缘实体在5GC眼中的“身份”。

规范原文中的“Figure 6.2-2: Utilization of 5GS network services based on the 5GS SBA – service based representation”清晰地表明：

The ECS, EES and EAS act as AFs for consuming network services from the 3GPP 5G Core Network entities over the Service Based Architecture…

ECS、EES和EAS，都被核心网统一视为AF（Application Function，应用功能）。它们通过标准的Nnef、Npcf等接口，与NEF（网络能力开放功能）、PCF（策略控制功能）等核心网网元交互，以获取网络能力或影响网络行为。

例如，当EES需要获取“智行一号”的精确位置时，它就以AF的身份，向NEF发起一个UE位置查询的标准服务请求。

1.3 视角三：通过CAPIF的能力消费视图 (Figure 6.2-3)

CAPIF（Common API Framework）是3GPP定义的一套统一的API框架，用于规范化地管理和开放网络API。这张图展示了边缘实体如何通过CAPIF框架来“消费”网络能力。

规范原文中的“Figure 6.2-3: Utilization of Core Network Northbound APIs via CAPIF – service based representation”描绘了这一场景。ECS、EES和EAS作为“API调用者”（API Invoker），通过CAPIF核心功能，与NEF、SCEF等“API提供者”（API Exposing Function）进行交互。

这种方式的好处在于，CAPIF提供了统一的API发现、认证、授权、计费等能力，使得边缘应用消费网络能力的过程更加标准化和安全可控。

1.4 视角四：经典的参考点视图 (Figure 6.2-4)

这是我们最熟悉的架构图形式，通过“方框+连线”的方式，定义了实体之间的点对点接口，即“参考点”（Reference Point）。这张图是后续理解所有具体流程的“地图”。

规范原文中的“Figure 6.2-4: Architecture for enabling edge applications - reference points representation”是本章的重中之重。它清晰地标示出了我们将在6.5节中详细解读的各个EDGE-x接口，如EEC与ECS之间的EDGE-4，EEC与EES之间的EDGE-1，EAS与EES之间的EDGE-3等。我们将在后续章节中详细拆解这些接口的用途。

2. 角色详解：边缘世界的“功能实体” (6.3 Functional entities)

在了解了架构的整体视图后，我们必须深入剖析每一个“演员”的具体职责。6.3节为我们提供了每个功能实体的详细“角色说明书”。

2.1 Edge Enabler Client (EEC)：“智行一号”的贴身管家

EEC provides supporting functions needed for AC(s). Functionalities of EEC are: a) retrieval of configuration information… b) discovery of EASs available in the EDN; c) detecting UE mobility events; d) exposure of events of interest to AC; and e) retrieval of UE ID and/or Edge UE ID.

EEC是部署在“智行一号”车载系统中的核心代理。它的职责就是将上层导航应用（AC）的业务需求，转化为与边缘使能层的标准化交互。它的主要工作包括：

  • 配置信息检索: 负责与ECS通信，获取EES的配置信息（服务开通）。
  • EAS发现: 负责向EES发起EAS发现请求。
  • 移动性事件检测: 它是服务连续性的“哨兵”，负责监测UE的位置变化，判断何时需要触发ACR。
  • 事件暴露: 它可以将从网络侧感知的事件（如ACR完成）通知给上层AC。
  • ID检索: 负责获取UE的各种网络身份标识。

2.2 Edge Configuration Server (ECS)：边缘世界的“城市规划局”

ECS provides supporting functions needed for the EEC to connect with an EES. Functionalities of ECS are: a) provisioning of Edge configuration information to the EEC.

ECS的职责相对聚焦，但至关重要。它维护着一个宏观的边缘服务资源地图。

  • 边缘配置信息下发: 它的核心任务就是响应EEC的服务开通请求，为其提供一个动态的、基于位置的EES列表。
  • 联邦与漫游支持: 在更复杂的场景下，ECS还负责与其他运营商或合作伙伴的ECS（通过EDGE-10接口）交互，支持跨域的服务发现和联邦。我们将在后续章节详细介绍。

2.3 Edge Enabler Server (EES)：区域服务的“调度中心”

EES provides supporting functions needed for EASs and EEC. Functionalities of EES are: a) provisioning of configuration information to EEC… g) registration functions … for the EEC(s) and the EAS(s); i) supporting ACR related operations…

EES是边缘使能层中功能最丰富、职责最复杂的实体。它是一个区域性的管理核心。

  • 注册管理: 负责处理EEC和EAS的注册、更新和去注册请求，维护动态的“供需”信息。
  • 能力开放代理: 作为AF，与3GPP核心网交互，并将网络能力（如定位、QoS）封装成API暴露给EAS。
  • 服务连续性核心: 在ACR流程中扮演核心角色，负责发现T-EAS、协调S-EES与T-EES之间的上下文传输（如EEC Context Push/Pull）。
  • 动态实例化触发: 在需要时，向更高层的管理系统触发动态创建EAS实例的请求。

2.4 云端角色：Cloud Enabler Server (CES) & Cloud Application Server (CAS)

边缘并非万能，当“智行一号”驶出所有边缘节点的覆盖范围时，服务需要平滑地回退到中心云。为此，规范定义了云端的对应角色。

Cloud Application Server (CAS): CAS is the application server resident in the cloud, performing the server functions. Cloud Enabler Server (CES): CES provides supporting functions needed for CASs. … CES facilitates service continuity between EAS and CAS.

  • CAS: 业务应用部署在中心云的版本。
  • CES: 扮演着EES在云端的“镜像”角色，使得CAS也能够参与到ACR流程中，实现从边缘到云（Edge-to-Cloud）或从云到边缘（Cloud-to-Edge）的服务连续性。

3. 通信接口：解读边缘世界的“高速公路网” (6.5 Reference Points)

如果说功能实体是城市，那么参考点（接口）就是连接城市的高速公路。6.5节详细定义了每条“高速公路”的用途。

  • EDGE-1 (EEC ←> EES): 这是最繁忙的公路。EEC的注册、EAS发现、发起ACR等核心操作都在这条路上进行。

  • EDGE-2 (EES ←> 3GPP Core): EES通往“首都”（核心网）的公路，用于获取网络能力。

  • EDGE-3 (EES ←> EAS): EAS向EES“报备”和EES向EAS“赋能”的专用通道。

  • EDGE-4 (EEC ←> ECS): “智行一号”启动后，寻找EES的“导航专用路”。

  • EDGE-5 (AC ←> EEC): UE内部的“私家路”，应用与代理之间的沟通渠道。

  • EDGE-6 (ECS ←> EES): EES向ECS注册自己的通道，确保“城市规划局”有最新的“区域调度中心”名单。

  • EDGE-9 (EES ←> EES): 实现服务连续性的“城际特快专线”。当需要进行EEC上下文迁移时，源EES和目标EES通过这条线路高效同步信息。

  • EDGE-10 (ECS ←> ECS): 支持联邦和漫游的“国际公路”，用于不同运营商的ECS之间交换信息。

  • ECI-x / CLOUD-x: 这些接口定义了边缘实体与云端实体（CES/CAS）之间的交互，是实现“边云协同”的桥梁。例如，ECI-1 (CAS ←> EES) 用于云端应用参与到边缘的ACR流程中。

4. 拓展疆域：漫游与联邦的架构支持 (6.2a Roaming, 6.2b Federation)

“智行一号”的旅程不会局限于一个运营商的网络。当它跨省、甚至出国时，就需要漫游和联邦的支持。

4.1 漫游架构 (6.2a Architecture for Roaming support)

This clause describes the architectures for roaming UEs. To support UEs that are roaming, the EEL uses ECSs provided in HPLMN and VPLMN.

当“智行一号”漫游到外地网络（VPLMN）时，它需要同时与本地的V-ECS/V-EES和归属地的H-ECS/H-EES打交道。规范支持两种漫游模型：

  • 本地分流 (LBO): “智行一号”在访问本地边缘服务时，数据流量直接从漫游地的网络出去。这能保证最低的时延。
  • 归属地路由 (HR): 数据流量需要先绕回“智行一号”的归属地网络（HPLMN），再进行分发。虽然时延较高，但在策略和计费控制上更简单。

4.2 联邦架构 (6.2b Architecture for Federation support)

To support Federation, EDGE-10 reference point is used between the ECSs to exchange ECS profile and EDN configuration information.

联邦是指不同的服务提供商（ECSP）之间达成协议，共享边缘资源。比如，“智行一号”是A运营商的用户，但它想使用B运营商独有的高清视频渲染服务。通过联邦架构，A运营商的ECS可以通过EDGE-10接口向B运营商的ECS查询服务信息，并将结果返回给“智行一号”，引导它去使用B运营商的边缘服务。这极大地拓展了边缘服务的边界。

5. 规则与API：量化关系，固化能力 (6.6 Cardinality rules & 6.7 Capability exposure)

最后，规范通过量化的规则和API列表，为整个架构的实现提供了精确的指导。

5.1 基数规则 (6.6 Cardinality rules)

The cardinality rules are applied to the architecture… The functional entity cardinality specifies the multiplicity of the functional entity that can exist…

这一节回答了“多少对多少”的问题，例如：

  • 一个UE里可以有一个或多个AC/EEC。
  • 一个EEC可以同时与一个或多个EES通信。
  • 一个EES可以同时为成百上千个EEC服务。 这些规则对于系统设计和容量规划至关重要。

5.2 能力开放API (6.7 Capability exposure for enabling edge applications)

这一节通过表格（如Table 6.7.2-1: APIs provided by the ECS）的形式，汇总了ECS、EES等实体所暴露的全部API服务。这就像一份“政府服务清单”，明确告知了开发者可以调用哪些标准化的服务。例如，ECS提供了Eecs_ServiceProvisioning服务，EES提供了Eees_EASDiscovery、Eees_EECRegistration等服务。这些API是开发者进行实际编程时需要直接面对的接口。

总结

第六章是TS 23.558的心脏。它不仅定义了边缘世界的所有角色，还 meticulously地规划了它们之间的每一条互动路径和规则。通过这四种架构视角、详尽的实体功能定义、清晰的接口说明，以及对漫游、联邦等高级场景的支持，第六章为我们构建了一个逻辑严密、功能完备、可扩展性强的应用层体系。

“智行一号”的工程师们，在通读了这一章后，心中已经有了一幅清晰的开发路线图。他们知道该如何让“智行一号”的EEC去发现ECS，如何注册到EES，如何为AC寻找最佳的EAS，以及在面对复杂的跨域移动时，如何依赖这套标准架构保证服务的永不掉线。

FAQ

Q1：为什么架构图有“服务化”和“参考点”两种表示方法？它们有什么不同？ A1：这两种表示方法是从不同抽象层次来描述同一个系统。

  • 参考点（Reference Point）视图更偏向于“物理”和“网络拓扑”，它明确了两个实体之间存在一个点对点的、命名的接口（如EDGE-1）。这对于网络规划和接口协议的定义非常重要。
  • 服务化（Service-based）视图更偏向于“逻辑”和“软件架构”，它强调实体是作为“服务”存在的。一个实体可以向多个消费者提供服务，而消费者无需关心提供者具体在哪里。这种模型更符合现代云原生的设计思想，更加灵活和解耦。 两者结合，使得我们既能从宏观上理解服务的调用关系，又能从微观上定义接口的具体协议。

Q2：EES和3GPP核心网的NEF（网络能力开放功能）有什么关系？EES会取代NEF吗？ A2：EES不会取代NEF，它们是协作关系。NEF是5G核心网官方的、统一的能力开放门户，它负责将核心网内部的能力（如定位、策略、监控等）安全地暴露给外部的AF。EES在很多场景下，就是扮演AF的角色，去消费NEF提供的服务。然后，EES可以对从NEF获取的能力进行二次封装、聚合或简化，再暴露给更上层的EAS。可以把NEF看作“国家级”的能力开放网关，而EES则像是某个“垂直行业领域”（边缘计算领域）的“行业级”能力代理。

Q3：漫游（Roaming）和联邦（Federation）听起来很像，它们的根本区别是什么？ A3：根本区别在于主体和关系不同。

  • 漫游的主体是用户（UE）。指的是用户离开了自己的归属地网络（HPLMN），接入到了一个外部的、有漫游协议的访问网络（VPLMN）。关系是HPLMN与VPLMN之间的。
  • 联邦的主体是服务提供商（ECSP）。指的是不同的服务提供商之间达成协议，共享或互访对方的边缘资源和能力。用户可能并没有离开自己的归属地网络，但它使用的边缘服务可能来自与归属运营商有联邦协议的另一个ECSP。关系是ECSP-A与ECSP-B之间的。

Q4：为什么需要定义Cloud Enabler Server (CES)？直接让AC连接云端的CAS不就行了吗？ A4：直接连接当然可以，但那就失去了“服务连续性”。引入CES的核心目的，是为了让云端的CAS能够参与到TS 23.558定义的ACR（应用上下文重定位）流程中。当“智行一号”从最后一个边缘节点驶出，需要切换到云服务时，S-EES可以将EEC的上下文信息（EEC Context）通过CES传递，S-EAS也可以将应用上下文（Application Context）传递给CAS。这样就实现了从“边”到“云”的平滑切换，而不是一次粗暴的连接中断和重连。

Q5：6.7节中提到的API，是RESTful API吗？开发者可以直接用HTTP调用吗？ A5：是的。虽然TS 23.558作为Stage 2规范，主要定义的是功能和信息流，不涉及具体的协议实现。但3GPP SA6在制定对应的Stage 3规范（如TS 24.558和TS 29.558）时，这些API都被实现为基于HTTP/2的RESTful API。开发者确实可以通过标准的HTTP请求/响应方式来调用这些服务，这极大地降低了开发门槛，使得广大的互联网和IT开发者能够轻松地与复杂的电信网络进行集成。

关系图谱