Comparing Red Hat OpenShift models for Cloud RAN deployments

Telecommunications service providers have varying requirements for the products and technology that go into their networks. A typical large service provider access network comprises thousands, if not tens of thousands of devices. However, with many nodes constrained by a limited power and real estate budget, this access network is a delicate mix of scale and device-specific requirements, such as smaller form factor, lower power consumption, and possible environmental hardening.

Moving up the stack to pre-aggregation, aggregation, and core networks, the number of devices decreases but scale, capacity, port density, and high availability requirements become more demanding. Since aggregation and core networks are inherently designed with datacenters and point-of-presence locations with (likely) ample space and power, the considerations for size and power consumption of these devices become secondary to that of scale, capacity, and high availability.

---

Read other articles in this series:

• The road to Cloud RAN from 1G to 5G
• 20 radio access network (RAN) terms to know
• What is Open RAN?
• What does Red Hat OpenShift have to do with Cloud RAN?

---

These fundamental service provider network characteristics correlate with Cloud radio access network (Cloud RAN) as well: Cell sites are the provider's access network, whereas far edge, edge, regional, and national datacenters can be equated with pre-aggregation, aggregation, and core networks. A horizontal cloud platform, such as Red Hat OpenShift, across the mobile network must be adaptable to these requirements, for example, by having a leaner, smaller form-factor cloud platform at the cell sites that becomes increasingly flexible, scalable, and redundant as it moves deeper into the mobile provider network to the edge or a regional or national datacenter.

In the article 20 radio access network (RAN) terms to know, we established that the Red Hat OpenShift Container Platform offers a horizontal cloud platform across the entire mobile network. Like networking devices, the cloud-native applications that build the mobile network have diverse requirements of scale, capacity, and CPU/memory resources. Therefore, OpenShift clusters hosting these functions can't be one-size-fits-all. They must offer flexibility to be a genuinely horizontally scalable cloud platform to support cell sites, far edge, edge, and regional/national datacenter workloads. OpenShift is offered in the following form factors:

• Multinode OpenShift
• Three-node compact OpenShift
• Single-node OpenShift (SNO)

Image

While each of these offers the full capabilities and features of OpenShift (with minor exceptions discussed later), the major difference between these is the supportable number of worker nodes, and hence the scale of workloads, as well as high-availability models. We'll describe each type below, and then provide some guidance on how to choose the right model for your needs.

[ Learn about the technologies and approaches powering telecommunications transformation in the Open transformation in telecommunications eBook. ]

Multinode OpenShift cluster

This type of cluster adheres to the Kubernetes best practice of using at least three control-plane nodes for redundancy and high availability, which are typically dedicated to management of the cluster. In its most basic form, a traditional multinode cluster needs two worker nodes, in addition to the three master nodes, to run the workloads. A standard multinode cluster can scale to hundreds of worker nodes, making it suitable for large-scale datacenters such as national and regional datacenters that house many applications.

Though the worker nodes are generally colocated with the master nodes, it is also possible to use a remote worker node (RWN). As the name suggests, an RWN may be placed away from the control-plane node. An RWN deployment requires additional considerations to ensure that latency between the RWN and the rest of the cluster is within acceptable limits. Additionally, the network connecting them must offer sufficient bandwidth between control and remote worker nodes.

Three-node compact OpenShift cluster

Sometimes called a compact cluster, this type is meant for a smaller datacenter where a few servers are sufficient to host the required application workloads. A three-node compact cluster offers control-plane redundancy and high availability. In this case, the same three control-plane nodes serve a dual role by also acting as the worker nodes to host application workloads.

Single-node OpenShift cluster

As the name suggests, a single-node OpenShift cluster (SNO) runs on a single machine. The small form factor is suitable for scenarios where space, power, or workload requirements do not allow for, or do not require, multiple nodes. This comes at the cost of losing node-level redundancy, as the single server is the only master/worker node in this cluster. SNO scalability was restricted to a single worker node until recently. The ability to add a dedicated worker node to an SNO is now available, hence an SNO cluster can now scale up and cater to a higher number of workload pods, if required.

Choose the right OpenShift cluster for your mobile network

There is a strong correlation between the fundamental requirements of cell site, far edge, edge, and regional/national datacenters and different types of OpenShift clusters. This is not a coincidence! OpenShift strives to be the horizontal cloud platform of choice for communications service providers, so the three deployment models defined above are carefully engineered to meet the domain-specific needs of a typical service provider network. The benefits and merits of using OpenShift as  the horizontal cloud platform for service provider networks were discussed in What does Red Hat OpenShift have to do with Cloud RAN?

OpenShift for regional or national datacenters

A mobile network's regional or national datacenters demand a high level of redundancy, resiliency, extensibility, resource availability, and workload scalability. This is where the bulk of a mobile core's functions reside. It's not uncommon to have only a few national datacenters supplemented by a small number of regional datacenters. Therefore, the multinode cluster is the best option for these datacenters. Space, power, and cooling are not usually a concern for these datacenters, so dedicating three nodes for control-plane redundancy is entirely justified.

The large number of worker nodes supported by a multinode cluster matches the requirement to run multiple applications and functions at these datacenter locations. These functions may include the mobile core functions, various IT applications, and management functions, as well as the applications to manage and monitor the cloud infrastructure (that is, other OpenShift clusters) across the mobile network. In a large network, where the deployment architecture might require both regional and national datacenters, the regional datacenters can generally be set up as spoke clusters managed by the OpenShift cluster running at the national datacenter(s).

Some mobile providers have a great interest in using public clouds to replace or supplement the privately owned national and regional datacenter infrastructure, and OpenShift's ability to run on a public cloud as well as on-prem (private cloud) infrastructure offers a seamless experience whether the multinode cluster runs on a public, private, or hybrid-cloud environment.

[ Read Hybrid cloud and Kubernetes: A guide to successful architecture. ] 

OpenShift for edge datacenters, far edge, and cell sites

In contrast to the datacenters hosting mobile cores, edge and far-edge datacenters host a much smaller number of functions. These include virtualized centralized units (vCUs), virtualized distributed units (vDUs), and possibly the user-plane function (UPF) and multiaccess edge compute (MEC) applications.

When privately hosted, these edge and far-edge datacenters have a somewhat limited amount of space and power, which makes the three-node compact cluster a good fit for these locations, especially the edge sites. With the three-node cluster design, redundancy is not compromised, and using the control-plane nodes as the worker nodes is generally sufficient to support the limited application scale typically required. If workload requirements exceed the compute resources of the three nodes, additional dedicated worker nodes can be added to scale up the cluster.

[ Learn why open source and 5G are a perfect partnership. ]

Another available option for edge datacenters is using RWNs with the control plane hosted on the OpenShift cluster at the regional datacenter. As with regional and national datacenters, public cloud infrastructure is also a good candidate for hosting edge datacenters. An OpenShift three-node cluster can be seamlessly implemented regardless of what type of underlying infrastructure is used.

The far-edge and cell sites usually have strict constraints around real estate, power, and cooling capabilities. The distributed unit (DU) and a lightweight cell site router (CSR) are typically the only workloads at these locations. If located at the cell site (that is, a distributed RAN or D-RAN), an SNO might be best suited to host the DU function. This DU will serve a limited number of radios and hence a relatively small subset of mobile subscribers. A worker node can be added to the SNO cluster when the compute resources on an SNO are not sufficient.

On the other hand, a far-edge site deployed in a centralized RAN (C-RAN) deployment model would serve more than one cell site. As a result, an SNO may not always be the most suitable option to host the number of DU instances required to service all the cell sites. In such cases, a three-node OpenShift cluster may be an apt choice to host the multiple DU instances, thus offering scalability plus some level of redundancy and high availability.

Recall that the far-edge datacenter can serve only a limited number of cell sites due to the strict distance limitations between far-edge datacenters (where DUs are hosted) and cell sites (where RUs are located). The distance limitation stems from the low latency requirement for traffic between RUs and DUs, typically between 100 and 150 microseconds each way depending upon the implementation. Due to this latency-imposed distance limitation, the number of DUs in such a location will be fairly limited.

OpenShift deployment models compared

The flexible deployment options provided by OpenShift fit very nicely with the domain-specific requirements of a mobile network. OpenShift's support for multiple cluster sizes, along with its ability to run horizontally across a hybrid cloud environment, offer a wide range of choices. Mobile service providers should undertake a dimensioning exercise to determine which type of cluster and cloud infrastructure is best suited to their deployment requirements.

The lists below summarize various OpenShift options, their intended placement choices, and other key differentiators a mobile service provider may need to consider to determine which OpenShift flavor suits each part of their network.

	Single-node OpenShift (SNO)	3-node compact	Multinode OpenShift
Cluster size	Small	Compact	Variable
Physical space requirements	Low	Medium	Variable
Power requirements	Low	Medium	Variable
Recommended placement	Cell site	Far-edge datacenter (DC)	Edge DC, regional DC, national DC
Typical mobile workload	vDU	vCU, MEC, UPF (for CUPS and Local Breakout)	Multiple CUs, UPF, 5GC, and more
Cluster extensibility	Limited	Yes (can also be converted to multinode if required)	Additional workers can be added
Redundancy and high availability	SNO+Worker	Control and worker node redundancy	Control and worker node redundancy

[ Read Automating the last mile: Ensuring consistency and scalability at the edge. ]

Summary

Kubernetes-based telco cloud platforms and the use of cloud-native applications in mobile communication networks are transforming the service provider landscape. Red Hat OpenShift is the leading Kubernetes distribution offering an open, flexible, reliable, and versatile cloud platform that can be used to host a variety of application workloads, including mobile workloads (that is, the mobile core and RAN applications).

OpenShift, as a horizontal telco cloud platform, supports a variety of form factors that offer flexibility, extensibility, scalability, and redundancy as required by the application and use cases. The smallest OpenShift cluster—an SNO—is suitable for cell sites, a three-node compact cluster can be useful at far-edge sites, whereas a multinode cluster can handle workloads for edge, regional, and national datacenters. With OpenShift's ability to run on bare metal, virtual machines, and on-premises clouds, as well as public and hybrid clouds, Red Hat OpenShift is a smart choice for hosting cloud-native mobile applications, as shown in the representative topology below:

Image

That said, introducing a cloud platform in a traditional network infrastructure is cause for network engineers and architects to reimagine their network design and consider the implications of such an integration. Nowhere is this transformation more prominent than at the periphery of the network—that is, the cell site and the far-edge and edge datacenters. Telco network architects must plan carefully for the placement of the cloud platform, as well as the integration of various features such as timing and synchronization.

[ Learn about training and certification for the telecommunications industry. ]

---

This originally appeared on the Cloudify{ing}.Network{ing} blog and is republished with permisison.