如何在Cloud RAN中发挥5G中频的最大效能

开启新的激动人心的旅程

目前大多数5G部署都依靠中频来提供出色的客户体验，对于通信运营商而言，需要优化这些部署才能获得最大收益。

在这篇博文中，我们将展示爱立信如何利用云基础设施应对5G中频挑战，为运营商提供一些启发，并讨论要想获得成功的解决方案需要考虑哪些方面：

• 中频部署面临哪些挑战，如何在云基础设施中解决这些挑战？
• 如何将爱立信无线系统（Ericsson Radio System）的先进设计理念和丰富经验运用到Cloud RAN中？
• 低频段和中频段处理需求的差异会带来哪些影响？
• 如何将云基础设施的方方面面反映到总体拥有成本（TCO）评估中？

认真思索以上问题，让我们携手开启旅程：基于云基础设施的中频，将是这段奇妙之旅的起点。

解决中频覆盖难题

在6GHz以下的宽带时分双工（TDD）频段运行5G中频，可实现5G承诺的高容量，但由于波长较短，与低频段相比，它的覆盖范围较小。上行链路是限制因素，爱立信有两个主要的解决方案可解决这一难题，即Uplink Booster和5G载波聚合。

Uplink Booster

Uplink Booster是爱立信无线系统目前提供的一种创新解决方案，它将上行链路波束赋形处理从基带移至大规模MIMO无线基站，在爱立信多核架构（EMCA）上运行，从而扩大5G中频的覆盖范围。这将产生高达10dB的增益，相当于使覆盖面积扩大了3.7倍，可大大提高上行链路吞吐量和频谱效率。

从技术方面而言，Uplink Booster基于爱立信低层分离（E-LLS）技术，它能够分割协议栈的处理，并将大部分1层处理分流到无线单元，特别要提的技术是瞬时信道估算和全干扰抑制合并（IRC）。此外，我们使用演进型通用分组无线接口（eCPRI），减少了90%的前端数据需求。这是我们解决方案的一个主要优势，适用于爱立信无线系统和Cloud RAN。

借助5G载波聚合扩大覆盖范围

5G载波聚合是爱立信产品组合中另一个强大的解决方案。我们的解决思路是将下行链路与上行链路分离，将下行链路数据保持在中频，同时将上行链路数据和控制面移至低频段。简而言之，将中低频相结合，较弱的上行链路将到达5G低频段上的基站，这段距离更长。而5G中频信号将在基站允许的范围内传输，同时确保扩大覆盖范围，即使用户设备的信号较弱也不会受到影响。

这有两个主要优势：

• 与双连接部署相比，覆盖范围随着低频段的延伸而扩大了，增益增加了7dB，使覆盖范围扩大了2.5倍。
• 由于扩大了中频覆盖范围，整个网络实现了约27%的扩容，因此还可以将流量分流到中频。

在将5G载波聚合引入Cloud RAN的过程中，我们充分利用了从爱立信无线系统的成功中所获得的深厚知识、丰富经验和创新。爱立信无线系统全套组合始终以前瞻性视角打造，能够和未来的Cloud RAN解决方案无缝地协同工作。

我们产品组合的另一个优势是高输出功率中频无线基站，旨在应对中频的严格处理要求和覆盖挑战。通常情况下，每兆赫（MHz）带宽需要2瓦特（W）的输出功率。中频有100MHz带宽，这意味着无线基站可提供至少200W的功率。爱立信的产品组合为运营商提供了一站式服务，为爱立信无线系统和Cloud RAN部署提供高输出功率和高性能。

中频与低频处理比较

在以前的博文中，我们曾讨论过5G中频与低频所需的处理能力是不同的。下面，我们将探讨云基础设施结合加速器如何应对这一处理挑战。

在商用现货（COTS）服务器上，一个满载低频小区所需的处理能力（不包括操作系统和常见功能的处理）大约是1个内核。而一个没有任何加速器的满载中频小区则需要大约16个内核。处理量的巨大差异源自中频系统产生和消耗的数据量，带宽、各层和流量模式的差别。中频小区下行链路的带宽大约是低频小区的20倍（图1列出了粗略计算）。

图1.中低频处理需求对比

由于处理需求巨大，在与预期流量一同增长的部署场景中，基于纯软x86的中频实施方案在商业上不可行。然而，如果将某些第1层功能的处理分流到更专业的硬件，即加速器上，那么基于云基础设施的RAN也适用于中频。

在确定云基础设施的规模时，需要考虑整体情况。通信运营商需要考虑无线功能的处理要求，还要考虑管理、编排、前传和后传终结以及处理系统组件生命周期所需的处理能力。

在这些分解的系统中，规模过大和过小就在一线之间。必须做出战略选择，要么为系统的新功能和用户创建处理净空，要么缩小硬件尺寸，限制物理尺寸和功耗。无论采用哪种方式，都必须仔细考虑目标部署场景和预期流量的增长。

加速器选择

加速器的一个重要方面是可编程性。通常，一个完全可编程的解决方案的可扩展性最好，用途也最广泛，它能够根据流量负载和当前通信运营商的需求进行自动化调整。也就是说，最终将在可编程性和计算效率之间进行权衡，一个更加强大的解决方案总会以降低灵活性为代价来提高效率。在加速架构和硬件方面，市场上存在不同的声音。通常使用的加速器硬件包括现场可编程门阵列（FPGA）、图形处理单元（GPU）或专用集成电路（ASIC）。

在第1层加速的架构，有两种基本的方法-后备加速（look-aside acceleration）和内联加速（inline acceleration）。

两者之间的主要区别在于：在后备加速（look-aside acceleration）中，只有选定的功能被发送到加速器，然后返回到CPU，而在内联加速（inline acceleration）中，部分或全部数据流和功能均通过加速器发送（参见图2）。

图2. 后备加速与内联加速介绍

Look-aside acceleration 后备加速

采用后备加速架构的情况下，加速器处理要加速的数据，而CPU可以游刃有余地使用其周期来处理其他有用的任务。CPU从加速器接收到处理后的数据后，便可以切换回初始处理环境，继续执行流程，直到下一个要加速的功能出现。

后备加速需要CPU和加速器之间传输大量数据，因此首选紧密集成。

Inline acceleration 内联加速

采用内联加速的情况下，可将第1层流程的一部分或全部分流到加速器上，这可能会减少CPU和加速器之间对接的数据量。在这种情况下，加速解决方案可以是可编程和“硬”模块的组合，同样在灵活性和效率之间进行权衡。

开放的重要性

Cloud RAN市场仍处于起步阶段，加速解决方案将随着时间的推移而不断发展。爱立信认为，确保生态系统中有多种可用的加速选项非常重要。在一个真正分解的系统中，理想的状态是完全独立于软硬件选择。在实践中，后备加速和内联加速在架构方面存在差异，需要对软件进行调整，以最大限度地提高性能。因此，爱立信正积极参与O-RAN联盟第6工作组（WG6）的工作，以期实现多种加速器配置的规范以及软硬件之间的开放能力协商。

在裸机上部署容器，优化总体拥有成本

加速器的使用大大减少了云基础设施所需的CPU内核数量。为了进一步减少尺寸、提高处理效率和降低总体拥有成本，我们认为，目前最佳方法是在裸机上使用Kubernetes容器。Kubernetes已成为部署云原生应用的首选平台。在裸机上运行该容器，本质上意味着取消虚拟化层（参见图3），这是行业的自然发展趋势。

图3. 虚拟机上的Kubernetes与裸机上的Kubernetes比较

爱立信对在虚拟机或裸机上部署云原生应用的情况进行了比较。分析表明，在裸机上进行部署，可使总体拥有成本减少至少30%，资本支出和运营成本都可实现节省。

从资本支出的角度来看，可从3个方面实现节省。首先，提高硬件利用率，减少占地面积。其次，提高应用效率，性能比虚拟机高10-20%。最后，通过简化成本结构消除了虚拟机专项费用。

从运营成本的角度来看，也能够从3个方面实现节省。首先，由于消除了虚拟机层和相关的升级复杂性，软件升级更快、更简单。其次，由于系统的多样化程度较低，因此各应用具有统一的能力。最后，由于应用程序上线实现统一了，因此简化了系统生命周期管理。

通信运营商在中频部署Cloud RAN时应考虑的要点

我们已经阐述了基于云基础设施部署5G中频的主要观点。概括来话，运营商应注意以下6个要点。

• 利用低频扩大5G中频覆盖范围对于满足用户的需求和期望至关重要。
• 高性能中频部署需要处理能力较高的高输出功率无线基站。
• 云基础设施的规模测算应考虑整体情况，并考虑未来场景的处理能力需求。
• 通过增加硬件加速器，云基础架构成为中频部署的可行选择。
• 选择加速器是一项战略决策，取决于通信运营商的部署和流量情况。
• 与虚拟机部署相比，裸机云原生部署将提高效率并降低总体拥有成本。

爱立信强大的产品组合将Cloud RAN引入5G中频

5G中频将成为所有运营商的关键构件。我们始终与通信运营商在一起，帮助他们踏上Cloud RAN的中频旅程，为战略决策提供支持，并按照领先客户提出的时间要求提供全面而强大的产品组合

为了解决5G中频覆盖挑战，我们利用无线领域的深厚知识，开发未来的高性能Cloud RAN解决方案，充分利用爱立信无线系统的先进设计理念和功能集，例如Uplink Booster和5G载波聚合。此外，我们的高输出功率无线基站增加了额外的容量，使通信运营商能够充分利用更大的带宽来获得最佳性能。通过在裸机上使用Kubernetes，我们还可以显著降低Cloud RAN的总体拥有成本。

爱立信随时准备协助客户让5G中频在Cloud RAN中充分发挥威力。

Watch the Mid-band considerations for Cloud RAN video

Explore the Tech Unveiled blogs and videos for Cloud RAN

Read more about Cloud RAN