How committed are the major NEPs to open networking, and specifically to developing functions and elements within the RAN?
Nokia has better claims than most to support open RAN. It has been a member of O-RAN Alliance since it formed with the merger of X-RAN and C-RAN Alliance. And of O-RAN’s nine work areas, it leads two projects, contributes to another four and is not involved in three.
By contrast, Huawei is not a member of O-RAN, and Ericsson joined much later than Nokia and has limited its involvement to upper layers of the architeture.
On a webinar yesterday (now available on demand), Nokia CTO Marcus Weldon said that telecoms vendors should take the approach, “Integrate what you have to, open what you can.” If vendors do this, he said, they would be aiming at a “sweet spot” that is “open, but integrated.” This model sees different integrated modules that are connected on open interfaces to other integrated modules.
Weldon characterises Open RAN as being about horizontal openness – with open interfaces enabling functions of the RAN to connect with other functions, for example a radio unit to a baseband, or the constituent parts of a split baseband (DU-CU), or the RIC element to the NMS/orchestrator.
The benefits of Open RAN, as described by Weldon, are that it could bring in a new range of low cost radio players, and it could enable operators to optimise deployment options for specific performance requirements. Simply put, it gives operators choice.
“The RAN was a tightly coupled system between the radio and the baseband, which we are now splitting into the RU, and the baseband into the DU and CU. Broadly you can think of the DU doing the real time L1 and L2 scheduling functions, and the CU doing non real time, higher L2 and L3.
“There is merit in [operators] having more choice in these components, to build it based on a SoC, or an FPGA hardware accelerator and a GPP, or on a GPU, or based on cloud server infrastructure with the associated orchestration and management systems. So that’s the reason to focus on this [RAN] segment.
“In my view the power in 5G networks is getting to the point where the range of performance criteria is different; you need very high performance for some use cases and can make do with consumer level performance for others. And of course you need to scale in and scale out because you want to serve enterprises and industrials. I think that requires a whole host of different configurations of a RAN in 5G, which means you need more choice.”
V for vertical as well as virtual
vRAN is about hardware-software separation, so that RAN software or associated apps from different vendors can be deployed on different hardware types. Weldon said this could be thought of as vertical openness. vRAN disaggregation could be a significant driver of innovation. It enables different architectural options, as well as the addition of new software “apps” onto shared compute platforms in the RAN. Then there’s the potential it offers for alignment with webscale players on edge buildouts.
But with great choice comes great responsibility. How open should the industry go, and how disaggregated? Weldon said that being too open everywhere, the equivalent of breaking the RAN down into microservices that are dynamically assembled into services, is simply too challenging for radio and too costly.
Weldon is also not convinced that a “whitebox” approach in the RAN – the idea that RAN functions can run on COTS hardware – will deliver the Total Cost of Ownership reductions that some propose.
“Generally if you want to achieve the same performance as conventional systems, the capex savings are not there because the capex can be higher for white box versus dedicated silicon to achieve the same performance. And opex is also a question as integrating the many options puts the burden of integration on someone – probably the operator.”
The real driver of disaggregation is reducing time-to-market for specific performance criteria, innovation and the ability to scale in and out.
Conversely, being tightly integrated [ie more closed] might deliver more guaranteed and tested performance but it takes time and, Weldon said, “in some ways is restrictive because there are only certain things you are able to integrate if you are to test for performance.”
Engage brain
Choosing which path to take is a brainer, or rather, it is not a no-brainer.
“There will be some capex reduction as there will be lower cost radios appearing. Or it may be capex is down because you consume GPU as opex, paid over time. Those are changes. But I think the way to think about this is that it is about enabling new use cases and dynamism and agility and simplifying operations.
“I can simplify by being cloud native but I can at the same time incur excess costs by having to do a lot of interoperability testing between the DU, CU, RU vendors. So it’s a complex calculus which is why it’s not a no-brainer. You have to pick your CU-DU-RU set, and cloud strategy, and optimise that cluster, and you will have to make some choices to make sure that (capex and opex) doesn’t go up.”
Making a RIC of it
So where is Nokia aiming for in this “open, but integrated”, sweetspot. Weldon said that the favourites for Nokia are supporting the O-RAN Fronthaul interface and the O-RAN RIC.
He likes O-RAN’s specification based on the 3GPP 7.2 split, where there is enough fibre. But he thinks that to support Massive MIMO in areas with little fibre to the radio unit, you’d need to support all the beam forming at the RU – ie channel estimation and beam forming. That requires the 7.3 interface which is not being specified by O-RAN, and it makes multi-vendor implementations difficult because you need co-ordination of channel weights between the RU and DU.
And he points out that certain functions won’t work across multi-vendor deployments. For example, carrier aggregation needs to share a common baseband, as does DSS.
Another sweet spot for Nokia is the RIC (RAN Intelligent Controller) – which is an optional entity in O-RAN that abstracts the complexity of the hardware “beneath” it in the architecture. The RIC takes a request from an orchestrator, network management system or a slicing app and implements that request to the RAN. It is also the platform where specific control apps or where AI/ML based programmability could be sited, for elements such as SON. An open RIC would be able to control over E2 any vendor’s RAN.
In terms of products, Nokia is working with a number of different splits for 5G vRAN prototypes.
Nokia’s configuration evaluations in the Open RAN
Weldon outlined the splits it has configured and evaluates. The first is the RAP, a “sort of small cell” version with the RU and DU together at the radio access point, where the CU can be centralised. In the midband “because of that complexity of the eCPRI interface” there are different options. Weldon said Nokia has implemented the open interfaces between its own RU to another vendor’s DU and CU or the other way round. It hasn’t yet done the interoperability for 5G (and nor has anyone else, he said), “but we have done this for LTE and the plan now is to do that for 5G”.
Again he said if there are fibre constrained areas “we will have to implement the modified 7.3 interface”, which doesn’t currently support interoperability.
In terms of design, Nokia has implemented two different types for the midband, one based on a GPP processor with an L1 accelerator embedded in it, which Nokia calls vRAN 2.0. And it has also developed a prototype which is a GPU-based solution.
“We are investigating both, the DU with GPUs and GPPs with accelerators and working out which is best for different configurations. We are not just talking, we are doing.”
