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 (編排/協調)當中，保護異質分散網...

Google Distributed Cloud (GDC) 助力企業 AI 應用與數位轉型 在過去，企業多半會將應用服務架設在 公有雲(Public Cloud Region) 上來運行，因為那邊有最多的計算資源、最強的資訊處理能力。 而近年來，產業積極導入各種 AI 應用，期望藉此實現數位轉型，並創造更多價值；隨著企業加速導入 AI 應用，對於伺服器（計算資源）彈性部署(低延遲) 的需求也逐漸浮現。因此，公有雲無法協助產業解決所有問題，因為除了 彈性部署(低延遲) 的需求之外，如產業需要處理敏感/機密資料，就還需要 注意關於 數位主權 在地合規 等…的法規限制 。 我國關於 資料在地化 的法規 就有像是： 個人資料保護法 電子支付機構業務管理規則 人體生物資料庫管理條例 醫療機構電子病歷製作及管理辦法 所以為了因應這些需求及挑戰，Google Cloud 推出了硬體+軟體的解決方案組合叫做： Google Distributed Cloud (GDC)  這次 Google I/O Extended Kaohsiung 2024 的演講，主要介紹 GDC 引入了哪些 Google I/O 2024 提及的新技術，以及 Google Cloud Next '24 關於 GDC 的更新。讓我們在此快速回顧一下今天演講內容吧！ 這次 GDC 的升級，就是專為佈署 AI 應用來設計，讓 GDC 支援了 NVIDIA GPU ，並提供兩種佈署選項： 在邊緣端、Air Gap(斷網)端，使用 NVIDIA L4 GPU（高能源效率） 在資料中心、營運端，使用 NVIDIA H100 GPU（高效能） 除此之外， GDC 也搭載了 GKE Enterprise ， 支援 SR-IOV、多網路(Multiple Networking) 。上述功能除了能優化應用的網路效能之外，也提高了應用的可擴展性和故障冗餘(redundancy)。 在 GDC 的 PaaS Stack， 大家最期待的 VectorDB, Vector Search 功能，在 GDC 上面也都支援了 （VectorDB 使用 Google 自家 AlloyDB）。 除此之外，GDC 也支援了 Dataproc ，讓企業可以進行 大規模數據 的管理/處理。現在 GDC 提供了各式各樣的管理服務，我們已經不...

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

 Kubernetes 是一個 自動化部署、擴展、管理應用程式的平台。 本文與 GDSC 計畫合作， 介紹  Kubernetes (K8S) 元件及原理。 3大優點介紹 同時部署多個容器到多台機器上（Deployment）。 服務的乘載量有變化時，可以對容器做自動擴展（Scaling）。 管理多個容器的狀態，自動偵測情況，若失效或錯誤，及重啟故障的容器 (self-healing) 。 Kubernetes 架構基礎元件介紹 Cluster -集群 多個 Worker 與 Master 的集合在一起的的組件 Master Node -Master 節點 運作的指揮中心 管理所有其他 Node Worker Node -worker 節點  運作的最小硬體單位 硬體資源的提供者  可以是 實體機器 或 虛擬機 Pod Kubernetes 當中最小的組件單元 可以有一個或是多個 Container，但通常都只有一個 同一個 Pod 中 Containers 共享資源及網路 Kubernetes 他管理著一系列的主機或伺服器(Worker Node)，，Node 當中有各自獨立運作的Pod。 Pod 的功能要比喻的話，可以說成是 container 的集合，這些 container 將一個 Pod 的應用 build 起來。 （例如：今天有一個網頁應用服務，我這個 Pod 應用中可能會需要哪些功能的  comtainer） 這麼多的 Pod ,Node，就會需要一個 coordinator （協調員）的角色來負責，調度、負載均衡，或是失效後重建，使服務能夠穩定運行。 這個協調員就叫做 Master Node，Master Node 透過與 Worker Node 上的 API 通道進行通訊，並藉由 API 即時監控 Node 及 Pod 的資源使用狀況 (satus)。 當 Pod 失效、崩潰時，負責重建的 Pod ，我們稱之為 Replica Set （副本集），他們是重要的功臣，就像伺服器上的乖乖一樣，讓我們的應用程式能夠長久且穩定的運行。 下圖展示 Kubernetes Architecture  上方紅色框框即為 協調工作的Master Node Kubernetes Architecture （整個黑...