移动核心网应用NFV的关键问题探讨及实践

陈炜　韩小勇　尼凌飞

摘要：基于网络功能虚拟化的背景，探讨了移动核心网应用网络功能虚拟化（NFV）需要解决的3大关键技术：基础设施平台选择、核心网云管理架构设计和转发面性能加速，并基于NFV架构定义了一种移动核心网的云管理系统架构。与传统电信核心网管理相比，该系统架构增加了对硬件资源、虚拟资源层、虚拟化网元以及完整网络功能的管理、编排和调度，增加了虚拟网元管理和虚拟网元之间的接口，增强了对通用硬件运行状态的管理能力，以便能更及时、更全面地管理通用硬件和虚拟网元，实现实时的资源和功能调度。

关键词： 虚拟化；网络功能虚拟化；云管理

1 背景

1.1 网络需要新技术促进变革

移动通信网络主要由电信级设备组成，具有高性能、高可靠和标准化的特点，但同时存在建设周期长、业务上线时间长和缺乏灵活性的问题。随着移动宽带的规模部署，移动网络面临的流量将呈指数级增长，而传统的基础业务收入将逐渐降低。移动运营商迫切需要一种低成本和高效的运营方式，降低每比特传输的网络成本，提高利润。

在互联网领域，虚拟化、云计算技术实现了设备的通用化、业务的快速上线和资源的灵活管理与共享。这一方面支撑了Google、Amazon等互联网公司的海量数据存储和高性能计算的需求，另一方面尽可能地让网络建设和维护成本可控，实现可持续增长。在移动互联网时代，虚拟化、云计算的IT技术必将再一次深刻改变传统电信网络。

网络功能虚拟化（NFV）在这种背景下应运而生。2012年10月AT&T、BT、Telefonica、中国移动等全球13家运营商发起成立了ETSI ISG NFV工作组，提出了NFV的概念，旨在改变现有电信设备的形态及实现方式，拟基于通用标准的服务器、存储和网络设备并利用IT虚拟化技术以软件的方式实现现有多种电信设备的功能，推进电信网络虚拟化架构及关键技术的研发工作。移动网络和固定网络中的控制网元和数据转发网元是NFV的重要应用场景[1]。

1.2 NFV可实现网络能力的提升

通过IT虚拟化及应用的软件化，可实现网络新功能的快速引入。移动网功能引入时间往往很长，通常需花费约3～3.5年的时间。一个新功能的引入涉及到多个过程，如标准方案的制订（以3GPP等标准化组织方案标准化估计，约需1.5年）、厂商设备的产品实现（约需0.5～1年）、软硬件测试（约需0.5年）以及现网部署的规划和调整（约需0.5年）。虚拟化技术所带来的功能软件化和管理智能化将极大地提升网络部署的灵活性，在虚拟化环境中，网元演进为软件，可在虚拟资源上直接加载、扩容、缩容和灵活调度，从而使网络新功能的推出时间大幅缩短。

研究发现，软件化、虚拟化能显著降低建设成本（CAPEX）。据ACG Research统计[2]，移动运营商使用虚拟化技术能够降低部署费用约61%。这要归功于：采用通用硬件，实现了设备的统一化和资源共享；通过统一的管理和自动化运维，提升运维效率，如可根据网络负载的潮汐效应，进行系统的自动扩容和缩容，避免高能耗，实现网络的绿色可持续发展。

2 NFV在移动核心网应用

的关键问题探讨

在移动核心网（如EPC、IMS）中应用NFV技术，基础设施平台选择、核心网云管理架构设计和转发面性能加速问题是需要解决的三大关键问题。

2.1 基础设施平台选择问题

核心网虚拟化的基础设施主要包括物理硬件层及虚拟化层。

在物理硬件层面，计算设备的选择是关键问题之一，众所周知，传统核心网网元主要采用高级电信计算架构（ATCA）服务器，而云计算系统主要采用商业现货供应（COTS）服务器。一个是电信应用，一个是互联网应用，两者提供的服务不同，造成了对设备要求的不同。电信平台要保证不间断的业务提供，对物理硬件的可靠性要求高，而互联网应用仅需做到尽力而为，对物理硬件的可靠性要求较低；电信设备一般置于传统电信机房，对设备的环境适用性（例如温度适用性、电信兼容性、防尘、抗震）、设备尺寸、功耗及供电类型、重量等要求严格，而互联网设备一般置于新型数据中心，由于机房环境较好，可适当降低对设备的要求。核心网虚拟化是传统电信领域与互联网技术结合的产物，仅从功能上来讲，ATCA及COTS设备完全能够实现核心网虚拟化，但从可靠性、经济性等角度考虑，ATCA及COTS的选择仍是业界正在考虑的问题。

在虚拟化层面，从功能上来讲，核心网虚拟化对虚拟化层的基本要求主要包括以下几个方面：

（1）支持x86指令集以使用服务器设备。

（2）支持共享存储以实现虚拟机迁移等特性。

（3）支持硬件辅助虚拟化以提升虚拟机性能。

（4）支持虚拟机远程部署和监控以实现远程自动管理。

（5）支持标准化的虚拟机模板以实现跨厂家。

（6）支持亲和度识别以及虚拟层高可用机制以实现系统级可靠性。

目前，业界主流的虚拟化产品（如Xen[3]、KVM[4]、VMware[5]、Hyper-V[6]等）均能够支持以上特性。但电信厂家多选择Xen、KVM等开源软件，这主要是因为可进行定制研发，避免功能开发受制于第三方，并实现成本节约。此外，OpenStack[7-8]提供了开源的云资源管理方案，其功能组件及标准的应用编程接口（API）已被各厂家的核心网虚拟化平台所采用，这也为核心网虚拟化层的开发提供了更多的便利。

除了计算设备和虚拟化软件的选择之外，物理硬件层与虚拟化层与外部的交互也是需要考虑的关键问题之一。传统的核心网软件直接运行在物理平台上，为保证系统的可靠性，网元软件需要实时采集物理服务器状态，判断电源、风扇、网口、磁盘，甚至芯片等是否工作正常。在核心网虚拟化环境中，网元软件不仅需要了解物理服务器的状态，还需要了解虚拟化软件的状态。而且，一旦物理服务器或者虚拟化软件发生故障，需要将故障映射到相应的虚拟机，以使得上层软件能够正确定位并处理故障。这种状态上报及定位的机制需要云管理平台及核心网软件的共同支持，进一步来说，如果物理层、虚拟层以及网元软件来自不同的厂家，即跨厂家实现核心网虚拟化，我们认为这些状态上报的信息需要实现标准化。endprint

2.2 核心网云管理问题

核心网虚拟化后，将打破现有的以网元为中心的软硬件紧耦合的管理模式，转向以资源为中心的软硬件松耦合的管理模式，从而实现跨域，跨地区，跨平台的集中管理，实现资源的智能调度（自动化的扩容、缩容等），这就是基于NFV的核心网云管理。基于欧洲电信标准组织（ETSI）的NFV架构[9]，我们定义了移动核心网的云系统架构，如图1所示。

与传统电信核心网管理相比，核心网云管理增加了对硬件资源、虚拟资源层、虚拟化网元以及完整网络功能的管理和调度。实现核心网云管理的网元功能包括虚拟设施管理（VIM）、虚拟网元管理（VNFM）和虚拟业务编排（VNFO）。

（1）VIM

VIM负责虚拟化基础设施的管理。主要功能包括：采集硬件资源和虚拟资源的状态信息并上报给VNFM，实现资源监测、故障监测和上报；接受来自VNFM的上层应用请求并进行认证，认证通过后，通过控制虚拟机管理器（Hypervisor）来执行上层应用请求，实现资源的迁移和弹性伸缩。

（2）VNFM

VNFM负责虚拟网络功能（VNF）的生命周期管理及其资源使用情况的监控。具体包括VNF的添加、删除、更改、查询、扩容/缩容、预留以及VNF所占用资源的动态监控等。以添加一个VNF为例，VNFM需要计算这个VNF所用的计算、存储和网络资源的需求，并根据需求向VIM申请创建虚拟机，在创建成功的虚拟机上加载相关VNF软件并运行。

（3）VNFO

VNFO负责基础设施和虚拟化网络功能VNF的管理和编排，进而实现完整的网络服务。以IMS为例，VNFO可以通过对呼叫会话控制功能（CSCF）、归属用户服务器（HSS）等VNF的编排进而提供一个完整的IMS网络服务。在多数据中心和多厂家部署的场景下，VNFO通过标准接口可提供跨数据中心和跨厂家的协同管理能力。

与ETSI NFV的云管理相比，图1中的核心网云管理在以下几个方面进行了增强，能实现更高的可靠性：

（1）增加了VIM与硬件资源层间的C1接口，可以及时采集各种硬件故障信息，并通知上层业务进行快速切换。

（2）在虚拟化平台中增加了亚健康的检测机制，对于硬件尚未出现故障但已经出现较多业务失败的场景能够及时感知并提前进行相应的预防处理。

（3）增加了VNFM和VNF之间的C10接口，使业务情况的变化也能及时地为云管理网元所感知，例如当出现业务量陡增，负荷迅速上升的场景时，云管理网元能够迅速感知并进行相应的资源调度，以避免出现过载而导致业务中断。

2.3 转发面加速问题

核心网转发面设备通常具有较高的转发性能要求，比如承载移动网络数据流量的分组域核心网网关设备。大多数传统电信设备厂家都采用专有的转发芯片以实现高性能转发的目标。随着核心网虚拟化技术的发展，转发面设备的演进路线仍是一个值得深入研究的问题。

从物理硬件的分类来看，传统设备采用的专有芯片（如NPU等）转发性能高但扩展性较差，而通用服务器采用的通用芯片转发性能低但扩展性较好。随着硬件技术的发展，通用芯片的计算能力越来越高，通用网卡的转发能力也越来越强（已经达到10 Gb/s、40 Gb/s等），同时，数据面开发套件（DPDK）[10]、单根I/O虚拟化（SR-IOV）[11]等优化技术的出现，还将进一步提升通用服务器的转发性能。这些都使得核心网的转发面采用通用服务器并引入虚拟化技术成为一个可能，但核心网转发面采用专有芯片设备还是通用芯片仍然是一个复杂且值得进一步解决的问题。

从转发面设备的演进路线来看，传统设备中大多采用专有的单板来实现转发功能，而其业务控制处理功能则由其他类型的单板来实现。由于机框单板数量的限制，传统设备通常通过两种单板的配比来实现容量的要求，这在一定程度上限制了转发单板和业务处理单板的独立扩展，难以充分利用硬件资源。转发面网元设备引入虚拟化之后，可有以下两种演进路线：

（1）转发面功能和业务控制功能绑定，由软件实现。这种方式简单灵活，但转发性能需要进一步验证。

（2）转发面功能和业务控制功能分离，独立扩展，分别优化。

3 核心网NFV的产业实践

随着IT虚拟化技术的发展，全球标准化组织、电信运营商、电信设备厂家均开启了核心网虚拟化的研发工作。到2013年，参与ETSI NFV ISG的运营商从13家扩展到20多家，全球众多电信厂家、IT厂家参与其中，同年10月发布了用例[12]、需求[13]、术语[14]等规范，在产业界将电信网络虚拟化的研发推向了高潮。

由于业界普遍认为在已经部署且稳定运营的现有网络上直接替换并进行虚拟化改造的收益不大，因此承载VoLTE的IP多媒体子系统（IMS）成为核心网虚拟化的触发点。在2013年，多家电信运营商均对IMS云化进行了可行性验证和测试。2013年年初运营商Vodafone提出在通用的HP x86服务器上开展IMS核心网虚拟化测试，各测试厂家实现了基于HP C7000服务器和VMware虚拟化平台的IMS云化可行性验证。同年10月韩国运营商LG Uplus在本土开展IMS云化测试，同月运营商DT在欧洲部署VoLTE、RCS和RCSe的虚拟化平台，其中RCSe已经实现商用。2013年年底，运营商TELE2分别在荷兰和瑞典完成IMS核心网和业务平台的虚拟化测试，并计划于2014年上半年实现商用。

与IMS相比，核心网的其他网元虚拟化进程相对较慢。2013年，全球的电信设备厂商、新兴电信厂商和创业公司纷纷开展了虚拟化演进分组核心网（EPC）的研发工作，与准商用的IMS云化产品不同，EPC虚拟化目前还主要停留在概念验证阶段，主要的“瓶颈”在于转发面性能问题，而少数的几个准商用的EPC虚拟化案例主要来自不太考虑转发性能的企业网应用。endprint

中国移动从2010年开始就开展了多项核心网虚拟化的研究工作，通过在实验室搭建虚拟化平台，验证了在未进行任何技术优化的前提下，虚拟化的IMS及软交换网元将额外消耗10%～20%的CPU资源，并增加10%～20%的信令时延，这表明引入虚拟化带来的性能损耗在可接受的范围内。

2013年中国移动在TC3牵头发起了《核心网控制网元虚拟化技术研究》的研究报告，研究移动核心网控制面网元（如CSCF/MME等）虚拟化的需求、场景、架构及关键问题，在TC5牵头发起了《移动软网络需求及架构》的研究报告，研究移动分组域网络演进的需求、架构及关键问题。同期，中国移动开展了多厂家的虚拟化IMS和虚拟化EPC的实验室测试工作，在2014年世界通信展[15]（MWC）成功展示了全球首次多厂家混合组网的端到端虚拟化网络原型系统，并打通了基于微型基站（Nanocell）、基于通用服务器的虚拟化云接入网（C-RAN）和核心网（EPC和IMS）的VoLTE视频通话，展示了虚拟化核心网的可靠性、自动扩容和缩容等特性，会展期间引起了全球多个运营商、ETSI NFV技术专家、各大通信设备商及IT厂家的极大关注，进一步加速电信网络实现网络功能虚拟化（NFV）的进程，并为后续核心网虚拟化技术的进一步研究和现网应用奠定了基础。

4 结束语

随着移动宽带的到来，互联网及流量对传统电信业的冲击将愈加激烈，这促使电信运营商走到了变革的十字路口，而核心网的网络虚拟化则是从网络自身出发的一种应对变革的有效手段。通过将虚拟化、云计算的IT技术引入到移动核心网，实现网络部署能力的提升、网络部署成本的降低和运营能力的增强。

虽然业界对于核心网虚拟化是未来网络的重要组成部分已经达成共识，但是核心网的网络虚拟化技术在基础设施平台、云管理以及转发性能优化上仍然存在很多待解决的问题，我们还需要继续深入开展核心网网络虚拟化的各项研究，推动产业的成熟，为将来部署云化的核心网做好技术储备。

参考文献

[1] Network Functions Virtualisation [EB/OL]. （2014-03-20）. http：//portal.etsi.org/NFV/NFV_White_Paper.pdf.

[2] Business Case for Juniper Networks Virtualized Mobile Control Gateway [EB/OL]. （2014-03-20）. http：//www.acgresearch.net/.

[3] Xen Home Page [EB/OL]. （2014-03-20）. http：//www.xenproject.org/.

[4] KVM Home Page [EB/OL]. （2014-03-20）. http：//www.linux-kvm.org/page/Main_Page.

[5] VMware Home Page [EB/OL]. （2014-03-20）. http：//www.vmware.com/cn.

[6] LEINENBACH D， SANTEN T. Verifying the Microsoft Hyper-V Hypervisor with VCC [M]// FM 2009： Formal Methods. Springer Berlin Heidelberg. 2009： 806-809. doi： 10.1007/978-3-642-05089-3_51.

[7] Openstack Home Page [EB/OL]. （2014-03-20）. https：//www.openstack.org/.

[8] 林利， 石文昌. 构建云计算平台的开源软件综述 [J]. 计算机科学， 2012，39 （11）：7-13.

[9] Network Functions Virtualisation （NFV）； Architectural Framework [EB/OL]. （2014-03-20）. http：//www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.01.01_60/gs_NFV002v010101p.pdf.

[10] DPDK Home Page [EB/OL]. （2014-03-20）. http：//dpdk.org/.

[11] DONG Y Z， YANG X W， LI J H， et al. High performance network virtualization with SR-IOV [J]. Communication Architectures for Scalable Systems. 2012， 72（11）： 1471-1480. doi： 10.1016/j.jpdc.2012.01.020.

[12] Network Functions Virtualisation （NFV）； Use Cases [EB/OL]. （2014-03-20）. http：//www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV001v010101p.pdf.

[13] Network Functions Virtualisation （NFV）； Virtualisation Requirements [EB/OL]. （2014-03-20）. http：//www.etsi.org/deliver/etsi_gs/NFV/001_099/004/01.01.01_60/gs_NFV004v010101p.pdf.

[14] Network Functions Virtualisation （NFV）； Terminology for Main Concepts in NFV [EB/OL]. （2014-03-20）. http：//www.etsi.org/deliver/etsi_gs/NFV/001_099/003/01.01.01_60/gs_NFV003v010101p.pdf.

[15] 2014 MWC Home Page [EB/OL]. （2014-03-20）. http：//www.mobileworldcongress.com/.endprint