HackMD
從命令式部署到宣告式閉環管理：Cloud O-RAN 自動化的技術演進、實務應用與未來挑戰之探討
〈引言〉
隨著電信產業逐步走向雲原生（Cloud-Native）架構，如何在無線接取網路（Radio Access Network；RAN）場域實現更高效能且即時的自動化管理，成為近年來的關鍵議題。在 2023 年以前，電信業者大多使用 Helm chart、Docker Compose 等命令式（Imperative）部署工具，雖然適用於初期（Day-1）的快速導入，但對於網路環境持續變化與閉環自動化（Closed-loop Automation）的即時需求，往往緩不濟急。由於傳統做法缺乏動態感知與調整能力，也無法同時協調網路功能組件（Network Function；NF）與底層基礎建設（Infrastructure），因此在日後維運管理（Day-2）的複雜度與成本上升顯著。
2025 年，隨著 O-RAN 聯盟更新了一系列針對 O2 Interface、Infrastructure Management Services（IMS）、Deployment Management Services（DMS）的規範，加上業界對 Kubernetes 宣告式（Declarative）框架及帶內管理（In-Band Management）的採納，Cloud RAN Automation 體系逐漸成熟。部分前瞻研究也將 GitOps、GenAI（Generative AI）與 Nephio 等技術整合至 Kubernetes 的 CRD（Custom Resource Definition）與 Operator 之中，進一步降低人為干預，來減少成本，同時減少資料孤島、人工操作與重複部署等問題，並加速電信網路邁向真正的智慧化與閉環式運作。
為了呈現本領域的整體演進，本文在彙整 2023 年 6 月與 2025 年 3 月之間多項標準化與實務成果的基礎上，提出一個多層次的研究視角，涵蓋「理論與標準 → 實務落地 → 前後對照與未來展望」，期能作為產官學研各界深度探討 Cloud RAN Automation 的參考依據。
〈背景與技術脈絡〉
1. 從命令式部署到宣告式管理
在 2023 年前，電信業者於 RAN 自動化多仰賴 Helm chart、Docker Compose 等命令式工具。這些工具在 Day-1 的部屬確實提供便利，但其高度依賴預先定義的部署步驟，一旦網路負載或資源狀態產生變動，就缺少即時調整能力；維運人員往往需要手動更新參數或重複部署，進而導致高昂的 Day-2 維護成本。為解決此侷限，O-RAN 在 2025 年後全面導入 Kubernetes 為基礎的宣告式框架，藉由撰寫 CRD、Operator 與對應的 Policy（例如：彈性伸縮（Scale-out & in）策略、健康檢測（Health Check）等），使系統能根據即時狀態自動調整配置，達到更高階的閉環自動化。
2. O-RAN 最新標準與多層雲端架構
近年 O-RAN 聯盟著力於 O2 Interface、IMS 與 DMS 之標準化，形成了針對 O-Cloud（雲計算平台）上所有網路功能的統一管理介面。Cell Site、Edge Cloud、Regional Cloud、Central Cloud 等不同拓撲，也透過 Federated O-Cloud Orchestration and Management（FOCOM）機制與 Scenario-based Deployment 的標準化進程，提供了多層式雲端協調（Reconciliation）運作的藍圖。這些標準規範進一步明確了 O-Cloud CNF 的生命週期管理（LCM），從最初只有 Deploy、Terminate 與 Scale-in/out，到如今包含 Health Check、自癒（Heal）、Diagnostic、垂直擴展（Vertical Scaling）等更先進功能，體現了雲原生技術在電信網路的成熟應用。
3. Kubernetes 擴展與特殊硬體需求
電信網路對高吞吐量、低延遲與強穩定度有更嚴苛的要求，尤其在 SR-IOV、DPDK、CPU pinning、HugePages 等領域，原生 Kubernetes 難以完全滿足。為此，O-RAN 規範新增了 Acceleration Abstraction Layer（AAL），將硬體加速器抽象化，以便 CRD/Operator 能動態感知與配置特殊硬體資源。此外，Nephio 透過 Kubernetes 原生的擴充能力，協同管理底層加速器與 CNF，讓雲原生的電信環境能更靈活地分配計算資源，進而實現高效能且具可移植性的部署模式。
〈主要技術挑戰與解決方案〉
1. Helm chart 侷限與 Template Hydration
- 挑戰：Helm chart 在複雜場景中可重複利用度不高，產生大量配置檔案難以維護。跨不同部署環境（如 Edge Cloud 與 Central Cloud）時，參數調整往往需要人工逐步修改，且若要配合 O-RAN 多場景化的需求，代價更加昂貴。
- 解決方案：針對此痛點，Nephio 提供了 Template Generation 與 Hydration 機制，再配合 GenAI 協助自動化生成 Operators、CRD 或 TOSCA/KRM 格式的模板，動態填入環境參數，克服 Helm chart 無法彈性重複使用的侷限。在 O-RAN 標準裡，Scenario-based Deployment 進一步定義了各種 O-Cloud 場景的 Cluster Template，並搭配 DMS 完成 Day-2 維運時的自動化配置與事件回報，提高系統可擴張性（scalability）與穩定性。
2. 命令式部署的 Closed-loop Automation 落地不足
- 挑戰：過去命令式工具對 Closed-loop Automation 的支援度有限，無法根據即時監控的負載或資源使用情況進行自動調配，導致維運人員大量介入，且易錯或延誤。
- 解決方案：O2 Interface 與 IMS/DMS 的標準化使網路功能與基礎建設狀態能被即時觀測並回報，透過宣告式管理機制的 CRD 與 Operator，可動態調整 CNF 部署參數，真正落實「系統自發調整—監控回饋—再調整」的閉環循環。同時，GitOps 思維（如 FluxCD、ConfigSync）導入 Nephio 之後，使整個流程從程式碼版本控管到環境部署都保持一致，可確保任何異動皆可追蹤且自動化應用，顯著降低人為失誤。
3. 帶外管理（Out-of-Band）協同不足
- 挑戰：帶外管理模式下，NF 的 LCM 與基礎建設的資源調度常分屬不同管理平面，難以協同運作。面對突發流量高峰或資源故障時，NF 層與 Infrastructure 層可能互相掣肘。
- 解決方案：O-RAN 最新的 Service-Based Architecture（SBA）加上 In-Band 管理模式，使 NF 與 Infrastructure 能在同一 Orchestration 層協同運作。配合 Nephio CRD/Operator 機制，帶內管理能夠讓 NF 層及底層資源狀態在單一控管點被調度，形成真正端對端的 Closed-loop Automation。
Federated O-Cloud Orchestration and Management（FOCOM）則確保即便在不同層級的雲端或多廠商異構環境中，也能同步掌握整體網路狀態並協同優化。
〈進階功能與實踐案例〉
1. O-Cloud CNF LCM 之進階功能
在早期（2023 年 6 月前），O-Cloud 上的 CNF LCM 僅能執行 Deploy、Terminate 與水平（horizontal） Scale-out & in。但到了 2025 年，O-RAN WG6 明確定義並落實了 Health Check、自癒（Heal）與 Diagnostic 等功能。
- Health Check：透過 IMS/DMS 標準化接口，系統定期探測 NF 容器與底層硬體資源的健康狀態，如出現效能瓶頸或隱性故障，Operator 可主動執行重啟或容器遷移。
- 自癒（Heal）：結合 Kubernetes 標準化事件機制（例如 Pod Failure 或 Node 失效），在發生問題時自動觸發自癒工作流程，進行重新配置或資源回收，減少服務中斷。
- Diagnostic：對於複雜故障可留存系統狀態快照（snapshot）與日誌，協助維運人員釐清根本原因，大幅縮短排除故障的時間。
2. Template Hydration 與 GenAI 之實務成果
Nephio Release 4 在 Kubernetes 生態系整合 GitOps、Template Hydration 與 GenAI，已於 Edge Cloud 和 Regional Cloud 等多個試點獲得驗證。例如：電信運營商在不同地理場域部署的 O-CU、O-DU、Near-RT RIC 都有不同硬體加速需求（DPDK、SR-IOV 等），Nephio 能透過 GenAI 自動生成相對應的 CRD 與 Operator，然後結合 Template Hydration 動態填充區域參數（例如：頻譜配置、CPU 綁定策略）。這些功能大幅縮短了部署時間並提升配置正確率，也降低了工程師的負擔。
3. 帶內管理（In-Band Management）的閉環自動化樣板
傳統帶外管理下，需要分別在 NF 層與 Infrastructure 層設定調度規則，且兩者之間往往缺少共同的事件機制。帶內管理則能將 NF 與 Infrastructure 納入同一個 Operator 中，使資源感知與網路策略能在同一邏輯平面處理。實務案例顯示，當 Edge Cloud 偵測到頻寬異常或 CPU 資源不足時，In-Band 管理能立即與 NF 的 CRD 溝通，決定是否執行容器 migration、負載分流或垂直（vertical） Scale out & in。藉此可有效預防流量壅塞、服務中斷或高延遲情況，達到端對端的 Closed-loop Automation。
〈未來研究與結論〉
1. 尚待解決的核心議題
- 多廠商異構整合：雖已有 FOCOM 協議處理不同層級雲端，但真正在大型商用環境，仍需要更多跨廠商測試與驗證，以確保 Operator、CRD、加速器與 Kubernetes 核心能順利對接。
- 資料隱私與安全：電信網路的關鍵數據（例如：用戶流量、基站資訊）涉及高度敏感度，如何在 GenAI 或帶內管理流程中兼顧高彈性與安全性，值得深入探討。
- 能源效率：隨著 CNF 與容器數量快速增長，伺服器耗能成為重大考量。O-RAN 雖引入 AAL 與 Kubernetes 協同，但具體的能耗調度演算法尚有最佳化的空間。
2. 學術與產業合作潛能
- In band 管理的最佳化：可以結合 AI/ML 技術，動態預測流量與資源使用率，協調優化 NF 調度策略。
- Scenario-based Deployment 的智慧自動調整：如何更精準地根據場域特性（Cell Site、Edge Cloud、Central Cloud）自動生成最適合的配置模板，避免繁瑣的手動微調，是未來研究重點。
- 跨領域應用：Cloud RAN Automation 也可與物聯網（IoT）、智慧城市、MEC（Multi-access Edge Computing）、RIS 等技術結合，產生更多創新商業模式。
3. 結論
在 2023～2025 年間，Cloud RAN Automation 從原本在命令式部署階段的侷限，逐步發展出宣告式自動化管理框架與多層次的標準化方案。O-RAN 聯盟發布的一系列規範（特別是 O2、IMS/DMS 與 FOCOM）加上 Kubernetes 生態系的 CRD、Operator、AAL 等技術成熟，讓電信業者不再受限於傳統 Helm chart 的場景侷限與帶外管理的協同不足。再結合 GitOps、GenAI 與 Template Hydration，整個雲原生網路自動化的流程已能實現高度閉環與智慧化。
展望未來，電信產業的自動化程度將持續提升；同時，更多 AI/ML 技術的深度導入將促成 NFs 與 Infrastructure 更緊密的協同，帶來更高彈性、更優化的能源管理與服務體驗。雖然仍存在多廠商異構整合、資安與隱私、能源效率等議題，但在 O-RAN 規範與 Kubernetes 持續演進下，Cloud RAN Automation 必將在產官學研合作下穩步邁向更廣闊的未來。藉由不斷推動標準落地、實務創新與學術研究，電信產業可在雲端通訊領域發揮更強的競爭力與國際影響力。
致謝
本文綜合了 2023 年至 2025 年之間 O-RAN SC、Nephio wiki 及相關開源社群的多方研究成果與實踐經驗，另外，我也要感謝林小美還沒回我訊息，所以目前半夜 03:53 我非常焦慮的還在等她回，但其實訊息根本不重要，我只是想和她聊天，這樣我就開心了。還有對我的肝 感謝它。
剛剛 AM 4:00多 她回了，現在捷克時間 3/29 PM 10:00，今天 3/30 等等捷克 AM 2 點要改成夏令時間，她說她要熬夜錄下那段 2 點直接跳到 3 點的畫面。而我的話，要去吃早餐睡覺了，今天陽明還是好冷，清晨下了雨Sun, Mar 30, 2025 5:24 AM
