發表文章

[LTE筆記] CSI-Based User Positioning with an NVIDIA 5G Testbed (1)

圖片
以下的內容主要來自於此篇文章: CSI-Based User Positioning, Channel Charting, and Device Classification with an NVIDIA 5G Testbed ArXiv:  https://arxiv.org/abs/2512.10809v1 針對此篇文章的內容預計分成兩篇來撰寫, 在第一篇文章中, 我們將介紹在 Nvidia 系統中, 如何取的 CSI 的資訊, 以及取得 CSI 資訊的格式, 方法, 以及對應的實驗量測環境. 在第二篇文章中, 則會說明 CSI 資訊的應用. 首先, 先說明一下, CSI 有兩種方法可以取得, 除了之前說的 SRS 之外, 另一個則是透過 DMRS 來取得. DMRS 全稱為 Demodulation Reference Signal,  是在 5G 通訊中, 用以進行通道估測與輔助解調 OFDM 的參考訊號, 在上行的 PUSCH (Physical Uplink Shared Channel) 中, UE 裝置可以每 7/14 OFDM symbol 發送一組基礎的 DMRS 參考, 當然, DMRS 訊號可以有類似 comb 的編排機制 (在頻域上間隔出現), 我們在此先以基礎的設定 (使用所有 3276 個 sub-carrier 傳輸) 作為當前設定. 考慮到 DMRS 在 PUSCH 中的配置和 SRS 頗為一致, 在此就不贅述. 在 5G NR 系統中, DMRS 也是由基站通知手機端發送, 因此 DMRS 的回報間隔來自於基站的排程時間. 在這篇論文中, 他們的系統配置讓 CSI sample 至少每 10 ms 或 20 ms 進行回報, 最短的回報時間則是 2.5 ms (TDD pattern=3DSU, 因此, 0.5*5=2.5ms). 同時, 在此系統中, DMRS 在同一個 PUSCH slot 裡被配置 3 次, 換句話說, 在系統配置中, 可以看不同 OFDM symbol 的 CSI 變化. 比較可惜的是, 論文中並未明說這三個 OFDM symbol 配置的順序, 因此, 對於 OFDM RADAR 等應用會缺乏一些資訊. 基於上述的設定, 我們可以整理此系統的時序設定如下所述...

[2026] 新年新計畫

圖片
今天是 1/11, 遲到的說一聲新年快樂, 在過去的一年中, 這個部落格約略是以每月兩篇的速度更新. 在撰寫文章的同時, 不免俗的, 我也藉助了越來越多大語言模型的幫助, 不論是資料的收集, 文章的邏輯脈絡, 論點組織, 等,  都藉立了許多大語言模型 (主要是 GPT) 的幫助, 雖然, 可以保證的是, 最後文章中每個字詞都是自己審閱/寫作, 但是, 現在的寫作越來越接近事與 GPT 協作的成果, 初擬, 討論, 意見回饋, 修改, 最後產生一篇文章. 必須說明的是, 在這過程中, 也逐漸發現大型語言模型的進步, 從一開始, 較小段落的輔助, 同時必須要給予資料提示, 到最後, 常常可以提出超出我知識範圍內的內容與資料, 都讓自己反思, 自己部落格的存在價值: 假如面對疑惑, 使用 GPT 半小時就可以有一篇深入完全的研究, 那麼技術部落格的價值是甚麼呢? 時到如今, 我可能還能夠提供幫助的大概是論點的組織, 資料方向上的取捨, 以及資料不一致時的重新釐清, 不過, 搞不好在 2027 年的此時, 也都將被 GPT 所超越. 考慮到這樣的殘酷現實, 因此, 我們也提早做出一些改變, 首先是介紹的內容目標, 我們將轉以有趣的論文發表為主, 一方面, 針對舊有習知的技術,  GPT 可以以其搜索能力提供完整的資料論述與組織, 另一方面, 針對提問者的面向, 提供更即時與客製化的回應, 這是靜態部落格所比不上的. 既然如此, 也只有往深度與新穎興去做比較吧? 第二, 是更新頻率部分, 可能會減緩到每個月一篇, 不過, 這也是為了上述深度問題所做的取捨. Stackoverflow 的貼文 (Post) 數量, 以及 GPT 的出現 來自:  https://medium.com/tech-ai-chat/did-ai-kill-stack-overflow-i-hope-it-survives-798f66d9a6da 以上, 就是 2026 年的部落格轉型與規劃, 根據網站後台統計, 多數的連入都來自於搜尋, 換句話說, 也就是關鍵字式的詢問與反響, 也因此, 預期這篇文章也不會有多少讀者真的看到. 不過, 也是記錄下一個文字工作者 (?) 面臨科技的掙扎與轉型, 回顧初心, 當初希望為台灣的環境留下更多技術內容的整理, 然而, 看到 st...

LTE筆記: 3GPP Positioning Reference Signal (PRS) -4

圖片
在前幾篇 PRS 文章中ㄝ,  我們把 PRS 當成由 TRP/gNB 下行發送, 由 UE 量測的定位參考訊號, 並整理了 PRS 相較 SRS 的幾個差異, 例如: muting, 較高功率, 彈性的 comb/symbol, 可做 burst, 同步要求更高等, 以及 PRS 在實作上 (OAI / STARE) 目前的實作成果. 接著, 我們把問題延伸一些, 也就是利用 NTN 衛星網路來進行定位, 為什麼要用 NR-NTN 來進行定位呢? 從標準來說, 3GPP 在 Rel-18 開了方向為 network verified UE location for NR-NTN (TR 38.882), 在需求與 use case 層面把位置驗證當成一個 NTN 會面對的議題. 這代表, 以 NTN 進行定位, 的確被列入未來 5G NR 網路發展的需求, 那麼, 就技術面來說, 為何 NTN 會是一個定位的好選擇呢? 相較於 GPS 系統, 雖然 NTN 時間精準度 (振盪器) 不比 GPS,  但是, NTN 對應的低軌衛星在數量與高度上都更有優勢,  有機會做到更好的定位誤差. 來自:  https://www.ultrontek.com/news_detail/5g-ntn-challenges-architecture-overview 如果比較對象是一般的基站或是地面通訊,  考慮到 NTN 衛星網路的特徵, 會為定位帶來以下問題: 1. 傳播延遲大很多 以 LEO 衛星常見高度範圍 (例如 300–1500 km) 來看,  就算只考慮高度, 單程傳播時間就是毫秒等級,  用 𝑡=𝑑/𝑐 粗估:300 km 約 1.0 ms, 而實際斜距會更長. 2. Doppler 會非常明顯 LEO 相對速度很大,所以 f_d≈(v/c)f_c, 粗估若 𝑣≈7.5 km/s, 在 2 GHz 約 50 kHz, 4.7 GHz 約 118 kHz (只是量級, 實際看軌道與仰角) 這會直接影響 matched filter / delay estimation 時的搜尋範圍與 tracking 難度. 3. 多衛星/多 beam 同頻干擾更容易變成主因 地面 OTDOA 的 PRS 已...

LTE筆記: 3GPP Positioning Reference Signal (PRS) -3

圖片
在前兩篇中, 不論是 SRS 或是 PRS 的定位框架, 我們主要討論的是以時間為基礎 (time-based) 的定位方法, 例如: OTDOA, RTT,  在這些方法中, 其核心概念都是將距離差轉換成時間差, 再由時間差 (多點或是單點) 推回裝置的位置資訊, 這類方法在遇到一個根本限制: 時間解析度直接受限於系統可用頻寬. 以 5G NR 的系統而言, 我們可以簡單估算一下: 假設系統頻寬為 100 MHz, 對應的時間解析度約為: 10 ns 乘上光速後, 我們可以得到距離的解析度為 3 公尺, 換句話說, 這種方法在原理上即不可能達成公尺內的定位誤差. 考慮到這樣的限制, PRS 在 Release 18 中, 加入了以相位 (phase) 的定位量測, 此方法稱為: Phase-based Measurement, 此量測包含了: Carrier Phase measurement Phase Difference between TRPs 其核心轉變在於, 我們不只是關心什麼時候收到 PRS 訊號, 也開始關心收到 PRS 的載波是什麼相位. 這個轉變, 使得定位精度的上限, 從頻寬 (e.g., 100 MHz) 轉向載波波長, 以 4.7 GHz 為例, 波長為 6.38 公分, 在此範圍內我們皆可看到相位的變化, 然而, 使用相位資訊進行定位也會有對應的問題, 考慮到相位變化隨波長周期性變化, 單一觀察到的相位將產生大量的重複解, 也因此, 在進行定位時, 實際上需要同時考慮時間, 相位, 甚至是強度資訊, 我們以下圖表示:   來自:  https://arxiv.org/abs/2209.01183 這張圖說明 Carrier Phase 在不同定位解法中所扮演的角色差異: 左側示意在角度式定位架構下, 來自同一 gNB 的多天線訊號. 其接收相位差可與到達角度 (AoA) 結合, 用以提升角度估計的解析度. 此時相位資訊主要作為空間量測的輔助維度. 右側則示意在時間式定位架構中, 多個 gNB 的到達時間 (ToA) 仍構成主要的定位幾何, 而載波相位則可用於細化距離估計, 降低時間量測受限於頻寬所帶來的誤差. 需要特別強調的是, Carrier Phase 本身並非獨立的定位方法, 而是一種高解析度...

LTE筆記: 3GPP Positioning Reference Signal (PRS) -2

圖片
針對 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():...

LTE筆記: 3GPP Positioning Reference Signal (PRS) -1

圖片
在之前的文章中, 我們介紹了 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...

[AIML] Model Context Protocol 介紹 (1)

圖片
在目前 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 可以在本機或遠端, 也可由不同團隊維護, 已達成擴充性需求.