Acentury

Part 1: How 5G/O-RAN and cloud native architectures introduce new complexities for testing labs

Mobile networks are rapidly becoming more like IT networks and Mobile Network Operators will need to adapt their testing and deployment processes accordingly. Technologies like 5G and Open RAN present fundamentally new challenges and traditional testing approaches are no longer enough. In this multi-part blog series, 'Replicate your 5G Open RAN Network and Enable Zero-touch Test Orchestration', we will share how a Mirror Lab can enable end-to-end network testing that includes everything from virtualized network functions and RAN elements to RF channel performance and the subscriber device itself. By replicating the production network in the lab, Mobile Operators save testing time, improve test coverage, and simplify deployment at scale. The blog series will take a closer look at the testing domain and system architectures and explore why the tools and processes formerly done in 4G cannot be done in the new 5G/Open RAN world without introducing more risk. The series will conclude with a set of mirror lab use cases that could be used to help manage new testing demands and requirements.

Open RAN technologies enable several vendors of hardware and software to mix and match together in ways that was not possible before. This introduces enormous financial benefits for carriers who no longer rely on a select few vendors for a fully integrated stack of technology. However, promoting interoperability between different suppliers means that operators must test for several more combinations of suppliers and technology together, which can be a significant challenge.

The following illustration is a dramatic oversimplification, but the left side of this image shows traditional network architectures in older generations. Networks were purpose-built, highly vertically integrated, and supplied by a single vendor. Operators had multiple vendors within the same networks but the interface points were minimal and tightly controlled between only a handful of players in the game. The advent of 5G and Open RAN introduced a lot of new suppliers into the industry, including Mavinir, Red Hat, Wind River and VMware to name a few. Commercial off-the-shelf hardware suppliers are also joining the party, including HP and Dell, and not to be left out, the hyperscale cloud platforms providers: Azure, AWS and Google Cloud.

5G network performance gains are well documented, but they too introduce new testing challenges for operators:

• Additional complexity. 5G networks are far more complex compared to previous generations, introducing more components, more frequency bands, and new technologies such as massive MIMO and beamforming.

• Virtualized and containerized network functions. With network functions moving to software on servers in a data centre, this introduces new testing challenges as operators need to deal with new software architectures.

• Performance. 5G networks are expected to deliver higher speeds, lower latency, and more reliability. With a greater volume of components and new software architectures to support them, this presents even greater challenges for operators.

• Security. 5G networks also introduce new security risks with potential vulnerabilities in virtualized network functions, increased vectors of attack from a significantly larger pool of connected devices, and the adoption of cloud services.

These latest trends mean that the typical mobile network is more complicated now than it has ever been, and this has very real implications for testing lab strategies and operations. Let's take a closer look at the system architectures to understand further.

The typical 4G network architecture is comprised of an enhanced packet core with a BBU and RU. It's a straightforward architecture with only one real deployment question: where to locate the BBU equipment. Is it centralized with the with the core or is it distributed with the RF Equipment? In the world of 5G, the equipment suppliers are different, the BBU function is disaggregated, and its functions can exist in a variety of places on different hardware. These variations are called functional splits and there are eight major ones (where some are a lot more common than others). Different operator considerations can impact which ones are used. Some of the driving factors that can influence usage are specific operator requirements and constraints for a given field application, including latency, QOS, traffic loads, the available bandwidth for things like backhaul/midhaul/fronthaul, and the cost of scale of the bits in the network. It is also common to combine multiple splits into the same network to address different network site density and service offering requirements.

This diagram shows an example of three different functional splits operated by the same 5G core. Compared to 4G network architectures, this clearly illustrates the complexity involved with a 5G network architecture. In the next part of our blog series we will review current RAN testing and deployment tools, and explore new methodologies and tools to help address these new challenges.

Interested in learning more about how LAMTA can augment your wireless lab? Take a look at LAMTA's features, contact us directly, or have us contact you.