Cloud-RAN – Fronthaul Perspective

by RanAvital | Sep 4, 2013 5:39:40 AM

In my last blog post, I discussed how mobile operators are going to use a mix of technologies in order to increase capacity coverage while striving to reduce their total costs.

Ceragon’s Heterogeneous Network continuum (3H) underscores the reality that there will not be a single network approach. On one side of the 3H spectrum, denoted as ‘Offload’, a myriad of small cells from a host of vendors. Either Wi-Fi or Femto based, working independently and off-net, over any packet based broadband network, creating a relaxed combination of integration and coordination. You simply do not need all the high requirements you see in LTE / LTE-A for the backhaul.

ran avital - cran 1

The Details (and Implied Cost...)

Conversely, on the other side of the 3H spectrum, Cloud RANs and Distributed Base Stations require tight integration and coordination. This in turn brings to the transport side higher capacity and extremely low latency requirements, on top of increased availability. As a reminder, in these architectures there are semi standard interfaces between the two elements of the base station – the interface between the Radio Unit (RU) and the Digital Unit (RU) is usually based on Common Protocol Radio Interface (CPRI). Though CPRI is a standard interface, you should not expect for inter-operability. This is why ETSI is working on an Open Radio Interface (ORI). Calculating in the elements required to properly transport CPRI, it is easy to see what makes fronthaul costly to build and almost impossible to lease.

We can all agree that a central issue in our business is the cost of function. The more capacity that is needed, the more expensive the network is going to be. Let’s look at a qualitative capacity example:

  • 1 Gbps of Ethernet over fiber will cost you X USD
  • A 2.5 Gbps will cost two times X
  • Dark fiber (practically unlimited capacity) can cost you 10 times X

Similarly, you may apply this logic to see how stringent latency or availability constraints increase the cost of the network. Some requirements simply cannot be met by all of the existing technologies. Even with Fiber, I’m hard pressed to be able to locate a Radio Unit (RU) in Chicago and its Digital Unit (DU) in New York, and this is due to many reasons, and notably originating from the latency perspective. Note that a signal propagation delay of a 15 miles (or 20 km) in a fiber network equals to 100 uSec limiting the use of CPRI to this range give or take.

Fronthaul raises the bar for extreme capacity and latency requirements compared to backhaul. On the other hand, it’s probably lowers the need of QoS and security mechanisms in the transport. So is this what the $100B USD a year question looks like:

Can we make fronthaul costs efficient to facilitate C-RAN for mobile operators with less than 90% fiber coverage to the cell site?

Assuming C-RAN brings significant economic benefits to a mobile operator, we need to understand if this can justify the expected increase in the transport costs.

Ceragon's blueprint for future mobile networks. Ceragon's blueprint for future mobile networks.

The 1st step in striving to make Fronthaul costs efficient is to try and define fronthaul as a service (some may call it managed CPRI service). This will enable us to widen C-RAN’s addressable market. Self-owned fiber is a limited resource for many mobile operators. For the industry to break the linkage between self-owned facilities and C-RAN, vendors and service providers will need to improve the business case for Fronthaul.

Fronthaul as a transport has a stringent SLA requirements. By defining a set of guidelines and a clear definition of interface requirements for C-RAN fronthaul SLA we can achieve the following:

  • Enable sharing scenarios
  • Create a secondary market for C-RAN fronthaul services
  • Provide a smoother deployment environment for operators with self-owned transport facilities

To start the process of formalizing fronthaul as a service, we need to define the following elements:

  • The user interface – to the RU or the DU – usually CPRI however in the future can be Ethernet
  • The existence and the location of an optional CPRI Compress/Decompress Function
  • The existence and the location of an optional CPRI to Ethernet Mapping Function

The reference here is for CPRI but this discussion can be expanded to any RU-DU interface - such as ORI or OBSAI. But for the sake of discussion clarity, let’s assume its CPRI carrying a single LTE sector with 20 MHz in 2X2 configuration, i.e., 2.5 Gbps (to be precise 2,457.6 Mbps denoted CPRI line rate option 3).

With these base building blocks we will try to develop a language and a model that service providers may adopt to trade Fronthaul as a viable service. In my next blog post, I will look at a few different case studies analyzing Fronthaul. Be sure to be on the lookout for that in the coming weeks.

If you have any questions, please feel free to reach out to me at


Holistic HetNet Hauling (3H), Small Cells, ISPs & RSPs


Written by RanAvital