<!-- title: 手机怎么点切片：选择原理 -->

# 手机怎么点切片：切片选择机制原理详解

打开手机设置，你看到的还是那个熟悉的信号格。但在网络内部，同一个基站、同一套核心网，可能正在同时服务着几张彼此隔离的“虚拟专网”——工厂的机械臂、电网的差动保护、你刷的短视频，各走各的门。大多数讲切片的文章都在讲“墙是怎么砌的”（资源隔离），本文要讲的是另一件事：**你是怎么被分进那间包间的**。一个手机开机时说了什么，网络怎么审核，谁来拍板，点菜之后为什么还会被中途换桌——这条“切片选择链路”是现网专网开局和故障定位时最常用到、却最少被讲透的原理。

## 一、先看身份证：S-NSSAI 的两段式设计

要去包间，先得有包间号。5G 里每个切片的身份标识叫 S-NSSAI（单网络切片选择辅助信息），它只有两段，短得惊人：

```mermaid
flowchart TD
    A["S-NSSAI 切片身份证"] --> B["SST 菜系 8位"]
    A --> C["SD 包间号 24位 可选"]
    B --> D["0到127 标准值"]
    B --> E["128到255 运营商自定义"]
    D --> F["1 eMBB"]
    D --> G["2 URLLC"]
    D --> H["3 mMTC"]
```

第一段叫 SST（切片/业务类型），固定 8 个比特，最多表达 256 个值。它回答的问题是“你要哪**类**服务”。其中 0～127 是全球标准化的取值，128～255 留给运营商自己定义。第二段叫 SD（业务区分符），24 个比特，可选，回答的问题是“这一类里你要**哪一家**”。

为什么要拆成两段？这是一个典型的“通用性 vs 私有性”权衡：

- **只有 SST 时，它是世界通用的。** 任何一部手机、任何一张网都认识“SST=2 表示低时延高可靠类”。这保证了最朴素的诉求——手机开机随便点一个“菜系”，总有一家店能懂。
- **加上 SD 后，它变成了本地方言。** SD 标识的是某个运营商网络内部的第几号切片。标准明确：只要带了 SD，这个 S-NSSAI 就不再是“标准值”，手机不允许在其他运营商的网络里使用它。换句话说，**带 SD 的切片号出不了国门**——你在归属网络里点的“URLLC 系 3 号包间”，到了拜访网络里毫无意义，必须靠映射关系翻译成对方的本地编号。

SD 的容量值得算一笔账：

$$2^{24} = 16{,}777{,}216$$

一个 SST 菜系下，理论上可以编出 1600 多万个包间号。实际网络远用不了这么多，但这个设计给了专网订单近乎无限的编号空间——每签一个工厂、一个港口、一个医院，就能开出新的 SD，而不用去挤全球标准值那 127 个名额。（另有保留值 FFFFFF 表示“本切片不区分 SD”，协议编码上干脆省略该字段。）

目前标准已经定义了 7 个标准 SST 值：

| SST 值 | 名称 | 适用场景 |
|---|---|---|
| 1 | eMBB | 增强移动宽带，大流量下载、高清视频 |
| 2 | URLLC | 低时延高可靠，工业控制、车联网 |
| 3 | MIoT | 大规模物联，海量低功耗传感器 |
| 4 | V2X | 车联网直连类服务 |
| 5 | HMTC | 高性能机器通信 |
| 6 | HDLLC | 高速率低时延通信（后补） |
| 7 | GBRSS | 保障比特率的流媒体服务 |

两个容易被忽略的细节：一，**标准化不等于必须支持**——某个运营商的网可以只部署其中两三个值，也可以用另一个 SST 去承载同类业务；二，GSMA 有一份运营联盟侧的切片类型映射指南，把行业术语翻译成这些标准 SST，谈专网订单时对齐的就是它。

## 二、一份点菜单，五张副本：NSSAI 家族

如果说 S-NSSAI 是单个切片的身份证，那 NSSAI 就是一份**切片清单**——一叠 S-NSSAI。真正的复杂性来了：协议里光 NSSAI 就有好几种，很多初学者在这里晕掉。其实只要抓住一个问题就能理清：**这份清单是谁写的，写给谁看。**

| 名称 | 谁产生 | 出现在哪里 | 数量上限 |
|---|---|---|---|
| Subscribed S-NSSAIs | 签约数据（UDM） | 只在网络内部流转，UE 永远看不到 | 16 |
| Configured NSSAI | 归属运营商下发 | 注册接受 / 配置更新消息 | 16 |
| Default Configured NSSAI | 预置在手机里 | 不传信令，兜底用 | — |
| Requested NSSAI | 手机自己拼出来 | 注册请求消息 | 8 |
| Allowed NSSAI | AMF 审核后下发 | 注册接受消息 | 8 |
| Rejected S-NSSAIs | AMF | 注册接受消息，附带拒绝原因 | 7 |
| Pending NSSAI | 网络 | 切片级认证还没做完的中间态 | — |
| Selected NSSAI | 手机选、网络确认 | 每建一条 PDU 会话带一个 | 每会话 1 个 |

把这张表翻译成餐厅语言：

- **Subscribed** 是你包里那张 VIP 会员卡，写着“你有资格点这些”，只有店家内部能看到；
- **Configured** 是进门时发的菜单——“本店今日供应这些”；
- **Requested** 是你举手点菜——“我要这几个”；
- **Allowed** 是后厨批复——“这几桌可以给你安排”；
- **Rejected** 是“这道菜本店没有”，还会告诉你为什么；
- **Selected** 是最终落在桌上的那一道——每开一条数据会话，只能绑定清单里的一个切片。

为什么要拆得这么碎？因为**点菜的意愿、吃饭的资格、今天灶上的余量，是三个独立的信息源**。手机想要什么（可能来自 App 或操作系统）、运营商给这个用户签了什么（商用合同）、网络此刻在这个位置能伺候什么（覆盖与容量），任何一方的信息单独决策都会出错。所以协议把三次信息交汇设计成了显式的协商流程：

```mermaid
flowchart TD
    U["UE 开机"] --> R["注册请求 带Requested"]
    R --> AMF["初始AMF 收到点菜单"]
    AMF --> UDM["查签约 有无资格"]
    AMF --> NSSF["问NSSF 该进哪个切片"]
    NSSF --> AMF2["答Allowed 与目标AMF"]
    AMF2 --> ACC["注册接受 四份答复一起带"]
    ACC --> PDU["建PDU会话 带Selected"]
```

几个数字上限也值得记：手机一次注册最多“点” 8 个切片（Requested ≤ 8），网络最多“批” 8 个（Allowed ≤ 8），但签约库里最多能存 16 个（Subscribed ≤ 16）：

$$N_{req} \le 8,\quad N_{allow} \le 8,\quad N_{sub} \le 16$$

为什么“能存的”比“能点的”多一倍？因为签约是长期合同，覆盖这个用户可能用到的所有业务；而注册是短期行为，一次只需要声明当下要用的少数几个。信令消息里塞太多切片号会白白膨胀开销——这是把“存储上限”和“信令上限”分开设计的典型手法。

还有一个冷门但实用的中间态：**Pending**。有些行业切片要求在入网前做切片级的二次认证（相当于包间还要再验一次工牌），认证没做完之前，这个切片既不算同意也不算拒绝，先挂起。现网专网调试时，如果发现某切片“有时能用有时不能用”，先查查是不是切片认证流程还没收敛。

## 三、中途换包间：NSSF 与 AMF 重定向

协商流程里藏着 5G 切片机制最精巧、也最少被科普的一环：**注册进行到一半，服务你的 AMF 可能会换人。**

要理解它，得先看基站的角色。手机发注册请求时，基站要先决定“把这条信令递给核心网里的哪个 AMF"。基站手里有两个线索：手机旧的中临时标识（里面编码了上次服务的 AMF 信息），以及注册请求里带的 Requested NSSAI。基站会尽量挑一个**能服务这些切片**的 AMF——也就是说，切片选择在你还没进核心网大门时就已经开始了。找不到线索时，就交给一个默认 AMF。

问题在于：基站只看得到“菜单”，看不到“后厨实际排班”。默认 AMF 收到请求后，去问专门的裁判——NSSF（网络切片选择功能），把手机想点的切片、签约数据、当前位置报上去。NSSF 裁决两件事：这批切片该给哪些，以及**这单该由哪个 AMF 组来管**。如果当前 AMF 不在目标名单里，就要换桌：

```mermaid
sequenceDiagram
    participant UE as 手机
    participant gNB as 基站
    participant AMF1 as 初始AMF
    participant NSSF as NSSF
    participant AMF2 as 目标AMF
    UE->>gNB: 注册请求 带Requested
    gNB->>AMF1: 递给初始AMF
    AMF1->>NSSF: 这部手机该进哪些切片
    NSSF-->>AMF1: Allowed 与目标AMF组
    AMF1->>AMF2: NAS消息转交
    Note over AMF1,AMF2: 换桌对手机透明
    AMF2-->>UE: 注册接受 带Allowed
```

换桌有两条路：一条是初始 AMF 直接把 NAS 消息转交给目标 AMF；另一条是核心网给基站回一条“重定向”指令，让基站把消息重新投递给目标 AMF。无论走哪条，**手机全程不知情**——它只看到最后那一条注册接受。

为什么要把架构设计成“允许中途换人”，而不是让基站一步到位？因为基站的判断依据太浅：它不知道你的签约、不知道切片实例的实时负载、也不知道跨 PLMN 的映射关系。把这些判断权收到核心网统一裁决，基站只负责“尽量猜准”，猜错了有纠错机制兜底。这和调度系统里“边缘做快决策、中心做准决策”的分层思想一模一样。

顺带回答一个常见疑问：**AMF 是共享的，SMF 和 UPF 往往是切片专属的。** 移动性管理（你在小区间走动）没必要为每个切片重复一套，共享 AMF 能大幅减少切换信令；而会话和用户面才是业务隔离的主战场，通常每个切片用自己的 SMF/UPF，让数据各走各的门。

## 四、App 怎么被分进包间：URSP 是手机里的点菜规则

前面都还是“注册”层面的事。真正落到“抖音走公网切片、电力抄表 App 走行业切片”这一步，靠的是手机里的一套策略——URSP（UE 路由选择策略）。

原理一句话：**网络把“什么流量进什么切片”的规则表下发给手机，手机上的操作系统或 modem 在每个 App 发起联网时逐条匹配。** 一条 URSP 规则分两半：前一半是“流量描述符”（这个 App 的操作系统 ID？目标 IP 段？目标域名？），后一半是“路由描述符”（匹配上了就建哪个切片、哪个数据网络名的会话）。规则有优先级顺序，从上往下匹配，全不中就落回默认的 Internet 会话：

```mermaid
flowchart TD
    APP["App要联网"] --> Q{"URSP有匹配规则吗"}
    Q -->|有| M["按规则选切片与DNN"]
    Q -->|没有| D["走默认Internet会话"]
    M --> V{"该切片本区Allowed吗"}
    V -->|允许| E["在此切片建PDU会话"]
    V -->|不允许| B["回退默认会话"]
    E --> G["App数据进专属包间"]
```

注意中间那个菱形判断——URSP 规则不是免死金牌。手机按规则请求某个切片，网络依然要在当前注册区检查 Allowed NSSAI：规则说“这个 App 进 URLLC 切片”，但你此刻所在区域该切片没开，那也只能回退。所以现网里“URSP 配了但没生效”的排查，永远要同时看两端：手机有没有收到并应用规则（运营商可通过操作系统通道更新），以及网络在当前位置批没批这个切片。

这一机制的意义在于把切片从“网络侧的技术能力”变成了“面向 App 的可选服务”。主流手机操作系统已经提供了切片 API 和运营商配置通道，应用开发者理论上可以声明“我的业务需要低时延能力”，由操作系统按 URSP 规则去请求对应切片。专网客户拿到的不再只是一张 SIM 卡，而是一套“哪些 App 进哪个包间”的完整分发方案。

## 五、切片和 QoS 流：包间与上菜速度

最后把本文和 QoS 体系的关系钉牢。这两个概念极易混淆，一张表说清：

| 维度 | 网络切片 | QoS 流 |
|---|---|---|
| 身份标识 | S-NSSAI | QFI / 5QI |
| 粒度 | 一整张子网络 | 一条业务流 |
| 协商时机 | 注册时协商一次 | 每条会话、每条流都可设 |
| 典型生命周期 | 天到月，随合同 | 会话级，分钟到小时 |
| 承诺内容 | 资源隔离、专属网元、专属策略 | 时延、速率、丢包等具体指标 |
| 类比 | 包间 | 包间里的上菜速度 |

两者的关系是**包含**而不是并列：一条 PDU 会话必须绑定一个切片（Selected NSSAI），而一条会话里可以同时跑多条 QoS 流。切片决定“你在哪间屋、这间屋和别的屋隔不隔音、有没有专属服务员”；QoS 流决定“这道菜几分钟上桌、凉了算谁的”。同一个工厂切片里，机械臂控制流用 GBR 流保障，视频监控流用非 GBR 流尽力而为——包间相同，上菜待遇不同。

反过来，为什么有了 QoS 还要切片？因为 QoS 修改不了三样东西：**网元的部署位置**（UPF 放不到园区里）、**数据的转发路径**（走不了专用传输）、**故障和攻击的波及范围**（隔壁业务拥塞照样殃及你）。切片恰恰是把这三样也圈进来——它卖的是“一整张子网络”，而 QoS 卖的是“队列里的优先级”。

## 六、现网连接：调试时这套知识用在哪

- **抓注册 NAS 信令看切片协商**。定位专网用户“进不了切片”时，第一件事是看注册请求里的 Requested NSSAI 和注册接受里的 Allowed NSSAI。Allowed 为空但 Requested 正常，问题大概率在签约（该用户没订这些切片）或 NSSF 侧的裁决，而手机侧日志永远不会显示原因——Subscribed 清单只在网络内部流转，UE 根本看不到。
- **SD 错配是高发故障**。同一个 SST、不同的 SD，就是两个完全不同的切片。订单交付时网络侧、SIM 数据、UE 预配置三处 SD 只要有一处对不上，整条 S-NSSAI 就会被拒。跨运营商/跨国场景还要额外做 S-NSSAI 映射，漏配映射的表现就是漫游用户点不进行业切片。
- **“带 SD 的切片号不能出归属网络”** 这条规则解释了很多漫游怪象：拜访地基站不会把非标准 S-NSSAI 用于接入层决策，一切以映射后的本地编号为准。
- **URSP 不生效三板斧**：规则没下发到手机（查策略下发通道）、规则描述符写得太窄没匹配上 App、切片在当前区域不在 Allowed 里被迫回退。三个原因各占三分之一，顺序排查。
- **Pending 状态别当故障**。行业切片常带切片级二次认证，认证流程走完前切片挂起是正常设计，别急着改配置。

## 常见问题

**Q: SST 相同、SD 不同，算两个切片吗？**
A: 算。SD 就是在同一“菜系”里区分不同包间的编号，SST=2/SD=0x01 和 SST=2/SD=0x02 是两个独立切片，资源、网元、策略都可以完全不同。但注意：一旦带 SD，这个编号就是运营商本地方言，不具备跨网络含义。

**Q: 手机注册时不带任何切片请求，网络会怎么处理？**
A: 网络可以照样下发 Allowed NSSAI（运营商可配置默认切片），后续建会话时由网络代为指定默认切片。也就是说“不点菜”不等于“吃不上饭”，店家会按你本来的套餐安排。

**Q: 切片能保证我的带宽吗？**
A: 切片承诺的是隔离和专属资源边界，具体速率仍由切片内的 QoS 流兑现——GBR 流给硬保障，非 GBR 流给公平调度。验收专网时，切片级 SLA 和流级 QoS 参数要分别核对，缺一不可。

**Q: 切片和 5G 专网是一回事吗？**
A: 不是一回事，但切片是实现专网的主流方式之一。专网还可以用独立频谱、独立基站等物理方式实现；切片的价值在于用一张公网的基础设施，虚拟出多张逻辑专网，成本低、开通快，代价是隔离强度依赖实现水平。

**Q: 4G 时代没有切片，运营商怎么隔离业务？**
A: 靠 APN 接入不同网关。但 APN 只能控制网关之后的那段路，管不到无线侧和接入网资源；切片是端到端的，从基站调度器到核心网到传输网都在同一张配置蓝图里，这正是两者本质的差别。

## 参考来源

1. [5G network slicing - Wikipedia](https://en.wikipedia.org/wiki/Network_slicing) — 切片定义、隔离特性、5G核心网各功能（含 NSSF）职责与共享/专属部署方式
2. [5G Network Slicing - ShareTechnote](http://www.sharetechnote.com/html/5G/5G_NetworkSlicing.html) — S-NSSAI 结构、标准 SST 值表、各类 NSSAI 数量上限、注册信令与 AMF 重定向流程及实网日志
3. [5G network slicing - Android Open Source Project](https://source.android.com/docs/core/connect/5g-slicing) — 安卓对切片与 URSP 规则的支持、运营商配置流量描述符的方式
4. [GSMA NG.141 Guidelines for URSP (PDF)](https://www.gsma.com/newsroom/wp-content/uploads/NG.141-v3.0-2.pdf) — 运营联盟侧的 URSP 实施指南：规则设计、与注册/会话流程的配合
5. [How 5G network slicing works: part 2 - 5G Technology World](https://www.5gtechnologyworld.com/how-5g-network-slicing-works-part-2/) — S-NSSAI 与 URSP 规则如何配合决定 UE 接入哪个切片

---
> 本文由「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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
