Castle on a Cloud

在上一篇文章的後續, OAI 團隊將此 SRS 的量測實驗延伸到室內, 並提供了更多實驗的細節, 後續的發表可以看此篇文章: Experimental Insights from OpenAirInterface 5G Positioning Testbeds: Challenges and Solutions link:  https://arxiv.org/abs/2508.19736 在文章中, 提到了 3 個實驗場域, 如下表所示: 圖、OAI SRS 實驗場域 (作者整理) 在三個場域中, 我們可以看到室外場域就是上一篇論文的環境, 此外, 又新增了兩個室內的場域, 對應智慧製造的應用, 這些場域的資料中, 作者公開了室外場域的量測, 放在 Gitlab 上提供下載: https://gitlab.eurecom.fr/ahadi/5g-srs-datasets  這些場域量測的資料已經經過預先的資料前處理, 分成三個部分: ToA Filtering, TDoA Averaging, TDoA Filtering. ToA Filtering: 使用統計方法過濾 ToA 資料, 以去除離群值, 增強測量準確度 TDoA Averaging: 在所有天線間進行TDoA資料的平均, 以提升測量的穩健性 TDoA Filtering: 經過平均化後, TDoA資料會透過位置資訊進行過濾, 提高定位精度 以上三個資料處理流程, 主要針對 SRS 轉換出來的 ToA 進行處理, 主要的目標是增加 ToA/ TDoA 的強韌性, 避免大幅的定位資訊跳動, 其資料前處理的流程圖如下圖所示: 圖、來自論文 比較可惜的是, 若是檢視提供的資料集資料, 看起來已經將不同 RU 間最大的 peak 數值對齊, 這邊我們需要進行額外的檢視, 以確定如何將 ToA 的資料取出: 圖、公開資料集的格式以及 CIR 繪圖成果  

在 SRS 的系統中, 我們介紹了資料傳輸的流程, 也就是基地台如何設定 UE 傳送 SRS, 以及鄰近基站如何識別要量測的鄰近 UE 裝置. 事實上, 針對 SRS 的信令, 仍有另一個重要的控制資訊, 也就是基地台設定 UE 在哪幾個 Resource Block (RB) 上傳送參考訊號, 以及參考訊號如何編成. 我們先說參考訊號的部分吧! SRS 採用 Zadoff–Chu (ZC) 序列產生基底序列,  ZC 序列具備恆定能量大小與良好的正交特性. 為了對不同 UE 產生 SRS 的參考訊號, 要針對 UE 指定序列 ID (sequenceId), 初始化 ZC 基底序列後, 經由離散傅立葉轉換展開至頻域子載波, 最終對應到特定的 RB 位置. 接著, 是關於這些參考訊號的 RB 配置, SRS 主要可以透過兩個方式配置用以傳送參考訊號的 RB,  在時間上 (OFDM symbol) 與頻域上 (sub-carrier), 如下圖所示: 來自:  https://www.mathworks.com/help/5g/ug/nr-sounding-reference-signals.html 在 OAI 的這一篇論文中, 並沒有明確說明 SRS 的設置, 所以我們近一步從公開程式庫取得原始碼： 以 git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git  複製 OpenAirInterface 5G 專案, 進入專案後切換至 NRPPA_Procedures 分支，並透過 git submodule update --init –recursive 完成子模組初始化 接著，在專案路徑 /openairinterface5g/openair2/RRC/NR/nr_rrc_config.c 中, 可以找到與 SRS 配置相關的核心函式: 其中 configure_periodic_srs() 用於設定週期性 SRS 的資源參數, static struct NR_SRS_Resource__resourceType__periodic *configure_periodic_srs(const NR_ServingCellConfigCommon_t *...

在通訊系統中, 透過 SRS 取得通道的量測數值是一個挑戰, 另一個挑戰是如何透過相鄰基站, 偕同量測 SRS 資訊. 不同於 RSRP 的回報是由 UE 進行量測週期廣播的 SSB 訊號, SRS 資訊由 UE 發出, 並由基站量測上行的通道變化. 這也意味著, 基站也必須共享 SRS 的設定,  這些 SRS 的配置涵蓋了頻域與時域的資源分配, 傳送週期性等參數, 並犧牲一部分的上行通訊資源, 以達成 SRS 定位的協作.  在 OAI 的實作中, 在 FAPI interface 裡新增了一種類型的 SRS report: Localization report type, 以及新增一種 SRS 類型 (type 5) 來標示該用途, 用來區別普通 SRS measurement 與為定位用途的 neighbour/serving 測量. FAPI 用以界接 MAC/ PHY 的功能, 如下圖所示: 來自:  https://www.telecomhall.net/t/which-split-options-are-used-in-5g-and-open-ran/18075 如果在 split 7.2x 的架構下, DU 包含 high-PHY 和 MAC 功能, 因此, FAPI 的實作位於 DU 之內. 此外, 為了讓 neighbour gNB/TRP 知道要接收哪個 UE 的 SRS, OAI 為 neighbour 測量引入一個 special RNTI (Radio Network Temporary Identifier), 填入於在 MAC → PHY 的 SRS PDU 中的 UL TTI request, 以標記 SRS 測量的需求. 同時, 在 PHY → MAC 的 SRS.indication 中, 除了 reserved RNTI,  還有 SRS resource ID / UE ID context 可以綁定該測量屬於哪個 UE. 在解出來 ToA 後, OAI 的實作也必須將此數值往上回報, 他們把從多個 TRP 收到的 Timing advance offset (ns) 帶回 MAC/LMF, 這些 offset 用來計算 ToA 差異 (TDoA),  並設計一組 TLV ...

針對 LTE (4G)/5G 這樣的行動通訊系統而言, TDoA (Time Difference of Arrival) 大概算是最常見的定位量測資訊, 然而, TDoA 的資訊事實上來自於使用者的傳輸訊號, 需要搭配 SRS (Sounding Reference Signal) 的傳輸進行量測, 在過去, 由於此部分的公開資料有些少, 所以我們並沒有許多實作的細節, 最近, OAI (Open Air Interface) 實作了 TDoA 與 LMF (Location Mgmt. Function), 讓我們可以一窺 TDoA 的取得方式與實作機制. 我們在第一篇文章中, 先介紹以 SRS 實作 TDoA 的基本概念, 本文主要的內容來自於: arXiv:2409.05217 From Concept to Reality: 5G Positioning with Open-Source Implementation of UL-TDoA in OpenAirInterface 來自:  https://arxiv.org/html/2409.05217v3 在以上的流程圖中, 介紹了 OAI 實作中, 如何發起 SRS 的量測: LMF (Location Management Function) 是定位的核心控制單元 LMF 先透過 API 接收到定位請求（包含 UE 的 IMSI/SUPI、NCGI 等資訊） LMF 透過 NRPPa 協議 向 serving gNB 發送 Positioning Information Request, 要求 UE 傳送 Sounding Reference Signal (SRS) serving gNB 配置 SRS 資源, 並回報其 SRS 配置給 LMF LMF 再下達 Positioning Activation Request, 正式觸發 UE 傳送 SRS 其他鄰近的 gNB/TRP 透過相同的配置接收 UE 的 SRS, 並回傳量測結果給 LMF 接著, 透過取得的 SRS 量測數值,  gNB 的 PHY 層利用 UE 的上行 SRS 進行通道估計與 ToA (Time of Arrival) 計算： 使用 Zadoff-Chu 序列的 SRS 進行相關運算與 IFFT, 得到通...

 ONNX (Open Neural Network Exchange) 是一個開放格式, 用來表示深度學習模型與傳統機器學習模型的計算圖結構, 讓不同的深度學習框架 (如 PyTorch、TensorFlow、Scikit-learn) 之間可以互通, 使模型的部署與交換更加方便. 來自: https://github.com/1010code/onnx-mlir-tutorial 透過 ONNX, 我們可以完成以下的目標: 模型跨平台轉換與交換 可將模型從 PyTorch、TensorFlow、Scikit-learn 等框架導出為 ONNX 格式 便於在不同工具或設備之間共享與重用模型 跨硬體部署 (CPU、GPU、FPGA、NPU) ONNX 模型可以在多種硬體平台執行，不需重新訓練 搭配 ONNX Runtime、TensorRT、OpenVINO 等工具，實現高效推理 推理優化與加速 可結合 TensorRT、ONNX Runtime 等進行圖優化 (Graph Optimization) 與推理加速 適用於邊緣設備、嵌入式系統、高性能伺服器等場景 多模型整合與模組化設計 可將多個子模型整合為一個 ONNX 模型，便於部署與管理 適合構建複雜管線 (例如預處理 → 模型 A → 模型 B → 後處理) 在 ONNX 架構中, 事實上是把模型拆解成計算圖 (GraphProto), 在計算圖中, 包含了以下 4 種角色: node: 每個節點代表一個操作 (如: matmul、relu、add) input: 圖的輸入 (例如: 影像、感測器資料) output: 圖的輸出 (例如: 分類結果、控制訊號) initializer: 模型的參數 (例如: 權重、bias 等) 來自:  https://onnx.ai/onnx/intro/concepts.html 透過上述運算子, ONNX 可以把原有的運算, 轉化成 Directed Acyclic Graph (DAG), 再放到不同計算平台進行運算. 然而, 也是由於計算圖 (GraphProto) 的原因, ONNX 有以下限制: 1. 無法封裝任意 Python 程式邏輯 ONNX 只能表示靜態的計算圖 (computational graph), 不支援像 Python 中的...

在很久之前的文章中 ( 這裡 ),  我們介紹定位方法時, 提到了 Time Advance (TA) 的量測. 最近正好讀到相關內容, 就整理一下 TA 的原理以及潛在的定位應用. Timing Advance (TA)  是一種用於 5G 網路中, 讓用戶設備 (UE) 在正確時間發送上行訊號的機制. 其主要目的是為了補償訊號從 UE 傳送到基地台 (gNB) 之間的傳輸延遲, 以避免來自不同距離的 UE 訊號在基地台接收端未按照排程對齊, 產生干擾. 我們可以以下圖做為範例說明: 來自: https://www.telecomhall.net/t/parameter-timing-advance-ta/6390/5 左圖是在沒有使用 TA 下進行傳輸,  在此情形下, UE 收到 downlink 訊號就直接回 uplink 傳輸, 由於不同距離產生的訊號延遲, 導致不同 UE 間的 uplink 訊號不同步, 在右圖, 透過 TA 機制彌補傳輸訊號延遲後,  對基站而言, downlink 和 uplink 的傳輸時間即可對齊. TA 為基站所計算, 根據 UE 傳來的時間資訊估算距離與延遲, 透過 RAR (RACH Response) 或 MAC 層的 TA Command 下達 Timing Advance 值, UE 根據 TA 調整自己上行符號的發送時機, 基站便能在自己的時間基準上, 準確地接收所有 UE 的上行訊號. 考量到 TA 資訊隱含了距離的資訊, 透過量測 UE 的 TA 值, 可推算 UE 到基地台的粗略距離. 在下圖中, 即展示了不同使用者位置對應的服務基站與 TA 數值: 來自:  https://www.sharetechnote.com/html/Handbook_LTE_TimingAdvance.html 然而, TA 作為定位資訊也有以下的限制: 1) TA 只能由 Serving Cell 量測與控制: 由於 TA 是針對 uplink 傳輸同步的參數, 非 Serving Cell 並未接收 UE 的上行訊號, 無法估計或是取得 TA 資訊, 無法實行多個基站的偕同定位 2) 因 TA 值有一定的精度限制, 只能作為粗略定位參考: 此數值和...