4. RAN详解（RAN Internals）

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

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

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

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

关键步骤如下：

• 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所示的分割，我们在本书的其余部分将采用这种分割模式。

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

因为无线传输的调度决策是由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）》^[1]。

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的所有组成部分，加上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 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）》^[2]。

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接口。

接口名称看上去很神秘，不过知道它们的细节对我们理解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://www.ngmn.org/wp-content/uploads/NGMN_RANEV_D4_BH_FH_Evolution_V1.01.pdf

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