各位专家大家下午好，我是来自中国移动研究院的陈佳媛，特别感谢大会给我们这样一个机会跟大家分享一下我们在NFV这个成熟，商用包括落实过程当中我们获得一些成果，还有我们遇到一些问题。

我的演讲分为两个部分，第一个是我们到目前为止NFV实践和一些应用，然后主要的话讲一讲我们中国在NFV这一块下一步的一个研究重点方向。

中国移动网络分为两个大层，一个核心层，第二下面边缘层，核心层会主要部署控制网元，中国移动在NFV主要在核心层这一块，到目前为止的话我们其实是把核心层已经推到商用这个阶段了，核心层里面把网元设计包括配置都已经规范化，满足三层解耦的要求。其次对于硬件这一块我们已经是确定了很明确服务器配置要求，也确定会有分布式的存储。从底层网络这一块我们也是很明确是说，会把管理存储以及这个业务分成三个独立的业务平面进行一个组网。

在核心云的工作里面我想重点介绍我们做了NFV三层解耦，除了中国移动，包括联通、电信包括移动运营商，他们肯定会遇到这样的问题，怎么来做解耦。在国外有一些运营商直接指定虚拟层的厂家，让上层业务跟指定虚拟层进行对接，这样就相对简单一点，中国移动没有短名单的机制，我们不可能说指定某一个虚拟层，第二个原因我们希望对这个虚拟层有一定的掌控力，不希望这个虚拟层频繁迭代更新，这个平台作为底层东西是要为上层业务服务的。基于这个原因，我们就做了一个三层解耦，希望按照中国移动的期望一步一步演进，而且也是可管可控模块。

对照右边架构图从五个维度对三层解耦进行一个定义。首先是虚拟层与网元兼容性，在测试集成过程当中，我们经常会遇到，因为厂家这个网元增强一些定义，包括一些个性化的配置会导致这个厂家对接会出现问题，在这个接口上，可能是一个网元对于底层虚拟资源的需求，包括虚拟层怎么向上层提供能力这么一个约定，我们把这个东西统一规范一下，保证厂家网元可以进行正常部署和运行。我们要求所有网元都按照这个进行设置和配置，确保三层解耦配置和运行。第二和第三结果处在统一位置，从功能角度分成两个点，所有的ABCD定完以后再回到虚拟层本身，我们是从建设、组网、运维等等方面把虚拟层功能性能可靠性都进行统一定制。

目前的话我们三层解耦已经试点进行验证了，厂家满足程度还是可以的。我今天演讲主要是想跟大家分享一下NFV下一步重点研究方向，好多点刚才赵院长都已经提到过了。第一个重点方向就是边缘云，大家也猜到了核心云做完了就是往下走做边缘云，边缘计算现在很火边缘云跟边缘计算关系是什么？边缘云其实组成边缘计算里面各种各样不同类型基础设施一种，这种对运营商来说非常重要，这一层上面运营商不仅可以部署网元，4G、5G网元，同时也可以部署垂直行业边缘计算新型网元，这些网元特点是什么？非常突出，首先就是大容量，比如说CDN等等，其次实验会非常短，还有一些计算密集型的业务，包括深度学习AI等等，部署在运营商网络里面只有可能部署在边缘云，基于这个原因，要满足这些业务需求，我们边缘云位置基本上也就确定了，从接入这个DC到曲线不超过300公里这个范围。

刚才说边缘云跟这个核心层不一样，核心层趋于同质化，边缘云不一样，但是我们也不可能让这个边缘云泛化比较厉害，所以规定了几个栈型，大型的边缘云认为部署在地市或者大型区县的，规模大于25台服务器，机房条件比较好的区县可能会到100台服务器的样子。再小一点的话，跑到这种比较偏远这个中型区县里面，为了达到一定资源利用率控制组件应该是可以部署的，如果占用很大控制面的资源的话利用率会非常低，达不到应用这个业务的效果。越往边缘管理能力越弱，就提出了一个问题，边缘云怎么管理？我们感觉应该偏向集中化管理方式，第一个是业务的集中管理，第二个是资源池的集中管理。

其次是云资源一个集中管理，我们只看下两层的话，我们认为边缘云资源池管理应该由地市一级进行管理，可以负责将租户、镜像进行一个统一管理和下发，并且还会负责自己故障运维监控。实际运维过程当中，会有一些运营商定制化需求，我们现在能够看到的是多VIM应该有一个指令。

第二的话版本兼容，因为我边缘会分布非常散，没法保证时刻保持一致，对于多VIM管理组件我们还要求兼容，其次对于这个多VIM管理组件管理下层边缘包括服务器、防火墙等等，这个还没有定义非常详细。第二个问题在区县级边缘里面，最小这个边缘云里面，因为管理没法占用过多的资源进行一个轻量化的部署，目前我们看到有一些厂家会有一些产品的原型，实现VIM轻量化。还有一种是通过容器化方式，减少最大连接数，减少一些最大并发数量等等，目前有一些产品原型，但是产品本身从可靠性，从性能来讲还需要进一步提升，所以我们在这里呼吁厂家社群也好，在这一方面有一个更细化和进一步完善。

第二个方向是关于容器，即便不到今年年初的时候，怎么引入容器，会对NFV有什么影响，我们争论很多，说到5G非常明显商用时间点之前，其实还是处于一定弱势的。正好跟容器化是一个非常吻合的设计，5G引入应该是最大的驱动力之一。其次就是考虑到刚才一些边缘云场景，资源非常受限，需要轻量化部署，提升资源利用率，对一些网元需要更快升级等等，都跟容器自己本身特性非常吻合，我觉得容器肯定是会引入的技术，但是怎么引入是大家一个看法。

这是我们初步想法，中国移动会引入容器怎么一个节奏，对于中国移动或者对于运营商来讲，目前考虑如何引入容器面临两个问题，5G商用时间的提前，其次我们已经部署的NFV怎么办，我们考虑引入容器的时候非常担心容器引入之后还没有非常完备的NFV系统会变成一个什么样的系统，能不能实现收益最大化，我们分成三个阶段图里面红色框表现前一个框的差别，阶段一跟5G商用时间契合起来，这个时间厂家可以通过时间来实现网元，因为担心容器会对运营商已经部署的NFV系统产生影响，这个容器肯定被部署在虚拟机之类的，我们叫虚机容器，对外就不可见，但是因为套了一层虚拟机会有更大的消耗，我们觉得这个时间持续不会太长。什么时间过渡到第二阶段呢？定义为容器从虚拟机脱离出来一个阶段，这个阶段容器就变得可见的了，在第二阶段的时候这个红线事我们认为那些需要改变和新增的接口，第二阶段对NFV平台产生非常大影响的阶段，同时也是我们可以收获容器很多优势这个时候，包括资源这个节省，轻量化部署，快速灰度升级等等，这个阶段我们觉得也不会来得太早，产品也好标准化也好不太成熟。

第三阶段平台做大做强之后才会到的一个阶段这个阶段目前觉得还不是特别肯定会不会，至少中国移动会不会研究这个阶段不是特别确定，这个阶段特点是作为这个容器平台，这个能力越来越强，可以把一些底层能力，比如说服务的治理，数据库的能力，包括一些负载均衡能力都通过平台来实现，通过容器来包装，可以对上提供给网元，只需要关心自己业务构建是怎么做的，所以是不是会进入到这个阶段在于首先这个运营商或者这个厂家对于这个ICT是怎么看的，是只关心这个业务，还是关心运营商原有特征，关于这个阶段我们知道都是见仁见智的。

第三个是加速，加速这一块的话我只能从运营商这个角度跟大家聊一聊目前加速一个产业的情况以及从移动的角度我们对加速哪些问题比较关心，首先我们看一下加速的需求。大家知道5G业务相对于4G要求是非常高的，还有这种计算型业务部署，这些处理基本上都要消耗CPO很大资源，如果恰巧部署在边缘，不得不用一些加速方式，所以这个是我们认为参数一定会引入的。

对于哪一些东西需要卸载到这个加速器上呢？有的厂家认为网络转发因为消耗CPO太多，而且不适合CPO去做，还有一些比如说DPI，GDP或者是边界码转换都可以卸载。从这个角度来看，目前对于哪些逻辑需要卸载到加速技术上大家还没有达成一致的意见，在这个之上对于每一种功能卸载，大家采取方式也不一样，有华为中兴主推NP的方式还有GPU这种方式，从目前看我们觉得产业需要收敛第一个前提是什么？就是哪些功能需要卸载，第二卸载的时候用什么样的方式？用一个什么样统一方式保证底层加速资源通用化的一个池子？这是目前产业情况。

移动对于NFV加速关心哪些问题呢？作为运营商来讲部署一个加速池子的话我的需求非常明确，可管、可用、可解耦，底层加速资源确保VIM可以识别他，同时确保可以辨别哪些加速资源可以解析，只有在可管前提下才能够把这个加速资源利用起来。目前刚刚启动了一个项目做加速资源管理，可能定了一些架构，具体应该从接口上来说，包括VIM区别哪些是普通网卡，哪些是加速网卡，还是可以的，至少有一个社区可以让大家探讨，这个技术成熟是可指望的。

第二和第三，我们觉得关系非常密切，业界对于哪些逻辑需要卸载到加速器上没有一个特别一致的意见，如果要把这些功能卸载到加速器上，前提要打通这个通路，不管是通过NP的方式还是其他方式，不管怎么样要有一个统一方案去实现。我们是打破传统设备，我们把硬件和软件进行解耦，底层资源变成一个池子，资源可以共享这是我的诉求，引入加速的时候反而把三层紧紧绑定在一起了，我为什么不去买一个传统网元设备。这是我们运营商遇到问题，至少在加速这个领域不管在社区也好还是厂家产品也好，跟我们一起，找到几个明确的方向，统一认知下推动这个技术的成熟。

总结一下我们刚才提到边缘、加速包括容器，我们认为目前来看研究这一块还是处于相对来讲比较初级阶段的，我们希望业界专家可以跟我们一起不管社区，都可以加速成熟商用化落地。谢谢大家。