Open RAN    

 

 

 

Where To Split

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

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 <--> DC <--> 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, ID,HD,E,IU are the splits defined by eCPRI specification
  • 7.2x is 3GPP based split
  • O-RAN FH is O-RAN based split

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.

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 latency requirement for each of the split options are as follows.

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).

Why 7.2 split ?

As mentioned above, there are so many different options for the point of the split. I don't think there is any consensus that are accepted in the whole industry. However, at least it seems that the industry is getting closer to a consensus in terms of DU and RU(RRU) separation. That is 7.2 split.

Why 7.2 split ?  For this, I would like to quote from an article from telnovet : Why most of the telecom companies are interested in 7.2x split?. (The author kindly allowed me to share his article here. I am sharing only about 7.2 split part of his article, but you can get further details for other options in his original writing).

  • 7.2x 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. Following is a list of characteristics (nature) of 7.2x split.
  • 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 doesnt depend on the number of physical antennas. Required fronthaul capacity is defined as (IQsize * nLayers * nSubcarriers / symTime)
  • Fronthaul latency requirements are less than split 8.
  • RU is simplified compared to option 2 and 6.
  • 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.

Reference

YouTube