Skip to main content
Publications lead hero image abstract pattern


Written By:

Joe Madden, Principal Analyst, Mobile Experts

Published: 4 Oct 2018


CTN Issue: September 2018

A note from the editor:

When you read this article you will note that I stole the excellent “Also RAN” quip from the author, Joe Madden who, following on the heels of a big ORAN meeting in August, provides us with an insightful view of the ORAN interoperability effort, comparing it to the OBSAI/CPRI efforts in the 3G era and pointing out some new technical challenges brought about by 5G. As we learned from OBSAI and CPRI these kind of efforts come with tremendous promise of change but also with tremendous obstacles to implementation, both technical and political. Your comments, rebuffs and cheers are welcome as always in the comment section at the bottom of the article.

Alan Gatherer

ORAN Is the Sequel to the CPRI Story

Joe Madden

Joe Madden

Principal Analyst

Mobile Experts

Mobile operators are pushing for an open standard in mobile network architecture. They want to increase the level of competition between vendors, to reduce network cost…and of course, open interfaces between a modular network would enable them to break up the network into pieces, then invite competition to bid for individual modules. This approach was very effective in the PC world, as standard modules created intense competition in the hardware area.

But there’s a major difference between the PC market and the mobile network market. Users generally throw away their PC after a few years, as they upgrade software and features. In telecom, we’re still running 2G and 3G networks throughout most of the world, so the legacy hardware is important. As much as LTE and 5G networks are supposed to be independent of the legacy 2G/3G gear, handovers and spectrum sharing techniques involve proprietary techniques for each of the big vendors.

Figure 1

The working groups for the Open RAN can be confusing. ORAN, xRAN, C-RAN, Also-RAN. It’s getting simpler now. The xRAN Forum merged with C-RAN Alliance, to form the ORAN Alliance. With the merger, the initiative is picking up additional carrier members and several working groups have been formed to examine specific interfaces. Leading global carriers are behind it, including China Mobile, AT&T, Bharti, Deutsche Telekom, NTT DoCoMo, Orange, and several others.

Verizon is one operator that has not joined up. Instead, they have applied direct pressure on their vendors. Verizon has recently succeeded in forcing Ericsson, Nokia, and Samsung to share their proprietary RRH-BBU interfaces. Note that Verizon is NOT taking a standards-based approach, but simply a customer telling its vendors to share their proprietary interfaces with each other.

The situation is eerily familiar, for anybody that was involved with OBSAI and the CPRI Alliance in 2002 and 2003. As the industry revved up for 3G deployment, these organizations had an explicit goal to create an open RRH/BBU interface. They failed because the OEMs didn’t want them to succeed---and even took over the CPRI/OBSAI meetings to ensure a lack of compatibility.

What’s different this time? Siemens, Nortel, Motorola, Alcatel, and Lucent are gone, so the power exercised by the surviving RAN vendors is higher than in 2003, not lower. The legacy equipment is more important than it was in 2003, because now we have three generations of legacy equipment at each base station site, with more complex handover algorithms. In addition, 5G deployment will begin as a Non-Stand Alone (NSA) architecture, which means that the 5G radios will use LTE control channels and link to a 4G core network. Think that’s a good environment for opening up an interface?

Figure 2

Also, 5G beamforming will create new challenges in the radio that have not been anticipated in the market. The guys at the 3GPP committee meetings are very smart, but they can’t have anticipated every nuance of RF propagation for the new beamforming topology.  Over the next 5 years, we expect the major RAN vendors to learn a lot about beamforming, and they’ll be developing proprietary algorithms to coordinate radio performance between multiple base stations. That means that the interface between the RRH and the BBU will need to include the ability to coordinate unknown future communications between multiple radios. Imagine trying to make that work with two different radio vendors on a single baseband unit.

The CPRI and OBSAI working groups of the early 2000s did succeed in one way: They created the CPRI baseband I/Q serial interface that everyone uses for the basic serial data transfer over fiber. Each vendor has a proprietary twist on CPRI, but they all use it because they like to use the CPRI serializer/deserializer chipsets (Serdes chips) that became available to support the entire industry. Staying close to the CPRI format for the main data payload gives the RAN vendor the economy of scale to buy these devices inexpensively.

In that way, my prediction is that the ORAN Alliance will create some useful interface specifications which define the “normal” way to do things, and we’ll get some low-cost semiconductors to support the ORAN interfaces. But I don’t believe that operators will achieve the interoperability that they’re looking for across the entire industry. Instead, we will have radio units that are tailored for interface to each vendor’s legacy 2G/3G/4G hardware, as well as a proprietary suite of 5G coordination algorithms.   

Over the next 5 years, the choice will become clear: The operator can have great performance by sticking with a single RAN vendor and using their proprietary algorithms, or they can save money with an open network. In the PC world, the open ecosystem results in slow performance and the “blue screen of death” on a regular basis. The telecom world won’t accept that. At the end of the day, the ORAN trend will fall short of its lofty goals.

Statements and opinions given in a work published by the IEEE or the IEEE Communications Society are the expressions of the author(s). Responsibility for the content of published articles rests upon the authors(s), not IEEE nor the IEEE Communications Society.

Sign In to Comment