Castle on a Cloud

在這篇文章中, 我們介紹一下 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) 與 CFR (cfrs). 在 AODT 中並沒有計算 RSRP 的數值, 可能須自行累計. te

在一開始的介紹中, 我們貼了一張 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/ )  在目前 AOD