O-RAN 科普教育

Nephio 驅動 5G 專網的智慧化 Orchestration 引言 2025 年即將到來！同時，行動通訊技術的演進也從未暫緩，目前正高速朝 6G 的技術演進中。除此之外，隨著政府大力推動數位轉型（我國也開放了 Band n79 供 5G 專網使用），現如今 5G 專用網路（Private 5G），逐漸成為企業、營運商與 MSP（Managed Service Provider），甚至是文創場域所關注的焦點。傳統電信網路的部署若採用單一供應商模式，往往缺乏彈性與成本優勢；而多供應商環境（Multi-vendor）雖帶來技術與功能上的多樣化，卻同時伴隨著 orchestration 與 management 上的挑戰。面對這些問題，業界正積極尋求一個能夠 統一自動化管理與編排 解決方案，讓網管人員能在 單一管理平台 下高效掌握整個 5G 專網生態系。 因此，本文將介紹 Linux Foundation Networking（LFN）旗下的重要專案 Nephio，並探討如何利用 Kubernetes、GitOps、Intent-based（意圖驅動）等雲原生技術，達成跨供應商、多集群、多元應用（包括網路功能與邊緣應用）的自動化部署、管理與維運。我們將結合技術背景、實務案例與生態系趨勢，讓從事 5G/6G 學研人員或電信產業工程師能夠「深入淺出」理解 5G 專網的未來運營方式。 一、5G 專網編排與管理的挑戰 在 5G 專網的網路設計中，我們必須同時面對多家供應商的軟硬體組件，包括： 異質性網路功能 (Heterogeneous NFs)： 如 RAN（無線接取網路）、5G Core、邊緣運算平台、防火牆、CPE（用戶端終端設備）甚至是特定的邊緣應用（如電腦視覺、VR/AR 裝置管理）。 多層次網路結構： 從核心雲端（Core Cloud）到區域資料中心（Regional Site），再延伸至邊緣端（Edge Site），每個層次都可能來自不同廠商、不同 Kubernetes cluster 或不同類型的底層基礎設施（實體伺服器、虛擬機、Bare Metal即服務、雲端虛擬機）。 多重管理系統： 各廠商經常都會使用自家的 EMS（Element Management System）與 GUI，但對營運管理者來說，維護多個獨立介面既費時也不直觀。企業或 MSP 需要的是...

隨著電信業務的演進與變革，網路功能（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 的決策基...

本文所要表達的「從邊緣端到雲端的 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 的 ...