Castle on a Cloud

考慮到實作上的困難, 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 上實現, 對於一般的通訊  (

在 上一篇文章 中,  提到了 3GPP 組織於 TR 38.801 中決定了 higher layer 的分層設定, 對於 lower layer 的分層設定則留待之後討論, 所衍伸的討論文件為: TR 38.816 Study on CU-DU lower layer split for NR 在 TR 38.816 中討論了以下四個不同的選擇: Inter-PHY split: Option 7-1, Option 7-2, Option 7-3 MAC-PHY: Option 6, 其中, 不同的選項表示如下圖: 來自: TR 38.816  Study on CU-DU lower layer split for NR 在圖中, 我們可以看到 Option 7-1 的斷點在 FFT/IFFT 的部分, FFT/IFFT 通常都是由專屬電路負責, 因此, 移入 CU 並沒有太大的意義, Option 7-2 則把和使用者即時通到資訊相關的 pre-coding 部分也放在 DU, 這樣的架構可以減少 DU 向 CU 回傳的資訊量, 最後則是 Option 7-3 的架構, 只把 coding 的部分移入 CU. 在 TR 38.816 的討論中, 由於以下兩個原因, 最後並沒有做出選用的結論, 第一, 在系統實作上, 許多基地台有其特有的功能 (如: beamforming), 這部分的功能並不在 3GPP 的規範之中, 可實作於實體層的不同部分, 如果強硬規定其切分方式, 可能會影響各廠商的實作. 第二, 在原有的 Radio Access Network 規範中, 對於上行 (uplink) 接收部分, 並沒有詳細的功能切分(functionality)定義,  同時, 對於未來不同的通訊需求 (IoT, ultra-low latency), 也可能改變實體層所需的功能, 這也造成了此處切分的困難, 不論如何, 雖然 TR 38.816 無法取得一致的同意,  但是這份文件也指出了切分時的重要依據, 也就是 fronthual 所需的頻寬, 並討論了幾種不同切分下的應用情境, 作為廠商實作之參考.