51学通信

深度解析 3GPP TS 29.531：1 Scope, 2 References & 3 Definitions (范围、参考文献与定义)

25分钟阅读

深度解析 3GPP TS 29.531：1 Scope, 2 References & 3 Definitions (范围、参考文献与定义)

本文技术原理深度参考了3GPP TS 29.531 V18.8.0 (2024-09) Release 18规范中，关于“Chapter 1 Scope”、“Chapter 2 References”和“Chapter 3 Definitions and abbreviations”的核心章节，旨在为后续的深度拆解构建坚实的知识地基。

在上一篇《网络切片选择服务的核心枢纽 (NSSF 全景概述)》中，我们通过5G发烧友“小杰”一天的生活，宏观地了解了NSSF在5G网络切片中的核心地位和两大关键服务。我们知道了NSSF是切片选择的“总舵主”，负责为用户匹配最合适的网络资源。

从本文开始，我们将正式进入对TS 29.531规范的“显微镜”模式，逐章、逐节、逐句地进行精细化解读。任何伟大的建筑都始于坚实的地基。同样，要透彻理解一份技术规范，前三个章节——范围（Scope）、参考文献（References）、定义与缩略语（Definitions and abbreviations）——就是我们必须稳扎稳打的地基。

很多工程师和初学者可能会习惯性地跳过这些看似“务虚”的章节，直奔核心的信令流程。然而，这种做法往往会导致对后续内容的理解出现偏差。这三个章节如同寻宝图的“图例”和“指南针”，它们清晰地界定了本规范的边界，指明了所有知识点的来源与依赖，并统一了我们沟通的“语言”。

因此，让我们再次跟随小杰的视角，不过这次我们不再是观察他的行为，而是像他一样，以一位严谨的产品经理和技术爱好者的身份，坐下来，泡上一杯咖啡，仔细研读这份规范的开篇部分，看看3GPP的专家们是如何为NSSF这部鸿篇巨制定下基调的。

1. 范围 (Scope)：划定NSSF的“权责边界”

规范的第一章“Scope”，其核心作用是回答一个根本性问题：“这份长达数十页的文档，到底规定了什么，又不规定什么？” 它为NSSF的功能实现划定了一个清晰的、不多也不少的“管辖范围”。

规范原文引用 (Chapter 1 Scope):

The present document specifies the stage 3 protocol and data model for the Nnssf Service Based Interface. It provides stage 3 protocol definitions and message flows, and specifies the API for each service offered by the NSSF.

The 5G System stage 2 architecture and procedures are specified in 3GPP TS 23.501 and 3GPP TS 23.502.

The Technical Realization of the Service Based Architecture and the Principles and Guidelines for Services Definition are specified in 3GPP TS 29.500 and 3GPP TS 29.501.

短短三段话，信息量巨大。让我们来逐一拆解。

1.1 “Stage 3”的深刻含义：从“做什么”到“怎么说”

第一段话的核心是 “Stage 3”。在3GPP的规范体系中，这是一个至关重要的概念，它将复杂的系统设计分为了三个逻辑阶段：

  • Stage 1 (业务与服务需求)：定义系统需要支持哪些业务，以及从用户角度看应该具备什么能力。例如，TS 22.261就定义了5G系统的业务需求。这相当于建筑设计的“客户需求书”。

  • Stage 2 (系统架构与流程)：定义为了满足Stage 1的需求，需要哪些逻辑功能实体（网元），以及这些实体之间的高层交互流程。这相当于建筑的“总体设计图和功能分区图”。

  • Stage 3 (协议与接口实现)：详细定义Stage 2中网元间接口的具体协议、消息格式、参数编码等实现细节。这相当于建筑的“详细施工图”，精确到每一根钢筋的尺寸和位置。

TS 29.531 明确自己是 Stage 3 规范，这意味着：

  1. 它不是创造者，而是实现者：NSSF这个网元的功能、它需要和谁交互，这些都不是由29.531决定的。决定这些的是Stage 2规范，也就是原文中引用的TS 23.501和TS 23.502。

  2. 它关注的是“通信语言”：这份规范的核心是定义AMF、NSSF等网元之间如何“说话”。说的“语言”是HTTP/2，说的“内容格式”是JSON，说的“语法规则”就是本规范定义的API（Application Programming Interface）。

  3. 它直接指导开发与测试：核心网设备开发商的工程师们，正是依据这份Stage 3规范，来编写NSSF和AMF等网元接口部分的代码。测试工程师也依据它来设计测试用例，验证不同厂商设备间的互操作性。

场景关联：小杰作为产品经理，他首先会看Stage 1规范，了解市场需要什么样的切片服务。然后，他会和架构师一起看Stage 2规范（23.501/23.502），确定产品（比如AMF）需要具备与NSSF交互的能力。最后，他会把Stage 3规范（29.531）交给开发团队，说：“好了，这就是我们和NSSF对话的具体协议，照着这个去实现！”

1.2 奠定NSSF存在的四大基石

规范原文的第二、三段引用了四份极其重要的规范，它们共同构成了TS 29.531赖以存在的“四大基石”。不理解这四份规范，就无法真正理解TS 29.531的设计思想。

| 规范编号 | 规范标题 (节选) | 角色与作用 | 与TS 29.531的关系 |

| :--- | :--- | :--- | :--- |

| 3GPP TS 23.501 | System Architecture for the 5G System | 5G系统蓝图 | 定义了NSSF这个功能实体的存在，以及它在整个5G核心网架构中的位置和高层职责。29.531是其架构思想的具体协议落地。 |

| 3GPP TS 23.502 | Procedures for the 5G System | 5G业务故事板 | 详细描述了包含网络切片选择的各种端到端信令流程，如注册、PDU会话建立等。它明确了在哪个流程的哪个步骤，需要调用NSSF的服务。 |

| 3GPP TS 29.500 | Technical Realization of Service Based Architecture | SBA通用法则 | 定义了所有5G核心网服务化接口（SBI）都必须遵守的公共规则，如HTTP/2的使用、错误处理机制、安全框架等。29.531定义的API必须遵循这些法则。 |

| 3GPP TS 29.501 | Principles and Guidelines for Services Definition | API设计指南 | 提供了设计和定义服务化接口（如NSSF的服务）的模板和原则，特别是如何使用OpenAPI规范来描述API。29.531的附录A中的OpenAPI定义就是遵循此规范完成的。 |

深入解读：

  • 23.501 告诉我们，5G世界里需要一个叫NSSF的“角色”。

  • 23.502 告诉我们，在“UE注册”这个“剧本”里，AMF这个“演员”需要去找NSSF“对台词”。

  • 29.500 告诉我们，所有演员“对台词”时，都必须说“普通话”（HTTP/2），遇到问题要按统一的规矩处理。

  • 29.501 则告诉我们，每个“剧本”的“台词本”（API定义文件）应该用什么样的标准格式（OpenAPI）来写，方便所有演员阅读和理解。

因此，TS 29.531 是在这样一个宏大而严谨的框架下，专注于完成一件具体而精细的工作：为NSSF这个角色，谱写它在各个剧本中需要说的精确台词。

2. 参考文献 (References)：构建NSSF知识体系的“索引”

第二章“References”看似只是一个枯燥的文档列表，但它实际上是构建NSSF完整知识体系的“超链接索引”。任何时候当我们在后续章节中遇到一个不熟悉的概念或协议时，都应该回到这里，找到它的“出生证明”——原始定义所在的规范。

规范原文引用 (Chapter 2 References):

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

  • References are either specific … or non-specific.
  • For a non-specific reference, the latest version applies. …

这段引言说明了这些参考文献的法律地位：它们的内容通过引用，成为了TS 29.531规范本身的一部分，具有同等的约束力。

我们将这些参考文献进行分类解读，以便更有条理地理解NSSF的知识依赖图谱。

| 分类 | 关键参考文献 | 解读其对TS 29.531的重要性 |

| :--- | :--- | :--- |

| 基础词汇与架构 | 3GPP TR 21.905
3GPP TS 23.501
3GPP TS 23.502 | TR 21.905是3GPP的“新华字典”，所有术语的权威定义都在这里。TS 23.501/502在第一章已详述，它们是NSSF存在的架构和流程基础。 |

| 服务化架构(SBA)核心 | 3GPP TS 29.500
3GPP TS 29.501
3GPP TS 29.510 | 29.500/501是SBA的“宪法”和“立法原则”。TS 29.510定义了NRF（网络功能仓库功能）的服务接口。AMF等NF消费者需要通过NRF的服务来发现NSSF实例。 |

| 通用数据类型 | 3GPP TS 29.571 | 定义了所有SBI接口共用的数据类型，如 Snssai, Tai, PlmnId 等。TS 29.531的大量数据结构都直接复用了这里的定义，避免了重复造轮子。 |

| API与协议基础 | OpenAPI Specification
3GPP TS 23.003
IETF RFC 9113 (HTTP/2)
IETF RFC 8259 (JSON) | OpenAPI是描述API的“语言”。TS 23.003定义了号码、地址和标识，例如NSSF的FQDN（完全限定域名）构造规则就在其中。HTTP/2和JSON则是SBA通信的底层承载协议和数据格式。 |

| 安全与流程协议 | 3GPP TS 33.501
3GPP TS 24.501
3GPP TS 38.413 | 33.501定义了5G系统的安全架构，包括NF间的认证授权机制。24.501是UE与AMF间的NAS层协议，UE请求的切片信息正是通过NAS消息传递给AMF的。38.413是NG-RAN的NGAP协议，涉及RAN与AMF的交互。 |

场景关联：当开发团队在实现NSSF接口时，读到请求参数中有一个Tai字段。他们不清楚Tai这个数据结构具体包含哪些内容（比如PLMN ID, TAC），格式是什么。此时，他们就应该查阅第二章，找到定义通用数据类型的规范是TS 29.571，然后打开29.571，就能找到Tai类型的精确定义。这个“按图索骥”的过程，在实际开发中每天都在发生。

3. 定义与缩略语 (Definitions and abbreviations)：统一沟通的“行话”

第三章是规范中最简短但至关重要的部分之一。它确保了所有阅读、使用这份规范的人，对于关键术语的理解是完全一致的，避免因概念不清而导致的歧义。

3.1 定义 (Definitions)

规范原文引用 (Clause 3.1 Definitions):

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP TR 21.905.

这段话有两个要点：

  1. 默认词典：大部分术语的定义，请参考“新华字典”TR 21.905。

  2. 本地优先：如果本规范（TS 29.531）对某个术语有自己的定义，那么以本规范的定义为准。这体现了规范的特殊性优先于通用性。

在当前版本的TS 29.531中，3.1章节并未定义任何新的术语，表示所有术语都遵循通用定义。

3.2 缩略语 (Abbreviations)

规范原文引用 (Clause 3.2 Abbreviations):

…An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 3GPP TR 21.905.

NSAG Network Slice AS Group

与定义类似，缩略语也遵循“本地优先”原则。而在这里，规范明确定义了一个在本规范后续内容中会使用到的关键缩略语：NSAG。

  • NSAG (Network Slice AS Group): 网络切片AS组。

虽然规范在此只给出了全称，但这个概念对于理解高级的切片功能至关重要。NSAG到底是什么？

简单来说，它是一组S-NSSAI的集合。属于同一个NSAG的多个网络切片，共享相同的网络配置和行为。

深入解读NSAG：

NSAG的主要目的是为了支持网络切片和特定接入方式的关联，以及确保业务的连续性。例如，一个运营商可能定义了一个“企业办公NSAG”，其中包含了一个用于3GPP接入（如5G蜂窝）的S-NSSAI和一个用于非3GPP接入（如企业Wi-Fi）的S-NSSAI。

场景关联：小杰在公司办公。他的笔记本电脑同时连接了公司的5G CPE和内部Wi-Fi。他正在使用一个需要稳定连接到公司内网的远程桌面应用。

  1. 这个远程桌面应用被运营商策略定义为属于“企业办公NSAG”。

  2. 当小杰的笔记本通过5G CPE接入时，NSSF会授权与该NSAG关联的3GPP S-NSSAI。

  3. 当网络发生切换，笔记本无缝切换到公司Wi-Fi接入时，系统（通过N3IWF/TNGF）知道这也是属于同一个NSAG的业务，会使用与该NSAG关联的非3GPP S-NSSAI，并且可能会选择同一个SMF和UPF（数据面锚点）。

  4. 由于锚点不变，小杰的远程桌面连接不会中断，实现了跨接入方式的无缝业务连续性。

NSSF在处理Configured NSSAI时，需要理解和处理NSAG的信息，以确保在不同接入网络下的策略一致性。这个在第6章的数据模型NsagInfo中会有更详细的体现。

本章小结

通过对TS 29.531前三个章节的精读，我们为后续的探索之旅打下了坚实的基础。我们不仅明确了这份规范的“权责边界”，还绘制出了一幅清晰的知识依赖图谱，并掌握了沟通所需的核心“行话”。

| 章节 | 核心目的 | 关键信息点 | 对工程师的价值 |

| :--- | :--- | :--- | :--- |

| 1. Scope | 界定规范做什么 | Stage 3规范；定义Nnssf SBI的协议、数据模型和API；依赖于23.501, 23.502, 29.500, 29.501。 | 明确开发任务的边界，理解技术方案的上下文和顶层设计来源。 |

| 2. References | 提供知识索引 | 列出了所有被引用的规范，是解决具体技术疑问的“导航图”。 | 快速定位特定概念（如数据类型、安全机制、底层协议）的权威定义。 |

| 3. Definitions & Abbreviations | 统一术语 | 遵循TR 21.905，但本地定义优先；引入了关键缩略语NSAG。 | 确保团队成员和不同厂商之间对技术术语有统一、无歧义的理解。 |

现在，我们的“地图”和“指南针”已经准备就绪。在下一篇文章中，我们将正式进入规范的核心腹地——第4章“Overview”和第5章“Services offered by the NSSF”，开始详细拆解NSSF的架构图、两大核心服务以及它们背后的详细操作流程。

FAQ环节

Q1：为什么3GPP要将规范分为Stage 1, 2, 3三个阶段？直接写一份大而全的规范不是更简单吗？

A1：分阶段是现代大型复杂系统工程的标准化做法，好处巨大。直接写一份大而全的规范会导致混乱和低效。分阶段的优势在于：

  1. 关注点分离 (Separation of Concerns)：让不同领域的专家可以专注于自己擅长的工作。业务专家负责Stage 1，架构师负责Stage 2，协议和软件专家负责Stage 3。

  2. 并行工作：在Stage 2架构稳定后，多个Stage 3的协议可以并行开发，加快了标准化进程。

  3. 模块化和灵活性：当底层技术（如传输协议）需要升级时，可能只需要修改Stage 3规范，而Stage 1和Stage 2的架构和需求可以保持不变，增强了系统的演进能力。

  4. 清晰的逻辑层次：从需求到架构再到实现，逻辑层次非常清晰，便于学习、理解和排查问题。

Q2：在阅读TS 29.531时，我应该以什么样的顺序去阅读这些参考文献？

A2：对于初学者，建议的“最小知识集”阅读顺序是：

  1. 先理解架构：快速浏览 TS 23.501 的相关章节，了解NSSF是什么，在5GC架构图的哪个位置。

  2. 再看核心流程：阅读 TS 23.502 中关于“Registration Management”和“Session Management”中涉及网络切片选择的流程图和步骤描述。

  3. 掌握SBA通用规则：大致了解 TS 29.500 的内容，知道所有SBI接口共用的HTTP方法、状态码、错误处理等。

  4. 最后精读本规范：有了以上基础，再回过头来精读 TS 29.531，你就会发现所有API和数据模型的设计都是“事出有因”的。遇到不清楚的数据类型，再去查阅 TS 29.571。

Q3：什么是服务化接口（Service Based Interface, SBI）？它和传统网元间的接口有什么不同？

A3：SBI是5G核心网采用的服务化架构（SBA）的产物。与传统的点对点、基于特定协议（如Diameter, GTP-C）的接口不同，SBI具有以下特点：

  • 服务化：NF（如NSSF）以“服务提供者”的身份，对外暴露一组定义清晰的服务（如Nnssf_NSSelection）。其他NF作为“服务消费者”来调用这些服务。

  • 协议统一：所有SBI都基于统一的应用层协议栈，即HTTP/2 over TCP/IP，数据格式为JSON。这大大降低了协议的复杂性。

  • 解耦与发现：服务消费者不需要硬编码服务提供者的地址。它通过向NRF查询服务名称来动态发现可用的服务实例，实现了高度的解耦和灵活性。

Q4：规范中提到TS 29.531的OpenAPI文件可以在GitLab上找到，这对于开发者意味着什么？

A4：这意味着巨大的便利性和开发效率的提升。OpenAPI（曾用名Swagger）是一种API的标准化描述语言。开发者可以利用这份YAML格式的API定义文件：

  1. 自动生成代码：使用OpenAPI生成器，可以自动生成客户端和服务端的大部分骨架代码（包括数据结构、请求/响应处理框架），极大减少了手动编码的工作量和出错率。

  2. 生成API文档：可以自动生成交互式的、人类可读的API文档，非常清晰。

  3. 模拟和测试：可以轻松地创建API的模拟服务器（Mock Server）进行前端或客户端的并行开发和测试，而无需等待后端服务完全实现。

Q5：既然TS 29.531只定义接口，那么NSSF内部如何决策（比如如何判断切片负载）是由谁决定的？

A5：这是一个非常好的问题，点明了标准化的边界。TS 29.531只定义了NSSF的“输入”（收到的请求参数）和“输出”（返回的响应）。至于NSSF内部的“处理逻辑”，即决策算法，3GPP标准并未作强制规定，这部分留给了设备制造商作为实现差异化和竞争优势的空间。例如，一个基础的NSSF可能只根据签约和位置来决策；而一个更智能的NSSF，则可能像规范中提到的，会主动与NWDAF交互，引入切片实例的实时负载、预测性分析等高级数据，从而做出更加优化和智能的切片选择。

关系图谱