O-RAN 科普教育

本文所要表達的「從邊緣端到雲端的 Orchestration (編排/協調) 挑戰」，意思是在 協調邊緣端設備與雲端平台（基礎建設）之間的資料與服務時，所會面臨到的各種挑戰！ 請注意這個 "挑戰" 是雙向的~ 資料同步與資料一致性的挑戰 在協調邊緣端到雲端的過程中，確保資料的同步並維持分散式系統之間的資料一致性，是一項艱鉅的挑戰！因為 Data 的生成通常來自於多個不同的邊緣位置，而且邊緣裝置可能會將 Data 進行初步處理，而後送到雲端進行聚合或分析，所以可能會出現「資料不一致、資料衝突甚至資料遺失（丟包）」等......的風險。 如果邊緣端的資料與雲端的不同步，對於時間敏感的應用來說，可能導致其根據過時或不完整資訊的來進行決策。此外，由於邊緣裝置的工作環境各不相同，且連線狀況各異，因此確保所有資料的變更在整套系統當中統一反映，保證不重複也不遺漏，就成為了一項複雜的任務，需要強大的同步協議和細致的資料管理策略。 針對異質設備和網路的協調挑戰 從邊緣端到雲端的 Orchestration (編排/協調) 挑戰，其中最複雜莫過於是管理各種各樣的邊緣設備和平台。打個比方（如：智慧家電、穿戴式裝置、工業感測器和自動駕駛汽車）這四個設備，就特性上，我們也許會認為其中有幾個會採用相同的通訊協定或是架構。 但就實際應用上，可能因為數位主權、在地合規、成本考量等......因素，導致它們採用的是完全不同的通訊協定（僅支援特定的網路切片組，如：LTE-M, 3GPP R15 mMTC, R17 的 redcap, etc,.）和不同的架構和作業系統。因此要整合和協調這樣一個異質的設備和網路環境，就必須深入了解每種裝置之間的細微差別，並有能力建立統一的介面來實現無縫通訊。 在這個多樣化的生態系統當中，要確保軟體更新、安全性修補程式和效能最佳化都能保持一致，也是一項巨大ㄉ Day 2 挑戰！隨著邊緣設備的數量和種類不斷增加，開發標準化的方法和工具來統一進行管理，已成為從邊緣端到雲端的 Orchestration (編排/協調) 的成功關鍵。 當然，針對異質設備和網路的問題，如果要解決的問題是整體管理的決策優化，則可以往開發新的聯邦學習演算法來解決！ 面對分散的邊緣到雲端環境中的安全問題 從邊緣端到雲端的 Orchestration (編排/協調)當中，保護異質分散網

本文整理並逐一說明目前電信產業雲原生轉型，可能會面臨到的眾多挑戰，此外，說明為何電信產業已經引入了雲原生技術，卻仍舊無法真正地享受到雲原生轉型所帶來的各項好處。期望鼓勵更多莘莘學子投入 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

隨著新世代行動通訊技術標準的不斷更新，為了追求更高的網路速度、更大的網路容量，適應更複雜的使用場景，同時還須兼顧設備成本、APRU 和敏捷性管理，電信網路架構的演進，引入了DevOps 概念。一路從 核心網路 (Core Network；CN) 開始著手，緊接著是 無線電接取網路(Radio Access Network；RAN)，開始了一連串的開放原始碼、虛擬化，甚至是全雲原生 (Cloud-Native) 的遷移之旅。 電信網路產業朝向全雲原生的轉型已經開始（圖源：自製） 開放式無線電接取網路 (O-RAN) 的出現，驅動下世代行動通訊技術的高速發展，藉由其標準化的開放介面、新增支援 AI/ML Workflow 的 RAN 智慧控制器 (RIC) 、支援雲原生網路功能的部屬等…創新技術，為下世代電信網路管理帶來了新的機會，有望翻轉傳統電信生態圈。而其中「支援雲原生網路功能部屬」，也意味著 Cloud RAN 時代即將來臨，雲原生網路功能 (CNF) 儼然成為一種趨勢。 雲原生網路功能(CNF) 部屬帶來許多新機會的同時，也意味著我們也即將面臨新的電信資安挑戰。過去面對IT與OT的資安攻防，好厲駭學員早已做好備戰準備，但是現在新型態 CT (Communication Technology) 通訊資安的挑戰即將來臨，試問台灣好厲駭學員該如何處置，就讓我們接著看下去！ 雲原生技術帶來的優點與資安威脅 近年來，雲原生技術的應用逐漸興起，不僅帶動了產業界的發展，雲轉型的概念也衍生了許多的商業機會，許多產業界紛紛投入大把資金，期望藉由引入雲原生技術以俾產業轉型順利，雲原生已然成為一股潮流! 承如前段提及，電信網路功能往 Cloud-Native 的過渡已經開始，那麼網路功能在雲原生的過程，勢必會面臨一些既存的 虛擬化/雲原生 資安威脅。 因此本專題海報將針對於 O-RAN O-Cloud 以及部屬在其上面的雲原生網路功能(CNF)，可能會遇到的 Migration Attacks 資安威脅進行說明，並提出可能的解決方案。 O-RAN簡介 O-RAN 功能簡介（高級架構圖）圖源：自製 （由於網路功能雲原生已成趨勢，因此後段提及的NF已全部視為CNF） 首先進行 O-RAN 的簡介 SMO 會透過 O1介面進行 NFs 的配置管理，同時透過 O1 介面獲得來自 NFs 的