Open RAN Operator Survey
This report presents the results of Heavy Reading’s 2023 Open RAN Operator Survey conducted in January 2023. This is the fourth report in a series of open RAN surveys previously conducted in the fall of 2018, the summer of 2020, and the fall of 2021. The 2023 survey was open only to employees of telecom operators that offer mobile network services.
At the start of the survey, respondents were presented with the following definition:
“Open RAN” refers to the ability to integrate, deploy and operate radio access networks (RANs) using components, subsystems, and software sourced from multiple suppliers and connected over open interfaces. In places, the survey uses the terms “open vRAN” and “vRAN” to also include virtual and cloud native RAN.
OPERATORS’ OPEN RAN OUTLOOK
This section of the report discusses operator demand for open RAN, their motivations, expected deployment timelines, and how they might scale open RAN in the future.
Sentiment and Pace of Open RAN Activity
The first question is designed to help understand how sentiment toward open RAN has changed over the past year, considering better knowledge of the technology, experience from lab and field trials, increased maturity of vendor products, changes in the policy environment, and so on. This question is repeated from the 2021 survey to help identify any shift in sentiment. The results from the 2021 and 2023 surveys are similar.
Just under half (45%) say their company has not changed the pace of its planned deployments versus 54% in fall 2021, as shown in Figure 2. The other half of the response is split between the 20% accelerating their plans (the same as in 2021) and the 35% slowing down (vs. 27% in 2021).
There is an indication that the European cohort is slowing activity more than elsewhere. The regional score for “pace is slower” is as follows: Europe, 43% (n=30); North America, 25% (n=28); and Rest of the World, 36% (n=25).
Given that slightly more than half the survey base has changed pace to some degree, there is clearly some volatility in open RAN activity. There is also a slight leaning toward “slower.” However, this leaning is not pronounced and does not indicate a major change in sentiment. As a group, operators are working at a steady pace. This reflects that open RAN is a major architecture change and is a long-term, multi-year exercise.
Importance of Performance
Why are operators interested in open RAN, and what do they want to achieve by deploying it? The 2023 survey asks specifically about the business benefit, and the response lands conclusively on “improved RAN performance” (41%). This result is substantially ahead of “supply chain diversity” (20%), “simplified management and operations” (16%), and “lower total cost of ownership” (16%), as presented in Figure 3.
These results confirm what operators have related anecdotally: they will not significantly compromise on performance to deploy open RAN. This can be explained by the fact that operators have invested vast sums in tower infrastructure and spectrum and therefore expect RAN equipment to maximize how these assets perform. Even if open RAN equipment was less expensive, it would be a false economy if performance was so significantly lower that it compromised the customer experience, which is largely defined by the RAN coverage and capacity. A focus on performance sets a high bar for open RAN systems.
An implication of this position (untested by the survey) may be that operators hope open RAN can, at some stage, deliver better performance than classic single-vendor integrated RAN. This is a “stretch target” at this stage, but it identifies why open RAN technology is important to pursue: the potential to, ultimately, create better radio networks.
It is also worth a note that the 41% “improved RAN performance” number, while strong, is short of an absolute majority. The other business benefits that score moderately are not unimportant; in practice, open RAN will need to be competitive on all axes. It is also notable that among operators with greater than $5bn in annual revenue, “lower total cost of ownership” scores almost as high (29%) as “improved RAN performance” (33%).
The low score for “greater flexibility and control of feature development” (7%) is a puzzle in the sense that open RAN was pitched as a programmable, software-defined RAN in the early days. Ironically, it is likely that programming an open RAN via the RIC will be a major way in which open RAN performance will be stretched and optimized.
Open RAN Capex Expectations
It is difficult to forecast the size of the open RAN market given the variables in definitions, deployment timing, unit pricing, and so on. To aid in forecasting, the survey asks operator respondents to estimate how much of the overall RAN capex budget their company will allocate to vRAN and open RAN by 2025. Answers are clearly only approximations (at best), and this result is not a forecast but a potentially useful input to market estimates.
Figure 4 shows that, by 2025, a majority of respondents expect more than 10% but less than 20% of their RAN capex will be dedicated to open RAN and vRAN. This gives a midpoint of 15%, which for reference, and entirely by coincidence, aligns closely with Omdia’s market forecast that open vRAN will make up 16% of the RAN equipment market by 2026 (Heavy Reading is a division of Omdia). The numbers are not directly comparable for several reasons, not least because capex is a broader measure than equipment spend; nevertheless, it is noteworthy that they are in the same range.
This result means, as expected, that the majority of RAN technology spending will continue to be on single-vendor integrated solutions over the next three years (only 22% of respondents expect their company to spend more than 20% of RAN capex on open vRAN by 2025). However, it also indicates the market for open vRAN will grow and that, by 2025, it will be on the way to being large enough to support a competitive vendor ecosystem. The outlook for growth beyond 2025 is not tested in the survey, but with a revenue base for suppliers to work off, there is potential for further market growth.
DEPLOYMENT OF OPEN RAN SYSTEMS
The true test of open RAN is commercial deployment in live networks and how well the technology serves customers. This section addresses some key deployment questions.
Maturity of Open RAN Technology
Figure 5 asks operators if they believe open RAN products and architectures are ready for commercial deployment. Approximately a third (36%) say that in terms of overall system performance, open RAN is now “mature for scale deployments,” and another third (37%) say it is “close to maturity.” This is a good indicator that the technology is advancing and is deployable in the right circumstances for a lead cohort of operators.
However, it also means a majority of respondents (approximately two-thirds) do not yet think open RAN is ready to scale. This aligns with anecdotal operator commentary and underlines that further development is required to meet mass-market needs.
Heavy Reading’s 2021 survey asked a very similar question, and it is interesting to compare how sentiment has evolved on this issue. Figure 6 compares the responses for “mature for scale deployments” in 2021 and 2023 (data was collected 17 months apart) and shows a positive change in sentiment. For example, the response for “overall system performance” moves from 18% to 36% and “security robustness” from 9% to 29%. These results are strong indicators of industry progress.
Barriers to Deployment
What is stopping operators from deploying open RAN at large scale? The survey asks respondents to select the single biggest barrier from a list of options. As shown in Figure 7, there is really no standout challenge, with responses widely distributed.
“Security robustness” scores slightly above the other options, with 23% identifying it as the biggest challenge. However, for operators with revenues of over $1bn, none selected security as the biggest challenge. In later questions, the survey shows larger operators are very concerned about security in open RAN; this result simply shows it is not their biggest concern. The major challenge for larger operators was spread among the other options, with “SI” slightly ahead at 24%.
Open RAN for 4G or 5G?
Will open vRAN primarily be used in 4G or 5G networks? Or both? The response to this question, shown in Figure 8, is useful but does not resolve the issue. In hindsight, this may not even be the right question.
The largest group (43%) expects to run the technology for both 4G and 5G. Over the medium and long term, Heavy Reading’s view is that this makes sense for a host of reasons (operational efficiency, spectrum refarming, automation and tooling, etc.). For many operators, a single integrated open RAN system per site is an attractive solution.
It is interesting, then, that a solid 32% anticipate open vRAN for 5G-only networks; this could refer to situations where 5G is a greenfield or is overlaid using open RAN-compatible equipment on an existing RAN. For example, this is the case with some operators deploying open RAN-compatible systems for 5G in the US and Japan and in some European trial networks. The 20% score for 4G-only could perhaps be explained by operators without 5G spectrum or those focusing open vRAN on regions and markets where 4G remains dominant in the subscriber base. Many middle-income and emerging markets are in this position.
More broadly, Heavy Reading believes operators will develop open vRAN as a platform technology that is somewhat independent of the “G cycle” and can be deployed to support multiple air interface generations in multiple configurations, according to the time and location in question. This level of flexibility is a key potential advantage of open vRAN.
Vendor Selection Preferences
Open RAN, almost by definition, implies some change in how operators select vendors, how they manage vendor relationships, and which vendors they choose. Figure 9 shows operators are likely to pursue a range of vendor selection models. A small, but not insignificant, 16% expect to continue with the “same vendor(s) as our traditional RAN deployment.” This business-as-usual approach probably reflects the effort needed to switch vendors and the continuity benefits of working with trusted suppliers.
On the other hand, open RAN is an opportunity to work with new suppliers. The earlier question on capex established that open RAN would only be a part of an operator’s overall RAN investment in 2025 and will be deployed alongside single-vendor integrated RAN systems. Therefore, it makes sense that a majority of respondents will introduce a new vendor, in some form, for the open RAN part of their network.
It is interesting that the biggest group expects to use “a new single vendor that is open RAN-compliant” (31%). This is probably the simplest way to introduce open RAN because it is close to the existing RAN operating model and means a single supplier would be responsible for SI, performance, maintenance, and so on.
About a quarter (27%) anticipate a “multi-vendor environment, consisting of new vendors along with traditional RAN vendors.” Among operators with more than $5bn in annual revenue, this is the most popular option, with a score of 48%. This model is more challenging but is already deployed in several markets and provides good flexibility. For example, an operator could introduce a new radio unit (RU) or DU vendor to an existing RAN footprint where it needs to increase competition or add features or a new spectrum band. Or it could use a RIC from an alternative vendor in association with a traditional base station vendor.
About the same number (24%) expect a “multi-vendor environment, consisting of the traditional RAN vendors.” At first look, this might raise an eyebrow, but it is well-known several of the larger incumbent vendors are involved in open RAN and support, or will support, open interfaces in their products. The ability to source a multi-vendor solution from these established suppliers gives operators another vector of flexibility.
Open RAN Systems Integration
The responsibility for SI is a decisive issue for open RAN. To what extent should the operator manage this in-house? Or if it outsources, what is the right type of partner? Figure 10 asks, for initial open RAN deployments, how operators plan to bridge the gap between SI and rollout. The results are very consistent with a similarly worded question in the 2021 survey.
With a score of 51%, “systems integrators partnered with an open RAN vendor” is the lead choice. This is more than double any other option and is therefore conclusive. In disaggregated telecom networking, a technology vendor often leads the project, perhaps with support from closely partnered SIs. This is a familiar model in the mobile core, for example, and has the advantage that a lead vendor is responsible for the overall system performance, including stack integration. This may not be a “true” disaggregated network model, but it is a practical, tested approach to deployment. The survey indicates, for the second year running, that this model is likely to prevail in open RAN.
A related issue, not tested in the survey but nevertheless important, is the SI challenge once the initial open RAN deployment is done. RAN lifecycles are long (equipment in the field for five to seven years is not unusual), and RAN systems need to be maintained and updated over time. When different parts of the system are sourced from different vendors, even a single software update to one part of the system needs to be tested and verified as safe to deploy by the operator or its integrator. This is likely to again favor a master integrator in Heavy Reading’s view.
Cloud Infrastructure for vDU and vCU
Will open RAN baseband functions (RU and CU) be deployed as physical network functions (PNFs), virtualized network functions (VNFs), or cloud native network functions (CNFs)? On an industrywide basis, it will likely be a mixture of all three. The extent to which open RAN is deployed on cloud infrastructure is a key consideration that drives important decisions on the hardware and software platform strategy. It is, however, a complex area with dependencies on silicon, server hardware, cloud software, applications software, and operations.
Figure 11 provides some guidance on the uptake of cloud native RAN. It asks operators to estimate what percentage of their DU and CU functions will be deployed as CNFs within the next two years.
There is a clear lead answer, with 46% of respondents selecting the 25–49% option. The two-year timeframe is quite tight and perhaps explains why a majority think less than half their vCU and vDU functions will be cloud native—presumably, the remainder is some mix of VNF and PNF.
RAN ARCHITECTURE
The survey asks several implementation- and architecture-related questions.
Lower Layer Split and Massive MIMO
Massive MIMO plays an important role in 5G mid-band systems by increasing cell capacity and cell edge performance. This technology requires deep R&D expertise to implement. A particular challenge in open RAN systems is that massive MIMO requires close coordination between the RU and DU, which drives a stringent performance requirement on the fronthaul transport link and very well-defined interoperability between O-RAN RU (O-RU) and O-RAN DU (O-DU) vendors.
There is debate about the optimal split between O-DU and O-RU functions and, in particular, where the lower Layer 1 function should reside. Many open RAN advocates argue that the standard RU-DU split over a 7.2b fronthaul interface is adequate to support massive MIMO and is well-standardized and well-supported by vendors. There are now several open RAN suppliers of massive MIMO-capable O-DUs and O-RUs and several examples of this multi-vendor architecture in commercial operation.
Others argue that better uplink performance can be achieved if some of the Layer 1 function is moved to the RU so that the RU can make faster decisions on how best to schedule transmissions—particularly uplink transmissions. This is important because in mid-band systems, improving uplink performance extends the effective range of the cell, which in turn has implications for cell density, RAN economics, and the customer experience. There is not yet an open fronthaul profile for this architecture specified by the O-RAN Alliance. However, there is a new split option called ULPI in development.
The survey seeks to understand how important the ULPI profile is for open RAN massive MIMO deployments. With the proviso that it is a complicated topic, the results shown in Figure 12 have something for both sides of the debate. Broadly speaking, operator respondents are positive about ULPI and would like to see it specified to improve the performance of massive MIMO. About a third (36%) believe they will wait for the ULPI specification before they deploy massive MIMO for open RAN.
Close to half (47%) would like ULPI but will deploy massive MIMO using the existing 7.2b split in the meantime. In combination with the 7% that believe 7.2b “meets our needs,” this indicates the majority of respondents plan to move ahead with deployment before ULPI is available.
The decision, for operators, appears to be largely linked to timing when they need to deploy massive MIMO. For suppliers, ULPI may mean they require updated silicon, updated software, and multiple rounds of further interoperability testing. The ULPI ecosystem will follow specification completion, targeted for November 2023.
Centralized or Distributed RAN
Moving on to a wider RAN architecture discussion, the survey asks operators for their preferred open RAN deployment topology. The vast majority of RAN deployments to date are distributed RANs (D-RANs), where the baseband is deployed at the cell site close to the radio and antenna. However, there is a view that centralized RAN (C-RAN) will become more popular over time and that because open RAN (especially with vRAN) is more “cloud-like,” it may be more likely to be deployed as C-RAN.
As shown in Figure 13, the results indicate that open RANs will continue to be distributed, as is the case today, but with a trend toward centralization. The top two results both reference the DU deployed at the site. It is interesting, however, that a large number (38%) expect to centralize Layer 3 (the CU) because this indicates open RAN is likely to be associated with a change in RAN architecture in some cases. (It is true that centralized CU is already used in non-open RAN 5G networks, but deployments of this sort are limited.) In this context, it might be significant that the two largest commercial greenfield open RAN networks in the world both use centralized CU, and one uses centralized DU.
The 37% that expect to distribute both DU and CU mirror the dominant RAN architecture today. This is a tried and tested model. It makes sense many operators expect to also use this architecture for open RAN.
A smaller 22% expect to go to a fully centralized model for both DU and CU. This is a more radical departure from the classic RAN architecture and has major implications for the fronthaul transport network. There are already some high profile examples of open RAN operators that use this architecture. As a note of caution, however, operators have been slow to adopt C-RAN (although, again, there are examples of traditional C-RAN in operation). This survey result may give an overly optimistic picture of how fast it will be deployed for open RAN.
Open RAN for Private 5G
Previous versions of this survey have investigated open RAN for private 5G enterprise networks. There is a view that private networks provide a good entry point for open RAN because they have a differentiated feature set that open RAN can be configured to deliver, because enterprise is often a less demanding use case, or because there is less risk to the performance of the macro-area public network.
Enterprises are not expected to consume open RAN themselves. Instead, operators (as well as vendors and systems integrators) may use open RAN to create integrated RAN systems for private networks. Operators have had a choice of systems for private network technology from several vendors. This year’s survey sought an update on how operators think open RAN will play in their private network strategy.
The overall finding is that operators see an important role for open RAN in private 5G networks, but the position is nuanced. In Figure 14, close to a third of respondents (31%) expect open RAN to be “a critical part of our private 5G offer.” This is a strong endorsement but still someway short of a majority. It indicates there is some reservation about how well the technology and use case are currently matched. The specificity of 5G (the private network ecosystem is primarily 4G today) and the two-year timeframe perhaps caused respondents to be somewhat cautious. It is also the case that non-open RAN systems dominate the private mobile network market today.
A further 40% say, “open RAN will play an important role.” This is a key group of respondents because it indicates that open RAN can be part of a private network design—even if it is not “critical.” Enterprises do not consume open RAN directly, and most operators currently have vendor-integrated solutions in their offer. But this result does keep the door open to using the technology in the future for parts of the systems—essentially an optimistic, pragmatic view.
It is worth a note that larger operators are slightly more cautious. Of the 21 respondents at companies with more than $5bn in annual revenue, a larger 29% say “probably, but only a limited role.” This group is still positive overall, but this caution adds useful context.
THE SMO FRAMEWORK AND RIC
The O-RAN architecture introduces the SMO Framework and RIC functions. More specifically, the SMO Framework offers an approach to managing RAN functions and radio parameters. The RIC is part of the SMO.
The SMO Framework
A question on operator priorities for the SMO Framework reveals a couple of interesting findings, as shown in Figure 15. The first is that the largest number of respondents (30%) are prioritizing RAN data exposure. An issue in classic single-vendor RAN is that analytics data is not delivered in a standard format and may incur a vendor licensing charge, making it harder to use, for example, in RAN optimization tools. Access to this data, using a standard data model, is an important step toward open, programmatic RAN management and automation. It is logical that this should be a high priority.
It is interesting, however, that the score for RAN data exposure drops to 19% among operators with more than $5bn in annual revenue, perhaps indicating larger operators have less of a challenge accessing and normalizing RAN data feeds and/or that they already have license agreements with vendors. The highest priority SMO capability for these larger operators is instead to identify “open cloud deployment and orchestration – O2 interface” (33%). This can be interpreted to mean that large operators are focused on working to establish a cloud infrastructure platform to enable open vRAN.
Heavy Reading’s anecdotal information is that creating an open cloud infrastructure platform is a high priority because it gives much greater flexibility to evolve the RAN in the future, and this should ultimately result in lower opex, better performance, and greater agility.
After a couple of false starts in the mobile core network, many operators now stress the importance of an operational cloud platform as essential to long-term success. The same thinking is very likely at play in open vRAN.
In the SMO Framework, the RIC consists of the near-real-time (near-RT) RIC and the non-real-time (non-RT) RIC, both of which host applications that can make changes to RAN functions. Non-RT apps are known as rApps and operate over time cycles of greater than 1 second. Near-RT apps are known as xApps and operate over time cycles of between 10ms and 1 second. The RIC does not exist in the 3GPP RAN architecture. It is a new capability that has attracted great interest as a way to programmatically control the RAN.
RIC deployment will occur either at the same time as an open RAN deployment or sometime afterward. The survey asks when operators expect to deploy a RIC in a live commercial network. Figure 16 shows that for the majority, RIC deployment is still two years (42%) or three-plus years (12%) away, but a lead cohort says it will deploy sooner. A lead 10% claim a deployment is already underway (this may refer to small-scale pilots or deployments that are in process), and a solid 27% are expecting to deploy within a year.
The “already underway” and “within 1 year” cohorts are significantly larger than Heavy Reading had anticipated. Being overly optimistic about deployment timelines is common in surveys (individuals involved in new network technologies are naturally enthusiastic about deployment prospects), but even with that caveat, this result appears ambitious. Perhaps a useful way to view the result, therefore, is in terms of sentiment; on that measure, it is a solid indication that RIC deployment will gather pace over the next two to three years.
xApps and rApps
The survey asks two questions about how operators would source rApps and xApps. The response is amalgamated in Figure 17. Respondents were asked to select “all that apply” in each case and selected, on average, 1.5 answers each.
One finding is that there is virtually no difference between rApp and xApp sourcing strategies. This lack of difference might be a surprise because xApps are “closer to the radio” in the sense that they are able to make faster, fine-grained changes to the DU and CU and thus might be more likely to be sourced from, or licensed by, the CU/DU vendor or a closely associated partner. In practice, xApps is complicated and immature technology, and it is possibly too soon for a mass of survey respondents to give a well-informed answer.
Another finding is that the scores for planning to get rApps and xApps “from third-party vendors” are relatively high (42% and 46%, respectively). This shows that operators expect to source apps from a competitive, multi-vendor market and do not want to be limited to a small number of pre-approved apps from the RIC or DU/CU vendor. After all, the intent of the SMO Framework is to offer open, interoperable interfaces to RAN functions, making this, in theory, a reasonable result. In practice, x/rApps provided by the RIC vendor and x/rApps provided by third parties are likely to be deployed.
The high scores for open-source rApps and xApps are a puzzle. Currently, Heavy Reading is aware of open-source RIC platform software that is widely used (e.g., by vendors to create RIC products), but not of open-source rApp or xApp software. It is possible respondents were confused by the question, or this result is an expression of the desire to use open-source apps—should they at some point exist in sufficient quality and number.
OPEN RAN SECURITY PERSPECTIVES
Open RAN introduces new interfaces, which potentially increases the “attack surface” of the RAN. Where virtualization is part of the deployment, it also introduces cloud infrastructure, which again introduces new threats. In the 5G era, in which more services—and more critical services—are connected to the network, this has clear implications. In some markets, there are additional security considerations linked to geopolitics and industrial policy.
Comparing Open RAN and Single-vendor RAN Security
There is debate about how the security of open RAN systems compares to single-vendor integrated RAN systems. The survey shows (Figure 18) that a larger number (45%) think “open RAN will be harder to secure than single-vendor RAN” compared to those that think “open RAN will be more secure due to greater visibility and ability to harden each layer” (32%). This is not a huge delta, but given the importance of security, neither is it insignificant. It is also notable that among larger operators (revenue >$1bn), “harder to secure” jumps to 59%, versus 38% for smaller operators (<$1bn annual revenue).
The survey also shows that 19% think “open RAN security will be equivalent to single-vendor RAN solutions.” If this is combined with the 32% that think open RAN can be more secure, then approximately half the respondent base (51%) can be said to be somewhat confident about the security outlook for open RAN.
In general, Heavy Reading observes that concern about security is well-placed because of the critical nature of mobile network infrastructure. Security concerns do not, however, preclude deployment. Instead, they highlight how important it is to design open RAN systems that are reliable and dependable over time. This is not a simple task, but it is an essential one.
Perceptions of Security Risk
The perceived security risks in the O-RAN architecture are widely distributed. The survey asks respondents to select the top security risk from a list of options. Figure 19 shows the response falls in a tight range of between 11% and 21%. In other words, there is not a standout issue but a broad range of challenges. This is consistent with the many government-instigated reports (e.g., by US, EU, and UK institutions) on open RAN security. The implication is that open RAN security needs to be addressed systematically before the industry can move forward.
In Heavy Reading’s view, combining best practice security from the telecom domain with best practices from the cloud domain will provide a route forward. In many cases, operators are already operating 5G core networks and critical IT systems (which are more security sensitive than RAN) on cloud infrastructure; there is no clear security reason why RAN cannot follow a similar course.
2020 Open RAN Operator Survey: Measuring Progress and Looking Ahead to Open RAN at Scale
Principal Analyst, Heavy Reading