CU/DU Split for NTN

By Rashid Khouli, Fraunhofer IIS, Germany

CU/DU Functional split is one of the key enablers for 5G networks. It supports Centralized RAN (cRAN), virtualized RAN (vRAN), and the recent Open RAN (ORAN). There is a trade-off between the advantages of RAN centralization (energy efficiency, power cost reduction, and the cost of the CU/DU interface) and the complexity of carrying traffic between the data processing unit and distributed antennas. The virtualized RAN is split into a distributed unit (DU) and a centralized unit (CU), and a number of CU/DU split options have been defined by 3GPP.

Currently, there are ongoing studies on implementing CU/DU Functional Split in NTN which take the different characteristics on NTN into account. The CU/DU Architecture in NTN as defined by 3GPP is depicted below, where the gNB is split into two entities, namely, the gNB-DU which have the lower functionalities from the protocol stack, and is implemented onboard the satellite, and the gNB-CU which has the higher functionalities of the protocol stack and is implemented on the ground.  Implementing CU/DU split options in NTN achieves the following:

1. Reduce the complexity onboard the satellite compared to a full gNB onboard.
2. Reduce the bandwidth and the signaling towards the core network (over the feeder link).
3. Service continuity and ubiquitous coverage.

It is clear that 3GPP has only defined F1 interface for split options 2, to be the only CU/DU interface which has been fully standardized. However, other split options might be applicable for NTN, which can be summarized as the following:

• Split Option 8: This split option is defined between the RF and the PHY layer, where only the Radio Frequency (RF) sampler and the upconverter are left in the DU, resulting in a very simple DU which supports different RATs.
• Split Option 7.1: This split option is defined between the digital beamforming/RE mapping and the IFFT operation in the DL, where only the IFFT, the CP, and the analogue beamforming are performed on the DU side onboard the satellite. In the UL, this interface is defined between the FFT and the RE de-mapping. Additionally, PRACH filtering is performed in the DU as well.
• Split Option 7.2: This split option is defined by 3GPP, and it is defined between the precoding and the RE mapping, which, compared to split option 7.1, includes both the beamforming and the RE mapping functionalities on the DU. There are ongoing discussions on where to place this split option (whether or not to include the precoding on the DU). Including both the precoding and the RE mapping in the DU has many advantages when it comes to the CU/DU interface bit rate requirements and multi-connectivity support. This split option keeps the FEC inside the CU-pool which is a benefit for the close cooperation between the forward error correction (FEC) and the MAC.
• Split Option 7.3: This split option is defined between the coding stage and the modulation, so, compared to split option 7.2, it includes the precoding, layer mapping and modulation on the DU. It is worth mentioning that precoding could be included in the DU in split option 7.2 as already mentioned.
• Split Option 6: This split option is defined between the MAC and PHY, where all PHY functionalities are performed on the DU.
• Split Option 5: This split option is defined between the lower MAC and the higher MAC, where the MAC time-critical functionalities such as HARQ are performed on the DU. In this split an overall scheduler is centralized in the CU, and a MAC sublayer is local in each DU to handle time critical processing. From this split and below, the time critical procedures in the HARQ are performed locally in the DU, and also the functions where performance is proportional to latency.
• Split Option 4: This split option is defined between the MAC and the radio link layer (RLC), where the PHY and the MAC functionalities are performed on the DU.
• Split Option 3: This split option is defined between the low RLC and the high RLC, where the low RLC functionalities such as segmentation are performed on the DU. The UP processing of PDCP and asynchronous RLC processing takes place at the CU. All other UP functions remain in the DU including synchronous RLC network functions.
• Split Option 2: This split option is defined between the RLC and the PDCP and was standardized by 3GPP. This split option is a big candidate for NTN.
• Split Option 1: This split option is defined between the PDCP and the RRC for the control plane and between the PDCP and the SDAP for the user plane.

The applicability of the different split options in NTN is evaluated based on different KPIs such as:

1. The bitrate requirements on the feeder-link
2. The timing requirements on the feeder-link.
3. The maximum number of supported DUs.
4. Multi-connectivity support.
5. Beamforming support.
6. CU/DU Interface Complexity.
7. Multiplexing gain.

Based on the KPIs mentioned before, many split options could be candidates for NTN, where the different requirements and use cases determine the best applicable split option. Split options such as 8 and 7.1 are not applicable for NTN due to the high constant bit rate, and the high timing requirements associated with protocols such as CPRI and eCPRI, which were initially used for lower split options. However, split options such as 8 and 7.1 might still be implemented in NTN using other protocols or modified eCPRI versions, which take the long NTN propagation delay into account. Additionally, split options 7.2, 7.3, and 6 could play an important role in NTN to reduce the complexity onboard the satellite while tolerating the bit rate and the latency requirements on the feeder link (CU/DU interface). These split options could be implemented in vLEO where the complexity onboard the satellite is the most important factor. Split option 2 on the other hand is a big candidate for NTN, as the interface F1 between the CU and the DU has already been standardized by 3GPP. This could be beneficial in multi-connectivity and mobility management, as an interface is required between the CU and the DU, and between the DUs. Additionally, a strict synchronization is also required between these entities, which could be a challenge for lower layer split options such as 7.2, 7.3, and 6.