電信產業如何透過 Nephio 來處理複雜的 Network Function（Workload）？

隨著電信業務的演進與變革，網路功能（Network Function; NF）的需求日益增加，尤其是在雲端環境中運行的複雜網路功能負載的部署與管理，已成為電信業者面臨的重大挑戰。而 Nephio 作為一個針對 Kubernetes 的自動化平台，為解決這些挑戰提供了強大的技術支持和框架，成為現代電信業者應對複雜網路挑戰的重要技術基石。本篇文章將深入探討如何使用 Nephio 來管理這些複雜的Network Function （Workload），並逐步分析其在 Helm 支援及相關 SDK 研發方面的進展，幫助業界專家理解如何導入這些技術來有效地優化網路功能管理。

什麼是 Nephio？

Nephio 是一個專門用來執行基於 Kubernetes 的自動化管理工作的 Open source code 平台。其核心目標聚焦在三大領域：

  1. Infrastructure 的部署與管理
  2. Workload 對 Infrastructure 需求的定義與滿足
  3. 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 的決策基於兩個主要原因：

  1. 普及性與成熟度：Helm 作為 Kubernetes 生態系統中的重要 Component，已經存在相當長一段時間，並且是一個穩定且成熟的專案。目前的 Helm 版本為第三版，於四年前發佈，經過多年發展已成為行業標準工具之一。據估計，大約 90% 的 Kubernetes  Workload 都是透過 Helm 來部署的（雖然此數據缺乏確切來源，但其普及性毋庸置疑）。對於 Ericsson 等主要電信供應商，Helm 早已成為內部主要的部署工具之一。
  2. 複雜性與過渡性：Helm 的使用帶來了一定的複雜性，特別是 Helm hooks 的存在，使其具有很多命令式的特徵，增加了操作的複雜度。此外，Nephio 的 KRM（Kubernetes Resource Model）模型目前仍處於發展和完善階段，對於開發者來說，撰寫操作器（operator）來管理 Workload 仍是一項具挑戰性的任務。因此，在現有 Helm 負載和 KRM 負載共存的過渡期，支援 Helm 顯得尤為重要，這樣可以在最大程度上減少 migration 過程中的摩擦，確保生產環境的穩定性與連續性。

此外，Helm 的普及性也使得引入 Helm 支援成為必要的一步，這不僅能夠利用現有的 Helm 知識和工具，還可以促進 Helm 使用者無縫過渡到 Nephio 的自動化管理系統。Helm  Chart的豐富性及其在部署應用程式邏輯方面的靈活性，使得它成為一個不可或缺的工具，這也是 Nephio 決定支持 Helm 的一個重要考量。

Helm 支援的實施方法

在 Nephio 中，Helm 的支援可以透過兩種主要方式來實現：

  1. Flux Helm Release Operator：Nephio 採用了 Flux 的 Helm Release Operator 來部署 Helm  Workload 。Flux 作為 GitOps 引擎的一部分，支援原生的 Helm 客戶端 SDK，這意味著所有 Helm  Chart能夠直接通過原生方式進行部署，避免了其他引擎將 Helm  Chart轉換為 KRM 再使用 Kubernetes API 部署的繁瑣步驟。這樣的方式保留了 Helm 的靈活性和原生特性，使得部署更符合實際需求。
  2. Helm 到操作器的代碼生成 SDK：另一種實現方式是透過 SDK 將 Helm  Chart 轉換為操作器代碼，從而快速進入操作器的開發世界。這種方法的優勢在於可以快速進入 Nephio 生態系統，使開發者能夠更直接地參與到自動化管理中。然而，這樣的過程也存在一定的挑戰，因為開發者需要自行處理部分 Helm  Chart 的轉換工作，這在複雜場景中可能需要投入較多的精力。

這兩種實施方法各有優勢，Flux Helm Release Operator 使得 Helm  Workload 的部署更加簡便和自動化，而 Helm 到操作器的代碼生成則為開發者提供了一個通過 Helm 快速進入 Nephio 自動化管理世界的途徑。這樣的雙管齊下策略，不僅提高了 Workload 的部署效率，還為未來向更高階段的自動化和標準化過渡奠定了基礎。

Ericsson 的實驗性研究與實踐

Ericsson 目前正在進行一系列技術領導性的研究，旨在探討如何將 Nephio 用於 Ericsson 現有 Workload 的部署，並最大化其效益。首先，Ericsson 使用 Flux 和 Helm 的集成方式進行了一些實驗性部署，並取得了一些初步的成功經驗。這些經驗已經通過 PR 或 GitHub 上的 ticket 進行了記錄，以便在社群中共享和改進。

除此之外，Ericsson 還開發了一個 CRD operator，將 Helm 的交互邏輯嵌入 operator 中，僅對最終用戶 expose KRM，以簡化部署的使用體驗。這種方式旨在降低用戶的技術門檻，使其在進行 Workload 部署時不必直接面對 Helm 的複雜性。此外，Ericsson 也在積極探索進一步超越 Helm 的 Nephio 原生方法，以期實現更高的自動化和標準化。

這些實驗性研究的目的是通過不斷的技術迭代，發現 Nephio 在實際應用中的挑戰和機遇，並通過不斷調整來使其更加完善。Ericsson 期望通過這些實驗，能夠更好地指導未來 Nephio 的發展方向，並幫助電信行業有效地應用這一自動化平台來提升網路功能的管理能力。

5G 核心 Workload 的案例


在具體應用中，Ericsson 使用 Nephio 成功部署了三個 5G 核心元件：

  • NRF（網路註冊功能）
  • NSSF（網路切片選擇功能）
  • DNS 伺服器

這些 Workload 作為 Cloud Native Applications 進行部署，並使用 Helm 作為 Deployment engine，通過 Helm  Chart 的靈活性來達成對各類元件的高效管理。在這些部署過程中，Ericsson 使用了三個主要的 Helm Chart：

  • CRD Helm Chart：用於部署 CRD，這是 Workload 運行的基礎結構。
  • 服務網格（Service Mesh） Helm  Chart：負責部署服務網格（Service Mesh），以保證各元件之間的網路互通性和安全性。
  • 應用程式邏輯 Helm  Chart：負責部署核心商業功能，以及與此相關的其他微服務。

這些部署透過 Nephio 的自定義操作器與 Porch 的協作進行管理，並將 Helm  Chart的部署自動化，從而實現最終用戶僅需與 KRM 互動的簡化部署體驗。這不僅提升了部署的效率，也降低了使用者在操作過程中的技術負擔。

此 use case 展示了 Nephio 在實際運行環境中的強大能力，以及其在支援複雜 Workload 時的靈活性和可擴展性。對於 5G 這樣需要高度靈活性的網路功能來說，Nephio 能夠提供一個穩定而有效的部署與管理方式，讓網路功能的運營更為高效。

未來發展與 SDK 研發

Nephio 社群目前正積極開發一套 SDK，以支持網路功能供應商的網路功能快速導入，特別是在 L3 階段的 Helm 導入。這套 SDK 的核心概念是透過簡化的 CLI packaging tool，使供應商能夠迅速生成 gRPC 伺服器，並與 Nephio 生態系統無縫對接，從而實現更高效的網路功能管理。

在未來，這套 SDK 將進一步引入更多自動化工具，例如自動生成模板功能，幫助供應商在不需要手動編寫代碼的情況下完成 CR 的轉換與部署。此外，SDK 也計畫支持第二天（Day 2）的運維需求，包括導入 OpenTelemetry 來提升整體系統的可觀測性和監控能力。這將有助於網路功能在運行過程中的持續優化與改進，確保其穩定性和效能。

另外，社群也計劃在 SDK 中加入更多模板化的支持，這些模板將涵蓋從網路功能部署到運維的各個方面，旨在提供更完整的解決方案。透過這些模板，供應商可以更快速地完成複雜網路場景的自動化配置，從而降低技術開發成本，縮短部署週期。

除此之外，SDK 研發還將專注於增強網路功能的觀察性和管理性。OpenTelemetry 的導入將使得電信業者能夠更好地觀察網路功能的運行狀態，及時發現和解決問題，並提供關鍵的性能數據，這些數據對於優化網路功能的運行至關重要。

結論

Nephio 在電信業中的應用代表著一種新型的網路功能管理方式，特別是在 Kubernetes 和 Helm 的結合應用中展現出其獨特的價值。雖然 Helm 目前仍是大多數 Workload 的主要部署工具，但 Nephio 逐步引入的 KRM 模型及其相關 SDK 則讓我們看到了未來更為標準化與自動化的管理方向。Nephio 的引入與 Helm 的融合，不僅增強了網路功能的靈活性與可擴展性，也為未來的網路管理奠定了更加穩固的基礎。

對於電信業者而言，Nephio 的最大價值在於其能夠大幅簡化複雜的網路功能管理流程，減少手動干預，並提升自動化程度，從而有效地降低運營成本。同時，Nephio 的標準化特性也讓不同供應商的 Workload 之間的互通性變得更為簡便，這對於實現跨供應商的網路協作具有重要意義。隨著 Nephio 生態系統的不斷成熟，我們可以預期它將成為未來網路功能部署與管理的重要工具，幫助電信業者達成高效能、高穩定性的網路運營，並推動整個行業的技術進步與創新。

此外，Nephio 的發展還具有更廣泛的前景。隨著 5G 和未來 6G 網路的普及，網路功能的複雜性與需求量將進一步增加，這對於自動化管理提出了更高的要求。Nephio 的自動化能力和擴展性使其能夠應對這些挑戰，並在網路技術的未來演進中扮演至關重要的角色。無論是針對現有網路的升級，還是面對新技術的引入，Nephio 都能為電信業者提供一個穩健而靈活的平台，從而推動網路 Infrastructure 的現代化與智能化。

隨著 Nephio 和相關 SDK 工具的不斷發展，電信業者將能夠更好地應對網路環境中的各種挑戰，從而提供更優質、更穩定的服務。這些技術不僅能夠降低部署和運營的成本，還能夠顯著提升網路功能的運營效率，並為未來的技術創新和發展奠定基礎。通過有效應用 Nephio，電信業者能夠在面對日益激烈的市場競爭時，保持技術領先地位，並持續為客戶提供更高品質的網路服務。

位置： 30010台灣新竹市東區大學路1001號

留言

張貼留言

這個網誌中的熱門文章

生成式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...
閱讀完整內容