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余项。