Castle on a Cloud

和 non-RT RIC 不同, near-RT RIC 可說是完整由 ORAN 設計的元件, 在 near-RT 的架構設計上, 較 non-RT RIC 簡潔, 並引入虛擬化和資源共享, 其架構使用 container 為主的計算架構 (例如: kubernetes), 並提供一個共同的資料存取層, 將計算 (xAPP) 以及資料儲存分開, 並提供各項 xAPP 之間的資料存取管理, 安全性管理以及服務管理, 如下圖所示: 來自: O-RAN.WG3.RICARCH-v01.01   near-RT RIC 對外則有三個接口, 提供 O1, A1, E2 三個介面的串接. 其中, O1 主要是讓 xAPP 統合 E2 Node 資訊後,  向 non-RT RIC 提供錯誤 (faults and events information management, FM) 或是效能 (performance management, PM) 的資訊. A1 介面則以 RESTful API 的方式, 以 1-to-1 對應方式, 使 rAPP 提供 xAPP 支援, 最後, E2 介面則是負責將 xAPP 做成的指令傳達至對應的 E2 Node, 進行相對應的工作. 通常在 ORAN 的架構圖中, near-RT RIC 被歸類於 RAN 的部分, 而 non-RT RIC 被歸類於 SMO 模組的部分, 在實際的布建上, near-RT RIC 通常和 CU 部現在同樣的位置 (Cloud/Edge), 這是因為在 5G NR 架構下, CU 多半被視為軟體化的實作, RU 為硬體實作, 而 DU 則是軟體/硬體兩者兼有, 看實際布建的需求, 簡單的想法就是, 若需要越即時的計算結果, 則需要把 near-RT RIC 往前端布建, 然而代價就是, 較小的管轄範圍以及更頻繁的資料交換. 在這邊需要注意的是, ORAN 的架構的確不只包含 5G, 也可支援 LTE, 此處的表現在 E2 Node 定義包含了 CU/DU (5G NR 架構下), 也包含了 eNB (O-eNB) 請見 O1, A1 介面的 介紹 中的圖一, 但應避免在同一脈絡中, 混用 5G NR 和 LTE 兩邊不同的概念與名詞, 除非是在討論 NSA (Non-StandAlone) 或 SA (S

介紹完 ORAN 中的各項介面後, 我們接著介紹 ORAN 架構中兩個主要元件: non-RT RIC 和 near-RT RIC, non-RT RIC 全寫為: non-RealTime Radio Intelligent Controller, near-RT RIC 則是 non-RealTime Radio Intelligent Controler. 兩者的差別明顯的在於響應的時間, 並透過 A1 介面, 交換資料並分工. 在本文中, 將著重於 non-RT RIC 的介紹. non-RT RIC 負責秒以上等級響應時間的操作, 按照 ORAN 的想法, 其主要有三個功能: Enrichment Information Service: 透過 O1 取得系統的效能, 匯集外部資訊 ML Model Management Service: 更新於 near-RT RIC 上運行的 ML (Machine Learning) 模型 Policy Management Service: 透過 A1 管理 near-RT RIC 要執行的 policy  其詳細的功能圖可以以下圖表示: 來自: O-RAN.WG2.Non-RT-RIC-ARCH-TR-v01.00 在圖中, 我們可以按照顏色分成四塊: 紅色: 暨有 SMO 功能, 又稱為 FCAPS  (Fault, Configuration, Accounting, Performance, Security) 藍色: 暨有 non-RT RIC 功能 黃色: 連接外部資料 (Enrichment Information Service) 白色: rAPP 的架構 (透過 R1 介面, Open API for rAPP) 從圖中, 我們可以發現, non-RT RIC 並不是一個全新的發明, 而是在許多舊有架構 (SMO framework) 下,  重新組織的成果, 在 ORAN 的定義下, 主要是透過介面的標準化, 以及虛擬化的技術, 將 rAPP 引入 SMO 的框架下, 使第三方可以更輕易的開發 non-RT RIC 的功能, 同時也可以相容現有的程式框架, 避免重複開發. * SMO: Service Management and Orchestration 考慮到現有 SMO 的功能,