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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Among operators, the big requirement for 6G is simple; it has to be more technologically evolutionary than revolutionary. Operators are almost universal in their belief that 5G didn’t return on the investment it demanded. The majority (just shy of three-quarters) also express reluctance to accept any promise of new revenue to offset costs, which means that they expect 6G “transformation” to be accomplished with a lot less hardware deployment than 5G.

Among vendors, you get almost the opposite picture, which isn’t much of a surprise. They want 6G to be a true infrastructure revolution. One vendor eagerly told me that “6G will transform every device that touches a network.” You can almost see them counting the prospective money. The thing they believe is that it’s all about speed and latency. “We will offer terabit service; we will offer latency measured in single-digit microseconds.”

Build it and they will come meets build it on the cheap.

There are some “technical” goals that both camps accept, and they’re mostly related to cost reductions that satisfy the operators but focus on something other than capex, so they don’t hit vendors’ bottom line. One example is energy efficiency, another is reductions in network complexity. There’s also interest in RF efficiency to get more from available spectrum, which could lower the cost of achieving some of the feature/function goals.

A couple of smart people in both the operator and vendor camps offered what I think is the most realistic summary of 6G goals. To paraphrase, 6G has to prepare the network for the evolution of applications and experiences that businesses and consumers will want or need going forward, so the network will not create a barrier to their growth. This means that the network will have to anticipate these new requirements in a way that fosters early adoption and experimentation, but does not impose a high “first cost” on operators, an impact that could delay or even stop deployment.

These smarties think that what’s likely to happen is an advance into 6G in phases, each phase offering a useful step that manages cost but introduces new capabilities to encourage application development. One very interesting comment these people offered was that private 6G and FWA may end up being the keys to 6G success. The reason is that many of the features of 6G would logically develop from applications with a very limited scope, more suited to private wireless, and would expand to wider geographies only if they were proved out in the early private missions.

Again, paraphrasing: Low-latency applications are real-time applications, and these are today almost totally limited to plant and campus distances, supported by WiFi and wired connections. One goal of 6G is to be the sole accepted solution to real-time low-latency missions, which we’d call IoT missions. To make that happen, it has to go into the plants and campuses, and displace local connection options there, rather than depend on new wider-ranging and as-yet-undeveloped applications that WiFi and wires can’t serve.

The first phase of 6G, say this group, has to focus on efficiency and on this private-mission goal. They see early private 6G utilizing current 5G spectrum, but using a simplified network model versus 5G, and relying more on machine learning to make components of the service work autonomously. As these applications expand, the literati think they’d likely open new spectrum at the high end of the mid-band, in the 20-24 GHz piece of the 14-24 GHz range. This spectrum has potential as a private resource, in part because the shorter wavelength doesn’t propagate as far, and carving out something in this range for local exploitation has less impact on future exploitation of the mid-band by operators.

The simplified model this group is thinking about is about building wireless networks with fewer boxes, meaning eliminating things in 6G that were really introduced in 4G and continued in 5G. One proposal many make is to completely rethink the concepts of the IP Multimedia Subsystem. Anyone who’s looked at an IMS diagram recognizes that there are more different boxes in it than in the whole of the rest of IP networking. The group believes that the nIMS (as one calls it) should be viewed as a mobility-capable overlay on a standard data infrastructure, one that is provisioned to have the capacity needed and that therefore has little reason to manage it.

One goal of nIMS is to make it possible to deploy private 6G at the plant/campus level, using resources enterprises either have (current local-edge process control servers) or can acquire and manage in the way they’re used to handle compute. Think of it as running on Linux blades, and the only new thing needed is the radio setup. Some of the thoughtful group think that any specialized features might also be hosted in a router blade, and that in particular, any User Plane functions of nIMS should be router/switch features and not custom devices.

To facilitate the expansion of the private 6G model, the group think that spectrum policy is critical. They recommend a chunk of the top end of the 14-24 MHz spectrum be allocated for government/utility use in smart cities, with priority given to any municipality with at least 100,000 population. Since smart cities are one of the specific 6G application targets, this would encourage development of 6G solutions rather than force cities to use an earlier alternative. They also say that 6G should run within any 5G spectrum available, public or private, which would mean it could in theory be used with existing radios if 5G were already deployed.

The big points this group makes are related. First, you have to make 6G start small, with minimal “first cost” and that cost focused on preparing for a private 6G application-driven evolution. Second, you have to ensure that every step in the process is aimed at just getting you to the next step by opening new benefits gradually, as the service opportunities justify. Operators in this group agree that it’s first cost, the cost of an initial deployment, that matters, and that by targeting limited mass-market deployment early on, you could manage their first cost and risk.

But, of course, you don’t address the vendor problem of wanting a boatload of money, nor do you eliminate the risk that the gradual roll-out doesn’t generate any validating missions, and that 6G then never does anything revolutionary at all. But better to fail on the cheap than to fail expensively.

One thing we can say confidently is that there’s still more provider interest in mobile services than in wireline. That’s probably a good place to start, so will mobile drive the future network? I think it depends on what part of the network we’re talking about.

The recent interest in satellite-to-4G-phone service illustrates that one force in mobile networks is the desire to be connected everywhere. There are two prongs to this particular force; rural broadband and remote in-touch services. The former relates to the desire to project reasonable broadband quality to locations that are difficult to serve with traditional wireline or even FWA technology. The latter relates to both emergency calling in the wild, and simply keeping in touch when you’re kind of off the grid.

Another force in mobile networking is the presumption that broadband capacity limits the ability of the Internet and OTT ecosystems to provide new services and features. Thus, having more mobile bits to play with is inherently a good thing, which is why so much of 5G hype centered on the greater bandwidth it could provide. Pushing more bits requires fundamental changes to not only mobile infrastructure but also mobile devices, and this of course enriches vendors.

Wireline, as I’ve pointed out, is generally less interesting to operators than mobile services, but there is a third force in this space, created by the combination of a gradual gain in the use of the Internet as a transport media for VPNs (via SD-WAN or SASE) and the uncertain regulatory status of premium handling features on the Internet itself.

The future of service provider networking likely depends on how these three forces work for and against each other in the coming decades.

Let’s assume that the “everywhere” force dominates. This clearly further accentuates the interest in and profit from wireless, and likely focuses a lot of attention on 6G. Given the almost-universal (and rightful) discontent operators had with the ROI of 5G, we can expect this attention to take the form of explicit ROI pressure by the operators, pressure that will demand that either a convincing and significant new service revenue stream can be identified, or that the cost of the 6G transformation is minimized. Operators are skeptical about the former (once 5G-bitten, twice 6G-shy) and so are already saying they want 6G to be a software upgrade wherever possible. That means that any significant new equipment revenue would likely be limited to the radio itself, perhaps not even including other elements of the RAN subsystem.

I would expect that this would tend to direct 6G to “capacity” in some missions (like FWA) but perhaps more to the integration of satellite services and mobile services, improving on the symbiosis with 4G already coming in satellite broadband. There is potential for this to create a value-add (meaning incrementally profitable) service, which would help 6G’s credibility considerably.

Anything that makes FWA potentially better, particularly things that might make the number of customers per unit area and the per-customer capacity higher, would shift deployment focus more toward FWA. The limitations in mobile devices to meaningfully display content with resolutions above full HD (1920×1080) make it hard to justify faster device-mobile connectivity, but in FWA missions even 8k video is a reasonable longer-term target.

Universal connectivity might also come to mean IoT connectivity. For IoT to step up, it seems essential that it be both inexpensive enough to adopt for basic sensor missions, and widespread enough to accommodate the sort of mobile IoT applications already emerging in transportation, even personal vehicles. Might a universal 6G mobile-and-satellite combo be a way to go there? Perhaps, if it could be structured to be inexpensive for the real missions it targets, and have limited or no risk of being arbitraged for missions served already by higher-priced mobile services.

The big risks in this evolution overall are the proven inadequacy of standards initiatives to address real-market conditions, and the risk of vengeful vendors pushing back on a process that leaves them limited opportunity. One of the largely unrecognized impacts of a software-6G framework is that there is virtually no opportunity for any vendor other than one of the wireless infrastructure giants of today (Ericsson, Huawei, Nokia) from gaining much traction. This is the group that has dominated 5G despite operators expressing a desire for an “open” solution, and so whatever 5G technology has deployed and is expected to be software-upgraded to 6G (with perhaps some new radio stuff injected) comes from these vendors. Operators admit that they don’t see much chance of their buying 6G software from a new vendor to go into 5G hardware from one of these three. “We’d be multiplying integration and finger-pointing when we want to limit it,” one told me.

All of this tumult tends to collide with the goal of operators to converge all their services on a single infrastructure. This collision is created in no small part by the nature of the Internet’s bill-and-keep, net-neutral approach to services. Mobile services, from Release 5 of IMS two decades ago, have allowed for special handling of sessions to mobile devices. Might this encourage operators to think of their access networks as service-neutral, their core as an extension of “the Internet”, and try to push services out into the access side to avoid colliding with neutrality rules, which blow in the political wind? Could IMS, network slicing, or both somehow extend into wireline access? Could 6G help with that?

Another possibility some operators cite is repurposing the current MPLS VPN model. MPLS VPNs are created with substantially the same resources as operator Internet backbone services, and they don’t get neutrality push-back. Suppose that MPLS was used for what we might call a “SD-WAN-net”, a backbone where business services run, separated from each other by the SD-WAN level of technology and from the Internet by MPLS? Would that still pass the regulatory sniff test? If it did, might it meet up with an IMS-ish structure in the access network of both mobile and wireline? Might something like that also support IoT? I think this is the question we need to be looking at if we cast out eyes two decades forward to look at service provider evolution, so I’ll touch on it later this week.

Enterprises don’t see any specific shifts in the missions that drive networking to change things in the next three years. If that’s true, then it’s likely that the same cost-driven network modernization policies that have been in force over the last decade (except during the COVID lockdowns) will continue to drive things. More for less, then, is the goal.

One area where there’s a lot of interest is in branch or secondary site access. The traditional approach to this has been the MPLS VPN, but enterprises are very concerned about site access costs, and VPN access will, they say, cost as much as ten times the price of the same bandwidth delivered as business Internet. Yes, they admit that QoS and reliability might be better with the MPLS VPN, but they point out that companies depend on the Internet for direct prospect/customer connectivity already, and that mobile workers or those in home offices or mobile also depend on an Internet path back to enterprise applications.

Of our 294 enterprises, all say they already depend on the Internet to reach customers and prospects, and all say that mobile workers use the Internet to reach the company VPN. About a third say that some branch locations are connected via the Internet already, including those who use mobile-worker VPN access techniques for very small office locations.

Formal SD-WAN or SASE is harder to pin down; roughly a fifth of enterprises say they use it, but I’m not confident that all those who don’t say are in the “don’t use” category. For example, 147 of the 294 commented on what site conditions would to them justify VPN connectivity, which is exactly half the total, and why would they have a view here if they didn’t have to decide between VPNs and an Internet-based VPN connection somewhere?

With regard to those comments on site conditions, the primary metric enterprises say they look at is the number of workers. On the average, companies suggest that an IP VPN isn’t cost-effective in sites with fewer than 17 workers, but the nature of the workers and the work seems to influence this. Companies whose remote sites are largely staffed with high-unit-value-of-labor professionals (healthcare, finance, etc.) set the decision point as low as 8 workers, and those whose office locations are staffed with people whose labor value is lower set it as high as 28. The presence of any custom network-connected devices (again, common in healthcare and finance) argues in favor of MPLS, too.

Of the 294 companies 208 say they could do more with SD-WAN and related technologies, meaning that there are sites where they believe it could be applied. The “why-wasn’t-it” comments offered center on simple inertia; enterprises tend not to change things unless there’s something specific to drive them to consider change. Here, there seems to be an indication that a driver is emerging. Among the 208, 78 say that they are “considering” initiating or expanding the displacement of MPLS VPNs, and all this group cite a company drive to reduce network service costs. Most interestingly, of the 28 comments I’ve gotten since the latest tariff/market flap, 22 say that reconsideration of MPLS VPN usage is likely to come along. This suggests that financial uncertainty could generate an interest in a preemptive cost-reduction push, even before any specific need to do that has emerged.

AI is another complex topic, even beyond network implications but especially within them. Going back to the first Andover Intel comments on AI back in early 2023, enterprises weren’t really considering the issue at all. Within a year, they divided into two camps, the AI-traffic optimists and pessimists, with roughly two thirds in the first group and the remainder in the second. Even at this point, there wasn’t much specificity regarding what kind of traffic is generated and where it’s going.

In late 2024, most AI-traffic optimists said that the primary impact would be from self-hosting AI, and likely in the data center LAN. The optimist group had grown, at this point, to account for three-quarters of enterprises. The pessimist group didn’t see self-hosting at all (they believed in cloud AI) or they didn’t believe in large language models, generative AI, or extensive AI training. This group, while small, included a larger percentage of companies who’d actually adopted AI for significant business missions.

I think the pattern of viewpoints is due to the evolution in the level of actual AI experience, in the planning phase and then in deployment. Everyone comments on things that they know are new and think are interesting, but only when businesses start a real exploration can we expect the comments to mean much in a predictive sense. This is why surveys get things wrong so often; if you don’t validate actual familiarity in some way, you can bet that everyone will comment on any exciting new technology, but their comments will rarely matter more than what you’d get from a random encounter on the street.

The broadest comment from enterprises, made by 221 of 294, was that increasing the performance and reliability of the data center network was important. This group is larger than the number who explicitly cite AI as a driver to the data center LAN (133), and things like increased use of virtualization and greater traffic loads in general were cited, but equally important was the view that technology improvements should make it possible to increase capacity well beyond any (minimal) increases in cost. Modernization, then, is still an explicit driver of network change.

Enterprises didn’t have any significant number of comments on their broad networking goals, another indication that they aren’t seeing these goals changing. I think that even AI and SD-WAN are simply examples of things they hope to accommodate in the orderly more-for-less modernization. What might drive a more proactive, business-driven, model shift?

A business case, obviously. If we look only at the question of model-generative forces, we could speculate that the business case would have to create new network-connected workflows, which means a combination of new data and new data consumers. “New” here would mean previously unexploited, which likely means that the new data consumers would have to be drawn from the 40% of non-office-centric workers. New data would then mean information either not previously collected at all, or collected but not fully utilized, that associates with these workers. That would almost surely mean IoT data, or “telemetry” as some would call it.

OK, you’ve heard this from me before, but truth is truth. If we want to see a big jump in network and IT spending, we have to unlock a big new benefits pool. But there is perhaps a new wrinkle here. Of a separate group of 188 companies who reported use of IoT, 173 said they had a significant edge computing initiative dedicated to the control of real-time processes. Of that group, 73 said they collected all of this for analysis, 42 said they collected some, and the remaining 58 said they didn’t collect any of it except as a backup. Is all that data not being collected and analyzed truly useless? Could we examine it and look for productive uses? Might we then identify some new network missions? Worth thinking about.