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

作者： -
在 Nvidia ATB (Aerial TestBed) 中, 也針對 dApp 與 E3 介面實作,
不同於 OAI 以 E2/E3 介面實作 dApp 的資料交換,
在 Nvidia 的 dApp 實作中, 考慮了底層的系統實作與 AI-RAN 的架構,
搭配了 DataLake (資料庫) 以及共享記憶體, 來避免大資料的搬移.
我們先以 Nvidia 的圖來說明其架構, 原始連結如下:

來自: Nvidia ATB

在圖中, 我們可以看到 Nvidia 實作的 dApp 主要是對 DU 動作, 並可分成 4 部分:
  1. DU-low, 包含 Layer 1 的服務, E3 Agent 以及 DataLake
  2. DU-high, 包含 Layer 2 的服務, 範例中以 OAI 進行示範
  3. 共享記憶體 (CPU Shared Memory, CPU SHM)
  4. dApp 應用服務
在 Nvidia 的框架中, 針對 dApp 與 DU-low 的部分進行設計,
針對 DU-high 則保有原本 OAI 的 E3 框架.
這樣的設計架構有兩個好處:
1) 可以復用原本 E3/dApp 的註冊/通訊方式, 不會重複定義.
2) 針對感測資料量最大的 DU-low 服務 (raw IQ, 通道估測, 等), 設計更有效的架構.

接下來, 我們進一步看 Nvidia 如何實作 dApp 與 DU-low 之間的資料交換.
從架構上來看，Nvidia 仍然使用 E3 作為 dApp 與 RAN 之間的主要介面.

在 ATB 中, Nvidia 實作了一個 E3 Agent, dApp 可以透過 E3 完成:
1. Setup
2. Subscription
3. Indication
4. Control

也就是說, dApp 啟動之後, 可以先與 E3 Agent 建立連線, 接著訂閱自己需要的 RAN 資料.
當資料更新時, E3 Agent 再透過 E3 Indication 通知 dApp.
dApp 完成分析或 AI inference 後, 也可以再透過 E3 Control 將控制命令送回 RAN.

整體流程可以簡化成:
E3 Setup → E3 Subscription → Data Indication → dApp Processing / AI Inference → E3 Control
這部分與一般 E3/dApp 的概念沒有太大差異.
真正不同的地方, 在於: E3 message 裡面放置多少資料?
對 Layer 2 的 KPI、scheduler 資訊或一些簡單的狀態來說,
資料量並不大, 直接包在 E3 message 中沒有太大的問題.

但是到了 Layer 1, 情況就完全不同.
在 Nvidia 的實作中, 可以傳輸的資料, 包含:
* Raw I/Q samples
* DMRS
* Channel estimates
* PUSCH intermediate data
這些資料可能非常大, 而且每一個 slot 都持續產生.

如果將完整的 I/Q samples 先 encode 成 E3AP message, 
再透過 socket 傳送, dApp 收到後又重新 decode, copy 到自己的 memory,
會產生相當大的資料搬移與 serialization overhead.

所以 Nvidia 在這裡採用了另外一種方式: 小資料走 E3, 大資料走 Shared Memory
Nvidia 的 E3 Agent 會根據資料的性質使用不同的資料交換方式, 對於較小的資料, 例如:
* SFN / Slot
* Timestamp
* Cell ID
* RSRP
* RSSI
* CQI
* MCS
* QAM order
* CRC status
* RB allocation
這些資料可以直接放在 E3 Indication message 中送給 dApp.

但如果是大型資料, 例如:
* Raw I/Q samples
* Channel estimates
* PUSCH estimates
E3 Agent 不需要把完整資料塞進 E3 message,  它送出的反而是:
metadata + shared memory reference,
讓 dApp 再直接從 CPU Shared Memory 讀取資料.

為了此機制, Nvidia 在 DU-low 與 dApp 之間建立了 CPU Shared Memory (CPU SHM)
在 DU-low 的 PHY pipeline 中, 資料原本主要在 GPU memory 中處理
Nvidia 將需要提供給 dApp 的 uplink data 搬到 pinned host memory, 利用 ping-pong buffer 保存.
當 Ping buffer 正在被讀取時, 新的資料可以繼續寫入 Pong buffer. 下一輪再交換, 因此可以避免:
PHY → E3 serialization → socket → E3 deserialization → dApp buffer
這一連串額外的資料搬移.

另一方面, Data Lake 又扮演什麼角色?
Data Lake 的目的不只是讓 dApp 即時讀取資料.
它同時也是 Nvidia 整個 AI-RAN 架構中的 RAN data collection infrastructure.
Data Lake 可以即時收集:
* Fronthaul I/Q samples
* L1 intermediate data
* FAPI metadata
* UL_TTI.Request
* RX_Data.Indication
* CRC.Indication
並將這些不同來源的資料，透過 SFN、Slot、Timestamp 等資訊對應起來.

另一方面, Nvidia 的 dApp 內部架構, 又進一步把 dApp 拆成三個部分：
1. E3 Manager
2. dApp Client
3. dApp Logic
其中 E3 Manager 可以視為 dApp framework 的核心.

它負責:
* E3AP protocol
* E3 Agent connection
* Subscription
* Indication handling
* Shared Memory
* Application dispatch
因此實際開發 dApp 的研究者, 不需要自己重新處理完整的 E3 protocol.

針對與 OAI E3 實作的差異, 如果從 OAI 現在的 E3 framework 來看, OAI 提供比較通用的架構,
目前 OAI E3 Agent 可以使用不同 transport, 例如:
* IPC
* TCP
* SCTP

並搭配 POSIX 或 ZeroMQ 等方式進行 E3 Agent 與 dApp 的通訊.
E3 framework 負責隱藏 Setup、Subscription、Indication 與 Control 等 protocol 細節.

最後, 我們可以把 Nvidia 實作的 dApp/E3 整個流程整理如下:

1) 首先 dApp 啟動：
*dApp
→ E3 Manager
→ E3 Setup
→ DU-low E3 Agent

2) 接著 dApp 訂閱需要的資料:
*E3 Subscription
例如訂閱: RSRP + Channel Estimate + I/Q

3) 當新的 uplink slot 到來:
*RU
→ Fronthaul I/Q
→ GPU L1 Pipeline
→ Data Lake / CPU SHM
→ E3 Agent 得知新資料產生
接著依照資料大小:
*Small data: → E3 Indication payload
*Large data: → E3 Indication metadata / SHM reference → dApp 直接讀取 CPU SHM

4) dApp 再執行: AI / ML inference
最後如果需要修改 RAN 行為:
*dApp
→ E3 Control
→ E3 Agent
→ DU-low / RAN Function

5) 整體形成一個 real-time closed loop:
Sense → Notify → Access Data → Infer → Control
這也就是 Nvidia 將 dApp 放進 AI-RAN 架構中的核心目的.
換句話說，Nvidia 的 dApp 架構是在兩個需求中取得平衡:
一方面維持 E3/dApp 的開放介面與 application abstraction
另一方面又利用 GPU、Data Lake 與 Shared Memory, 
處理真正 AI-RAN 系統中大量且具有嚴格 latency 要求的 PHY data.

留言

張貼留言

熱門文章

LTE筆記: RSRP, RSSI and RSRQ

作者： -
圖片
在一般通訊系統中, 我們常用 RSSI (Received Signal Strength Indication) 來表示訊號強度,  其單位為 (dBm), 可以轉換成功率大小 (mW): https://en.wikipedia.org/wiki/DBm [註] dBm 的原意即是: (dB) reference to (m)W, 因此, 1 W = 10*log10(1000mW) = 30dBm. 在 LTE 通訊系統中, 除了 RSSI 之外, 又額外定義了兩個用以標示訊號強度的數值: RSRP 和 RSRQ 以下, 我們將介紹 RSRP, RSRQ 和 RSSI 的不同： Reference Symbol Received Power (RSRP) RSRP 為 UE 量測 Reference Signals (RS) 的平均訊號強度, DRS 為基地台在下行訊號中, 於固定 RB (Resource Block) 上傳送的訊號, 由於這些訊號具有特定的傳送格式, 接收端便可以解出這些控制訊號的強度, 對於不同的相鄰基地台, 甚至是同一基地台不同的天線, 可以透過不同的 RS 配置, 讓使用者得知不同目標的量測數值, 如下圖所示: 紅色為 RS, 不同基地台或天線使用不同的 RS 排列方法, 可分開量測 來自: https://api.semanticscholar.org/CorpusID:22030582 RSRP 的回報由 UE 進行 Measurement Report, 回傳給基地台, 其中, 關於 Measurement Report 的設置定義於 RRC 的規範中, 我們之後有機會再提, RSRP 的量測, 通常在換手 (handover) 時進行量測, 用以指出目標基地台的訊號強度, 其中, UE 所量測的數值, 將藉由下表進行轉換 (訊號強度 (dBm) - (-140)), 並回報給 eNB 作為換手的決策使用: (3GPP Reference: TS 36.133) RSSI (Received Signal Strength Indication)  RSSI 是 UE 接收到的 wide-band 訊號強度, 包含 DRS 以及其他...
閱讀完整內容

[WiFi] WiFi 網路的識別: BSS, ESS, SSID, ESSID, BSSID

作者： -
圖片
在 WiFi 網路中, 一個基本的識別方式就是 SSID (Service Set Identifier), 也就是我們口語中的 "WiFi 網路名稱", 然而, 此網路事實上是一個服務集合 (Service Set) 的概念, 而一個服務群集, 也可以對應到一個基本的無線網路, 包含: 一個 WiFi AP 以及多個 WiFi 使用者, 對於剛剛這種簡單的網路架構, 又稱為 BSS (Basic Service Set), 若是多個 BSS 都使用同一個 SSID, 則稱為 ESS (Extend Service Set), 如下圖所示: 來自: https://ppt.cc/fXIvex 對於 ESS 來說, 有兩個假設, 第一, 底下的 BSS 必須是相鄰 (有交疊範圍) 第二, 這些 BSS 有網路連線, (有線或是無線都可以) 這兩個假設是為了完成 ESS 的主要功能, 也就是換手 (handoff), 當裝置在同一個 ESS 下不同 BSS 範圍中移動時, 可不必重新連線就可以繼續傳輸. 這樣的流程事實上是由原本服務的 AP (BSS 1), 把使用者的資料轉傳到換手目標的 AP (BSS 2), 資料流程為: DS -> BSS 1 -> BSS 2 -> Sation, 也因此, 兩個 AP 之間必須連線, 同時切換時間也不能太久 (相鄰條件), 那麼在上述例子中, 如何知道 BSS 1 和 BSS 2 的差別呢? 在 WiFi 網路中, 為了完成這件事情, 所以就有了 ESSID 和 BSSID, ESSID 如上所述, 對應於 ESS 所使用的 SSID, 至於 BSSID (通常是 WiFi AP 的 MAC 位址) 來區分同個 SSID 下的網路. 反過來說, 同一個 WiFi AP 也可以擁有多個 SSID, 此功能稱為 VAP (Virtual AP), 此時, 一個 WiFi AP 會虛擬出多個 BSSID, 通常作法就是從原有的 MAC 位址往上加一, 作為多個不同的 BSSID. 這些 VAP 會對應到 WiFi AP 中的不同 VLAN 中, 因此, 我們可以給他們不同的網路設定, 例如: 流量, 安全性, 頻寬等, ...
閱讀完整內容

LTE筆記: 波束成型 (beamforming) 和天線陣列

作者： -
圖片
在5G的技術中, 其中一個新被引入的通訊技術就是波束成型 (beamforming), 波束成型技術可以大略的分成兩種: 第一種、藉由量測到的通道係數, 設計傳送參數 (precoder), 最佳化通道 第二種、透過多天線的相位偏移 (phase shifter), 決定電波傳遞強度模 在文章中, 會著重介紹第二種波束成型的架構, 在第二種波束成型的架構中, 所使用的是電磁波干射的物理特性, 簡單來說, 透過電磁波的建設性干涉與破壞性干涉, 我們就可以在某個方向上產生一個較強的訊號, 而在其他方向上減低此訊號的影響. 來自:  https://en.wikipedia.org/wiki/Phased_array 在上圖中, 我們可以發現這種波束成型架構的兩個需求: 1. 必須有多根天線服務同一筆傳輸訊號 2. 每個天線都必須要有一個相位調節器 (phase shifter)
閱讀完整內容