O-RAN雲原生自動化的發展與挑戰

本文整理並逐一說明目前電信產業雲原生轉型,可能會面臨到的眾多挑戰,此外,說明為何電信產業已經引入了雲原生技術,卻仍舊無法真正地享受到雲原生轉型所帶來的各項好處。期望鼓勵更多莘莘學子投入 O-RAN 領域研發新議題,以助我國在半導體領域之外,再創國際新巔峰!

Cloud RAN Automation 發展的現況和議題

1. 命令式機制在 RAN Automation 中的缺點

目前,要實現 RAN Automation,會需要先制定用於優化 Policy 以及觸發執行 Policy 的門檻(threshold) 。這些 Policy 可以用來自動調整 Network Function 的 Configuration 參數,以俾提高網路的效能,或讓佈署在 O-Cloud 上的 NFs 可以根據資源的負載狀況自動進行 scale-out、scale-in。
但由於目前的 NFs 仍是採用經典的 CNF、VNF,因此需要撰寫 helm chart 或 docker compose 來執行用於優化 Policy。然而,helm chart 和 docker compose 這些工具都還屬於命令式機制(imperative programming),這是一種開發人員早已制定好,明確要求 RAN 需執行的步驟,而非根據即時情況自動做出的決定;綜合以上所述,我們了解目前要實現 RAN Close loop Automation ,可以說是非常繁瑣。

2. 採用 Helm chart 部署 RAN 的侷限性

使用 Helm chart 部署 O-RAN 時存在一些侷限性。例如 Helm chart 的可重複利用率較低,因為它通常是針對特定使用場景來定制的,而且通常只會在 Day 1 部署時使用。而 RAN 這種東西,是需要長期維護的,而且部署在不同的使用場景(Scenario) 的 RAN,就必須有不同的 Helm chart,並且當服務需要升級時,就還會需要使用另一組 Helm chart 來進行升級和管理。
以台灣任一電信業者為例,它們通常會需要佈署大量的 RAN(基地台)在不同地點,因此僅 Day 1 的部署就會生成大量的 Helm chart。並且隨著時間的推移,管理和維護這些 Helm chart 的成本都會變得非常高昂。
用熱力學的概念來總結的話,就是說,想用 Helm Chart 來部屬基地台,你的 Entropy 會很變得高喔!

3. O-RAN O-Cloud 目前僅提供 CNF 基礎的 LCM

O-Cloud 為佈署在其上的 CNFs 提供一些基礎的生命週期管理(Life Cycle Management)功能,包括部署(Deploy)、終止(Terminate)、水平擴展/縮減(Horizontal Scale-out & in)。截至 2023 年 6 月 O-RAN 最新標準,健康狀態偵測(Health Check)、自愈(Heal)、診斷(Diagnostic)和垂直擴展/縮減(Vertical Scale-out & in)等功能,仍待未來研究(For Future Study)。

截至2023/06,O-Cloud 上面有關 CNF 的 LCM 很多都還是 FFS

4. NF 和 Cloud Infrastructure 之間複雜的 LCM 需求

在電信產業轉型到全雲原生之後,想要實現網路功能 (NF) 自動化,第一個可能會遇到的瓶頸就是原生 Kubernetes 的功能有限,無法滿足電信產業 NF 的所有需求。
電信產業的 NF 具有許多特定需求,例如 SR-IOV、DPDK、CPU pinning/hugepages。原生的 Kubernetes 並不具備這些功能,因此需要擴展功能來實現。例如,NF managers 可以用來控制 End-to-End application 和服務管理這方面的功能。除此之外,NF 和雲基礎架構 (O-Cloud Infrastructure) 都具有複雜的生命週期管理 (LCM) 需求。原生 Kubernetes 的編排系統也並不支援 LCM,因此也需靠擴展功能套件來解決。
因此,為了實現 NF Automation,就需要在 CNF 上擴展功能,並進一步研究如何與 O-Cloud Infrastructure 進行整合,因為 O-Cloud 可能會分為多個平面,(例如:控制平面、管理平面和數據平面)所以會需要準確規劃哪些 NF 要部署在哪些平面上。這也是電信雲原生轉型實現 NF Automation 所需要考慮的問題之一。

O-Cloud 可以分為三個功能平面:
管理平面(Management Plane)、控制平面(Control Plane)、部署平面(Deployment Plane)

5. 「帶外管理網路自動化」的局限性問題

現代的網路架構中,(上圖紅色框框)虛擬化基礎設施管理 (VIM) 和雲原生應用服務 (CaaS) 都是 Infrastructure Orchestration Layer 的一部分。然後(上圖紅色框框)的最上面,還有一個 Network function Orchestration Layer,負責管理 Network Function Deployment、Network function configuration,還有 Service deployment 和 Service management。而這種網路管理方式,稱之為 out of band management(帶外管理)。

我們的目標是全雲原生自動化,所以當然會希望網路的管理越簡單越好,但當我們想要同時實現 NFs Automation 和 Infrastructure Automation,僅靠單一個帶外管理的Orchestration Layer(例如:NF manager、 NFVO),是無法解決所有連貫性的問題。所謂連貫性的問題指的是,NFs 和 Infrastructure 之間的合作協調。

在這個案例架構中,帶外管理網路自動化只能管理網路基礎設施,而不能管理 NFs,因此它不能解決這一問題。因此,如果我們想要同時實現 NFs Automation 和 Infrastructure Automation,就需要使用「帶內管理網路自動化」。
而所謂「帶內管理網路自動化」是將 NFs 的管理功能整合到 Orchestration layer 中,這樣我們就可以使用單個 Orchestration layer 來管理 NFs 和網路基礎設施。

若覺得本文有任何不精確的地方,歡迎留言指教,有任何想法,或是對於 O-RAN 有興趣的話,歡迎與我聯繫,可以共同討論交流~;現在中歐時間 03:14 ,剛剛兩點時,我百川期末專題報告遲交9秒,就才9秒而已欸,氣死,等等發文完,我就要來睡覺了,因為等等早上八點,晶創計畫的長官還要跟我聊 MD 累...~

這篇我還會再小修一下文字,讓讀者閱讀起來更順一點~

聯絡資訊(蔡秀吉)

參考資料

留言

這個網誌中的熱門文章

生成式AI將電信業推向新紀元

O-RAN Y1介面簡介

「強化全民數位韌性」之前?先來聊聊什麼是 O-RAN 吧!| 科普教育