Where Should BT, Orange, and Vodafone Host Their Voice and Data Workloads?

Anecdotal evidence indicates that up to 30% of enterprise workloads are hosted on Hyperscale Cloud Providers’ (HCPs) infrastructure. Increasingly, Communication Service Providers (CSPs) are migrating their workloads off private Data Centers (DCs) into the public cloud (see AN-5399). For example, based on ABI Research’s general research on the cloud, we observe that 10% to 15% of telco workloads have already migrated to the public cloud—Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. Approximately 79% is estimated to be hosted on-premises in private DCs; 4% of the workload is hosted on dedicated public cloud infrastructure on telcos’ premises (e.g., AWS Outposts, Azure Stack, and Google Anthos); and 2% is managed by a third party like Accenture or IBM. Partnerships between CSPs and HCPs are proliferating apace and examples abound. In addition to AT&T and Verizon (see IN-6296), Orange recently announced a partnership with GCP to modernize its Information Technology (IT) infrastructure.

A proprietary telco cloud is a complementary hosting environment, as recently evaluated in ABI Research’s body of market intelligence work for cloud infrastructure (PT-2637). Traditionally, for CSPs, there has been a clean interface between designing telco cloud components and public cloud subsystems. Purpose-built for the stringent requirements and regulatory frameworks that characterize telcos, the telco cloud hosts workloads separately from the public cloud. That is because telco and Network Functions Virtualization (NFV) workloads, unlike enterprise workloads, tend to be any combination of latency-sensitive, jitter-sensitive, and demanding a high packet rate throughput. Given HCPs’ traction in the ecosystem, this is changing. This account focuses on CSPs. More specifically, will success for BT, Orange, and Vodafone be built around hosting user- and control-plane Network Functions (NFs) in a proprietary, on-premises DC, or should they “outsource” that to a partner like AWS, GCP, or Azure?

There are three domains to consider for BT and Vodafone to assess the (functional) practicality of the public cloud. There is Subscriber Data Management (SDM), IP Multimedia System (IMS) for voice and media, and packet core for data. Different from enterprise workloads, IMS and packet core (data plane, control plane, and signal processing) are latency-sensitive, jitter-sensitive, and demand high packet rate throughput. The data plane carries user traffic and media streams. They are characterized by a high Input/Output (I/O) processing, have high packet throughput, and are latency-sensitive. Intensive I/O operations are offloaded to the Operating System (OS), and they interface with external bare metal. But with public cloud, CSPs have no access to underlying bare metal. So, it may be a challenge to obtain as much hardware “horsepower” as possible. For the user plane, rather than decoupling NFs from hardware, a dedicated full-stack implementation may be the optimal choice to achieve throughput and latency performance. Here, NFs and hardware come from the same vendor; for example, China Mobile, China Telecom, and China Unicom have all opted for a dedicated user plane. Signaling processing is also latency-sensitive, so it can benefit from tuning at bare metal level, too.

On the contrary, control plane workloads are less intensive in I/O processing and transactions per second. Performance for control plane is not as stringent, so they can be adequately supported using “out of the box” public cloud configurations. Whether it is data plane, voice signaling, or control plane workloads, broadly speaking, telco services entail forwarding high amounts of data with low latency. Except for deep packet inspection, forwarding centers around Layer 2 (Ethernet, Multiprotocol Label Switching (MPLS), Media Access Control (MAC) addresses) or Layer 3 headers (IP forwarding). That is a key point to make because virtualization technologies that HCPs use (Xen, KVM) are not conducive to Layer 2 networking. Xen, KVM, and other hypervisors automatically generate a random MAC address for each virtual network interface at creation. Again, the importance of access to bare metal comes to the fore, but this time from a different angle—that of the creation of network services, sending/receiving Layer 2/Layer 3 payloads to/from peers. Examples include Ethernet frames, IP packets and MPLS frames spanning a distributed, multi-site geographical footprint.

The public cloud uses a centralized server architecture, so multi-site support may be a challenge. What drives that point home is that HCPs do not have availability zones in every country. That may be a challenge for latency-sensitive applications. The challenge is exacerbated if a strong fiber optic network is not in place. There are some CSPs like DISH Wireless that have the “muscle” to negotiate their own network design and guaranteed links. But, for the wider CSP community, ABI Research opines that the user plane and voice signaling can be the anchor for telco-cloud in the next 5 years. Further, voice, unlike data, is regulated. Consequently, voice traffic must stay in-country to adhere to local regulations. CSPs will fret over the prospect of their egress traffic going to a neighboring country and come back. But, due to a broad choice of technology available, hosting NFs in a public cloud holds strong appeal for CSPs as they foray into the enterprise domain. A co-existence of telcos and public clouds is inevitable. But for that to be harmonious, a distinct demarcation of telco and public cloud needs to be in place.

HCPs have a place in the ecosystem (see IN-6150). But, as noted above, in the near term, CSPs are likely to host part of their core/Radio Access Network (RAN) workloads on a telco cloud. 5G Core can be deployed on a public cloud, but that is mostly on a Proof of Concept (PoC) basis, and it focuses on vertical industries. Furthermore, to ABI Research’s knowledge, there is no commercial case of Virtual Evolved Packet Core (vEPC) and Virtual IMS (vIMS) deployed on a public cloud. DISH uses AWS for its 5G rollout. But anecdotal data points from conversations with the industry suggest that only 10% to 20% of DISH’s workloads are currently hosted on AWS. DISH maintains part of its network on VMware’s platform. And this is a lesson that can be applied broadly. CSPs can adopt a public cloud if it aligns with their interests. But at this early stage, in addition to the public cloud, it is practical to retain the services of horizontal platform providers like Canonical, IBM/Red Hat, and VMware, particularly for voice. These companies have Kubernetes-based platforms that serve as an abstraction layer, enabling a telco to port workloads from one environment to another. This may be why AWS’s tenant, DISH, still has a relationship with VMware.

Growth forays for CSPs stand to revolve around ecosystems of intertwined, decoupled components. Whether it is an HCP or a horizontal platform provider that offers fully integrated solutions as is the case with Canonical, IBM/Red Hat, and VMware, CSPs must establish a demarcation point across three interfaces: 1) between single-vendor, full-stack cloud deployments and decoupled, multi-vendor cloud architectures (see AN-5369); 2) between public and private cloud; and 3) between virtualized, cloudified, and NFs still in physical form (see AN-5279)—in that order. With multi-vendor deployments, it is challenging to establish fault demarcation and root cause analysis. Conversely, with a single-vendor, full-stack deployment, caution must be taken, so that a given provider does not establish itself deeply in CSPs’ networks and give rise to lock-in considerations. AT&T, BT, and Orange should hedge their bets on competing platforms (see IN-6573). For example, establishing some clarity on where HCPs operate, and where cellular providers like Ericsson, Huawei, Nokia, and ZTE operate is a first step in that direction.

To conclude, the opportunity for HCPs to host voice and data workloads is a function of performance in terms of functionality and reliability. CSPs continue to compete with a proprietary, interdependent (core) architecture. Consequently, to preserve the existing status quo in the consumer domain, CSPs as commercial entities must be integrated (see IN-6322). In ABI Research’s opinion, BT, Orange, and Vodafone must control the design and modification of every critical component of the network to optimize performance, including the underlying hardware. The right to integrate comes with technology ownership, not technology access (see IN-6603). The ability and right to improve, personalize, or appropriate will be a key a question in the next iteration of public cloud adoption. For voice, but also for some data workloads, according to some industry voices, and as discussed in this ABI Insight, Evolved Packet Core (EPC) elements and 5G Standalone (SA) functions remain that CSPs need to optimize for performance. For the time being, that may be easier achieved with owned and proprietary on-premises DCs.