Castle on a Cloud

在 上一篇文章 中, 我們介紹了 Traffic Steering 在 WG1 文件中的定義, 接著, 我們繼續看一下 WG2 中相關的 Use Case 定義, 相關文件名稱如下: O-RAN.WG2.Use-Case-Requirements-v02.01 為什麼我們要把 WG1 和 WG2 的文件分開來說呢? 在 O-RAN 的組織切分中, WG1 和 WG2 負責的功能如下: WG1: Use Cases and Overall Architecture Workgroup WG2: The Non-real-time RAN Intelligent Controller and A1 Interface Workgroup 相較 WG1 以應用情境和架構為主, WG2 著重在 Non-RT RIC 的功能, 因此, 我們預期在 WG2 的文件中, 我們可以看到更多的技術細節. 而在 WG2 的文件中, 一開始的確從相同的流程圖 (請參考 上一篇文章 ) 出發, 但是額外討論了兩個 non-RT RIC 的功能: EI (Enrichment Information) 和 A1 policy. 在 EI 的討論中, 原本 17 步驟的流程圖, 拓展成 28 步驟, 其中, 增加的步驟主要在原有步驟之後, 如下圖所示: 來自: O-RAN.WG2.Use-Case-Requirements-v03.00 在上圖, 我們可以看到 EI 參與的方式, 是由外部通知 non-RT RIC, 當有新的 EI 資訊進來後, non-RT RIC 就會開始生成資料, near-RT RIC 可以以詢問 (request) 或是訂閱 (subscription) 的方式, 取得 EI 的資訊, 輔助決策. 在 EI 的例子中, 用以輔助決策的資訊為: Radio Fingerprint, 在原本 mobility management 的架構下,  為了進行換手的判斷, UE 將會量測連線基地台 (serving eNB) 的訊號強度, 以及附近基地台的訊號強度, 當兩者強度落差到一定時, eNB 就會進行換手的程序. 然而, 考慮到量測時間的限制, 有時候 UE 無法量測到附近所有的基地台, 此時, 就可以藉由長時間的統計數據 (也就是 Radio Fingerprint

在 ORAN 的 SPEC 中, Use Case 的說明主要在以下三個文件: O-RAN.WG1.Use-Cases-Analysis-Report-v04.00 O-RAN.WG1.Use-Cases-Detailed-Specification-v04.00 O-RAN.WG2.Use-Case-Requirements-v02.01 其中, WG1-Use-Cases-Analysis-Report 範圍最廣, 定義可行的應用情境, WG1-Use-Cases-Detailed-Specification 定義需求與基本的資料流, WG2-Use-Case-Requirements 則進一步討論不同佈建下的實作, 更接近實際場景, 在應用案例的數量上, 因為 ORAN 採取的是並行的策略,  定義完成的應用情境, 也隨著要求細節的增加而逐漸減少, 我們先以三份文件中都出現的 Traffic Steering 為範例: 在 WG1 的討論中, 會將一個 Use Case 分成 4 項討論: Background and goal of the use case (應用情境的目標) Entities/resources involved in the use case (各單元的功用) Solutions (一個簡單的資料流, 各元件如何協力完成目標) Required data (E2 Node 需實作/提供的資訊) 針對以上四點, 我們從 WG1 文件中整理出以下說明: 對於 Traffic Steering 而言, 其目標考慮的不只是換手與移動性問題, 還考慮在不同無線介面 (NR, LTE, WiFi) 之間的切換, 並考慮了各節點在不同負載下, 如何透過預先資源配置, 確保通訊品質. 為了達成上述目標, 需要 Non-RT RIC, Near-RT RIC 以及 E2 Node 參與, 其中, Non-RT RIC 負責產生 policy 予 Near-RT RIC 執行, 而 E2 node 則負責資料收集, 以及換手功能的執行 Non-RT RIC 透過 O2 介面定期取得系統效能的參數, 並發起 Traffic Steering, 當發起 Traffic Steering 後, 會再次收集資料, 運算出適合的 policy, 並將 policy