Deploy and maintain an Open RAN network

Open radio access networks offer advantages in locating network functions of proprietary RANs. Automation and orchestration let telecom networks do what computing networks have done for years.

Open radio access networks (Open RAN) significantly enhance how mobile networks operate. The telecom industry, and especially the RAN segment, is several years behind the innovation curve due to tightly integrated hardware and software from just a few vendors. Open RAN can change that.

The IT industry has long benefited from a software-centric approach and transitioned to an open model where software companies compete and innovate. Now the telecom industry is going through the same transformation in many aspects of the network, but especially in the RAN. This change began with the deployment of networks such as Rakuten Mobile in Japan and the DISH Open RAN 5G network in the US. Mobile network operators (MNOs) throughout the world, including many brownfield networks, are now trialing and deploying Open RAN.

Open RAN is part of a shift in deploying and maintaining software defined networks (SDNs) and automation. SDN approaches associated with virtualization and vendor neutrality offer new ways to manage the mobile network. Orchestration and automation play an important role in demonstrating the potential of Open RAN by reducing human intervention in maintaining the network. Long-term transformations are also occurring in the RAN, including how Open RAN will enable new 5G use cases and the overall deployment of 5G networks.

Deploying Open RAN hardware
Traditional RAN deployments had all intelligence located inside an environmentally conditioned cabinet designed for an ASIC server appliance called a baseband unit (BBU). BBUs process Layer 1, Layer 2 and Layer 3 IP protocol stack functions before sending the processed signals over the backhaul interface to the operators’ 4G evolved packet core (EPC). As Figure 1 shows, such transport uses conventional network methods such as multiprotocol label switching (MPLS). This method has been in place since the advent of 1G and 2G networks.

Today, two trends allow virtualization in Open RAN networks. One comes from wide availability of low-latency transport options with higher bandwidth from fiber-optic transport networks. The second is a concept that was widely adopted in IT platforms but made few strides into RAN until now: network functions virtualization (NFV). With NFV, key processing elements and intelligence previously managed by the BBU can now disaggregate and move to an edge cloud data center away from the cell site. Cloud-native containerization followed NFV as another virtualization tool.

Enter Open RAN
Open RAN is a set of standards that specify interoperability between RAN hardware and software elements from different vendors. While enabling this interoperability, Open RAN has incorporated virtualization, using NFV and containers that let RAN workloads operate as virtual network functions (VNFs) and containerized network functions (CNFs), which run on commercial off the shelf (COTS) servers. This development eliminates ASIC-based appliances, enabling BBUs to run on conventional servers that meet the memory and processing requirements demanded by RAN functions.

In traditional RAN deployments, software and hardware of a single vendor are tightly coupled using proprietary interfaces, as shown in Figure 2. Any mix of components of different companies risks incompatibility, although radio and basebands served the same purpose.

The radios connect to the baseband over proprietary interfaces using the Common Public Radio Interface (CPRI) standard. Each manufacturer implemented its own CPRI interface version, thus making radios and basebands of different companies incompatible. When 3GPP standardized 4G LTE, the overall network architecture became flatter. An expectation arose that, to enable optimal subscriber experience, base stations would use the X2 interface to communicate with each other to handle resource allocation.

This initiative didn’t gain traction. Traditional RAN companies created lock-in by implementing their own flavors of the X2 interface, creating difficulty for operators to use more than one RAN company’s products in a given location.

Operators became locked into deploying equipment from a single RAN company per geographic area. Assume company A’s products were deployed in the north of a city or state, whereas company B’s was deployed in the south. Here are some of the hurdles that exist even with geographical diversity:

• Spares rationalization was impossible: the operator had to keep a pool of spare BBUs for both company A and company B, and similarly a pool of radio spares for all bands for both company A and company B.
• Border Performance between two RAN companies: because the handovers should use the X2 interface, which were not interoperable, operators instead had to use the S1 interface. This increased signaling, adding delay and ultimately negatively affecting the performance. Operators mitigated this limitation by planning the RAN borders so that they would overlap in areas of low traffic and reduced mobility such as natural geographical borders, such as a mountain, river or forest. It would affect fewer people if the borders crossed in a forest rather than a densely populated city, for example.
• Operations: supporting two networks increases the number of people needed to operate the networks. Mobile operators needed a technician specialized and trained for company A’s RAN software and hardware. This same person sometimes lacked the skill and knowledge to troubleshoot the same issues on company B’s equipment. Hence the operator needed to have specialized pools of resources trained to operate both networks.
• Support: operators pay an annual fee to each RAN vendor to support its hardware and software. This fee is set partly on the number of cells, radios, and nodes deployed in its geographic area. Often times, the benefits of scale did not apply to support fees as the infrastructure was divided into multiple vendors.
• Swap: should the operator decide to modernize or swap its network and change from one vendor to another in a given geographical area, the operator must rip and replace the existing hardware. That requires a truck roll and a tower climb to remove existing radios and install new hardware to do essentially the same thing. While costly, this effort would not yield new functionality or benefits.

Open specifications
The O-RAN Alliance designed its specifications to solve these hurdles and let operators benefit from best-of-breed hardware and software that are interoperable as illustrated in Figure 3.

The operator can now choose a radio based on its own technical and or procurement criteria. Open RAN also opens the door to custom radio hardware adapted to the operator’s needs. For example, assume that an operator had spectrum assets in 3GPP band 3 (1800 MHz FDD), band 7 (2600 MHz FDD) and band 1 (2100 MHz FDD). They could design each cell site with three remote radio units (RRUs) one for each band multiplied by the number of sectors, typically three per site. So, a total of nine radios would be required.

With Open RAN, the operator could ask an Open RAN radio manufacturer to design and build a radio with all three bands as shown in Figure 4. This can dramatically reduce the costs operators pay for tower rental space and power consumption while reducing load on tower structures.

This practice also lets the operator have hardware tailored to its engineering principles. For example, if vendor A only had in its portfolio a radio that can transmit 120 W, but the operator would like a radio capable of transmitting 160 W, the operator can now search for other vendors who support their preferred power levels. Open RAN introduces competition that pushes companies to better support network operator needs.

This competitive scenario is also available for baseband hardware, where an operator can choose a hardware server platform that fits its individual needs. Because these are COTS systems, there may also be synergy with hardware that its IT department uses reducing the number of spares and the tapping into a trained pool of management and troubleshooting experts.
For the software, an operator can choose from an array of different vendors, but there is no limitation, as O-RAN standards have provisions for software of different providers to interoperate and all interfaces are open and standardized.

Transport
3GPP standardized BBU disaggregation with a central unit (CU)-distributed unit (DU) split. The non-real time functions of the CU can be virtualized in a cloud or central data center, while the real-time functions provided by the DU reside in an edge cloud server or installed at the cell site. So, the functions inside the IP stack that before resided within the BBU and hence had very little delay from the RU to the BBU will now be flexible and more cost effectively deployed in the edge cloud data center using a low latency transport medium.

Real-time functions such as forward error correction (FEC) that now reside in the DU need to work properly and without additional delay or reduction in quality of service. The initial solution to this delay involves replacing the BBU with DU on site. See Figure 5.

Because DUs run on COTS servers in cell sites, they connect through a new interface called midhaul. Midhaul interfaces operate with a relaxed latency requirement (compared to fronthaul but more strict than backhaul), typically in the order of 50 ms round-trip time (RTT). Many DUs on the cell sites can connect to a CU using COTS servers and also reside in a centralized data center. The CU will connect to the mobile core over a backhaul link.

Open RAN can expand to deployments that use low-latency fiber in densely populated cities and cover small site-to-site distances. The DUs can operate in an edge cloud data center that typically manages a small number of cell sites covering an area where latency will not exceed 150 µs to 200 µs RTT from air interface (or input port of radio) to the edge cloud data center. These low-latency figures can be obtained by typically using dark fiber but any Layer 2 (LLS Ethernet/eCPRI) connection that fulfills the latency budget between the nodes could allow full virtualization. This configuration is commonly called split 7.2x.

The fully virtualized deployment model, shown in Figure 6, provides rationalization and pooling of processing resources in a data center. It also expands the use of edge computing, improving scalability and enables slicing for a service-oriented 5G network. In rural/suburban sites where latency is higher and fiber isn’t available to support a less dense population, the operator may consider co-located deployment of RU/DU or an integrated CU/DU into the same form factor.

These extra fiber fronthaul/backhaul requirements, depending upon fiber availability, could offset Open RAN cost savings. More standardized hardware for both the edge cloud server (DU) and standardized data center hardware (CU) can lead to operational benefits overall for operators. Furthermore, there are clear operational cost savings including energy savings and cell site space savings when compared to a legacy RAN approach.

Open RAN network automation
Through automation, Open RAN can reduce human intervention in network operations. A traditional nationwide wireless network might require several thousand people to run while a fully virtualized network could require just hundreds. Network orchestration can reduce this effort.
Automation and orchestration are different, but related concepts. In general, automation refers to automating a single task. Examples include:

• Automatically restarting a software procedure or hardware card when a fault or exception occurs.
• Automatically sending via FTP a new software instance that needs to be loaded into a baseband processor.

Open RAN brings to the telecom concepts already ingrained in the IT industry. Open RAN introduced orchestration to the RAN.

Orchestration is gaining momentum. In MPLS networks, for example, orchestration lets routers coordinate to direct traffic more efficiently along a hub and spoke framework, minimizing congestion and bottlenecks. Orchestration in the IT world is the automated configuration, management, coordination of computer systems, applications, and services.

These are only some examples of automation that still require different levels of human supervision and intervention. By aggregating multiple automation routines across clustered applications, multiple data centers, clouds, and applications with complex dependencies, we can orchestrate processes ensuring that single tasks occur in proper order and eliminate human intervention.

Manually intensive legacy RAN functions include:

• Lifecycle management of baseband hardware and software: upgrading, applying patches, monitoring and cleanup.
• Auto integration: configuring and commissioning of new hardware added to the network. Orchestration can provision or deploy servers, assign storage capacity, create virtual machines and manage networking, among other tasks.
• Self-healing: locating faults and executing troubleshooting routines to bring a service back to working state.
• Capacity optimization: scaling capacity dynamically by spawning new CU/DU instances as capacity demands shift. This can be achieved by deploying spare servers located in a data center pool, assigning storage, creating virtual machines when capacity scales up and then decommissioning these logical entities when capacity recedes, freeing up server resources for other tasks.

Automation also reduces human error. Orchestration supports a DevOps approach helping operations teams deploy applications more quickly, securely and accurately.

Accelerating 5G use cases
The foundation of many 5G use cases is a concept called network slicing, where the user plane operates separately from the control plane traffic in relevant network domains (i.e., RAN, core, transport) to offer multiple virtual services with different latency, performance and other characteristics.

This de-coupling of user and control planes also happens to be one of the fundamental tenets in SDN and NFV. This has led to a natural adoption of end-to-end network slices based on data paths being already separated in a virtualized environment.

It is possible to partition the same physical network to support different access types and service-level agreements for different use cases and this ability has existed for a long time. Network slicing is, however, required to meet all the demands placed on 5G networks, such as very low latency and drastically increased bandwidth. Network slicing must be designed on fully virtualized networks to accelerate and facilitate the adoption of innovative 5G use cases.

Examples of software defined Network (SDN) concepts accelerating 5G use case adoption include:

• • The application of SDN in wireless networks, and associated cost savings, could accelerate applications for 5G technology in industrial internet of things (IIoT) given that industrial IoT use cases (e.g., factory automation) do not have a pre-existing large number of consumers to provide an economic underpinning for data provision. Cost-effective deployment through virtualized networks may help drive uptake.
  • At Altiostar, we believe that harnessing virtualization could improve the viability of IIoT. This use case, in a factory/automated driving setting, typically leverages 5G fast connectivity, allied to the collection of extremely large quantities of data from sensors and real-time data analysis. Given the proximity of the data to the processing location, applications reside in the same data center as the CU. For example, we believe this will improve latency/speed required for use case quality of service.
  • For use cases such as autonomous vehicles, where the volume of data collected and sent over the network could potentially be extremely large, the capability to scale capacity up or down dynamically via orchestration is advantageous.

The task of identifying and applying use cases and network slicing belongs to the whole industry. Open RAN provides the foundation that will allow the strict latency and capacity targets to be achieved by providing a virtualized and scalable network via orchestration framework.

Conclusion
Virtualization in enterprise data centers perfected the technology and demonstrated the value of a software-centric and cloud-native approach to networks. Now the mobile telecom industry is realizing the potential of this industry shift, taking an open and virtualized approach to the RAN. Incorporating SDN as an approach, Open RAN has reinvented how operators deploy and maintain their networks. This approach, which is associated with virtualization and open interfaces, offers new and more efficient ways to manage the mobile network. This in turn leads to reduced human intervention in maintaining the network, while enabling increased orchestration and automation, accelerating new 5G use cases.

André Silva Biscoto is a network consultant for Altiostar’s Product Go-To-Market team. He has over 20 years of experience in mobile network engineering in the US and Latin America, being responsible for 5G and LTE systems engineering, product management, legacy network design and optimization, consulting and sales support. At Altiostar he assists operators in adoption of open virtualized radio access networks (Open vRAN).