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

4. RAN 详解（RAN Internals）

在上一章（第三章基础架构），我们对 RAN 的介绍主要集中在功能上，基本没有涉及 RAN 的内部架构。现在我们将关注更多的内部细节，介绍 5G 是如何改造 RAN 的。我们首先介绍数据报文处理流水线的几个步骤，然后展示这些步骤是如何被分解、分布和实现的。

在本章中，我们会在前三节中自底向上逐步构建 RAN，然后第四节总结整个设计，重点关注如何构建端到端的系统。

4.1. 报文处理流水线（Packet Processing Pipeline）

图 19 展示了 3GPP 标准定义的基站的数据包处理步骤。注意，该图将基站描述为一个流水线（发送给 UE 的包沿着从左到右的步骤进行处理)，不过也可以将其视为协议栈（在 3GPP 官方文档中也是这样做的）。还需要注意的是（截止到目前）我们还不知道这些步骤是如何实现的，但由于我们最终将走向基于云的实现，我们可以将每个步骤都视为对应的微服务（也许这样可以有助于理解）。

图 19. RAN 处理流水线，包括用户面和控制面组件。

关键步骤如下：

• RRC（Radio Resource Control，无线资源控制）→ 负责配置管道以及相应的策略。RRC 运行在 RAN 的控制面，不处理用户面的报文。

• PDCP（Packet Data Convergence Protocol，分组数据汇聚协议）→ 负责压缩和解压 IP 报头，提供加密和完整性保护，并做出“早期”转发决定（例如，是将包沿管道发送到 UE 还是转发到另一个基站）。

• RLC（Radio Link Control，无线链路层控制协议）→ 负责分片和重组，基于 ARP（automatic repeat request，自动重传请求）实现分片的可靠发射/接收。

• MAC（Media Access Control，媒体访问控制协议）→ 负责缓冲、多路复用和解复用分片，包括做出什么时间传输什么分片的所有实时调度决策，以及“延迟”转发决策（例如，切换到替代载波频率，包括 Wi-Fi）。

• PHY（Physical Layer，物理层）→ 负责编码和调制（在前面章节有所讨论），包括 FEC。

图 19 中的最后两个步骤（D/A 转换和射频前端）超出了本书范围。

虽然可以将图 19 中的各个步骤简单的视为一个纯粹的从左到右的管道，但实际上是由 MAC 阶段的调度器完成了对于出站流量处理“主循环”的工作，它负责从上游的 RLC 读取数据并将传输工作调度给下游的 PHY。调度器需要决定在每个时间段（基于前一章中列出的所有因素）向给定 UE 传输的字节数，因此它必须从上游队列请求（获取）符合该长度的一段分片。在实践中，在单个调度间隔内向单个 UE 传输的分片大小可以从几个字节到整个 IP 包大小。

4.2. 分布式 RAN（Split RAN）

下一步需要理解上面概述的功能是如何在物理模块之间进行划分的，从而在集中式和分布式的部署位置之间进行“分割”。历史上，主要的实现选择是“不分离”，图 19 中所示的整个管道在单个基站中运行。如今 3GPP 标准已经被扩展，允许选择在多个不同的位置进行功能分割，由运营商领导的 O-RAN（Open RAN）联盟正在积极探索如图 20 所示的分割，我们在本书的其余部分将采用这种分割模式。

图 20. 分布式 RAN 处理流水线分割为中央单元(CU)，分布式单元(DU)和无线电单元(RU)。

这导致了与图 21 所示类似的 RAN 配置，其中有一个部署在云上的 CU（Central Unit，中央单元），服务于多个 DU（Distributed Unit，分布式单元），每个 DU 又服务于多个 RU（Radio Unit，无线单元）。关键是，RRC（集中在 CU 中）只负责近实时的配置和控制决策，而调度器是 MAC 的一部分，负责所有实时调度决策。

图 21. 分布式 RAN 的层次结构，一个 CU 服务多个 DU，每个 DU 服务多个 RU。

因为无线传输的调度决策是由 MAC 层实时做出的，DU 需要尽量“靠近”（时延在 1ms 内）它所管理的 RU（不能基于过时的通道信息做出调度决策)。一种熟悉的配置是将 DU 和 RU 一起部署在铁塔上。但如果 RU 对应的是小基站（small cell），在一个中等大小的地理区域（例如商场、校园或工厂）内可能会部署很多 RU，那么一个 DU 就需要服务于多个 RU。mmWave 在 5G 中的使用可能会让后面这种续配置变得更加普遍。

还要注意的是，分布式 RAN 改变了回传网络的性质，在 4G 中，回传网络将基站（eNB）连接回移动核心网。而分布式 RAN 将会出现多个不同的连接，它们的正式名称是：

• RU-DU 之间的连接被称为前传（Fronthaul）

• DU-CU 之间的连接被称为中传（Midhaul）

• CU-移动核心网之间的连接被称为回传（Backhaul）

关于 CU 还需要注意（与下一章相关），人们可能会将 CU 和移动核心网部署在同一个集群中，这意味着回传是通过集群交换网络实现的。在这样的配置中，中传起到了之前回传的效果，而前传则受到 MAC 实时调度器的可预测/低延迟需求的限制。

关于图 20 中表示的 CU 还有一个需要注意的地方，它包含两个功能块：RRC 和 PDCP，它们分别位于 RAN 的控制面和用户面。这种分离与第 3 章中介绍的 CUPS 的思想是一致的，并且随着我们深入了解 RAN 是如何实现的，它将发挥越来越重要的作用。现在，我们注意到这两个部分通常分别被称为 CU-C 和 CU-U。

延伸阅读：要了解更多关于分布式 RAN 的组件设计考虑，请参见 NGMN 联盟 2015 年 3 月的报告：《RAN 演进项目：后传和前传的演进（RAN Evolution Project: Backhaul and Fronthaul Evolution）》^[2]。

4.3. 软件定义 RAN（Software-Defined RAN）

我们现在介绍如何根据 SDN 的原则实现 RAN，从而诞生 SD-RAN 的概念。关键的架构洞察如图 22 所示，图 19 中的 RRC 被划分为两个子组件：左边实现了符合 3GPP 规范的和移动核心网控制面通信的接口，而右边则有机会定义一个新的可编程 API，实现对 RAN 用户面管道进行基于软件的控制。

更具体地说，左边的子组件只是在移动核心网和 PDCP 之间转发控制面数据包，通过这条路径，移动核心网可以与 UE 进行通信并执行控制。而右边的子组件则实现了 RRC 的核心控制功能。在 O-RAN 架构文档中，这个组件通常被称为 RIC（RAN Intelligent Controller，RAN 智能控制器），我们在这里也采用这个术语。“近实时（Near-Real Time）”这个限定词表示 RIC 是 CU 中实现 10-100ms 控制循环的一部分，从而有别于 DU 中运行的 MAC 调度器所完成的 1ms 控制循环。

图 22. RRC 解耦为面向核心网的控制面组件和近实时控制器。

尽管没有在图 22 中明确显示，但是 RRC 的所有组成部分，加上 PDCP，就构成了 CU。

图 23 显示了近实时 RIC 的内部细节，实现为加载了一组 SDN 控制应用程序的 SDN 控制器。RIC 维护着 R-NIB（RAN Network Information Base，RAN 网络信息库），这是一组可以被许多控制应用程序使用的通用信息。R-NIB 包括时间平均 CQI 值和每个会话的状态（例如，GTP 隧道 ID，流量 QCI 值），而 MAC（作为 DU 的一部分）维护实时调度器所需的瞬时 CQI 值。具体来说，R-NIB 包括以下状态：

• 节点（NODES）：指基站和移动设备基站属性（Base Station Attributes）：标识符（Identifiers）版本（Version）配置报告（Config Report）RRM 配置（RRM config）PHY 资源使用情况（PHY resource usage）移动设备属性（Mobile Device Attributes）：标识符（Identifiers）能力（Capability）测量配置（Measurement Config）状态（活跃/非活跃）

• 链路（LINKS）：两个节点之间的实际链路，以及 UE 与所有相邻蜂窝（cells）之间的潜在（Potential）链路链路属性（Link Attributes）：标识符（Identifiers）链路类型（Link Type）配置/承载参数（Config/Bearer Parameters）QCI 值

• 切片（SLICES）：虚拟化 RAN 架构切片属性（Slice Attributes）：链路（Links）承载/流（Bearers/Flows）有效期（Validity Period）预期 KPI（Desired KPIs）MAC RRM 配置（MAC RRM Configuration)RRM 控制配置（RRM Control Configuration）

图 23. 近实时 RAN 控制器上运行的控制应用程序示例。

图 23 中所示的控制应用程序示例包含了一系列的可能性，但这并不是一个详尽的列表。其中最被寄予厚望的是最右边的 RAN Slicing，它引入了一个新功能：虚拟化 RAN（Virtualizing the RAN）。这个想法已经被实现了，下一章我们将详细介绍。

接下来的三个应用（RF Configuration、Semi-Persistent Scheduling、Cipher Key Assignment）是面向配置的应用程序的示例。它们提供了一种程序化的方式来管理很少变化的配置状态，从而实现零接触运维。制定有意义的策略（也许是基于分析驱动）很可能是未来创新的途径。

最左边的四个控制应用示例是 SDN 思想的最佳实践，它强调对分布式转发的集中控制。这些功能（Link Aggregation Control、Interference Management、Load Balancing、Handover Control）目前由单个基站实现，只有局部可见性，但它们具有全局影响力。SDN 方式是集中收集可用的输入数据，做出全局最优决策，然后将各自的控制参数发送给基站执行。这部分工作正在进行中，但是采用这种方法思想的产品已经出现了。在广域网领域，多年来有很多使用类似方法优化网络的尝试，获得了引人注目的效果。

虽然上面将可能的控制应用程序分类为面向配置的以及面向控制的，但另一个可能的分类方式是基于当前在两个不同层次上控制移动链路的做法。在细粒度级别上，每个节点和每个链路的控制是使用分布在各个独立基站上的 RRM（Radio Resource Management，无线资源管理）功能进行的。RRM 功能包括调度、切换控制、链路和载波聚合控制、承载控制和访问控制。在粗粒度层面，利用 SON（Self-Organizing Network，自组织网络）功能对本区域移动网络进行优化和配置。这些功能监控相邻节点列表、管理负载均衡、优化覆盖和容量、旨在减少网络范围内的干扰、集中配置参数等等。由于存在这两种级别的控制，在 SD-RAN 的 O-RAN 文档中我们可以看到既有 RRM 应用程序（RRM Applications）又有 SON 应用程序（SON Applications）。

延伸阅读：想要了解 SDN 原则如何成功应用于生产网络，我们推荐阅读 2013 年 8 月发布于 ACM SIGCOMM 的论文：《B4：全球部署软件定义广域网的经验（B4: Experience with a Globally-Deployed Software Defined WAN）》^[3]。

4.4. 架构演进（Architect to Evolve）

和前面三节一样，我们将在最后通过再次分析 RAN 的解耦所涉及的步骤来结束对 RAN 内部的讨论。解耦涉及到多个不同的层次，在这个过程中，我们需要解决几个问题，包括定义新的开放接口，这些接口定义了围绕 5G RAN 架构演进的核心要素。

在解耦的第一层中，3GPP 标准定义了如何对 RAN 进行水平分割的若干种选项。水平分割将图 19 所示的 RAN 处理流水线分解为独立运行的组件。图 24(a)展示了将单个 RAN 水平分解为三个不同的组件：CU、DU 和 RU。O-RAN 联盟从 3GPP 中选择了特定的解耦选项，并正在开发这些组件之间的开放接口。3GPP 定义了 RAN 与移动核心网之间的 N2 和 N3 接口。

第二层是垂直分割，关注 CU 的控制/用户面分离（CUPS），形成 CU-C 和 CU-U，如图 24(b)所示。其中控制面为 3GPP 控制平面，CU-U 负责维护服务于用户流量的管道，CU-C 专注于处理移动核心网和 RAN 组件（以及 UE）之间的控制消息信令。图 24(b)还展示了 O-RAN 定义的组件之间的接口。

第三层遵循 SDN 范式，并进一步推进了垂直分割。通过将 RAN 的大多数控制功能（RRM 功能）从 RAN 组件中分离出来，并在逻辑上将它们集中部署为运行在 SDN 控制器上的应用程序，对应于图 22 和 23 中显示的近实时 RIC。图 24(c)再次展示了这种基于 SDN 的垂直分解，并且展示了对应的 O-RAN 接口。

图 24. RAN 三层解耦：(a)水平，(b)垂直 CUPS， (c)垂直 SDN。

接口名称看上去很神秘，不过知道它们的细节对我们理解 RAN 的概念来说并没有什么帮助，只会让我们越发理解将 SDN 这样的技术变革引入到这样一个需要努力实现完全的向后兼容和具备通用互操作性的环境中的挑战。话虽如此，我们还是举两个值得关注的例子。

一个是 A1 接口，移动运营商的管理平面（在电信领域中通常称为 OSS/BSS(Operations Support System，运营支持系统/Business Support System，业务支持系统)）用它来配置 RAN。到目前为止，我们还没有讨论过电信 OSS/BSS，但可以肯定的是，这样的组件应该位于任何电信软件协议栈的顶部，是操作网络所需的所有配置设置和业务逻辑的源头。注意，如图 24(c)所示的管理平面包括一个非实时 RIC（Non-Real-Time RIC）功能模块，协助位于 A1 接口下面的近实时 RIC。我们过会儿再介绍这两个 RIC 的关系。

第二个是 E2 接口，近实时 RIC 通过它来控制底层的 RAN 组件。E2 接口的一个需求是要能够将近实时 RIC 对接到不同类型的 RAN 组件。类型基于服务模型（Service Model）进行抽象，反映在 API 中。其思想是，每个 RAN 组件发布一个服务模型，该模型有效定义了组件能够支持的 RAN 功能集。然后 RIC 对这个服务模型发出以下四种操作的组合：

• 报告（Report）：RIC 要求组件报告一个特定功能的值设置。

• 插入（Insert）：RIC 指示组件激活用户面功能。

• 控制（Control）：RIC 指示组件激活控制面功能。

• 策略（Policy）：RIC 在激活的功能上设置策略参数。

当然，通过其发布的服务模型，RAN 组件定义了可激活的相关功能集、可报告的变量和可设置的策略。

总之，A1 和 E2 接口完成了 RAN 的三个主要控制回路中的两个：以非实时 RIC 为控制点的外部（非实时）回路，以近实时 RIC 为控制点的中间（近实时）回路。第三个（内部）控制回路（没有在图 24 中显示）在 DU 内部运行：包括嵌入在 RAN 处理流水线 MAC 层中的实时调度程序。两个外部控制回路的时间边界分别为>>1sec 和>10ms，正如我们在第二章中看到的，实时控制回路时间边界为<1ms。

这就产生了一个问题：具体的功能是如何在非实时 RIC、近实时 RIC 和 DU 之间分布的？我们先看一下后边两个（即两个内部回路）。我们需要认识到并非所有 RRM 功能都可以集中处理，在完成了水平/垂直 CUPS 解耦后，RRM 功能被划分为 CU-C 和 DU。因此，基于 SDN 的垂直分割主要是将 CU-C 测的 RRM 功能集成到近实时 RIC 中。除了 RRM 之外，SON 也将被集成到近实时 RIC。

然后我们再看外部控制回路，近实时 RIC 开启了引入基于策略的 RAN 控制的可能性，通过这种方式，如果发生了运维工程师定义的策略无法处理的情况，则表明需要引入外部控制回路。例如，我们可以开发基于学习的控件，这些控件的推理引擎将作为近实时 RIC 上的应用程序运行，而它们的非实时学习引擎则运行在其他地方。然后，非实时 RIC 与近实时 RIC 交互，通过 A1 接口从管理平面向近实时 RIC 推送相关操作策略。

最后，你可能想知道，既然 3GPP 已经是负责全球蜂窝网络互操作性的标准化机构，为什么还要有 O-RAN 联盟。答案是，随着时间的推移，3GPP 已经成为一个供应商主导的组织，而 O-RAN 是最近由网络运营商创建的（AT&T 和中国移动是创始成员）。O-RAN 的目标是促成一种基于软件的实现，打破目前主导市场的厂商锁定。特别是 E2 接口，它是围绕支持不同服务模型的思想构建的，是该策略的核心。运营商能否成功实现最终目标还有待观察。

Reference:

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

[2] https://www.ngmn.org/wp-content/uploads/NGMN_RANEV_D4_BH_FH_Evolution_V1.01.pdf

[3] https://cseweb.ucsd.edu/~vahdat/papers/b4-sigcomm13.pdf

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

微信公众号：DeepNoMind