Month: March 2021

According to Light Reading, 6G is getting messy. Well, 5G is messy too, and I think it’s time to accept a revolutionary point, which is that we’ve passed the point where the traditional international standards processes like the 3GPP work. We need to think differently, totally differently, in considering how to evolve networks and services.

Let’s start with an obvious point. Wireless generations, the “Gs” we always read about and that include both 5G and 6G, are the wrong way to go about things. 5G standards have taken over a decade, and optimists hope that 6G could follow in another decade. This, in the era of the Internet? Nothing we know about tech at the start of a given decade has much value by the end of it. The process of evolving mobile and other services should be gradual evolution, not successive, obsolete-before-they-take-hold, revolutions.

The next question, also obvious, is how the gradual evolution should progress. We all know the answer to that one; software. The consumption side of network services is totally software-dependent, and we all know that software has a short development cycle compared to hardware. Applications can often be deployed in less than a year, and changes in applications in a matter of days. We have a whole science, sometimes called “rapid development” and sometimes “CI/CD” for “continuous integration/continuous deployment”, that aims for short turnaround between business needs and software to support them.

Software is also what’s responsible for virtualization and cloud computing, the second concept being an application of the first. Virtualization and the cloud defined an ongoing evolution of how we build and deploy software applications for maximum efficiency and availability. There is probably no space in all of technology that’s progressed as far, and as fast, as these two areas.

The 5G evolution we’re in at the moment, defined as all mobile evolutions are by the 3GPP, recognized that software and virtualization were the keys, and so was the first of the 3GPP standards to really be based on function virtualization. It was a noble thought, a noble effort, and largely a failure, and we can see some of the effects of that failure today.

First, virtualization in 5G is linked to the ETSI Network Functions Virtualization (NFV). NFV was a 2013 project that’s still churning on, but that produced a box-centric vision of what virtualization and software-centric network features would look like. There was no real knowledge of the public cloud involved in NFV specifications; the “functional diagram” translated into a set of flows between monolithic elements, with no provision for incorporating even 2013 cloud awareness. Since 2013, of course, the cloud and virtualization have continued to evolve quickly, and so NFV is now hopelessly behind.

You can see that in the Open RAN (or O-RAN) initiative. O-RAN took a key element of the 5G RAN that was defined by the 3GPP as a typical virtual box, and turned into a cloud-ready and perhaps even cloud-native, software application. Had 5G standards truly exploited virtualization and the cloud, the O-RAN work wouldn’t have been necessary.

Then there’s the recent story about the security flaw in 5G network slicing and function virtualization. The article quotes the people who identified the problem as saying that network bodies that adopt software and cloud technology have to change their mindset. Darn straight, but the truth that such a change isn’t possible even in the decade-at-a-time generational evolution that’s common in telecom. Cloud people wouldn’t have done 5G this way, wouldn’t have left the holes for other projects to fill, and wouldn’t have exposed the security problems that were left behind by the 3GPP.

The truth is often unpleasant, and it’s going to be that in the case of 5G/6G, but here it is. We have to throw out the 3GPP process completely, and in fact throw out most telecom standards processes completely. Everything these days is a software and cloud project, period, and it’s time to accept that means that software and cloud project practices have to be the foundation of everything. The old stuff is obsolete.

You’re probably thinking at this point that I’m going to say that open-source software project structures are the answer, and you’re half-correct. Open-source software is the answer, but we have had many bad open-source software projects in the networking space. The NFV management and orchestration (MANO) stuff is proof that open, collaborative, development doesn’t overcome poor design. Same with ONAP. We have actually tried open-source a number of times in the telco world, and almost all the attempts have failed.

How do things go wrong so consistently? Knowing that is probably key to making them go right, so let’s start there. In both NFV and ONAP, the problem IMHO was a series of truths that led to a bad place.

Truth one. Telco people are not cloud people. That’s particularly true of people involved in telco standards. They don’t automatically think in cloud terms. Networks, through most of their careers, were built by connecting boxes, so they’re box people. When box people do what they think is “cloud”, they do collections of boxes (virtual or real) that don’t move the architectural ball at all.

Truth two. Requirements insidiously morph into specifications. Technical people of all sorts are problem-solvers. Ask them to set out requirements, and the temptation to define those requirements in terms of a presumed implementation is irresistible. A list of functional requirements becomes a functional flow chart. A flow chart becomes a software implementation model.

Truth three. You have to design for the cloud to create cloud software. I was heavily involved in NFV from the first US meeting in the spring of 2013, and I fought from that meeting forward to bring the cloud into NFV. By July it was hopeless, in retrospect, because box momentum was by that time irreversible. It could have worked, though, had any major vendor or major operator gotten decisively behind the effort.

That brings up truth four. Network vendors dominate network evolution, and they’re protecting their own short-term interests. Network operators tend to look to the vendors, because they’re accustomed to building networks from commercially available technology, not promoting technology from concept to commercial availability. The network vendors, having incumbent positions and quarterly sales to project, aren’t in a hurry to transform anything.

That lays out my vision. What 5G needs, what transformation needs, what we need to stop the “Gs” and move network software into the present (much less future), is competing vendor vision. What the telco would should do is mandate that their critical software be open-source, then encourage cloud software vendors to create an open-model architecture for their review. The vendors make a pitch, and the winner is the player who leads the implementation project. The project is open-source, other vendors and interested parties are invited to contribute, or to leave the project in control of the winning design source, which of course would be competitive disaster.

A good, complete, 6G cloud architecture would take a team of three to five architects about six months to create. Add in three months for review of competing approaches. Within another 15 months we’d have code, and that two year period wouldn’t have been long enough for a standards body do accomplish anything other than draw diagrams that would unreasonably constrain the future they were trying to promote.

The reason this would go so fast is that cloud architects would see telecom projects as things that need to be solved in the context of current cloud tools and techniques. A major part of the work is done already. It’s just a matter of recognizing that, and recognizing what does it. We even have cloud software vendors with special initiatives for service providers, but all too often, these initiatives are handicapped because the operators expect them to include many of the NFV and ONAP concepts that were wrong from the first.

I’ve said before that cloud providers were a threat to network operators, and some posted their disagreements on LinkedIn. I hold to that position. No, cloud providers won’t become access competitors, but they’ll become service competitors who will threaten to tap off any high-margin opportunity. If operators, and network vendors, don’t want that to happen, they’ll need to get their own houses in order and present a vision of the future that actually solves the problems, not just blows kisses in the appropriate directions.

What happens when this is over, when all the noticeable impacts of COVID have gone? It’s surely a heady prospect for most of us personally, but what might it mean tech markets? How many things did COVID promote that will now be “un-promoted”, and how many suppressed things will now expand? A lot of companies are trying to read those tea leaves, and I’ve tried to model the trends too, so I’ll throw my predictions into the ring.

Let’s start with the obvious, which is the work-from-home (WFH) momentum that COVID largely created. In early fall of 2020, over three-quarters of companies were telling me that they expected to stay with WFH even when it wasn’t mandatory. Today, that number is less than a third, so most companies say that they will not make remote work a true alternative to traditional office work. This will have an impact on video collaboration tools, on the sale of laptops used in WFH, and on broadband service consumption.

Not, perhaps, quite as much as the numbers would suggest. While most companies don’t intend to replace offices with WFH, most do expect to allow more WFH, and almost half think that the majority of their administrative staff would be working from home at least two days a week. Not only that, companies believe that meetings with people outside their own organization will decline sharply. For example, among the two-thirds of companies that say they won’t replace office with WFH, almost 80% say that they will retain remote collaboration tools and video calling for these outside meetings, even using them for prospecting.

The net impact of all of this would be to reduce the use of video collaboration tools like Zoom and Teams by about 20% within a year of the end of COVID impact on gatherings and behavior. Even before that, we could expect sales of technology tools like laptops and home WiFi, designed to facilitate in-home work, to decline by about that same 20%. There is likely to be a small shift in broadband services and providers as people go back to a “normal” home broadband consumption model, but that won’t be as dramatic as the shift in broadband use created by other factors below.

While WFH momentum will reverse itself a bit after COVID, the use of portals to create direct engagement with customers and partners will not. In fact, companies tell me that they will be expanding their use of “web portals” to connect with stakeholders, and even to empower their workers while at their desks. Even though two-thirds of companies wanted to return to the office at least much (if not most) of the time, they all expected that they would still be working to make their processes less dependent on physical co-location. Call it “WFH in waiting”, which is one of the motives companies offer for the continued development.

This is important because the increased use of cloud computing can be traced largely to the portal concept. If use of portals will be expanding even post-COVID, then public cloud service use will also be expanding, and shifts in process management thinking will also likely continue to develop. Application design and process automation, then, have been permanently changed. So has hosting, in ways that I don’t think the market has yet fully appreciated.

The fundamental, core, transaction processing associated with most businesses is more static than we think. Take banking; the elements of a financial transaction are nearly fixed, it’s the presentation of the information that tends to change. That means that the “front end” of applications is actually where most changes are made, and if that goes to the cloud (which it has been doing during the lockdown) then the dynamic part of applications goes there. If the front-end stays, then the IT spending balance shifts permanently toward the cloud. It’s early to try to model this stuff given that we’re not even out of the pandemic at this point, but one effect that my model predicts is that the percentage of applications that could be moved to the cloud will increase from 23% to 37%, better than 50% growth. That means that in addition to shifting front-end application logic to the cloud, some core logic will be pulled through.

By 2024, I think it’s very possible that IT spending will have shifted to the point where over half of it is directed to public cloud services, something some forecasts have suggested incorrectly that we’ve already reached. Enterprise cloud spending isn’t there yet, not nearly so, and even total public cloud spending hasn’t reached 50% of total IT spending.

This total-spending category includes the startups and social media players who really account for the largest chunk of spending on the cloud today. By around 2024, that will continue to be true only if “carrier cloud” takes off, and 2024 is likely too soon for that to happen. Thus, we could see true enterprise cloud spending dominating public cloud computing in just three years.

We’re only now learning how to build the kinds of applications that will dominate in three years. Simplistic statements like “cloud-native is sweeping development” or “the cloud will mean containers are the way of the future” are only partly true, and the part that is true stems as much from the broad fuzzy definitions we have for the terms related to the cloud. We don’t know how hybrid applications, which is what nearly every business will run, are optimally built, because our use of hybrid cloud today is conserving prior application development in the data center. Within three years, orderly modernization will provide the opportunity to rethink these hybrid applications, and where they will go is still a bit of a mystery.

On the consumer side, we have a similar balance of what-changes and what-doesn’t. Lockdowns have limited social interaction and reshaped entertainment in a number of ways, and a relaxation of COVID restrictions will impact different parts of the social/entertainment story in different ways, some very complex.

COVID has increased the use of chat and social media, and my model says that at least half the growth in use will be permanent. However, the growth was modest to start with because the group that was most impacted in this area (young people) were already highly engaged via social media. Thus, it doesn’t appear that a COVID recovery would impact social-media revenues or activity.

On the entertainment side, there’s no question that streaming has benefited from lockdown behavior. Not only were people more likely to stay home, TV production was seriously impacted, meaning there were fewer new shows available. People had to find alternative video resources, and they did. Some of that behavior, accounting for as much as 40% of the growth streaming saw in 2020, is going to taper down as things get back to normal.

Gaming is also almost certain to taper down from what was explosive growth during the lockdown. However, there’s evidence already that this particular entertainment sector might not dip as quickly, because gamers change their habits more slowly than entire families, whose collective behavior creates a lot of the streaming market. In fact, gaming is likely to be a better sector in all of 2021 than TV and streaming, since TV production won’t recover until the fall, at the earliest.

All of this, of course, depends on the pace of vaccination and the way that mutations to the virus would impact spread of the disease, and thus human behavior. It’s likely that if there is indeed a spring/summer wave created by mutations, companies would be even more likely to invest in a WFH approach, and even encourage a persistent shift in practices.

Overall, it’s clear that COVID has brought about permanent changes in how we use technology, because it’s brought about the first massive change in “work behavior” and entertainment that we’ve seen in decades. Some of the changes are taking us down new pathways, and those shifts may bring about future shifts. We may not see the end of the impact, or even the end of the pace of changes the virus generates, when the infection period passes.

I’ve done a few recent blogs on telco risks. It’s now time to talk about what they can do about them. I think most people in the industry, including most telcos, would agree that the future for network operators has to be different somehow, but how? And no, I don’t mean that all they need to do is babble about new 5G revenues from sources that can’t be validated, either.

The basic problem that network operators in general, and telcos in particular, face is commoditization. Connection services, meaning services that create connections between users, or between users and applications/experiences, are almost impossible to differentiate except on price. You can see this in the increased reliance of mobile operators on smartphone deals as a means of attracting and retaining customers. The cost of customer acquisition and retention is, for most operators, the fastest-growing cost of all. A lot of the 5G hype is really an attempt to make 5G a differentiator, and from the near-universal support for 5G that’s quickly developed, it’s clear that’s not going to work.

Commoditization is what’s behind the profit-per-bit problem operators have faced for over a decade. In the very first presentation on the topic an operator made to me in 2010, the slide showed a revenue-per-bit curve declining, a cost-per-bit curve declining more slowly, and the two converging in around 2018 if no action were to be taken. Obviously some actions have been taken because the same curves, drawn today, show the point of convergence around 2023-2024. Still, delay of the inevitable is preferable only to facing it immediately; it would be better not to face it at all.

Cost management vanishes to a point. Measures to lower cost are important, but they can’t make the “inevitable” into the “avoidable”, only buy some time for other measures to take hold. You can make routers cheaper, but not free. You can make operations zero-touch, but not negative-touch. At some point, if you want to avoid collapse, you have to raise revenues, period. I tell operators today that a point they must raise in their dialog with vendors is “What will you offer to raise my revenue line?” Even if cost reduction is what the vendor wants to talk about, don’t talk if you don’t get a satisfactory response to that question, because that vendor cannot save you.

There are two broad possibilities for raising revenues; you can either enhance connection services in a compelling way or sell something other than connection services. The former is the approach that network operators in general, and telcos in particular, find almost hypnotically beguiling. It must therefore be subject to the most objective and thorough examination. The latter is something that operators/telcos should have done ten years ago, when it would have been easy. Now it’s going to be hard, and not only because it involves a culture shift.

Given all this, let’s return to the cost-management band-aid. Any new revenue strategy can be compromised by inefficient cost management, and of course so can the basic connection services strategy. We all know that it’s unlikely that competition would make every current connection service into a loss leader; a race to the bottom doesn’t stop when you hit bottom, but when you are at risk of going under water. The fixes operators have created for the convergence of revenue and cost have largely been focused on operations costs. Operators need to have an automated, efficient, service lifecycle automation story, period. It’s essential in realizing the full benefit of new revenue opportunities, and so we’ll address it in that context.

Now back to revenue, and to the first option of enhancing the revenues associated with connection services. The prevailing hope of operators is that you can add features to connection services to make them more profitable to operators and still also more valuable in cost/benefit terms to consumers. For at least a decade, and likely for far longer than the whole profit-per-bit craze has been emerging, the idea has been to add service features that users would pay more for by absorbing into the service add-on features that are normally provided by CPE. Security has been the primary target.

While Network Functions Virtualization (NFV) was a general concept for hosting functions as an alternative to using proprietary devices, from the first, NFV was turned in the direction of “virtual CPE” or vCPE, which aimed at making edge devices into service elements operators could charge for. The fact is that there is not now, nor has there ever been, a compelling argument for integrating edge features into services via vCPE. In most cases, an appliance solution is inexpensive; look at the home or small business WiFi router as an example. NFV’s operational complexity would make it difficult to secure even cost parity with a traditional edge device.

What might work, then? It’s long been my view that if you want to evolve to meet an opportunity, you have to build to where the opportunity is heading, not to where it is at the moment. The evolution of connection services is personalized connection services, which means network-as-a-service, or NaaS. NaaS says that the best “network” is one that exactly fits what you do, and prevents you from doing what you’re not supposed to be doing. NaaS is really what gluing a bunch of new edge appliances onto a network demarcation was heading, imperfectly and inefficiently, for.

The fundamental element of NaaS is the notion of a virtual network. You can’t give every user their own network infrastructure, so instead you give each of them a virtual network, a network that looks like it’s their own, and thus fits the NaaS model. Any solution to enhancing connection services that isn’t based in some way on a virtual network is an excursion to nowhere. Those who want to sell it can only hope for perpetual buyer ignorance to save them. Those who buy it are committing to an ever-growing cost that will ultimately fail to deliver value. SD-WAN is the best track to the right approach to NaaS we have today, period.

Properly done, NaaS can be a revenue kicker that takes operators well into the second half of this decade, but eventually it commoditizes too, because what users really want isn’t being connected to their applications/experiences, it’s having them. And applications or experiences have to be created to be had, and creating them means deploying cloud infrastructure. Carrier cloud is absolutely critical for operators to deliver on future revenues. Eventually, all other kinds of revenue measures will fail to meet operator goals. An operator without a carrier cloud strategy is an operator praying for nationalization or subsidies.

But what would a carrier cloud strategy look like? To start with, let’s address what it wouldn’t look like, which is a situation where operators outsource their cloud tasks to the public cloud providers. I’ve modeled this approach from multiple perspectives, and every one of the results puts the operators in a significantly worse position by 2025, most by 2024. Like many others, I’ve postulated that operators might gain knowledge from these relationships, but while that’s true in a general sense, the nature of the relationship between the two parties has to be defined just right for the benefit to shift to the operators.

If you are a network operator, you do not want to host your 5G in 5G-as-a-Service form using cloud provider infrastructure. You do not want to use any specialized service features of any public cloud provider. You want to host virtual machines in IaaS service form, and nothing else. The cloud provider is simply a lower-cost starting and remote-area strategy for hosting your carrier cloud. You don’t help them build theirs. That’s the starting rule, and it’s as hard-and-fast as any rule my modeling can define.

The second point is that network operators should not plan to build their own software for 5G or any other carrier cloud application. Even the best of them have proved they don’t understand cloud architecture well enough at this point. They should base their software strategy on open-source tools acquired if necessary from major firms (IBM/Red Hat, HPE, and VMware are the giants, but some other smaller ones are also fine) who can integrate the open-source elements and even provide support for new open-source initiatives. Open source software and IaaS hosting, combined with deployment of provider-owned data centers, is the pathway to successful leveraging of the public cloud.

While these software-platform partnerships are working, and operators are leveraging and exploiting public cloud, they should use the activity to build their own cloud skills. The presumption they should make is that they will have to hire in new people to be the foundation of their carrier cloud business, including and even especially at the management level.

There’s a single infrastructure target and two specific service areas that are the prime early targets for operator initiatives. The infrastructure target is edge computing and the service areas (which both relate to the infrastructure target) are IoT and contextual services. Operators have a massive advantage in edge computing that they’re in the process of throwing away, as I said in a recent blog. IoT and edge computing have an obvious symbiosis, but one that will require an architectural foundation. Contextual services are an application of edge computing that combines it with other technologies, including AI/ML and augmented and virtual reality (AR/VR).

The future of technology is arguably in the creation and exploitation of a pervasive digital parallel universe, a kind of massive multiplayer game in which everyone and everything is a player/element. IoT and other applications feed information between the real world and this parallel universe, and artificial intelligence draws insights from the data that defines the parallel universe to influence behavior and productivity in the real world. This is IMHO the touchstone for future experiential revenues, and so this should be the target toward which operators are planning their carrier cloud.

Going back now to NaaS, you can see perhaps the value proposition for it within carrier cloud. Site networking, meaning connecting clusters of workers back to a data center, is just pumping bits. When you start to create relationships between workers and consumers and hosted experiences, there’s a lot more dynamism involved. Even getting to that, changing application architectures and information flows to support productivity based on individual activity-centric information demands a lot more customization. NaaS evolves nicely into this contextual, parallel-digital-universe, future. It’s not the final answer, but it’s a step in the right direction that provides easy access to a near-term revenue kicker.

So there we are. A lot of people are going to say that this shift is too much for the telcos. Swimming for a lifeboat after your ship sinks is a lot of work too, but it’s probably not smart to think that difficulty is bad if the alternative is fatal. Commoditization, unfettered, is fatal, and telecoms need to accept that and deal with the alternative.

How much change in software is required for “digital transformation?” Do you need to redo everything to cloud-native form? There’s a school of thought, now represented by at least one startup, that thinks there’s a better way. According to Venture Beat, Camunda raised a hundred million dollars for cloud-native process automation software, and their approach might offer us a new option for transformation, even in networking.

I’ve talked in past blogs about the possibility of orchestrating project workflows, both the pieces that are already represented by applications and those represented by manual processes. To do this, you need a process model that represents how work (both responsibility and data) move through a complex flow to completion. There are a variety of tools that could be brought to bear on this problem, but there’s also an opportunity for someone to come up with a custom approach.

Camunda bills itself as “Automate Any Process, Anywhere”, a claim that’s nothing if not ambitious. It’s never easy to dig out an approach from a company’s public material, but Camunda seems to have created something like a super-enhanced version of an Enterprise Service Bus, an ESB, that steers work to applications using a business language, this making the workflow itself programmable.

The languages Camunda uses are BPMN (Business Process Model and Notation) and DMN (Decision Model Notation), and the two combine to allow process flow rules and decisions to be expressed and implemented, in the case of Camunda, in cloud-native form. There are seven components to Camunda’s solution, divided into the areas of design, automate, and improve. The first phase uses two tools to design business processes, creating the models. These are passed to the automate phase, which has four components to execute the process automation. The improve phase then has one component, which is really designed to manage the overall process and produce reports.

The interesting thing here, particularly from a network perspective, is that this is really process automation. The model created is used to sequence and direct work items, and it can be applied to applications or human processes (via a “work order” and a “completed” event). Thus, you could model anything and then automate its execution, even if the component tasks were old-line monolithic applications or human processes. Could this then be a way to describe service lifecycle automation?

I think the answer is that it could, and better yet, Camunda’s use of BPMN and DMN shows that these languages could be the basis for describing process automation, period. The questions would then be how these could be used in service lifecycle automation, and how the result would compare with things like the TMF NGOSS Contract approach I’m always citing, or ONAP.

In the TMF NGOSS Contract approach, there was a service data model (expressed in the TMF’s SID data model structure). This model defined a service as a series of components, each of which was represented to include a state/event table that related current state and incoming events to the process that was designed to handle them. The service data model would hold all the service parameters and data, and so any instance of a process could, with reference to the service data model, handle an event. That facilitates the use of stateless components, meaning that it would be naturally cloud-native.

While the TMF invented this, they never really implemented it, and the current “ODA Contract” doesn’t appear to include the concept at all. Thus, while this approach has always been the gold standard to me, it doesn’t appear to be supported, and we can discount it except as the iconic reference.

ONAP is the current implementation of the AT&T-originated operations automation tool. I had high hopes for this early on, but unfortunately it didn’t build from the NGOSS Contract approach of a data-model-driven event steering process. Instead it took a largely monolithic management view, not unlike that adopted by NFV’s MANO and VNFM. After a couple of releases where no model or model-driven approach was introduced, I told the ONAP people I would no longer take briefings on ONAP until it became model-driven, and they’ve not briefed me since. We can thus discount this approach too.

Which, of course, means we have nothing that we can really compare the Camunda model to, except in abstract. However, it appears to me from the documentation on their website and from the BPMN and DMN documentation that the languages would support the same capabilities as the TMF NGOSS Contract would have, though not in exactly the same way. I think that wrapping event-handling into a language rather than representing it as a table makes sense from a modeling and maintenance perspective; state/event tables aren’t naturally the language of humans, where BPMN and DMN are (with practice) human-readable.

I think that the approach Camunda is taking, and the use of BPMN/DMN in general to express process models for automation, would allow true service lifecycle automation to develop. It’s not yet fully clear to me whether Camunda’s implementation would preserve full scalability and even whether it’s truly cloud-native overall, but it looks promising, and clearly you could implement the models and the engines that interpreted them in a cloud-native way.

Which means, I think, that since the TMF is apparently not going to develop its own NGOSS Contract concept, this may be the way that service lifecycle automation should be heading. In fact, the approach has benefits that could be uniquely helpful in the telco world.

The first benefit is that process automation is functionally an outsider in the telco world. It doesn’t evolve from OSS/BSS, NMS, or any of the other “S’s” (no pun intended!), and so it’s a neutral play in an organization whose internal politics can confound everyone inside the company and out. In fact, since process automation is about model-based invoking of processes and applications, it could even be seen as providing integration across various operator business and management systems.

A related “outsider” benefit is that process automation is going to advance based on its broad-market value, not on its adoption by operators. In the world of open-source software, you can’t beat breadth of interest and support. Process automation tools are likely to advance faster than specialized telco tools would, and because they’re designed to support a wide variety of applications and manual processes, they’re more likely to adapt to a given operator’s situation.

It’s also true that process automation, at least the form that Camunda is offering, is model-based, as the venerable TMF NGOSS Contract was. It appears to me that it would be possible to build service models in the BPMN and DMN languages, populate them with order-specific stuff, and turn them into the closest thing to an ideal operations automation tool that we’ve been offered so far.

None of the operator planners I talked with about this were even aware of the company, though one was in fact a user of the technology in a narrow application. I don’t think the potential of the approach has been realized yet, and I hope that changes, and changes quickly.

If the telcos are under threat for basic services, from multiple sources, can they hope to gain new revenue at the edge? Telcos are surely potential edge players, but not the only ones, as Light Reading suggests HERE. Will there be competition for edge computing deployment, will telcos end up losing out to other more aggressive players (who would be less aggressive than a telco anyway?) The edge market has always been a bit of an opportunity question mark, and complications in terms of who provides the services could make things better, or worse.

The biggest question in edge computing is just what “edge” means. There are three theoretical possibilities. First, it could mean the customer edge, meaning the point of service connection or demarcation. Second, it could mean the inside edge of the access connection, which would typically be a telco central office. Finally, it could mean the inside edge of the access network, the place where access meets metro/transport. Each of these areas has advantages and disadvantages in terms of things like latency, and each drives a different business model for providers of edge computing.

Customer-edge technology favors a customer-purchased platform, though in theory a third party could provide a box for the customer edge, what used to be called “CLE” or customer-located equipment. The customer edge offers the lowest latency possible, but the poorest economy of scale, and since so far its ownership doesn’t seem up for grabs, the players most interested in it are the public cloud providers, who’d like to see cloud middleware pushed onto the customer edge to create a bond with the provider’s cloud solution.

Access edge is largely a space owned by telcos because they’re the most common access provider, but cable companies and independent broadband companies would also have pride of place in this zone. Because messages generated by users or “things” in IoT need travel only to the other end of the access connection, latency is as low as it can be without moving back to customer-edge solutions. There’s typically telco/cableco real estate available at the access edge, so you could site computing there, and because multiple customers are served at the access edge, you could justify a resource pool with better economy of scale than pure customer-edge deployment could achieve. If a deal with the owner of the access edge could be struck, third parties could hope to deploy there.

The interconnect edge, the inside of the access network, is the last edge and the one that creates the largest number of potential competitors. Content delivery networks (CDNs) have connections to the access network providers to facilitate high-speed delivery, and players like Equinix have data centers that connect to this spot, so there are hosting resources available for those who want to get into the edge game at this point. Since many interconnect edges share access to multiple local access networks, you can potentially reach a broader community of users with something hosted here, and so economies of scale are higher yet.

The biggest threat to telco’s natural edge position is still the cloud providers, for two reasons. First, they have successfully used the telco cloud-phobia as a lever to engage operators in edge partnerships. In exchange for cloud know-how (which the cloud providers likely figure won’t make the telcos into cloud competitors in any case), the cloud providers get access to telco edge locations to site 5G (usually Open RAN) hosting. Second, the cloud providers have been turning user edge hosting into an extension of the cloud.

I’ve blogged before about the impact of operator partnerships with cloud providers, and the fact that these risked the operators never getting around to building out their own facilities. If 5G applications at the edge do develop, the operators would then have no facilities available to offer them, or would have to pay a percentage to cloud providers through the partnership agreements. That could reduce the revenue benefits of higher-level services to the operators, and that in turn could cut off what is likely the most credible new revenue resource available to improve profit per bit.

The issue of the “creeping cloud”, as one enterprise CIO described it to me, is more insidious. The fact is that in applications where latency is critical, such as closed control-loop IoT process management, the best place to host an edge process isn’t at the service provider’s edge, but on the premises. Public cloud providers have accepted that, and their own edge strategies have long included offering tools that, when installed by an enterprise on their own edge, make it effectively an extension of the cloud.

The principal “insidious” aspect of this is obvious, because the tool that extends the cloud to the edge tends to tie edge development, and the user overall, to the cloud provider. It’s also valuable to the user because it creates a uniform edge/cloud platform with the best possible edge latency. If it were to take hold, it could have a major impact on edge computing as a service, favoring instead private local edge deployments.

Equally insidious is the impact of the approach on the way telcos would have to address edge computing. They have no cloud service to extend to the premises, and so they would have to either promote the user into creating an edge partnership with the telco edge, which means defining something specific in terms of services, or promote the telco edge in a service mission that a local edge isn’t particularly good for.

I think you could make a case for the notion of a tiered edge strategy, with a local (on premises) edge and a linked deeper provider edge, but it’s a case that remains to be made. Would the telcos, notorious followers and play-it-safers, be the logical players to make such a case? I think we all know the answer to that one.

The problem for the telcos is that the other option takes them in the same direction. If you want to define specific edge partnership services, you have to start from scratch because no such service relationships have been established. What would a “deep” versus “shallow” edge look like, how would each work in terms of capabilities and interfaces, and how would they cooperate? These are good questions that have to be answered, but again is it likely that the telcos could be the ones to come up with the answer?

I think that this is an indicator of another battlefield in a war we don’t often acknowledge, which is the one between vendor and cloud provider. If users consume services they don’t consume platforms. Edge computing vendors, for example, would have to sell to a different customer with a different price point and expectations if edge computing were realized totally in the cloud versus in a combination of telco and premises. Those vendors have a strong vested interest in pushing an edge strategy that promotes their own interest, and so I think they’re the ones who will have to push the edge strategy forward for telcos.

Ah, but which vendors? The traditional network vendors like Cisco, Ericsson, Juniper, and Nokia are all network vendors not compute vendors, though Cisco does offer compute products. The platform vendors like Dell, IBM/Red Hat, HPE, and VMware would be the ones best positioned to define an edge approach for the telcos. All these organizations have a telco group, and most even have specific telco cloud and edge strategies, but they’re not thinking of how to sell through their actual buyer to the downstream, ultimate, actual buyer who has to drive the whole process. In this case, that’s the consumer of edge computing.

Providing tools that would facilitate the creation of edge services to someone who doesn’t know what they should build with them isn’t helpful. That’s what the platform vendors do with their telco strategies today, and it’s not going to be successful. The key lesson here is that a win by public cloud providers, in any compute area, is less of a win for the platform vendors because public cloud providers are really platform competitors themselves. Sure, they’ll do a deal here and there to host a platform, but they know that’s just a tactical concession. In the long term, they want to be the platform, particularly at the edge.

If you’re a platform vendor, this is what you need to be looking at. Your program has to reflect the strategy that, if implemented by your buyer, maximizes your own sales. For the telco world, that means that you’ll need to come up with the strategy as well as its implementation, and the sooner you face that truth, the less at-risk your telco strategy will be.

The attack on MPLS VPNs seems to be expanding. SD-WAN, originally conceptualized as an extension strategy for small sites, has been quietly growing more toward MPLS replacement. Now we have a new offering that combines SD-WAN with a backbone network to create an MPLS replacement. In fact, this is the second such offering that I’m aware of, so the trend is worth reviewing, particularly since it creates another possible competitor for telcos’ embattled MPLS services.

Business data services have become a bit of a floating-deck-chair-for-Titanic-survivor thing as far as telcos are concerned. Residential broadband’s profit per bit is in the toilet, and there’s little chance for improvement. Businesses’ current VPN services are the CFO’s delight of the moment, and nearly all enhanced services an operator might offer are also credible only to business. No wonder there’s a growing fear that competitors are going to eat both pies.

The growing competitive situation with regard to SD-WAN and VPNs is similar to the recent risk that cloud providers pose, something I blogged about only yesterday. In this case, you take an edge element, SD-WAN, and combine it with a backbone network other than the public Internet. This is actually something that Cato Networks has done for a while now, but of course they’re a startup, where the Cloudflare Magic WAN service involves some big-name players, and that may be critical for the combination of SD-WAN and non-Internet backbone to succeed.

The standard way for SD-WAN to provide connectivity has always been through the public Internet, which is pervasive and cheap. The problem is that the Internet is also a hotbed of hacking in various forms as well as a best-efforts service. Both Cato and Cloudflare are banking on a private backbone to resolve those problems, which is also what Microsoft is doing with its Azure cloud network expansion. The personality of the service is created on premises, so what we’re seeing is proof that most of the “service” is really the edge.

For managed services, some credible backbone strategy is critical even if its features are largely invisible. Managed services depend on service level agreements (SLAs), and it’s hard to write one if you can’t provide any QoS at the network level, and have no control over network status or behavior. However, companies are almost universally betting their customer relationships on the Internet, and since COVID have expanded that bet with WFH, which uses the Internet as well. The attitude toward what SLAs are involved in managed services is slowly transforming for sure.

It hasn’t transformed yet, though. Businesses are still reluctant to bet major-site connectivity on the Internet (though that’s changing too, just slowly), and it’s this reluctance that these SD-WAN-plus-backbone offerings are exploiting, to the detriment of MPLS. It’s not provably a runaway trend yet; Cato, the longest-standing player, is private so we don’t have revenue numbers from them, but their total valuation is over a billion dollars. Cloudflare push things faster; they’re publicly traded (NYSE) and their 2020 revenues were over $400 million.

The prospect of an explosion in SD-WAN-plus-backbone stuff isn’t just a threat to the operators, either. SD-WAN has been increasingly competitive, which means that more features are getting glued onto it in various ways. It’s also interesting that both Cato and Cloudflare are positioning their offerings around the beloved-by-analysts-new-product-category of Secure Access Service Edge (SASE). This, as it happens, only multiplies the risk to network vendors.

Anything that undermines MPLS undermines network vendors, because operator sales of MPLS services creates a revenue stream to justify router purchases. The growth of SD-WAN could significantly reduce the business service revenue stream in and of itself, and if SD-WAN is combined with a private backbone, it could pull more MPLS traffic away.

Then there’s the SASE dimension. Network vendors have made a lot of money on glue-on security. How much of that is at risk if there’s a level of intrinsic security created by a VPN or by zero-trust session awareness? You could argue that the whole concept of SASE was promoted in part by network vendors’ desire to bundle glue-on security into a new SD-WAN-created service edge, making it seem less likely that SD-WAN evolution would impact the old security model. Both Cato and Cloudflare, though, have adopted the SASE term for their offerings, and Cato at least has provided a level of intrinsic security all along. Does this then threaten the SASE defense for security?

Both these factors may explain why traditional network vendors have been slow to fully exploit the virtual-network trend, and have largely ignored the SD-WAN-plus-backbone opportunity. Juniper seems to have at least some ambition there with session-smart routing, which brings zero-trust security to the network, but they’ve been cautious with positioning it. They do have a pretty active security business, after all.

The problem all the doubters of the concept face is that it might well become a populist revolution. Any MSP with a decent SD-WAN tool and access to backbone capacity could enter this space and carve out a credible position. If enough of them try that, it could be enough to force the big telcos to introduce their own offerings, on the sound theory that it’s better to self-cannibalize than to be cannibalized by others. If any major operator gets really serious about an MPLS alternative approach, it would make it very difficult for other operators to hold back.

Why should anybody be holding back? You would think that the SD-WAN-backbone option would let operators create VPNs at a lower cost, which could help them boost profit per bit. The additional features that could be added would be another potential revenue boost, and of course the whole thing could end up evolving into a form of network-as-a-service (NaaS), which is how Cloudflare classifies its new service. So, what’s not to like?

Change, essentially. The problem with virtual networking, SD-WAN, and NaaS is that any of them could shake up the concept of services, and the valid players in the space. The fact that we’re seeing people offer assured-quality-of-service VPNs using SD-WAN technology is an indicator that the space would be accessible to many new competitors. It’s further pressure on the traditional network operators, at a time when they don’t need it.

The space to watch now is mobile networks and services in general, 5G and wireline/wireless convergence in particular. All these SD-WAN service offerings are business services and exploit wireline connectivity. If that becomes less profitable, then wireless is pretty much the only game in town, and we know that open-model 5G is already a target for the public cloud providers. Spectrum license fees will likely constrain competition in the wireless space for a time, but even if operators don’t have “new competitors” in 5G, they are almost certainly going to have new partners, in no small part because the operators have failed to account for the growing importance of hosted control-plane features, and have no plans to do the hosting themselves. If open-model 5G proceeds as it has been, things could get very difficult for the traditional telcos and even cable companies over time.

The biggest future threat to network operators may be a present threat. Microsoft’s decision to offer Azure customers the option to have their entry and exit traffic carried on Microsoft’s own network rather than on the Internet is a signal that cloud providers may be flexing their own muscle in network services, as telcos stick their heads in the sands on services at a higher layer.

It’s long been known that Google has an enormous private IP network that links all its worldwide assets; this existed before Google started offering cloud computing, but it’s grown since then. Amazon and Microsoft also have these networks, and it’s that truth that Microsoft is supporting and that the network operators should be fearing, but that’s not the end of it.

Content delivery is a major mission for the Internet, and in terms of volume of traffic it’s the largest mission. Content delivery networks (CDNs) were created to reduce the performance issues associated with delivering content across the web of interconnects that make up the Internet. These CDNs consist of cache points at the inside edge of the access networks for the ISPs, linked by trunks that then deliver content to the caches for use. Thus, they also have “networks”.

Even edge computing might turn out to be a threat to network operators. The edge is distributed close to the user by definition, designed to offer a low-latency processing path. If edge points were connected to a private wide-area network by the edge provider, that network would then be an alternative for handling all sorts of traffic.

Alternative network service providers are emerging, but how much would they threaten the network operators, really? In the case of Microsoft’s Azure network, the direct threat is to public Internet handling of into- and out-of-cloud traffic. It’s not likely that this would have a serious impact on enterprise IP service revenues, as long as that was the only target, and that may not always be the case.

If Azure cloud traffic jumps onto Microsoft’s network, and if we assumed for the moment that Azure was the front-end for all an enterprise’s applications, then wouldn’t that enterprise be able to drop any corporate VPN? It would sure seem likely, but not many enterprises would have all their user traffic going to Azure or any other cloud. On the other hand, suppose Microsoft just decided to offer a VPN service based on the same Azure-linked network? Maybe they add in an SD-WAN element that does the traffic routing. Wouldn’t that then replace a VPN? Seems likely that it could.

If cloud providers, edge providers, and even CDN providers were to get into this game, the current network operators would be in a position of competing for IP transport with players whose IP backbones were justified in part by other, higher-level and higher-margin, applications. Any public cloud relationship an enterprise had might become a wound through which business IP service revenues bled away from the network operators. They might end up being nothing more than access providers.

Which, if you think about it, is just what would happen if we assumed that the SD-WAN craze made the Internet the IP transport network of choice. Every site would pay for Internet access, of course, but other IP services (notably MPLS VPNs) would be unnecessary. That could happen even without cloud providers entering the business network game, but it would be more likely if they did because the effects of SD-WAN and alternative IP providers would be combined.

The combination of cloud/edge provider and CDN competition on one hand, and SD-WAN adoption on the other, could force network operators who believed that businesses were their big opportunity to shift their thinking away from core transport to either special access (5G slices, for example) or finally accept the need to offer higher-layer services, taking the cloud provider’s competitive battle to those providers’ own turf.

I don’t think there’s an operator CFO on the planet that would smile at the thought of getting into higher-layer services and competing in any way with cloud providers. What would then rescue operators from the risk? It seems likely that it would have to be 5G, but how exactly could that help?

5G creates most service features in what would be considered the access network. In effect, a mobile 5G network is a kind of halfway point between a traditional IP network and a switched connection-oriented network. It has to be able to do a bit of both, which might perhaps make it a contender as the foundation of network-as-a-service, and NaaS might be a good strategy for an operator to counter a cloud provider.

How? The one thing an operator has over a cloud provider is ubiquity. Microsoft and other potential operator competitors don’t have nearly the number of points of presence as traditional telcos or cable companies. Thus, any service offering that seems to be promising indiscriminate connectivity across a large area would favor the traditional operators. NaaS is such a service because it focuses on connecting relationships.

Juniper’s financial-industry talk on its “Session-Smart Routing” would seem to take aim at the NaaS opportunity by facilitating session, meaning relationship, awareness at the service level. Even 5G, which is likely to be used as a site-connection service to businesses, wouldn’t offer that granularity. Juniper’s positioning of the concept has been tentative, though. My Wall Street sources didn’t like the financial industry presentation, for example. They wonder whether Juniper is torn between aggressive presentation of their recently acquired assets and sustaining their position with the old familiar stuff.

That may be the same problem operators have, of course. NaaS is different, and “different” doesn’t play well in a conservative industry, which telecom surely is. The question is whether vendor caution and operator caution are locked in a deadly embrace here. Operators can’t adopt what nobody sells or promotes. It’s a major risk for an executive to sponsor a transformation that the vendors themselves don’t seem committed to. Thus, we may have to wait for vendors to advance their own positioning.

The public cloud providers may not be interested in waiting. Virtual networking, including traditional VPNs, are perfect examples of the black-box approach. What’s inside the network is opaque, and features and services are projected through the visible edge. The cloud providers in general, and giant Google in particular, have for a decade been using advanced network technology inside rather than building box networks. Microsoft’s announcement is an indication that they see the opportunity to take advantage of these new models in providing “old” services.

You can’t win a purely defensive war, only control how fast you lose. If cloud providers are happy to invade telco space, and telcos are content to let the cloud providers hold their own home turf, they’re accepting inevitable defeat. Telcos, beware.

Every day, I see and hear about new data points that suggest we’re getting the whole hybrid- and multi-cloud story all wrong. It’s a given that stories about the cloud are all about hybrid and multi-cloud deployments, but they’re sparse on just what the terms mean, and that means they’re not particularly useful in guiding planning.

One of my pet peeves is the growing number of stories about hybrid cloud or multi-cloud being “adopted”, as though these models were something that users thought about and planned for. What enterprises say about their own cloud usage is entirely different, and has been from the first.

Hybrid cloud, they say, is the only cloud usage model the majority of enterprises will adopt. They say that they’re not moving old applications to the cloud, or rewriting applications to get them from data center to cloud. What they’re doing is changing the front-end piece of the applications, where the users connect, and the changes are being made by adding cloud-hosted components in front of their data centers. Hybrid cloud.

Multi-cloud is also less a goal than a defense. In the early days of the cloud, enterprises saw it as a single source of failure and a new source of lock-in. Keep those greedy cloud providers honest and have a couple of them in the bullpen to draw on. Interestingly, the number of enterprises who see multi-cloud that way are diminishing annually. What’s replacing them are enterprises who pick different cloud providers for different applications, based on things like geographic coverage or special web service features that would facilitate application development.

The net is that one of the big problems with our conception of hybrid- and multi-cloud is that there’s no real technical definition of what the relationships mean, either at the resource level of at the application level. A hybrid cloud is a resource relationship between a public cloud provider and the data center, and a multi-cloud is a relationship with multiple cloud providers. Neither of these generally accepted views deal with the applications involved, which is a problem because that’s what users are trying to run. That leads to a misunderstanding about what resource relationships should exist.

The public cloud has an advantage in terms of scalability and resilience, when compared to a company’s own data center. It has a disadvantage in terms of security and compliance for legacy applications and their databases, and all the enterprises who have shared their numbers with me say that hosting everything in the cloud would increase their costs rather than reduce them. That’s why the prevailing goal is to divide applications so that the variable, elastic, piece goes in the cloud and the rest stays where it is.

For the great majority of enterprise cloud planners, what’s happening is an extension of existing applications via new cloud components, creating a “hybrid application”. The two pieces aren’t intended to cross back and forth between data center and cloud; the cloud feeds the data center. That creates something I’ll call the workflow integration model.

Workflow integration in cloud applications is characterized by a very loose linkage between cloud and data center (or among clouds). A hybrid application has components that run in the cloud(s), and in the data center, and in general those components scale, deploy, and redeploy within their primary hosting environment. There’s a linkage point where work passes from one environment to the other, but it’s the work that moves and not the applications. This is in one sense a hybrid cloud application, even when multiple cloud providers are used, because the clouds were chosen for specific tools to support specific applications, and there’s limited (if any) direct cloud-to-cloud integration.

The other possible cloud model is the hybrid pool model, the one most people seem to think dominates multi-cloud (but doesn’t). With this model, there is a pool of resources that’s made up of contributions from the data center and one or more public cloud providers. This hybrid pool then hosts some or all of the components of an application, and those components could in theory move between hosting contributors as they deploy, redeploy, and scale. Workflows move because what they’re linking between has moved.

Hybrid pools are potentially useful for backup of cloud resources, but they pose significant problems for enterprises. The need to run the same stuff on multiple clouds means accepting a kind of web-service-lowest-common-denominator in terms of custom application-building tools. Changes in workflow created by multi-cloud deployment of components can create a lot of random and uncontrolled “border-crossing” events and require a much more general strategy for interconnecting the clouds for application traffic than a static gateway would. There’s also a potentially enormous financial downside because traffic flows in and out of the cloud are often a cost item, so it’s hard to price out this approach with any conviction. This doesn’t mean that multi-cloud isn’t useful, of course, only that most enterprises will adopt it not as a hybrid pool but as a set of parallel front-ends.

Current coverage of multi-cloud suggests that 1) it’s a hybrid pool, and 2) that it’s different from hybrid cloud. In most cases both those suggestions are wrong. Most multi-cloud will use the parallel workflow-integrated hybrid cloud model, but with more than one provider. Most of what enterprises need to do for multi-cloud will be based on their hybrid-cloud approach.

A final complicating factor is the growing conflation of “containerized” and “cloud-native” in terms of application structure. Containers are a general hosting strategy whose benefit is management of dependencies, thus improving the ability to host something more portably. Cloud-native is a program architecture that maximizes a component’s ability to be scaled or redeployed in case of failure. If we start thinking that containers equal clouds, we could end up backing into the hybrid pool model, and at the same time lose focus on the cloud-native techniques that would really maximize cloud benefit.

The net of this is that we’ve come to think of hybrid- and multi-cloud as complete architectural descriptions, even as goals, when they’re a hosting configuration byproduct of good application design in a cloud-capable world. They aren’t. One is a description of what enterprise cloud adoption has been all along, and the other is a byproduct of the fact that cloud providers have sought differentiation by providing their own set of web-service-based application tools that draw a different mix of applications to each cloud. It’s this underlying trend that should be watched, because the fight for differentiation continues.

Nokia, who seems to have struggled a bit more with 5G than rival Ericsson, may be taking the “open” way out, and it might also turn out to be the “easy” way. As TelecomTV reports HERE, Nokia has established an Open RAN development relationship with all three of the public cloud giants. You’ll recall that these cloud players have already made announcements in the 5G public cloud area, and the deals open a lot of interesting points.

Despite all the glowing stories about 5G benefits, the fact is that there have been no credible opportunities for major revenue growth generated so far. Speculations, yes, but no opportunities. As a result of this, the 5G operators have been facing the risk that 5G would reduce their profit per bit further, when it’s already in danger of falling too low to sustain infrastructure investment. If ROI is the problem and the “R” or revenue part is nailed to the floor, the all that’s left is reducing investment, the “I”. Capex reduction is an obvious target, which means forcing vendor discounts and promoting open-model networking.

Ericsson and Huawei are the market-share leaders in mobile network infrastructure, with Nokia third. Traditional competitive moves like aggressive marketing and discounts aren’t attractive when you’re behind and at risk to disappointing shareholders, so you need to rock the boat on the market game, which Nokia has done with its more aggressive Open RAN approach, part of a broader commitment to an open model for 5G, and even for networking.

There may be a relationship or two here, between Nokia’s open-model networking approach and its recent announcement it was cutting 11% of its staff. If you are going to embrace community-developed resources, you don’t have to have as large a development team on staff, and your overall marketing burden could be lessened by the general popularity of the open approach. Whether staff cuts were enabled by the open approach, the open approach was dictated by the need to have a less people-intensive product development model, or what, we may never really know.

We do know that an open-model decision has an impact beyond product development. If you raise chickens for eggs, you’re part of the egg ecosystem. If you decide to raise cattle for milk instead, you’ve got to accept that you need to cultivate a new set of relationships. Who are the players in the open-model network ecosystem? Other players that operators or enterprises would likely turn to if they decided to embrace the model-model approach. Enter the public cloud providers.

Many of the potential operator buyers of open-model 5G would prefer 5G as a service for the same reason they wanted open-model 5G—lower cost and no vendor lock-in with escalating costs. Nearly every enterprise who might consider private 5G would prefer it as a service too. Given that the major public cloud providers have all announced some form of hosted 5G, Nokia has to realize that if it wants to promote its own flavor of an open-model network, it had better get a footprint with those public cloud providers, particularly Google and Microsoft.

Google is the master of cloud-native thinking. They invented Kubernetes and Istio, and their Anthos multi-everything orchestration maestro for Kubernetes is becoming the go-to strategy for organizations who need to run multiple clouds along with their own data centers. If you want a development partner for open-model 5G that’s right up to speed with the cloud, you want Google in your corner.

Microsoft is the cloud pragmatist. They know more about hybrid cloud than anyone because they saw it as the winning concept from the first. As a result, they’re growing faster among enterprises than leader Amazon. If you want 5G wins in the enterprise space, Microsoft’s nose is well into that tent. In the 5G technology space, they’ve gone out and acquired technology to provide 5GaaS, which makes them a direct threat to any 5G vendor. If Nokia wants their cloud enemies closer, it’s cuddle time with Microsoft.

Sitting at the feet of Google-the-cloud-master or cuddling with Microsoft are a pair of great tactics for Nokia, but they need a strategy too, and that may well be the hardest thing for them to find. Differentiation in the open-model, open-source, world has typically come through professional services, support, and integration credibility. Nokia has that with operators but less so (if at all) with enterprises. Even operators might find the Google piece of a Nokia/Google partnership more compelling than the Nokia piece.

Any strategic position Nokia might want will also have to be defended against other open-model players, including VMware, IBM/Red Hat, and HPE, to name a major few. All of these companies have strong enterprise positions and credible engagement with the network operators too. Any of them could jump out with powerful differentiators of their own, or even jump on a Nokia differentiator that wasn’t presented decisively enough.

AI may be a differentiator Nokia has in mind. They just signed a big self-organizing- (or optimizing-) network (SON) deal with Orange, and while almost everyone claims to have AI these days, a big part of a strong AI strategy is an inventory of subject-matter experts who can be tapped to set up the environment. Nokia has that for networking, and most of their potential competitors, and even their cloud provider partners, do not.

The risk for Nokia here is that the cloud providers may be their most formidable long-term competitors for 5G infrastructure. All that stands in the way is cloud provider exploitation of the Achilles heel of 5G for network equipment vendors, which is the notion of control-plane separation. 5G generally divides itself into a control plane and a user plane, which is essentially IP. 5G’s control plane could easily be cloud-hosted, which would leave the user plane as the only box-specific component. Router vendors, a group Nokia is among but not the leader, might partner with cloud providers and present a whole-network solution.

That might not be all, either. If we separate IP’s software from its hardware, and in particular the IP control plane from the forwarding plane, how much of the resulting software could be hosted in the cloud? We might have nothing left but commodity white boxes for carrier network equipment vendors to fight over.

There is a major transformation in network thinking underway. It’s not really far along at this point, but it’s clearly gaining momentum because the new-think has already empowered players like the cloud providers, who tell time in Internet years (about a calendar quarter) and not telco years (half a decade). Nokia may have to change its watch, and not just its alliances.

AT&T has been the arguable champion of transformed infrastructure, a major contributor to open networking projects and an adopter of open technology from cellular edge to core, as well as open operations automation and orchestration. The company has announced it would be virtualizing its network, and has recently said it’s met the majority of those goals. That, coupled with the recent executive changes, has led some to speculate that AT&T may ease off the gas on open-model networks. I think the truth is a lot more complicated, because the reasons why AT&T might consider easing off are more complicated.

AT&T stands out among US Tier Ones, and perhaps even global Tier Ones, for its challenges. Its demand density (roughly, revenue opportunity per square mile) is low in comparison with almost all the other Tier Ones, and it seems to have fumbled its M&A a bit. In the recent spectrum auctions for C-band 5G, they had to bid high, creating some Wall Street concerns that their debt was becoming an issue.

All of this is actually a pretty good reason to want things like open-model networks and service lifecycle automation, so on the surface it would seem that AT&T’s business challenges might push them further into their open-model commitment rather than cause a reverse. That’s where the complications come in, though, because AT&T has made some mistakes in its early transformation and virtualization projects, and while they may not back away from open-model networks, the might have to reconsider some of the stuff they’ve been doing.

The heart of AT&T’s transformative vision lies in the traditions of networking. We build networks from “nodes” and “trunks”, the latter representing point-to-point connection paths and the former devices that can shuffle packets from one path to another. That process creates “routes” through a network, and it’s also what gave us the name “router” for the nodes. AT&T planners, like most network planners, are conditioned to think in terms of nodes and trunks, and so their view of a transformed network was really a vision of transformed nodes and trunks. Since a trunk is a rather featureless bit pipe, the focus is on the nodes.

What is a transformed node? There are three basic models that have emerged. The first is the “white box”, which is a hardware device built to be a generic switch/router when equipped with the proper software. The fact that hardware and software are separated in this model, presumably creating a situation where you can play mix-and-match with the combination, this is also called “disaggregation”. The second model is the virtual model, where the software functionality of a node is hosted on a resource pool, meaning a server or virtual machine.

Both these basic models emerged from a presumption that networks had to be built a box, meaning node, at a time, so the transformed nodes had to look like traditional ones (routers) from the outside, and function as one if they were introduced into a random point in the network. Our third model, the SDN model, took a different view, taking “disaggregation” further to separate the control and data/forwarding planes. The control plane, rather than being distributed as it is traditionally to every router, was centralized so that knowledge of routes and topology was concentrated in one place. The forwarding plane was simplified to be a pure shuffler of packets, with no intelligence to decide what a route was.

Before you wonder what this has to do with AT&T (if you’re not already wondering that!), let me close the loop. AT&T took a white-box view, the first of our three models. Mobile networks, especially 5G, have taken up the virtual model, where functional elements are hosted. Data centers have tended to adopt the third SDN model. This is the first of AT&T’s problems; the future of networking is surely a combination of the thing that’s budgeted (5G and the virtual view) and the thing that’s the credible revenue future, the data center where higher-level features can be hosted. They’re nailing their conception of the future network to the node-and-trunk rigidity of the past, in the face of indications that it’s going a different way.

Part of the reason behind the rigidity is that the virtualization track, our second model, was also bound with the old-network vision rather than facing forward to the ultimate virtual destination, the cloud. Network Functions Virtualization (NFV) was a box maven’s notion of a virtual network, discarding modern visions of cloud-native in favor of node-and-trunk-think elements like “service chaining”. NFV-think was written into 5G, and it was also a theme in the way AT&T thought about “orchestration”, something we now see as a cloud-and-container concept. We’ll get to that shortly.

The second problem AT&T has goes back to those days of old, the nodes and trunks. Operations was at one time a purely manual process. Even thirty years ago, “provisioning” meant sending a human to diddle with wires and connections. Just as early IT focused on post-processing records of manual tasks that had already been done, so early operations visions had a batch focus. AT&T operations people had this mindset when they set out on the adventure that became ONAP.

The Open Network Automation Platform, ONAP, is the Linux foundation project successor to AT&T’s own ECOMP (Enhanced Control, Orchestration, Management, and Policy). It’s absorbed some of the NFV work, and a lot of the same thinking.

The big problem with ONAP is that it’s really a batch system with some real-time tweaks, largely in queuing. It lacks any real connection with current cloud-think, to the point where it’s hard to point out any real accommodations to cloud-native design. It’s not based on a service model or template, though they seem to be trying to retrofit one in, and it doesn’t use the old TMF NGOSS Contract mechanism to steer events to processes through state/event tables in the data model. This means that it’s not inherently stateless and scalable/available.

Done right, ONAP could take on the role of the “Near-Real-Time RAN Intelligent Controller”, which AT&T suggests it’s thinking about, but ONAP is not done right. Let me see, we’ve got NFV Management and Orchestration (MANO), we’ve got 5G RICs (two of them, in fact) that orchestrate, and we have ONAP. The mere fact that we seem to have multiple levels of orchestration/orchestrators developing is a pretty clear sign that people aren’t thinking about infrastructure as much as pieces of infrastructure, and they’re not summing the parts to see if they add up to the whole.

Just because today’s IP networks are made up of pieces doesn’t mean that you can address transformation piecemeal. There was a vision behind the IP network of today, and there will have to be a vision behind any transformed equivalent, or the result will be, at best, incapable of realizing the full benefits of transformation. At worst, it simply won’t work, won’t scale.

The smart thing to do, whether you’re AT&T or another big operator, is to think of everything in terms of a separate, cloud-hosted control plane, not only for IP but for 5G, CDNs and other complex services. You then couple it to a white-box data plane built like SDN’s, designed to work with a control plane forwarding table that’s delivered from the Great Above. That’s a melding of the three models I’ve described for open networking, with a respectable dose of cloud awareness thrown in. But that’s not what they’re doing, at least so far.

I think it’s what they’ll end up doing, though, under what’s likely to be considerable pressure. The problem with AT&T’s open initiatives isn’t executives or realized goals, but the lack of realization that the goals were meaningless because their “progress” was in the wrong direction. NFV is virtualization and it would be a terrible idea to apply throughout a network. ONAP is similarly a terrible way to do orchestration. They’ve gotten out in front by neglecting critical whole-network requirements assessment, and they’ve taken a leadership position, but mostly one that will be known for going in the wrong direction.

AT&T’s recent comments on the C-band auction and its 5G direction have been cautious in comparison with remarks made by other bidders, according to another Light Reading story. It may be less that AT&T is cautious than that others have played up to the marketing dimension of 5G more than they should have. But caution here also begs the question of what AT&T intends to do to realize some revenue and improve profit-per-bit in their 5G deployments. If the classic 5G drivers like IoT aren’t real, then either AT&T needs something that is, or they need to accept that their spectrum bids may in fact have hurt their financial picture, and Wall Street skeptics might then be right.

If AT&T is changing its open-source commitment to reflect the fact that they’ve got to rethink their model, that’s a bitter pill but one worth swallowing. If they are indeed thinking they’re nearly done with their virtualization, or if the key executive support for open-model networking has departed and gutted efforts, that’s a very bad thing.

Every promise AT&T has made, every deployment, every vendor commitment, every contribution to open source or open hardware, needs to be reviewed right now, because it’s almost too late. I hope that the AT&T exec quoted in the article I cited above is wrong and they’re stopping their current initiatives and thinking hard about where they’re headed, because it’s not where they need to be.

That’s something for the vendor community to think about too. It should be clear from the 5G Open RAN activity that operators are determined to adopt open-model networking. Vendors need to figure out how they’ll support that goal, and one smart starting point would be to get themselves positioned at the point where open-model evolution will inevitably take AT&T and others. Right now, that’s wide-open space, free for any to lay claim to, but it’s not going to stay like that. Inevitably, somebody gets smart, even if it’s a happy accident.