Sorting Out New-Generation RAN Terminology

This article is about protocols used or proposed for connecting remote radio heads (RRH) or radio units (RU) or whatever you call that part of the network to baseband units (BBU) or data units (DU) or C-RAN, or whatever you have in that other part of the network:

RRH/RU/whatever <-> BBU/DU/C-RAN/whatever

The fact that the sentence is so vague illustrates the need for this article. And the namespace for this topic is already so crowded with redundant terminology from different groups that it is difficult to talk even in general terms without accidentally using some defined term from a spec somewhere. (Just look at the title of this post, for example.)

This article doesn’t have a lot of pictures, to reduce the risk of copyright infringement. I apologize in advance.

And now to climb this Tower of Babel…

Architecture Approaches

Different groups are proposing different RAN architectures, but mostly around a common set of ideas, and using their own, differing terminology for many of the same concepts. In particular, there are these big themes:

  • Break the functionality of the RAN node into two or three parts, according to protocol layers, and define interfaces that allow some of these parts to be cloud-hosted or virtualized. (But remember, one end of the radio network, the “RF” part, is always in the real world and has very strict timing requirements. And that’s what makes radio so much more fun than normal virtualized corporate IT.)
  • Define “functional splits” or “split options”, layer boundaries in the RAN functions that can demarcate boundaries between these parts.
  • Define protocols and APIs that can be used for the RAN parts to communicate across these “splits”.

Here, we will try to summarize some of these approaches and point out their commonalities and differences.


FlexRAN is a RAN node architecture from the Small Cell Forum, mostly pushed by Intel and Cisco. From the Intel web page: “FlexRAN is a reference implementation for cloud enabled wireless access VNFs.” FlexRAN uses FAPI to separate control and processing functions, allowing developers to separate control and DSP functions in each layer.


From the Small Cell Forum web page: “The functional application platform interface (FAPI) is an initiative within the small cell industry to encourage competition and innovation among suppliers of platform hardware, platform software and application software by providing a common API around which suppliers of each component can compete.”

FAPI breaks the eNB into a protocol subsystem and a DSP subsystem, and defines a set of interface points between them.


Along with the FlexRAN, SCF also defines a set of functional splits, described in a table later in this article.


Not to be confused with FlexRAN, FlexCRAN is a proposal for “a unified RRU/BBU architectural framework for C-RAN that can support both a flexible functional split and a FH transport protocol over Ethernet.”


OpenRAN is a RAN node architecture from the OpenRAN consortium. From the OpenRAN web site: “OpenRAN’s mission is to accelerate innovation and commercialization in the RAN domain with multi-vendor interoperable products and solutions that are easy to integrate in the operator’s network and are verified for different deployment scenarios.” OpenRAN attempts to standardize every aspect of the RAN node, including O&M. OpenRAN provides API and protocol definitions and some open source code for reference implementations of some of these interfaces. OpenRAN seems to be the industry favorite at this point, and is seeing POC deployments by several large operators around the world.

OpenRAN breaks the RAN node into three parts:

  • CU – Control Unit
  • DU – Data Unit
  • RU – Radio Unit

OpenRAN uses eCPRI for the DU/RU interface.

Split Options

OpenRAN defines a set of 10 “split options”, possible interface points inside the RAN node that can demarcate the boundaries among these three units. These options are summarized in a table later in this article. 


NG-RAN is the official 3GPP RAN node architecture, an actual part of the LTE and 5GNR specifications, defined in 3GPP 38.401. It breaks the RAN node into a CU and DU, like in OpenRAN, but with the RU functions included in the DU, at least conceptually. The CU is further split into a CU-CP for control and a CU-UP for user traffic.

Functional Splits

NG-RAN also defines their own set of “functional splits”, some of which are equivalent to the “split options” of OpenRAN, but with different names. These are summarized in a table at the end of this article.

F1 interface

F1 is the 3GPP NG-RAN CU/DU interface. It is functionally equivalent to the “NFGI-II” interface in IEEE terminology. It operates at the “Option 1” split, between RRC and PCDP.

From the specification: “The F1 interface provides means for interconnecting a gNB-CU and a gNB-DU of a gNB within an NG-RAN, or for interconnecting a gNB-CU and a gNB-DU of an en-gNB within an E-UTRAN.”

The 3GPP TS 38.47x series of technical specifications define the F1 interface, which has two parts:

  • F1-C – The control side, using the F1AP protocol.
  • F1-U – The data side, using GTP-U to carry user traffic.

NGFI and IEEE 1914.1

IEEE 1914.1 defines a RAN node architecture for 4G and 5G, called NGFI (“Next Generation Fronthaul Network”). From this IEEE web page: “The architecture and requirements for next generation fronthaul networks are specified in this standard. NGFI-I is defined as the next generation fronthaul network with low layer splits in a baseband station. NGFI-II is defined as the next generation fronthaul network with high layer splits in a baseband station. The requirements of fronthaul transport nodes in these networks are also specified.” China Mobile was a big driver of NGFI.

Like OpenRAN, NGFI defines CU/RU/DU architecture:

  • NGFI-I is the interface between the RU and DU. This is a Radio Over Ethernet (RoE) interface, presumably IEEE 1914.3.
  • NGFI-II is the interface between the DU and CU.

IEEE 1914.1 defines these interfaces conceptually, but does not define an actual protocol.

NGFI has yet more names for functional splits, which are given in a table later in this article.


The Open Base Station Architecture Initiative was one of the early efforts at defining a modular RAN node architecture. It has been overtaken by OpenRAN and CPRI and it is no longer relevant.

RoE Protocols

RoE is “Radio over Ethernet’, a class of protocols that are be used on the DU/RU interface, where radio data is transported using UDP/IP packets or raw Ethernet frames over ordinary Ethernet networks, using either copper or fiber.

IEEE 1914.3

A Radio over Ethernet (RoE) protocol defined as part of the IEEE NFGI.


A Radio over Ethernet (RoE) protocol, CPRI over Ethernet, defined by the CPRI industry group. The eCPRI standard also defines a set of “function splits” similar to the “split options” of OpenRAN, with yet more differing terminology. These are given in a table later in this article.


Well, that was a lot of words. What does it all have to do with the price of beans? (What is the practical value of this information?)

Status and Acceptance

So, you are committing development resources to RAN software? Great! Whose architecture do you use? The industry trend appears to be toward OpenRAN, with eCPRI RRHs becoming standard among Chinese OEMs and IEEE 1914.3 not getting much uptake.

Function Splits, Split Options, Etc.

Different standards groups use different names for the functional splits. The answer to “What splits do you support?” is meaningless without more context. Here is a summary to help you find your way:

Layer Boundary Content 3GPP/
RLC Hi/Low   3      
MAC Hi/Low   5 IF1    
MAC/PHY transport blocks 6 IF2 D  
PHY coding/modulation channel bits 7-3 IF3 Id FI1
PHY modulation/beamforming resource elements 7-2 IF4 Iu; IId IF2
PHY beamforming/IFFT resource elements 7-1 IF4.5   IF3
PHYRF time-domain IQ 8 IF5 E IF3b/4

The tower of Babel for RAN functional splits.

The original CPRI used what is now called “Option 8” (3GPP terminology). The industry trend is now for “Option 7-2”, because of a bandwidth savings of 50% or more on the fronthaul interface.