[ORAN] E2 介面的實作架構與資料交換 (1)

E2 介面目前是 O-RAN SC 開源軟體中定義比較完整的一塊,

為了進一步了解 E2 介面的運作方式, 我們將研讀相關的內容,

在 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 透過 RESTful API 向 SubMngr 發出訂閱需求時,

SubMngr 也會給予一個獨有的訂閱 ID (REST request id),

若 xApp 要 (刪除/重新進行) 訂閱服務, 則需要透過此 ID 進行.

若 SubMngr 收到相同 REST request id 的請求, 則可以複用之前的設定,

重新建立 xApp 以及 E2T 之間的連線, 整體資料交換流程如下圖:

Castle on a Cloud