Exploring Functional Splits in 5G RAN: Tradeoffs and Use Cases

Ankur Sharma, Associate Vice President, Product Management and Strategy, Radisys

 

Shortly after LTE reached maturity, service providers started facing new challenges to meet customer demand for high capacity and “always-on” connectivity with quick set-up and transition time, spurred by diverse new applications and extremely high data usage by subscribers. To address some of these challenges, service providers began spending on new hardware and software for Radio Access Network (RAN) upgrades, spectrum refarming, and co-existence of licensed-unlicensed multi-mode deployments.  While these approaches helped alleviate some of the issues, they also increased service providers’ CAPEX and OPEX and significantly reduced profitability.  Service providers needed a software-controlled RAN with embedded intelligence on purpose-built hardware which could be deployed in multiple ways. To meet these requirements, 5G topology introduced a new mindset of creating and defining a “multi-split” architecture.

Evolution of the 5G RAN split

Today’s 5G networks are meant to support various applications with diverse requirements such as latency, high data rates and real-time support for random traffic demands. Initially, the proposal to handle such requirements was in the form of Cloud-RAN with ultra-dense small cells. Such a model, with Control Plane – User Plane Separation (CUPS) like design, would bring more flexibility. Disaggregated hardware and software would enable more efficient scaling, allowing service providers to customize their networks to align with their own demand needs and available infrastructure. However, with eight possible functional split options in 3GPP’s 5G-NR RAN2 specification, one of the standards bodies which oversees the development of mobile protocols, it was tough to meet the fronthaul requirements. After extensive discussions, 3GPP defined two 5G-NR split architectures in addition to the traditional monolithic one:

• Option 2 – a high-level centralized Unit (CU) and distributed Unit (DU) split which is primarily a separated control and user plane
• Option 7 (or 7.2) – a low-level split for ultra-reliable low-latency communication (URLLC) and near-edge deployment

Further evolution was needed to support these two architectures to reduce complexity in the remote radio unit (RRU), to bring more intelligence to the local RAN, to increase cost competitiveness and resiliency, and to support disaggregated spectrum and efficient transport utilization. The Open RAN Alliance as well as the Small Cell Forum (SCF) evolved their specifications to support 5G functional splits with two additional versions:

• O-RAN Alliance defined the low-level split (option 7.2x)
• Small Cell Forum defined split option 6

                                           5G Functional Split Options.  (Source: Small Cell Forum)

Key split options for initial 5G deployment

Not all split options are considered ideal for initial 5G deployments. Though the 3GPP 5G RAN specification comes with a CU-DU split design with distributed capability and virtual functionalities, both the O-RAN Alliance and the Small Cell Forum have proposed further enhancements to this base design with new variants and flexible topologies:

Split 2: RRC/PDCP split. Radio resource control and packet data convergence control are split from the Layer 2 radio link control (RLC). Split 2 can be deployed in two variants:

• Variant 1: RRC, service data adaptation protocol (SDAP) & PDCP in the same central unit as one entity; no control and user split. RLC, medium access control (MAC), and high physical layer will be part of the DU, and the low physical layer along with the RF are in the DU.
• Variant 2: In addition to Variant 1, this split option comes with control and user split like in a CU-CP and CU-UP. RRC along with PDCP-C will be part of CU-CP, and the SDAP/PDCP-U will be associated with CU-UP.

Split 6: MAC/PHY layer split. The MAC, RLC and upper layers will be part of the central unit (CU). There is no Low PHY/High PHY split; instead the full stack of the PHY layer and the RF are in the DU/RU.

Split 7.2x: Low PHY/High PHY split. The Low PHY/High PHY split is the most acceptable approach for it is less complex and it supports various fronthaul requirements and most importantly it has high virtualization benefits. This split has been further optimized by the O-RAN Alliance into two variants: split 7.2a and split 7.2b. Split 7.2x comes with fronthaul compression techniques like BFP IQ compression and de-compression to further reduce transport bandwidth.

Split 8: PHY-RF split. This 3GPP defined split was considered earlier in traditional C-RAN based designs including CPRI supporting RRUs, but it still holds benefits for 5G in some unique business cases. This split enables complete separation of the RF from the Physical layer to maximum virtualization gains. Everything from the Physical layer and up, including all protocol layer levels, is centralized, resulting in a very tightly coordinated RAN. This allows efficient support of advanced 5G features that require extremely low latency like multiple TRP transmission and reception, high order MIMO, and high diversity for URLLC-like traffic.

Summary of RAN Splits (Source: Radisys)

 

Which split function to use where?

5G brings higher throughput and extended cell edge coverage benefits as compared to LTE. This became possible because of higher spectrum, flexible air interface, high order MIMO with smart beamforming, access agnostic and disaggregated RAN with flexible deployment options. 5G is being deployed today as Unified Delivery Network (UDN), Fixed Wireless Access (FWA), Non-Public Network (NPN) / Public network integrated NPN (PNI-NPN) and many more topologies to address diverse use cases.

The choice of RAN split in 5G deployment depends on many factors and is not limited to just radio network deployment scenarios, intended supported services, existing infrastructure, or cost competitiveness. Some additional factors to consider include:

• Specific QoS requirement for offered services (e.g., low latency, high throughput)
• Network densification, traffic profile, bandwidth demand, available spectrum with RF features like MIMO
• E2E transport availability networks with different performance levels, from ideal to non-ideal
• Use cases: Real-time or Non-Real Time
• Features requirement for the RAN like DSS, NR-NR CA, NR-NR-DC, TDD-FDD mode and more.

When talking about end-to-end network topology, we must consider that these split options will provide adequate gains if other network elements like transport, data center placement and connectivity, packet core, infrastructure programmability, automation, data collection and analytics, cloud native platform and others are considered as well.

To help with the decision process, here are details on how each split is designed, where it can be deployed, its tradeoffs, and best use cases.

Split 2

Split 2 – design and deployment:

Split 2 brings SDAP/PDCP with RRC into the centralized unit while all L2/L1 functions will be part of the local or centralized DU. This split transfers PDCP/SDAP PDUs in the DL and receives RLC SDUs in the UL direction. This option is like 3GPP Release 12 based LTE dual connectivity (option - 3C) which can handle multiple flows to various access nodes to enable multi-connectivity scenarios. Because of the control and user split, deployment is mainly focused on non-real-time applications running in the CU when transport requirements like latency and bandwidth are relaxed.

Split 2 – tradeoffs:

1. This split is an already standardized PDCP-RLC split like in LTE dual connectivity.
2. Its most important advantages are centralized encryption/integrity and enhanced coordination of mobility and session transfer procedures. This split brings centralized PDCP entity (user plane) which can be separated from RRC/RRM (control plane), hence it is highly latency tolerant.
3. Requires a “re-sequencing buffer” in both DU and CU so that packets arrive in the correct sequence.
4. Enables beamforming gains, though it lacks the efficient coordinated scheduling between multiple DUs, so inter-DU coordination is not fast enough for low latency applications.
5. Delivers only marginal multiplexing gains in the CU pool because most of the critical functions are in the DU which can be part of on-site or close-to-cell site deployment such as in a local data center.
6. Needs to have the coordination of security context parameters if deployed in a topology having different PDCP instances.

Other considerations:

Low latency as well as bandwidth in the fronthaul are needed. With split option 2, UL/DL fronthaul rates are defined by 3GPP in TR 38.801, Table A-1 as below:

• DL FH bitrate = Peak Rate*(BW/BW for control signal) *(# of layers/# of layers in control signals) *(8/6) + signaling
• UL FH bitrate= Peak Rate*(BW/BW for control signal) *(# of layers/# of layers in control signals) *(6/4) + signaling
• In scenario using 100 MHz bandwidth, 8 layers and 256 QAM modulation the fronthaul bitrate will be DL 4 Gbps and UL 3 Gbps.

Split 2 – use cases: Ideal use cases include scenarios where a low fronthaul bitrate is necessary to be transported over a less ideal fronthaul interface, where higher security and resiliency is obtained by CP/UP separation.

 

Split 7.2x (The O-RAN Alliance)

Split 7.2x - design and deployment:

Split 7.2x is the O-RAN Alliance fronthaul specification between O-DU to O-RRU. It has two variants: 7.2a and 7.2b based on where precoding occurs. If precoding and resource element mapper are part of the O-DU and the O-RRU handles beamforming onwards then it is 7.2a split. If precoding happens in the O-RRU then this is 7.2b split. The below figure illustrates a complete view (interface connectivity within RU/DU/CU) of O-RAN split 7.2x:

                                           

Source: Radisys

7.2a splits supporting RRU are much simpler and lower in cost as compared to 7.2b splits supporting O-RRU due to how much functionality has been pushed to the O-RRU or remains in the O-DU. An important aspect of this split is the fronthaul bandwidth requirement gets smaller while using O-RRU. E.g., DL precoding in O-RRU prevents further increased demand in fronthaul bandwidth when the number of MIMO streams are greater than MIMO layers. However, processing and memory requirements are increased in the O-RRU.

If we compare split 7.2x with Split 2, the fronthaul bitrate will achieve extra overhead from scheduling control, synchronization and the Ethernet frame.

Split 7.2x – tradeoffs:

1. Supports “multi-TRP”, Joint Reception, multiple Carrier aggregation and similar features which need low latency.
2. Great multiplexing gains on fronthaul link can be achieved because of centralized or common scheduler.
3. Joint processing on multiple access node is possible (Transmit/receive at same time on different nodes).
4. Most of the L1/L2 functions which need high processing power can be virtualized in this split and then enable efficient resource utilization and optimization from the SMO layer in O-RAN.
5. Key constraint in this approach is high latency stringent requirement because of subframe-level timing interactions between part of PHY layer in CU and part of PHY layer in DUs.
6. Fronthaul interface needs to meet certain QoS to ensure priority for time critical data.

From a DU cost perspective, split 7.2x is more cost effective when compared to DUs supporting split 2 as more functions are shifted to O-RRU in split 7.2x which further enables more virtualization gains. Extremely low latency and higher bandwidth needed for this split as UL/DL fronthaul rates are defined by 3GPP in TR 38.801, Table A-1 as below:

• DL FH bitrate = Sub Carrier*# of Symbol*# of layers*IQ size*2*1000 +MAC info
• UL FH bitrate = Sub Carrier*# of Symbol*# of layers*IQ size*2*1000 +MAC info
• For the same scenario as above using 100 MHz bandwidth and 32 antenna ports the DL bitrate will be 9.8 Gbps and the UL 15.2 Gbps

Split 7.2x - use cases: Scenarios where an ideal fronthaul is possible for URLLC and carrier aggregation, presence of eCPRI and common scheduler for deployment like virtualized local data centers. It supports use cases where efficient resource utilization from multi-RAT and multi-connectivity is needed.

Split 6 (Small Cell Forum)

Split 6 – design and deployment:

The MAC-PHY layer split is being standardized by the Small Cell Forum (SCF) with the nFAPI (network FAPI) interface designed to enable Open RAN. The nFAPI-like interface allows service providers to mix distributed and central units from different vendors to connect to any small cell radio unit (S-RU). All physical processing is handled locally, and the MAC scheduler is centralized. The centralized CU pooling gain provides efficient optimization and resource handling and the fronthaul payload is transport blocks with greatly reduces the fronthaul link bandwidth. Using this split, the fronthaul bitrate will achieve extra overhead from scheduling control, synchronization and the Ethernet frame. Similar to LLS-HLS in split 7.2x, split 6 also has very strict delay requirements as the HARQ and other time critical procedures are centralized in the CU-pool. For 5G use cases, an ideal one-way latency is required and, in the worst case, near ideal in the MAC/PHY split. Any fronthaul delays may reduce the benefits from shorter subframes and wider channel bandwidth, but offers greater advantage in cases of non-ideal transmission conditions and during mobility because the automatic repeat request (ARQ) is centralized in the CU. In this split option, an in-band protocol is necessary to support modulation, multi-antenna processing and PRB allocation due to the separation of the physical layer and the MAC.

Split 6 – tradeoffs:

1. Low and cell load dependent bitrate on the fronthaul link, but fronthaul delay will impact the abilities of shorter subframes and can degrade 5G performance.
2. Split 6 enables multiplexing gains for different UE densities which results in a significantly decreased number of DUs.
3. Centralized scheduling enables 5G enhanced feature support like multi-TRP, low-high band CA/DC, but it comes with a requirement of low latency relation between FEC and MAC as they are separated in this split and it comes with higher scheduling control overhead.
4. In comparison to split 7.2x, split 6 shows lower performance in terms of cell-edge user throughput and average cell throughput.
5. Layers from MAC and above will benefit from enhanced processing in the CU-pool, hence a virtualized platform is limited to L2/L3 only, unlike in option 7.2x where High PHY can be part of virtualized platform.
6. Requires an in-band protocol needed for modulation, multi-antenna processing and PRB allocation.
7. Comes with significant fronthaul bandwidth reduction as compared to split 7.2x.

Other considerations:

UL/DL fronthaul rates are defined by 3GPP in TR 38.801, Table A-1 as below:

• DL FH bitrate = (Peak rate+ signaling rate) *(BW/control signal BW) *(# of layers/# of layers in control signal) *(8/6)
• UL FH bitrate = (Peak rate+ signaling rate) *(BW/control signal BW) *(# of layers/# of layers in control signal) *(6/4)
• For a scenario using 100 MHz bandwidth, 8 layers and 256 QAM modulation the bitrate will be DL 5.6 Gbps and UL 7.1 Gbps

Split 6 – use cases: The ideal use cases are scenarios where only centralized scheduling is required. It is best suited for small cell fem-to-cell like deployment as well as where heterogeneous backhaul and fronthaul with variable performance is available and the cost to cater for different small cells is needed.

Possible options to align the disaggregated RAN with various split options and map with transport/data center

 

Conclusion

Service providers should consider these tradeoffs and their specific use cases when selecting the RAN split option that will best meet their requirements for their 5G deployments. The industry organizations such as 3GPP, the O-RAN Alliance and the Small Cell Forum will continue to develop the specifications and architectures to support diverse 5G use cases.