51学通信

深度解析 3GPP TS 29.531：5.2 Nnssf_NSSelection Service (网络切片选择服务)

23分钟阅读

深度解析 3GPP TS 29.531：5.2 Nnssf_NSSelection Service (网络切片选择服务)

本文技术原理深度参考了3GPP TS 29.531 V18.8.0 (2024-09) Release 18规范中，关于“Chapter 5.2 Nnssf_NSSelection Service”的核心章节。本文将深入剖析NSSF最核心的“按需查询”服务，通过多个具体场景，详解其唯一的服务操作GET是如何支撑5G网络中多种关键流程的。

在前面的文章中，我们已经了解了NSSF的宏观架构和它的两大服务“菜单”：Nnssf_NSSelection（按需查询）和 Nnssf_NSSAIAvailability（订阅通知）。从本文开始，我们将走进第一间“功能大厅”，对Nnssf_NSSelection服务进行一次彻底的探索。

这项服务是NSSF存在的基石，它响应来自AMF、SMF等网络功能的实时请求，为每一个需要接入网络切片的“会话”或“用户”提供权威、精准的决策。它是典型的“拉模式”（Pull Model），只有当客户（NF消费者）上门询问时，NSSF才会提供服务。

为了让整个过程更加具象化，我们的老朋友，5G发烧友“小杰”，将迎来新的挑战。他所在的公司正在一个新型智慧工业园区部署业务，小杰带来了一台专为工业场景设计的5G加固平板电脑，我们称之为“智勘-T1”。今天，我们将跟随小杰，通过“智勘-T1”的首次开机、运行专有应用、优化网络连接等一系列操作，来揭示Nnssf_NSSelection服务在幕后所扮演的关键角色。

1. 服务描述 (Clause 5.2.1 Service Description)：NSSF的核心职责清单

在深入具体操作之前，规范首先用5.2.1章节概括了Nnssf_NSSelection服务的核心能力。这相当于这家“问询处”门口挂着的“业务范围”告示牌。

规范原文引用 (Clause 5.2.1 Service Description):

The Nnssf_NSSelection service is used by an NF Service Consumer (e.g. AMF, SMF, NWDAF or NSSF in a different PLMN) to retrieve the information related to network slice in the non-roaming and roaming case.

It also enables the NSSF to provide to the AMF the Allowed NSSAI and the Configured NSSAI for the Serving PLMN.

It also enables the NSSF to provide to the AMF the NSAG information associated with the Configured NSSAI for the Serving PLMN.

It also enables the NSSF to provide to the SMF+PGW-C the mapping of S-NSSAI(s) of the VPLMN to corresponding HPLMN S-NSSAI(s).

It also enables the NSSF to provide to the NWDAF the NSI ID(s) associated with the requested S-NSSAI.

这段描述非常精炼，我们可以将其拆解为NSSF在此服务下的几大核心职责：

职责服务对象场景解读
提供授权与配置切片AMFUE注册、移动性管理、UE配置更新这是最核心的职责。NSSF告诉AMF，根据用户签约、当前位置和网络策略，最终允许（Allowed）UE使用哪些切片；或者在UE无明确请求时，为其配置（Configured）默认的切片。
提供NSAG信息AMFUE支持NSAG的场景如果UE支持网络切片AS组（NSAG），NSSF会提供与配置切片相关联的NSAG信息，以确保跨不同接入方式（如5G和Wi-Fi）的业务连续性。
提供切片映射信息SMF+PGW-C, vNSSF漫游、4G/5G互通在漫游时，需要将拜访地网络（VPLMN）的切片ID映射到归属地网络（HPLMN）的切片ID。NSSF负责提供这种权威的映射关系。
提供切片实例IDNWDAF网络数据分析当NWDAF需要对某个特定的网络切片（S-NSSAI）进行负载分析时，它可能不知道这个逻辑切片背后具体由哪些物理的切片实例（NSI ID）承载。NSSF可以提供这种从S-NSSAI到NSI ID的映射。

这些职责覆盖了从普通用户接入到漫游互通，再到网络智能分析的方方面面，充分体现了NSSF作为切片信息中心的地位。

2. 服务操作 (Clause 5.2.2 Service Operations)：大道至简，唯有GET

与Nnssf_NSSAIAvailability服务包含多种操作（增、删、改、查、通知）不同，Nnssf_NSSelection服务的设计哲学是“大道至简”。

规范原文引用 (Clause 5.2.2.1 Introduction):

For the Nnssf_NSSelection service the following service operations are defined:

  • Get.

是的，你没看错，整个服务只定义了一个操作：GET。

这意味着所有与网络切片选择相关的查询，无论发起者是谁（AMF, SMF, …），无论场景是什么（注册、PDU建立、漫游…），最终都统一为向NSSF的一个特定资源URI发送一个HTTP GET请求。

这种设计的精妙之处在于：

  • 统一入口: 简化了接口设计和实现，所有查询逻辑都汇聚到一个入口。
  • 灵活性: 通过在GET请求中使用不同的**查询参数（Query Parameters）**来区分不同的场景和需求。NSSF的“智能”就体现在它如何解析这些纷繁复杂的查询参数，并给出相应的决策。

接下来，我们将通过“智勘-T1”的系列操作，详细拆解这个看似简单的GET请求在不同场景下的“七十二变”。

3. GET操作的“七十二变”：不同场景下的精确实践

3.1 场景一：“智勘-T1”首次开机注册 (Clause 5.2.2.2.2)

小杰在智慧工业园区，第一次按下了“智勘-T1”的开机按钮。平板电脑启动后，开始向园区内的5G网络发起**初始注册（Initial Registration）**流程。这是Nnssf_NSSelection_Get服务最经典的用例。

信令流程图重绘与解读 (Figure 5.2.2.2.2-1: Retrieve the network slice information during the mobility procedure)

实体 (Entity)实体 (Entity)
NF Service Consumer (e.g. AMF)NSSF
1. GET …/network-slice-information?
--------------------------------------------------------⇒
2a. 200 OK (AuthorizedNetworkSliceInfo)
⇐--------------------------------------------------------
2b. 403 Forbidden (ProblemDetails)
⇐--------------------------------------------------------
Or 4xx/5xx (ProblemDetails) Or 3xx
⇐--------------------------------------------------------

这个流程非常直观，我们来聚焦于其中的细节。

步骤 1: AMF发起GET请求

当AMF收到“智勘-T1”的注册请求后，它会精心构造一个HTTP GET请求发送给NSSF。这个请求的查询参数中，会包含一个名为slice-info-request-for-registration的复杂结构体。

规范原文引用 (describing parameters for registration):

If the AMF wants to retrieve the slice selection information, one or more of the following parameters shall be included in the slice-info-request-for-registration query parameter:

  • Requested NSSAI and Subscribed S-NSSAI(s) with the indication if marked as default S-NSSAI…
  • optionally UE support of subscription-based restrictions to simultaneous registration of network slice feature Indication;
  • …
  • Indication of the support of NSAG by the UE.

In both scenarios, the AMF shall also include the following parameters in the message:

  • PLMN ID of the SUPI in roaming scenarios;
  • TAI;
  • NF type of the NF service consumer and;
  • Requester ID.

请求参数深度解析:

参数解释“智勘-T1”场景下的值 (示例)
nf-type, nf-id表明请求者身份AMF, amf-instance-01
slice-info-request-for-registration包含注册所需切片信息的结构体核心内容:
içinde Requested NSSAI“智勘-T1”希望使用的切片列表[ {SST:1, SD:10}, {SST:2, SD:20} ] (一个eMBB切片和一个URLLC切片)
içinde Subscribed S-NSSAIs从UDM获取的该终端签约的切片列表[ {SST:1, SD:10, default:true}, {SST:2, SD:20}, {SST:3, SD:30} ]
tai终端当前所在的跟踪区标识PLMN-ID:XXX, TAC:YYY (智慧工业园区的TAI)

步骤 2a: NSSF成功响应 (200 OK)

NSSF收到请求后，开始其内部复杂的决策逻辑：

  1. 核对Requested NSSAI与Subscribed S-NSSAIs，剔除所有未签约的请求。
  2. 检查剩余的S-NSSAI在当前TAI下是否可用。
  3. 应用网络策略（比如，URLLC切片只在工作时间对普通员工开放）。
  4. （可选）查询NWDAF，检查切片实例负载。

决策完成后，NSSF返回200 OK响应，其消息体是AuthorizedNetworkSliceInfo。

规范原文引用 (describing the successful response):

On success, “200 OK” shall be returned…, the response body shall include a content containing at least the following parameters:

  • Allowed NSSAI and;
  • target AMF Set or the list of candidate AMF(s).

对于“智勘-T1”的场景，响应可能包含：

  • allowedNssaiList: [ {allowedSnssai: {SST:1, SD:10}}, {allowedSnssai: {SST:2, SD:20}} ] (假设两个请求的切片都通过了验证)
  • rejectedNssaiInTa: [] (没有在当前TA被拒绝的切片)

AMF收到这个响应后，就知道了“智勘-T1”被允许使用这两个切片，并完成后续的注册流程。

步骤 2b: NSSF拒绝请求 (403 Forbidden)

如果“智勘-T1”请求的切片在当前园区都不可用或未签约，NSSF会返回403 Forbidden。

规范原文引用 (describing the failure response):

If no slice instances can be found for the requested slice selection information…, then the NSSF shall return a 403 Forbidden response with the “ProblemDetails” IE containing the Application Error “SNSSAI_NOT_SUPPORTED”.

响应体中的ProblemDetails会明确指出失败原因为SNSSAI_NOT_SUPPORTED，帮助AMF进行后续处理（例如，只为UE注册到网络，但不分配任何切片，或者只分配默认切片）。

3.2 场景二：启动高精度无人机控制应用 (Clause 5.2.2.2.3)

注册成功后，小杰在“智勘-T1”上打开了一款用于控制勘测无人机的App。这款App需要建立一个专用的PDU会话，以保证控制信令的低时延和图传数据的高带宽。这触发了**PDU会话建立（PDU Session Establishment）**流程。

信令流程图重绘与解读 (Figure 5.2.2.2.3-1: Retrieve the network slice information during the PDU session establishment procedure) (流程图与场景一类似，但请求和响应的关注点不同)

实体 (Entity)实体 (Entity)
NF Service Consumer (e.g. AMF)NSSF
1. GET …/network-slice-information?
--------------------------------------------------------⇒
2a. 200 OK (AuthorizedNetworkSliceInfo)
⇐--------------------------------------------------------

步骤 1: AMF为PDU会话发起GET请求

这次，AMF发起的GET请求的查询参数中，会包含S-NSSAI，明确指出是为哪个切片请求建立会话。

规范原文引用 (describing parameters for PDU session):

The request shall include query parameters, contain at least the following parameters:

  • S-NSSAI;
  • …
  • the NF type of the NF service consumer;
  • Requester ID and;
  • non-roaming/LBO roaming/HR roaming indication.

请求参数深度解析:

参数解释“无人机App”场景下的值 (示例)
S-NSSAI明确为哪个切片建立会话{SST:2, SD:20} (URLLC切片)
roaming-indication漫游指示NON_ROAMING
tai当前位置PLMN-ID:XXX, TAC:YYY

步骤 2a: NSSF成功响应 (200 OK)

此时NSSF的响应，其关注点不再是Allowed NSSAI列表，而是为了帮助AMF找到正确的SMF来处理这个PDU会话。

规范原文引用 (describing the successful response):

On success, “200 OK” shall be returned…, the response body shall include a content containing at least the NRF to be used to select NFs/services within the selected Network Slice instance;

响应的AuthorizedNetworkSliceInfo消息体中，将包含一个至关重要的信息：nsiInformation。

  • nsiInformation:
    • nrfId: NSSF会告诉AMF，“要找处理这个URLLC切片的SMF，你应该去问这个指定的NRF”。这实现了切片和NRF的关联，使得不同切片可以由不同的资源池（和不同的NRF）来管理。
    • nsiId (optional): NSSF还可能直接告诉AMF，这个S-NSSAI当前由哪个网络切片实例（NSI ID）承载。

AMF拿到这个“指路信息”后，就会去指定的NRF查询支持{SST:2, SD:20}这个S-NSSAI的SMF实例，从而为无人机App建立起专用的PDU会话。

3.3 场景三：网络优化，切换到专用频段 (Clause 5.2.2.2.4)

无人机起飞后，网络监测系统发现小杰的控制业务非常关键。为了避免干扰，网络决定将“智勘-T1”从公共频段切换到为URLLC业务预留的专用毫米波频段。这个过程需要通过**UE配置更新（UE Configuration Update）**流程来完成。AMF需要命令UE切换网络配置，而这个决策需要NSSF的参与。

信令流程图重绘与解读 (Figure 5.2.2.2.4-1: Retrieve the network slice information during UE configuration update procedure) (流程图同上，核心差异仍在参数)

步骤 1: AMF为配置更新发起GET请求

规范原文引用 (describing parameters for UE config update):

The request shall include query parameters:

  • Subscribed S-NSSAI(s)…
  • Rejected S-NSSAI(s) for the Registration Area;
  • PLMN ID of the SUPI;
  • TAI;
  • … NOTE: … The AMF does not include the Requested NSSAI to the NSSF in this procedure…

一个非常重要的细节是，规范的NOTE中明确指出，在这种流程下，AMF 不会 包含Requested NSSAI。AMF只是把当前的情况（签约的、已允许的、已拒绝的）告诉NSSF，让NSSF来决策下一步该怎么办。

步骤 2a: NSSF成功响应 (200 OK)

NSSF的响应中，除了更新Allowed NSSAI和Configured NSSAI外，可能会包含一个特殊的参数：Target NSSAI。

规范原文引用 (describing the successful response):

On success, “200 OK” shall be returned…, the response body shall include a content containing at least the following parameters:

  • Allowed NSSAI;
  • Configured NSSAI and;
  • optionally Target NSSAI.
  • Target NSSAI: 这个参数包含了NSSF为UE选择的目标S-NSSAI，这些S-NSSAI与专用的频段相关联。AMF收到Target NSSAI后，就会在给UE的配置更新命令中包含这个信息，指示UE去新的频段上重新选择和接入网络。

这个场景体现了NSSF在网络动态资源调配和优化中的高级功能。

4. 总结：Nnssf_NSSelection 服务的力量

通过对规范5.2章节的深度剖析和三个核心场景的演绎，我们可以深刻体会到Nnssf_NSSelection服务虽然只有一个GET操作，但其强大之处在于其灵活性和情景感知能力。

场景核心流程GET请求关键参数NSSF响应核心产出
首次开机Initial Registrationslice-info-request-for-registration (包含Requested & Subscribed NSSAI), TAIAllowed NSSAI (授权切片列表)
启动AppPDU Session EstablishmentS-NSSAI (为哪个切片建会话)nsiInformation (包含NRF地址，用于SMF发现)
网络优化UE Configuration UpdateSubscribed NSSAI, Rejected S-NSSAI (不含Requested NSSAI)Target NSSAI (用于频段重定向)

Nnssf_NSSelection服务是5G网络实现差异化、按需服务承诺的基石。它确保了每一次网络接入、每一次业务请求，都能在NSSF这位“总舵主”的集中决策下，被精确地引导到最合适的虚拟网络资源上。它不仅仅是一个简单的查询服务，更是一个融合了用户签约、位置、网络策略、实时状态乃至运营商策略的智能决策引擎。

在下一篇文章中，我们将继续探索NSSF的另一面——Nnssf_NSSAIAvailability服务，看看NSSF是如何从一个被动的“问询处”，变身为一个主动的“新闻台”，为网络带来更强的动态适应能力的。

FAQ环节

Q1：GET请求中的slice-info-request-for-registration和slice-info-request-for-pdu-session这两个参数可以同时出现吗？

A1：不可以。这两个参数分别对应于完全不同的业务流程。slice-info-request-for-registration用于UE级的移动性管理流程（如注册、TAU），其目的是为UE确定一组可用的网络切片。而slice-info-request-for-pdu-session（在后续版本中，其信息被更通用的参数如S-NSSAI等替代）用于会话管理流程，其目的是为一个特定的PDU会话获取切片内部的资源信息（如用于SMF发现的NRF）。一个GET请求只会出现在一个特定的流程中，因此只会携带与该流程对应的查询参数。

Q2：Target NSSAI和Allowed NSSAI有什么本质区别？

A2：Allowed NSSAI是NSSF告诉AMF，“在当前的网络状态和接入点下，我批准UE使用这些切片”。它描述的是当前状态下的许可。而Target NSSAI是NSSF告诉AMF，“我建议你引导UE去另一个地方（比如另一个频段或TA），在那个目标状态下，UE应该使用这些切片”。它描述的是一个未来状态的引导。Target NSSAI是实现网络主动、动态地重定向和优化UE接入策略的关键机制。

Q3：如果小杰漫游到园区外，Nnssf_NSSelection服务流程会有什么不同？

A3：流程会变得更复杂，涉及到vNSSF和hNSSF的交互。

  1. 小杰的UE向拜访地网络（VPLMN）的AMF发起注册。
  2. VPLMN的AMF向本地的NSSF（即vNSSF）发起GET请求。
  3. vNSSF发现这是个漫游用户，它自己无法决策。于是，vNSSF会扮演一个NF消费者的角色，向小杰归属地网络（HPLMN）的NSSF（即hNSSF）发起一次Nnssf_NSSelection GET请求，请求中会带上小杰的SUPI和VPLMN支持的切片列表。
  4. hNSSF根据小杰的签约数据，返回他在HPLMN中允许使用的切片。
  5. vNSSF收到hNSSF的响应后，执行一个关键的映射（Mapping）过程，将HPLMN的S-NSSAI翻译成VPLMN中等效的S-NSSAI。
  6. 最后，vNSSF将映射后的Allowed NSSAI以及原始的映射关系mappingOfNssai一并返回给VPLMN的AMF。

Q4：NSSF的决策是实时的吗？它需要从哪里获取所有决策所需的信息？

A4：是的，NSSF的决策是实时的，针对每一次GET请求。它的信息来源是多方面的：

  • 来自NF消费者的请求: GET请求本身就包含了大量上下文信息，如UE ID, TAI, Requested NSSAI等。
  • 本地配置/策略: 运营商会为NSSF配置大量的静态和半静态策略，如哪些S-NSSAI在哪些区域受限，漫游协议等。
  • UDM (via AMF): 用户的签约切片信息（Subscribed S-NSSAI）由UDM存储，AMF在请求NSSF之前会从UDM获取，并包含在给NSSF的请求中。
  • AMF (via Nnssf_NSSAIAvailability): NSSF通过Nnssf_NSSAIAvailability服务，从各个AMF处汇聚了全网TA支持的S-NSSAI信息。
  • NWDAF: 对于更智能的决策，NSSF可以从NWDAF获取切片实例的实时负载等分析数据。

Q5：为什么在UE配置更新流程中，AMF不能发送Requested NSSAI？

A5：这是由该流程的本质决定的。UE配置更新流程通常由网络侧发起，目的是对UE的行为进行调整或优化，而不是响应UE的新请求。在这种情况下，AMF不是在替UE“传话”，而是在向NSSF“征求意见”。AMF向NSSF呈现的是当前UE的完整上下文（它签约了什么、已经被允许了什么、在当前RA被拒绝了什么），然后问NSSF：“基于现状，下一步最优的策略是什么？是否需要进行重定向？” 如果AMF发送了Requested NSSAI，就会将流程的性质混淆为一次新的用户请求，这不符合流程设计的初衷。

关系图谱