I’ve done a few recent blogs on telco risks. It’s now time to talk about what they can do about them. I think most people in the industry, including most telcos, would agree that the future for network operators has to be different somehow, but how? And no, I don’t mean that all they need to do is babble about new 5G revenues from sources that can’t be validated, either.
The basic problem that network operators in general, and telcos in particular, face is commoditization. Connection services, meaning services that create connections between users, or between users and applications/experiences, are almost impossible to differentiate except on price. You can see this in the increased reliance of mobile operators on smartphone deals as a means of attracting and retaining customers. The cost of customer acquisition and retention is, for most operators, the fastest-growing cost of all. A lot of the 5G hype is really an attempt to make 5G a differentiator, and from the near-universal support for 5G that’s quickly developed, it’s clear that’s not going to work.
Commoditization is what’s behind the profit-per-bit problem operators have faced for over a decade. In the very first presentation on the topic an operator made to me in 2010, the slide showed a revenue-per-bit curve declining, a cost-per-bit curve declining more slowly, and the two converging in around 2018 if no action were to be taken. Obviously some actions have been taken because the same curves, drawn today, show the point of convergence around 2023-2024. Still, delay of the inevitable is preferable only to facing it immediately; it would be better not to face it at all.
Cost management vanishes to a point. Measures to lower cost are important, but they can’t make the “inevitable” into the “avoidable”, only buy some time for other measures to take hold. You can make routers cheaper, but not free. You can make operations zero-touch, but not negative-touch. At some point, if you want to avoid collapse, you have to raise revenues, period. I tell operators today that a point they must raise in their dialog with vendors is “What will you offer to raise my revenue line?” Even if cost reduction is what the vendor wants to talk about, don’t talk if you don’t get a satisfactory response to that question, because that vendor cannot save you.
There are two broad possibilities for raising revenues; you can either enhance connection services in a compelling way or sell something other than connection services. The former is the approach that network operators in general, and telcos in particular, find almost hypnotically beguiling. It must therefore be subject to the most objective and thorough examination. The latter is something that operators/telcos should have done ten years ago, when it would have been easy. Now it’s going to be hard, and not only because it involves a culture shift.
Given all this, let’s return to the cost-management band-aid. Any new revenue strategy can be compromised by inefficient cost management, and of course so can the basic connection services strategy. We all know that it’s unlikely that competition would make every current connection service into a loss leader; a race to the bottom doesn’t stop when you hit bottom, but when you are at risk of going under water. The fixes operators have created for the convergence of revenue and cost have largely been focused on operations costs. Operators need to have an automated, efficient, service lifecycle automation story, period. It’s essential in realizing the full benefit of new revenue opportunities, and so we’ll address it in that context.
Now back to revenue, and to the first option of enhancing the revenues associated with connection services. The prevailing hope of operators is that you can add features to connection services to make them more profitable to operators and still also more valuable in cost/benefit terms to consumers. For at least a decade, and likely for far longer than the whole profit-per-bit craze has been emerging, the idea has been to add service features that users would pay more for by absorbing into the service add-on features that are normally provided by CPE. Security has been the primary target.
While Network Functions Virtualization (NFV) was a general concept for hosting functions as an alternative to using proprietary devices, from the first, NFV was turned in the direction of “virtual CPE” or vCPE, which aimed at making edge devices into service elements operators could charge for. The fact is that there is not now, nor has there ever been, a compelling argument for integrating edge features into services via vCPE. In most cases, an appliance solution is inexpensive; look at the home or small business WiFi router as an example. NFV’s operational complexity would make it difficult to secure even cost parity with a traditional edge device.
What might work, then? It’s long been my view that if you want to evolve to meet an opportunity, you have to build to where the opportunity is heading, not to where it is at the moment. The evolution of connection services is personalized connection services, which means network-as-a-service, or NaaS. NaaS says that the best “network” is one that exactly fits what you do, and prevents you from doing what you’re not supposed to be doing. NaaS is really what gluing a bunch of new edge appliances onto a network demarcation was heading, imperfectly and inefficiently, for.
The fundamental element of NaaS is the notion of a virtual network. You can’t give every user their own network infrastructure, so instead you give each of them a virtual network, a network that looks like it’s their own, and thus fits the NaaS model. Any solution to enhancing connection services that isn’t based in some way on a virtual network is an excursion to nowhere. Those who want to sell it can only hope for perpetual buyer ignorance to save them. Those who buy it are committing to an ever-growing cost that will ultimately fail to deliver value. SD-WAN is the best track to the right approach to NaaS we have today, period.
Properly done, NaaS can be a revenue kicker that takes operators well into the second half of this decade, but eventually it commoditizes too, because what users really want isn’t being connected to their applications/experiences, it’s having them. And applications or experiences have to be created to be had, and creating them means deploying cloud infrastructure. Carrier cloud is absolutely critical for operators to deliver on future revenues. Eventually, all other kinds of revenue measures will fail to meet operator goals. An operator without a carrier cloud strategy is an operator praying for nationalization or subsidies.
But what would a carrier cloud strategy look like? To start with, let’s address what it wouldn’t look like, which is a situation where operators outsource their cloud tasks to the public cloud providers. I’ve modeled this approach from multiple perspectives, and every one of the results puts the operators in a significantly worse position by 2025, most by 2024. Like many others, I’ve postulated that operators might gain knowledge from these relationships, but while that’s true in a general sense, the nature of the relationship between the two parties has to be defined just right for the benefit to shift to the operators.
If you are a network operator, you do not want to host your 5G in 5G-as-a-Service form using cloud provider infrastructure. You do not want to use any specialized service features of any public cloud provider. You want to host virtual machines in IaaS service form, and nothing else. The cloud provider is simply a lower-cost starting and remote-area strategy for hosting your carrier cloud. You don’t help them build theirs. That’s the starting rule, and it’s as hard-and-fast as any rule my modeling can define.
The second point is that network operators should not plan to build their own software for 5G or any other carrier cloud application. Even the best of them have proved they don’t understand cloud architecture well enough at this point. They should base their software strategy on open-source tools acquired if necessary from major firms (IBM/Red Hat, HPE, and VMware are the giants, but some other smaller ones are also fine) who can integrate the open-source elements and even provide support for new open-source initiatives. Open source software and IaaS hosting, combined with deployment of provider-owned data centers, is the pathway to successful leveraging of the public cloud.
While these software-platform partnerships are working, and operators are leveraging and exploiting public cloud, they should use the activity to build their own cloud skills. The presumption they should make is that they will have to hire in new people to be the foundation of their carrier cloud business, including and even especially at the management level.
There’s a single infrastructure target and two specific service areas that are the prime early targets for operator initiatives. The infrastructure target is edge computing and the service areas (which both relate to the infrastructure target) are IoT and contextual services. Operators have a massive advantage in edge computing that they’re in the process of throwing away, as I said in a recent blog. IoT and edge computing have an obvious symbiosis, but one that will require an architectural foundation. Contextual services are an application of edge computing that combines it with other technologies, including AI/ML and augmented and virtual reality (AR/VR).
The future of technology is arguably in the creation and exploitation of a pervasive digital parallel universe, a kind of massive multiplayer game in which everyone and everything is a player/element. IoT and other applications feed information between the real world and this parallel universe, and artificial intelligence draws insights from the data that defines the parallel universe to influence behavior and productivity in the real world. This is IMHO the touchstone for future experiential revenues, and so this should be the target toward which operators are planning their carrier cloud.
Going back now to NaaS, you can see perhaps the value proposition for it within carrier cloud. Site networking, meaning connecting clusters of workers back to a data center, is just pumping bits. When you start to create relationships between workers and consumers and hosted experiences, there’s a lot more dynamism involved. Even getting to that, changing application architectures and information flows to support productivity based on individual activity-centric information demands a lot more customization. NaaS evolves nicely into this contextual, parallel-digital-universe, future. It’s not the final answer, but it’s a step in the right direction that provides easy access to a near-term revenue kicker.
So there we are. A lot of people are going to say that this shift is too much for the telcos. Swimming for a lifeboat after your ship sinks is a lot of work too, but it’s probably not smart to think that difficulty is bad if the alternative is fatal. Commoditization, unfettered, is fatal, and telecoms need to accept that and deal with the alternative.