---
# System prepended metadata

title: O-RAN雲原生自動化的未來發展與挑戰
tags: [O-RAN]

---

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

## 命令式機制在 RAN Automation 中的缺點
目前，要實現 RAN Automation，會需要先制定用於優化 Policy 以及觸發執行 Policy 的條件 。這些 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 ，可以說是非常繁瑣。

## 採用 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 會很變得高喔！

## 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)。

![螢幕擷取畫面 (325)](https://hackmd.io/_uploads/BkFl0cwK6.png)
> 圖（一）截至2023/06，O-Cloud 上面有關 CNF 的 LCM 很多都還是 FFS[color=#F4B400]

## Network Functions 和 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 所需要考慮的問題之一。
![螢幕擷取畫面 (326)](https://hackmd.io/_uploads/Sk4ERcwK6.png)
> 圖（二）O-Cloud 可以分為三個功能平面：管理平面(Management Plane)、控制平面(Control Plane)、部署平面(Deployment Plane)[color=#F4B400]

## 帶外管理網路自動化的局限性問題
![螢幕擷取畫面 (327)](https://hackmd.io/_uploads/Sy1dCcPFp.png)

現代的網路架構中，（上圖紅色框框）虛擬化基礎設施管理 (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 累...~

### 參考資料
* [O-RAN.WG1.OAD-R003-v08.00](https://drive.google.com/file/d/1d93kpSnRHMeSqn7tytI3MpG9Pewma7JH/view)
* [O-RAN.WG6.O2-GA&P-R003-v04.00](https://docs.google.com/document/d/1yhXBwQhdvtCS_-4NmE3guxdSN0npV-Kl/edit?usp=drive_link&ouid=110128176878908257953&rtpof=true&sd=true)

### 作者聯絡資訊
* hctsai@linux.com
* hctsai1006@cs.nctu.edu.tw
* https://www.facebook.com/thc1006