5G网络切片NSSF选择机制与S-NSSAI映射信令全链拆解

网络切片是5G区别于4G的核心架构能力之一。它让一张物理网络能够同时为eMBB、URLLC、MIoT等差异化业务提供逻辑隔离的"专网"。然而，UE开机后如何知道自己能用哪些切片？网络如何把"用户想用的切片"映射到"实际部署的切片实例"？这套判定逻辑并不在UE，也不完全在AMF，而是由一个常常被忽视的功能实体——NSSF（Network Slice Selection Function，网络切片选择功能）——在注册流程的关键节点上一锤定音。

本文聚焦 TS 23.501 §5.15（网络切片总体）、TS 23.502 §4.2.2.2（注册流程中的切片选择） 与 TS 29.531（NSSF服务化接口 Stage 3），逐条拆解 NSSF 的两个服务、S-NSSAI 到 NSI-ID 的映射规则、Allowed NSSAI 的授权算法，以及切片选择与 AMF 重分配之间的耦合关系。

一、切片选择要解决的根本问题

在4G/EPC中，UE通过 APN 区分业务网络，PGW 选择主要靠 DNS。5G切片把这种"按业务选网络"的能力提到了更高的抽象层：一个切片由 S-NSSAI 唯一标识，并对应一组专属的 AMF、SMF、UPF 实例（即 NSI，Network Slice Instance）。问题由此产生：

1. UE 不知道全网部署了哪些切片，只能基于订阅和配置"请求"自己想用的切片；
2. 一个 S-NSSAI 在网络侧可能对应多个 NSI（同一切片多实例部署，用于容量或地域隔离），需要把请求映射到具体实例；
3. 当前 AMF 可能并不支持 UE 想要的切片，需要重新选择一个合适的 AMF Set。

这三个问题分别对应 NSSF 的三类输出：Allowed NSSAI（授权的切片集）、S-NSSAI→NSI-ID 映射（实例定位）、目标 AMF Set / NRF（功能体重定向）。

S-NSSAI 的比特级结构

一个 NSSAI 是至多 8 个 S-NSSAI 的集合。SST 决定"用什么类型的网络"，SD 决定"具体哪一张"。例如 SST=2, SD=0x010203 表示某个客户的 URLLC 切片。

二、五种 NSSAI 的语义与生命周期

这是最容易混淆的概念群，也是抓包时最先要分辨的。TS 23.501 §5.15.2 给出了它们的精确定义：

下方的状态图刻画了一个 S-NSSAI 从"被请求"到"被授权"再到"被拒绝"的完整生命周期：

stateDiagram-v2
    [*] --> 未配置: UE 开机
    未配置 --> 已配置: Reg Accept / UE Configuration Update<br/>下发 Configured NSSAI
    已配置 --> 已请求: 下次注册携带 Requested NSSAI
    已请求 --> 已授权: AMF 查询 NSSF 判定通过<br/>下发 Allowed NSSAI
    已授权 --> 已拒绝: 当前 TA 内切片不可用<br/>下发 Rejected NSSAI
    已拒绝 --> 已请求: 移动到支持区域 / 重新注册
    已授权 --> [*]: 去注册

三、注册流程中的切片选择信令全链

切片选择不是一个独立流程，而是嵌在 Registration（TS 23.502 §4.2.2.2） 中的判定环节。其完整时序如下：

sequenceDiagram
    participant UE
    participant RAN as NG-RAN
    participant IAMF as 初始 AMF
    participant UDM
    participant NSSF
    participant NRF
    participant TAMF as 目标 AMF

    UE->>RAN: NAS Reg Request (Requested NSSAI)
    Note over RAN: RAN 切片路由:<br/>按 Requested NSSAI / Default<br/>Configured NSSAI 选初始 AMF
    RAN->>IAMF: NGAP Initial UE Message<br/>(NAS: Reg Request, UserLocationInfo)
    IAMF->>UDM: Nudm_SDM_Get (SUPI)<br/>获取 Subscribed S-NSSAIs
    UDM-->>IAMF: 订阅的 S-NSSAI 列表 + 缺省切片
    alt 初始 AMF 可独立判定
        Note over IAMF: Allowed NSSAI =<br/>Requested ∩ Subscribed ∩ 当前TA可用
    else 需要 NSSF 协助
        IAMF->>NSSF: Nnssf_NSSelection_NSSelectionAvailabilityGet<br/>(Subscribed, Requested, TAI, PLMN, default)
        Note over NSSF: 切片选择算法:<br/>1. 算出 Allowed NSSAI<br/>2. 映射 S-NSSAI → NSI-ID<br/>3. 确定目标 AMF Set + NRF
        NSSF-->>IAMF: Allowed NSSAI, NSI 映射,<br/>TargetAmfSet, CandidateAmfList, NrfId
    end
    alt 初始 AMF 即可服务
        IAMF-->>UE: NAS Reg Accept (Allowed NSSAI)
    else 触发 AMF 重分配
        IAMF->>NRF: Nnrf_NFDiscovery (在 Target AMF Set 内)
        NRF-->>IAMF: 选定目标 AMF
        IAMF->>RAN: NGAP Reroute NAS Request<br/>(Target AMF Id, 原始 NAS 消息)
        RAN->>TAMF: NGAP Initial UE Message (重路由 NAS)
        TAMF-->>UE: NAS Reg Accept (Allowed NSSAI)
    end

关键判定节点解析

节点1：NG-RAN 的切片路由（TS 23.501 §6.3.6 / TS 38.413）。 RAN 收到 Reg Request 时，若携带 Requested NSSAI，则优先按其中的 S-NSSAI 选择能支持该切片的 AMF；若无，则按 Default Configured NSSAI 选默认 AMF。RAN 并不做"授权"，只做"路由"。这就是为什么 RAN 不查询 NSSF——它只需要足够的信息把消息送到一个"大概率能处理"的 AMF。

节点2：AMF 的本地判定 vs. NSSF 查询。 AMF 拿到 Subscribed S-NSSAIs 后，可以自行计算 Allowed = Requested ∩ Subscribed ∩ 当前TA可用。但必须查询 NSSF 的典型场景包括：

• Requested NSSAI 中存在 AMF 不确知是否部署的切片；
• 网络策略要求由 NSSF 统一管控 NSI-ID 映射；
• 需要触发 AMF 重分配（当前 AMF 不支持目标切片）。

节点3：Reroute NAS。 这是 NGAP 中一个专为切片而生的消息（TS 38.413）。初始 AMF 通过它把原始 NAS 消息 + 目标 AMF 标识原路退回 RAN，RAN 再以一条新的 Initial UE Message 转发给目标 AMF。整个过程对 UE 透明——UE 只发了一次 Reg Request，却"换了"AMF。

注意：本节聚焦 NSSF 的切片选择逻辑本身；AMF 重分配的完整步骤（含 UE Context 协商）属于另一专题，此处仅作为切片选择的"下游后果"出现。

四、NSSF 的两个服务（TS 29.531 深拆）

NSSF 通过 SBI 暴露 两个服务，职责清晰分离：

4.1 Nnssf_NSSelection —— 一次性切片决策

这是注册流程里 AMF 调用的核心。其响应体（OpenAPI 定义在 TS 29.531 §6.1.6 AuthorizedNetworkSliceInfo）结构如下：

graph TD
    A[Nnssf_NSSelection 响应<br/>AuthorizedNetworkSliceInfo] --> B[allowedNssai]
    A --> C[configuredNssai]
    A --> D[targetAmfSet]
    A --> E[nsiInformation 列表]
    A --> F[candidateAmfList]
    A --> G[nrfAmfSetId / nrfId]
    A --> H[rejectedNssaiInPlmn / rejectedNssaiInTa]

    B --> B1[每个元素: snssai + mappingInd?]
    D --> D1[amfSetId + supportedNssai]
    E --> E1[nsiId + nrfId + nsiName]

• allowedNssai：本接入类型下授权的 S-NSSAI 列表，AMF 必须原样写入 Reg Accept；
• nsiInformation：S-NSSAI → NSI-ID 映射，这是"一个切片对应多个实例"问题的答案。同一切片可挂多个 NSI（容量/地域冗余），PDU 会话建立时 SMF 据此选择 UPF 锚点；
• targetAmfSet + candidateAmfList + nrfAmfSetId：当需要 AMF 重分配时，NSSF 指定目标 AMF Set 及该 Set 内发现 AMF 的 NRF，AMF 再用 NRF 选定具体 AMF；
• rejectedNssaiInPlmn / rejectedNssaiInTa：明确告知哪些切片"全网不支持"或"当前 TA 不支持"，分别对应不同拒绝粒度。

4.2 Nnssf_NSSAIAvailability —— TA 级可用性管理

这个服务常被忽略，却是运维切片的关键。它的本质是维护一张"TA → 可用 S-NSSAI"的动态表，并支持订阅/通知：

• Update：AMF 在配置或变更某 TA 的切片可用性时，把新的映射写入 NSSF；
• Subscribe/Notify：AMF（或 OAM 代理）订阅变更，当某 TA 新增/移除切片部署时，NSSF 主动 Notify，AMF 据此刷新本地的 Allowed NSSAI 判定基线，避免每次注册都重算。

这意味着切片的部署与回收是可热更新的：新增一个 URLLC 切片实例后，OAM 通知 NSSF 更新可用性，AMF 收到 Notify，后续该 TA 内的 UE 注册即可命中新切片，无需 AMF 重启或重新下发配置。

五、切片选择算法的设计意图

为什么要把这套逻辑独立成 NSSF，而不是塞进 AMF？三点设计权衡：

1. 策略集中化。一个运营商可能部署数十个切片、上千个 TA，"哪个 TA 支持哪些切片、哪些客户优先"是高度动态的运营策略。把它集中到 NSSF，AMF 保持"无状态的业务执行者"角色，便于横向扩展和策略统一变更。

2. NSI 映射与接入网解耦。RAN 只认 S-NSSAI（粗粒度），而网络侧的 NSI-ID（细粒度实例）只有 NSSF 知道。这种分层让 RAN 切片路由保持简单，实例层面的负载均衡/重定位由核心网闭环。

3. AMF 池与切片正交。AMF Set 是基于地理/容量划分的，切片是基于业务的。二者正交导致"某 AMF Set 不支持某切片"是常态，必须由 NSSF 提供"目标 AMF Set"来打通重分配路径。NSSF 是这两个正交维度之间的适配器。

六、抓包识别与排错

抓包识别（HTTP/2 SBI）

在 NSSF 接口抓包中，切片选择体现为一条 HTTP GET：

GET /nnssf-nsselection/v1/nss-selections?
  nf-id=AMF-001&
  slice-info-request-for-registration={"requestedNssai":[...],"homePlmnId":...,"roamingIndication":...}&
  taai=...&
  nscai=1

响应为 200 OK + JSON AuthorizedNetworkSliceInfo。排错第一抓手就是看响应里的 allowedNssai 是否包含用户期望的 S-NSSAI，以及 rejectedNssaiInTa 是否把目标切片挡掉了。

在 NGAP 侧，关注 INITIAL UE MESSAGE 的 Allowed NSSAI（注册成功后 RAN↔AMF 协商用）与 REROUTE NAS REQUEST 的 AMF Set ID、Allowed NSSAI IE（TS 38.413 §9.3）。

常见故障点

R19 在此基础上增强了切片级 NSAG（Network Slice AS Group）与 RAN 侧切片感知移动性，但 NSSF 作为"切片决策中枢"的定位未变。

常见问题

Q1: AMF 什么时候必须查询 NSSF，什么时候可以跳过？ A: 当 AMF 已在本地持有有效的 TA→S-NSSAI 可用性信息、且 Requested NSSAI 全部在 Subscribed 且当前 TA 可用时，AMF 可自行计算 Allowed NSSAI 跳过 NSSF；只要任一条件不满足（如出现未知切片、需 AMF 重分配、需 NSI-ID 映射），就必须调用 Nnssf_NSSelection。

Q2: 一个 S-NSSAI 为什么会有多个 NSI-ID？ A: 同一切片业务类型（如某客户的 URLLC）可能因容量、地域隔离或冗余部署多个实例。NSSF 通过 nsiInformation 把同一 S-NSSAI 映射到多个 NSI-ID，SMF 在 PDU 会话建立时根据负载/位置选择具体实例对应的 UPF，实现切片内多实例的负载均衡与故障隔离。

Q3: Default Configured NSSAI 和 Configured NSSAI 有什么本质区别？ A: Default Configured NSSAI 是 UE 出厂/USIM 预置的、仅在 UE 未从网络获得任何配置时用于首次接入的兜底集合，不出现在空口信令；Configured NSSAI for Serving PLMN 是网络动态下发并按 PLMN 区分的，后续 UE 的 Requested NSSAI 必须是它的子集。

Q4: 漫游用户的切片选择有何不同？ A: 漫游时 UE 的 Home PLMN 订阅数据由 HPLMN 的 UDM 提供，但实际可用的切片由 VPLMN 决定。NSSF 会结合 HPLMN 下发的 Subscribed S-NSSAIs 与 VPLMN 的部署情况，返回受限的 Allowed NSSAI，并通过 roamingIndication 参数标识归属/拜访关系。

Q5: NSSF 故障会导致什么后果？ A: 若 NSSF 不可用，AMF 通常回退到本地缓存的可用性数据进行降级判定，可能导致部分切片无法授权（用户拿到错误的或空的 Allowed NSSAI）；若同时需要 AMF 重分配而 NSSF 不可用，则可能注册失败。因此 NSSF 通常部署为高可用集群，并依赖 NSSAIAvailability 的本地缓存做兜底。

参考来源

1. 3GPP TS 23.501 V19.x.x — System architecture for the 5G System, §5.15 Network slicing — 切片总体架构与 NSSAI 定义
2. 3GPP TS 23.502 V19.x.x — Procedures for the 5G System, §4.2.2.2 Registration — 注册流程中的切片选择与 AMF 重分配
3. 3GPP TS 29.531 V19.x.x — 5G System; Network Slice Selection Services; Stage 3 — NSSF 两个服务的 OpenAPI 与 IE 定义
4. 3GPP TS 38.413 V19.x.x — NG-RAN; NG Application Protocol (NGAP) — Initial UE Message / Reroute NAS Request 中的 NSSAI IE
5. ShareTechnote — 5G Network Slicing / NSSF — 切片选择流程的可视化解读

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。