Castle on a Cloud

針對 PRS 的系統實作, 雖然 3GPP 已在 R16 定義, 同時, 在 RAN 端與手機端也都已有支援, 舉例來說,  Ericsson:  https://www.ericsson.com/en/blog/2020/12/5g-positioning--what-you-need-to-know Amarisoft: https://www.5ghubvaasa.fi/wp-content/uploads/2023/10/5G-positioning-on-interactive-map.pdf Mediatek: https://www.rohde-schwarz.com/uk/about/news-press/all-news/rohde-schwarz-and-mediatek-verify-5g-lbs-release-16-features-on-the-r-s-ts-lbs-test-solution-press-release-detailpage_229356-1238101.html 我們可以看到不論是 RAN (Ericsson) 或是手機晶片 (Mediatek) 都支援 PRS, 然而, 在現實生活中, 我們卻很難看到 PRS 真實於場域中的應用, 這樣的落差主要是來自於在 3GPP 中 PRS 屬於 LMF (Location Mgmt. Function) 的應用, 這部分是額外要訂閱或是付費, 但卻沒有相對應的應用,  因此, PRS 或是 5G NR 的定位技術, 在目前公網的環境, 沒有普及的應用. 相較之下, 定位在企業專網 (Private Network) 中有比較可行的應用, 主要是在企業/工廠的應用場域中, 可能有更多精密定位的需求, 因此, 不論是 Nokia/Ericsson 的白皮書中, 都強調在企業專網的應用. 另一方面, 在開源的社群 (Open Air Interface/ srsRAN) 中, 對 PRS 的支援如何呢? 我們先從 OAI 開始, OAI 從 2022 年開始支援 PRS,  不同於 SRS 有實作整個 NRPPa 的控制信令, OAI 對 PRS 的支援主要是透過 PHY 層的實作來完成, 主要包含兩個函式: nr_generate_prs()：...

在之前的文章中, 我們介紹了 3GPP 中 SRS 的訊號以及定位方法, SRS 主要是上行的定位訊號, 由 UE 進行發送, gNB 進行量測, 與之對偶的是 PRS (Positioning Reference Signal), 由 gNB 發送 UE 量測, 這樣的 PRS 訊號是在 3GPP R16 中被引入, 透過 gNB 廣播的 PRS 資訊, 用以提供進行裝置為基礎的定位方法. 相較於 SRS, PRS 的訊號有以下的差異: 1) PRS 考慮的是基地台間的協作, 因此有 muting 的機制, 使基地台可以分時多工 2) 考慮到基地台的覆蓋範圍, PRS 使用較高的傳輸功率, 並不支援分碼多工 3) PRS 提供較稀疏的 comb 與 OFDM symbol 設定, 可依據設定提供彈性配置 4) 在基站間的 PRS 配置, 可以透過 RRC 曾進行協同, 避免進行基地台間的 PRS 干擾 5) PRS 比起 SRS 在同步上要求更高, 以相位為基礎的定位在 R18 才被提出 6) PRS 支援 burst 配置 (數百 ms, 甚至數秒才發送一次 PRS) 圖來自: https://www.mathworks.com/help/5g/ug/5g-new-radio-prs.html 在這邊值得注意的是, 雖然上述文字中使用 gNB/基地台代稱傳送端, 但是, 實際於 3GPP 標準中的用語是 TRP (Tx/Rx Point), 不只可以對應於一組小基站, 也可以對應於基站的不同傳輸天線, 透過 PRS 的訊號, 我們可以實現以下的定位方法: OTDOA (Observed Time Difference of Arrival): 利用多個基站下行發送的定位參考信號 (PRS), 由 UE 測量相鄰基站與參考基站之信號到達時間差 (RSTD) 進行定位. 最早在 3GPP Release 9 (LTE) 引入, 在 5G NR 中於 R16 支援.  AoD (Angle of Departure): UE 通過測量多基站的 PRS 下行信號不同波束的接收功率, 確定來自每個基站訊號的發射方向角, 用以進行定位 此技術同時需要波束成形與 PRS 支援, 在 3GPP Release 16 中加入標準. RTT 定位 (Round Trip T...

在目前 LLM 模型的發展下, 一個共通的模型還有一段距離, 取而代之的是, 各家各有擅長的模型, 同時, 對於 Agentic AI 的需求, 我們對於 AI 也不再是處理文字訊息, 而是希望其可以融合各式模型的能力, 自動判斷使用者意圖, 進而操作各式模型, 已完成使用者意圖中的目標. 老慮到這樣的需求, 如何定義這些 AI 模型的介面, 也就變成一個問題, 對此, MCP (Model Context Protocol) 也就順應而生. MCP 是由 Anthropic 於2024 年11 月推出的開放標準,  目標是在讓 LLM 能夠透過標準化的方式與外部工具, 資料庫和應用程式, 透過 MCP 定義的 API 介面進行安全, 結構化地溝通. 在 MCP 的架構中, 有三個主要的角色: Host, Server, Client, 其架構如下圖: 來自: https://www.geeksforgeeks.org/artificial-intelligence/model-context-protocol-mcp/ 其中, Host 為 MCP 的平台, 提供 AI 應用或代理執行環境,  例如: 聊天介面, IDE 外掛, 桌面助理等, 為使用者操作的介面. Host 負責協調多個 client, 管理工作階段, 並把結果回饋給使用者. 然而, Host 不直接跟各種資料源與 AI 模型溝通, 而是透過 client 進行. MCP Client 在 MCP 架構下, 並非服務的使用者, 而是 AI 模型的代理. 其連線代理由 Host 發起, 同時每個 client 維持與一個 MCP server 的連線, 負責把 Host 的需求翻成 MCP 訊息, 處理握手／重試／能力宣告等需求, 並把 MCP Server 的回應再轉給 Host. 最後, MCP Server 是真實真正提供服務的地方, 有以下功能: 1) 對外宣告可用的 resources (資料), tools (函式庫), prompts (提示範本). Server 可以在本機或遠端, 也可由不同團隊維護, 已達成擴充性需求.

在上一篇文章的後續, OAI 團隊將此 SRS 的量測實驗延伸到室內, 並提供了更多實驗的細節, 後續的發表可以看此篇文章: Experimental Insights from OpenAirInterface 5G Positioning Testbeds: Challenges and Solutions link:  https://arxiv.org/abs/2508.19736 在文章中, 提到了 3 個實驗場域, 如下表所示: 圖、OAI SRS 實驗場域 (作者整理) 在三個場域中, 我們可以看到室外場域就是上一篇論文的環境, 此外, 又新增了兩個室內的場域, 對應智慧製造的應用, 這些場域的資料中, 作者公開了室外場域的量測, 放在 Gitlab 上提供下載: https://gitlab.eurecom.fr/ahadi/5g-srs-datasets  這些場域量測的資料已經經過預先的資料前處理, 分成三個部分: ToA Filtering, TDoA Averaging, TDoA Filtering. ToA Filtering: 使用統計方法過濾 ToA 資料, 以去除離群值, 增強測量準確度 TDoA Averaging: 在所有天線間進行TDoA資料的平均, 以提升測量的穩健性 TDoA Filtering: 經過平均化後, TDoA資料會透過位置資訊進行過濾, 提高定位精度 以上三個資料處理流程, 主要針對 SRS 轉換出來的 ToA 進行處理, 主要的目標是增加 ToA/ TDoA 的強韌性, 避免大幅的定位資訊跳動, 其資料前處理的流程圖如下圖所示: 圖、來自論文 比較可惜的是, 若是檢視提供的資料集資料, 看起來已經將不同 RU 間最大的 peak 數值對齊, 這邊我們需要進行額外的檢視, 以確定如何將 ToA 的資料取出: 圖、公開資料集的格式以及 CIR 繪圖成果  

在 SRS 的系統中, 我們介紹了資料傳輸的流程, 也就是基地台如何設定 UE 傳送 SRS, 以及鄰近基站如何識別要量測的鄰近 UE 裝置. 事實上, 針對 SRS 的信令, 仍有另一個重要的控制資訊, 也就是基地台設定 UE 在哪幾個 Resource Block (RB) 上傳送參考訊號, 以及參考訊號如何編成. 我們先說參考訊號的部分吧! SRS 採用 Zadoff–Chu (ZC) 序列產生基底序列,  ZC 序列具備恆定能量大小與良好的正交特性. 為了對不同 UE 產生 SRS 的參考訊號, 要針對 UE 指定序列 ID (sequenceId), 初始化 ZC 基底序列後, 經由離散傅立葉轉換展開至頻域子載波, 最終對應到特定的 RB 位置. 接著, 是關於這些參考訊號的 RB 配置, SRS 主要可以透過兩個方式配置用以傳送參考訊號的 RB,  在時間上 (OFDM symbol) 與頻域上 (sub-carrier), 如下圖所示: 來自:  https://www.mathworks.com/help/5g/ug/nr-sounding-reference-signals.html 在 OAI 的這一篇論文中, 並沒有明確說明 SRS 的設置, 所以我們近一步從公開程式庫取得原始碼： 以 git clone https://gitlab.eurecom.fr/oai/openairinterface5g.git  複製 OpenAirInterface 5G 專案, 進入專案後切換至 NRPPA_Procedures 分支，並透過 git submodule update --init –recursive 完成子模組初始化 接著，在專案路徑 /openairinterface5g/openair2/RRC/NR/nr_rrc_config.c 中, 可以找到與 SRS 配置相關的核心函式: 其中 configure_periodic_srs() 用於設定週期性 SRS 的資源參數, static struct NR_SRS_Resource__resourceType__periodic *configure_periodic_srs(const NR_ServingCellConfigCommon_t *...

在通訊系統中, 透過 SRS 取得通道的量測數值是一個挑戰, 另一個挑戰是如何透過相鄰基站, 偕同量測 SRS 資訊. 不同於 RSRP 的回報是由 UE 進行量測週期廣播的 SSB 訊號, SRS 資訊由 UE 發出, 並由基站量測上行的通道變化. 這也意味著, 基站也必須共享 SRS 的設定,  這些 SRS 的配置涵蓋了頻域與時域的資源分配, 傳送週期性等參數, 並犧牲一部分的上行通訊資源, 以達成 SRS 定位的協作.  在 OAI 的實作中, 在 FAPI interface 裡新增了一種類型的 SRS report: Localization report type, 以及新增一種 SRS 類型 (type 5) 來標示該用途, 用來區別普通 SRS measurement 與為定位用途的 neighbour/serving 測量. FAPI 用以界接 MAC/ PHY 的功能, 如下圖所示: 來自:  https://www.telecomhall.net/t/which-split-options-are-used-in-5g-and-open-ran/18075 如果在 split 7.2x 的架構下, DU 包含 high-PHY 和 MAC 功能, 因此, FAPI 的實作位於 DU 之內. 此外, 為了讓 neighbour gNB/TRP 知道要接收哪個 UE 的 SRS, OAI 為 neighbour 測量引入一個 special RNTI (Radio Network Temporary Identifier), 填入於在 MAC → PHY 的 SRS PDU 中的 UL TTI request, 以標記 SRS 測量的需求. 同時, 在 PHY → MAC 的 SRS.indication 中, 除了 reserved RNTI,  還有 SRS resource ID / UE ID context 可以綁定該測量屬於哪個 UE. 在解出來 ToA 後, OAI 的實作也必須將此數值往上回報, 他們把從多個 TRP 收到的 Timing advance offset (ns) 帶回 MAC/LMF, 這些 offset 用來計算 ToA 差異 (TDoA),  並設計一組 TLV ...

針對 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, 得到通...

 ONNX (Open Neural Network Exchange) 是一個開放格式, 用來表示深度學習模型與傳統機器學習模型的計算圖結構, 讓不同的深度學習框架 (如 PyTorch、TensorFlow、Scikit-learn) 之間可以互通, 使模型的部署與交換更加方便. 來自: https://github.com/1010code/onnx-mlir-tutorial 透過 ONNX, 我們可以完成以下的目標: 模型跨平台轉換與交換 可將模型從 PyTorch、TensorFlow、Scikit-learn 等框架導出為 ONNX 格式 便於在不同工具或設備之間共享與重用模型 跨硬體部署 (CPU、GPU、FPGA、NPU) ONNX 模型可以在多種硬體平台執行，不需重新訓練 搭配 ONNX Runtime、TensorRT、OpenVINO 等工具，實現高效推理 推理優化與加速 可結合 TensorRT、ONNX Runtime 等進行圖優化 (Graph Optimization) 與推理加速 適用於邊緣設備、嵌入式系統、高性能伺服器等場景 多模型整合與模組化設計 可將多個子模型整合為一個 ONNX 模型，便於部署與管理 適合構建複雜管線 (例如預處理 → 模型 A → 模型 B → 後處理) 在 ONNX 架構中, 事實上是把模型拆解成計算圖 (GraphProto), 在計算圖中, 包含了以下 4 種角色: node: 每個節點代表一個操作 (如: matmul、relu、add) input: 圖的輸入 (例如: 影像、感測器資料) output: 圖的輸出 (例如: 分類結果、控制訊號) initializer: 模型的參數 (例如: 權重、bias 等) 來自:  https://onnx.ai/onnx/intro/concepts.html 透過上述運算子, ONNX 可以把原有的運算, 轉化成 Directed Acyclic Graph (DAG), 再放到不同計算平台進行運算. 然而, 也是由於計算圖 (GraphProto) 的原因, ONNX 有以下限制: 1. 無法封裝任意 Python 程式邏輯 ONNX 只能表示靜態的計算圖 (computational graph), 不支援像 Python 中的...

在很久之前的文章中 ( 這裡 ),  我們介紹定位方法時, 提到了 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 值有一定的精度限制, 只能作為粗略定位參考: 此數值和...

在之前的文章中, 說明了如何透過 prompting 的方式訓練 LLM 模型, 事實上, 在這邊說 "訓練 (training)" 有點奇怪, 因為 LLM 模型的權重並沒有產生任何改變, prompting 比較像是提供範例學習 (few-shot learning),  讓 LLM 增進回答的精確度, 或者, 更貼近使用者想要的回答. 當然, 針對特定的應用領域, 例如: 法律, 通訊, 客服, 等 擁有大量語意資料, 同時, 擁有特殊的領域資訊,  我們可以透過微調 (fine-tuning) 方式, 來調整 LLM 模型的權重, 在此架構下, LLM 模型的權重將被改變, 而可以記憶放入學習的資料, 以下是兩種方法的比較表:   在過往, 對 LLM 模型的微調相對複雜, 通常我們會基於開源的基礎模型 (base model), 如: LLaMa 進行調整, 主因大概有兩個: 第一、微調需要大量資料, 以及對應的資料前處理, 第二, 微調需要不少算力, 有能力建立者皆可自行訓練 LLM 模型. 同時, 微調後的 LLM 模型, 也被視為重要產出, 對應目標的應用領域. 不過, 我們還是可以從現有的 LLM 模型 API 中一窺 fine-tuning 的方法, 我們一樣以 Gemini 為範例, Gemini 提供了 fine-tuning 的 API, 如下: https://cloud.google.com/vertex-ai/generative-ai/docs/models/gemini-use-supervised-tuning 其中, 第一個重點即是準備訓練資料與文本, 其範例如下: {    "input_text": "這是輸入文本。",   "output_text": "這是期望的輸出文本。" } 當然, 我們也可以結合之前 prompting 的資訊,  給予訓練資料更多的角色定義, 例如: {   "systemInstruction": {     "role": "system",     "parts": [ { "text": ...

我們在上一篇文章中介紹了如何有系統地提供問題資訊, 讓 GPT 或是其他 LLM 模型可以更精確地回答, 考慮到 LLM 在各應用中的便利性, 以及其高昂的訓練成本, 透過提示 (prompting) 提升回答精確度的方法, 被廣泛的應用與討論, 其中, 最基本也最廣為人知的也就是 RAG (Retrieval-Augmented Generation). Retrieval-Augmented Generation 於 2020 年由 Facebook AI 提出,  是將生成式模型 (Generative Model) 與檢索模型 (Retrieval Model) 結合的架構. 其設計的核心任務包含了: 解決 LLM 記憶受限問題 (context window 大小限制) 提升回應準確性與可追溯性 (根據外部知識檢索來源回答) 減少 hallucination (幻覺生成) 現象 RAG 的工作流程, 包含了以下的步驟: Query Encoding: 將輸入的問題進行向量化 (embedding), 使用相容的 embedding model 處理 Retrieval: 透過向量相似度搜尋 (vector similarity search) 從外部知識庫檢索最相關的段落 Context Fusion: 將檢索結果與原始 query 進行 prompt engineering，形成完整輸入 Generation: 將結合 context 的 prompt 輸入 LLM, 生成基於外部知識與語言模型推理的答案 來自:  https://medium.com/data-science/retrieval-augmented-generation-rag-from-theory-to-langchain-implementation-4e9bd5f6a4f2 (2,3 併入 Augment 步驟) 和上一篇文章中介紹的 prompting 技術比較, RAG 技術最大的技術特點即是在設計時是針對一個普及的使用. 為了面對多樣不同的查詢, 用以提供範例的資料庫也將十分龐大, 因此, 如何根據當前的資料查詢, 找到相對應的範例就是一個重要的問題. 在 RAG 中使用兩個技術: embedding 將輸入的語意編碼, vecto...

這一系列的文章, 預計會寫個幾篇, 說實話, 這大概連技術文件都說不上, 就是紀錄一些現有熟知的技巧, 在專有名詞部分, 標題的 GPT 其實可借代成任何 LLM (Large Language Model), 這些模型, 以昂貴的訓練成本, 不開源的存取方式稱著, 當然, 他們會收集我們在網頁上的輸入以及反饋,  以免費存取作為代價, 以全人類的資料, 進一步優化這些生財工具, 但是, 對於個人而言, 我們如何客製化一個我們想要的 LLM? 首先, 我們先談談這是否必要? 針對多數的應用中, GPT 或是其他 LLM 其實都已對應大眾使用行為進行調整, 撇開幻覺生成 (Hallucination), 以及過於順從的問題, 在多數的時候, 不論你詢問星座或是 python coding, 他們都可以表現得不錯, 原因無他, 因為在網路上已有大量的相關資料供 LLM 學習. 然而, 若我們考慮一個小範圍且專業的領域呢? 或是, 當我們資訊的提供, 無法以文字或是圖片有效傳達該怎模辦呢? 我們不太可能重新訓練一個 LLM, 而是想借力於一個已經訓練好的 LLM 能力, 針對我們設想的任務優化, 通常來說, 我們有兩種方式可以達成, 分別是: 提示工程 (prompting) 以及模型優化 (fine-tuning). 我們先從最基本的提示工程開始吧! 為了要有一個準確的回答, 首先, 我們需要一個好的問題, 那麼, 一個好的問題需要提供那些資訊呢? 以下是 Gemini 提供的一些指引:  https://ai.google.dev/gemini-api/docs/prompting-strategies 1. 明確的指示（Clear instructions） 使用清楚、具體、直白的語句。 說明任務是什麼、要用什麼格式輸出。 若任務有多步驟，建議拆解並分別列出。 2. 上下文（Context） 提供必要背景資訊（如任務目標、角色、使用者需求）。 可加入範例、定義或限定條件讓模型更準確理解。 3. 角色扮演（Role prompting） 指定模型扮演的角色（例如：「你是資深數據分析師」）。 讓模型以特定觀點或風格作答，提高一致性與專業度。 4. Few-shot 示範（Few-shot prompting） 提供1～3個範例作為輸入與期望輸出格式。 ...

原本想說結束 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, 這一個布建基...

回到原本的主題, 讓我們來介紹 DPU 的分類吧, 在 Nvidia 的文件中, DPU 一共有 4 種不同的運作模式, 分別是: DPU mode or embedded function (ECPF) ownership where the embedded Arm system controls the NIC resources and data path (default) Restricted mode which is an extension of the ECPF ownership with additional restrictions on the host side NIC mode where the DPU behaves exactly like an adapter card from the perspective of the external host Separated host mode (symmetric model) 在上一篇文章所介紹的模式, 被稱為 DPU mode, 考慮到所有的裝置也都被命名為 DPU, Nvidia 又稱為 embedded function (ECPF) 模式, 在此模式下, DPU 中的 ARM (CPU) 控制所有的資料流. 在 Restricted mode 則是延伸原有的 ECPF 模式, 但是更限制主機的存取, (無法從主機上對 DPU 進行對應的設定, 所有設定在 ARM 上執行) 主要應用的場域是在安全性較高的網路設定中. NIC mode 則是之前提及的 ConnectX 網卡模式, 最簡單容易設置, 但是, 就無法發揮 DPU 進行負載平衡的功能. 最後 Separated host mode, 這邊的資料比較少, 不過按照文件敘述, 主要是對應於資料中心的網路規劃, 主機和 DPU 分開並平行處理資料流. 這些不同模式, 可以用下列的 MST 指令來設定, 首先是看目前 DPU 狀態: $ mst status -v ... DEVICE_TYPE             MST              ...

最近實在是太忙碌了, 以致 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) 的發展.