AI Cloud RAN：結合雲原生架構與AI/ML技術，實現電信產業淨零排放

⚠ 注意：本文所探討的 O-Cloud 與各項 Network Functions，皆是以雲原生架構為基礎進行設計，並圍繞此架構進行深入討論。比較不會在意細枝末節（例如：特定 NFs 目前以雲原生方式實現無法發揮其最大效能，或是 x86、ARM 等晶片會限制特定 NFs 的效能。）如果您是務實派（功利主義）支持者，那建議您可以點擊返回鍵了~

鑒於本人 5、6 月要去考淨零碳排規劃管理師…

不行這樣開頭太爛了，重來…，吾師聞後必笑曰：「恨鐵不成鋼」。俠之大者，應心懷蒼生、為國為民，要將個人行動與產業轉型、國家願景扣連起來，文章立意才會更為宏遠，而且人要有遠志，聊以塞責之筆，難成氣候；若能銳意求精，未來必可期。（誤

鑒於全球暖化的日益嚴重，國際能源署（IEA）於 2021 年發表了全球能源系統淨零排放的預測路徑分析報告，提供了實踐減碳目標所需之行動以及時程。同時 2021 年的聯合國氣候變遷大會，各國也紛紛承諾減少碳排放，部分國家亦將「淨零排放」之實施方法以及概念立法進行管理。

因此，敝人在此拋磚引玉，這次要來和大家談談的是一些關於 AI Cloud RAN 實現「淨零排放」轉型的前瞻性議題，期盼促進產、官、學、研各界對此議題展開相關研究與技術儲備。本文核心探討的是未來 6G 時代，如何將 AI/ML 與 Cloud O-RAN 架構進行深度整合，使網路功能元件（NFs）與基礎設施（Infrastructure）之間能夠更緊密的協同運作，以提高能源管理的智慧化水準，同時實現 Cloud RAN Automation，並殫盡雲原生所帶來的優勢，來進一步提升能源使用效率（Energy Efficiency）。 最終，希望透過此一技術進展，來帶動電信垂直產業的革新，並作為全球電信業界推動「淨零轉型」的重要典範與參考依據。

為什麼 Cloud RAN Automation 可以減少能源消耗？

在開始說明 Cloud RAN Automation 是如何減少能源消耗以及達成低能源消耗（Low Power Consumption），並協助電信營運商 [註1] 達成永續發展與減少碳足跡的目標之前，需要先帶各位來認識幾個與實現 Cloud-Native O-RAN Automation 密切相關的核心組件和介面及其支援的功能（服務）。

與 RAN Automation 密切相關的核心組件和介面及其支援的功能

想深入所有與 RAN Automation 有關的組件及介面的朋友，歡迎點擊（觀看此影片）

• SMO；Service Management & Orchestration（下圖藍色圓角矩形）：為了方便解釋，這邊還是會以(Out-of-band) [註2] 的邏輯來進行說明。在 O-RAN 架構當中，SMO作為大腦的角色，它會透過 O1 介面（下圖並未列出）和 O2 介面分別對 NFs 和 O-Cloud 進行管理和提供服務。
• O2 介面（下圖中間橘線）：是 API；O2 介面是 SMO 與 O-Cloud 之間溝通的橋樑，根據定義之功能／服務不同，可以分成兩類，分別是 O2ims 和 O2dms。

O-Cloud 簡介（上圖綠色圓角矩形）（深入了解）

O-Cloud 指的是在雲原生化的 RAN（Cloudified RAN） 架構中，用於部署、管理和執行網路功能組件（Network Functions, NFs）的雲端基礎設施（可以把它看成是一個擁有計算資源的雲平台）。而這個平台整合了架設 O-RAN 基站所需的各種物理基礎設備節點（Node）（包含：計算資源、網路資源、儲存資源等），並透過資源池（Resource Pool）進行統一管理，支援硬體加速的技術（例如：SR-IOV、DPDK 及特殊電信需求如 NUMA、HugePages 等），藉此來有效提供 Cloud-Native Network Functions (CNFs) 最佳的運行環境，除了能有效管理資源，也能達成資源的最佳化利用。

O-Cloud 提供 CNFs 生命週期管理(LCM) 服務的現況與未來發展

O-Cloud 提供部署在其上面的 CNFs 生命週期管理（LCM）功能（服務），這些功能皆是透過 部署管理服務（DMS） 和 基礎設施管理服務（IMS）來實現；以下針對 O-Cloud 目前有提供的功能 進行簡介。

資料來源（截至 2025年 3月）：《O-RAN.WG6.TS.O2-GA&P-R004-v08.01》、《O-RAN.WG6.CADS-v08.01》。

O-Cloud 目前有提供的生命週期管理 (LCM) 功能

資料來源是上面兩篇 O-RAN 標準，當中明確指出目前 O-Cloud 提供給 CNFs 的生命週期管理（LCM）服務為以下幾項：

已實現的基礎 CNF LCM 功能

• NF Deployment instantiation：O-Cloud 提供了網路功能（NF，Network Function）部署實例的實例化能力。當新的 NF 需要進行部署時，透過 O-Cloud 的自動化管理流程，可迅速地將所需的軟體元件部署至計算資源（例如：虛擬機或容器）上，並自動分配必要的 O-Cloud 資源，實現快速且高效的資源配置（NFs 通常被視為軟體元件）。
• NF Deployment termination：當某一 NF 實例已經不再使用或需要撤除時，O-Cloud 提供了便捷且迅速的終止功能。此操作可即時釋放該 NF 所佔用的全部計算與網路資源，避免資源浪費，且有利於網路功能的即時調整、更新或服務結束時的資源回收。
• Horizontal CNF Scaling（in and out）：O-Cloud 透過水平擴展機制，實現 NF 實例數量的動態增減。此擴縮容操作能夠因應實際流量變化或資源需求，由 O-Cloud 或 SMO 主動觸發。舉例來說，當流量瞬間激增時，O-Cloud 能夠自動增加 NF 實例數量，確保網路服務持續穩定且效能最佳化。
• Querying information about a CNF：為了實現對 NF 部署實例的有效監控與管理，O-Cloud 提供了透過 O2 介面查詢部署實例的詳細資訊能力，包括目前運行狀態、配置參數、軟體版本及資源使用狀況。系統管理員或自動化管理工具（例如：SMO）可藉此迅速掌握 NF 運行實際狀況。
• Querying status of LCM operations：O-Cloud 具備查詢生命週期管理（LCM，Lifecycle Management）操作狀態的功能，LCM 包含部署、擴展、終止、修復等關鍵流程。透過此功能，系統管理員能夠及時獲得操作的最新狀態，包括操作是否成功執行、目前執行中或已失敗，從而有效協助操作進度追蹤與問題解決。
• Upgrading of any or all components of a NF：O-Cloud 提供了 CNF（NF Deployment）[註3] 內任意或全部元件的升級能力，使軟體版本與配置能夠維持最新狀態。此升級過程能夠在不中斷服務運作的前提下進行，確保 NF 在持續提供服務的同時，也能兼顧軟體安全性與版本的即時更新，維持網路功能的長期穩定性與效能。

上方列表當中的 「Horizontal CNF Autoscaling（in and out）」是我們今天的主角，也就是能夠提升能源使用效率（Energy Efficiency），同時也能實現 RAN Automation 的關鍵功能，稍後會單獨拉出來詳細說明。此外，O-Cloud 還有支援進階的生命週期管理（LCM）功能包括：健康狀態偵測（Health Check）、自癒（Self-Healing）、診斷（Diagnostic）等功能。

健康狀態偵測 (Health Check)：

健康狀態偵測的核心目的在於即時且精準地掌握 O-Cloud 及其上所部署的 Network Function（NF）的運行情形，以確保整體系統的穩定性及服務的可靠性。

自癒 (Heal) 功能：

自癒功能（Heal）提供 O-Cloud 系統自動或半自動處理故障與異常狀況的能力，旨在有效減少系統中斷或效能退化可能產生的衝擊。

診斷 (Diagnostic) 功能：

診斷功能的主要目的在於透過詳細且完整的日誌（Logging）與效能紀錄（Logging Level）分析，協助技術人員深入查找故障根本原因（RCA），提升系統維運效率。

仍待未來研究的 O-Cloud 生命週期管理 (LCM) 功能

由於再繼續寫下去，本文的篇幅就太長了，因此將（O-RAN O-Cloud 尚未解決，仍待未來研究的問題 For Future Study）獨立成一篇文章進行簡介。吾人深知電信界很喜歡 （畫虎爛） 談各種前瞻新奇概念，但至少面對問題是解決問題的第一步，而會被寫出來表示已經跨出第一步ㄌ，剩下的就待你我未來持續研究將其落地成真！

Horizontal CNF Autoscaling（in and out）帶領 6G 網路效率達到新境界

前面提到 O-Cloud 提供給 CNF 的 LCM 功能之一 「水平自動化擴容或縮容（Horizontal Autoscaling）」，除了是實現 RAN Automation 最最重要的關鍵之外，同時也是能提升能源使用效率的藏鏡人。Horizontal CNF scaling（in and out）的這個概念，在 Kubernetes 的生態中可以對應到 Horizontal Pod Autoscaling（HPA，水平 Pod 自動擴展）機制 [註4]。

什麼是 Horizontal Pod Autoscaling（HPA）？

HPA 是 Kubernetes 原生支援的自動擴縮容機制。Kubernetes 作為目前市面上最常見被作為容器工作負載編排的平台。其內建的 HPA 功能可根據系統指標（如 CPU、Memory、或自定義指標）自動調整 Pod 數量。放在 5G CNF 架構中，HPA 能根據即時流量，自動調整像是：核心網路端的 用戶平面功能（UPF）、接入與移動管理功能（AMF）、會話管理功能（SMF）與網路切片管理功能（NSMF）等 CNF 的資源數量，以維持最佳的服務品質（QoS）。

另外，HPA 還支援使用者定義的指標，舉例像是可以加入自定義的 5G 網路指標（例如：活躍使用者（UEs）數量、延遲（Latency）、吞吐量（Throughput）、封包遺失率、抖動等）。只要這些數值突破我們設的上下限門檻，HPA 就會計算出當前相對應要有多少個 CNF 存在，接著在第一時間進行擴縮容（Scale Out and In）的操作，確保資源分配既不浪費，也不短缺。

為什麼 HPA 對電信業者這麼重要？（HPA為電信商帶來的價值）

就以這次清明連假為例好了，2025/04/02 收假第一天，我們可預見異鄉遊子會返鄉祭祖，因此地區性的網路的流量變動非常大，即我們可以預料到除直轄市外的高鐵站或是火車站（二等站、三等站）會相對平時白天有更大的網路需求。像這樣的情境 UPF、AMF 這類網路功能就可能得要緊急擴容，但到了夜晚或離峰時段，由於非直轄市或特等站，所以離峰後可能甚至完全沒有班次，反而要縮減 CNF 來節省成本。

要將 Autoscaling 與 5G 服務指標緊密結合，才真正有效！

以剛剛清明連假的那個案例，靠人力去手動調整根本不切實際，所以我們這邊直接不討論。因此本小節的剩餘段落就要從現況的角度帶大家來了解 AI 整合 Cloud RAN 實現智慧化 HPA 的必要性及需求性。傳統的 HPA 多半只看 CPU 和記憶體使用率，但這對於需求越來越多樣性的 B5G/6G 而言這遠遠還不夠。因此我們需要納入真正影響使用體驗的「電信 5G/6G 專屬指標」，例如：

• 延遲（對於網路切片 URLLC 而言，必須非常低）
• 封包遺失率與抖動（影響即時語音和影音品質）
• 每個網路切片的流量（切片化管理關鍵）
• 吞吐量與連線成功率（直接影響使用者體驗）

這些指標一旦被納入 HPA 判斷邏輯，就能讓 Autoscaling（in and out）的動作更貼近實際需求，也能針對個別 CNF 或網路切片進行精細調控，甚至能根據用戶使用行為進行預測性 Autoscale，不再只是被動因應。

舉例（中秋連假）：傳統方式會根據 CPU 的使用率來決定 CNF 的 scale out and in 行動，但面對即時性的大量需求突然來臨（一台連自由座都爆滿的高鐵經過雲林高鐵站）且每個人使用的網速方案都可能不一樣。如以傳統方式來因應，根本緩不濟急。但有了智慧 HPA，就可以監控每個網路切片的活躍用戶數，進行預測性擴容，即根據實際需求來調整不同 CNF 的資源。此外，若能整合 AI 即可讓基站具備記憶能力，讓每年連假高鐵經過的基地台都要記得 scale out UPF 和 AMF，來應付高流量需求，確保延遲不升高。同時，透過機器學習來計算需求，避免過擬合創建過多 CNF 導致資源浪費，又能保證 CNF 冗餘（Redundancy）因應不可預期之問題。

落實智慧資源管理，助攻淨零轉型

面向未來永續：HPA 結合 AI/ML 的潛力

總結上述的舉例，隨著 5G/6G 持續演進，電信業者可結合 AI/ML，對過往的歷史流量及使用者行為趨勢進行分析和預測，讓冷冰冰的數字變得有價值，以後在尖峰時段之前就能先行 scale out，離峰時即時 scale in，除了能進一步降低耗電量和碳排放之外 [註5]，也有助於電信業者達成其 ESG 目標。

• 預測式調度：利用生成式 AI 或深度學習模型，推測下一時段的流量峰值，提前布署 CNF 實例。
• 智慧冷卻與電源管理： AI 可協調硬體運行溫度與功率，最佳化資源分佈以減少散熱需求。
• AI + EMS + 5G 實現智慧節能閉環：透過部署 Energy Management System（EMS）來即時監控碳排與耗能數據，並整合 AI 應用使系統能夠 autoscaling 或是自動調整網路配置以提升能源使用效率（Energy Efficiency）。同時還可以善用 5G 特定切片（如：Redcap）的低延遲特性，每隔固定時間收集來自終端的碳排、耗能等細粒數據，供 AI 應用更好的了解能源策略該如何進一步優化，並進行 AI 能源管理 model 的更新，實現由終端數據驅動閉環節電控制。此外，有了更細緻的資料，（外國）電信業者也可以計算自身可提供多少乾淨能源，讓公部門或有需要的企業採購。

ESG 的推力：歐洲與國際趨勢

由於川普上任，目前在美國針對 ESG（環境、社會、治理）議題的關注明顯較低 [註6] 。但這並不表示 ESG 在全球的重視程度同樣下降。事實上，歐洲與其他地區已逐步將 ESG 與淨零排放放作為企業發展及技術落地必須納入考量的關鍵指標，尤其是歐盟積極推動相關法規，且歐盟在推法規的力度十分強大，迫使企業全面落實能源監控與碳排放管理。

目前，在 O-RAN SC 等開源專案中，ESG 尚未成為主要焦點，但隨著市場需求與政策壓力逐步升溫，環境永續性必將成為未來技術部署的重要挑戰。特別是在 Day 2 和網路基礎設施的建置過程中，如何兼顧能源消耗與環境影響，在未來將直接影響到產品的競爭力與市場接受度。

隨著環境永續性議題受到重視，Kubernetes 生態圈也逐步將「綠色維運」（Green Operations）納入核心發展方向。未來，未來可能出現更多針對節能策略與資源動態分配的開源專案，推動雲原生基礎設備管理在高效能與低碳排放之間取得平衡。

台灣作為全球電子五哥代工廠與軟體開發實力享譽國際的科技重鎮，必須超前佈局，積極將 ESG 的標的融入到未來 Cloud-Native O-RAN 的設計、部署與運營過程中。透過在系統設計階段即著手能源效率的優化、資源利用的精細化管理，並在自動化流程中導入即時能源使用監控及優化機制，才能確保未來產品在國際市場，尤其是對 ESG 要求嚴格的歐洲地區，維持高度競爭力。

具體而言，未來的 Cloud RAN 技術必須進一步整合能源優化與資源使用效率的策略。這在邊緣運算（專用網路端）和大型數據中心（結合 vRAN 與核心網路端）的部署情境中尤為重要，因為這些場景對節能與環保設計的需求將更為迫切。因為各產業龍頭企業通常都會擁有多個 Regional/Central Cloud，如能透過 AI/ML 技術能夠更精準地將負載分配至採用綠色能源或具備更高能源效率的資料中心，從而實現資源配置的最佳化。

然而，儘管目前的重點依然集中在網路自動化與管理功能的實現上，但若忽略節能與永續發展的要求，未來在歐洲等對法規標準極為嚴苛的市場中推廣應用時，勢必會面臨諸多挑戰與阻礙。這不僅關乎技術層面的提升，更是電信產業全球競爭力的重要保證。

總得來說，開放架構與開源軟體持續是全球技術發展的主流趨勢，而 Cloud-Native O-RAN 更為台灣提供了站上世界技術高峰的絕佳機會。在追求技術領先的同時，將 ESG 理念與實踐完整地融入產品生命週期，不僅能符合國際趨勢，更將奠定台灣品牌的長期競爭力與全球影響力。

結語：從雲原生到淨零，AI Cloud RAN 未來可期

總結來說，未來的電信產業並非只是要打造「速度更快」的 5G/6G 網路，而在於如何藉由 AI/ML 與 Cloud-Native O-RAN 的深度整合，推動整體運營模式的革新與永續。從 O-Cloud 的資源調度到 Kubernetes HPA 的動態擴縮容，再延伸到 ESG、碳權交易等全球議題，我們正看見「技術能力」和「節能減碳」開始交疊融合。對於電信營運商而言，水平擴展（HPA）並不僅止於降低 OPEX，更能為他們在邁向淨零排放、提升 ESG 指標的道路上，累積寶貴的策略籌碼。

短期而言，業者可從 5G CNF 的基礎部署切入，採用自動化資源管理來先行嘗試；而在中長期階段，若能整合 AI 數據分析、邊緣運算與綠色能源，就有機會讓動態調度與節能機制更臻完備，進而達到真正的智慧化、低功耗網路。當 AI 與 O-RAN 架構不斷深入耦合，並配合 Kubernetes 的自動化擴縮容機制一同發揮，加上 ESG 嚴格要求帶來的外部推力，電信產業或許不僅能讓網路變得更「綠」，更可藉此開啟一場深層次的產業轉型與創新浪潮。

註釋：

• [註1]：電信營運商（Telecom Operator）的說明；以美國為例，電信營運商（Telecom Operator）通常指的是擁有網路基礎建設的業者，而電信服務供應商（Telecom Service Provider）指的是提供電信服務的公司。但是在台灣，沒有分的那麼細。以中華電信為例，中華電信既是 Operator 也是 Service Provider，因為它們不僅擁有網路基礎建設，還提供各種電信服務。而其他電信業者如台灣大哥大、遠傳等基本上也是這樣。值得注意的是！無框行動是特例，因為它沒有網路基礎建設，它是漫遊中華電信的網路，所以它可以算是台灣唯一一間電信服務供應商。
• [註2] Out-of-band 的缺點：由於 Out-of-band 管理無法同時協調 Network Functions（NFs）與 Infrastructure 的部署與配置，會產生連貫性問題；而 in-band 管理將 NFs 管理功能整合進 K8s 原生資源中，能用一個統一的控制層實現真正的全域自動化，所以 in-band 管理將會是未來趨勢。
• [註3] NF Deployment(Workload)：是部屬雲原生 NF ，在單一 NF 內共享的資源，或是跨多個 NF 共享的資源。 NF Deployment 會去配置和組裝雲原生構造(Cloud Native Construct) 所需的 User Plane 資源，用來建立 NF Deployment 並管理其從創建到刪除的整個生命週期。
• [註4] 名詞說明：由於本文主要是以雲原生架構做為基礎，並圍繞其核心概念來進行討論，在 Cloud RAN 的框架下，Network Function（NF）通常被稱為 Cloud-Native Network Function（CNF）或 Containerized Network Function，同時亦可被稱為 instance、workload 或 NF Deployment。另一方面，由於雲原生的實作一般都是採用 Kubernetes 技術來實現，其最小運行單元為 Pod。而雲原生 NF 通常會以單一一組 Pod 的形式來部署，而這樣的部署結構與策略可統稱為 NF Deployment。NF Deployment 的主要職責在於配置並組裝實現 Cloud-Native Construct 所需的使用者平面（User Plane）資源，並負責從建立、運行至刪除的整體生命週期管理。因此，NF Deployment 除了可能是以單一 Pod 的形式實現，也可能可能包含多個 pod 之間的協作，意思就是有可能是由多個 Pod 組成，或者是跨多個 Pod 共享的特定資源。基於此，實作水平方向的 Cloud-Native Network Function 自動擴展（Auto-Scaling in/out）功能，實際上也可視為 Kubernetes 所提供的 Horizontal Pod Autoscaler（HPA） 機制的應用。
• [註5]：對於部署大量 5G CNF 的電信業者來說，耗電成本是一筆不小的支出。這份（Intel 和 SK Telecom 共同出版的白皮書提到）在雲原生的 5G 基礎建設中，動態的電源調節技術可在離峰時段減少最多 55% 的能源消耗，在尖峰時段減少 30%，平均下來可在 24 小時內減少約 42% 的能源消耗。
• [註6]：由於川普上任，至少在目前的美國，針對ESG（環境、社會、治理）議題的關注度相對較低。但某種意義上，這種現象讓我聯想到亞當斯密那套「看不見的手」，即個人或政府在追求自身利益時，反而可能間接促進了社會整體的發展。但卻也有點像地球又進入冰河時期那樣的自然冷卻循環，因為美國總統不會一直是川普 —— 但彷彿社會價值觀也在經歷一種週期性波動。