Castle on a Cloud

最近實在是太忙碌了, 以致 2 月的第二篇拖到現在才寫, 原本是想說, 也該找時間回補一篇文章, 達成一個月兩篇的自我承諾, 不過看了看自己的行事曆, 還是不要把承諾給得太輕易好了... 回歸正題, 在上一篇文章中, 我們介紹了 DPU 以及 DOCA 的源起, 接著, 我想我們就從 DPU 的架構來說明, 這樣的功能如何實現, 在開始討論以前, 我想先談談兩個我之淺搞混的產品: ConnectX: 本質上還是 NIC, 但具備硬體卸載 (offload) 能力來減少 CPU 負擔 BlueField: 這個才是 DPU, 具備 ARM CPU 獨立晶片, 也是我們討論的目標 針對 Nvidia CuRAN 的功能, 以上兩者皆能支援, 若以實作上的功能簡單化來說, 使用 ConnectX 可能可以少走一些路. 那我們就從 DPU 的架構開始吧: 來自:  https://docs.nvidia.com/networking/display/bluefieldbsp480/bluefield+software+overview 看到這張圖, 就代表我們要先對其中專有名詞說文解字一下: Rhsim 是 BlueField DPU 的模擬環境，允許在同一台 BlueField DPU 上同時運行 Host 和 DPU 環境，以測試 DPU 處理流量的能力 (這個我們之後再介紹) ConnectX Port 指的是 NVIDIA ConnectX 系列網路介面卡 (NIC) 的網路埠 (Port)，這些埠可用於各種高速網路通訊, 例如: Ethernet、InfiniBand、RDMA RDMA (Remote Direct Memory Access) 允許伺服器之間直接存取彼此的記憶體，而不經過 CPU 處理 在上圖中, 我們可以看到 DPU 基本上就是 ConnectX 網卡和 ARM CPU 的組合, 這裡增加的 ARM CPU 一方面提供一個簡單的作業系統 (BlueField OS), 另一方面, 也可以透過此作業系統上的 OpneVSwith 提供 SDN (Software Define Network) 功能. 來自: https://www.servethehome.com/nvidia-bluefield-3-dpu-archite...

由於近日工作有所插斷, 所以就來改看一些 DPU 的文章, DPU (Data Processing Unit) 是 Nvidia 生態圈中比較不亮眼的一支, 但卻也是一個建構新型態運算的重要角色. 在 Nvidia 的新型態運算框架中,  主要的目標就是要從以 CPU 為主的計算架構, 改成以 GPU 為主的架構,  這其中有一個困難處, 就是計算透過網路平行化的效能, 為了處理大量的資料, 資料中心必須考慮多個節點的資料平行化, 這些平行運算的資料, 就需要透過網路在各節點中透過 CPU 處理並交換, 因此, 整體運算的瓶頸仍是在 CPU 的運算上. 為了打破這樣的架構, Nvidia 在 2019 年收購了 Mellanox, 並開始開發 DPU 的產品, 用意在直接串連 GPU 的運算算力,  提供資料中心以 GPU 為基礎的計算架構. 來自: https://docs.oracle.com/zh-tw/learn/gpudirect-rdma-ib-write-bw/index.html#introduction 為了達成以 GPU 為核心的平行計算架構,  Nvidia 使用 RDMA (R emote Direct Memory Access, RDMA ) 技術來串聯 GPU, 並透過 DPU 與 GPU 之間的 PCIe 匯流技術 ( Direct Memory Access, DMA ), 繞開 CPU 端到端間的存取, 讓不同節點上的 GPU 可以進行資料交換, 進而提供跨節點的 GPU 平行化計算框架.  來自:  https://developer.nvidia.com/blog/demystifying-doca/ 和發展 CUDA 的策略類似, Nvidia 也希望發展 DPU 的環境形成業界標準. 相對於 CUDA 主要為 CPU 的核心平行化, DPU 這邊的環境稱為: DOCA (Data-Center-Infrastructure-On-A-Chip Architecture), 我們以上圖作為參考的實作框架, 左邊為 GPU 右邊為 DPU, 兩者透過 CUDA 協作,  在 DPU 的框架中, 我們看到有一個 DOCA Runtime, 運作在 D...

我們就從 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 的實作複雜度,...