Castle on a Cloud

在這一系列文章中, 我們跟隨著教學文件"安裝"了 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 數值, 這也就是此範例提供的目標, ...