陳煒　韓小勇　尼凌飛

摘要：基于網(wǎng)絡功能虛擬化的背景，探討了移動核心網(wǎng)應用網(wǎng)絡功能虛擬化（NFV）需要解決的3大關鍵技術：基礎設施平臺選擇、核心網(wǎng)云管理架構設計和轉發(fā)面性能加速，并基于NFV架構定義了一種移動核心網(wǎng)的云管理系統(tǒng)架構。與傳統(tǒng)電信核心網(wǎng)管理相比，該系統(tǒng)架構增加了對硬件資源、虛擬資源層、虛擬化網(wǎng)元以及完整網(wǎng)絡功能的管理、編排和調度，增加了虛擬網(wǎng)元管理和虛擬網(wǎng)元之間的接口，增強了對通用硬件運行狀態(tài)的管理能力，以便能更及時、更全面地管理通用硬件和虛擬網(wǎng)元，實現(xiàn)實時的資源和功能調度。

關鍵詞： 虛擬化；網(wǎng)絡功能虛擬化；云管理

1 背景

1.1 網(wǎng)絡需要新技術促進變革

移動通信網(wǎng)絡主要由電信級設備組成，具有高性能、高可靠和標準化的特點，但同時存在建設周期長、業(yè)務上線時間長和缺乏靈活性的問題。隨著移動寬帶的規(guī)模部署，移動網(wǎng)絡面臨的流量將呈指數(shù)級增長，而傳統(tǒng)的基礎業(yè)務收入將逐漸降低。移動運營商迫切需要一種低成本和高效的運營方式，降低每比特傳輸?shù)木W(wǎng)絡成本，提高利潤。

在互聯(lián)網(wǎng)領域，虛擬化、云計算技術實現(xiàn)了設備的通用化、業(yè)務的快速上線和資源的靈活管理與共享。這一方面支撐了Google、Amazon等互聯(lián)網(wǎng)公司的海量數(shù)據(jù)存儲和高性能計算的需求，另一方面盡可能地讓網(wǎng)絡建設和維護成本可控，實現(xiàn)可持續(xù)增長。在移動互聯(lián)網(wǎng)時代，虛擬化、云計算的IT技術必將再一次深刻改變傳統(tǒng)電信網(wǎng)絡。

網(wǎng)絡功能虛擬化（NFV）在這種背景下應運而生。2012年10月AT&T、BT、Telefonica、中國移動等全球13家運營商發(fā)起成立了ETSI ISG NFV工作組，提出了NFV的概念，旨在改變現(xiàn)有電信設備的形態(tài)及實現(xiàn)方式，擬基于通用標準的服務器、存儲和網(wǎng)絡設備并利用IT虛擬化技術以軟件的方式實現(xiàn)現(xiàn)有多種電信設備的功能，推進電信網(wǎng)絡虛擬化架構及關鍵技術的研發(fā)工作。移動網(wǎng)絡和固定網(wǎng)絡中的控制網(wǎng)元和數(shù)據(jù)轉發(fā)網(wǎng)元是NFV的重要應用場景[1]。

1.2 NFV可實現(xiàn)網(wǎng)絡能力的提升

通過IT虛擬化及應用的軟件化，可實現(xiàn)網(wǎng)絡新功能的快速引入。移動網(wǎng)功能引入時間往往很長，通常需花費約3～3.5年的時間。一個新功能的引入涉及到多個過程，如標準方案的制訂（以3GPP等標準化組織方案標準化估計，約需1.5年）、廠商設備的產(chǎn)品實現(xiàn)（約需0.5～1年）、軟硬件測試（約需0.5年）以及現(xiàn)網(wǎng)部署的規(guī)劃和調整（約需0.5年）。虛擬化技術所帶來的功能軟件化和管理智能化將極大地提升網(wǎng)絡部署的靈活性，在虛擬化環(huán)境中，網(wǎng)元演進為軟件，可在虛擬資源上直接加載、擴容、縮容和靈活調度，從而使網(wǎng)絡新功能的推出時間大幅縮短。

研究發(fā)現(xiàn)，軟件化、虛擬化能顯著降低建設成本（CAPEX）。據(jù)ACG Research統(tǒng)計[2]，移動運營商使用虛擬化技術能夠降低部署費用約61%。這要歸功于：采用通用硬件，實現(xiàn)了設備的統(tǒng)一化和資源共享；通過統(tǒng)一的管理和自動化運維，提升運維效率，如可根據(jù)網(wǎng)絡負載的潮汐效應，進行系統(tǒng)的自動擴容和縮容，避免高能耗，實現(xiàn)網(wǎng)絡的綠色可持續(xù)發(fā)展。

2 NFV在移動核心網(wǎng)應用

的關鍵問題探討

在移動核心網(wǎng)（如EPC、IMS）中應用NFV技術，基礎設施平臺選擇、核心網(wǎng)云管理架構設計和轉發(fā)面性能加速問題是需要解決的三大關鍵問題。

2.1 基礎設施平臺選擇問題

核心網(wǎng)虛擬化的基礎設施主要包括物理硬件層及虛擬化層。

在物理硬件層面，計算設備的選擇是關鍵問題之一，眾所周知，傳統(tǒng)核心網(wǎng)網(wǎng)元主要采用高級電信計算架構（ATCA）服務器，而云計算系統(tǒng)主要采用商業(yè)現(xiàn)貨供應（COTS）服務器。一個是電信應用，一個是互聯(lián)網(wǎng)應用，兩者提供的服務不同，造成了對設備要求的不同。電信平臺要保證不間斷的業(yè)務提供，對物理硬件的可靠性要求高，而互聯(lián)網(wǎng)應用僅需做到盡力而為，對物理硬件的可靠性要求較低；電信設備一般置于傳統(tǒng)電信機房，對設備的環(huán)境適用性（例如溫度適用性、電信兼容性、防塵、抗震）、設備尺寸、功耗及供電類型、重量等要求嚴格，而互聯(lián)網(wǎng)設備一般置于新型數(shù)據(jù)中心，由于機房環(huán)境較好，可適當降低對設備的要求。核心網(wǎng)虛擬化是傳統(tǒng)電信領域與互聯(lián)網(wǎng)技術結合的產(chǎn)物，僅從功能上來講，ATCA及COTS設備完全能夠實現(xiàn)核心網(wǎng)虛擬化，但從可靠性、經(jīng)濟性等角度考慮，ATCA及COTS的選擇仍是業(yè)界正在考慮的問題。

在虛擬化層面，從功能上來講，核心網(wǎng)虛擬化對虛擬化層的基本要求主要包括以下幾個方面：

（1）支持x86指令集以使用服務器設備。

（2）支持共享存儲以實現(xiàn)虛擬機遷移等特性。

（3）支持硬件輔助虛擬化以提升虛擬機性能。

（4）支持虛擬機遠程部署和監(jiān)控以實現(xiàn)遠程自動管理。

（5）支持標準化的虛擬機模板以實現(xiàn)跨廠家。

（6）支持親和度識別以及虛擬層高可用機制以實現(xiàn)系統(tǒng)級可靠性。

目前，業(yè)界主流的虛擬化產(chǎn)品（如Xen[3]、KVM[4]、VMware[5]、Hyper-V[6]等）均能夠支持以上特性。但電信廠家多選擇Xen、KVM等開源軟件，這主要是因為可進行定制研發(fā)，避免功能開發(fā)受制于第三方，并實現(xiàn)成本節(jié)約。此外，OpenStack[7-8]提供了開源的云資源管理方案，其功能組件及標準的應用編程接口（API）已被各廠家的核心網(wǎng)虛擬化平臺所采用，這也為核心網(wǎng)虛擬化層的開發(fā)提供了更多的便利。

除了計算設備和虛擬化軟件的選擇之外，物理硬件層與虛擬化層與外部的交互也是需要考慮的關鍵問題之一。傳統(tǒng)的核心網(wǎng)軟件直接運行在物理平臺上，為保證系統(tǒng)的可靠性，網(wǎng)元軟件需要實時采集物理服務器狀態(tài)，判斷電源、風扇、網(wǎng)口、磁盤，甚至芯片等是否工作正常。在核心網(wǎng)虛擬化環(huán)境中，網(wǎng)元軟件不僅需要了解物理服務器的狀態(tài)，還需要了解虛擬化軟件的狀態(tài)。而且，一旦物理服務器或者虛擬化軟件發(fā)生故障，需要將故障映射到相應的虛擬機，以使得上層軟件能夠正確定位并處理故障。這種狀態(tài)上報及定位的機制需要云管理平臺及核心網(wǎng)軟件的共同支持，進一步來說，如果物理層、虛擬層以及網(wǎng)元軟件來自不同的廠家，即跨廠家實現(xiàn)核心網(wǎng)虛擬化，我們認為這些狀態(tài)上報的信息需要實現(xiàn)標準化。endprint

2.2 核心網(wǎng)云管理問題

核心網(wǎng)虛擬化后，將打破現(xiàn)有的以網(wǎng)元為中心的軟硬件緊耦合的管理模式，轉向以資源為中心的軟硬件松耦合的管理模式，從而實現(xiàn)跨域，跨地區(qū)，跨平臺的集中管理，實現(xiàn)資源的智能調度（自動化的擴容、縮容等），這就是基于NFV的核心網(wǎng)云管理?；跉W洲電信標準組織（ETSI）的NFV架構[9]，我們定義了移動核心網(wǎng)的云系統(tǒng)架構，如圖1所示。

與傳統(tǒng)電信核心網(wǎng)管理相比，核心網(wǎng)云管理增加了對硬件資源、虛擬資源層、虛擬化網(wǎng)元以及完整網(wǎng)絡功能的管理和調度。實現(xiàn)核心網(wǎng)云管理的網(wǎng)元功能包括虛擬設施管理（VIM）、虛擬網(wǎng)元管理（VNFM）和虛擬業(yè)務編排（VNFO）。

（1）VIM

VIM負責虛擬化基礎設施的管理。主要功能包括：采集硬件資源和虛擬資源的狀態(tài)信息并上報給VNFM，實現(xiàn)資源監(jiān)測、故障監(jiān)測和上報；接受來自VNFM的上層應用請求并進行認證，認證通過后，通過控制虛擬機管理器（Hypervisor）來執(zhí)行上層應用請求，實現(xiàn)資源的遷移和彈性伸縮。

（2）VNFM

VNFM負責虛擬網(wǎng)絡功能（VNF）的生命周期管理及其資源使用情況的監(jiān)控。具體包括VNF的添加、刪除、更改、查詢、擴容/縮容、預留以及VNF所占用資源的動態(tài)監(jiān)控等。以添加一個VNF為例，VNFM需要計算這個VNF所用的計算、存儲和網(wǎng)絡資源的需求，并根據(jù)需求向VIM申請創(chuàng)建虛擬機，在創(chuàng)建成功的虛擬機上加載相關VNF軟件并運行。

（3）VNFO

VNFO負責基礎設施和虛擬化網(wǎng)絡功能VNF的管理和編排，進而實現(xiàn)完整的網(wǎng)絡服務。以IMS為例，VNFO可以通過對呼叫會話控制功能（CSCF）、歸屬用戶服務器（HSS）等VNF的編排進而提供一個完整的IMS網(wǎng)絡服務。在多數(shù)據(jù)中心和多廠家部署的場景下，VNFO通過標準接口可提供跨數(shù)據(jù)中心和跨廠家的協(xié)同管理能力。

與ETSI NFV的云管理相比，圖1中的核心網(wǎng)云管理在以下幾個方面進行了增強，能實現(xiàn)更高的可靠性：

（1）增加了VIM與硬件資源層間的C1接口，可以及時采集各種硬件故障信息，并通知上層業(yè)務進行快速切換。

（2）在虛擬化平臺中增加了亞健康的檢測機制，對于硬件尚未出現(xiàn)故障但已經(jīng)出現(xiàn)較多業(yè)務失敗的場景能夠及時感知并提前進行相應的預防處理。

（3）增加了VNFM和VNF之間的C10接口，使業(yè)務情況的變化也能及時地為云管理網(wǎng)元所感知，例如當出現(xiàn)業(yè)務量陡增，負荷迅速上升的場景時，云管理網(wǎng)元能夠迅速感知并進行相應的資源調度，以避免出現(xiàn)過載而導致業(yè)務中斷。

2.3 轉發(fā)面加速問題

核心網(wǎng)轉發(fā)面設備通常具有較高的轉發(fā)性能要求，比如承載移動網(wǎng)絡數(shù)據(jù)流量的分組域核心網(wǎng)網(wǎng)關設備。大多數(shù)傳統(tǒng)電信設備廠家都采用專有的轉發(fā)芯片以實現(xiàn)高性能轉發(fā)的目標。隨著核心網(wǎng)虛擬化技術的發(fā)展，轉發(fā)面設備的演進路線仍是一個值得深入研究的問題。

從物理硬件的分類來看，傳統(tǒng)設備采用的專有芯片（如NPU等）轉發(fā)性能高但擴展性較差，而通用服務器采用的通用芯片轉發(fā)性能低但擴展性較好。隨著硬件技術的發(fā)展，通用芯片的計算能力越來越高，通用網(wǎng)卡的轉發(fā)能力也越來越強（已經(jīng)達到10 Gb/s、40 Gb/s等），同時，數(shù)據(jù)面開發(fā)套件（DPDK）[10]、單根I/O虛擬化（SR-IOV）[11]等優(yōu)化技術的出現(xiàn)，還將進一步提升通用服務器的轉發(fā)性能。這些都使得核心網(wǎng)的轉發(fā)面采用通用服務器并引入虛擬化技術成為一個可能，但核心網(wǎng)轉發(fā)面采用專有芯片設備還是通用芯片仍然是一個復雜且值得進一步解決的問題。

從轉發(fā)面設備的演進路線來看，傳統(tǒng)設備中大多采用專有的單板來實現(xiàn)轉發(fā)功能，而其業(yè)務控制處理功能則由其他類型的單板來實現(xiàn)。由于機框單板數(shù)量的限制，傳統(tǒng)設備通常通過兩種單板的配比來實現(xiàn)容量的要求，這在一定程度上限制了轉發(fā)單板和業(yè)務處理單板的獨立擴展，難以充分利用硬件資源。轉發(fā)面網(wǎng)元設備引入虛擬化之后，可有以下兩種演進路線：

（1）轉發(fā)面功能和業(yè)務控制功能綁定，由軟件實現(xiàn)。這種方式簡單靈活，但轉發(fā)性能需要進一步驗證。

（2）轉發(fā)面功能和業(yè)務控制功能分離，獨立擴展，分別優(yōu)化。

3 核心網(wǎng)NFV的產(chǎn)業(yè)實踐

隨著IT虛擬化技術的發(fā)展，全球標準化組織、電信運營商、電信設備廠家均開啟了核心網(wǎng)虛擬化的研發(fā)工作。到2013年，參與ETSI NFV ISG的運營商從13家擴展到20多家，全球眾多電信廠家、IT廠家參與其中，同年10月發(fā)布了用例[12]、需求[13]、術語[14]等規(guī)范，在產(chǎn)業(yè)界將電信網(wǎng)絡虛擬化的研發(fā)推向了高潮。

由于業(yè)界普遍認為在已經(jīng)部署且穩(wěn)定運營的現(xiàn)有網(wǎng)絡上直接替換并進行虛擬化改造的收益不大，因此承載VoLTE的IP多媒體子系統(tǒng)（IMS）成為核心網(wǎng)虛擬化的觸發(fā)點。在2013年，多家電信運營商均對IMS云化進行了可行性驗證和測試。2013年年初運營商Vodafone提出在通用的HP x86服務器上開展IMS核心網(wǎng)虛擬化測試，各測試廠家實現(xiàn)了基于HP C7000服務器和VMware虛擬化平臺的IMS云化可行性驗證。同年10月韓國運營商LG Uplus在本土開展IMS云化測試，同月運營商DT在歐洲部署VoLTE、RCS和RCSe的虛擬化平臺，其中RCSe已經(jīng)實現(xiàn)商用。2013年年底，運營商TELE2分別在荷蘭和瑞典完成IMS核心網(wǎng)和業(yè)務平臺的虛擬化測試，并計劃于2014年上半年實現(xiàn)商用。

與IMS相比，核心網(wǎng)的其他網(wǎng)元虛擬化進程相對較慢。2013年，全球的電信設備廠商、新興電信廠商和創(chuàng)業(yè)公司紛紛開展了虛擬化演進分組核心網(wǎng)（EPC）的研發(fā)工作，與準商用的IMS云化產(chǎn)品不同，EPC虛擬化目前還主要停留在概念驗證階段，主要的“瓶頸”在于轉發(fā)面性能問題，而少數(shù)的幾個準商用的EPC虛擬化案例主要來自不太考慮轉發(fā)性能的企業(yè)網(wǎng)應用。endprint

中國移動從2010年開始就開展了多項核心網(wǎng)虛擬化的研究工作，通過在實驗室搭建虛擬化平臺，驗證了在未進行任何技術優(yōu)化的前提下，虛擬化的IMS及軟交換網(wǎng)元將額外消耗10%～20%的CPU資源，并增加10%～20%的信令時延，這表明引入虛擬化帶來的性能損耗在可接受的范圍內。

2013年中國移動在TC3牽頭發(fā)起了《核心網(wǎng)控制網(wǎng)元虛擬化技術研究》的研究報告，研究移動核心網(wǎng)控制面網(wǎng)元（如CSCF/MME等）虛擬化的需求、場景、架構及關鍵問題，在TC5牽頭發(fā)起了《移動軟網(wǎng)絡需求及架構》的研究報告，研究移動分組域網(wǎng)絡演進的需求、架構及關鍵問題。同期，中國移動開展了多廠家的虛擬化IMS和虛擬化EPC的實驗室測試工作，在2014年世界通信展[15]（MWC）成功展示了全球首次多廠家混合組網(wǎng)的端到端虛擬化網(wǎng)絡原型系統(tǒng)，并打通了基于微型基站（Nanocell）、基于通用服務器的虛擬化云接入網(wǎng)（C-RAN）和核心網(wǎng)（EPC和IMS）的VoLTE視頻通話，展示了虛擬化核心網(wǎng)的可靠性、自動擴容和縮容等特性，會展期間引起了全球多個運營商、ETSI NFV技術專家、各大通信設備商及IT廠家的極大關注，進一步加速電信網(wǎng)絡實現(xiàn)網(wǎng)絡功能虛擬化（NFV）的進程，并為后續(xù)核心網(wǎng)虛擬化技術的進一步研究和現(xiàn)網(wǎng)應用奠定了基礎。

4 結束語

隨著移動寬帶的到來，互聯(lián)網(wǎng)及流量對傳統(tǒng)電信業(yè)的沖擊將愈加激烈，這促使電信運營商走到了變革的十字路口，而核心網(wǎng)的網(wǎng)絡虛擬化則是從網(wǎng)絡自身出發(fā)的一種應對變革的有效手段。通過將虛擬化、云計算的IT技術引入到移動核心網(wǎng)，實現(xiàn)網(wǎng)絡部署能力的提升、網(wǎng)絡部署成本的降低和運營能力的增強。

雖然業(yè)界對于核心網(wǎng)虛擬化是未來網(wǎng)絡的重要組成部分已經(jīng)達成共識，但是核心網(wǎng)的網(wǎng)絡虛擬化技術在基礎設施平臺、云管理以及轉發(fā)性能優(yōu)化上仍然存在很多待解決的問題，我們還需要繼續(xù)深入開展核心網(wǎng)網(wǎng)絡虛擬化的各項研究，推動產(chǎn)業(yè)的成熟，為將來部署云化的核心網(wǎng)做好技術儲備。

參考文獻

[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