各位好,然后这会是今天的最后一个时间段,然后也是非常感谢大家留到现在,然后我们是来自于中国运动的云云生研究的一个团队,然后我们今天的这个topics is cloud native is good,but how to apply it in telecom network,然后我们会主要介绍一下,就是说我们现在网络云的一个基本情况,然后同时也会缠述一下我们电信行业,就是想要引入网络云的一个主要诉求,另外一个就是对目前行业里面比较关心的像逻辑容器在网络云引入,然后网员的微服的那个设计相关的一些内容做一些就是我们的一些思考的一个呈现,然后首先来第一部分吧,就是咱们网络云的一个背景,如果是熟悉中国移动的这些伙伴们应该是对这个是比较了解的,就是我们从2015年开始就以推动网络云转型为目标去构建这个电信级增强的这个网络云,然后在这个过程中呢,我们是明确了整个中国移动网络云的一个总体设计,另外我们也制定了像包括Mano的端端端流程啊,然后虚拟层的这种功能接口啊,北向接口相关的一些体系化的技术方案,另外一个就是我们用通过超过六期的这个试点来推进了我们整个网络云的一个商用进程,那目前我们是已经构建了包括核心和边缘两级的这样一个数据中心架构,那么核心我们是分成了八个大区,里面是对我们中国移动网络云的这个物理资源做了一个融合,然后在每一个的数据中心内部我们对核心网的网员按省去做了一个逻辑的划分,它主要承载的这个网员类型是包括像45G的这种核心网的网员以及像智能网啊,采清中心Volte以及我们的这个网络云管理系统这样的一些网员类的模块,然后在边缘呢我们目前是在省地市去按需做了一个规划,主要的部署的网员是我们的UPF MEP以及这个垂直行业相关的一些业务,那么到目前为止我们整体的规模是已经超过了13万台服务器,那有超过46类的网员已经在我们这个网络云里面去进行了部署,总体的这个云化比例是超过了85%,其中5GC的这一部分是达到了100%的一个云化现状,然后这个是我们就是网络云的一个参考技术架构,那这个架构其实是一个ETSI的标准架构吧,基本上国内外的云商在落网络云的时候都会,就是虚拟化网络云的时候都会采用这样一个架构去落,所以这边我就不做详细的一个介绍了,然后下面是我们对这个网络云引入云原生做的一个分析,就是这边我们对比了一下IT和CT类业务的一个差异,可能大家也会有一些了解,就是目前我们认为对于IT类的业务的话,就是我们从业务特征商业属性可靠性要求,以及因为模式这四个部分去做了一个分析,那在业务特征这一块我们觉得IT的业务相对来说它的那个灵活性比较高,可能业务和业务之间存在那种短连接的情况会多一些,所以当出现一些故障的时候,我们可以通过一些比如说重视啊这样的一些方式去进行一个故障恢复,但是对于我们CT业务来说我们主要是网源嘛,然后这个用户,中端用户在我们的这个整个核心网的这个网源里面,它其实是一个状态机的这样一个情况在存在,那么我们的中端和我们的核心网,以及核心网网源和网源之间其实很多程度上是存在这种长连接的这种情况的,所以我们是基本上很难说一旦出现断连的这种情况,我们再进行比如说网络的连接的时候就会进行大量的一个重视,那这里面就会存在很大量的一个性命风暴的这种状态,所以我们对这个网络的这个连接稳定性要求会比较高,然后第二个是商业属性这一块,就是IT的行业一般来说它的这个研发能力都会比较强,所以很多的业务包括自己的云体系都是采用的自建自营,然后甚至也是开始于自言的这种一个状态,然后它也不需要去遵循一些规范的这种约束,那对于我们的电信行业来说,我们基本上是大部分时候是去采购的这样一种模式在组建我们的核心网,我们的平台,然后我们的网源,甚至我们的管理系统都有可能是采购来的,所以说我们是要大量的去依赖这种企业规范以及行业的规范去约束每一个产品,我们买到的产品的这个能力的,这个是商业属性上面的一个差异,然后可靠性这一块可能在那个IT行业它会更关注这个数据的一个可靠性,当然对我们电信行业来说我们在核心网里面每一个连接其实都是需要有一个可靠的,所以我们是要保证这个业务全程的一个高可靠,所以这块也是一个区别,那在运为这一块,因为本身云原生这个就是起源于IT嘛,所以像现在IT的那个运为的对象一般都是微服务,而且它基本上能够采取这种在线运为的这种模式,而对于我们的这个电信行业来说一般都是采取这种新部署,然后直接做切割的这种方式来做运为,所以说就是我们City行业如果说要引入云原生的话,其实能够引入的那些能力基本上也是典型的一些云原生的能力,但是我们在引入的时候是需要结合我们自己的一个建设方式和业务特点来去做我们的一些引入的考虑的,那这边我们是对这个驱动力做了一个分析,那么目前我们的虚拟化技术的网络云基本上已经进入了规模商用的一个阶段,那后续我们向云原生眼睛其实主要的诉求点无非就是三个,一个是这种网络资源利用率的一个提升,然后一个业务创新速度的一个提升,还有一个就是运为管理效率的一个提升,那么在基础设施资源这一块呢,我们就是现在的这个虚拟化技术已经基本上实现了这种底层硬件的通用化和资源共享,但是因为本身hypervisor层以及gasOS相关的一些资源开销,再就是本身那个虚拟化网源它的那个颗粒度会比较大,那么在调度部署的时候服务器上存在的这种虚拟化资源也会比较多,所以我们这一块是希望通过引入比如说裸机容器的这种方式去解决这个资源利用率的问题,那然后在业务云化网源业务这一块我们是目前来看的话,就是我们如果基础设施软硬件集成基本上已经就绪的情况下,本身WNF的上限和它的扩缩容速率其实是OK的,但是如果说我们要存在一些新的这种业务能力的增加,那我们的整体的响应速度是比较慢的,所以我们也是说在这边是不是能够通过比如说微服务的这种方式,包括PASS能力的一些方式去加速业务的敏捷性,然后最后一个是在管理运为这一块是目前来看的话,我们很多的运营商基本上已经采用了这个自动化测试的这样一个工具,但是它解决了我们现在测试速率慢的问题,但是它没有解决的是我们整个运营商的入网的流程其实依然还是比较漫长的,像我们的入网审核基本上是以周围单位的,可能通常来看的话三周到四周才能拿到一个入网的审批,然后像一些入网测试的话可能也是以月为单位,可能也是三个月、四个月这样的一个时间,整体的流程会比较长,而且基本上是依赖人工来进行相关的一些操作,所以这一块我们也是希望引入一些运营生的比如说自动化工具,这样的一些软件或者理念来去提升我们入网升级扩容的一个自动化。然后后面的话我们是对整个电信行业引入运营生的一些关键问题的思考,那么首先是一个技术引入的现状,就是我们前期对全球的15家典型的运营商的运营生商用做了一个调研,我们会发现基本上主流的运营商或多或少都在引入运营生的技术了,可能是容器也好,然后微服也好,那像现在的ETSA、3GPP也包括国内的CCSA这样的一些标准化组织,也基本上在启动运营生相关的一些标准化的研究,所以引入运营生本身是一个必然的一个趋势,但是目前来看的话因为技术或者产品成熟度的一些问题,那实际的这个商用案例是相对来说比较少的,而且建设的规模也是比较小的,然后整体上基本上是处于一个商用探索的阶段,那这边我们也是分了这个平台网源和运营管理三部分对大家的那个引入情况做了一个规纳,那在基础设施及能力平台这一块呢,因为不同的运营商他前期的这个硬件资产,包括虚拟层资产的投入不太一样,所以他们引入这种虚极容器或者逻辑容器,基本上是取决于自己的这个前续资产的,那么但是大部分的运营商在引入容器的时候,一般会选择在新建的资源池里面去引入,所以可能逻辑容器的这个概率会相对来说高一些,另外就是有一些像地势啊,然后那个AT&T这样一些比较就是超前的这种运营商,他会选择直接在公共运营商去部署他的核心网业务,这是平台这一块,那么在这个部分我们发现有超过三分之一的这个运营商,其实在已经基于他的这个容器平台去引入了一部分pass的能力,然后这部分pass能力主要是提供两个作用,一个是给这个业务提供一些功能的支撑,比如说像一些数据库啊,然后附载均衡啊,这样的一些能力,当然他提供了之后用不用是另外一回事,但是他会提供这样一些能力,另外一个比较明显的就是会去提供像自动化流程,然后这个配置管理可观赠信相关的一些管理运营相关的能力,是从pass来提供的,这个是平台这一块,然后网源和业务这一块主要是集中在这个微服务的一个设计,那么因为也是各个运营商本身他的这个建网的时间其实不太一样,比如说像我们是2020年就开始了5GSA的建设,但是很多国外的运营商他目前比如说去年才开始那个5GSA的建设,所以大家在做这个业务切入选择的时候也会有一些差异,那基本上的话大部分还是去选择就是建网时间比较晚,然后基于这种本身就基于SBA架构实现的这种5GSA的新业务去进行切入,然后对于我们中国运动来说我们会去选择目前灵活性比较高,而且影像面比较小的这个网管业务池去进行一个切入,这个是网源的微服设计,那么这里值得一提的就是说我们前期在跟很多的运营商包括设备商在沟通的时候,就是对微服务本身的这个范围有一个就是不太一致的理解不太一致的地方,就是本身其实5G核心网整体上是一个微服务的架构,它在之前四季的这个基础之上把一些功能做了比较好的这种规划,然后也是有一些比如说像HCP通信,然后N2F这种网源的注册中心这样一些微服务的理念存在,但是我们其实认为它本身就是微服务的,但是我们在这里提到的微服务其实是针对每个网源内部去做进一步的这种微服务的设计,就比如说像用最那边那种的这个像AMF的这种微服务里面,我们可能会考虑把像移动性管理啊,然后性灵处理或者HCP处理相关的这种LB,每一个模块都去做一个比较clean的那种分割,当然这个只是一个初步的构想,具体最后是不是会以这种形式去推进,也是需要就是我们做一些标准化相关的一些推进工作,这个是网源和业务这一块,那在运为这一块基本上就是比较清晰的三个部分,一个是引入这种设备商和运营商交付的一个中间仓库,去存储一些比如说镜像啊,然后这种安装部署包相关的一些内容,再一个就是引入自动化测试的一个工具,最后就是去构建这个移制化的这种验证,部署验证的一个环境,这个是现在全球运营商引入云元生的一个总体分析,然后这边我们对这个云元生技术本身引入做了一个优先级的一个分析吧,就从前面来看的话,就是云元生引入无非就是三个类型的要素,一个是容器,一个是微服务,一个是自动化,那么我们对每一个要素做了一些执行点的一个分析,并且对它的优先级去分了ABC三类,那对于容器技术来看的话,比较明确就是逻辑容器这边持,这个因为对我们整个底层技术设施是一个颠覆性的,而且它基本能够带来,就是对我们的绑络云带来最大程度的这种改变和收益,所以给它的优先级是A,然后在微服务这一块呢,微服框架这一部分,因为它本身现在很多设备商的产品里面,基本上已经引入了微服框架,而且它能够帮助我们去更好的管理微服务,所以这块给的优先级是B,然后通用PASS能力,这个因为本身是平台的能力,但是它的能力的产生是来源于,比如说网源做完微服设计之后,公共能力的一个沉淀,然后或者是说来源于我要支撑网源,跟网源做一些协同相关的一些能力,这块会有一些前述的依赖,所以我们给的优先级是C,然后在微服务的标准化,就是像前面提到的在AMF内部去定义更细利度的这种微服务的结构,那这块因为基本上所有的设备商,它在实现这一块的时候,一定是要对现有的这个产品去做更新的,所以这块给的优先级也是C,实现起来难度比较大,而且目前来看的话收益也不是特别的明显,然后最后在自动化这一块,自动化测试因为很多的运营商已经基本落了,所以收益比较明显,而且难度不大,所以是优先级是A,那自动化流水线这一块主要是,像打通运营商和厂商之间的这个衔接,然后我们要构建自己内部的这种FOA测试的环境,这个部分因为对我们的整体的这种流程以及组织结构,会有一些影响,所以这块给的优先级是一个B,整体上就是这样一部分,然后后面我们这一部分请同乡来给大家介绍一下,就是逻辑容器资源池相关的一些内容。像我介绍一下逻辑容器资源池刚刚说到嘛,逻辑容器的这个是优先级是A的嘛,所以我们先要研究一下,怎么去在现有的网络云的环境上去提供逻辑的管理的能力。我们有两个场景去考虑,一个是容器层是以虚拟层为基础去构建的,第二场景就是容器层是单独去构建,这两个我们考虑的点在于有两个主要的点,一个是本来网络云目前已经构建了一个八大区这么一个完整的架构,在这上如果构建一个单独的一个池子的话,一个是目前的容器的应用并不够,第二就是本身这个架构并不是一个明确的一个目标架构,然后从这我们选择了一些相关的技术啊,容器层以虚拟层为基础构建的时候需要引入就是Ironic,这个我们之前已经在OpenStack领域已经知道Ironic本身的一些功能,但它本身问题在于它的流程是比较复杂的,第二个是它构建出来的这个逻辑本身就有一些安全问题,比如它如果去调这个后端存储的话,它会把后端存储的地址直接暴露给用户,所以我们怎么解决这个问题呢就引入了这个DPO去把CloudAgent去卸载到DPO上面,同时把这个OVS也卸到上面,把它的网络的性能达到一定的提升,单独这个层次虽然我们不把作为一个目标方案,但是它的一些技术我们还做了一些研究,有些独立的比如说RackShift这种独立的一个,准备做专门做这个逻辑管理的一个技术方案,它的问题它跟K8S跟OpenStack的这个融合现在还没有,它需要重新开发,而针对这个MicroTube它是基于Ironic去优化的,但它本身跟Ironic的问题是一样,同样会面临一些安全的问题,这是逻辑管理的一些功能点,第二部分是容器安全,容器安全我们更多关心的是容器本身它的安全性能就比较差,但它到了一个工程阶段它的问题就更加明显,一个是我们去实施时发现它的节点跟控制面之间,就比如说我们的像虚层就不会有这个问题嘛,虚层的是把一个虚计交给一个用户,而容器我们可能把它一个容器交给用户,或者把一个容器节点交给用户,容器本身它有可能去越权获得这个节点的权限,就可以攻击到我们的控制面,而节点之间就可能它是不同的租户去使用,而这个通过容器去攻破了某一个节点之后,就可以去攻击其他的租户的节点,所以这个怎么解决呢,一个是通过网络控制,但是网络控制只是一方面,因为它本身的容器安全问题还需要引入这个安全容器,就中间这一部分,就是节点内的一个容器的安全的一个解决方案,目前开源的主要有三个方案,一个KATA,一个GWISER,那个是NAMLA,NAMLA和KATA两个方案其实类似,都是基于这种轻量化的虚拟层去做的,相比而言KATA的性能更好一些,然后GWISER的问题是在于它把一部分的调整系统的接口,直接透传给Kernel,一部分是它过滤了一下,但是它去直接调用这些怎么保证它的安全性呢,就是它没有考虑好,所以我们选择的是基于KATA去做研究,但是这个实验的实测数据并不是很理想,CPU的性能损耗大概10%,内存还好,内存2%,然后网络是一个比较大的问题,达到30%的一个损耗,当然这可能也要有一些优化的空间,可能跟我们本身选择的某些网络插件也是有一些关联的,基于这个现象呢,我们目前的方案是,尽量避免在几点间有不同的租户的容器,就是把一个节点放在某一个租户去使用,第三个方面就是比较像上一层的机密容器,就是容器在HouseOS上智商运行的话,那这个HouseOS的使用方控制方,那时候一定会有这种容器的权限呢,能从内存中看到容器运行的内容呢,这个有一个开源的一个解决方案,但这个方案本身的问题是它本身依赖一个硬件,还是一个强绑定的关系,这又是带来了一个方案单一,然后有硬件限制,本身它的学习门槛也是比较高的,好,后面请那个喜欢继续介绍。裸机容器之后呢,我们会回到就是这个业务的一个微服务设计这一块,那像刚刚提到的本身业务微服设计目前不是一个,就是合适的实际去切入,所以我们只能说提出一个设计的一个基本原则,和一个设计的一个分类参考,那基本原则其实和现在City行业,IT行业在做这种微服设计的时候没有本质上的差异,就是业务与平台结偶,然后单一职责无状态,高度自治,持续眼镜相关的一些内容,那我们在结合这种设计原则和相关的这个电信网员的一些现状,我们觉得就是后续的这个网员微服务其实是可以划分成,像接口业务中间阶类这三类去进行做微服设计的,那接口里面主要是承载着这个网员的南北向通信相关的一些接口类的服务,主要是做一些比如说协议解析和转发的,像HTP、GDPC、GDPU相关的一些服务,然后业务类主要是网员内部处理业务逻辑的一些核心模块,比如说像AMF的介入管理,然后AMF的安全服务,那在那个中间阶类这里面主要是提供一些比如说像数据存储的服务,然后通信队列,然后可观测信息,包括这个CICD流水线相关的一些能力,这个是一个划分,那么我们这里是也是对这个就是从中间阶类里面抽出来一个服务治理类,这主要是用于这个微服务治理的,那像刚刚提到的就是我们考虑说做一些公共能力的沉淀成为PASS的能力的话,基本上也是从这个接口类中间阶类这样的一些模块里面去提取,那后续如果说这个架构是可行的话,我们或许可以说未来在做这个新的网员的这个能力增强的时候,就直接去插入微服务或者是选择一些各种各样微服务去做一些组合,去做这样的一些设计,这个是微服的划分,然后这边有一个网员无状态设计和绘度升级相关的一些内容,那其实目前来看的话就是这个网员的设计其实本身就已经考虑了这个无状态的话,比如说我们之前把这种用户数据存到UDM里面,然后VNF内部去设计独立的这种数据库的一些存储去存储业务的剩下文,它本身就有考虑,那么我们觉得后续因为目前来看就是要让网员做无状态设计,大家最常提到的就是网员有状态,那么我们的下一部分工作其实就是可以对网员内部的一些数据去进行一个分类,然后去基于这种多种不同的这种数据状态去定制化的给一些处理的机制去实现一个惊喜化的管理,那么这边我们是可以做这样几个分类的,第一个就是像用户的一些业务、策略这样的一些稳态数据,一般可以沿用现在的去存到外部的这个数据网员里面,然后去按照网员的这种可靠性要求去对它进行一个备份,然后对于没有办法从这个网员内部去剥离的这种状态数据呢,我们首先也是考虑像左边那种在地币里面去进行一个存储,然后我们再通过对地币的一些比如说多副本啊,然后去进行一个可靠性的维护,然后对于网员内部还有一些就是不太重要的状态数据的话,我们就可以默认它是无状态的,那么这里面具体包括就是首先是数据和状态不太重要的这种情况,第二个就是我们可以抛弃之后重新生产的这样一种数据,再就是本身是需要做荣誉,本身存在荣誉,而且各种荣誉数据之间切换时间并比较短的这种情况,这几种情况我们是可以做这种状态数据认为它是无状态的,那么对于就是没有办法消除状态的这种一些网员的话,我们是要做一些可靠性的这种机制的,就比如说沿用现在的一些主备、环状相关的一些模块之间的户备的这种机制,另外一个就是我们要做这种数据的实施进向相关的一些考虑,这个是网员无状态设计,然后这边是一个自动化相关的,就是我们对CICT-CD的一个流程优化的一个思路,那么目前来看的话就是厂商测的这个研发测试,然后我们运营商这边的这个技术验证以及最后的这个交付运萎,这三个阶段基本上现在阶段是独立的,那么后续的话我们也是希望去能够建立这种产品研发测试认证到一个交付运萎的这种端端端衔接起来的一个循环,那它主要会从这样几个方式去切入,第一个是我们希望去在中国运动线网内去构建一个跟线网高度已知的一个测试环境,然后把我们前期的那种像功能试点、集成测试这样的一些测试去进行一个合并,然后基于最终化的工具去提升一个效率,这个是测试效率的一个优化,然后第二个就是研发流程的优化,就是我们希望能够说在运营商这边和厂商那边去建立这种测试工具的一个共享,那这里面一个是工具共享,一个是测试用力的一个共享,那么这样的话就是我们能希望借此去打通运营商和厂商之间研发测试的这样一个环节,最后实现就是当有更新的时候,我们可以实施地去完成这样相关的一些验证,然后去推到我们的线网里面去,最后一个就是一个FoA的测试,就是我们去建立相关的这个FoA测试的环境,然后主要以这种工程验收和稳定性测试为主去提升整体的一个交付效率,然后后面这一块我们是管理部分就是这个性能数据的一个管理,那么目前就是比较旧的这种方式,就是传统的这种方式是基于这个OMC的方式去进行实现的,也就是说我们的这个传统网源像PNF, VNF,它的这个业务性能的这个数据其实是通过我们的这个网管的OMC接口去进行上报的,然后这个接口是私有的,在一个就是OMC网上的话到OSS,基本上是基于这个中国运动起标的这种呃,北向接口去上报一些上报这个业务的性能数据,然后目前这样的一些数据主要是通过本地采集,然后生成这种文件的形式在存储和传输,那它的传输周期目前我们常见到的是五分钟,呃,那我们觉得引入了这个呃,语言声之后其实直接可以考虑使用普罗米修斯的这种管理方式,那基本上呃,这个点也是大家比较明确的就是呃,matrix管理就使用到普罗米修斯呃,那我们觉得就是引入普罗米修斯之后可以去保留这种双路径的性能数据管理的这种方式,也就是说我们一方面去保留这个OMC的这种方式去上报网源的这个性能数据,另外一方面就是可以考虑使用这个PushGateway的这种方式去把业务的性能数据实施地推到普罗米修斯这边,然后通过普罗米修斯对业务的数据,然后平台的数据进行一个汇总之后再去做商报呈现,那这种方式相对来说比原来的会更清亮化,而且它是支持就是本地实施地去展示这个网络的性能的,所以灵活性会更高,而且基于这种方式的话也是比较变于我们后续基于呃,K8普罗米修斯去引入这个HPA这种自动扩缩容的机制,那会比现在的这种NFA的这种反复交互的这种自动扩缩容机制要会容易一些,这个是性能数据管理这一块,然后有一个那个CNF的这个生命周期管理,那目前呃就是右左手边这个是目前的呃,ETSI定义的这种标准化的,基于WFM解析,然后基于WFD描述这个网源内部的结构的一种实现方式,那目前我们看到在开源里面其实基本上呃,大家都在用Helm或者是operator的方式去进行部署,所以这个也是我们后续觉得一个比较呃,就是建议的这种方式,那像现在Onap基本上是按左边那种方式去进行实现的呃,对于那个呃中国运动现在的这个规划里面的话,我们也是希望基于这个Helm的方式去进行实现,这个是生命周期管理这一块,然后最后我们通过前面的这些分析,其实对后续的这个运原生的技术架构给出了一个设想,那目前来看的话K8普罗米修斯Helm Chat,然后Helm,然后CCRM这样一些运原生领域的这个开源软件,基本上都是成为了事实标准嘛,那么我们后续其实可以基于这些开源软件,去对整个NF体系的各个模块的功能,去进行一个简化和呃融合,那基本上就是呈现到右手呃,左手边的这种这个目标架构,那这里面有几个新引入的这个模块,一个是CAM的这个模块,它是容器技术设施管理器,基本上就是K8,然后还有一个是CCRM这个模块,它是容器集群的一个管理器,主要是做容器集群的下发,就是基于现在的比如说逻辑环境或者是虚机环境,去构建一个K8的集群,然后还有一个就是PIM,这个是物理技术设施管理器,这个是呃在虚拟化的阶段就本身存在的一个模块,主要是收集一些物理资源相关的,相关的一些呃性能或者高顶的一些数据,然后还有一个就是呃CIE,CIE这个就是容器技术设施引擎,也就是Docker Container D这样的一些呃软件,那呃引入这个架构之后,主要会存在这样的几个变化,第一个是在Manual和网管这一块,首先我们觉得NF的这个管理的架构是可以进行简化的,像本身K8 HALM是具备一些编排管理的工作的,它是呃介于这个基础资源和这个业务之间的一层,所以我们觉得SIMK8后续是可以承担一定的这种呃VNFM,OMC原来对这个CNF的一些生命周期管理啊,业务配置啊,扩锁融管理相关的一些工作,然后第二个就是呃我们如果说后续想要去引入PASS的一些网关的话,其实可以直接基于现有的这个容器去进行,容器平台去进行扩展,比如说引入像呃Qubi Apps这样的一些类似于呃运用仓库相关的一些呃组件,直接基于这个容器平台去引入,然后去进行一个PASS能力的扩展和管理。第二个就是说呃目前我们的NFAOSS这样的一些抹块已经具备了这个容器管理的能力,那后续在像我们引入DPO,然后引入PASS服务之后它是需要对相关能力的编排去进行一个扩展的,所以这边是需要一个扩展。再一个就是我们希望引入的这个CICD的这个工具链,是需要和我们的这个NFAO去进行一些衔接,然后去定一些比如说像呃自动部署啊相关的一些流程和接口,来实现就是整个全流程的一个自动化。然后第二个比较大的变化可能存在的就是这个SDN的一个系统,就是呃为了进一步的去减化这个技术架构吧,我们觉得后续SDN的这个功能也是可以由这个CCM去集成的。那原因主要有两个,第一个就是目前在容器的这个场景下,基本上网源的这个逻辑网络都是由这个K8的CNi去进行实现的,所以没有必要去再引入这个SDNC去对网源的这个业务呃逻辑去进行一个呃区分呃进行一个配置,然后第二个就是在多级群管理的这种模式下呢,目前只有这种物理节点是需要SDNC来进行一个呃网络配置的,所以呃也也不存在说比较复杂的这种overlay的网络,所以后续也是可以由CCM去承担相关的一些网络设备配置的一些功能,这个是第二个变化。那第三个变化就是呃如果我们后续去引入DPU呃智能网卡来实现比如说弹性罗金属啊,然后网络现在相关的一些能力的话,那么我们以势必会存在着就是比如说罗金属的一些生命周期管理,然后节点网络的一些呃编排呃编排相关的一些接口和功能需要去定义,那这一部分我们也是建议去放到这个CCM里面去进行一个统一实现的,这个是整体的一个架构,那基本上就是云温升这一块的内容就是这些,然后后面我们还有一点点小的这种就是呃推广,就是我们目前呃酸连网络也是就是运营商常提的一个概念哈,呃我不知道在互联网行业有没有横火,但是为了推广这个酸连网络的一个建设和成熟发展呢,我们是中国运动是联合了19家合作伙伴在Open Infra基金会去成了的一个叫酸连网络工作组的这样一个呃呃工作组,那我们现在主要研究的内容呢主要是涉及到比如说像DPU然后这个应用的这种跨价构千亿跨AI价构千亿然后多集群节点的这种呃犯在调度相关的一些内容,它整体选择的场景是我们希望能够呃实现一个AI训练或者是推理类的应用能够在跨厂商的跨域的这样一个环境里面去实现在GPU啊,然后FPGA或者是像华为的那个呃圣腾芯片呃韩伍基的MLU芯片这样的一些卡上去做灵活的这个部署和迁移,那呃基本上是希望是能够实现用户的无感迁移这个是目前我们主要研究的一个场景,那目前呢我们是希望在2023年的11月份去输出我们的手皮成果,如果各位有对这个项目有兴趣的话也是可以考虑联系我们去呃了解一些相关的详情,那整体上就是这些,谢谢。对云元生这块儿有没有什么问题,行,那要是没有的话,啊,您说UPF是吧,这种。呃就目前来看的话其实数据面的东西我们嗯坦白讲哈就为了性能的话我们可能现在会有一定的倾向在做应该是还是保留的物理机的这种状态在实现,但是像虚拟化的UPF然后后融器化的UPF我们也是在同步去做,我如果回答得不对的话会想帮我纠正一下。目前UPF还是这个裸机形态,基本上还是一个属于专用硬件保证性能,但是我们在这个我们自己内部研究啊一些联合的一些课题里面也会做一些融器化的这些试炼。谢谢,你刚刚展示了一下那个AMF那个融器化的那个架构就是有一张图,这个为什么会这么考虑,因为按道理3GP为规范来说AMF可以用AMF SET去解决,就整个5GC的这个微乎架构里就可以通过AMF SET去解决,那为什么会单独又把AMF拿出来做微乎化。还有人想要问问题吗,这边可以接触。