發表文章

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 需要的是...
張貼留言
閱讀完整內容

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

圖片
隨著電信業務的演進與變革，網路功能（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 的決策基...
張貼留言
位置： 30010台灣新竹市東區大學路1001號
閱讀完整內容

全光網路 IOWN GF 架構是什麼？

圖片
IOWN Global Forum 架構的介紹 IOWN GF（全稱為：Innovative Optical and Wireless Network Global Forum）中文可以翻譯成 創新全光學和無線網路的全球論壇 。IOWN GF 這個全球論壇的目標，就是建立一個端到端的（end-to-end）計算與網路架構，而且這個架構 能夠支援各種 Data flows 和各種 Workloads 。如下圖（一）所示。 筆者在此給大家一個觀念，在網路領域中 Workload 絕大部分時間也可以被稱之為 Application 或是 Network Fuction (Depolyment)。 圖（一）：IOWN Global Forum Overall Architecture 所謂 開放全光網路 ，全名叫做 Open All-Photonics Network（可縮寫成：Open APN）是一種利用 光路徑（Optical Path） 直接連接端點（endpoints）的網路，能夠提供 高速、超高可靠性 及 低延遲 的連線服務。 在現今的網路系統中， 光路徑的實作是以分段的方式來運行(segment-by-segment) 的 。講白話一點就是：現今從核心網路到終端設備之間傳輸的這條鏈路，在實作上會被分成好幾個網段，而且每一個網段都是各自獨立運作。例如：區域網路（LAN）、接取網路（Access Network）和 inter-data-center network，這裡每一段都需要分開實作和管理。 相比之下，本篇的主角 IOWN GF 的 Open APN 技術 ，其目標就是實現 「僅靠單一個光路徑，貫穿所有（多個）網段」。就好像讓一條高速公路，從你家車庫門口（用戶終端）直接通到目的地（資料中心）一樣。 這樣可以使端到端（E2E）的通訊有一定的品質保障，同時也讓 E2E 的通訊品質具備可預測性。另一方面，這當然也會需要對 E2E 的光路徑管理進行更動態（dynamic control）和更細緻的細粒度控制（granular control）。除此之外，由於光路徑是動態建立的（因此在建立之前，我們很難去準確預測所需的網路效能(需求)，因為需求會根據即時的網路使用狀況和用戶的行為而產生變化）所以咧！我們會需要一個能夠 real-time 測量和監控效能的機制，讓...
張貼留言
位置： 112台灣台北市北投區立農街二段155號
閱讀完整內容

從邊緣端到雲端的 Orchestration (編排/協調) 挑戰

本文所要表達的「從邊緣端到雲端的 Orchestration (編排/協調) 挑戰」，意思是在 協調邊緣端設備與雲端平台（基礎建設）之間的資料與服務時，所會面臨到的各種挑戰！ 請注意這個 "挑戰" 是雙向的~ 資料同步與資料一致性的挑戰 在協調邊緣端到雲端的過程中，確保資料的同步並維持分散式系統之間的資料一致性，是一項艱鉅的挑戰！因為 Data 的生成通常來自於多個不同的邊緣位置，而且邊緣裝置可能會將 Data 進行初步處理，而後送到雲端進行聚合或分析，所以可能會出現「資料不一致、資料衝突甚至資料遺失（丟包）」等......的風險。 如果邊緣端的資料與雲端的不同步，對於時間敏感的應用來說，可能導致其根據過時或不完整資訊的來進行決策。此外，由於邊緣裝置的工作環境各不相同，且連線狀況各異，因此確保所有資料的變更在整套系統當中統一反映，保證不重複也不遺漏，就成為了一項複雜的任務，需要強大的同步協議和細致的資料管理策略。 針對異質設備和網路的協調挑戰 從邊緣端到雲端的 Orchestration (編排/協調) 挑戰，其中最複雜莫過於是管理各種各樣的邊緣設備和平台。打個比方（如：智慧家電、穿戴式裝置、工業感測器和自動駕駛汽車）這四個設備，就特性上，我們也許會認為其中有幾個會採用相同的通訊協定或是架構。 但就實際應用上，可能因為數位主權、在地合規、成本考量等......因素，導致它們採用的是完全不同的通訊協定（僅支援特定的網路切片組，如：LTE-M, 3GPP R15 mMTC, R17 的 redcap, etc,.）和不同的架構和作業系統。因此要整合和協調這樣一個異質的設備和網路環境，就必須深入了解每種裝置之間的細微差別，並有能力建立統一的介面來實現無縫通訊。 在這個多樣化的生態系統當中，要確保軟體更新、安全性修補程式和效能最佳化都能保持一致，也是一項巨大ㄉ Day 2 挑戰！隨著邊緣設備的數量和種類不斷增加，開發標準化的方法和工具來統一進行管理，已成為從邊緣端到雲端的 Orchestration (編排/協調) 的成功關鍵。 當然，針對異質設備和網路的問題，如果要解決的問題是整體管理的決策優化，則可以往開發新的聯邦學習演算法來解決！ 面對分散的邊緣到雲端環境中的安全問題 從邊緣端到雲端的 Orchestration (編排/協調)當中，保護異質分散網...
張貼留言
位置： České vysoké učení technické v Praze, Technická 1902/2, 166 27 Praha 6 - Dejvice-Praha 6, Czechia
閱讀完整內容

Google Distributed Cloud 升級：AI 應用、數據處理與數位主權的全方位解決方案

圖片
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 提供了各式各樣的管理服務，我們已經不...
張貼留言
位置： 捷克布拉格斯特拉霍夫
閱讀完整內容

應變網路行動車簡介 #運作原理說明 #數位發展部

圖片
一台應變網路行動車，整合了這麼多的設備 這次數位發展部moda（Ministry of Digital Affairs）緊急派出的「應變網路行動車」，其連接的是盧森堡的 SES 中軌衛星通訊系統。而截至去年(2023年)，SES 公司前前後後也發射了 20顆衛星上去，衛星高度大約在海拔 8,000 Km。也正因為這個高度相較於定軌衛星(約 36,000 Km) 而言，距離地面更近，因此 SES 中軌衛星的延遲時間大約僅有定軌衛星的四分之一，這樣的延遲時間在緊急通訊面前，可說是綽綽有餘！ 這套 SES 中軌衛星通訊系統還蠻方便的。首先，中軌衛星會先與合作的地面站連接（這次我猜應該還是和台灣微軟 Azure 合作），以獲得網路存取。一旦中軌衛星成功獲取網路存取，隨後便開始向行動車傳輸網路訊號。 那基本上「行動車」會裝有兩組天線，以便於執行切換 (handover) 操作。（實際運作時，一支主要用來通訊，另一支追蹤下一顆衛星） 傳統搭載的是 可轉動的碟盤天線 ，但這次安裝在「應變網路行動車」上的似乎是 新型的相位陣列天線(Phased Array Antennas) ！！！（下圖紅框） 紅框-我猜是最新相控陣列天線（傳統為可轉動式碟盤天線） 藍框-看起來像電信基地台的Micro Cell，可以提供災區網路服務。 回到正題，當行動車上的天線成功追蹤到衛星，並測量通訊品質符合標準，便會建立連線，開始接收來自衛星的訊號。但由於衛星訊號使用的頻段非常高（Ka：26.5–40GHz），因此衛星傳下來的訊號是無法直接與地面網路系統對接，所以天線後端會連接 SES 它們家基頻處理的裝置（下圖紅色虛線框處），用於進一步將衛星訊號降頻，然後經過一系列類比/數位轉換和訊號處理步驟。 最終訊號會變成封包，並以 IP 的形式連接地面網路系統（如：5G O-RAN基地台、Wi-Fi CPE、乙太網路），就可以應用在像是跨國工廠或是災害現場等......場景(scenario)。 > 當然這套系統也支援接收 X band、C band、Ka band、Ku band。 紅框-SES系統（包含降頻設備和訊號處理設備 藍框-地面網路系統。 補充一下，衛星向「應變網路行動車」提供網路訊號之前，必須先與其他國家或合作網路供應商的地面站進行連接，以此來接取網路，中軌衛星成功獲取網路存取之後，即可向行動車...
張貼留言
位置： České vysoké učení technické v Praze, Technická 1902/2, 166 27 Praha 6 - Dejvice-Praha 6, 捷克
閱讀完整內容

O-RAN雲原生自動化的發展與挑戰

圖片
本文整理並逐一說明目前電信產業雲原生轉型，可能會面臨到的眾多挑戰，此外，說明為何電信產業已經引入了雲原生技術，卻仍舊無法真正地享受到雲原生轉型所帶來的各項好處。期望鼓勵更多莘莘學子投入 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...
張貼留言
位置： Olympijská 1901/7, 169 00 Praha 6-Břevnov, 捷克
閱讀完整內容