[ORAN] FlexRIC Sevice Model (5): Control 的設計邏輯
在之前文章中, 我們仔細地討論了 Indication 所需要做的修改,
在這篇文章中, 我們轉而討論另一種 E2 協定: Control,
Control 在 O-RAN 的定義中, 用以乘載 RIC 對 E2 Node 的控制信令,
不同於 Indication 在 O-RAN SC 中有完整的定義,
Control 的開源實作的進度較慢, 這可能主要來自兩個原因:
- Indication 可以回傳的資訊數量與格式相對明確, 可以定義並以模擬器實作
- Control 所需承載的資訊需要硬體支援, 並和 Use Case 相關
而針對第二點, 也正是 FlexRIC 的優點,
在擁有 Open Air Interface 的硬體平台支援下,
FlexRIC 可以更容易實作 Control 的功能, 並結合硬體進行展示.
Control 和 Indication 相同, 可以視為一個獨立定義的 Service Model,
需要預先定義其資料格式, 考慮到 O-RAN SC 並未有詳細定義實作,
我們通常以 plain-text 的方式定義 Control 的資料格式,
下圖為 FlexRIC 所實作的 Control 流程:
這兩步驟建立起 E2 Node 以及 xApp 之間的通訊連線,
而對於 Control 和 Indication 兩者設計差異,
主要在於 Indication 是定期驅動, 所以需要設定驅動的週期,
相對的 Control 是依據 RIC 上的事件驅動, 送出 Control Request,
在 E2 Node 執行完後送回 Control Acknowledge,
這樣的設計邏輯在於 E2 Node 的回報應是頻繁且規律的,
RIC 上的 xApp 透過這些收集的資料以及 AI/ML 的運算,
只有在必要的時候, 才透過 Control 更改 E2 Node 上的參數設定,
畢竟任何針對網路的修改都需要硬體反應時間,
同時, 太頻繁的修改也將導致網路的不穩定性, 要審慎進行.
留言
張貼留言