Castle on a Cloud

在最新版本 (2021/7) 的 O-RAN SPEC 中, 在 MIMO Beamforming 的 Use Case 中加入了 E2 的使用情境, 和原本的 O1 介面的應用情境相比, E2 介面更即時, 因此, 最佳化的目標也從統計上的 Beam Allocation, (原文標題為: MIMO GoB (Grid of Beams) Beamforming optimization) 改為移動性的 MRO (Mobility Robustness Optimization) 問題 (原文標題為: MIMO Beam-based Mobility Robustness Optimization) 在 near-RT RIC 的 Use Case 中 (也就是上述的 E2 應用情境), 假設前述 GoB 的模型已經由 non-RT RIC 決定 (O1 應用情境), near-RT RIC 再藉由調整 MRO 的參數 (例如: Cell Individual Offset, CIO), 來保證使用者移動性的最佳化, 其流程如下: 和 O1 Use Case 類似, 在整體的交換流程中, 可以分成 4 個部分: [Step1-Data Collection] SMO 給定 GoB 的參數, 取得網路 (RAN) 中各節點的資訊 [Step2-AI/ML Flow] near-RT RIC 訓練 AI/ML 模型 [Step3-Configuration Update] near-RT RIC  透過 E2 界面對 E2 Node 進行 MRO 設定 [Step4-Performance Monitoring] near-RT RIC 持續量測網路效能, 適時驅動重新計算模型. 在整體流程上, 和原本 O1 情境中最大的差異在於起始條件, 考慮到 E2 情境中, GoB 的設定為必需的演算法輸入,  因此, 起始條件就包含 GoB 資訊給定 (GoB Beam Pattern Infomation is available), 同時, 當 GoB 資訊改變 (GoB Beam Pattern Change) 時, 就必須重新訓練 ML/AI 演算法, GoB 的資訊除了可以透過 SMO 計算得知 (透過 O1 告知 near-R...

在此 Masive MIMO 的 Use Case 中,  和之前 Traffic Steering 以及 Indoor Positioning 的範例不同, 負責運算的單元為 nRT-RIC (RT-RIC 也有一個範例, 但尚未有內容) 因此, 通訊的介面也由 E2 介面, 改成 O1 介面. 這樣修改的主要原因是 Massive MIMO 主要在 RU 上實作, 而 RU 和 O-RAN 之間的介面就只有 O1, 因此, 計算的位置就改到 nRT-RIC 中 SMO 進行, 資料的交換流程如下圖所示: 在整體的交換流程中, 可以進一步分成 5 個部分: [Begin]  電信營運商開始流程, 或是由事件觸發 [Step1-Data Collection] SMO 發起量測資料的流程, 取得網路 (RAN) 中各節點的資訊 [Step2-AI/ML Flow]  nRT-RIC 從 SMO 中取得量測資訊, 並訓練 AI/ML 模型 [Step3-Configuration Update] SMO 透過 O1 界面對 RU 進行設定, 包含以下資訊: 水平與垂直的波束寬度, 波束的水平與垂直角 每個波束所使用的最大能量 [Step4-Performance Monitoring] SMO 持續量測網路效能, 並適時驅動重新計算模型. 值得注意的是, 由於計算的單元為 nRT-RIC, 犧牲了運算的即時性. 因此, 在此處學習的 AI/ML 模型基於網路的長期效能最佳化, 而非針對即時的網路狀況. 對於 AI/ML 網路的訓練資料則包含了目前波束設定, 使用者的歷史分布, 基地台的波束參數 (水平/垂直方向角, 波束寬度等), 網路的效能 KPI, 等資訊.  透過 AI/ML 網路的學習, 限制網路中基地台使用的波束可用方向與能量, 即可減少相鄰基地台透過波束傳輸產生的干擾.