[ORAN] RIC Indication Procedure

RIC 和 E2 Node 之間的訊息交換就算完成,

兩者之後的互動, 就按照 RAN function 和其中的 Action 定義,

在所有的互動中, Indication 是最早被實作出來的項目.

事實上, Indication 並不是一種 E2 Application Protocol (E2 AP) 定義的功能,

在 E2 AP 中, 四種功能型態分別為: REPORT, INSERT, CONTROL, POLICY.

Indication 的資料通常被包含在 REPORT, INSERT 兩個功能項內,

其中的的差別在於, REPORT 為比較單純的資料回報,

INSERT 則牽涉到 E2 Node 的控制 (回報後, 等待新的控制訊息下達).

[註] 目前 xApp-bouncer 的實作就接近 INSERT 的方式,

換句話說, 就是 xApp 收到一個 Indication 後就送一個 CONTROL 給 E2 Node.

然而, xApp-bouncer 的實作並非標準的 INSERT 實作,

其 subscription 的 RAN function 仍為 REPORT,

CONTROL 也未按 E2 AP 格式, 而是以字串方式傳送.

回到這次的主題, 我們討論的應是 Indication-REPORT 的範例,

如第一張圖所示, Indication 所帶的資訊可以分成三類:

識別資訊: RIC Request ID IE, RAN Function ID IE, RIC Action ID IE
資訊內容: RIC Indication Type IE, RIC Indication Header IE, RIC Indication Message IE
其他資訊: RIC Indication SN IE, RIC Call Process ID IE

其中, 識別資訊是用以傳達目標的 xApp 與之後的資料處理,

資訊內容和其他資訊則是 xApp 向 E2 Node 所訂閱的資訊.

比較需要注意的是: RIC Indication Header IE, RIC Indication Message IE 這兩項資訊,

其表示方式皆為 16 進位字串, 若要進一步解析內容,

則需要找到對應的 E2 Service Model (E2 SM) 定義, 進行解碼.

在目前個人對 O-RAN OSC 的實作部分, 都只看到 E2 AP 層,

然而, 若缺乏 E2 SM 的解析, 就只看得到行為, 而缺乏真正的指令,

接下來應會對 E2 SM 進行比較完整的研讀, 希望可以有更詳盡的了解.

Castle on a Cloud