核心网引入NFV的思考

胡轶群

（中国移动通信集团安徽有限公司，合肥 230088）

核心网引入NFV的思考

胡轶群

（中国移动通信集团安徽有限公司，合肥 230088）

本文介绍了核心网向NFV方向演进的技术特点、组网架构、重点问题，并对引入前后网络规划、设备采购、工程建设和运行维护等方面的变化进行了探讨和分析。

软硬件解耦；软件功能虚拟化；核心网云化

随着互联网业务的爆炸式发展，传统的网络架构和运维模式已越来越难以适应层出不穷的新需求新业务，运营商的通信网络面临着巨大的转型压力。NFV技术的出现并趋于成熟，可以较好的解决以上问题。

1 背景

1.1 NFV基本概念

NFV（Network Function Virtualization)采用虚拟化技术，将传统的电信设备功能与硬件解耦，基于通用硬件实现电信功能节点的软件化，可快速响应用户/市场需求，实现网络的快速部署、业务的快速上线和更新以及网络的灵活调度。

从技术实现角度来看，接入、承载、核心控制和业务等网络层面都可以引入NFV，但从业务响应速度和成本节省等维度来看，核心网和业务网引入NFV后价值提升最为明显。

核心网云化是NFV在核心网中的具体应用。综合分析引入难度、技术成熟度、厂家支持情况，IMS和EPC核心网云化最适合在现阶段考虑引入。传统核心网网元与NFV核心网网元如图1所示。

图1 传统核心网网元与NFV核心网网元

1.2 NFV网络架构（如图2所示）

NFV核心网络由硬件资源、虚拟资源和虚拟网元功能以及一个资源网元管理调度域组成。其中，虚拟资源部分由Hypervisor和VM组成：Hypervisor：虚拟机监控器负责虚拟机的创建、监控、销毁等；

VM：虚拟机向上层应用提供虚拟主机；

网元功能部分主要为虚拟网元：

VNF（Virtual Network Function，虚拟网元功能）软件，CSCF、MME等网元的虚拟化功能软件实体；

图2 NFV网络架构

核心网云管理MANO（Management and Orchestration）由VIM、VNFM和NFVO组成，提供虚拟资源管理和调度以及虚拟网元的全生命周期管理。

EMS和OSS为网元网管和综合网管，均为现网已有网元。

2 引入NFV后的重点问题分析

2.1 云化硬件选择

云化后，核心网硬件设备采用通用服务器。目前通用服务器主要有刀片式服务器或机架式服务器两种。从集成度和扩展性、可靠性、工程与维护、散热性、投资和适用场景等方面对两种服务器进行比对分析，主要区别如下。

2.1.1 集成度和扩展性

刀片式服务器集成度较高，一个机框可包含12-16块刀片，但由于体积受限，扩展插槽较少，扩展性较差；机架式服务器集成度较低，但扩展插槽较多，扩展性较好。

2.1.2 可靠性

刀片式服务器机框故障会影响整个机柜内所有刀片，故障影响面大；但同时由于机框集成度高，配线和光模块等外围设施少，潜在故障也相对较少。

机架式服务器的故障只影响单机架，故障影响面小；但相对地，由于机架式服务器集成度低，整机柜的配线和光模块等外围设施多，潜在故障也相对较多。

2.1.3 工程与维护

刀片式服务器在机框内安装、扩容、更换服务器仅需直接插拔即可，同时由于配线等外围设施少，工程施工和运行维护相对简单。

机架式服务器安装、扩容、更换等操作涉及配线调整、设备安装等，更换风扇则需要先给机架下电，抽出服务器，方可实施；同时由于配线等外围设施多，工程施工和运行维护相对复杂。

2.1.4 散热性

刀片式服务器由于集成度高，相应地对散热要求也较高；机架式服务器集成度低，对散热要求相对也较低。

2.1.5 投资

在同等配置情况下，由于背板交换模块等原因，导致刀片式服务器投资较机架式服务器高。

2.1.6 适用场景

刀片式服务器适合I/O需求较低、存储量较小、机房空间有限等场景；机架式服务器适合I/O需求较高、存储量较大、机房空间充足的等场景。

云化的核心网选用何种服务器需要根据具体的使用场景来综合考虑。

2.2 解耦方式选择

从发挥虚拟化优势的角度来看，NFV主要有共享资源池、硬件独立及全解耦3种解耦方式，如图3所示。

对于共享资源池方式，几乎没有厂家同时支持硬件资源层和虚拟资源层，而且由于不同厂家上层功能网元对虚拟层要求不同，故障定位较难，网络部署及运维难度较大。

硬件独立方案支持的厂家多，软硬件分别由不同厂家提供，故障定位相对简单，网络部署及运维的难度较小，产业的成熟度也较高。但硬件独立方案要求虚拟资源层和虚拟网络功能层为同厂家，对于不同厂家的NFV设备无法共享资源池，降低了资源池的使用效率，无法充分发挥虚拟化的优势。

采用全解耦方式，资源池可在不同厂家间实现共享，资源池使用效率较高，但现阶段产业成熟度较低，网络部署和运维难度大，可在具备条件时考虑引入。

图3 NFV的3种解耦方式

2.3 故障关联方式选择（如图4所示）

NFV架构中，虚拟网元的告警信息由EMS采集，资源池的告警信息由VIM采集，两类告警信息需要进行关联后呈现。故障关联可以选择在EMS、VNFM或OSS三处关联，关联后的告警信息可用于定位发生业务层告警所在的虚拟机位置和物理机位置。

图4 NFV的故障关联

如在OSS侧关联，虚拟网元的告警信息可由EMS通过北向接口传给OSS，NFVI的告警信息需由NFVO传给OSS，由于OSS和NFVO的接口还不成熟，现阶段不建议在OSS关联。

如在VNFM侧关联，需要EMS把网元告警传递给VNFM，VNFM需要支持解析网元告警的能力，关联完成之后还要通过EMS上报给OSS。

如在EMS侧关联，考虑到EMS作为网元网管，目前已具备软硬件故障告警功能，只需进行少量改造后，即可支持NFV故障关联。

考虑到在EMS关联改造量最小，故建议故障关联在EMS侧实现。

2.4 NFV电信云与现网私有云的关系

NFV电信云和现网私有云虽然都面向自有业务，但NFV主要承载核心网网元和核心网业务平台，私有云主要承载互联网业务和IT支撑系统，业务在运维管理、网络可靠性等方面不同，承载业务的云平台和云管平台也存在差异。

首先，业务量不具备互补性。NFV承载的电信业务因话务量和数据流量的最忙时不在同一个时段，存在明显的“潮汐效应”；私有云的少量业务有峰谷效应，但与NFV业务之间无法互补。

其次，管理架构不同。NFV引入了基于MANO的云管平台，实现统一的资源编排和调度。现网私有云中并没有关于MANO的概念，管理平台仅作资源管理。核心网云中仅VIM与私有云的资源池管理平台有对应关系。

再次，可靠性要求不同。私有云的系统可靠性一般只有99.9%，对上报的硬件故障内容要求较少，实时性要求较低；NFV的系统可靠性要求更高，需达到99.999%，上报的硬件故障内容要求较多，实时性要求也较高。

第四，虚拟层要求不同。私有云允许CPU、内存超分配，不强制要求物理绑定；NFV不允许CPU、内存超分配，要求物理核绑定。

最后，管理维护要求不同。NFV资源必须严格保证，不能复用给其它非电信系统。私有云资源对独占性要求较低。

综合以上分析，在NFV引入初期建议核心网云独立部署。

3 引入NFV后的变化

引入NFV后，由于设备软硬件解耦，新增虚拟层，网络组网架构发生变化，网络的网络规划、设备采购、工程建设和运行维护模式也需随之改变，如图5所示。

3.1 网络规划

3.1.1 硬件规划

传统网元只需规划网元的容量和数量，云化后还需规划功能网元和网管（含云管）所需的硬件资源。

服务器、存储等硬件的资源需求可根据不同网元类型、不同业务模型与硬件资源的配比关系，以及核心网NFV硬件的规格配置模型来确定。

3.1.2 软件规划

除VNF功能软件与现有网元功能软件类似外，核心网云化还将新增虚拟化软件、通用软件（操作系统、数据库、双机软件等）以及云管软件（VIM、VNFM、NFVO）；同时还需考虑网元容量、性能等与资源池的容量匹配问题。

3.1.3 资源池内部组网规划

传统核心网元因机框背板具备汇聚功能，输出配线少，直接接入IP承载网CE设备；云化后， NFV网元由于分布在多个虚拟机上，配线多，需经过交换机汇聚后再接入CE，增加了组网规划的复杂度。

接入层面接口较多，为便于后期维护管理，需根据接入设备种类划分为不同的平面，如业务、基础设施、网管平面等。

3.1.4 配套规划

现有核心网设备设置在传统机房中，按传统机房标准进行配套的规划建设；不同厂商的设备对配套要求不同；云化后核心网机房配套应按数据中心配套标准进行规划建设，由于要求统一，可提前准备。

3.2 采购模式

传统核心网网元软硬件统一采购。核心网云化后，软硬件的解耦，需增加通用硬件的采购环节；VNF功能软件与虚拟层软件解耦时，虚拟化软件和操作系统等通用软件也需单独采购。

同时需要注意的是，由于虚拟网元软件定价方式可能发生变化，导致采购模型也会较目前有所不同。

3.3 工程建设

业务部署更快。硬件提前具备条件，部署业务时，仅需进行软件调测和系统集成，大大缩短了业务部署时间。

网元部署更为便捷。在硬件资源具备条件的情况下，网络部署更侧重软件层面，基于云管理更易实现自动化快捷部署，部署效率会有所提升。

系统集成难度加大。现有核心网软硬件同步建设，不需要复杂的集成，调测较为简单；云化后，由于操作系统及上层应用软件均以功能模块为单位部署在不同的虚拟机上，功能模块间配合的接口和界面不如传统系统清晰、易于观察，增加了系统集成工作量和系统调测的难度。

工程施工工艺发生变化。云化设备采用通用硬件，在机房布局、机架设计、设备安装、线缆走线、工程分工等方面都较传统设备建设有较大差异。

图5 引入NFV前后带来的变化

3.4 网络运维

引入NFV后，网络架构的变化带来了网络运维体系的变化。软硬件解耦，通用硬件和上层功能软件由不同厂商提供，无法像传统网元一样统一管理，需分层维护，故障定位复杂，增加了故障处理难度；同时，原有统一网管分为虚拟网元管理和云化资源管理两部分，对网管体系也提出了新的要求。

从组织架构来看，分层维护后，网络运维对象由单一设备变为资源池管理和网元软件，打破了专业界限，传统的一体化的通用运维将转变为多专业协同运维，如何调整现有的维护组织架构以适应技术的发展和变化，提升运维管理效率和灵活服务能力，是需要提前考虑的问题。

从维护人员来看，现有的核心网维护人员IT方面知识有所不足，IT维护人员的核心网专业知识水平也有待提升。云化后的核心网无论从日常设备维护到紧急故障定位，都需要有既精通核心网基础知识又熟悉IT专业技能的复合型人才，人才队伍的建设和培养迫在眉睫。

图6 传统网络架构和NFV网络架构

4 NFV引入的原则和策略

4.1 引入原则

NFV的引入宜首先适应运营商战略发展方向，优先在导向明确的领域和网元考虑引入。其次，由于NFV技术目前还处在商用初期，为确保网络安全，宜优先在新建系统中考虑引入。另外，还需考虑不同网元云化的难易程度，宜按照先易后难的顺序引入NFV。

4.2 引入策略

NFV可考虑大规模发展的新网络、需要灵活开放的新能力、面向未来灵活简化的新架构等需求场景。按照先易后难的原则，结合网络大规模部署建设和系统升级换代工作，对控制面/信令面网元较多的新领域，如VoLTE IMS核心网中的CSCF和AS以及物联网EPC等信令面网元，考虑优先引入，满足业务快速部署和灵活应用的需求。

5 结束语

NFV的引入是从网络架构、网络建设到网络运维的一次重大变革，对规划方法、采购模式、工程实施、故障处理、组织架构等方面均提出了新的要求。引入NFV不能脱离已有的业务和网络，需根据实际情况并结合能力开放等的新业务需求考虑引入时机及引入步骤。

[1] 孙金霞，孙红芳，韦芳. 关于NFV与SDN的基本概念及应用思考[J]．电信工程技术与标准化，2014(8)．

Some thoughts on introducing NFV into the core

HU Yi-qun
(China Mobile Group Anhui Co., Ltd., Hefei 230088, China)

This paper introduces the technical characteristics, the evolution of NFV core network to the direction of the network architecture, key issues, and changes of before and after the introduction of network planning, equipment procurement, construction and operation and maintenance are discussed and analyzed.

hardware and software decoupling; software function virtualization; core network cloud

TN915

A

1008-5599（2017）06-0062-05

2017-01-18