O-RAN 科普教育

隨著電信業務的演進與變革，網路功能（Network Function; NF）的需求日益增加，尤其是在雲端環境中運行的複雜網路功能負載的部署與管理，已成為電信業者面臨的重大挑戰。而 Nephio 作為一個針對 Kubernetes 的自動化平台，為解決這些挑戰提供了強大的技術支持和框架，成為現代電信業者應對複雜網路挑戰的重要技術基石。本篇文章將深入探討如何使用 Nephio 來管理這些複雜的Network Function （Workload），並逐步分析其在 Helm 支援及相關 SDK 研發方面的進展，幫助業界專家理解如何導入這些技術來有效地優化網路功能管理。 什麼是 Nephio？ Nephio 是一個專門用來執行基於 Kubernetes 的自動化管理工作的 Open source code 平台。其核心目標聚焦在三大領域： Infrastructure 的部署與管理 Workload 對 Infrastructure 需求的定義與滿足 Workload 本身的配置與管理 這些功能有助於簡化和優化電信業務中許多複雜的網路部署挑戰，使得各類網路功能能夠以更高的效率和靈活性運行。 在目前的 L2 和 L3 Network Function Deplotment 中，Nephio 主要支援 Free5GC 和 OpenAirInterface (OAI) 這兩個供應商，並透過社群共同定義的 CRD（Custom Resource Definition）來管理這些 Network Function 的部署過程。這些操作主要依賴 Kubernetes API 來達成自動化和標準化，從而使 Network Function 的管理變得更加方便和一致。 Nephio 不僅是一個自動化管理平台，更是一個具有可擴展性和靈活性的平台。它的開放性和兼容性使其可以整合各種不同的技術和工具，進一步提升電信業務的靈活性和效率。這使得 Nephio 成為在雲原生時代背景下，面對越來越複雜和多樣化的網路需求時，實現高效和標準化運營的一個關鍵解決方案。 為什麼要在 Nephio 中引入 Helm 的支援？ 在一年多前，Nephio 社群開始深入探討引入 Helm 支援的必要性。雖然 Nephio 本身試圖超越 Helm 的限制，探索更具彈性和強大的管理模式，但最終確定支援 Helm 的決策基...

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

本用例主要說明在 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 示意圖...

由於在 O-RAN 架構中 Traffic Steering(TS) 的實現主要交由 RIC 來處理，本文將簡介 O-RAN 負責實施 Traffic Steering 的網路功能元件們，它們的職權有什麼？ O-RAN Traffic Steering xApp 簡介 Traffic Steering(TS) xApp 是部屬於 O-RAN RIC 平台上的應用程式。電信業者會使用 TS xApp 來引導流量，並且優化其服務的終端裝置(UE)在跨不同網路環境移動時的換手，但並非僅需考量基地台間的換手，同時也要考慮 NAT （如：4G,EN-DC NSA,5G）以及接入的頻段和載波，藉由讓 UE 或是網路切片組，能接入最合適的網路，來提高網路使用效率，並確保終端用戶通訊品質，總而來說，下世代通訊的 TS 設計已然成為一項挑戰。 > 電信業者對於特定類型的用戶終端，會有不同的無線電資源分配策略 Traffic Steering 操作時主要涉入的網路功能元件 執行 TS 時主要涉入的網路功能元件（實體） TS 相關網路功能組件工作職權 Non-RT RIC 制定策略指導 ：Non-RT RIC 提供一種聲明式策略，用於指導 Near-RT RIC 中的 TS xApp 及相關 xApps。（舉例：提供一種優化策略，引導基站的載波/頻段的服務特定 UE 或網路切片）。 資料雙向協調 ：提供 Near-RT RIC  豐富資料(Enrichment Information) ，用以輔助 TS 功能，同時也將測量配置參數傳輸給 RAN node。 （豐富資料：基於 UE 測量報告  Measurement Report(MR)  的  RF fingerprints ，像是正在服務中的Cell / 相鄰 Cell，它們的 RSRP/RSRQ/CQI 資訊。） 看不懂的專有名詞這邊有介紹： https://hackmd.io/@thc1006/B1pLKMAUh Near-RT RIC 解譯並執行 Non-RT RIC 傳來的策略。 使用 Non-RT RIC 提供的豐富資料，來優化 TS 和 其他 xApps 控制功能。 E2-Node 收集 E2 node 上 (O-eNB、O-CU、O-DU) 的細粒度資料，並藉由 O1 介面傳輸...