Getting on the OpenRAN train: Go/No-Go

OpenRAN is the telecom industry’s most recent buzz word, although it’s been around for a while, there’s a convergence of events from geo-political moves, the dawn of 5G and cost-pressure on operators leading to a timely importance of this technology in the telecommunications ecosystem.

I will not use this blog to explain OpenRAN or it’s architecture, as we already have one here. What I would like to talk about, if you are looking at getting on the OpenRAN train, is how you should do it.

Is it time to jump on the OpenRAN train?

As with many disruptive “products” you always have the early adopters who are willing to embrace the benefits along with the growth pains and others prefer to wait for it to be mature enough and move carefully.

It needs to be said though: OpenRAN is not mature yet.

The above means that the full benefits are not available for grabs just yet however ignoring it is probably not the best move. Those outside the OpenRAN train will have to make a much bigger effort to enter it than those already inside or even those looking around in the train station. The reason is that we are not just talking about another RAN product, we’re talking about a new RAN philosophy, and as this train gains more and more momentum it will become increasingly difficult to get inside.

So far, the RAN has been a black box, delivered end-to-end (from controller to the base-band and radio) and besides the already complex planning, parameterization and optimization you had one vendor to go to when something went wrong. Now imagine a scenario in which you dis-aggregate from 1 vendor into a mesh of multiple vendors across software and hardware for each of the OpenRAN components (CU Hardware, CU Software, DU Hardware, DU Software, RU Hardware and OSS Hardware/Software).

To make it more interesting, the hardware is no longer a proprietary black box, it will be a general purpose server or a Virtual Machine, this means that we are getting a point where radio engineers have to deal with IT, and vice versa. A few years ago, this las statement would have made the universe collapse. From the skillset point of view, the need of Agile DevOps, IT and Cloud experience in a mobile environment is a difficult concept to grasp for the majority, and there’s no way to do it without… how to put it: actually, doing it.

While some bigger operators are already deploying OpenRAN as a way to test it and at the same time incentivise the ecosystem, we have the example of Rakuten as the first cloud mobile network based on OpenRAN and we have other cases where operators are taking a peek.

Other private sectors considering private 5G networks are also looking for OpenRAN as a way to decrease costs considerably and having more customized solutions.

After you answer, “should you be jumping on the OpenRAN train?” the next question is: how far do you want to go?

So, how far do you want to go?

In most of the cases, the first gap that we have seen in operators about to engage into OpenRAN is the definition of the final end-game objective.

To make it easier, let me break it down into a few options:

1. Is the objective to get ready for OpenRAN, gain some knowledge, maybe even run some field trials?
2. Is the objective to deploy OpenRAN in a few locations?
3. Is the objective to actually swap part or all of the network or deploy the new 5G layer with OpenRAN?

Another option is to decide it is not time to engage in it yet and I assume that the legacy RAN will adapt to OpenRAN prices and/or keep a better performance (at this stage, no one knows).

Once the objective is agreed, then the strategy unfolds very naturally as it will be easier to know how much effort needs to be put into the OpenRAN program. There is a trade-off between how much you put into OpenRAN and how much you get out of it. Especially at this stage, a lot of the roadmap is being defined by those investing in the technology and working with the vendors.

An OpenRAN program, being a new concept, will be transversal to the different network domains and on top of it, a new domain will come in: IT. Since resources are not just laying around, ideally a program should start by defining some important streams and appoint people to dedicate time to it. Depending on the objective, the amount of dedication will have to increase or even become full time for some resources.

OpenRAN program will require staff to be appointed to each of these streams:

• A program head – someone that can drive the program according to the objective you’ve set without losing sight of the OpenRAN philosophy.
• Testing – a test lab will require at least 1 person of each network domain, being Radio and IT the ones that will be spending more time in it
• Design – OpenRAN offers many options on the design, this team will require mostly RF, Transport and IT skill sets to select the best design options for the expected deployment scenarios. The defined designs will be tested by the Testing team.
• Procurement/sourcing – interacting with the design team, the procurement/sourcing will be looking at cost aspects of the selected designs and contractual concerns from SLA to responsibility matrix definition (getting from 1 RAN à 1 vendor to 1 RAN à N vendors).
• Management and SMO– IT, DevOps, NMS and RF mix of skill sets will be required to define what the Service Management and Orchestration (SMO) will look like. ONAP[1] and ZSM[2] will offer additional information on this space.
• Operations – the team that will take all of the above and think about how to make it operational from staff to network. This will encompass Network Operations, HR, domain team managers, etc…

On the external side, it is important to start looking at vendors that are providing OpenRAN solutions. Typically, you will find a base-band (CU+DU) software vendor that is already integrated with a specific IT platform (it makes it easier but keep this in mind as a potential problem later on). Ideally having a few options on the table would be the best scenario, while on the Radio Side, there are many options for ORAN Radios (O-Rus) and ideally it would be best to select the ones that are already advanced in the frequency combinations and technologies (2G, 3G, 4G, 5G) that you’re interested in and willing to integrate with your selected baseband provider.

There is a variety of vendors in the O-RAN Alliance membership that you can look for: https://www.o-ran.org/membership.

Finally, you may need support to find a prime integrator to bring of all of the above together. It could be one of the base-band vendors, the operator or a 3^rd party company.

Avoid getting back to the future

I am obviously a fan of this movie trilogy, however I’m not talking about time travel. If you noticed above, I spoke about “not losing sight of the OpenRAN philosophy”.

One of the big advantages of OpenRAN is vendor independency, which means, you will not have to be locked-in into one vendor for all the components of the RAN. As any open solution, the interfaces between each component will have to be opened as well. This means that if a new vendor with a better radio shows up in the market, you will not have to replace the entire chain, as the radio with its opened front-haul (OpenRAN version of CPRI/eCPRI) will easily integrate with the existing base-band.

Same thing on the Hardware side, if a new server with better performance is available, you should be able to move your base-band software into it. If we advance into VMs or Containers then we’re talking about spawning a new base-band out of thin air in your horizontal cloud.

Now, we have been around long enough to know that at the end of the day, business and markets and costs will shape reality. And, as requirements arise and price pressure puts constraints on R&D, it is likely that OpenRAN vendors will join efforts or buy each other into a few options in the market where suddenly these open interfaces are not that opened anymore. Just like CPRI was supposed to be opened.

This is why it is key to avoid lock-ins now, and from the requirements perspective, if Operators really want to have vendor in-dependency, this is the time to ensure that any selected vendor is really Opened or has a clear roadmap to openness. Due to lack of maturity, it is expected that some interfaces are not fully developed to the point of plug-n-play and it’s unlikely to find in the market available options that are fully independent between hardware and software.

However, as the technology matures, it is in the hands of the operators to accept another vendor or vendor combination lock-in. As RAN moves to a fully opened, cloudified technology, with single orchestrator and zero-touch provisioning, the benefits will only be achieved if in the end if we get to an independent, diverse and competing ecosystem where different vendors fight for a role in your network as long as they fit the open interfaces and open solutions.

This can very well co-exist with incumbent non-opened RAN vendors, and the future mobile network may end up being a mix of both. Or incumbent RAN vendors will end up offering opened solutions as well, who knows?

Well, the coming 12 to 18 months will determine a lot of this and the really good part about new technologies is that your strategy may actually make a difference.

Need help defining your strategy

Aspire has been testing and integrating OpenRAN solutions for a while now and with a past on R&D of legacy radio networks we’re very well positioned to support you on your strategy, evaluating your goals and point you in the right direction. If you’d like to know more, I’m happy to answer any of your questions, just drop me an e-mail at: luis.isidoro@aspiretechnolgy.com.

[1] ONAP – Open Network Automation Platform – www.onap.org

[2] ZSM – ETSI Zero Touch network and Service Management – https://www.etsi.org/technologies/zero-touch-network-service-management