Is it open yet? Closed RAN and other short stories

The dream of an open RAN ecosystem is to broaden the vendor landscape so that service providers can mix and match best-of-breed suppliers with ease. That requires rigorous standardization and the only accepted authority to do that is the O-RAN Alliance. Some would suggest standardization is not required; however, such approaches inevitably imply complex pairwise contracts and interoperability efforts – resulting in a different form of lock-in and counter to the fundamental stated objectives.

Standardization and Closed RAN 2.0

This leads us to a long-overdue clarification of terminology. Since open RAN is highly ambiguous, a more precise and appropriate term is O-RAN compliant system. Similarly, the term legacy is inappropriate. Every major provider in the world today is deploying bespoke solutions and thus, by definition, they are not legacy, rather they are integrated vs open.

Work within the O-RAN Alliance is being developed by subject matter experts spread across nine different Working Groups (WGs) [and a tenth to be added], as shown below. While progress is admirable, specifications are at different levels of maturity. For example, the Fronthaul Control, User and Synchronization Specification, developed by WG4, is at Version 5.0 and considered stable.

O-RAN Alliance Working Groups

However, the O1 SMO data models, O2 cloud management interface and security specifications haven't even been specified yet! For this reason, it is factually correct to say that it is literally impossible to build an end-to-end, standardized O-RAN compliant system today. Could you build a partially compliant system? Yes, but it would have proprietary components (requiring pairwise agreements).

Even when specifications exist, further tuning may be required. For example, the CUS plane specifications cover a broad array of capabilities. Actual deployments require only a subset of those defined. Those subsets are called profiles, specifying things like usage of 3.7-3.98GHz spectrum, 20MHz carriers, dynamic PRACH and so on. More than 100 profiles have been defined to date. That proliferation has resulted in an exercise to collapse those down into a more reasonable and generalized set of 10-20 IOT Profiles. A work in progress.

Finally, while O-RAN is broad in its coverage, 3GPP specifications are even greater in breadth and constantly evolving. It is quite natural then that some 3GPP capabilities haven't been fully analyzed by the O-RAN Alliance. One example is RF sharing.

O-RAN Alliance Specification Status

From this, it should be clear that O-RAN interoperability between vendors today may not be as seamless as one would hope. That is why some operators who have gone through this somewhat painful process have packaged fixed line-ups of components from different vendors and are offering them globally. Iain Morris of Light Reading adroitly referred to them as Closed RAN 2.0.


Above and beyond the need to align with mature specifications, is the requirement parity. Simply put, the set of features or capabilities available with O-RAN compliant products should, minimally, be the same as those deployed today and in the future with incumbent, integrated solutions. Parity applies to features, performance (KPIs), security and other factors. Think of the alternative. Does it make sense to degrade a network for the sole purpose of being open? This is flawed thinking in the extreme, as it could lead to reduced competitiveness at a country or service provider level, or equally disgraceful, an increase in the digital divide if enforced on rural providers as a prerequisite for receiving government funds.

It is true that some use cases do not require full feature parity, such as in private networks, however, one would guess performance and security parity are non-negotiable. Even then, history has shown enterprise feature creep tends to lead towards content like that available on public networks.

Parity is challenging. Nokia received requests for 327 CU/DU features, 35 custom KPIs and 52 new Radio Units (RUs) – to be delivered across multiple 5G platforms, in 2021. Multiplied across ten to 15 years and one can appreciate the breadth of content available on incumbent products today. Parity is not the home of the meek. It requires significant scale.

Infrastructure readiness

The O-RAN Alliance specifications do not mandate virtualized implementations. Traditional or classic solutions with vendor-specific hardware can also be O-RAN compliant. Classic solutions do not require new infrastructure and can be deployed in tandem or adjacent to existing systems today. Conversely, virtualized DU solutions do require new infrastructure with significant capital investment and changes to operational procedures. Few providers have implemented such changes. Those that have, have taken many years to do so.

The only possible exception to this might be virtualized CU or RAN Intelligent Controller (RIC) functions, having less stringent latency demands. They could in principle coexist with existing virtualized core network sites.

Replacement technology vs. new value

All of this leads to the discussion of value. Why are we doing this?

The RIC, enabled by the E2 interface, enables the development of xApps by third-party, independent vendors. Examples include admission control, traffic steering and power consumption optimization. The RIC thus provides net new value. Arguably, the O1 and O2 interfaces also provide new value by enabling vendor-independent network and lifecycle management. The open fronthaul interface, however, offers no new network capabilities. It is a replacement technology that enables a wider choice of vendors, for the purpose of price competition and, in theory, innovation.

Service providers thus need to consider the complexity that comes with multivendor O-RAN solutions with no increase in competitiveness versus working with incumbents on pricing and content, or, looking at net new services enabled by the RIC, O1 and O2 interfaces.

To close, the O-RAN Alliance suite of specifications is progressing well, but with different levels of maturity. Deployment of end-to-end solutions needs to also consider service provider infrastructure readiness, parity with existing integrated product capabilities and whether net new value is introduced.

— Mike Murphy, CTO, Nokia North America

Be the first to post a comment regarding this story.
Sign In