Castle on a Cloud

在上一篇文章中, 我們介紹了 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...

很就沒有來看 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 先用...

過完忙碌的 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 波形可以...

在本文中, 我們預期從 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. 透過上述的通道模型,  雖然在頻域...

在上一篇文章中, 我們整理了 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...

以下的內容主要來自於此篇文章: 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 等應用會缺乏一些資訊. 基於上述的設定, 我們可以整理此系統的時序設定如下所述...

在前幾篇 PRS 文章中ㄝ,  我們把 PRS 當成由 TRP/gNB 下行發送, 由 UE 量測的定位參考訊號, 並整理了 PRS 相較 SRS 的幾個差異, 例如: muting, 較高功率, 彈性的 comb/symbol, 可做 burst, 同步要求更高等, 以及 PRS 在實作上 (OAI / STARE) 目前的實作成果. 接著, 我們把問題延伸一些, 也就是利用 NTN 衛星網路來進行定位, 為什麼要用 NR-NTN 來進行定位呢? 從標準來說, 3GPP 在 Rel-18 開了方向為 network verified UE location for NR-NTN (TR 38.882), 在需求與 use case 層面把位置驗證當成一個 NTN 會面對的議題. 這代表, 以 NTN 進行定位, 的確被列入未來 5G NR 網路發展的需求, 那麼, 就技術面來說, 為何 NTN 會是一個定位的好選擇呢? 相較於 GPS 系統, 雖然 NTN 時間精準度 (振盪器) 不比 GPS,  但是, NTN 對應的低軌衛星在數量與高度上都更有優勢,  有機會做到更好的定位誤差. 來自:  https://www.ultrontek.com/news_detail/5g-ntn-challenges-architecture-overview 如果比較對象是一般的基站或是地面通訊,  考慮到 NTN 衛星網路的特徵, 會為定位帶來以下問題: 1. 傳播延遲大很多 以 LEO 衛星常見高度範圍 (例如 300–1500 km) 來看,  就算只考慮高度, 單程傳播時間就是毫秒等級,  用 𝑡=𝑑/𝑐 粗估：300 km 約 1.0 ms, 而實際斜距會更長. 2. Doppler 會非常明顯 LEO 相對速度很大，所以 f_d≈(v/c)f_c, 粗估若 𝑣≈7.5 km/s, 在 2 GHz 約 50 kHz, 4.7 GHz 約 118 kHz (只是量級, 實際看軌道與仰角) 這會直接影響 matched filter / delay estimation 時的搜尋範圍與 tracking 難度. 3. 多衛星/多 beam 同頻干擾更容易變成主因 地面 OTDOA 的 PRS 已...

在前兩篇中, 不論是 SRS 或是 PRS 的定位框架, 我們主要討論的是以時間為基礎 (time-based) 的定位方法, 例如: OTDOA, RTT,  在這些方法中, 其核心概念都是將距離差轉換成時間差, 再由時間差 (多點或是單點) 推回裝置的位置資訊, 這類方法在遇到一個根本限制: 時間解析度直接受限於系統可用頻寬. 以 5G NR 的系統而言, 我們可以簡單估算一下: 假設系統頻寬為 100 MHz, 對應的時間解析度約為: 10 ns 乘上光速後, 我們可以得到距離的解析度為 3 公尺, 換句話說, 這種方法在原理上即不可能達成公尺內的定位誤差. 考慮到這樣的限制, PRS 在 Release 18 中, 加入了以相位 (phase) 的定位量測, 此方法稱為: Phase-based Measurement, 此量測包含了: Carrier Phase measurement Phase Difference between TRPs 其核心轉變在於, 我們不只是關心什麼時候收到 PRS 訊號, 也開始關心收到 PRS 的載波是什麼相位. 這個轉變, 使得定位精度的上限, 從頻寬 (e.g., 100 MHz) 轉向載波波長, 以 4.7 GHz 為例, 波長為 6.38 公分, 在此範圍內我們皆可看到相位的變化, 然而, 使用相位資訊進行定位也會有對應的問題, 考慮到相位變化隨波長周期性變化, 單一觀察到的相位將產生大量的重複解, 也因此, 在進行定位時, 實際上需要同時考慮時間, 相位, 甚至是強度資訊, 我們以下圖表示:   來自:  https://arxiv.org/abs/2209.01183 這張圖說明 Carrier Phase 在不同定位解法中所扮演的角色差異: 左側示意在角度式定位架構下, 來自同一 gNB 的多天線訊號. 其接收相位差可與到達角度 (AoA) 結合, 用以提升角度估計的解析度. 此時相位資訊主要作為空間量測的輔助維度. 右側則示意在時間式定位架構中, 多個 gNB 的到達時間 (ToA) 仍構成主要的定位幾何, 而載波相位則可用於細化距離估計, 降低時間量測受限於頻寬所帶來的誤差. 需要特別強調的是, Carrier Phase 本身並非獨立的定位方法, 而是一種高解析度...

針對 PRS 的系統實作, 雖然 3GPP 已在 R16 定義, 同時, 在 RAN 端與手機端也都已有支援, 舉例來說,  Ericsson:  https://www.ericsson.com/en/blog/2020/12/5g-positioning--what-you-need-to-know Amarisoft: https://www.5ghubvaasa.fi/wp-content/uploads/2023/10/5G-positioning-on-interactive-map.pdf Mediatek: https://www.rohde-schwarz.com/uk/about/news-press/all-news/rohde-schwarz-and-mediatek-verify-5g-lbs-release-16-features-on-the-r-s-ts-lbs-test-solution-press-release-detailpage_229356-1238101.html 我們可以看到不論是 RAN (Ericsson) 或是手機晶片 (Mediatek) 都支援 PRS, 然而, 在現實生活中, 我們卻很難看到 PRS 真實於場域中的應用, 這樣的落差主要是來自於在 3GPP 中 PRS 屬於 LMF (Location Mgmt. Function) 的應用, 這部分是額外要訂閱或是付費, 但卻沒有相對應的應用,  因此, PRS 或是 5G NR 的定位技術, 在目前公網的環境, 沒有普及的應用. 相較之下, 定位在企業專網 (Private Network) 中有比較可行的應用, 主要是在企業/工廠的應用場域中, 可能有更多精密定位的需求, 因此, 不論是 Nokia/Ericsson 的白皮書中, 都強調在企業專網的應用. 另一方面, 在開源的社群 (Open Air Interface/ srsRAN) 中, 對 PRS 的支援如何呢? 我們先從 OAI 開始, OAI 從 2022 年開始支援 PRS,  不同於 SRS 有實作整個 NRPPa 的控制信令, OAI 對 PRS 的支援主要是透過 PHY 層的實作來完成, 主要包含兩個函式: nr_generate_prs()：...

在之前的文章中, 我們介紹了 3GPP 中 SRS 的訊號以及定位方法, SRS 主要是上行的定位訊號, 由 UE 進行發送, gNB 進行量測, 與之對偶的是 PRS (Positioning Reference Signal), 由 gNB 發送 UE 量測, 這樣的 PRS 訊號是在 3GPP R16 中被引入, 透過 gNB 廣播的 PRS 資訊, 用以提供進行裝置為基礎的定位方法. 相較於 SRS, PRS 的訊號有以下的差異: 1) PRS 考慮的是基地台間的協作, 因此有 muting 的機制, 使基地台可以分時多工 2) 考慮到基地台的覆蓋範圍, PRS 使用較高的傳輸功率, 並不支援分碼多工 3) PRS 提供較稀疏的 comb 與 OFDM symbol 設定, 可依據設定提供彈性配置 4) 在基站間的 PRS 配置, 可以透過 RRC 曾進行協同, 避免進行基地台間的 PRS 干擾 5) PRS 比起 SRS 在同步上要求更高, 以相位為基礎的定位在 R18 才被提出 6) PRS 支援 burst 配置 (數百 ms, 甚至數秒才發送一次 PRS) 圖來自: https://www.mathworks.com/help/5g/ug/5g-new-radio-prs.html 在這邊值得注意的是, 雖然上述文字中使用 gNB/基地台代稱傳送端, 但是, 實際於 3GPP 標準中的用語是 TRP (Tx/Rx Point), 不只可以對應於一組小基站, 也可以對應於基站的不同傳輸天線, 透過 PRS 的訊號, 我們可以實現以下的定位方法: OTDOA (Observed Time Difference of Arrival): 利用多個基站下行發送的定位參考信號 (PRS), 由 UE 測量相鄰基站與參考基站之信號到達時間差 (RSTD) 進行定位. 最早在 3GPP Release 9 (LTE) 引入, 在 5G NR 中於 R16 支援.  AoD (Angle of Departure): UE 通過測量多基站的 PRS 下行信號不同波束的接收功率, 確定來自每個基站訊號的發射方向角, 用以進行定位 此技術同時需要波束成形與 PRS 支援, 在 3GPP Release 16 中加入標準. RTT 定位 (Round Trip T...

在上一篇文章的後續, 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, 得到通...

在很久之前的文章中 ( 這裡 ),  我們介紹定位方法時, 提到了 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 值有一定的精度限制, 只能作為粗略定位參考: 此數值和...

原本想說結束 Sionna 的系列文章, 結果今天爬文時, 又發現了一個值得寫的內容: Sionna Research Kit (Sionna-RK) https://nvlabs.github.io/sionna/rk/index.html Sionna Research Kit 結合了 NVIDIA Jetson 平台以及 OpenAirInterface, 提供支援 O-RAN 介面, 以及軟硬體整合的 5G 開發架構. 提供一個軟體定義無線電的開放式開發架構, 讓開發者可以實現所發展的 AI/ML 演算法. Source:  https://nvlabs.github.io/sionna/rk/quickstart.html#hardware-requirements 和之前我們介紹過的 cuRAN 不同, Sionna Research Kit 雖然也基於 Nvidia 硬體 (Jetson, 未來會支援 Project Digit), 但並沒有實作 cuPHY 與 cuMAC 功能, 猜測是為了節省 GPU 算力需求, 相對的, 在系統架構上, 也須依賴 B210 開發板來進行 (OpenAirInterface 開發板), 在 Jetson 上, 就只有原本 OAI gNB 原生的功能實作. 這樣的架構, 事實上, 和既有 OAI 在 PC + B210 的系統實作類似, 也因此, Sionna-RK 的功能的特色, 應該在於 Sionna 提供了甚麼樣的功能接口, 使得第三方可以在此平台上快速開發與實現 AI/ML 演算法. Source:  https://nvlabs.github.io/sionna/rk/tutorials.html 在 Sionna-RK 中, 提供了 2 個不同的 AI/ML 應用, 分別是: GPU-Accelerated LDPC Decoding Neural QAM Demapper 用以展示使用 Sionna 將 AI/ML 引入 AI RAN 的能力, 不過, 在這邊需要注意與澄清的是: 目前的整合實作不包含 Sionna-RT, 換句話說, Sionna-RK 的通道, 並非使用 Sionna-RT 進行模擬, (Source: https://nvlabs.github.io/sionna...