电信运营商的能源成本可能高达总运营支出的 10%。随着运营商推出 5G，这一点尤其明显。尽管 5G-NR 标准比之前的标准更加节能（例如，5G 的每单位数据能耗 - 瓦/比特比 4G 低得多），但 5G 基站的总体功耗可以很高。例如，华为的一份报告表明，5G 基站的能耗可能是 4G 基站的约 1.7 倍[1]。随着大多数网络延迟关闭传统技术（2G-4G），总体能耗不断增加。图 1 很好地总结了支持多代移动设备的基站最大功耗（按组件划分）（来源：Analysys Mason），呈现出急剧上升的趋势。
由于无线电传播特性，5G 运行的新频段的使用将增加移动站点的密度。事实上，5G 需要更高的 RAN 密度才能提供相同的覆盖范围，同时具有更高的容量和吞吐量。此外，大规模 MIMO【https://info.support.huawei.com/info-finder/encyclopedia/zh/MIMO.html】 和更高的 MIMO 模式非常有利于支持高频段 (FR2) 的移动宽带，但需要更多的功率。此外，随着移动边缘计算，数据中心的数量将会增加，计算要求较高的用例将进一步加剧能源使用。 5G 操作的第三个方面是每个通道的操作带宽更高，已从 20 MHz (LTE) 增加到高达 400 MHz。为了降低设备功耗而将较大的带宽细分为带宽部分（BWP），这将导致基站的能耗增加。因此，总体而言，随着 5G 的推出，移动网络的能耗预计将大幅上升。
能源消耗的快速增长给电信运营商带来了两大压力：
所有这些方面都是移动运营商面临部署智能解决方案以优化其移动网络能耗的巨大压力的原因。
AT&T 最近的一份公开报告表明，该公司每年在能源成本上花费约 1.6B 美元 [3]。据估计，RAN 占该成本的 73%，这意味着 RAN 能源成本每年约为 1.1B 美元。即使我们仅节省 RAN 能源 1%，每年节省的费用也相当于 1100 万美元。研究表明，我们可以通过利用各种方法实现约 10% 至 15% 的能源节省，这将进一步增加优化移动网络电力利用率的财务吸引力。下面是这一点的简单说明。
在 RAN 中节能的方法之一是在低负载时段（例如，商业区的午夜至凌晨 6:00）关闭从容量角度来看不需要的小区或频率层（也称为载波） ）。我们将在后续部分中详细研究这个用例——现在我们只考虑基本的财务。例如，假设一个 MNO 有 100,000 个站点，每个站点平均有 3 个扇区，每个扇区有 3 个载波（小区）。如果两个运营商可以在关闭期间关闭（进入睡眠状态）平均 5 小时，则单元睡眠时间为 3x2x5 = 每天每个站点 30 小时。这意味着整个网络每年的总睡眠时间为 30 小时 x 100,000 个站点 x 365 天，约为 11 亿小时（约占总小区时间的 14%）。当一个单元进入睡眠模式时，它的功率放大器就会关闭。功率放大器的平均功耗为 200 瓦（0.2 千瓦）。如果我们平均每千瓦时 10 美分作为能源成本（在许多国家，这个值远高于此；例如，在一些欧洲国家，高达 30 美分），每年节省的成本约为 2200 万美元。请注意，这仅适用于 SMaRT 5G 下的一个用例，该用例下还有多个类似和增强的用例。
O-RAN 联盟还进行了一项研究，该研究显示了上述用例（小区开/关）的类似节能估计[4]。如果我们放眼全球，估计电信公司每年在能源成本上花费约 $25B，其中约 $18.25B 仅用于 RAN [5]。按照我们上面估计的 14% 的节省（仅模拟电池开/关方法），这相当于全球每年节省 2.55B 美元。根据一些传统计算，这意味着每年可减少 2,650 亿磅二氧化碳的排放 [6]。
ONF 的可持续移动和 RAN 转型 5G (SMaRT-5G) 项目是一项协作项目，旨在开发和演示ML（机器学习）驱动的移动网络智能节能解决方案。计划实施概念验证 (PoC)，以展示逐步先进的节能技术。实施将在开源 RAN 堆栈（为研究人员提供工具）和商业级 RAN配置（以加速运营商采用的解决方案）上进行。
该举措被构建为一系列分阶段的 PoC，旨在使 MNO 能够开始在开放 RAN 和传统 RAN 架构上使用每个 PoC 的结果，从而支持棕地和绿地网络并提供最快的路由影响。
SMaRT-5G正在探索优化整体功耗的两种主要方法：
最终的策略是以整体方式协调这两个方面并达到最佳的运行条件。
我们现在研究各种在 RAN 中节省能源的方法以及相关的一些实现细节。
SMaRT-5G 的第一项任务 (PoC) 是展示优化的小区开/关功能，其中涉及在移动网络中打开和关闭载波频率。或者，如果在低流量条件下不需要峰值吞吐量，则可以禁用载波聚合以进一步减少能源使用并为小区关闭决策提供更多自由。
参考图2，小区开/关可能有两种情况：
监控网络性能的三个常用 KPI 是：
关于 KPI 计算的快速说明。按照惯例，单元级 KPI 是根据定期（通常为 5/15/30 分钟间隔）从每个单元收集的性能计数器来计算的。计数器跟踪小区级事件并在事件发生时进行更新（例如，会话丢失、切换尝试）。对于传统 RAN，计数器按特定值报告EMS 的间隔（通常为 xml 文件）。然后解析这些 xml 文件以提取计数器值，并根据RAN 供应商给定的公式计算各种 KPI。
接下来，我们将更仔细地研究传统的宏小区场景。
例如，考虑一个具有 5 个小区（载波）、两个 700 MHz、一个 850 MHz 和两个 1900MHz 的扇区。一种策略是始终保持一个 700 MHz 小区（作为覆盖小区），因为它在载波中具有最佳的传播特性，并将其他载波视为容量小区。
如果需要进一步扩大节能，则可以使整个扇区进入休眠状态，甚至可以使整个站点进入休眠状态。这在密集的城市环境中是可能的，因为可以通过向上倾斜附近站点的天线或增加发射功率来实现覆盖补偿。尽管发射功率对小区边界有直接影响，但大多数移动网络运营商都会最大限度地利用可用功率，只留下很少的功率余量来增加邻近小区扇区方向的覆盖范围，而载波在该扇区上处于休眠状态。因此，调整天线倾角可能是覆盖补偿唯一可行的解决方案。通常进行倾斜调整来操纵垂直方向图，但较新的天线技术可以根据需要对覆盖方向图进行许多复杂的调整。
图 4 是当站点的整个扇区进入休眠状态时如何进行覆盖补偿的图形描述，并且通过调整面向休眠扇区的附近站点的扇区的 RF 足迹来补偿丢失的覆盖范围。
值得注意的是，为了用另一个电池来补偿关闭的电池，我们可能需要更高的功率，这是一种权衡，需要考虑在内。也就是说，补偿扇区可以比正常操作条件消耗更多的功率来提供关闭扇区中的覆盖。因此，关闭此类设置中的单元可能需要付出代价。
现在让我们看看当涉及小型蜂窝时如何应用蜂窝开/关概念。首先，考虑如图 5 所示的空间和时间流量，该图描绘了一个具有宏小区（具有覆盖）的扇区以及该扇区覆盖区域内的小型小区集群。该图还显示了不同时间 (t) 发生不同级别峰值 § 的流量分布。
以下几点值得注意：
1、如前所述，扇区内的一些宏小区（尤其是低频段）可以作为覆盖小区，而一些宏小区（中频段和高频段）可以作为容量小区。
2.小电池几乎都是容量电池。每个小型蜂窝扇区的峰值流量通常发生在不同的时间。例如，绿色集群的高峰交通时间可能发生在工作日的上午 8:00（假设在火车站），而黄色集群的高峰交通时间可能发生在同一天的上午 11:00。一天（假设是在商业区）。这意味着，绿色集群中的单元需要在工作日的上午 7:00 至上午 9:00 期间打开，而黄色集群中的单元只能在同一天的上午 10:00 到中午期间打开天。我们稍后会看到这个使用具有某些 RAN 功能虚拟化的分解 RAN 架构，操作非常有效。这也意味着相关的核心容量可以相应地打开/关闭，基于云的核心架构非常适合此目的。这两个方面对于节能都起着关键作用。
当决定关闭某个小区时，即使在低负载条件下，某些用户可能仍然占用该小区。这是一种极有可能发生的情况，因为空闲和连接状态期间的负载平衡方案可确保 UE 均匀分布在所有可用载波上（用于载波分配的基于 IMSI 的散列是通常遵循的技术）。需要对小区进行优雅的关闭，这意味着直到该小区上没有活动用户时才会关闭该小区。还需要从空闲模式和连接模式接入和邻居列表中删除应被关闭的小区，以便UE不会尝试继续检测该小区。可以通过两种方式实现电池的平稳关闭：
在配置系统进行电池关闭和开启时，通常使用两种方法：基于负载和基于时间：
将两种方法结合在一个解决方案上是有利的，这可以直观地产生良好的结果。
现在让我们看看分解的 RAN 如何在能源管理方面非常有效。这可以借助图 6 进行说明。
在此示例中，我们有 100 个 RU（无线电单元）、10 个 DU（分布式单元）（平均每个 DU 10个 RU）和 2 个 CU（中央单元）（平均每个 CU 5 个 DU）。
如果我们考虑每个集群平均有 10 个 RU，并且在给定时间仅需要 5 个集群，则仅需要5 个 DU 和 1 个 CU。由于 DU 和 CU 是 VNF，因此可以关闭这些 VNF，并且相关的云资源可能会进入休眠状态。这意味着除了与 RU 相关的节能之外还可以节省更多能源。此外，相应的核心容量（VNF）和相关的云资源也可以进入休眠状态，从而更加节能。
让我们看两个场景。
图 7 概括了两种情况下的概念：
需要注意的是，当操纵 MIMO 配置时，应补偿对覆盖范围的影响。为此我们有三种选择：
选项 1：增加射频功率，但会降低可能的节能效果。此外，大多数移动网络运营商都会最大限度地利用可用功率，而留下的功率余量非常小。
选项 2：光束形状管理（见图 8）。调整基站配置和相关天线方向图以确保覆盖范围。
选项3：上倾附近站点天线以补偿覆盖损失（就像小区开/关覆盖补偿一样，如图4所示）。
ASM 对应于基站不同组件的逐渐停用。可以根据每个组件的转换时间（即关闭然后再次唤醒所需的时间）来考虑不同类型的睡眠级别。这可以在符号级、子帧级、帧级或节点（RU）级完成。这个概念导致基站的不同组件分为四种睡眠模式类别，SM1 到 SM4[8,18]。
基本上：
– ASM 关闭某些 O-RU 组件并降低能耗。
– 睡眠模式级别越深（越长），唤醒时间越长（见下表1）。
SM1：表示最短的睡眠模式，需要 71 \mu s 的转换时间（OFDM 符号）。功率放大器以及数字基带和模拟前端（Rx 和 Tx 中）的一些组件被停用。
SM2：对应更长的睡眠模式，需要1ms作为过渡时间（1子帧或TTI），并且与SM1相比，模拟前端的更多组件被置于睡眠和唤醒状态。
SM3：功率放大器和数字基带的所有组件以及模拟前端的几乎所有组件（时钟发生器除外）都进入休眠状态。这些组件需要 10 毫秒（一帧）才能进入睡眠状态然后醒来。
SM4：这对应于整个基站进入待机模式，并且几乎其整个组件集（睡眠/唤醒功能所需的组件除外）都进入睡眠状态并被唤醒。这需要 1 秒的转换时间（因此通常称为深度睡眠模式）。
几乎所有 RAN 供应商都为传统 RAN 实施了节能解决方案，作为基本小区开/关方法的分布式自组织网络 (DSON) 解决方案。图 9 是基于 DSON 的解决方案的简化描述，该解决方案通常用于实现基本的小区开/关解决方案以节省 RAN 能耗。
尽管 DSON 实现因供应商而异，但从总体上看，其工作原理如下（请参阅图 9 中所示的基本解决方案）。
首先，MNO 必须将小区分类为覆盖小区（始终处于开启状态以确保覆盖的小区）或容量小区（根据负载进行睡眠和唤醒的候选小区）。这通常称为小区资格过程，由 MNO 作为单独的功能完成。一旦完成，移动网络运营商必须确定负载阈值。有两组阈值：(1) 容量单元的负载阈值，低于该阈值容量单元适合进入休眠状态，以及 (2) 活动单元的负载阈值，高于该阈值则休眠（容量）细胞应该被唤醒。通常这些阈值是 RRC 连接和 PRB利用率的特定值。 DSON 根据 RRC 连接数量和 PRB 利用率监控提供给 eNB 或 gNB 的负载，并确保执行适当的睡眠和唤醒操作。
当特定容量小区中的流量负载低于阈值（RRC 连接和 PRB 利用率）时，该小区将进入睡眠模式（实质上，功率放大器被关闭）。在复杂的实现中，计划休眠的小区中的所有活动用户都会主动转移到其他活动小区（容量小区或覆盖小区）。
现在假设只有覆盖小区是活动的，而所有容量小区都在休眠。当负载（RRC连接或PRB利用率）超过阈值时，所有容量单元同时被唤醒，而不是一个接一个地被唤醒。这是因为DSON 功能不知道流量增加的速率，并且为了保障性能，整个容量立即可用。
一个挥之不去的问题是唤醒休眠细胞所涉及的延迟。供应商在这一领域取得了良好进展，但可能达不到移动网络运营商的总体满意度。为了规避这个问题，运营商通常会设置非常保守的阈值，但这当然会减少节能机会。
另一个问题是每个小区负载阈值的定制，因为站点之间的负载特性差异很大，并且有时使用基于人工智能/机器学习的方法来解决这个问题，因为设置通用的、保守的睡眠/唤醒阈值会导致能量减少节省。
此外，重要的是要考虑到节能算法不能在真空中工作。关闭整个基站的决定需要与其他功能协调。一般来说，需要提供节能感知的流量引导机制，在小区关闭之前将用户移出小区。这需要协调和整体节能方法，以避免网络不稳定。
虽然 DSON 操作看起来很简单，但它有很多缺点。这些总结如下。
DSON 解决方案本质上以开环方式运行，对网络性能没有固有的反馈。小区睡眠/唤醒决策完全基于负载 – RRC 连接和 PRB 利用率。虽然这是一种合乎逻辑的方法，但 MNO 常常担心网络性能以及 DSON 快速响应网络负载突然增加的能力；小区休眠活动会占用 RAN 的容量，而负载是不可预测的，并且小区唤醒时间可能约为几分钟。因此，很多MNO并不完全有信心一直开启DSON功能，因此他们将这一功能的激活限制在网络维护时间（比如午夜至凌晨4:00）。然而，这会减少细胞的睡眠时间和相应的节能。
手动设置小区睡眠/唤醒阈值。如前所述，移动网络运营商的任务是设置阈值，这需要在节能和网络性能之间进行仔细平衡。因此，移动网络运营商常常被迫设置保守的、通用的睡眠/唤醒阈值，从而减少睡眠时间。很少有 MNO 自行或通过其供应商实施AI/ML 解决方案来根据站点/部门自定义阈值，如图 9 (b) 所示。
站点/单元鉴定过程是单独管理的，而且通常很费力。需要注意的是，并非所有容量单元都适合休眠。例如，如果某些容量小区用于动态频谱共享（DSS）或许可辅助接入（LAA），它们通常会从睡眠候选列表中删除。移动网络运营商存在许多此类条件，并且这些条件通常会随时间变化。站点/小区认证必须与 DSON 解决方案很好地集成，这通常并不容易做到。
网络中存在许多可能同时处于活动状态的自动化功能（如其他集中式 SON 类型功能），MNO 面临着协调这些其他功能与节能功能的困难。例如，如果站点集群中的流量卸载处于活动状态（即，将流量从"热点"站点移动到不太繁忙的相邻站点），则此功能需要与能源很好地协调节省（例如，需要在潜在冲突的行动中指定优先级）。这可能相当复杂。
请注意，睡眠/唤醒决策是由 DSON 在各个扇区/站点的基础上完成的。然而，集群中多个站点之间的协调将通过它们之间的整体流量管理来实现更好的节能效果。
一般来说，基于人工智能/机器学习的方法支持基于时间的节能策略和相关解决方案。目前，3GPP 和 O-RAN 标准 [4] [9] [10] 正在讨论利用 RAN 数据的基于 AI/ML 的智能节能。虽然智能控制器和不同 RAN 组件（节能 AI/ML 模型的功能和输入）之间的消息传递正在进行标准化讨论，但节能 AI/ML 算法背后的细节超出了标准化范围。
正确估计未来负载和小区服务质量对于设计智能节能解决方案至关重要。例如，如果预测负载低于实际负载，则关闭电池（或其他节能操作）可能会导致断电情况，因为电池在其实际和近期的未来负载较高时被关闭。另一方面，在负载过度预测的情况下，当未来实际负载较低时，电池可能不会被关闭，从而导致节能较少。
因此，在寻求最大节能和最小化服务质量下降之间存在固有的权衡。因此，在 AI/ML 的背景下，需要将 MNO 的偏好与 QoS 要求一起纳入未来的负载预测中。移动网络运营商可能会根据多种因素（例如客户合同、地理位置、一天中的时间、流量类型等）强调其网络中的服务质量而不是高水平的节能。例如，在市中心地区日间运营商将更加重视避免预测不足的情况，这可能导致服务质量下降，同时确保充分节约能源。相反，在夜间低流量时段，运营商可能会选择更加重视这些电池的节能。
我们进一步观察到网络中的每个小区可能具有不同的负载分布特征、不同的节能优先级和不同程度的流量不平衡[11]，需要基于相应的数据特征和数据在每个小区级别进行机器学习训练移动运营商偏好。请注意，一些现有的节能解决方案是在不同负载情况下负载平衡且均匀分布的假设下设计的。近年来，培训不平衡和公平性受到高度评价。机器学习社区对计算机视觉等不同领域的关注，但在智能 RAN 节能方法中尚未得到充分解决。
下面列出了基于 AI/ML 的节能解决方案的一些设计要求：
值得注意的是，如果对 QoS 给予较高的权重，则通常需要实时检查流量转移（并做出相应反应）。
考虑到这些点，让我们来看看O-RAN架构如何非常适合实施RAN节能解决方案。首先，图10 显示了节能解决方案的 O-RAN 架构框架：
提供基于 ML 的智能网络控制的 Non-RT RIC/rApps 和 Near-RT RIC/xApps 是该解决方案的核心。一般来说，非 RT RIC/rApp 实现的控制循环延迟为一秒或更长，而近 RTRIC/xApp 实现亚秒级控制循环。虽然 O-RAN 没有指定数据架构，但图 10 显示了支持PoC 实现的 RIC 数据存储。
有关该解决方案的更多详细信息，请参阅 O-RAN 规范 O-RAN.WG1.NESUC-R003-v01.00[4]。此外，Rimedo Labs 文章是获取更多信息的良好资源 [20]。
小区开/关和 RF 通道/MIMO 开/关可以使用非 RT RIC/rApp 实现，而 ASM 需要在近 RTRIC/xApp 中实现才能实现必要的性能/延迟。无论如何，基于 O-RAN/RIC 的节能解决方案具有以下优势。首先，我们将从架构的角度来看待它。
更多信息可以从 Rimedo Labs 白皮书 [7] 获得。
在操作上，基于 RIC 的解决方案具有以下优点：
固有的闭环解决方案。小区睡眠/唤醒决策基于 KPI，为 MNO 提供更好的网络性能处理。因此，该功能可以一直打开，从而提高节能效果。
移动网络运营商可以根据运营情况在节能和网络性能之间取得良好的平衡，并且凭借闭环能力充满信心。可以使用 AI/ML 技术实现扇区/小区的最佳睡眠阈值（PRB 利用率和 RRC 连接），无需任何人工干预，从而节省运营成本。
基于策略的细胞鉴定过程更易于管理，并且无需任何人为干预即可完成。这也可以与单元睡眠/唤醒过程集成，从而显着提高操作效率并降低相关成本。
RIC 具有集群中各个站点的可见性，与其他网络管理功能（例如负载平衡）相结合，使协调的睡眠/唤醒决策变得可行且高效，从而通过自动化降低网络操作复杂性。
RIC 应用程序愿景允许一流的解决方案提供商开发创新算法，而无需处理网络接口的复杂性。
然而，在 SMaRT-5G 中使用 O-RAN 架构会带来以下挑战，这些挑战对于一般 O-RAN 采用来说很常见：
因此，使 SMaRT-5G 能够快速对运营商产生影响的可能策略如下。
如果运营商处于 O-RAN 采用周期的早期（或者甚至没有采用 O-RAN），他们可以在 SMO和 EMS 之间或直接在 SMO 和节点之间开发自定义接口（取决于 RAN 供应商的支持级别） ）通过将 rApp 与其供应商的 DSON 结合使用，立即获得节能 rApp 的好处（见图11）。随着 MNO 进一步向 O-RAN 发展并将近 RT RIC 引入其架构，可以通过解决 ASM等更多用例来逐步增强节能优势。 SMaRT-5G 提供的价值可能会极大地激励运营商加速采用 O-RAN 标准。
请注意，除了 ASM 之外，本文讨论的其余 RAN 节能方法都可以通过 Non-RT RIC/rApp来实现。这些 rApp 可以与传统 RAN 的 DSON 配合使用，也可以与开放 RAN 的 xApp配合使用。
在本节中，我们概述了基于xApps和rApps的基于RIC的节能解决方案的一些基本要求。
当如前几节所述根据网络流量修改 RAN 元件配置以节省能源时，5G 移动核心容量和RAN/核心云资源也可以相应调整以节省能源。假设云原生实现，分配给各种任务的处理器核心的数量可以通过扩展或缩小云原生工作负载来调整。可以考虑反应性和预测性横向扩展/收缩，使用 AI/ML 来自动化预测场景。
随着 RAN 和移动核心工作负载被虚拟化和容器化为 CPU 负载，我们有机会动态调整计算，从而调整功耗，以更好地满足移动网络的实时和预计需求。随着网络流量的变化，移动核心用户面（UPF）受到的影响最为直接，也是节能的重点。图 12 说明了这个概念。我们正在考虑两个级别的计算优化 - (i) 系统级别，即 RAN 和 Core 的云资源的扩展/扩展，以及 (ii) CPU 级别，其中涉及支持 RAN 和 Core 的资源的 CPU 优化。
系统级计算节能是通过 O-RAN 联盟 [10] 指定的 FOCOM 和 NFO 云编排机制动态释放/暂停云资源来实现的。如果云原生网络功能的底层拓扑已知，则可以轻松获得有关可横向扩展的资源的信息。 O-RAN 联盟 [10] 正在制定 SMO 内交互的规范，并且人们对O-RAN SC 和 ONAP 对 O-Cloud 管理协作解决方案的兴趣日益浓厚 [19]。
在CPU层面，为了CPU的优化，开放标准的高级配置和电源接口（ACPI）提供了CPU电源管理的机制。 ACPI 电源管理规范分为两类或两种状态：P 状态和 C 状态。
电源性能状态（P 状态）提供了一种扩展处理器频率和电压以优化功耗的方法（假设CPU 功耗随频率呈线性变化，随电压呈二次方变化）。请注意，这会调整整个 CPU，并且闭环可以动态调整整个移动基础设施中的各个 CPU，以寻求容量与需求的平衡。
处理器空闲睡眠状态（C 状态）将 CPU 的选定功能置于睡眠状态。不同的处理器支持不同数量的 C 状态，在这些状态下 CPU 的各个部分都被关闭。由于可用状态取决于CPU，因此应仔细选择目标系统，并预先确定各种调整对各种类型的移动工作负载的影响（RAN 和移动核心预计对于选定的更改会有不同的行为）。
不同的平台提供了多种需要优化的硬件功能。这些功能允许精确调整特定 CPU 内核的核心/非核心和基本/涡轮频率。由于设置性能（效率、吞吐量、延迟等）系统的配置搜索空间很大，我们可以使用 ML 技术静态地调整 CPU 核心的配置，并且动态地达到所需的目标。可能需要优化解决方案来利用先进的动态资源分配技术来处理工作负载调度，以提高资源利用率、降低功耗并降低拥有成本。
为了在节点级别实现更多自主权，需要现代人工智能/机器学习技术来支持应用程序和资源所有者。贝叶斯优化、强化学习、深度学习等算法可用于静态和动态分配共享硬件资源（例如缓存线、内存带宽和CPU）状态）针对不同的应用程序，提高应用程序性能，提高服务器利用率，降低能源成本。
最近的资源分配优化工作可以分为两大类：基于搜索的方法和基于强化学习的方法。基于贝叶斯优化的搜索方法在资源分配方面已经受到关注[12][13][14][15]。在基于强化学习的方法中，基于深度 Q 学习的方法正在变得流行[16][17]。
图 13 是基于非 RT RIC/rApp 的解决方案的架构，其中包含端到端 RAN 和移动核心能源管理，其中包括 CPU 功率优化。
比较图 10（RAN 能量管理架构）和图 13，请注意以下增强功能：
当概念验证 (PoC) 实施旨在试验 SmaRT-5G 支持下的各种节能概念时，需要重点考虑以下几个方面：
如果我们看一下 RIC 的 O-RAN 标准的采用情况，最成熟的接口是 O1，运营商的早期采用围绕 SMO、Non-RT RIC 和 rApp。这是因为其他实体（例如 Near-RT RIC、xApp）以及支持接口（例如 A1 和 E2）严重依赖于供应商支持。
考虑到这些因素，可以考虑一系列 PoC 阶段，如图 14 所示。
可以看出，最初仅考虑 RAN（但同时考虑传统和分解的 RAN）。 PoC 程序从小区开/关开始，然后添加 MIMO 开/关。随后考虑针对 RAN 和移动核心的云资源优化以及 CPU 电源管理。在此阶段之前，PoC 仅需要 SMO/非 RT RIC。最后，介绍了Near-RT RIC并考虑了ASM场景。
PoC 的目标架构本质上如图 13 所示，添加了近 RT RIC 和相关接口以支持各种 ASM。如图 15 所示。
SMaRT-5G PoC 必不可少的另一个重要组件是 RAN 模拟器。需要 RAN 模拟器来解决以下问题：
– 模拟器有助于大规模测试应用程序。具有少量网络元素的"玩具网络"可能不足以实现此目的。
– 在实时网络上尝试新的想法和技术是高风险的。模拟器应该给移动网络运营商足够的信心，以便他们能够在新技术进行现场试验之前对其进行测试。这意味着一个好的模拟器应该能够尽可能多地显示实际的网络行为，因为它是由每个 PoC 中先进的技术/算法控制的。
– 模拟器应该能够涵盖全方位的"假设"场景，包括异常情况，通常称为"极端情况"。
作为说明，图 16 是图 10 的改编版，其中架构中集成了 RAN 模拟器。
RAN Simulator 可以利用 O-RAN SC 中的开源工作和 NS3 的使用，但也可以考虑其他选项，包括商业选项。对于 PoC，模拟器应专门解决以下功能（至少对于阶段 1 和阶段2）：
小区站点配置数据
– 扇区信息、载波频率（UL/DL）、发射功率、方位角、位置坐标等
邻居列表和相关详细信息
RRC 的尝试、成功与失败
– 流量，上行/下行
– PRB利用率，UL/DL
活动和空闲UE
用于计算性能 KPI（可访问性、可保留性、吞吐量）的附加数据
MIMO配置支持（第2阶段需要）
能源消耗KPI（也可以估算）
移交统计和KPI
– 传入/传出切换尝试/失败
让我们考虑一下如何在开源平台上启动 PoC（图 14）（请注意，商业平台也在并行开发中，旨在展示开放级和商业级的可持续性用例平台）。
第一阶段是纯粹的 rApp 游戏。此外，此阶段不需要非 RT RIC，因为此阶段不需要 A1接口。因此，我们可以使用基于O-RAN软件社区的轻量级ONAP/OSC组件的SMO。
第一步，开发一个事件生成器，它可以在 SMO 框架内手动触发 VES 事件，如图 17a 所示。这些事件是触发器，rApp 可以使用它们来创建特定操作。
下一步是开发 O1 模拟器（O-DU 和 O-RU）并公开 O1 YANG 模型（用于配置管理(CM)，如图 17a 所示。对于性能管理 (PM)，O1 模拟器公开样本真实网络数据就足以开始，并且它可以基于文件。
下一步是开发一个单元开/关 rApp（只是一个开始的微服务），消耗 PM 数据并触发 O1NETCONF 客户端执行 CM。
严格来说，如果没有R1接口，将该应用程序称为rApp是不合规的。但请注意，这是迈向全面的 rApp 的第一步，稍后将开发 R1 界面。
一旦此设置正常工作，可以使用具有 O1 接口的 NS3 模拟器（或类似功能）来执行上述步骤，如图 17b 所示。请注意，此时不需要手动事件触发器，因为模拟器将解决该方面的问题。
PoC 各个阶段的构建方式使得 MNO 可以根据其逐步采用的 O-RAN 水平从 PoC 的每个阶段中受益，并与网络从棕色到棕色的演进保持一致。现场场景（现在）到完全开放的RAN场景（如图11所示）。如图 18 所示：
在图 18 中，rApp 通过 EMS 控制棕地网络中的 DSON。为此，MNO 需要开发两个适配器，一个用于从 EMS 收集 PM 数据并通过 O1 将这些数据推送到 SMO，另一个用于通过EMS 实现 eNB/gNB 中的参数更改通过O1。当然，适配器取决于供应商，并且可以与 EMS 一起使用 REST 或 Web 服务接口。
如果/当 MNO 具有 O-RAN 兼容网络时，可以丢弃适配器并使用直接 O1 连接来实施节能解决方案。
RAN 节能是移动网络运营商乃至全世界的一个重要用例。 Open RAN 为解决这一重要问题提供了高效的技术可能性。 ONF 的可持续移动和 RAN 转型 5G (SMaRT-5G) 项目是一项协作项目，旨在为传统和开放 RAN 移动网络开发和演示 ML 驱动的智能节能解决方案。鉴于开放 RAN 标准的采用进展缓慢，设计出同样适用于传统 RAN 和开放 RAN 的解决方案非常重要，这样才能在当前产生影响，并随着开放 RAN 采用的进展而增强影响。为了实现节能目标，同时促进开放 RAN 的采用，运营商、系统集成商、应用开发商和平台提供商之间的技术试验至关重要。 ONF 提供了一个优秀的行业论坛来促进这样的生态系统，ONF 正在 SMaRT-5G 项目的背景下与行业合作伙伴合作实现这一议程，在开源和商业 RAN 堆栈上相继实施更强大的 PoC。
