Red Hat OpenShift Deployment Models for Cloud RAN

Telecommunications Service Providers have varying requirements for product and technology that goes into their networks. With a large number of nodes that are constrained by a limited power and real estate budget, a service provider’s 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 go down, but scale, capacity, port-density, and high availability requirements are more demanding. Since aggregation and core networks have proper data centers and point-of-presence locations with (likely) ample space and power, the size and power consumption of these devices become secondary to scale, capacity and High Availability.

Correlating these fundamental Service Provider network characteristics with Cloud RAN mobile networks; Cell Sites are the provider’s access network, whereas Far Edge, Edge, Regional and National data centers can be equated with various Pre-Agg, Agg and Core networks. The horizontal cloud across the mobile network must also be cognizant of these requirements - i.e. a leaner, smaller form factor cloud platform at the cell sites, becoming increasingly flexible, scalable and redundant as it moved deeper into the mobile provider network to Edge, Regional or national Data Center.

It was established in the previous blog post that Red Hat OpenShift Container Platform offers itself as a horizontal cloud platform across the entire mobile network. Just like networking devices, the cloud native applications that build the mobile network also have diverse requirements of scale, capacity, and cpu/memory resources. Red Hat OpenShift clusters aim to host these functions, therefore, can’t be one-size-fits-all and must offer flexibility to be a true horizontally scalable cloud platform to support Cell Site, FarEdge, Edge, and Regional/National datacenters workloads. OpenShift offers the following form-factors for that:

• Multi-Node OpenShift
• 3-Node Compact Openshift
• Singe Node OpenShift (SNO)

While each of these offers the full capabilities and features of OpenShift (with minor exceptions, that will be discussed later), the major difference between these is the supportable number of worker nodes, and hence the scale of workload, as well as high availability models.

The following figure provides a visual comparison of three OpenShift cluster options:

Multi-Node OpenShift Cluster

This type of cluster adheres to the kubernetes best practices of using at least three control plane nodes for redundancy and high availability, which are typically dedicated for management purposes of the cluster. In its most basic form, a traditional Multi Node cluster needs two worker nodes, in addition to the three master nodes, to run the workloads. A traditional multi-node cluster can potentially scale to 100s of worker nodes, making it suitable for large scale data centers such as National and Regional DCs that may 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, and the network connecting the two offers significant bandwidth between control nodes and worker nodes.

3-Node Compact OpenShift Cluster

Sometimes referred to as Compact Cluster, this type of cluster is meant for a smaller data center, where a few servers are sufficient to host the applications. A 3-node compact cluster offers control plane redundancy and high availability. In this case, the same three control plane nodes have a dual role and are also used as worker nodes to host application workloads.

Single Node OpenShift Cluster

Just like the name suggests, a Single Node OpenShift cluster, commonly referred to as 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, multi nodes. Obviously 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 till recently. However, the ability to add additional worker nodes is now available and hence SNO can now slightly scale up and cater to a higher number of workload pods.

Choosing the Right OpenShift Cluster for your Mobile Network

There is a strong correlation between the fundamental requirements Cell Site, FarEdge, Edge and Regional/National Data Centers and different types of the OpenShift clusters. This is not a coincidence! OpenShift strives to be the horizontal cloud platform of choice for communications services providers, and as such, the three deployment models defined above are carefully engineered to meet domain specific needs of a typical service provider network. Our previous blog touched on OpenShift as the horizontal cloud platform for Service provider networks.

OpenShift for Regional and/or National Data Centers

The Regional or National Data centers in a mobile network demands a high level of redundancy, resiliency, extensibility, resource availability, and workload scalability. This is where the bulk of a mobile core’s functions reside; and there are usually just a handful of data centers of this nature. In fact, it's not uncommon to have only a couple national data centers, supplemented by a small number of regional data centers. Therefore, hands down the multi node cluster is the best option for these data centers. Space, power, cooling etc. are not usually a concern for these data centers, so dedicating three nodes for control plane redundancy is completely justified.

The large number of worker nodes supported by a multi-node cluster perfectly matches up with the requirement to run multiple applications and functions at these data center locations. These functions include the mobile core functions, various IT applications, 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 Data centers, the regional data centers can generally be set up as spoke clusters that are managed by the OpenShift cluster running at the National data center(s). It must be mentioned that there is great interest by mobile providers to utilize public cloud to replace or supplement the privately owned National/Regional data centers 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 public, private or hybrid cloud environment.

OpenShift for Edge Data Centers, Far Edge and Cell Sites

In contrast to the data centers hosting mobile core, the Edge and Far Edge Data Centers host a much smaller number of functions. These may include vCU, vDU, perhaps the User Plane Function (UPF) and Multi Access Edge Compute (MEC) applications. When privately hosted, these Edge/FarEdge Data centers have a somewhat limited amount of space and power, which makes the 3-node compact cluster a good fit for these locations, especially the Edge sites. With the 3-node cluster design, redundancy is not compromised, and using the control plane nodes also as the worker nodes can generally be sufficient to support the limited application scale that is required in a lot of cases. In case the workload requirements exceed the compute resources of the three nodes, additional dedicated worker nodes can be added to scale up the cluster. Another available option for Edge Data centers is the use of Remote Worker Nodes (RWN) with the control plan hosted on the OpenShift cluster at the Regional Data Center. Just like the case of Regional/National DC, public cloud infrastructure is also a good candidate for hosting Edge data centers and, once again, OpenShift 3-node cluster can be seamlessly implemented in irrespective of what type of underlying infrastructure is being used.

The Far Edge sites and Cell sites usually have strict constraints around real estate, power and cooling capabilities. The DU is typically the only workload at these locations. If located at the cell site, that is, a D-RAN deployment model, an SNO might be best suited to host the DU function as this DU will be serving a limited number of radios and hence a relatively small subset of mobile subscribers. In scenarios where the compute resources on a SNO are not sufficient, a worker node can be added to the SNO cluster. On the other hand, a Far Edge site deployed in a Centralized RAN deployment model, would be serving more than one cell site and, as such, a SNO may not always be the most suitable option to host the number of DU instances required to service all the cell site. In such cases a 3 node OpenShift cluster may be an apt choice at Far Edge Data Centers to host the multiple DU instances thus offering scalability as well as some levels of redundancy and high availability. It must be noted that the Far Edge data center can only serve a limited number of cell sites due to the strict distance limitations between Far Edge DC’s (where DUs are hosted) and Cell site (where RU is located). The distance limitation stems from the low latency requirement for traffic between RU and DU - typically between 100 and 150 microsecond depending upon the implementation. Due to this latency imposed distance limitation, the number of DUs on such a location will be fairly limited.

OpenShift Deployment Models Comparison Summary

In summary, the flexible deployment options provided by Red Hat OpenShift deployment fits 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 offers a wide range of choices, a mobile service provider should go through a dimensioning exercise to determine which type of cluster and cloud infrastructure is best suited to their deployment requirements.

The table below summarizes various OpenShift options, their intended placement choices and other key differentiators a mobile service provider may need to consider to determine which Openshift flavor is right for which part of their network:

Summary

Kubernetes based telco cloud platforms, along with the use of cloud native applications in mobile communication networks, are transforming the Service Provider landscape. Red Hat OpenShift is the leading Kubernetes distribution that offers an open, flexible, reliable and versatile cloud platform which can be used to host a variety of application workloads, including mobile workloads (that is the Mobile Core and RAN applications). OpenShift, as the horizontal telco cloud platform, supports a variety of form factors that offers 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 3-node compact can be useful at Far Edge Sites, whereas a multi-node cluster can handle the appropriate workloads for Edge, Regional and/or National data centers. Coupled with OpenShift’s ability to run on bare metal, virtual machines, on-prem clouds as well as public and hybrid clouds, Red Hat OpenShift is easily the platform of choice for hosting cloud native mobile applications as shown in the representative topology below:

That said, the introduction of a cloud platform in a traditional network infrastructure is a cause for network engineers and architects to reimagine their network design and consider the implications of such an integration into their infrastructures. Nowhere is this transformation more prominent than at the far edges of the network - that is the Cell site as well as the Far edge and Edge data center. Telco network architects have to carefully plan for the placement of the cloud platform as well as the integration of various features such as timing and synchronization. Our upcoming series of blogs Reimaging Cell Sites with Red Hat will cover more on this topic.