Light Reading notes, in THIS piece, that the problem with 5G stemmed from the failure to realize the IoT connections that were claimed for it. We have, today, roughly 4.7 billion cellular IoT devices according to my modeling (LR quotes Ericsson as saying 7.5 billion, but I don’t see that as credible). That’s a tenth of what a Cisco 5G cheerleader told us to expect by 2020. So sure, under-realizing device connection potential destroyed a telco pay-for-connections revenue plan, but that doesn’t address the question of whether telcos could have done anything to connect more devices.

Vendors, of course, always want to portray an exploding need for their product. Get your capacity in place right now, dear telco, or be swamped by a zillion sensors who will be demanding connectivity. Your competitors are already plotting how to divide up the sensor customers you’ll lose. The threat of IoT explosion was enough to serve vendor purposes. But why was this all hype and nonsense? Don’t we have real applications out there? It depends on your definition of reality.

I had a nice exchange with a public utility who used cellular connectivity for meter reading. They pointed out that the big problem with the notion that every metered service would evolve to use cellular-connected meters is that the cost of this transformation to and execution of an IoT strategy has to be significantly less than the cost of reading the meters manually. That cost includes the cost of the new cellular-linked meters, the cost of installing them, and the cost of the service used to connect them. This utility said that their meter-readers read an average of 600 meters per day, and the meters had to be read only monthly. For this utility, the cost/benefit of cellular reading was unsatisfactory. The point is that most of the hypothetical applications of cellular IoT are really extensions of simple transactional missions, which means that you don’t need the connectivity until you’re ready to generate a transaction. The thing that transforms the mission is the introduction of some process-control requirement. Suppose you want to be able to identify a customer whose usage rate is suddenly abnormally high, to avoid having something like a leak or short consume more than you’ll likely be able to bill, risk damage to a facility, or whatever? Suppose you’re going to manage usage in peak periods? Now it’s a lot easier to justify real-time connectivity, but those missions are a fraction of the total IoT missions today.

Rural areas pose a much greater challenge to manual reading, of course. One rural utility told me they could read only 10 meters per day per reader, and extensive vehicle use was required. However, they also said that they used their meter-readers for other missions, including inspection and replacement of equipment. This utility was very interested in RFID or “proximity” reading, where instead of having a call-home capability built into meters, the meter simply responded to a query issued by a reader that might simply drive past. Proximity automatic meter reading lets readers do thousands of meters per day, and the cost of a cellular connection is eliminated.

The point here is that everything that you could do in a theoretical, technical, sense isn’t necessarily going to be a smart thing to actually do. Marginal business cases rarely realize the full market potential of a technology, and encourage a search for alternatives, even non-technical ones or simply one that stays the present course, that can build ROI better. The best solution would be to find non-marginal business cases, but an alternative would be to lower the cost points for the stuff that’s already being considered.

The problem with Door Number Two here is that telcos can’t control all of the cost elements. Many of the 5G and proposed 6G connectivity options target what’s essentially a message-based service, whose costs would be proportional to the number of events reported rather than the number of devices, However, anything like this will lower telco revenues and impact the business case for the service-facilitating infrastructure investments. It doesn’t mean that the new sensors or their installation will be less costly. This sort of IoT, then, doesn’t seem to offer a real mass-connection opportunity.

So what might? Telco experts seem to be collecting around the potential offered by smart glasses, meaning AR/VR, and utilities are also interested. The two groups have different visions, however. Telcos see the glasses as being cellular-connected, where utilities see them as an extension to phone/tablet connectivity. The difference, the comments I get suggest, comes from targeting presumptions. Telcos seem most interested in seeing smart/connected glasses as an evolution of smart glasses, a pathway to device connectivity. Utilities see the glasses as tools in worker empowerment, facilitating tasks that are likely to involve smartphones already. For example, most utilities see the glasses as a means of linking a worker to diagrams/photos of complex equipment to guide operations/maintenance, and in these missions many workers also rely on smartphones to access reference material.

Consumer missions for smart glasses may be the most essential element in a 6G future, but not likely in the form that telcos seem to expect. I don’t think that smart wearables need to have their own cellular connections; nobody who depends on one would be likely not to depend on a smartphone even more, and the wearable is indeed a logical satellite to a phone. But visual integration between technology and the real world, tight and optimally useful integration, has to involve video both to capture reality and to communicate between the tech world and the real one. If telcos hope to sell 6G service to glasses, they need to come up with some realistic reason why a direct connection would be needed, and that’s true for IoT applications across the board.

I remember when computers didn’t use chips; a 16 Kbyte machine that was slower and less powerful than a smartwatch today was three feet wide, five feet high, and seven feet long. The cost would have been more than almost any home at the time. Chip-based systems are why we have personal computers, smartphones, and even AI. They shrunk computing down radically, not only in size but in power consumption, cooling requirements, and cost. Chips were behind the computer revolution. What’s next?

I think that we can expect to see continued improvements in the sort of chips that make up personal computers, smartphones, and wearable technology, but I think the focus of the advances is going to shift, away from the general-purpose model and more to the system-on-a-chip (SoC) and to becoming specialized to the mission. This means that the chip wars will focus increasingly on AI and quantum computing.

You can rightfully wonder why that is, and the answer is simple. General-purpose computing is not infinitely distributable; once you’ve let people carry a smartphone you’ve hit a point where the value of shrinking the device hits the utility. I have a smartwatch, and while it can be (and sometimes is) a useful adjunct to my phone, most of its utility comes from non-traditional compute missions. Chips are important, in a financial impact sense, because they facilitated compute distributability, which means that underneath it all, it was the ability to distribute computing that mattered. Further distribution of computing will be about embedding it in special-mission devices, like wearables and IoT elements. For that, they’ll need to support the mission of the thing they’re embedded in, and that will mean stepping beyond general-purpose compute into things like AI/ML and quantum computing.

We are in the mainframe era of AI. The top-line Nvidia chips (the B200 or H200) runs more than I paid for my car and requires racking and cooling, making them minimally distributable. We are going to see the same trend in AI that we saw in computing; chips will shrink the size of an AI agent host to the point where we can deploy it closer to the processes and people it’s supporting. At some point, we’ll be able to embed it in things, first large expensive things like machinery and vehicles, and eventually in cameras, glasses, and sensors. If you want to see an AI revolution, this is the way it will develop, not through more and more B/H200 chip installations. Sorry, Nvidia.

The same thing is true of quantum computing, except that it is arguably in the pre-mainframe stage of evolution. The earliest computers were so large and expensive (they were based on vacuum tubes) that enterprises really couldn’t afford them; they were research tools. When I went to the University of Pennsylvania, the floors in the Moore School building where the first general-purpose programmable computer (ENIAC) was housed were permanently warped by the weight (30 tons) and heat that 18,000 vacuum tubes created. Twenty years later, we had IBM System 360 mainframes a hundred times as powerful for five percent of the cost, and twenty years after that the IBM PC that could match the bottom-end 360 in power for less than two thousand dollars. I don’t think that the realization of quantum computing will take that long, but there’s no doubt that it won’t come overnight. When it does come, it will be quantum chips that bring it.

Enterprises who follow the leading edge of these sorts of thing say that the driving force behind “real” AI and quantum computing is the need to distribute intelligence to the things we do and use, at work or otherwise. They’ve always seen AI agents, for example, as pieces of AI technology that can interact with business operations and workers’ activity directly. This, to them, leads things toward real-world, real-time AI missions. One enterprise AI expert told me “If you put AI in a hyperscaler data center, you deploy maybe a hundred thousand units. If you put it in a sensor, you could deploy a hundred billion units.” The idea behind that, the justification, is that once you believe in the AI agent, you’ll want to embed its intelligence in stuff to make the stuff self-smart. An autonomous vehicle that’s run by a data center will never be truly safe; one that’s smart in itself can be as good or better than a human-operated vehicle. And, of course there are almost two billion vehicles on the road today worldwide, and another ten million industrial/construction vehicles in factories, warehouses, and job sites. That’s a big market, with a big economic impact.

People believed in “time-sharing” computers in the late 1960s and early 1970s, but they were quickly devalued by minicomputer and personal computer advances. Distributable always wins. What can’t be distributed is almost surely doomed not to be revolutionary; it takes massive deployment to make a revolution, so this is what we need to be looking for in both AI and in quantum computing. Everything else is simply a side-show at best, and pure hype and nonsense at worst. Today’s AI is yesterday’s time-sharing, doomed to be overtaken by chips. Same with quantum computing, but in that area, we’ve not yet launched the presumption of a revolution that might actually be delaying an actual one.

To understand why, we have to address two questions, “What chips?” and “From whom?” Both are difficult at this point. Right now, what enterprises are saying is that embedded, distributed, AI is likely to look a lot like machine learning or a pre-trained small-language model; edge AI goals are specialized to the mission that justified the distribution in the first place, the thing that created a need for a local response to an event. However, there is a value to creating a more generalized chip; manufacturing and distribution economies would be better, and it would be more capable of being repurposed, perhaps lending to building a durable business case.

On the “who” side, enterprises are mixed with regard to their views on Nvidia’s role. Some think they’d be the obvious ones to bring out distributed chips, given that they’ve been active in promoting “world model” deployments for AI. Others think that they’re too fixated on selling to hyperscalers, which dictate big expensive chips of the type that makes up their primary revenue source today. Certainly the Street would be concerned about any visible shift in direction.

There’s a chance nobody does this, of course. The problem I see is that we’ve not been talking about what enterprises consider “realistic AI business cases”, most of which would lead to real-time missions and distributed AI. Enterprises are not progressing with their self-hosted AI nearly as fast as they thought they would; almost two-thirds who expected to deploy “significant” AI internally this year now say they won’t meet that goal. The reason most offered is that senior management tends to believe the popular cloud-hosted-expensed-AI approach, making it hard to drive self-hosted projects. This creates a kind of negative feedback; lacking movement toward extensive self-hosting, cloud AI gets all the attention, which then makes it harder to do self-hosting projects. You get the picture.

This may be why the Street is so antsy about massive AI contributions to profits. SK Hynix stock was hammered even though it had a major profit increase, because the increase depended on AI. We might see meaningful progress toward self-hosting delayed until 2028, and I don’t think that the current boom can be sustained that long. Maybe the Street is starting to agree, and what that will mean for AI overall is something we’ll have to wait to determine.

For decades, network operators and enterprises have both clung to a notion that the best network and the best data center were built around playing vendors against each other. Ideally, it was said, you needed to have three competitors to beat on in order to get the best price/performance. However, as I’ve noted in past blogs (notably here), enterprises first and then even operators started to see things differently. The reason was the combination of exploding integration costs and fault isolation and correction problems related to vendor finger-pointing, inevitable when something breaks in a multi-vendor environment.

Like any buyer trend, this one got the attention of vendors, who had a problem of their own. In the same couple-decade period, the percentage of both data center and network spending attributable to new projects, and thus justifying incremental spending, fell by over 70%. That meant that almost all the budgets for network and IT gear was focused on just sustaining what was already there, and that makes it harder to gain revenue if you’re a vendor. If you can’t rely on new benefits, then you have to steal someone else’s market share while making sure nobody steals yours. The result was what the article calls the “platform” strategy.

New projects rarely justify the full range of network gear, from LAN to WAN, data center to desktop. Same with IT gear. Combine this with the old open-best-of-breed mindset and you had vendors pushing segments of equipment—workgroup LAN, data center LAN, servers, management tools, software and middleware. In the new platform world, IT and network vendors started to see value in bundling all their gear into a platform. You win the platform and you win it all, because nobody is going to forklift an entire infrastructure to change vendors.

But now, could the separation of network and IT itself be at risk to platformization? Every network and every computer in an enterprise is linked in some way. Many network vendors sell network interface cards and of course almost all server vendors do. We’re already bleeding between the spaces, and now we have an indication that both buyers and sellers want even tighter coupling.

In 2020, when I was still operating under CIMI Corporation, only 19% of enterprises told me that they’d like to have, or even be interested in having, the same vendor offer them IT and network products. In 2026, 54% of enterprises Andover Intel heard from said that would be something they’d be interested in, 25% said they’d be very interested in hearing that story, and 9% said they had started to actively converge on one vendor for both areas.

One reason for this could fairly be called “nostalgia”. Remember that there was a time (the 1980s and early 1990s) when IBM was both the network vendor and the computer provider, and some who learned their jobs in that period are now senior managers or executives. IBM lost dominance when cheap IP routers replaced expensive SNA controllers, and the shift led IBM to sell Cisco its network business in 1999. Many IBM types remember, with a happy smile, when all of IT was one, and they’re happy to explore reasons to return to that state.

Reason two is more practical; HPE, Dell, and Cisco all sold both LAN and computer products, and in particular Dell and HPE both encouraged data center expansion based on their servers and switches. Some enterprises deployed these converged platforms when they had projects involving expansion. Over time, those enterprises say they found it easier to manage these combined infrastructure pieces than those involving a mix of vendors, and now they’re thinking about making the one-vendor-fits-all a policy.

Another reason for the shift, and for the 9% in particular, was the HPE merger with Juniper. Juniper is a full-scope network equipment vendor, not just a provider of LAN switches, and so the deal provides enterprises and operators an opportunity to build units of infrastructure that include servers, switches, and WAN gear from a single source.

For the vendor, HPE in this case, there’s a tactical benefit because it’s rare for an enterprise to look at expanding a data center in server racks without expanding networking, and vice versa. Having more skin in the game means HPE sales can spend more time. In theory, it could also be a strategic advantage, which if true could be an instrument to spread the converged platform concept to other vendors.

Converged data center and network platforms are most valuable to companies who are deploying a new chunk of hosting resources and need the whole package. Given that new projects with new benefits to fund such a thing are increasingly rare, it would seem to me that to gain an offensive advantage through this sort of convergence, you’d need to promote the new projects. That’s why I’ve not been fully satisfied with HPE/Juniper integration; I think it’s been tactical rather than strategic.

The strategic benefit would be simple; a company with more skin in the game has a greater incentive to promote those new projects, even if it requires some of the vendor-dreaded “educational selling”. There is some technical symbiosis between networking and hosting, of course; you can’t build a resource pool without connecting it. The symbiosis is greatest where the hosting involves something unfamiliar to buyers, which of course is why there’s so much attention being paid to AI.

AI is not, at present, a major factor in enterprise data-center building and connecting, but it’s a concern to planners. That means that it’s possible to leverage the notion that AI is a driver of converged-platform procurement, a reason to buy IT and network equipment from the same vendor. HPE may be benefitting, to a degree, from this, but I’m not seeing it yet in enterprise comments to me, which suggests that the impact is so far highly contained.

Is it enough to change the competitive landscape. Judge an enemy by their capabilities, not their intentions, says military-think. Could HPE competitors, especially Dell or SMC, see HPE as more of a threat because they might, just might, start thinking more strategically? Might IBM, who has mastered strategic thinking but doesn’t sell either network equipment or traditional servers, decide to broaden out; after all, buyers see “the data center” as a unity of hosting and connecting, and major competitors already offer both. Or will they rely on their Red Hat software as the hosting side, and play the notion that hardware is simply an essential and unglamorous underpinning to software, whatever kind of hardware we’re talking about? We’ll surely find out.

Most people know quantum computing only as a threat. The potential for it to break all of today’s encryption algorithms in seconds, exposing everything they’re supposed to protect, has been talked about for several years. Does this remind you of how AI’s threat to destroy humanity has been a hot topic? It should. OK, this is something that should be addressed, but first and foremost any promising technology has to realize its promise or it’s unlikely to get far enough to pose a threat to anyone. Quantum chips are the critical element of the future of the technology, because if you can’t make the cost manageable, next to nothing will justify its use, and to make a quantum chip successful you have to sell it to more than the hacking community. In any case, what quantum computers can break, the experts tell me it can render unbreakable. So we need to move from threat to promise, which is what IBM’s report aims to do.

The document was produced by IBM’s Institute for Business Value, looking at what the report calls “the innovators and risk takers—those who seized frontier opportunities and are now advancing out front.” These, IBM says, are concentrated in “aerospace, genomics, material sciences and financial services.” The primary focus within each of these verticals are problems that conventional computing technology has not addressed effectively, but future-proofing computing strategy and accelerating innovation were also cited by more than half the companies involved. Note that I’ve gotten quantum computing implementation comments from only 25 enterprises, and of that group only five were actually involved in trial/test applications, none yet in production.

One thing everyone actually involved in quantum computing agrees with is that it’s not the same as “traditional” computing. Quantum computing is about algorithms, about mathematics at a fundamental level. Linear algebra, a vector/matrix math, is arguably the underpinning of quantum computing, to the point where what doesn’t fit that model doesn’t optimally fit quantum as a use case, and arguably doesn’t even belong there. This is central to understanding how companies trying to identify quantum use cases, like those IBM cites, are working to accomplish their goals.

The key point to all the cited applications, IMHO, is that they’re “planning and analysis” more than “production and operations”. Right now, quantum computers aren’t practical purchases for most enterprises, so they buy time on systems for their applications. Material and chemical analysis and simulations used to assess techniques or systems seems to be the main missions. In these areas, quantum solutions are explored to enhance traditional computing models. Pangenomics, meaning population-scale analysis of genetic factors, is cited as an example of a field where there really are no models based on current technology, so they’re a proving ground for greenfield quantum solutions.

Vanguard, the financial/investment company, offers an example of quantum applications that are likely to be more readily adopted across verticals. Their work has focused on optimizing portfolio performance and modeling risk to assess downside potential. This is an approach that obviously many business processes could benefit from, by applying common methodologies to different statistical bases. Detecting illegal behavior like money laundering, one mission being explored, is a technique that could be applied to many different kinds of fraud/theft detection. Bond portfolio analysis techniques could be applied to optimizing inventory, shelf space, and even production relationship to sales patterns.

Simulation, though, seems to be the early-adopter brass ring for quantum computing. Almost any complex system can be optimized through simulation. In the design/deployment stage, this gets the “base” state working at its best, and this mission is suitable for quantum service users. As quantum chips improve, and the price per qbit comes down, more and more “operations” missions could evolve from the base design mission. Networks, utility grids, transportation systems, warehousing, and so forth could be optimized closer and closer to real-time with improved price/performance, and the techniques could all evolve from simulation applications used in that baseline planning mission.

Simulation can also guide R&D, which is where a lot of medical/health-care interest is focused. Screening for diseases and looking for a cure are both areas where real-world trials are essential, but simulation using quantum computing could identify the most likely fruitful approaches, reducing both time and cost to a final, proven, approach. The director of the quantum initiative for a university notes that getting a drug to market today is typically about 15 years, and so a ten or twenty percent reduction in that through quantum computing simulation and analysis could “change lives”.

Today, most quantum simulation is linked to traditional computing technology for real-world application. Simulation, then, essentially defines an approach that is implemented using familiar IT tools, including AI. One cited pioneer notes that quantum computing won’t replace AI but will “sit above it” in the sense of framing the application architecture in novel ways. Every quantum maven says that traditional computing in some form has to envelop the quantum-algorithm-and-linear-algebra applications, just to handle linkage with the real (and business) world.

There are obviously commonalities between quantum computing adoption and AI adoption. In both cases, my own enterprise contacts say that the primary barrier is internal skills. There is also a tendency for early applications to rely on a service rather than on self-hosting, and there’s an expectation that costs will have to decline considerably before large-scale deployment of actual infrastructure can be expected.

One interesting thing here, though, is that both enterprises I chat with and those cited by IBM in the report seem to believe in the notion of an “ecosystem” for quantum computing. Governments have been funding or heading initiatives on this; the IBM report cites one example, and IBM was awarded a billion dollars in USDoC funds to build a quantum computing chip foundry. IBM says it’s adding its own funds to this, and has signed more than $1.1 billion in contracts for quantum computing trials, tests, and even some actual production.

When will quantum computing see more actual applications? Right now, my enterprise contacts are even in trials at levels below statistical significance, and only three tell me that they have done any real production work. That doesn’t mean that no such work has been done; another ten indicated that they knew of companies who had actually leased time on quantum computer systems for real work. Healthcare and materials/chemicals seem to be the active areas today, but absent a determined broad-based survey effort, I don’t think we can get any reliable data on actual quantum applications. Enterprises think that there will be “some” production quantum-as-a-service adoption this year, and “significant” adoption by 2028. They think that self-hosting is likely to come along in the second half of 2028 or early 2029.

I think that while more people and companies will use AI than will use quantum computing, at least in the next ten or fifteen years, quantum computing may be more important to businesses, and indirectly to people, in the long run.

In parallel with all of this is the basic truth that when 6G insiders talk about “use cases” they’re really talking about stuff that 6G could support, or be required for, rather than stuff that is in a position to make an actual business case. Many in the telco world point out that this is how 5G went astray; use cases were taken as promised changes in available services and features, most of which never appeared. So where are we, as of June, 2026? Let’s try to work it out.

The 3GPP release process is currently advancing both 5G Advanced and 6G, with the former envisioned as a bridge to the latter. 6G is seen almost universally as a “generational leap”, so much so that most experts tell me that the predicted features are not currently needed. Sound like the 5G boondoggle? Well, the optimistic proponents of this approach say that 5G Advanced will move 5G capabilities toward the 6G generational barrier, close enough that work could be done on the applications that would really need 6G.

Given all of this, I think we can fairly say that the impact of 6G will depend on the pace at which the target “use cases” that combine to create the features in the generational leap promised would actually develop. Many of the use cases, we’ll see, sure sound like things 5G was supposed to bring about. If it had, then 5G Advanced wouldn’t seem to be needed, and even 6G might not be. One must assume that some of the push behind 6G-leaping is the belief that 5G didn’t improve things enough. So, to assess where we really are with 5G/6G transformation, we need to look at the use cases and the incremental feature jump from 5G to 5G Advanced and then to 6G.

The use cases for 5G fell into three categories, enhanced mobile broadband, massive IoT device support, and support for highly reliable low-latency connections, also related to IoT applications. In the first category we find 4K/8K streaming, AR/VR support, and FWA. In the second, it’s primarily smart cities, and in the final one autonomous vehicles, robotics and robotic healthcare applications, and automated supply chain management. All these are cited as use cases for 5G Advanced and 6G too.

IMHO, there’s little support for 5G having a major impact in any of these areas, so we have to conclude that the thesis for 5G Advanced and 6G is that there was a deficiency in 5G features that inhibited the development of the applications. We also have to conclude that the risk is that development was actually inhibited by factors beyond the mobile service, and thus may or may not be addressed. That raises four possibilities.

First, it may be that the problem was in fact that 5G didn’t do enough, and if that’s the case I’d say it’s likely that 6G at least would correct them. This is clearly the hope of the industry, but the problem is that if this were the case, we should see the most service-tolerant examples of the applications actually deploying now. We do have some examples of some of the use cases, in utility, manufacturing, transportation, and healthcare. However, enterprises in these verticals tell me that they don’t see network service features as the barrier to further expansion of these applications. In some utility examples of massive IoT, 4G LTE has proved to be sufficient to the point that migrating the application to 5G didn’t pay back in any way.

Second, it may be that the issues with these use cases had nothing to do with 5G deficiencies, but that those issues (whatever their source) will be corrected outside mobile evolution, and in time for 6G. There is some support for this, too. AR/VR glasses are starting to appear, and clearly any xR application would benefit from having supporting devices in use before it was attempted, because the new use cases would not then have to justify the glasses’ cost. However, we’d then have to justify a belief that this would facilitate the development of use cases that needed more than 5G. Can we, or is this another case of believing hype? If not, then staying with 5G would almost surely be the most profitable choice.

Third, it may be that the issues of these use cases had nothing to do with 5G deficiencies, and they will not be corrected in time for 6G. This happens to be my own view of most of the use cases. These use cases require deployment of application software, hosting, and in many cases, devices. They also require a business case, which means that there will be pressure to reduce communications costs to improve the odds of reaching the ROI target. In the days when the Internet was contending with other options for connectivity, the theory was that best-efforts service wouldn’t be good enough for many applications. What happened was first that “best efforts” got better as the Internet grew, and second, that applications tuned their connectivity requirements to fit the lowest cost service available.

The final possibility is that the use cases are simply not realistic, meaning that the whole story of 5G was built on use-case hype. The difference between this possibility and the last is a bit soft, but I’m adding it because there are some use cases I think are simply unrealistic. Robotic remote surgery, for example, may well be an example, but it’s likely only between hospital sites that would have permanent high-bandwidth wireline connectivity. Some autonomous vehicle missions are unrealistic because most of the latency-critical features of these vehicles would have to be handled with on-board intelligence, leaving mobile connectivity features like navigation that don’t demand special services.

Where are we with this? I think the simple truth is that we have no reason to believe that simply deploying 5G Advanced or 6G will promote any of the use cases that were previously claimed for 5G, and failed to develop into a new service market for telcos. Thus, the mobile standards process is focusing increasingly on a Plan B.

Which (surprise, surprise!) is AI. I have to say that of all the things that have happened in 6G so far, the decision to explicitly focus on AI is the one that I believe is the worst. There’s nothing wrong with having an architectural objective to allow AI to be integrated into infrastructure (and it wouldn’t be much work, either) but to make it a primary goal at a time when many (myself included) believe that 6G architecture decisions, and even many broad infrastructure decisions, are dragging on too long, is a major problem. Not the worst, though, because while there are issues with how the use cases for new 5G Advanced and 6G services need a boost, as I’ve noted here, there is no evidence that AI could raise revenues except in support of the same use cases. Double down on what failed in 5G by not addressing those use cases properly, then add in AI to double down again?

Crazy? Maybe not, since AI is now the “universal band-aid”, something you can stick on any strategic or tactical wound to render yourself safe from Wall Street. But the problem with first aid in any form is that it’s really supposed to tie you over until real, decisive, aid comes along. In this case, I’m afraid that the AI band-aid on 6G is going to cover up problems that need to be solved to save 6G, and maybe to save the telecoms.

The first headlined section of the piece is “Toward a hyperconnected AI world”, where “later-stage 5G and pre-6G technologies are planted in smart glasses, robots, industrial machinery and other objects.” The problem with this is that it’s not at all clear that there’s a business case for any of those things. Even if there is, there are a lot of pieces needed to build the justifying applications, and Ericsson doesn’t even make them all. AI is, in the picture, not the driver of change that will inevitably succeed, but another of the costs we’d need to justify in our business cases.

There are a lot of things you could do with AI, but there were a lot of things we could do with ISDN, frame relay, ATM, 5G and so forth. Utility isn’t the same as suitability-for-purpose, and that in turn isn’t the same as creating-justification-value. Should Ericsson assume that somehow the demand for all that wonderful stuff, the “tailored user experiences” the article quotes, will actually develop? Remember that the same piece, a couple paragraphs later, admits that it lost ground to Huawei in the past. Huawei is a price leader, and you generally can’t focus R&D on being price-competitive while you’re making speculative bets on service evolution. Particularly in an industry where past bets have gone awry more often than they’ve paid off.

5G is really the issue that everything for Ericsson, and for the industry, revolves around. Any mobile standard has to balance the “needs” against the returns on fulfilling them. 4G networks, the piece notes, needed more capacity to cope with consumer broadband and smartphones. Yes, perhaps, but how does that pay back in terms of service revenues? Telcos started their disintermediation complaints less than a decade into this century, and showed me their now-classic revenue-per-bit charts plummeting in 2012, five years before current CEO Börje Ekholm took over. Where was the 5G contribution to fixing that? Obviously, it didn’t work, so why would Ericsson (and Elkholm) do better now?

The problem that Ericsson has, that telcos have, that the whole telecom industry has, is that “The hope was that 5G would be used outside smartphones to power self-driving cars or allow robots to perform surgery. So far, it has not happened at scale.” True, but the fault lies in the “hope” part. Things don’t happen in a global market because someone hopes they will, they happen because someone drove them to happen.

Why would businesses, people, spend more on telecom services or anything​​? Remember, as the tagline said, we’re in a period of geopolitical uncertainty. They’d have to have a good reason, which is another way of saying that they’d have to make a business case. How long would it take for self-driving cars to replace vehicles now on the road? How long would it take before we’re letting robots clean our living spaces or take out our appendix? Candidly, anyone who believed that any real progress could be made in any of those areas in a few years was dreaming, not doing market research. And, candidly, what operator would make a massive investment in infrastructure today in expectation of a return more than three years off, at best?

Why did PCs succeed? They were revolutionary technologies and the uptake of PCs by businesses was fast enough to cause IT spending to grow far faster than GDP. The answer is that a PC was a more personal way of doing stuff we did impersonally, and also a very cost-effective way. Smartphones were based on the assumption that people would want the Internet experience they got at their desks when they weren’t at their desks at all, or at any desk. We had opportunity, demand, in place. 5G robotic surgery? Self-driving cars? We have some robotic surgery today, some autonomous vehicles, but far from enough to create pent-up demand, and in any event, can you really run a vehicle in traffic through a mobile network connection? Can you do surgery over such a connection, given that it might fail at a critical point? There are some cases where both these might be essential, but enough to justify mobile infrastructure spending on a large scale?

Ericsson’s problem is everyone in tech’s problem. They understand technology, but not why someone would need it. They “hoped” that someone would develop the applications that would justify the need, when that unnamed force would have to make their own business case for their work and products, and likely they’d have others who’d have to make their own business cases first. What is enterprise tech spending doing these days? Modernization and cost management, because there are few tech projects that can make new business cases, and thus contribute benefits to offset their adoption costs.

Why is this such a problem? Some enterprises tell me what they think they could use to build new business cases, but they can’t focus vendors on these long-term requirements. Some say they can’t develop use cases for new technologies themselves, they’d need vendors to take the lead, and most don’t do that. It goes back, I think, to the short-term-sales focus. A number of my friends in sales tell me that they need to make quotas for the current year, the current quarter. Pushing ideas that would take years of work to turn into a sale just isn’t in the cards. People do what they’re paid to do, after all.

And this stuff is new, hard, and risky. But it’s also the only way, in the long run, to make the pie bigger. Ericsson, like most tech/networking companies has been cutting jobs to preserve profits. Smart for them, essential in fact. But why then isn’t it also smart for their prospects and customers? How did Ericsson sustain hopes that the strategy that they’ve themselves adopted to protect their business would be ignored by those they were trying to sell to? The same way other tech companies, and AI companies, do today.

Some enterprises tell me that they think “tech consumerism” is a contributor to this problem. More and more technology is sold to individuals these days; fifty years ago, people didn’t own computers and smartphones didn’t exist. Is it possible that tech, increasingly dominated by consumers, has started to market in a consumeristic way even to businesses? Forget actual business cases and focus on “everyone else is doing it”? If so, it might explain how vendors forget to consider the business case of their buyers, the complexity of modern tech value chains.

Ericsson is selling to a vertical that has notoriously long periods of depreciation, which means that it takes a long time for a technology to become eligible for modernization. If its buyers are cautious about proving the value of technology change, they’re doing the same sort of profit optimization that Ericsson itself is doing, and Ericsson simply has to contend with that. So do all vendors, in the long run.

The number one problem I hear about is citizen AI. The form of AI whose “adoption is rising” is the cloud-hosted form, which is either fully usage priced or priced based on base-plus-usage, and this form can usually be adopted with only minimal management approval and rarely requires any IT oversight. My comments come largely (2:1 roughly) from IT professionals, but both line and IT types agree that there is really no supervision of AI usage by the approving authority, until costs become conspicuous. Workers are happy to have the company spend on things that make their jobs easier, and their management will often simply agree. Enterprises agree that this form of AI inevitably leads to misuse, meaning spending that doesn’t produce a valid benefit. How much of this goes on is hard to say because no enterprises indicated there was anyone in their company who even knew just who was spending on citizen AI, and how much.

The second problem, by a small margin, is related to this. AI is an expensed service. How many times did we hear that “repatriation” of cloud applications was necessary because of cloud cost overruns? That’s already happening with AI, as more and more workers exceed any base usage levels on their plans and end up needing tokens. However, with cloud computing, the stuff that was a cloud expense used to be a data-center capital project, so bringing it back was a consideration. With AI, companies find that it’s often not even clear that the AI expense is justified, and the path to running it in house to improve costs is rarely considered. Instead, the applications are simply abandoned, or scaled back by budget controls.

Problem number three is data access and sovereignty. Making a data center connection for an AI service will normally require some form of IT coordination, but in some cases workers may have access to raw data in a generalized form, like a spread sheet. Some AI models will even accept PDFs, which means that “printed” reports are available. Workers are encouraged by AI stories, and sometimes by their AI service providers, to expand the data sources, and this can run up costs and also end up giving an AI model proprietary data that governance policies say can’t even be used or hosted in the cloud. Where IT is involved in data access, enterprises find that there’s not enough control exercised over the data connection (RAG, MCP, or whatever) to manage cost and compliance.

Problem four is AI literacy. There are five AI providers typically recognized by enterprise AI users (Amazon, Google, Microsoft, OpenAI and Anthropic). All of them offer multiple models and tools, and all these are evolving over time. In addition, the AI plans available, including tools, costs, features, etc. are evolving. About a third of enterprises say that their line AI users are often switching between AI providers and services based on what they see online, or hear from the providers. As a result, it’s harder to develop a basis for confident AI planning, and often necessary for a user to retrain themselves and adapt their application of AI to new tools. This makes AI less effective.

Problem five is advanced AI features are more often expensive, and wrong. Enterprises say that “everyone who uses AI has found errors.” They also say that the more sophisticated the AI tool, the greater the chance it will make a mistake, that the worker(s) won’t catch it, and that it will generate a cost problem. Of course, everything said or written about AI encourages users to employ the most advanced tools, features, and models. One enterprise noted that generating a presentation was more than twice as likely to produce a problem with the data than generating a report, that generating a video was perhaps three times as likely to introduce errors as a presentation, and that the entire base usage quota for an AI plan would likely be consumed by creating a video less than a minute in length.

The final problem is AI encourages classic “theft of time” and also wastes company money on personal usage. Theft of time is a personal activity that’s undertaken on company time, and since AI tools can’t discriminate between a desire to create a product image and a personal one, almost all enterprises say that some (well, most) workers will use AI tools at work for personal reasons. Most enterprises say that they believe that some workers run up significant usage costs this way, too. Enterprise IT has recognized this from the first, and IT projects using AI often embed the AI within another application or in a workflow, rather than expose a chat/request type of interface.

You can see in the article I referenced that it’s based on chat-interfaced AI services, so the presumed AI of the future is that form of AI. This is most definitely not how IT organizations see it, but it’s surely how the AI giants are hoping things will go. However, these issues are all weighing on AI just as many weighted on cloud usage. Enterprises really do believe that the cloud providers hope is that AI will be a back door into a new “everything moves to the cloud” paradigm, that AI adoption will turn enterprises away from self-hosting.

Enterprises I chat with don’t see this happening, and neither do I, but what I think may be true is that it will take a long time for enterprises to come to terms with the “real AI”, and that means the AI hype wave likely has more runway available than cynical me might offer it.

What’s the difference between a large-scale real-time application and a “digital enterprise” with its entire supply and distribution chain built by integrating its core applications, as a service bus might do? That may be a critical question in the evolution of IT.

Enterprises in every vertical (including telecom) have evolved a set of “core business applications”. These applications support their own supply and distribution chains, and also things like accounting, personnel and payroll, and regulatory requirements. There has been, historically, a trend to integrate these through APIs rather than having data passed between them by workers. In the early 2000s, the advent of “service-oriented architecture” or SOA led to the creation of various message-bus strategies to provide this integration. Think “Enterprise Service Bus” or ESB, or “API broker”.

The value of this sort of application integration is clear to everyone, but to many the limitations were also obvious. Many of the jobs critical to enterprises, and in fact to businesses of any size, are driven by human effort. I worked on systems that, where this happened, the software would crank out a work order to initiate the action, and then expect either some application message response or a human-generated “completed” transaction.

Real-time process automation systems have a similar problem. How do you align a bunch of manufacturing steps, or link them with the movement of parts/materials in and goods out? Manufacturing systems using automated process control did this first with custom applications, then with more generalized things like a numerical control language, and today with “digital twins”. Today, the concept of digital twins, though not even fully realized, has been caught up in the AI wave to become a “world model”, and the question it raises is less how AI might play, but what the fact that process automation evolution and application integration are colliding, and the winning concept could drive massive changes.

Today’s computing, and networking, is based on the integrated-application model. That model does not promote the expansion of real-time world-model thinking beyond process control. Thus, only an application evolution from the process control side would generate “world model” that was in effect a model of all aspects of a company’s business. The optimum approach, from a tech-spending-impact perspective, would be to apply the process automation/integration approach at a company (or even wider) level. The “world model” would model a larger world. The question is how this might come about, and whether those with an interest in raising tech spending in the long term might facilitate it.

We have process automation and process-contained digital twins today. We have service-bus-integrated applications today. Cloud providers, as I’ve noted in the past, have been deploying middleware tools that allow some cloud software to run local to processes (AWS Greengrass, for example). If we assume, as I think we should, that local process automation evolves both functionally and geographically, then the question is how the increased functionality and scope would be accommodated. That depends on the interplay between the two.

Suppose that we had to reflect a decline in parts inventory on the East Coast by ordering from a West Coast supplier. The time to transport the material would likely be measured in days, and so it would be a waste of money to build real-time coordination between the two sites; just generate an order from east to west. That is an application integration problem, not a real-time process problem.

A reduction in the geographic scope of this example would gradually reduce the transit time for fulfillment, and as that happened, the value of tighter coupling of the process automation tasks at each end of the chain would increase. Similarly, if the needed parts were not inventoried, but made to order, then there would be a value in expediting the linkage. At some point, having Process East signal Process West would be valuable enough to visualize the combination as a twin-of-two-twins, with automated process correlation.

What we can say, in general, is that real-time integration of two processes has to be justified by a value of real-time co-management. For processes, like transportation and utilities, that are already inherently distributed, finding that value is likely easier. If we looked at traffic management as an example in an age of autonomous vehicles, we can see that it would be very helpful to be able to look at all the vehicles in terms of their position, destination, and route, and adjust as needed to optimize traffic flow and minimize congestion. However, it’s obvious that this specific application would require a truly massive investment just to initiate (sensors for traffic, autonomous vehicles, then all the IT elements). I think this is something that would come along only at the end of a digital-twin evolution. Something has to get the earlier phases of that evolution started, and keep it moving.

I’d love to point out one or two compelling applications that could do that, but if such applications existed, even our hype-driven, short-term-obsessed-with-our-feet-not-the-future market would likely have discovered them. One example of a possibility would be specific product tracking. Suppose that a specific lot of a given part was found to have a manufacturing defect. Would it be best to pull the lot from every stage, to pull products it had been used in wherever they were found, or simply accept the cost of return/replacement in case of a failure? In most cases today, there would be no reliable way of doing anything other than inspecting for the problem in the final product, or letting users return failed products. With real-time tracking you could establish where each potential problem part was, what it was in if it was already through some assembly stage, whether other lots without problems were available nearby, and so forth.

One thing that I think this potential use case demonstrates is that the value of real-time process integration can likely be fully realized only by accepting greater complexity. I think that AI is almost a given in higher-level world models for that reason. Thus, I think this path of creating large-scale “hierarchical” world models is a major AI application.

If we accept this even as a potential future path, then we need to look at the evolution of current real-time applications of process control with the idea of asking whether the next evolutionary step could, at acceptable cost and delay, be made to prepare for this more radical outcome. We’re not doing that today, and enterprises say that they’d need their vendors to be willing to help with the assessment. Will they, or will they continue to be focused on the current quarter’s sales? That focus, I think, is why we’re not launching new tech applications, and why many promising technologies may not survive the hype phase of interest. We could do better.

Opportunity forces, then, are a real factor in how service planning for 6G should be done. Is it being done, though, or are telcos obsessing on the fear that the mistakes of 5G, which generated minimal (if any) real ROI for telcos, would be repeated in 6G? It’s good to avoid repeating mistakes, but to do that you need to do something that isn’t one. I’m still not sure telcos get that, and recent announcements seem to support my concern.

The NGMN Alliance (Next-Generation Mobile Networks Alliance) is, self-described, “a global, operator-driven organization, established by leading international mobile network operators (MNOs). As a global alliance of operators, vendors, and academia, NGMN provides industry guidance to enable innovative, sustainable and affordable next-generation mobile network infrastructure.” It’s warning the industry, in a couple of publications representing operators’ views, not to let 6G repeat the mistakes of 5G. That’s hardly surprising to me, given that of the 88 operators I’ve chatted with, 85 say that 6G cannot follow 5G in its failure to address new opportunities in a realistic way, but at the same time demanding a major infrastructure upgrade at significant cost. But will the viewpoint really matter if the group doesn’t embrace a better, specific, alternative?

There is a value to upgrading mobile standards, and a cost. The cost has to be carried by the telcos for service infrastructure and consumers (and telcos, with handset subsidies) for devices. The former are the mobile network operators or MNOs, who are the founders of the NGMN. The value goes first to those who the costs are paid to, and also in at least a justification sense to those who have to bear the cost. Over the last couple decades, the mobile infrastructure vendors and handset vendors have been proponents of change, radical change. The telcos have gone along because, up through 4G/LTE at least, they saw a service revenue value flowing to them. With 5G that changed.

None of the telcos I’ve chatted with will admit that they drove 5G hype on their own. They say that it was media/analysts who did that, likely pushed by a combination of click-appetite and vendor influence. I tend to agree with that; I saw telcos accepting the market vision of others, which was usually the case, and fearing that if they didn’t follow the herd, they’d end up empowering competitors. But none of the telcos today believe that the 5G market vision of the past was valid, and their concern is that 6G will end up repeating that vision failure, which resulted (for 5G) in a major infrastructure spending boom with minimal financial gain to MNOs.

So the statements of the NGMN Alliance fixes that? I’d guess that such an expectation would sound naive to you, and your skepticism would be at least somewhat justified. Yes, the NGMN can discourage vendors from making 6G into another boondoggle, but the 3GPP is a separate body, and telcos don’t supply most of the resources for its work. The most likely way for vendors to assert pressure would not be outright defiance, but a kind of spec creep. Gee, Telco, if we just diddled this or that section a little, it would open up massive revenue opportunity. The diddling could well end when revolutionary fervor has totally displaced evolutionary caution.

The problem here, the problem with a “no-forklifting” goal, is that almost any useful evolution of standards, meaning any that generate any value at all, will tend to impact handsets, radios, and mobility management to some degree. Any useful suggestion would likely live near, or over, the boundary between evolution and revolution. And telcos (almost all of my 88 for example) believe they need some new service revenue opportunity. Can you propose a change that would justify users spending more, but that would have no impact on handset or infrastructure? I’m not at all sure I could even uncover such a thing, unless….

…unless we presumed a jump up the stack to features that were on the network rather than in it. We all know that the Internet shifted the goal of user connectivity from user-to-user to user-to-experience. What gets the user committed is not the route, but the destination. That’s particularly true for broadband, which isn’t useful for text or voice calling. The whole telco mantra of disintermediation came about because telcos first were happy to find a way of getting consumer data applications going because it justified the growing capacity available in the network, then resentful that the suppliers of those applications were making better profits. Telcos, if they want OTT-like margins, need to offer OTT-like services. But they don’t want to do that, so in a way the whole pressure on mobile standards to evolve rather than revolutionize is consistent with their attitude on services; in effect they want a service upgrade in comfortable services that generates revenue, without raising their costs. No forklifts in cost, only in revenue.

The Internet created the need for the progression of G’s, the need for consumer broadband. Absent it, offering users hundreds of megabits or gigabits of connectivity would just waste bits on voice and text. You can’t drive changes in service requirements without changing the thing you’re serving. Some new mission set would have to drive things.

And that’s the problem with the no-forklift movement for 6G. If you don’t define and promote and ultimately validate some new missions in 6G, you cannot do anything that’s really worthy of any new standards at all. Instead, you should simply work on lowering costs until everything vanishes to a point. But to validate a new mission, telcos would need to consider the points I made in my blog yesterday; to focus on connectivity alone in a real-time future means focusing on something the cloud providers and others will use to disintermediate you (again), and perhaps also work to minimize even the need for the services you want to sell.

Low latency and high availability are service features, but their value depends on how you organize event processing. The more you do local to the event, the more higher layers of processing are immunized against the need for these service features. If you’re already hosting transactional front-end processing, as the cloud providers are, would you not want to push low-latency needs down to the local level? If you make chips, phones, computers, would you not want to do the same? It’s very possible, even likely, that the decision to push critical control loop applications to the local level offers the best short-term path of evolution and the best long-term outcome.

The fact is that we don’t know the “ideal” balance of event processing, partly because every stakeholder’s “ideal” is optimized to their own profits, and partly because the way that applications evolve could influence just how much new services are needed, versus how much new local technology and chips are needed. We don’t even know what impacts the shift in event processing location would impact the overall business case for enterprises or value proposition for consumers. This is a complex moving target, and for that reason it may be difficult for organizations like the NGMN Alliance to say “no forklift” without impacting the future opportunities of their members. Better to try to come to terms with where things could go before setting boundaries on what the future services should look like.

Telcos may now be looking at playing some role in private 5G, according to THIS article, but do they have a chance, or even a plan? If they do, I think they’re following the same road that vendors like Nokia have, and almost every wireless vendor admits that private 5G has been very difficult to promote successfully. Many tell me that they’re really not even sure how to promote it. Well, I think they’re all missing the point.

If you look at private 5G (or 6G) as a kind of WiFi alternative, my enterprise contacts say that the value is limited to complexes of facilities that cover blocks or even square miles. Based on this, you’d expect the focus of opportunity to be in transportation and utilities, which is how most private 5G initiatives have been targeting. I think that may be the wrong place.

OK, indulge me here. We need to have more benefits driving changes in services, networks, and IT spending. Absent that, everything will focus on orderly modernization that does more for less, meaning total commoditization. Talking about 5G or 6G or AI or quantum computing as a driver is skipping a step; what makes the business case for these technologies? It’s the missions, the applications, that they open up. If we want revolutionary results from any of these things, what we need is revolutionary business cases. WiFi replacement isn’t that, so we need to think deeper.

Hence, indulgence. I’ve blogged before, often, about real-time services. We’ve only managed to empower about half the workforce with technology, because the other half can’t sit at desks and use computers. The barrier to doing that is the complexity of the mission, the size of the ecosystem of products and services that we’d need.

What we need for real-time services is first and foremost an application, and second a viable evolution from business-case low apples to something that fully realizes their potential across the market. We have real-time applications today; enterprises in many verticals have “local” process control applications that are based on self-hosted-close-to-the-process edge computers. These are often specialized devices, using custom hardware and even a custom operating system and middleware toolkit to manage event-based rather than transaction-based missions. What would be nice would be to figure out a way of expanding these to create an evolutionary bridge that full exploitation of real-time computing could cross.

Private 5G/6G is not the entire bridge, but it is a critical element in it. Real-time means real-world, and so expansion of current applications means introducing a larger physical footprint for the activity. Private 5G/6G can easily evolve to, and even mesh with, public 5G/6G services. This would allow enterprises to first expand the geographic scope of current real-time applications, and then build new ones on the same network framework. The private 5G/6G service could cover a large multi-building complex, and when augmented with public services, embrace related complexes as well.

Most real-time systems are hierarchical, meaning that there are layers of intelligence. If you use a smart thermostat, you’re using such a system. The thermostats have a local intelligence that allows the devices to be controlled physically, and also supports a schedule of operations to run things for you. The remote intelligence, usually linked to your phone, lets you control and schedule remotely. We can expect that the evolution of current process control missions would also be hierarchical; local intelligence would handle the most time-sensitive and high-availability pieces, and subsequent layers would handle things that aren’t as demanding. For evolving enterprise real-time applications, we could expect “local expansion” to be supported by application elements hosted in a user-owned complex that’s part of the expanding system, but eventually we’d see an opportunity to cloud-edge host some elements. Edge computing could evolve much as cloud computing has evolved, to offer better resource economy for applications where average offered load can’t fully utilize what’s needed during peak periods.

There’s both good and bad news for many of the prospective IT/network stakeholders in all of this. The most obvious bad news is that technology advances can only drive massive spending if the business cases can be made throughout the ecosystem needed for the advances to deploy. AI can’t change things unless AI can change business cases. So also for 5G/6G. The most obvious good news is that this paradigm, while perhaps not as newsworthy and satisfying of desires for instant gratification, is a proven model. We’ve done this before, so we know it can be done.

The challenge here is that evolution isn’t revolution, so instant results cannot be expected. For vendors, and telcos, facing a combination of higher costs and slower revenue growth, there’s no prospect of immediate relief. In fact, there is a real risk that some more aggressive player will take a risk you’re unwilling or unable to take, and so gain control of more of the real-time pie than they might have had, than you will have.

This all comes to focus when you consider the role that the hyperscalers, the cloud providers, might play. Real-time today is not a cloud mission. Real-time today isn’t a telco mission either; all the telcos have done is propose service features to connect still-hypothetical real-time edge hosting. The cloud providers, via tools like Amazon’s Greengrass (Google and Microsoft have similar tools), which is a middleware toolkit to unify cloud and self-hosted edge features. Obviously, these could become feature conduits to create real-time processing capabilities that will eventually be offered in the cloud. All three providers already position “IoT” versions of their tools, and this could mean that enterprises build applications on a platform that self-integrates with cloud provider edge services, where they are financially viable. Google and Microsoft are particularly aggressive in linking their edge IoT stuff with enterprise IT tools and practices, making it easier for enterprises to bridge to a highly distributed deployment via these tools.

This isn’t automatically a big new lose for telcos, but it’s a big new risk. Telco complaints about OTT disintermediation reflect the truth that any network-connected application tends to first value the requirements for the application and only then for the network. The real-time edge, controlled by cloud providers, might still need some real-time-capable service features, but cloud providers would likely work hard to ensure that the layer of processing hierarchy above on-premises was in-cloud, meaning that they’d likely work to reduce the need for an edge hosting service. Telcos would then either lose an opportunity to exploit their geographic spread to host resource pools, or find the value proposition more challenging.

Focusing on 5G/6G should include focusing on how to maximize the telcos’ role in what will justify those services, and private 5G will make this “should” into a “must”. Will telcos be ready for that, or will they get caught up in the “G’s” again? We’ll look at this further tomorrow.