While the failure of 5G to generate the hoped-for incremental revenue for operators has been largely accepted, as I noted yesterday, there’s another broader tech transformation that may still be balancing between realization and disappointment, the “open network” model of telco infrastructure. TelecomTV ran their Open Telco Infra Summit on this topic, and the story is found HERE. I’ve also gotten input from 56 operators over the last three months, and I hope the combination of these sources can drive some insights into where this balance will fall.
While the paths forward from the key value proposition are complex, the value propositions for open-network infrastructure is simple; cost reduction and revenue enhancement through an open contribution of service feature logic, in that order. Of my 56 operators, all of them wanted lower costs, and 39 wanted an open framework into which multiple vendors could be expected to contribute feature elements that would drive service revenue growth.
Why, given the assertion that the key value propositions for open-model infrastructure are simple, are the pathways so complicated? There are a number of reasons cited in the article, and more suggested by my operator contacts.
Where both agree is that telco participation in open-model initiatives has not been helpful. My own experience has been that telcos are happy to participate in standards processes, which they resource using CTO reports who have a long history in working on standards. They are not generally willing to participate in open-source projects, and when they do they tend to want to contribute requirements and approaches but not contribute coding resources. The summit made this point, and a surprising 33 of 39 operators agreed with it. However, they note that their own organizations don’t have that level of development skill in-house, that the software work they do is largely confined to OSS/BSS systems under the CIO. “It’s easy for [vendor name omitted] to send bodies to the Linux Foundation; they have them,” said one telco planner.
As broadly held as the telcos-don’t-help view is, though, it may not be particularly helpful. Saying “this is not working” may be a prerequisite to finding something that will work, but it doesn’t get you over the goal like by itself. What has to be addressed is whether it would be better for telcos to develop open-source skills and increase their participation in the projects, or whether to rely on others to resource projects that have open-model goals.
Years ago, I was a technology staff lead to a line organization who wanted to improve their own software skill set. The director was a business type, and one day he called me into his office and said “I’ve just hired a great software expert!” I looked him in the eye and asked “How did you recognize him?” As it turned out, of course, the new hire was not a great software expert, and that illustrates the challenge facing a non-software organization to hire software expertise. Operators largely agree, which is why 33 of 39 said they didn’t have any resources to contribute.
OK, Plan B. Open-model infrastructure is a big pie to sit on the window sill. Wouldn’t the scent draw plenty of interest from vendors? Again, from my own experience, yes it would. It would draw a lot of vendors interested in preventing the project from being successful. Every telco initiative I’ve participated in has failed because one or more critical vendors obstructed it. In some cases, the projects just faded away, in others they produced a result that was far short of what was needed. None generated anything good, and I think that’s been the case with almost every project where telcos tried to drive an open-model initiative.
Part of the problem in this area is that vendors are rarely willing to overturn their own product sales strategy, which open-model networking would surely do. Another part is that software projects have to start with an architectural model, which is why they have software architects. Telcos who are trying to drive an open-source project don’t know how to frame their requirements in general software-architecture terms, and so they tend to make everything into boxes and interfaces. As a result, they create a structure that’s actually not a software architecture at all, but rather a set of independent applications that have to somehow cooperate. That makes integration complicated, in no small way because the box-and-interface approach is “brittle”, meaning that a seemingly modest change (which is almost inevitable) will break it. Nobody likes projects that require complex integration. Of those 39 operators, all said that they feared that integration costs would overwhelm open-model benefits, and you can see from the AT&T/Ericsson/Nokia saga that telcos are increasingly asking for “single-vendor-open-model” solutions to address that.
But speaking of the AT&T deal, which is Open RAN, we come to the issue I believe is the most important, and one the summit report doesn’t cite. Let’s call it the missionless-feature problem. 5G has a bunch of “new features” that were intended to generate “new services” and “new revenue”. But could you really lay out a bunch of “new features” without knowing what would justify them? What was the mission that the buyer would value enough to make them pay for its fulfillment? I contend that this has cut 5G in two very different ways.
First, and most obvious, is the fact that absent mission knowledge you have neither a justified set of features nor an understanding of what outside-the-network elements would have to be present in order to realize the network’s expected benefit. If IoT is essential in valuing low 5G latency, for example, you need IoT applications. Where are they? If network slicing is essential in creating a charging basis for QoS and security, who exactly has the problem those capabilities resolve?
Second, and less obvious but perhaps more impactful, you can easily assign floating-in-air, missionless, features a place in an architecture where any evolving missions couldn’t realistically be supported. How much of Open RAN work, sales effort, business development, and sheer time and money, were focused on creating an architecture where “features” could be hosted in the RAN? Most of the operators I talked with still think that one of the benefits of Open RAN should be the fostering of a thriving ecosystem of software vendors who want their stuff hosted out in the RAN under control of the non-real-time RIC. Is that where they believe edge computing would develop? Of the 39 operators in my chat sessions, all of them placed any “carrier cloud” deployments at the locations of the old central offices or tandem offices, meaning deeper in the network than the RAN. In any event, it’s hard to see why you’d host any feature other than one related to connectivity in the RAN, and connectivity features are a dead end for revenue generation.
The question of features and service revenues raises yet again my (yet, perhaps boring-to-you) point of the metro opportunity. The places where operators tend to put those valuable hosted service features is at the first place they own real estate when moving inward from the user access point. That, typically, is a current CO/TO location. My own view, which I must point out is not fully validated by operator comments, is that trends in access network technology evolution would deliver satisfactory latency with significantly better capital and operations economies of scale if we pushed to the “tandem” or deeper points, which tend to coincide with current metropolitan complexes. The good news for vendors is that there are hundreds of such complexes in every major market area, creating a market for several thousand metro centers, and that you could modernize metro deployments one center at a time, making it easier to justify the capital budgets.
Closing points? Operators want more from open-model networks that lower costs alone. They also want them to be a platform for feature injection and service revenue growth. There will be operators who, like AT&T, plan a major modernization of infrastructure and could therefore consider a complete refresh of current gear, but the majority are looking to phase in any open-model strategy, either by focusing it on one layer (like Open RAN) or on one geography (a metro area at a time). With most of 5G deployments budgeted already complete or committed, I think the metro opportunity is where open-model networking will shine, because that’s where it can be most easily justified. But…it may take a while.
