史庭祥 徐法祿 章璐

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

關(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īng)過了10余年的歷程。2006年8月9日，ERICSCHMIDT在搜索引擎大會上首次提出了“云計算”的概念。隨后，云計算在IT市場被廣泛使用。

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

為統(tǒng)一云原生接口標準，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ā)起并維護的基于Docker的開源容器集群管理系統(tǒng)。K8S容器集群能在私有云、公有云或者混合云之上運行。K8S屬于主從的分布式集群架構(gòu)，包含Master和Node。其中，Master作為控制節(jié)點，可以調(diào)度和管理整個系統(tǒng);Node是運行節(jié)點，可以運行業(yè)務(wù)容器。

根據(jù)CNCF對云原生的定義，云原生網(wǎng)絡(luò)功能（CNF）和K8S的設(shè)計與架構(gòu)應(yīng)滿足相應(yīng)要求[1]。為此，基于容器的云原生應(yīng)用，通常需要滿足幾個條件：具有微服務(wù)體系結(jié)構(gòu)、可拆分性和獨立的業(yè)務(wù)邏輯，不僅支持獨立擴展，還支持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獨立組網(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標準滿足增強移動寬帶（eMBB）商用要求，和R16一起為5G核心網(wǎng)定義SBA，并支持如下幾方面的新特性[6-12]。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（1）VNF=VNFC1+VNFC2

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

（2）NF=NFS1+NFS2

NFS是NF（或CNF）的一個組件。每個NFS都由一組相關(guān)的業(yè)務(wù)組件（SC）構(gòu)成，包括操作維護管理（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采用虛擬機方式部署，SC以POD（K8S定義的最小部署單元）方式部署。假設(shè)每個POD都有一個容器，即最常見的單容器POD。

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

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

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

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

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

2容器演進路線

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

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

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

（1）兼容性

演進過程要考慮原有VNF長期共存的要求，這里我們以5G核心網(wǎng)為例進行說明。一方面，雖然分組數(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)用。

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

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

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

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

3容器演進方案

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

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

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

3.1邊緣云部署先行

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

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

因此，容器化應(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)能夠推薦緊湊型的容器平臺或者虛擬機和容器融合的綜合云平臺。

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

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

（3）擴容中心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容器演進方案兼顧現(xiàn)網(wǎng)VNF

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

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

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

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

（2）新建容器資源池

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

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

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

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

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

4容器演進實踐

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

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

第1階段：5G非獨立組網(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ò)相當于對現(xiàn)網(wǎng)的業(yè)務(wù)網(wǎng)元進行重構(gòu)，無法在兼顧投入和收益的情況下滿足不同國家和不同運營商的需求。

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

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

4.2從VNF演進到CNF的具體步驟

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

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

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

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

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

（4）SDN和交換網(wǎng)絡(luò)升級。一般認為交換網(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平臺和虛機部署方式的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)狀來看，虛擬機容器方案是5G電信云網(wǎng)絡(luò)演進的重點。同時，從虛擬機部署到虛擬機容器部署的演進具有的更好平滑性。本文中，我們結(jié)合實踐案例，從應(yīng)用、云平臺和硬件等多個角度闡述5G電信云網(wǎng)絡(luò)演進過程的要點和詳細步驟，希望為廣大電信網(wǎng)絡(luò)和技術(shù)工作者提供一些參考。

參考文獻

[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ù)研究和實踐[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)用實踐[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ò)多租戶改造方案分析和實踐[J].郵電設(shè)計技術(shù)，2020，（4）：80-84

[14]史庭祥，田會芹.電信基礎(chǔ)網(wǎng)絡(luò)共享技術(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].軟件學(xué)報，2015，26（1）：62-81

作者簡介

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

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

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