早就想写一个系列，给互联网行业的朋友介绍一下移动通信网络，特别是 5G 移动通信系统，但一直没想好怎么写。最近看到 ONF 发布的开源书《5G Mobile Networks：A Systems Approach》，其目标读者正是互联网从业者，因此打算将全书翻译为中文，希望能让有兴趣的朋友们能够了解移动通信网络的一些基本概念、网络架构和演进方向。原文：5G Mobile Networks: A Systems Approach^[1]。中文版 Github 仓库：https://github.com/yuff100/5GSystemApproachCHN。

6. 参考实现（Exemplar Implementation）

我们在前几章中介绍了移动网络的虚拟化、解耦、优化、分布式和切片，不仅有助于我们理解 5G 的内部工作，而且对于在实践中简化 5G 移动网络的实现工作也是很有必要的。我们的目标是做出具体的工程选择，从而完成一个参考实现。这只是一个范例，不是唯一的可能性。

我们描述的系统被称为 CORD，如果你还记得，我们在引言中介绍过这是 Central Office Re-architected as a Datacenter 的首字母缩写。具体来说，CORD 是一份基于商用硬件和开源软件组件构建 5G 系统的蓝图。我们称这种硬件/软件组合为 CORD POD，其想法是在蜂窝网络的每个边缘站点部署一个 POD。下面从一组工程决策的角度来描述 CORD。它不能代替安装、开发和操作 CORD 的详细文档。还要记住，尽管 CORD 在其名称中包含“Central Office”，但 CORD POD 是一种通用设计，并不严格局限于部署在传统的 Central Office 中。

延伸阅读：要了解如何安装、操作 CORD 开源软件平台，并对其做出贡献，请参阅 CORD 指南^[2]。

在讨论细节之前，重要的是要了解，CORD 是一个正在进行中的工作，有一个相当大的开源社区为它的代码库做出贡献。其中许多组件相当成熟，目前正在进行运营商测试并在生产网络中运行。其他的（主要对应于上一章中描述的高级功能）是在“演示模式”中运行的原型，还不够完整，不足以包含在正式发布版本中。此外，正如前面关于部署选项的讨论中所概述的，CORD 从一个产品质量的 EPC 开始实现，并正在逐步向 5G 演进（本章使用特定于 EPC 的组件进行说明）。

6.1. 框架（Framework）

图 34 给出了 CORD POD 的示意图。它的下游连接到一组 DU（以及相关的 RU），并将上游连接到互联网的其余部分。在内部，它包括一组商用服务器（图中显示了四个机架，每个机架有三个服务器，但设计上可以支持从部分机架到 16 个机架的任何部署）和一组白盒交换机，这些交换机以叶脊网络拓扑结构排列（图中显示了两个叶脊交换机，但设计上既能够支持单一的交换机或者每机架两个叶交换机，也能够支持多个脊交换机，只要能够提供足够的东西向带宽）。

图 34. CORD 实现的 RAN 和移动核心网。

软件方面，图 34 显示了 RAN（红色）和移动核心网（蓝色），以及定义 CORD 平台的模块（橙色）。我们将在本章后面介绍平台组件，但您可以将它们看作是一个多租户云的整体实现，许多不同的可伸缩服务可以在其上运行。RAN 和移动核心网就是这样的两个租户。CORD 平台还可以承载其他边缘服务（这是 CORD 从一开始就使用云技术构建的原因之一），但有哪些边缘服务可以在 CORD POD 上运行不在本书讨论范围之内。

与 RAN 和核心网相关的组件在前面的章节中已经介绍过了，分别包括 CU 和移动核心网的控制平面和用户平面。为了简化起见，我们将 SGW 和 PGW 合并为单个 S/PGW。另一个值得关注的细节是 CU 控制面中包含的 RAN 控制组件，包括了 4.3 节介绍的近实时 RIC，这意味着一个 CORD POD 包含两个 SDN 控制器：控制 RAN 的 RIC，控制网络的 ONOS（在 CORD 中运行的 RIC 实际上是 ONOS 的第二个定制版本，不过这是实现细节了）。

接下来我们来看以下 RAN 和移动核心网组件是如何实现的。具体来说，图中所示的功能组件有三种不同的表现形式：（1）CU-U 和 S/PGW-U 的数据面以 P4 程序加载到可编程交换机中实现；（2）CU-U 和 S/PGW-U 的控制面（以及 Trellis 平台模块）作为加载到 ONOS 上的控制应用实现；（3）其余组件实现为 Kubernetes 管理的微服务（Kubernetes 是隐含的，没有在图中显示出来）。

为了扩展这一思想，图 35 给出了 CORD POD 的另一种视图，舍弃了承载哪些服务的细节，而关注于这些服务是如何在 POD 上实例化的。在该图中，所有实例化到 POD 上的功能都是作为基于 Kubernetes 的微服务和基于 ONOS 的控制应用程序组合实现的。

图 35. CORD 的另一种视图，通过 CI/CD 工具链管理平台和服务，这些服务是由基于 ONOS 的控制应用程序和基于 Kubernetes 的微服务组合实现。

当以这种方式进行抽象时，我们可以将 POD 视为三个子系统：

• 平台（Platform）：通用的基础层，包括作为容器管理系统的 Kubernetes，作为 SDN 控制器的 ONOS，每台交换机上都会加载的 Strata（开源交换机操作系统）。ONOS 和它托管的控制应用程序都是 Kubernetes 管理的微服务。

• 配置（Profile）：特定部署的微服务和 SDN 控制应用程序的集合，这些应用程序被调度在特定的 POD 上运行。这是一个可变的集合，还可以包括在其他地方描述的控制面和边缘服务。

• CI/CD 工具链：用于封装、部署、操作和升级特定的平台/配置，它通过一系列处理流程，将一组分离的、虚拟化的组件转换为能够响应运维工程师的指令并承载实时流量的操作系统。

CI/CD 工具链使用标准的 DevOps 工具将软件部署到服务器和交换机集群上，并在需要的时候可以隔离/回滚单个微服务和控制应用程序。它还可以基于 POD 配置自动生成管理 POD 的 NBI（Northbound Interface，北向接口），运维工程师可以在生产环境中通过 NBI 接口操作 CORD POD。

6.2. 平台组件（Platform Components）

现在我们回头看一下图 34 和 35 中所示的三个平台相关组件。就其本身而言，每个组件都是一个开源项目，但就我们的目的而言，了解它们在支持 CORD 的 5G 配置中所扮演的角色就足够了。

• Stratum：轻量级白盒交换机操作系统，提供硬件无关接口，用于对 CORD 中的交换机进行管理和编程，支持通过 P4 定义交换机转发管道的行为（可以视为控制面和数据面之间的契约)，以及使用 P4Runtime 在运行时控制转发。

• ONOS：网络操作系统，用于配置和控制由可编程白盒交换机组成的网络。逻辑上它作为集中的 SDN 控制器运行，并托管一组 SDN 控制应用程序，每个应用程序控制底层网络的某些功能。由于 ONOS 在逻辑上是集中式的，因此被设计为高可用性和可伸缩的。

• Trellis：ONOS 托管的 SDN 控制应用程序，用于在白盒交换机网络上实现叶脊网络。它支持多个应用的控制，包括 VLAN 和 L2 桥接、IPv4 和 IPv6 单播和组播路由、DHCP L3 中继、双链接（dual-homing）服务器、上行路由器、QinQ 转发/终止、MPLS pseudowires 等。此外，Trellis 可以使整个网络体现为一个单一的（虚拟的）路由器连接到上游路由器上，上游路由器使用标准的 BGP 与 Trellis 进行通信。

Stratum（运行在交换机上）和 ONOS（运行在交换机外部，管理整个交换机网络）通过以下接口进行通信：

• P4：定义可编程交换芯片的转发行为，以及对功能固定的 ASIC 管道建模。P4 程序定义了一个由控制面通过编程定义，并由数据面实现的契约。

• P4Runtime：为 SDN 准备的接口，用于控制运行时的转发行为，是用于配置转发表和控制转发状态的关键模块，其工作方式与硬件无关。

• OpenConfig 模型：定义了设备配置和管理的最小集。这些模型通过可编程的方式扩展特定于平台的功能，其目标是最小化模型之间的差异，从而支持与供应商无关的管理平面。

• gNMI（gRPC 网络管理接口，gRPC Network Management Interface）：为 SDN 准备的接口，通过使用二进制接口和双向流来改进现有配置接口，与 OpenConfig 模型配合使用。

• gNOI（gRPC 网络运维接口，gRPC Network Operations Interfaces）：一组用于支持特定交换机操作的微服务，如证书管理、设备测试、软件升级和网络故障排除等。gNOI 提供了语义丰富的 API，取代现有的基于 CLI 的方式。

Trellis 作为运行在 ONOS 上的 SDN 控制应用程序，可以控制从内部交换网络到 CORD POD 的包转发（在单个站点内）。但是 Trellis 也可以通过多个层级的脊柱网络扩展到多个站点，如图 36 所示。这意味着 Trellis 具有在 RAN 的中传和后传网络中发挥作用的潜力，也可以帮助将 RAN 扩展到客户现场（图中“On Site”域)。

图 36. Trellis 控制应用程序管理(可能是分布式的)叶棘网络。

我们刚才介绍的软件栈非常庞大，有可能会破坏蜂窝网络现有的构建和运行方式。特别需要注意的是，图 34 所示的 RAN 智能控制器是作为 ONOS 的一组扩展实现的，这种架构将基于 ONOS 的 RIC 置于设计的中心，位于 SDN 和 5G 世界的交界处。

本次讨论虽然只聚焦于部署 5G 网络的一种选择，但这也说明了为什么 5G 被视为电信行业转型的原因之一。5G 架构充分利用了几个重要的、广泛的行业趋势，远超以往任何电信网络。融合了 SDN 的崛起、开源软件的力量及其在网络中日益广泛的使用，当然还有以云技术作为提供创新服务的基础。

延伸阅读：关于 SDN 软件栈的更多信息，推荐阅读：《软件定义的网络：一种系统方法（Software-Defined Networks: A Systems Approach）》^[3]。

Reference:

[1] https://5g.systemsapproach.org/index.html

[2] https://guide.opencord.org/

[3] https://sdn.systemsapproach.org/

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术总监，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。

微信公众号：DeepNoMind