近日，西班牙电信德国公司（Telefonica Germany）宣布，他们正在和爱立信、AWS 合作，准备在公有云上部署爱立信提供的 5G 核心网（以下称 “5GC”），预计将在 2021 年商用。

消息一出，业界震动。

虽然电信业一直在讲 NFV、核心网云化，但此前相关实践都集中在新兴运营商和专网应用上，供应商主要是IT侧厂商，底层硬件基本是私有云。

这是第一次有国际主流运营商把传统设备商的核心网部署在公有云上，创造了通信网络云化的三个 “第一”：

第一个部署云原生 5GC 的主流运营商，第一家提供 5GC 公有云部署支持的传统设备商，第一家承载规模商用 5GC 的公有云厂商。

本文将就这一事件，进行深度分析和研判。

理想中的 5GC

3GPP 规范中的 5GC，设计之初的目标，就是希望成为云原生应用。

从架构上来说，转发和控制分离的 5GC，就是一个有着云原生控制器的 SDN 网络。

5GC 的系统架构

控制面的 SBA 架构，就是IT领域常讲的微服务架构。5GC 新引入的 NRF，就是微服务架构中的注册中心。

5GC 各服务之间的信令，采用的是IT领域通用的 http2 协议，而非此前核心网常用的 diameter 等专用协议。

5GC 的各个服务，在设计上就是无状态的，因此可以随时在服务器之间无缝迁移。

控制面采用云原生部署，而转发面 UPF，因为功能非常单一，采用白盒转发设备也完全可行。

这样的架构设计，使 5GC 实现了充分解耦，支持分布式部署，从而帮助 5G 网络支持两大杀手级特性——边缘计算和网络切片。

现实中的 5G 核心网

理想很美好，但现实往往很骨感。

目前，国内已经有不少省份部署了 5GC，并且承载了业务。从现场反馈来看，主要存在以下几个问题：

一、通用硬件适配性不足。

某运营商在某省部署 A 厂的 5GC，硬件方面采用 A 厂的服务器（包括虚拟化层和操作系统），B 厂的交换机以及 C 厂的磁盘阵列。

虽然这已经是一个缩水版的硬件解耦（因为最关键的服务器和中间件都是 A 厂自己的，连两层解耦都算不上），但部署过程中还是出了一大堆问题。

其中大部分问题，都是硬件驱动的问题。虽然驱动问题是小问题，但小问题多了，就是大问题。

而之所以会有这么多小问题，归根结底还是当前通信产业链的开放程度不足。

反观IT领域，一个典型 IDC 中涉及的厂商更多，所需要的驱动也更多，但异厂商不兼容的问题却少得多。

二、未能融入云原生的生态。

从高度集成的单体架构转向云原生，随着解耦的充分，必然带来复杂度的提升。例如 Netflix 的整体IT架构，就是由数千个互相依赖的微服务组成。

知名流媒体平台 Netflix 的复杂架构

这种新增的复杂性，需要有效的管理。

目前 5GC 开局和运维的复杂程度被广为诟病，一是因为运营商维护人员本身技能和意识都还在转型中，没有从传统网络维护完全转向云原生应用维护。二是因为厂商提供的核心网本身开放性就很差，未能和云原生领域成熟的全套 DevOps 工具链相结合，其配套的网管还是按传统思路在做。

这就好比马达换成了特斯拉的马达，但整套控制系统还是传统燃油车的，自然给运营造成了较大困难。

三、转发控制分离不彻底。

在 5GC 中，UPF 和控制面之间的 N4 接口是由 3GPP 定义的。但因为各种原因，N4 接口的解耦并不充分。

目前，第一批商用的 5GC 控制面和 UPF 均是同厂商，UPF 仍然是专用设备。

考虑到未来 UPF 会下沉到大量边缘节点，UPF 白盒化和异厂商兼容，对运营商来说是一个刚需。

因此，我们可以看到三大运营商均在大力推动 N4 接口解耦，并且已经取得了一定成果。

西班牙电信的方案

目前来看，西班牙电信和爱立信的官方消息更多是商业性质的宣传，对于具体的技术方案，并没有进行披露。

但是，AWS 今年发布的白皮书《AWS 使能 5G 演进：构建可扩展、安全、可靠、高效的云原生核心与边缘网络》中，却对相关部署方案有较为详细的阐述。初步预计，西班牙电信的整体技术方案会以此为蓝本。

从总体架构来说，5GC 的控制面功能会承载于 AWS 区域的中心机房（AWS Region），而 UPF 以及 5G NR 的 CU 部分控制面，可以通过部署在边缘节点的 AWS Outpost 承载。

AWS Outpost，是 AWS 推出的可以部署在客户侧机房的一体化机柜。

这个机柜内部根据客户订单预集成了服务器和交换机，运送到客户机房后，连通电源和网络即可使用。

尽管 Outpost 部署于客户机房，但其本身是 AWS 公有云服务的一部分。客户对设备本身不享有产权，也不负责设备的维护。

Outpost 通过专线或者 public VPN 与 AWS Region 连接，在逻辑上作为 AWS Region 的延展。

对于控制面，AWS 推荐的是 EKS（亚马逊的托管版 K8S）承载。其在白皮书中，详细描述了如何通过水平扩展来应对 5GC 的高性能需求。

而对于转发面，AWS 推荐的是虚拟机承载（转发能力达 100Gbps，支持 SR-IOV、DPDK 等的网络优化实例）。

鉴于 AWS 目前采用的 Nitro 虚拟化技术，通过讲虚拟化的相关负荷卸载到专用硬件板卡上，基本实现了虚拟机性能等价于物理机。

因此，从性能上讲，也可以看作是物理机在直接承载。

考虑到西班牙电信的业务需求，不排除用白盒交换机作为 UPF，实现 Tbps 级别转发（例如 Facebook 自研的白盒交换机，由 4 块至强 CPU 加上高性能转发 ASIC 组成，基本上等同于高性能服务器插上了 Tbps 级别的转发 ASIC，完全可以满足 UPF 需求）。

值得注意的是，AWS 并未针对 5GC 的部署推出任何定制化产品，整个方案用到的组件全部是 AWS 的成熟产品。

这也就意味着，AWS 现有运维和 DevOps 工具链可以完美适用于 AWS 承载的 5GC。运维这样的 5GC，将和运维任何一个 AWS 上的IT应用一样简单。

在白皮书中，AWS 还专门讨论了如何将其总结的云上运维最佳实践框架应用于 5GC 运维。从相关内容看，在 AWS 眼中，5GC 作为一个云原生应用和其它云原生应用的共性远远大于特性。

目前，AWS 和运营商合作的 MEC 产品 Wavelength，已经在多地试商用，为 MEC 应用的开发者提供和在 AWS Region 上进行应用开发相一致的体验和工具链。

如果西班牙电信此次真的能把 5GC 放在 AWS 上，它的 5G 行业解决方案将取得巨大的规模优势。

步履蹒跚的网络云化

网络云化已经提出很多年了。

通信行业一直在说 NFV 和 SDN，5G 在相关技术架构上也基本体现了云原生的设计理念。但即使是各大厂商交付的最新 5GC 设备，对云原生的支持和其本身的开放程度仍然不足。

在笔者看来，这无外乎三个原因：

一、即得利益者对改革的抵触非常大。

进一步说，就是以四大设备商为首的力量，非常抗拒网络云化导致的生态开放趋势。毕竟要论利润率，肯定还是封闭最好。

当然，面对潮流，大家也不能全然无动于衷。

目前的形势，是在传统领域实力越弱的企业，改革的步伐越大。

例如诺基亚，目前应该是四巨头里面唯一一个把基站前传的 eCPRI 接口都开放给运营商的设备商，好像也是最早在 5G 基站芯片中推广 FPGA 的设备商。

可惜，早走一步是先驱，早走两步就成了烈士。因为 FPGA 的性能和成本问题，诺基亚产品性价比落后，最终导致股价大跌。

爱立信相对在技术路线上比较稳健，但最近也在加快向云原生演进。

这次爱立信愿意配合把产品部署在公有云上，也说明了他的态度。

至于无线领域当之无愧的大哥，一直以性能和成本为由批判云原生理念，继续推销自己不解耦或者假解耦的方案，以此来全方位服（suo）务（ding）客户。

二、整个行业对网络云化认识仍然不到位。

很多人说运营商的员工技能不行，无法胜任云原生网络的运维。

但其实更重要的是态度问题。

IT的技能并不比传统通信更复杂，只要愿意学，转型不是问题。问题在于很多人压根就不认为云原生代表未来，认为还是高度耦合的一体化方案性能好，其他都是吹牛。

欧美运营商解决这个问题的方案比较粗暴。比如 AT&T，就是全员学习，然后年纪大不学习的员工裁掉。我国运营商相对来说比较温和，主要还是以鼓励内部学习和人员自然迭代为主。

三、泛政治化带来的阴影。

目前，除了思科还在无线市场占有一定份额之外，美国已经没有无线设备商了。

为了实现 MAGA（Make America Great Again）的愿景和打压华为，美国政府出面鼓吹 open-RAN 的同时，又把全球无线设备最大的生产国和消费国——中国排斥在外。

这样既人为割裂了技术社区，也给技术选型强加了政治因素。从长远上看，对网络云化的发展负面影响是相当大的。

结语

沉舟侧畔千帆过，病树前头万木春。

核心网的云化是大势所趋，整个通信网络都在朝这个方向发展。

几日前，阿里巴巴 XG 实验室和浙江联通合作的 5G 轻量级核心网，在浙江舟山港落地。这也是一个强烈的信号，不仅国外的竞争对手会行动，国内的厂商也不会错过网络云化的机会。

相信随着 5G 建设的不断深入，产业互联网会诞生更多的网络云化需求。核心网的市场格局，将发生翻天覆地的变化！

---

本文由LinkNemo爬虫[Echo]采集自[https://www.ithome.com/0/508/404.htm]