TW202425609A

TW202425609A - 用於藉由擴展近ｒｔ及非ｒｔｒｉｃ功能來實現ｏ雲端最佳化及管理的無線電存取網路最佳化的設備及方法以及其裝置

Info

Publication number: TW202425609A
Application number: TW112137518A
Authority: TW
Inventors: 拉維尚卡拉文德蘭
Original assignee: 美商Ｆ５公司
Priority date: 2022-09-30
Filing date: 2023-09-28
Publication date: 2024-06-16
Also published as: US20240111594A1; WO2024073090A1

Abstract

揭示關於藉由擴展O雲端近RT及非RT功能達成近即時O雲端最佳化需求的技術。在一個實例中，一種方法包括經由O雲端協調器與近即時RAN智慧控制器之間的一介面接收關於O雲端工作負載最佳化之政策。該方法進一步包括判定一或多個政策情景已發生。然後將一或多個校正動作之指令自該近即時RAN智慧控制器傳輸至O雲端。該方法進一步包括經由該O雲端上之一或多個XApp執行與該等接收之指令一致的一或多個校正動作。最後，自該O雲端上之該一或多個Xapp傳輸對該一或多個校正動作之執行的確認。

Description

用於藉由擴展近RT及非RT　RIC功能來實現O雲端最佳化及管理的無線電存取網路最佳化的設備及方法以及其裝置

本文中描述之實施例通常係關於無線通信系統領域，且特別係關於無線通信系統之無線電存取網路的管理。更確切地，本文中之實施例係關於開放式RAN (O-RAN)架構，且更確切地，用於O-RAN架構中之非即時及即時最佳化的技術及方法。

隨著與各種網路裝置通信的不同類型之裝置的增加，3GPP LTE系統之使用增加。行動裝置在現代社會之滲透持續推動對廣泛多種網路化裝置的需求。隨著行動訊務的增加，行動網路及其運行設備必須變得更加軟體驅動、虛擬化、靈活、智慧且節能。經由使用無線電存取網路(RAN)技術，5G網路之通量、覆蓋範圍及穩健性提高，而潛時及營運與資本支出減小。

RAN虛擬化及朝向更多基於容器與雲端原生之RAN實施方案的走向已引起開放式RAN介面之行業範圍標準的開發。由O-RAN及3GPP推動之此等標準支援RAN設備的互通性，無論供應商為何。

如本文進一步描述的，O-RAN架構相對於3GPP所提出之現有LTE/5G RAN架構引入兩個重要的控制功能及管理功能。首先為RAN智慧控制器(RIC)，其經由開放式介面將RAN相關的控制平面無線電資源管理(RRM)及最佳化功能與供應商供應之RAN功能解耦，此與當今由供應商提供且主要與特定供應商實施方案相關的封閉SON最佳化功能形成對比。其次為亦經由開放式介面的服務管理與協調(SMO)功能，該等功能用於管理RAN之FCAPS及O雲端基礎建設。

RIC具有兩個架構組件：近RT RIC及非RT RIC。RIC為代管適用於RAN堆疊之L1/L2/L3之RRM最佳化應用程式的平台。近RT RIC代管控制迴路潛時為10 ms至1 s之最佳化功能。以遠端或邊緣雲端部署代管近RT RIC以管理關鍵任務應用程式。非RT RIC代管控制迴路延遲＞1 s之最佳化功能。非RT RIC為集中式的且與SMO位於同一地點。建議RIC平台藉由訂閱來自RAN之近即時資料來管理端對端5G服務的嚴格SLA，XApp使用該資料推理RAN系統是否在期望限制內操作，若不，則對RAN協定堆疊應用更改以達成期望的操作點。

O雲端(O-Cloud)為O-RAN架構之另一組成部分，其代管實體基礎建設及虛擬化RAN工作負載。此等經由配備有適當OS/核心、I/O、加速器之COTS平台來實現，以減輕即時DU及CU工作負載所需的某些處理。O雲端形成解耦RAN硬體及軟體之典範位移的較大部分，以允許靈活的RAN部署滿足私營企業、(子)城市、農村的需求，從而允許CU及DU基於在特定部署情境中提供的特定訊務特性及服務而以階層式雲端部署置放。

RAN目前專注於經由RIC之近即時RAN堆疊最佳化，本專利解決了另一關鍵缺失部分，即非即時及近即時O雲端最佳化，因為若底層平台無法適應RAN工作負載之動態要求，則以非即時或近即時方式保留SLA之總體目標可能失敗。

相關申請案

本申請案主張於2022年9月30日提出申請且標題為APPARATUS AND METHODS FOR RADIO ACCESS NETWORK OPTIMIZATION BY EXTENDING NEAR-RT AND NON-RT RIC FUNCTIONALITY FOR O-CLOUD OPTIMIZATION AND MANAGEMENT AND DEVICES THEREOF的美國臨時申請案第63/411,733號之優先權，該美國臨時申請案係以全文引用之方式併入本文中。

以下詳細描述參考圖式。在不同的圖式中可使用相同的元件符號來標示相同或相似的元件。在以下描述中，出於解釋而非限制目的，闡述了特定細節，諸如特定結構、架構、介面、技術等，以便提供對本揭示內容之各種態樣的透徹理解。然而，受益於本揭示內容的熟習此項技術者將顯而易見，可在背離此等特定細節之其他實例中實踐申請專利範圍之各種態樣。在某些例項中，省略對眾所周知的裝置、電路及方法之描述，以免不必要的細節模糊本揭示內容之描述。

參考圖1，支援網路可存取之客戶端-伺服器軟體應用程式100的例示性計算基礎建設可包括各種互連之計算裝置(例如，網路訊務裝置)，以潛在地提高示出之客戶端-伺服器架構的可擴縮性、可用性、安全性及/或效能。作為一個實例，諸如網路訊務管理裝置106或設備之中間伺服器電腦可邏輯地定位於試圖存取客戶端-伺服器軟體應用程式的客戶端裝置102a至102n與執行客戶端-伺服器軟體應用程式之伺服器側的伺服器電腦110a至110n之間。舉例而言，中間伺服器電腦可執行各種代理及其他服務，諸如負載平衡、速率監測、快取、加密/解密、會話管理(包括金鑰產生)、位址轉換及/或存取控制。此技術提供許多優點，包括提供跨複數個局部連接之計算子域(包括智慧型網路介面卡)的應用部署的方法、非暫態性電腦可讀媒體、網路訊務管理系統及網路訊務管理設備。

在此特定實例中，圖1中揭示了網路訊務管理設備106、伺服器裝置110a至110n及客戶端裝置102a至102n以作為專用硬體裝置。然而，網路訊務管理設備106、伺服器裝置110a至110n及客戶端裝置102a至102n中之一或多者亦可用軟體在網路訊務管理系統中之一或多個其他裝置內實施。如本文所用，術語「模組」係指作為專用硬體裝置或設備的實施方案，或由可代管一或多個其他軟體組件或實施方案之另一硬體裝置或設備代管的軟體實施方案。作為一個實例，網路訊務管理設備106以及其組件、模型或應用程式中之任一者可為實施為在伺服器裝置中之一者上執行的軟體之模組，而在其他實例中，亦可使用許多其他排列及類型的實施方案。此外，網路訊務管理設備106、伺服器裝置110a至110n及客戶端裝置102a至102n中之任一者或全部可實施且在本文中可被稱為模組。

圖2繪示習知O-RAN架構。O-RAN架構包括四個O-RAN定義之介面：A1介面202、O1介面204、O2介面206及開放式前傳管理(M)平面介面208，其將服務管理與協調框架(SMO)框架210連接至O-RAN網路功能(NF) 212及O雲端220。SMO 210亦可與外部裝置或系統連接，該外部裝置或系統可將組態資料提供至SMO 210。如進一步繪示的，A1介面202連接SMO 210中或處的O-RAN非即時(RT) RAN智慧控制器(RIC) 214及O-RAN NF 212中或處的O-RAN近RT RIC 216。如將了解，O-RAN NF 212可為虛擬化網路功能，諸如位於O雲端220之上的虛擬機器(VM)或容器及/或利用客製化硬體的實體網路功能。SMO 210與O-RAN無線電單元(O-RU) 218之間的開放式前傳M平面介面208支援O-RAN混合模型中之O-RU管理。

圖3展示對應於圖5之O-RAN架構的O-RAN邏輯架構。如將了解，O-RAN邏輯架構包括無線電部分及管理部分。架構之管理部分/側包括含有非RT RIC 304之SMO框架302及與O雲端實例相關的管理功能。O雲端306為雲端計算平台，該平台包括一系列用於代管相關O-RAN功能之實體基礎建設節點(例如，近RT RIC 308、O-RAN中央單元-控制平面(O-CU-CP) 310、O-RAN中央單元-使用者平面(O-CU-UP) 312及O-RAN分佈式單元(O-DU) 314)、支援軟體組件(例如，OS、VMM、容器運行時間引擎、ML引擎等)及適當的管理與協調功能。邏輯架構之無線電部分/側包括近RT RIC 308、O-RAN分佈式單元(O-DU) 314、O-RU 316、O-RAN中央單元-控制平面(O-CU- CP) 310及O- RAN中央單元-使用者平面(O-CU-UP) 312功能。邏輯架構之無線電部分/側亦可包括O-eNB 318。

DU 314為代管基於較低層功能劃分的RLC、MAC及較高PHY層實體/元件(高PHY層)之邏輯節點。O-RU 314為代管基於較低層功能劃分的較低PHY層實體/元件(低PHY層) (例如，FFT/iFFT、PRACH提取等)及RF處理元件之邏輯節點。O-RU 316之虛擬化為FFS。O-CU-CP 310為代管PDCP協定之RRC及控制平面(CP)部分的邏輯節點。O O-CU-UP 312為代管PDCP協定及SDAP協定之使用者平面部分的邏輯節點。

E2介面320終止於複數個E2節點處。E2節點為終止E2介面之邏輯節點/實體。對於NR/5G存取，E2節點包括O-CU-CP 310、O-CU-UP 312、O-DU 314。對於E-UTRA存取，E2節點包括O-e/gNB 318。如圖3所示，E2介面亦將O-e/gNB 318連接至近RT RIC 304。E2介面上之協定完全基於控制平面(CP)協定。E2功能分組為以下幾類：(a)近RT RIC 304服務(REPORT、INSERT、CONTROL及POLICY)；及(b)近RT RIC 304支援功能，該等功能包括E2介面管理(E2設定、E2重置、一般錯誤狀況報告等)及近RT RIC 304服務更新(例如，與經由E2暴露之E2節點功能清單相關的能力交換)。

eNB 318為支援E2介面之LTE eNB、5G gNB或ng-eNB。O-eNB 318可與先前論述之其他RAN節點相同或相似。可存在多個O-e/gNB 318，每一O-e/gNB可經由各自的介面彼此連接。

開放式前傳(OF)介面324a、324b處於O-DU功能314與O-RU功能316之間。OF介面324a、324b包括控制使用者同步(CUS)平面及管理(M)平面。圖2至圖3亦展示O-RU 316終止通往O-DU 314且視情況通往SMO 302之OF M平面介面324b。O-RU 316終止通往O-DU 314及SMO 302之OF CUS平面介面324a。

F1-c介面326連接O-CU-CP 310與O-DU 314。如3GPP所定義，F1-c 326介面處於gNB-CU-CP節點[O07]與gNB-DU節點[O10]之間。然而，出於O-RAN目的，在O-CU-CP功能310與O-DU功能314之間採用F1-c介面，同時重用3GPP定義之原理及協定堆疊及互通性設定檔規範的定義。

F1-u介面328連接O-CU-UP 312與O-DU 314。如3GPP所定義，F1-u介面328處於gNB-CU-UP節點與gNB-DU節點之間。然而，出於O-RAN目的，在O-CU-UP功能312與O-DU功能314之間採用F1-u介面328，同時重用3GPP定義之原理及協定堆疊及互通性設定檔規範的定義。

NG-c介面330由3GPP定義為5GC中的gNB-CU-CP與AMF之間的介面。NG-c 330亦被稱為N2介面。NG-u介面由3GPP定義為5GC中的gNB-CU-UP 310與UPF之間的介面。NG-u介面330被稱為N3介面。在O-RAN中，3GPP定義之NG-c及NG-u協定堆疊被重用且可經調適以用於O-RAN目的。

X2-c介面332在3GPP中被定義用於在EN-DC中在eNB之間或在eNB與en-gNB之間傳輸控制平面資訊。X2-u介面在3GPP中被定義用於在EN-DC中在eNB之間或在eNB與en-gNB之間傳輸使用者平面資訊。在O-RAN中，3GPP定義之X2-c及X2-u協定堆疊被重用且可經調適以用於O-RAN目的。

Xn-c介面334在3GPP中被定義用於在gNB之間、ng-eNB之間或ng-eNB與gNB之間傳輸控制平面資訊。Xn-u介面在3GPP中被定義用於在gNB之間、ng-eNB之間或ng-eNB與gNB之間傳輸使用者平面資訊。在O-RAN中，3GPP定義之Xn-c及Xn-u協定堆疊被重用且可經調適以用於O-RAN目的。

E1介面331由3GPP定義為gNB-CU-CP與gNB-CU-UP之間的介面。在O-RAN中，3GPP定義之E1協定堆疊被重用且經調適作為O-CU-CP功能310與O-CU-UP功能312之間的介面。

RAN非即時(RT) RAN智慧控制器(RIC)為SMO框架內之邏輯功能，該邏輯功能實現RAN元件及資源的非即時控制及最佳化；AI/機器學習(ML)工作流程，該(等)工作流程包括模型訓練、推理及更新；及近RT RIC中之應用程式/特徵的基於政策之指導。

在一些實施例中，非RT RIC為位於O-RAN架構中之SMO平台(或SMO框架)內的功能。非RT RIC之主要目標為支援非即時間隔(即，大於500 ms)之智慧無線電資源管理、RAN中之政策最佳化及將AI/ML模型插入至近RT RIC及其他RAN功能。非RT RIC終止至近RT RIC之A1介面。非RT RIC亦經由O1介面自O-RAN節點收集OAM資料。

RAN近RT RIC為一種邏輯功能，其經由E2介面上之細粒度資料收集及動作來實現RAN元件及資源的近即時控制及最佳化。近RT RIC可包括一或多個AI/ML工作流程，該等工作流程包括模型訓練、推理及更新。

非RT RIC可為代管一或多個ML模型之訓練的ML訓練主機。ML訓練可使用自RIC、O-DU及O-RU收集之資料離線執行。對於監督式學習，非RT RIC為SMO之一部分，而ML訓練主機及/或ML模型主機/參與者可為非RT RIC及/或近RT RIC之一部分。對於無監督學習，ML訓練主機及ML模型主機/參與者可為非RT RIC及/或近RT RIC之一部分。對於強化學習，ML訓練主機及ML模型主機/參與者可作為非RT RIC及/或近RT RIC之一部分位於同一位置。在一些實施方案中，非RT RIC可請求或觸發訓練主機中之ML模型訓練，而不管模型在何處部署及執行。ML模型可能經過訓練，但目前尚未部署。

在一些實施方案中，非RT RIC為ML設計者/開發者提供可查詢的目錄以發布/安裝經過訓練之ML模型(例如，可執行軟體組件)。在此等實施方案中，非RT RIC可在特定ML模型可在目標ML推理主機(MF)中執行的情況下提供發現機制，及可在MF中執行的ML模型之數目及類型。舉例而言，非RT RIC可發現三種類型之ML目錄：設計時間目錄(例如，駐留在非RT RIC外且由一些其他ML平台代管)、訓練/部署時間目錄(例如，駐留在非RT RIC內)及運行時間目錄(例如，駐留在非RT RIC內)。非RT RIC支援ML模型推理之必要能力，以支援在非RT RIC或某一其他ML推理主機中運行的ML輔助解決方案。此等能力使得能夠安裝可執行軟體，諸如VM、容器等。非RT RIC亦可包括及/或操作一或多個ML引擎，該一或多個ML引擎為提供用於運行ML模型之方法、常式、資料類型等的套裝軟體可執行程式庫。非RT RIC亦可實施政策以在不同的操作條件下切換及啟動ML模型實例。

非RT RIC可經由O1介面存取關於ML模型效能之回饋資料(例如，FM及PM統計資料)且執行必要的評估。若ML模型在運行時間期間失敗，則可產生警報以作為至非RT RIC之回饋。ML模型在預測準確度或其產生之其他操作統計資料方面的執行情況亦可經由O1發送至非RT RIC。非RT RIC亦可藉由觀察MF中之資源利用率經由O1介面來縮放在目標MF中運行的ML模型實例。運行ML模型實例之環境(例如，MF)監測正在運行的ML模型之資源利用率。此監測可例如使用連續監測資源利用率的稱為近RT RIC及/或非RT RIC中之資源監測器(ResourceMonitor)的ORAN-SC組件來進行。若資源較少或低於某一臨限值，則近RT RIC及/或非RT RIC中之運行時間環境提供縮放機制以新增更多的ML實例。縮放機制可包括比例因數，諸如用於放大/縮小ML實例之數目的數字、百分比及/或其他類似資料。藉由觀察MF中之資源利用率，可自動縮放在目標ML推理主機中運行之ML模型實例。舉例而言，Kubernetes® (K8s)運行時間環境通常提供自動縮放特徵。

A1介面處於非RT RIC (在SMO內部或外部)與近RT RIC之間。A1介面支援三種類型之服務，包括政策管理服務、豐富資訊服務及ML模型管理服務。與持久性組態相比，A1政策具有以下特性：A1政策對於訊務為非關鍵的；A1政策暫時有效；A1政策可處理個別UE或動態定義的UE群組；A1政策在組態內運作且優先於組態；及A1政策為非持久性的，即在近RT RIC重新啟動後不會繼續存在。

如圖2及圖3所示，可組態以下O-RAN介面： (a) A1介面處於非RT-RIC功能與近RT RIC功能之間；A1與控制平面功能及使用者平面功能之政策指導相關聯；與A1相關聯之受影響O-RAN元件包括O-RAN節點； (b) O1介面處於O-RAN受管元件與管理實體之間；O1與管理平面功能、組態及臨限值設定相關聯，主要為OAM及FCAPS功能至O-RAN網路功能；與O1相關聯的受影響O-RAN元件主要包括O-RAN節點； (c) O2介面處於SMO與基礎建設管理架構之間；O2與雲端基礎建設及分配給O-RAN之雲端資源、O雲端之FCAPS的管理相關聯；與O2相關聯之受影響O-RAN元件包括O雲端； (d) E2介面處於近RT RIC與E2節點之間；E2與控制平面及使用者平面控制功能相關聯；與E2相關聯之受影響O-RAN元件包括E2節點；E2-cp處於近RT RIC與O-CU-CP功能之間。E2-up處於近RT RIC與O-CU-UP功能之間；E2-du處於近RT RIC與O-DU功能之間。E2-en處於近RT RIC與O-eNB功能之間；及 (g) 開放式前傳介面處於O-DU功能與O-RU功能之間；此介面與CUS (控制使用者同步)平面與管理平面功能及FCAPS至O-RU相關聯；與開放式前傳介面相關聯之受影響O-RAN元件包括O-DU功能及O-RU功能。

O雲端為代管RAN功能之分佈式基礎建設的關鍵部分，其包括CU-UP、CU-CP、DU及RIC。在操作期間，O雲端預計將在實體層次、虛擬層次及工作負載層次產生大量的健康及效能相關資料。實體層次資料與實體裝置(NIC、處理器、OS、加速器、交換器或儲存節點)有關，此資料包括電力或能量度量、操作狀態、如溫度或風扇速度之實體參數等。資料可為工作負載或非工作負載相關度量，諸如操作狀態、總利用率、溫度等。虛擬層次(叢集層次)資料與管理虛擬化功能之功能(諸如CRI、Kubelet、工作負載、CNI外掛程式及裝置驅動程式)的健康有關，且亦與效能度量有關，效能度量諸如每一虛擬化資源(諸如加速器、CPU、記憶體等)之總體利用率，或專用於工作負載之此等虛擬資源中之每一者的電力/能量消耗。工作負載相關資料係關於與特定工作負載相關的可用及已利用的VF資源。此關鍵資料可用於驅動近RT或非RT RIC中所代管的AI/ML功能，以預測o雲端基礎建設(計劃的或反應性的)之任何異常，或伺服於能量最佳化目標且採取補救動作，諸如無縫工作負載遷移至另一主機，從而避免任何服務中斷。

解決近即時O雲端最佳化之當前方法主要依賴於使用非RAN無關功能，該等功能實現為站點或叢集範圍的O雲端虛擬化平台軟體(例如，K8S控制器)之一部分，或經由SMO中之長時間標度最佳化智慧及利用集中式SMO與分佈式O雲端實例之間的O2-ims介面及O2-dms介面來實現。如將了解，O雲端分佈式站點可能有數千個，因此亦引起可擴縮性問題。到目前為止，此等解決方案尚不能滿足近RT最佳化要求。

圖4至圖9繪示目前揭示之技術的各種實施例。如下文進一步展示及描述的，揭示之技術旨在解決由於O雲端平台之工作負載、故障效能或定時/同步降級的動態變化而影響CU/DU效能的近即時O雲端最佳化要求。此等動態變化需要動態適應諸如計算、記憶體、加速器或I/O資源的底層O雲端資源，以滿足DU或CU之近即時要求。此外，系統可能需要來自底層實體及虛擬化平台的對RAN工作負載之近即時通知服務暴露，以允許採取校正動作。

本技術之實例要求最佳化功能以類似RRM XApp之近RT標度操作，以便自O雲端可程式性角度滿足近RT要求。此需要類似於RAN之功能(即，O雲端中心XApp)作為近RT RIC及非RT RIC平台之一部分操作，使得O雲端/R-App可在分佈式O雲端/X-App中設定政策，且O雲端X-App可向O雲端的IMS及DMS子系統訂閱相關資料且執行控制功能以滿足政策要求。如圖3至圖9中所繪示的，所描述技術之實例擴展近RT及非RT RIC以代管與O雲端相關的虛擬化資源、恢復、基礎建設故障排除、節能及最佳化功能。此外，建議之解決方案可預測或應對硬體、虛擬化或工作負載之任何異常，且採取補救措施以減輕對RAN服務之任何干擾。另外，RRM/XApp亦可與O雲端平台通信以訂閱與實體、虛擬或工作負載特定功能相關的資料，且請求任何額外資源以滿足未來對特定DU或CU集合之預期需求。

圖4繪示具有A1介面402及E2介面404之更新的O-RAN邏輯架構。如所繪示的，該架構包括對當前A1介面402及E2介面404之擴展。如下文進一步描述的，該等擴展允許O雲端Xapp之生命週期管理、Xapp之政策管理及使用IMS及DMS功能的O雲端實例之資料訂閱/控制。確切地，A1-O2*擴展406允許在操作中的O雲端相關XApp中設定政策以最佳化實體及虛擬工作負載資源。E2-O2*擴展408擴展針對CU及DU提出的語意及API，且作用於來自O雲端之近RT資料且採取行動以達成特定政策目標。如將了解，此允許第三方O雲端XApp的請求及應用實體硬體調諧及最佳化或虛擬化層中的控制之標準化方法。

O雲端XApp可為用於管理叢集中之O雲端資源的獨立服務，或可補充RAN/X-App以維持RAN服務及功能之政策目標。舉例而言，RAN/X-App可用於將資源垂直地或水平地向外擴展或向內擴展。此類O雲端X-App之目的可類似於RRM，亦即根據RAN工作負載之變化的需求來監測且控制及調適O雲端實例之行為。舉例而言，訊務操縱X-App/R-App在監測與DU相關聯之小區之利用率的同時可與O雲端X-App/R-App介接以擴展對小區中之使用者訊務之動態有反應的資源，資源包括CPU核心、大頁、I/O、加速器資源等，或建立網路功能之新實例。作為另一實例，監測主機或虛擬化資源之獨立o雲端X-App/R-App在發現與主機或虛擬化資源相關之健康或效能度量有任何異常的情況下可起始工作負載遷移。在另一實例中，O雲端Xapp可用於監測代管DU功能之每一主機的時間同步。任何偵測到之同步缺失可調用諸如檢查與PTRC/GM或邊界時鐘開關之PTP連接的步驟。

如將了解，圖4中繪示之架構可允許使用O1/O2介面來完成O雲端Xapp之自動生命週期管理(LCM)。此外，SMO/非RT RIC介面功能可經擴展以使用來自O2之資料來訓練AI/ML模型。此等ML模型因而可經由A1-O2由非RT RIC進行管理以實現近RT最佳化目標。

圖5繪示併入有在上文關於圖4描述之新增介面的更詳細系統架構圖。如圖5中所繪示，揭示之技術包括非RT RIC中之一組新的O雲端RApp，標記為O雲端/RApp。與RRM功能一樣，此等應用程式為使用案例特定的。舉例而言，RApp可經設計以設定分佈式O雲端/XApp之資源目標，專注於O雲端基礎建設及網路功能之最佳化方面，該等方面包括資源、恢復、基礎建設故障排除、節能最佳化功能。如進一步繪示的，揭示之技術亦包括位於近RT RIC實例中之一組應用程式，標記為O雲端/XApp。如所繪示的，O雲端/XApp自RApp接收政策目標且與本地IMS/DMS功能介接以獲取近RT資料，且以程式設計方式做出反應以設定組態參數以滿足O雲端服務目標。另外，O雲端/RApp可經組態以與非RT平台中之RRM/RApp介接，而O雲端/XApp可經組態以經由API與近RT平台中之RRM/XApp介接，以影響與RAN工作負載相關聯之O雲端資源的變化或訂閱RAN工作負載可靠運作所需的資料。

如將了解，O雲端/RApp及O雲端/XApp功能可利用非RT RIC及近RT平台進行資料存取、XApp間通信且利用諸如O2/A1/E2的協定終止功能來實現其自身的目標。除了RRM資料之外，資料庫亦可經組態以管理來自O雲端實體、虛擬或工作負載功能之資料。

圖6繪示併入有在上文關於圖4描述之新增介面的更詳細系統架構圖。在本揭示內容之一實例中，A1介面經擴充以識別一組新的API以設定O雲端Xapp 610特定之政策。舉例而言，如圖6中所繪示，A1-O2*介面406可允許O雲端/RApp 612與O雲端/Xapp 610之間的互動。如將了解，O雲端/XApp 610暴露API以設定以一組特定的RAN工作負載(DU及CU)為目標的局部化O雲端中心意圖。此等意圖或宣告性規則可包括與能量利用或政策、CPU、記憶體、I/O或加速器使用、定時/同步可容忍錯誤相關之參數的臨限值極限。如將了解，API為應用程式特定的。因此，取決於o雲端最佳化目標，其可包括實體基礎建設、叢集服務、虛擬管理系統或特定RAN工作負載之先前提及的政策目標的全部或子集。O雲端/RApp使用此等API來設定O雲端/Xapp中之政策目標。經由A1-O2* 406之政策回饋(成功或失敗，或任何中間狀態)可與經由O2 616之PM資料相關以量測政策之成功。亦可為A1-O2* 406提供o雲端/X-App 610之豐富資訊，亦即在可自o雲端IMS/DMS來源獲得之內容之外的外部來源。

此外，A1/O2*介面406亦可用於作為O雲端/XApp之一部分執行的ML模型管理。來自O雲端實例之資料可供SMO及非RT使用。舉例而言，RRM/Rapp功能可與對應的O雲端/Rapp協調以實現意圖政策管理、一致性或定案。

如圖6中進一步繪示的，E2-O2*介面408可經組態以在O雲端604中終止而非終止於RAN功能(CU/DU)。IMS系統606及DMS系統608暴露服務模型，該等服務模型識別由用於虛擬化資源及受管理的工作負載兩者的實體基礎建設、叢集及網路功能管理層暴露之PM/FM或控制API。此等服務模型允許O雲端/XApp 610訂閱特定度量，設定在違反某些臨限值的情況下對通知的觸發，設定用於在違反某些條件的情況下採取某些動作或等待O雲端/Xapp 610觸發動作的政策。先前描述之額外API亦適用於新描述之E2-O2*介面408。舉例而言，可實現新的E2-SM介面以處置O雲端功能特定之使用案例。特定的E2SM API (例如，資料、政策、控制等特定的)可基於特定使用案例進行組態。如所繪示，RRM Xapp 612可與相關聯的O雲端Xapp 610介接以協調O雲端資源管理功能、效能管理(資料訂閱)、警報/故障通知及其他相關功能。

圖7繪示O-RAN邏輯架構之子集，其中對O1介面及O2介面進行了更新。如所繪示，O1*介面702已更新以管理O雲端Xapp之組態及資料訂閱，且O2*介面704已更新以管理O雲端XApp之LCM。舉例而言，O1*介面702可管理O雲端/XApp之組態及資料訂閱及其以服務為中心的生命週期管理，且O2*介面704可管理O雲端/XApp之上載、部署、啟動、生命週期及資源管理，從而考量到此等XApp亦將包括可能需要GPU資源之ML推理O雲端模型。如將了解，此種組態允許與O雲端Xapp之O2/O1介面可提供與RRM Xapp之功能類似的功能。如前所述，此種改良將確保RAN服務之高可用性。

圖8繪示O-RAN邏輯架構之子集，其中對O1介面及O2介面進行了更新。如將了解，FOCOM 802為SMO之一部分，該部分管理O雲端實體及虛擬基礎建設，且NFO 804為SMO之一部分，該部分用於管理NF部署之生命週期。在揭示之技術中，O雲端/RApp 806可訂閱來自FOCOM 802及NFO 804之資料且通過O2介面經由FOCOM 802及NFO 804應用政策及控制動作。SMO中之FOCOM 802管理O雲端基礎建設及叢集實例的LCM，而NFO 804管理虛擬網路功能(VNF)或容器化網路功能(CNF)的LCM。

作為一實例，O雲端/RApp 806管理政策且亦包括用於強制執行政策之邏輯。在此情況下，取決於O雲端應用之政策要求，Rapp 806將通過O2-i-p介面808/o2-i-m介面810經由FOCOM 802及NFO 804訂閱相關資料，且在違反政策要求的情況下通過該等介面執行控制動作。取決於動作為對實體基礎建設之動作抑或與NF管理動作相關之動作，向FOCOM 802及NFO 804通知此等動作。在此情況下，FOCOM 802及NFO 804中之控制應用程式經由O2介面來映射此等動作。

作為又一實例，FOCOM 802及NFO 804亦可包括用於管理政策及調用控制動作之邏輯。在此情景中，O雲端/Rapp 806中之政策管理應用程式將經由O2-i-p介面808/o2-i-m介面810將政策要求傳送至FOCOM 802及NFO 804。FOCOM 802及NFO 804中之控制應用程式將訂閱來自O雲端之相關資料且在違反任何政策時經由O2介面調用控制動作。FOCOM 802/NFO 804中之政策管理然後可向O雲端/Rapp 806通知所請求之政策的狀態(成功或失敗)。

揭示之技術可用於解決各種使用案例情景。舉例而言，典型使用案例可為在體育場、機場、購物中心或密集城市環境中出現的瞬間擁擠情景。在瞬間擁擠情景期間，特定地理位置將經歷網路訊務大幅上升，從而導致由同一DU管理的一組相鄰RAN小區站點出現擁塞。此外，通常相關CU最終亦將注意到訊務激增。在傳統系統中，RAN XApp將經由訊務操縱對此做出反應，此涉及平衡小區之間的訊務負載。如將了解，這在此情景中可能不起作用，因為相鄰小區亦為高負載的。

揭示之技術可用於先驗地以必要的政策目標實例化O雲端/X-App以監測DU及CU資源需求，且使O雲端/X-App請求增加至DMS系統的計算、記憶體或加速器資源以為處置額外負載之DU及CU提供更多資源，或減少計算、記憶體或加速器資源以節省每一O雲端站點處的能量。此請求可經由藉由O雲端/X-App暴露之API觸發，以向可在近RT時間尺度中調用之RRM/XApp請求對資源進行向內/向外擴展。圖9繪示此種實例情況之資料流圖900。如所繪示，紅色所示之異動表示由所描述技術實現之互動。如將了解，雖然對於大多數使用案例情景來說整體流程為相同的，但O雲端/RApp及O雲端/XApp中之政策集合、資料訂閱及控制調用API的細節將會不同。

如所繪示，在步驟(1)中，SMO 902使用O2-ims介面來供應O雲端實例，將在該O雲端實例上代管RAN工作負載。在步驟(2)中，SMO 902供應RAN工作負載，即DU、CU-UP 910及CU-CP。在步驟(3)中，SMO 902供應O雲端/Rapp 904及RRM/RApp以用於控制及管理RAN工作負載。在步驟(4)中，SMO 902亦供應O雲端/XApp 904及RRM/Xapp 908以用於對在RAN工作負載中代管之服務進行近RT最佳化及控制。在步驟(5)中，O雲端/Xapp 906向O雲端/Rapp 904註冊，使得能夠在FE或邊緣中被發現。

如進一步所繪示，在步驟(6)中，O雲端/RApp 904設定O雲端/XApp 906 中之政策以監測專用於RAN工作負載之O雲端資源。在此情景中，其必須識別O雲端ID，且對於每一O雲端實例，在DMS實例之上下文中唯一地識別DU及CU-UP 910實例之集合。對於每一虛擬化工作負載，O雲端/RApp 904設定與RAN工作負載相關之參數(諸如功率/能量、計算、記憶體、I/O或加速器資源)的臨限值。臨限值可為統計度量，諸如自總體角度為特定工作負載或為主機本身量測的特定PM之平均值、最大值/最小值、變異數。此外，在步驟(7)及步驟(8)中，基於政策要求，O雲端/Xapp 906經由管理O雲端及RAN工作負載之IMS功能914/DMS功能916來訂閱PM/FM度量。另外，假設RRM/XApp 908已經過政策組態且訂閱來自RAN工作負載之PM/FM資料。

在步驟(9)中，存在自DU/CU 910至RRM/Xapp 908的具有表明此情形之度量的通知。如將了解，此種通知會在由O雲端/Xapp 906管理之O雲端實例下在一組DU或CU所伺服之小區中的進行中瞬間擁擠情景期間發生。在步驟(10)中，處於同一近RT實例下的RRM/XApp 908及O雲端/Xapp 906使用O雲端/XApp 906暴露之API以使至此等RAN工作負載之底層O雲端資源增加。在步驟(11)中，O雲端/XApp 906然後調用DMS之適當控制API以增加用於管理觀察到瞬間擁擠之一組小區的彼等RAN工作負載的計算、記憶體、I/O或加速器資源。在步驟(12)中，O雲端/XApp 906確認對RRM/Xapp 908之請求成功完成。最後，在步驟(13)中，RRM/Xapp 908然後組態CU/DU 910/RU 912以利用更多頻譜資源進行操作，從而利用現在可供vRAN工作負載支配的額外O雲端資源。

此實例中之網路訊務管理系統之伺服器裝置中之每一者包括由匯流排或其他通信鏈路耦合在一起之(多個)處理器、一記憶體及一通信介面，但亦可使用其他數目或類型之組件。此實例中之伺服器裝置可包括例如應用程式伺服器、資料庫伺服器、存取控制伺服器或加密伺服器，該等伺服器沿著基於應用程式邏輯預期之通信路徑交換通信，以便促進客戶端裝置之使用者與應用程式的互動。

儘管伺服器裝置被示出為單一裝置，但伺服器裝置中之每一者的一或多個動作可分佈在一或多個不同的網路計算裝置上，該一或多個不同的網路計算裝置一起構成伺服器裝置中之一或多者。此外，伺服器裝置不限於特定組態。因此，伺服器裝置可含有使用主/從方法操作之網路計算裝置，由此伺服器裝置之網路計算裝置中之一者操作以管理或以其他方式協調其他網路計算裝置的操作。伺服器裝置可作為例如叢集架構、對等架構、虛擬機器內或雲端架構內的複數個網路計算裝置來操作。

因此，本文中揭示之技術不應被解釋為限於單一環境，且亦設想其他組態及架構。舉例而言，伺服器裝置中之一或多者可在網路訊務管理設備本身內操作，而非作為經由通信網路與網路訊務管理設備通信的獨立伺服器裝置來操作。在此實例中，伺服器裝置中之一或多者在網路訊務管理設備之記憶體內操作。

此實例中之網路訊務管理系統之客戶端裝置包括可交換網路資料的任何類型之計算裝置，諸如行動、桌上型、膝上型或平板計算裝置、虛擬機器(包括基於雲端之電腦)或類似物。此實例中之客戶端裝置中之每一者包括一處理器、一記憶體及一通信介面，其等藉由匯流排或其他通信鏈路(未示出)耦合在一起，但亦可使用其他數目或類型之組件。

客戶端裝置可運行介面應用程式，諸如標準網頁瀏覽器或獨立客戶端應用程式，該等介面應用程式可提供用於經由通信網路對伺服器裝置中之一或多者發出請求且接收儲存於伺服器裝置中之一或多者上的內容的介面。客戶端裝置可進一步包括諸如顯示螢幕或觸控螢幕的顯示裝置或諸如例如鍵盤(未示出)的輸入裝置。另外，客戶端裝置中之一或多者可經組態以執行軟體碼(例如，網頁瀏覽器內之JavaScript碼)，以便記錄客戶端側資料且將記錄之資料提供至網路訊務管理設備，如稍後將更詳細地描述及示出的。

儘管本文中描述且示出了具有網路訊務管理設備、伺服器裝置、客戶端裝置及通信網路之例示性網路訊務管理系統，但可使用其他拓撲中的其他類型或數目之系統、裝置、組件或元件。將理解，本文中描述之實例的系統係出於例示性目的，因為用於實施該等實例之特定硬體及軟體的許多變化為可能的，如熟習相關領域之技術人員將了解的。

網路安全系統中繪示之組件(諸如網路訊務管理設備、伺服器裝置或客戶端裝置)中之一或多者例如可經組態以作為虛擬實例在同一實體機器上操作。換言之，網路訊務管理設備、伺服器裝置或客戶端裝置中之一或多者可在同一實體裝置上操作，而非作為經由通信網路通信之單獨裝置來操作。另外，可存在比圖1所示更多或更少的網路訊務管理設備、客戶端裝置或伺服器裝置。

另外，兩個或更多個計算系統或裝置可取代任何實例中之系統或裝置中之任一者。因此，亦可根據需要實施分佈式處理之原理及優點，諸如冗餘及複製，以提高該等實例之裝置及系統的穩健性及效能。該等實例亦可在使用任何合適的介面機制及訊務技術跨任何合適的網路擴展之電腦系統上實施，僅舉例說明，包括無線訊務網路、蜂巢式訊務網路、封包資料網路(PDN)、網際網路、內部網路及其組合。

對於本技術之一或多個態樣，該等實例亦可體現為上面儲存有指令(例如在記憶體中)之一或多種非暫態性電腦可讀媒體，如藉由實例在本文中描述及示出的。一些實例中之指令包括可執行碼，可執行碼在由諸如處理器的一或多個處理器執行時導致該等處理器實行實施本文中描述且示出的本技術之實例之方法必需的步驟。

在如此描述本發明之基本概念後，熟習此項技術者將顯而易見，前述詳細揭示內容意欲僅以舉例方式呈現且並非限制性的。將想到各種更改、改良及修改且該等更改、改良及修改係針對熟習此項技術者的，儘管在本文中沒有明確陳述。此等更改、改良及修改意欲特此提出，且在本發明之精神及範疇內。此外，除了在申請專利範圍中可能指定之外，所列舉之處理元件或序列之次序、或數字、字母或其他指稱之使用並不意欲將所主張保護之程序限於任何次序。因此，本發明僅受以下申請專利範圍及其等效物限制。

100:網路可存取之客戶端-伺服器軟體應用程式 102a~102n:客戶端裝置 106:網路訊務管理設備/網路訊務管理裝置 110a~110n:伺服器裝置/伺服器電腦 202:A1介面 204:O1介面 206:O2介面 208:開放式前傳管理(M)平面介面 210:服務管理與協調框架(SMO)框架 212:O-RAN網路功能(NF) 214:O-RAN非即時(RT) RAN智慧控制器(RIC) 216:O-RAN近RT RIC 218:O-RAN無線電單元(O-RU) 220:O雲端 302:SMO框架/SMO 304:非RT RIC 306:O雲端 308:近RT RIC 310:O-RAN中央單元-控制平面(O-CU-CP)/O-CU-CP功能/gNB-CU-UP 312:O-RAN中央單元-使用者平面(O-CU-UP)/O-CU-UP功能 314:O-RAN分佈式單元(O-DU)/O-DU功能 316:O-RU/O-RU功能 318:O-eNB/O-e/gNB 320:E2介面 324a:開放式前傳(OF)介面/OF CUS平面介面 324b:開放式前傳(OF)介面/OF M平面介面 326:F1-c介面/F1-c 328:F1-u介面 330:NG-c介面/NG-c 332:X2-c介面 334:Xn-c介面 402:A1介面 404:E2介面 406:A1-O2*擴展/A1-O2*介面/A1-O2*/A1/O2*介面 408:E2-O2*擴展/E2-O2*介面 604:O雲端 606:IMS系統 608:DMS系統 610:O雲端Xapp/O雲端/XApp 612:O雲/RApp/RRM Xapp 616:O2 702:O1*介面 704:O2*介面 802:FOCOM 804:NFO 806:O雲端/RApp 808:O2-i-p介面 810:o2-i-m介面 900:資料流圖 902:SMO 904:O雲端/Rapp 906:O雲端/XApp 908:RRM/Xapp 910:DU/CU/CU-UP 912:RU 914:IMS功能 916:DMS功能

Claims

一種與包含一或多個網路基礎建設裝置、伺服器裝置或客戶端裝置之一網路系統協作實施的O-RAN最佳化方法，該方法包含：經由O雲端協調器與近即時RAN智慧控制器(「近RT RIC」)之間的一介面接收關於O雲端工作負載最佳化之多個政策；判定一或多個政策情景已發生；經由該近RT RIC上之一或多個XApp訂閱與關於O雲端工作負載最佳化之該等政策相關聯的資料；將一或多個校正動作之多個指令自該近RT RIC傳輸至O雲端；經由該O雲端上之一控制應用程式執行與該等指令一致的該一或多個校正動作；及自該O雲端上之一或多個Xapp傳輸對該一或多個校正動作之執行的確認。
如請求項1之方法，其中該近RT RIC上之該一或多個Xapp經組態以接收來自該O雲端及來自外部來源之資料。
如請求項1之方法，其中該一或多個XApp中之一Xapp經組態以監測與一DU相關聯之小區的利用率且與其他O雲端資源介接以回應於偵測到之訊務動態地縮放資源。
如請求項1之方法，其中該一或多個XApp包含可操作地連結以執行協調操作之複數個XApp。
如請求項4之方法，其中該一或多個XApp經組態以與該O雲端之IMS及DMS介接以執行資源管理功能。
一種經組態以在一開放式無線電存取網路(「ORAN」)中使用的近即時RAN智慧控制器(「近RT RIC」)裝置，該近RT RIC裝置包含：記憶體，該記憶體包含儲存於其上之程控指令；及一或多個處理器，該一或多個處理器經組態以能夠執行該等儲存之程控指令以：經由O雲端協調器中之非即時RAN智慧控制器(「非RT RIC」)與該近RT RIC之間的一介面接收關於O雲端工作負載最佳化之多個政策；判定一或多個政策情景已發生；經由該近RT RIC上之一或多個XApp訂閱與關於O雲端工作負載最佳化之該等政策相關聯的資料；將一或多個校正動作之指令自該近RT RIC傳輸至O雲端；自該O雲端上之一或多個Xapp接收對該一或多個校正動作之執行的確認；及分析自該O雲端接收之資料以驗證校正動作已發生。
如請求項6之近RT RIC裝置，其中該O雲端上之該一或多個Xapp經組態以接收來自該O雲端及來自外部來源之資料。
如請求項6之近RT RIC裝置，其中該一或多個XApp中之一Xapp經組態以監測與一DU相關聯之小區的利用率且與其他O雲端資源介接以回應於偵測到之訊務動態地縮放資源。
如請求項6之近RT RIC裝置，其中該一或多個XApp包含可操作地連結以執行協調操作之複數個XApp。
如請求項9之近RT RIC裝置，其中該一或多個XApp經組態以與該O雲端之IMS及DMS介接以執行資源管理功能。
一種非暫態性電腦可讀媒體，其上儲存有包含可執行碼之指令，該可執行碼在由一或多個處理器執行時使該等處理器：經由O雲端協調器與近即時RAN智慧控制器(「近RT RIC」)之間的一介面接收關於O雲端工作負載最佳化之多個政策；判定一或多個政策情景已發生；經由該近RT RIC上之一或多個XApp訂閱與關於O雲端工作負載最佳化之該等政策相關聯的資料；將一或多個校正動作之多個指令自該近RT RIC傳輸至O雲端；經由該O雲端上之一控制應用程式執行與該等指令一致的該一或多個校正動作；及自該O雲端上之一或多個Xapp傳輸對該一或多個校正動作之執行的確認。
如請求項11之非暫態性電腦可讀媒體，其中該O雲端上之該一或多個Xapp經組態以接收來自該O雲端及來自外部來源之資料。
如請求項12之非暫態性電腦可讀媒體，其中該一或多個XApp中之一Xapp經組態以監測與一DU相關聯之小區的利用率且與其他O雲端資源介接以回應於偵測到之訊務動態地縮放資源。
如請求項11之非暫態性電腦可讀媒體，其中該一或多個XApp包含可操作地連結以執行協調操作之複數個XApp。
如請求項14之非暫態性電腦可讀媒體，其中該一或多個XApp經組態以與該O雲端之IMS及DMS介接以執行資源管理功能。
一種無線電存取網路系統，該無線電存取網路系統包含一或多個網路管理設備、伺服器裝置或客戶端裝置、記憶體及一或多個處理器，該記憶體包含儲存於其上之程控指令，該一或多個處理器經組態以能夠執行該等儲存之程控指令以：經由O雲端協調器與近即時RAN智慧控制器之間的一介面接收關於O雲端工作負載最佳化之政策；判定一或多個政策情景已發生；將一或多個校正動作之多個指令自該近即時RAN智慧控制器傳輸至O雲端；經由該O雲端上之一或多個XApp執行與該等接收之指令一致的該一或多個校正動作；及自該O雲端上之該一或多個Xapp傳輸對該一或多個校正動作之執行的確認；及產生局部連接之計算子域的複數個超管理器之間的一橋。
如請求項16之無線電存取網路系統，其中該O雲端上之該一或多個Xapp經組態以接收來自該O雲端及來自外部來源之資料。
如請求項16之無線電存取網路系統，其中該一或多個XApp中之一Xapp經組態以監測與一DU相關聯之小區的利用率且與其他O雲端資源介接以回應於偵測到之訊務動態地縮放資源。
如請求項16之無線電存取網路系統，其中該一或多個XApp包含可操作地連結以執行協調操作之複數個XApp。
如請求項16之無線電存取網路系統，其中該一或多個XApp經組態以與該O雲端之IMS及DMS介接以執行資源管理功能。