Meeting the Challenge of Making Open RAN Work

In the service provider (SP) networking space, we’re on the cusp of some groundbreaking changes. 5G standalone architectures, ultra-low-latency services, end-to-end network slicing—it’s all exciting, if still in early days. There’s one network transformation, however, that’s well under way that might just represent the biggest change of all: the shift to Open Radio Access Network (ORAN) architectures.

Even as SPs have embraced open IT models and disaggregation in other parts of their environments, the RAN has been stubbornly resistant to change. For understandable reasons: the stringent synchronization and real-time processing requirements of RAN connectivity, and its inherent complexity, meant it was just easier to buy prepackaged, monolithic solutions from the big RAN vendors. So that’s what everyone did.

Today though, ORAN is turning that model on its head. A product of the Open RAN Alliance, ORAN standards define the interfaces to make interoperability possible. These standards allow operators, for the first time, to break away from closed proprietary solutions, disaggregate monolithic RAN functions, and open the door to new startups and third-party innovations in their networks. All of which makes for a very exciting time to work in telecom—but potentially a scary one as well. ORAN brings fundamental changes to the way we design, source, and operate radio networks. And, while these changes promise a long list of benefits, they come with real challenges too.

What are the biggest outstanding question marks around ORAN, and what do SPs need from the rest of the industry to overcome them? We decided to ask SPs themselves, polling operators in various stages of ORAN adoption. Here’s what they had to say.

Setting the Stage for Opening Up the RAN

Before diving into the challenges facing operators deploying ORAN architectures, let’s review how we got here. Why have SPs been so keen to reimagine the RAN anyway? Because, while SPs and their vendors have done well with conventional RAN architectures, this corner of the industry has stayed pretty much the same for years, leaving plenty of room for new ideas and optimizations.

First, there’s just dollars and cents. RAN makes up the largest portion of SP capital expenditures (CapEx), in some cases exceeding 80 % of total network costs. The increase in cell sites and radio types that comes with 5G will likely drive RAN costs even higher. But it’s hard for operators to put much pricing pressure on RAN equipment suppliers when there are only two or three vendors, at most, to choose from. It hasn’t helped that, once an SP made that choice, they’ve been effectively locked into that vendor and its closed, proprietary management interfaces. By opening up the RAN to competition, operators expect costs to come down.

ORAN also enables more deployment flexibility, allowing operators to “customize” the RAN for a particular geography—something that could not be done with traditional models. SPs can now tailor services to align to a specific network design, choosing the elements best suited to the geography and user base of a particular coverage area.

Additionally, opening up the RAN can help improve operators’ visibility into the operation and security of their networks. While prepackaged, monolithic RAN solutions can make deployments simpler, they introduce a “black box” problem when it comes to security and observability. When you can’t see inside the solution, you can’t verify what it’s actually doing. Finally, SPs wanted to accelerate the pace of RAN innovation by encouraging new startups and innovators to start playing in this space alongside incumbents.

Enter Open RAN

For all those reasons, the world’s leading SPs and vendors joined together to form the key industry groups advancing ORAN standards, as well as to standardize open RAN interfaces in the 3GPP 5G specification. (It’s important to note though, ORAN is not the only change happening in the RAN; operators are also embracing virtualized RAN, or vRAN technologies. While these efforts often overlap, they are not the same. vRAN aims to virtualize network software, so it can run on off-the-shelf hardware instead of dedicated appliances, allowing SPs to plan and maintain their networks at a much lower cost than proprietary solutions. ORAN, meanwhile, focuses on splitting up and disaggregating monolithic RAN solutions, so RAN components can be provided by different vendors and controlled via open, standardized interfaces.)

As ORAN technology matures and industry adoption grows, SPs expect to realize significant benefits, including:

• Lower costs as a result of new vendors and competition in this space, as well as the ability to run RAN components on off-the-shelf hardware;
• Flexibility to serve new use cases, such as smaller, tightly defined 5G networks in rural areas and private 5G deployments;
• Reduced vendor lock-in, with the ability to mix and match “best-of-breed” solutions from multiple suppliers; and
• Accelerated innovation, as new vendors and startups have an opportunity to innovate in parts of telco networks that were previously closed off to them.

As the ORAN ecosystem evolves and more new players enter the market, we can expect those advantages will only grow.

Defining ORAN Challenges

Clearly, there’s a lot to look forward to. For SPs though, the journey to an open RAN future is not a simple one. Building a brand-new ORAN architecture from the ground up, and ensuring it works the way it’s supposed to, is a massive undertaking. We recently polled SPs in various stages of ORAN migration to ask about their experiences and the biggest near-term challenges they face as they evolve their networks. Their responses fell into the following four areas.

Maturity: In theory, open standardized interfaces should allow SPs to mix and match best-of-breed RAN solutions. In practice, ensuring multi-vendor interoperability can get enormously complex, especially when standards are not yet 100% complete. SPs worry that, even as vendors adhere to the basic requirements of the standards, they’ll end up creating their own proprietary flavors of ORAN technologies, undermining the benefits of openness. SPs also have lingering questions about RAN disaggregation itself. They need concrete assurance that RANs composed of different vendor components, deployed in disparate locations, can truly meet the demanding synchronization and performance requirements of production networks.

Security risks: Splitting up monolithic RAN technologies into separate components, potentially from different vendors, can spur exciting innovation. But it also inherently expands the RAN threat surface, as there are now more disparate pieces that need to be secured. SPs worry that the cost of adding these new safeguards could erode the ORAN savings they expect to realize. Additionally, while SPs are excited to welcome new vendors into the RAN, they are leery of the level of support they can expect from new startups and smaller vendors in ensuring end-to-end security. They wonder how much of that effort they’ll end up needing to shoulder themselves.

Costs: A disaggregated RAN with multi-vendor components is inherently more complicated to install and integrate than a traditional monolithic solution. As with security, operators worry that newer, smaller entrants into this space won’t be able to meet that challenge themselves. In which case, SPs would need to turn to large system integrators or take on the task themselves—potentially offsetting the cost savings that drove them to consider ORAN in the first place.

Operational readiness: SPs overwhelmingly agree that the multi-vendor openness and broad architectural flexibility that come with ORAN are sorely needed. But they also know that actually using an open RAN—mastering the new operational, automation, and DevOps software models this new architecture entails—represents a major lift for their organizations. To succeed, they will need to add a huge amount of new knowledge and technical capabilities.

Breaking Down Barriers

The good news is that the industry is already coalescing around strategies to address the major challenges SPs cite. Among the most important steps in this effort: developing frameworks and tools for comprehensive testing and assurance of multi-vendor ORAN architectures. Indeed, effectively RAN testing—particularly third-party, objective testing of the interactions among disparate RAN components—is a critical factor in advancing ORAN adoption.

New testing regimes that can thoroughly validate performance and interoperability across all parts of the architecture will be essential to instill confidence in emerging ORAN solutions and accelerate their evolution. That includes testing the various components of ORAN baseband units—radio units (RU), distributed units (DU), centralized units, and the interfaces linking them together—as well as their security, synchronization, conformance with standards, and more.

The need for more robust, comprehensive, and objective testing does require more investment than was typically directed towards testing in the past. But it’s absolutely necessary if SPs want to realize the benefits they expect. Additionally, when operators make the effort to thoroughly and objectively test ORAN implementations—when they test all interfaces in either a wraparound fashion, in aggregate using adjacent blocks, or via full end-to-end testing such as core to user endpoint and back—they end up with more stable, fully functional networks. Which means accelerated time-to-revenue and a quicker journey to seeing ORAN fulfill its promise.

This does, however, represent a significant change for the industry as a whole, and every stakeholder in the ecosystem has a role to play:

• Service providers will need to validate that their multi-vendor ORAN architectures meet performance and security requirements across the full lifecycle of their networks, from deployment to operation to ongoing updates and maintenance.
• Network vendors must take responsibility for ensuring that their solutions and ORAN components adhere to standards and fully support open interfaces and full interoperability.
• System integrators need to build up comprehensive suites of sophisticated new testing capabilities—both for initial integration and deployment, as well as assuring continuous performance and security as the environment changes.
• Hyperscale cloud providers that aim to host cloud-based ORAN and vRAN components will need to show that they understand the demanding synchronization and latency requirements of RAN services. And they’ll need to demonstrate they can meet them with objective, vendor-neutral testing and validation.

Advancing the ORAN Revolution

Few operators would argue that ORAN won’t ultimately become the default for SP networks—it’s just a question of how long it takes the industry to work through the outstanding issues. Some SPs plan to stay on the sidelines in early-stage deployments, letting more aggressive players work out the wrinkles (and shoulder more of the risk). And yet, operators are also intimately familiar with one of the golden rules of emerging technologies: early adopters often have the best chance to stake their claim in the marketplace and win important first-mover advantages.

Whichever approach SPs pursue, whatever pace adoption takes for their business, tomorrow’s mobile networks will ultimately bring the benefits of open RAN architectures to SPs, integrators, and vendors alike. And a renewed commitment to thorough, ongoing validation of performance, security, and interoperability will play a key role in making it happen.

Click here to learn more about ORAN.

Click here to learn more about the 5G NR Release 16 standard by 3GPP.