Castle on a Cloud

在目前的 O-RAN 環境 (e-version) 中, 最完整的 xApp 範例仍是 Traffic Steetring, 在之前的文章中, 我們有提及了 Traffic Steering 在 O-RAN 中的 流程 與 細節 ,  但並沒有詳述其在 O-RAN Software Community (OSC) 中的實作, 其中, 主要參考的內容為:  https://wiki.o-ran-sc.org/display/IAT/Traffic+Steering+Flows 在 OSC 實作中, 我們可以以下面這張圖來解說: 在流程圖中, 有4個 xApp (KPIMON, QPd, QP, TS), 我們列舉並說明其功能: KPIMON: 以 GO 撰寫, 負責向 E2Term 訂閱資訊, 存入 SDL QPd (QP driver): 讀取 SDL 的數值, 將數值給予 QP (後續實作已併入 QP) QP (QoS Predictor): 根據 TS 的需求, 預估目標 UE 在附近 gNB 可得到的 UL/DL 資源 TS (Traffic Steering): 進行換手的決策 (寫入 log 中) 在此實作中, 其實不只有 Use Case 5: Traffic Steering 的實作, 也包含了 Use case 4: QoE Optimization 的實作, 這部份我們會在之後解釋. 同時, 我們也可以看到在這個實作中, 為了當時 O-RAN 的限制, 做出許多奇怪的設計, 例如:  QPd, QP 都是使用 python xApp 撰寫,  由於 python xApp 不支援 E2 的資料交換, 因此有一個以 GO 撰寫的 KPIMON xApp 進行 E2 資料的訂閱, 並轉傳 SDL. QPd 和 QP 的分工, 一開始應該是為了把資料接取和計算框架分開, 所以寫了兩隻 xApp 進行分工, 這部分在 Dawn 版本中, 已整合至 QP xApp 中. TS xApp 由於當初並不支援 Control 的資料下行,  因此, 只能將資料寫入 log 中, 在 Dawn 版本以後, 這部分有加入一個新的 RC (RAN Control) xApp, 試圖將 Control 訊息下達 E2 Node 中. 關於目前最新的 TS Use Case

在 上一篇文章 中, 我們介紹了 UAV 在未來通訊中的角色,  針對此類 3D 通訊應用, O-RAN 也設想了一個 Use Case,  並在此 Use Case 中明訂了三個對於通訊系統的挑戰: LOS propagation/uplink interference (直視路徑的衰減/上行的干擾),  Poor KPI caused by antenna side lobes for base stations (旁波效應造成的低通訊效能),  Sudden drop in signal strength (訊號強度的突然衰減).  上述的挑戰主要來自於 3D 波束通訊的兩難: 一方面, 我們希望波束集中, 加強使用者接收到的訊號強度, 另一方面, 集中的波束導致較小的服務範圍, 導致移動裝置通訊不穩定, 也因此, 引出了旁波 (side lope)* 低效能通訊 (訊號小幅失焦), 以及訊號強度突然衰減 (移動裝置離開可通訊的範圍). * 旁波 (side lope): 在設計通訊波束時, 主要波束方向稱為 main lope, 在 main lope 旁邊會有數個 side lope, 其訊號增益強度較低. 針對上述的挑戰, 對通訊系統而言, 可以用的手段包含: 配置額外的基地台, 提供備援的通訊波束 動態針對 UAV 進行波束的調整 此應用情境下的 UAV 作為空中的小基地台提供使用者通訊服務, 其所需要的通訊需求 (throughput) 為高頻寬的即時資料流, 需要高集中的波束服務, 另一方面, 考慮到 3D 波束通訊中, 每一個波束由多個天線所形成, 且波束間尚有因旁波造成的干擾, 需要進行整體的最佳化, 因此, 針對單一 UAV 進行波束配置的動態最佳化, 需要大量的通訊資源完成, 考慮到基站有限的通訊資源 (天線, 傳輸功率, 計算資源等),  如何配置這些資源給予不同 UAV 就形成一個問題. 考慮到在 O-RAN 的應用情境下, 無法針對 RU 提供 real-time 的控制, 取而代之的是使用 near-RT RIC 以 ML 模型的方式, 提供即時的通訊資源配置 (例如: 功率, 天線數, 頻譜) 給予其所管轄的 CU/DU,  RU 則根據通訊資源配置進行波束設計 (例如: 方向, 波束間最佳化), 此處的 ML 模型由 non-R