5G核心网学习平台
网络切片 实践篇 #19

5GC实践篇之切片篇第9篇：AMF在注册过程中拒绝用户请求NSSAI中没有签约的S-NSSAI

《5G核心网原理与实践》实践篇 · 网络切片 网元功能

5GC实践篇之切片篇第9篇：AMF在注册过程中拒绝用户请求NSSAI中没有签约的S-NSSAI

作者：爱卫生

1 测试背景与用例简介

在前面的第6至第8篇中，我们用了三篇文章的篇幅，详细讨论了AMF/NSSF如何在不同条件下确定目标AMF与Allowed NSSAI。那些场景关注的是"正常流程"——网络如何为UE找到合适的切片并完成注册。

但从本篇开始，我们转向另一个重要维度：切片拒绝。当UE请求了未签约的S-NSSAI时，网络如何安全地拒绝这些请求，同时不影响已签约切片的正常服务？

本篇讨论的具体场景是：UE在注册过程中（Registration Request或Security Mode Complete消息中）携带了Requested NSSAI，其中包含了UE未在UDM签约的S-NSSAI。AMF从UDM获取签约数据后，发现Requested NSSAI中存在未签约的切片，将其从Allowed NSSAI中排除，并通过Registration Accept消息告知UE最终授权的切片集合。

这是一个在实际网络中经常遇到的场景。例如，某企业用户的UE中预配置了eMBB（SST=1）和URLLC（SST=2）两种切片的Configured NSSAI。但由于运营商套餐变更或企业策略调整，该用户的签约数据中已不包含URLLC切片。当UE开机注册时，仍然会请求URLLC切片（因为终端保存的Configured NSSAI尚未更新）。AMF需要识别出URLLC不在签约列表中，将其从Allowed NSSAI中排除。

理解切片拒绝机制对于保障网络安全和资源隔离至关重要。如果网络不加区分地接受UE的所有切片请求，可能导致未授权的资源访问和切片间干扰。

2 协议规范与关键技术

2.1 相关协议规范

本篇涉及的协议规范重点在于NAS层面的切片拒绝机制：

  • TS 23.501 第5.15节：定义了Allowed NSSAI的生成规则，明确指出Allowed NSSAI必须是Requested NSSAI与Subscribed NSSAI的交集。不在交集中的S-NSSAI不得出现在Allowed NSSAI中。

  • TS 23.502 第4.2.2.2.2节：注册流程中切片选择的完整描述，包括AMF处理未签约S-NSSAI的步骤。

  • TS 24.501 第5.4.4.2节：Registration Request消息中Requested NSSAI信元的编码格式。特别关注以下内容：

  • 当UE有有效安全上下文时，Requested NSSAI在Registration Request中加密传输；

  • 当UE没有有效安全上下文时，Requested NSSAI在Security Mode Complete消息中传输。

  • TS 24.501 第5.4.4.3节：Registration Accept消息中Allowed NSSAI信元的编码格式。

  • TS 29.503：UDM服务接口，Nudm_SDM_Get获取签约NSSAI。

2.2 安全上下文与Requested NSSAI的传输

本场景涉及一个重要的安全细节：Requested NSSAI的传输时机取决于UE是否有有效的安全上下文。

场景A：UE有正确的安全上下文

当UE保存了有效的5G安全上下文（例如，此前成功注册过）时：

  • UE在Registration Request消息中直接携带加密后的Requested NSSAI；

  • AMF在收到Registration Request后即可获取Requested NSSAI信息；

  • AMF在后续的切片选择过程中可以直接使用。

场景B：UE没有正确的安全上下文

当UE没有有效的5G安全上下文（例如，首次注册或安全上下文已过期）时：

  • UE在Registration Request消息中不携带Requested NSSAI；

  • UE在Security Mode Complete消息中携带Requested NSSAI（此时安全通道已建立）；

  • AMF需要在安全模式完成后才能获取Requested NSSAI，再执行切片选择。

这个区别在实际信令跟踪中非常重要。如果在Registration Request中看不到Requested NSSAI，不要急于下结论说UE没有请求切片——可能它藏在Security Mode Complete中。

2.3 Allowed NSSAI的生成规则

根据TS 23.501第5.15节，Allowed NSSAI的严格生成规则为：


Allowed NSSAI = Requested NSSAI INTERSECT Subscribed NSSAI INTERSECT Network Supported NSSAI

三个集合的交集。任何不在Subscribed NSSAI中的S-NSSAI，无论UE是否请求、网络是否支持，都不能出现在Allowed NSSAI中。

未被纳入Allowed NSSAI的S-NSSAI，AMF可以通过Rejected NSSAI信元（如果实现）告知UE哪些请求被拒绝了以及拒绝原因。

3 消息流程与详细解读

3.1 整体流程概览


sequenceDiagram

    participant UE

    participant RAN as NG-RAN

    participant AMF

    participant UDM

    UE->>RAN: RRC Setup + NAS Registration Request

    Note over UE,RAN: UE携带Requested NSSAI<br/>包含未签约的S-NSSAI

    RAN->>AMF: Initial UE Message(NAS Registration Request)

    alt UE有安全上下文

        Note over UE,AMF: Requested NSSAI在Registration Request中

    else UE无安全上下文

        AMF->>UE: Authentication Request/Security Mode Command

        UE->>AMF: Security Mode Complete(with Requested NSSAI)

        Note over UE,AMF: Requested NSSAI在Security Mode Complete中

    end

    AMF->>UDM: Nudm_SDM_Get(SUPI/NSSAI)

    Note over AMF,UDM: 获取UE签约切片数据

    UDM-->>AMF: Nudm_SDM_Get Response(Subscribed NSSAI)

    Note over AMF: 比对Requested NSSAI与Subscribed NSSAI<br/>排除未签约的S-NSSAI<br/>生成Allowed NSSAI

    AMF->>RAN: Initial Context Setup Request

    Note over AMF,RAN: 携带Allowed NSSAI<br/>仅包含已签约的S-NSSAI

    RAN->>UE: NAS Registration Accept(Allowed NSSAI)

    Note over RAN,UE: Allowed NSSAI中不包含<br/>未签约的S-NSSAI

    UE->>RAN: NAS Registration Complete

    RAN->>AMF: Initial Context Setup Response

3.2 流程详细解读

步骤1：UE发起注册请求并携带Requested NSSAI

UE开机发起Registration流程。在RRC建立完成后，UE通过NAS Registration Request消息发送注册请求。消息中携带的Requested NSSAI包含以下S-NSSAI：

  • SST=1（eMBB）——已签约

  • SST=2（URLLC）——未签约

  • SST=3（MIoT）——已签约

其中SST=2（URLLC）是UE请求但未在UDM签约的切片。UE之所以请求这个切片，可能是因为：

  • 终端中预配置了Configured NSSAI包含SST=2；

  • 或者用户手动配置了Requested NSSAI。

步骤2：Requested NSSAI的传输（安全上下文依赖）

如果UE有正确的安全上下文，Requested NSSAI在Registration Request消息中加密携带，AMF在收到消息后立即可以解析。

如果UE没有正确的安全上下文，则执行以下流程：

  1. AMF发起Authentication流程，完成UE与网络之间的双向鉴权；

  2. AMF发起Security Mode Command流程，建立NAS安全通道；

  3. UE在Security Mode Complete消息中携带Requested NSSAI；

  4. AMF在安全模式完成后获取Requested NSSAI。

步骤3：AMF向UDM获取签约数据

AMF收到Registration Request后（或在Security Mode Complete后），检查本地是否有该UE的签约上下文。如果没有，AMF向UDM发起Nudm_SDM_Get请求，获取UE签约的NSSAI数据。

步骤4：AMF比对Requested NSSAI与Subscribed NSSAI

AMF获取签约数据后，执行以下比对：

Requested NSSAI Subscribed NSSAI 结果
SST=1 (eMBB) SST=1 (eMBB) 匹配：纳入Allowed NSSAI
SST=2 (URLLC) - 不匹配：排除
SST=3 (MIoT) SST=3 (MIoT) 匹配：纳入Allowed NSSAI

AMF将SST=2从Allowed NSSAI中排除，因为它不在UE的签约数据中。

步骤5：AMF生成并发送Registration Accept

AMF通过Registration Accept消息将Allowed NSSAI下发给UE：


Allowed NSSAI:

  - S-NSSAI 1: SST=1 (eMBB)

  - S-NSSAI 2: SST=3 (MIoT)

注意：SST=2（URLLC）不在Allowed NSSAI中。UE收到Registration Accept后，应理解SST=2的切片请求被网络拒绝了。

UE回复Registration Complete消息，注册流程完成。

3.3 AMF切片验证决策流程


flowchart TD

    A[收到Requested NSSAI] --> B[向UDM获取签约数据]

    B --> C[获取Subscribed NSSAI]

    C --> D[逐个比对Requested NSSAI与Subscribed NSSAI]

    D --> E[Requested S-NSSAI在签约列表中]

    D --> F[Requested S-NSSAI不在签约列表中]

    E --> G[纳入Allowed NSSAI]

    F --> H[排除：不纳入Allowed NSSAI]

    G --> I[生成最终Allowed NSSAI]

    H --> I

    I --> J[通过Registration Accept下发]

    J --> K[注册完成]

4 关键信令参数分析

4.1 Registration Request中的Requested NSSAI

S-NSSAI索引 SST SD 是否签约 说明
1 1 N/A 是 eMBB，已签约
2 2 N/A 否 URLLC，未签约
3 3 N/A 是 MIoT，已签约

4.2 Security Mode Complete中的Requested NSSAI（无安全上下文场景）

当UE没有正确的安全上下文时，Requested NSSAI在Security Mode Complete消息中携带：

参数 值 说明
NAS Security Header Integrity Protected and Ciphered 安全模式已完成
Requested NSSAI [SST=1, SST=2, SST=3] 包含未签约的SST=2

4.3 UDM返回的签约数据

Nudm_SDM_Get Response：

参数 示例值 说明
Subscribed NSSAI [SST=1, SST=3, SST=1/SD=000001] UE签约的S-NSSAI列表
Default NSSAI [SST=1, SST=3] 默认S-NSSAI

注意：签约列表中不包含SST=2，这是后续拒绝的原因。

4.4 Registration Accept中的Allowed NSSAI

参数名称 值 说明
Allowed NSSAI [SST=1, SST=3] 仅包含已签约的S-NSSAI
Rejected NSSAI [SST=2] (可选) 被拒绝的S-NSSAI

关键分析：

  • SST=1（eMBB）：出现在Allowed NSSAI中，UE可以正常使用eMBB切片。

  • SST=2（URLLC）：未出现在Allowed NSSAI中，UE不得使用URLLC切片。UE收到Registration Accept后，应清除对SST=2切片的任何待处理请求。

  • SST=3（MIoT）：出现在Allowed NSSAI中，UE可以正常使用MIoT切片。

4.5 CLI验证数据

AMF UE上下文查询（脱敏）：


# AMF UE Context Query

IMSI: 4608800000XXXXXX

GPSI: 86138000XXXXXX

RM State: RM-REGISTERED

CM State: CM-CONNECTED

Requested NSSAI from UE:

  [1] SST=1 (eMBB) -- Subscribed

  [2] SST=2 (URLLC) -- NOT Subscribed

  [3] SST=3 (MIoT)  -- Subscribed

Subscribed NSSAI from UDM:

  [1] SST=1 (eMBB), SD=N/A

  [2] SST=3 (MIoT), SD=N/A

  [3] SST=1, SD=000001 (Custom-eMBB)

Allowed NSSAI (Sent to UE):

  [1] SST=1 (eMBB)

  [2] SST=3 (MIoT)

Rejected NSSAI:

  [1] SST=2 (URLLC) - Reason: Not Subscribed

Slice Selection Result: AMF independently processed (no NSSF query required)

从上述输出可以看出，AMF成功识别了UE请求中未签约的SST=2（URLLC），并将其从Allowed NSSAI中排除。

5 测试验证与数据解读

5.1 验证要点

验证点1：UE携带包含未签约S-NSSAI的Requested NSSAI

在NAS消息跟踪中确认：

  • Registration Request或Security Mode Complete消息中携带了Requested NSSAI；

  • Requested NSSAI中至少包含一个S-NSSAI不在UDM签约数据中。

测试方法：在UE关机状态下，设置终端下次开机请求的NSSAI中包含未签约的S-NSSAI。这通常通过修改UE的Configured NSSAI或使用测试终端的强制切片配置功能实现。

验证点2：AMF正确获取签约数据

在Nudm_SDM_Get接口跟踪中确认：

  • AMF向UDM成功发起请求；

  • UDM返回的Subscribed NSSAI中不包含UE请求的某些S-NSSAI。

验证点3：Allowed NSSAI不包含未签约的S-NSSAI

在Registration Accept消息中确认：

  • Allowed NSSAI仅包含已签约的S-NSSAI；

  • 未签约的S-NSSAI不出现在Allowed NSSAI中。

验证点4：UE注册仍然成功

确认即使部分请求的切片被拒绝，UE仍然能够完成注册流程。已签约的切片服务不受影响。

5.2 数据解读

通过分析测试数据，可以得出以下关键结论：

  1. 切片拒绝不影响注册成功：UE请求了3个S-NSSAI，其中1个未签约。AMF拒绝了SST=2但仍然接受了SST=1和SST=3，UE成功注册到网络。这体现了5G切片机制的"部分授权"特性——网络不是"全有或全无"的处理方式，而是逐个S-NSSAI进行授权判断。

  2. 安全上下文对Requested NSSAI传输的影响：测试中需要特别关注Requested NSSAI出现的消息位置。如果UE有安全上下文，Requested NSSAI在Registration Request中；如果没有，则在Security Mode Complete中。这影响AMF执行切片选择的时机。

  3. UDM签约数据是最终判决依据：无论UE请求什么切片，最终的Allowed NSSAI完全取决于UDM中的签约数据。这确保了运营商对切片访问的完全控制。

5.3 与切片选择场景的区别

对比维度 第6-8篇（切片选择） 本篇（切片拒绝）
UE请求的S-NSSAI 全部已签约 部分未签约
AMF核心动作 确定目标AMF/Allowed NSSAI 过滤未签约S-NSSAI
是否需要NSSF 视情况而定 本场景不需要
结果 UE获得全部请求切片 UE获得部分请求切片
网络侧行为 路由/重定向 过滤/拒绝

6 小结与思考

6.1 本篇小结

本篇详细分析了5G切片拒绝的第一个场景：AMF在注册过程中拒绝UE请求的未签约S-NSSAI。关键流程包括：

  1. UE在Registration Request或Security Mode Complete中携带Requested NSSAI，其中包含未签约的S-NSSAI；

  2. AMF从UDM获取签约数据，将Requested NSSAI与Subscribed NSSAI逐一比对；

  3. AMF将未签约的S-NSSAI从Allowed NSSAI中排除；

  4. AMF通过Registration Accept消息下发仅包含已签约切片的Allowed NSSAI；

  5. UE成功注册，但无法使用未签约的切片。

本场景体现了5G切片机制中"签约数据即策略"的核心原则。

6.2 延伸思考

思考1：UE如何知道自己的切片请求被拒绝了？

UE通过对比自己发送的Requested NSSAI和收到的Allowed NSSAI，可以推断出哪些切片被拒绝了。此外，如果网络实现了Rejected NSSAI信元（3GPP Release-16增强），UE可以更明确地获知被拒绝的S-NSSAI列表及原因。

思考2：被拒绝后UE会怎样？

UE收到不包含SST=2的Allowed NSSAI后，不得在当前注册周期内为SST=2发起任何PDU会话请求。如果UE确实需要URLLC服务，用户需要联系运营商开通相关套餐，运营商在UDM中更新签约数据后，UE重新注册即可获得URLLC切片服务。

思考3：与第10篇的对比预告

第10篇将讨论另一个切片拒绝场景：UE已经成功注册并获得了Allowed NSSAI，但随后在PDU会话建立请求中携带了未签约的S-NSSAI。AMF在PDU会话层面拒绝该请求，返回PDU Session Establishment Reject消息，携带5GSM cause值91（DNN not supported or not subscribed in the slice）。与本文在注册过程中的"静默过滤"不同，第10篇中AMF会发送明确的拒绝消息。

← 返回 网络切片 实践篇