Nephio 與 AI Cloud O-RAN 自動化的關鍵技術解析 （Nephio and AI: Key Technologies for Cloud O-RAN Automation）

⚠ 注意：本篇提到的 AI（人工智慧）與 O-RAN RIC（智慧控制器）沒有任何關聯，如果您是為了 O-RAN RIC 點入本文章的話，您可以點返回了~

前言

隨著 Pretrain-finetune（預訓練與微調）方法的成功，生成式 AI 在適應多模態的能力上持續增強，同時也讓 Transformer 可被應用的範疇越來越廣。因此，有些人開始認為可以將此方法無痛應用於電信產業。只要透過遷移學習和預訓練通用模型再進行微調的方法，即可協助佈署在 Edge Cloud Side 的 Nephio 工具，迅速根據不同 scenario 的需求，對 O-Cloud 的 full stack 進行相對應的主動協調（Reconciliation）[註1]。

上方隨口提出的概念研究題目，雖聽起來很「美好」，但在現實生活呢卻是「沒好」！（因為以現有的技術無法實現）。

在現今的雲端封建時代 [註2]，雲服務平台資本家們（FAAMG）擁有至高的權力，能夠主導議題、鼓動風潮，間接引領媒體刻意炒作，使社會大眾早已把 Gen AI 視為一把「萬用的鐵鎚」，另一方面，則把所有稀奇古怪的問題則被視為「釘子」，大眾總以為 AI 這把大槌子，可以幫忙解決目前所有無法解決的問題。真的是這樣嗎？答案當然是否定。在現實生活中，並非所有問題導入 AI 技術就能解決（因為不是所有情況都適合使用 AI 解決）。事實上 AI 能提供的也不過就只是一種通用型解決方案（general-purpose solution）。因為在現實生活中有太多 interfering factors ，導致 AI 的場景適用性受限。

所以儘管 AI 的計算量與計算速度遠超人類，但其學習與推理仍然受限於資料輸入的品質與範圍。好比當前 AI 技術仍面臨多模態資料 「輸入」的限制，由於尚未發展出足夠多樣化的感應器（sensor），來全面捕捉/採樣並數位化所有重要的環境資訊供 AI 進行運算與分析。因此，在某些複雜場景下，無法透過 AI 來實現精準模擬真實場景。另一方面，由於人類的認知範圍是有極限的（且人類有 bias），因此即使是專業的網管人員，也可能因自身認知瓶頸，無法意識到某些關鍵變數的重要性，或是無法提供那些不在自己認知範圍內的資訊，進而無法提出正確的問題（prompt）[註3]、提供足夠的資訊，使 AI 在訓練或推理過程中因缺少關鍵輸入數據，而產不出理想結果。

因此，我認為網路工程領域在決定整合 AI 前，應當避免單純為了追趕技術潮流而整合 AI，而是該專注於眼前實際的應用場景與需求，選擇真正有效且可行的技術，不要依賴推測或不切實際的期望去擴展 AI 的應用。

那麼究竟 「電信網路的雲原生之旅」，AI 如何提供幫助。下方分享我的觀點，不過在此之前呢！需要先來幫大家複習一下什麼是 Nephio？，再來進一步剖析 Nephio 的定位，並與各位說明 AI 如何替 Nephio 賦能以及 AI 帶給 Nephio 最主要的價值在何處？

什麼是 Nephio？

Nephio 是 Linux Foundation 旗下的一個專案。它是一個專為電信產業需求而設計的「意圖導向的（Intend-based）雲原生網路自動化工具（基於 Kubernetes）」。這個專案的目標旨在簡化並自動化網路功能(Network Function) 的部署與管理流程。

簡單來說，Nephio 就是為了電信網路雲原生自動化而生

 Nephio 的定位：跨多平面的管理

透過上一小節的簡介，我們了解到 Nephio 誕生的目的是什麼？那麼接下來我們就可以開始了解 Nephio 究竟是如何實現這些目標！以及我認為的 Nephio 引入 AI 後其價值所在位於何處？

圖（一）O-Cloud Planes (O-RAN.WG6.O2-GA&P-R003-v03.00)

O-Cloud Nodes 被定義為資源，並由 O-Cloud Management Software 根據 blueprint 分配給特定的用途。

眾所周知嘛，O-RAN 的 O-Cloud 可以被分成 2-3 個功能平面（見上圖(一)），分別是：

• Management Plane（簡稱 M）：此平面中的 O-Cloud Nodes 除了負責管理 O-Cloud，也用來託管 IMS 和 DMS 功能。
• Control Plane（簡稱 C）：此平面中的 O-Cloud Nodes 負責管理 Deployment Plane 分配給特定 instances 的資源。
• Deployment Plane（簡稱 D）：此平面中的 O-Cloud Nodes 和 O-Cloud Node Cluster Networks 用於託管 O-Cloud NF Deployment。

M 平面和 C 平面可以視為同一個平面

而 Nephio 為了簡化 O-Cloud 整體的自動化，利用 Kubernetes 作為 O-Cloud 三個功能平面的自動化（控制）平面（見圖（二）），以實現聲明式管理，同時也能對 O-Cloud 整體 stack 進行主動協調（Reconciliation）。

圖（二）Nephio 高級架構圖

透過 O2ims（上圖小紅框），對兩個功能平面 （(M+C)+D） 進行管理與編排

透過 O2dms （上圖小黃框），對 Deployment Plane 進行管理與編排

補充：基於服務的 2 個 O2介面 (SBI)

• O2ims：是專為管理和配置 O-Cloud 資源而生，而這些資源可以透過 O2ims 上的 FOCOM 提供給 SMO。除此之外，O2ims 將可以使用的 O-Cloud Resources（如：計算/網路）分配到 O-Cloud Node Clusters，以及在整個生命週期內對 O-Cloud Node Clusters 進行所有集群範圍(cluster-wide) 的操作。
• O2dms：O2ims 可以動態創建 O2dMS，來進行 Workload(NF Deployment) placement 和 O-Cloud Node Clusters 的部署管理。除此之外，O-cloud Node Clusters 可透過 O2dms 上的（北向） NFO 供 SMO 使用。其中包括把準備好 O-Cloud Node Clusters，以便對這些在 Node Clusters 上部署的網路功能（NF Deployments）進行管理。

簡單來說，Nephio 的使命就是提供一個「電信等級、簡單、開放」的雲原生意圖自動化（Intent-Based Networking, IBN）框架，並且以 Kubernetes（K8s）為核心，建立通用的自動化模板（Templates），讓網路部署變得更高效、更具彈性。

Nephio 透過 K8s Operators 和 K8s CRD（Custom Resource Definition）實現基礎設施自動化，無論是公有雲、私有雲，還是多雲和混合雲環境，電信業者都能更輕鬆地部署與管理網路服務。更厲害的是，Nephio 打破多廠商之間的技術壁壘，讓雲原生的 infra 與 Network Functions 都能夠在一起無縫運行。特別是在 大規模邊緣部署（Edge Deployments） 的場景下，Nephio 提供了一種更加統一、簡單的方式，幫助電信商在異質環境下可以更快速、更可靠地完成佈建與管理。

潛在隱憂

要注意的就是，雖然絕大部分的 Workload（Network Functions）都可以使用 K8s container 的方式來實作，但還是建議不要過度整合，將 Management Plane 與 Workload 層（Network Function deployment）層整合包在一起變成一塊「大堆疊」（Big Stack），誓言打造一體化的雲原生網路解決方案。

我知道可能有人曾經被微服務架構搞過，在 debug 的時候很痛苦，找上下游找到很躁，而且網路一斷 node 之間就無法溝通。但親愛的電信領域朝雲原生方向演進已是必然，一切數位化也助於預估耗能，規劃減碳計畫。嗚嗚嗚 個人喜好改變不了世代洪流！

但這種全部包在一起的問題在於，會嚴重限制了電信商在設備供應商選擇上的彈性，導致模組/組件間出現相依性，同時使市場逐漸朝向獨佔市場或是寡佔市場的生態系統傾斜，形成不健康的供應商鎖定（Vendor Lock-in）。而避免 「供應商鎖定」是開放網路架構的核心之一。 如果組件之間的介面（Interface）沒有被明確制定（標準化），那供應商就有機會在不同平面層進行「深度綁定」，讓電信商在升級或擴展時，不得不依賴同一品牌，喪失靈活替換關鍵組件的能力。這樣電信商就會被設備商拿得死死的，同時也降低了網路架構的可擴展性，並影響創新空間。此外，強大的設備供應商還可藉此讓規模較小的電信商在市場競爭中失去主導權。

AI 如何替 Nephio 賦能

AI 在改善 Cloud RAN 的 Workflow 扮演重要角色

以我的觀點來看，我會認為「在最佳化邊緣雲（Edge Cloud）的 Workflow」上導入 AI 有很大的潛力，因為 AI 不僅僅是解決一個簡單的工作流程（Workflow）問題，而是可以協助改善整體 Workflow 的自動化（Automation），提高部署效率和可擴展性，並確保在多個 O-Clouds 環境中能夠有效地管理和編排資源，讓整體的 workflow 變得更加高效。

Edge Cloud 的定義：是一個支援將 RAN 的網路功能虛擬化，並將這些被虛擬化的網路功能（資源）提供給多個 Cell Sites 的位置（location）。此外，這個位置除了將網路功能虛擬化，也將這些 Cell Sites 所需的網路功能集中化，以實現「規模經濟」的效益。O-RAN.WG6.CADS-v08.00 TR

規模經濟之定義：指的是當生產或服務的規模增加時，單位成本隨之下降的經濟現象。上面的意思是，Edge Cloud 將多個基站所需要的（網路功能）資源集中化，來降低整體的運營成本，因為同樣的基礎設備和管理系統可以服務更多的基站，從而達到更大的規模經濟效益。 

純murmur（Google Distributed Cloud 的未來走向？）

未看先猜，Google Distributed Cloud(GDC) 為了實現在 Edge Cloud side 的 Automation（更精確一點應該說是：整合 LLM 的 Intent-based Automation）。在未來，Google Distributed Cloud 上面的 GKE Enterprise，一定會被 Nephio 給取代（或部份取代）。因為 Nephio 是 Linux Foundation 旗下的 Open Source Project，意思就是說 Nephio 是靠 Crowdsource 來實現技術創新，而非像 GKE Enterprise 只有 Google Cloud 團隊在搞。

畫重點：Gemini Code Assist 未來可能大有前途，另外，由於 OpenAI 目前還沒佈局到電信產業，所以我覺得 Nephio 整合 Gemini code assistent 勢必是趨勢。

AI 賦能 Nephio：這些領域將大幅提升

以下是我認為 Nephio 導入 AI，幾個非常有潛力的區塊：

• Federated O-Cloud Management：聯合雲基礎設施（資源）管理
• O-Cloud Cluster Lifecycle Management
• O-Cloud Registration and Resource Inventory
• Workload(NF Deployment) Placement
• NF Deployment Lifecycle Management
• Infrastructure services for the lifecycle management of Cloud Resources

O-Cloud 是一組硬體和軟體組件，提供雲端運算能力來執行 O-RAN 的雲原生網路功能（CNF）。這些 O-Cloud 可以根據不同的部署場景，集中部署或部署在邊緣，而如何部署牽涉到成本和複雜度。O-Cloud Lifecycle Management 的目標是透過協調 O-Cloud 的部署和管理，來降低這些成本和複雜性。此外，SMO 可以透過 O2ims 和 O2dms 對 O-Cloud 進行管理。所以看起來 Edge Cloud 就是 O-cloud 來實現。

 

圖（三）基於 Nephio 的 O-RAN 架構圖
O-RAN 整合在 Nephio 中的重點是聯邦 O-Cloud 編排與管理（FOCOM）、網路功能編排（NFO）、基礎設施管理（IMS）和部署管理（DMS）等…服務。（了解更多…）

O-RAN Working group 已經對於基於 Nephio 的 O-RAN 整合架構達成共識。而這個架構的特點為下列 2 項。此外，這兩個 Nephio instances 之間的整合只會且只需透過 O2ims 介面來完成。

• SMO FOCOM 和 SMO NFO 會透過同一個 Nephio instances / management clusters 來實現
• 而 O-Cloud IMS 則有獨立的 Nephio instances / management clusters 來實現

當然，要記得我們不能只是把 AI（或是 LLM）當成一個「workflow 自動化工具」，光是解決 Workflow、配置和執行層面的問題還不夠。從長遠來看，AI 的介入應該是動態、高適應性的，必須能夠定期評估與調整，以因應瞬息萬變的網路需求和場景。更重要的是，AI 不該只停留在技術層面，而是要真正落地到運營場景，以確保這些機制能在實際運營中順利執行，這樣才能推動市場採用，讓 AI 在電信產業的應用不只是概念，而是真正能帶來價值的變革。

什麼？Nephio 也可以替 AI 賦能？！

在人生的旅途上，有時我們不妨可以逆向思考。不只 Nephio 可以應用 AI 來增強自身功能、來改善 Workflow automation，AI 其實也能從 Nephio 身上獲得好處。這兩者之間，不只是單向賦能，而是互利共生的。

我為什麼會這樣說呢？回顧過去，產官學研界在網路管理（Network Management） 領域早已投入大量資源，建立了一整套成熟的管理框架，特別是在 EMS（設備管理系統）、NMS（網路管理系統）、OSS（運營支撐系統） 這三大領域。這些系統不僅具備清晰的架構分層、標準化介面、生命週期管理流程、可觀測性與回饋機制，更讓網路管理擁有高度的可控性與自動化能力。

但 AI 領域呢？雖說不上是初出茅廬，但應該可以說是初生之犢！對於 AI 領域而言，仍處在剛起步，還在摸索如何打造真正可持續運行的管理架構。 AI 在生命週期管理（從模型訓練、生成、部署到監控與回饋）這一塊，還缺少像 EMS/NMS/OSS 這樣的成熟機制，這也讓 AI 領域產生了一個迫切的需求——即如何構建一個全面的協調與管理系統，來處理 AI 模型的生命週期，包括模型訓練、部署（Model Push）、回饋機制（Feedback Loop）等關鍵環節。

這就讓 Nephio 成為一個值得借鑒的典範！如果我們把 Nephio 在網路管理領域的編排與自動化思想延伸到 AI 領域，讓 AI 也能具備類似 k8s pods 的生命週期管理機制，那麼 AI 與網路管理生態將能夠更緊密地融合，甚至創造全新的應用場景。

寫這一段的目的不是為了讓 Nephio 轉換研發目標或是使其失去焦點，只是單純提出一種可能性，將現有的網路管理機制引入 AI 管理框架，這確實可以成為一個有應用價值的使用案例。

AI 協助大規模自動化要記取教訓

上一段提到 AI 領域應借鑑過去網路管理領域的成熟經驗，其實在我們推動 Cloud-Native Intent-Based Networking 時，也應該牢牢記住 SDN（軟體定義網路）世界曾經走過的彎路。

從網路工程的開發演進史來看，我們經歷了從最初一步一步明確下達指令的 Imperative Programming，到相對抽象、靈活的 Declarative Programming。就如同曾建超教授在 SDN 課堂上循序漸進所教的，從最初直接下達的 Flow Rule，到稍微抽象化的 Flow Objective，最後再進階到更抽象、更接近使用者需求的 Intent。

從 Intent 一路翻譯成 flow rule 通常會有微小的延遲，但一般都會忽略。

教訓一：自動化越多，透明度越少

「任何形式的自動化都會帶來操作的不可見性」。隨著操作越來越朝向自動化。當更多 Task 被自動化系統接手之後，就意味著操作者無法清楚掌握關鍵流程的每個步驟及其執行情況，逐漸失去控制權和觀察能力。同時，也更難在發生異常時迅速定位問題根源。

以 113-1 的 SDN 期末專案為例，那個專案讓我了解，當 SDN 一切順利運作時，自動化系統簡直完美（無懈可擊）！但一旦 bug 發生，我們往往難以找出 bug 源頭或返回到初始狀態。

另一方面，隨著系統規模與複雜度的逐步提高，自動化程度亦同步增加，但是，這也可能導致系統錯誤發生率相應提高。為了避免上述問題，我們就需要建立一個具備「可觀測性（Observability）」和具有即時「反饋循環機制（Feedback Loop）」，因為只有這樣，才能確保工作人員在高度自動化的系統環境中，仍能迅速掌握系統運行狀態，並在異常發生時快速做出應對。總而來說，AI 的作用不僅在於強化 workflow 自動化，更重要的是能分析網路運行狀況，提供即時的問題偵測與處理反饋，維持操作上的透明度。

教訓二：避免像ONAP一樣包山包海，目標過大

過去 ONAP（Open Network Automation Platform）明顯遇到的一個挑戰，就是想一次性解決太多問題（試圖解決過多且範圍過廣的需求）結果反而變成很複雜的系統。當初 ONAP 設計之初，本來是想打造一個統一且全方位的自動化網路管理平台，然而，現實很骨感。這種「萬能平台」（Uber Encapsulation）理念雖然夢幻，但也使系統複雜化，帶來嚴重的整合難題、冗長的部署時間以及操作界面難以上手等實務問題，大幅降低了系統的彈性與實用性。

其實不只 ONAP，過去同時期的 OPNFV 等其他專案，也曾犯下相同的錯誤。這些專案企圖涵蓋太多領域，最後落得功能過於龐雜、系統靈活性不足、推廣困難。有鑑於這些歷史經驗，Nephio 未來在發展時必須特別注意以下幾點，以避免重蹈覆轍：

• 專注核心領域：Nephio 應聚焦於明確且有限的範圍，尤其是vRAN（虛擬化無線接入網路）及 O-RAN 相關的特定應用場景，避免一次性整合過多功能。
• 架構明確化：各個系統模組應明確定義角色與責任，特別是清晰劃分各模組間的介面，例如 SVA 等互動界面，避免角色混亂與介面含糊。(且要重點處理與 SVA 介面的互動)
• 考慮未來擴展性：以目前 O-RAN 為例，其應用尚未完全涵蓋整個 vRAN 領域。Nephio 若在設計時未充分考量介面彈性，未來擴展到新應用場景時勢必會面臨嚴重的整合難題。
• 模組化與簡化架構：從過去 ONAP 與其他專案的經驗中可以發現，架構越是模組化與簡化，越容易實現高彈性與調整性。Nephio 應著重於打造簡潔且清晰的系統架構，而非試圖一次性解決所有需求。

唯有明確且務實的策略，才可以讓 Nephio 免於遭受 ONAP 所遇到的重大困難，並且能更有效率地推動實務落地，真正為電信產業帶來價值。

結語：Nephio 與 AI 會是電信產業新未來？

說了這麼多，總結起來就一句話：Nephio 要走的路很明確，絕對不能重蹈 ONAP 那種想一次攏包包凱（包山包海）的覆轍！ Nephio 的未來就在於保持專注，清晰地劃分模組的責任，明確設計彈性互通的標準化介面，避免被任何一家設備供應商鎖死。這樣不僅能提升整個網路架構的靈活性，還能在電信產業內部形成更健康、更活躍的競爭環境。

但 Nephio 這條路上，AI 絕對是不可忽視的隊友。AI 和 Nephio 之間可謂相互借鑑、相互砥礪、相知相惜、相敬如賓、相濡以沫、相互取暖、相依為命、香蕉芭樂，它們兩個不只是技術上的結合，更可能開啟一個「網路管理與AI編排」融合的新時代。想想看，當 AI 模型的生命週期管理借助 Nephio 這種電信級的網管架構時，未來 AI 在實務中的落地豈不就更加輕鬆、更貼近真實需求？

當然，到最後了還是要說。最重要就是：在高度自動化的系統裡，Nephio 絕不能忽略「可觀測性（Observability）」與「透明的反饋循環（Feedback loop）」。不然到時候系統跑起來了，萬一出個問題卻不知道問題在哪，我想這應該誰都不願意看到。

最後秀吉純mur，雖然電信界很喜歡　（畫虎爛）　講各種前瞻、新奇技術概念，但要能真正落地轉食才是關鍵啦！Nephio 加上 AI，或許就是電信業界真正走向自動化與智慧化的關鍵一步。讓我們拭目以待，看 Nephio 能不能成為下一個真正落地、真正好用的自動化平台！

註解：

• 註1：我是覺得這個方式用來學習這個 scenario 的需求可以非常快，但僅限於學習需求然後 zero Day，但沒有想到遇到 DR
• 註2：雲端封建時代：過去那些掌握大量資本「喊水能夠結凍」的產業，如今也都得低身下氣、阿諛奉承，依照雲服務平台資本家的臉色行事。FAAMG 創造了一個顛覆傳統亞當斯密交換經濟（Exchange Economy）的新型態「掠奪」經濟模式，除了能夠任意宰割產業外，更可怕的是，雲服務平台資本家還可以直接對使用者開刀。
• 註3：sensor 獲得高溫警報事件，操作者體感也也知道最近很熱，但你以為是地球暖化，但沒人預想到2024年底會因為反聖嬰現象，導致西太平洋海域的水溫升高，隨著水溫升高，蒸發變強，水氣增加，進一步對流強化。上述總總即會導致東亞及東南亞地區氣壓下降，颱風活動增強。