The open RAN technical priorities release 3 was published in March 2023 by Deutsche Telekom, Orange, Telefónica, TIM and Vodafone as part of the open RAN MoU group at the Telecom Infra Project.

My review of the mandatory, highest-priority unanimous requirements will hopefully shed some light on what these network operators consider essential for vendors to focus on this year. More importantly, these technical priorities show how much effort is necessary for the industry to meet market expectations.

For your reference, here is a link to the technical priorities document, the running list of requirements that the open RAN MoU signatories have agreed are their priorities for open RAN architecture. You can follow along using the tabs at the bottom of the Excel sheet: https://telecominfraproject.com/wp-content/uploads/OpenRANTechnicalPriorityDocument-Rel3.xlsx

Scenarios

In this section, the operators regard virtualized DU (distributed unit) and CU (centralized unit) with open front haul on-site as necessary for macro and indoor/outdoor small cell deployments. This indicates that 7.2.x remains the interface of choice, despite recent attempts by other vendors to change its implementation. It also shows that as a first step, they are considering conventionally deploying open RAN, replacing traditional eNode B or gNode B with like-for-like O-RU, DU and CU on-site.

The benefits of resource pooling due to disaggregation and virtualization, enabling either the CU or CU and DU to be centralized, is the highest priority by the majority of operators. Network sharing of O-RU and vDU/CU is also a high priority for most operators.

Security

The security requirements have increased dramatically in this latest version, with the vast majority of the requirements (166 out of 180) considered the highest priority by all the MoU operators. This evolution marks the effort dedicated to the topic over the last 24 months. Open RAN has been openly criticized and accused of lax security, and the O-RAN alliance has dedicated a working group to assess and shore up criticism in that space.

Most of the security concerns of open RAN are either linked to virtualization implementation or just mechanically a result of having more open interfaces, providing more attack surfaces. Open RAN is not inherently more or less secure than 3GPP implementation. The level of security by design necessary to satisfy the criticisms we have seen in the media is not currently implemented by traditional RAN vendors. Having said that, the requirements now spell out exhaustively the level of admission control, authentication, encryption and certification necessary for each interface, for each infrastructure block and their implementation in a cloud-native containerized environment.

O-Cloud Infrastructure (CaaS)

The O-Cloud requirements are focused on ensuring a cloud-native architecture while allowing acceleration hardware whenever necessary. As a result, the accent is put on bare metal or IaaS implementations of Kubernetes, with FPGA, eASIC, and GPU acceleration support and management. The second theme prevalent in O-Cloud's unanimous high-priority requirements is the lifecycle management features indicating a transition from the lab to more mature commercial implementations.

CU and DU requirements

First and foremost, the big 5 unanimously are looking at virtualized and containerized implementations of O-CU/O-DU with both look-aside and inline acceleration (this is contradictory, I assume either one is acceptable). The next requirements are the usual availability, scalability and performance-related requirements in generic legacy RAN systems. All O-RAN interface support is mandatory.

Interestingly, power consumption targets are now spelled out per scenario.

RU requirements

The Radio Units requirements area illustrates the difficulty of creating a commercially viable open RAN solution at scale.

While all operators claim highest urgent priority for a variety of Radio Units with different form factors (2T2R, 2T4R, 4T4R, 8T8R, 32T32R, 64T64R) in a variety of bands (B1, B3, B7, B8, B20, B28B, B32B/B75B, B40, B78 ... ) and with multi-band requirements (B28B+B20+B8, B3+B1, B3+B1+B7), there is no unanimity on ANY of these.

This leaves vendors in a quandary as they'll attempt to find which configurations could satisfy enough volume to make the investments profitable. There are hidden dependencies that need to be spelled out in the requirements; this is where we see the limits of the TIP exercise. Operators cannot, at this stage, select two or three RU vendors for an open RAN deployment, which means that, in principle, they need vendors to support most, if not all, of the bands and configurations they need to deploy in their respective networks.

Since each network is different, it is extremely difficult for a vendor to define the minimum product lineup necessary to satisfy most of the demand. As a result, the volume projections are low, making the vendors only focus on the most popular configurations. While everyone needs 4T4R or 32T32R in the n78 band, having five vendors providing options for these configurations, with none delivering B40 or B32/B75, makes it impossible for operators to select a single vendor and for vendors to aggregate sufficient volume to create a profitable business case for open RAN.

The other RU-related requirements helpfully spell out the power consumption, volume and weight targets for each type of configuration.

Open Front Haul requirements

There are no changes in release 3, which shows the maturity of the interface implementation.

RAN features

The RAN features of the highest priority unanimously required by the five MoU operators remain mostly unchanged and emphasize the need for multi-connectivity. Dual connectivity between 4G and 5G is essential for any Western European operator to contemplate mass deployment of open RAN or replacement of their Chinese RAN vendors. The complexity of advanced features such as Dynamic Spectrum Sharing (DSS) and Carrier Aggregation (CA) are high barriers to entry for new vendors in the space, as they have been developed for years by traditional vendors and require a high level of technological maturity and industrialization.

Near-RT RIC

The requirements for the Near-Real Time RAN Intelligent Controller are extremely ambitious. While they technically would enable better control of a multivendor RAN operation, they are unlikely to succeed in the short to medium term, in my opinion.

SMO and Non-RT RIC

Service Management and Orchestration and Non-Real Time RIC requirements are fairly mature and provide a useful framework for RAN domain automation and lifecycle management. The accent in this release is put on AI/ML support and management, which shows that the operators have been seduced by the promises of the technology, allowing a zero-touch, automated network, relying on historical analysis and predictive algorithms. The requirements are fairly high level, suggesting that the operators still need clearer targets regarding algorithm policy, performance and management.

In conclusion, this document provides useful data on open RAN maturity and priorities. While release 3 shows great progress in many aspects, it still fails to provide sufficient unanimous guidance from a commercial standpoint on the minimum set of end-to-end capabilities a vendor could reasonably develop to be selected for deployment at scale of an end-to-end open RAN solution in Western European networks.

– Patrick Lopez, CEO, {Core Analysis}, a boutique analyst firm specializing at the intersection of clouds and telco networks.