51学通信

深度解析 3GPP TS 23.558：边缘计算架构 (全文概览)

33分钟阅读

深度解析 3GPP TS 23.558：边缘计算架构 (全文概览)

本文技术原理深度参考了3GPP TS 23.558 V18.10.0 (2025-03) Release 18规范，旨在为通信行业的工程师和未来技术专家们提供一个关于3GPP如何为边缘应用构建应用层体系架构的全景视图。本文将作为系列文章的开篇，对整个规范的核心理念、关键角色和主要流程进行一次全面的梳理和解读。

引言：为何我们需要一篇专门的边缘应用架构规范？

5G时代，“低时延、高带宽”不再是遥不可及的口号，而是催生无数创新应用的基石。从自动驾驶、工业互联网、云游戏到AR/VR，这些应用对网络的苛刻要求，将计算和存储能力从遥远的中心云推向了离用户更近的网络边缘。这，就是边缘计算（Edge Computing）。

然而，边缘计算的落地并非易事。应用开发者如何发现并使用运营商提供的边缘能力？用户的终端应用（APP）在移动过程中，如何从一个边缘节点无缝切换到另一个？不同的运营商和设备商之间，如何保证边缘服务的互联互通？为了解决这些问题，3GPP SA6工作组制定了TS 23.558规范——《Architecture for enabling Edge Applications》。

这本规范的核心使命，就是定义一个标准的应用层架构，构建一套通用的“语言”和“规则”，让上层的边缘应用（Edge Application）能够与下层的3GPP网络（包括运营商网络和第三方网络）高效、标准地协同工作。它不关心底层网络如何传输比特，而是聚焦于应用层面的服务发现、能力开放、服务连续性等关键问题。

在本文中，我们将化身为一辆名为“智行一号”的高度自动驾驶汽车，通过它在智慧城市中穿梭一天的旅程，来生动地揭示TS 23.558规范的精髓。

1. 边缘计算的蓝图：TS 23.558描绘的世界 (Chapter 4 Overview)

一切的开始，源于一个清晰的目标。TS 23.558希望构建一个怎样的世界？规范的第四章“Overview”为我们描绘了蓝图。

For edge computing, it is essential that the ACs are able to locate and connect with the most suitable application server available in the EDN, depending on the needs of the application. The edge enabler layer exposes APIs to support such capabilities.

这段话点出了边缘计算最核心的需求：让应用客户端（AC, Application Client）能够找到并连接到边缘数据网络（EDN, Edge Data Network）中最合适的边缘应用服务器（EAS, Edge Application Server）。而实现这一目标的关键，就是规范定义的核心——边缘使能层（Edge Enabler Layer）。

想象一下，“智行一号”正行驶在繁忙的城市道路上。为了做出毫秒级的决策，它需要实时获取前方路口的高精地图、交通灯状态、以及其他车辆的行驶意图（V2X信息）。这些数据处理和融合服务，就部署在路边的边缘计算节点上，也就是EAS。

“智行一号”上的导航和决策系统，就是AC。它面临的第一个问题就是：在成千上万的边缘节点中，我应该连接哪一个？是距离最近的？还是计算能力最强的？或者两者兼顾？

TS 23.558通过“Figure 4.1-1: Overview of 3GPP edge computing”这张图，清晰地回答了这个问题。这张图将整个体系划分为四个逻辑层面：

  • 应用层（Application Layer）: 这是“智行一号”的导航APP（AC）和路侧服务器（EAS）所在的地方。
  • 边缘使能层（Edge Enabler Layer）: 这是TS 23.558规范的核心，它如同一个“超级中介”，负责应用的注册、发现、连接管理等。
  • 边缘托管环境（Edge Hosting Environment）: 这是承载EAS运行的物理或虚拟化环境，例如边缘服务器、容器平台等，规范对其不做具体定义。
  • 3GPP传输层（3GPP Transport Layer）: 即5G核心网和无线接入网，负责提供基础的数据连接。

整个规范的核心工作，就是详细定义“边缘使能层”的功能。它主要包含以下几个核心能力，我们将在后续章节中通过“智行一号”的旅程来逐一展开：

  • 服务开通 (Service Provisioning): 如何让“智行一号”知道附近有哪些可用的边缘服务“大市场”？
  • 注册 (Registration): “智行一号”和路侧的边缘应用如何进入这个“市场”并亮明身份？
  • EAS发现 (EAS Discovery): “智行一号”如何在这个市场里，根据自己的需求（例如，需要处理V2X数据）找到最合适的“摊位”（EAS）？
  • 能力开放 (Capability Exposure): 边缘应用如何向3GPP网络请求特定的服务，比如获取“智行一号”的精确位置？
  • 服务连续性 (Support for service continuity): 当“智行一号”从一个路口驶向下一个路口时，如何保证服务不中断，实现无缝切换？
  • 计费 (Charging): 运营商如何对这些丰富多彩的边缘服务进行计费？

2. 架构的设计原则：构建稳固的地基 (Chapter 5 Architectural requirements)

在建造任何宏伟建筑之前，都必须遵循一套严格的设计原则。TS 23.558的第五章“Architectural requirements”就扮演了这样的角色，它为整个边缘应用架构设定了必须遵守的“军规”。

这些要求看似抽象，但每一条都至关重要，确保了整个系统的开放性、灵活性和安全性。

[AR-5.2.1.2-a] The application layer architecture shall support deployment of EAS(s) and AC(s) with or without modifications compared to their existing deployments. [AR-5.2.1.2-c] The application layer architecture shall be compatible with the 3GPP network system.

这两条通用要求（General requirements）体现了极强的工程实用性。第一条意味着，应用开发者不需要为了适配边缘计算而重写整个应用，现有的大部分应用（AC和EAS）可以轻松地“迁移”到边缘。第二条则确保了这套应用层架构能够与复杂的3GPP网络系统和谐共存。

让我们通过“智行一号”的视角来理解其他关键要求：

  • 注册要求 (Registration): 规范要求架构必须提供机制，让“智行一号”上的客户端（EEC）和边缘应用服务器（EAS）都能向系统注册。这就像进入一个会员制俱乐部，你必须先登记身份，系统才能知道你的存在，并为你提供服务。同时，还要能检测到异常的注销，防止“僵尸”连接占用资源。

  • 发现要求 (EAS discovery): 架构必须提供机制让“智行一号”能够发现可用的EAS。这不仅是找到，更是要找到“最合适”的。并且，发现结果必须包含足够的信息，让“智行一号”能直接与EAS建立通信。

  • 能力开放要求 (Capability exposure to EASs): 架构必须支持向EAS暴露3GPP网络的能力。比如，一个提供高精定位服务的EAS，需要向网络查询“智行一号”的无线信号质量、小区ID等信息，以辅助定位。这种应用与网络的“对话”能力是实现智能服务的关键。

[AR-5.2.6.2-c] Communication between the functional entities of the application layer architecture shall be protected. [AR-5.2.6.2-h] The application layer architecture shall provide mechanisms to support privacy protection of the user.

  • 安全要求 (Security): 安全是自动驾驶的生命线。规范强制要求边缘使能层各实体间的通信必须被保护。同时，当EAS需要获取“智行一号”的位置等敏感信息时，必须获得用户的授权，并保护用户隐私。

  • 服务连续性要求 (Service continuity): 这是对移动场景的核心要求。规范明确指出，架构必须提供机制来支持应用上下文（Application Context）的转移。

[AR-5.2.11.2-a] The application layer architecture shall provide mechanisms to support service continuity such that the Application Context with a S-EAS is transferred to a T-EAS.

当“智行一号”从A路口（由S-EAS服务）驶向B路口（由T-EAS服务）时，它在A路口积累的所有状态信息（如行驶轨迹、周围环境模型等），即“应用上下文”，必须能够平滑地转移到B路口的T-EAS。否则，每过一个路口，系统就需要重新学习一次，这将导致决策延迟，甚至引发危险。

这些架构要求，共同构成了TS 23.558的坚实地基，确保了其上构建的边缘生态系统是健壮、安全且高效的。

3. 核心角色与通信网络：边缘世界的“玩家”们 (Chapter 6 Application layer architecture)

有了设计原则，就需要具体的“角色”来执行任务。第六章“Application layer architecture”是整个规范的灵魂，它定义了边缘使能层的核心功能实体（Functional entities）以及它们之间的交互接口（Reference Points）。

This clause describes the architecture for enabling edge applications… A service-based representation, where the Edge Enabler Layer functions (e.g. ECS) enable other authorized Edge Enabler Layer functions (e.g. EES) to access their services. This representation also includes point-to-point reference points where necessary.

让我们来认识一下这个边缘世界的主要“玩家”：

  • 边缘使能客户端 (EEC, Edge Enabler Client): 它驻留在用户设备（UE）中，是边缘应用（AC）的“代理人”。在我们的故事里，EEC就是安装在“智行一号”车载系统中的一个标准化软件模块。它代表上层的导航应用（AC）处理所有与边缘网络交互的复杂事务。AC只需告诉EEC“我需要一个V2X服务”，而无需关心如何发现、如何连接、如何切换。

  • 边缘使能服务器 (EES, Edge Enabler Server): 它是边缘应用服务器（EAS）的“守护神”，部署在运营商的边缘数据网络（EDN）中。EES负责管理其服务范围内的所有EAS，接收并处理来自EEC的请求。它就像一个区域性的“婚介所”，既管理着所有“待嫁”的EAS信息，又接待着前来“相亲”的EEC。

  • 边缘配置服务器 (ECS, Edge Configuration Server): 它是整个边缘生态的“导航员”。当“智行一号”（EEC）开机并接入网络时，它首先需要知道该去哪里找“婚介所”（EES）。ECS就负责告诉EEC，根据你当前的位置，你应该去联系A路口或B路口的EES。ECS通常由运营商部署，覆盖更广的范围。

  • 边缘应用服务器 (EAS, Edge Application Server): 这就是提供具体业务的应用服务器，比如前文提到的V2X数据处理服务、高精地图服务等。

  • 应用客户端 (AC, Application Client): UE上的具体应用，如“智行一号”的导航APP。

规范通过“Figure 6.2-4: Architecture for enabling edge applications - reference points representation”这张图，清晰地描绘了这些角色之间的关系网。这张图定义了一系列以“EDGE-”命名的接口，它们是理解工作流程的关键：

  • EDGE-4 (EEC ←> ECS): 这是“智行一号”旅程的第一步。EEC通过这个接口向ECS查询，获取附近可用的EES列表和配置信息。这被称为“服务开通（Service Provisioning）”。

  • EDGE-1 (EEC ←> EES): 这是EEC与EES之间的主通信接口。EEC通过它进行注册，并发起EAS发现请求。当服务需要切换时，也是通过它来发起应用上下文重定位（ACR）。

  • EDGE-3 (EAS ←> EES): 边缘应用（EAS）通过此接口向EES注册自己，并上报自己的服务能力、状态、服务范围等信息。EES也通过此接口向EAS暴露网络能力（如UE位置）。

  • EDGE-5 (AC ←> EEC): 这是一个UE内部接口。应用（AC）通过它向EEC发出服务请求，例如“帮我找一个游戏加速服务”。

  • EDGE-9 (EES ←> EES): 这是服务连续性的关键接口。当“智行一号”需要从一个EES的服务范围移动到另一个EES时，两个EES通过此接口传递EEC的上下文信息，实现平滑的“关系转移”。

除了这些主要接口，规范还定义了EES/ECS/EAS与3GPP核心网交互的接口（EDGE-2, EDGE-7, EDGE-8），以及与云端应用（CAS）交互的接口（ECI-1, CLOUD-1等），形成了一个完整的、可扩展的架构。

4. 关键旅程：从启动到无缝切换的完整流程 (Chapter 8 Procedures and information flows)

理论知识已经铺垫完毕，现在让我们跟随“智行一号”的脚步，完整地体验一遍TS 23.558定义的核心流程。第八章“Procedures and information flows”是规范中最具体、最详细的部分，它定义了每个动作的详细步骤。

场景： “智行一号”在城市的A区域启动，准备前往B区域。

第一幕：启动与服务开通 (ECS Discovery and Service Provisioning - 8.3)

“智行一号”启动车载系统，其内置的EEC模块被激活。

Service provisioning allows configuring the EEC with information about available Edge Computing services, based on the hosting UEs location, service requirements, service preferences and connectivity. This configuration includes the necessary address information for the EEC to establish connection with the EES(s).

  1. ECS发现: EEC的首要任务是找到它的“引路人”——ECS。ECS的地址可以通过多种方式配置给EEC，例如在UE出厂时预配置，或者通过5G核心网（5GC）在UE接入网络时下发。
  2. 服务开通请求: 找到ECS后，EEC立即通过EDGE-4接口向ECS发起一个“服务开通请求”。这个请求中会包含“智行一号”的身份标识、当前的大致位置（例如小区ID）、以及它所安装的应用（AC）的类型信息（AC Profile）。
  3. 服务开通响应: ECS收到请求后，会根据“智行一号”的位置和应用需求，从其庞大的数据库中筛选出当前最适合服务它的一个或多个EES。然后，ECS将这些EES的地址、服务范围、连接所需的DNN/S-NSSAI等信息打包，通过EDGE-4返回给EEC。

至此，“智行一号”已经拿到了通往边缘世界的第一张“地图”。

第二幕：注册与发现 (Registration & EAS Discovery - 8.4, 8.5)

手握EES列表，EEC选择了信号最好、覆盖最匹配的S-EES（Source EES），开始正式“入场”。

An EEC performs registration with an EES in order to provide information that can be used by the EES in Edge Computing services. EAS discovery enables the EEC to obtain information about available EASs of interest… based on matching EAS discovery filters provided in the request.

  1. EEC注册: EEC通过EDGE-1接口向S-EES发起注册请求。S-EES验证其身份后，会为“智行一号”创建一个“EEC上下文（EEC Context）”，记录它的身份、订阅的服务、安全信息等。这个上下文是后续所有服务的基础。
  2. EAS发现请求: 与此同时，“智行一号”的导航应用（AC）通过EDGE-5接口向EEC发出指令：“我需要一个低时延的V2X服务！”。EEC将这个需求转换成标准的“EAS发现过滤器”（EAS discovery filters），通过EDGE-1发送给S-EES。过滤器中可能包含：服务类型（V2X）、期望时延（<10ms）、地理位置（当前路口附近）等。
  3. EAS发现与选择: S-EES在自己管理的EAS“花名册”中进行匹配，找到了一个完全符合条件的S-EAS（Source EAS），并将S-EAS的地址、服务详情等信息返回给EEC。
  4. 建立连接: EEC将S-EAS的信息通过EDGE-5告知AC，AC随即与S-EAS建立直接的应用数据连接。“智行一号”开始享受由边缘计算提供的超低时延V2X服务，实时感知周围路况。

第三幕：移动中的挑战与服务连续性 (Service continuity - 8.8)

“智行一号”平稳地驶过A区域，即将进入由另一个边缘节点覆盖的B区域。一场无形的“接力赛”即将上演。

When a UE moves to a new location, different EASs can be more suitable for serving the ACs in the UE… Support for service continuity provides several features for minimizing the application layer service interruption by replacing the S-EAS connected to the AC in the UE, with a T-EAS or CAS.

  1. ACR触发: EEC通过监测UE的移动性事件（例如，从核心网收到的位置更新通知）或AC的预测，感知到“智行一号”即将离开S-EAS的服务范围。它判断需要进行应用上下文重定位（ACR, Application Context Relocation）。
  2. T-EAS发现: EEC向其当前的S-EES发起一个特殊的EAS发现请求，请求中包含了对目标区域（B区域）和未来位置的描述。S-EES自身可能无法服务B区域，但它知道B区域由T-EES（Target EES）负责。S-EES通过EDGE-9接口与T-EES通信，或EEC通过服务开通重新发现并连接T-EES，最终为“智行一号”找到位于B区域的目标应用服务器T-EAS（Target EAS）。
  3. 应用上下文转移: 这是ACR的核心。S-EAS会将“智行一号”当前所有的服务状态数据——即“应用上下文”——打包，直接或通过EES的中转，发送给T-EAS。这个过程对AC是透明的。
  4. 无缝切换: T-EAS接收并加载应用上下文后，它就完全同步了“智行一号”之前的状态。此时，AC在EEC的引导下，将数据流从S-EAS无缝切换到T-EAS。“智行一号”的驾驶员（或自动驾驶系统）完全感受不到任何中断，导航和危险预警服务依旧流畅。
  5. 清理: 切换完成后，S-EAS会清理掉旧的应用上下文，释放资源。整个ACR流程宣告完成。

这个过程完美诠释了TS 23.558如何通过标准化的流程，解决移动边缘计算中最棘手的服务连续性问题。

5. 身份与坐标：边缘世界的唯一标识 (Chapter 7 Identities and commonly used values)

在上述所有复杂的交互流程中，系统如何精确地识别每一个参与者？第七章“Identities and commonly used values”定义了这些“身份证”。

The following clauses specify a collection of identities that are associated with entities defined and being used in this specification.

  • EECID (Edge Enabler Client ID): 全局唯一的EEC标识符，是“智行一号”上EEC模块的“身份证号”。
  • EESID (Edge Enabler Server ID): 标识一个EES，是“婚介所”的“营业执照”。
  • EASID (Edge Application Server ID): 全局唯一的应用标识，标识一类应用，例如所有V2X服务都共享同一个EASID。
  • UE ID: 用户的唯一标识，可以是GPSI（如MSISDN或IMSI）等。

除了身份ID，规范还定义了“常用值”，比如UE location（UE位置）和Service areas（服务区）。服务区可以是拓扑服务区（如一组小区ID），也可以是地理服务区（如一个圆形或多边形区域）。这些标准化的定义，使得不同实体之间在讨论位置和范围时有了统一的语言。

6. 总结：TS 23.558的价值与意义

通过“智行一号”一天的旅程，我们完整地体验了3GPP TS 23.558所定义的边缘应用架构。从启动时的迷茫，到通过ECS找到方向，再到通过EES发现并连接上最佳的EAS，最后在高速移动中实现服务的无缝切换，每一步都有据可循，有章可依。

TS 23.558的真正价值在于，它在复杂的边缘生态中建立了一套标准化的协同框架：

  • 对于应用开发者（ASP）: 他们无需再为对接不同运营商的私有边缘平台而烦恼。只需遵循TS 23.558的应用层接口规范，他们的应用就能“一点接入，全网适用”，极大地降低了开发和部署成本。
  • 对于运营商（MNO/ECSP）: 规范提供了一套清晰的架构，指导他们如何构建开放、可管理的边缘能力平台，如何将网络能力（如定位、QoS）安全地开放给第三方应用，从而创造新的商业价值。
  • 对于终端和芯片制造商: 规范定义了EEC的功能，使得他们可以在硬件或操作系统层面集成标准化的边缘连接能力，提升产品的竞争力。
  • 对于最终用户: 标准化带来了生态的繁荣和服务的可靠。无论是自动驾驶、云游戏还是远程医疗，用户都能享受到低时延、高连续性的优质体验。

总而言之，3GPP TS 23.558不仅仅是一份技术文档，它更像是一部“边缘世界的宪法”，为万物互联时代的智能应用和服务构建了坚实的法律和秩序。它承载着推动5G应用从“可用”迈向“好用”的重任，为未来数字社会的构建奠定了不可或缺的应用层基石。

FAQ

Q1：边缘使能层中的ECS, EES, EAS三个角色有什么区别？ A1：可以把它们比作一个大型购物中心：

  • ECS (边缘配置服务器) 是购物中心的总服务台。当你刚进入商场时，你需要去总服务台获取楼层指南，了解各个区域（比如“家电区”、“餐饮区”）在哪里。ECS就负责告诉你的设备（EEC）附近有哪些可用的边缘服务区域，以及该联系哪个区域的“经理”（EES）。
  • EES (边缘使能服务器) 是每个特定区域的区域经理。比如“家电区”的经理，他管理着该区域内所有的店铺（EAS），了解每个店铺卖什么、是否在营业。EES负责管理一个或多个边缘数据网络（EDN），处理来自用户的具体服务发现请求。
  • EAS (边缘应用服务器) 就是区域内的具体店铺，比如“XX品牌电视专卖店”。它提供实际的应用服务，直接与顾客（AC）进行“交易”（数据交互）。

Q2：EEC (边缘使能客户端) 是一个APP还是操作系统的一部分？ A2：EEC是一个功能实体，它的实现方式很灵活。它可以是一个独立的代理程序（Agent），也可以是一个SDK（软件开发工具包）被集成到具体的APP（AC）中，甚至可以由设备操作系统提供基础能力。从应用开发者的角度看，他们通常是通过调用EEC提供的API来与边缘网络交互，从而简化开发。在我们的“智行一号”例子中，EEC可以被看作是其智能座舱操作系统的一部分。

Q3：什么是应用上下文重定位（ACR），它为什么对移动边缘计算至关重要？ A3：应用上下文重定位（ACR）是指在用户从一个边缘服务器（源EAS）的服务范围移动到另一个边缘服务器（目标EAS）的服务范围时，将用户的服务状态信息（即应用上下文）从源服务器迁移到目标服务器的过程。这对于需要保持服务连续性的移动应用至关重要。例如，对于“智行一号”，它的应用上下文可能包括当前的驾驶意图、已规划的路径、传感器融合后的环境模型等。如果没有ACR，每切换到一个新的EAS，这些信息都将丢失，系统需要重新计算和同步，这将导致服务中断或决策延迟，在自动驾驶等场景下是不可接受的。

Q4：TS 23.558定义的架构与ETSI MEC（多接入边缘计算）是什么关系？ A4：它们是互补而非竞争的关系。ETSI MEC更侧重于定义边缘托管环境（Edge Hosting Environment）的架构和API，即如何在一个边缘节点上部署和管理应用、如何开放无线网络能力（如RNI API）等。而3GPP TS 23.558更侧重于应用层，解决的是UE上的应用如何在广域范围内（跨越多个MEC节点）发现服务、并保持服务连续性的问题。简单来说，MEC管好“一个点”，而23.558管好“一张网”上的应用协同。规范的附录C也明确指出了两者之间的关系和协同方式。

Q5：作为一名应用开发者，如果我想让我的应用支持边缘计算，最应该关注TS 23.558的哪个部分？ A5：作为应用开发者，你应该重点关注AC（你的应用）与EEC之间的交互，即EDGE-5接口相关的流程和API（在8.14章节中有详细定义）。你需要理解如何通过EEC发起EAS发现请求，如何描述你应用所需的边缘服务特性（AC Profile），以及如何在ACR发生时配合EEC完成应用上下文的迁移。规范使得开发者不必关心底层复杂的网络信令，只需与EEC这个标准化的“代理”打交道，就能利用整个边缘网络的能力。

关系图谱