# A3: O-RAN Fronthaul Interface (FHI)
###### tags: `Wireless Communications`

## Split Option 7-2x
[上一篇](https://hackmd.io/@Ting-Wan/HJ99GFsmj#Open-Fronthual)已認識到什麼是O-RAN為了防止出現廠商壟斷的情況，就要做硬體上面的切片，讓不同的供應商製造元件。所以要考慮RAN如何解耦(RAN Disaggregation)。
### Open Fronthual 採用Split Option 7.2規格
主要考慮的兩個點：

1. 能耗
* 如果RU功能愈多，相對能耗就愈多。
* 使O-RU盡可能簡單、更小、更省電
2. 資料需求(option 1~8)
* 考量位元速率、資料傳輸，open-fronthaul 切在數字愈大(ex:option 8)，RU功能少研發更簡單。
* 但介面傳輸量會提高，對於延遲要求也會增加
* 最後就是把Open-Fronthual 切在H-PHY, L-PHY的中間，解耦DU, RU。


In general, the required fronthaul bandwidth becomes smaller as more functions become entrusted to the O-RU.

Furthermore, when the O-RU handles all Layer 1 functions, the required fronthaul bandwidth is essentially comparable to the baseband bit rate.

On the other hand, in that case, the amount of processing and memory required of dispersed O-RUs increases. Additionally, when making function modifications and extensions, it is often the case that not just the O-DU but the O-RU too must be upgraded.

Moreover, when performing resource element mapping/demapping on the O-DU side, data will be transmitted after user multiplexing thereby simplifying control signals on the fronthaul and making it easier to achieve multivendor RAN. Split Option 7-2x was adopted taking these tradeoffs into consideration.

## Overview of Fronthaul Interfaces
在 C/U-Plane 中，O-RAN 前傳規範支持通過以太網直接傳輸 eCPRI 或以太網無線電 (RoE) 使用的信號的協議棧和通過用戶數據報協議 (UDP) 傳輸信號的可選協議棧 /IP。

與此同時，在 S-Plane 中，O-RAN 前傳規範支持協議棧，該協議棧通過以太網傳輸精確時間協議 (PTP) 和 SyncE 中使用的信號。

最後，在 M-Plane 中，O-RAN 前傳規範支持通過以太網/IP/傳輸控制協議 (TCP)/安全外殼 (SSH) 傳輸網絡配置協議 (NETCONF) 中使用的信號的協議棧

NETCONF 在 Internet 工程任務組 (IETF) 中被制定為 RFC6241，是用於管理網絡設備的通用協議。 O-RAN 前傳規範主要關注 NETCONF 的數據模型部分，該部分是運營的目標並被視為實現問題。

:::spoiler
* UDP：傳輸層的協議，通過不進行傳遞確認、擁塞控制等，具有輕處理的特性。它用於傳輸過程中數據丟失不會成為主要問題的通信。
* PTP：用於在連接到網絡的設備之間實現高精度時間同步的協議。
* SyncE：在以太網上傳輸時鐘信號的系統。
* TCP：IP 之上的標準 Internet 上層協議。 它通過提供在連接和數據到達中確認對方、執行流量控制以及檢測數據重複或丟失的功能來補充IP，以實現高度可靠的通信。
* SSH：實現安全遠程登錄和提供網絡服務的協議。
* IETF：開發和推廣互聯網技術標準的標準化組織。 此處制定的技術規範以請求評論文檔 (RFC) 的形式發布。
:::
### U-Plan
#### U-Plane message frame format

The eCPRI payload of the U-Plane message can be used to transmit an IQ sample (iSample/qSample) sequence of the OFDM signal in the frequency domain applying IQ compression and IQ compression information (udCompHdr).

This information is transmitted together with time/frequency resource information that should be applied to the transmission and reception of the IQ sample sequence on the radio interface.

the frame format of the U-Plane message is used in common in both directions, that is, for transmission from the O-DU to O-RU and transmission from the O-RU to O-DU.

### C-Plane
#### C-Plane message frame format
The eCPRI payload of the C-Plane message passed from the O-DU to O-RU consists of information specifying BF weights to be applied when transmitting and receiving IQ sample sequences included in the U-Plane message on the radio interface. It also consists of time resource information (the same as the U-Plane message) and frequency resource information (startPRBc, numPRBc) to which the above BF weights are to be applied. The O-RU uses this information to generate a beam for transmitting and receiving signals on the radio interface.

### Delay Management
O-RAN拆分選項 7-2x在無線電接口的 PHY 層內引入了O-DU和O-RU之間的功能拆分。這種分裂導致O-DU 和 O-RU 之間交換的數據的傳輸和接收出現一些延遲，這種延遲被稱為Fronthaul Delay。前傳的數量取決於拓撲、 O-DU 和 O-RU 的連接方式以及底層傳輸（路由器和交換機）網絡。

前傳延遲管理需要根據無線電接口(Uu)的發送/接收時序和HARQ 過程的重傳時序在前傳上傳輸C/U-Plane 消息。這種延遲管理能夠採用基於eCPRI框架的接收窗口和發送窗口的概念。

O-RU從前傳接收到OFDM信號在頻域的IQ樣本序列後，及時進行一定的IFFT、模擬轉換、BF等，以便在給定的特定時間資源（無線電幀）的無線電接口上傳輸信號、子幀、時隙、OFDM符號）。由於這個原因，O-RU的接收窗口位置在無線電接口上的傳輸定時之前被設置在與該O-RU處理延遲相對應的偏移處。

同時，O-DU 將C / U-Plane 消息傳輸到前傳，以便在 O-RU接收窗口內傳遞。因此，O-DU的發送窗口位置被設置在與O-RU處理延遲和前傳延遲相對應的偏移處到無線電接口的發送定時之前。這裡，前傳時延包括前傳距離和交換處理時延等可變因素。

* O-RU接收窗口的大小被校準為可以覆蓋前傳延遲和 O-DU發送窗口大小的這種波動的長度。
* O-DU發送窗口的大小是在考慮了O-DU將 C/U-Plane 消息發送到前傳所需的處理時間後計算的。
使用相同類型窗口的延遲管理也適用於從 O-RU 到 O-DU 方向的傳輸。此外，前傳規範為 C-Plane 和 U-Plane 定義了單獨的窗口。

### M-Plan
The M-Plane provides a variety of O-RU management functions to set parameters on the O-RU side as required by the C/U-Plane and S-Plane described above, to manage O-RU software (SW), perform fault management, etc.

This eliminates dependence on each O-RU vendorʼs implementation and makes multivendor RAN possible.

支持以下兩種模型作為 MPlane 架構:
1. 分層模型：在此配置中，一個 O-RU 由一個或多個 O-DU 管理。這些O-DU終止了對下級O-RU的監控/控制，使得NMS無需處理所有O-RU的監控/控制，有助於降低NMS的處理負荷。 此外，在現有NMS還不支持NETCONF的情況下，由於O-DU在這個M-Plane中支持NETCONF，該模型的優勢在於可以在不影響現有系統的情況下進行網絡建設。
2. 混合模型：在這種配置中，除了 O-DU 之外，一個 O-RU 還由一個或多個 NMS 管理。 該模型的一個優點是除了 O-RU 之外，NMS 還可以監視/控制其他網絡設備，從而實現對所有設備的統一維護、監視和控制。

在任一架構模型中，都可以限制每個NETCONF客戶端管理O-RU的管理功能，從而實現靈活操作。 例如，操作可以分為NETCONF客戶端進行SW管理和NETCONF客戶端進行故障管理。

## Fronthaul Network Topologies
考慮到 O-DU 和 O-RU 之間物理線路數量的限制，前傳可能需要採用點對點以外的網絡拓撲（圖a），例如使用 第 2 層交換機。 上述 C/U/S 平面和 M-Plane 支持如下示例所示的網絡拓撲（圖b）。

圖中的情況（1）描述了一個拓撲，其中前傳線路的數量在每個間隔內可以不同。 該拓撲可用於增加前傳傳輸容量，而無需通過簡單地增加每個具有標準容量量的端口的數量來增加 O-DU 和 O-RU 的每個端口的容量。 此外，這種拓撲結構允許在 L2 交換機之間僅使用一條線路，這有助於降低線路成本。

圖中的情況 (2) 描繪了一種拓撲，它為 O-DU 和 O-RU 之間的前傳路徑提供冗餘。 如果顯示的路徑中的任何一條出現故障，此拓撲使服務能夠通過使用另一條路徑的設備繼續。

圖中的情況（3）描繪了一種拓撲，即使O-DU上的物理端口數量應該受到限制，也可以通過將交換機用作集線器來同時連接多個O-RU。

## Conclusion
This article introduced Split Option 7-2x adopted in O-RAN fronthaul specifications and described the C/U/S-Plane and M-Plane prescribed in the same specifications. Going forward, the O-RAN Alliance will continue to promote genuine multivendor RAN using O-RAN fronthaul specifications and to make useful extensions to those specifications.