打开手机设置，你看到的还是那个熟悉的信号格。但在网络内部，同一个基站、同一套核心网，可能正在同时服务着几张彼此隔离的“虚拟专网”——工厂的机械臂、电网的差动保护、你刷的短视频，各走各的门。大多数讲切片的文章都在讲“墙是怎么砌的”（资源隔离），本文要讲的是另一件事：你是怎么被分进那间包间的。一个手机开机时说了什么，网络怎么审核，谁来拍板，点菜之后为什么还会被中途换桌——这条“切片选择链路”是现网专网开局和故障定位时最常用到、却最少被讲透的原理。
要去包间，先得有包间号。5G 里每个切片的身份标识叫 S-NSSAI（单网络切片选择辅助信息），它只有两段，短得惊人：
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 私有性”权衡：
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，谈专网订单时对齐的就是它。
如果说 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 个 |
把这张表翻译成餐厅语言：
为什么要拆得这么碎？因为点菜的意愿、吃饭的资格、今天灶上的余量，是三个独立的信息源。手机想要什么（可能来自 App 或操作系统）、运营商给这个用户签了什么（商用合同）、网络此刻在这个位置能伺候什么（覆盖与容量），任何一方的信息单独决策都会出错。所以协议把三次信息交汇设计成了显式的协商流程：
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。有些行业切片要求在入网前做切片级的二次认证（相当于包间还要再验一次工牌），认证没做完之前，这个切片既不算同意也不算拒绝，先挂起。现网专网调试时，如果发现某切片“有时能用有时不能用”，先查查是不是切片认证流程还没收敛。
协商流程里藏着 5G 切片机制最精巧、也最少被科普的一环：注册进行到一半，服务你的 AMF 可能会换人。
要理解它，得先看基站的角色。手机发注册请求时，基站要先决定“把这条信令递给核心网里的哪个 AMF"。基站手里有两个线索：手机旧的中临时标识（里面编码了上次服务的 AMF 信息），以及注册请求里带的 Requested NSSAI。基站会尽量挑一个能服务这些切片的 AMF——也就是说，切片选择在你还没进核心网大门时就已经开始了。找不到线索时，就交给一个默认 AMF。
问题在于：基站只看得到“菜单”，看不到“后厨实际排班”。默认 AMF 收到请求后，去问专门的裁判——NSSF（网络切片选择功能），把手机想点的切片、签约数据、当前位置报上去。NSSF 裁决两件事：这批切片该给哪些，以及这单该由哪个 AMF 组来管。如果当前 AMF 不在目标名单里，就要换桌：
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（UE 路由选择策略）。
原理一句话：网络把“什么流量进什么切片”的规则表下发给手机，手机上的操作系统或 modem 在每个 App 发起联网时逐条匹配。 一条 URSP 规则分两半：前一半是“流量描述符”（这个 App 的操作系统 ID？目标 IP 段？目标域名？），后一半是“路由描述符”（匹配上了就建哪个切片、哪个数据网络名的会话）。规则有优先级顺序，从上往下匹配，全不中就落回默认的 Internet 会话：
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 流 |
|---|---|---|
| 身份标识 | S-NSSAI | QFI / 5QI |
| 粒度 | 一整张子网络 | 一条业务流 |
| 协商时机 | 注册时协商一次 | 每条会话、每条流都可设 |
| 典型生命周期 | 天到月，随合同 | 会话级，分钟到小时 |
| 承诺内容 | 资源隔离、专属网元、专属策略 | 时延、速率、丢包等具体指标 |
| 类比 | 包间 | 包间里的上菜速度 |
两者的关系是包含而不是并列：一条 PDU 会话必须绑定一个切片（Selected NSSAI），而一条会话里可以同时跑多条 QoS 流。切片决定“你在哪间屋、这间屋和别的屋隔不隔音、有没有专属服务员”；QoS 流决定“这道菜几分钟上桌、凉了算谁的”。同一个工厂切片里，机械臂控制流用 GBR 流保障，视频监控流用非 GBR 流尽力而为——包间相同，上菜待遇不同。
反过来，为什么有了 QoS 还要切片？因为 QoS 修改不了三样东西：网元的部署位置（UPF 放不到园区里）、数据的转发路径（走不了专用传输）、故障和攻击的波及范围（隔壁业务拥塞照样殃及你）。切片恰恰是把这三样也圈进来——它卖的是“一整张子网络”，而 QoS 卖的是“队列里的优先级”。
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 只能控制网关之后的那段路，管不到无线侧和接入网资源；切片是端到端的，从基站调度器到核心网到传输网都在同一张配置蓝图里，这正是两者本质的差别。
本文由「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 等场景全覆盖。