發表文章

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

作者： -
圖片
在 Nvidia ATB (Aerial TestBed) 中, 也針對 dApp 與 E3 介面實作, 不同於 OAI 以 E2/E3 介面實作 dApp 的資料交換, 在 Nvidia 的 dApp 實作中, 考慮了底層的系統實作與 AI-RAN 的架構, 搭配了 DataLake (資料庫) 以及共享記憶體, 來避免大資料的搬移. 我們先以 Nvidia 的圖來說明其架構, 原始連結如下: https://docs.nvidia.com/aerial/testbed/latest/text/product_description/index.html#software-components 來自: Nvidia ATB 在圖中, 我們可以看到 Nvidia 實作的 dApp 主要是對 DU 動作, 並可分成 4 部分: DU-low, 包含 Layer 1 的服務, E3 Agent 以及 DataLake DU-high, 包含 Layer 2 的服務, 範例中以 OAI 進行示範 共享記憶體 (CPU Shared Memory, CPU SHM) 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 Co...
張貼留言
閱讀完整內容

AI-RAN: E3 Interface & dApp 的資料格式與參數

作者： -
圖片
在上一篇文章中, 我們介紹了 dApp 和 E3 介面在 O-RAN 框架中的定位. 接著, 我們介紹一下 E3 的資料格式與參數, 接著我們來介紹 E3 介面的細節, 說明此介面設定如何乘載大量且即時的感測資訊. 首先, E3 interface 目前是 dApp 架構中的延伸介面, 用來讓部署在 O-DU / O-CU 附近的 dApp 與 RAN function 做 超低延遲資料交換與控制. 和 E2 介面連結 nearRT-RIC 和 RAN 不同, E3 直接實作於 RAN (CU/ DU) 之中, 不過在 E3 介面的設計上, 和 E2 有許多雷同之處, E3 也可以拆成 3 層來看: E3 logical interface: E3 是整體 southbound 介面，連接 dApp <=> RAN node E3AP (E3 Application Protocol): E3AP 負責程序與封包類型, 類似 E2AP 在 E2 裡扮演的角色 E3SM (E3 Service Models): E3SM 負責 dApp 資料/控制的定義, 類似 E2SM 也和 E2 介面類似, E3 介面主要有兩個建立關聯的步驟: E3 Setup, E3 Subscription. 我們先從 E3 Setup 開始說明: 這張流程交換的圖示, 應該很有印象,  基本上, 把 xApp/ dApp 以及 E3 Agent/ E2 Agent 的角色調換一下, 就是 E2 介面的 Setup 流程,  在 E3 介面中用來做初始配對, 認證, 建立 dApp 與 RAN node 關聯. 考慮到我們主要要介紹 E3 介面的資料格式與 dApp 功能,  我們先略過 Setup 的介紹, 來花篇幅介紹更重要的 E3 Subscription. 和 E2 介面類似, E3 Subscription 的流程也是先定義了需要的資源, 此處的資源可以是回報的數值, 例如: SRS 回報, 也可以是被控制的功能, 例如: PRB 分配. 在確保了 CU/ DU 有 dApp 所需的支援之後, 接著進行以下的流程: E3 Indication MessageRAN => dApp: 傳遞 tele...
張貼留言
閱讀完整內容

AI-RAN: E3 Interface & dApp 系統架構與資料流

作者： -
圖片
很就沒有來看 O-RAN 的變革, 雖說知道有 dApp 的出現, 提供 realtime App 的應用, 但沒有發現到針對 dApp 也有一個專屬的介面: E3 interface. 我想就找個機會來整理並介紹. 首先, dApp 和 E3 interface 是 O-RAN 社群在 nGRG / research report 中提出的延伸架構, 不是像 E2/ O1/ A1/ F1/ Open Fronthaul 那樣已經是大家熟知的介面. 它的目的是補足現有 rApp/xApp 架構兩個缺口: 無法直接處理 user-plane/ IQ symbol/ reference-signal 級資料 難以做到 10 ms 以下的 real-time control. 我們先以一張圖來表示 dApp, E3 以及其他元件的關係: 在這張圖中, 我們介紹一下各個元件的關係: rApp 在 Non-RT RIC，時間尺度通常 > 1 s xApp 在 Near-RT RIC，時間尺度通常 10 ms ~ 1 s dApp 不在 RIC 裡，而是直接部署在 O-DU / O-CU-CP / O-CU-UP  E3 是 dApp <=> DU/CU 的即時資料與控制介面 E2 仍然是 Near-RT RIC/xApp <=> E2 node (DU/CU) 的介面 如果用角色來分, 各元件的功能如下: rApp: 慢速策略, 模型管理, 長時間尺度 (>1s) 最佳化 xApp: 近即時控制, 跨 cell/RU 之間的協調 dApp: 超低延遲, 貼近協定堆疊, 直接處理 SRS/IQ/CIR/封包等即時大量資料 DU/CU/RU: 真正執行無線與協定功能的 RAN 節點 接著, 我們來看各元件之間的資料交換流程, 並以 SRS 回報為例, 在相關論文中, 明確寫到 SRS 可由 O-DU 透過 E3 提供給 dApp, 定位 use case 則是使用 UL CIR. 所以整體的流程是: SRS => O-DU channel estimation => CIR/features => dApp inference. 我們以下圖來表示整體資料交換流程: 整體的流程可分成 6 步驟: dApp 先用...
張貼留言
閱讀完整內容

[LTE 筆記] OFDM 系統下的感測技術: OFDM RADAR

作者： -
圖片
過完忙碌的 5 月, 接下來是更忙碌的 6 月. 這一路的忙碌, 似乎看不見盡頭似的, 時間受壓力吞噬, 通常一篇文章的找資料加撰寫, 耗時約 5-6 小時, 盡然難以抽出. 也因此先對 5 月文章的缺失, 先說聲抱歉了. 這一篇文章延續上一篇 OFDM 系統的假設, 但是, 我們著重在如何使用 OFDM 通道估測的結果, 來進行 6G 網路中的 ISAC (Integrated Sensing And Communication), 也就是, 透過通訊的通道估計, 但同時進行環境的感知 (Sensing). 這樣的技術, 被稱為 OFDM RADAR. OFDM radar 的核心優勢,  在於它可以重用通訊系統既有的波形, 頻譜與硬體, 在 5G NR 系統下, OFDM radar 的整合大致有三條路線:  第一類是以基地台下行 reference signals 為主的感知, 例如 PRS, CSI-RS 與 DMRS 第二類是以 uplink 為主的 bi-static sensing，例如 PUSCH 內嵌的 DMRS, 或是 SRS 第三類則是進一步從單一基地台延伸到多基地台協作的 distributed sensing.   我們在本文中, 先著重在前兩點, 分析在 5G NR 系統下, OFDM RADAR 的實作方式與限制. 來自:  https://www.mdpi.com/1424-8220/26/4/1317 在 5G NR 中, OFDM 訊號可以表示為一個二維的 time-frequency resource grid.  以 SCS = 30 kHz 為例, 一個 frame 由 10 個 subframes 組成, 每個 subframe 包含 2 個 slots, 每個 slot 進一步包含 14 個 OFDM symbols. 在頻域上, 每一個 OFDM symbol 會展開到 N_fft 個 subcarriers. 以100 MHz 為例, N_fft 為273*12=3276, 273 為 Resource block 個數. 發射端先在時間域產生 OFDM symbols, 再經過 FFT/IFFT 對應到時頻資源格,  因此整個 5G NR 波形可以...
張貼留言
閱讀完整內容

[LTE 筆記] OFDM 系統下的通道估測與誤差

作者： -
圖片
在本文中, 我們預期從 5G NR 的 OFDM 通訊行為來分析通道與同步造成的收訊誤差與扭曲. 我們將以 SRS (Sound Reference Signal) 為例,  SRS 並不是未知的資料訊號, 而是一種已知的 reference signal. 系統會先透過高層或 PHY 層配置決定 SRS 的參數, 例如: numerology, 子載波間距, SRS bandwidth, comb factor, 傳送的 OFDM symbol 位置等. 這些參數決定了 SRS 會出現在 resource grid 的哪些 resource elements 上. 在頻域中, SRS 會先形成一串已知序列 (Z-C Sequence), 接著映射到指定的子載波上.  之後, OFDM transmitter 透過 IFFT 將頻域 resource grid 轉為 time-domain samples. 為了降低多路徑延遲造成的 inter-symbol interference,  系統會將 OFDM symbol 尾端的一小段複製到前方, 形成 cyclic prefix.  最後, 這段含有 CP 的時域訊號會經由 RF front-end 與天線送入無線通道. 接收端取得 time-domain IQ samples 後,  會先進行時間與頻率同步, 再移除 CP, 並透過 FFT 回到頻域. 由於接收端知道 SRS 的時頻位置與原始序列, 因此可以從接收到的頻域訊號中抽取 SRS RE, 並將接收值除以已知的 SRS 符號, 得到該子載波上的 channel frequency response, 也就是 CFR. 如果進一步對 CFR 做 IFFT, 則可以得到 delay-domain 的 channel impulse response, 也就是 CIR. 整體的資料傳輸流程如下圖所示: 在圖中顯示了以 SRS 為例的 OFDM 訊號流程: SRS 先在頻域產生與映射, 經 IFFT 與 CP insertion 形成時域 waveform, 經過無線通道後, 接收端再透過 FFT 回到頻域. 利用已知 SRS 估測 CFR, 並可進一步轉換為 CIR. 透過上述的通道模型,  雖然在頻域...
張貼留言
閱讀完整內容

[LTE筆記] CSI-Based User Positioning with an NVIDIA 5G Testbed (2)

作者： -
圖片
在上一篇文章中, 我們整理了 ARC-OTA → DataLake → CSI 的兩段式流程: 線上把 FH I/Q + FAPI 落到 DataLake DB 離線用 pyAerial 重跑 PUSCH receiver + channel estimator 取得 CSI/CFR 在這一篇文章中, 我們繼續跟隨論文的脈絡, 並嘗試說明以下兩點: 介紹 ARC-OTA 對 SRS 的支援, 以及為何此論文以 DMRS 進行實作  介紹使用 CFR 的三種應用, 以及每種應用的資料處理流程, 演算法, 與應用成果  我們先從第一點開始: 為何這篇論文用 DMRS (PUSCH) 而非 SRS 來進行 CFR 取值? 這並不是因為 ARC-OTA 不支持 SRS 取得 CFR 的功能, 而是因為這篇論文的主軸是在標準 5G NR 通訊鏈路上進行操作, 並把 sensing 當成副產品. 也因此, 它把資料源鎖定在 uplink 的 PUSCH,  並用 PUSCH 內建的 DMRS 做通道估測, 減少 Sensing (SRS) 對通訊資源的消耗. 這樣做的好處是: 不需要另外開一條量測信號: UE 只要照常送 uplink traffic, 就自然有 DMRS 可以估通道. CSI 更新率主要由 TDD pattern + SCS + scheduler 決定, 論文指出其配置下最密可到 2.5 ms,  時間尺度上也與 SCS=30 kHz (slot=0.5 ms) 及 3DSU 的週期性設定相符 同一個 PUSCH slot 內, 有 3 個 DMRS symbols, 可以觀察 CSI 在不同 OFDM symbol 的變化 如果根據 NVIDIA Aerial (ARC-OTA 底層堆疊) 的文件,  SRS 的支援是從 PHY 到 FAPI 一路打通的, 其實作的功能包含: PHY / pyAerial: 有 SRS Tx/Rx pipeline pyAerial 的 SRS 模組已經提供 SrsTx / SrsRx, 並且有官方 notebook 示範如何跑 SRS Tx/Rx. SCF FAPI：支援 UL_TTI.request 的 SRS PDU + SRS.indication Aerial cu...
張貼留言
閱讀完整內容

[LTE筆記] CSI-Based User Positioning with an NVIDIA 5G Testbed (1)

作者： -
圖片
以下的內容主要來自於此篇文章: CSI-Based User Positioning, Channel Charting, and Device Classification with an NVIDIA 5G Testbed ArXiv:  https://arxiv.org/abs/2512.10809v1 針對此篇文章的內容預計分成兩篇來撰寫, 在第一篇文章中, 我們將介紹在 Nvidia 系統中, 如何取的 CSI 的資訊, 以及取得 CSI 資訊的格式, 方法, 以及對應的實驗量測環境. 在第二篇文章中, 則會說明 CSI 資訊的應用. 首先, 先說明一下, CSI 有兩種方法可以取得, 除了之前說的 SRS 之外, 另一個則是透過 DMRS 來取得. DMRS 全稱為 Demodulation Reference Signal,  是在 5G 通訊中, 用以進行通道估測與輔助解調 OFDM 的參考訊號, 在上行的 PUSCH (Physical Uplink Shared Channel) 中, UE 裝置可以每 7/14 OFDM symbol 發送一組基礎的 DMRS 參考, 當然, DMRS 訊號可以有類似 comb 的編排機制 (在頻域上間隔出現), 我們在此先以基礎的設定 (使用所有 3276 個 sub-carrier 傳輸) 作為當前設定. 考慮到 DMRS 在 PUSCH 中的配置和 SRS 頗為一致, 在此就不贅述. 在 5G NR 系統中, DMRS 也是由基站通知手機端發送, 因此 DMRS 的回報間隔來自於基站的排程時間. 在這篇論文中, 他們的系統配置讓 CSI sample 至少每 10 ms 或 20 ms 進行回報, 最短的回報時間則是 2.5 ms (TDD pattern=3DSU, 因此, 0.5*5=2.5ms). 同時, 在此系統中, DMRS 在同一個 PUSCH slot 裡被配置 3 次, 換句話說, 在系統配置中, 可以看不同 OFDM symbol 的 CSI 變化. 比較可惜的是, 論文中並未明說這三個 OFDM symbol 配置的順序, 因此, 對於 OFDM RADAR 等應用會缺乏一些資訊. 基於上述的設定, 我們可以整理此系統的時序設定如下所述...
張貼留言
閱讀完整內容