O-RAN雲原生自動化的發展與挑戰
![圖片](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhU4A1BV-vqAJGc9-lSy3IVqs8crWPZnKs-wXo4PFB_ltrtsx4bznDfN9iPdlT8oDON82AxQI-QQV5mQrxBpKMKWCKnBCAN-DLnPxqUSiaN08aLi9GEvhwPGusm1vP6NDCatFM5_fyE7hXZkZqmZ3N3isX4LgIRkcBkoFqLj7Jg5LiVP0q4SLBpTj9pN38/w640-h360/%E8%9E%A2%E5%B9%95%E6%93%B7%E5%8F%96%E7%95%AB%E9%9D%A2%20(325).png)
本文整理並逐一說明目前電信產業雲原生轉型,可能會面臨到的眾多挑戰,此外,說明為何電信產業已經引入了雲原生技術,卻仍舊無法真正地享受到雲原生轉型所帶來的各項好處。期望鼓勵更多莘莘學子投入 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 的成本都會變得非常高昂。 用熱力學的概念來總結的話,就是說,想用 He