I think One of the key idea about OpenRAN is to split the whole RAN protocol stack into bunch of smaller building blocks and let us to combined it like lego block as we like. I know some of you would be angry about this analogy.. especially if you are a development engineer in this area -:). First, splitting and combining the radio protocol stack is not easy as lego block assembly. Second, we are not allowed to combine those building blocks of radio stack as arbitrarily as Lego block.  Just take my comment as an analogy..

• So many options to split
• How do Option 1 through 8 fit together?
• Option 2 Details
• Option 6 Details
• Option 7 and it's variants
• How do bandwidth and timing constrain the split?
• How do you choose a split for a real deployment?
• Reference
• YouTube

So many options to split

Just sticking with my lego block analagy, the building blocks of radio protocol would be what we call 'layer' like PHY, MAC, RLC etc. The fundamental idea is to split the whole radio protocol stack into every layers with open interfaces to other radio below and above each layer as shown in the left side of the illustration shown below.

Ideally it would be the best to have an open interface for each and every layer (i.e, every options in the picture on the left side) without any technical difficulties. However, in practice (at least as of now, 2022) the industry (especially OpenRAN industry) decided to split the radio stack into three major blocks as shown on the right side and distribute all the layers into these three standard blocks. This is the basic idea on 'Split' in Open RAN industry.

Now the question is how to distribute all the layers in the radio stack into three major blocks that are commonly used in modern cellular deployment (e.g, RRU <--> DU <--> CU).  Would there be any single best way of distribution ? The simple answer is 'there is no best/single answer that fits all the use-cases'. So there would be a huge set of different combinations (distribution). Just a few most commonly used distributions can be illustrated as below.

One of the questions you may have at this point would be 'why only three split ?' or 'why not split at every layer as suggested in 3GPP ?'.  There is no clear answer for this question but we can think of a few possible reasons for it as listed below.

• Cost : Split and develop as standard interface would require additional development cost and if the split require separate hardward, it would generate additional hardware as well.
• Interoperability Issues : Making a split and providing standard interfaces to a component mean that you are making a commitment that each of your component would interoperable to components from any other vendors. But this is not always an easy commitment and also requires additional cost for test and verification. Even after going through all those costly process, there are still possibility to cause unexpected interoperability issues.

When to use which split is up to each use case of the network deployment. You need to determine the split pattern based on some of important characteristics of each split which is well summarized as illustrated below.

NOTE : Some additional labels and comments are added to the original picture based on my email discussion with Amichai Markovitz who helped me to get better understandings on various solit options.

Source : Courtesy of ParallelWireless WhitePaper - 5G NR LOGICAL ARCHITECTURE AND ITS FUNCTIONAL SPLITS

Digging into further details of Case [C] and [D] of above illustration can be illustrated as follows. This illustration is based on eCPRI specification, O-RAN specification, 3GPP specification.

• D, I_D, II_D, E and I_U are the eCPRI split labels shown in the illustration
• 7-2x is the O-RAN-defined lower-layer split within the broader intra-PHY split family
• O-RAN FH identifies the Open Fronthaul interface at that lower-layer boundary

Correction to the PHY illustration: In the uplink column, read the lower "Cyclic Prefix Insertion" block as cyclic-prefix removal and the "IFFT" block above it as FFT. The receive path runs upward from ADC/RF. The picture also shows one processing allocation; it does not capture every O-RU category or optional feature.

I found a well written descriptions for each of these split options from Small Cell Forum Document titled as DARTs An analysis tool for Disaggregated RAN Transport.

Three logical nodes create two internal boundaries: CU-DU and DU-RU. The drawing does not imply that the industry permits only three split options. It shows how a higher-layer boundary and a lower-layer boundary can coexist in one deployment.

The type of the link for splits shown in the illustration above are as folllows.

• The CU is connected to the core network via a backhaul link.
• The CU and DU are connected via a midhaul link.
• The DU and RU are connected via a fronthaul link.

The historical SCF comparison below lists example one-way latency allowances. These values are not universal limits for every implementation; Open Fronthaul timing must be checked against the applicable endpoint timing windows.

Downlink Bandwidth for each of the split is shown below in plot. (NOTE : Just refer to relative bandwidth for each split since the exact number can vary depending on various factors like channel bandwidth, MIMO scheme etc).

Uplink Bandwidth for each of the split is shown below in plot. (NOTE : Just refer to relative bandwidth for each split since the exact number can vary depending on various factors like channel bandwidth, MIMO scheme etc).

How do Option 1 through 8 fit together?

Options 1 through 8 are possible boundaries along the same protocol stack. They are not eight processing stages to connect in sequence. Choosing a boundary determines which functions remain together on each side.

Read the stack from RRC toward RF. As the option number increases, the boundary moves closer to the antenna. More processing can then remain on the central side, while fewer functions remain on the remote side. The split numbering describes the functional alternatives studied in 3GPP TR 38.801; it does not mean that eight interchangeable commercial interfaces exist.

The table follows the layer ordering in the earlier illustration. "Central side" means the side toward RRC; "remote side" means the side toward RF. These terms describe the candidate split, not necessarily the standardized gNB-CU and gNB-DU functions.

Options 1, 2, 4 and 6 divide between protocol layers. Options 3, 5 and 7 divide within a layer, so their detailed function allocation needs further definition. "High" and "Low" identify portions of that layer; they are not additional standardized protocol layers. Option 8 separates baseband PHY processing from the RF side.

Then how do these alternatives fit the CU-DU-RU arrangement? A common combination uses Option 2 for CU-DU and O-RAN 7-2x for DU-RU. In NR, the CU hosts RRC, SDAP and PDCP, while F1 connects it to the DU. The historical table omits SDAP because it follows the earlier split-study diagram.

With this combination, the O-DU contains RLC, MAC and the upper PHY functions. The O-RU contains the lower PHY and RF functions. O-RAN 7-2x is a specific intra-PHY arrangement related to the Option 7 family, not another name for every Option 7 variant. For downlink, Category A O-RUs do not perform precoding, while Category B O-RUs support it.

Moving the boundary changes what crosses the link. A higher-layer interface exchanges protocol data and control, while Option 8 transports time-domain IQ. An intra-PHY split depends on the particular PHY boundary. That is why the split number alone cannot provide a bandwidth or latency budget.

• The eight options describe alternative boundaries. They are not eight mandatory boxes or interfaces in a deployed RAN.
• Multiple boundaries can coexist. Option 2 and 7-2x together divide the stack into CU, DU and RU responsibilities.
• Check the specific interface definition. Functional placement, optional features and transport requirements must agree at both endpoints.

Option 2 Details

Option 2 separates PDCP from RLC. It keeps the upper protocols central while leaving scheduling and radio processing on the distributed side. In the standardized NG-RAN architecture, this becomes the CU-DU separation connected through F1.

Figure 1 separates the CU control and user planes and traces their F1 connections to the DU. The internal E1 link coordinates the CU components. The radio stack stays below the PDCP/RLC boundary, with RF shown separately from the logical DU functions.

Figure 1. Option 2 keeps RRC and PDCP central while RLC, scheduling and PHY processing remain on the distributed side.

The gNB-CU hosts RRC, SDAP and PDCP. The gNB-DU hosts RLC, MAC and PHY. When the CU is further separated, the CU-CP handles RRC and control-plane PDCP, while the CU-UP handles SDAP and user-plane PDCP. F1-C connects the CU-CP to the DU, and F1-U connects the CU-UP to the DU. These are logical responsibilities; they do not require every function to occupy a separate server.

The table separates the two F1 paths. User traffic and control signalling cross the same architectural boundary, but they use different protocols and serve different purposes.

For a downlink data bearer, the CU processes a packet through SDAP and PDCP. F1-U delivers the data to the DU, where RLC prepares it for MAC scheduling and PHY transmission. Uplink data follows the reverse direction. F1-C separately manages the context needed for those bearers. See F1 Interface for setup and message details.

Because MAC remains with PHY on the distributed side, individual scheduling decisions and the radio HARQ loop do not cross F1. This gives Option 2 more transport-delay flexibility than a MAC/PHY split. F1 delay still affects packet delivery, buffering and control procedures; it does not become irrelevant.

Option 2 can coexist with a lower split. For example, an O-DU and O-RU can divide PHY processing through 7-2x beneath the F1 boundary. The two interfaces then solve different parts of the deployment problem.

• Keep the boundary clear. Option 2 divides PDCP and RLC; it does not centralize the MAC scheduler in the CU.
• Budget packet transport. Traffic load, QoS, buffering and control latency matter more than a continuous antenna-IQ sample rate.

Option 6 Details

Option 6 separates MAC from PHY. The central side makes scheduling decisions, while the radio side performs the complete PHY processing. That difference changes both the information carried by the interface and its timing requirements.

Figure 2 shows the information exchanged across a networked MAC/PHY split. The central scheduler sends payload and radio instructions to the remote PHY. The PHY returns decoded uplink data and reception reports. The bottom annotation identifies the transport delay within this scheduling dependency.

Figure 2. Option 6 transports bits and PHY instructions instead of IQ, while scheduling deadlines still cross the network.

The historical split places MAC and all higher layers centrally, with PHY and RF on the remote side. Here, central side does not mean the standardized gNB-CU from Option 2: that CU ends at PDCP. A deployment can use Option 2 above a separate Option 6 boundary.

The interface carries transport-block bits together with configuration, scheduling information and measurements. Downlink data needs instructions such as resource allocation and modulation and coding choices. On uplink, the remote PHY returns decoded data and reception information to the central MAC.

Small Cell Forum provides a concrete interface family for this boundary. FAPI defines the MAC-PHY API, while 5G nFAPI adds network transport around it. SCF calls the resulting split-6 arrangement Open6 and uses the names S-DU and S-RU for its endpoints. FAPI support inside a device alone does not establish a networked split-6 deployment. The SCF Network FAPI overview explains this relationship.

The main transport benefit comes from sending transport-block data instead of frequency-domain IQ. However, fewer payload bits do not remove the scheduling deadline. A scheduling instruction must reach the PHY early enough for the intended transmission, and reception feedback must return in time for MAC operation. Delay variation and endpoint processing therefore belong in the budget.

Compared with 7-2x, Option 6 places more processing at the radio site, including channel coding and decoding. That can reduce fronthaul payload, but central compute no longer directly performs those PHY functions. Compare radio processing capacity, transport timing and the required coordination features together.

• Option 6 keeps the whole PHY remote. Option 7 divides PHY processing between the endpoints.
• Check the networked interface. Compatible nFAPI capabilities and transport timing are needed in addition to a matching split number.

Option 7 and it's variants

Option 7 divides the PHY itself, so the split number alone tells only part of the story. We also need to know which PHY functions remain near the antenna and what data crosses the fronthaul.

The names 7.1, 7.2 and 7.3 here mean the historical 7-1, 7-2 and 7-3 alternatives in 3GPP TR 38.801 v14.0.0, clause 11.1.2.7. That study calls the two sides CU and DU. To avoid confusing them with today's F1-connected gNB-CU and gNB-DU, the diagrams use central side and radio side. O-RAN 7.2x, normally written 7-2x, uses O-DU and O-RU.

Figure 3 compares the downlink allocations. Each row is an alternative, with the fronthaul between the two boxes. The blocks group related functions; they do not show every reference-signal or physical-channel procedure.

Figure 3. Moving from 7.1 toward 7.3 places more PHY processing on the radio side and changes the payload from IQ to encoded data.

Option 7.1: keep most PHY processing central

With 7.1, the radio side performs the conversion between frequency-domain samples and the OFDM waveform. Most PHY processing remains central, including downlink precoding and uplink receiver processing.

Figure 4 traces downlink and uplink through the 7.1 boundary. Each endpoint lists processing stages from top to bottom. The cross-link arrow shows the transported representation, while the radio-side FFT and IFFT convert between frequency-domain IQ and the waveform.

Figure 4. Option 7.1 leaves RE mapping, RE demapping and most PHY processing central; frequency-domain IQ crosses in both directions.

Downlink IFFT and cyclic-prefix addition take place near the radio. Uplink processing starts there with cyclic-prefix removal and FFT. The remaining PHY functions stay central, so frequency-domain IQ crosses the boundary in both directions. The study also allows possible radio-side PRACH filtering, without defining its details.

This allocation leaves the central receiver access to the antenna-domain observations. That supports centralized receiver design, but transporting more antenna streams increases the IQ payload. Moving the FFT alone does not make the required capacity independent of antenna count.

Option 7.2: move more PHY functions to the radio side

Option 7.2 moves additional work beyond the 7.1 boundary. Downlink precoding and resource mapping move to the radio side, while uplink resource demapping also takes place there.

Figure 5 places the downlink precoder and resource mapper on the radio side. Uplink resource demapping moves there as well. The arrows identify the different IQ boundaries in the two directions; coding and decoding remain central.

Figure 5. Historical 7.2 changes both the precoding boundary and the uplink resource-demapping location compared with 7.1.

The central side sends downlink data before precoding expands it toward the antenna ports. On uplink, the radio side removes the CP, runs the FFT and demaps resource elements before forwarding data. Possible pre-filtering was left unspecified in the study. These details matter when comparing implementations that use the same short label.

Figure 6 follows received signals toward the central receiver. Notice where RE demapping moves between the rows. The study permits asymmetric choices, such as uplink 7.1 combined with downlink 7.2.

Figure 6. Historical uplink 7.2 moves RE demapping to the radio side; 7.1 keeps it central.

Option 7.2x: the O-RAN Open Fronthaul split

O-RAN 7-2x defines a specific O-DU to O-RU arrangement. Its allocation differs from historical 7.2, and its Category A and Category B radios differ in their support for downlink precoding.

Figure 7 expands the 7-2x processing paths for Category A, Category B and uplink. The U-Plane arrows carry frequency-domain IQ. Control information and synchronization support those transfers, while the selected radio capability determines where downlink precoding occurs.

Figure 7. O-RAN 7-2x keeps uplink RE demapping in the O-DU and supports different downlink precoding placements.

The O-DU performs downlink coding, modulation and frequency-resource mapping. Category A requires precoding in the O-DU; Category B supports precoding in the O-RU. The O-RU performs IFFT and CP addition. On uplink, it performs CP removal, FFT and applicable digital beamforming. RE demapping and the remaining receiver processing reside in the O-DU. Figure 8 follows these allocations from ETSI TS 103 859 v12.0.1, clause 4.2.

Figure 8 shows the ordinary IQ path, including the compression boundary. The Category B example enables RU precoding; the category indicates capability rather than requiring every supported mode to use that placement.

Figure 8. O-RAN 7-2x retains RE demapping in the O-DU and allows downlink precoding placement to depend on O-RU capability.

For a capacity estimate, count transported streams and allocated resources, then include IQ width, compression and packet overhead. For example, eight transported streams and 64 antenna elements are different quantities. The antenna count alone cannot determine the fronthaul rate.

Option 7.3: transport encoded downlink data

Option 7.3 keeps only the encoder from the PHY on the central side. The radio side performs the remaining PHY processing, so the downlink interface carries encoded data rather than IQ samples.

Figure 9 follows the downlink from the central encoder to the remaining PHY at the radio. The boundary carries encoded data before modulation produces IQ symbols. The notes separate the downlink definition from the independently chosen uplink split.

Figure 9. Option 7.3 centralizes the encoder but leaves the remaining downlink PHY remote; it does not define a mirrored uplink split.

This changes the transport calculation. Count encoded bits instead of multiplying every complex sample by its I and Q widths. Coding rate, scheduled traffic and interface overhead still matter. The radio side now needs more PHY processing than with 7.1 or 7.2.

The historical definition covers downlink only. It does not define a corresponding uplink 7.3 split at the decoder input. A design that transports uplink soft bits needs its own allocation and quantization assumptions; it cannot be inferred by reversing Figure 3.

Also keep 7.1/7.2/7.3 separate from the older 7a/7b/7c labels in transport tables. ITU-T G-series Supplement 66, clause 6 explicitly distinguishes these naming schemes. Matching the actual processing boundary is more reliable than matching a similar-looking label.

• Check both directions. Historical 7.1 and 7.2 describe uplink and downlink allocations; 7.3 is downlink only.
• Distinguish 7.2 from 7-2x. RE mapping, RE demapping and precoding placement are key differences.
• Count the transported representation. Encoded bits, layer streams and antenna-domain IQ need different bandwidth calculations.

How do bandwidth and timing constrain the split?

A split may reduce radio-site processing while increasing the work required from the transport network. Check both data volume and delivery time; a link with spare average capacity can still miss a radio deadline.

For uncompressed time-domain IQ, a useful payload estimate is R = fs * N * 2 * b. Here fs is samples per second, N is the number of transported complex streams, and b is bits per I or Q component. Headers and line overhead are additional.

For example, 122.88 MS/s, four streams and 16-bit components give 15.72864 Gbit/s of IQ payload in one direction. This is a calculated example, not a fixed rate for Option 8. Changing the sampling rate or stream count changes the answer immediately.

For frequency-domain transport, count the resource elements actually sent, the number of streams, the IQ representation and packet overhead. Compression and resource allocation can change the result. Reference signals, control traffic and the chosen handling of unused resources also matter. The earlier downlink and uplink charts illustrate particular assumptions rather than universal rates.

Timing requires a separate budget. Include propagation, serialization, switching, queueing and endpoint processing. Light travels through typical fibre at roughly 200,000 km/s, so 10 km adds about 50 microseconds one way before switching or processing. This physical estimate does not establish an allowable deployment distance.

Open Fronthaul defines transmission and reception windows relative to radio timing. Check the supported endpoint timing parameters and the variation of the complete path. A generic 250-microsecond entry in a comparison table cannot replace that calculation. Clock alignment is another constraint: low packet delay does not prove that the radios share the required time reference.

• State the bandwidth assumptions. Channel bandwidth, stream count, compression and packetization belong beside every rate estimate.
• Budget delay and synchronization separately. Throughput, packet arrival time and clock error measure different limitations.

How do you choose a split for a real deployment?

Start with the transport and radio requirements that the deployment must satisfy. The most centralized arrangement is not automatically the best one, especially when its timing or capacity requirements exceed the available network.

First identify the required carriers, bandwidths, antenna configuration and traffic load. Then identify which functions benefit from sharing compute resources or coordinating across cells. Moving processing away from the site can simplify some operations while increasing transport dependence and the impact of a shared failure.

Next, evaluate the actual routes between sites. Include normal load, competing traffic and protection paths. A backup route can have a different delay even when its nominal capacity matches the primary route. The system must either support that condition or define what service is lost during the change.

Check interoperability at the feature level. The two endpoints need compatible releases, radio capabilities, compression settings, timing behaviour and management procedures. A matching split label is only the beginning of that comparison. Test the intended configuration rather than assuming that support for the interface implies support for every combination.

Finally, measure the complete system under representative radio load. Observe packet loss, late arrivals, clock status, processing utilization and radio performance together. A successful link test cannot establish the signal quality or capacity of the resulting cell.

Keep the decision record explicit: required services, transport assumptions, supported features and measured margins. This makes later changes easier to assess. Adding antennas or another carrier can invalidate the original budget even though the named split remains unchanged.

• Choose from deployment constraints. Centralization benefits must fit the available transport, compute and operational support.
• Validate a configuration, not a label. Interoperability and performance depend on the features enabled at both endpoints.

Reference

The references include the functional-split study overview and the specifications used for the CU-DU and Open Fronthaul explanations.

• Small Cell Forum Network FAPI / Open6 overview : MAC-PHY split, FAPI and nFAPI relationship consulted.
• 3GPP TS 38.472 v18.0.0 and TS 38.474 v17.0.0 : F1 signalling and data transport definitions consulted.
• 3GPP TR 38.801 v14.0.0 : Clauses 11.1.2.2, 11.1.2.6, 11.1.2.7 and summary table 11.1.2.9-1 consulted for Options 2, 6 and the historical intra-PHY alternatives.
• ITU-T G-series Supplement 66 (07/2019) : Clause 6, Figure 6-4 and the adjacent naming caveat consulted for the distinction between 7-1/7-2/7-3 and 7a/7b/7c.
• ITU-T SG15 presentation, slide 8 : Hiroshi Ota - IMT-2020/5G related standardization; split Options 1 through 8 reproduced from 3GPP TR 38.801. The functional-split slide was consulted.
• 3GPP TS 38.401 v19.2.0 : NG-RAN architecture; CU, DU and F1 definitions consulted.
• ETSI TS 103 859 v12.0.1 : O-RAN Open Fronthaul CUS specification; split allocation, O-RU categories and timing-window descriptions consulted. This is the edition used for these explanations, not a claim of the latest edition.
• ParallelWireless WhitePaper - 5G NR LOGICAL ARCHITECTURE AND ITS FUNCTIONAL SPLITS
• New Transport Network Architectures for 5G RAN - Fujitsu Whitepaper
• Overview of O-RAN Fronthaul Specifications (DOCOMO WhitePaper) (2019)
• The Ultimate Guide to Open RAN: Deep Dive Into RU, DU, CU (2020)
• Cloud-RAN functional split for an efficient fronthaul network (2021)
• Why most of the telecom companies are interested in 7.2x split? - telnovet.com (2022)
• Why 7.2x split is the Best Split Option? (2022)

YouTube

• A Deep Dive into Open RAN (YouTube, Feb 2021)