| When you start to dig into the details of Open RAN, on paper it very quickly becomes a compelling proposition. The notion of having an open, disaggregated Radio Access Network which, crucially, is fully standardized is hard to ignore. Surely, with such an approach to RAN deployment, there must be CAPEX and OPEX savings aplenty? Cost savings are clearly a key driver for Open RAN, but it’s not the only one. Advocates will also point towards the lack of vendor lock-in, the increased market competition and the embracing of cloud native software design. What is there possibly not to like? |  |
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.