The Big Five European operators who signed the Open RAN MoU have released an Executive Summary of their Technical Priorities – a high level description of their requirements on Open RAN.
In January 2021, four main operators said they had signed an MoU to prioritise Open RAN deployments and foster greater investment in Open RAN technologies. (They were later joined by TIM, brining the MoU signees up to five).
The initial MoU said that they companies would produce a summary of technical requirements within three months, and an action plan within six. Well, we now have the technical requirements, and these would probably point us some way towards the impending action plan.
The companies have released an executive summary, that breaks requirements down into a number of sections. None of them contains any great surprises, although there are perhaps some interesting details, such as those detailing the level of interface support, need for small cells and RAN sharing, and for structural items such as common automation, management and orchestration capabilities.
The requirements show the level to which the tentacles of the Open RAN ecosystem are spreading out from the vision of “make this baseband talk to this radio unit”. We’re seeing definitions related to cloud platform management, to real time AI-ML-enabled optimisations and management, and reaching into making sure element and network management and orchestration systems are also open.
In a section outlining priority deployment scenarios, the paper says that “Macro deployment is the primary target”, but adds that Open RAN small cells are also a target for indoors, with different splits.
The document also says that RAN sharing is a key requirement.
In terms of spectrum support, the operators say, “A clear focus for Open RAN is on 3.4-3.8 GHz and a number of legacy FDD bands, while the interest in millimeter wave is tied to specific country availabilities.” This reflects the European priorities of most of these operators where mmWave spectrum is still some way off. We might expect to see a similar document from some Asian countries or the USA make more of a play around mmWave in the short term.
For interfaces, as you might expect the Open Fronthaul most important but there is also considerable support for the whole range of O-RAN interfaces. The paper says, “Open X2/Xn are a baseline but a fully disaggregated RAN will also require an Open F1 interface for the CU-DU split of gNBs”
“Open E2 and A1 interfaces are also required and shall comply with the O-RAN ALLIANCE specifications to allow multi-vendor / multi0technology RIC deployment mid-term.
“For a unified SMO approach, interoperable O1 interfaces towards all the RAN nodes will be required, while the O2 interface will be needed for the SMO (Service Management & Orchestration) to operate the CNFs running on the O-Cloud infrastructure.”
Deconstructing this a bit, we can see that operators are keen to open up the black box of the radio network, including between the DU-CU, and in the links to management and control. Not only that, but open X2 is a “baseline”, which opens up interfaces to eNodeBs – in theory enabling multi-vendor 4G/5G networks.
In terms of the cloud infrastructure upon which these networks are based, the paper says that the mainstream implementation would be a Kubernetes-based O-Cloud (Open Cloud) platform supporting the necessary RAN software. For the software, a Containerised Network Function (CNF) on Bare Metal is the target solution.
In the “mid-term” the operators would like to see cloud functions such as “the definition of auto-scaling policies for a given node pool, allowing the number of nodes to be scaled automatically according to metrics such as CPU and number of users.”
The O-Cloud platform should also support time-synchronisation (PTP, SyncE, GPS) and Hardware accelerators as well as an Acceleration Abstraction Layer (AAL) that provides a set of Open APIs to CNF applications for offloading the hardware accelerated functions.
The O-CU/ O-DUs will be implemented as CNFs on “power-efficient and reliable GPP CPUs with HW acceleration support for O-DU processing.”
As for the Radio Units, an element where many vRAN software providers have been calling for more innovation, the paper calls for variants for legacy bands, 3.4-3.8 GHz and millimetre wave spectrum, with various transmission modes (number of TRX), output power values and bandwidth requirements depending on frequency bands.
“Single band, dual band or triple band products are required depending on the respective bands. Support for multi-band O-RUs for low and mid bands is important for cost effective deployment. Massive MIMO products (32 and 64 TRX) are demanded primarily in 3.4-3.8 GHz. The main focus is on macro cell products, but small cell products are also needed, both indoor and outdoor.”
The operators also like the look of the RIC, saying it should bring enhancements in terms of programmability, with AI/ML enabled SON and Radio Resource Management applications related to traffic steering, QoS/QoE optimization, RAN slicing and Massive MIMO.
Here, is says “Open E2 and A1 interfaces are the baseline requirements to allow multi-vendor RIC deployment from an early phase”.
Deployments must also be manageable within an automation and Service Management and Orchestration (SMO) framework, and here the operators says, “Automation & SMO Vendors shall adopt a unified data and information model (aligned with O-RAN ALLIANCE, 3GPP, ETSI and ONAP) to increase service management efficiency and vendor independent automation.
“The Service Management and Orchestration framework is a central RAN domain function to manage and control disaggregated multi-vendor RAN Network Functions (NF). The vision is to avoid vendor specific adoption of proprietary EMS (Element Management System) functions by using a unified modelling approach.”
Additionally, “The SMO function requires defined Northbound Interfaces e.g., 3GPP, TM Forum Open API, or a defined functional split for OSS systems.”
