Castle on a Cloud

針對 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...

在完成了 Sionna RT 的範例後,  我們接著研讀如何藉由 Sionna RT 的模擬資料, 與 Sionna PHY 和 Sionna SYS 進行結合, 在 Sionna 的網頁中, 個有一個對應的範例程式: Sionna PHY:  https://nvlabs.github.io/sionna/phy/tutorials/Link_Level_Simulations_with_RT.html Sionna SYS:  https://nvlabs.github.io/sionna/sys/tutorials/SYS_Meets_RT.html 我們就從這兩個範例介紹, 並著重在和 Sionna RT 介接的部分. 就先從 Sionna PHY 的範例開始, 在 Link_Level_Simulations_with_RT 的範例中, 整體的執行步驟可以分成以下的程序: 建立 Ray-Tracing 場景 (Sionna RT) 將 Ray-Tracing 通道導入 Sionna Channel 模型 (Sionna PHY) 輸入為 CIR 資料, 包含: delay, gain 的數據 根據場景, 產生一整個 CIR 資料集合 設定 Sionna PHY 對應的設定 執行模擬並評估效能 其中, 最為關鍵的是在第二步驟,  也就是把 Sionna RT 產生的通道放入 Sionna PHY 模擬, 在這一步驟中, Sionna RT 取出的資料值為 CIR 的形式 (tab 轉換後), 並把產生的資料存入一個資料集, 作為之後 Sionna PHY 訓練之用. 在 Sionna PHY 與 Sionna RT 的整合中,  使用 Sionna RT 的資料包含了時間延遲, 以及通道增益, 不包含通道的相位資訊, 至於在 Sionna SYS 中使用的 Sionna RT 資訊更少, 是透過 CFR 資訊轉換出來 SINR 數值, 其功能方塊圖如下:  其中, 上圖所標示的功能介紹如下:   Sionna RT 的模擬, 用以產生 CIR 資訊, 並轉換成 CFR 計算對應 SINR 數值 PHYAbstraction: 用來虛擬化實體層 (Physical Layer) 的計...

我們就從 Sionna RT (Ray Tracing) 開始吧, Sionna 的安裝過程已經包成 pip 套件, 通常是不會遇到甚麼問題. 如果擔心和現有 python 環境衝突, 可以用 miniconda 之類的套件處理. 安裝好 Sionna 之後, 我們就按照其範例進行實作: https://nvlabs.github.io/sionna/rt/tutorials/Introduction.html 在開始介紹 Sionna RT 之前, 我想先列一下 3 項和 AODT 的差異: Sionna RT 對場景定義使用 XML 格式, AODT 使用 USD 格式 Sionna RT 不包含 cuMAC 和 cuPHY  Sionna 不包含即時的互動介面 (AODT 藉由 Omniverse 平台實作) 在 Sionna RT 的介紹範例中, 介紹了如何載入場景, 設置基地台與使用者, 並進行通道模擬, 取出模擬通道中的通道響應, 並搭配可視化界面呈現. 由於 Nvidia 技術文件其實寫得很好, 整體執行範例也不成問題, 所以, 我們在這邊就以整體執行流程的概念來說明, 我們列出整體流程如下: 載入場景（Scene）[block 1-12] 在範例中是以 Mitsuba XML 檔載入, Mitsuba 為 Ray-Tracing Model 的底層套件 可使用 Blender 搭配 OpenStreetMap 資料建立場景 場景的圖示化須設置攝影機位置, 並針對攝影機與場景的互動, 產生如下圖片 針對場景, 另一個重點是場景中物件的特性, 這邊可以看 SceneObject 的定義 透過 SceneObject 的設定, 可以設定場景中物體的電磁特性（如混凝土、玻璃等） 放置裝置（Transmitter & Receiver）[block 13] 定義發射器與接收器的位置與天線陣列 scene.rx_array = PlanarArray(num_rows=1,                              num_cols=1,       ...

之前停頓了一段時間, 沒有繼續寫 Sionna 的文件, 看起來或許是一件好事, Sionna 在 Nvidia 的 GTC 2025 中, 公布了正式的 1.0 版本, 連結如下: https://nvlabs.github.io/sionna/index.html 相較於之前 0.19 的版本,  Sionna 1.0 版中, 明確地把 Sionna 分成三個部分: Sionna RT: A lightning-fast stand-alone ray tracer for radio propagation modeling Sionna PHY: A link-level simulator for wireless and optical communication systems Sionna SYS: System-level simulation functionalities based on physical-layer abstraction 其中, Sionna RT 也就是底層通道模擬的部分, 如之前所述, 這邊需要定義基站和使用者位置, 環境,  系統則會模擬出每一對基站到使用者訊號強度. 第二部分, Sionna PHY 則是利用模擬的通道來進行 PHY 層的計算, 對於 Sionna PHY 而言, 輸入可以是統計的通道 (AWGN, Rayleigh fading), 進行包含包括調變, 編碼, 通道, 接收與解碼的不同功能, 當我們要把 Sionna PHY 和 Sionna RT 進行整合時, 我們可以把 Sionna RT 的輸出存成 sionna.channel 的形式, 表示通道的時間響應 (Channel Impluse Response, CIR), 作為 Sionna PHY 的輸出, 下圖為 Sionna RT + Sionna PHY 結合的範例, 先透過模擬基站 (紅圈) 與使用者 (紅點) 的通道, 記錄下來, 之後放入 Sionna PHY 中進行後續模擬. 來自:  https://nvlabs.github.io/sionna/phy/tutorials/Link_Level_Simulations_with_RT.html 最後, 對於 Sionna SYS, 這一個布建基...

我們就從 Sionna 的安裝開始吧! Sionna 可以簡單的用 Google Co-lab 開啟, 但我們還是開立一個新的 linux 環境來進行安裝. 主要的操作, 請參考:  https://nvlabs.github.io/sionna/installation.html 首先, 先建立一個 conda 環境, 並進入: conda create -n sionna conda activate sionna 接著, 透過 pip 安裝 Sionna 相關套件, Sionna 的相依套件已封裝至 sionna 這個軟體安裝組合中, 除了 sionna 之外, 為了進行圖形化顯示, 我們還需要安裝 jupyter notebook, 提供圖形的顯示, 安裝指令如下: (sionna) ov2@ov2:~$ pip install sionna Defaulting to user installation because normal site-packages is not writeable  Collecting sionna [...] (sionna) ov2@ov2:~$ pip install --upgrade ipykernel jupyterlab jupyter 這邊 jupyter notebook 還需要一些額外的設置, 使外部的編輯需求可以連入, 考慮到此處的設定和伺服器相關, 便不再詳述, 主要步驟即是設定對外 IP 並對 port 進行 NAT 轉換. 安裝完成後, 我們先透過 python 的介面檢查 Sionna 是否可以正確引入, 其對應的指令如下: (sionna) ov2@ov2:~$ python3 Python 3.10.12 (main, Jan 17 2025, 14:35:34) [GCC 11.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sionna >>> print(sionna.__version__) 0.19.1 這邊我們可以看到可以正...

在一系列文章的最後, 我們進入 Sionna 的介紹, 考慮到 Sionna 只有少數的硬體需求, 我們在此系列文章中, 將介紹 Sionna 的安裝, 環境建立, 以及模擬. 在整體 Sionna 的介紹中, 我們也將側重兩個部分: 光跡追蹤 (Ray-tracing) 通道模型 通道參數對於 5G/6G 通訊應用的轉換 在開啟一系列文章之前, 我們還是先看看 Sionna 如何介紹自己: 來自: https://nvlabs.github.io/sionna/ Sionna 是用以發展 5G 與 6G 相關的研究套件, 支持: MIMO link-level 模擬, LDPC/Polar 編碼解碼, OFDM 通道估測與分配 Sionna 基於 Tensor-flow 開發, 可以使用 GPU 加速, 但也可以單獨使用 CPU 可以使用 Google Co-lab 與 Jupyter 環境編譯操作  來自:  https://developer.nvidia.com/blog/jumpstarting-link-level-simulations-with-sionna/ 事實上, Sionna 的整體實作核心是光跡追蹤的通道模型, 對於此部分的通道模擬機制, Sionna 有單獨的文件介紹:  https://nvlabs.github.io/sionna/em_primer.html 透過此通道模型, Sionna 可以進行 CIR (Channel Impluse Response) 的計算, 並據此取得 5G/6G 通訊環境中, OFDM symbol 的強度響應, 進行後續的資源分配與網速的分析. 基於光跡追蹤模型, Sionna 也提供了 RIS (Reconfigurable Intelligent Surfaces) 的模擬套件, 用以提供 6G 架構下, ISAC (Integrated Sensing and Communications) 的演算法開發, 針對通訊演算法部分,  Sionna 側重通道估測, 以及編碼-解碼設計, 希望透過以 GPU 加速的 5G/6G 通道模擬系統, 加速 5G/6G AI RAN (Radio Access Network) 的發展.

在這一系列文章中, 我們跟隨著教學文件"安裝"了 cuRAN 的環境, 列出了一些需要注意的事項, 也介紹了 cuRAN 的架構, 雖然, 這畢竟不是真的安裝, 可以預期真實安裝應該會遇到更多問題, 尤其在版本相依的障礙下, Nvidia 並沒有花太多時間測試相容性問題, 或許, 最快的方法就是買一套 Supermicro GH200 + BF3 的設備, 按照官方步驟進行系統建立. 因此, 在最後一篇 cuRAN 的文章中,  我們先回顧一下 cuRAN 的架構, 如下圖所示 (Open Air Interface): 來自:  https://openairinterface.org/news/openairinterface-demonstrates-5g-virtual-ran-with-nvidia-aerial-sdk/ 在上圖 OAI 的實作中, 使用的是標準的 cuRAN 架構, 可以提供 4T4R 的 O-RU 與 4T4R 的使用者裝置對接, 考慮到 cuRAN 中的 cuMAC 和 cuPHY 源自於原有 OAI 的實作, 在 OAI 與 Nvidia 的合作中, 著重在系統的串接, 提供了 O-CU, 部分 O-DU 以及 Core Network 的 OAI 解決方案. 透過 cuRAN 的 E2E 測試可以達成怎樣的效能呢? Nvidia 也對其效能測試建立了如下的效能指標 (ARC-OTA 1.5): MIMO layers DL: 2 layers -> 4 layers Peak throughput SMC-GH (新架構) DL: ~1.03 Gbps UL: ~125 Mbps Dell R750 / Gigabyte Edge E251-U70 DL: ~800 Mbps 說實話, 上述的效能指標,  大概就是一般的 O-CU/O-DU 連上 O-RU 的效能, 甚至還更低一些 (通常 DL E2E 測試應可到達 1.7 Gbps), 在此看來, AI-RAN 無法將這些高階 GPU 的計算效能, 轉換成通訊效能, 這一部分是由於當前的技術限制 (OAI 原有的限制), 另一方面, 單基站 E2E 的測試原本即非 Nvidia 計算框架的強項. 在 Nvidia 的設想中...

針對 O-RAN 架構下的網路同步, 可以分成以下 4 架構: LLS-C1 Configuration (DU-RU 對接, DU 為同步源) LLS-C2 Configuration (DU-RU 透過 fronthaul switch 對接, DU 為同步源) LLS-C3 Configuration (DU-RU 透過 fronthaul switch 對接, fronthaul switch 為同步源) LLS-C4 Configuration (DU-RU 對接, DU/RU 各自和 GPS 同步) 其中, LLS 代表 Lower Layer Split, 這邊是因為 3GPP 雖然定義了 CU/ DU 間的切分位置, 但是, DU 和 RU 間的功能切分並沒有統一的規範, 而給各廠家不同實作的空間, 4 種不同同步架構也就是在不同網路框架下, 設定不同同步訊號源的方式, 其中, 主要的同步訊號源 (Grand Master) 都是 GPS 訊號, 其他同步裝置 (client) 則透過 PTP (Precision Time Protocol) 方式進行精確同步. 4 種不同的同步架構可以表示如下圖: 來自:  https://www.techplayon.com/o-ran-fronthaul-transport-synchronization-configurations/ 在實作中, 常用的架構包括 C1 和 C3, 對應不同的應用情境, 在 C1 的實作中, GPS 訊號源接入 DU 裝置, RU 透過 PTP 和 DU 同步, 在此架構下, 適合由單一 DU 接出多個 RU 裝置同步, 同時, 每個 RU 的訊號獨立接入 DU, 可以設立獨立的 PCI, 作為單獨的 Cell, 相對的, 在 C3 的架構下, 同步的中心是一個額外的 T-GM (Telecom Grand Master), 並連上 DU 和 RU 間的 fronthaul switch, DU 和 RU 都和 T-GM 進行 PTP 同步, 此架構對應的是 Cell-free 的網路框架, 所有的 RU 共享相同的 PCI, 進行通訊. 若是使用 C1 的框架, 對 DU 所在的硬體就有作為 T-GM 的需求, 也會增加 cuRAN 的實作複雜度,...

在做 Open Source 的專案時, 常常覺得 Open Source 就像是迷宮, 要在大量的資料以及討論串中, 尋找有用的資源. 總是想到著名的大教堂與市集的比喻,  作為一個初始的開發者, 總是沒辦法貢獻市場甚麼, 頂多就是作為一個有經驗的迷航者, 未來尋路的旅人指指方向. 科隆大教堂聖誕市集（照片：Shutterstock） 回歸正題, 在一系列尋找後, 我們可以找到當年的安裝文件, https://docs.nvidia.com/aerial/archive/cuda-accelerated-ran/24-1/aerial_cubb/cubb_install/installing_tools.html 在文件中, 我們可以看到其安裝的需求, 包含如下: Install the GPU card and CX6-DX NIC (GA100 + CX6-DX MCX623106AE-CDAT). Connect the CX6-DX port 0 on both servers using a 100GbE cable. (另一邊為 RU 模擬器, 皆需要 CX6-DX 網卡) Connect the Internet port to the local network. 針對 CX6-DX 網卡 driver 的安裝, 可以參考: https://docs.nvidia.com/aerial/archive/cuda-accelerated-ran/24-1/aerial_cubb/cubb_install/installing_tools.html#install-rshim-and-mellanox-firmware-tools-on-the-host CX6-DX 網卡為 Nvidia 收購 mellanox 後推出的產品, 有其自己特殊的 driver 設定,  在安裝好 CX6-DX 網卡後, 要把 MAC 為只填入對應的設定檔.  針對 GPU 的安裝, 在此範例中, 使用的 CUDA 版本為: 535.54.03, 同時, 還需要停止 Nouveau 並安裝額外的 GDRCopy Driver, 用以進行低延遲記憶體搬移. [更新] 這邊需要注意一下, GDRCopy 對 cuRAN 是必須功...

我們先來介紹一下 cuRAN 所需要的安裝環境, 在現有的架構中, Nvidia 一共有在 三個硬體框架 下進行實作: SMC-GH: Supermicro Server ARS-11GL-NHR (Config 2) Dell PowerEdge R750 Server + A100X Gigabyte Edge E251-U70 Server 其中, 3. 是在 Intel CPU 與 GPU (GA100) 協作的架構下完成, 而 1. 則是透過 ARM-based CPU (NVIDIA Grace) 與 GPU (GH200) 協作, 2. 的架構則把計算都整合至 A100X GPU 加速卡. 來自:  https://docs.nvidia.com/aerial/aerial-ran-colab-ota/current/text/installation_guide/procure_the_hardware.html   在 Nvidia 提出的架構中, 為了最大化其 CUDA 平台的計算, 我們可以看到其計算的重心一路從: CPU 架構下的 GPU 運算協作 (架構 3),  變成以 GPU 架構為主的計算 (架構 2), 整合 ARM-based CPU 提供整體運算平台 (架構 1). 這樣計算框架的演進, 也展示了近幾年運算框架的改變, 與 Nvidia 的雄心. 不過, 相對的, 為了讓我們更快的了解 cuRAN 需求, 我們從架構 3 進行說明. 在架構 3 的應用中, 我們需要的元件包含: Intel CPU (Intel Xeon Gold 6240R) RAM (96GB DDR4) GPU (Nvidia GA100) NIC (MLX CX6-DX MCX623106AE-CDAT) 其中, 最特別的是網路卡的需求, 我們來看一下這張網卡的細節, 根據官網敘述, 這張網卡的功能如下: ConnectX-6 Dx EN adapter card, 100GbE, Dual-port QSFP56, PCIe 4.0 x16, Crypto, No Secure Boot, Tall Bracket 來自:  https://www.gotodirect.com/mcx623106ae-cdat-m...

雖然, AODT 還有很多可以介紹的, 不過, 我想我們就先暫時停在這邊, 先進入下一個章節: cuRAN, cuRAN 全稱為: Aerial CUDA-Accelerated RAN,  顧名思義, 即是透過 Nvidia CUDA 計算平台加速的行動網路, 對於 Nvidia 而言, 縱使 AODT, 或是其對應的數位雙生概念, 才是主要的發想, cuRAN 也是其在電信產業的敲門磚, 證實其有能力進行實作, 並透過 CUDA 加速, 甚至是優化現有的電信網路. 考慮到這樣的面向, 我們不針對 cuRAN 中的單元一對一介紹, 相反的, 我們直接從其 E2E (End-to-End) 的展示開始, 對於 Nvidia 如何串接 CUDA 平台, 並展示其實體通訊能力進行介紹, 相關的內容在:  1) 影片介紹:  https://www.nvidia.com/en-us/on-demand/session/other2023-arc/ 2) ARC-OTA 文件: https://docs.nvidia.com/aerial/aerial-ran-colab-ota/current/index.html 3) blog 介紹:  https://developer.nvidia.com/blog/introducing-aerial-research-cloud-for-innovations-in-5g-and-6g/ 在這邊先解釋一下, 我們主要的參考文件來自於 ARC-OTA, 而不是來自於之前介紹的 cuBB 文件, 兩者使用的版本些落差, 在 ARC-OTA 中, 使用 24-1 的 cuBB 版本, 同時並未實作 cuMAC:  https://docs.nvidia.com/aerial/aerial-ran-colab-ota/current/text/getting_started/index.html 在 CU/DU 層, 則使用 OAI 的解決方案. 來自: Nvidia Technical Blog 在 Nvidia 2024 年的 DEMO 架構中, 我們可以看到可以分成 5 個部分: 5GC: OAI - 2024.w21 CU/DU-high: OAI - 202...

在 AODT 中, 另一個重要的特色即在於對 AI/ML 演算法的支援, 在 Nvidia 的初始想法中, 數位雙生的主要目標即在於產生訓練模型用的訓練資料, 也因此, AODT 也提供了一個 AI/ML 的範例, 展示如何透過 AODT 所產生的訓練資料, 進行模型的訓練. 關於這一部分的內容, 相關的文件內容可以參考: https://docs.nvidia.com/aerial/aerial-dt/text/ran_digital_twin.html#simulation-mode-3-ml-examples 在此範例中, 強調的是如何透過 AODT 平台鑲嵌 AI/ML 演算法, 在 AODT 1.1 中, 提供兩個範例, 第一個是 CFR 的預測, 如下圖所示: 在此範例中, 輸入是 EM engine 產生的通道數值, 以 CFR 的方式進行呈現, 其基本想法即是透過收集加入雜訊後的 CFR 數值, 作為輸入, 以神經網路回估原始未加雜訊的 CFR 變化, 不過在此範例中, 通道的估計器 (Channel Predictor, 上圖橘框) 並不是一個泛化的估計器, 而是針對每一組傳送-接收端, 都有一個獨立實作模型, 因此, 期能夠預測的也只有時間上的變化 (N=5 slots 後的通道效應), 考慮在 AODT 環境中, 使用者移動模型為在開放場域中直線移動, 應可以透過數個連續的 CFR 數值, 預估短時間內的通道變化, 也就是有效反射路徑的連續變化. 另一個範例的應用也是通到估計, 不過, 其設計則是用以展示 AODT 進行模型優化的能力, 在此範例中, 先以 Sionna 的統計通道模型對模型預訓練 (ML Channel Estimator, 下圖橘框), 在以 AODT 實際的通道輸入 (解調完的 DMRS) 作為即時估計輸入, DMRS 全名為: DeModulated Reference Symbols, 存在於 PUSCH (上行排程的通道), 然而, 對於單一的使用者而言, DMRS 只佔有部分的通訊資源 (Resource Block), 因此, 若我們要利用 DMRS 訊號幫助下行的排程 (scheduling), 我們必須利用少量的通道響應, 內差與外插出整體頻寬的通道變化, 也就是 CFR 數值, 這也就是此範例提供的目標, ...

在這篇文章中, 我們介紹一下 AODT 可以取得那些模擬參數, 考慮到在 AODT 框架下, 計算 (backend) 與顯示 (frontend) 是分離的,  中間資料交換部分, 則是透過 ClickHouse Database 進行, 因此, 所有可以透過 AODT 介面顯示 (frontend) 的模擬資訊,  都可以透過 ClickHouse 的資料庫讀取來取得.  關於 ClickHouse 資料庫內部的欄位可以參考 AODT 的官方文件: https://docs.nvidia.com/aerial/aerial-dt/text/additional_info.html#database-tables 其中, 我們先大致整理一下表格內容, 並分類資訊類別: AODT 系統模擬參數:  db_info, time_info 環境參數: scenario, materials 通道模擬結果: raypaths, cirs, cfrs RAN 設定: panels, patterns, rus, dus 使用者與移動性: ues,  RAN Simulation: telemetry,  ML Training 結果: training_result 其中, 多數的內容應該直接查看網頁中的定義就可以理解, 因此, 我們就專注在 raypaths 與 telemetry 這兩個跟模擬結果直接相關的部分, 針對 raypaths 部分, 資料庫列出了每一條互動路徑的數值, ru_id, ue_id 代表了傳輸路徑的兩端, points 則代表了中間產生互動 (interaction) 的位置, 互動分成 5 類: 發送 (emission), 反射 (reflection), diffraction (繞射), diffuse (散射), reception (接收), 透過記錄下每一次互動的時間, 位置, 以及對應的訊號強度變化, 便可以完整表示出電磁波在環境中的互動狀況. 值得注意的是, 目前 AODT 並沒有模擬電磁波的穿透效應 (折射, 衰減), 因此, 能夠應用的範圍仍侷限在室外的場域中,  另外, 這些路徑的接收強度疊加就會表示為 CIR (cirs) ...

在一開始的介紹中, 我們貼了一張 AODT 的架構圖, 可以清楚地分成三個部分: 使用者介面: 進行模擬情境的定義 通道模擬器: EM solver 以光跡追蹤模型模擬 CIR 和 CFR RAN 模擬器: cuMAC 和 cuPHY 進行網速模擬 這樣的架構, 清楚的切分出 AI-RAN 模擬的挑戰, 以及所需要的計算套件. 不幸的是, 在系統實作上, 有更多其他的限制需要考慮, 有些時候, 還必須受限於既有系統的框架. 來自:  https://docs.nvidia.com/aerial/aerial-dt/text/overview.html 上圖是實際 AODT 的實作框架, 原本 3 分的計算架構, 改成 2 分式, 對應於前台 (front-end) 與後台 (back-end), 中間資料交換的部分, 透過 Nvidia 的 Nucleus Server 以及對應的 Neculeus Connector, 以 Server-Client 的架構進行實作, 也或許因此改成二階段框架, 減少中間資料交換, 中間資料交換的部分是以 ClickHouse 進行實作, 提供 SQL-like 的資料存取. 在介紹完資料交換的元件之後, 接著我們透過 AODT 執行流程來說明各元件功能: Scene Important 根據 CityGML* 格式的檔案, 產生對應的 3D USD* 模型 AODT front-end 進行模擬的設定, 可以分成三種模式: (a) Channel Simulation, (b) Channel + RAN Simulation, (3) Channel Simulation + ML training 將計算設定透過 Nucleus Server 傳送給後端, 進行計算 後端將計算完後的結果, 傳到 ClickHouse 儲存 前端的 AODT 介面撥放後端計算完的結果 Note 1: CityGML 為針對城市定義的 3D 模型 ( https://www.citygmlwiki.org/index.php ) Note 2: USD 為一種開放的 3D 場景 (Scene) 描述語言, 為 Nvidia 所採用, ( https://www.nvidia.com/zh-tw/omniverse/usd/ )...

就讓我們從 Aerial Omniverse Digital Twin 談起吧!  為了減少打字的麻煩, 在後續文章中簡寫為 AODT, 以 AODT 作為介紹的起點, 一方面是因為他有完整的使用者介面, 可以視覺化的呈現 AI RAN 的應用與概念, 另一方面, AODT 也有善用到 CUDA 的平行運算能力, 我們可以介紹 Nvidia 對於 AI RAN 的投入. 我們先從 AODT 的是範例出發, 可以參考以下影片: 來自:  https://www.youtube.com/watch?v=J5-rkgL2dFA 在影片中, AODT 展示了兩個主要的能力: 透過 3D 城市建模, 模擬電磁波實際和場景互動 模擬使用者的移動行為, 即時計算傳送端到接收端的訊號變化 透過以上兩個能力, 在布建基地台前, 我們就可以評估是否有訊號死角, 不必像傳統的行動網路業者, 還需要開車去做事後評估與補強, 同時, 這些模擬不只是訊號強度, 還包含了通道的時域 (CIR) 與頻域 (CFR) 特徵, 可以直接匯入 cuMAC 和 cuPHY 的模組中, 進行網速的評估. 因此, AODT 可以提供一個大型通訊網路在一個城市中的數位雙生 (Digital Twin), 這些收集來的通道資訊, 更可以作為 AI/ML 模型的訓練資料, 透過大量的訓練資料, 賦予通訊網路引入 AI/ML 能力的潛力. 看起來非常厲害, 簡直就是無線通訊的未來對吧? 一方面, 是的. Nvidia 憑藉著其對 GPU 平行運算能力的掌握, 將原有無線通道模擬的速度從小時, 推進到分鐘. (依據我們的經驗) 這樣的模擬速度與尺度, 的確讓大量訓練資料產生變成可能, 同時, 考量到 AI/ML 模型的訓練需要大量的資料,  AODT 也的確解決了 AI-RAN 訓練資料從何而來的問題. 另一方面, AODT 1.0 版的發布時間為 2024 年 4 月. 作為一個年輕的專案, 其本身一定會有許多限制 (以及 bugs ...) 我們將在後續文章中, 先介紹其實作框架, 以及各元件功能, 接著, 我們將繼續介紹他們的限制,  給予 AODT 目前的狀態一個較全面的評估.

隨著 AI 在近年的興起,  Nvidia 憑藉著其 CUDA 平台的平行計算能力, 在 AI 領域取得了大量的成功, 為了推展 CUDA 的應用, Nvidia 推出了一系列 Omniverse 的服務, 其基本的想法是: 隨著平行化運算晶片的發展, 算力將更加便宜, 此時, 對於 AI 模型的問題將不是算力限制, 而是訓練資料不足, 因此, Nvidia 希望透過 Omniverse 的數位雙生技術 (Digital Twins), 來提供訓練模型的大量訓練資料.   *Note: 可以參考黃仁勳於 Computex 的演說: https://www.nvidia.com/en-us/events/computex/ 在 Nvidia 為了通訊系統 (稱為 Aerial RAN) 的生態系中, 又可以分成三個不同的專案: Sionna:  https://nvlabs.github.io/sionna/examples/Discover_Sionna.html Aerial Omniverse Digital Twin:  https://docs.nvidia.com/aerial/aerial-dt/index.html Aerial CUDA-Accelerated RAN:  https://docs.nvidia.com/aerial/cuda-accelerated-ran/index.html 在整體 AI-RAN 的架構中, 可以用下面這張圖來表示各分項的功能: 來自:  https://developer.nvidia.com/blog/boosting-ai-driven-innovation-in-6g-with-the-ai-ran-alliance-3gpp-and-o-ran/  在 Nvidia 的 AI-RAN 架構中, 區分成三個層級: Link-level: 模擬通道特性, 並分析網路的效能, 對應於 Sionna System-level: 包含 cuMAC, cuPHY 的模擬, 對應於 AODT End-to-End: 介接其他設備 (CU/DU/RU), 提供真實 5G 連線, 對應於 Aerial RAN   在實作上, 其中的差...

在這一系列文章的最後, 我們來介紹一下波束管理的應用. 事實上, 由於引入 mmWave 的頻段, 波束管理一直是 5G NR 中的重要問題. 波束 (beamforming) 可以視為是往特定方向增強的訊號, 透過最佳化波束的指向, 我們可以為無線通訊引入一個新的角度: 空間, 並透過空間上的多工, 達成更高的通訊效能與更低的干擾. 然而, 在空間上聚焦, 意味著網路必須能夠掌握使用者的位置, 並能夠快速地根據使用者在空間上的變化, 進行波束的配置. 波束管理 (Beam Management) 在通訊的研究上本身就是一個大集合, 不論是波束搜尋, 波束追蹤, 波束配置, 都有許多相關研究, 然而, 在 3GPP 的框架中, 特別在乎的是實際通訊場域中要如何使用波束, 以及 AI/ML 可以達成的角色, 這又可以分成三類題目: (1) 利用 AI/ML 學習通道在環境中的非線性變化, 避免數學的過度簡化 (2) 如何透過 AI/ML 的方法, 減少波束掃描的次數 (3) 透過 AI/ML 進行波束的預測 (學習使用者的動態行為) 為了解釋上述問題, 我們先解釋一下目前波束搜尋的框架, 分別對應網路與手機端的應用, 如下圖所示: 來自:  https://www.sharetechnote.com/html/5G/5G_AI_ML_PHY_BM.html 在圖中, 我們可以看到可以分成: P1, P2, P3 三個階段, 分別對應於 Set B (較寬的波束) 與 Set A (較窄的波束),  其中, 要進行波束管理的前提即是要有對應的量測資料 (L1-RSRP), 考慮到波束掃描與量測都需要時間, 都會造成通訊資源的損失, 因此, 如何減少掃描的次數, 或是有效地從 Set B 推論 Set A 中有效的波束, 即是 AI/ML 演算法可以介入的地方. 相同的問題命題, 在方向 (1) 中則表現於 Set B 與 Set A 的空間關聯性, 如何透過 AI/ML 的上進行建模, 可以得到 Set B 與 Set A 的對應, 對應於方向 (3), 則是透過動態模型來進行波束的預測, 減少波束進行掃描的次數, 以及對應要消耗的計算資源, 以上的應用方向, 也就是 AI/ML 最受期待能夠直接應用於 5G NR 的領域.

介紹完 AI/ML 在定位領域的應用後, 我們接下來介紹 AI/ML 模型用於 CSI 處理的應用, CSI 全稱為 Channel State Infomation, 用以表示通道的細部變化, 相較於傳統上 RSRP 的訊號強度資訊, CSI 的資訊可以反映出訊號在時間或是頻域上強度的變化, 可以用來進行 precoder 的設計, 或是進行定位演算法開發. 然而, CSI 資訊也引入了新的問題, 包含了估測與回傳. 考慮到在下行的應用情境下, SSB (Synchronization Signal Block) 由基地台發出, 裝置端透過接收此訊號, 進行通道估測並取出 RSRP 與 CSI 資訊, 並將 RSRP 與 CSI 資訊回傳至基地台, 讓基地台進行 precoder 的選擇. 因此, 對基地台而言, CSI 的回報數量就和服務的使用者數量呈正比, 同時, 每一筆 CSI 回報又包含在不同頻帶上的量測數值, 因此, 如何減少回報的數量, 以避免佔用太多通訊資源, 是一個重要的問題. 在傳統上, 有兩種做法可以對 CSI 回報進行壓縮, 第一種是基於 codebook 的方法, 在此架構下, 基地台和使用者分享一共同的 codebook, 因此, 使用者回傳時只需要回傳最接近 CSI 的 codebook 編碼, 這種方法雖然可以有效地減低傳送資料量, 但是卻會有失真的問題, 第二種方法則是透過壓縮感知方式 (Compressive Sensing) 進行 CSI 資訊壓縮, 此方法需要一預定的感知矩陣 (sensing matrix), 此矩陣對於所有使用者的一般性, 以及壓縮感知方法本身的稀疏性假設, 會是此方法的限制. 考慮到 AI/ML 演算法的發展,  3GPP 也開始討論如何借力於 AI/ML 方法減少 CSI 的回報量, 事實上, 上述所說的壓縮感知也算是一種 ML 方法, 因此, AI/ML 在此應用中的主要價值應該在於使用者可以動態學習壓縮方法, 並且透過資訊分享的方式, 讓基地台可以近乎無損的取出 CSI 資訊, 目前主要討論的方法包含: SVD, reinforcement learning, Encoder-Decoder 架構. 如下圖所表示: 來自:  https://www.sharetechnote.co...