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 累...~

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

聯絡資訊（蔡秀吉）

參考資料

位置： Olympijská 1901/7, 169 00 Praha 6-Břevnov, 捷克

留言

張貼留言

這個網誌中的熱門文章

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

圖片
電信產業如何應用生成式 AI？ 究竟電信產業該如何引入生成式 AI (Generative AI)，來解決業界長久以來的痛點呢？秀吉現在就報給你知！ 前言 這個學年來捷克訪問，無法實體參與  Google Cloud Summit Taipei ，但身為國外的 GDSC Lead ，進修和教學還是責無旁貸，畢竟人生的樂趣在學習，人生的收穫在於奉獻 www 所以就忙裡偷閒在國外補檔一下  Google Cloud Summit Taipei | (中華電信)解析 Next’23 最新雲端技術 ；可能是因為主題安排或是時間關係，這場演講比較像是產品成果發表，技術偏少。 但沒關係，本篇文章將科普電信業引入生成式 AI 的魅力在哪？，同時針對演講中提到的 Data Cloud 服務應用與挑戰 做進一步的說明和科普。 簡而言之，這是一篇科普文，所以即使你沒聽過演講也看得懂 （廢話結束，以下正文） 電信產業如何應用生成式 AI 電信產業究竟如何應用生成式 AI，主要可以分成兩大使用範例(Use Cases)： Customer Automation （用戶自動化） Network Automation （網路自動化） 一般人經常使用到的生成式 AI，大多都是 大型語言模型 (Large language model；LLM) ，那麼隨著越來越多人的使用和媒體的炒作，民眾對生成式 AI 衍生服務的接受度也將逐漸增加，而這點對於電信業者來說，是個非常好的機會，為什麼我會這樣說呢？讓我們繼續看下去！ Customer Automation（用戶自動化） 對於絕大部分天然呆的台灣用戶來說：「電信供應商的好壞，在於客戶服務！」 所以只要將客服的體驗優化好，萬事皆好談！ 以中華電信為例，它擁有全台 90% 的固網業務以及 1300萬個門號用戶；對於一間擁有如此龐大用戶的電信業者，最重要的就是導入生成式 AI（如：語音辨識模型、對話模型），用來實現 用戶自動化(Customer Automation) ，和以下目標： 更快解決客戶遇到的問題 減少客服中心收到的來電 確保電信業真的有善用自家強大的科技技術，實現用戶個人化的電信服務 所以台灣四大電信業者正面臨一個龐大的機會，透過導入生成式 AI 實現用戶自動化，即可徹底改變現狀（例如：使用機器學習來分析客訴情況的描...
閱讀完整內容

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

圖片
我國數位發展部的核心理念，即為「強化全民數位韌性」 摘要： 數位發展與全體國民的日常生活息息相關，我國數位發展部（以下簡稱數位部）成立的核心理念，即是為了 「強化全民數位韌性」 ，可是瑞凡 「數位韌性」 這個詞，對於全體民眾而言，似乎還太過遙遠，多數民眾對數位發展仍缺乏概念，也不了解數位到底如何發展？這乃是數位發展政策執行面上長久以來的痛點，因此，為了以俾日後社會全面數位化發展順利， 數位發展專有名詞 的 科學普及教育 實為勢在必行。 本篇文章以民眾日常生活中一定會接觸到的 行動通訊基地台 為題，並針對於我國數位發展的最新應用技術  O-RAN  來進行科普介紹，帶領讀者了解什麼是  O-RAN ？以及數位部是如何 應用  O-RAN 強化我國數位韌性 ，實現「科技島」願景，就讓我們接著看下去吧 ~ 前言： 行動通訊的高速演進，促進社會朝向全面數位化發展，現代人的生活無論求學、工作、娛樂，都早已離不開行動通訊，但當你在享受數位發展帶來生活便利的同時，有沒有想過數位發展究竟是透過什麼樣的工具來實現。本文將會分為三個部分進行科普，首先簡介行動通訊概論及其演進歷史，而後帶領讀者了解為 促進我國數位發展、強化數位韌性 背後的重要功臣「 O-RAN 」究竟是什麼，以及為何我們需要  O-RAN ？最後說明  O-RAN 強化我國數位韌性的應用案例 。 行動通訊概論及其演進歷史簡介： 在了解什麼是  O-RAN  之前，我們先來了解什麼叫做 (RAN ， Radio Access Network) 。 所謂的  RAN  就是 「無線電接取網路」，聽到這個專有名詞，大家可能還是很模糊。 我們換成另一個日常生活稱呼 「基地台」 ，大家應該就比較耳熟能詳，而就是  RAN  它發出了 4G 、 5G 的無線電訊號（如：手機、智慧手錶 等…）接收到訊號後，並與  RAN  互相收發訊號、交換資訊，就實現我們所謂的無線上網啦！ 圖(一) RAN 的基本架構，需包含 RU (射頻單元) 和 BBU (基帶單元)，才能組成完整的 RAN 「什麼是 O-RAN？敢是路邊攤个黑輪？這是啥可以吃嗎？」 讀者對於  RAN  有初步的瞭解...
閱讀完整內容

O-RAN Y1介面簡介

圖片
一句話介紹：這是 O-RAN 新增的介面(2023/03)，允許 Y1 consumers 訂閱或請求 Near-RT RIC 提供的 RAN 分析資訊 (RAN analytics information)。 圖(一) O-RAN Y1介面（圖中紅框處） O-RAN Y1介面功能介紹： Near-RT RIC 透過 Y1 介面，提供 RAN 分析資訊 (RAN analytics information) 的服務，而 Y1 consumers 可以藉由訂閱或請求 RAN 分析資訊 ，來使用 RAN 分析資訊 服務。 當 Y1 consumers 在 O-RAN 可信域 (Trusted Domain) 時，可以作為應用程式功能 (Application Functions，AFs)；或  RAN 分析資訊 可以透過網路曝光功能 (Network Exposure Function，NEF) 以安全的方式提供給 (Application Functions，AFs) 速記：在 O-RAN Trusted Domain 時 ， Y1 consumers == (Application Functions，AFs) 安全的網路曝光方式(NEF) 詳見：3GPP TS 23.501, Clause 5.20 (External Exposure of Network Capability)，連結如下： Release 17:  https://reurl.cc/ml7Y6W Release 16:  https://reurl.cc/7RnV2y 秀吉 MurMur： Y1 consumers  使用 RAN 分析資訊 服務，出發點一定是好的啦~，得以提供不同情境的使用者裝置更適合的服務，但 新介面的出現，同時也意味著新的資安威脅，學術界又有新的研究領域了（誤 綜觀 O-RAN 的高級架構 (High Level Architecture；HLA)   圖(一)： 圖(一) 顯示 O-RAN 架構中主要的四個介面 (A1、O1、Open Fronthaul M-plane、O2)。 SMO（服務管理和編排）透過 A1、O1、Open Fronthaul M-plane 連結 O-RAN Network Func...
閱讀完整內容