5G電信云網絡的容器演進方案

史庭祥 徐法祿 章璐

摘要：以云原生計算基金會（CNCF）定義的容器技術為出發點，從技術方案和客戶價值兩個維度分析5G電信云網絡引入容器技術的必要性。討論了演進路線的兼容性和開放性，并針對不同的部署場景和云平臺新老供應商提出了相關演進方案。基于項目實踐，給出了分階段部署應用和虛擬網絡功能平滑遷移到基于虛擬機容器的云原生網絡功能詳細過程。

關鍵詞：5G核心網;容器;云原生;電信云;微服務

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

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

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

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

為統一云原生接口標準，2015年7月云原生計算基金會（CNCF）成立。該基金會的會員包括Google、IBM、Intel、Docker、RedHat等國際著名公司，代表了業界最領先的容器技術和云計算技術。CNCF致力于通過技術優勢和用戶價值創造一套新的通用容器技術，以推動云計算和相關服務的發展。

CNCF中最知名的項目是Kubernetes（以下簡稱K8S）。K8S是Google發起并維護的基于Docker的開源容器集群管理系統。K8S容器集群能在私有云、公有云或者混合云之上運行。K8S屬于主從的分布式集群架構，包含Master和Node。其中，Master作為控制節點，可以調度和管理整個系統;Node是運行節點，可以運行業務容器。

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

1電信云網絡在5G階段引入容器技術的必要性

隨著全球5G網絡建設浪潮的到來[2-5]，電信網絡中以5G獨立組網（SA）核心網為代表的業務網元，需要引入容器技術。

1.1第3代合作伙伴計劃（3GPP）協議定義的服務化架構（SBA）和相關新特性

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

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

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

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

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

此外，跨平臺部署的5G網絡強調自動化和智能化。將不同平臺和不同云架構的應用串聯起來，有助于實現諸如業務一鍵開通、新業務快速上線等功能。

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

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

雖然容器技術不是SBA架構和上述新特性的必選，但是容器技術仍具有一些突出優勢。

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

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

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

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

這里的云平臺主要指與容器相關的云平臺。在部署方式上，對邊緣數據中心（DC）有更高的時延要求，也有更低成本和低功耗的設備要求。相應地，只有采用輕量級的虛擬化技術代替傳統虛擬機資源，才能滿足這些要求。容器平臺是典型的輕量級虛擬化技術，已廣泛應用于IT領域。

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

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

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

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

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

（1）VNF=VNFC1+VNFC2

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

（2）NF=NFS1+NFS2

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

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

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

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

1.2.4在NFS占有資源方面容器技術更具優勢

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

2容器演進路線

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

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

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

（1）兼容性

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

（2）開放性

容器應用在IT領域已成為主流，但是在電信領域還沒有得到廣泛應用。

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

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

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

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

3容器演進方案

如前文所述，電信云網絡從虛擬機部署轉變為容器部署，需要經歷多個階段。從需求的角度看，業務網元在前，支撐它的云平臺在后;從網絡建設和演進的角度看，云平臺基礎設施建設在前，相應的業務網元部署在后。由此可見，業務網元和云平臺之間將相關作用、互相影響。

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

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

3.1邊緣云部署先行

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

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

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

（1）新建邊緣云網絡和相關應用

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

（2）實現邊緣云和中心DC的云網絡互通

中心DC的云網絡和邊緣云需要分開部署，擁有各自獨立的交換網絡、SDN、DC-分組數據網關（GW），以實現業務面的互聯互通。同時網絡功能虛擬化編排器（NFVO）和EMS功能將納入全網統一管理。

（3）擴容中心DC的云網絡

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

3.2中心DC容器演進方案兼顧現網VNF

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

（1）依托現有IaaS資源池的演進方案

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

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

（2）新建容器資源池

一般而言，現有IaaS平臺承載的4G業務是客戶的收入來源。當5G網絡處于初期或實驗階段時，在成熟網絡上疊加5G網絡并不是最佳選擇。5G網絡所需要的硬件和網絡基礎設施與4G相比有顯著差別，如支持URLLC的高性能硬件、切片網絡所需的特殊軟硬件等。此外，當容器平臺來自新的供應商時，新建容器資源池具備一定優勢。

與新建邊緣云類似，5G應用建設需要獨立的容器云網絡。這里我們以虛擬機容器方案為例進行說明。考慮到4G和5G融合部署的需求，5G核心網要支持回落到4G網絡的5G用戶仍可以接入同一張核心網，即實現業務網元在新建容器云和現網的云網絡之間的按需分布。

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

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

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

4容器演進實踐

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

4.1應用演進階段

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

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

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

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

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

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

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

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

（3）管理節點升級，具體包括：備份管理節點的數據配置;建立新的管理節點;從備份數據恢復數據配置;完成新管理節點和全部CNF節點的業務調試;原管理節點下電，以釋放資源。

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

5結束語

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

參考文獻

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

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

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

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

[5]陳億根，尹曉峰，邵黎勛.5G+工業互聯網應用實踐[J].中興通訊技術，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]史庭祥，田會芹.云化網絡多租戶改造方案分析和實踐[J].郵電設計技術，2020，（4）：80-84

[14]史庭祥，田會芹.電信基礎網絡共享技術研究和實踐[J].電信網技術，2017，（7）：40-45

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

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

[17]張朝昆，崔勇，唐翯翯，等.軟件定義網絡（SDN）研究進展[J].軟件學報，2015，26（1）：62-81

作者簡介

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

徐法祿，中興通訊股份有限公司系統產品MKT及方案部副部長;擁有多年通信行業的從業經驗，曾從事CDMA、FDDLTE、5G等產品的研發和規劃;獲得國家科技進步獎二等獎、深圳市科技進步獎一等獎、IF設計獎、GTI移動業務應用創新獎、IF紅點獎等獎項。

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