O-RAN 科普教育

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系統（包含降頻設備和訊號處理設備 藍框-地面網路系統。 補充一下，衛星向「應變網路行動車」提供網路訊號之前，必須先與其他國家或合作網路供應商的地面站進行連接，以此來接取網路，中軌衛星成功獲取網路存取之後，即可向行動車

本文整理並逐一說明目前電信產業雲原生轉型，可能會面臨到的眾多挑戰，此外，說明為何電信產業已經引入了雲原生技術，卻仍舊無法真正地享受到雲原生轉型所帶來的各項好處。期望鼓勵更多莘莘學子投入 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

電信產業如何應用生成式 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 Network Planning（網路規劃）和部署的過程中，如何使用 TE&IV 服務供應商提供的批次上傳服務。 透過 Network Planning（網路規劃），使得 CSP（雲端服務供應商）能有效地設計、管理和最佳化網路。此外，進行 Network Planning 和 Network Design 的目的，也是為了確保新（世代）的電信網路，能以最佳效益來運行，並有足夠的網路容量和可靠性，以滿足用戶和營運商(operator)的需求。 隨著用於部署的雲原生技術（如：容器化、微服務）高速發展，網路規劃、設計、部署到實現的開發週期已經大大縮短。 庫存(Inventory) 會透過儲存和提供有關 Network Planning 的資訊，來支援Network Planning 的流程。TE&IV 服務[註1] 可將網路資料批次上傳至庫存(Inventory)，從而簡化大規模規劃和部署網路的過程。 [註1] TE&IV 服務(Topology Exposure and Inventory Management)：代表測試、評估和整合性的驗證。主要用於將新網路技術和服務部署到生產環境之前，對其進行測試、評估和驗證的流程。TE&IV 是網路生命週期管理流程的重要環節，因為它有助於確保新技術和服務能夠滿足用戶的需求，並確保它們能與現有網路基礎設施無縫整合。 備註：用於批次上傳至庫存(Inventory)資料的檔案格式，取決於通用拓撲結構和 Inventory Model，這部分本規範沒有涉及。 本用例涉及的實體(Entities)/資源(Resource) SMO Framework：用於支援 PNFs 的部屬。 OAM Functions：用於管理 NF 的配置(Provisioning of NFs)，和庫存物件[註2]的狀態。 NFO：用來與 O-Cloud 進行互動，執行 NF 的生命週期管理(LCM)。 TE&IV Service Producer：可批次上傳庫存中的 Data。 O-Cloud：與 SMO 進行互動，以佈署 NFs。 [註2] 庫存物件，所謂 O-RAN 的庫存物件，大致可分為兩大類： 實體庫存物件：包括基站、無線射頻天線等…硬體組件。 邏輯清單物件：包括虛擬網路功能 (VNF

SDR Platform 指的是用來實現軟體無線電（Software Defined Radio，SDR）的硬體和軟體系統，SDR Platform 可以用來實現各種衛星的操作功能，（如：遙測接收、遙控指令傳輸和頻譜監測...）總而言之 SDR Platform 是一種靈活、高效益的衛星與地面接收站通訊的解決方案。 而軟體無線電(SDR) 呢，它是一種使用軟體來控制 RF 訊號處理的無線電。它比傳統無線電靈活度還要高，並且適應性更強，因為通常傳統無線電都是為了連接特定頻率，或是特定調製方案(modulation scheme)的來專門進行設計的。 以下簡介通用無線電系統的硬體設備及其職責： 通用無線電系統的 Physical Layer 處理和硬體設備示意圖 資料來源：A Software-Defined Baseband for Satellite Ground Operations 上圖最左邊橘色的部分，即是無線電系統前端的接收天線。無論你是用 Phased array、Control Plane Receiver 或是 User plane Receiver 一旦接收衛星通訊訊號之後，必然需要再進行後端處理，讓衛星訊號得以轉換成地面行動通訊訊號以供使用。 由於不同軌道的衛星會使用不同的通訊頻段（如：X, S, Ka, Ku band ...），所以傳統無線電系統的設計方式，會依據不同的頻段來設計 專門的接收器 、專門的 Up/Down Converter ，甚至可以說專為特定頻段 專門 設計了整套無線電系統 。 地面接收站接收到特定頻段之後，就會需要進行降頻處理，藉由將高頻的衛星通訊訊號降到中頻或是基頻，最後再經過基頻的系統處理，（上圖右邊藍色部分）將訊號轉換成 OSI 第三層（TCP/IP的網路層） 的 IP，後端就可以透過像是 Gateway 等設備，再介接電信基站、Wi-Fi Router、乙太網路，以供使用！ 基於硬體 的衛星地面接收站整體運行的架構圖 資料來源：A Software-Defined Baseband for Satellite Ground Operations 像這類傳統基於硬體的衛星地面接收站，就會需要針對不同的衛星頻段（如：X band, S band ）來設計不同硬體和處理方式，雖然它看起來是一套系統，但是其實整合度不是很好，