What we know is that they’re almost certainly business services. There is no indication that telcos could sell incremental services to consumers without abandoning their bias toward connectivity-based services. What new service could telcos offer enterprises that would be transformational? That’s a question that telcos should be trying to answer, but one that probably has to be answered by enterprises. I’ve had enterprise comments from over 400 enterprises on telecom evolution, but only 93 comments on an optimum future service offering. I’m going to focus on those today, or more properly on the 63 that described something both very different (25 said “just cut prices for current services”) and converged at least somewhat on a common theme. The theme? IoT.

Telcos loved the idea of IoT, for all the wrong reasons. Why rely on human reproduction and upward economic mobility to increase your TAM and ARPU, respectively? Get machines to consume telecom services. OK, that sounds cynical, but you’d be surprised at the number of telecom CxOs who admit that their thinking reduced to that. The presumption was that “Internet of Things” would mean a major connectivity, authentication, and thing-management burden that they’d be paid to carry. Obviously, this drove nearly all the early IoT initiatives, but when it didn’t pan out as expected, things floundered.

Enterprises’ comments suggest that the telcos got part of the answer, but only a small part, in their initial planning. That wasn’t enough to move the ball in terms of project generation, approvals, and execution. What’s needed isn’t what telcos find convenient or interesting, but what’s needed to drive the buyer to commit. An IoT service isn’t just connectivity and management, it’s not even just about networks, and it’s even somewhat about stuff that never gets off the customer’s premises.

One comment I made about edge computing resonated with most of the 63 enterprises I’m citing here. I visualized hosting as a set of layers, starting with stuff that was so sensitive to latency and QoS that it had to be proximate to the business activity being supported, and then building outward/upward to things that could be done in an enterprise or cloud data center. The comment I got most often on this point was something like “Yes! And there has to be a set of middleware and service tools that builds application components so they can run in any of these layers.”

This reflects a reality we miss often in tech, which is that you can’t launch a revolution from a standing start unless you have both an absolutely compelling buyer need and an absolutely compelling seller opportunity. Such a thing isn’t likely to happen, which means that a future transformation evolves from some limited attempt to transform in the present. IoT as a telco opportunity grows out of…IoT as it is today. That’s local process control using specialized “embedded control” systems and software. If there’s a telco IoT opportunity, it’s logical to see it as evolving somehow from opportunistic changes in the mission of these current systems. Network connectivity opportunity, central to a telco role in anything, comes about because something requires these applications (in whole or in part) to migrate off their local hosts. Find that, and find how to make the migration work for enterprises, and you have the basis for a telco IoT service.

Why not just address the remote hosting of the current embedded IoT applications? Because enterprises say there’s no business case to be made there, because the mission is already being filled in a way that’s proven satisfactory. Without the Internet and e-commerce, we’d not have cloud computing today, at least not at the level we do. Change drove the cloud, and change has to drive IoT services.

What would a real driver of change look like? The 63 enterprises offer the same answer—integration. Right now, businesses tend to be a series of loosely connected processes, each of which is automated in its own way. The office/transaction stuff is divided as we all have seen; accounting, payroll and personnel, order and inventory. The IoT stuff tends to be compartmentalized by facility. You have factories, you have warehouses, and you automate them. For transactional systems, we integrate through APIs, API brokers, service busses and meshes. For IoT, we need to integrate more than the automation, we need to integrate the real-world stuff being made and moved. Thus, we need a kind of transportation process, something to link facilities. That process has to be driven by what it links, and its automation has to link to the automation of the linked facilities.

The nice thing about transportation automation is that it relies on assets that move around, that are not currently controlled by local embedded processor systems. There are many transportation systems that do have sensor/controller elements, but most of these are really about finding the vehicles and contents or maintaining specific conditions inside to protect that which is being moved. There’s room to create a two-level (many-layered) system for transportation of goods, parts, even people. One level has to be abstraction-based, a digital twin of real-world elements. The other has to be software, portable through all manner of hosting points, designed to be distributed to the points of shipment and reception and integrate with the systems there to drive the real-world movement of things.

Another nice thing? This ties in with 5G. One of the 63 enterprises described a project to use an open-source O-RAN implementation to create a hosting point for edge components of an IoT application. They jokingly called their model the “RIC-Rack”, referencing the RAN Intelligent Controller. Their implementation created a platform linked to the O-RAN RIC via an API set, one for the non-real-time and one for the near-real-time piece. This tightly couples the contents of the virtual rack with the RAN implementation. They’ve been discussing the extension of the approach to public 5G, but with more cloud providers than telcos.

All the telco IoT elements of the past can fit into this “rack”, and be justified by it. It could be the basis for a telecom IoT service that would transform the whole of IoT. But there’s a problem. Not a single telco has even suggested thinking about this, and none of the 63 enterprises believed that the telcos could build the necessary software architecture. Could the cloud providers? Yes, and they could also facilitate the integration of the RIC-Rack, but they couldn’t guarantee it was universally accepted, and the opportunity can’t wait for 6G to firm up. Could cloud/telco partnering work? That’s probably the best shot at turning away the risk that the new IoT model is another source of disintermediation for telcos. From disintermediation to remediation? Not quite. Maybe to mitigation, which is all you can expect if you don’t want to play the right game.

Or, maybe, a telco-centric vendor? Nokia has Open RAN credentials. Nokia has private 5G, digital twins, advanced IoT work. Might they step up here? I’m not hearing about it yet, but it wouldn’t surprise me a bit.

First, let me say that when I talk about the value of AI, I’m talking about the general case of artificial intelligence and machine learning (AI/ML), not just about the popular example of large language models (LLMs) and generative AI. I’m also talking about the “assistant” model of application, the autonomous model, and the application component model, where AI elements are used as a part of an application workflow. It’s important to understand that there is no single AI type or application model that’s useful, nor is the utility of any consistent across all these verticals.

Overall, telecom revenue dollars break down into capex, opex, and profit. Typically, capex makes up 21% of the applied revenues, opex makes up 68%, and profit 11%, which is quite different from a couple decades ago. Not only that, roughly 52% of opex is related to network operations (what I’ve called “process opex”) today, when in the past that was roughly a third of total opex.

Success, according to telcos themselves, is achieved through growth in average revenue per user (ARPU), increasing share of the total addressable market (TAM), and managing churn to avoid losing your customers to someone else. Thus, their measure of success really relates to revenue gains. However, all telcos recognize that there is a need to control or (better yet) reduce opex in general and process opex in particular.

OK, these are the foundation points we need to consider. AI works for telcos if it can meet the goals these points dictate. Can it? We can look at that from two perspectives; what telcos themselves say, and what my model says.

Right now, telcos report having a focus on the LLM/generative, AI-assistant, approach. There is no vertical in which I find that enterprises report great AI success with that approach, nor do telcos report it. The model says that telco value in AI-based customer support could be great, but only 8% of telcos report significant gains with AI in that mission. From what I see, the problem is one of implementation. To succeed with a support chatbot, enterprise results say you need a combination of a support-centric foundation model, a strong training strategy based on your own technology, and a means of keeping support data in sync with service changes and experience. The number of telcos who say they have all of this is below the level of statistical significance.

The failure to create optimum AI-based customer support has a major impact on the revenue side of telco aspirations, since problems with support rank in the top two causes of churn across the whole telco community. Even where a competitor has an appealing free-phone premium option, customers are less than half as likely to respond to such offers if their support experience is strong. In fact, my model says that a customer portal driven by AI, if fully optimized, is such a benefit that it would be justified to develop non-problem missions for the portal to ensure customers have an opportunity to get familiar with it. Again, this is not currently being exploited, according to the telco comments I get.

Process opex, meaning the activity related to network operations, planning, etc., is equivalent to business operations in the enterprise space. In general, the verticals who report the largest gains from AI are those who have the most complex operations activities, usually related to a large “plant in service”, fleet of vehicles, and workers with a high unit value of labor. Telcos qualify on all these grounds, yet the data I get from them falls significantly short of other enterprise verticals in claims of AI success. My model says telcos should lead in this AI mission, and they do not.

The barriers here, I think, are complicated to understand. First, the telco vertical reports more difficulty in acquiring AI expertise than other verticals with similar opportunity profiles. Second, telcos don’t have vendors pushing AI adoption to them as fervently as those other verticals do. Third, telcos have unusually long depreciation cycles compared to similar verticals, which means that they can’t implement major changes in technology as easily because the write-down of residual value of the old stuff makes a business case harder to make.

The vendor issue needs some explanation, I think. Enterprises typically have a mixture of vendors, but in almost all cases there is one vendor (almost always the primary IT vendor, meaning server or platform software) who has decisive strategic influence. This vendor is in a position to drive project processes, and for most enterprises the strategic leader sees a benefit to promoting AI. For telcos, there is almost always one dominant vendor, a network vendor. This vendor often doesn’t see a specific benefit to pushing an AI project, and may in fact think that such a project might increase another vendor’s influence. I think this accounts for the difference in how telcos’ vendors see AI, and whether they’re an active force for AI adoption.

The three issues I cited above are almost surely related to the telco fixation on generative AI assistant models, which first tend to emphasize the productivity of lower-value-of-labor workers and second, don’t take advantage of the ability of AI to enhance current operations process workflows. Where similar enterprise verticals are significant users of specialized-model AI or ML, telcos are behind the curve there.

On the average, my model suggests that telcos could cut process opex by 37% with proper use of AI, and cut churn by 45%. AI could enhance marketing to raise revenues for mobile services by 18%, and improve the profitability of business network services by 25%. My model also says that AI augmentation to home and business IoT could give telcos a revenue boost of about 13% overall. No telco has offered comment on any of these potential moves, which doesn’t prove they’ve not looked at them, but is suggestive.

Some telco comments I’ve gotten suggest that there’s no “AI culture” at telcos, and that also seems to be true if we judge the culture from the bias of senior management/executive comments on AI and its potential. In all, while over 80% of enterprise CxOs are at least claiming to be AI proponents, only a little more than half of telco CxOs made positive spontaneous remarks on AI. But that’s not out of line with some of the enterprise verticals, so it may be that like actual AI opportunity, AI attitudes are a function of the profile of each company and its markets.

Then there’s the “anthropic principle” angle. The principle says that there’s an inherent observer bias, that we see things and interpret the basic rules that govern those things according to what we see, so our own views set our perceptions of the value of stuff like AI. Telco executives, perhaps more than most executives, live in a very structured world and have tuned their thinking to that structure. What fits is what has fit, not what should, and with AI we’re surely in a period when it’s the “should” that matters.

The easy reason is that the 3GPP box-centricity had gone too far by the time NFV came along. But 5G didn’t come along, at least in a deployment sense, until 2019, and NFV launched in earnest in 2012. True, but LTE had already solidified much of the structure of 5G because it was essential that 5G retain backward compatibility with LTE, just as 6G is expected to have to be compatible with 5G. In any case, if the goal of an initiative is to virtualize functions, the presumption (explicit in NFV) has to be that the functions aren’t already virtual, but embodied in boxes or what NFV called “physical network functions”. We need to dig deeper.

The original goal of NFV was to virtualize appliances, as shown in its seminal paper “Network Functions Virtualization: An Introduction, Benefits, Enablers, Challenges & Call For Action”. The key figure in the paper, identifying the targets of the initiative, did indeed include many of the elements of wireless infrastructure, and so it’s totally reasonable to think that the initiative could have targeted some of the key things that, in mobile standards in particular, went wrong.

As a very early participant in NFV, my view of why it didn’t do what it might have done is that the “proof of concept” or PoC process itself. The problem with PoCs is that they’re implementations, which probably should come along only when an overall framework for NFV had been defined. There were PoCs that were useful in defining that framework, and even in addressing some of the elements of mobile infrastructure that we needed to address to fix the box-centricity problem, but early focus ended up on “virtual CPE” or “universal CPE”, which was the use of a general “white box” combined with loadable software to replace customer edge appliances in particular.

The reason this was a problem is that it box-bound the whole notion of NFV, which should have been to unbind from boxes. It’s tough to say why things got so u/vCPE focused, but one factor was surely a hope by telcos that by creating a facile way of deploying edge services like firewalls, they could build some incremental revenue on top of their comfortable connectivity-based services. Again, this isn’t a bad mission, but rather a mission that should have been an application of a generalized model that was never really solidified.

But wasn’t there an overall NFV model released? There was, in an end-to-end architecture that, as is often the case, was depicted as a series of functional blocks linked by interfaces. It looked like boxes linked by connections, and the whole initiative started talking about NFV elements in terms of specific monolithic pieces of functionality. When the Linux Foundation released OPNFV, an “open platform to accelerate NFV” it retained, in fact adopted and implemented, the function monolith model.

A function monolith is like a box-less box, it’s functionality that should be fully virtual made to fit into a single component implementation. MANO, or NFV’s management and orchestration function, should have been kept as a logical function that could be made up of many things, including existing cloud orchestration tools like Kubernetes.

Decades ago, I was managing a project to automate a rather vast and complex enterprise activity, working with a dozen programmers and a set of end-user experts. One part of the task was to automate the contract piece of an information service, and the end-user methods analyst flow-charted it as a series of steps that mirrored the manual processes. The programmer assigned to do the work came to me to say that this wasn’t the way to do it, and probably wouldn’t even work, and so I did a redesign that took the functions and re-framed them in a way that optimized IT efficiency and agility, which did work. That’s the problem with visualizing processes as a series of functional steps; the steps you visualize constrain the implementation.

I’m not surprised that the NFV process went off-track like this; it’s how almost all telecom initiatives went off-track as we attempt the essential process of box-think to software-think transition. I’m a little more surprised that the OPNFV project didn’t address the problem, but the main contributors to it came from the NFV community and so likely thought of the “right” implementation in the way the initial architecture document described. The current OPNFV project seems to have worked to correct the bias, but again it’s hard to step away from work already done and approved by the base body, the NFV ISG itself.

Services, as in any sort of as-a-service, are the cooperative outcomes of complex systems. To create them, you should be able to define the service as such, meaning through the use of a template that calls on intent-model components. They are also event-driven, both to the service user and the service manager. That means that the whole ecosystem needs to be a state/event processes controlled by tables or graphs. This is the only way to get to the goal of function virtualization, since it makes every service feature, in-service or management, a task run in response to an event. Where the task gets run is a matter of operations efficiency, so there’s no requirement to stick it in a monolithic piece of software or in a hard-wired appliance.

The Open Network Automation Platform (ONAP) is another project that fell prey to monolithic-ism. It should have started off with a service template or model and built itself around that by using the intersection of element states and events to define action sets. Instead, it was built on a monolithic event-handler, and that made the whole system nothing more than a virtual box, which we now realize has all the impediments to agility and scalability that an actual box presents.

It’s also true that these points are equally applicable to any real-time system, which means that we should visualize IoT systems as digital twins defined by templates and processing (and generating) events. That makes it all the more important to start dealing with things from a software perspective, given software’s role in providing functionality and making business cases.

OK, can we summarize the reasons NFV didn’t fix the box-centric problem telcos have? Two things, I think. First, too many of those involved in NFV were box-centric, so their notion of a software-driven future was a future where boxes were replaced by virtual boxes, not by abstract functions and features. Second, the nature of the PoC process biased the work toward things that got a lot of vendor participation, and vendors are rarely willing to disrupt their own markets. It’s not hard to see that these same factors created the standards framework that broke things to start with, so unless they’re dealt with in future initiatives, we’re carrying the seeds of defeat forward with us.

Business IT is really about transaction processing. A “transaction” is the modern equivalent of the stuff we used to call “commercial paper”, the invoices, payments, ledgers, reports, and stuff that define business operations and support the essential buying and selling that make up our economy. Commercial paper or transactions originate where business is done, which is widely distributed, but transaction processing tends to concentrate toward the point where databases reside. That’s why early IT was totally concentrated in data centers, and why almost every major enterprise has a data center where things are concentrated and stored today.

Here’s the thing. A company almost always needs a kind of “single source of truth” with regard to things like accounts, inventories, and so forth. If you were to assume that there were multiple databases representing, let’s say, the current inventory levels, you’d need to keep them synchronized to avoid having differences among them result in significant errors, like selling something you don’t actually have on hand. You also need to mediate access to a record to ensure that a collision in usage doesn’t leave it in a bad state. We’ve long had something called “distributed transaction processing” to manage synchronous access and updates.

The concept of a “mainframe” evolved as the early computer systems, designed for single-thread “batch” processing, grew to handle multiple simultaneous programs and online real-time access. IBM’s System/360 was arguably the first mainframe, released in the mid-1960s. Distributed computing in various forms came along in the next decade, and more localized (and eventually “personal”) computing gradually absorbed many of the tasks workers needed IT to help with, but transaction processing still normally centralized on the “mainframe”, so it became a kind of database engine. IBM says “Mainframes are data servers that are designed to process up to 1 trillion web transactions daily with the highest levels of security and reliability.”

That point frames the whole mainframe/Linux relationship. On the one hand, a mainframe data engine, and even a mainframe that hosts applications that demand a lot of database access, is one thing. A mainframe as a continued single source for applications is another. For two decades, IBM contended with the fact that mainframes weren’t the ideal application platform, and that even transaction processing had elements that should be run elsewhere.

IBM’s insight into cloud computing was that the data-server role was a persistent business requirement, which meant that the cloud was a hosting point for more presentation-level functions, projected outward, closer to the user, with the elasticity needed to absorb load variations and to unload an essential choke point in every process, the core database functions. Things like reporting, accounting, and other central business functions are logically more efficient if they’re run local to the point of data storage, so the IBM vision of a “data center” is a mainframe, surrounded by local adjunct servers that peruse the databases, augmented by elements distributed outward, including to the cloud or to desktop PCs.

The spread of processing threatens the mainframe, and IBM took a number of steps to minimize the threat. One was what one enterprise wryly calls the “miniframe”, the lower-end Z-series products that are designed to run in a data center cluster adjacent to the real central mainframe. Another was the effort to accommodate Linux, which accelerated with IBM’s acquisition of Red Hat. The newest LinuxONE stuff, I think, is designed to build a platform that is based on Linux and that can also be that central mainframe, running more database-centric applications as well…applications like AI.

Business analytics are obviously something that’s database-centric, and it’s also the area where enterprises have consistently said offered the greatest potential for AI augmentation. If AI is separated from the data it works on, and if AI elements are separated from each other, then the network impacts the performance of AI significantly, to the point where its value in some real-time missions might be compromised. It’s clear that the latest LinuxONE stuff from IBM is a response to this. Make a mainframe into both a database engine and an AI engine and you have the ideal business analytics centerpiece.

IBM sees the logical structure of IT as a set of concentric layers, the innermost of which is the database collection and the outermost the users of applications, human or machine. That’s logical, which makes the big question why we seem to have missed the obvious all along, and we can divide the causes into “practical” and “cynical”.

The practical cause is the way that computer hardware evolved, toward the integrated circuit, solid-state memory, mini- and microcomputers. This allowed it to be pushed out to the worker level, and it’s natural that vendor and buyer attention both focused on the new things this outward push enabled. Think the word processor, spreadsheet, and other components of desktop office suites. This push opened new areas for computer vendors and software providers, and that tended to focus product news on the outer layers of the model. It was a lot easier to be a new PC vendor than to be a new mainframe vendor; there was no incumbent to fight to displace.

The cynical cause is the combination of ad-sponsorship and search-engine optimization (SEO) created by the online age of publications. A typical first-line manager has the budget authority to purchase a PC, and could very well simply buy one online or at a retail store. Enterprises tell me a typical database-machine mainframe today would cost almost two million dollars, that it’s often surrounded by smaller mainframes costing a couple hundred thousand, and for all of this the purchase process is a long slog through layers of evaluation and approval. The former kind of buy is driven by marketing; you can’t send sales people out to push PCs to line managers. The latter buy is supported by a permanent on-site sales team, and you don’t need to beat the bushes to find prospects; they’re already customers. Thus, all the advertising is pushed by the outer-layer players, and that creates an artificial picture of how IT is done.

One thing this has done is to give IBM a unique position in terms of account control and strategic influence. Mainframe accounts almost always have sales teams, pre- and post-sale support for enterprise project planning. Other IT vendors rarely have this level of persistent customer contact, and so a much smaller level of influence on planning. IBM has a decisive lead in enterprise AI, despite what you may read to the contrary, because they can get their story to the right people at the right time, and because their accounts are the largest consumers of IT.

So why do so many enterprises depend on mainframes? The truth is that for most, a mainframe data engine is almost surely the best strategy in terms of performance and availability. The big problem for the mainframe in its traditional form (The IBM Z-series) is that the software running there is often old, sometimes ancient, and significant modernization pressure on applications can lead to the question of whether the existing software can be updated effectively. I think the LinuxONE mainframes are IBM’s answer to this; you can retain the mainframe engine role but adopt an operating system and programming model (Red Hat software) that is the same as would be used on the layers surrounding the database engine. By linking AI into it, as the most recent stories do, IBM is sowing the seeds of a new mainframe model that doesn’t have the old-software vulnerability. If they succeed, they cement themselves in a strategic leadership position for decades to come.

The wider implications here are even more important. If the layered model is indeed obvious and real, then we should be keeping it in mind when considering almost every development in IT opportunity or technology. You need to run data-centric stuff proximate to the data; that means governance is likely to demand centralization of those applications. The greatest impact on networking is likely to be created by missions that change upper-layer requirements, which is why real-time IoT is so critical. The lesson here is that despite being considered a dinosaur by many, IBM has actually gotten things right here.

First, perhaps surprisingly, none of those who commented were prepared to say that AI was a game-changer. Can it make things better? Yes, in many missions. Will it make a difference in telcos’ long battle against profit pressure? Few think it would, and none thought it would resolve those challenges. Might there be future missions where AI could shine, change things more radically? Some think so, more think it’s too soon to say.

Let me say at this point that all this seems to run strongly against what we all hear constantly about AI. OK, that’s true, but it’s also true that both enterprise and telco comments I get on AI have been noticeably more cautious than the broader media publicity has carried. Some of what I’ve heard even notes this; one telco assistant CFO said “I don’t know who these people are talking to. Nobody I talk to, apparently.” At any rate, I can only say what I hear and you’ll have to judge for yourself.

To dig deeper, we need to look at missions for AI by category. The comments I got relate almost totally to four application areas, which I’ll list in order of mention. First, impacts of AI on operations and opex. Second, impacts on capital equipment and capex. Third, on customer acquisition and retention. Forth, on energy efficiency, sustainability, and resource optimization. We’ll explore them one by one.

Operations missions top almost everyone’s list. Netops, for operators, is increasingly complex, with more different pieces that interact in more ways, creating a web of interdependencies that make fault isolation difficult and raise the risk of “breaking something big when trying to fix something little.” This is, not surprisingly, the only AI application that seems to consistently pay back for those who adopt it. However, there’s a lot of groping around needed to get it right.

The big problem, say operators in comments, is that there’s a management and market conception that operations AI is some giant tool that autonomously runs the network. Senior management often believes this is possible, and some AI promoters play to that. Operators say no such thing exists, and they’d likely not adopt it at this point even if it did. Networks are an interlocking grid of technologies and vendors, and netops has always been the same. They’d like to see AIOps work that way, a set of technology- or area-based tools that were then somehow aggregated into a master viewpoint. They also see these tools as a kind of “manufacturer’s rep” expert sitting at the elbow of the network operations professional, offering diagnostic help, recommending actions, and warning of consequences. Might, over time, something more autonomous be accepted, even sought out? Sure, most say, but this isn’t that time. Still, this particular mission gets a rating of justified from almost all those who commented.

Savings on capex comes up mostly in relation to mobile operators and optimization of tower locations, spectrum, beamforming, etc. Less than a third of operators say this has a clear capex benefit though; most really relate the benefit to “optimizing” RAN costs and maximizing user quality of experience to avoid dissatisfaction and churn. They point out that, with mobile networking, periods of high use tend to be created by a broadly impactful condition, like a traffic jam, that requires urgent communication, even just to tell someone you’d be late. Too many cases where the network overloads locally because of this, and you lose a customer.

AI in 5G RAN, though, may be one of the most oversold missions as far as demonstrable ROI is concerned. This is the space where most operators tend to say that there is an application for AI, but even considering things like churn, it’s difficult to find a capex justification for it, and it’s never transformational.

Regarding customer acquisition and retention, we can already see the potential value in the comment on mobile capex AI above. Operators most often mention the need to frame network behavior to respond to major events as they are happening, not when people start to complain. In most cases, they say, you could predict vehicular traffic-driven issues because you see the movement of vehicles through cells, the density per cell, conditions in the power grid, weather events, and so forth. Could AI predict, correlate, and even establish a set of operating states that it could invoke (with human consent or override) based on analysis of the then-and-now compared with records of past conditions? It could, they believe, but right now it doesn’t do that.

There’s also a lot of interest in using AI to analyze marketing campaigns and the demography of those who elect to change their operators. What works best to acquire customers, what offers operators the best return on any premium cost they provide, and what kind of prospect returns the best over time? Some work is being done here, but not as much as you’d think. So far, most believe this mission is justified, but it’s still early.

With regard to overall energy efficiency and sustainability, it’s a mixed bag. About a third of comments suggest that those who have used AI in these applications have gotten favorable results with few failures, they also note that the impact hasn’t been substantial, at least not yet. “This is really something you have to look at as a long-term planning activity,” one said. “We haven’t run the program long enough to broadly impact power and cooling decisions because things already in place can’t be redone to make them more efficient. That’s inefficient.”

Operators are also mixed on the value of the “social capital gains” they would achieve from this application of AI. They point out the strong political division on the issue, and the fact that a change in government can quickly reverse the perception of sustainable operations. That’s focused them more on a direct power/cooling benefit, which as I’ve noted above is easiest to achieve when planning new deployments, and so can’t be fully effective immediately. “We think a lot about ‘first cost’ and so we think about ‘last benefit’ too.” They want to minimize both, and having the former and latter together means having ROI back-loaded to the extreme, at best. Rate this one as an application of AI that may, over time, prove justified.

The point here is that while telcos are still optimistic about AI having value, they’re far from demonstrating the value is transformational, and they’re not totally sure that any of the AI missions will always make a business case under current financial guidelines. In this regard, they’re not as “in” on the AI topic as enterprises, who generally believe it could be transformational even though few have really even proved it to justify the investment. Telcos are more uncertain, and none of them defined the kind of AI-centric projects that are starting to pop up at the enterprise level. In some ways, that’s surprising given that telecom is a vertical, where enterprises reside in many verticals, and concentration of interest usually makes it easier to focus on technology solutions. In other ways, given that regulations have often barred collaboration among telcos as collusion, it’s perhaps less surprising. Whether lack of experimentation will hamper further telco AI progress remains to be seen.

The thing that stood out to me was, paraphrasing one operator friend “OK, this is in fact a mess. What would you do differently?” That’s a good question, and one I’ll try to answer, taking into account the comments of the 51.

The challenge operators face is that they sell into what’s become and likely will always now be, a telecom market dominated by consumer issues. That means the demand side blows in the wind, and that tendency is exacerbated by the fact that today’s network is dialtone for OTTs to deliver proof-of-concept, fast-fail, tests that if successful will launch the next opportunity, the next driver for the underlayment the network provides. But at the same time, operators are tied to a stake in the ground created by long expectations of useful life for what they buy. The stake is seven to fifteen years’ deep, too deep to allow for rapid infrastructure change. This is a contributor to the supply-side mindset; you plan based on your capital constraints, set in no small way by the long depreciation cycle you need.

This, I think frames the challenge. What about the solution? Can it be found? Well, if we think about it, it already has.

Enterprises have some of these same problems, and the solution they’ve hit on over time was the notion of commodity hardware, open middleware, and modular software. If operators want to be successful with their supply-side mindset, then they have to do the same, and to do that they have to shed a persistent bias.

Which is the “box mindset”. To telecom types, network features are created by devices. Those devices present physical interfaces that link them to other devices over network connections. Because the features you define are box-bound, even an evolutionary view of services threaten to displace current technology. They also constrain you in terms of evolution, compatibility with the past. If you need to interwork with Generation A in Generation B, and if both A and B are device-based, then you tie yourself to the early generation just to phase in, and that limits how much you can advance. This has to go.

The starting point for the right approach is simple; functionality is created by software, and hardware is just something you run software on. The functionality for any given mission, then, should be a series of logical components that offer units of functionality. These units interact with each other via APIs and exchange messages via these APIs. You don’t think in terms of defining interfaces but in terms of defining APIs. If the APIs link things that aren’t local to each other, you may have to carry the messages between them on a network connection, but the messages are the meat and the network connection is just the condiments.

You have to map these logical components and their APIs to hardware, eventually, and in order to do that you have to rely on the same sort of resource abstraction that’s been around in IT for decades—the operating system and middleware. For the former, it’s logical to consider Linux to be the presumptive target. For the latter, you have two sets of issues to consider.

The first set is whether the requirements of the mission puts special performance, cost, or other requirements on the components you’re hosting. If your mission is to push packets, a data-plane mission, then you have to assume that you need special chips to handle the pushing. The middleware then needs to supply a set of bicameral “drivers”, with one side of the driver exposing a common function set and the other implementing it on a given chip type. The P4 language for switching is an example. The goal here is to support a set of logical functional elements on whatever is the best modern hardware mechanism available for the specific set of trade-offs you have to work with.

If you’re not pushing packets, then your messages are “control plane” messages aimed at managing the functions and their cooperative behavior in fulfilling the mission. For this sort of thing, you have to look at the relationship the functional components have with each other to fulfill their mission. Maybe the relationship is a simple peering, maybe client/server, maybe a community of partners, maybe a set of sequential process that’s either source-steered, hop-by-hop, or orchestrated…you get the picture. We have middleware tools designed for all the possible relationships we could ever expect to encounter in telecom, and we’d surely lose nothing by mandating that no relationship-managing model could be standardized if it didn’t map to a model we already have proven out.

The second set of issues relates to the intrinsic or useful level of function execution and distributability. Do the functions’ ability to support the mission demand they be collected, or can they be distributed in either groups or individually? Can the components be scaled by multiplication to handle loads? How do they maintain state? What data do they require? Is the model here suitable for cloud hosting, and what are the economic issues related to the features it would need? There’s middleware available to handle almost every possible way software components are organized and workflows are threaded, so it’s a matter of picking something. This step, interestingly, is often attempted, and sadly it almost always leads to a failure.

It’s not that this is the wrong approach; it isn’t. It’s not even that the person or group developing the functional map or model does it wrong. It’s that it’s used wrong. We see this almost everywhere in telecom, including in LTE, 5G, NFV…. People interpret the functional model as a network of devices. You can see this in the way that NFV developed, and ONAP as well. They map work paths to, or like, device interfaces, and they build a monolith whose rigid structure guarantees that if by a miracle it manages to serve the mission that stimulated its creation, it won’t survive a year of evolution.

The function map does has its challenges. As a software architect, I saw many enterprise applications that were first defined in a “flow chart” that described not a good way to do something, but rather the sequence of manual-based steps that work would go through. Having something modeled on an inbox-outbox human chain is no better than, nor different from, having a set of boxes linked by physical interfaces. A function map has to be developed with the best way of combining the functions needed; if it starts by assuming the functions are discrete devices, that’s how it will end up.

I’ve seen, and you’ve likely also seen, some industry initiatives that have tried to apply some of these principles (MEF comes to mind), but I don’t think of this process as a standards activity as much as a methodology that standards activities should apply. The fact is, particularly for telecom standards, there’s generally only one body that can really set standards, and that’s not going to change.

I’ve looked at a lot of telecom standards in my career, and none of them were framed with the goal of achieving the separation of function and function hosting, software and hardware, that enterprises take for granted. That has to change or we’ll never see a successful telecom standard again. The old way of standardization cannot deliver it.

We’ve all heard jokes about meetings and consensus. “A mule is a horse designed by committee”, or “The IQ of any group is equal to that of the dumbest member divided by the number of members.” Wry humor aside, there’s an element of truth in this. One problem with telecom is that you need broad consensus for something to be accepted, and achieving that consensus is inevitably a matter of compromise. How do you avoid compromising too much, giving away the essential value of what you’re working on?

Telecom standards are created by two distinct groups who often have polar opposite needs. One group is the telcos, who are at least usually on the same page at the high level. This group is primarily concerned with controlling the cost the standard might expose them to, and in practical terms that is often focused on avoiding the displacement of gear that, in the telecom world, is often written down over a very long period. The other group is the telecom vendors, and this group is usually at each other’s throats in rabid competition for spending that may be under threat overall, and may be further impacted (higher or lower) by the standard.

My own experience with standards bodies, going back to the 1970s, has led me to believe that the starting point in standards problems, and therefore the first target for solutions, is the nature of the telecom people working on them. Most telcos have a formal group under the CTO who participate in standards. This is good in the sense that they bring a sense of order to the process, which might otherwise get pretty chaotic. It’s bad in the sense that these people rarely have much exposure to the demand side of telecom, and so can’t bring a picture of future market need to the table.

I remember one memorable early meeting, where I saw the agenda for the day was “Who are we?” This sure sounded more existential than useful to me, but the leader explained that when a report said “We believe…” or something similar, there was a need to be explicit on who “we” were. We spent a full day on that.

I think that a telco standards team should be made up of equal numbers of standards people and marketing/sales staff people. The former organize, the latter set the mandatory demand-side focus by introducing market factors and ensuring that the process continually addresses them. This division should be reflected in the nature of the agenda and the structure of the document. An early section needs to address the specific new revenues that the standard is to facilitate.

My experience also says that vendors in a standards process are inevitably disruptive. Not all of them, but enough to taint the whole process. I can honestly say that I have never participated in a standards process that wasn’t eventually contaminated by vendors who sought their own advantage even at the expense of doing something optimal in a total-market sense. The biggest problem always comes from incumbents, who reason that given they’re winning under the current paradigm, any paradigm shift is bad for them.

The IPsphere Forum actually found a way to address this that, for quite a while, worked. What they did was to establish a “service provider council” whose meetings were for operators only, with others allowed to speak at one only by invitation. The SPC laid out the framework for something, and only after that was done, and staying at all times consistent with it, was a broader group that included vendors formed to address the concept and turn it into a real model.

The next issue I saw, and that needs addressing, is a notion that consensus means unanimity. Going into the process, there must be a realization that a single individual/company or even a small group cannot block something the majority favors. It’s fine to say that you need more than a simple majority, but whatever you decide has to agree, you must allow members of the group to call for a vote to end discussion and move forward. This is critical not only at plenary sessions, but in working group meetings as well. Regular votes on points is smart so it doesn’t look like you’re only doing it to shut out dissent, though that’s necessary in any group meeting.

The last issue is simple; rate of progress. Standards groups don’t meet often enough to make significant progress even in a year. If F2F meetings more regularly is a burden, everyone is used to online virtual meetings at this point. Every telecom standard takes years to mature, and there’s no way that even the best futurists can hope to anticipate needs too far into the future. We are working on 6G, for example, with an expected early availability of 2030. Who can possibly know what conditions will prevail then?

OK, the issue is simple, but the solution may not be. Neither classic telco supply-side planning nor the yet-unrealized vision of demand-side planning seems likely to generate a five-year window of visibility, which is why I think that the efforts have to focus on getting results quicker. The telco interest in a 6G model that’s software-only, or at least primarily software, is in effect a mechanism that could speed up development of a deployable version of a new standard. Why bother if you’re waiting five years to even offer a final version to deploy? In any event, if we really want to start to focus on software (which I think we should), then a primary step that could be taken as a kind of “5G Advanced Next Gen” would be to frame 5G implementation as a set of generic devices rather than as special-function boxes.

One thing that has hurt almost every standards initiative in the telecom space is a tendency to encapsulate logical elements of functionality into boxes on a diagram, which then tends to get them implemented as discrete devices. How far might application software progressed if we did that in application design? We’d still be reading punched cards or paper tape. Even little steps in an outdated process need to be modernized, lest they anchor us in a past we can no longer live with.

Revenue per bit is not a particularly good way to measure telco profit potential, or at least not a comprehensive way. Over time, because of technology improvements, it’s common to see the marginal cost of bandwidth decline somewhat. The big problem is a lot more complicated. Over time, the broadband total addressable market (TAM) tends to plateau simply because the number of unconnected users declines in both consumer and business sectors. At the same time, the utility of broadband and the number of things users want to do with it stabilizes, which means that average revenue per user has little upward drive. Competition, then, actually lowers ARPU. However, whatever the source of the pressure, there is no question that telcos are under pressure to sustain and even raise profits, and natural forces are pushing in the other direction.

Neutrality poses a problem for two reasons. At the high level, the fact that the Internet model has always been one of bill-and-keep, and because rules often prohibit priority handling for a fee, it’s difficult for access providers serving the consumer market to share in the benefits created by large traffic generators like streaming video. While this rule isn’t always in play, given that telecom regulation is essentially political, the fact that it might be imposed again when there’s a change in government means operators can’t rely on a policy over time, which means they aren’t likely to deploy a premium service model.

The business services side is also critical in the sense of TAM/ARPU growth. Obviously, the number of business sites grows primarily as the retail presence for walk-in grows, and if anything online services in many forms has been pushing more and more in the other direction. The number of satellite sites of multi-site businesses has been shrinking gradually for about six years, and it’s this kind of site that generates new adds to an MPLS VPN. In addition, enterprises increasingly rely on the Internet and cloud to reach prospects, customers, and partners, simply because no other economical option exists. Given that, there’s a steady pressure to reach small office sites the same way, and since “business” forms of what’s essentially consumer broadband Internet access are steadily improving in QoS and availability (Comcast, for example will offer SLAs on theirs), the reasons to pay for MPLS/Ethernet access to sites are weakening.

All these changes are creating competitive options for the “interior” part of network services, and leaving traditional operators little more than the access piece. This happens to be a third of the total capex and almost 60% of opex, and thus the least profitable part of a network. It also includes mobile infrastructure, which has a history (with 5G) of driving a significant wave of investment that generates minimal return.

So, the net of all of this is that telecom as a business is being marginalized, and nothing is going to save it short of new revenues or new subsidies. The latter is obviously something that would likely be considered as a last resort, and that is surely a political issue. Thus, we have to look at the former.

Operators have tried to enter OTT service competition, and have generally not been successful for many reasons not worth going through again. Suffice it to say that the humor definition of insanity is to continue to do the same thing while expecting different outcomes. The only realistic form of new revenue would therefore have to come from either an extension of a current operator access service paradigm, or competing in a completely new area. As it happens, the two are likely related.

You can’t invent consumers or businesses; when the TAM has plateaued, you’re done in those spaces. However, you can serve devices independent of both, meaning some form of IoT. This truth was accepted by telcos, but with was (let’s face it) characteristic myopia, they saw it as meaning that you sold cellular plans to IoT devices. Obviously that’s not practical in most cases. Further, operators saw this as a simple connection mission, without considering the fact that devices are not inherently sociable and thus don’t talk spontaneously among themselves (please don’t tell me that AI will create just that sort of device!). So, if you want to sell access to gadgets, you need to have an application framework that creates both your opportunity and a viable value proposition for whoever/whatever is going to pay on their behalf.

There are probably over a billion IoT devices out there, the percentage of which are served by a connection some operator is getting paid for falls below statistical significance. Consumer IoT is almost completely associated with various elements of the smart home, including security, lighting, and heating/cooling, and WiFi and the Internet make any connections not made by wires or a special control protocol like Z-wave or Zigbee. Business IoT devices are largely installed in fixed facilities like plants, warehouses, etc. In some verticals, like healthcare and utilities, there may be an opportunity for mobile services, but enterprises say that where WiFi would not serve, they prefer private cellular services to a public operator because the devices are operating in a small geography.

So what happens, what could be a positive? The most obvious thing would be some application that relied on a lot of mobile IoT elements, a lot of new elements placed where wire connections could be expensive, or both. The problem, as it often is with the stuff that’s supposedly obvious, is that even identifying such an application is a challenge, and showing how it could make a business case for the buyer/user and all the stakeholders is even more so.

There is genuine momentum in industrial IoT applications for 5G/6G adoption, but far less so for public IoT services. Part of that is due to the fact that the vendor stakeholders in the applications are reluctant to make a push in the absence of any tangible service offerings with specific prices and features, and telcos have been slow to take the initiative in providing tangible/specific stuff absent specific use cases. Classic chicken-and-egg.

The cloud providers may end up being the players who break the deadlock here. They’re a middle player in the story; something that applications run on and networks connect to. While that may help get things moving, the driving player in any new initiative seeks to maximize their own value, and to make the initiative appealing to buyers, minimize the take of any other player. The network operators need to think about that point going forward.

The long-expressed 6G latency goal is a microsecond, so let’s start by looking at what that means. One one-millionth of a second, obviously, but in practical terms, it depends on how fast the things that are important to you are happening. A vehicle at 60 mph would travel about nine-one-hundred-thousandth of an inch. A person walking would travel five percent of that. A jet, ten times that far. So, it seems, we could argue that a microsecond latency goal is pretty hard to justify as a hard requirement.

It would be at least as hard to achieve. 6G radio waves in air would travel roughly 300 meters (a thousand feet, approximately), and data over fiber or copper roughly 680 feet. With apologies to edge enthusiasts, it is simply not economically reasonable to assume we could make cloud-like shared hosting resources practical if they had to be within a thousand feet of where they’re needed.

Suppose, though, we tie these two points together. What is a practical level of latency? I don’t have totally convincing or consistent views on this from enterprises and experts, but here are some. All these numbers represent estimates of reasonable round-trip delays for a control loop, including message propagation and processing.

For autonomous vehicle operation, the average answer is 50 milliseconds. In this amount of time, a vehicle would move about 4 feet, but it’s still at least 5 times faster than driver reaction.

For industrial process control, the average answer is 20 milliseconds, but some high-speed process control can require round-trip delays of a tenth of that, and others can tolerate up to five times that much.

Enterprises who offered actual local edge round-trip latency numbers report that both propagation and processing latencies in their applications are between 200 and 300 milliseconds. Only 11 enterprises said they achieved 50 ms, and only 2 said they had any applications that delivered 20 ms. In all cases, these local edge applications were connected to real-world systems using wired sensors, and there was no significant network handling. The edge hosts were, on the average, less than 150 meters from the processes they controlled, which means propagation delay could be ignored. The current primary source of latency, then, is the compute processes themselves.

Think on that a moment. In the average 250 ms latency users achieve today in an almost-processing-only situation, a vehicle would move 22 feet. An assembly line, say enterprises, would move an inch. Given this it would be easy to conclude that edge computing is hopeless for any new distributed applications, no matter what network latency was achieved, but that doesn’t consider two important factors, the distribution of event processing, and the nature of the real-time system overall.

If we assumed that an autonomous vehicle could achieve brake activation only after 22 feet of movement, you could visualize a lot of accidents, but the truth depends on what event stimulates that activation. Today, autonomous actions in vehicles are usually triggered in anticipation of a threatened condition. In my own car, I’ll get an alert when backing up if any motion is detected, and braking will activate if the motion is within a warning zone outside the actual vehicle path. In other words, the overall system builds in latency tolerance.

Distribution of event processing is often combined with this. If you want a bolt to be inserted in a hole, do you wait till a sensor sees the hole in front of the bolt-inserter? Hardly. You assume a consistent speed of hole-motion, and synchronize the insertion to the position of the bolt, considering all the latency factors. It’s like shooting at a moving target. But you could also use either a mechanical system or a simple local processor (think something like Raspberry Pi) to synchronize something that requires extreme precision. This is what those who actually achieve very short control loops (low round-trip delays) do.

User comments suggest to me that it’s worthless to look at network latency in IoT or real-time process control unless you can trace the totality of a control loop and assign latency to each piece. When you do that, or try to, it’s clear that the real issue in edge computing is less likely to be latency, and more likely to be processing delays and economic factors inherent in shared hosting of anything.

While a network device isn’t a computer, it’s a computer-driven element. As such it has its own delay contribution, ranging from roughly 15 microseconds per packet for simple switching to roughly 1.5 milliseconds for more complex processing. To this, you have to add any queuing delay. Current reported average latencies for an Internet-level amount of handling are approximately 2 ms per hundred miles excluding access serialization delay. LTE achieves total latencies reported as 12 ms, and 5G has some reports as low as 2 ms, but this has to be added to latency from the Internet, where used.

Overall, what seems important is to establish a kind of “layered” approach to event process hosting, and in particular lay out standardized APIs for the control loop’s threading through the layered elements. The presumption would be that where the loop length is less than roughly 10 ms, you’d attempt to support the loop using a locally hosted (on-board) element.

Beyond this local element there are a lot of questions, and there have been plenty of proposed answers but little consensus. About half of enterprises see relatively little need for anything in the way of a shared hosting service short of the cloud or data center, meaning that all the critical timing is handled by the local processing resource. The half who see a value see it where latency loop limits are no more than 50 ms. This seems in a network sense even assuming you had an edge host per major metro area (over 100k population), but it’s not clear that processing economy of scale could be achieved in all those locations, and the first cost to position resources at that level could be problematic.

That, friends, is the real issue in real-time services. It’s not network latency but pool efficiency, and that also relates to the applications’ structure and performance. To share a resource is to wait for something to become available, which means that you have to add to the control-loop length. Price a shared resource optimally, you have to run at a high utilization while sustaining a low resource queuing time, which means you have to have a lot of capacity and a lot of use. The total round-trip control loop length is really set by the distance you have to haul things to achieve pool optimality, factoring in a willingness to pay more for the premium latency. That distance determines whether the network really contributes, positively or negatively, to the overall latency picture and to the application’s value proposition and business case for buyer and seller.

The important point to make on 6G here is hopefully clear by now. Absent a solid and optimal model for process distribution, we can’t know what the actual requirements for 6G latency would be, and we can’t know whether there are other issues that are more important. One example enterprises offer is packet loss. Typically, QoS parameters like packet loss and latency are traded against each other, but in real-time applications packet loss is a potential disaster. 6G, then, may actually be aiming at something very different than the most important class of applications will need.

The increased role of public cloud services as a front-end application element, and the growing tendency for enterprises to think of workers, customers, and partners as roles within a common hybrid cloud application set, has meant that many enterprise traffic flows have already abandoned the MPLS VPNs in branch locations, flowing instead from Internet to cloud to data center.

Google’s Cloud WAN, Amazon’s AWS Cloud WAN, and Azure Virtual WAN are all cloud provider services that aim to increase the role of the cloud provider in what was once a branch-and-HQ MPLS VPN lake. I’m not seeing, or hearing about, any major initiatives from cloud providers to take on branch connectivity missions for non-cloud customers. Enterprises also, so far, seem not to be looking for that sort of relationship, but changes could be in the wind.

Recall my comments on the possibility that something IMS-like might create an opportunity to steer traffic by QoS? Well, these cloud WAN services are all essentially fast paths from the Internet (for access to the sites) to the cloud WAN. If we presumed that there was a fast path from the user to the cloud WAN on-ramp closest to them, it might then create a QoS facility for the cloud WAN that was better end-to-end than an externally provided SD-WAN solution.

Another possibility related to that is the chance that some form of access network partitioning, not unlike wireless network slicing, could offer a way to separate premium services. Would this violate net neutrality? Who knows? There have been times, particularly early on, when neutrality policy also excluded services that aimed at Internet bypass in order to offer paid prioritization. There have been times when it allowed it, and probably times when sunrise and sunset might have been under suspicion. Let’s face it, neutrality policy is in the eye of the party in power.

Another Fierce Network article raises a third possibility. Lumen Technology, who in the first of my Fierce Network pieces was cited in its partnership with Google’s Cloud WAN, is of the view that the Internet is not the enterprise, or the enterprise network. Lumen proposes to build something that is, a fabric if high-capacity Ethernet trunks that link the cloud providers and enterprises. He’d like to connect the local hubs of all these providers too, and I’d not be surprised to find Lumen connecting some major enterprise sites and partnering with metro/regional fiber access players, too.

This is one of those good-news-bad-news things. Enterprises would surely be happy to see cloud providers offer competition in premium business services. Cloud providers would, of course, be even happier to sell them. Telcos? Well, that’s where bad-ness comes in.

Telcos are, as ISPs, more likely subject to neutrality rules, including wavering policies on Internet bypass. In the US, the original justification for extending net neutrality in that direction was to prevent non-neutral services, because they were more profitable, undermining Internet investment that directly impacts…wait for it…voters. The risk, they see, is that cloud providers with no neutrality issues to worry about might end up providing those premium services and increasing the disintermediation the telcos already suffer at the hands of OTTs. Before, they were disintermediated from higher-level, more valuable services. Now they could be disintermediated from services in their own zone.

On the other hand, might operators who used 5G or 6G IMS and network convergence (the much-hoped-for “all-IP network”) offer what I previously characterized, based on some insightful comments, as nIMS across wireline and wireless? Remember that IMS spec calls for specialized bearer channels based on service requirements, and it seems unlikely to me that 6G would deliver on microsecond latency for everything, which suggests that low-latency might be an example of a service requirement for a specialized bearer channel.

This last point may be critical, because it illustrates a paradox that’s been created for the network operators. On the one hand, they’re buoyed by the hope that new applications in general, and new real-time applications in particular, are a major future source of revenue for them. The same thing, I must point out, is the hope of edge computing and many who envision a “smart” future. On the other hand, these applications will surely demand latency and availability guarantees that are not justified for the Internet overall, and may not be economically feasible if they have to be presented on a no-extra-charge basis to everything.

Best-efforts Internet isn’t an ideal, optimal, or perhaps even compliant service on which to base real-time applications. We need to accept, at the policy level, what we’re mandating economically and technically. Real-time is the next time we need to be worrying about. It’s likely that a real-time application would demand a subset of Internet features, optimized for low latency and high availability. Getting to that could happen, in theory, either by refining how real-time-enabling features work, or separating real-time from the Internet. Cloud providers, who are also the most likely players to take a shot at the real-time-dependent edge computing space, have a big incentive to try to advance those special features. Could they do it themselves? Yes, deeper in the network, but not likely in the access network unless the features become part of “standards”.

Could it be? In theory, mobile services (IMS, 4G, and 5G) support multiple data network gateways, so theoretically a cloud provider could offer connection to one of their hubs. Would an operator themselves be allowed to offer something like this? I’m skeptical. This would, in my view, create a reversal of the past policies aimed at keeping operators from exercising an unfair advantage due to their position. Could neutrality put them at unfair disadvantage here?

There’s a potential collision between public policy in the traditional sense, and the health of the market that, to the FCC and many other regulatory bodies, is the primary goal of regulation in the first place. We have standards and technology trying to advance, but at risk to running into a barrier created not by technology limits or economics, but by a policy. The role of the Internet has evolved to be truly the modern equivalent of dialtone, and we need to think about that in technology planning and regulation.