51学通信

深度解析 3GPP TS 23.558：8.3 ECS Discovery and Service provisioning (Part 1 - 寻找边缘世界的入口)

22分钟阅读

深度解析 3GPP TS 23.558：8.3 ECS Discovery and Service provisioning (Part 1 - 寻找边缘世界的入口)

本文技术原理深度参考了3GPP TS 23.558 V18.10.0 (2025-03) Release 18规范中，关于“8.3 ECS Discovery and Service provisioning”的核心章节。在本系列的前几篇文章中，我们已经掌握了边缘计算的宏观蓝图、设计法则以及核心身份标识。从本文开始，我们将正式潜入规范的“深水区”——第八章“Procedures and information flows”，逐一拆解边缘世界运转的每一个具体流程。本文作为流程篇的开篇，将聚焦于“智行一号”唤醒后的第一个动作：如何找到进入边缘世界的入口并获取第一份导航地图。

引言：万里长征第一步

清晨，停在地下车库的“智行一号”被车主远程唤醒。车载系统（UE）启动，内置的边缘使能客户端（EEC）模块也随之苏醒。此刻的它，如同一位初生的婴儿，对广阔的边缘世界一无所知。它知道自己身处一个5G网络中，也知道自己身负重任——需要为上层的自动驾驶应用（AC）连接到低时延的边缘服务。但问题是：“门”在哪里？

网络中可能有成千上万的边缘节点，由不同的边缘使能服务器（EES）管理。EEC该如何找到那个“对的人”？这便是本章要解决的核心问题——ECS发现与服务开通。这个过程，是万里长征的第一步，也是后续所有精彩边缘故事的序章。它决定了“智行一号”能否顺利地从“离线”状态，踏入到“在线”的边缘智能世界。

1. 流程鸟瞰：从唤醒到“持图索骥” (8.3.1 General)

在深入细节之前，8.3.1节首先为我们提供了一张高度概括的流程全景图，让我们对服务开通的整个生命周期有一个宏观概念。

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).

规范原文中的“Figure 8.3.1-1: Overview of Service provisioning”清晰地描绘了“智行一号”从启动到消费边缘服务的完整链路：

  1. UE被授予ECS连接配置：这是起点。“智行一号”出厂时或通过网络连接，被告知了至少一个ECS（边缘配置服务器）的地址。
  2. UE请求服务开通：EEC向ECS发起它的第一次“问询”。
  3. UE被配置连接到EDN：ECS响应请求，返回EES（边缘使能服务器）的地址和连接边缘数据网络（EDN）所需的信息。
  4. EEC向EES注册：EEC向EES“报到”，建立正式的管理关系。
  5. UE消费边缘服务：EEC开始代表AC进行EAS发现、建立连接、甚至进行ACR（应用上下文重定位）。

有趣的是，这是一个循环。在“智行一号”行驶过程中，某些事件可能会再次触发服务开通流程，比如：

  • UE侧触发:
    • “智行一号”的应用更新了。车主新安装了一个AR导航应用，EEC需要为这个新应用重新向ECS查询匹配的边缘服务。
    • “智行一号”驶出了当前EDN的服务区。例如，从北京市区开往河北，需要重新获取河北区域的边缘服务配置。
  • ECS侧触发:
    • 运营商在“智行一号”行驶的路线上新增或更新了EES/EAS。ECS可以主动通知EEC，有更好的服务可供使用。

这个概览图告诉我们，服务开通不仅是“一次性”的启动行为，更是一个贯穿UE整个边缘服务生命周期的、动态的、可重复的配置更新过程。

2. 发现ECS：茫茫人海中找到“引路人” (8.3.2 ECS Discovery)

服务开通的第一步，是找到ECS。8.3.2节详细阐述了EEC可以如何发现ECS。

ECS configuration information consists of one or more endpoint information (e.g. URI(s), FQDN(s), IP address(es)) of ECS(s), and optionally the corresponding ECS Provider Identifier. ECS configuration information can be:

  • pre-configured with the EEC;
  • configured by an edge-aware AC;
  • configured by the user;
  • provisioned by MNO through 5GC procedure…

就像寻找一家餐厅，你可以有多种方式获取地址：

  • 预配置 (pre-configured): 这是最可靠的方式。就像“智行一号”出厂时，车载导航系统已经内置了全国主要城市的地图。同样，EEC可以预置一张主流运营商的ECS地址列表。
  • 应用告知 (configured by an edge-aware AC): 某个特定的APP（AC），比如一个由某运营商定制的“智慧高速”应用，它自己就知道该使用哪个ECS，并在启动时将地址告诉EEC。
  • 用户配置 (configured by the user): 虽然不常见，但系统可以提供一个入口，允许专业用户或测试人员手动输入ECS地址。
  • 5GC下发 (provisioned by MNO through 5GC): 这是最智能的方式。当“智行一号”的5G模块接入网络时，运营商的核心网（如PCF）可以根据车辆当前的位置，通过5G信令动态地将最合适的ECS地址下发给UE。
  • 标识符派生 (derived from HPLMN/VPLMN identifier): EEC还可以根据当前连接的运营商网络标识（PLMN ID），按照一个预定义的规则（如ecs.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org）来构造出ECS的域名（FQDN）。

在获得了ECS的地址信息后，我们来看看这张“名片”上都写了什么。

首先，我们来解析Table 8.3.2.1-1: ECS configuration information per ECS 这张表，它定义了EEC获取到的关于单个ECS的配置信息结构。

Information elementStatusDescription
ECS addressMEndpoint information of ECS (e.g. URI, FQDN, IP address)
ECSP Identifier (NOTE 1)OThe identifier of the ECSP (e.g., the MNO or a 3rd party service provider) that provides the ECS.
Spatial Validity ConditionsOSpatial validity condition, as described in 3GPP TS 23.548
Security ParametersOThe security parameters… used by EEC to communicate with the ECS.
List of supported PLMN(s)OThe List of PLMNs and associated ECSPs for which EDN configuration information can be provided by the ECS.
> PLMN IDOThe identifier of a PLMN for which EDN configuration information can be provided by the ECS.
> List of supported ECSP(s) (NOTE 2)OThe identifier of the ECSP(s) associated with the PLMN and whose information is available at the ECS
>> ECSP IDMIdentifier of an ECSP

核心字段解析：

  • ECS address: (必需) 这就是ECS的联系方式，是EEC下一步通信的目标地址。
  • ECSP Identifier: (可选) 提供了这个ECS的服务商是谁，比如是中国移动还是某个第三方云厂商。
  • Spatial Validity Conditions: (可选) 指明了这个ECS配置信息的有效地理范围。比如，这个ECS地址只在北京地区有效。
  • List of supported PLMN(s): (可选) 对于一个可能服务于多个运营商的ECS，这里列出了它能为哪些网络提供服务，以及在每个网络下，它又代理了哪些边缘服务提供商（ECSP）的资源。这在联邦和漫游场景下非常重要。

3. 服务开通流程：获取你的专属“边缘地图” (8.3.3 Service provisioning)

找到了“引路人”ECS，接下来就是正式向它请求“地图”了。8.3.3节定义了两种截然不同的交互模式：请求/响应模式和订阅/通知模式。

3.1 请求/响应模式 (Request-response model - 8.3.3.2.2)

这是最基础、最直接的模式，适用于一次性的配置获取。规范原文中的“Figure 8.3.3.2.2-1: Service provisioning – Request/Response”描绘了这个简单的三步流程。

“智行一号”的旅程：

  1. EEC发送服务开通请求: “智行一号”的EEC向ECS发送一个请求。这个请求中包含了丰富的“上下文”信息，我们通过解析Table 8.3.3.3.2-1: Service provisioning request来一探究竟。

    Information elementStatusDescription
    EECIDMUnique identifier of the EEC.
    Security credentialsMSecurity credentials resulting from a successful authorization…
    AC Profile(s) (NOTE)OInformation about services the EEC wants to connect to…
    Application information (NOTE)O…including the option to provide application group profile information.
    EEC Service Continuity SupportOIndicates if the EEC supports service continuity or not…
    UE IdentifierOThe identifier of the UE (i.e. GPSI)
    Connectivity informationOList of connectivity information for the UE, e.g. PLMN ID, SSID.
    UE locationOThe location information of the UE.
    ECSP identifiersOThe list of EEC preferred ECSPs that provide the EES.

    核心字段解析：

    • AC Profile(s): 这是请求的核心！它告诉ECS，“智行一号”上安装了哪些应用，每个应用对网络有什么样的需求（比如时延、带宽）。ECS将依据这份“需求清单”来筛选EES。
    • UE location: 车辆当前的位置，是ECS进行地理位置匹配的关键输入。
    • EEC Service Continuity Support: 车辆是否支持高级的服务连续性功能，这会影响ECS推荐的EES类型。
    • ECSP identifiers: “智行一号”可以表明它“偏爱”使用哪些服务商的边缘资源。

  2. ECS处理请求: ECS收到请求后，将化身为一个智能的“调度大脑”。它会综合EEC提供的所有信息，进行一系列复杂的匹配和决策，最终找出一个或多个最合适的EES。

  3. ECS返回服务开通响应: ECS将结果打包返回给EEC。这个“大礼包”的内容定义在Table 8.3.3.3.3-1: Service provisioning response中。

    Information elementStatusDescription
    Successful responseOIndicates that the service provisioning request was successful.
    > List of EDN configuration informationMList of EDN configuration information as defined in Table 8.3.3.3.3-2.
    Failure responseOIndicates that the service provisioning request failed.
    > CauseOIndicates the cause of service provisioning request failure.
    RedirectOIndicates redirection to (an)other ECS(s).
    > ECS(s) informationMEndpoint address of ECS(s) to which the UE is redirected…

    最核心的内容是List of EDN configuration information，这张表（8.3.3.3.3-2）是EEC收到的最终“地图”，内容极为丰富，包括EES的地址、EDN的网络信息（DNN/APN）、EES的服务范围、安全凭证，甚至还有该EES下已知的EAS信息和动态实例化能力等。

    一个有趣的分支是Redirect。如果当前的ECS发现自己无法满足“智行一号”的需求，但它知道另一个ECS（比如漫游地或联邦伙伴的ECS）可以，它就会在响应中提供那个ECS的地址，让EEC去那里“另请高明”。

3.2 订阅/通知模式 (Subscribe-notify model - 8.3.3.2.3)

对于“智行一号”这样的移动设备，一次性的配置获取是不够的。当它在城市中行驶时，最佳的EES是在动态变化的。订阅/通知模式允许EEC向ECS“订阅”配置更新，当有更合适的EES出现时，ECS会“主动通知”EEC。

这个模式包含了一系列流程，我们快速过览：

  • Subscribe (订阅): EEC向ECS发起一个“服务开通订阅请求”（见Figure 8.3.3.2.3.2-1）。除了请求/响应模式的参数，它还会提供一个Notification Target Address，告诉ECS“有新消息请送到这个地址”。ECS成功处理后会返回一个Subscription ID。
  • Notify (通知): 当ECS检测到有满足EEC订阅条件的事件发生时（如“智行一号”进入了一个有更好EES服务的区域），它会主动向EEC之前提供的地址发送一个“服务开通通知”（见Figure 8.3.3.2.3.3-1）。通知的内容与请求/响应模式的成功响应类似，都是一份更新后的“边缘地图”。
  • Subscription update (订阅更新): EEC可以在订阅有效期内，更新它的订阅条件，例如延长订阅时间或修改AC Profile。
  • Unsubscribe (取消订阅): 当“智行一号”关机或不再需要该服务时，EEC会向ECS发送取消订阅的请求。

4. 统一的API入口 (8.3.4 APIs)

最后，规范将上述所有复杂的流程，统一封装在了一个API服务中。如Table 8.3.3.4.1-1: Eecs_ServiceProvisioning API所示：

API NameAPI OperationsOperation SemanticsConsumer(s)
Eecs_ServiceProvisioningRequestRequest/ResponseEEC
SubscribeSubscribe/NotifyEEC
Notify
UpdateSubscription
Unsubscribe

这张表清晰地表明，无论是简单的一次性请求，还是复杂的订阅/通知，对于开发者来说，都归结于调用Eecs_ServiceProvisioning这一个API的不同操作（Operations）。这种高度统一的API设计，极大地简化了客户端的开发逻辑。

总结

8.3章“ECS发现与服务开通”为我们详细描绘了“智行一号”从茫然到清晰的“寻路”之旅。它通过一套严谨的流程，确保了EEC总能基于自身的位置、应用需求和偏好，从网络中动态获取到一份最优的、定制化的“边缘服务入口地图”。

  • ECS发现解决了“找谁问路”的问题。
  • 服务开通则解决了“路在何方”的问题。
  • 两种交互模式（请求/响应和订阅/通知）兼顾了静态启动和动态移动两种场景的需求。
  • 统一的API封装则大大降低了开发者的实现复杂度。

完成了这一步，“智行一号”的手中已经握有了一张通往EES的“门票”。在下一篇文章中，我们将继续跟随它，走进EES的大门，去探索一个更精彩、更具体的世界——注册与EAS发现。

FAQ

Q1：为什么服务开通（Service Provisioning）是由EEC和ECS交互，而不是直接和EES交互？ A1：这是基于分层和分治的设计思想。ECS扮演的是一个广域的、宏观的配置角色，它的“视野”是整个运营商网络甚至跨网络。而EES是一个区域性的、具体的服务管理角色，它只关心自己“一亩三分地”上的EAS和EEC。让EEC先找ECS，就像找工作的流程：你先上海投平台（ECS）筛选出符合你大致方向和地域的公司（EES），然后再向这些具体的公司（EES）投递简历（注册和发起发现请求）。这种分层架构大大提升了系统的可扩展性和管理效率。

Q2：在请求/响应模式中，ECS返回的“EDN configuration information”里为什么可能包含EAS的信息？此时不是还没到EAS发现阶段吗？ A2：这是一个很好的问题，体现了规范的灵活性。ECS在某些情况下，可以进行“优化”或“预提供”。如果EEC的请求非常明确（例如，AC Profile里指明了只需要某一个特定的、全局知名的EAS），且ECS恰好从EES的注册信息中得知，某个EES下正好有这个EAS，它可以在服务开通响应中就“顺便”把这个EAS的信息告诉EEC。这可以减少后续EEC与EES之间的一次EAS发现交互，提升效率。但这只是一个可选的优化，标准的流程依然是先获取EES，再由EEC向EES发起EAS发现。

Q3：订阅/通知模式听起来很棒，但如果“智行一号”断网了或者进入了无信号区域，错过了ECS的通知怎么办？ A3：这是一个很好的实际问题。3GPP的订阅/通知模型通常都有配套的鲁棒性机制。虽然TS 23.558没有深入到底层协议，但通常的实现会是：

  1. 带时效性: ECS下发的配置信息（EES列表）会有一个“Lifetime”（生命周期）参数。如果EEC长时间没有收到更新通知，它会认为当前配置可能已失效，并在重新获得网络连接后，主动再次发起服务开通请求。
  2. 触发式更新: 当“智行一号”重新接入网络、发生位置区更新等重大网络事件时，EEC会被触发，主动向ECS进行一次信息同步，以确保自己持有最新的配置。
  3. SEAL服务: 规范第九章提到了可以使用SEAL（Service Enabler Architecture Layer for Verticals）的通知管理服务，该服务提供了更可靠的消息传递机制。

Q4：AC Profile在服务开通过程中到底有多重要？ A4：AC Profile是ECS进行智能决策的核心依据。一个没有AC Profile的服务开通请求，就像一个走进商场却不说想买什么的顾客，总服务台（ECS）只能给他一份标准的全楼层指南。而一个带有详细AC Profile的请求，则像一个目标明确的顾客，他告诉服务台：“我要买一台能玩4K游戏的电视，预算1万以内，而且我只信赖A和B两个品牌”。服务台（ECS）就能根据这些精确的需求，直接告诉他去五楼的A品牌旗舰店和B品牌专卖店（最合适的EES）。AC Profile的详细程度，直接决定了服务开通的精准度和效率。

Q5：如果ECS返回了多个EES，EEC该如何选择？ A5：规范将选择权交给了EEC，允许它根据自身的策略来决定。EEC的选择依据可能包括：

  • 网络状况: 选择到哪个EES的网络路径质量最好（如RTT最低）。
  • 服务区匹配度: 如果多个EES的服务区有重叠，EEC可能会选择那个能覆盖其未来预测路径更广的EES。
  • 负载信息: 如果EES能提供一定的负载状态指示，EEC会优先选择较为空闲的EES。
  • ECSP偏好: 根据用户或应用的偏好设置，优先选择某个服务提供商的EES。 这种客户端侧的选择机制，赋予了终端更大的灵活性和智能性。

关系图谱