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指南^[1]。

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

6.1. 框架（Framework）

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

软件方面，图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的控制应用程序组合实现的。

当以这种方式进行抽象时，我们可以将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”域)。

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

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

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

Reference:

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

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