Month: March 2022

MWC generated a lot of announcements in the Open RAN space, not surprisingly. That makes it harder to dig through to identify relevant trends, I’ve picked out some specific announcements that I think fit a pattern and offer some useful insights into where mobile networks, and networking overall, may be heading.

SDxCentral did a piece on an IEEE-sponsored panel on the state of Open RAN, which is a good place to start. Like a lot of panels, this one had its share of platitudes, but one point that came through and reflects the real world quite well is that Open RAN is a bit of the classic horse-designed-by-committee in multiple ways. First, it’s a consortium activity, and the telecom space is littered with examples of this kind of initiative that just dissolved into collective confusion. Second, the committee model is carried on to deployment through the integration challenge.

Operators, like most technology users, really hate integration. Just the term rouses visions of seas of fingers pointing everywhere, or little players so small that there’s no recourse possible if they mess up. Nokia, an established mobile vendor on the panel, called this point out. Others have criticized Nokia for being an OINO open-in-name-only) but many operators see them as the only credible open game in town.

Telefonica offered an important operator perspective with its announcement of Release Two of Open RAN Technical Priorities. Many operators and Open RAN supporters have told me that this release represents a foundation for “stepping from proof of concept to deployment”, as one operator put it. Operators want to see not just a complete architecture, but one that’s operationalized and integrated. To quote Telefonica, this release “focuses in particular on intelligence, orchestration, transport and cloud infrastructure, aiming at defining a fully automated and interoperable Open RAN system.”

Release Two and the views on it demonstrate that the benefit of “openness” isn’t a free pass to acceptance; operators want Open RAN to offer the kind of stability and quality that they’re used to. That “as they’re used to” description frames the face-off that MWC presented. Release Two demonstrates that telcos recognize that 5G is a piece of a very large transformation. That may be frightening to a conservative vertical like telecommunications. That this issue is coming to the fore now suggests that a gap has developed between the “maturity” of Open RAN and the need for telcos to deploy 5G. It’s that gap the public cloud providers may be looking to fill.

One of the biggest drivers of Open RAN is something that’s not directly connected to the technical specifications or even the concept. Operators have been very interested in having public cloud providers undertake a major role in 5G hosting, and the cloud providers have responded by offering 5G feature support to a greater or lesser degree. Microsoft bought a couple of companies (Affirmed and Metaswitch) that had software implementing elements of 5G, for example. Arch-rival Amazon, of course, countered.

The Amazon approach, presented at MWC and summarized for analysts here, is much broader than just 5G hosting, or even edge computing. Amazon believes that telcos need a broad cloud transformation, one that specifically includes the OSS/BSS systems involved in customer care. At the opening of the presentation, Amazon makes a telling point, which is that they hope to bring all the values of the cloud to a partnership where the telcos contribute the connectivity they’ve provided for decades. Is this a “stay in your lane” admonishment?

Amazon is building from its previous telco-centric AWS Wavelength and AWS Outpost offerings, Snowcone edge computing, and then 5G deals like AWS Private 5G, AWS Cloud WAN. All this leads to an Amazon commitment to build a cloud-native 5G infrastructure solution, including RAN, Core, and edge. Their MWC talks were focused on announcements of operator and vendor deals more than on new AWS features, but the announcements demonstrate that what Amazon wants is a “network as a service” form of 5G support rather than a strategy to help telcos move their stuff to the cloud. That doesn’t mean that Amazon won’t support telco-supplied stuff; they’re happy to do that in AWS and in Outpost.

Amazon wants to build a broad ecosystem, too. They’re calling for partnerships with the whole spectrum of vendors that telcos now deal with, and that may be the most interesting thing of all. It’s hard to imagine that a commitment of telcos to any public cloud strategy wouldn’t generate collateral losses to vendors who’d normally supply the elements of telco-owned infrastructure and operations tools. It’s also hard to imagine that a vision of cloud-sourcing everything wouldn’t give telco traditionalists the willies, so Amazon’s position here is bold. They’re betting on a radical win in the telco space, risking a substantial pushback from everybody and a potential loss.

Juniper is obviously one of those traditional telco vendors that Amazon would love to have in their tent, but Juniper has its own bottom line to consider, and its own strategy to promote, as described in this SDxCentral piece. “Open RAN will have its day”, says Juniper’s CTO. It’s not “if” but “when”. That doesn’t necessarily put Juniper into the position of advocating the telcos go it alone, without the public cloud providers, but a subsequent quote from the article does. “Telcos are trying to become tech companies,” he said. “They see how hyperscalers are expanding into their space more and more with local zones. They are reducing the last mile between hyperscalers and the end customers and enterprises, and that’s where the telcos get squeezed out.”

Juniper, like other non-mobile-incumbent promoters of Open RAN, likely sees the 5G RAN space as the leading edge of what might be a movement to open-model networks, one to open 5G, maybe a movement to open mobile networks to new players, or a movement to an “as-a-service” public cloud model that could impact network investment by telcos and even other verticals. Table stakes in this confusing competitive mix is a presence in Open RAN in general, and the RIC (RAN Intelligent Controller) in particular. Juniper has that, but the AWS “ecosystem” announcement and the Release 2 Technical Priorities suggest that more may be needed.

Telefonica and AWS may be agreeing on that critical point. 5G is a complex structure in itself, beyond RAN in scope and leading to questions of new applications and new compute models, like edge computing. A telco network of the future would then be expected to be quite different from today’s model, and that doesn’t even consider questions like the impact of radically improved consumer broadband Internet, the metaverse, and metro-mesh configurations of the future core network. Telefonica is saying that whatever that future is, it has to be a fully operationalized ecosystem. AWS is saying that whatever that future is, telcos really need to let the cloud provider experts host the non-connectivity piece for them. Network vendors have to say something too.

MWC said that 5G and Open RAN are not point technologies, but both indicators and drivers of a broad change in what “service” means, how “infrastructure” is built and managed. Those are obvious messages, but a less obvious one is the notion that 5G may be the first network technology that steps beyond connectivity, at least in terms of the full scope of its justification and benefits. Operators appear to have decided not to try to go it alone; “carrier cloud” isn’t a mandate to deploy edge computing for any of the operators I’ve chatted with, though some hold the option to do some deployment on their own.

It’s hard not to contrast this to AT&T’s insightful vision of a future where operators develop wholesale features to augment connectivity and build a partnership with OTTs that’s more balanced. Do we have a future like that, or do we see operators focusing more and more on pure connectivity, leaving all the service value-add to others? There’s a lot riding on that question.

What is the relationship between the metaverse and augmented or virtual reality? The question relates not only to just how realistic the metaverse ends up being, but also to the question of how far metaverse-friendly technology might percolate out to other areas. That has significant implications on a lot of things, including conference/collaboration and edge computing.

Most people understand that the metaverse is an alternate reality in that it represents a “world” inhabited by “virtual people” that we call “avatars”. The extent to which the metaverse’s version of reality is credible will depend on how closely it can map to at least the most dominant of our senses, the visual. That depends on the sophistication of the “point-of-view” construction of what an avatar would see, and the sophistication of the display that renders it to the player/user behind the avatar.

I’ve talked in past blogs about the role that low latency plays in metaverse realism. That role is part of the point-of-view construction process, in that if multiple player/users cannot control their avatar’s movements in something close to synchronized real time, the interaction of the avatars will quickly become unrealistic and awkward. The latency issue is related to a lot of factors, from the processing performance that constructs the point of view to the network connection that carries information between each player/user and the master reference on which the points of view of everyone must be based.

The display issue also involves a lot of factors. One basic truth is that if the point of view presented by a metaverse is mapped to a very small part of the field of view of the player/user, then the metaverse experience simply cannot be immersive. That may not mean it won’t be useful, fun, entertaining, but it won’t be realistic. A larger screen, something like a laptop screen, is only a little better. A big monitor or HDTV would be better yet, but even if you sat fairly close to a high-res large display, you’d still see stuff around it. Our ability to focus, and in particular to focus on screens, tunes us to being able to ignore distractions around the display, but that’s not the only issue.

Would we expect the metaverse to be silent? Hardly; we’d need conversations. Would the conversations be expected to emerge from the place where the avatar we were talking with was located? Perhaps not immediately, but eventually. In any event, if some avatar spoke from “behind” us in a virtual sense, we’d have to map the sound somewhere, and having it appear to have come from in front would be one of those jarring things that could impact our feeling of realism.

Then there’s our own movement. When we want to see what’s to our left, we turn our head, we don’t diddle with a game controller. Natural behavior would not only expect head-turns to trigger a change in view, it would likely generate that movement instinctively. If we’re sitting in front of our huge HDTV, turning our head doesn’t change our avatar-field-of-view, it makes it disappear as the display moves out of our field of vision or focus.

A sophisticated, immersive, successful, metaverse will surely encourage a shift to AR/VR headsets. While I put the two (augmented reality/virtual reality) together, it is almost certain that it’s VR that’s promoted by the social-media model of the metaverse. Augmented reality means adding stuff to what’s real-world vision, with the presumption that what you’re adding is relatively simple in comparison to what’s passing through. The more complex the additions are, the more difficult it is to keep real-world view and augmentation in sync, and that means you’re looking at creating a full virtual reality by combining a camera view with the augmentation. Given that the metaverse software would then “see” both real and augmentation, it would be far easier to synchronize the behavior of the two. Finally, full VR is really the only way to make the social metaverse realistic.

The question of the role of AR/VR in the metaverse, and in other “Metaverse of Things” applications, is important because limitations in AR/VR could limit the metaverse experience, and applications of the metaverse, enough to reduce near-term pressure to support things like edge computing and low-latency networking. There have been comments on this topic for weeks, and many suggest that AR/VR isn’t really necessary, but I think that the issue of immersion argues the other way.

The downside of metaverse AR/VR is that, for now, the technology can’t really support the mission unless we presume that the AR/VR headset is specialized to a metaverse application or that such a headset can be connected just as we would an external display. The first of these could be problematic unless every metaverse provider adhered to a common standard, and the second (while preferred) is just not within the current state of the art. We don’t have the resolution needed, and the additional software to support a “virtual monitor” as big as a room that you could turn your head to scan is also lacking. In basic gaming AR/VR, we’re a long way from a strategy that could work.

The question this raises is whether the things we need for the metaverse to really take off are, overall, just too expensive and difficult to create. We need edge computing, we need metro meshing, and we need AR/VR. If we have a billion metaversers out there, fully equipped, and we assume we can build good VR for three hundred bucks at volume, we have three hundred billion dollars worth of AR/VR alone. That would surely make vendors salivate, but is it realistic? We need a practical on-ramp approach.

What I think will happen is that we’ll have a segmented metaverse model. Not only will different metaverse players (Meta and others) likely each create their own metaverse offering, the offerings will carefully balance what’s needed in the way of new technology investment with what they hope to gain from their users. Companies like Meta will almost surely either create or permit the use of “spaces” within a metaverse where admission will either require or encourage a higher level of investment.

The AR/VR headset issue is more complex, but obviously it could impact metaverse features and adoption. I think it’s clear that full VR is likely to be required for metaverse, and I also think that even applications we’d classify as “augmented reality” would be limited unless we had better real-to-virtual-world coordination than classic AR could provide. The question is whether AR/VR applications outside the metaverse (not including gaming, which is clearly more metaverse-VR-like) would contribute to advances in AR/VR headsets. If they do, and if the headsets are more widely used because of these contributions, then we could see a more advanced metaverse mixture pretty quickly.

I blogged last week about AT&T’s vision of a future where new service features built on connectivity would serve as a platform for OTTs to create true higher-layer services. That obviously raises the question of what those features might be, and I’ve been trying to get some insight from operator contacts and a bit of modeling. This is what I’ve found.

First, there seem to be three categories of “new features” that sit between today’s network services and the higher-layer OTT services that operators have largely determined they can’t or won’t offer. The first category is connectivity extensions that are designed to frame connection services in a slightly different light. Category two is connection-integrated features, which are features that relate to a retail service that’s built on connectivity, but are not actually connectivity in themselves. The final category is features that exploit service opportunities not yet realized, and for which operators could hope to play a foundational role.

Connectivity extension features are designed to enhance basic IP in some useful way, without creating a different interface that would mandate changes to existing hardware or software. These can be divided into features relating to how connectivity is offered, and features that change connection properties in some way. The first group would include things like SD-WAN and the second group things like managed services, metered services, etc.

The advantage of this category of features is the ease with which they could be introduced. SD-WAN technology, and the superset category “virtual-network” technology, are already available from multiple vendors and could be introduced with little delay. Some operators already have. Managed services have been around for decades, and many operators have already dipped their toes into it. As an on-ramp to a new connection service model, this category of features is great. The downside is that it doesn’t have a decisive impact on the ability of others to create true higher-layer services on top.

The second category of features plays on the fact that a connectivity service has more elements than simple packet-pushing. In an IP service, you need address assignment (DHCP), URL resolution (DNS), content caching and address redirect (CDN), for example. Operators routinely provide the first two of this group, but they’re less involved in the third, and they’ve not considered what might lay beyond the obvious-and-current members of the category.

The only potentially money-making service currently recognized in this category is CDN. There are a number of profitable CDN providers, Akamai being the leader, but the network operators have been slow to consider the space. A part of the reason is the “competitive overbuild” challenge; multiple access providers exist in virtually every metro area and each would have to deploy CDN technology to cover all the users. An OTT CDN provider could simply peer with each. CDN networks also require that the metro cache points be fed from some distribution network, but right now the biggest operator issue would be competition from CDN incumbents.

Dodging incumbents means dodging traditional CDN, or at least supersetting it. Two examples come to mind, likely related. The first is ad insertion and the second is “wholesale streaming”.

CDN technology can easily adapt to streaming video. Time-shifted stuff, in fact, is naturally a CDN application, and the distribution of live video via the CDN framework is also possible if the cache points can be fed in at least near-real-time. More and more networks and other players are either getting into streaming or interested, and there are already some accommodations to streaming underway among the CDN giants. An operator CDN might be an ideal mechanism to support a wholesale model of streaming.

Ad insertion is another (related) point. Programming has natural points where ads make sense and pose a minimal disruption to viewing. Could a network operator offer a means of identifying those places (in material where there isn’t a natural slot already staked out)? Could they then provide ad insertion? It seems possible.

Security opportunities may exist in this space. Virtually all network operators offer email services, but no major effort to promote email security and trust has been launched. Even spam detection features are rare in operator email services. Robo-call blocking is now mandated in some areas, but it’s been a potential security feature for over a decade, and operators have failed to capitalize on it. However, this is another area where operators would now face competition that moving faster might have dodged.

The last of our three categories, exploiting yet-unrealized service opportunities, is probably the most interesting and yet the most challenging for operators. Interesting for two reasons; there’s little or no competition in these areas, and the potential revenue upside is likely the largest of any of our categories. Challenging in that addressing any opportunity in this third category will be likely to create culture shock, and also require a considerable “first-cost” capital investment.

The biggest opportunity in this category by far is what I’ve been calling contextual services. We could visualize computing’s evolution over the last 70 years as a continual initiative to move computing closer to us, with smartphones being the most recent step. The value to that is its support for activities, rather than an insistence that activities shape themselves around computing. “Point-of-activity empowerment”, in other words. In order to offer that, we need information resources to be presented in the context of our lives and work.

“Context” is a complex relationship between where we are and indicators of our current interests and activities. Every aspect of our behavior sheds contextual clues, but many aren’t readily visible to software and thus available as a factor in tuning information presentation. Location is an example; we know where we are (most of the time, anyway), and we also know where many others are. We know our current mission, and we can often infer the mission of others by watching their behavior. If all that knowledge were available to software, we can likely imagine the value of the information the software could deliver. The challenge is making it known.

When telephony was first imagined, it was clear to most that the cost of creating a national phone network would be enormous, so great that nobody would likely do it except as a protected monopoly. The cost of creating the framework needed for contextual services would be very large too, but likely within multiple players in today’s market. Of them, the network operators have the advantage of a historically large tolerance to low rates of return and high initial deployment costs (“first costs”). Since contextual services would have to track us in the real world and conform to our changes in focus, they’d likely have to rely on edge computing, which means edge real estate to house them. Operators have that too.

In a sense, contextual services return us to something like the original notion of the “Internet of Things”. That original model aimed to foster a widespread deployment of “things” on the Internet, as free to be leveraged to create new applications and services as the Internet itself. It’s pretty easy to see how a collection of sensors could be used to track traffic conditions, even detect collisions. Something like this could form the basis of a whole new layer of navigation systems, paralleling the traditional GPS. The question would be who spent the money to deploy and secure everything. Operators could do that, and they could also provide resources to host the “virtual agent” that would collect other contextual information and format it for wholesaling.

The motivation for operators to make the investment would be that wholesale revenue. Not revenue from renting access to sensors, but revenue created by encapsulating all the data, mulching it into useful form, and exposing it to partners via APIs. You don’t get traffic information from intersection sensors, you get counts of passing vehicles. There’s a higher-level process needed to correlate information from multiple sensors with street maps, and that process is what provides “traffic” data. Rather than having everyone try to derive the information from sensors (impossible, since all the attempted accesses would create what is in effect a denial-of-service attack on the sensors), the operators could expose services, and earn revenues.

This is what I think the ultimate in AT&T’s model of a service that promotes other services would look like. My model says that it could generate several hundred billion dollars in worldwide revenues for operators, and a like amount (or more) in higher-layer partner revenues. It’s a big lift for operators to think this way, though, and I don’t think we’ll have a reliable indicator of whether any will make the move until we see how they deal with the more comfortable categories of new features. We may have some insights into that later this year.

Who, if anyone, could actually move everything to the cloud? I’ve never been a fan of the “move-to-the-cloud” model because my data has always shown a different trajectory for cloud growth, but the view that a full migration is inevitable is pretty pervasive. What can we say about that, based on information from enterprises and my modeling? A lot, it turns out, and while it may not support popular views of cloud evolution, it offers a very positive view about cloud growth.

The only motivation to use any IT strategy, including the cloud, is cost/benefit. “Cost” here means total cost of ownership (TCO), and probably the biggest misconception about public cloud service is that it’s less expensive than owning your own gear, because of “economy of scale”. Enterprises achieve nearly the same capital economies of scale as cloud providers do, and the majority of enterprises achieve reasonably good opex economies too. Given the risks associated with moving to the cloud, which include security issues and availability of compute resources you need network access to use, enterprises have generally declined to “move” to the cloud. However, they love the cloud in other missions, and there are some businesses who do show interest in an all-cloud strategy.

If we apply the term “enterprises” traditionally, to mean very large multi-national companies, my work and modeling has never indicated that everything would be moved from data center to the cloud. In fact, it hasn’t showed that much would be “moved” at all. Instead, the trend has been to use the cloud to develop “portals” that provide web and mobile device access to traditional core business applications running in the data center.

At the other end of the scale, it’s pretty obvious that small businesses with just one or two locations, relying on personal computers for their IT, aren’t moving to the cloud either. Still, it’s these one-or-two-site businesses that offer us some insight into just who might be contemplating a shift to the cloud. Most of these smallest businesses have only a few employees, but there are firms with one or two sites and over 50 employees, even over 100, and it’s this group that presents the biggest move-to-the-cloud potential.

What my contacts with users, and modeling, show is that in order to be a candidate for cloud-based IT (other than personal computers), a company has to meet some specific criteria. None of these criteria are decisive, so we have to look at how they all relate. We can gain some insight into how many might fit the bill through a use of government data on businesses.

The first and most obvious criteria for moving everything to the cloud is to have something to move, which means that there has to be at least a rudimentary data center. These days, this usually takes the shape of a rack of servers, which usually run Linux.

The second criteria is a high unit value of labor per employee, meaning that employees on the average are highly compensated. The higher the compensation, the more useful it is to make them productive. This tends to favor “professional” firms over retail firms, for example.

The third criteria is dependence on a single application. Generally speaking, businesses who run a lot of different applications tend to want local skills to support them. Those with a single application, predominately retail but also medical and legal firms, are better candidates for a cloud-only strategy.

The fourth criteria is tolerance to an Internet outage. In some verticals, loss of compute services could be literally life-threatening, and these companies are obviously reluctant to depend on the cloud, accessed via the Internet, to get to their applications.

The final criteria is application software sourced from a VAR/integrator. There are two impacts of this software approach. First, the fact that a firm is getting applications from a third party implies a lower level of in-house technical knowledge, which would make it harder to sustain in-house IT. Second, the VAR/integrator, if they provide a cloud-based strategy, will then influence all their customers to do the same. For self-installed software, there is no common motivator.

If we run all the business data through my model, what we get for the US market is that there are approximately 250,000 firms that fit the firm-size criteria. Of this, about 175,000 have a high unit value of labor, 110,000 are dependent on a single application, and 78,000 get their software from a VAR/integrator. Only 34,000 firms report low tolerance for loss of application access. The model combines these factors to indicate that of the 250,000 qualifying firms, 50,000 represent high-probability cloud-only opportunities, 120,000 represent “possible” cloud-only, and the remaining 80,000 have a low probability of moving everything to the cloud.

The model does suggest that there are a relatively small number of “enterprises” who could be candidates for a cloud-only strategy. These are verticals who represent a large number of employees per firm but a low percentage of high-value-of-labor employees. They also show very slow growth in centralized IT spending. There are roughly 20 verticals (out of 62 I model) that fit this bill. These represent approximately 14% of firms, or about 200 in total. However, up to this point at least, move-everything-to-the-cloud penetration into this group isn’t statistically significant.

One likely reason for this is illuminating for the whole move-to-the-cloud picture. This group of verticals has the lowest percentage of IT personnel, and the lowest average IT wage, of any group of verticals. My contact with this group is limited (for obvious reasons), but what I’ve had suggests that they believe they lack the ability to acquire and retain cloud expertise. They are uncomfortable making a cloud move, feel that they couldn’t support a cloud-resident IT framework, and often don’t even feel qualified to assess the cloud’s value to them, or evaluate the assessments made by others.

Could it be that even the companies who could benefit from moving to the cloud are trapped in their current IT models by a lack of skill? Since that lack of skill in their labor force is a product of their low IT commitment and their minimal career opportunities for IT specialists, and since that makes hosting their own IT difficult, it’s a classic Catch-22. I’m a cloud candidate because I can’t support in-house IT properly, but I also can’t support or even assess a cloud move properly either.

If my data is correct (which I believe it is), there is little to be gained by pushing a move-everything strategy to enterprises. There would be the potential to sell all-cloud service strategies to companies with between 50 and 500 employees, but the best path to pursue for this group would be to encourage their VARs and integrators to use the cloud instead of local compute for hosting those groups’ vertical-market applications.

The real opportunity may lie with the companies with between 500 and about 2,000 employees. This group is not currently committed to the cloud front-end approach that’s commonly used by enterprises for their public cloud services; only about 9% of companies in the 500-1,000 employee range use cloud front-ends for their applications and only 16% of the 1-to-2-thousand employee group does. This compares with 91% of “enterprises”.

The model suggests that the best way to approach a cloud prospect who doesn’t already have a cloud commitment, whether they’re an enterprise or an SMB, is through SaaS, either in the form of software specialized to their vertical or a “horizontal” cloud offering like Salesforce. This approach seems best because (as noted earlier) many of the companies who have not moved to the cloud say they lack the skills to either move or manage their applications there.

The final point the model makes is that even if all the nascent move-to-the-cloud opportunities were realized, the impact on cloud provider revenues would be smaller than that created by full exploitation of the cloud for new applications. We could add perhaps 40% to cloud revenues from realizing all the move-to opportunities, but we could more than triple it if we took advantage of new applications. However, half those gains would come from executing on “edge computing” missions, and the edge is still groping for a path to full deployment and for an architectural model that addresses everything optimally. There’s still a lot of work to do.

We’re reading all the time about how Web3 or the metaverse or blockchain are going to revolutionize the Internet. What the heck is a blockchain, as it’s applied to either Web3 or metaverse? I’m sure that you’ve already seen stories that assert a given vendor or service provider is at the forefront of one or both those hot new areas just because they have “blockchain”. I’ve noticed that there’s no real attempt to validate these claims, either proactively by the claimant or reactively by the media/analyst community. Part of the reason is likely that there’s not much understanding of how the whole process works.

I can’t possibly do a blog that explains all of blockchain, or even all about its relationship to Web3. Hopefully I can address the most important points, and issues. There are a number of blockchain technology options out there, and the one best-known is the Bitcoin cryptocurrency example. Crypto’s use of blockchain is a bit minimalist, so if we want to understand how blockchains would apply to Web3/metaverse, we need to look at something a bit broader, so I’ll pick Ethereum.

Relating things to Web3 as our general topic, practical blockchains like Ethereum have four basic pieces. First, they have a “blockchain”, which is an encrypted/protected ledger that represents a “smart contract”, the unit of journaling in Ethereum. Second, they have a community of “miners” who compete with each other to create the blockchains for transactions. Third (and related), they have “nodes” that perform the mining functions and validate blockchains to create a process of distributed consensus and trust. Finally, they have an Ethereum Virtual Machine (EVM) that executes actual code as called for directly or indirectly in a contract. In a real-world Ethereum network, “nodes” would perform mining and blockchain validation functions and also host instances of the EVM. This all interworks to create a framework on which something like Web3 and the metaverse can be (at least in part) based.

While it’s common to think of a blockchain representing an asset (cryptocurrency), Ethereum is more broadly focused on its representation of a contract. The concept, broadly, is an “If you do this then I do that” reciprocity relationship, which obviously works for asset transfers and other commercial stuff. However, there are core principles to blockchains that Ethereum, Bitcoin, and most all others will follow. Encryption is one, and full journaling (the “blocks” in blockchain) of changes is another. Ethereum adds another concept, which is the ability to execute code on EVMs, for many purposes, including the determination that a contract’s terms have been met, and so the compensatory action/transfer can be completed.

The blockchain is an ordered list of all the changes that have ever occurred on a “contract” from its inception to the current moment. Full knowledge of the past history is a big part of the provenance of a contract. The presumption in blockchains is that creating/encrypting a block is computational intensive, while reading one is far easier. The nodes in a blockchain network will read/validate the blocks, exchanging contracts to ensure that all the nodes have a copy and can validate it. In Ethereum, they also run “programs” in the EVMs. For their role in a contract, nodes are “paid” (in Ethers, the Ethereum currency). That’s an issue in itself, but one that you can review in other material.

Authenticity in Web3 “decentralized” environments is backed not by a big player (“big tech”) but by consensus. All nodes inspect blockchains, with each assessing its validity and with one of three mechanisms used to determine what passes the test. The first two are based on “voting” in an abstract sense, and the third on a specific property of the blockchain. One voting strategy is based on proof of identity, where validated nodes all get an equal vote. Another depends on proof of stake, where the votes one has depends on the contribution of resources made. The third concept is a bit different; proof of work. This presumes that the valid, most recent, blockchain is the one with the most work done on it, meaning the most blocks. Ethereum uses proof of work for validation because the other models could be broken if over half the nodes had been turned bad—by infiltration, contamination, or breaking the node network into segments to isolate parts.

All the players in an Ethereum network, the “smart contractees”, have both a public and a private key. The public key lets them exchange information with parties, and the private key lets them create and sign blocks. A smart contract is created by a creator/owner, who enlists a “miner” node to create the blockchain (for a fee). This would normally be transferred to another party, which would be done by having the creator/owner reference that party’s public key, and sign the transaction (the transfer block) with their own private key. This process is computationally intense since it requires doing the computation/encryption to protect the block. Unless the originator of the contract is itself a miner node, the transfer is “bid out”, with the node that responds fastest being the winner.

Let’s get to the heart of potential Web3 issues, which is the decentralization through the elimination of central “trust authorities” who are essential because they hold credentials and information that permits secure commercial exchanges. The theory is that blockchains like Ethereum would provide what might be called “collective” or “consensus” security. This means that nodes cooperate, sending each other copies of a blockchain, and that what’s a form of consensus prevents bad actors from contaminating things. The nodes are the guardians of consensus, the source of trust.

This is one fundamental area where I’m not comfortable, frankly. There’s a “proof of work” theorem in blockchain, which says that each block represents work done on a contract. Since work requires blocks, blocks require considerable computational resources, the longest blockchain represents the most work and is therefore the most up-to-date and likely the most authentic, because the nodes have collectively validated it or they’d discard it. However, it’s possible to have the nodes broken into separate areas by a network problem or attack, and it’s also possible that a bad-actor node might represent a computational collective of enormous power, enough power to work faster to create bad blocks than the rest of the nodes would be able to work to validate good ones.

I remember the early days of the Internet, the days before the web and widespread public access. The great majority of the real players were known to each other and trusted, and when things like malware and DDoS came along, the technology wasn’t really equipped to deal with them because they never had to do so before. My concern with Web3 is that we’ll find that the scale of nodes needed to make true decentralization work will create an opportunity to inject bad stuff in ways we’ve just not adequately assessed and dealt with…because we’re thinking like most of the world is good. Maybe so, but a few bad people can do a lot of damage nevertheless.

Another issue I have is another “proof”, proof-at-scale. Web3 is either an enormous, pervasive, enveloping movement or it fails. You can’t partially decentralize. Cryptocurrency is an application that, for all the value of the assets, doesn’t generate a huge number of transactions. Web3, if it’s to replace centralized authority and trust, would have to generate thousands, millions, of times more activity. The computational effort associated with mining is significant; it has to be for the concept of “proof of work” to be effective in keeping bad actors at bay. How long would it take to validate a transaction? We’re used to having purchases or other online fulfillment happen in seconds; blockchain mining might increase that to minutes or even hours depending on how long the chain is and how fundamental the changes being made are. If an early block is changed, all later blocks have to be re-processed.

Then there’s power/environmental. Crypto activity already consumes enough electricity to power a city, so what would Web3 do? There is already pressure to reduce the computational effort involved in blockchain mining and validation, but the problem is that things that make those tasks easier may also contaminate the basis of the proof-of-work means of keeping bad actors out. A blockchain easily processed is one easily forged, hacked, etc. Will pressure to reduce the environmental impact, or to speed the approval of transactions, lead to a weakening of the security?

It’s really hard to say whether the issues related to blockchain can be resolved, for two reasons. First, we’re so forgiving of bold statements, presented in an interesting way but totally without proof, that there’s really not much incentive for the early Web3 and blockchain players to pay much attention to reality. Arguably, the current climate encourages sweeping a lot of technology and issues under the rug in the name of promotion. Second, we really don’t have a solid example of what our blockchain goals are. Even Web3, the most “active” area in the blockchain startup ecosystem, is known mostly by its hazy “decentralization” goal. At best, you don’t know whether you’ve met a hazy goal or not. At worst, everything can be claimed to meet it. Either way, we can’t be sure that decentralization is a worthwhile goal, given that we’ve done pretty well with the current model, or even whether it’s possible. Given all of this, it’s hard to make real progress.

We have made real progress in networking and IT over the 70 years or so that the two have existed. The progress that’s created the most economic and social value was largely made prior to the year 2000. Is the reason for that the fact that over the last couple decades, we’ve spent more human capital creating hype than advancing the industry? Worth thinking about.

Research reports are always interesting, but like anything these days, you have to consider the question of bias. Nobody is going to publish research that contradicts their own market positioning and sales efforts, which is why individual companies’ research is nearly always suspect. Organizations like the TMF, representing a collection of companies, are sometimes immune to specific bias, but even they may publish reports that are sponsored and have to be assessed objectively. That’s the case with a recent TMF report, sponsored by Red Hat and available HERE, and called “Key Themes for 2022”. There are eight key themes in the report, and we’ll look at each of them briefly.

The first theme is “core networks: 2022 is all about deployment, not monetization”, and it’s an interesting point that’s worthy of being first. Essentially, the idea is that operators are changing their vision of “core” networks to unify wireline and wireless in general, but in particular to support 5G Core and 5G SA concepts. The sense is that operators are going forward with 5G Core and in particular network slicing to create new future revenue. Right now, they know they need to suck it up and bear initial deployment burdens.

While frankly I think this is an approach that’s incredibly risky, it is in many cases the current operator view. They are committed to 5G as an evolution of cellular broadband. There is next-to-no willingness to pay more for consumer 5G, and if you look at 5G logically you’d expect that this would result in having 5G RAN deploy over legacy LTE Evolved Packet Core (the so-called “Non Stand Alone” or NSA model). This would likely mean that there would be no real additional revenue from 5G at all, which looks bad for operators. Thus, they cling to the notion that having 5G Core and network slicing will somehow transform them. Do they believe it? Most I chat with do not, but they have no other position they can take to affirm a revenue-positive 5G model.

The second theme is “Open RAN’s disruption of the radio network oligopoly will ramp up in 2022”, and I think this is also a fair statement of what operators say and see, and what I think is going on. However, I also think it’s an oversimplification, and that the linkage between it and the first theme needs some explaining.

Open RAN has in fact helped to open up the RAN, but is that really disrupting the “radio network oligopoly?” The actual radios involved in 5G are far from open and populist, and the one thing that every 5G network needs is radios. The fact is that the radio piece is, and has been, the primary attractor for the big mobile vendors. Some operators even argue that without a major initiative to create an “open radio” as opposed to an “open RAN”, the impact of the Open RAN initiative will be limited to new entrants and small players. So as a belief, this theme is valid. As truth, not much more than a “maybe”.

Theme three is “telcos are playing catch-up as MPN competition intensifies”, and this shifts focus from what operators think to what I believe vendors like Red Hat want them to think. MPN means “mobile private network”, and so this statement is both an assertion that there is significant new MPN opportunity to be had, enough to be important, and that telcos could and should chase it by providing MPN packages. Both these points have problems to consider.

We have no reason to believe that 5G will generate significantly more private cellular networks than 4G has. With regard to 5G MPN as an operator opportunity, that smacks of self-cannibalization. Enterprises would adopt private 5G only if it were less expensive than operator 5G, so it’s hard to see how operators could think this was a big plus for them. Enterprises would have a lower barrier to adoption for open-model 5G, and despite the fact that there’s no solid reason to think they will be significant sources of adoption (and revenue), vendors like Red Hat look to them for some early success. If operators could be induced to jump on supplying private 5G to enterprises using open-model networks, so much the better. This theme is more wishful thinking than a statement of fact, but there’s at least a tenuous basis.

Theme four is “end-to-end orchestration gathers momentum as 5G scales up”, and with this point I think we’re moving into speculating a future shift based on a chain of hopes. If UFOs land, and if the inhabitants want to eat out rather than on the ship, there’s a market for alien groceries. You can probably guess from my analogy here what I think about this theme.

We have no solid model for what the network of the future would look like, but as I’ve said in many blogs, I believe that changes in demand will drive architecture changes, not technology shifts like 5G. It’s certainly possible that SDN and function hosting (not NFV; that concept is D..E..A..D) will play a role in creating edge applications. That will create a need for orchestration, but function hosting or SDN will not be driven by 5G RAN or Core, open or otherwise. That’s more likely to be an effect of edge computing, for which we’re looking at an IoT or metaverse driver.

Theme five is “telcos should open up their networks to become true platform businesses” and here I really think we’ve elevated oversimplification to an art form. Let me get this straight. We’re network operators sagging under a burden of decades of decline in profit per bit. The solution is to become a wholesaler, offering our bits to others for exploitation…and wholesalers need a discount. What’s wrong with this picture?

AT&T said the right thing here. Operators need to build new features that they can wholesale, features that would facilitate the creation of higher-level (OTT) services. They do not need to sell current connectivity, marginally profitable as it is, at a wholesale discount.

The sixth theme is “digital trends are raising the bar for customer experience”. As operators move into the advanced 5G services that they hope to find customers for, those customers are going to foul the profit nest by demanding even more quality when we know they’ll be hoping to pay less for new connections, not more. We have hypothetical B2B slicing or private 5G, but surely more demanding in QoE. This is now, IMHO, promoting a vendor-centric vision that undermines the business case that would be needed to support doing anything at all.

QoE is important, but if we’re talking about 5G services based on network slicing cores (the earlier themes) then “raising the bar” is hard to justify given that these are services with no experience base. In any event, the notion that you absolutely have to meet customer expectations no matter what is simply silly. You have to deliver what you promise, at a price that gives you a profit and makes the customer’s business case.

Theme seven is a question: “will hyperscalers continue to have the upper hand in relationships with telcos?” The telcos have provided, says the piece, the connectivity on which those parasitic public cloud giants ride to their billions. Well, yes, and that’s exactly the role the telcos chose for themselves. They had every possible asset in the public cloud service market—the real estate, the connectivity, and the low internal rate of return that facilitates a market entry. They had good free cash flow and a historic tolerance for a big capital investment. Carrier cloud could have tapped the market that the public cloud providers exploited. It’s now too late to be thinking like that.

What this theme about is really “co-investment” which means that somehow both sectors would cooperate to produce a common service set. This is again what AT&T is talking about, but AT&T is looking at the issue sensibly. Yes, it would be possible for telcos and the public cloud giants to set up a partnership. Right now, such a relationship would either favor the public cloud providers or it wouldn’t happen. The telcos have no leverage. What AT&T has suggested is that they could create leverage by framing lower-than-OTT-higher-than-connection services that would shape the partnership. That’s the right approach.

Theme eight, the last one, is “telcos strive to become better competitors in the war for talent.” The report talks about COVID and the “great resignation”, but the fact is that telcos have been disconnected from the leading edge of the tech job market for decades. Why? Because they hired what they needed for what they wanted to do. They wanted to build it and let them come, where the real skills gravitated to Those who built where “they” wanted to go.

Every organization is self-limiting in hiring. Managers hire for positions they value, and pay for the skills associated with those positions. The truth is that the “talent” the report talks about will always, these days, go to either startups, vendors, or OTTs, because those organizations offer more. There are many companies who cannot acquire or retain talent in key technology areas, largely because they can’t meet prevailing salary/benefits or can’t provide a credible career path. Some, like the telcos, aren’t really trying today, but would they offer as good a position as one of those startups? I doubt it.

The report makes some good points, cites some interesting data, but I think that it shows a bias that colors its conclusions more and more as we progress through the eight themes. Most of all, it reflects a subliminal “supply-side” vision of the market, the notion that a specific technology deploys because it’s “better” or “newer” or “more open”, even if there’s no clear business case to drive its adoption. That’s a view that a vendor in the networking space could be forgiven for holding, but not one that’s likely to succeed for either sellers or buyers. In the end, wishing and hoping won’t make it so.

What do we need to see, condition-wise, for Open RAN (or other open-model networking) initiatives to succeed? There are plenty of articles on this question, but nearly all focus on a single technical/business issue directly related to Open RAN itself. As an industry, we tend to look at technology changes as isolated processes, with little or no relation to either independent drivers or related activities. That’s a pretty doubtful proposition, I think, but what specifically would facing interdependence mean to our view of technology advance? Let’s try to figure it out, starting as usual from the top.

There are two reasons for open-model networking. First, network vendors have their own bottom lines and stock prices to support, and so their goal is for network operators to buy more stuff every year. When the ROI on the “stuff” is declining over time (which it is), operators’ incentive to play their role diminishes. Second, vendors will (privately, usually) admit that incumbency is their greatest asset. A revolutionary change in technology or opportunity can promote a vendor change, so vendors will usually resist revolution if they’re incumbent. If they’re not, their ability to promote it is limited. Catch-22.

Obviously, this boils down to a single point—network operators believe that network vendors are hurting their bottom lines, retarding useful advances, to suit their own interests. The solution? To create something like we have in the IT and data center world, where commodity hardware combines with open software to create a market that commoditizes on prices and focuses on trying to create new features as a means of rising to the top. There are issues with both these goals.

It would be, IMHO, very difficult for an open-model entrant to cover a major swath of network technology on their own. If the technical requirements of a given major segment of the network could be met by simply assembling hardware and software elements, and if price commoditization was the buyer goal, then the revenue model for the vendor would be pretty questionable. Most open-model advocates are focusing on a specific piece of a service/infrastructure puzzle, and relying on integrating other stuff for the rest.

Who does the integrating is an issue here. Unless the open-model player is a significant company, they likely lack both the resources to do a major integration project and the credibility to back it up. That puts the integration onus on the buyer, and that generates a perception of risk, which generates resistance.

Creating new features, meaning providing a benefit beyond simple price commoditization, is a possible solution to this. The problem is that in an open-model network, creating new features without becoming proprietary is a challenge. If the new features are “open”, then they don’t differentiate the vendor, which means that their effectiveness as a dodge for pricing differentiation is limited.

Then there’s evolution. There are few “greenfield” operators these days, which means that the majority of candidates for open-model networking are companies with networks in place, built using proprietary technology from the vendors operators believe are working against operator interests. How does this interwork with new open-model technology, and how do open-model vendors handle the obstruction of incumbents to open-model introduction?

Where we are in open-model 5G relates to all of this. Operators are convinced that their vendors are locking them in and gouging them on pricing, both of which are at least somewhat true. What is just as true is that operators are not necessarily champions of openness, they’re just enemies of lock-ins and gouging. They want their familiar business model to work, and they’re prepared to ask for sacrifice for that to happen—vendors’ sacrifice, of course. Open-model 5G is a way of levering discounts out of their vendors more than a goal to transform the industry, and their own infrastructure.

This is why I believe that AT&T is so important. They’re the Tier One with the most challenges in the “traditional” access/connectivity business model. They’ve demonstrated that they’re prepared to take what most in their space would consider extreme measures. They’ve articulated a series of sensible paths toward a better infrastructure, a better business model.

Open RAN, open-model 5G, and open-model networking in general, are all forces of change, not the determinants of that new model. We don’t yet know what the new model is, but it is something that will respond to all of the forces of change, decisively enough to bring about a change in how we buy and build networks. Linux and its success was the most recent act of an IT shift that started forty years ago and had absolutely nothing to do with the philosophy of open source. It was the intersection of vendor needs and available paths to take. Networking will take the same path, but in its own idiosyncratic way.

IT is populist. Networking is elitist. There are hundreds of thousands of companies that consume IT on a fairly large scale, and over 70% of all network infrastructure investment is made by 25 companies. There are two ways to get that kind of ecosystem to change. One is to have a member (AT&T is the obvious candidate) demonstrate the right path to take. The other is to have a vendor step up and define what the model of the future network will be, with such clarity and charisma that it sweeps through the market.

I’ve said in prior blogs that I do believe that the SD-WAN/virtual-network technology pathway can lead to incremental connection revenue, but that model doesn’t directly relate to the AT&T goal of defining a kind of “service middleware” layer that would add features that partners could leverage in building higher-layer service offerings. Does somebody have to get specific with respect to this new feature set?

This opens the last form of “interdependence”, which is the issue of overlapping business cases. A supply-side view of the market, one that reflects the “build it and they will come” perspective, conveniently dodges the business case challenge. That’s bad, because for things like 5G there are actually a series of interlocking technology changes, each of which requiring a business case. We have a strong business case for 5G New Radio and NSA, but the business case for 5G Core and network slicing is problematic. The relationship between anything in 5G and edge computing is similarly tenuous at this point, since operators have not been using 5G function hosting to justify carrier cloud.

Interdependence is complicated, whether it’s related to open-model networking or anything else, and we live in an age where complexity is something we avoid, even where facing it is essential to making progress. So when you read that all we need to have to make 5G SA and network slicing work end-to-end is integration, reflect on the question of whether instructions on how to assemble a boat would be helpful to someone in the middle of the Sahara. A strong business case is always the place to start.

We might be facing a major, even seismic, shift in networking. How are vendors going to respond? Will the changes that we could see have an impact on their ranking, even on their bottom lines? The situation is still very fluid, but there are some early signs and signals we can try to read. There are three major forces driving the shift, so let’s start with them and move to their impact.

Force Number One is bit commoditization. That’s another way of saying that willingness to pay for network bandwidth is rising more slowly as bandwidth increases. Users tend to cluster at the low-capacity end of service ranges, and the price of twice the bandwidth is far, far, less than double the base price. That’s making it harder to sustain profit margins on access and connection services, since competition tends to push prices down where differentiation isn’t possible.

The second force is open-model networking. Vendors have relied on incumbency and inertia to sustain their customer commitments, even as they try to raise prices to improve their own bottom lines. Today, we’re seeing more network products based on open platforms and open-source software, and this not only reduces the strike price for technology (forcing incumbents to discount), it also threatens to create a completely open-model future, where proprietary technology will be difficult to sell.

The final force is edge and metaverse computing. For decades, network traffic has been increasingly video content, and that has been served from edge-sited cache points, the “content delivery network” or CDN. This has reduced core network traffic, but cloud computing and general Internet access still creates a need for core connectivity. Edge computing, driven in part by the metaverse, will place more compute resources in metro centers, and meshing these centers will shift networking toward an almost-data-center-network edge meshed via an optical core.

OK, so what can be done about these forces? That’s obviously a lot more complicated.

Bit commoditization is perhaps the top of the cause-and-effect heap. There’s a growing demand for capacity, particularly in the consumer market where the Internet is becoming (virtually, in many senses) the center of the universe. There is no corresponding expectation of proportional payment, so network operators have been trying to cut costs in order to sustain their profits. You can cut cost through your capital and expense budgets (capex and opex), and for over a decade, operators have been trying to do both. That’s put pricing pressure on the network vendors, and their response has been to discount when they had to, but to focus on trying to (subtly) lock in customers with features, certification programs, etc.

Open-model networking is arguably a response to this top-level force. Asking vendors to discount, absent any credible alternative source of products, is a waste of time. Operators take heart from the server market, where Linux and open-model server technology has combined to create a highly competitive market where vendor lock-in is nearly impossible. It’s a buyers’ market. The operators see that, and hope that a similar move to white boxes and open-source software would make networking a buyers’ market too. The challenge for open-model networking is integration, because the classic approach demands the buyer pull pieces of technology together to make it work. DriveNets’ biggest impact on networking has been to create a credible one-stop shop for open-model technology, but they still face the force of incumbency and the willingness of competing proprietary vendors to discount if they have to.

5G deserves a special comment in the open-model space, because 5G is transformational at the infrastructure level, and that sort of thing opens opportunities for non-incumbent vendors to step in and take some market share. It therefore represents something that incumbents will want to defend vigorously. The question is how, given that being against openness is cynical at best and totally opportunistic, manipulative, and doomed to bad PR at worst. We have a mixture of software vendors playing in this space, like Mavenir, Dish, Microsoft, and VMware, but the market is still trying to shake out a face of open-model 5G.

The thing about these two force-response pairings is that they’re accepting the notion that bit commoditization is inevitable because no connection features can be added. This assumption is true as far as it goes, but as I noted last week in my blog on AT&T’s response to conditions in the market, there are now new circumstances to be considered. As AT&T said, “I’m talking about moving up the stack to do things with our network that allows us to refer our connectivity, because it will work better with people who are running more sophisticated software on top of that stack.” That’s a way of saying that while AT&T doesn’t see itself becoming an OTT player, they do see themselves building out “up the stack” to deliver connectivity-related features that would facilitate other players’ creation of more sophisticated stuff. AT&T, presumably, might sell that stuff, but it would surely sell the up-the-stack features.

The final force, the edge-and-metaverse movement, is important because it’s a disruptor of the network model and not just of ROI. Edge computing and metaverse hosting, even perhaps Web3 “virtual machines”, are surely metro functions. Metro areas are big enough to justify the resources, and few enough that once they exist, they could be meshed with fiber to create a kind of distributed super-core. Metro areas would be a combination of a powerful data center and data center network, including CDN hosting, and an element in this optical mesh. What this has the potential of doing is revolutionizing how networks are built, which undermines the value of incumbency. It’s a force that current network leaders need to watch, because it’s the one that could making resting on your laurels start to look like resting under them.

So that’s the forces and the general responses. Can we say anything about the vendors and where they might be taking things? I think that there are really two “disruptive” vendors, ones that may be representing change rather than trying to cement incumbency. They are DriveNets, who’s the open-model fresh face, and Juniper, who seems to be the only “incumbent” who’s really proposing to face the future through an insightful expansion of features, rather than by trying to deny or obstruct it.

DriveNets’ product is a kind of modular router, a cluster of white boxes that behave symbiotically, with specialized but open (if not strictly open-source) software. It’s a disaggregated approach, one that they describe as creating a “network cloud” that can be divided into multiple router instances or used cooperatively to create a network. The individual white boxes are interchangeable, which means that one set of spares supports all the possible missions.

Juniper is a traditional network equipment vendor who’s made some non-traditional acquisitions. Of particular note are those of 128 Technology (SD-WAN, virtual networking, and session-based security), Apstra (intent-based data center network deployment) and Mist (AI/ML for management of operations). They’ve created a powerful symbiosis among these new elements, one that aligns nicely with the changes in the network market that I’ve summarized above.

Both these vendors have responded to the “seismic changes” that are at least possible (and IMHO, inevitable), but it’s interesting that the two are on opposite sides of the incumbency issue. DriveNets needs buyer acceptance of the notion that radical changes are underway to blast buyers loose from their current network models and commitments. They do well where an operator has decided that change is coming, but incumbents tend to defeat them where no such realization is present. Juniper, as an incumbent, has to balance their tales of revolution against the fact that revolution could put some of their own base at risk…perhaps to an up-and-coming like DriveNets.

If I’m right about seismic change, then it’s these two network vendors I would watch most closely. What I’d watch for is how they respond to the 5G and edge computing initiative in particular. We are already seeing, with AT&T, some transformational thinking that suggests that operators are already planning for change, and AT&T has offered some insight into what those operators are likely to be thinking about. Right now, that prospective vision isn’t a major element of any vendor’s positioning, including both DriveNets and Juniper.

Aggressive positioning is always a risk for a startup. Aggressive positioning toward a radical market shift is always a risk for an incumbent, and culturally it’s a risk for pretty much everyone. However, if there is a seismic shift, then naked aggression is the winning response. I’m really interested in seeing whether either or both these vendors, or a competitor, takes the plunge.

But what plunge should be taken? I’ve said in past blogs that any focus on content or experience would inevitably lead to a concentration of service assets in metro areas, because they’re close enough to the edge to deliver QoE but deep enough to represent a reasonably large service opportunity base. Metro networks would look like data center networks meshed through data-center-interconnect (DCI) optical technology. We’d have much, perhaps even most, of the high-value stuff terminating there (certainly all the content, metaverse hosting, and so forth) and accelerated connectivity among the centers.

What about the other vendors? In the mobile space, I think the “incumbent” is really Nokia, and they are doing a decent job of navigating the Open RAN shift. I still think VMware, of the software/cloud vendors, has the cleanest shot at open-model 5G overall, but because network operators are favoring cloud-hosted solutions, they risk being submerged. Cisco, as always, is fast-following rather than trying to lead the trend, but they’re likely to kick off some M&A as soon as they see that there’s clear evidence that my seismic shift is real. I think we may see clear movement this year, almost surely in the second half, but depending on geopolitics and economics (including COVIDnomics) we might have to wait till early 2023 for a clear trend to emerge.

I’ve noted several times in recent blogs that AT&T is at a disadvantage versus rival Verizon because of the sharp difference in their demand densities, the effectiveness of infrastructure to address opportunity in their service areas. That’s not a good thing, to be sure, but it has given AT&T the incentive to do something that few Tier One operators globally have even considered, and that is to restructure itself away from the regulated monopoly it grew from. It could be that AT&T is the most important telco on the planet, because they’re the only one testing the murky waters of the future.

Light Reading did a nice piece on AT&T’s recent investor/analyst conference, and it quotes AT&T in expressing what can only be called highly impressive insights about the network services market. That makes it a great place to start in trying to dispel some of that murk.

Our first quote is “The AT&T story will be written in two acts. Today we’ll focus on the first act, and that is taking our current asset base and delivering competitive returns.” Shedding what the article calls their “troublesome media business” lets them focus on being a premier broadband provider. That’s the core issue for any telco, any network operator. You’re in the connection business. You have billions of dollars in network infrastructure, and you can’t let all that sunk cost end up supporting a loss leader. You have to clean house in connection services.

What is the second act? “On what I refer to as Act Two, we are doing a lot of work today that is enabling us to open up aspects of the network for others to come in and start at offering value-added services associated with it.” This, to me at least, suggests that AT&T is saying that it will build service value “upward” from connectivity, through partnerships with others who have specific capabilities and incumbencies. Carrier cloud seems sure to be a casualty of this, and partnerships with public cloud providers seems sure to be the big winner.

The unification of these points can be found in this quote: “I’m talking about moving up the stack to do things with our network that allows us to refer our connectivity, because it will work better with people who are running more sophisticated software on top of that stack.” We need to parse that statement to see whether we can discover what path AT&T will take, and what might be the path for all network operators eventually.

“Moving up the stack to do things with our network” obviously means taking on things that are not part of pure, limited, connection services. AT&T is not proposing to let others do this moving; those others are the ones AT&T is going to be working with. They still see themselves as a provider of “that stack”, meaning the set of communications services from which value-added players will compose things.

All this is interesting, but it begs the question of just what AT&T proposes to add when they move up the stack. This quote provides a couple hints: “How do we begin instantiating software that can add these features back into the network that allow us to put value add on top of it and sell those managed services or capabilities back into the core connectivity that we put in place?”

Parsing this quote yields some insights, I think. First, the “features” that live “up the stack” are features that relate to the use of and value of connectivity. They’re not talking about OTT stuff here, but about things that are related to, and potentially enabling for, connectivity. Second, managed services are a specific target offering, the only such offering called out in the article and quotes. That, friends, is very significant, and it ties into the opex blogs I’ve just completed.

Opex is the bane of everyone’s existence. To make technology more useful, we need to expand how we use it. To expand how we use it, we need to add features and elements, and every additional feature and element is something that has to be managed. Creating successful tech in an organization means expanding complexity and expanding management challenges, whether you’re a network operator or a service user. I pointed out in this blog that enterprises are facing major problems in service and network management, not only for wide-area services but for the LAN.

Managed services, meaning managed connection services, would be the lowest of the apples to pluck, from the perspective of the sales process. Arguably, services like MPLS VPNs are a form of managed service because they replace an IP network built from transit trunks and routers with an IP service whose interior behavior is the responsibility of the provider. You can see why a telco like AT&T would like the managed service idea.

There is, however, another perspective to consider; the perspective of realization. To make managed services work, first and foremost, you need management economy of scale. You need a very low management cost, far lower than your prospective buyers could achieve, low enough to allow you to tack on a nice profit margin and still be better/cheaper than not only the buyer’s self-management, but also other managed service competitors.

This is where that past blog series on service lifecycle automation comes in. Here we have the telcos like AT&T, who have historically been stuck in the mud with regard to lifecycle automation because they’ve been unable to modernize OSS/BSS systems or to shed their device-centric NMS strategy, something that just does not scale to provide the economies they need for managed services to work.

Managed services need two technical layers to be effective. The first layer, the “consumption” layer, has to present an entire feature collection as a network-as-a-service offering. The buyer cannot be aware of the details of a service you’re going to manage, because that defeats buyers’ desire to unload responsibility. The second layer, the “production” layer, has to be able to focus management on the “feature SLAs” of each service feature the consumption layer exposes.

IMHO, this is the perfect picture of a hierarchy/intent-modeled service view, the focus of yet another of my blog series recently. Putting things another way, one aligned with semantics as much as technology, managed service success demands management by analysis and not management by synthesis. You don’t build up from devices to services the way the old OSI management model required (synthesis), you build down from services to the devices that create them (analysis).

AT&T hasn’t said what its plans for modernizing lifecycle automation might be, and in fact hasn’t really signaled that the recognize the step is essential if managed services are to succeed as revenue generators. There are a lot of questions that need to be addressed in a realistic initiative to do that kind of modernization. We still have to balance the value of “self-organization” or “adaptive” management against explicit management and traffic engineering. We have to work out what role AI and machine learning might play, and we have to figure out how to evolve from what we have to wherever we believe we need to be. It’s going to be a long, exciting, and frustrating journey, I think, for AT&T and for all the network operators.

A unified lifecycle automation model, as I noted in my blog on March 15^th, seems to be the only way for operators to stabilize or reduce opex, now that they’ve used customer care portals to pick the low apples of high-touch support. I’ve suggested that this would likely involve creating a single state/event-driven model for service/network/OSS/BSS, and that it could impact future profit per bit trends. How? That’s what we’ll look at today.

OSS/BSS systems, the biggest consumer of IT resources for operators today, are often based on a hierarchical service model like the TMF’s SID. I’ve suggested in recent blogs that this approach could be modernized to allow for hierarchical decomposition of elements, explicit intent model principles, and perhaps a link to a digital-twin model of infrastructure. However, I was really looking at lifecycle automation in terms of the operational lifecycle rather than the entire lifecycle. Let’s start with the difference.

In operations lifecycles, we could expect the process to start with a service in a state we might call “orderable”, and an event we could call “order”. That event would initiate the process of decomposing a commercial-feature model downward into resource commitments. The “order” would presumably emerge from the commercial side of the service, which could be an OSS/BSS element. Could we, should we, model that commercial side?

Portal technology has proven that it’s possible to rethink “service operations”, eliminating the OSS/BSS model in favor of treating customer orders for service or service change as transactions, transactions for which we have a cloud front-end. Work I’ve done with regional business service operators suggests that these companies tend to create a portal-based system rather than adopting traditional OSS/BSS. As I’ve noted before, about half of a given Tier One organization seems to want to trash OSS/BSS and start over, presumably with a portal strategy.

It’s not quite that simple, of course. There are two sides to OSS/BSS, one focused on managing the order/support processes (especially billing) and one focused on managing “resources” that include the field service people and higher-value trunks and service elements. For example, where do we have capacity on a “multiplexer” to connect a new access point? We could surely convert a lot of the process to a portal-based system, using for example the public cloud to front-end current systems. We could also use the “new” portal to generate events to our state/event process. However, in order to do all this, we’d need to build event-driven process elements to replace the current transactional OSS/BSS frameworks.

What’s actually happening in most telcos and many cable companies is that there’s an “OSS/BSS modernization” movement aimed at “real-time” behavior. In practice, this is sort-of-creating the same model for OSS/BSS applications that we’re seeing in enterprise applications, meaning that it’s building a web/cloud front-end to a legacy system. That has been helpful in that it’s limited the impact of automated customer care on the balance of the operations systems and practices, but it’s also limited the extent to which we can actually unify operations. The relationship between OSS/BSS and NMS, in particular, has been largely sustained, and since I’ve noted that the relationship between NMS and virtual functions sustains the device-management model of traditional networks, we have created a chain of limitations.

That chain of limitations is further sustained by the public-cloud dependence that’s growing among operators who deploy 5G or other virtual-function-based applications. That’s because this move taps off the need to create IT operations systems that are more efficient; public cloud operators now do the IT operations. And, of course, because new IT operations systems would be the easiest way to “modernize” and “unify” lifecycle automation.

IT operations, in the wider world, is in large part application operations. While there is normally a mechanism for identifying broken IT elements that are not currently committed as application resources, the primary focus is to redeploy applications around the stuff that’s broken. Repair of the resources themselves is a manual, offline, task.

Application operations is increasingly event-driven, meaning that steps are taken to remedy problems, triggered by a report of a problem. Scaling and redeployment, for example, are attributes of a container/Kubernetes platform, and issues are triggered by a report of an issue by a distributed element, or by having a distributed element disappear and stop reporting.

OSS/BSS systems are just applications, core business applications like those found in virtually every industry. Things like order entry, customer care, CRM, ERP, and so forth have counterparts in both OSS/BSS and other industries. Operators’ CIO organizations and their vendors have, not surprisingly, resisted any thinking that OSS/BSS has no reason to be “different”. However, there is increased recognition that OSS/BSS needs to be modernized, made “event-driven” or “real-time”.

Some vendors are making progress in that area, and a truly event-driven OSS/BSS would be a very critical step. We don’t seem to be there yet, and I’m not even sure that there’s general movement in that direction at the technical level. The current vendor approach is to do something based on events, and then say they have an event-driven system. PR conquers all, I guess. However, a movement toward virtual-function hosting in any form could break the logjam for three reasons.

First, virtual-function hosting would really require a modern event-driven, application-centric, IT operations model. Such a model, derived from the broader IT marketplace, could then spread to the OSS/BSS space to manage OSS/BSS as an application, which could then encourage a more general commitment to industry practices for application operations and event-based automation.

Second, virtual-function hosting isn’t a CIO activity, it’s a network operations activity. The CTO and COO would have a greater role, and they have a much different, much broader, vision of lifecycle automation. A pool of operations people, focused on aggressive opex management, would quickly become the largest source of IT expertise within an operator organization, where the CIO group holds that title for most today.

Third, virtual hosting almost surely means a resource pool, and if there’s a resource pool available there will be pressure on the CIO people to host their OSS/BSS on it. Given the above two factors, that is very likely to shift the power of IT operations completely, and that in turn would likely stabilize lifecycle automation views around the network-centric model of function hosting. OSS/BSS is then just an application.

Which brings me to the final point. OSS/BSS systems are leftovers from an era when “provisioning” meant sending out field techs and making connections, running wires, and testing stuff. That high-touch past is totally impractical in the modern age of consumer broadband. We don’t “provision” services any longer, we “coerce” them from pools of resources. You don’t have your own Internet, or even your own broadband. You have access to a pool. Aren’t we then already at the point where OSS/BSS relevance is slipping away? Isn’t managing that pool of stuff now the real requirement. Worth thinking about.