Castle on a Cloud

在 上一篇文章 中, 我們介紹了 A1 和 O1 介面, A1 和 O1 主要從 non-RT RIC 出發, 用以串接 O-RAN 架構中各裝置, 而 E2 介面*則由 near-RT RIC 出發連接 5G 網路中的裝置, 並稱為 E2 Node, 我們一樣從架構圖出發: 來自: O-RAN.WG1.O-RAN-Architecture-Description-v03.00 這張架構圖和之前的一致, 不過標出了 3 個 control loop 以及時間響應:  Non-RT RIC (>=1000 ms), Near-RT RIC (10~1000 ms), O-DU (<10 ms), 在這張圖中, 我們可以看出 E2 和 O1 介面在時間響應上的差異, 簡單來說, E2 負責較即時的資料交換, 並基於各 E2 Node 的控制訊息實作. 考慮到 O-RAN 的架構, 基本上所有實體 (CU, DU, eNB) 都可以作為 E2 Node, 在 E2 介面的定義上, 採取將 E2 Node 虛擬化的想法, 如下圖所示: 來自:  https://wiki.o-ran-sc.org/download/attachments/10715420/Near_RT_RIC_for_ONS.pdf 在圖中, 我們可以看到, 每一個 E2 Node, 不論扮演 CU, DU 或其他功能, 都透過 E2 Agent 和 Near-RT RIC 上的 xApp 進行資料交換, 不同的單元, 如 O-DU, O-CU, O-eNB, 與 Near-RT RIC 之間介面相連的關係如下圖:   來自: O-RAN.WG3.E2AP-v01.01 從上圖, 我們也可以看到 O-RAN 取名 E2 而非 E1的 原因, E1 介面為 3GPP 定義 CU-CP 和 CU-UP 之間的介面,  因此, O-RAN 從 E2 定義, 而非如 A1, O1 般, 從1開始編號.  在 E2 Node 一開始連上 Near-RT RIC 時, 透過 E2 Node Setup Procedure, 告知 Near-RT RIC 自己所支援的 Func (對應到 Near-RT RIC services), 宣告完...

在大略看過 O-RAN 的架構之後, 在這一篇文章中, 我們把重點放在各單元之間的介面, 來自: O-RAN.WG1.O-RAN-Architecture-Description-v03.00 在 O-RAN 架構下, 其自訂介面可以包括以下項目: O1: FCAPS (Fault, Configuration, Accounting, Performance, Security) 的控制介面 O2: 和 O-Cloud 溝通 A1: Non-RT RIC 和 Near-RT RIC 溝通 E2: Near-RT RIC 和 gNB/eNB (O-RAN 中稱為 E2 Node) 溝通 Open Fronthaul: RU (Radio Unit) 溝通   CUS: Control User Synchronization (連接至 DU)  M: Management (連接至 Non-RT RIC 或 DU) 多數的介面都是直接定義兩個單元之間的界接 (O2, Open Fronthaul), 比較值得關心的介面像是 E2 (因為 E2 Node 有各式功能) 以及 O1 與 A1 (兩者都連接 Near-RT RIC, 如何分工?) 我們先從 O1 和 A1 介面開始, 按照 SPEC 中的描述, O1 介面不直接與 Non-RT RIC 相連, 並負責 FCAPS 功能, A1 介面則是連接 Non-RT RIC 和 Near-RT RIC 提供 RAN 的設定最佳化, 在目前 O-RAN 框架下, A1 介面有以下三個功能: Policy Management Service: 提供 Near-RT RIC 的執行策略設定 ML Model Management Service: 更新 Near-RT RIC 的 ML 模型 Enrichment Information Service: 提供 Near-RT RIC 外部資訊 透過 A1 介面, 我們可以發現在 Near-RT RIC 和 Non-RT RIC 的分工上,  Near-RT RIC 負責即時的運算, Non-RT RIC 負責 ML 模型訓練以及參數選擇, 詳細的內容與分工, 我們之後會以實例進行說明, 至於 A1 和 O1 的分...

ORAN (Open Radio Access Network) 是一個主要由電信營運商發起的組織, 其目標在於在 3GPP 的 5G NR 架構上, 提供一個開放性的管理架構, 提供 Radio Access Network (基地台, 無線接取點) 的協作管理, 智能化, 與虛擬化, 其官方網站為:  https://www.o-ran.org/ 在上述目標中, 我們可以釐清一些重點: ORAN 的發展是基於 3GPP 架構, 因此, ORAN 不會重複定義 3GPP 的功能, 而以補充 3GPP 框架, 或是提供協定外的裝置管理為主 ORAN 的組成為營運商為主, 和 3GPP(硬體廠商也佔有重要角色) 不一樣 , 發展重點也著重於開放硬體架構 或許, 會有人好奇:  假如 ORAN 不是一個通訊協定 (如 3GPP LTE/5GNR), 那麼其標準的意義與範圍為何? 事實上, 在通訊系統的實作中, 有許多功能的演進都不是由 3GPP 推動, 而是由各硬體/營運商實作, 例如 China Mobibe 的 Cloud-RAN 就是一個很好的例子, 通訊協定, 通常只定義了封包交換的格式與流程, 作為基本的相容性規範, 而留下了許多空間讓各家廠商實作並優化演算法與架構. 對於 ORAN 而言, 其目標也不是提供優化演算法的標準, 反而是在現有 3GPP 的框架下, 提供框架與資料接取流程, 站在電信營運商的角度, ORAN 可以解決兩個問題:  透過開放降低白牌裝置的進入障礙, 進而降低整體建置成本,  透過定義資料交換架構, 使得一集中式控管的 RAN 架構更容易實現, 有利於在 5G NR 眾多異質接取設備下, 提供良好的布建與管理. 下圖為 ORAN 的架構:   來自:  https://www.o-ran.org/ 在 ORAN 架構中, 依循 Cloud-Edge-eNB (RF) 的架構,  依據即時性的需求, 將 RAN Intelligent Controller (RIC) 架構分成 3 個部分: Non-RT RIC: 紫色方塊, 位於雲端平台, 響應時間 >1000 ms Near-RT RIC: 深藍色方塊, 位於 Edge 平台, 響應時間為 10~1000 m...