导读
功能拆分放到现在来说并不是什么新鲜事了，其概念最初在3GPP R14中就提及过，3GPP R15发布了定义，并引入了新的术语、接口和功能模块。
但是在Open RAN中，为什么RU、DU、CU功能拆分的概念变得如此重要？
本文将带你从Why、What、How、When四个方面进行全面了解。
WHY
先前的RAN架构（2G，3G和4G）基于“整体”构建块，其中逻辑节点之间很少发生交互。 但是，自从新无线电（NR）研究的最早阶段开始，就感到在中央单元（CU）和分布式单元（DU）之间划分gNB（NR逻辑节点）将带来灵活性。 灵活的硬件和软件实施方式允许进行可扩展的，具有成本效益的网络部署-但前提是硬件和软件组件可以互操作并且可以与不同供应商进行混合和匹配。 分离式架构（在中央单元和分布式单元之间）允许协调性能功能，负载管理，实时性能优化，并能够适应各种用例和需要支持的QoS（即游戏，语音，视频），具有不同的延迟容忍度以及对传输的依赖以及不同的部署方案（例如农村或城市），这些部署方案具有像光纤一样的不同传输方式。
但是，什么使任何拆分的体系结构开放并适用于Open RAN？
移动运营商可以部署完全兼容的功能拆分体系结构，但是除非RU，DU和CU之间的接口是开放的，否则RAN本身将不会开放-请参阅下图，该图显示了当前的行业思想。 根据他们的经验，诺基亚认为唯一有效的划分是在RU和DU之间。 时间将证明一个供应商的DU与另一供应商的CU的集成是否会带来灵活性和节省。
资料来源：诺基亚
主要收获：如果开放硬件和软件组件之间的接口，功能拆分将节省成本。
WHAT
在5G RAN架构中，BBU功能分为两个功能单元：负责实时L1和L2调度功能的分布式单元（DU），以及负责非实时，较高L2和更高实时性的集中式单元（CU） L3。 在5G云RAN中，DU的服务器和相关软件可以托管在站点本身上，也可以托管在边缘云（数据中心或中央办公室）中，具体取决于传输可用性和前传接口。 CU的服务器和相关软件可以与DU放在同一位置，也可以托管在区域性云数据中心中。 DU和RU之间的实际划分可能会有所不同，具体取决于特定的用例和实现（尽管O-RAN联盟的定义是Option-7.2，而Small Cell Forum是Option-6）。
资料来源：赛灵思
RU：这是处理数字前端（DFE）和PHY层各部分以及数字波束成形功能的无线电单元。5G RU设计本来应该是“固有的”智能，但是RU设计的关键考虑因素是尺寸，重量和功耗。
DU：这是分布式单元，位于RU附近，并运行RLC，MAC和部分PHY层。 根据功能划分选项，此逻辑节点包括eNB / gNB功能的子集，并且其操作由CU控制。
CU：这是运行RRC和PDCP层的集中单元。 gNB由一个CU和一个DU组成，一个DU分别通过Fs-C和Fs-U接口分别用于CP和UP。 具有多个DU的CU将支持多个gNB。 拆分架构使5G网络能够根据中途可用性和网络设计在CU和DU之间利用协议栈的不同分布。 它是一个逻辑节点，除了专门分配给DU的功能外，还包括gNB功能，如用户数据传输，移动性控制，RAN共享（MORAN），定位，会话管理等。 CU控制中途接口上几个DU的操作。
集中式基带部署允许在不同RU之间进行负载平衡。 这就是为什么在大多数情况下，DU将在现场与RU并置以执行所有密集处理任务，例如快速傅立叶变换/快速傅立叶逆变换（FFT / IFFT）。 以边缘为中心的基带处理可提供低延迟，本地突破，具有实时干扰管理的无缝移动性以及最佳的资源优化。 将DU与RU分离的三个目的：1.降低成本-减少智能RU的成本，减少2.能够一次查看RU的一个区域，而不仅仅是单个RU-这将有助于启用CoMP等功能， 3.由于在DU中完成处理，因此可以合并资源，从而获得合并收益。
业界已经达成共识，连接RU和DU（前传）的较低级接口应该是eCPRI，以提供最低的延迟。 前传延迟被限制为100微秒。 单个DU可能为距离最远的RU提供服务。
重要的是要注意，DU / CU拆分几乎不受基础结构类型的影响。 新的主要接口是DU和CU之间的F1接口，它们必须在不同供应商之间互操作，才能真正实现Open RAN。Midhaul将CU与DU连接起来。虽然理论上可以有不同的分割，但DU和CU之间唯一被认为是事实的分割是Option-2。 不同分割之间（1-5）之间的中途接口也几乎没有差异。 链路上的等待时间应为1毫秒左右。 集中式CU可以控制80 km半径内的DU。
回程将4G / 5G核心连接到CU。5G核心可能距离CU最多200公里。
资料来源：Altran（Aricent）
从CPRI开始的RAN供应商现在正在尝试出售其体系结构中将CPRI转换为eCPRI的解决方案，不应尝试证明这种方法的合理性，因为它会造成不必要的复杂性和延迟。 也许应该让他们想起当他们尝试通过IP发明ATM时ATM发生了什么？
主要要点：随着部署占地面积的增加，光纤和所需前传（FH）的可用性可能会面临挑战。 通过在不同组件之间分配协议栈（不同拆分），解决方案提供商可以专注于满足RU，DU和CU之间接近完美FH的严格要求。
HOW
如果需要更多对延迟敏感的服务，则基于适当的前传可用性，MAC-PHY拆分将是首选解决方案。 选项7拆分架构是DU处理RRC / PDCP / RLC / MAC和较高PHY功能的模块，而RU处理较低PHY和RF功能的模块。 CU功能可以与DU嵌入在同一服务器上，也可以与OpenRAN控制器或聚合器一起作为虚拟化聚合实体向上推入网络。 选件7使运营商可以在DU和RU上保持最低处理利用率的同时，利用共享或集中收益的优势–带来具有非常高成本效益的解决方案，具有较低的TCO，是分布式RAN部署（包括大规模MIMO）的理想选择。
资料来源：平行无线
对于5G，在某些用例中，这仍是一种可能有效的选择。 与7.x中一样，更高的拆分率将是在不同部署方案中部署未来移动网络的最佳方法。 它是4G和5G的理想选择，可支持人口稠密的城市地区的流量。
Split 8基于行业标准的CPRI接口，已经存在了一段时间。 通过业务量分割8，除了RF之外，所有功能（从PHY到RRC层）都由DU处理，而RF层位于无线电中。 但是，为什么这种分裂现在引起注意呢？
这种划分在2G和3G中非常有效，在2G和3G中，流量速率要低得多（因此处理本身在一定程度上较低），并且可以轻松地在x86服务器上完成，同时允许运营商以最小的成本使用成本优化的RU。逻辑和处理。DU和RU应与其他第三方DU和RU互操作。 对传统Split-8的增强在于，为了使RU在同一FH接口上运行多种技术，它们现在需要利用eCPRI代替RU和DU之间的传统CPRI接口。
此方法允许从RU进行集中的流量聚合，从而实现从传统LTE生态系统到NR生态系统的无缝迁移路径。
资料来源：平行无线
RAN DU位于RU和CU之间，并执行实时L2功能（基带处理）。 在O-RAN联盟工作组中，提出了DU支持多层RU。 为了正确处理数字信号处理并加快网络流量，可以使用FPGA。 但是要理解的重要一点是，硬件加速被认为是5G的要求，而在诸如2G，3G甚至4G之类的先前技术中则没有。
资料来源：Supermicro
围绕FPGA和GPU的硬件加速器也得到了关注，以加速针对5G无线电基带最低层的实时敏感处理。 爱立信和诺基亚正在研究针对某些vRAN工作负载的基于GPU的加速，特别是对于5G M-MIMO和AI。 因此，绝对有必要在不同的芯片技术上进行更多投资，以确保Open RAN可以访问市场上最好的DU。
降低总体TCO将是当务之急，围绕GP处理器架构的解决方案将提供创新，创新的解决方案，以提供最高效，最具成本效益的计算，存储和网络元素。
主要要点：不同的拆分适用于不同的用例。 一分裂可能不适合全部。 不仅支持4G和5G，还支持2G和3G的许多技术的解决方案对MNO最具吸引力，因为它将简化网络管理和总体TCO。
WHEN
在体系结构中如何拆分新无线电（NR）功能的选择取决于与无线电网络部署方案，约束和预期支持的使用案例有关的某些因素。 三个关键要素是：1.需要为所提供的服务支持特定的QoS（例如，低延迟，城市区域的高吞吐量）以及实时/非实时应用。 2.支持每个给定地理区域的特定用户密度和负载需求。3.具有从理想到非理想的不同性能水平的可用传输网络。
移动运营商需要使用不同的软件实现方案，以基于相同的基于COTS的硬件和网络组件灵活地选择不同的分组。 根据前传可用性和部署方案，不同的协议层将驻留在不同的组件中。 这种方法将降低移动运营商的运营成本和总体拥有成本。
对于人口稠密的城市地区的容量使用案例，较高的功能拆分更可取，而较低的功能拆分将是覆盖范围使用案例的最佳解决方案。 因此，尽管较低的功能拆分使用的功能少于完美的前传，但较高的功能拆分对前传性能的依赖性更大。
资料来源：平行无线
为了充分利用可提供互操作性，选择同类最佳组件的能力和可扩展性的拆分架构，任何解决方案都需要支持2G，3G，4G，5G基带功能。为了获得最佳的延迟支持要求，应将与硬件分离的基带功能部署在NFVI上或作为容器。MNO可以使用任何VM要求和/或任何编排来启用这些功能拆分 。
RAN的未来发展将朝着动态功能划分。 虽然OpenRAN控制器（聚合器）充当RAN与核心网络之间的中介，但RAN的功能将按照5G中的定义在DU和CU之间分配，并且该软件可以与聚合器位于同一位置。 在不同的情况下，这些元素可以折叠在一起并创建具有不同虚拟功能的单个物理实体。 我们将在接下来的部分中介绍开放式RAN控制器，近实时无线电智能控制器（Near-RT RIC）和非实时RIC（Non-RT RIC）。
转译自：Eugina Jordan
--END--
