[ORAN] AI/ML workflow description and requirements ~4
在上一篇文章中, 我們介紹了 AI/ML 的大致流程,
其中, 我們可以看到 AI/ML 程式的不同布署位置 (例如: near-RT RIC, non-RT RIC),
在這篇文章中, 我們將說明不同布署位置的原因, 以及其設計準則,
分別對應於: <10 ms, 10 ms~ 1 sec, >= 1sec, 三個不同的時間等級.
針對不同應用的即時性需求,
會產生不同的資料回報速度, 以及相對應的計算即時性需求.
針對計算的即時性需求, 則會衍伸出運算能力的需求, 與硬體的限制,
在這裡, 我們會發現, 即時性的需求與運算資源的能力, 正好是相悖離的,
舉例來說, near-RT RIC 通常實作於 edge server, 只有有限的運算能力,
卻要負荷小於一秒的即時運算響應.
相較之下, non-RT RIC 通常有較高的運算能力, 但在企業專網的應用中,
可能沒有深度學習訓練網路時所需要的特殊硬體 (如: 高階 GPU 顯卡).
因此, 在 O-RAN 的設想中, 就針對這樣的限制, 提出一些想法,
例如在 Scenario 1.2 中, 可以利用 non-RT RIC 用以訓練多個 ML/AI 模型,
並在 near-RT RIC 中收集即時的量測回報, 根據回報執行 AI/ML 的運算,
當環境改變時, 這些即時回報也可以上傳給 non-RT RIC 進行模型的訓練,
或是透過 A1 介面, 通知 near-RT RIC 切換使用的 AI/ML 模型.
相對 Scenario 1.2, Scenario 1.1 是一個簡化的架構,
當響應需求的即時性不高時, 可以將所有的運算 (訓練/執行) 都放在 non-RT RIC 上,
此時, near-RT RIC 的角色就像是一個代理者, 負責資料的收集與控制指令的傳遞.
在 AI/ML 的設計中,
可以看出來 O-RAN 對於如何將 AI/ML 落實於電信網路有許多的討論,
然而, 到目前為止 (v1.02版) 似乎仍有許多待定項目,
我們就先在此暫停此系列討論, 若之後有更豐富內容, 再進行更新.
留言
張貼留言