本文聚焦 3GPP TS 28.530(管理与编排:概念、用例与需求)Section 4.3 所定义的切片生命周期四阶段,结合 TS 28.531(Provisioning) 的实例化信令流程与 TS 28.533(编排模型与流程) 的分解编排机制,逐步拆解一个端到端 Network Slice Instance(NSI)从业务需求录入到部署激活、再到退役释放的完整管理面信令链路。这是切片"运行态信令"(如 UE 注册、PDU 会话建立、UL CL 分流)的上游前提——没有管理面的实例化部署,就没有运行态可供 UE 接入。
过去在"51学通信"前序文章中,我们已经拆解了 UL CL 上行分流器插入、URLLC 双连接冗余传输、边缘 EASDF 发现等运行态机制。这些机制都隐含一个前提:该切片实例(NSI)已经被成功部署并激活,UE 的 S-NSSAI 才能在 NSSF/AMF 处匹配到一个真正"存在且可用"的切片。
但一个 NSI 是怎么"凭空"出现在网络里的?它由谁创建、如何分解到无线/核心/传输三大域、又如何与 NFV 基础设施协同把虚拟化的 AMF/SMF/UPF 实例拉起来?这一整条链路就是 3GPP SA5 定义的切片管理面(Management Plane) 职责,规范集中在 TS 28.530 ~ 28.545 系列。本文要回答的核心问题是:
一个运营商在 BSS/OSS 下单开通"大上行视频回传切片"后,CSMF/NSMF/NSSMF 三级编排实体之间究竟交互了哪些消息、传递了哪些 IE,才让一个端到端 NSI 真正"上线"?
3GPP 在 TS 28.530 Section 4.2.2(网络切片管理框架原则) 与 TS 28.533 中定义了分层编排架构。需要特别澄清一个常被误解的点:CSMF、NSMF、NSSMF 是非标准化(non-standardized)的功能实体名称——3GPP 在与 IETF 的联络声明(LS)中明确表示,规范标准化的是它们之间的管理服务(MnS, Management Services)与接口能力,而非实体本身的具体实现。
flowchart TB
subgraph 商业层["商业层 / OSS-BSS"]
CSI["通信服务实例<br/>CSI - Communication Service Instance"]
CSMF["CSMF<br/>通信服务管理功能<br/>需求翻译"]
end
subgraph 切片编排层["切片编排层 (E2E)"]
NSMF["NSMF<br/>网络切片管理功能<br/>NSI 生命周期 + 需求分解"]
NST[("NST<br/>网络切片模板")]
NSI[(("NSI<br/>端到端切片实例"))]
end
subgraph 子网编排层["子网编排层 (NSSMF)"]
CNNSSMF["CN-NSSMF<br/>核心网子网"]
RANNSSMF["RAN-NSSMF<br/>无线子网"]
TNNSSMF["TN-NSSMF<br/>传输子网"]
end
subgraph NFV层["NFV 基础设施层 (ETSI ISG NFV)"]
NFVO["NFVO<br/>NFV 编排器"]
VNFM["VNFM<br/>VNF 管理器"]
VIM["VIM<br/>虚拟基础设施管理器"]
VNF["VNF/CNF<br/>AMF SMF UPF PCF..."]
end
CSI -->|"1. 创建通信服务"| CSMF
CSMF -->|"2. NSReq<br/>切片需求"| NSMF
NSMF --> NST
NSMF -->|"3a. CN子网需求"| CNNSSMF
NSMF -->|"3b. RAN子网需求"| RANNSSMF
NSMF -->|"3c. TN子网需求"| TNNSSMF
CNNSSMF -->|"Os-Ma-nfvo<br/>VNF LCM"| NFVO
NFVO --> VNFM --> VIM --> VNF
CNNSSMF & RANNSSMF & TNNSSMF -->|"4. NSSI创建结果"| NSMF
NSMF --> NSI
style NSMF fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
style CSMF fill:#fff3e0,stroke:#ef6c00
style NFVO fill:#e3f2fd,stroke:#1565c0
| 实体 | 规范锚点 | 核心职责 | 典型实现 |
|---|---|---|---|
| CSMF | TS 28.530 §4.2 | 接收业务侧通信服务需求(CSI),翻译为 NSI 需求(NSReq);与 OSS/BSS、客户门户对接 | 运营商 BSS/OSS 北向接口、切片即服务(Slice-as-a-Service)门户 |
| NSMF | TS 28.530 §4.2, TS 28.531 | NSI 端到端生命周期管理;将 NSReq 分解为各域子网需求;决定复用还是新建 NSI;聚合 NSSI 为 E2E NSI | E2E 切片编排器(如 ONAP SO、华为 iMaster NCE、爱立信 5G NMS) |
| NSSMF | TS 28.530 §4.2, TS 28.533 | 管理 Network Slice Subnet Instance(NSSI);CN-NSSMF 通过 Os-Ma-nfvo 接口驱动 NFVO 实例化 VNF | 域级编排器(CN域=MANO/VNFM、RAN域=O-RAN SMO/网管、TN域=SDN控制器) |
| NFVO | ETSI GS NFV-IFA 009/010 | 跨 VIM 的网络服务编排;VNF 生命周期管理(实例化/扩缩容/终止) | OSM、ONAP、OpenStack Tacker |
这是整个机制的规范骨架。TS 28.530 Section 4.3 明确将 NSI 生命周期划分为四个串行阶段,每个阶段有严格的"入口条件"和"产物"。
stateDiagram-v2
[*] --> 准备阶段
准备阶段 --> 实例化阶段 : 模板就绪 +<br/>资源预评估通过
实例化阶段 --> 运行阶段 : NSI激活成功<br/>NSI状态=Activated
运行阶段 --> 运行阶段 : ModifyNSI<br/>扩缩容/修改
运行阶段 --> 退役阶段 : 业务下线/合约到期
退役阶段 --> 准备阶段 : 资源完全释放<br/>(模板可复用)
退役阶段 --> [*]
note right of 准备阶段
TS 28.530 §4.3.2
产物: NEST/NSST
NSI尚不存在
end note
note right of 实例化阶段
TS 28.530 §4.3.3
Instantiation→
Configuration→
Activation
end note
note right of 运行阶段
TS 28.530 §4.3.4
PM/FM监控
容量调整
end note
note right of 退役阶段
TS 28.530 §4.3.5
Deactivation→
Termination
end note
入口条件:NSI 不存在。
核心动作:
- 切片设计:定义 Network Slice Template(NEST),固化切片属性集;
- 容量规划与资源可用性预评估;
- 子网模板(NSST)的准备;
- 输出:一个可被实例化引用的模板库,但此时没有任何运行实例。
设计意图:将"设计"与"实例化"解耦。运营商可预先设计几十种 NEST 模板(eMBB 大上行、URLLC 低时延、mMTC 海量连接……),实例化阶段只需"选模板 + 注入参数",大幅缩短切片开通时间(从天级到分钟级)。
这是本文的信令拆解核心。该阶段内部又细分为三个子动作:
NSI 激活后进入运行态,承担: - 性能管理(PM)与故障管理(FM); - 按需修改(ModifyNSI):容量扩缩容、QoS 调整、覆盖区域变更; - 运行态切片选择:UE 注册时基于 Requested NSSAI 触发 NSSF 选片(TS 23.501 §5.15),这才是与"用户态信令"的衔接点。
下图拆解 TS 28.531(Provisioning)+ TS 28.533(Orchestration) 定义的端到端 NSI 实例化信令流。这是 Commissioning 阶段 "Instantiation + Configuration + Activation" 三动作的完整展开。
sequenceDiagram
autonumber
participant BSS as OSS/BSS门户
participant CSMF as CSMF
participant NSMF as NSMF
participant CNNSSMF as CN-NSSMF
participant RANNSSMF as RAN-NSSMF
participant TNNSSMF as TN-NSSMF
participant NFVO as NFVO
participant VNFM as VNFM/VIM
Note over BSS,NSMF: ① 需求录入与翻译 (Preparation→Commissioning)
BSS->>CSMF: createCommunicationService(CSI需求)
Note right of CSMF: IE: 时延/吞吐/可靠性/<br/>用户数/覆盖/隔离级别
CSMF->>CSMF: 服务需求→NSReq翻译<br/>(TS 28.531)
CSMF->>NSMF: createNSIRequest(NSReq)
Note over NSMF: ② NSMF 决策: 复用 vs 新建
NSMF->>NSMF: 选择NEST模板<br/>评估: Scenario1(复用)/Scenario2(新建)
alt Scenario2 新建NSI
NSMF->>NSMF: 需求分解为CN/RAN/TN子网需求
end
Note over NSMF,TNNSSMF: ③ 子网并行实例化 (Orchestration)
par CN子网
NSMF->>CNNSSMF: createNSSI(CN子网需求+NSST)
CNNSSMF->>CNNSSMF: 选择CN功能<br/>(专用/共享AMF/SMF/UPF)
alt 需新建VNF
CNNSSMF->>NFVO: Os-Ma-nfvo: InstantiateVNF/NS
NFVO->>VNFM: Grant/VNFLCM
VNFM-->>NFVO: VNF实例ID
NFVO-->>CNNSSMF: CN-NSSI创建结果
else 复用共享NF
CNNSSMF->>CNNSSMF: 在共享AMF上配置切片上下文
end
CNNSSMF-->>NSMF: CN-NSSI ID + 配置参数
and RAN子网
NSMF->>RANNSSMF: createNSSI(RAN子网需求)
RANNSSMF->>RANNSSMF: PRB预留/调度策略<br/>切片资源池配置
RANNSSMF-->>NSMF: RAN-NSSI ID
and TN子网
NSMF->>TNNSSMF: createNSSI(TN子网需求)
TNNSSMF->>TNNSSMF: VPN/MPLS隧道建立<br/>端到端连通性
TNNSSMF-->>NSMF: TN-NSSI ID
end
Note over NSMF: ④ 聚合 + NSI配置 + 激活
NSMF->>NSMF: 聚合CN/RAN/TN NSSI→E2E NSI<br/>分配NSI ID + 关联S-NSSAI
NSMF->>NSMF: Configuration: QoS/AMF Set/NSSAI映射
NSMF->>NSMF: Activation: NSI状态→Activated
NSMF-->>CSMF: NSI部署完成通知(NSI ID)
CSMF-->>BSS: 通信服务就绪
Note over NSMF: 此后UE的S-NSSAI方可在NSSF被解析
这是切片开通的起点。CSMF 接收的不是"切片参数",而是业务需求,体现 CSMF"翻译者"的角色。
| IE 名称 | 含义 | 示例值(大上行视频回传切片) |
|---|---|---|
| Service Type | 业务类型 | eMBB / URLLC / V2X |
| E2E Latency | 端到端时延 | < 20 ms |
| UL/DL Throughput | 上下行吞吐(每用户/聚合) | UL 200 Mbps / UE |
| Reliability | 可靠性 | 99.9% |
| Coverage Area | 覆盖区域 | 北京朝阳赛区基站列表 |
| UE Density | 用户密度 | 10,000 UE / km² |
| Isolation Level | 隔离级别 | 资源隔离(非完全专用) |
| Delay Tolerance | 时延容忍度 | 非实时 |
| Availability | 可用性 | 99.95% |
CSMF 将上述业务需求翻译为 NSI 需求(NSReq),这是 TS 28.531 Provisioning 的输入。NSReq 的关键新增 IE:
| IE 名称 | 含义 | 设计意图 |
|---|---|---|
| NSI ID | NSI 唯一标识 | 若 Scenario1 复用,则指向已有 NSI |
| S-NSSAI | 切片类型标识 | 与运行态 TS 23.501 §5.15 衔接的关键锚点 |
| SST/SD | 切片类型/差分器 | SST=1(eMBB), SD=特定值 |
| NSST 引用 | 引用的子网模板 | 实现模板化部署 |
| Slice QoS Profile | 切片级 QoS | 5QI 列表、GBR 参数 |
这是 3GPP 切片管理与 ETSI NFV MANO 互联的唯一标准化接口,定义于 TS 28.533 Annex A.4。CN-NSSMF 作为 MnS 生产者,通过该接口调用 NFVO 的 VNF 生命周期管理(VNFLCM) 能力:
关键 IE:VNF 描述符(VNFD)引用、实例化参数(flavor、镜像、网络连接)、亲和/反亲和规则(决定 AMF Set 拓扑)。
实例化流程的"模板化"能力,依赖 TS 28.540/28.541(NR;网络切片/NSSI 管理信息模型) 定义的信息模型。下图展示 NEST、NSST、NSI、NSSI 与 S-NSSAI 之间的实例化关系:
flowchart TD
subgraph 模板层["模板层 (Design - Preparation阶段)"]
NEST["NEST<br/>Network Slice Template<br/>TS 28.541"]
NSST1["NSST-CN<br/>核心网子网模板"]
NSST2["NSST-RAN<br/>无线子网模板"]
NSST3["NSST-TN<br/>传输子网模板"]
end
subgraph 实例层["实例层 (Commissioning阶段产出)"]
NSI["NSI<br/>端到端切片实例<br/>NSI-ID"]
NSSI1["CN-NSSI"]
NSSI2["RAN-NSSI"]
NSSI3["TN-NSSI"]
end
subgraph 运行态锚点["运行态锚点 (TS 23.501)"]
SNSSAI["S-NSSAI<br/>SST+SD"]
NSSAI["Allowed NSSAI<br/>(AMF下发)"]
end
NEST -->|"实例化"| NSI
NSST1 -->|"实例化"| NSSI1
NSST2 -->|"实例化"| NSSI2
NSST3 -->|"实例化"| NSSI3
NSI -.->|"由3个NSSI聚合"| NSSI1
NSI -.-> NSSI2
NSI -.-> NSSI3
NSI -->|"激活时绑定"| SNSSAI
SNSSAI -->|"UE注册时"| NSSAI
style NEST fill:#f3e5f5,stroke:#6a1b9a,stroke-width:2px
style NSI fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
style SNSSAI fill:#fff9c4,stroke:#f9a825
设计精髓:模板(Template)是"蓝图",实例(Instance)是"建筑"。同一个 NEST 可被实例化多次(如为不同赛区部署同一规格切片),实现一次设计、多次部署。
TS 28.533 与 ONAP 实现中都强调了 NSMF 在实例化前必须做的复用决策。这是切片"按需开通"和"资源高效"的关键:
| 维度 | Scenario1(复用 NSI) | Scenario2(新建 NSI) |
|---|---|---|
| 触发条件 | 新业务需求可由现有 NSI 容量满足 | 现有 NSI 无法满足(隔离/容量/覆盖) |
| 信令开销 | 仅 ModifyNSI(增量配置) | 完整 createNSI 全流程 |
| 资源开销 | 低(共享已有 VNF/PRB) | 高(新建 VNF/专用资源) |
| 部署时间 | 秒级~分钟级 | 分钟级~小时级 |
| 适用场景 | 同一租户追加用户、扩容 | 全新业务类型、强隔离需求 |
| 隔离强度 | 共享隔离 | 资源/服务隔离 |
NSMF 的决策依据是 NST 中预定义的容量上限与隔离要求——若新接入 CSI 的需求叠加后仍不超限,则复用;否则触发新建或扩容。
管理面部署完成后,必须回答:UE 如何"看到"这个切片? 这是管理面与用户面的衔接点,定义于 TS 23.501 Section 5.15。
flowchart TD
A["管理面: NSI激活<br/>NSMF绑定 S-NSSAI"] --> B["运行态: UE开机注册<br/>携带 Requested NSSAI"]
B --> C["AMF→NSSF: 选片请求"]
C --> D["NSSF: 查询已激活NSI<br/>匹配 S-NSSAI"]
D --> E{"NSI是否存在<br/且已激活?"}
E -->|"是"| F["返回 Allowed NSSAI<br/>选定 AMF Set"]
E -->|"否(未部署/未激活)"| G["拒绝/降级到默认切片"]
F --> H["UE接入该切片<br/>PDU会话按切片路由"]
style A fill:#e8f5e9,stroke:#2e7d32
style E fill:#fff9c4,stroke:#f9a825
style G fill:#ffebee,stroke:#c62828
核心耦合点:NSSF 的选片决策依赖管理面已激活的 NSI 列表。若 NSMF 尚未激活某 NSI,NSSF 即使配置了 S-NSSAI 映射,也无法将 UE 路由到该切片——这正是切片开通失败最隐蔽的根因(详见下文排错)。
与用户面(NGAP/NAS/PFCP)不同,管理面信令走的是 SBI(HTTP/2 + JSON) 或 NETCONF/RESTCONF,端口通常为:
识别技巧:在抓包过滤器中按这些 API 的 URL 前缀过滤,例如 /slice-management/v1/nsi、/nslcm/v1/nsi/instantiate。
| 故障现象 | 可能根因 | 排查路径 |
|---|---|---|
| UE 携带 S-NSSAI 注册被拒 | NSI 未激活或 NSSF 配置未同步 | 查 NSMF 是否 Activation 成功 → 查 NSSF S-NSSAI→NSI 映射表 |
| 切片开通后 UPF 未拉起 | CN-NSSMF→NFVO InstantiateVNF 失败 | 查 Os-Ma-nfvo 接口返回码 → 查 VIM 资源池余量 |
| 端到端不通但 CN/RAN 各自正常 | TN-NSSMF 隧道未建立 / 端到端连通性缺失 | TN 域查 VPN/MPLS 隧道状态 → 三域 NSSI 拓扑关联 |
| 实例化超时 | 三域并行但某域(如 TN)串行瓶颈 | 查 NSMF 是否并行下发 → 查各 NSSMF 响应时延 |
| 复用决策错误导致拥塞 | NSMF Scenario1/2 判断逻辑缺陷 | 查 NST 容量上限配置 → 查 NSMF 复用算法 |
| ## 十、与其他编排方案的对比 |
| 维度 | 3GPP NSMF/NSSMF(TS 28.53x) | ETSI ZSM(零接触管理) | ONAP 切片编排 |
|---|---|---|---|
| 标准化主体 | 3GPP SA5 | ETSI ISG ZSM | Linux 基金会 |
| 核心实体 | CSMF/NSMF/NSSMF | 管理域+跨域协调器 | SO(CSMF/NSMF)+DCAE+SDNC |
| 与 NFV 关系 | 通过 Os-Ma-nfvo 解耦 | 抽象管理接口 | 内嵌 NFVO/VNFM |
| 标准化程度 | 接口能力标准化,实体非标准化 | 架构框架标准化 | 开源实现,事实标准 |
| 适用场景 | 3GPP 5G 切片原生 | 多厂商端到端自动化 | 运营商云网协同 |
Q1: NSMF 的"复用 vs 新建"决策(Scenario1/Scenario2)依据什么?
A: 依据 NST 模板中预定义的容量上限和隔离级别。NSMF 在收到 NSReq 后,先评估现有同类型 NSI 的剩余容量是否满足新需求且不违反隔离约束:满足则 Scenario1(复用,仅 ModifyNSI);否则 Scenario2(新建,走完整 createNSI)。这是切片按需开通与资源高效的平衡点。
Q2: 切片部署后 UE 仍注册不上,是不是切片没真正激活?
A: 很可能是。需检查链路:①NSMF Activation 是否成功(NSI 状态=Activated);②NSSF 的 S-NSSAI→NSI 映射是否同步;③AMF 是否已加载该切片上下文。三者任一缺失,UE 的 Requested NSSAI 都会落空。这是管理面与用户面最易脱节的耦合点。
Q3: CN-NSSMF 和 NFVO 是什么关系?必须经过 NFVO 吗?
A: 当切片需要新建专用 CN 功能实例(如专用 UPF/SMF)时,CN-NSSMF 必须通过 Os-Ma-nfvo 接口(TS 28.533 Annex A.4)调用 NFVO 完成 VNF 实例化。若切片只是复用共享 NF(如共享 AMF),则 CN-NSSMF 仅需在该共享网元上配置切片上下文,无需调用 NFVO。
Q4: NEST/NSST 模板和运行态的 S-NSSAI 是什么关系?
A: NEST/NSST 是管理面的设计模板(Preparation 阶段产物);S-NSSAI 是运行态的切片标识(SST+SD)。激活 NSI 时,NSMF 将二者绑定——NSI 获得 NSI ID 同时关联 S-NSSAI。此后 UE 在运行态用 S-NSSAI 寻址切片,最终映射回管理面的 NSI 实例。
Q5: 切片实例化和切片选择是同一个流程吗?
A: 完全不是。实例化是管理面 NSMF/NSSMF 的部署流程(TS 28.53x),让 NSI"存在且可用";选择是用户面 UE 注册时 NSSF/AMF 的运行态流程(TS 23.501 §5.15),让 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 等场景全覆盖。
