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 的成本都會變得非常高昂。 用熱力學的概念來總結的話，就是說，想用 He

電信產業如何應用生成式 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 Network Planning（網路規劃）和部署的過程中，如何使用 TE&IV 服務供應商提供的批次上傳服務。 透過 Network Planning（網路規劃），使得 CSP（雲端服務供應商）能有效地設計、管理和最佳化網路。此外，進行 Network Planning 和 Network Design 的目的，也是為了確保新（世代）的電信網路，能以最佳效益來運行，並有足夠的網路容量和可靠性，以滿足用戶和營運商(operator)的需求。 隨著用於部署的雲原生技術（如：容器化、微服務）高速發展，網路規劃、設計、部署到實現的開發週期已經大大縮短。 庫存(Inventory) 會透過儲存和提供有關 Network Planning 的資訊，來支援Network Planning 的流程。TE&IV 服務[註1] 可將網路資料批次上傳至庫存(Inventory)，從而簡化大規模規劃和部署網路的過程。 [註1] TE&IV 服務(Topology Exposure and Inventory Management)：代表測試、評估和整合性的驗證。主要用於將新網路技術和服務部署到生產環境之前，對其進行測試、評估和驗證的流程。TE&IV 是網路生命週期管理流程的重要環節，因為它有助於確保新技術和服務能夠滿足用戶的需求，並確保它們能與現有網路基礎設施無縫整合。 備註：用於批次上傳至庫存(Inventory)資料的檔案格式，取決於通用拓撲結構和 Inventory Model，這部分本規範沒有涉及。 本用例涉及的實體(Entities)/資源(Resource) SMO Framework：用於支援 PNFs 的部屬。 OAM Functions：用於管理 NF 的配置(Provisioning of NFs)，和庫存物件[註2]的狀態。 NFO：用來與 O-Cloud 進行互動，執行 NF 的生命週期管理(LCM)。 TE&IV Service Producer：可批次上傳庫存中的 Data。 O-Cloud：與 SMO 進行互動，以佈署 NFs。 [註2] 庫存物件，所謂 O-RAN 的庫存物件，大致可分為兩大類： 實體庫存物件：包括基站、無線射頻天線等…硬體組件。 邏輯清單物件：包括虛擬網路功能 (VNF

SDR Platform 指的是用來實現軟體無線電（Software Defined Radio，SDR）的硬體和軟體系統，SDR Platform 可以用來實現各種衛星的操作功能，（如：遙測接收、遙控指令傳輸和頻譜監測...）總而言之 SDR Platform 是一種靈活、高效益的衛星與地面接收站通訊的解決方案。 而軟體無線電(SDR) 呢，它是一種使用軟體來控制 RF 訊號處理的無線電。它比傳統無線電靈活度還要高，並且適應性更強，因為通常傳統無線電都是為了連接特定頻率，或是特定調製方案(modulation scheme)的來專門進行設計的。 以下簡介通用無線電系統的硬體設備及其職責： 通用無線電系統的 Physical Layer 處理和硬體設備示意圖 資料來源：A Software-Defined Baseband for Satellite Ground Operations 上圖最左邊橘色的部分，即是無線電系統前端的接收天線。無論你是用 Phased array、Control Plane Receiver 或是 User plane Receiver 一旦接收衛星通訊訊號之後，必然需要再進行後端處理，讓衛星訊號得以轉換成地面行動通訊訊號以供使用。 由於不同軌道的衛星會使用不同的通訊頻段（如：X, S, Ka, Ku band ...），所以傳統無線電系統的設計方式，會依據不同的頻段來設計 專門的接收器 、專門的 Up/Down Converter ，甚至可以說專為特定頻段 專門 設計了整套無線電系統 。 地面接收站接收到特定頻段之後，就會需要進行降頻處理，藉由將高頻的衛星通訊訊號降到中頻或是基頻，最後再經過基頻的系統處理，（上圖右邊藍色部分）將訊號轉換成 OSI 第三層（TCP/IP的網路層） 的 IP，後端就可以透過像是 Gateway 等設備，再介接電信基站、Wi-Fi Router、乙太網路，以供使用！ 基於硬體 的衛星地面接收站整體運行的架構圖 資料來源：A Software-Defined Baseband for Satellite Ground Operations 像這類傳統基於硬體的衛星地面接收站，就會需要針對不同的衛星頻段（如：X band, S band ）來設計不同硬體和處理方式，雖然它看起來是一套系統，但是其實整合度不是很好，

隨著新世代行動通訊技術標準的不斷更新，為了追求更高的網路速度、更大的網路容量，適應更複雜的使用場景，同時還須兼顧設備成本、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 的

O-RAN 架構由哪些組件組成？ (What components makes up the O-RAN architecture?) Ans: SMO、Non-RT RIC、Near-RT RIC、O-CU-CP、O-CU-UP、O-DU、O-RU、eNB、O-cloud OAM 功能的管理服務是什麼？ (What are the Management Services of OAM function?) Ans: FCAPS Management OAM 功能有哪些特點？ (What are the Management features of OAM function?) 追蹤並快速識別發出警報通知的組件所在以及警報的內容 (Trace and quickly identify problems) 監控狀態(Monitoring Status) 自我修復(Self-healing) OAM function 連接哪些介面？ (Which interfaces are connected to the OAM function? ) O-Cloud: Via O2-IMS interface and O2-DMS interface O-RU: Via Open FH M-Plane interface. Other (Managed Elements；MEs): Via O1interface. 您認為 OAM 的哪些 feature/function 更重要？ 原因又是什麼呢？ (Do you think which feature/function of OAM is more important? And what is the reason?) Ans: Alarm notifications，因為它可以幫助服務供應商快速識別 O-RAN NF 發生了什麼問題。 搜尋開源平台（O-RAN SC 或 ONAP）是否可用於支援 OAM 功能？ (Survey the open-source platform (O-RAN SC or ONAP) is available for OAM function?) 是的，MANO(ONAP)、NMS（上述的管理與編排系統在 O-RAN 中稱為 SMO）支持 OAM OAM 與 SMO的交互workflow 示意圖