Well, it turns out quite a lot, depending on which side of the fence you may happen to be on. Just for the record, in the interest of customer relations, Mpirical are sat firmly on the fence on this one…
Before looking at the potential issues, it’s worth spending a little time on exactly what Open RAN is (for those who don’t know already) and also what Open RAN can potentially offer.
For some mobile service providers, the notion of a small handful of RAN equipment vendors effectively having control of the majority of the 5G RAN market is not an appealing prospect. Fear of vendor lock-in is a concern shared by many service providers, a concern which Open RAN seeks to avoid by creating a RAN ecosystem that features software and hardware components that are fully interoperable and can hence be mixed and matched from different vendors. Interestingly, the focus is not purely 5G related; Open RAN is designed to be applicable to all of the generations of mobile technology. The key objectives associated with Open RAN are summarized as follows:
There are, of course, challenges related to Open RAN which in some cases, are yet to be resolved. Figure 2 shows a selection of the potential pitfalls.
Open RAN will be only be successful if widespread adoption takes place. Although this is a rather obvious statement, it is a fact that full investment (beyond financial) in the Open RAN concept will have to take place, both in the service provider and vendor space. However, there is still scepticism as to whether Open RAN will ultimately deliver on its promise, or whether Open RAN will end up being a slightly more open architecture but still suffering from vendor lock in.
The reality of a multi-vendor RAN deployment invariably sees a lot of deployment complexity, particularly at the systems integration stage but also very much at the MANO (Management and Orchestration) level. Critics argue that a single vendor solution has the advantage of all components interworking “out of the box”, whereas Open RAN could mean a very long deployment timeline whilst vendor integration is addressed.
Although subscriber security is, if anything, enhanced with the introduction of a disaggregated RAN (security functions such as signalling and user plane encryption can be conducted closer to the core, which is more secure), the very nature of introducing more functional elements into the RAN which are physically separate increases the number of points of vulnerability into the network. This extends to the O&M traffic that each of the RAN elements will need to exchange with the network.
Both the 3GPP and O-RAN alliance operate a FRANS (Fair, Reasonable and Non Discriminatory) policy when it comes to patents that are held by contributors to those respective organizations. So, patents are held on aspects of the 3GPP and O-RAN Alliance specifications, but the holders of those patents agree that it’s mutually beneficial for everyone if their patents are licensed with a FRANS approach. The concern in this area is political; if trade relations between China and the West dramatically deteriorate, is there a possibility that the patents held by Chinese manufacturers and service providers may be withdrawn from the FRANS licensing arrangement?
The early deployments of Open RAN have received a lot of scrutiny in terms of the potential CAPEX and OPEX saving that were (or were not) made. Fundamentally, there are costs to deploying a new RAN which are unavoidable; manual labour, civils, construction, spectrum licensing, etc. Therefore, CAPEX reductions can only go so far and on top of this, as a rough figure, CAPEX spend for RAN contributes to around 20% (arguably) of a service provider’s overall CAPEX, hence the cost savings are inherently limited. When OPEX is considered, the situation is possibly worse; although CAPEX saving may be made, system integration of a multi-vendor RAN leads to operational complexity, which will not help to improve OPEX.
Although Open RAN was supposed to prevent vendor lock in, there is a risk that because Open RAN deployments are so complicated from an integration perspective, service providers may be forced to buy Open RAN “blueprints” from service providers or vendors that already have integration experience. Therefore, the service provider ends up purchasing a pre-prescribed list of vendor solutions, which is contrary to the choosing of best of breed that’s cited as one of the Open RAN advantages.
I wonder if Open RAN is a panacea for all of the service provider’s RAN woes, or whether it has the potential to lead to a host of new issues. If the latter is the case, any cost savings will soon begin to dwindle. Despite the single vendor approach having its drawbacks, it’s a tried and tested model which mobile service providers are more than familiar with. For some, Open RAN just won’t have the appeal until the CAPEX and OPEX savings are fully proven.
When this article was originally published, Open RAN deployment was very limited. Five year on, there’s real-world implementations so it’s worth revisiting the challenges we raised and seeing how they’ve played out.
OpenRAN has moved beyond its initial trials into large commercial programs. In the US, AT&T is working towards a fully Open RAN network under a multi-year deal with Ericsson. It has passed the halfway point of its radio replacement program, and more than half its network traffic now runs on open-capable hardware. In Europe, Vodafone has deployed Open RAN across thousands of UK sites and chose Samsung as its main Open RAN partner for a large rollout in Germany.
Our previous concern about multi-vendor integration has proved well-founded. Operators have tended to manage the complexity by relying on a lead vendor or a small number of trusted partners, rather than mixing and matching freely. There has been progress, though. AT&T has completed an Open RAN call on its commercial network using Ericsson basebands with third-party radios from 1Finity.
We suggested that operators might end up buying pre-integrated “blueprints” rather than choosing best-of-breed components. That is largely what happened. The biggest deployments are led by established vendors, and the RAN market has stayed highly concentrated among a few large suppliers. Open RAN has expanded the architecture more than it has opened the market, although the open interfaces do give operators more options for future sourcing than they have had previously.
The savings element remains the most contested part of the debate. Real deployments suggest that the economics are more complicated than early advocates claimed, which matches our aforementioned caution. Unavoidable costs such as site work, civils and spectrum haven’t gone away, and integration still adds operational overhead.
The most visible benefit so far hasn’t been cost or vendor diversity. It's the programmability of the RAN. With the implementation of the RIC (RAN Intelligent Controller), its apps (rApps and xApps) are now being used in live networks. As an example, Rakuten Mobile has deployed third-party rApps on its RIC across its entire Japanese network, using them for predictive maintenance, mobility enhancement and traffic optimisation.
If you require further training on 5G, why not explore our courses page or contact us directly.
If you would like to get a taste of our on-demand telecoms training, sign up to our 48-hour Free Trial. Gain access to our Learning Portal, 4 course modules and our learning tools NetX, NetXpert and NetXplore.
Blog reviewed and updated: September 2026