5GC实践篇之切片篇第3篇：初始注册未携带NSSAI与5G-GUTI的切片选择流程

SIM卡更换后首次注册：新SIM卡中未预配置任何NSSAI信息
UE删除了已保存的切片信息：某些终端在特定条件下会清除保存的NSSAI
网络切片配置变更后：网络侧更新了切片策略，UE需要重新获取

本篇的核心问题是：当UE完全没有提供任何切片请求信息时，网络如何决定为UE分配哪些切片？AMF如何处理这种"零切片信息"的注册请求？

2 协议规范与关键技术

2.1 核心协议参考

本篇涉及的3GPP协议规范主要包括：

TS 23.501（第5.15节）：详细规定了当UE未提供Requested NSSAI时，网络基于签约数据中的Default NSSAI进行切片选择的机制。
TS 24.501（第8.2.6节）：定义了Registration Request消息中Requested NSSAI为可选字段的规则，以及UE不携带NSSAI时的行为。
TS 29.503（Nudm_SDM服务）：定义了AMF如何从UDM签约数据中获取Default NSSAI和Subscribed NSSAI。
TS 29.531（Nssf_NSSelection服务）：定义了当AMF无法独立确定切片选择时，如何向NSSF请求协助。

2.2 Default NSSAI的核心作用

当UE未携带Requested NSSAI时，Default NSSAI成为切片选择的关键依据。Default NSSAI在UDM签约数据中被标记，具有以下特性：

特性	说明
来源	UDM签约数据中标记为default的S-NSSAI
数量	通常1-8个S-NSSAI（标准允许最多8个）
必选性	每个UE的签约数据中至少应包含一个Default S-NSSAI
优先级	高于普通Subscribed NSSAI，但低于UE主动请求的NSSAI
作用域	在UE未请求切片时作为默认分配的切片

2.3 三篇注册场景对比

对比维度	第1篇	第2篇	本篇
UE标识	5G-GUTI	SUCI	SUCI
携带NSSAI	Requested NSSAI	Requested NSSAI（Security Mode Complete中）	未携带
切片选择依据	Requested ∩ Subscribed ∩ Supported	Requested ∩ Subscribed ∩ Supported	Default NSSAI ∩ Supported
需要UDM获取签约	是（刷新）	是（首次）	是（首次+关键依赖）
Configured NSSAI	可选下发	可选下发	重要下发（UE需保存供后续使用）

2.4 Configured NSSAI在本场景中的特殊意义

在本场景中，Configured NSSAI的下发具有特殊的重要性：

UE无切片信息：由于UE未携带任何NSSAI，说明UE可能没有任何已知的切片配置
网络主动配置：AMF通过下发Configured NSSAI，告知UE可以使用的切片列表
后续注册参考：UE保存Configured NSSAI后，在下次注册时可以据此构造Requested NSSAI
减少AMF重选：有了Configured NSSAI，UE可以在后续注册中更精确地选择AMF，减少不必要的AMF重定向

3 消息流程与详细解读

3.1 整体流程图


sequenceDiagram

    participant UE as UE终端

    participant RAN as gNB(RAN)

    participant AMF as AMF

    participant UDM as UDM

    participant AUSF as AUSF

    UE->>RAN: RRC Setup<br/>携带SUCI，未携带NSSAI

    RAN->>AMF: NGAP: Initial UE Message<br/>携带SUCI，未携带NSSAI

    AMF->>AUSF: Nausf_UEAuthentication<br/>发起鉴权请求

    AUSF-->>AMF: 鉴权结果

    AMF->>UE: Security Mode Command

    UE->>AMF: Security Mode Complete<br/>未携带Requested NSSAI

    AMF->>UDM: Nudm_SDM_Get<br/>获取UE签约数据(含Subscribed NSSAI)

    UDM-->>AMF: 返回签约切片数据<br/>含Default NSSAI

    AMF->>AMF: 将Default NSSAI作为Requested NSSAI<br/>检查本AMF支持的切片

    AMF->>AMF: 计算Allowed NSSAI和Configured NSSAI

    AMF-->>UE: Registration Accept<br/>携带GUTI+Allowed NSSAI+Configured NSSAI

    UE->>AMF: Registration Complete

3.2 流程详细解读

步骤1：UE发起注册请求（仅携带SUCI）

UE在无任何切片信息和有效GUTI的情况下，使用SUCI发起初始注册。Registration Request消息中：

Mobile Identity字段携带SUCI
不包含Requested NSSAI字段
不包含5G-GUTI字段

RAN在收到此消息后，由于没有GUTI和NSSAI作为路由依据，只能选择Default AMF将注册请求转发。

步骤2：完整鉴权流程

与第2篇相同，AMF收到SUCI后需要执行完整的5G-AKA鉴权流程。鉴权完成后建立NAS安全上下文。

步骤3：Security Mode Complete（不携带NSSAI）

在本场景中，Security Mode Complete消息中也不携带Requested NSSAI。AMF此时已经明确：UE没有提供任何切片偏好信息。

步骤4：AMF获取签约数据（关键步骤）

AMF向UDM发起Nudm_SDM_Get请求，获取UE的完整签约数据。在本场景中，这一步尤为关键，因为：

AMF没有任何来自UE的切片请求信息
签约数据中的Default NSSAI将成为切片分配的唯一依据
AMF需要特别关注签约数据中标记为default的S-NSSAI

步骤5：AMF将Default NSSAI作为Requested NSSAI

AMF从签约数据中提取Default NSSAI，将其视为UE的隐式请求。然后执行与第1、2篇相同的三重校验：


Allowed NSSAI = Default NSSAI (作为Requested)

                ∩ Subscribed NSSAI (签约数据)

                ∩ AMF Supported NSSAI (本AMF支持)

由于Default NSSAI本身就是Subscribed NSSAI的子集，所以实际计算简化为：


Allowed NSSAI = Default NSSAI ∩ AMF Supported NSSAI

步骤6：下发Configured NSSAI（重要）

在本场景中，AMF应下发Configured NSSAI，包含：


Configured NSSAI = AMF Configured NSSAI ∩ Subscribed NSSAI

Configured NSSAI帮助UE了解自己签约的所有可用切片，在后续注册时可以据此构造Requested NSSAI。

步骤7：注册接受与完成

AMF发送Registration Accept，携带5G-GUTI、Allowed NSSAI和Configured NSSAI。UE保存所有信息后发送Registration Complete。

3.3 无NSSAI场景的切片选择决策


flowchart TD

    A[AMF收到Registration Request<br/>仅SUCI无NSSAI无GUTI] --> B[完成鉴权建立安全上下文]

    B --> C[向UDM获取签约数据]

    C --> D{签约数据中是否有Default NSSAI}

    D -->|是| E[提取Default NSSAI]

    D -->|否| F[使用运营商策略配置的默认切片]

    E --> G[将Default NSSAI视为Requested NSSAI]

    F --> G

    G --> H[检查本AMF是否支持Default NSSAI中的切片]

    H --> I{本AMF是否支持所有Default S-NSSAI}

    I -->|是| J[当前AMF继续服务]

    I -->|否| K[仅保留AMF支持的Default S-NSSAI]

    K --> L{交集是否为空}

    L -->|非空| J

    L -->|空| M[查询NSSF触发AMF重选]

    J --> N[计算Allowed NSSAI和Configured NSSAI]

    N --> O[下发Registration Accept]

    M --> P[路由到目标AMF重新处理]

4 关键信令参数分析

4.1 Registration Request消息参数（无NSSAI场景）

参数	取值示例	说明
Registration Type	Initial Registration	初始注册
Mobile Identity	SUCI: type=IMSI, MCC=460, MNC=88	加密后的用户标识
UE security capability	NR SA, 5G-EIA1/2/3, 5G-EEA1/2/3	安全能力

Requested NSSAI: 不携带 | UE无切片信息

4.2 UDM返回的签约数据（含Default NSSAI标记）


{

  "amData": {

    "nssai": {

      "defaultSingleNssais": [

        {"sst": 1, "sd": "010203"},

        {"sst": 1, "sd": "040506"}

      ],

      "singleNssais": [

        {"sst": 1, "sd": "010203"},

        {"sst": 1, "sd": "040506"},

        {"sst": 2},

        {"sst": 3}

      ]

    }

  }

}

对比第1、2篇的签约数据，可以看到Default NSSAI（defaultSingleNssais）仅包含SST=1的两个切片，而完整签约数据（singleNssais）还包含SST=2和SST=3。

4.3 Registration Accept消息参数

参数	取值示例	说明
5G-GUTI	460-88-01-02-01-0xAABBCCDD	新分配的临时标识
Allowed NSSAI	SST=1, SD=010203; SST=1, SD=040506	基于Default NSSAI计算
Configured NSSAI	SST=1, SD=010203; SST=1, SD=040506; SST=2; SST=3	签约中AMF支持的所有切片

注意本篇与前两篇的关键区别：

Allowed NSSAI来源于Default NSSAI，而非UE主动请求
Configured NSSAI尤为重要，因为UE此前没有任何切片信息，需要网络告知全部可用切片

4.4 Allowed NSSAI计算过程

步骤	输入	结果
1. Default NSSAI（视为Requested）	SST=1/SD=010203, SST=1/SD=040506	2个S-NSSAI
2. Subscribed NSSAI	SST=1/SD=010203, SST=1/SD=040506, SST=2, SST=3	4个S-NSSAI
3. AMF Supported NSSAI	SST=1/SD=010203, SST=1/SD=040506, SST=2	3个S-NSSAI
4. Allowed = 1 ∩ 2 ∩ 3	SST=1/SD=010203, SST=1/SD=040506	2个S-NSSAI
5. Configured = AMF Config ∩ 2	SST=1/SD=010203, SST=1/SD=040506, SST=2	3个S-NSSAI

5 测试验证与数据解读

5.1 NAS消息跟踪分析

Registration Request（脱敏后，无NSSAI）：


NAS-MSG:

  Protocol Discriminator: 5GS Mobility Management

  Security Header Type: Plain NAS message

  Message Type: Registration Request (0x41)

  5GS Registration Type:

    Registration Type: Initial Registration

  Mobile Identity:

    Type: SUCI

    SUPI Type: IMSI

    MCC: 460, MNC: 88

    Routing Indicator: 0001

    Protection Scheme: ECIES Profile A

    Public Key ID: 1

    Encrypted Output: 0xC7D8...[encrypted MSIN]

  UE Security Capability:

    5G-EIA: EIA1/2/3 supported

    5G-EEA: EEA1/2/3 supported

  [No Requested NSSAI IE present]

Registration Accept（脱敏后）：


NAS-MSG:

  Protocol Discriminator: 5GS Mobility Management

  Security Header Type: Integrity Protected and Ciphered

  Message Type: Registration Accept (0x42)

  5G-GUTI:

    MCC: 460, MNC: 88

    AMF Region ID: 0x01

    AMF Set ID: 0x02

    AMF Pointer: 0x01

    5G-TMSI: 0xAABBCCDD

  Allowed NSSAI:

    S-NSSAI 1: SST=1, SD=010203

    S-NSSAI 2: SST=1, SD=040506

  Configured NSSAI:

    S-NSSAI 1: SST=1, SD=010203

    S-NSSAI 2: SST=1, SD=040506

    S-NSSAI 3: SST=2

5.2 关键分析点

Registration Request中无NSSAI：消息中没有Requested NSSAI IE，AMF通过此信息判断UE没有切片偏好。
Allowed NSSAI = Default NSSAI：AMF将签约数据中的Default NSSAI（SST=1/SD=010203和SST=1/SD=040506）作为Allowed NSSAI下发，因为这两个切片都在AMF支持列表中。
Configured NSSAI包含3个切片：除了Default的两个切片外，还包含SST=2，因为SST=2也在UE签约数据中且AMF支持。但SST=3不在Configured NSSAI中，因为当前AMF不支持SST=3。
UE保存Configured NSSAI：UE收到后保存Configured NSSAI，在后续注册时可以据此构造Requested NSSAI。例如，如果UE需要使用URLLC业务（SST=2），下次注册时可以主动请求SST=2。

5.3 AMF CLI验证

在AMF上查看UE上下文信息（脱敏后）：


AMF-Version# show ue context imsi 4608800000XXXXXX

UE Context Information:

  SUPI        : 4608800000XXXXXX

  SUCI        : sutype-0-460-88-0001-sch1-key1

  GPSI        : 86138000XXXXXX

  5G-GUTI     : 460-88-01-02-01-0xAABBCCDD

  RM State    : RM-REGISTERED

  CM State    : CM-IDLE

  Registration Type: Initial Registration

  NSSAI Information:

    Allowed NSSAI:

      S-NSSAI 1: SST=1, SD=010203 (from default)

      S-NSSAI 2: SST=1, SD=040506 (from default)

    Configured NSSAI:

      S-NSSAI 1: SST=1, SD=010203

      S-NSSAI 2: SST=1, SD=040506

      S-NSSAI 3: SST=2

    Subscribed NSSAI:

      S-NSSAI 1: SST=1, SD=010203 (default)

      S-NSSAI 2: SST=1, SD=040506 (default)

      S-NSSAI 3: SST=2

      S-NSSAI 4: SST=3

  AMF Supported NSSAI:

    S-NSSAI 1: SST=1, SD=010203

    S-NSSAI 2: SST=1, SD=040506

    S-NSSAI 3: SST=2

5.4 三篇注册结果对比

切片	第1篇（GUTI+NSSAI）	第2篇（SUCI+NSSAI）	本篇（SUCI无NSSAI）
SST=1/SD=010203	Allowed	Allowed	Allowed(来自Default)
SST=1/SD=040506	未请求	未请求	Allowed(来自Default)
SST=2	请求但被拒绝(AMF不支持)	未请求	Configured
SST=3	未请求	Allowed	未分配(AMF不支持)

6 小结与思考

6.1 本篇小结

本篇分析了最简单的切片注册场景：UE既无5G-GUTI也无Requested NSSAI。核心要点如下：

Default NSSAI是安全网：当UE没有提供任何切片信息时，网络通过Default NSSAI确保UE至少能获得基本的切片服务，不会因为缺少NSSAI而被拒绝注册。
Configured NSSAI是学习机制：通过下发Configured NSSAI，网络"教会"UE可以使用哪些切片。UE保存后在后续注册中主动使用，形成正向循环。
三篇递进关系：第1篇→UE有GUTI有切片信息（最理想）；第2篇→UE有切片信息但无GUTI（需鉴权）；第3篇→UE啥都没有（完全依赖网络配置）。三种场景覆盖了实际网络中的绝大多数初始注册情况。

6.2 延伸思考

问题1：如果UDM签约数据中没有Default NSSAI怎么办？

TS 23.501规定，如果UE的签约数据中既没有Default NSSAI，UE也未提供Requested NSSAI，AMF应使用运营商策略中配置的默认S-NSSAI。如果运营商也未配置默认切片，AMF可能拒绝注册或仅提供基础的non-slice服务。

问题2：Configured NSSAI和Default NSSAI有什么区别？

Default NSSAI是UDM签约数据中标记为default的切片，表示"UE未请求时自动分配的切片"。Configured NSSAI是AMF下发给UE的网络侧配置信息，范围可能比Default NSSAI更广（包含签约中但非default的切片），目的是告知UE所有可用的切片选项。两者来源不同、用途不同。

问题3：UE能否拒绝网络下发的Configured NSSAI？

根据TS 24.501，UE应接受并保存网络下发的Configured NSSAI。如果UE认为Configured NSSAI与自身的切片需求不匹配，UE可以发起Registration Request携带自己期望的Requested NSSAI来请求特定切片。也就是说，Configured NSSAI是参考信息，UE在后续注册中可以选择使用或不使用。

51学通信（微信：gprshome201101）——专注5G核心网与IMS技术教学，已帮助10000+通信工程师提升技能。知识星球搜"51学通信"，200+小时视频+3000+文章等你来。

5GC实践篇之切片篇第3篇：初始注册未携带NSSAI与5G-GUTI的切片选择流程

5GC实践篇之切片篇第3篇：初始注册未携带NSSAI与5G-GUTI的切片选择流程

1 测试背景与用例简介

2 协议规范与关键技术

2.1 核心协议参考

2.2 Default NSSAI的核心作用

2.3 三篇注册场景对比

2.4 Configured NSSAI在本场景中的特殊意义

3 消息流程与详细解读

3.1 整体流程图

3.2 流程详细解读

3.3 无NSSAI场景的切片选择决策

4 关键信令参数分析

4.1 Registration Request消息参数（无NSSAI场景）

4.2 UDM返回的签约数据（含Default NSSAI标记）

4.3 Registration Accept消息参数

4.4 Allowed NSSAI计算过程

5 测试验证与数据解读

5.1 NAS消息跟踪分析

5.2 关键分析点

5.3 AMF CLI验证

5.4 三篇注册结果对比

6 小结与思考

6.1 本篇小结

6.2 延伸思考

查看完整内容