Sign Up

Sign In

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Captcha Click on image to update the captcha.

You must login to ask a question.

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Why most of the telecom companies are interested in RAN 7.2x functional split?

Several options for splitting RAN functions have been proposed by 3GPP. There are 8 splits proposed going from option 1 (higher layer split) to option 8 (lower layer split).  A fully centralized architecture (Option 8) has the benefit of cost reduction due to a fewer number of sites hosting RAN functions but requires high fronthaul capacity to transmit radio signals on fiber. The fronthaul capacity problem resides not only in the constant bit rate used by the legacy fronthaul protocol, namely Common Public Radio Interface (CPRI), but also in the high redundancy present in the transmitted I/Q signals.
Let’s understand it case by case and find out which split works the best for the vendors:

  1. If we pick split 8:

    In split 8 complete PHY is at the DU side and only the physical antennas are at the RU side. This architecture is similar to LTE. With large number of physical antennas in 5G, the bandwidth requirement for fronthaul increases for split 8.

    For an example, for 100 MHz bandwidth & 30 kHz subcarrier spacing the number of samples in single slot (500 u sec) are 61440 ( = 4096*14 + CP samples). So the number of IQs for 16 transmit antennas are 61440 * 16 = 983040. Considering 16 bit I and 16 bit Q format, total number of bits are 31457280 in 500 us. So the data rate required is 31457280 bits/500u = 62.915Gbps, which is 63 Gbps. Now for 64 antennas, data rate between DU and RU goes close to 252 Gbps for a single RU. For multiple RUs and with carrier aggregation this will blow up, which is way too high data rate to handle for fronthaul.
    The other reason is latency requirement. Because of the tight latency requirements the distance between DU and RU can’t be huge.
    Though in this case RU is very simplified and DU-CU is centralized, this option can’t be used because of latency and data rate constraints.

    Split 8 is highly effective in 2G and 3G, where traffic rates are much lower (and therefore processing itself is low to a certain extent) and can be easily done on an x86 server, while allowing operators to use cost-optimized RUs with minimal logic and processing.


  2. If we pick option 6:

    This split is between MAC and PHY. Small cell forum proposed nFAPI interface for option 6 split (

    1. In this split MAC and high PHY communicates at slot level, therefore this split needs slot level timing accuracy.
    2. RU has complete physical layer processing.
    3. MAC scheduling can be centralized.
    4. Data rate requirement between DU and RU is under 10 Gbps.
      With highest MCS, 100 MHz bandwidth, 30 kHz subcarrier spacing, 16 layers multiplexed and with single carrier, the maximum theoretical achievable data rate is around 9.6 Gbps.
    5. Delay in fronthaul can affect the scheduling.
    6. MAC scheduler and FEC are no longer co-located.
      This could be a good option for small cells and for delay sensitive services, but this option is still less preferred because of un co-located MAC scheduler and High PHY.


  3. If we pick option 2:
    This split is between CU and DU (midhaul split) and one of the best option to discuss.

    1. This option is latency tolerent, therefore the distance between CU and DU can be large (upto 40km)
    2. There are less functions at the CU and more functions at the DU. If there is no further split between DU and RU then RRH becomes complicated and costly. Low cost RRU designs are widely preferred.
    3. Data rate requirement is very low in option 2 compared to option 7 and option 8.
    4. Centralization is less here. Most telecom vendors prefer CU & DU to be centralized.
  4. If we pick option 7.2x:
    ORAN 7.2x split has two split options 7.2a split and 7.2b split. This split is between low PHY and high PHY where L2, L3 and most of the L1 processing is centralized at DU, and low PHY and RF processing is performed at RU.
    The only difference between split 7.2a and 7.2b is where the precoding and beamforming is performed.

    There is no difference wrt to uplink in both the splits. In split 7.2b RU is more complicated since it handles precoding and beamforming.

    1. Bandwidth requirement in this split is less than split 8, but more than split 6 and split 2.
      Fronthaul bandwidth depends on number of layers, MCS, system bandwidth and IQ size. It doesn’t depend on the number of physical antennas. Required fronthaul capacity is defined as (IQsize * nLayers * nSubcarriers / symTime)
    2. Fronthaul latency requirements are less than split 8.
    3. RU is simplified compared to option 2 and 6.
    4. One of the best advantage is, open and simple interface protocol. This split makes it easy for different DU and RU vendors to integrate.

So there is a tradeoff between centralization and RU complexity/fronthaul latency. Most of the telecom operators look for a centralized CU-DU and also not a very high data rate link on fronthaul. So ORAN split 7.2x seems to be the best choice. In ORAN 7.2x split fronthaul data rate is not more than 25 Gbps, latencies are not as tight as in option 8 and also most of the BBU is centralized.


  1. Thanks for sharing. This is quite informative. Why have you not considered other ORAN split options?

  2. Thanks. You have put together everything in very simple words.
    Why can’t we have option 2 split and option 7.2x split both?