LTE筆記: C-RAN (Cloud-RAN) ~5

考慮到實作上的困難, 3GPP 最終並沒有制定底層的功能切分,

此部分的功能切分, 就變成一個開放議題, 而回到各設備廠商的實作,

其中, 值得一提的是 O-RAN 此組織在 C-RAN 協定上的努力.

首先, 先談談 O-RAN 這一個組織,

O-RAN 全名為 ORAN Alliance, 組成包括全世界重要的電信商以及設備商,

其目標是提供開放架構的電信網路, 將原有的特製化設備, 使用標準的軟硬體取代,

並透過開放的系統與定義完善的接口, 讓更多硬體商加入設備提供,

完成電信網路的白牌化.

先撇開最終成敗不談*, O-RAN 的目標的確是一有趣的想法.

有興趣的同學, 可以查看: https://www.o-ran.org/

其中, 關於 C-RAN 的討論在於 WG6: The Cloudification and Orchestration Workgroup,

在此工作項的說明中, 就強調了要引入商用硬體, 加入 C-RAN 的競爭,

在該份文件的撰寫時, 也的確花了很大的篇幅討論商用軟硬體的腳色,

不過, 商用硬體的腳色並不是本文的重點, 因此先存而不論,

回到功能的切分, 在 O-RAN 的討論中, 決定了底層切分的方式為 Option 7-2,

並且透過一個名為 Open fronthual 的介面通訊,

因此, 在 O-RAN 的架構下, C-RAN 的架構變成了: CU-DU-RU (Radio Uint),

其中, RU 為天線的單元, 透過 fronthaul 傳送至 DU.

此時, 就將引出了延遲的問題,

對此, O-RAN 的想法是根據不同的應用的延遲需求來佈建 DU, 如下圖所示:

來自: Cloud Architecture and Deployment Scenarios for O-RAN Virtualized RAN (v2.0)

在上圖中, 我們可以看到 DU 基本上是安放於 edge 上,

考慮到其負擔了部分 PHY 層的功能, 必須在低延遲下, 和 RU 進行溝通,

其中, 延遲的限制約為 0.1 ms, 也限制了 fronthual 網路的範圍小於 20 km.

至於 CU 的位置則隨應用而改變,

對於 URLLC (超低延遲通訊, 用於車聯網), CU 必須在 edge 上實現,

對於一般的通訊 (eMMB) 與務聯網應用 (mMTC), CU 則可於雲端實現.

* Note: 以我個人的角度來看, O-RAN 的成功主要是要看電信商的角色,

考慮到目前沒有一個組織負責功能之認證 (如 WiFi 之於 IEEE 802.11一般)

若要期待有一天電信網路要走向白牌, 與通用之硬體,

電信商就必須投入更多人力與技術, 自行負起電信網路的組織與最佳化,

(如同 Google 建立白牌資料中心一般, 不是白牌取代 IBM, 而是 Google 取代 IBM 的角色)

然而, 考慮到電信業為特許且極度在地之產業, 少有電信商擁有跨國之佈建能力,

此商業模式無法輕易複製, 也無法將所產出的服務面向全球,

因此, 電信商真實願意投入的動機, 在我來看是令人存疑的.

Castle on a Cloud