51学通信

深度解析 3GPP TS 23.222：第七章及后续 - CAPIF的“实战演练”与API“说明书”

16分钟阅读

好的，我们继续对TS 23.222的深度拆解。

这是系列文章的第五篇，也是我们对这份规范解读的最终章。我们将把目光投向规范的第七章及以后的核心流程、API定义及附录。这部分内容是CAPIF框架从“蓝图”走向“实操”的关键，它详细定义了API生命周期管理的每一个具体步骤和接口规范。

深度解析 3GPP TS 23.222：第七章及后续 - CAPIF的“实战演练”与API“说明书”

本文技术原理深度参考了3GPP TS 23.222 V18.7.0 (2024-12) Release 18规范中，作为规范核心流程和API定义的“Chapter 7 Application of functional model to deployments”, “Chapter 8 Procedures and information flows”, “Chapter 10 CAPIF core function APIs”及相关附录。本文旨在带领读者完成一次CAPIF的“实战演练”，我们将从部署模式的选择开始，逐步走过API调用者“入驻”、API“上架”、“发现”和“调用”的全流程，并最终检阅CAPIF核心功能所暴露的API“说明书”。

引言：从“解剖图”到“模拟手术”，亲历API的生命之旅

在上一篇中，我们已经拥有了CAPIF的“系统解剖图”，知道了它由哪些功能实体和参考点构成。现在，是时候进入“模拟手术室”，亲手操作一遍，看看这个系统是如何运转的了。

如果说第六章是静态的“解剖学”，那么第八章“Procedures and information flows”就是动态的“外科学”。它为CAPIF的每一个核心操作——从API调用者的“入院登记”（Onboarding），到API的“上架”（Publish）、“查找”（Discover），再到最终的“调用”（Invocation）——都提供了详尽的分步手术流程图。

而第十章“CAPIF core function APIs”，则是我们手中的“手术器械说明书”。它详细定义了我们与CAPIF核心功能（CCF）这个“大脑”进行交互时，所使用的每一个API的名称、功能和参数。

今天，我们将扮演“主刀医生”的角色，跟随开发者**“极客小创”的脚步，完整地经历一次与CAPIF框架的交互。同时，我们还会看一看第七章所描述的不同“手术室布局”（部署模式）**，并最终检阅CAPIF的API“说明书”。

1. 第七章 Application of functional model to deployments：选择你的“战场布局”

本章描述了第六章定义的功能模型，在现实世界中可以有哪些不同的部署方式。

  • 7.2 Centralized deployment (集中式部署):
    • 布局 (Figure 7.2-1): CAPIF核心功能（CCF）与API提供者域的功能（AEF, APF, AMF）合设在一个物理节点或集群上。
    • 特点: 部署简单，管理集中。对于外部的API调用者来说，CAPIF就像一个单一的、统一的“API网关”。
    • 适用场景: 中小型网络，或者业务相对单一的私网部署。
  • 7.3 Distributed deployment (分布式部署):
    • 布局 (Figure 7.3-1): CAPIF核心功能（CCF）与API提供者域的功能分离部署。例如，CCF部署在中央数据中心，而AEF（NEF）则可以根据地理位置或业务类型，分布在网络的边缘。
    • 特点: 架构更灵活，扩展性更好，支持更复杂的拓扑（如7.3.2节的级联AEF）。
    • 适用场景: 大型运营商网络，需要支持边缘计算、多地接入和复杂拓扑隐藏的场景。

2. 第八章 Procedures and information flows：API生命周期的“实战演练”

本章是规范的“流程精华”。让我们跟随“极客小创”的无人机应用，走完一次完整的API生命周期。

2.1 8.1 Onboarding the API invoker to the CAPIF (“入驻”API市场)

Figure 8.1.3-1: Procedure for onboarding the API invoker to the CAPIF

  1. API invoker sends Onboard API invoker request: 小创的应用向**CAPIF核心功能（CCF）**发起入驻请求，提交身份等注册信息。
  2. CAPIF core function … verifies … and further initiates a grant process: CCF验证信息的合法性，并可能需要CAPIF管理员进行人工审批（explicit grant）。
  3. …provisioning API invoker profile: 审批通过后，CCF为小创的应用创建一个API invoker profile（会员档案）。
  4. CAPIF core function returns … onboard API invoker response: CCF向应用返回成功响应，可能包含用于后续认证的凭证。

2.2 8.3 & 8.7 Publish and Discover service APIs (“上架”与“发现”API)

Figure 8.3.3-1: Publish service APIs Figure 8.7.3-1: Discover service APIs

  • 发布 (Publish):
    1. 运营商的NEF（通过API publishing function, APF）向CCF发起Service API publish request，请求“上架”一个新的“无人机轨迹API”。
    2. CCF验证APF的权限，成功后将这个API的信息存入自己的“API注册表（API registry）”。
  • 发现 (Discover):
    1. 小创的应用（API invoker）在入驻成功后，向CCF发起Service API discover request，查询条件为“API类别 = 无人机服务”。
    2. CCF在其“API注册表”中进行检索，并根据为小创配置的发现策略进行过滤。
    3. CCF将符合条件的“无人机轨迹API”的详细信息（功能描述、入口地址AEF_Address等），通过Service API discover response返回给小创的应用。

2.3 8.11 & 8.15 API调用前的“双重认证”

在真正调用API之前，安全是第一位的。CAPIF设计了严谨的双重认证/授权流程。

  1. 8.10/8.11 获取“通行证” (Authentication/Authorization with CAPIF core function):

    Figure 8.11.3-1: Procedure for the API invoker obtaining authorization for service API access

    • 小创的应用向CCF发起认证，并请求获取访问“无人机轨迹API”的授权。
    • CCF验证其身份和权限后，向其颁发一个OAuth 2.0访问令牌（Access Token）。这张“令牌”，就是进入API安全门禁的“通行证”。

  2. 8.14/8.15 API调用时的“验票” (Authentication with AEF):

    Figure 8.15.3-1: Procedure for authentication between the API invoker and the AEF upon the service API invocation

    • 小创的应用带着这个“通行证”（Access Token），向之前发现的AEF地址，发起真正的API调用。
    • AEF作为“门禁”，在执行业务逻辑前，必须验证这个令牌的真伪和有效性。它可以自己验证，也可以向CCF发起“验票”请求。
    • 验证通过后，AEF才将请求转发给后台的业务实体。

这套“先去票务中心领票，再到景点门口验票”的机制，确保了每一次API调用都是经过授权和认证的，构建了零信任的安全模型。

3. 第十章 CAPIF core function APIs：CAPIF的“遥控器”

第十章是CAPIF的“API说明书”。它详细定义了CCF向外暴露的、用于实现第八章所有流程的RESTful API。

Table 10.1-1: List of CAPIF core function APIs

这张总览表，就是CCF的“遥控器”面板。它将所有功能，归类为几个核心的API。

  • CAPIF_Discover_Service_API: 用于发现API。
    • Discover_Service_API operation: 核心的查询操作。
    • Subscribe_Event operation: 订阅“有新API上架”等事件。
  • CAPIF_Publish_Service_API: 用于发布和管理API。
    • Publish_Service_API operation: 上架API。
    • Unpublish_Service_API operation: 下架API。
    • Update_Service_API operation: 更新API信息。
  • CAPIF_API_invoker_management_API: 用于管理API调用者。
    • Onboard_API_Invoker operation: 入驻。
    • Offboard_API_Invoker operation: 注销。
  • CAPIF_Security_API: 用于安全认证与授权。
    • Obtain_Authorization operation: 获取访问令牌。
  • 其他API: 还包括事件订阅、监控、日志、审计、策略控制等一系列API。

每一条API操作，规范都给出了详细的描述，包括功能说明、消费者、输入参数和输出参数。例如：

10.2.2 Discover_Service_API operation API operation name: Discover_Service_API Description: Provides the published service APIs information. Known Consumers: API invoker. Inputs: Refer subclause 8.7.2.1. (即包含API调用者身份和查询条件的请求) Outputs: Refer subclause 8.7.2.2. (即符合条件的API列表)

这份详尽的API“说明书”，是第三方开发者（如小创）与运营商CAPIF平台进行对接开发的最直接、最权威的技术依据。

4. 附录：CAPIF的部署实例与外部关系

  • Annex B (CAPIF relationship with network exposure aspects of 3GPP systems):
    • 本附录提供了CAPIF在4G EPS和5G 5GS网络中部署的具体映射关系。
    • Table B.1.1-1和Table B.2.1-1清晰地指出了：
      • CAPIF的AEF角色，在EPS中由SCEF扮演，在5GS中由NEF扮演。
      • API调用者（3rd party application）在EPS中对应SCS/AS，在5GS中对应AF。
      • CAPIF的各个参考点，与SCEF/NEF的外部和内部接口（如T8, N33）的对应关系。
    • 这个附录，是理解CAPIF如何在现有3GPP能力开放架构上“落地”的关键。
  • Annex D (CAPIF relationship with external API frameworks):
    • 本附录对比了CAPIF与OMA Network APIs和ETSI MEC API framework在各项功能上的支持情况。
    • 它显示了这三大API框架在发现、授权、拓扑隐藏等方面有很多共通之处，但也各有侧重。这体现了3GPP在制定CAPIF时，积极地与业界其他标准组织进行对齐和协同。

FAQ环节

Q1：第八章定义了如此多的流程，对于一个最基础的API调用，最核心的流程是哪几个？ A1：一个最简化的、核心的流程“三部曲”是：

  1. Onboarding (8.1): 一次性的开发者注册。
  2. Discover (8.7) + Authorize (8.11): 应用在启动或需要调用新API时，先发现API的入口，然后获取访问该入口的令牌。
  3. Invoke (8.15/8.16): 带着令牌，反复地调用业务API。

Q2：第十章的CAPIF API，是基于什么技术实现的？ A2：它们被设计为RESTful API，遵循当今互联网最主流的API设计风格。这意味着：

  • 协议: 基于HTTP/2。
  • 数据格式: 通常使用JSON。
  • 接口风格: 面向资源（Resource），使用统一的接口（GET, POST, PUT, DELETE等HTTP方法）来操作资源。
  • 安全: 使用OAuth 2.0框架进行授权。 这种设计，极大地降低了习惯于互联网开发的“极客小创”们的学习和接入成本。

Q3：为什么需要区分CAPIF-1/2/3/4/5和CAPIF-1e/2e/3e/4e/5e这些接口？ A3：后缀e代表external（外部），用于区分API交互的信任域。

  • 不带e的接口: 用于信任域内部的实体之间交互。例如，运营商自己的一个App调用CAPIF。
  • 带e的接口: 用于跨越信任域的交互。例如，一个来自公共互联网的第三方应用调用CAPIF。 带e的接口，通常意味着需要经过更严格的安全网关（如API Gateway, Security Gateway），并采用更强的安全策略。这种区分，是CAPIF安全体系的重要组成部分。

Q4：附录B中提到，SCEF/NEF可以“实现CAPIF架构”。这是否意味着，一个单独的NEF就可以完成CAPIF的所有功能？ A4：是的，这是一种被称为**“集成部署（Integrated deployment）”的模式。一个功能强大的NEF/SCEF产品，完全可以在其内部，同时实现CAPIF核心功能（CCF）和API提供者域功能（AEF/APF/AMF）。对于外部世界来说，这个NEF就是一个“All-in-One”**的CAPIF实例。这种部署方式简单、高效，特别适合起步阶段或规模不大的网络能力开放场景。

Q5：作为系列终章，回顾TS 23.222，它给移动通信行业带来的最根本的变革是什么？ A5：最根本的变革，是它为3GPP网络从一个**“封闭的通信管道提供者”，转型为一个“开放的平台化服务运营者”，提供了标准化的技术引擎和商业框架**。

  • 对运营商: CAPIF提供了一套将网络能力“产品化”、“服务化”并推向广阔开发者市场的工具，是其在5G时代实现业务创新和价值变现的关键。
  • 对开发者: CAPIF打破了电信网络的“黑盒”，提供了一个统一、安全、便捷的入口，让他们能够像调用云计算服务一样，轻松地利用5G网络的独特能力。
  • 对整个生态: CAPIF通过与ETSI MEC、OMA等业界标准的对齐，促进了一个更开放、更协同、更繁荣的全球通信应用生态的形成。 TS 23.222不仅是一份技术规范，更是3GPP拥抱开放、融入互联网生态的“宣言书”。

关系图谱