5G電信云網(wǎng)絡(luò)的容器演進(jìn)方案

史庭祥 徐法祿 章璐

摘要：以云原生計算基金會（CNCF）定義的容器技術(shù)為出發(fā)點(diǎn)，從技術(shù)方案和客戶價值兩個維度分析5G電信云網(wǎng)絡(luò)引入容器技術(shù)的必要性。討論了演進(jìn)路線的兼容性和開放性，并針對不同的部署場景和云平臺新老供應(yīng)商提出了相關(guān)演進(jìn)方案?；陧椖繉?shí)踐，給出了分階段部署應(yīng)用和虛擬網(wǎng)絡(luò)功能平滑遷移到基于虛擬機(jī)容器的云原生網(wǎng)絡(luò)功能詳細(xì)過程。

關(guān)鍵詞：5G核心網(wǎng);容器;云原生;電信云;微服務(wù)

Abstract：ThecontainertechnologydefinedbytheCloudNativeComputingFoundation（CNCF）isanalyzed，andthenecessityofintroducingcontainertechnologyishighlightedfromthetwoaspectsoftechnicalsolutionandcustomervalue.Thecompatibilityandopennessoftheevolutionroadmaparediscussed，andrelevantmigrationsolutionsareproposedfordifferentdeploymentscenariosandsuppliersfornewandexistingcloudplatforms.Basedontheprojectpractice，thedetailedprocessofphaseddeploymentofapplicationsandsmoothmigrationofvirtualnetworkfunctiontovirtualmachinecontainer-basedcloudnativefunctionisputforword.

Keywords：5Gcorenetwork;container;cloudnative;telecomcloud;microservice

云計算從信息技術(shù)（IT）發(fā)展到通信技術(shù)（CT），網(wǎng)絡(luò)功能（NF）從虛擬化演進(jìn)到云化和云原生，都經(jīng)過了10余年的歷程。2006年8月9日，ERICSCHMIDT在搜索引擎大會上首次提出了“云計算”的概念。隨后，云計算在IT市場被廣泛使用。

云原生是MATTSTINE在2013年提出的一個概念，具有良好的可伸縮性。目前，云原生應(yīng)用和服務(wù)受到了越來越多的關(guān)注。云原生是一個思想的集合，既包含技術(shù)（如微服務(wù)、敏捷基礎(chǔ)設(shè)施），也包含管理（如DevOps、持續(xù)交付、康威定律、重組等）?？梢哉f，云原生是一系列云技術(shù)和企業(yè)管理方法的集合。

為統(tǒng)一云原生接口標(biāo)準(zhǔn)，2015年7月云原生計算基金會（CNCF）成立。該基金會的會員包括Google、IBM、Intel、Docker、RedHat等國際著名公司，代表了業(yè)界最領(lǐng)先的容器技術(shù)和云計算技術(shù)。CNCF致力于通過技術(shù)優(yōu)勢和用戶價值創(chuàng)造一套新的通用容器技術(shù)，以推動云計算和相關(guān)服務(wù)的發(fā)展。

CNCF中最知名的項目是Kubernetes（以下簡稱K8S）。K8S是Google發(fā)起并維護(hù)的基于Docker的開源容器集群管理系統(tǒng)。K8S容器集群能在私有云、公有云或者混合云之上運(yùn)行。K8S屬于主從的分布式集群架構(gòu)，包含Master和Node。其中，Master作為控制節(jié)點(diǎn)，可以調(diào)度和管理整個系統(tǒng);Node是運(yùn)行節(jié)點(diǎn)，可以運(yùn)行業(yè)務(wù)容器。

根據(jù)CNCF對云原生的定義，云原生網(wǎng)絡(luò)功能（CNF）和K8S的設(shè)計與架構(gòu)應(yīng)滿足相應(yīng)要求[1]。為此，基于容器的云原生應(yīng)用，通常需要滿足幾個條件：具有微服務(wù)體系結(jié)構(gòu)、可拆分性和獨(dú)立的業(yè)務(wù)邏輯，不僅支持獨(dú)立擴(kuò)展，還支持K8S應(yīng)用程序接口（API），即具有K8S感知的網(wǎng)絡(luò)功能。

1電信云網(wǎng)絡(luò)在5G階段引入容器技術(shù)的必要性

隨著全球5G網(wǎng)絡(luò)建設(shè)浪潮的到來[2-5]，電信網(wǎng)絡(luò)中以5G獨(dú)立組網(wǎng)（SA）核心網(wǎng)為代表的業(yè)務(wù)網(wǎng)元，需要引入容器技術(shù)。

1.1第3代合作伙伴計劃（3GPP）協(xié)議定義的服務(wù)化架構(gòu)（SBA）和相關(guān)新特性

引入容器技術(shù)，不僅可以滿足CNCF提出的要求，還能滿足Vodafone在定義云原生時提出的容器技術(shù)需求：微服務(wù)架構(gòu)和開放接口，其中開放接口用于微服務(wù)之間的通信;輕量化虛擬技術(shù)，如容器或其他輕量化云平臺;以微服務(wù)為單元提供網(wǎng)絡(luò)功能（NF）生命周期管理，包括初始化、彈縮、自愈等。

此外，3GPPR15標(biāo)準(zhǔn)滿足增強(qiáng)移動寬帶（eMBB）商用要求，和R16一起為5G核心網(wǎng)定義SBA，并支持如下幾方面的新特性[6-12]。

（1）微服務(wù)。5GSA核心網(wǎng)重新定義各個NF。大多數(shù)NF之間采用服務(wù)接口（SBI），同時NF采用微服務(wù)架構(gòu)，以便支持無中斷在線升級（ISSU）。

從2020年上半年某運(yùn)營商的5GSA核心網(wǎng)招標(biāo)項目可知，SBA架構(gòu)、微服務(wù)組件、無狀態(tài)設(shè)計、網(wǎng)絡(luò)切片、自動化部署、2G/3G/4G/5G全接入和全融合等需求，必須以微服務(wù)為特性要素，才能實(shí)現(xiàn)靈活敏捷的業(yè)務(wù)創(chuàng)新、網(wǎng)絡(luò)的部署和運(yùn)維，以及資源的重復(fù)利用，實(shí)現(xiàn)低成本、高價值的5G網(wǎng)絡(luò)目標(biāo)。

（2）跨平臺。無論是以R15標(biāo)準(zhǔn)為主的eMBB場景，還是R16和R17正在規(guī)劃的超可靠低時延通信（URLLC）和海量機(jī)器類通信（mMTC）場景，抑或是公有云和私有云之間[13]，都使得5G核心網(wǎng)不僅要依托現(xiàn)有云化基礎(chǔ)設(shè)施，還要按需混合部署在虛擬機(jī)、容器（如虛擬機(jī)容器、裸金屬容器等）之上，因?yàn)橹挥羞@樣才能最大程度地實(shí)現(xiàn)資源共享，節(jié)省基礎(chǔ)設(shè)施投資成本[14]。

此外，跨平臺部署的5G網(wǎng)絡(luò)強(qiáng)調(diào)自動化和智能化。將不同平臺和不同云架構(gòu)的應(yīng)用串聯(lián)起來，有助于實(shí)現(xiàn)諸如業(yè)務(wù)一鍵開通、新業(yè)務(wù)快速上線等功能。

（3）易演進(jìn)。為進(jìn)一步提升資源利用率，基于SBA架構(gòu)的5G核心網(wǎng)能夠提供服務(wù)化接口，以便于合作方調(diào)用業(yè)務(wù)功能，實(shí)現(xiàn)NF和網(wǎng)絡(luò)功能服務(wù)（NFS）共享。依照5G標(biāo)準(zhǔn)和產(chǎn)業(yè)逐步發(fā)展的特點(diǎn)，架構(gòu)設(shè)計須側(cè)重前瞻性。比如，公共服務(wù)先期以R16基于服務(wù)的架構(gòu)增強(qiáng)（eSBA）的服務(wù)框架呈現(xiàn)，以降低長期投資成本[15]。

1.2從5GC技術(shù)落地實(shí)踐中挖掘容器技術(shù)價值

雖然容器技術(shù)不是SBA架構(gòu)和上述新特性的必選，但是容器技術(shù)仍具有一些突出優(yōu)勢。

1.2.1微服務(wù)要求每個NF的各個組件以更小的粒度占有資源

微服務(wù)之間通信協(xié)議采用的是面向服務(wù)的開放接口超文本傳輸協(xié)議版本2（HTTP2），原有的虛擬機(jī)資源分配方式無法滿足系統(tǒng)要求，為此引入容器技術(shù)成為必然選擇。

此外，容器化NF不僅可以使生命周期管理（LCM）變得更加高效，還能使自動化編排占有更少的資源。這些都將顯著提升NF和NFS的服務(wù)水平，改善網(wǎng)絡(luò)性能，提升用戶體驗(yàn)，增強(qiáng)對突發(fā)性業(yè)務(wù)的響應(yīng)能力。

1.2.2跨平臺要求NF部署在各種云平臺并支持多種部署方式

這里的云平臺主要指與容器相關(guān)的云平臺。在部署方式上，對邊緣數(shù)據(jù)中心（DC）有更高的時延要求，也有更低成本和低功耗的設(shè)備要求。相應(yīng)地，只有采用輕量級的虛擬化技術(shù)代替?zhèn)鹘y(tǒng)虛擬機(jī)資源，才能滿足這些要求。容器平臺是典型的輕量級虛擬化技術(shù)，已廣泛應(yīng)用于IT領(lǐng)域。

對運(yùn)營商網(wǎng)絡(luò)而言，雖然當(dāng)前NF仍然以VNF形式進(jìn)行部署，但已處于CNF等容器應(yīng)用的初期階段。如圖1所示，結(jié)合近期全球運(yùn)營商的需求，NF的部署形式主要有三大類：VNF、CNF和IT應(yīng)用程序（APP）。這3種部署形式對應(yīng)3種云平臺。基礎(chǔ)設(shè)施即服務(wù)（IaaS）平臺：如主流的虛擬化管理系統(tǒng)Openstack和VMware，即虛擬機(jī)平臺;容器即服務(wù)（CaaS）平臺：如主流容器管理系統(tǒng)K8S，即容器或裸金屬容器平臺;IaaS+CaaS平臺：容器應(yīng)用包裝在虛擬機(jī)資源池里運(yùn)行，即虛擬機(jī)容器平臺。這3種平臺支撐的NF形式分別為（1）IaaS：VNF、ITAPP;（2）CaaS：CNF、ITAPP、部署在CaaS上的VNF;（3）IaaS+CaaS：CNF。

1.2.3易演進(jìn)要求容器技術(shù)為基于SBA的NF和共享公共服務(wù)提供強(qiáng)大支撐

一方面，更小規(guī)格的容器化NF有利于更為靈活的組件資源劃分和動態(tài)調(diào)整。例如，不同使用頻度的NFS將采用不同的資源占用粒度：高頻使用的NFS采用規(guī)格較小的容器部署，低頻使用的NFS采用規(guī)格較大的容器。不同使用頻度的NFS將具備各自的資源調(diào)整能力，易于業(yè)務(wù)快速擴(kuò)展，還能兼顧資源管理開銷和效率。

另一方面，更小規(guī)格的容器化NF便于將業(yè)務(wù)組件和基礎(chǔ)組件分開配置資源。以往以大規(guī)格虛擬機(jī)方式部署的NF，像沒有應(yīng)用集裝箱技術(shù)的貨物運(yùn)輸一樣，資源使用率不高。

為更加清晰地表明以虛擬機(jī)方式部署的VNF和以容器方式部署的CNF之間的差別，如圖2所示，我們做出如下幾種假設(shè)：

（1）VNF=VNFC1+VNFC2

其中，虛擬網(wǎng)絡(luò)功能組件（VNFC）是VNF的一個組成單元。比如，操作維護(hù)管理單元（OMU）是一個VNFC，通用業(yè)務(wù)處理單元（GSU）是另一個VNFC，不同的VNFC有不同的特性。

（2）NF=NFS1+NFS2

NFS是NF（或CNF）的一個組件。每個NFS都由一組相關(guān)的業(yè)務(wù)組件（SC）構(gòu)成，包括操作維護(hù)管理（O&M）、元數(shù)據(jù)管理等。相應(yīng)地，對于歸屬某一類SC1的多個SC，假設(shè)有SC1-1、SC1-2等;對于歸屬某一類SC2的多個SC，假設(shè)有SC2-1、SC2-2等。于是有NFS1=SC1-1+SC2-1、NFS2=SC1-2+SC2-2。（3）VNFC采用虛擬機(jī)方式部署，SC以POD（K8S定義的最小部署單元）方式部署。假設(shè)每個POD都有一個容器，即最常見的單容器POD。

為便于比較，設(shè)SC1和VNFC1是一類功能組件，SC2和VNFC2是另一類功能組件。假設(shè)有兩個節(jié)點(diǎn)各自分配虛擬機(jī)資源，并各自部署一類SC。那么，VNFC1對應(yīng)容器化NF的功能由SC1-1和SC1-2實(shí)現(xiàn)，VNFC2對應(yīng)的功能由SC2-1和SC2-2實(shí)現(xiàn)，即兩種方式的資源消耗相同。

容器方式的好處是基于更小粒度的SC/POD進(jìn)行調(diào)度。其中，POD是K8S中能夠創(chuàng)建和部署的最小單元，是K8S集群中的一個應(yīng)用實(shí)例。而虛擬機(jī)方式則基于VNFC實(shí)現(xiàn)調(diào)度。顯然前者的調(diào)度效率更高，虛擬化管理更加精細(xì)化。此外，NF以微服務(wù)方式對外呈現(xiàn)業(yè)務(wù)，以消息總線呈現(xiàn)接口。因此，基于容器技術(shù)的NF更容易發(fā)揮優(yōu)勢。

此外，容器技術(shù)應(yīng)用于NF還具有其他突出優(yōu)勢：（a）快速交付和部署，比如虛擬機(jī)容器方式可以采用已有的標(biāo)準(zhǔn)鏡像包，并以容器方式部署，具備快速啟動、擴(kuò)容和縮容的特點(diǎn)，可大幅度節(jié)約時間;（b）容器技術(shù)是面向內(nèi)核的虛擬化技術(shù)，不需要額外Hypervisor的介入，其虛擬化效率更高，需要額外開銷的資源更少;（c）基于共享Linux內(nèi)核技術(shù)，自動化部署和維護(hù)更加簡便。

1.2.4在NFS占有資源方面容器技術(shù)更具優(yōu)勢

一般而言，包含訪客操作系統(tǒng)在內(nèi)，采用虛擬機(jī)方式部署的中央處理器（CPU）消耗為0%～15%，內(nèi)存消耗為吉比特量級，鏡像文件規(guī)模在兆比特到吉比特之間。容器方式則可以共享Linux內(nèi)核且通過進(jìn)程隔離來實(shí)現(xiàn)微服務(wù)化的應(yīng)用。容器方式的CPU消耗在0%～5%，內(nèi)存消耗在兆比特量級，鏡像文件規(guī)模在千比特到兆比特之間。圖3給出了虛擬機(jī)架構(gòu)和容器架構(gòu)的對比。

2容器演進(jìn)路線

無論是CNCF定義的云原生，還是3GPPR15、R16等版本定義5G核心網(wǎng)所需的SBA架構(gòu)、微服務(wù)、跨平臺等，容器技術(shù)必然被納入5G電信云網(wǎng)絡(luò)的技術(shù)規(guī)劃中。電信云從虛擬化到云化，承載著4G網(wǎng)絡(luò)改造的兩大訴求：如何實(shí)現(xiàn)彈性、智能、可管可控的網(wǎng)絡(luò)？在流量增收不增利的情況下，如何實(shí)現(xiàn)低成本建網(wǎng)和高效運(yùn)維？

在5G階段，電信云不僅要滿足網(wǎng)絡(luò)從4G向5G發(fā)展的業(yè)務(wù)側(cè)要求，還要進(jìn)一步提升網(wǎng)絡(luò)性能，支撐eMBB、mMTC、URLLC等多場景需求，并完成“一云多構(gòu)、一網(wǎng)多制”的轉(zhuǎn)變。從2G到5G的發(fā)展過程看，無論是不斷豐富的業(yè)務(wù)功能和日益完善的用戶體驗(yàn)，還是網(wǎng)絡(luò)側(cè)從會話初始協(xié)議（SIP）到應(yīng)用程序的認(rèn)證、鑒權(quán)、計費(fèi)框架協(xié)議（Diameter），都證實(shí)了一點(diǎn)：兼容和開放是電信網(wǎng)絡(luò)發(fā)展的永恒主旨。

結(jié)合中國運(yùn)營商的5G發(fā)展思路，我們從如下兩個角度分析如何從目前基于虛擬機(jī)的VNF演進(jìn)到基于容器的CNF。

（1）兼容性

演進(jìn)過程要考慮原有VNF長期共存的要求，這里我們以5G核心網(wǎng)為例進(jìn)行說明。一方面，雖然分組數(shù)據(jù)網(wǎng)的網(wǎng)元將首次應(yīng)用在5G網(wǎng)絡(luò)，并定義微服務(wù)化NF，如接入管理功能（AMF）、會話管理功能（SMF）、用戶面功能（UPF），但是相關(guān)協(xié)議對電路域（CS）和IP多媒體子系統(tǒng)（IMS）的定義尚未完成或成熟度不足。另一方面，存量VNF遷移到CNF，并沒有形成平滑改造的共識。

（2）開放性

容器應(yīng)用在IT領(lǐng)域已成為主流，但是在電信領(lǐng)域還沒有得到廣泛應(yīng)用。

目前，從虛擬機(jī)向容器演進(jìn)的方式有虛擬機(jī)容器和裸機(jī)容器兩種。虛擬機(jī)容器方式下CNF的編排接口沒有納入?yún)f(xié)議規(guī)范，同時供應(yīng)商對裸機(jī)容器方式的具體實(shí)現(xiàn)方式存在爭議。為此，支撐從VNF向CNF演進(jìn)的容器技術(shù)、云管理系統(tǒng)和編排器，都需要具備充分的開放性，以避免日后在引入新應(yīng)用或新技術(shù)時，面臨重新部署甚至重構(gòu)整個系統(tǒng)的被動局面。

當(dāng)前，中國三大運(yùn)營商已規(guī)模部署5G核心網(wǎng)（5GC）網(wǎng)絡(luò)設(shè)備，同時各種5GC應(yīng)用以VNF形式部署。如圖4中的初期所示，各廠家即使引入容器技術(shù)也無須對外呈現(xiàn)，即不必對外提供容器管理功能。盡管如此，VNF方式仍有諸多優(yōu)點(diǎn)：標(biāo)準(zhǔn)程度、商用成熟度和虛擬機(jī)隔離方案的安全性都很高，擁有成熟的轉(zhuǎn)發(fā)面優(yōu)化技術(shù)等。基于目前成熟的IaaS云平臺方案和產(chǎn)品，VNF方式有利于5GC網(wǎng)絡(luò)建設(shè)初期的快速部署和運(yùn)營。然而，沒有引入開放的容器技術(shù)且不滿足CNF要求的可感知K8S接口，是基于虛擬機(jī)方式部署VNF的最大不足。

如圖4所示，發(fā)展期引入了虛擬機(jī)容器方案。該方案既支持容器化部署，滿足運(yùn)營商對容器的管理需求，又擁有虛擬機(jī)的安全能力，同時可應(yīng)用于那些對安全隔離有較高需求的場景。影響該階段快速發(fā)展的因素主要有兩個：（1）相關(guān)標(biāo)準(zhǔn)尚不成熟，如歐洲電信標(biāo)準(zhǔn)化協(xié)會（ETSI）協(xié)議沒有定義K8S容器管理系統(tǒng)和管理和網(wǎng)絡(luò)編排（MANO）的接口;（2）IaaS云平臺、硬件和APP的三方解耦轉(zhuǎn)變?yōu)楹蠧aaS云平臺的四方解耦，這使技術(shù)的選擇難度和驗(yàn)證難度變得更大，商業(yè)成熟期變得更久。

隨著容器應(yīng)用進(jìn)入成熟期，靈活的應(yīng)用、彈性的網(wǎng)絡(luò)和多層次的安全管控都將裸機(jī)容器平臺推向主流。如2G/3G/4G和5G長期共存一樣，該階段仍要兼顧多種NF部署方式，最終才能實(shí)現(xiàn)“一云多構(gòu)”的綜合云平臺。

3容器演進(jìn)方案

如前文所述，電信云網(wǎng)絡(luò)從虛擬機(jī)部署轉(zhuǎn)變?yōu)槿萜鞑渴?，需要?jīng)歷多個階段。從需求的角度看，業(yè)務(wù)網(wǎng)元在前，支撐它的云平臺在后;從網(wǎng)絡(luò)建設(shè)和演進(jìn)的角度看，云平臺基礎(chǔ)設(shè)施建設(shè)在前，相應(yīng)的業(yè)務(wù)網(wǎng)元部署在后。由此可見，業(yè)務(wù)網(wǎng)元和云平臺之間將相關(guān)作用、互相影響。

在云平臺長期演進(jìn)過程中，支持容器的云平臺同時也要支持原有的虛擬機(jī)部署方式。容器部署包括虛擬機(jī)容器、裸機(jī)容器、未來“容器化的VNF”等方式（VNFoverContainer）。對于業(yè)務(wù)網(wǎng)元來說，從基于虛擬機(jī)部署發(fā)展到基于容器部署是一個漸進(jìn)過程，它要求虛擬機(jī)部署的網(wǎng)元逐步遷移到容器平臺上。

按照容器平臺提供者和虛擬機(jī)平臺提供者的異同，以及部署場景的不同，我們提出如下容器演進(jìn)方案。

3.1邊緣云部署先行

圍繞5G核心網(wǎng)對電信云的新需求，比如控制面和媒體面分離（CUPS），媒體面下沉將帶來本地分流和業(yè)務(wù)時延減少。為此，將MEP、UPF等網(wǎng)元下沉到邊緣，意味著邊緣云網(wǎng)絡(luò)建設(shè)必將先行。

與中心DC相比，邊緣DC的邊緣云具備3個特點(diǎn)。（1）可改善系統(tǒng)性能，如具有硬件加速功能。（2）擁有多樣性的云管理系統(tǒng)和SDN[16-17]。不同于重量級的中心DC、功能豐富的云管理系統(tǒng)和SDN，邊緣云注重高效、輕量和易管理。（3）軟硬件傾向高度集成，便于快速安裝、上線和擴(kuò)容。

因此，容器化應(yīng)用和容器平臺大多首先部署在邊緣云。如圖5所示，邊緣云部署包括3個部分：

（1）新建邊緣云網(wǎng)絡(luò)和相關(guān)應(yīng)用

邊緣云硬件基礎(chǔ)設(shè)施和云管理系統(tǒng)應(yīng)滿足幾個方面的需求：提供專有硬件支撐的硬件加速方案，以優(yōu)化媒體面性能;制定虛擬化加速方案，以提升應(yīng)用面的包轉(zhuǎn)發(fā)能力;具有虛擬交換軟件（OpenvSwitch）+數(shù)據(jù)平面開發(fā)工具集（DPDK）卸載能力，以便采用專有硬件來優(yōu)化CPU性能;增加MANO和網(wǎng)元管理系統(tǒng)（EMS）對專有加速硬件的統(tǒng)一編排和管理能力;云管理系統(tǒng)能夠推薦緊湊型的容器平臺或者虛擬機(jī)和容器融合的綜合云平臺。

（2）實(shí)現(xiàn)邊緣云和中心DC的云網(wǎng)絡(luò)互通

中心DC的云網(wǎng)絡(luò)和邊緣云需要分開部署，擁有各自獨(dú)立的交換網(wǎng)絡(luò)、SDN、DC-分組數(shù)據(jù)網(wǎng)關(guān)（GW），以實(shí)現(xiàn)業(yè)務(wù)面的互聯(lián)互通。同時網(wǎng)絡(luò)功能虛擬化編排器（NFVO）和EMS功能將納入全網(wǎng)統(tǒng)一管理。

（3）擴(kuò)容中心DC的云網(wǎng)絡(luò)

在邊緣云部署的業(yè)務(wù)網(wǎng)元需要與中心DC的業(yè)務(wù)網(wǎng)元協(xié)同工作。例如，AMF和SMF仍然需要部署在中心DC上，同時SMF能夠按不同策略選擇分布式部署的UPF。NFVO和EMS功能也將納入全網(wǎng)統(tǒng)一管理。

3.2中心DC容器演進(jìn)方案兼顧現(xiàn)網(wǎng)VNF

引入CaaS容器平臺的方式不同，產(chǎn)生的容器演進(jìn)方案也會不同。一種方式是在現(xiàn)有IaaS資源池部署容器應(yīng)用;另外一種方式是，首先為容器平臺和應(yīng)用新建一個獨(dú)立的資源池，然后在初期與現(xiàn)有IaaS虛擬機(jī)平臺共存，最終實(shí)現(xiàn)虛擬機(jī)與容器融合的綜合平臺。

（1）依托現(xiàn)有IaaS資源池的演進(jìn)方案

將中心DC的虛擬機(jī)部署方式改造成虛擬機(jī)容器混合部署方式的高效方案是升級現(xiàn)有IaaS云平臺。這種方案尤其適用于IaaS和CaaS平臺均來自同一個供應(yīng)商的情況，如圖6所示。

升級方案具體包括：（a）升級IaaS云平臺和SDN支持5GC容器應(yīng)用，如支持加速硬件和交換網(wǎng)絡(luò);（b）如果步驟a不能對VNF不可見，則VNF將重新上電或進(jìn)行重新部署;（c）資源池擴(kuò)容，如部署5GC業(yè)務(wù)網(wǎng)元或擴(kuò)容4G網(wǎng)元;（d）部署CaaS容器平臺，如果是異廠家的容器平臺，建議采用IaaS平臺不感知的容器方案;（e）部署5GC容器應(yīng)用。

（2）新建容器資源池

一般而言，現(xiàn)有IaaS平臺承載的4G業(yè)務(wù)是客戶的收入來源。當(dāng)5G網(wǎng)絡(luò)處于初期或?qū)嶒?yàn)階段時，在成熟網(wǎng)絡(luò)上疊加5G網(wǎng)絡(luò)并不是最佳選擇。5G網(wǎng)絡(luò)所需要的硬件和網(wǎng)絡(luò)基礎(chǔ)設(shè)施與4G相比有顯著差別，如支持URLLC的高性能硬件、切片網(wǎng)絡(luò)所需的特殊軟硬件等。此外，當(dāng)容器平臺來自新的供應(yīng)商時，新建容器資源池具備一定優(yōu)勢。

與新建邊緣云類似，5G應(yīng)用建設(shè)需要獨(dú)立的容器云網(wǎng)絡(luò)。這里我們以虛擬機(jī)容器方案為例進(jìn)行說明。考慮到4G和5G融合部署的需求，5G核心網(wǎng)要支持回落到4G網(wǎng)絡(luò)的5G用戶仍可以接入同一張核心網(wǎng)，即實(shí)現(xiàn)業(yè)務(wù)網(wǎng)元在新建容器云和現(xiàn)網(wǎng)的云網(wǎng)絡(luò)之間的按需分布。

由于統(tǒng)一云平臺需求有利于降低運(yùn)維和新業(yè)務(wù)部署的費(fèi)用，容器技術(shù)下一步演進(jìn)方向是在容器云的基礎(chǔ)上實(shí)現(xiàn)原VNF的遷移。這里遷移方式包括兩種：現(xiàn)有VNF遷移到容器云上，保留原有VNF部署方式;基于已有虛擬機(jī)容器混合云或已部署的CNF來實(shí)現(xiàn)VNF功能的遷移。

第1種遷移方式適合容器云和現(xiàn)有VNF不是同一個供應(yīng)商的情況。VNF供應(yīng)商希望在盡量不感知的情況下將VNF遷移到新平臺，以便減少遷移費(fèi)用并維持業(yè)務(wù)平滑過渡。

第2種遷移方式一般用于第1種遷移方式不可行或者現(xiàn)有VNF已老舊甚至過保的情況。將現(xiàn)有VNF合并到容器云上的CNF，有利于降低運(yùn)維費(fèi)用，提升資源利用率和運(yùn)維效率。對于第2種方式，我們推薦使用裸機(jī)容器，以便VNF徹底遷移到CNF。

4容器演進(jìn)實(shí)踐

眾所周知，目前業(yè)界的虛擬化核心網(wǎng)的網(wǎng)元主要以虛擬機(jī)方式部署。如何從VNF遷移到CNF，成為運(yùn)營商最為關(guān)心的話題之一。以VNF向虛擬機(jī)容器方案演進(jìn)為例，綜合考慮2G/3G/4G核心網(wǎng)向5G演進(jìn)的相關(guān)設(shè)計和步驟，我們在本節(jié)說明容器演進(jìn)的實(shí)踐情況。

4.1應(yīng)用演進(jìn)階段

第1階段：5G非獨(dú)立組網(wǎng)（NSA）部署階段。這一階段的訴求是：在不割離VNF的情況下升級VNF，以支持5GNSA網(wǎng)絡(luò)。3GPPR15定義的NSA網(wǎng)絡(luò)已滿足大部分eMBB業(yè)務(wù)需求。在不改變現(xiàn)有IaaS平臺、不引入容器平臺的情況下，平滑升級VNF是支持5GNSA的最佳方式。這樣做的原因是，部署基于R16的5GSA網(wǎng)絡(luò)相當(dāng)于對現(xiàn)網(wǎng)的業(yè)務(wù)網(wǎng)元進(jìn)行重構(gòu)，無法在兼顧投入和收益的情況下滿足不同國家和不同運(yùn)營商的需求。

第2階段：5GC初期部署階段。這一階段具體包括：（a）基于虛擬機(jī)容器方式部署一些2G/3G/4G/5G融合的CNF，具體包括分組域（PS）、用戶數(shù)據(jù)管理（SDM）、策略控制功能（PCF）/策略與計費(fèi)規(guī)則功能（PCRF）等。此時，原IaaS平臺要改造成IaaS和CaaS的混合平臺;（b）保持其他VNF不變，例如IMS、CS等;（c）升級EMS，同時兼顧VNF和CNF管理。

第3階段：5GC大規(guī)模部署階段。（a）對CNF進(jìn)行擴(kuò)容以支持更大容量，同時引入新CNF以支撐大規(guī)模部署，并增強(qiáng)網(wǎng)絡(luò)靈活性，如安全邊緣保護(hù)代理（SEPP）和服務(wù)通信代理（SCP）;（b）將STP、DRA和基于位置的服務(wù)（LBS）等從VNF遷移到CNF;（c）由于沒有進(jìn)一步的業(yè)務(wù)功能需求，CS仍采用VNF方式部署。

4.2從VNF演進(jìn)到CNF的具體步驟

CNF是基于虛擬機(jī)容器的應(yīng)用，而VNF只是基于虛擬機(jī)的應(yīng)用，沒有容器。對于NF而言，從VNF到CNF的遷移過程類似于把“大象”裝進(jìn)“冰箱”。下面我們將簡單描述如何完成從VNF到CNF的遷移過程。

如圖7所示，VNF和CNF的架構(gòu)與組件差異很大，沒法通過軟件升級方式實(shí)現(xiàn)業(yè)務(wù)功能遷移。這需要先在IaaS平臺實(shí)例化NF，然后再實(shí)現(xiàn)VNF的業(yè)務(wù)功能。具體操作步驟大致有4個。

（1）新建控制節(jié)點(diǎn)：提供支持基于虛擬機(jī)容器的CNFIaaS平臺，如支持5GC和虛擬機(jī)容器應(yīng)用的OpenStack平臺。

（2）計算節(jié)點(diǎn)實(shí)現(xiàn)NF遷移，具體步驟包括：備份節(jié)點(diǎn)的IaaS平臺數(shù)據(jù)和VNF配置數(shù)據(jù);在空余硬件上裝載支持CNF的IaaS平臺，如Hypervisor/分布式虛擬交換機(jī)（DVS）等;在管理節(jié)點(diǎn)上裝載支持CNF版本的MANO，并打通原VIM接口;在空余硬件上初始化含K8S組件的CNF，使業(yè)務(wù)配置數(shù)據(jù)與VNF相同，同時打通相關(guān)組件的接口，在業(yè)務(wù)調(diào)試成功后投入CNF資源池，使NF層面和VNF保持負(fù)荷分擔(dān)或容災(zāi)關(guān)系;將某VNF的業(yè)務(wù)功能遷移到該CNF上;釋放原VNF占有的硬件資源;重復(fù)上述步驟，直至完成全部計算節(jié)點(diǎn)的NF升級。

（3）管理節(jié)點(diǎn)升級，具體包括：備份管理節(jié)點(diǎn)的數(shù)據(jù)配置;建立新的管理節(jié)點(diǎn);從備份數(shù)據(jù)恢復(fù)數(shù)據(jù)配置;完成新管理節(jié)點(diǎn)和全部CNF節(jié)點(diǎn)的業(yè)務(wù)調(diào)試;原管理節(jié)點(diǎn)下電，以釋放資源。

（4）SDN和交換網(wǎng)絡(luò)升級。一般認(rèn)為交換網(wǎng)絡(luò)（如SDN）和IaaS平臺有接口，無須和CaaS平臺開通接口。構(gòu)建CNF資源池的工作包括接管原VNF的交換功能，這使得SDN和交換網(wǎng)絡(luò)仍然有升級的需求：升級SDN以支持CNF;升級交換網(wǎng)絡(luò)設(shè)備（如DC-GW、Spine和Leaf）;更新SDN和交換網(wǎng)絡(luò)設(shè)備的管理接口。

5結(jié)束語

隨著基于NFV的5G核心網(wǎng)規(guī)模商用，采用IaaS平臺和虛機(jī)部署方式的VNF網(wǎng)絡(luò)已成為5GSA網(wǎng)絡(luò)建設(shè)的開端。VNF網(wǎng)絡(luò)將支撐以eMBB為主的2C應(yīng)用和以URLLC/mMTC為主的2B應(yīng)用。然而，基于容器技術(shù)的5G電信云網(wǎng)絡(luò)將促使5G核心網(wǎng)應(yīng)用產(chǎn)生更多價值。從目前全球IaaS網(wǎng)絡(luò)建設(shè)的現(xiàn)狀來看，虛擬機(jī)容器方案是5G電信云網(wǎng)絡(luò)演進(jìn)的重點(diǎn)。同時，從虛擬機(jī)部署到虛擬機(jī)容器部署的演進(jìn)具有的更好平滑性。本文中，我們結(jié)合實(shí)踐案例，從應(yīng)用、云平臺和硬件等多個角度闡述5G電信云網(wǎng)絡(luò)演進(jìn)過程的要點(diǎn)和詳細(xì)步驟，希望為廣大電信網(wǎng)絡(luò)和技術(shù)工作者提供一些參考。

參考文獻(xiàn)

[1]CNCF.Whatiscloudnative？[EB/OL].（2018-06-11）[2021-11-06].https：//www.cncf.io/about/faq/#what-is-cloud-native

[2]陳佳媛，王瑞雪，班有容，等.中國移動面向5G的電信云基礎(chǔ)設(shè)施技術(shù)研究和實(shí)踐[J].移動通信，2019，（1）：57-62

[3]陸平，李建華，趙維鐸.5G在垂直行業(yè)中的應(yīng)用[J].中興通訊技術(shù)，2019，25（1）：67-74.DOI：10.12142/ZTETJ.201901011

[4]李珊，張春明，汪衛(wèi)國.5G商用起步，融合應(yīng)用蓬勃興起[J].中興通訊技術(shù)，2019，25（6）：2-7.DOI：10.12142/ZTETJ.201906001

[5]陳億根，尹曉峰，邵黎勛.5G+工業(yè)互聯(lián)網(wǎng)應(yīng)用實(shí)踐[J].中興通訊技術(shù)，2020，26（6）：2-6.DOI：10.12142/ZTETJ.202006002

[6]ETSI.NetworkFunctionsVirtualisation（NFV）;usecases：ETSIGSNFV001[S/OL].（2018-07-03）[2021-11-06].https：//www.etsi.org/technolo-gies-clusters/technologies/nfv

[7]ETSI.NetworkFunctionsVirtualisation（NFV）;ar-chitecturalframework：ETSIGSNFV002[S/OL].（2019-12-02][2021-11-06].https：//www.etsi.org/de-liver/etsi_gs/NFV/001_099/002/01.02.01_60/gs_NFV002v010201p.pdf

[8]ETSI.NetworkFunctionsVirtualisation（NFV）;terminologyformainconceptsinNFV：ETSIGSNFV003[S/OL].（2019-12-02][2021-11-06].https：//www.etsi.org/deliver/etsi_gs/NFV/001_099/003/01.04.01_60/gs_NFV-003v010401p.pdf

[9]ETSI.NetworkFunctionsVirtualisation（NFV）;vir-tualisationrequirements：ETSIGSNFV004[S/OL].（2019-12-02][2021-11-06].https：//www.etsi.org/deliver/etsi_gs/NFV/001_099/004/01.01.01_60/gs_NFV004v010101p.pdf

[10]ETSI.NetworkFunctionsVirtualisation（NFV）;infrastructureoverview：ETSIGSNFV-INF001[S/OL].（2019-12-02][2021-11-06].https：//www.etsi.org/deliver/etsi_gs/NFV-INF/001_099/001/01.01.01_60/gs_NFV-IN-F001v010101p.pdf

[11]3GPP.Systemarchitectureforthe5Gsystem（Re-lease15）：3GPPTS23.501[S/OL].（2019-12-02）[2021-11-06].https：//www.3gpp.org/

[12]3GPP.Proceduresforthe5GSystem（Release15）：3GPPTS23.502[S/OL].（2019-12-02）[2021-11-06].https：//www.3gpp.org/

[13]史庭祥，田會芹.云化網(wǎng)絡(luò)多租戶改造方案分析和實(shí)踐[J].郵電設(shè)計技術(shù)，2020，（4）：80-84

[14]史庭祥，田會芹.電信基礎(chǔ)網(wǎng)絡(luò)共享技術(shù)研究和實(shí)踐[J].電信網(wǎng)技術(shù)，2017，（7）：40-45

[15]史庭祥，田會芹.無線核心網(wǎng)的TCO分析方法研究[J].中興通訊技術(shù)，2016，22（1）：50-53.DOI：10.3969/j.issn.1009-6868.2016.01.013

[16]劉旭，李俠宇，朱浩.5G中的SDN/NFV和云計算[J].電信網(wǎng)技術(shù)，2015，（5）：1-4

[17]張朝昆，崔勇，唐翯翯，等.軟件定義網(wǎng)絡(luò)（SDN）研究進(jìn)展[J].軟件學(xué)報，2015，26（1）：62-81

作者簡介

史庭祥，中興通訊股份有限公司高級工程師;主要研究方向?yàn)樵朴嬎?、核心網(wǎng)、虛擬運(yùn)營及其關(guān)鍵技術(shù);發(fā)表論文10余篇，獲發(fā)明專利10余項（國際專利2項）。

徐法祿，中興通訊股份有限公司系統(tǒng)產(chǎn)品MKT及方案部副部長;擁有多年通信行業(yè)的從業(yè)經(jīng)驗(yàn)，曾從事CDMA、FDDLTE、5G等產(chǎn)品的研發(fā)和規(guī)劃;獲得國家科技進(jìn)步獎二等獎、深圳市科技進(jìn)步獎一等獎、IF設(shè)計獎、GTI移動業(yè)務(wù)應(yīng)用創(chuàng)新獎、IF紅點(diǎn)獎等獎項。

章璐，中興通訊股份有限公司電信云與核心網(wǎng)產(chǎn)品線產(chǎn)品規(guī)劃總工、高級工程師;研究方向?yàn)殡娦旁婆c核心網(wǎng)的組網(wǎng)及其關(guān)鍵技術(shù);發(fā)表論文10余篇，擁有專利10余項。