關(guān)于xAPPs 與 RAN 功能的對比關(guān)系

近日，愛立信官網(wǎng)發(fā)布了一篇名為《Security considerations of Open RAN》的文章，引起業(yè)內(nèi)人士廣泛轉(zhuǎn)發(fā)。

文中指出，隨著行業(yè)向 vRAN 和O-RAN發(fā)展，采用基于風險的方法來充分解決安全風險非常重要。對于包括 O-RAN 的任何新興技術(shù)，安全性在設(shè)計之初就應該完整構(gòu)建，而不是事后再補。為了確保 O-RAN 能滿足運營商安全級別，愛立信基于對 O-RAN 標準的參與和實踐，指出其存在一些安全風險。

3GPP RAN架構(gòu)與 O-RAN 架構(gòu)的區(qū)別

如上圖，3GPP R15 引入了 CU 和 DU 分離的 RAN 架構(gòu)，定義了 CU-CP（控制面）和 CU-UP（用戶面）之間的 E1 接口，以及 CU 與 DU 之間的 F1 接口。

但 O-RAN 進一步開放前傳接口，并在管理層和 RAN 新引入了 Non-Real-Time RIC 和 Near-Real-Time RIC 兩個控制器，同時新增了 A1、E2、O1、O2 等接口。

從架構(gòu)上不難看出，為了實現(xiàn)開放化和智能化，Open RAN 架構(gòu)更加復雜，這可能會增加如下安全風險。

開放前傳接口安全風險

在傳統(tǒng) RAN 部署方式下，DU 和 RU 來自同一廠家，DU 和 RU 之間的前傳接口由單廠家實現(xiàn)。而 O-RAN 采用 7-2x 開放前傳接口，O-DU 和 O-RU 可以來自不同的廠家。

當 O-DU 和 O-RU 來自不同廠家時，意味著 O-DU 不能完全控制 O-RU，需要通過更高層的服務管理與編排層來輔助管理，這可能會帶來通過前傳接口向 O-DU 之上的北向系統(tǒng)發(fā)起中間人攻擊的風險。

Near-Real-Time RIC 安全風險

為了便于理解，我們先來科普一下 O-RAN 架構(gòu)中的 Non-Real-Time RIC 和 Near-Real-Time RIC 這兩個控制器，以及 SMO（服務管理與編排）。

（O-RAN 架構(gòu)）

SMO，Service Management and Orchestration，類似 NFV 中的 MANO，負責管理網(wǎng)絡功能和 NFVI 基礎(chǔ)設(shè)施，其包含的管理接口和管理內(nèi)容如下：

? O1 接口：負責管理網(wǎng)絡功能（vNF），包括配置、告警、性能、安全管理等。

? O2 接口：負責管理云平臺（o-cloud）的資源和負載管理。

? M-Plane 接口：負責對 O-RU 管理。

RIC，全稱為 Radio intelligent controller，無線智能控制器。顧名思義，就是通過引入 AI 實現(xiàn) RAN 運維自動化、智能化。

Non-Real-Time，指非實時部分，負責處理時延要求大于 1 秒的業(yè)務，比如數(shù)據(jù)分析、AI 模型訓練等。

Near-Real-Time，指近實時部分，負責處理時延要求小于 1 秒（50ms-200ms）的業(yè)務，比如無線資源管理、切換決策、雙連接控制、負載均衡等。

Non-Real-Time RIC 位于 SMO 內(nèi)，通過從 RAN 和應用服務器收集全域相關(guān)數(shù)據(jù)，進行數(shù)據(jù)分析和 AI 訓練，并將推理和策略通過 A1 接口下發(fā)、部署于 Near-Real-Time RIC。

Near-Real-Time RIC 位于 RAN 內(nèi)，負責收集和分析 RAN 的即時信息，結(jié)合 Non-Real-Time RIC 提供的額外或全局信息，并通過 Non-Real-Time RIC 下發(fā)的推理模型和策略，實時監(jiān)控和預測網(wǎng)絡和用戶行為變化，并根據(jù)策略（比如 QoE 目標）實時對 RAN 參數(shù)進行調(diào)整，包括調(diào)整資源分配、優(yōu)先級、切換等。比如，預測到網(wǎng)絡即將發(fā)生擁塞，Near-RT RIC 根據(jù)推理實時調(diào)整網(wǎng)絡參數(shù)以預防擁塞。

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

（xAPPs 與 RAN 功能的關(guān)系）

xAPP 是可以由第三方獨立部署的應用，它將 AI 推理模型和策略部署于其中，并且不同的 xAPP 與不同的 RAN 功能關(guān)聯(lián)，從而使得 RAN 功能組件具備靈活的可編程性和可擴展性。

總之，O-RAN 通過引入 Non-Real-Time RIC 和 Near-Real-Time RIC，兩者合力可基于 AI 對網(wǎng)絡負載均衡、移動性管理、多連接控制、QoS 管理、網(wǎng)絡節(jié)能等功能進行主動優(yōu)化和調(diào)整，最終實現(xiàn)網(wǎng)絡智能化、自動化。

但對于這樣的架構(gòu)，愛立信指出，O-RAN 中的 Near-Real-Time RIC 存在潛在的安全漏洞，包括 Near-Real-Time RIC 與 gNodeB 沖突、xAPPs 沖突、xAPP 信任根、RIC 中的 UE 標識等問題。

Near-Real-Time RIC 與 gNodeB 沖突

由 O-RAN 架構(gòu)可知，Near-Real-Time RIC 作為一個邏輯實體，或者說由多個 xAPPs 組成的軟件平臺，其部署于 gNodeB（CU-CP、CU-UP 和 / 或 DU）之上。

Near-Real-Time RIC 可通過 E2 接口在 xAPPs 與 gNodeB 之間交換數(shù)據(jù)，來實現(xiàn)每個 xAPP 控制一個或多個 RRM（無線資源管理）功能。比如，Near-Real-Time RIC 可以通過 E2 接口讓特定的 xAPP 與 CU-CP 之間交換數(shù)據(jù)來控制移動性和負載均衡。

但問題來了，Near-Real-Time RIC 控制 RRM 功能，gNodeB 也執(zhí)行 RRM 功能，兩者之間沒有明確的功能界限劃分，這可能造成 Near-Real-Time RIC 和 gNodeB 供應商之間存在決策沖突，從而可能導致網(wǎng)絡不穩(wěn)定，甚至帶來攻擊者可以利用的漏洞，比如，攻擊者可以利用惡意的 xAPP 故意觸發(fā)與 gNodeB 內(nèi)部相沖突的 RRM 決策而導致服務拒絕。

xAPPs 沖突

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

除非能做到完美協(xié)調(diào)，否則不同 xAPP 可能會做出相互沖突的決策，比如，用于移動性管理的 xAPP 和用于負載均衡的 xAPP，在同一時刻為同一用戶觸發(fā)了不同的切換決策，該聽誰的？這可能會引發(fā)無線鏈路故障風險。

在 O-RAN 規(guī)范中已指出 xAPPs 之間存在以下可能的沖突：

? 直接沖突：不同的 xAPPs 請求修改同一參數(shù)。

? 間接沖突：不同的 xAPPs 請求修改不同的參數(shù)，但修改這些參數(shù)會產(chǎn)生相反的效果，比如天線下傾角和測量偏移。

? 隱式?jīng)_突：不同的 xAPPs 請求修改不同的參數(shù)，這些參數(shù)不會產(chǎn)生相反的效果，但可能會導致網(wǎng)絡整體性能下降。

由于 xAPPs 沖突會導致網(wǎng)絡不穩(wěn)定或性能下降，攻擊者就可能會利用這個漏洞來攻擊網(wǎng)絡，令網(wǎng)絡存在安全隱患。

xAPP 信任根

Near-Real-Time RIC 中的 xAPP 具有處理特定小區(qū)，一組 UE，以及特定 UE 的行為的能力。簡單的說，xAPP 可以追蹤某個特定用戶，并可以通過從 A1 接口接收命令設(shè)定特定 UE 的優(yōu)先級，這存在 VIP 用戶的大致位置和優(yōu)先級設(shè)置會通過故障 xAPP 暴露或惡意更改的潛在風險。因此，為了減輕這些風險，需要從硬件到應用程序建立牢固的信任鏈。

此外，愛立信在文章中還指出軟硬件解耦增加了對信任鏈的威脅，以及開源代碼增加了漏洞的暴露等其他安全隱患。

對于這些問題，愛立信認為，隨著 RAN 向虛擬化、開放化發(fā)展，行業(yè)應該采用全新的方式來處理安全性，并表示將繼續(xù)在 O-RAN 聯(lián)盟中發(fā)揮領(lǐng)導作用，整合安全最佳實踐，以確保 O-RAN 滿足運營商的安全級別。

愛立信于 2018 年 12 月申請加入 O-RAN，2019 年 2 月正式加入 O-RAN，并在 O-RAN 工作組中占有兩個主席職位。作為 O-RAN 的主要成員之一，愛立信基于對 O-RAN 的深入研究，在今年 3 月份主持的一次 Open RAN 網(wǎng)絡研討會上，也提出了以上類似的觀點。

在會上，愛立信 O-RAN Program Manager Per Emanuelsson 指出，由于 O-RAN 引入了 Non-Real-Time RIC、Near-Real-Time RIC 和更多開放接口，存在以下挑戰(zhàn)：

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

盡管通過 Non-Real-Time RIC 和 A1 接口，可收集包括核心網(wǎng)、傳輸網(wǎng)和應用等更廣域的數(shù)據(jù)，并實現(xiàn)閉環(huán)的自動化網(wǎng)絡等，但存在用例不清晰、價值不明確等問題。

2）Near-Real-Time RIC

Near-Real-Time RIC 包含了多個 xAPP，需一組 xAPP 與 CU-CP（CU 的控制面）交互完成無線管理決策，比如切換，這可能會帶來以下問題：

? xAPP 之間發(fā)生沖突

不同的 xAPP 同時運行于相同的無線資源和 UE，要實現(xiàn)在 ms 級內(nèi)相互協(xié)作是一大挑戰(zhàn)。

? xAPP 與 CU-CP 沖突

像切換、負載均衡等無線資源管理功能，本身是相互強關(guān)聯(lián)的，而 O-RAN 將這些功能模塊通過 xAPP 的方式拆分部署于 Near-Real-Time RIC 和 CU-CP 中，這并不是最優(yōu)的選擇。

3）開放的前傳接口

愛立信認為，開放前傳接口后，運營商可以從不同的設(shè)備商購買 DU 和 RU 設(shè)備，有助于擴大產(chǎn)業(yè)生態(tài)。

但存在以下挑戰(zhàn)：

? 增加測試和集成工作量

? 會明顯降低 RAN 性能

4）云化 RAN

云化 RAN 解耦了硬件和軟件，并將軟件部署于標準的 COTS 硬件之上（至少部分是 COTS 硬件），有利于組成資源池，擴大供應商生態(tài)。

但存在以下挑戰(zhàn)：

? 相比專用硬件，性能會下降

? 設(shè)備功耗會增加
責任編輯:pj