How Can the Public Cloud Unify Operations for Telecoms?

Communication Service Providers (CSPs) are increasingly adopting the public cloud model into their enterprise deployments. This is evident through the budding partnerships between CSPs and public cloud companies, such as Amazon Web Services (AWS) and Azure. For example, AT&T announced in June 2021 that they will begin deploying their mobile network on Azure, starting from their core network. In exchange, Azure will have access to AT&T Network Cloud Platform technology to further enhance their Azure for Operator portfolio. In May 2021, Dish Network announced the deployment of their 5G RAN and Core on AWS. Further, recently at AWS re:Invent 2021, AWS announced their AWS Private 5G solution, which is a private network solution that can be deployed via the AWS console, with partners providing networking components and network functions.

While the public cloud was first utilized by the telecoms industry to host IT applications and workloads, it has now entered into the edge (i.e., virtualized Radio Access Networks (vRAN), Open RAN, and Multi Access Edge Computing (MEC) edge) and is slowly encroaching into CSPs core networks as well. However, what would the impact be for CSPs and their customers? Will the public cloud be able to unify operations for telecoms?

The telecom industry has long been characterized by monolithic systems where development occurs in siloes and there are high levels of technological heterogeneity where end to end orchestration, logging, monitoring, and assurance becomes challenging. However, with the uptake of the public cloud, which is often developed with homogeneity in mind, CSPs can stand to gain if they were to leverage the public cloud as a unified platform to host their applications. Furthermore, as the telecom cloud and enterprise cloud converge, CSPs would also be able to provide value-added services for enterprise applications and end devices. One such idea would be to have CSPs provide end-to-end network assurance that does not stop at the network device, but is also able to collect telemetry and performance data from enterprise end devices such as Augmented Reality (AR) headsets, Automated Guided Vehicles (AGVs), Condition-Based Monitoring (CBM) devices, etc.

In the above-mentioned scenario, CSPs would be able to leverage on the public cloud where enterprises deploy their applications and have a uniform single cloud platform where assurance and self-healing does not only happen for network elements, but also for enterprise devices. Currently, such use cases are challenging as CSPs running legacy equipment have many Physical Network Functions (PNFs) and their Virtualized Network Functions (VNFs) are still running in siloes without the ability to manage other components in the telecom stack. For example, current network assurance solutions are vertically integrated with Fault, Configuration, Accounting, Performance, and Security (FCAPS) systems handling individual networking domains or layers, where there is very limited cross-domain and cross-layer capability. In this situation, while their network assurance solutions might detect a problem at the core network, they will not be able to correlate the problem with the impact to the RAN or end user devices. The outcome of this is that troubleshooting might occur at the core network when there is little impact to the RAN or end user experience. However, if CSPs were to run their network assurance applications and connected end devices on the public cloud, the challenge of heterogenous and disaggregated systems can be overcome.

However, the path to public cloud for CSPs is not a monolithic one. While public cloud companies have been aggressively innovating and influencing CSP edge strategies, CSPs are the ones who decide which applications are best put to the public cloud and which are best ran on the telecom cloud. Ultimately, CSPs have to decide based on what business value the public cloud would bring, which would be measured in increased profit potential created through new business opportunities and more attractive solutions for the enterprise. For example, as previously mentioned, networking solutions underpinned by the public cloud would be able to draw data from enterprise applications running the public cloud, which gives CSPs the opportunity to provide solutions to directly manage the performance and monitor enterprise end devices. Utilizing the public cloud would also benefit enterprise application developers as it creates a consistent networking layer where applications would run on. Beyond that, public cloud increases scalability for CSP enterprise deployments as it allows for the offloading of network traffic unto the public cloud. Utilizing the public cloud for CSP enterprise deployments will also reduce the overall Total Cost of Ownership (TCO) for Small Medium Enterprises (SMEs) as deployments will take a pure operating expenditures approach compared to the more costly capital expenditures approach using private telecom clouds.

However, this is not to say that the private telecom cloud will not have its place in the enterprise space. While it is true that telecoms are generally at a disadvantage when competing against the public cloud in terms of enterprise application development, the private telecom cloud still remains a central piece of the CSP portfolio and is crucial in providing customized end-to-end Service Level Agreements (SLAs), ultra-high bandwidth capacity, and mission-critical low latency capabilities. For example, in Sichuan, China, ZTE and China Telecom deployed an end-to-end warehousing solution for a logistics company. In this use case, up to US$ 471 million (three billion RMB) worth of end user devices were connected and hosted on the private telecom cloud, consolidating networking control, quality of service monitoring, and feedback loops on one cloud. This approach was chosen as it was much more suitable to host critical applications on the private telecom cloud to ensure data anonymity, security, and SLAs.

That being said, both the private telecom cloud and public cloud will be here to stay, and CSPs will have to enter into a phase of developing multi-cloud and hybrid-cloud strategies. In order to do so, CSPs will have to work towards being cloud smart by undergoing operational changes and technological changes. In terms of operational changes, CSPs will have to adopt cloud native principles in their approach. Traditionally, CSPs have developed software in a sequential waterfall approach, which results in longer time to market and work in siloes. A cloud native approach would require CSPs to adopt a “microservice”-based architecture whereby each service is disaggregated, highly scalable, and flexible to be quickly deployed. Engineers would also require a cloud-first approach in their design, testing, and deployment of services, and adopt a DevOps approach. In terms of technology, CSPs will have to begin deploying Containerized Network Functions (CNFs) and building multi-cloud and hybrid-cloud environments. This includes utilizing telecom cloud platforms and cloud orchestrators with such functionality. Many vendors nowadays provide multi-cloud telecom cloud platforms, including Red Hat OpenShift and VMware Telecom Cloud Platform, with incumbent Network Equipment Vendors (NEVs) innovating in this aspect (e.g., Nokia Container Services can be deployed on any cloud and across multiple-clouds, and Ericsson Dynamic Orchestration claims to be able to manage multi-cloud environments). Ultimately, CSPs will begin to run both telecom and enterprise apps on multiple clouds, whether it be private telecom ones or public clouds. As such, true unification does not come from only utilizing a single type of cloud deployment but being able to run apps across a much more interoperable cloud environment with multi-cloud capabilities.