Castle on a Cloud

E2 介面目前是 O-RAN SC 開源軟體中定義比較完整的一塊, 為了進一步了解 E2 介面的運作方式, 我們將研讀相關的內容, 主要參考自: https://docs.o-ran-sc.org/projects/o-ran-sc-ric-plt-submgr/en/latest/user-guide.html 在 near-RT RIC 平台中, O-RAN SC 花了很多精神在這部分實作, 相關的套件包含: xApp, Subscription Manager, Routing Manager, E2 Termination. 其中, xApp 為 E2 介面資料交換的發起端, 可以向 E2 Node (O-CU, O-DU, O-eNB) 訂閱以下四種類型的 E2 Node 服務: REPORT, INSERT, CONTROL, POLICY   (目前已實作 REPORT, CONTROL, POLICY 三種服務) E2 Termination (E2T) 為 E2 介面在 near-RT RIC 上的入口, 負責接收來自 E2 Node 的各式訊息, 並透過 Routing Manager (RMR) 回報給 xApp. Subscription Manager (SubMngr) 則負責管理 E2 Node 服務的訂閱, 當不同 xApp 向 E2 Node 做出重複的訂閱時, SubMngr 不會重複發送訂閱需求, 而是向 RMR 和 E2T 溝通, 直接建立新的 E2T 和 xApp 連線.  當 xApp 發起 E2 需求時, 並不是直接發送給 E2 Node, 而是透過 RESTful API 發送給 SubMngr, 發送的訊息中, 帶有自己的 xApp ID, 以及多個 E2 Node 服務需求, SubMngr 會依序, 透過佇列, 進行處理, 並和既有的 E2 Node 服務整合. 在 near-RT RIC 的架構中, SubMngr 實際上管理了 E2 Node 與 xApp 的所有連線, 因此, 對於每一組 E2 Node 服務訂閱, SubMngr 給予一組獨特的 ID (InstanceId), 此 InstanceId 可以讓 xApp 用以判斷 E2 Node 回報的資訊, 除了 InstanceId 之外, xApp

在 上一篇文章 中, 我們介紹了 AI/ML 的大致流程, 其中, 我們可以看到 AI/ML 程式的不同布署位置 (例如: near-RT RIC, non-RT RIC), 在這篇文章中, 我們將說明不同布署位置的原因, 以及其設計準則, 在 O-RAN 的架構中, 控制的流程分成三個層級: O-DU, near-RT RIC, non-RT RIC, 分別對應於: <10 ms, 10 ms~ 1 sec, >= 1sec, 三個不同的時間等級. 針對不同應用的即時性需求,  會產生不同的資料回報速度, 以及相對應的計算即時性需求. 針對計算的即時性需求, 則會衍伸出運算能力的需求, 與硬體的限制, 在這裡, 我們會發現, 即時性的需求與運算資源的能力, 正好是相悖離的, 舉例來說, near-RT RIC 通常實作於 edge server, 只有有限的運算能力, 卻要負荷小於一秒的即時運算響應. 相較之下, non-RT RIC 通常有較高的運算能力, 但在企業專網的應用中, 可能沒有深度學習訓練網路時所需要的特殊硬體 (如: 高階 GPU 顯卡). 因此, 在 O-RAN 的設想中, 就針對這樣的限制, 提出一些想法, 例如在 Scenario 1.2 中, 可以利用 non-RT RIC 用以訓練多個 ML/AI 模型, 並在 near-RT RIC 中收集即時的量測回報, 根據回報執行 AI/ML 的運算, 當環境改變時, 這些即時回報也可以上傳給 non-RT RIC 進行模型的訓練, 或是透過 A1 介面, 通知 near-RT RIC 切換使用的 AI/ML 模型. 相對 Scenario 1.2, Scenario 1.1 是一個簡化的架構, 當響應需求的即時性不高時, 可以將所有的運算 (訓練/執行) 都放在 non-RT RIC 上, 此時, near-RT RIC 的角色就像是一個代理者, 負責資料的收集與控制指令的傳遞. 在 AI/ML 的設計中,  可以看出來 O-RAN 對於如何將 AI/ML 落實於電信網路有許多的討論, 然而, 到目前為止 (v1.02版) 似乎仍有許多待定項目, 我們就先在此暫停此系列討論, 若之後有更豐富內容, 再進行更新.