[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 決定, 因此, CSI sample 最密可到 2.5 ms (根據設定: 3DSU, SCS=30 kHz, slot=0.5 ms → 5 slot pattern=2.5 ms) 同一個 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.indicat...