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

5GC实践篇之切片篇第10篇：AMF拒绝用户携带未签约S-NSSAI的PDU会话创建请求

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

5GC实践篇之切片篇第10篇：AMF拒绝用户携带未签约S-NSSAI的PDU会话创建请求

作者：爱卫生

1 测试背景与用例简介

在上一篇文章（第9篇）中，我们讨论了AMF在注册过程中拒绝UE请求的未签约S-NSSAI。那是一种"前端拦截"——在UE获得网络服务之前，AMF就已经将未签约的切片从Allowed NSSAI中过滤掉了。

本篇讨论的是另一种拒绝场景：UE已经成功注册到网络，获得了Allowed NSSAI，但在随后发起PDU会话建立请求时，携带了一个未签约的S-NSSAI。AMF检查签约信息后发现该S-NSSAI不在UE的签约数据中，向UE返回PDU Session Establishment Reject消息，携带5GSM cause值91（DNN not supported or not subscribed in the slice）。

这个场景为什么会出现？如果AMF在注册时已经下发了正确的Allowed NSSAI，UE理论上不应该请求不在Allowed NSSAI中的切片。但在以下几种情况下，UE可能仍然会携带未签约的S-NSSAI发起PDU会话请求：

  1. UE行为异常：终端实现不正确，忽略了Allowed NSSAI的限制，直接使用本地预配置的S-NSSAI发起PDU会话。

  2. 签约数据动态变更：UE注册后，运营商在UDM中修改了用户的签约数据（删除了某个S-NSSAI），但尚未通过Configuration Update流程通知UE。UE仍然使用旧的Allowed NSSAI信息。

  3. 测试场景：网络运维人员通过测试终端强制构造携带未签约S-NSSAI的PDU会话请求，用于验证AMF的安全控制能力。

无论触发原因是什么，AMF必须具备在PDU会话层面检查S-NSSAI签约状态的能力。这是5G切片安全防线的"第二道关卡"——即使第一道关卡（注册时的Allowed NSSAI过滤）被绕过，AMF仍然可以在PDU会话建立时拦截未授权的切片请求。

2 协议规范与关键技术

2.1 相关协议规范

本篇涉及PDU会话管理层面的切片验证，相关的协议规范与第9篇有所不同：

  • TS 23.501 第5.15节：定义了PDU会话与S-NSSAI的绑定关系。每个PDU会话必须关联一个Allowed NSSAI中的S-NSSAI。不在Allowed NSSAI中的S-NSSAI不得用于PDU会话建立。

  • TS 23.502 第4.3.2节：PDU会话建立流程。AMF在收到PDU Session Establishment Request后，需验证S-NSSAI的合法性。

  • TS 24.501 第6.4.1节：PDU Session Establishment Request消息格式，定义了S-NSSAI信元的编码。

  • TS 24.501 第6.4.1.3节：PDU Session Establishment Reject消息格式，定义了5GSM cause值的编码。

  • TS 29.503：UDM服务接口，AMF可通过Nudm_SDM_Get或订阅Nudm_SDM_Notify获取最新的签约数据。

  • TS 29.502：SMF服务接口，AMF与SMF之间的PDU会话管理交互。

2.2 5GSM Cause值91

本场景中AMF返回的5GSM cause值为91（DNN not supported or not subscribed in the slice）。这个cause值的含义是：

  • UE请求的DNN（Data Network Name）在指定的S-NSSAI切片中不被支持，或者

  • UE请求的DNN/S-NSSAI组合不在用户的签约数据中。

在3GPP TS 24.501的Table 9.11.4.2中，5GSM cause值91的定义为：

"#91 DNN not supported or not subscribed in the slice"

这个cause值不仅涵盖了"DNN在切片中不支持"的情况，也涵盖了"整个S-NSSAI未签约"的情况。AMF在检测到S-NSSAI未签约时，使用这个通用的cause值拒绝PDU会话请求。

2.3 PDU会话与S-NSSAI的绑定关系

5G系统中，每个PDU会话都与一个S-NSSAI绑定。这意味着：

  1. UE在发起PDU Session Establishment Request时，必须指定一个S-NSSAI；

  2. 该S-NSSAI必须在UE当前的Allowed NSSAI中；

  3. DNN与S-NSSAI的组合必须在UE的签约数据中授权；

  4. SMF必须支持该S-NSSAI和DNN组合。

如果任何一个条件不满足，PDU会话建立请求将被拒绝。

2.4 注册拒绝 vs PDU会话拒绝的对比

对比维度 第9篇（注册拒绝） 本篇（PDU会话拒绝）
拒绝发生的流程 Registration PDU Session Establishment
拒绝方式 从Allowed NSSAI中排除 发送Reject消息（cause 91）
拒绝的粒度 切片级别 PDU会话级别
UE是否已注册 否（正在注册中） 是（已注册）
消息类型 Registration Accept PDU Session Establishment Reject
对UE行为的影响 UE无法使用被拒绝的切片 UE的PDU会话创建失败

3 消息流程与详细解读

3.1 整体流程概览


sequenceDiagram

    participant UE

    participant RAN as NG-RAN

    participant AMF

    participant UDM

    Note over UE,AMF: 前提：UE已成功注册并获取Allowed NSSAI

    UE->>UE: 触发PDU会话建立请求

    Note over UE: 携带未签约的S-NSSAI

    UE->>RAN: NAS PDU Session Establishment Request(S-NSSAI, DNN)

    Note over UE,RAN: S-NSSAI为未签约切片

    RAN->>AMF: N2 NAS Transport(NAS PDU Session Establishment Request)

    Note over AMF: 检查S-NSSAI是否在签约数据中<br/>检查S-NSSAI是否在Allowed NSSAI中<br/>判定：S-NSSAI未签约

    AMF->>RAN: N2 NAS Transport(NAS PDU Session Establishment Reject)

    Note over AMF,RAN: 5GSM Cause: 91<br/>DNN not supported or not<br/>subscribed in the slice

    RAN->>UE: NAS PDU Session Establishment Reject(5GSM Cause 91)

    Note over UE: PDU会话建立失败<br/>UE不得重试该S-NSSAI

3.2 流程详细解读

前提条件：UE已成功注册

本场景的前提是UE已经成功完成了Registration流程，获得了Allowed NSSAI。例如，UE的Allowed NSSAI为[SST=1(eMBB), SST=3(MIoT)]，不包含SST=2(URLLC)。

步骤1：UE发起PDU会话建立请求

UE由于某种原因（终端异常、本地配置残留等），发起PDU Session Establishment Request消息，其中携带：

  • S-NSSAI：SST=2（URLLC）——这是一个未签约的切片；

  • DNN：internet（或运营商配置的DNN）；

  • PDU Session ID：UE分配的会话标识；

  • PDU Session Type：IPv4/IPv6/IPv4v6。

步骤2：RAN转发NAS消息

NG-RAN收到UE的NAS消息后，通过N2 NAS Transport消息转发给AMF。RAN不检查S-NSSAI的合法性，这个验证由AMF完成。

步骤3：AMF验证S-NSSAI

AMF收到PDU Session Establishment Request后，执行以下验证：

  1. 检查S-NSSAI是否在Allowed NSSAI中：AMF首先检查UE请求的S-NSSAI（SST=2）是否在UE当前的Allowed NSSAI中。由于SST=2不在Allowed NSSAI [SST=1, SST=3] 中，验证失败。

  2. 检查签约数据：AMF进一步验证签约数据，确认SST=2是否在UE的Subscribed NSSAI中。确认结果为不在签约列表中。

  3. 决策：AMF判定该PDU会话请求不合法，应予以拒绝。

步骤4：AMF返回PDU Session Establishment Reject

AMF构造PDU Session Establishment Reject消息，包含：

  • 5GSM Cause：91（DNN not supported or not subscribed in the slice）；

  • PDU Session ID：与请求消息中的PDU Session ID一致。

AMF通过N2 NAS Transport消息将Reject发送给RAN，RAN转发给UE。

步骤5：UE处理拒绝

UE收到PDU Session Establishment Reject后，应当：

  1. 识别到5GSM cause值为91；

  2. 理解该S-NSSAI/DNN组合不被网络支持或未签约；

  3. 不得在当前注册周期内针对该S-NSSAI再次发起PDU会话请求；

  4. 如果需要该切片服务，应等待签约数据更新后重新注册。

3.3 AMF PDU会话切片验证决策流程


flowchart TD

    A[收到PDU Session Establishment Request] --> B[提取S-NSSAI和DNN]

    B --> C[检查S-NSSAI是否在Allowed NSSAI中]

    C --> D[是：继续处理]

    C --> E[否：检查签约数据]

    E --> F[签约数据中也不包含该S-NSSAI]

    E --> G[签约数据包含但Allowed NSSAI不包含]

    F --> H[返回Reject 5GSM Cause 91]

    G --> I[返回Reject 5GSM Cause 91]

    D --> J[检查DNN是否在S-NSSAI中授权]

    J --> K[授权：继续PDU会话建立]

    J --> L[未授权：返回Reject]

    H --> M[PDU会话建立失败]

    I --> M

    L --> M

4 关键信令参数分析

4.1 PDU Session Establishment Request消息参数

参数名称 值 说明
PDU Session ID 5 UE分配的PDU会话标识
S-NSSAI: SST=2 (URLLC) | 未签约的切片
DNN internet 请求数据网络名称
PDU Session Type IPv4 PDU会话类型
SSC Mode SSC Mode 1 会话和服务连续性模式

4.2 AMF验证过程中的关键数据

UE当前上下文（脱敏）：


IMSI: 4608800000XXXXXX

RM State: RM-REGISTERED

Allowed NSSAI: [SST=1, SST=3]

Subscribed NSSAI: [SST=1, SST=3, SST=1/SD=000001]

Requested S-NSSAI: SST=2

Verification Result: SST=2 NOT in Allowed NSSAI AND NOT in Subscribed NSSAI

Action: REJECT with 5GSM Cause 91

4.3 PDU Session Establishment Reject消息参数

参数名称 值 说明
PDU Session ID 5 与请求消息一致
5GSM Cause 91 DNN not supported or not subscribed in the slice

5GSM Cause值91的含义详解：

根据TS 24.501 Table 9.11.4.2，Cause 91在以下情况下使用：

  1. UE请求的DNN在指定的S-NSSAI中不被网络支持；

  2. UE请求的DNN在指定的S-NSSAI中未签约；

  3. UE请求的S-NSSAI本身未签约（本场景）；

  4. UE请求的S-NSSAI不在当前的Allowed NSSAI中。

AMF使用这个通用的cause值而非更具体的原因码，可以避免向UE暴露过多的网络内部信息。

4.4 CLI验证数据

AMF PDU会话处理日志（脱敏）：


# AMF PDU Session Processing Log

Time: 2026-04-17 16:45:22.345

SUPI: imsi-4608800000XXXXXX

GPSI: 86138000XXXXXX

Received PDU Session Establishment Request:

  PDU Session ID: 5

  Requested S-NSSAI: SST=2 (URLLC)

  Requested DNN: internet

  PDU Session Type: IPv4

Current UE Context:

  Allowed NSSAI: [SST=1 (eMBB), SST=3 (MIoT)]

  Subscribed NSSAI: [SST=1, SST=3, SST=1/SD=000001]

Slice Verification:

  SST=2 in Allowed NSSAI: NO

  SST=2 in Subscribed NSSAI: NO

  Verification Result: REJECTED

Action: Send PDU Session Establishment Reject

  5GSM Cause: 91 (DNN not supported or not subscribed in the slice)

  PDU Session ID: 5

Result: PDU Session Establishment Failed

UE侧行为日志（模拟）：


# UE PDU Session Log

Time: 2026-04-17 16:45:22.500

PDU Session ID: 5

Requested S-NSSAI: SST=2

Requested DNN: internet

Received Response: PDU Session Establishment Reject

  5GSM Cause: 91

  Action: Do not retry with S-NSSAI=SST=2

  Note: S-NSSAI not subscribed in current subscription profile

5 测试验证与数据解读

5.1 测试预置条件

本场景的测试预置条件包括：

  • UE、RAN、AMF、UDM等网元运行正常；

  • 环境已配置好相关的切片信息，UE在UDM成功签约了切片数据；

  • AMF上配置了支持的切片信息；

  • UE已经成功接入网络（已注册并获取Allowed NSSAI）；

  • 设置UE下次发起PDU会话建立请求时携带未签约的S-NSSAI。

测试步骤：

  1. UE已成功注册，Allowed NSSAI为[SST=1, SST=3]；

  2. 通过测试终端或配置工具，强制UE发起携带SST=2（URLLC）的PDU会话请求；

  3. 检查消息跟踪，确认AMF正确拒绝。

5.2 验证要点

验证点1：UE成功注册并获得Allowed NSSAI

在注册流程的NAS消息跟踪中确认：

  • Registration Accept消息中包含Allowed NSSAI [SST=1, SST=3]；

  • Allowed NSSAI中不包含SST=2。

验证点2：UE发起携带未签约S-NSSAI的PDU会话请求

在NAS消息跟踪中确认PDU Session Establishment Request消息中：

  • S-NSSAI参数值为SST=2；

  • 该S-NSSAI不在UE的Allowed NSSAI中。

验证点3：AMF返回PDU Session Establishment Reject

在NAS消息跟踪中确认：

  • AMF返回了PDU Session Establishment Reject消息；

  • 5GSM Cause值为91（DNN not supported or not subscribed in the slice）；

  • PDU Session ID与请求消息一致。

验证点4：已签约切片的PDU会话不受影响

在同一UE上，使用已签约的S-NSSAI（如SST=1）发起PDU会话请求，确认：

  • PDU会话成功建立；

  • 已签约切片的服务不受影响。

5.3 数据解读

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

  1. AMF的双重验证机制：AMF不仅检查S-NSSAI是否在Allowed NSSAI中，还进一步检查签约数据。这种双重验证确保了即使Allowed NSSAI被错误修改（如网络故障导致），AMF仍然可以通过签约数据进行兜底验证。

  2. 拒绝不影响其他切片服务：UE请求SST=2的PDU会话被拒绝，但SST=1和SST=3的PDU会话仍然可以正常建立。这说明AMF的切片验证是逐个PDU会话进行的，不会因为一个切片的请求失败而影响其他切片的服务。

  3. Cause值91的通用性：AMF使用通用的Cause 91而非更具体的错误码，既满足了协议要求，又避免了向UE暴露网络内部的详细信息。从安全角度看，这是一种良好的实践。

5.4 与第9篇场景的完整对比

对比维度 第9篇（注册拒绝） 本篇（PDU会话拒绝）
发生时机 Registration Request阶段 PDU Session Establishment阶段
UE状态 未注册 已注册
拒绝方式 从Allowed NSSAI中排除（静默） 发送明确的Reject消息
消息类型 Registration Accept（不含被拒切片） PDU Session Establishment Reject
错误指示 无明确错误码（UE通过对比推断） 5GSM Cause 91
安全防线 第一道防线 第二道防线
对其他切片的影响 无（全部已签约切片正常） 无（其他PDU会话不受影响）

6 小结与思考

6.1 本篇小结

本篇详细分析了5G切片拒绝的第二个场景：AMF在PDU会话建立过程中拒绝UE携带未签约S-NSSAI的请求。关键流程包括：

  1. UE已成功注册并获得Allowed NSSAI，但随后发起PDU会话时携带了未签约的S-NSSAI；

  2. AMF收到PDU Session Establishment Request后，验证S-NSSAI的合法性；

  3. AMF发现S-NSSAI不在Allowed NSSAI和签约数据中，拒绝该PDU会话请求；

  4. AMF返回PDU Session Establishment Reject消息，携带5GSM Cause 91。

本场景展示了5G切片安全防线的"纵深防御"理念：注册时过滤和PDU会话时验证形成双重保护。

6.2 延伸思考

思考1：签约数据动态更新时的处理

在实际运营中，运营商可能需要动态修改用户的签约数据（如增删切片）。TS 23.502定义了UE Configuration Update流程，AMF可以通过该流程更新UE的Allowed NSSAI和Configured NSSAI。但在更新完成之前，如果UE使用旧的切片信息发起PDU会话，AMF应如何处理？

答案是：AMF应始终以UDM中的最新签约数据为准。如果签约数据已更新但UE Configuration Update尚未完成，AMF在PDU会话验证时使用最新的签约数据。这确保了运营商的策略变更能够及时生效。

思考2：连续请求未签约切片的UE行为

如果UE反复使用未签约的S-NSSAI发起PDU会话请求，会产生大量无效信令，浪费网络资源。协议层面，UE收到Cause 91后不应立即重试，而应等待一段退避时间。但在恶意终端场景下，AMF可能需要额外的速率限制机制来防止信令风暴。

思考3：切片篇系列总结

从第6篇到第10篇，我们用五篇文章完整覆盖了5G切片选择与拒绝的核心场景：

  • 第6篇：AMF独立处理（最简单场景）

  • 第7篇：NSSF参与，UE携带Requested NSSAI（AMF不匹配）

  • 第8篇：NSSF参与，UE未携带Requested NSSAI（AMF不匹配）

  • 第9篇：AMF在注册时拒绝未签约S-NSSAI

  • 第10篇：AMF在PDU会话时拒绝未签约S-NSSAI（本篇）

这五个场景构成了5G切片实践的"最小知识集"。掌握了这些场景，读者可以应对绝大多数5G切片相关的工程问题。后续如果需要深入了解更多场景（如切片变更、跨PLMN切片、VPLMN切片等），可以继续关注本系列的后续文章。

← 返回 网络切片 实践篇