Castle on a Cloud

在 上一篇文章 中, 我們從青銅時代 (Bronze Age) 的貴族戰爭, 談到鐵器時代 (Iron Age) 大規模軍事動員的改變. 在這一篇文章中, 我們從電影的其中一個爭議: 黑海倫, 談起. 在許多批評中, 黑海倫, 就是 Nolan DEI (Diversity、Equity、Inclusion) 的證據, 一個傾國傾城的美人, 怎麼會是一個黑人? 這比埃及豔后是黑人更缺乏考據, 根本是為討好左膠的 DEI 傾向. 我承認, 以文本和歷史來說, 這個選角更可能是對電影出資者交代, 畢竟, 拍電影從來不是一件簡單的事, 至少比起我在這邊打字, 要花的成本高上不少. 但若是要說, Nolan 為了 DEI 出賣了靈魂 (?), 這大概也不必, 總體來說, 海倫在此電影中*, 從來就不是開戰的原因, 真正的原因是: 貿易, 以及兩邊氏族的長久摩擦. 我們先從特洛伊的地理位置談起. 特洛伊 (Troy) 位於今日土耳其西北部, 靠近達達尼爾海峽 (Dardanelles) 的愛琴海入口. 從這裡出發, 經過達達尼爾海峽、馬爾馬拉海, 再通過博斯普魯斯海峽, 便能抵達黑海 (Black Sea). 換句話說, 特洛伊正好位於愛琴海通往黑海的門戶附近. 來自:  https://www.worldhistory.org/image/589/map-of-the-trojan-war-states-c-1200-bce 根據考古紀錄, 在希臘的青銅器時代, 已有大型船隊進行銅與錫的貿易, 而特洛伊也因為其地理位置, 而成為補給, 貨品交易的集散地, 優越的地理位置為此城市帶來了繁榮與發展, 也解釋了考古上特洛伊城的一再重生. 然而, 地理位置並不能解釋戰爭的爆發, 還缺少兩個勢力的敵對. 在伊利亞德文本中, 特洛伊戰爭本身即是兩個盟邦的爭霸, 甚至還列出了船隊目錄, 列舉聯軍的領袖、所屬地區以及各自帶來的船隻. 依照史詩的敘述, 這是一支由希臘本土、愛琴海島嶼及克里特等地不同政治共同體組成的聯軍, 這支軍隊來自不同地區, 甚至使用不同的語言. 因此各部隊仍由自己的首領指揮, 而非完全整編為特洛伊王國的軍隊. 這也說明了奧德賽必須全程參戰的原因, 以及電影強調 leadership 的由來: 在戰場上, 他是對這些來自家鄉弟兄生死負責的人. 在歷史中,...

先聲明以下內容: 我不是 Nolan 的粉絲, 甚至稱不上任何粉絲, 看過最多影片的導演是楊德昌 我也不是歷史或是考古系, 所有的知識來源只是淺層的知識, 如: Wiki 我對奧德賽的了解止於高中時的中譯版讀物, 也無力於文本分析 以下文章就是在上述限制下完成, 所以, 不會包含複雜的文本比較分析, 也無力探討導演的手法, 或是膠捲的技術差異, 甚至我看的廳也不是 IMAX... 以上聲明, 大概是在當前越漸分立世代的一些界線, 那麼, 閉口不言不是比較好嗎? 但總是有一些有趣的想法或許值得分享? 在此, 借用之前 factfulness 的分類寫一篇文章, 並不是這也是 factfulness 的一種探討, 但在求證史觀上,  我想也借鏡了 factfulness 的精神, 讓我們從歷史文本中出發分析, 假如 Nolan 思考一個真實的奧德賽歸鄉旅程,  他的背景, 他的決斷, 他的足智多謀與狡詐, 背後的時代動力. 這個問題的起點, 可能是青銅時代 (Bronze Age) 到鐵器時代 (Iron Age) 的轉變. 在人類歷史中, 金屬工具的進步並不只是讓刀劍更加鋒利, 或讓農具更加耐用. 當新的工具改變了人們生產, 運輸以及組織戰爭的能力,  社會權力的分配方式也可能跟著改變. 原本由少數貴族 (所謂國人 [1,2]) 掌握的軍事與政治資源,  可能逐漸擴散到更廣泛的社會群體,  而新的財富與武力, 又會進一步挑戰原有的秩序. 有趣的是, 類似的變化, 也可以從中國西周到春秋戰國的歷史中觀察到. 考慮到作者的智識水平, 我必須頻繁以此為比擬,  兩者當然不是相同的歷史進程, 但若將它們並置,  讓我們針對歷史進程與其中殘缺 (希臘黑暗時代), 一點對應. 首先, 先讓我們回到特洛伊戰爭. 根據希臘傳說, 奧德修斯（Odysseus）參與了長達十年的特洛伊戰爭,  戰爭結束後, 又經歷十年的海上漂泊才終於返回伊薩卡 (Ithaca). 特洛伊並非完全虛構, 現今土耳其的特洛伊遺址,  確實存在一座曾經繁榮, 並經歷多次毀壞與重建的古代城市. 其中, 考古學家特別關注其中的 Troy VI 與 Troy VIIa 地層,  年代大約落在西元前 1750 至 1180...

在前面的文章中, 我們介紹了 OAI E3 interface 與 dApp 的基本架, 也進一步介紹 Nvidia Aerial Testbed 如何利用 Data Lake 與 Shared Memory, 減少大量 Layer 1 資料透過 E3 message 傳輸所造成的負擔. 在上述的 E3/ dApp 的架構中, dApp 是依附在 AI-RAN 之外的應用, 對 Spectrum Sensing, ISAC, Positioning 等應用來說, 這樣的架構相當合理. 而今天我們要介紹的是 DeepSig 與 OCUDU 在 2026 年提出另一種 dApp runtime 架構: 在他們提出的架構中, 根據 dApp 的 timing requirement, 分成 Class A、Class B 與 Class C. OCUDU 論文將三者分別定義成： - Class A：Resident Inline L1 - Class B：Bounded Real-Time Control - Class C：Asynchronous Observation and Advisory OCUDU 仍然在 DU 中放置 Embedded E3 Agent 進行控制,  負責 lifecycle、configuration、model management、telemetry 與 RAN control. 針對 Class A/B/C 的 dApp 的執行, 則依據時間需求放置不同地方: Class A 進入 PHY processing pipeline,  Class B 在 MAC scheduler 的 decision boundary 被直接呼叫, Class C 則取得資料進行非同步分析, 可以部署在 DU process 內, 也可以放在外部 process. 如下圖所示: 在圖中, 紫色虛線表示 E3 管理路徑, 實線表示資料或執行路徑. Class A, Class B 與 Native Class C 位於 DU process 中,  Supervised Class C 使用同主機的獨立 worker, Portable Class C 則透過 E3 取得資料. Class C 的受准許結果可由 host ...

在 Nvidia ATB (Aerial TestBed) 中, 也針對 dApp 與 E3 介面實作, 不同於 OAI 以 E2/E3 介面實作 dApp 的資料交換, 在 Nvidia 的 dApp 實作中, 考慮了底層的系統實作與 AI-RAN 的架構, 搭配了 DataLake (資料庫) 以及共享記憶體, 來避免大資料的搬移. 我們先以 Nvidia 的圖來說明其架構, 原始連結如下: https://docs.nvidia.com/aerial/testbed/latest/text/product_description/index.html#software-components 來自: Nvidia ATB 在圖中, 我們可以看到 Nvidia 實作的 dApp 主要是對 DU 動作, 並可分成 4 部分: DU-low, 包含 Layer 1 的服務, E3 Agent 以及 DataLake DU-high, 包含 Layer 2 的服務, 範例中以 OAI 進行示範 共享記憶體 (CPU Shared Memory, CPU SHM) dApp 應用服務 在 Nvidia 的框架中, 針對 dApp 與 DU-low 的部分進行設計, 針對 DU-high 則保有原本 OAI 的 E3 框架. 這樣的設計架構有兩個好處: 1) 可以復用原本 E3/dApp 的註冊/通訊方式, 不會重複定義. 2) 針對感測資料量最大的 DU-low 服務 (raw IQ, 通道估測, 等), 設計更有效的架構. 接下來, 我們進一步看 Nvidia 如何實作 dApp 與 DU-low 之間的資料交換. 從架構上來看，Nvidia 仍然使用 E3 作為 dApp 與 RAN 之間的主要介面. 在 ATB 中, Nvidia 實作了一個 E3 Agent, dApp 可以透過 E3 完成: 1. Setup 2. Subscription 3. Indication 4. Control 也就是說, dApp 啟動之後, 可以先與 E3 Agent 建立連線, 接著訂閱自己需要的 RAN 資料. 當資料更新時, E3 Agent 再透過 E3 Indication 通知 dApp. dApp 完成分析或 AI inference 後, 也可以再透過 E3 Co...

在上一篇文章中, 我們介紹了 dApp 和 E3 介面在 O-RAN 框架中的定位. 接著, 我們介紹一下 E3 的資料格式與參數, 接著我們來介紹 E3 介面的細節, 說明此介面設定如何乘載大量且即時的感測資訊. 首先, E3 interface 目前是 dApp 架構中的延伸介面, 用來讓部署在 O-DU / O-CU 附近的 dApp 與 RAN function 做 超低延遲資料交換與控制. 和 E2 介面連結 nearRT-RIC 和 RAN 不同, E3 直接實作於 RAN (CU/ DU) 之中, 不過在 E3 介面的設計上, 和 E2 有許多雷同之處, E3 也可以拆成 3 層來看: E3 logical interface: E3 是整體 southbound 介面，連接 dApp <=> RAN node E3AP (E3 Application Protocol): E3AP 負責程序與封包類型, 類似 E2AP 在 E2 裡扮演的角色 E3SM (E3 Service Models): E3SM 負責 dApp 資料/控制的定義, 類似 E2SM 也和 E2 介面類似, E3 介面主要有兩個建立關聯的步驟: E3 Setup, E3 Subscription. 我們先從 E3 Setup 開始說明: 這張流程交換的圖示, 應該很有印象,  基本上, 把 xApp/ dApp 以及 E3 Agent/ E2 Agent 的角色調換一下, 就是 E2 介面的 Setup 流程,  在 E3 介面中用來做初始配對, 認證, 建立 dApp 與 RAN node 關聯. 考慮到我們主要要介紹 E3 介面的資料格式與 dApp 功能,  我們先略過 Setup 的介紹, 來花篇幅介紹更重要的 E3 Subscription. 和 E2 介面類似, E3 Subscription 的流程也是先定義了需要的資源, 此處的資源可以是回報的數值, 例如: SRS 回報, 也可以是被控制的功能, 例如: PRB 分配. 在確保了 CU/ DU 有 dApp 所需的支援之後, 接著進行以下的流程: E3 Indication MessageRAN => dApp: 傳遞 tele...

很就沒有來看 O-RAN 的變革, 雖說知道有 dApp 的出現, 提供 realtime App 的應用, 但沒有發現到針對 dApp 也有一個專屬的介面: E3 interface. 我想就找個機會來整理並介紹. 首先, dApp 和 E3 interface 是 O-RAN 社群在 nGRG / research report 中提出的延伸架構, 不是像 E2/ O1/ A1/ F1/ Open Fronthaul 那樣已經是大家熟知的介面. 它的目的是補足現有 rApp/xApp 架構兩個缺口: 無法直接處理 user-plane/ IQ symbol/ reference-signal 級資料 難以做到 10 ms 以下的 real-time control. 我們先以一張圖來表示 dApp, E3 以及其他元件的關係: 在這張圖中, 我們介紹一下各個元件的關係: rApp 在 Non-RT RIC，時間尺度通常 > 1 s xApp 在 Near-RT RIC，時間尺度通常 10 ms ~ 1 s dApp 不在 RIC 裡，而是直接部署在 O-DU / O-CU-CP / O-CU-UP  E3 是 dApp <=> DU/CU 的即時資料與控制介面 E2 仍然是 Near-RT RIC/xApp <=> E2 node (DU/CU) 的介面 如果用角色來分, 各元件的功能如下: rApp: 慢速策略, 模型管理, 長時間尺度 (>1s) 最佳化 xApp: 近即時控制, 跨 cell/RU 之間的協調 dApp: 超低延遲, 貼近協定堆疊, 直接處理 SRS/IQ/CIR/封包等即時大量資料 DU/CU/RU: 真正執行無線與協定功能的 RAN 節點 接著, 我們來看各元件之間的資料交換流程, 並以 SRS 回報為例, 在相關論文中, 明確寫到 SRS 可由 O-DU 透過 E3 提供給 dApp, 定位 use case 則是使用 UL CIR. 所以整體的流程是: SRS => O-DU channel estimation => CIR/features => dApp inference. 我們以下圖來表示整體資料交換流程: 整體的流程可分成 6 步驟: dApp 先用...