Castle on a Cloud

在 上一篇文章 中, 介紹了 E2 Setup 的流程以及資料傳遞的欄位, 透過上述資料交換流程, RIC 就可以得知 E2 Node 的能力以及識別方式, 之後, RIC 將透過 Subscription Procedure 向 E2 Node 訂閱相對應的資源, 相關的資料交換如下圖所示: 我們可以看到, 其訊息組合主要由 RIC Subscription Request 和 Response 組成, 其中, RIC Subscription Request 包含了下列資訊: 來自: O-RAN.WG3.E2AP-v02.00 其中, RIC Request ID 包含了 RIC 的訂閱時的識別資訊, 由 PLMN (Public Land Mobile Network) ID 和一組 RIC ID 組成, 用以表示 RIC 平台的電信營運商, 以及其對應的 RIC 編號, RAN Functional ID 包含了要向 E2 Node 訂閱服務, 在此假設 RIC 和目標 E2 Node 的連線已經透過 SubMngr 建立, 故不帶 E2 Node 識別資訊, 至於 RIC Event Trigger Definition 中則定義了驅動事件 (例如: 定時驅動), 在 E2AP 的格式中, 此欄位為 16 進位編碼, 其定義編寫於 E2SM 中. RIC Action ID /Type 則定義了當事件發生時要進行的動作 (例如: REPORT-indication), RIC Action Definition 的格式如同 RIC Event Trigger Definition 一樣, 定義於 E2SM. 另一方面, RIC Subscription Response 包含了下列資訊: 來自: O-RAN.WG3.E2AP-v02.00 除了在 Request 已經提過的 RIC Request ID, RAN Function ID 之外, 在 Response 中最重要的任務就是確認 RIC 要求的 Action 是否被接受, 若接受則放於 RIC Action Admitted List 中, 若不接受則放於 RIC Action Not Admitted List 中, 並加入原因.

在之前的一系列文章中, 介紹了 O-RAN 平台上, 如何透過 RESTful API 向 Subscription Management 註冊資訊, 在接下來的一系列文章中, 將介紹在目前 O-RAN 架構中的資料交換格式, 以及其在 E2 Application Protocal (E2AP) 標準中的規範. 首先, 我們先從 E2 Setup Request 和 E2 Setup Response 開始, E2 Setup 的流程是為了讓 RIC 知道 E2 Node 的識別方法與能力 (支援的功能), 其對應的資料交換流程如下圖所示: 來自: O-RAN.WG3.E2GAP-v01.01 在 RIC Setup Request 中, 包含以下的資訊 (Information Element, IE): Global E2 Node ID Optional: List of RAN Functions Added IE Optional: E2 Node Component Configuration Update List IE  其中, Global E2 Node ID 適用以辨別 E2 Node 的資訊, 包含了一組 gNB/eNB ID 以及其對應的 CU-DU, RU 的組成 (以 local ID 表示), 用以表示  gNB/eNB 和 CU-DU, RU 的組成,  可在 E2 Node Component Configuration Update List 中進行宣告. 我們可以看到其內容如下表所示: 來自: O-RAN.WG3.E2AP-v02.00 另一方面, RAN Functions 則代表了 E2 Node 所支援的功能, 每一個 RAN Function 包含了三項資訊: ID, Definition, Revision, 定義如下: 來自: O-RAN.WG3.E2AP-v02.00 其中, RAN Function Defination 的內容為 16 進位的字串,  並被定義於 E2 Service Model (E2SM) 中, 目前一共定有三種不同的 SM, 包含了: Network Interface (NI), KPM Monitor...