企业官网建设流程全解析

简介：一份专门围绕5G核心网端到端网络切片专题的PPT课件，内容覆盖网络切片概念、差异化业务需求与切片管理三大模块，适合5G网络工程师、通信专业学生及相关技术人员系统学习。课件开篇梳理NGMN、5G-PPP等电信标准组织提出的开放网络架构框架，明确网络切片应对移动宽带、海量物联网和任务关键性物联网三类典型场景；随后讲解无线侧协议栈功能模块分离订制裁剪、核心网切片灵活定制等关键实现思路，呈现出满足差异化业务的端到端闭环方案，并给出切片管理的基本逻辑。压缩包内共1个pptx文件，大小4.12MB，页面结构紧凑、知识条理清晰，可用于自学整理、课程展示或内部技术分享。目前已有1045人学习下载，对希望快速建立5G网络切片整体认知、厘清切片技术脉络的读者有较好参考价值。

1. 5G 端到端网络切片到底在切什么：先想清楚「给谁切、在哪切、怎么验证」

打开标题里这份「5G核心网关键技术-5G端到端网络切片.pptx」时，别急着翻页找结论。真正值钱的不是 PPT 里的架构图，而是你照着它把切片在现网或实训环境里跑通的过程。网络切片并不是把物理网线剪断，而是同一个 5G 无线接入网、传输网和核心网上，隔离出多张互相独立的逻辑网络，每张网有自己的 AMF、SMF、UPF 和无线资源调度策略。最容易被低估的「端到端」三个字，才是难点所在：RAN、传输、核心网三段都在切，而三段的协同全靠 S-NSSAI 这一个标识符牵着走。这篇笔记适合三类人——刚接手 5G 核心网调测的工程师、给政企客户做专网方案的售前/交付人员、以及搭 5G 实训室的讲师，目标是看完能动手配出一套可验证的双切片环境，而不是只记住概念。

2. 把端到端切开看：RAN、传输、核心网三段各自切什么、怎么协同

2.1 RAN 侧：S-NSSAI 如何映射到 QoS Flow 和 DRB

无线侧是最容易被误读的一段。很多人以为「RAN 切片」就是给不同业务分配不同带宽，实际上 RAN 做的是两件事：一是把核心网下发的 S-NSSAI（Slice/Service Type + Slice Differentiator）识别出来，二是把用户面的 QoS Flow 映射到无线承载（DRB）上，再对不同类型的承载执行不同的调度优先级和资源预留策略。

从协议栈角度看，UE 在注册请求里带上 Requested NSSAI，gNB 把这个信息透传给 AMF，AMF 返回 Allowed NSSAI 后，gNB 才能在后续的 RRC 重配置里给这个切片建立对应的 DRB。也就是说，RAN 只负责「按切片标识做承载映射和调度」，而「这个切片允不允许、对应哪个核心网实例」是核心网的决定权。这也是为什么很多实训环境里，UE 明明配了 S-NSSAI 却始终不是一个切片——因为 gNB 收到的 S-NSSAI 是透传的，它本身不校验，真正的校验点在 AMF 和 NSSF。

常见做法是给 eMBB、URLLC、mMTC 三类业务分别定义 SST=1、2、3，再通过 SD 区分同一种服务类型下的不同客户。SST=1 的对象性大带宽业务，调度策略偏向 RB 数拉满；SST=2 的对象性低时延业务，调度策略偏向短周期调度和更高的优先级；SST=3 的面向海量连接，允许更长的非活动定时器。你自己规划时，SST 尽量沿用 3GPP 约定值，SD 留给私有区分，否则容易在对接其他厂家设备时出现识别冲突。

2.2 传输侧：FlexE、SR-TE 与 VLAN 怎么承载切片的带宽隔离

传输侧切的是「管道」。核心网网元之间的 N2/N3/N4/N6 接口流量都走承载网，同一个物理链路里如果只有 VLAN 隔离，只能做到逻辑分隔，带宽还是共享的——这就是「逻辑切片」和「硬切片」的差别。真正要保障互不抢占，第一步是引入灵活以太网（FlexE）把物理口切成多个子接口，每个子接口对应一个切片；第二步是在承载网上用 SR-TE 或 FlexE 通道分别规划路径，让不同切片的业务走不同转发路径。

实训环境里一般不会上 FlexE 设备，最常见的操作是「用 VLAN + QoS 队列模拟」。核心网规划 IP 的时候把每张切片的 N3/N4 接口地址段分开，gNB 到 UPF 的用户面流量打上不同 VLAN TAG，然后在交换机上做优先级队列映射。这里有个容易翻车的点：VLAN 划分解决的是二层逻辑隔离，但如果接入交换机的端口缓存是共用的，某个切片的突发流量仍可能把另一个切片的时延抬高。所以传输侧做完隔离后，必须做打流验证，不能只看配置界面里「已隔离」三个字。

2.3 核心网侧：AMF、NSSF、SMF、UPF 在一张图里的分工

核心网侧才是端到端切片的主战场。AMF 是入口：UE 注册时把 Requested NSSAI 带给 AMF，AMF 不能自己拍板这个切片能不能用，而是把请求送给 NSSF 做切片选择，NSSF 根据 AMF 的 TA（Tracking Area）、签约数据、切片可用性，返回 Allowed NSSAI。这段交互在 5G 协议栈里属于 NAS 层的注册流程，但执行逻辑在 NSSF，所以很多人查了一遍 AMF 配置也找不到问题，最后发现是 NSSF 的策略没写好。

SMF 和 UPF 是用户面切片的执行者。SMF 负责根据 S-NSSAI + DNN 选择 UPF，并把 QoS 策略下发到 UPF。UPF 则是真正转发用户数据的网元，每张切片可以对应一个独立 UPF 实例，也可以是同一 UPF 上的不同逻辑接口。实际部署时，「切片 + DNN」的组合决定了 PDU 会话落在哪个 UPF。下表是我在规划时常用的对应关系：

这里要强调的是「端到端」三个字的代价：RAN 侧的 DRB 映射、传输侧的 FlexE/队列、核心网侧的 NSSF 决策和 UPF 选择，任何一段没对齐，最终呈现出来的就是「核心网说切片建成了，业务侧却感觉完全没变化」。所以后面第三、四、五章里，我会把配置、踩坑和验证按这个三段链路展开。

3. 从零配置一个 5GC 双切片环境：S-NSSAI、AMF/NSSF 与 PDU 会话的最小可跑配置

3.1 先定 S-NSSAI 规划：SST/SD 的取值习惯

动手前先定两张表，否则后面改配置会改到怀疑人生。第一张是切片与业务映射表，第二张是切片与核心网网元的路由表。实训环境我一般用两个切片起步：eMBB 用{SST=1, SD=0x010001}，URLLC 用{SST=2, SD=0x010001}。SST=1/2 都是 3GPP 标准值，SD 取 0x010001 作为两个切片公共的私有标识，这样后续接 UE 模拟器时不用在终端侧做太多定制。

规划时还要同步做的事情是核心网 IP 规划。常见做法是把 AMF 的 N2 地址、SMF 的 N4 地址、UPF 的 N3/N4 地址分别预留独立网段，并且让「切片 1 的 UPF 地址」和「切片 2 的 UPF 地址」从不同子网取。原因很简单：双切片调试时，你需要在 UPF 侧通过 IP/TEID 快速判断某个 PDU 会话到底被分流到了哪个切片。如果两个切片的 UPF 地址段重叠或过于接近，抓包定位会很痛苦。

3.2 AMF 与 NSSF 配置：默认切片与请求切片的取舍

在开源核心网里做双切片，最省事的路径是 Free5GC + UERANSIM，或者 OAI 5G 核心网 + gNB/UE 模拟器。OAI 5G 协议栈覆盖更全，但编译时间更长；Free5GC 上手快，切片配置逻辑清晰，适合先跑通再深挖。下面是 Free5GC AMF 配置的关键片段（按常见版本整理，字段含义以你用的版本实际为准），先看 AMF 侧的amfcfg.yaml：

plmnList: - mcc: "505" mnc: "01" tac: "000001" nssai: - sst: "01" sd: "010001" dnnList: - "internet" - "eMBB" - sst: "02" sd: "010001" dnnList: - "urllc001"

这段配置的用意有两层：一是告诉 AMF，在这个 PLMN 和 TAC 下可以对外提供两个切片；二是把切片和 DNN 绑定，后续 SMF 做 PDU 会话选路时，需要同时匹配 S-NSSAI 和 DNN。注意sst字段在不同版本里可能是整数也可能是十六进制字符串，你配置时务必先翻一下自己那份版本的 schema，否则 AMF 启动时不会报错，但 NSSF 选择时永远匹配不上。

接着是 NSSF 的nssfcfg.yaml，它管的是「哪些切片在这个 Tracking Area 里可用」：

nssfConfig: - nfId: "nssf-1" amfList: - "amf-1" taiList: - plmnId: mcc: "505" mnc: "01" tac: "000001" sliceInfo: - sst: "01" sd: "010001" - sst: "02" sd: "010001"

这里最关键的是taiList：如果 UE 注册时所在的 TAI 不在 NSSF 的列表里，NSSF 会返回「切片不可用」，AMF 就只能给 UE 分配默认切片。很多人配置了双切片但 UE 拿不到 URLLC，十有八九是这里少了taiList或者 PLMN 拼写错误。NSSF 的作用是「门卫」，AMF 是「前台」，前台再热情，门卫不放行也没用。

3.3 SMF/UPF 多实例与 PDU 会话建立过程

双切片要真正生效，SMF 和 UPF 也得能区分会话。第一种做法是每张切片一个独立 SMF/UPF 实例，隔离最彻底；第二种是同一 SMF 配两个 UPF，靠 S-NSSAI + DNN 做分流选择。实训环境我推荐第二种，省资源且排错路径短。先在 SMF 配置里定义两个 UPF：

upfList: - name: "upf-embb" host: "192.168.30.101" n4Port: 8805 dnnList: - name: "eMBB" sNssaiList: - sst: "01" sd: "010001" - name: "upf-urllc" host: "192.168.30.102" n4Port: 8805 dnnList: - name: "urllc001" sNssaiList: - sst: "02" sd: "010001"

这样 SMF 收到 PDU 会话建立请求后，会根据请求里的 S-NSSAI 和 DNN，把 N4 会话建立到对应的 UPF。如果两个切片都用同一个 DNN 名，SMF 就只能靠 S-NSSAI 区分；如果 DNN 也不同，混淆概率会大幅下降。这就是为什么我在 3.1 节里强调要把internet、eMBB、urllc001这种命名空间提前划分好。

PDU 会话建立的核心流程是：UE 发起 PDU Session Establishment Request（携带 S-NSSAI 和 DNN）→ AMF 基于注册时的 Allowed NSSAI 校验请求 → AMF 把请求转给 SMF → SMF 查 UPF 列表创建 N4 会话 → SMF 回 N1N2 Message Transfer 到 AMF → AMF 向 gNB 下发 N2 PDU Session Request 建立数据面。整个链路里任何一环的 S-NSSAI 不匹配，都会导致会话建立失败。

3.4 用 UE 模拟器触发注册与建会话：最小启动命令

UERANSIM 里改两个文件的参数就能让 UE 请求指定切片。gnb侧配置主要是 PLMN 和 TAC 要和 AMF 一致；ue侧配置关键是requestedNssai：

# gnb.yaml 关键段 plmn: mcc: "505" mnc: "01" tac: 1 amfConfigs: - address: 192.168.20.2 port: 38412 # ue.yaml 关键段 supi: 'imsi-505010000000001' requestedNssai: - sst: 1 sd: 0x010001

启动顺序有讲究，我一般会按「核心网各网元 → gNB → UE」来。核心网里 AMF 要先起来并完成 NRF 注册，SMF/UPF 才能被找到；gNB 起来后要和 AMF 建立 N2 连接；UE 再向 gNB 发起 RRC 和 NAS 注册。用 UERANSIM 的话，播放命令通常是：

# 终端1：启动核心网各网元（按各自项目脚本） ./free5gc-amf & ./free5gc-smf & ./free5gc-upf & # 终端2：启动 gNB ./nr-gnb -c gnb.yaml # 终端3：启动 UE ./nr-ue -c ue.yaml

跑起来后，重点看两个日志：UERANSIM UE 侧出现的Registration complete表示注册成功，PDU Session Establishment表示建会话成功；核心网 AMF 侧出现[NAS] Registration request和S-NSSAI相关打印，说明请求真的到了 5GC。如果注册成功但会话失败，不要急着改核心网，先回看 3.2 里的 DNN 是否配了，因为 UERANSIM 默认 DNN 是internet，而 URLLC 切片绑的 DNN 是urllc001，不匹配时 SMF 会直接报错。

4. 端到端切片落地避坑：从注册到建会话的 5 个真实翻车点

4.1 现象：UE 一直留在默认切片，自定义切片永远不生效

现象就是注册流程走完了，Allowed NSSAI 里只有默认切片，你配置的 URLLC 像不存在一样。先别怀疑核心网代码，按顺序查三处：第一，AMF 的plmnList.tac和 gNB 配置的tac是否完全一致，TAC 不一致时 AMF 会认为该区域不支持这个切片；第二，NSSF 的taiList里有没有覆盖当前 TAC，覆盖范围写错一个字都会让 NSSF 返回不可用；第三，签约数据里给 UE 订的subscribedNssai是否包含目标切片，很多实训环境直接修改 UE 的 requestedNssai 就以为能绕过去，但核心网侧签约数据没配，AMF 会按「未签约切片」拒绝。

原因层面，注册流程的决策链路是：UE 请求 → AMF 查 NSSF 得可用切片 → 再对照签约数据 → 算交集成 Allowed NSSAI。任何一段不匹配，AMF 都不会把切片下发。解决方法是先抓 NAS 层信令，从 Registration Request 里读实际请求的 S-NSSAI，再从 Registration Accept 里读 Allowed NSSAI，两份对比后缺哪段补哪段。不要凭印象改配置，这条经验我踩了不下三次。

4.2 现象：PDU 会话建立失败，SMF 日志报「no UPF found」或「DNN not supported」

这个现象最迷惑人，因为 AMF 和 gNB 都显示正常，核心网日志也看不到明显异常，最后发现是 SMF 的upfList里某个切片只绑了一个 DNN，而 UE 发起 PDU 会话请求时携带的是另一个 DNN。比如你的 URLLC 切片绑的是urllc001，但 UE 侧默认请求internet，SMF 遍历 UPF 列表时发现没有 UPF 同时匹配「SST=2 + DNN=internet」，直接拒绝。

原因本质是 PDU 会话建立和切片绑定是两套评判标准同时生效，只要一个不满足就失败。解决时建议先把 UERANSIM 的 UE 配置里apn（有的版本叫dnn）显式改成目标 DNN，然后在 SMF 日志里搜 DNN 关键字确认收到的值。如果你不想让 UE 配置太绕，也可以把两个切片的 UPF 都同时绑internet和专用 DNN，但这样做会让后续的 UPF 选择变得不可控，生产环境不建议。

4.3 现象：RAN 侧不识别切片，gNB 报「Unsupported S-NSSAI」

现象是 UE 注册成功，但 RRC 重配置里没有为目标切片建立 DRB，gNB 日志直接打 Unsupported S-NSSAI。很多工程师第一反应是去改核心网，实际上 gNB 根本不解析切片的合法性，它只是把 S-NSSAI 和 TAC 关联起来判断「这个区域是否支持」。如果你的 gNB 配置里只有默认 TAC 下的公共切片集合，而 UE 在另一个 TAC 下发起 URLLC 请求，gNB 就会报不支持。

原因在 RAN 侧的切片可用性列表没有和核心网对齐。解决方法是把 gNB 的tac、plmn与 AMF/NSSF 完全对齐，并确认 gNB 侧是否配置了切片到调度策略的映射。RAN 真正能做的隔离是「给不同切片配置不同 5QI 的调度权重」，所以建议同时给 URLLC 切片在 gNB 侧绑定一个低时延的 5QI（比如 5QI=82/83），而不是让所有切片共享默认 5QI。

4.4 现象：核心网和 UE 模拟器信令不一致，SST 值一个显示 1 一个显示 01

这个坑小但极其常见。不同开源版本对 S-NSSAI 的编码处理并不统一：有的配置文件里sst: 1表示十进制 1，有的sst: "01"表示十六进制 0x01，还有的在信令抓包里显示为SST=1, SD=0x010001。如果你 AMF 配的是sst: "01"，UE 侧配的是sst: 1，两者可能都能被解析，但 NSSF 在做精确匹配时会出现「看着一样，实际不同」的诡异问题。

解决方法是统一约定：配置文件全部写成同一个进制风格，核心网与 UE 模拟器保持一致；抓包确认时不看字符串，看 Wireshark 里解码后的实际数值。另一个相关坑是 SD 字段，如果 SD 为全 0，有的协议栈实现认为「没有 SD」，有的则认为「SD=0x000000」，两者在底层判等时结果不同。规避方式就是别用全 0 SD，给它一个明确的非零值。

4.5 现象：两个切片都建好了，但业务流量互相抢占，URLLC 时延并不低

这个现象说明你只做了「逻辑切片」，没做「资源切片」。核心网侧切片建好，只代表两张网络拓扑是分开的，但如果 RAN 侧调度权重一样、传输侧 VLAN 优先级没配、UPF 的处理资源共享，URLLC 切片的低时延根本保障不了。最典型的情况是：用 iperf 给 eMBB 切片灌满带宽，再 ping URLLC 切片的地址，时延从 2ms 涨到 20ms。

原因涉及三层：RAN 调度默认还是 QCI 对应的公平调度；传输交换机队列默认按普通 IP 优先级；核心网侧 CPU/网卡没有做 CPU 绑核和中断分离。解决思路是逐步收拢：先在 RAN 给 URLLC 配 5QI=82 并调高调度优先级，然后在传输交换机上给这两个 VLAN 分别打严格优先级队列，最后在 UPF 侧给 URLLC 所在的进程做网卡多队列绑定。到这一步能做到什么程度，取决于设备能力和预算，评估方案时要向客户把「逻辑隔离可以做到认证、业务、计费全分离，但物理隔离才算硬切片」这个边界讲明白。

5. 切片做没做成，怎么验证：从信令抓包到业务时延的一整套检查清单

5.1 注册流程里抓 NSSAI：信令面的关键信息在哪看

验证切片的第一步永远是看信令，而不是看业务。拿 tcpdump 在 AMF 和 gNB 之间的 N2 口抓包，或者直接在 UE 模拟器日志里看 NAS 消息。注册请求和响应里的三个字段你要盯住：Registration Request 里的 Requested NSSAI，Registration Accept 里的 Allowed NSSAI，以及如果有额外条件时的 Configured NSSAI。Allowed NSSAI 是最终裁决，它的内容直接决定后续 PDU 会话能不能带这个切片。

用 tshark 过滤 NGAP 层的 S-NSSAI 字段时，命令大致是这样：

tshark -r register.pcap -Y "ngap" -T fields \ -e ngap.messageType \ -e ngap.s_NSSAI.sST \ -e ngap.s_NSSAI.sD \ -e ngap.allowed_NSSAI

不同 Wireshark 版本对 NGAP 字段的命名可能不同，但思路一致：先解出每条 NGAP 消息里带的 S-NSSAI，再人工核对请求和接受的对应关系。如果请求里是 SST=2、SD=0x010001，接受里变成 SST=2、SD=0x000000，说明核心网把 SD 丢掉了或转换出错，这时候要去查 NSSF 的 sliceInfo 配置，而不是查 gNB。

5.2 UPF 流表与会话建立验证：确认 PDU 会话落在了正确的切片上

信令面没问题不代表数据面没问题。PDU 会话建立成功后，UPF 上会多一条 N4 会话对应的转发规则。在 Free5GC 里可以用free5gc-upf配套的 CLI 查询，OAI 5G 里则直接看spgwu日志中的 F-TEID 与 PDR/FAR 信息。验证要点有三个：看 UL F-TEID 和 DL F-TEID 是否与 gNB 侧一致，看 S-NSSAI 是否被正确关联到了这条转发规则，看 QoS 参数（比如 MBR/GBR）是不是你规划的值。

如果两个切片分别跑在两个 UPF 上，验证就更清楚了：互相对端发一个 PDU ping，然后在两个 UPF 的日志里分别看有没有流量经过。如果发现两个切片的流量都走同一个 UPF，但你配置了两个 UPF，多半是 SMF 的upfList绑定关系没生效，或者是 AMF 选 SMF 时用的 discover 条件没写 S-NSSAI。

5.3 业务面打流验证：ping、iperf 与峰值速率的粗略换算

业务面验证的常规组合是「ping 测时延抖动 + iperf 测吞吐」。ping 要统计的不是平均时延，而是最大时延和抖动，这两个值对 URLLC 切片才是决定性的。iperf 测试建议区分上行和下行，因为 RAN 侧上下行调度器行为不同，gNB 给上行分配的 RB 数往往受 UE 能力限制。用 iperf3 打流时，一个常用的命令组合是：

# UPF 侧作为服务端 iperf3 -s -p 5201 # UE 侧作为客户端，测上行吞吐，10 秒，并发 4 流 iperf3 -c 192.168.30.101 -p 5201 -u -b 100M -t 10 -P 4

打流的同时，在传输侧交换机或 UPF 网卡上抓包，确认不同切片的流量确实打在期望的 VLAN/队列上。顺带提一下「5G 峰值速率计算公式」在方案里的正确用法：峰值速率（Mbps）约等于有效带宽（MHz）乘以频谱效率（bps/Hz）再乘以一个小于 1 的开关损耗系数，实际计算要考虑调制阶数、层数、PDCP/RLC 开销等因素，所以别拿理论峰值去向客户承诺。做切片带宽规划时，我会先把单用户需求峰值、99% 保障速率和缓存型业务平均速率分开列出来，再按「峰值速率换算带宽需求 + 预留 20% 弹性」来定每张切片的 FlexE 子接口带宽。

5.4 双切片对比验证：同一终端在两个切片间的切换路径

实训环境里最有说服力的一套验证流程是：用 UERANSIM 启动两个 UE 实例，一个请求 SST=1，一个请求 SST=2，让它们同时在同一个 gNB 下完成注册和 PDU 会话建立，然后做三轮测试。第一轮，先对两个切片分别 ping 对端，确认时延基线；第二轮，用 iperf 灌满 eMBB 切片，再测 URLLC 切片的 ping 抖动，观察是否从个位数毫秒级恶化到数十毫秒；第三轮，把传输交换机的队列优先级改掉，对比 URLLC 切片的恶化程度。

这个过程能一次性暴露 RAN 调度、传输队列、核心网分流三段里的短板。验证完成后，把每轮的时延、抖动、吞吐记成一张对账单，比任何 PPT 都更能说服客户这个切片方案是「端到端」可用的。顺便说一句，如果发现改完 RAN 调度参数后 URLLC 时延没有改善，先复查 5QI 有没有真正下达到 gNB，很多开源 gNB 对核心网下发的 QoS 参数只解析不执行，这个黑匣子只能靠打流数据去戳穿。

6. 一个进阶技巧：单机跑双切片实训时，我坚持的验证习惯

实训和现网最大的差别是资源有限。我经常需要在一台物理服务器上把 5GC、gNB、UE 全部跑完，还要模拟出双切片隔离的效果。常见做法是一套核心网跑两个 UE 模拟器，每张 SIM 卡（也就是 UERANSIM 的配置文件）请求不同 S-NSSAI，核心网里配两个 SMF/UPF 上下文，表面上已经「双切片」了。但我会额外加一个动作：在两个 UE 的 PDU 会话都建立成功后，强制修改其中一个切片对应的 UPF 网卡上的流量限速，然后观察另一个切片是否受影响。这个动作能快速检验你是不是只做了「名词切片」，没做「资源切片」。

还有一个从失败里沉淀下来的习惯：改完任何配置后，第一步永远不是重新启动 UE 让注册流程走一遍，然后盯着看霞 — 而是先翻 UE 侧日志里的 Registration Request，确认它实际带出去的 S-NSSAI 和我预期一致。因为很多时候，你以为改的是 UE 配置，实际上改的是核心网另一份配置文件，UE 侧依旧带着旧参数在跑。注册请求里带错切片，后面所有信令和业务验证都是空转，只会把时间浪费在一堆无关日志里。记住这一点，你的切片调试效率会提升非常明显。希望我的这些踩坑和验证习惯，能帮你在自己的 5G 端到端网络切片方案里少走几次弯路。

本文还有配套的精品资源，点击获取