关于xAPPs 与 RAN 功能的对比关系

近日，爱立信官网发布了一篇名为《Security considerations of Open RAN》的文章，引起业内人士广泛转发。

文中指出，随着行业向 vRAN 和 O-RAN 发展，采用基于风险的方法来充分解决安全风险非常重要。对于包括 O-RAN 的任何新兴技术，安全性在设计之初就应该完整构建，而不是事后再补。为了确保 O-RAN 能满足运营商安全级别，爱立信基于对 O-RAN 标准的参与和实践，指出其存在一些安全风险。

3GPP RAN 架构与 O-RAN 架构的区别

如上图，3GPP R15 引入了 CU 和 DU 分离的 RAN 架构，定义了 CU-CP（控制面）和 CU-UP（用户面）之间的 E1 接口，以及 CU 与 DU 之间的 F1 接口。

但 O-RAN 进一步开放前传接口，并在管理层和 RAN 新引入了 Non-Real-Time RIC 和 Near-Real-Time RIC 两个控制器，同时新增了 A1、E2、O1、O2 等接口。

从架构上不难看出，为了实现开放化和智能化，Open RAN 架构更加复杂，这可能会增加如下安全风险。

开放前传接口安全风险

在传统 RAN 部署方式下，DU 和 RU 来自同一厂家，DU 和 RU 之间的前传接口由单厂家实现。而 O-RAN 采用 7-2x 开放前传接口，O-DU 和 O-RU 可以来自不同的厂家。

当 O-DU 和 O-RU 来自不同厂家时，意味着 O-DU 不能完全控制 O-RU，需要通过更高层的服务管理与编排层来辅助管理，这可能会带来通过前传接口向 O-DU 之上的北向系统发起中间人攻击的风险。

Near-Real-Time RIC 安全风险

为了便于理解，我们先来科普一下 O-RAN 架构中的 Non-Real-Time RIC 和 Near-Real-Time RIC 这两个控制器，以及 SMO（服务管理与编排）。

（O-RAN 架构）

SMO，Service Management and Orchestration，类似 NFV 中的 MANO，负责管理网络功能和 NFVI 基础设施，其包含的管理接口和管理内容如下：

• O1 接口：负责管理网络功能（vNF），包括配置、告警、性能、安全管理等。

• O2 接口：负责管理云平台（o-cloud）的资源和负载管理。

• M-Plane 接口：负责对 O-RU 管理。

RIC，全称为 Radio intelligent controller，无线智能控制器。顾名思义，就是通过引入 AI 实现 RAN 运维自动化、智能化。

Non-Real-Time，指非实时部分，负责处理时延要求大于 1 秒的业务，比如数据分析、AI 模型训练等。

Near-Real-Time，指近实时部分，负责处理时延要求小于 1 秒（50ms-200ms）的业务，比如无线资源管理、切换决策、双连接控制、负载均衡等。

Non-Real-Time RIC 位于 SMO 内，通过从 RAN 和应用服务器收集全域相关数据，进行数据分析和 AI 训练，并将推理和策略通过 A1 接口下发、部署于 Near-Real-Time RIC。

Near-Real-Time RIC 位于 RAN 内，负责收集和分析 RAN 的即时信息，结合 Non-Real-Time RIC 提供的额外或全局信息，并通过 Non-Real-Time RIC 下发的推理模型和策略，实时监控和预测网络和用户行为变化，并根据策略（比如 QoE 目标）实时对 RAN 参数进行调整，包括调整资源分配、优先级、切换等。比如，预测到网络即将发生拥塞，Near-RT RIC 根据推理实时调整网络参数以预防拥塞。

Near-Real-Time RIC 中包含了多个 xAPP。

（xAPPs 与 RAN 功能的关系）

xAPP 是可以由第三方独立部署的应用，它将 AI 推理模型和策略部署于其中，并且不同的 xAPP 与不同的 RAN 功能关联，从而使得 RAN 功能组件具备灵活的可编程性和可扩展性。

总之，O-RAN 通过引入 Non-Real-Time RIC 和 Near-Real-Time RIC，两者合力可基于 AI 对网络负载均衡、移动性管理、多连接控制、QoS 管理、网络节能等功能进行主动优化和调整，最终实现网络智能化、自动化。

但对于这样的架构，爱立信指出，O-RAN 中的 Near-Real-Time RIC 存在潜在的安全漏洞，包括 Near-Real-Time RIC 与 gNodeB 冲突、xAPPs 冲突、xAPP 信任根、RIC 中的 UE 标识等问题。

Near-Real-Time RIC 与 gNodeB 冲突

由 O-RAN 架构可知，Near-Real-Time RIC 作为一个逻辑实体，或者说由多个 xAPPs 组成的软件平台，其部署于 gNodeB（CU-CP、CU-UP 和 / 或 DU）之上。

Near-Real-Time RIC 可通过 E2 接口在 xAPPs 与 gNodeB 之间交换数据，来实现每个 xAPP 控制一个或多个 RRM（无线资源管理）功能。比如，Near-Real-Time RIC 可以通过 E2 接口让特定的 xAPP 与 CU-CP 之间交换数据来控制移动性和负载均衡。

但问题来了，Near-Real-Time RIC 控制 RRM 功能，gNodeB 也执行 RRM 功能，两者之间没有明确的功能界限划分，这可能造成 Near-Real-Time RIC 和 gNodeB 供应商之间存在决策冲突，从而可能导致网络不稳定，甚至带来攻击者可以利用的漏洞，比如，攻击者可以利用恶意的 xAPP 故意触发与 gNodeB 内部相冲突的 RRM 决策而导致服务拒绝。

xAPPs 冲突

Near-Real-Time RIC 中的 xAPPs 可以由不同的供应商提供，比如，一家供应商可提供用于移动性管理的 xAPP，另一家供应商可提供用于负载均衡的 xAPP。

除非能做到完美协调，否则不同 xAPP 可能会做出相互冲突的决策，比如，用于移动性管理的 xAPP 和用于负载均衡的 xAPP，在同一时刻为同一用户触发了不同的切换决策，该听谁的？这可能会引发无线链路故障风险。

在 O-RAN 规范中已指出 xAPPs 之间存在以下可能的冲突：

• 直接冲突：不同的 xAPPs 请求修改同一参数。

• 间接冲突：不同的 xAPPs 请求修改不同的参数，但修改这些参数会产生相反的效果，比如天线下倾角和测量偏移。

• 隐式冲突：不同的 xAPPs 请求修改不同的参数，这些参数不会产生相反的效果，但可能会导致网络整体性能下降。

由于 xAPPs 冲突会导致网络不稳定或性能下降，攻击者就可能会利用这个漏洞来攻击网络，令网络存在安全隐患。

xAPP 信任根

Near-Real-Time RIC 中的 xAPP 具有处理特定小区，一组 UE，以及特定 UE 的行为的能力。简单的说，xAPP 可以追踪某个特定用户，并可以通过从 A1 接口接收命令设定特定 UE 的优先级，这存在 VIP 用户的大致位置和优先级设置会通过故障 xAPP 暴露或恶意更改的潜在风险。因此，为了减轻这些风险，需要从硬件到应用程序建立牢固的信任链。

此外，爱立信在文章中还指出软硬件解耦增加了对信任链的威胁，以及开源代码增加了漏洞的暴露等其他安全隐患。

对于这些问题，爱立信认为，随着 RAN 向虚拟化、开放化发展，行业应该采用全新的方式来处理安全性，并表示将继续在 O-RAN 联盟中发挥领导作用，整合安全最佳实践，以确保 O-RAN 满足运营商的安全级别。

爱立信于 2018 年 12 月申请加入 O-RAN，2019 年 2 月正式加入 O-RAN，并在 O-RAN 工作组中占有两个主席职位。作为 O-RAN 的主要成员之一，爱立信基于对 O-RAN 的深入研究，在今年 3 月份主持的一次 Open RAN 网络研讨会上，也提出了以上类似的观点。

在会上，爱立信 O-RAN Program Manager Per Emanuelsson 指出，由于 O-RAN 引入了 Non-Real-Time RIC、Near-Real-Time RIC 和更多开放接口，存在以下挑战：

1）Non-Real-Time RIC 和 A1 接口

尽管通过 Non-Real-Time RIC 和 A1 接口，可收集包括核心网、传输网和应用等更广域的数据，并实现闭环的自动化网络等，但存在用例不清晰、价值不明确等问题。

2）Near-Real-Time RIC

Near-Real-Time RIC 包含了多个 xAPP，需一组 xAPP 与 CU-CP（CU 的控制面）交互完成无线管理决策，比如切换，这可能会带来以下问题：

• xAPP 之间发生冲突

不同的 xAPP 同时运行于相同的无线资源和 UE，要实现在 ms 级内相互协作是一大挑战。

• xAPP 与 CU-CP 冲突

像切换、负载均衡等无线资源管理功能，本身是相互强关联的，而 O-RAN 将这些功能模块通过 xAPP 的方式拆分部署于 Near-Real-Time RIC 和 CU-CP 中，这并不是最优的选择。

3）开放的前传接口

爱立信认为，开放前传接口后，运营商可以从不同的设备商购买 DU 和 RU 设备，有助于扩大产业生态。

但存在以下挑战：

• 增加测试和集成工作量

• 会明显降低 RAN 性能

4）云化 RAN

云化 RAN 解耦了硬件和软件，并将软件部署于标准的 COTS 硬件之上（至少部分是 COTS 硬件），有利于组成资源池，扩大供应商生态。

但存在以下挑战：

• 相比专用硬件，性能会下降

• 设备功耗会增加
       责任编辑:pj