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 的角色)

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

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

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