Nephio 驅動 5G 專網的智慧化 orchestration：從多廠商整合到雲原生自動化的未來展望

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 需要的是整合性單一管理介面 (Single Pane of Glass) 與統一管理方案，以便快速配置、監控、變更與優化整個網路環境。

在這樣的背景下，如果單純依賴傳統的 Telco MANO（Management and Orchestration）系統或單靠 Kubernetes 基本功能，都會有各自的不足。前者對企業端使用者而言過於複雜，缺乏雲原生靈活性；後者雖有彈性，但在大規模、多供應商的網路環境中缺少 GitOps 級別的版本控制、策略強制（Policy Enforcement）與閉環（Closed-loop）自動化管控能力。

二、Nephio 與 LFN 生態系：雲原生、多供應商、自動化的解方

面對上面的種種挑戰，Nephio 作為 Linux Foundation Networking 下的關鍵專案，提供了創新的概念：

  1. Kubernetes-based（將 Kubernetes 做為根本）：
    Nephio 將 5G 專網的編排和管理，視為 Kubernetes 平台上原生運行的 workload 的一部分或自然延伸。將傳統網路功能 (NF) 與 Application（如：邊緣運算）以雲原生方式封裝（變成 CNF），並透過 K8s 的 CRD（Custom Resource Definitions）將現實世界的 Business logic　 業務需求（可以把它想成是一種意圖）轉換成實際網路配置。如此一來，NF configuration 就不再需要出動大量人力，並且手動費時的去一一設定，而是透過宣告式配置（Declarative Configuration）自動將 config 推送到目標 cluster。

  2. Intent-driven 與 GitOps：
    延續上面所述，透過 Intent-based 模型，營運者只需定義 High level 的業務需求（例如：地點、Latency 的需求、是否具備邊緣應用），Nephio 便能透過一系列 KPT Functions 與 Controllers，自動將高階意圖轉換為底層技術參數（如：RAN、Core 功能的特定 Configration）。同時，所有的配置變更都會透過 GitOps 流程來進行管理；當業務需求的 Intent 改變時，系統自動偵測這些改變，並根據這些（新的意圖）的改變來更新相應的參數。接下來，運行在邊緣站點（edge site）的 Config Sync，就會進一步從 repository 中拉取（pull）配置，並將這些配置應用到 edge site，實現「所見即所宣告」，達成 NF automation 以及可追溯的配置 Lifecycle management。
    這邊 workflow 看不懂先別急著查，下面有補充實現這些流程的組件和工具
  3. 多叢集、跨供應商支援：
    Nephio 的應用不僅僅侷限於單一場域。Nephio 支援 Multi-cluster 與 multivendor，可以實現在 Nephio Central Cloud 放置 5GC 控制平面的網元（如：AMF、SMF），將 RAN 部署在 regional 或 edge cluster，並可再進一步依據需求將 UPF 往前移至邊緣端（可選擇部分放置於核心雲端，也可以移至邊緣），以滿足更嚴苛的延遲要求。這種彈性拓撲的組合完全建立在「changing intent」的基礎上，而非需要人工到實地進行繁瑣的作業。

  4. Closed-loop Automation與政策管控：
    Nephio 可結合 CNCF OPA（Open Policy Agent），實現閉環管控。系統可根據監控資料（例如：Kafka、Grafana 等資料收集與視覺化平台），自動觸發策略檢驗，若網路狀態不符預期，OPA 將驅動 Nephio 進行配置調整（Lifecycle Management Action），實現真正的「Zero touch」的動態優化。

  5. 整合 A&AI Inventory 與多重介面：
    來自 ONAP 的 A&AI（Active and Available Inventory）專案可提供資產與狀態的集中式存檔，加上 REST API、Python SDK、及自訂的 GUI 介面，讓網管人員不必在多個監控面板間來回切換。透過單一管理介面即可存取所有網路資源、功能與應用，達成真正的 Single Pane of Glass。

三、Nephio 架構解析：從高階 Intent 到技術細節的轉化流程

Kubernetes as a Uniform Automation Control Plane



Nephio 的核心架構可視為三大主軸」：
  1. 基礎設施編排 (Infra Orchestration)：不論是雲端 VM、Bare Metal 還是區域伺服器，Nephio 透過供應商或 API（如：Redfish）直接介入資源調度，以滿足網路功能的底層需求。基礎設施在被 Nephio 接管後，即成為受控資產，能夠自動因應上層 Intent 做出調配。
  2. 工作負載編排 (Workload Orchestration)：5G 專網不只部署網路功能，同時也需搭配邊緣應用。Nephio 可將 RAN、Core，以及任意雲原生應用（如邊緣電腦視覺）以 CRD 表達，並利用控制器自動將高階 Intent 轉為具體參數，分派至正確的叢集。
  3. 配置管理 (Configuration Management)：Day-0（初始部署）、Day-1（基本上線後調校）、Day-2（持續維運優化）的所有配置變更，皆透過 Nephio 的 Pipeline 與 GitOps 流程持續調和（Reconciliation）。這意味著當網路狀態發生偏移（drift），Nephio 能自動檢測並修正，確保網路狀態與定義的 Intent 同步。
Nephio High-Level Architecture

在這整個過程中，Nephio 的組成部件相對精簡：
  • KPT (package)：用來表達 intent 的 package，是一個以 package 為格式的 config unit，並由 Porch 進行管理。
  • Porch：管理「封裝 intent 的 KPT function」並負責版本管理。
  • KPT Functions 與 Operators：將 High intent 轉為可行的技術指令，包含 IPAM（IP 位址管理）等技術服務。
  • Config Sync：運行在 edge cluster 端，從 Git Repo pull configration 下來並套用。
  • Topology Controller、Package Variant Controller：分解網路拓撲意圖，將其解析成對應的特定功能組件配置。
這些組件共同組成一條從「業務的意圖」到「技術落地」的自動化 Pipeline。所以接下來我們就可以來簡述一下剛剛第二段提到的 Intent-driven、Closed-loop Automation 和 GitOps 的實現細節了。

舉例來說，所有 Configuration 的變更都會透過 GitOps 流程來進行管理；當 Intent 發生改變時，位在 edge site 的 Config Sync 就會負責將從 repository 發送的配置 pull 到 edge cluster (site)，以確保 edge cluster  (site) 的 config 始終是最新的。而這個過程使得 Config 可以被自動化地分發到多個站點，實現大規模的擴展（scalability）而上述的過程運用了 GitOps。

這時候可能就有小朋友要問啦！

  • 請問 GitOps 流程在哪裡？
    將「業務意圖」轉化為「技術意圖」，並將其（Configuration）儲存在 repository 中，接下來　會由 controller 和 Config Sync 將 Config 部署到 Edge cluster，實現 Configuration 的自動化與一致性。

  • 請問 Config Sync 是從哪個 repository pull Configuration 下來到 edge site 呢？而這個 repository 又位於哪裡呢？
    每個 Edge site 或 Workload Cluster 都會有指定的 Git Repo，該 Repo 作為其 config file 的來源。以 Edge cluster (site) 為例：首先會需要在 Edge cluster 內部署 Config Sync conponent，接下來會需要再安裝並且設置 RootSync，RootSync 會在 Edge cluster 中建立一個資源，指定包含：Configuration 的 Git repo URL、branch 和 directory，一切設定好之後 Config Sync 就可以 access Git repo 啦。而這個 Repository 可以是外部的（例如：GitHub 或 GitLab），也可是在 Nephio 內部，例如在 Nephio management cluster 當中部署像是 Gitea 這樣的自架 Git 服務，來管理 configuration repositories。

  • 有提到 將「業務意圖」轉化為「技術意圖」是透過 KPT 和 controller 來實現的，請問具體是如何實現的呢？|
    使用者會需要在 Repository 當中透過創建 `PackageVariant` 和 `PackageVariantSet` resources，它們是來定義 Intent（包含：configurations, transformations）。這時 Nephio 架構當中一個重要的 component 就需要派上用場了！這個 component 叫做 package variant controller，package variant controller 會去監視這些資源，當檢測到 Intent 變更或是有新定義時，就會對其進行處理（例如：進行補充（hydrate）或修改（mutate）），讓意圖適應具體需求，然後將其放回 Repository，而 Config Sync 也會偵測 repo 是否發生變更（異動），若有的話 Config Sync 即會將新的 Config pull 到 edge cluster  (site)。

四、實務案例：5G 專網雛形部署範例

假設你想在邊緣端部署 RAN 與 5G Core，同時在核心雲端保有控制功能。在 Nephio 架構下，只需定義一份簡化的高階 Intent（如：「RAN部署在邊緣叢集、Core 在核心叢集、延遲要求 XX ms、需要特定 Application …」），Nephio 便透過 Topology Controller 與各種 KPT Functions，將該意圖解析成各網元的具體配置檔案，並由 Config Sync 分發至目標 cluster。

過往，企業或 MSP 面對千餘項 RAN 參數、數百種核心網元設定，必須由專業人員手動調適。但有了 Nephio，多數複雜度由系統內置邏輯處理，最後給使用者的只是一個「六到十個參數的簡化表單」。同時，以 A&AI 將資產與狀態整理成清晰的圖譜（Graph），後續變更或問題排除也更加直觀。

透過結合 Kafka、Grafana 等工具，Nephio 能持續蒐集與分析實際運行數據，透過 OPA 閉環自動化政策，動態優化網路布署（例如更改 UPF 部署位置、調整 RAN 配置），讓 5G 專網能快速回應實際流量、用戶行為與應用需求變化。

五、展望與結論

面對未來 5G、6G 的網路世代，加上邊緣運算與雲原生服務的崛起，電信網路的部署與管理正在經歷根本性變革。Nephio 作為雲原生網路編排的關鍵專案，成功將 Intent、GitOps、Kubernetes、Policy Enforcement 與多供應商支援整合於一體，為5G 專網布建提供一個高彈性、高可擴充且可持續優化的技術架構。

未來，多家跨國電信供應商如 Google、Ericsson、Nokia、以及國內外雲端與網通大廠，將更積極採用此類解決方案，同時期待具有 GDPR 法規認知、雲原生技術與 AI 技能的人才加入，推動 6G AI-native Cloud RAN 的創新與落地。此一生態的發展意味著 5G 專網不僅可藉助 Nephio 取得自動化與彈性，更能因為閉環控制與政策導引走向真正的 AI 智慧化的網路時代。

簡而言之，Nephio 架構下的 5G 專網部署，不再是傳統電信工程師痛苦對接多家供應商系統的瑣事，而是一個以 Intent 為核心的自動化流程。對於正在尋求 5G 專網最佳實踐的研究員與雲原生工程師而言，Nephio 的崛起，正是開啟下一代電信雲原生領域的關鍵之鑰。

關於作者：

蔡秀吉，是就讀陽明交大ㄉ貓咪，目前技能樹點了：網路工程、SDN、開放電信網路（O-RAN）、外科、體外循環、腦科學、精神醫學、表觀遺傳、偏鄉教育、本土語言以及戲曲表演；基本上是個技能樹亂點的人生。

聯絡資訊：


位置： 112台灣台北市北投區男三舍

留言

張貼留言

這個網誌中的熱門文章

生成式AI將電信業推向新紀元

圖片
電信產業如何應用生成式 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 吧！| 科普教育

圖片
我國數位發展部的核心理念，即為「強化全民數位韌性」 摘要： 數位發展與全體國民的日常生活息息相關，我國數位發展部（以下簡稱數位部）成立的核心理念，即是為了 「強化全民數位韌性」 ，可是瑞凡 「數位韌性」 這個詞，對於全體民眾而言，似乎還太過遙遠，多數民眾對數位發展仍缺乏概念，也不了解數位到底如何發展？這乃是數位發展政策執行面上長久以來的痛點，因此，為了以俾日後社會全面數位化發展順利， 數位發展專有名詞 的 科學普及教育 實為勢在必行。 本篇文章以民眾日常生活中一定會接觸到的 行動通訊基地台 為題，並針對於我國數位發展的最新應用技術  O-RAN  來進行科普介紹，帶領讀者了解什麼是  O-RAN ？以及數位部是如何 應用  O-RAN 強化我國數位韌性 ，實現「科技島」願景，就讓我們接著看下去吧 ~ 前言： 行動通訊的高速演進，促進社會朝向全面數位化發展，現代人的生活無論求學、工作、娛樂，都早已離不開行動通訊，但當你在享受數位發展帶來生活便利的同時，有沒有想過數位發展究竟是透過什麼樣的工具來實現。本文將會分為三個部分進行科普，首先簡介行動通訊概論及其演進歷史，而後帶領讀者了解為 促進我國數位發展、強化數位韌性 背後的重要功臣「 O-RAN 」究竟是什麼，以及為何我們需要  O-RAN ？最後說明  O-RAN 強化我國數位韌性的應用案例 。 行動通訊概論及其演進歷史簡介： 在了解什麼是  O-RAN  之前，我們先來了解什麼叫做 (RAN ， Radio Access Network) 。 所謂的  RAN  就是 「無線電接取網路」，聽到這個專有名詞，大家可能還是很模糊。 我們換成另一個日常生活稱呼 「基地台」 ，大家應該就比較耳熟能詳，而就是  RAN  它發出了 4G 、 5G 的無線電訊號（如：手機、智慧手錶 等…）接收到訊號後，並與  RAN  互相收發訊號、交換資訊，就實現我們所謂的無線上網啦！ 圖(一) RAN 的基本架構，需包含 RU (射頻單元) 和 BBU (基帶單元)，才能組成完整的 RAN 「什麼是 O-RAN？敢是路邊攤个黑輪？這是啥可以吃嗎？」 讀者對於  RAN  有初步的瞭解...
閱讀完整內容

O-RAN Y1介面簡介

圖片
一句話介紹：這是 O-RAN 新增的介面(2023/03)，允許 Y1 consumers 訂閱或請求 Near-RT RIC 提供的 RAN 分析資訊 (RAN analytics information)。 圖(一) O-RAN Y1介面（圖中紅框處） O-RAN Y1介面功能介紹： Near-RT RIC 透過 Y1 介面，提供 RAN 分析資訊 (RAN analytics information) 的服務，而 Y1 consumers 可以藉由訂閱或請求 RAN 分析資訊 ，來使用 RAN 分析資訊 服務。 當 Y1 consumers 在 O-RAN 可信域 (Trusted Domain) 時，可以作為應用程式功能 (Application Functions，AFs)；或  RAN 分析資訊 可以透過網路曝光功能 (Network Exposure Function，NEF) 以安全的方式提供給 (Application Functions，AFs) 速記：在 O-RAN Trusted Domain 時 ， Y1 consumers == (Application Functions，AFs) 安全的網路曝光方式(NEF) 詳見：3GPP TS 23.501, Clause 5.20 (External Exposure of Network Capability)，連結如下： Release 17:  https://reurl.cc/ml7Y6W Release 16:  https://reurl.cc/7RnV2y 秀吉 MurMur： Y1 consumers  使用 RAN 分析資訊 服務，出發點一定是好的啦~，得以提供不同情境的使用者裝置更適合的服務，但 新介面的出現，同時也意味著新的資安威脅，學術界又有新的研究領域了（誤 綜觀 O-RAN 的高級架構 (High Level Architecture；HLA)   圖(一)： 圖(一) 顯示 O-RAN 架構中主要的四個介面 (A1、O1、Open Fronthaul M-plane、O2)。 SMO（服務管理和編排）透過 A1、O1、Open Fronthaul M-plane 連結 O-RAN Network Func...
閱讀完整內容