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

在上一篇文章中, 我們大致介紹了在 near-RT RIC 中和 E2 介面相關的單元,

包含了: xApp, Subscription Manager (SubMngr), Routing Manager (RMR), E2 Termination (E2T).

在這一篇文章中, 我們將繼續介紹 E2 介面的訂閱流程, 我們從上次的流程圖出發:

在這張流程圖中, 我們可以看到上述五個裝置的互動, 以及交換的訊息,

其中, 一開始 xApp 和 SubMngr 先透過 RESTful API 進行註冊與確認, 訊息格式如下:

在向 SubMngr 註冊的資訊中, 包含了以下的資訊:

• SubscriptionId: 此 ID 為 xApp 產生, 但不代表此次訂閱, 真正數值由 SubMngr 產生並回填.
• ClinetEndpoint: 提供給 RMR 的資訊, 包含 hostname, RMR port
• Meid, RANFunctionID: 和訂閱的 E2 Node 相關
• E2SubscriptionDirectives: RMR 參數設定, 非必要
• SubscriptionDetails->XappEventInstanceId: 真正的 xApp 產生的 ID, xApp 以此識別訊息
• SubscriptionDetails->ActionToBeSetupList: 要透過 E2 介面進行的操作

當 SubMngr 收到註冊資訊, 會進行回報, 其中, 帶有兩個重要的資訊:

• SubscriptionId: 若成功回傳, 則用以代表此次註冊
• E2EventInstanceId: 此 ID 用以建立 E2 連線 (如果需要), 也是後續 E2T 回報時的 ID

我們可以看到, 在 E2 資訊架構中, 註冊與資料傳輸是分開進行的,

SubMngr 負責註冊, 並代理產生 E2EventInstanceId 向 RMR 和 E2T 溝通,

溝通完畢 (建立 E2 Node 至 xApp 連線後), 會以 Subscription Notification 方式告知,

其格式如下:

透過上述的資訊來回, xApp 獲得以下資訊:

• XappEventInstanceId: xApp 所給予的識別 ID, 用以判斷發起方
• SubscriptionId: SubMngr 所分配的 ID, 綁定 E2EventInstanceId 並識別註冊資訊
• E2EventInstanceId: 真實包含在 E2T 回報訊息中的 ID

這樣的機制, 可以實現 E2T 回報訊息的複用,

當 xApp 訂閱的 E2 訊息沒有被訂閱時, SubMngr 產生新的 E2EventInstanceId,

並向 RMR 以及 E2 Node 進行 E2 訊息的訂閱.

當 xApp 訂閱的 E2 訊息曾經被其他 xApp 訂閱時, SubMngr 提供對應的 E2EventInstanceId,

並且向 RMR 溝通, 更新相對應的訊息傳送的 routing table.

因此, 我們可以看一下 SubMngr 向 RMR 發送的兩種訊息, 如下所示:

在第一個訊息中, 對應的是新創的 E2 訂閱, 

因此, 此處為 E2EventInstanceId (填入 subscroption_id) 對應一個 xApp,

此處的 xApp 對應的位址包含 hostname 和 port,

第二個訊息中, 則對應一串的 xApp 位址, 包含各自的 hostname 和 port 設定.

在此情境下, SubMngr 將不會向 E2T 和 E2 Node 溝通,

而是逕自向 RMR 更新這些 E2 資訊要傳送的終端與方向, 

如下圖所示:

和第一張的流程圖相較, 我們可以發現少了和 E2T 與 E2 Node 互動的流程,

這兩種不同的訂閱模式判斷, 實作於 SubMngr 中 (紅框 Logic 處).