AI-RAN: E3 Interface & dApp OCUDU 的實作

在前面的文章中, 我們介紹了 OAI E3 interface 與 dApp 的基本架,

也進一步介紹 Nvidia Aerial Testbed 如何利用 Data Lake 與 Shared Memory,

減少大量 Layer 1 資料透過 E3 message 傳輸所造成的負擔.

在上述的 E3/ dApp 的架構中, dApp 是依附在 AI-RAN 之外的應用,

對 Spectrum Sensing, ISAC, Positioning 等應用來說, 這樣的架構相當合理.

而今天我們要介紹的是 DeepSig 與 OCUDU 在 2026 年提出另一種 dApp runtime 架構:

在他們提出的架構中, 根據 dApp 的 timing requirement, 分成 Class A、Class B 與 Class C.

OCUDU 論文將三者分別定義成：

- Class A：Resident Inline L1

- Class B：Bounded Real-Time Control

- Class C：Asynchronous Observation and Advisory

OCUDU 仍然在 DU 中放置 Embedded E3 Agent 進行控制, 

負責 lifecycle、configuration、model management、telemetry 與 RAN control.

針對 Class A/B/C 的 dApp 的執行, 則依據時間需求放置不同地方:

Class A 進入 PHY processing pipeline, 

Class B 在 MAC scheduler 的 decision boundary 被直接呼叫,

Class C 則取得資料進行非同步分析, 可以部署在 DU process 內, 也可以放在外部 process.

如下圖所示:

在圖中, 紫色虛線表示 E3 管理路徑, 實線表示資料或執行路徑.

Class A, Class B 與 Native Class C 位於 DU process 中, 

Supervised Class C 使用同主機的獨立 worker, Portable Class C 則透過 E3 取得資料.

Class C 的受准許結果可由 host cache 提供給後續 scheduler decision 使用.

其中, Class A 對應的比較特別, 是針對原本既有的通訊功能,

例如: 通道估計 (chaanel estimation), 排程 (scheduling) 等,

這邊值得提及的是, 在 Nvidia 的架構中, Class A 的應用歸在 AI-RAN 的 pipeline,

不在 E3/dApp 的範疇中, 而是透過 CUDA 平台來進行串接.

Class A: 直接進入 PHY processing pipeline

例如, Channel Estimator 要先產生 channel estimate, Equalizer 才能繼續處理.

此時 AI 模型不只是觀察 RAN, 而是 PHY pipeline 的其中一個處理階段.

如果把資料送到外部處理, 再把 inference 結果搬回 PHY, 

資料搬移與 process wakeup 都可能是造成模型推論延遲的瓶頸.

在 Class A dApp 的範例中, 

dApp 取得 host 提供的 resident tensors, device pointers, PUSCH metadata 與 CUDA stream. 

模組把 kernel 排入 host stream, 輸出寫入 DU-owned buffer, 後續 PHY stage 再接著使用.

在圖中, 三欄分別是 CE、CE＋EQ, 到 soft bits 的 receiver.

CE 輸出接回 Equalization, CE＋EQ 的結果接回 Demapping, 第三種輸出在 Descrambling 前接回.

此處的 full RX 到 soft bits 為止, 後續仍包含 Descrambling 與 LDPC,

這邊 Class A 的 dApp 架構與 Nvidia AI-RAN 的架構頗為一致,

都是以 AI model 取代既有 AI-RAN 的資料處理程序.

Class B：讓 AI 參與 Scheduler Decision

Class B 是 Bounded Real-Time Control, 

最典型的使用情境是 Scheduling, PRB allocation, MCS selection 與 Link Adaptation.

dApp 回傳 typed intents, 由 host 檢查權限, 數值範圍, generation 與 deadline, 再決定是否提交.

100 μs 涵蓋 feature construction 到 commit 的完整時間, 並非只計算推論時間.

過晚或未通過驗證結果會被跳過, 丟棄或回推到既有 RAN 的計算結果.

Typed intent 可以表達 priority, PRB limits, MCS, layers, TPC 或 avoid mask 等內容,

但能否真正套用, 仍受 operator allow flags 與 host validation 限制.

Class C：觀察與建議型 dApp

Class C 是 Asynchronous Observation and Advisory, 

最接近前面介紹過的 sensing、ISAC、positioning 與 telemetry dApp.

例如 SRS channel estimate 可以交給 positioning algorithm, 計算 CIR、AoA 或位置.

PHY 不需要等待位置結果, 才能繼續處理接收鏈.

Native 使用 DU 內的資源進行計算, 可以減少 process boundary 的成本,

Supervised worker 使用 SHM ring 或 CUDA IPC export pool, 提供 worker isolation,

Portable 使用外部 E3 client 進行, Portable 則方便不同語言與不同 host 的應用接入,

這三種計算正好對應 OCUDU 提出的框架 (Native), Supervised 則是對應 Nvidia 框架,

以及 Portable 則對應 OAI 的 E3/ dApp 的框架.

總和來說, Class A/B/C 的差異可以用下圖總結:

Class A 的結果是 PHY continuation 的輸入, 

Class B 的結果必須在 scheduler decision budget 內完成驗證與提交, 

Class C 則讓 producer 繼續運作, 由 consumer 非同步分析.

Class A／B 的執行位置在 DU process 內, 

Class C 才提供 Native、Supervised、Portable 三種不同的選擇.

參考資料:

1. O’Shea, T., Pennybacker, M., & Kharchenko, A. (2026). The OCUDU dApp Platform: An Open Runtime and E3 Interface for Real-Time AI-RAN. arXiv:2609.07843v1. https://arxiv.org/abs/2609.07843 

2. DeepSig (2026-09-15). Opening the Fastest Part of the 5G Radio to AI: The OCUDU dApp Platform. https://www.deepsig.ai/ocudu-dapp-platform/