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.

The company’s earnings release is the best place to start. The company reported 48% gains in revenue, with operating margins of a record 67% and EBITDA another record at 69% of revenue. All of this was above guidance, but a bit shy of some estimates. This was the technical factor that caused its stock to fall; when hedge funds think a stock is strong in the long term but has a blip, they’ll sells short to drive down the price, the buy in to get a better cost position on top of the short-sale proceeds. You can see a bit of this in the markets this week. On Monday, Broadcom and AI bellwether Nvidia were both up, and this morning (Tuesday) futures are up for both. If this was the end of the AI hype cycle, that’s not what you’d expect. The Street loves a bubble, and while quantum computing is likely being groomed for the role, it’s a tougher sell since the technology is hardly populist.

With regard to AI, Broadcom doesn’t make GPU competitors, but rather the connecting/networking components. Its website currently has an AI solutions segment that’s focused on this, featuring its new network switch chip (Tomahawk 5) and optical elements. Thus, when we hear about their AI, we’re hearing about AI networking. Their AI story, and guidance, didn’t match the heady Street hopes, though they exceeded their own guidance. This is one of the problems with a bubble. A company tries to be realistic, and the Street tries to push the story to justify the hype. So, there’s inevitably a shortfall versus expectations, a blip to be exploited. They can hit Broadcom and other AI players. OK, the bottom line here is exactly that, the bottom line—for hedge funds.

For the rest of us, what can we learn? Truth be told, not necessarily a lot in a direct sense, Broadcom’s Tomahawk is the go-to chip for white-box networking products, so not all of the sales of the chip are even related to AI, nor is all AI networking based on it. Giant Cisco, the largest player in the market, has its own Silicon One chips, though rivals Juniper and Arista do use some of the Tomahawk family. DriveNets, arguably the most credible alternative supplier for large-scale deployments, also uses Broadcom. All of these companies are pushing an AI story, but all of them were selling switches before AI, and enterprises tell me that the number of true enterprise AI network deployments hovers at the edge of statistical significance.

That’s the basis for the real lesson here, or at least its foundation point. We are still seeing most AI deployments made by the hyperscalers. Enterprises are at most kicking self-hosting tires in the AI space, and that is the most important AI truth to be had at this point.

Almost all of enterprise IT spending from the 1950s to the present has been justified by “core business” applications. The “core” nature of these applications means the data they collect and process is critical to the companies, which in turn means its subject to governance. How much of a tech spending wave could be driven by applications that didn’t require governed data? Why would we expect the same enterprises who rejected “move everything to the cloud” hopes, in large part because of data security risks, accept “move a lot of things to cloud AI”? Enterprises will, to fully exploit AI, host more and more of it on their own resources, and as they do they’ll expand the need for AI-capable data center networks, not only to connect the clusters but also for data access. Eventually, this has to be the dominant opportunity, but for now it’s developing only slowly. Why?

Reason One is the same hype problem that I’ve already noted as a factor in Broadcom’s earnings miss. Enterprises overall tell me that they’re uncertain about self-hosting AI since nearly everything being talked about in the AI world relates only to the cloud model. Which, of course, is because the hyperscalers have spent billions on AI data centers and need to show Wall Street that it wasn’t a stupid move. The media loves the story because cloud AI is approachable; you can (and almost surely do) use it in your regular activities, even as a consumer. You almost surely don’t pay for it, though. Citizen AI has won the battle for good ink, which means that there’s little available online to bring confidence and comfort to enterprise IT organizations looking to make a business case for AI applications that use their core data.

A very few companies are driving the right bus. IBM is the company most mentioned by enterprises who have self-hosting AI project in process or being planned. Most IBM accounts are industry giants, and obviously they make up a small percentage of the total enterprise population. Not only that, they often find that AI is only adding to “horizontalization” pressures they’ve been facing from the time they started using virtualization to build efficient data centers. Thus, they are less likely to need “new” network technology. They’re also more likely to be Cisco customers, who won’t be using Tomahawk chips in their gear.

Broadcom needs self-hosting of AI to go mainstream for its “AI chips” to experience explosive growth. We’re seeing growth today, but driven by a small number of giants. Real AI success depends on democratizing hosting, and we’re not really addressing that. Where Broadcom is failing itself, IMHO, is there.

VMware is perhaps the dominant virtual-data-center technology, and Broadcom bought it. Some on the Street analyst side have been critical of the minimal growth they’ve seen in VMware revenue, but truth be told, that’s not the real problem Broadcom has with data center software. Giant data centers don’t spring up like mushrooms, and AI is not going to justify building new ones. Even hyperscalers are expanding their cloud data centers more than creating pure AI ones. What that means is that data center virtualization is a bit like IT overall, something that’s fallen into sustaining mode because new applications that could tap new benefits to justify new spending have not been emerging. One question is whether AI could change that. Another is whether Broadcom could drive it.

VMware has a larger account footprint than IBM’s strategic accounts represents. Could the sales teams then play, for VMware customers, the same role as IBM’s strategic account teams play? Why not? Will they? A lot is likely to depend on it, and enterprises so far say that VMware isn’t even trying to play the role of AI strategist.

The mainstream, as opposed to the tech and financial, media has not been shy raising questions about AI. Here’s an example from Axios, and one that makes a troubling connection to 2000’s dot-com market problem. As that piece points out, the big question now will be whether (to quote a source in the article) “Recent earnings reactions suggest that even outstanding growth isn’t always enough when expectations are stretched — a classic ‘priced for perfection’ dynamic.” There is no question that while the Street still loves the AI bubble, it’s wary about the bursting. The hype will end, as it always does, and for Broadcom the question is whether they’re prepared to step up and try to make that a PR event more than an economic one.

Many consumer broadband connections, as most consumers know, offer higher download than upload capacity. Even when the interface is uniformly clocked (200 Mbps symmetrical, for example) the networks may be designed with the almost-always-valid assumption that traffic will flow out to the user much more than in.

One follow-up question is whether robotaxis or AI actually generate that kind of WAN data pattern. The way almost every AI user works with the tools doesn’t. I write a prompt that might be two lines long, and get a ten-page report in return. Many have argued that AI search results actually reduce traffic in the WAN by reducing the number of times a user clicks on a result link. And I personally have questions on whether robo-vehicles of any sort have a reason to push a bunch of inward-heading bits; to rely on network connections for public-safety-related behavior would be reckless, IMHO. Insurance issues? Maybe, which might justify continuous video monitoring, but that wouldn’t involve AI.

So is all this bunk? Maybe some of it is, but there are some points to be considered, mostly points relating to the role that tech in general and AI in particular might play in real-time activity. Robotaxis may not be current examples of this, but they are perhaps advance warnings of a network challenge.

Tech-supported real-time systems seem to depend on “world models” or “digital twins” to create a computer-accessible view of what’s going on in at least a part of the physical world. To generate this view and keep it aligned with real-world processes, you need to obtain some sort of sensor data. For that, your choice is perhaps a whole bunch of limited sensors, infrared, ultrasonic, switches, and other familiar things, or a form of real-time video analysis. For simple real-time systems of the sort used already in factories and warehouses, simple stuff would likely serve. For real-time missions that involved more autonomous elements (including people) a better strategy would be to analyze video.

Doesn’t this then validate the notion of robotaxis pushing gigabits? Not really, because a robotaxi is big, expensive, and so could likely justify on-board technology. The problem arises when you try to incorporate things that are numerous, small, and have to be relatively cheap. If everyone carried XR glasses linked to on-board AI (in their phones, likely), that might give us enough analysis power to handle human-inclusive real-time systems, but we aren’t there yet, which means that some real-time traffic carrying video for analysis is likely to come along. That, clearly, would have network impacts and potentially costs that would impact the ability of these applications to make a business case.

Real-time applications overall need three things to be true about their network services in order to work. First, they have to be reliable because their failure would break the real-time system and likely generate the same sort of real-world impacts the Light Reading piece described, but on a larger and more dangerous scale. Second, you’d need to have low enough latency to maintain the correspondence between your world model and the real world, to the level that the pace of action/reaction was accommodated. Third, you’d need the cost to be low enough not to compromise the business case or make widespread deployment of the services unprofitable. Would these be possible?

Truth be told, we don’t know. Enterprises who have commented on this to me so far are almost 100% convinced that few if any of our three requirements are met today, and by a rough 4:1 majority think that they’re not in the cards for the next three years. But by a 6:1 majority, they think that by 2030 this sort of service set will be offered in most developed markets. To me, that suggests that in the transition period beyond Year Three, there will be massive change.

For the record, I think enterprises are more hopeful than realistic in their views here. However, I do think some comments they’ve made offer some suggestions on how things could evolve.

Most optimistic enterprises think that some public-policy support, meaning governments at some level, would have to be involved. There’s often a specific suggestion that public safety personnel would drive progress. A body camera on police, fire, and rescue personnel is already used in some areas, and it’s reasonable to suggest that making some of the cameras generate real-time feeds could be possible. AI analysis of these feeds might generate enough immediate value to drive a network opportunity.

The real value here, though, seems likely to depend on some form of hierarchy of analysis. Some things need immediate, reliable, actioning, so you need some on-body analysis. If this were provided, it could reduce the burden on network connections that link the camera systems to deeper analysis points. Hierarchical AI of some sort is definitely a potential source of more bidirectional traffic flows.

Are there other means? One that’s been suggested is some sort of populist resource pool created by using a connection to share unused resources. There have been many suggestions, and a few implementations, that have done this with access point technology. Personally, I do not believe that sharing access point resources, or local compute resources, to make up an ad hoc pool is a viable mission for reasons of profit and security/governance. Enterprises, at least, would need guarantees of both security and governance, and since even cloud provider promises here aren’t enough to support business-critical applications, it’s unlikely that consumeristic pools would be accessible. Could someone set up a commercial sharing deal, where companies deployed custom server/storage contributions to export through the network? I think security and governance issues would make this difficult too.

In all, I think that there are opportunities in real-time “uplink” services, but they depend on the development of applications that would exploit them. The needs in this space are clear, the technologies are available, but the ecosystem needed is yet to be realized. Still, it may be the best hope for new telco revenue.

Traditional data center LANs have been built as a tree, with layers of switches that connect in a multi-link way with those at the next layer down. This provides a resilient way of creating what’s effectively a mesh, but it imposes a greater and greater latency and cost burden as the size of the data center increases. A long-standing graph theory says that the best approach would be to create a “flat” network in which the switches connected among themselves at random. Such a network requires fewer switches and presents a nice predictable and linear relationship between network capacity loss and switch failure. The problem is that attempts to realize this happy outcome have been unsuccessful.

Amazon came up with an approach that mixes true randomness and deterministic behavior with what it calls “spraypoint”. In this approach, a source switch picks a neighbor at random and sends a packet to it. That’s the random part. The receiving neighbor uses traditional shortest-path rules to send the packet onward, which is the deterministic part. The connectivity is structured in “rings” connected by a “ShuffleBox”, which on one side connect too switches and on the other to other ShuffleBoxes. This means that when a new server or rack is added, you simply connect it to the local ShuffleBox, and no other cabling is needed. The way the rings and ShuffleBoxes are designed is based on modeling Amazon has built through simulation, so the data center operator can input the number of servers and the performance required, and the result is a ring/ShuffleBox configuration.

I’ll mention this again, because it’s important, but this is not an actual fabric. The ring-and-shuffle model means that the traffic will still take hops, and the number of rings and shuffles will influence latency. A true fabric would deliver better latency performance, but of course many “fabric” switches aren’t really any-to-any non-blocking. Just keep this in mind.

Amazon started proving this in at the end of 2024 in one data center, and in April of this year it was adopted as the default architecture for all new AWS data centers. It reduces cabling complexity, operational errors during updates to the data center, failures, and the number of switches needed versus the tree-hierarchy approach. The latter, of course, may be why a data center user like Amazon came up with this rather than a network equipment vendor.

I think Amazon’s move is a proof point for something I’ve said in a past blog; data center traffic is driven by more than just AI, and in fact “horizontalization” of application component traffic may be for most users the greater driver. It also, I believe, demonstrates that it’s inside the data center where AI models are hosted that the greatest network impact of AI is likely to be found, at least for the moment. The new strategy seems to answer some network and traffic questions, but not all of them.

First, it appears that this approach could be used for traditional and AI data centers, as long as you had a handle on the traffic loads to be handled. That’s something that’s possible through simulation but easier for those who already have a tree hierarchy in place supporting an application/server mix, and want to expand or improve it. Some of the enterprises who mentioned this approach to me had concerns that the dynamism of application configuration and usage might drive changes that would impact the design, but admit that’s true for any data center network model.

Second, some enterprises wonder whether the Amazon model might also reduce the number of servers needed to meet QoE objectives, by reducing horizontal latency. Would the traditional approach to a scaling problem perhaps involve adding servers to reduce response times? Amazon has not commented on this so far, but if they’d like to do so on my LinkedIn post or to me via email, I’m all ears.

Third, given the relentless focus of network vendors on AI traffic, could Amazon’s approach help or hurt vendors? It does look like you could buy less network gear with this model, and since data center switches are increasingly a target for revenue-hopeful vendors, might this derail some confidence in predicting sales growth due to AI? It’s clear that Amazon is already targeting a reduced switch spending target, and I hear both Google and Microsoft are doing the same.

Fourth, does this all mean that vendors who offer both servers/platforms and network switches will have an easier time? If there is a move to address AI or other horizontal traffic growth by remodeling networks to reduce switch count, the vendor who can also supply other gear like the servers generating the traffic will have greater influence and incentives than the one who has only network gear in their inventory. This could help HPE/Juniper, and potentially hurt Cisco, whose server business isn’t all that active. Or, perhaps, make Cisco get more server-aggressive?

Fifth, is this a full and best-of-the-lot solution? There are still hops, still potential variations in latency, versus a true any-to-any fabric. There also appears to be a risk that improper setup or careless changes in the configuration, including adding and removing things or even accidental unplugging of a cable, might set up a chain reaction. Still, as I’ve said in many customer tutorials in the past, “There’s no substitute for knowing what you’re doing”. It’s just this is a different sort of “doing” than most will be used to. For large-scale data centers who want to avoid full-fabric costs or who simply can’t get a true fabric with enough capacity, this seems to be a great idea. For smaller ones, I think it may offer minimal advantage over traditional layered switch models, and for AI model hosting that spreads across servers, the latency could be more of an issue.

The final, and perhaps most important question, is whether the Amazon move suggests we’re extending the more-for-less thinking that’s dominated enterprise IT planning for the last couple of decades. Enterprises have already shifted to the cost-savings model of planning, are the hyperscalers now doing the same? Could it be that AI hype is coming home to a lot of roosts?

Wall Street believes there’s a major risk that AI is a bubble. I’m of the view that it’s a PR-and-media bubble, and that it may well be approaching being over-invested based on current opportunities for revenue. If that’s true, one of the responses could be to try to cut costs without dissing the AI hype that’s keeping so many stocks afloat. A better response would be to work to find future opportunities for revenue, like those in real-world-real-time services.

Wireless standards evolution has, in the past, worked well for telcos. It’s what brought broadband Internet services and enabled the whole smartphone revolution, after all. But over time, it’s focused telcos on coming up with features to enable new applications, not to extend old ones (like Internet access) to mobile, and telcos have been unwilling or unable to promote all the ecosystemic components of the new stuff. Arguably, they’ve not even thought about what the new stuff might be. I’ve said for years that this was a strategic fault; you can’t expect fancy new apps to spring up without the required business cases for all the stakeholders the apps would depend on. Nothing has changed here.

What may have changed then? The answer lies in the nature of the “Gs”, which are really all about mobile access and potentially service/access independence. In one sense this is logical; most “new applications” of network services would necessarily have new access requirements or they wouldn’t require changes in services at all. In another sense, it’s opening a big problem.

Access is a sink for roughly a third of all network capex. Because access services get you on the network, they are baseline requirements that aren’t linked to a specific desirable application, but to…well…access to applications. Table stakes, so you can’t price them too high or nobody comes to the table at all. Consumer broadband is a good example of this; the price per bit of consumer broadband is insignificant compared to the price of business bandwidth, especially if you consider history. I remember when the average business paid almost a thousand dollars a month or so for 1.5 Mbps of access; today twenty or thirty bucks a month gets you a couple hundred Mbps in most developed markets. So access has a high capex and low base revenue; meaning it has a lousy ROI.

Telco focus on the “G” succession in mobile service, then, is focusing them on the connectivity role that at least sustains and might even exacerbate their revenue per bit problem. And this is happening as seemingly unrelated industry forces are pushing things in an unfavorable direction in the access space.

Let’s start with the cloud. Cloud computing is a byproduct of the shifting of consumer information-gathering to an online task. Gathering information is an irregular, unpredictable, activity overall, and most enterprises quickly found that the level of traffic generated by these applications varied considerably. If you sized your hosting for a typical safety margin above the average, some outside factor could drive up demand suddenly, resulting in your failure to serve your users, and likely poisoning the relationship. If you sized for the peak, your hosting costs skyrocketed. So you bought hosting from a third party (the cloud provider) who could average hosting costs across a large base, creating the classic economy-of-scale resource pool.

But if this is the typical situation, which it is, then more and more consumer broadband is simply getting users to a cloud. And why couldn’t the same strategy work for employees in remote locations or working from home or on the road? If that happens, then the low-ROI consumer access network gets everyone to the cloud, and the cloud provider offers a connection to your data centers. If you have the average thirty sites of a multi-site business, you might have had thirty-one (including your HQ) expensive business data lines. Now you have one.

Then there’s voice and text, traditional non-Internet services. Every mobile plan to speak of includes them, but most have shifted from linear voice to VoIP. And what are voice or text services seen as most important for? Emergencies, which is a problem because anyone in a remote area or anyone whose Internet is down suddenly can’t use them. So they want satellite backup. How long will it be before satellite companies can offer basic voice/text? That doesn’t mean that telcos can’t sell theirs, but it does mean that at least some users will be looking for a mobile cellular service that doesn’t include voice, and that the notion of a “universal number” independent of provider is in the offing. How much of mobile service stickiness is generated by a phone number and the hassle of porting it?

The same is happening with video; cable companies are finding it harder to sell linear TV, with users moving away from scheduled to on-demand viewing and with TV sources offering streaming services. Streaming video means that there is no unique video channels to sell users, no extra revenue. Cable companies had a big advantage over telcos because of those channels and the “What’s on?” mindset. You can already see that going away.

How does this impact our progression of mobile service standards? Well, low-latency is a way of getting real-time data to a processing point with minimal delay. But who makes the money on it? The processing people. Low-latency broadband would just be a new generation of table-stakes connectivity. And how about network slicing? What applications require special QoS? Not ones we have online now, so new ones will be hosted, and the same sort of disintermediation the cloud generated will now hit these QoS-dependent apps.

Mobile standards are an access trap for telcos. Even if they succeeded, they’d succeed in the context of an application ecosystem that rewards other more experience-related players far more than it would telcos, while focusing telco spending on an area that is not only low-ROI by nature, but is also cannibalizing (via the cloud and SD-WAN) other more profitable business access opportunities. They’re getting sucked into the communications-services equivalent of a draw play, and they’re not only not resisting, they’re actively helping with their own disintermediation. And they’re not going to stop.

That’s why we have to watch the players like Ericsson and Nokia. They’re remoras on the telco sharks, so if telcos starve so do they. And as equipment vendors, they have a broader infrastructure view. So think less about 5G or 6G or any-G, and more about what these vendors are trying to do at the application level. That’s the only stuff that can get telcos back in the game.