Like most analysts, I don’t often cite or praise the work of other analysts, but today I want to give a shout-out to Omdia for a figure they posted on LinkedIn, titled “Global telecoms capex flow, 2021”. It makes, in convenient graphics form, some of the points I’ve been raising in the evolution of telecommunications infrastructure and services, and it should serve as a warning to vendors not to take their eye off the ball.
Everyone knows that networks are aggregation hierarchies aimed at securing optimum economy of scale. At the edge or access end, the distribution of network users in the real world means that network infrastructure has to reach out to get traffic onboard. From there, traffic is concentrated inward to take advantage of optical capacity benefits. Access, aggregation, and core.
The Omdia chart shows the segments of operator capex, and while it doesn’t quantify the spending it does represent the categories proportional to their contribution. The fattest piece is the access network, which shouldn’t surprise anyone. The thinnest piece, smaller even than the devices-and-CPE piece, is the core, but that doesn’t mean that the core isn’t important, or isn’t a viable market target, particularly for new entrants.
The problem with the access network is that there’s so darn much of it that operators have to squeeze every cent of cost out of it or they risk being totally unprofitable. That means that capex is always under pressure there, and so is opex, because much of what I’ve always called “process opex” relating to actual network operations is related to customer care. “My network is broken if I say it is,” is a reasonable user mantra, and so it’s critical that everything humanly possible is done in the operations automation area to reduce the burden of finding problems and fixing them.
All of this tends to make access networking a fortress of incumbency. That’s particularly true in the wireless area, because even “open” initiatives like O-RAN don’t immediately convince the operators to adopt best-of-breed purchasing and do the necessary integration. In any case, it’s always difficult to introduce something new into a vast sea of old-ness without creating all manner of operations issues. That’s why 5G was an important opportunity for up-and-comings (one largely missed), and why the deployment of 5G New Radio over LTE EPC worked in favor of incumbents by accelerating early deployment, ahead of open-model specifications.
The beauty of the core network is that it does represent a pretty small piece of capex and opex, which means that if there’s a need to modernize and refresh core technology, it may be practical to do that by simply replacing the core network overall. There are millions of access devices in a network, but hundreds (or less) of core devices.
But even true beauty often has a blemish or zit here and there. With the core network, that blemish is the small contribution it makes to capex. If operators don’t spend much in a given space, then vendors in that space don’t make much. A success in the core here and there is going to quickly exhaust the total addressable market. A good play in the network core is a play that knows the core is a stepping-stone to something that has more capex associated with it. But, given operator reluctance to increase capex, what could that something be?
Cloud infrastructure, meaning server hosting resources, currently account for almost three times the capex as the network core. IT platform tools and software account for about double the capex of cloud infrastructure. And best of all, the access network that’s by far the biggest contributor to capex has one essential requirement, and that is to connect to all of this stuff…cloud, software, and core. That’s why I love the “metro” opportunity.
Traffic in the access network naturally moves into the core via some “on-ramp” technology. Every user can’t be efficiently connected to the core, so that on-ramp is the focus of aggregation within the access network, the collecting of traffic within a geographic area. Thus, this on-ramp point is both geographically linked and serves a concentrated amount of traffic and user connections. That makes it a great place to host things that are linked to geographies, which would include content delivery and IoT.
It’s also a great place to achieve economies of scale in hosting and storage. Go out further and you multiply the number of sites you’d need by several orders of magnitude, which means there would be no economy of scale and little chance of operational efficiency. Go deeper and there’s too much traffic to allow you to recover individual user characteristics and serve user needs, or to support real-time application hosting.
Where these on-ramp points are is of course a reasonable question. I think it’s one that was answered decades ago in the heyday of telephony. We had “edge offices” supported by “Class 5” switches. These offices were linked to “tandem” offices supported by “Class 4” switches, and those were located in what came to be called “Local Access and Transport Areas” or LATAs. We had about 250 such areas in the US, and that roughly corresponds to the number of metropolitan areas. Thus, a “metro” is, historically, the right place to jump on to a core network and to host incremental service features.
OK, topologically and geographically that all makes sense, but what about technologically and (most important) financially? There are three possible ways that “metro” could be supported. First, you could consider metro to be the inside edge of the access network. Second, you could consider it to be the outside edge of the core network. Finally, you could consider it an entirely new layer. Which option is best depends on perspective.
If I were a Nokia or Ericsson, I’d want to promote the metro to be a piece of the access network, because I’d be an access-network incumbent. Favoring this view is the fact that 5G specifications call for feature hosting, which means that hosting and “carrier cloud” are arguably requirements for 5G access networks (that’s a piece of the Omdia figure that’s almost three times the size of “core”, by the way).
If I were DriveNets, I’d want metro to be the edge of the core, because I’d be pushing core router sales. The DriveNets cluster router model fits well in the metro space too, in part because you could use it to connect server pools locally was well as support aggregation outward and core connectivity inward.
If I were Juniper, I’d want metro to be a separate, new, space. Juniper has actually articulated this to a degree with its “Cloud Metro” announcement a couple years ago. This positioning would let Juniper ease its way into access capex via 5G (which they’ve been promoting anyway), and also support general carrier-cloud missions.
Each of these three strategies has a vendor most likely to benefit from adopting them. Which strategy, which vendor, will win is the question that might determine the future of network infrastructure and the future of the vendors involved. It’s going to be fun to watch.
