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 數值, 這也就是此範例提供的目標, ...

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

我們先從 AI/ML 進行的定位演算法的 Use Case 開始, 3GPP 討論定位已經有一段很長遠的歷史, 不論是使用傳統 3G/4G 的 TDoA 進行定位, 或是嘗試結合其他通訊協定 (WiFi, 藍牙), 隨著定位功能在通訊網路愈來越受到重視, 也有更多的討論進行中. 也因為定位已在之前通訊架構中有許多討論, 在 3GPP 定義裡, 以 AI/ML 進行的定位演算法, 有可以進一步分為: 直接定位 (Positioning Direct AI/ML positioning) 與輔助定位 (AI/ML assisted positioning),  前者繼承自 3GPP 傳統定位框架, 透過 AI/ML 的輔助, 轉換出定位所需資訊 (如: TDoA), 後者則以 AI/ML 演算法直接取出定位目標的位置估測, 希望可以增進定位誤差. 兩種框架的比較如下圖所示: 來自:  https://www.sharetechnote.com/html/5G/5G_AI_ML_PHY_Positioning.html 在所有 3GPP 可以取得的定位資訊中, 最有潛力的應該是 CSI (Channel State Infomation) 資訊, 透過 SRS (Sounding Reference Signal) 可以使基地台估測到上行的 CSI 通道資訊, 此資訊不同於傳統的 TDoA, 訊號強度, 等精細度較低的物理量, 可以精確地反映出電磁波透過與環境 (室內隔間, 障礙物, 等) 互動所得到的通道效應, 相對的, 由於環境的介入, 此類資訊無法預先建立統計模型描述和距離的相關性, 也因此, 需要 AI/ML 的框架進行學習, 甚至是即時訓練, 以下是其訓練框架: Model training and inference - Direct positioning model inference phase (Case 3b) 來自:  https://www.sharetechnote.com/html/5G/5G_AI_ML_PHY_Positioning.html 其中, 在此框架 (Case 3b) 下, AI/ML 不論是訓練或是推論都是在 LMF 上進行, 在原有的定位架構中, 由於 LMF (Location Managem...

在之前的內容中, 我們介紹了 O-RAN 的標準, 並藉受如何透過 RIC 的介入, 使 AI/ML 演算法和 RAN 相結合. 相同的, 受啟發於 AI/ML 的熱潮, 3GPP 也思考如何與其進行整合, 其中, 可以分成以下 3 個整合方向: RAN 1/2/4: AI/ML for NR Interface  RAN 3: AI/ML on NG-RAN: NES, MRO, MLB SA 5: AI/ML Manegement (OAM) 其中, 第一點為這一系列文章中的主題, 我們後續介紹, 第二點則是延續之前 4G 架構中, 對於 SON 功能的討論,  所以可以看到 NES, MRO, MLB 這些對基地台參數最佳化的方法, 只是加入 AI/ML 演算法進行其架構的延伸. 第三點, OAM (Operations, Administration and Maintenance) 也是延續自 4G, 強調對於電信網路的管理, 營運進行視覺化與自動化. 來自: https://www.comsoc.org/publications/ctn/artificial-intelligence-3gpp-5g-advanced-survey 相較於現有網路的管理與最佳化方法的延伸, 在第一點的討論中, 由於跨越了 NR interface, 也就是無線的鏈結, 著重在 AI/ML 於使用者 (UE) 與網路端 (NW) 的協作,  也因此, 在此架構下的第一個重點即是: AI/ML 模型的訓練與推論流程, 而在目前的架構中, 目前仍保有彈性,  進行模型訓練的位置可以是 gNB, 也可以是網路控制器 (RIC, OAM, etc) 至於進行推論可以在 gNB 上進行, 或是將模型傳送至 UE 端進行推論. 來自: https://sharetechnote.com/html/5G/5G_AI_ML.html 在此計算框架下, AI/ML for NR Interface 專注在三個開發的方向: Channel State Information (CSI) 資料處理: 考慮到 CSI 的資料量很大, 可以透過編碼-解碼 (encoder-decoder) 的架構, 減少進行回報的資料量. 在目前討...

在寫第二篇文章前, 先說說自己再來新加坡前的預期, 考慮到一個高所得, 寸土寸金的城市,  我原本預期的是一個小而美的城市: 緊湊, 高效率, 高樓林立下有些壓迫. 實際來到之後, 卻是顛覆自己的猜想, 巨型建築林立, 但是卻不擁擠, 間隔有足夠的綠地以供呼吸. 車輛不多, 但由於發達的公共接駁, 郊區的行人也不多, 大學體系龐大, 建築看起來永遠有一定比例在進行翻新. (左上: NUS 中央圖書館大門; 右上: NUS 中央圖書館; 左下: NUS 理學院建築與空中花園; 右下: NUS 資訊學院建築) 身為一個台灣來的訪客, 彷若身處一個不斷進行都市規劃的城市, 規劃, 翻新, 升級, 再規劃, 彷若是在玩模擬城市一般, 若是有哪一區不符合心意或是預期, 就可以進行翻新與改建. 其實, 在大與小之間的誤解, 應該是來自於資源的投入, 在新加坡, 一共只有四間研究型公立大學: 新加坡國立大學 (NUS) 南洋理工大學 (NTU) 新加坡管理大學 (SMU) 新加坡科技設計大學 (SUTD) 在這次旅程中, 除了 SMU 無暇拜訪外, 其他三間大學都有參觀, 其中, 新加坡各大學的發展都是基於國家的政策需要設立, 並且在設立之初就強調了跟歐美大學與中國大學的合作, 透過實質的合作, 在策略上提升國際知名度以及合作發表論文數, 快速的提升國際排名. 左: 遠方望向 NUS, 右: NUS 圖書館內小展 同時, 也透過國家資源的投入, 重點維持研究大學的硬體與規模, 但是在學術與校園自治上, 卻較類似於美國制度, 以自治法人的形式, 校長對校務會議 (董事會) 負責,  擁有較大的人事與財政權 (捐助基金), 可以募款, 冠名與擴充學校體系, 而不直接受到政府法令的限制. 這不禁讓人想起台灣當年 5 年 500 億的頂尖大學爭議, 的確, 不患寡而患不均, 但這是當大家面向的是同一個小市場的狀況, 在這小小島 (台灣, 新加坡) 外的世界是大山大海, 關起門來爭吵的贏家, 真有遠見可以帶領我們走向彼方?

說到新加坡, 如果只能去一個地方,  那我會選擇的是去南洋理工學院看看, 一方面, 是因為讓我之前搞出笑話的英文縮寫 (NTU, Nanyang Technological University), 另一方面, 南洋公學 (Nanyang University) 也是母校交大的舊名, 這樣的淵源, 也讓我特別想去這所學校看看. 學校的位置, 正好和我所住的樟宜機場旅館, 分屬新加坡兩端, 以捷運路線來說, 要花上 90 分鐘通勤, 校園很大, 甚至還正在蓋捷運, 但可能因為假日, 學生不多, 大學建築的編制, 就很有新加坡大學的共同特色: 學院中心, 結合停車與教學的巨型建築, 學院制的學生宿舍, 風雨走廊, 較為集中的功能設計, 適合透過校內公車進行點到點的移動. (左上: 藝術、設計與媒體學院; 右上:計算機科學與工程學院; 左下: 商學院; 右下: The Hive (Learning Hub South - LHS) ) 事實上, 南洋理工大學, (爭議的) 承襲自 1958 年的南洋大學, 此南洋大學原為來自福建的華僑捐資成立, 希望成為新加坡地區, 以華語教學的大學, 傳承華僑的教育與文化. 而所謂南洋, 也就是面向南中國海, 離鄉背井的生活地方. 跨越遙遠的海洋, 不同時間點的兩間南洋大學 (Nanyang University) 遙遙相望. (左: 南洋大學牌樓; 右:南洋大學設立紀念碑) 事實上, 南洋大學的成立也是多有苦難, 作為華僑的文化中心, 面臨殖民政府與原生族群的不信任, 也受到冷戰時期, 自由世界與共產世界的對立干擾, 最終, 在李光耀的主政下, 1980 年併入了新加坡國立大學,  至此, 以華文辦學的大學消失, 也意味著華僑的主體性消失. 以當時的時空背景來看, 英語化是一種必要之惡, "馬來西亞人的馬來西亞" 不能是 "馬來人的馬來西亞", 當然, 更不能變成 "華人的馬來西亞",  一種新語言, 作為新的國族象徵, 作為不同族群間的橋樑, 是必要的. 然而, 所有抉擇都有其代價,  作為歷史的陰影, 南洋大學就消逝於新加坡歷史中. 南洋理工學院是在南洋大學舊址上建立的新學校, 國家出資, 英語教學, 在大量資源投入下, 已和新加坡國立大學不分軒輊, 新加坡政府象徵性地留...

在 5G 的架構中, 如前所述, 將原有的基地台拆分成: CU-DU-RU 的架構, 透過將基地台網元 (Network Element) 拆分並虛擬化, 一方面可以開創 vRAN (virtual RAN) 的應用, 將硬體搬移至雲端中心, 另一方面, 也讓網元間的拓譜更加彈性, 例如: 1 CU- 1DU- 4 RU 的架構, 而這些 RU, 在一開始時做的框架中, 擁有單獨的 Cell ID,  可以看做一個獨立的小基站, 只是分享背後的 CU-DU 運算資源, 在不同 RU 之間也需要進行對應的換手. 另一方面, 在 multi-TRP 架構中, 數個 RU 分享同一個 Cell ID, (TRP: Transmission Reception Point, 3GPP 定義的傳收點, 本文中可視為 RU) 因此, 不同的 RU 訊號, 可以縫合成為同一個 Cell, 透過 multi-TRP 的架構, 電信商可以提供低成本的訊號覆蓋. 來自:  https://ictjournal.itri.org.tw/xmdoc/cont?xsmsid=0M236556839091904564&sid=0N082511426278192757 相較原有每個 RU 都是單獨個體的架構, multi-TRP 架構最大的好處在於換手的消除, 減少使用者在不同 RU 間的延遲, 此外, 由於 RU 之間傳輸相同的訊號, 使用者將無間斷地享用較佳的 RU 服務, 不會受限於換手延遲效應, 在 RU 訊號覆蓋邊緣, 降低使用者的通訊品質. 同時, 由於所有 RU 從屬於同一個 Cell, 可以減低 RU 間的相互干擾. 另一方面, 此架構也將帶來一系列挑戰,  首先, 是通訊資源的減少, 考慮到 RU 偕同服務單一使用者, 等校的無線傳輸單元下降, 考慮到這樣的缺點, 目前 multi-TRP 框架多鎖定 4RU/ 2RU 架構, 減少效能減損, 第二, UE 與 RU 間的從屬問題, 尤其對於 UE 的上行資料的處理, 因此, 需要引入動態傳輸節點選擇 (Dynamic Point Selection, DPS) 克服, 最後, 使用者端的通道估計問題, 來自不同 TRP 的訊號, 類似於多路徑效應的疊加, 但是其訊號強度較多路徑效應更強, 也...

*本文主要內容參考自: J. Ping, "Network Resource Model for 5G Network and Network Slice," in Journal of ICT Standardization, vol. 7, no. 2, pp. 127-140, 2019 NRM (Network Resouce Model) 在 5G 網路中用以提供網路管理的功能, 起源於 R15 Management Service (MnS) 的功能定義, 其中, Network Resource 又稱為 Information Object Class (IOC), 為 5G 網路中的單一可控制的元件, 定義 IOC 之間的關係與屬性 (attribute). 在 3GPP 的 NRM 中, 將定義的功能分成 3 個階段 (stage), 分別是: Stage 1: Requirements-level, 在 stage 1 中, 定義了 NRM 的概念和 use case Stage 2: Information Service (IS)-level, 定義必要的 Network Resource (不隨技術改變) Srage 3: Solution Set (SS)-level, 隨著技術/網路演進的項目 在 3GPP 的文件中, Stage 1 定義於 TS 28.540, Stage 2 和 Stage 3 定義於 TS 28.541, 從以上 3 個 stage 來說, 可以看到從 stage 1 至 stage 3, 其更新的週期逐漸縮短, 我們可以以下圖表示: 來自: https://ieeexplore.ieee.org/document/10258059 在上圖中, 我們可以看到, NRM 不只對應於接取網路 (NG RAN), 也對應於核心網路 (5G Core) 與網路切片功能 (Network Slice). 值得注意的是針對 Stage 3 部分的功能定義, 在 3GPP 的定義中, 主要使用: XML, JSON, YANG 作為定義的格式, 針對接取網路 (5G RAN) 而言, 可以分成三種 IOC: CU-CP, CU-UP, DU, 此部分的功能分界, 可以參考: E2SM-CC...

在 上一篇文章 中, 我們介紹了 CCC 這個 Service Model 的設計目的, 接下來, 我們將介紹一些細節, 並針對一些特殊功能進行介紹, 首先, 我們先看一下 Cell level 和 Node level 的功能定義: 來自:  WG3-E2SM-CCC-R003 在上述的欄位中, 我們可以看到 CCC 主要對應於 CU/DU 功能, 並不包含 RU 的部分 (E2 介面其實不直接和 RU 通訊) 針對 Node level 和 Cell level 的差異, 我們以 DU 為例, 看一下 Table 8.8.2.1 和 8.8.1.2, 來自:  WG3-E2SM-CCC-R003 在表中, 我們可以看到 CU 主要是可以控制換手資訊, 可以控制的欄位多半在 Node level, 對 CU 直接進行控制, 相對的, DU 的控制主要是無線通訊的信令, 則集中在 Cell level 進行, 除此之外, 在表格的欄位中, 我們可以看到一個特殊欄位: is writable, 如果此欄位為 FALSE, 則代表此設定和其他設定有相依性, 不能由 RIC 修改, 但是, 我們也可以看到出現支援 Control Service, 但 writable 為 FALSE 的狀況, 對此, CCC SM 的解釋為, 此類欄位只能作為 Control 的參照 (reference),  不能作為修改的目標. 在本文的最後, 我們來看一下 CCC SM 和節能控制的關係, 定義在 O-CESManagementFunction 中 (Table 8.8.2.5), 來自:  WG3-E2SM-CCC-R003 其中, CES 代表 Cell Energy Saving,  在此功能項之下有三個欄位: cesSwitch, energySavingState, 與 energySavingControl, 前兩者對應於功能的開啟與關閉, 是唯讀的欄位 (Report), 最後一個欄位則是 CCC SM 可以控制的項位,  並要在 energySavingState = "isEnergySaving" 的條件下, 可以透過設定 "toBeEnergySaving" 和 "toBeNotEnergySaving...

在開始介紹 CCC (Cell Configuration and Control) 這個 Service Model 之前, 我們先來回顧一下 Service Model 的定義, 在 O-RAN 標準中, Service Model 對應於 E2 介面, 定義了 E2 Node (接取網路) 到 Near-RT RIC (控制器) 之前的資料格式. 不同的 Service Model 對應於不同的應用情境, 舉例來說, KPI Monitir (kpimon) 對應於接取網路的資訊收集, RAN Control (rc) 則對應於接取網路的控制. 因此, 當我們看到一個新的 Service Model 時, 應當想到的第一個問題是: 這對應於甚麼應用情境? 在 O-RAN 文件 (WG3-E2SM-CCC-R003) 中, 對此 Service Model 描述如下: “Cell Configuration and Control” which performs the following functionalities: - E2 REPORT services used to expose node level and cell level configuration information - E2 CONTROL services used to initiate control and/or configuration of node level and cell level parameters  和舊有的 RAN Control Service Model 相比, CCC 更著重在 Cell/ Node level 的控制, Cell level 的控制, 對應到基地台的功能, 例如: BWP (Bandwidth Parts) Node level 的控制, 則對應到基地台中的不同元件, 例如: CU, DU, 接著, 下一個關鍵的字詞是 configuration 的定義, 在同一份文件中, 定義如下: RAN Configuration Structures are groupings of RAN configuration attributes, which can either be based on the NRM d...

在上一篇文章中, 我們介紹介紹了一些 SRS 的基本特性, 接下來, 我們要在兩方稍微延伸下 SRS 的介紹, 在一開始, 我們先比較一下 SRS 在 4G 和 5G 的差異,  接著, 我們將看一下 SRS 訊號如何在 5G NR 中輔助定位進行. 首先, 當我們討論 4G 和 5G 的差異時, 最直接想到的就是波束成型 (beamforming) 技術的引入,  雖說, 波束成型的增益主要反映在基地台端 (較大天線陣列), 但對於 UE 端, 也可以在波束管理的階段, 透過 DMRS 提供上行通道估測, 針對沒有被分配到通訊資源的 UE (或是對應於未分配資源的頻帶), UE 可以透過 SRS 訊號, 讓基地台進行上行的通道估測. 考慮到 UE 通常天線數較少, 在 SRS 中直接以 antenna port 作為設置單位, 根據規範, 一共有以下選擇: 1T2R, 1T4R, 2T4R, T=R (1T1R, 2T2R, 4T4R)  根據不同的天線配置, SRS 也會有相對應的設定, 值得注意的是, 這裡的 Tx/Rx 指的是由 UE 角度出發,  以 1T2R 為例, 代表 UE 的兩根天線一次使用一根進行傳送,  基地台透過分接收這兩根天線的訊號, 進行通道估計, 如下圖所示: 來自:  https://www.sharetechnote.com/html/5G/5G_SRS.html 更多的範例以及詳細的設定可以參考這一篇文章: https://www.sharetechnote.com/html/5G/5G_SRS.html 第二部分, 讓我們關心一下 SRS 在定位中的應用, 相較於 DMRS 參考訊號, SRS 的一個重要好處就是可以同時有多個基地台接收, 同時, 考慮到 SRS 的配置是由基地台給定, 並可在基地台間分享資訊, 因此, 偕同量測的基地台不只可以取得上行的訊號強度, 也可以取得 SRS 訊號到各基地台的時間差, 以 TDoA (Time Difference of Arrival) 定位, 若考慮到 1T2R, 1T4R 的 SRS 架構, 基地台端還可以估計 AoA (Angle of Arrival), 這些資訊都可以作為 UE 定位的輸入資訊, 以 UL-TDoA 為...

在 5G NR 的上行通道估測中, 我們有兩種參考訊號 (Reference Signal): DeModulation Reference Signal (DMRS) Sounding Reference Signal (SRS) 這兩種訊號都是由使用者裝置 (UE) 發出, 並由基地台進行量測, 其中, DMRS 被包含在上行的資料傳輸中 (PUCCH/PUSCH),  SRS 則提供使用者在上行資料傳輸之外, 進行通道估測的方法, 不屬於 PUCCH/PUSCH, 並可以提供多個基地台同時對同一個 UE 量測的方法, 如下圖左所示. Cha, Hyun-Su, et al. 5G NR Positioning Enhancements in 3GPP Release-18. arXiv preprint arXiv:2401.17594, 2024. SRS 的參考訊號在 4G LTE 時便已被定義, 但並不常被終端裝置所支援, 在 5G NR 中, 由於 beamforming 以及定位的需求, SRS 被重新提起並受到重視, 在目前的 5G NR SRS 定義中, 有下列三種傳輸方式: Full-band transmissions: 4G SRS 的傳輸方式, 基本上是分時多工進行傳輸 Frequency-hopping transmissions: 透過跳頻方式傳輸, 使基地台取得不同頻率的通道估計 Multi-user transmissions: 提供多個 UE 同時發送 SRS 並被量測的機制 SRS 訊號可以是週期性傳輸, 或是非週期性傳輸, 通常起始於基地台對 UE 裝置 RRC 層的設置, 起始 UE 發出 SRS 訊號. 我們先不考慮 SRS 跳頻量測與使用者多工的不同設置,  針對單一 UE, SRS 訊號表示如下:  來自:  https://telcomaglobal.com/p/5g-nr-srs-sounding-reference-signals 透過上圖, 我們可以看到單一 UE 的 SRS 訊號, 如何在一個 time slot 中被給定, 包含了在時間與頻率上的位置 (offset), 長度 (RB 個數) 與使用者的多工, 詳細的訊號產生方式可以參考 Matlab 的範例程式: h...

在開始介紹這次的 NCR 內容前, 我們先介紹另一個相似的概念: IAB, IAB 全名為 Integrated Access and Backhaul, IAB 也是 3GPP 針對 5G NR (特別是 mmWave 段) 提出的新技術, 其技術的示意圖如下: 來自:  https://www.rcrwireless.com/20200727/5g/iab-the-cost-effective-solution-to-quickly-expand-5g-mmwave-coverage-analyst-angle IAB 技術的提出, 很明顯地是在 5G NR 初始時對 mmWave 充滿期待的時期, 考慮到 mmWave 在空氣中的衰減快, 但擁有高通訊頻寬的特性, 就有人提出了這種以 mmWave 延伸 mmWave 的概念, 簡單來說, 就是把 mmWave 當作光纖使用, 用以作為延伸小基站間的連線, 而資料傳輸的斷點設在 DU 中間 (PDCP-RLC層), 如下圖所示: 來自:  https://nccnews.com.tw/202209/ch4.html 如果說 NCR 是 Amplify-and-Forwarding (AF) 的技術延伸, IAB 就是 Decode-and-Forwarding (DF) 的技術延伸, 一方面, DF 可以避免在多個基站轉傳過程中造成的雜訊放大, 另一方面, IAB 技術的接收端為特殊設計的小基站, 有較佳的計算能力, 以及穩定的電源供應, 可以負擔 DF 的需求. 考慮到 IAB 為 DU 內分割 (intra-DU) 的框架, 所有分支節點皆可視為原有 DU 的延伸, 當結點的階層數大於一時, 則會產生對應的樹狀結構, 並避免迴圈產生, 至於干擾, 考慮到 mmWave 的指向性波束以及 IAB 位置為預先規劃,  IAB 結點之間的干擾應該不嚴重, 或是以空間多工即可避免, 比較需要注意的反而是因為天線無法同頻收法所導致的資源分配問題, 在目前 IAB 架構中, 簡單的作法即是以分時多工的方式進行. 考慮到 mmWave 在目前 5G NR 中並不算太成功, 對應的 IAB 發展仍是有限,   在目前各式的 Use Case 中, 最引人注目的應該是空中基地台...

在之前的文章中, 我們介紹了 RIS 的功能, 對於通訊研究而言, RIS 是一個新穎也陳舊的概念, 新穎的地方在於: 透過被動反射, 我們可以改變通道的特性, 陳舊的地方在於: 類似的訊號增強概念, 我們之前在中繼器 (Relay) 中, 已經在 3G/4G 時代轉了一大圈, 最後並沒有被實踐. 也或許是因為這樣的原因, 3GPP 對於 RIS 實現並沒有特別熱衷, 但是, 仍然組成了一個研究團隊, 以 Repeater 的角度切入, 並引入控制的概念, 這也就是我們今天要介紹的: Network-Controlled Repeater. 相關 3GPP 文件為: TR 38.867 Study on NR Network-Controlled Repeater (NCR) 我們先以一張示意圖說明 NCR 的概念: 在 NCR 的架構中, Repeater 受控於 gNB (基地台), 並有兩條路徑: Control Link: 基地台對應的控制信令, 由 NCR-MT 接收. Backhual/Access Link: 轉傳/增益的通道, 將訊號增強後傳至 UE. 在初始的討論中, Control Link 和 Backhual/Access Link 使用相同的頻帶, 同時, Control Link 透過 Uu Interface 進行控制,  因此,  NCR 對基地台的角色接近於一個特殊的 UE, 另一方面, Backhual/Access Link 可以視為在 RIS 構架下, BS-RIS, RIS-UE 這兩條直視路徑的無線通道, 在 3GPP NCR 的框架中, 轉傳單元 (NCR-Fwd) 類似於 RIS 反射板的角色, 但是不同於一般 RIS 為被動元件, NCR-Fwd 提供 Amplify-and-Forwarding (AF) 的功能, 換句話說, NCR-Fwd 會將接收到的訊號增強後, 再轉傳至 UE. 這樣的框架, 的確類似於 3GPP 之前對 Relay 的討論, 在類似於 RIS 的部分則在於對 NCR 加入的 beamforming 功能, 透過 beamforming 技術, NCR 可以減低一些 AF 遭詬病的雜訊放大問題, 同時, 也可以更有效的增強使用者接收訊號的強度....