解决方案

网络功能虚拟化被称为NFV
（Network Functions
Virtualization），而虚拟化之后的
网络功能被称为VNF
（Virtualized Network
Function）。
当我们谈“VNF”时，我们指
MME、S-GW、P-GW、CG这些传
统网元在虚拟化之后的实现。在硬
件通用化后，传统的网元不再是嵌
入式的软硬结合的产品，而是以纯
软件的方式安装在通用硬件（即
NFVI）上。传统网元变成了一个个
应用程序——APP，使用软件逻辑
完成一定的网络功能。
APP实在太低端，还是称作VNF
吧。

P1
01 传统的网元结构
传统网元处理板（进程）基于用户的状态对用户
消息进行处理。例如：

1. 用户在创建承载时，首先查询用户已有的上下
文信息，决定对用户进行什么样的处理：是否可
以进行该业务、赋予怎样的QoS；

2. 在转发用户面数据时，根据上下文中的信息决
定对数据进行怎么样的封装，下一次封装的包头
地址是什么，TEID（隧道端点标识Tunnel
EndPoint Identifier）是多少。

这些信息都保存在用户上下文中，同时也是用户
的状态。这些状态信息就保存在处理单元所在的
单板上，由处理单元负责维护。

在传统的ATCA USN上，我们在查询用户上下文数量时，均可以指定ECU/ESU单板。

P2
在查询用户上下文状态信息时，也会显示出用户上下文当前所在的单板以及进程信息。

这些都说明用户的状态和处理单元存在绑定关系。

02 云化架构的要求
NFV架构下，要求网元“弹性、伸缩、单点故障不影响业务”。 CloudEPC
如果计算节点同时存储用户的状态数据（上下文）信息，那么：
1. 在删除计算节点之前需要将用户上下文迁移到其他节点
上，否则会造成业务损失；
2. 在新增计算节点时需要将用户上下文迁移到新增计算节
点上，否则新增节点不能处理已经在线的用户；

为了实现快速的“弹性、伸缩、快速业务迁移”，NFV基于以下
原则重新设计系统：

● 前端无状态
● 横向可扩展性
● 单点失效不影响业务

P3
将业务处理单元和存储节点进行分离。计算节点不再保存用户状态信息，只负责对到来的信令进行处理。用户状态保存
在数据库中。业务处理单元在处理用户消息（信令）时需要从数据库获得用户状态信息，再结合用户的状态对用户消息
进行处理。

也就是将一个传统网元拆成多个组件，每个组件被称为VNFC（虚拟网络功能组件Virtualized Network Function

Component）。多个VNFC构成一个VNF。

传统架构 NFV架构

链路、地址
CSLB

MM

业务处理VNFC
MM MM MM MM

状态 状态 状态 状态
ECU板
SM SM SM SM

SM
CSDB

状态 状态 状态 状态

状态 状态 状态 状态 状态 状态 状态 状态
ECU板

P4
如下图所示，传统架构下，业务处理单元接收到用户信令消息后，直接在查询用户状态后对消息直接进行处理。NFV
架构下，业务处理单元从数据库获得用户状态。

传统架构 NFV架构

链路、地址
CSLB

MM

业务处理VNFC
MM MM

状态 状态 状态 状态
ECU板
SM SM

SM

状态 状态

状态 状态 状态 状态 状态 状态
ECU板 CSDB

● 保存用户状态的VNFC被称为CSDB（Cloud Session Database，云会话数据库）；

● 业务处理单元统称为SPU（Service Process Unit，业务处理单元）。处在SPU位置的VNFC会根据网元的功能而采
用不同名称的VNF组件。
● 在业务处理单元前端，有一个负责业务报文分发和数据面消息负载均衡的组件，被称为CSLB（Cloud Session
Load balancer，云会话负载均衡器）；

在CSLB的更前端，会有一个负责路由、转发的组件VNRS（Virtualized Network Routing Service，虚拟化网络路由

服务）。

这样的架构保证了单个业务处理节点故障、业务消息被CSLB分发到其他正常状态的业务处理节点后，新的业务处理节
点与CSDB交互获得用户状态后，仍然可以正常处理用户的业务消息。新扩容的业务处理节点与CSDB交互获得用户状
态，也能够处理任何处在初始态或者中间态用户的业务消息。

P5
03 不同VNF所需的VNFC
以CloudUSN网元为例，存在VNRS、CSLB、CSDB三个VNFC。业务处理单元部分存在USN、UDR、FAC三个VNFC。
其中USN VNFC完成传统USN业务处理的功能；UDR VNFC完成单据上报功能，是传统CHR和UDN功能的合集；FAC
完成信息采集和故障分析，类似于内嵌的FMA。

对于所有的VNF，除了上述业务路径上的VNFC之外，还存在一个负责管理的部分——VNFP（Virtualized Network
Function Platform，虚拟网络功能平台）。VNFP作为虚拟网络管理平台，主要负责网元内虚拟设备的管理，VNFC的
资源分配和部署，同时与MANO（Management and Orchestration）交互进行虚拟机资源控制。

几个部分共同组成的云架构下的USN网元。

VNRS

CSLB

MM
USN_VNFC 业务处理VNFC
计费 SM
……

VNFP UDR_VNFC
呼叫单据
FAC_VNFC
信息采集和故障分析

状态 状态

状态 状态 提供CloudUSN对应的业务功能。
CSDB

而CloudUGW的组成如下图所示。

提供CloudUGW对应的业务功能。

P6
04 VNFC与VM的关系FC
VNFC是构成VNF的组件，多个VNFC组成了等价于传统网元的虚拟网元。业务数据流在不同的VNFC之间流动，实现
了移动数据核心网的功能。

在虚拟化的架构下，硬件资源都被划分成一个个虚拟机（VM），可供业务层利用的资源均在一个个VM中。VNF的各
个VNFC最终需要从VM中获得资源去支撑业务处理，实现“理想落入现实”。

云架构下，不同VNFC中的不同功能是由类似传统架构下的“进程组”来实现的。这些“进程组”被称为RU
（Resource Unit，资源单元）。一个VM可以包括一个或多个RU，为不同的VNFC提供资源。

虽然系统设计中有很多种名字的RU，实际上只存在维护、接入转发、业务处理和数据库四种类型的VM资源。

VDU（VM） 说明

OMU 操作维护单元，是 VNF 的操作维护中心；

提供南向接口、配置、告警、话统、日志、接入认证等 OAM 基础功能。

IPU 接口处理单元，提供外部 IP 网络连接能力、虚拟网络交换能力、到各 SPU VM 的

load balance 能力。

SPU 业务处理单元，提供 3GPP 和非 3GPP 协议定义的业务功能。

SDU 会话数据库单元，提供分布式上下文数据存取功能；

SPU 负责计算处理，SDU 完成所有状态数据的存储，为云化场景下实现高可靠性

提供了基础保障。

每种VNFC都需要维护相关的RU，其余的RU需求根据进程的功能决定。

P7
以CloudUSN为例：

● VNRS VNFC和CSLB VNFC负责路由和分发，除维护RU外还需要转发RU。这些转发RU部署在IPU VM上。

● USN、UDR和FAC三种VNFC负责业务处理，除维护RU外还需要业务处理（类似计算）的RU。这些业务处理的RU部
署在SPU VM。
● CSDB VNFC负责数据库相关业务，除维护RU外还需要存储资源。这些存储资源来自有存储特性的SDU VM。

CloudUSN 各虚拟机（VMs）
VNRS_VNFC VNRS CSLB _IP _RU VNRS _IP _RU IPU_VM
VNRS _OM _RU VNRS _OM _RU
VNRS _IPSEC _RU
VNRS _IP _RU VNRS _IPSEC _RU

OMU_VM
VNFP _OM _RU

USN _OM _RU CSLB _OM _RU

CSLB_VNFC CSLB
CSLB _OM _RU CSLB _OM _RU UDR _OM _RU VNRS _OM _RU

CSLB _IP _RU CSLB _IP _RU …… FAC _OM _RU CSDB _OM _RU

VNFP _OM _RU

USN_VNFC NLS
USN _OM _RU USN _OM _RU USN _SP _RU SPU_VM for USN
USN _SP _RU USN _SP _RU ……
VNFP USN _SP _RU

UDR_VNFC
UDR _OM _RU UDR _OM _RU
UDR _SP _RU SPU_VM for UDR
VNFP _OM _RU

UDR _SP _RU UDR _SP _RU

…… UDR _SP _RU

FAC_VNFC
SPU_VM for FAC
FAC _OM _RU FAC _OM _RU
FAC _SP _RU FAC _SP _RU

CSDB_VNFC CSDB CSDB _SD _RU SDU_VM

CSDB _OM _RU CSDB _OM _RU
CSDB _SD _RU
CSDB _SD _RU CSDB _SD _RU

P8
05 VNF的扩缩容
VNF的扩缩容就是VNFC能力的增加和减少，而VNFC的能力依赖于RU资源的多寡。RU又来自于VM，因此VNF的扩缩
容通过增删VM来实现。

以扩容CloudUSN的业务处理能力为例，增加SPU VM的数量，也就增加了SPU内业务处理RU的数量，就增加
CloudUSN业务处理的能力。

CloudUSN 各虚拟机（VMs）
VNRS_VNFC VNRS CSLB _IP _RU VNRS _IP _RU IPU_VM IPU_VM IPU_VM
VNRS _OM _RU VNRS _OM _RU
VNRS _IPSEC _RU
VNRS _IP _RU VNRS _IPSEC _RU

OMU_VM OMU_VM
VNFP _OM _RU

USN _OM _RU CSLB _OM _RU IPU_VM

CSLB_VNFC CSLB
CSLB _OM _RU CSLB _OM _RU UDR _OM _RU VNRS _OM _RU

CSLB _IP _RU CSLB _IP _RU …… FAC _OM _RU CSDB _OM _RU

VNFP _OM _RU

USN_VNFC NLS
USN _OM _RU USN _OM _RU USN _SP _RU SPU_VM SPU_VM SPU_VM
USN _SP _RU USN _SP _RU ……
VNFP USN _SP _RU

UDR_VNFC
UDR _OM _RU UDR _OM _RU
UDR _SP _RU SPU_VM SPU_VM
VNFP _OM _RU

UDR _SP _RU UDR _SP _RU …… UDR _SP _RU

FAC_VNFC
FAC _OM _RU FAC _OM _RU SPU_VM SPU_VM
FAC _SP _RU FAC _SP _RU

CSDB_VNFC CSDB CSDB _SD _RU SDU_VM SDU_VM

CSDB _OM _RU CSDB _OM _RU
CSDB _SD _RU
CSDB _SD _RU CSDB _SD _RU

在一个大容量的CloudUSN中，多个SPU VM提供USN VNFC所需的RU资源。VM的数量直接反应了CloudUSN容量的

大小。

这种通过增减VM数量的扩缩容方式被称为Scale Out/Scale In。还存在另外一种方式——通过绑定和删减硬件资源来增

加和减少VM的能力，这种扩缩容的方式被称为Scale Up/Scale Down。

变多和减少——Scale Out/Scale In

长胖和减肥——Scale Up/Scale Down

P9
 CloudUSN
VNRS _VNFC VNRS
CSLB_VNFC CSLB

SPU_VM

SPU_VM
USN_VNFC

UDR_VNFC
SPU_VM

FAC_VNFC

CSDB _VNFC CSDB

Up
Down
Scale
CloudUSN CloudUSN
VNRS _VNFC VNRS VNRS _VNFC VNRS
CSLB_VNFC CSLB CSLB_VNFC CSLB

SPU_VM SPU_VM SPU_VM

Out
SPU_VM SPU_VM SPU_VM
USN_VNFC USN_VNFC
UDR_VNFC UDR_VNFC

SPU_VM
SPU_VM
FAC_VNFC
In SPU_VM
FAC_VNFC

CSDB _VNFC CSDB CSDB _VNFC CSDB

P10
这些VM部署在不同的硬件刀片上，从而实现了设备的分布式，使得VNF具备了“云化”的特征。

CloudUSN
VNRS_VNFC VNRS

CSLB_VNFC CSLB

NLS
SPU_VM SPU_VM

SPU_VM SPU_VM
USN_VNFC

UDR_VNFC

SPU_VM SPU_VM
FAC_VNFC

CSDB_VNFC CSDB

本章描述的VNF架构这部分内容历史上出现过很多概念。新的名词伴随着架构的调整不断产生，旧的名词被抛弃。所以
大家对这块的其他名词有什么疑问和心得，可以在评论中讨论。

预计VNF的结构（VNFC的构成）在将来还可能会调整。

P11