Month: March 2023

Discussions about the threat of AI have been popular for decades. “Hal” in the movie “2001: A Space Odyssey” is a classic example of AI run amok, and the recent explosion of interest in large language models and chatbots has reignited the whole discussion. Generally, the threats can be classified into two groups. First, there’s the one I’ve already blogged about, the threat AI might pose in competing with humans in some tasks. Second, there’s the threat that AI could actually develop hostile or at least actively anti-human behavior. This is the threat that seems to be getting all the attention, and even prompting some calls to hold back on AI development.

The big question in assessing the threat of actively hostile or anti-human AI is whether that requires that AI be essentially human itself. That’s the “Hal” model, the one that gets all the attention. But how could we know that AI had developed to that point? It’s a pretty hard question to answer because it dives into not only what constitutes “human” behavior, but also the extent to which human behavior can be established by inspection.

How do we know that a being we encounter is human or humanoid? The answer is pretty trivial; we know because we know what a human looks like. The intelligence, behavior, and intent of that being doesn’t really play into our identification at all. But suppose we have this room-sized black box, and inside that box is a something-that-might-be-human. Other than breaking into the box and looking, how would we know whether the contents really were human? That’s the real AI question, because if an AI entity that’s populating our black box can pass all the tests we can give it from the outside, is it “human/humanoid?” If it is, might it pose an active threat?

For decades there’s been software that seemed to emulate human behavior. Some may remember the old therapy emulators that pretended to be an analyst having a patient conversation with us. More recently, we’ve had software tools that can recognize objects, speak, and so forth. Chatbots are an example of one of those recent developments. If we were to tie a chatbot with a really good speech recognition and generation tool, we could ask our black box questions and make an assessment, based on the responses, as to whether we had a real person inside or some software collection, meaning AI.

Of course, we’re not going to create a biological human with AI, and saying “humanoid” raises the prospect of aliens on UFOs. Is there a property of brain activity we could cite to “dehumanize” our discussion? The definition of “sentient” is “responsive to senses”. We could clearly create an AI entity that would qualify as sentient in at least a limited sense; it could “hear”, “smell”, “see”, “feel” and so forth. I put the stuff in parenthesis because its ability to to any of those things would almost surely be different from our own, sometimes better and sometimes worse. Despite those differences, we could put “sentient” AI in a black box and expect it to be able to fool at least some people some of the time, fool them into believing another human was inside.

We could also program our sentient AI collection to be funny, to laugh and cry and show “emotions”. We could even tell it to try to manipulate our views, to lie to us. It could present bias, fear, hope, and love in a way that would at least be credible to a degree, from our outside-the-box perspective. Long exposure might expose it, particularly if we were trying to make an identification of our black-box contents, but it would survive casual interaction.

This might seem an excursion into irrelevance, but it isn’t. We can say that AI could pass an inspection test and be declared sentient, but could it pass a test to be “human?” I submit that, from the black-box test perspective, the two are the same thing. If we can’t see the contents of the box and apply our “it looks like a human so it is” test, then we have to rely on testing senses to test sentience, and we would equate our result to a test for humanity. That’s what we’ve done with chatbots today.

A lot of animals pass the “sentient” test, as easily as our black box could. We don’t declare them human/humaniod. The thing that’s missing in most of them, and what’s inside that black box, is the sense of self. We can focus software development on mimicking human behavior, but does that make it human? How do we test for self-awareness? The fact is that we’ve been trying to do that, debating our results, for centuries. Rene Descartes opened a work with the statement, “Cogito, ergo sum” or “I think, therefore I am.” It’s a great test if you apply it from the inside, as a thinking being. From the outside, not so much. We know that most animals “think”, but “I am” is a statement of self. Do they have that? We can’t know because we can’t look inside. We’ve tried to test self-awareness by putting a mirror in front of an animal whose face/body has been painted in some way, to see if it touches the body part we manipulated or treats its reflection as another animal. Some think that’s shown some results, and others disagree. Could we make a robot “recognize” itself by programming, through? Certainly we could make it pass the outside-the-box tests we’d give it, so for AI this best-of-our-tests isn’t valuable.

Self is important in our debate on AI, because to form deliberate actions you probably need to deliberate, which means to project yourself into a variety of possible future positions. To be deceptive or threatening in a symptomatic way can be programmed into an AI entity, but to intend to be that is a deliberative decision. Can AI make such a thing?

If we go back to our black box, the answer is “we probably can’t tell”. I think that we could make AI appear to intend, even with today’s technology. The question is whether we could expect it to actually exhibit intentions, and that gets back to that sense of self and consciousness. Can we expect AI to be conscious? I think many believe we’re almost there. Not me. I do not think that AI is anywhere near to being conscious, and I’m not sure that we can say it ever will be. The reason is that we really don’t know what creates consciousness, even in ourselves.

I’ve talked with AI experts who believe that consciousness is purely a matter of memory and CPU power. I’ve talked with others who believe that it’s really about the way that our brains are organized, the way that things like memory and thought and forethought work. The former group is the most optimistic about the prospects for truly conscious AI entities, and the latter group is IMHO the most realistic, because it admits we don’t really know why “consciousness” even exists.

Chimp brains aren’t as complex as human brains, but chimps exhibit a lot of human-like properties. They pass self-awareness tests, for example. They can use tools, and there is recent scientific evidence that some proto-apes (or proto-humans, depending on where you fit them in the anthropological tree) may have actually made tools. Many would say that chimps can form intent, too, but few really believe the Planet of the Apes movies represent something that’s actually possible. We don’t know why that is, what separates them from us.

Even so, our black box raises a practical question, which is simply “Does it matter?” If we could create an AI entity that was indistinguishable from a human in every way we could test, would that entity be as much a threat if it was totally dormant in terms of consciousness as if it were fully conscious? Remember, the contents of a black box can only be determined by examining what it exposes to the outside world. Could AI entities, set to the task of designing better ones by themselves, eventually create one of those human-enough-for-all-practical-purposes entities? Perhaps, but even if it did, I don’t think it would be the kind of threat many believe AI could present, because I don’t believe that we’d have even as much problem disabling it as the pilot did in “2001”.

We are biological entities, self-powering in a realistic sense. AI based on “technology” will need power, and while it’s certainly possible to imagine that an AI entity could design a successor that would be almost-human, could it design one based on biology rather than on chips? Maybe that’s possible too, but we’re not seeing any signs of it now, it would surely be enormously complex given that we don’t really even know how our own brains work, and a lot of research ethicists would scream at even the early steps.

AI may help us cheat in school, at work, even perhaps help us invent alibis for things we do at home. In that sense, it can change our lives, maybe even threaten aspects of our lives and how we live them. That’s enough of an impact to suggest we need to take care with how we use AI, but I do not believe it poses even the kind of threat that Hal did, and I don’t think we’ll need the Three Laws of Robots to protect us any time soon.

Every technology advance creates winners and losers, all “progress” is subjective in that the positive connotation is true for only some and not all people. AI is progress, and like self-driving cars, smartphones, personal computers, and smart homes, there are some who are hurt by it, some who fear it. That doesn’t mean we need to call a halt to it, which in any case is totally impractical. It just means we need to manage the impact.

Relax and enjoy yet another tech-driven revolution. When you look around for rampant rogue robots, you’ll see instead a lot of humans who pose a greater threat. Read the news; we’re our own worst enemies, and AI can only be expected to cause a small perturbation in our overall risk level. Another old saying applies; “We have met the enemy and they are us.”

It should be clear to everyone by now that the EU is going to provide some mechanism to subsidize telcos for carrying OTT traffic, at least the major players. It is less clear (but should be) that this is going to have a seismic impact on the industry. Perhaps the lack of clarity can be attributed to the hype on all sides of the issue, so the most important question we should be trying to answer is “how do we dig through the chaff to find the wheat?” Let’s give it a go.

All this talk about subsidization stems from discussions literally decades old, emerging from some of the basic tensions that were created by the dawn of the worldwide web. Consumer data services were in one sense a boon for operators, because the improvements in network technology were making long-distance calling increasingly competitive and leaving operators with an “access” business that could never replace lost long-distance revenue. In another sense they were a major threat, because early Internet access didn’t impose any data charges. The absence of usage pricing encourages usage.

Up to the time of the Internet, operator interconnection for all services was done based on settlement. Even voice calls involved payment by the calling operator to the called operator, a “termination charge”. Data services (packet-switched data based on the CCITT X.25 standard and interconnected via X.75) were settled. There was no “bill and keep”, the model that emerged with the Internet.

Even in the early days of the web, the risk of an imbalance in revenue versus costs arose around the subject of peering. “Retail” ISPs serving users were net sinks of traffic, and they were also the most costly piece of the Internet. A “wholesale ISP” who focused on connecting net sources of traffic could peer with the retail players and essentially consume their capacity while keeping revenues from the content providers. What we have now with the over-the-top (OTT) players is the successor concept. You pay a CDN provider to deliver stuff to the retail ISP edge to get to the customer. You don’t pay the customer’s ISP.

Early on this distortion in cost and revenue was recognized. I’ve noted in the past that I’d co-authored an RFC (Savvis’ CTO was the prime author) on “brokered private peering”, which would have established a paid peering mechanism that was designed to help balance revenue and cost, and also encourage features and QoS. The problem was that “the Internet” was perceived as being somehow independent of infrastructure, separate from other networks. Consumers wanted good, cheap, Internet and what they saw of the Internet was really only the OTTs. No wonder the OTTs won the lobbying wars with regulators, and what emerged was net neutrality.

The real question here is just what the thing that’s popularly called “net neutrality” really is, and means. The goal, leaving aside the politics and lobbying, was to create a fertile field in which Internet companies could grow, and support a whole new set of rich consumer and business services on the Internet. Which, of course, meant “over the Internet”. At the same time, regulatory provisions tended to bar the telcos from participating in these new service opportunities for fear they would use their incumbent power to stall other more innovative players.

Where we’ve ended up with this approach is that we’ve created a traffic-generating industry (OTTs) and a traffic-carrying industry, with the former offered all the new opportunities for service revenues and the latter increasingly pressured by declining profit per bit. Competition among “access providers” targeting the consumers of OTT services has run into the problem that you can’t really differentiate access services by any means other than price, and consumers are unwilling to pay proportionally for capacity. If you get “basic” 100 or 200 Mbps Internet for $40 to $60 per month, you might willingly pay $100 to $120 for gigabit services. Streaming video is the big consumer of bandwidth, and obviously we have more and more providers of that, consuming more and more bits. Since streaming doesn’t even require gig bandwidth to deliver, many users are quite happy to stream over basic Internet, so there’s not even much of a chance of selling higher access speeds, just a chance to carry more traffic for the same money, which is what trashes profit per bit in the first place.

My friends in the EU tell me that we will either see subsidies like the ones by the OTTs paid to the telcos, direct government subsidies, or some impact on the consumers. The impact could come in the form of data caps on broadband access, price increases, performance degradation, or some combination of these measures. Any of these things could have a chilling impact on the Internet.

The basic truth here is that no business is going to operate at a loss, or even to operate in such a way that they have no chance of improving revenues and enhancing their stock price. Most telcos, having been regulated monopolies, have tended to be considered “value stocks”, paying a dividend rather than promising a lot of share appreciation. They need to be able to sustain a dividend rate that’s attractive and also sustain their share price. Telcos have done a pretty good job of managing costs over the last two decades, but the problem with cost management is that you can only reduce so much. Operators have already taken most of the accessible opex reductions, and the maximum capex reductions they could hope for would drop costs only by about 4.7 cents of every revenue dollar, and that would take five years to fully realize.

There is no question that at some point they’ll need to either raise more revenue or be subsidized in some way. To claim that they can sustain operation without either of these two things is simply wishful thinking. Those who, like me, believe that subsidies aren’t the best answer are believing that revenue is, then. But operators have proved unwilling or unable to think beyond the basic connection-service models, and even those who can rise above (literally) those services somehow seem to mess up their efforts. However, they are making some progress, particularly those in the EU where competition is more acute. The consortium of operators who launched a personalization and identity initiative had the right idea even if they likely still picked the wrong target.

Telco intransigence doesn’t excuse regulatory myopia, though. Regulators focused so much on preventing telcos from monopolizing new OTT opportunities by taking advantage of their financial and market power, that they discouraged any form of innovation. Neutrality rules are often blowing in political winds, and any major new service revenues will require significant capital commitments that would be at risk if the winds changed. Whatever the EU decides here, and however regulators worldwide respond to their moves, it makes no sense to offer a market sector a helping hand while nailing their shoes to the ground. The regulatory structure of the industry has to conform to whatever policies on subsidies any jurisdiction comes up with.

I’ve noted in past blogs on MWC that the cloud providers were front and center at the show, and also that public cloud providers had their sights on the telco space in general, and 5G in particular, as a conduit for future revenues. Amazon sent a copy of their MWC presentation, and it’s a good way to analyze what cloud providers are saying and thinking with regard to their future relationship with telecom. The key slide in their presentation shows three layers of AWS support for telcos, so we’ll look at them starting at the bottom.

The bottom layer supports telco OSS/BSS applications, and this is the layer that most telcos tell me is interesting to them. OSS/BSS is the “core business” application piece for the telecom vertical, and much of it is the same as, or easily related to, core business applications for the broader market. However, Amazon announced the AWS Telco Network Builder (TNB) at MWC, so let’s take a look at that.

The tagline for TNB is “Automate the deployment and management of your telecom networks”, and it’s an orchestration and management framework to deploy network applications using industry-standard TOSCA service definitions, and also with the NFV ISG specifications. Deployment options include AWS CloudFormation, EKS, and VPC. I think that TNB is essentially a TOSCA decoder that then links to AWS services and features, combined with virtual network function (VNF) deployment and management. As such, it is targeting network services rather than OSS/BSS, and it extends the “basic” telco support that vanilla AWS would offer.

Having support for VNF deployment is as good as VNFs are, of course, and that’s the big issue for TNB. While VNFs are indeed linked to standards (ETSI NFV ISG specifications), the NFV concept hasn’t exactly exploded on the scene. As I’ve noted in past blogs, operators have had very mixed views on the value of VNFs as elements in the service data plane, because of performance and latency issues. If VNFs are actually to be used by telcos, those telcos could look at hosting them on AWS using TNB, but public cloud VNF hosting is also a stretch. Given that VNFs themselves are limited, adding public cloud hosting raises the issues considerably.

There are places where TNB could make sense, primarily in control-plane elements of things like 5G. However, the “telco network” is now and will likely always be dominated by network devices and not VNFs. I think that, ironically, TNB success may hinge on the success of Nephio, which is a Google project that would enable Kubernetes management of network devices as well as virtual functions and other containerized applications/components. Will Amazon join that initiative, or expect telcos to integrate Nephio. If they don’t do either of these things, I think TNB will have limited impact.

Amazon’s “Telco Ecosystem” middle-layer piece is focusing on the partnerships they’ve established with vendors, integrators, etc. The next thing Amazon talked about at MWC was the top layer, where they introduced the Smart Home Platform, Integrated Private Wireless, and Network APIs.

The smart-home piece seems aimed at providing telcos a role in the smart home revolution. Amazon points out that consumers love the concept of a smart home but are often defeated by the technology requirements. Telcos could play a role in this, offering an ISV platform that would be device-agnostic and centrally managed. I think this could be a smart play, but more for smart buildings than for smart homes, because I’m doubtful that consumers would pay for the integration given that they can get apps and hosting from the device vendors, including Amazon with its Ring series.

There is an extension of the concept for businesses, though, and that seems aimed at supporting IoT, AI/ML, and other emerging technologies through the cloud. Here there’s already cloud acceptance, and Amazon is working to frame their cloud services to facilitate development by ISVs in the key vertical areas. In some cases (connected vehicles, for example) they’re also addressing a related consumer-market opportunity.

Amazon, like others, is infatuated by private wireless, and there is a private wireless opportunity, but it’s one that takes some real effort to develop and is difficult to address at all except in a few verticals. My data says that Amazon’s customer base is only about half of Nokia’s base, and that its users are smaller as well. It’s interesting that they cite many of the same industries that Nokia does, including automotive/fleet/transportation and agriculture. Where Amazon is differentiated is in its ability to offer “managed private 5G” to SMBs as well as integrated operator/private 5G with partners in the CSP and MSP spaces. They work with integrators and radio vendors for the on-site deployments.

Integrated private wireless (IPW) seems to be Amazon’s main focus here, which I think is smart because it can support a broader set of missions and even a broader set of verticals than a pure private strategy. The partnering with CSPs and MSPs offers Amazon an entree into the telco space too, since most of the 5G elements and deployment and management tools are shared with Amazon’s telco service portfolio.

Not surprisingly, a lot of Amazon’s telecom story is dependent on third-party developers and hosted applications they build for verticals. Amazon has the largest developer community of the public cloud providers, and they also have a fairly well-articulated edge strategy that links with their core AWS services and APIs. That means that AWS can be bound tightly to on-prem edge elements (AWS Outposts).

Overall, Amazon is playing its cloud cards in the telco world, and all of their efforts are based on a fundamental truth, which is that in today’s market, “services” are international and telcos are constrained geographically. There is zero chance that telcos would deploy their own assets over their entire proposed service footprint because the cost of simply acquiring facilities would be crippling. The cloud is the obvious alternative, and it’s clear that Amazon is going to enhance the services AWS can offer (AWS Wavelength is an example) as well as exploit its base of developers and integrators.

Will that be enough, though? That’s the big question with Amazon’s telco strategy, and it’s a question Amazon probably can’t answer and may not even be able to influence. Amazon wins if operators, or at least MSPs, decide to build real higher-layer services on top of connectivity, services that may not require tight coupling with what’s below but could benefit from it. Amazon loses if operators stay with connection services, because truth be told there’s not much to be gained by the limited VNF hosting opportunities that don’t involve the data plane. For the data plane, white boxes are the cost-cutting (and feature-enhancing) answer.

That doesn’t mean that the Amazon telco initiatives aren’t important. Startups have been AWS bread and butter, and they’re in decline at least for now. Microsoft is doing better in the enterprise space, and will likely continue to do that. Google is still groping for a differentiating strategy, and for literally decades, operators have been more comfortable with Google as a partner than Amazon. If Google finds their feet, they’re more likely to take share from AWS than from Microsoft. But…and it’s a big “but”…if Amazon can be a bit less pedestrian in their thinking about the telcos, and work a bit harder to create a real opportunity for a JV, they could marginalize Google, and they’d then likely gain more from that than rival Microsoft. Think about it, Amazon.

Last week I was provided access to Google’s Bard chatbot, the ChatGPT competitor. I’ve had a chance to run it through its paces as I’ve done with ChatGPT, and I want to offer my view of Bard and what I think Bard could do. Let me say up front that I was impressed with Bard, more so than I was with ChatGPT.

Let me make a point that I’ll repeat later, because it’s important. I am not interested in whether Bard can make me believe it’s human, tell me jokes, entertain me, or whatever. I don’t propose to have it take tests for me, write articles, or send emails or text messages. I’m interested in whether it could play a role in my online research. I juggle a lot of numbers in my work, and finding them is often a chore. Can Bard make the job easier? If it can, then it presents a real value to me, and likely to other serious users of AI.

Here are three questions I asked Bard, and the response provided.

Question: Compare growth in US spending on information technology with US GDP growth.

Response: The US economy grew at an annual rate of 2.7% in the fourth quarter of 2022, while spending on information technology grew at an annual rate of 12.1%. This means that IT spending grew at more than four times the rate of GDP growth.

This trend has been continuing for several years. In 2021, IT spending grew at an annual rate of 8.3%, while GDP growth was 2.3%. And in 2020, IT spending grew at an annual rate of 10.7%, while GDP growth was -2.8%.

There are several reasons for this trend. First, businesses are increasingly using technology to improve their efficiency and productivity. Second, the COVID-19 pandemic has accelerated the adoption of remote work and virtual learning, which has led to increased IT spending. Third, the rise of artificial intelligence and machine learning is creating new opportunities for businesses to use technology to automate tasks and improve decision-making.

The continued growth in IT spending is a positive sign for the US economy. It indicates that businesses are investing in technology to grow their businesses, which could lead to increased hiring and economic growth. However, it is important to note that not all IT spending is created equal. Some IT spending is simply maintenance or upgrades, while other IT spending is more transformative, such as the development of new applications or the implementation of new technologies.

The growth in IT spending is also a sign of the changing nature of work. The rise of automation and artificial intelligence is leading to job displacement in some industries, but it is also creating new opportunities in others. Businesses that are able to adapt to these changes will be the ones that are most successful in the long run.

Question: Comment on the following: Back in the days when wireline telephony was pretty much the only pervasive network technology, we had perhaps sixteen thousand “edge” office locations in the US. Today, according to some information provided by the Wireless Infrastructure Association (WIA), the US has over 142 thousand towers, over 200 thousand “macrocell” sites, and almost half a million outdoor small cell nodes. Add that up and you get fifty times the number of access edge locations we had in the old wireline days, and that growth has some really important side effects.

One thing that’s really important is that fiber infrastructure deployment has decisively shifted toward the access network. It used to be that we used fiber primarily in aggregation missions, starting with those SONET rings and moving into the core of IP networks. Today, we deploy far more glass in the access network, and while fiber to the home isn’t universal and may never be, fiber close to the home is already a fact.

A second important thing is that mobile fiber backhaul is making it easier to create those close-to connections for FTTN. There’s already been pressure on operators to use fiber to home/business locations where demand density is locally high enough to pay back the pass costs. If you’re going to trench fiber to a node for mobile services, you could trench from there to a residential subdivision or a shopping mall at a lower cost, so more areas are open. You can also use mobile sites as FWA locations. As a result, wireline broadband for what would normally be classified as residential use is improving in reliability and capacity.

Response: The growth in the number of wireless infrastructure locations in the US has several important side effects. First, it has led to a decisive shift toward fiber infrastructure deployment in the access network. This is a positive development, as fiber is a much more reliable and capable medium than copper. Second, it has made it easier to create close-to connections for FTTN. This is also a positive development, as it will improve the quality of broadband service for many people. Finally, it has made FWA a more viable option. This is a positive development, as it will provide more choices for consumers and help to reduce the digital divide.

However, there are also some potential negative side effects of the growth in wireless infrastructure. First, it could lead to increased competition for spectrum. This could lead to higher prices for consumers and could also make it more difficult for new entrants to enter the market. Second, it could lead to an increase in the amount of electromagnetic radiation exposure. This could have negative health effects for some people. Finally, it could lead to an increase in the amount of light pollution. This could make it more difficult for people to see the stars at night.

Overall, the growth in wireless infrastructure in the US has both positive and negative side effects. It is important to weigh the pros and cons carefully before making decisions about whether or not to support this growth.

Question: What does CIMI Corporation’s public blog say about metro?

Response: CIMI Corporation’s public blog discusses the importance of the metro in the networking industry. It argues that the metro is the best place to introduce network service features, as it is close enough to the edge to permit real-time handling and personalization, but deep enough to serve the number of users needed to create reasonable economy of scale.

The blog also discusses the possibility of making metro-centricity a design mandate. This would involve defining a kind of “movement zone” around each metro center, with the goal of containing a large proportion of the users there within that zone as they travel locally. This would improve handling and latency, and would cover about three-quarters of the population that way.

Overall, CIMI Corporation’s public blog argues that the metro is a vital part of the networking industry, and that it should be a priority for network operators.

In one of my earlier blogs, I explored the question of whether AI could be a direct threat to humans. I decided to ask Bard the broad question, and this is what it replied.

Question: Could artificial intelligence develop to the point where it was a threat to humans?

Response: There is a possibility that artificial intelligence could develop to the point where it is a threat to humans. This could happen if AI systems become so intelligent that they are able to outsmart and outmaneuver humans, or if they become so powerful that they are able to take control of critical systems, such as power grids or nuclear weapons.

However, there are also many reasons to believe that AI will not become a threat to humans. For example, AI systems are still far from being as intelligent as humans, and it is likely that they will continue to be dependent on humans for many years to come. Additionally, there are many safeguards in place to prevent AI systems from becoming too powerful, such as the development of ethical guidelines for AI research and the creation of safety mechanisms for AI systems.

Overall, it is impossible to say for sure whether or not artificial intelligence will become a threat to humans. However, it is important to be aware of the risks and to take steps to mitigate them.

Question: Will AI need Asimov’s Three Laws of Robotics to protect us?

Response: It is not clear if AI will need Asimov’s Three Laws of Robotics to protect us. These laws are designed to ensure that AI systems do not harm humans, but they may not be sufficient to prevent all potential dangers. For example, an AI system that is programmed to obey the Three Laws of Robotics could still harm humans if it is hacked or if it makes a mistake.

Additionally, the Three Laws of Robotics may not be applicable to all types of AI systems. For example, an AI system that is designed to explore the universe may not need to obey the First Law of Robotics, as it would not be in a position to harm humans.

Ultimately, whether or not AI needs Asimov’s Three Laws of Robotics to protect us is a complex question that cannot be answered definitively. However, it is important to consider the risks posed by AI and to take steps to mitigate them.

I think that Bard did a pretty good job on these questions, and the fact that it raised the potential of a hack or mistake was in a real sense insightful. I also think that criticisms that Bard is “boring” compared to other chatbots trivializes the whole notion of AI. Does everything these days have to be entertaining? Can’t we find use for something in improving our productivity or enhancing our lives? Even a quick check of Bard’s capabilities demonstrated to me that I could find things in seconds using Bard that I might not be able to find at all with search. Some of the things I’ve tried to do searches on, in fact, produced no useful results even after ten or fifteen minutes of work, where Bard’s quick response was on the money. Yes, if I ask the wrong question I can get the wrong answer, but in most cases my error was obvious (or our difference in interpretation was) and easily corrected.

I am going to continue to use Bard for research, because Bard has proved to me that it’s useful in that role. I don’t need it to tell me jokes or sing me songs or pretend it’s my friend. I need it to do a job, a job that’s important to me, and so far it’s been able to do just that. If you want entertainment, try watching TV.

Back in the days when wireline telephony was pretty much the only pervasive network technology, we had perhaps sixteen thousand “edge” office locations in the US. Today, according to some information provided by the Wireless Infrastructure Association (WIA), the US has over 142 thousand towers, over 200 thousand “macrocell” sites, and almost half a million outdoor small cell nodes. Add that up and you get fifty times the number of access edge locations we had in the old wireline days, and that growth has some really important side effects.

One thing that’s really important is that fiber infrastructure deployment has decisively shifted toward the access network. It used to be that we used fiber primarily in aggregation missions, starting with those SONET rings and moving into the core of IP networks. Today, we deploy far more glass in the access network, and while fiber to the home isn’t universal and may never be, fiber close to the home is already a fact.

A second important thing is that mobile fiber backhaul is making it easier to create those close-to connections for FTTN. There’s already been pressure on operators to use fiber to home/business locations where demand density is locally high enough to pay back the pass costs. If you’re going to trench fiber to a node for mobile services, you could trench from there to a residential subdivision or a shopping mall at a lower cost, so more areas are open. You can also use mobile sites as FWA locations. As a result, wireline broadband for what would normally be classified as residential use is improving in reliability and capacity.

A third important thing is that we’re redefining “edge” in terms of access networking, at least, and raising the question of whether there will come a time when we could deploy service features and even edge computing outward beyond the current facility-based edge office sites. Probably, this won’t happen today or even next year, but we’re moving to a point where some features/functions might be hosted further out, providing we could make a business case for applications that depend on them.

One thing you probably see from my description of the side effects is that they’re “important” for what they might bring in turn, rather than what they are in detail. So what might they bring?

The most important result of these three edge points is that business-specific access is no longer a great opportunity for operators. Staying with the US market, the total number of multi-site businesses in the US is roughly 50,000 and these businesses have an average of about 32 satellite locations. Operators might have hoped to have over a million and a half prospective carrier Ethernet sites if everyone got on an IP VPN, but now we have to assume that at the minimum the primary market for carrier Ethernet would be the 50,000 main sites, and my data says that all but about ten thousand of these could easily be supported via the same fiber/PON connections used for residential broadband, just with different routing off the head end of the PON.

That, to me, means that operators have a dire choice to make almost immediately. Do they take steps now to condition residential-targeted fiber and FWA to support traditional MPLS VPN access, or do they accept that SD-WAN will eventually likely supplant MPLS VPNs completely and start deploying it instead? If they sit on their hands (a not-uncommon decision), they can expect to lose out to managed service providers or self-installed SD-WAN, or even to cloud-hosted SASE.

The second thing these three access-related points would do is to amplify what could be called uNode hosting opportunity over NFV hosting. Virtual functions in NFV were generally deployed in “cloud resource pools”, and when NFV ISG proof of concept trials looked at replacing CPE with VNFs, it rapidly reached the conclusion that you needed a generalized appliance to “host” something. Shift the mission from CPE to far-edge, and you get what I’m calling a “uNode”, a sort-of-white-box that’s designed to host small, agile, feature elements. I think that O-RAN already admits to the fact that you can’t expect the same sort of “function hosting” for the RAN as NFV had envisioned, and I think that we can expect to see the white box taking on new roles as it becomes the host de jure for far-edge feature elements.

The next of our access-related impacts is an increased interest in and value for “edge injection and interconnect”. We already know that “content injection” at the metro level (where it’s typically done today) results in traffic load congestion upstream toward the injection point. If we presume that many content experiences are real-time material, then we need to think about a better mechanism for distribution as that material increases. Some of this will likely be handled by my uNodes (creating another reason to have them at critical junction points in the access network), but some may also be handled by injecting things deeper in the access network. If we really see social-metaverse experiences develop, which eventually is likely, then that will likely require at least some interconnection of uNodes to adjacent metro centers to reduce latency.

Our final point is that access infrastructure changes will drive full convergence of mobile and wireline at the service level because of the increased harmony at the access infrastructure level. There have been operator-sponsored projects to address this for almost two decades (Project Icarus was one) but the unity of access infrastructure (and my uNodes!) will make it a lot easier. In fact, we can expect these points to create a full separation of access, transport, and services. That means continuity of calls, the Icarus goal, across wireline and wireless and even between devices you own, but it means a lot more.

These points reshape a lot of our industry, and it will also have to reshape regulatory policies and business models. Technically speaking, the Internet will become the universal dialtone for everything. All services, and I mean all services, will operate over the Internet and will thus become “OTT” services. That puts the infrastructure providers in a fatally compromised position, one that they can escape from only through some near-term effort to create a true service-over-the-Internet position for themselves, or by being rescued by regulators through settlements or subsidies.

Back in February, Juniper did a couple of blogs on Juniper announcements, opening a question of whether Juniper was getting ready for some major positioning changes. I noted that in this blog, and suggested that perhaps Juniper was making some major virtual-network changes, ones that could even end up impacting Juniper’s Cloud Metro story and positioning Juniper in the metro space in a decisive way. On March 17^th, they announced Apstra integration with their CN2 positioning, asking “Why are our data center and telco cloud customers so enthusiastic about the CN2 and Apstra integration?” Why? We’ll see.

Juniper’s blog post on this opens some points of interest for prospective metro applications. One thing that general function virtualization demands is the ability to host on pretty much anything, including VMs and bare metal. However, the optimum platform for most virtual functions would be containers, and the optimum orchestration strategy would be Kubernetes. CN2 supports that, and now Apstra can manage the switching fabrics in the data centers where mixed hosting options for virtual functions could be critical.

If you believe in service features, you believe in metro feature hosting. If you believe in edge computing, you believe in metro feature hosting. In fact, there’s not much new or exciting in either telecom or cloud computing that doesn’t absolutely depend on metro feature hosting, which is why I have a hard time understanding why vendors haven’t been all over it for years. Even given the fact that telcos are dragged kicking and screaming into anything, it seems, beyond tin cans and strings, it should be clear that somebody has to grab some arms and legs (and ear plugs) and start pulling. And all the drivers involve hosting, so data center integration with access and aggregation in one direction, and core connection in the other, mean metro is a big technology junction point.

Which is why I think Juniper may be getting more serious about it. Keep in mind that however much core-on-ramp or access aggregation goes on in the metro, it’s the feature injection piece that’s driving the bus, requirements-wise, and if you’re not going to build features you have to prep for unified hosting and management. I think Kubernetes and CN2 are two legs of an evolving metro stool, and the Nephio project is the third.

Let me quote the Nephio mission: “Nephio’s goal is to deliver carrier-grade, simple, open, Kubernetes-based cloud native intent automation and common automation templates that materially simplify the deployment and management of multi-vendor cloud infrastructure and network functions across large scale edge deployments. Nephio enables faster onboarding of network functions to production including provisioning of underlying cloud infrastructure with a true cloud native approach, and reduces costs of adoption of cloud and network infrastructure.” Juniper is a Nephio participant.

The point here is that Kubernetes is what makes the cloud go around. CN2 is what extends the cloud’s virtual networking to non-containerized, even non-cloud, server assets, and Nephio lets Kubernetes manage related network assets. The three combine to define the glue that ties all the various technologies in metro into a unified, manageable, entity. Not only for telcos, but for any public cloud providers or interconnects that want to play in function hosting and/or edge computing, which means pretty much all of the above.

All of this raises interesting opportunities, questions, and challenges, and not only for Juniper. As I noted in my referenced blog, Juniper has significant technology assets that could be highly relevant in the metro space. So do other vendors, most notably Nokia, who’s the topic of a blog I did earlier this week. Nokia hasn’t done much in the way of explicit metro positioning, but Nokia has a handle on the edge opportunity, and that’s driving the feature bus. Juniper has a position on the network side. The point is that if feature injection is the goal of metro, even Kubernetes-based operations is a long way down the stack from the features we’re trying to inject.

We’re really looking for a harmony of hosting and network to create a standard development platform and encourage feature production. That means that it’s not Nokia alone that could threaten Juniper’s potential metro evolution, so could other players not even in the networking space. While real threats would be solidified in a full set of “feature middleware”, there are intermediate things that could be done to both step toward that feature goal and provide some interim solutions to feature-hosting problems, in part by creating some unity between NaaS and PaaS. That’s particularly true if we generalize “feature hosting” to mean “edge computing”.

Tenant management in edge computing, and the related topic of tenant security, is way more critical than in the cloud. That’s because edge computing is really justified only for real-time applications, and real-time applications connect to the real world, where mischief could create a disaster of major proportions. That, I think, means that virtual network control is absolutely critical at the edge, and it has to meld the Kubernetes notion of virtual networks (which is the cloud/container view) and the network view. Unity, stroke one.

The next point is that we can’t have people writing edge apps for bare hosting, in large part because of that security point. Keep in mind, too, that security at the edge means more than keeping out bad actors, it means ensuring that Real Time A doesn’t somehow hog all the resources, bringing Real Times B and so forth to a grinding halt, even if it’s an accident and not malicious. Thus, we need middleware, and probably several perhaps-related-at-some-point middleware stacks. NFV hosting, if it evolves to become relevant, needs a specific middleware kit. Edge computing needs a middleware kit at the general level, with perhaps specialized stack top-offs for classes of applications. Some of this middleware will have to influence connectivity. Unity, stroke 2.

What’s important here is that none of our network vendor contenders has, as far as I know, any activities relating to the creation of this middleware, which would create both a NaaS and a PaaS element for the metro and its interconnected partner feature components. The question is then where thus stuff would come from, and there are three possibilities I can see.

First, some vendor in or out of the networking space could step forward with an architecture and and software prototype, and do the job. This would move things the fastest because a single hand on the reins moves the team best.

Second, some similarly constituted vendor could step forward with an architecture, and launch an open-source project to realize it. Juniper did something like this with IPsphere decades ago. This could also move things along quickly, but the risk is that open participation would lead to the inclusion of players who really wanted to interfere with rather than make project. Cisco was that player in IPsphere; maybe here too?

Third, somebody could launch a standards or standards-like initiative like Nephio or the NFV ISG. This would be the worst possible outcome because it would move at a glacial pace, satisfy nobody because it was trying to satisfy everybody, and stall any other initiatives with the same goal because nobody wants to step on a standards process.

If none of these options look likely, or at least look like they might be effective, what about non-network vendors who might jump in? The most obvious source of these new competitors would be the public cloud providers, and perhaps Google in particular given their connection to both Kubernetes and Nephio. VMware and Red Hat could also play from the software platform side. I’d rate the chances of a player in this non-network group stepping up as being slightly better than that of a network vendor stepping out of their usual comfort zone.

There is, of course a final implied possibility, which is that nobody does anything. Over the long haul, I think that would lead to a bunch of silo implementations that would fight it out and divert developer and other resources until all but one or two of them were killed off. That would take five or six years, and would delay full realization of the potential of metro, edge computing, and new and revenue-positive telco services. I hope somebody steps up, and I think that they will. I suspect that within a year, we’ll either see a potential answer to the problem of NaaS/PaaS unity at a higher level, or we’re in for a half-a-decade slog.

On March 16^th, I blogged about the question of what a cloud-native telco might look like, and obviously this had to address the evolution of things like NFV and 5G. The question I raised at the end of that blog was whether we had perhaps carried evolution too far in mobile networking and NFV, whether starting again from the top might lead us to a different place. Let’s look a bit harder at that one today.

A big piece of how mobile networks manage their critical property of mobility traces back quite a way. What we have today, in 4G and 5G in some form, is a strategy that connects per-device “tunnels” from the gateway point to the packet network (the Internet in most cases) to the cell site where the device is found. Packets are processed (in 5G, by the UPF) through a set of classification rules (Packet Detection Rules or PDRs in 5G), and the rules match the packet header (the IP address, tunnel headers, etc.) and apply handling policies. Every device has to have at least two rule sets, one for each direction of traffic. The implementation of these rules, handling policies, and routing based on the combination is normally associated with elements of the “user plane” of a mobile network.

You could justify having per-device PDRs, but how about per-device tunnels? A packet for any user, emerging from a gateway UPF representing the Internet, could “appear” in the right cell even if it shared the tunnel to that cell with hundreds of other packets from other users. Thus, we could cut down on the number of tunnels by having one tunnel per destination cell. Not only that, if we had detailed control over forwarding rules, we could simply forward the packet to its proper cell based on its own IP address. We could get more forwarding control, too, by thinking a bit about how the user plane of a mobile network would work.

In the 3GPP specifications, user-plane and control-plane elements are represented as boxes with interfaces, and in the past they’ve been implemented as real appliances. In an effort to open things up, recent standards evolution has described these elements as “virtual network functions” (VNFs) and presumed a hosted software instance implemented them. The suggestion about “microservices” or “cloud-native” network traffic handling likely comes out of this point.

Following the standards leads to the creation of mobile infrastructure that’s almost an adjunct to the IP network rather than a part of it. This mobile network touches the IP network in multiple places, and its goal is to allow a user roaming around through cell sites to be connected to the Internet through all this motion, retaining any sessions that were active. We have a completely separate set of “routers” with different routing policies to make this work.

Eliminating mobile-specific appliances in favor of hosted VNFs introduces cloud network overhead to the handling of mobile traffic, which seems at odds with the 5G goal of lowering latency and supporting edge computing for real-time applications. My suggestion, as described HERE and HERE [add references to the blogs, the latest being March 16^th], was to consider the control-plane implementation to be based on cloud-native and the user plane to be based on a “router with a sidecar” to add the capability of implementing the PDR-based handling 5G requires. I noted that something SDN-ish could work as the means of connecting sidecar element to the router.

There has been work done on supporting mobility management via “standard” devices, meaning either routers with some forwarding agility or white-box switches. SDN, as just noted, would offer a means of customizing forwarding behavior to include tunnel routing, and the SDN controller could act as an intermediary PDR controller. There has also been work done on using the chip-level driver language P4 to define mobile PDR handling. That would enable any device that supported P4 to be a PDR handler, though there would still be a need for “sidecar” control to implement the interface between the device and the 5G control plane.

If VNF-based handling of mobile traffic isn’t the optimum approach, it’s not the only thing that mobile standards lead to that could be sub-optimal. The problem with block diagrams in standards is that they are often difficult to connect with two real-world elements—the location where they might be deployed, and the patterns of traffic within the network overall. In my view, both these real-world elements converge into what I’ve been calling metro.

Metro to me is both a place and a traffic pattern. Network service features are most easily introduced at a point close enough to the edge to permit real-time handling and personalization, but deep enough to serve the number of users needed to create reasonable economy of scale. I submit that this place is the metro center or metro. As it happens, the notion of a metro center is already established because of the importance of content caching. The major CDN providers connect to broadband access networks at specific places, and these are probably the best early candidates for a metro site. That’s because video traffic is the great majority of Internet traffic, even mobile broadband traffic, and so there’s already great connectivity to these points, and a natural concentration of traffic. The majority of content cache sites are also places where real estate to house edge computing is available.

Mobile networks often implement a kind of implicit metro-centricity because it’s at least possible to differentiate between mobile users that remain within a metro area versus those that are roaming more broadly, with the former having direct IP addressing and the latter tunneling. Since most mobile users do tend to stay in a metro area, and since most video consumption on mobile devices involves those generally-in-metro users, traffic efficiency is often high because video traffic doesn’t need to be tunneled.

It might be possible, and valuable, to make metro-centricity a design mandate. If we were to define a kind of “movement zone” around each metro center, with the goal of containing a large proportion of the users there within that zone as they travel locally, we would improve handling and latency. We’d probably cover about three-quarters of the population that way, and over half the geographic area of the US, for example. For the rest of the population and geography we could expect users to be moving in and out of metros, and more tunneling would likely be needed.

Presuming population mobility was a challenge that had to be addressed in sustaining session relationships, we’d end up needing more tunneling because it would be very difficult to reconnect everything when a user moved out of a metro area and required a different mobile gateway to the Internet, or to cached content.

Edge computing and real-time digital twinning via 5G would exacerbate some of these issues, because interruption of message flows in real-time systems can have a catastrophic impact, and attempts to remedy that at the message-protocol level (requiring acknowledgments, buffering and reordering, etc.) would increase latency overall. If we were to assume that there were “social-metaverse” and other “cooperative” applications of edge computing that required broad edge-to-edge coordination, the need to optimize just what edge facility a given mobile user is connected with would increase. It’s also true that real-time edge applications would be likely based on microservices, and that could give impetus to attempts to create microservice-based mobile service elements overall.

I think that mobile standards, like NFV ISG work, have suffered from box fixation, making it difficult to assess how to implement them in a “cloud-native” way. I think that network standards in general have to balance between the optimized use of new technologies and the ability to evolve from existing infrastructure without fork-lifting everything at great cost. The problem is that this combination creates a barrier to motion and a limit to innovation at the same time. At some point, we need to think harder about going forward with network standards, and I think that starts by looking at features and not boxes.

When Nokia announced their “rebranding”, I blogged on it to cover their main points and to note that there’d better be something to it beyond a new logo. Shaun McCarthy, Nokia’s President of North America Sales, offered on LinkedIn to give me a briefing, and late last week we had our talk. It was, as you’ll see, insightful and useful.

The most important point Nokia made in their just-before-WMC announcement was their goal of expanding their enterprise business. While McCarthy reinforced Nokia’s commitment to the service provider space, he noted that the CSP market had a 1% CAGR, which isn’t the sort of thing you’d like from your primary market segment if you’re a vendor. In contrast, the enterprise sector has roughly a 9% CAGR, so expanding Nokia’s business there (currently 8% of their revenues) to their goal of 30% makes a lot of sense.

Finding high-growth market segments is good, but only if you can address them. I noted in that early blog that there was plenty of competition in the enterprise space, and that Nokia was going to have to fight to gain a respectable position. I also said that their private wireless push had only limited appeal among enterprises. My latest model run, in fact, said that the total private wireless and “hybrid” wireless (private combined with a public offering, which in 5G might mean a network slice) would amount to only about 8% of enterprise network spending. That’s not a great number, and I indicated that, to get to a 30% enterprise revenues level, they’d have to work out a strategy to increase enterprise revenues significantly over what private wireless can offer.

What I learned on my call is that they already have a strategy, and one that was not only working but had some pretty significant potential for success. We could call it “facilities automation”.

The overwhelming majority of IT spending today is directed at what could be called “office automation”. Workers who sit at computers and access applications in the cloud and data center make up this opportunity, and while this is the market that’s driven enterprise network spending too, it’s also a market that’s slipped largely into sustaining mode. That 30% expansion Nokia wants in their enterprise business would be a challenge in a market where incumbents were strong and growth was limited.

Neither of those are true in the facilities automation space. “Facilities” automation means the automation not of office work but of industrial/manufacturing and other core business processes, the stuff that creates and moves products and coordinates services. McCarthy calls this targeting “non-carpeted” areas. How much opportunity is there? According to my data, a lot. In fact, most of the opportunities that seem ripe for IT investment have more dirt on their floors than carpeting.

The most “empowerable” industries are those with the highest unit value of labor. In the entire spectrum of industries tracked by the government, there are only seven who have median unit values of labor in the “highly empowerable” category, and all but two are in those non-carpeted areas. The industry most represented is the energy sector, then various manufacturing sectors. As it happens, Nokia’s enterprise successes focus on these sectors already, and McCarthy mentioned the energy sector in our talk. And, also as it happens, these are the sectors most interested in private 5G.

The challenge in the facilities automation space is that it depends heavily on domain expertise. Office automation benefits from the fact that, well, an office is an office. Running a business is accounting, orders, shipments, and all sorts of stuff that doesn’t vary much across the verticals spectrum. Automating a factory or warehouse depends on knowing something about the way work is done, and influencing it as it’s being done rather than playing around with records of the money and order flows. Nokia has to depend more on partners, what could broadly be called “value-added resellers” or consulting firms that focus on the spaces you’re interested in. Their relationship with the Kendryl spinoff from IBM is a good example of how to get domain expertise, and the partner strategy has worked for Nokia so far, and will likely continue to create opportunities to fully realize private wireless potential.

Nokia wouldn’t sneeze at getting even 8% of enterprise network spending, according to McCarthy, but there may be more to that on the table if Nokia can work its way out of the private-5G space and into broader facilities automation and even into the service provider space. That may be possible because of the connection between private 5G, facilities automation, and edge computing.

Right now, over 95% of edge computing is done on-premises using customer-owned equipment. Private 5G is most useful as a better form of WiFi in manufacturing and related applications, and one reason for that is latency control and connection security for real-time process management running on these customer-owned edge devices. Having a foot in the private wireless door could thus open the larger door of IoT, edge computing, and real-time communications. It’s this secondary push that could represent the pathway to Nokia’s goal of having 30% of their revenue come from the enterprise. And it would be possible without having to face entrenched competitors in the office automation piece of the market.

Best of all, there’s another dimension to facilities automation, one that could be really significant. You can empower office workers in a bunch of ways, and that’s why we see a broad IT and network initiative aimed at them. However, office workers make up only about 30% of the workforce. The problem in getting to the 70% is that you can’t empower them with information, you have to empower them with automation. You have to step into the work itself and influence how it’s done in real time.

I continue to believe that the key to doing this is the digital twin concept. You can’t influence work without moving into real-time systems, and you can’t influence real-time systems without a digital twinning of the system to organize sensor data and to assess and take actions. McCarthy mentioned the “industrial metaverse” in our call, so they may be seeing this potential already, and seeing a role they could play there to boost enterprise sales.

While Nokia’s strategy for facilities automation is dependent on domain specialists at the sales execution and application level, all of the knowledge of the work has to be reflected eventually in implementations based on servers, platform software, and networks. There are major differences between how a farm and a nuclear power plant work, but if you dig downward toward and into the IT piece, you find middleware that’s creating the underpinning stuff like digital twinning and a metaverse concept based on it. One inclusive of the industrial metaverse but aimed at the broad facilities automation space. Nokia can’t develop custom software for every vertical, but they could develop middleware for a digital-twin metaverse that would support that custom vertical software.

And they could do it with open technology. When enterprises talk with me about Nokia (which is less often than they talk about Cisco or Juniper), the technical differentiator they see most often is “openness”, which surely comes from Nokia’s open-RAN 5G position, which has gotten them a lot of ink and is often cited as the reason they’re doing better in the service provider space than competitors. Could Nokia create an open-model digital-twin process? Sure. Would they, given that vendors typically try to lock up customers not open them up? That’s a question we’ll have to wait to answer.

Another of those “wait-for-it” questions is in the positioning and marketing. If you are a company who necessarily focuses your revenue-generating initiatives through partners, it’s easy to lose your identity. Truth be told, players like Kendryl aren’t going to work with Nokia alone. Suppose a Nokia partner decides to build something like digital-twin middleware? Facilities automation is a stack of function-to-IT mappings, and you can standardize that stack by starting at the top or at the bottom. Sure, open middleware for digital twinning is a risk, but is it a greater risk than just being made invisible by higher-level players? It might present a benefit, something you could market to become visible, and to set up the belief that the evolution you offer to facilities-based automation is critically valuable. It might also be something that service providers could use to create 5G edge applications, and that would then be a win for Nokia on the service provider side as well.

All this adds up to a real opportunity for Nokia, and even a value for private 5G, as long as you don’t expect it to carry all the revenue-gain water by itself. Exploiting the full opportunity could mean that Nokia’s “rebranding” is really a whole new initiative that could realize their enterprise goals and boost their service provider position too…providing they can get the word out.

I think Nokia’s position in facilities automation is strong, and that it will boost their enterprise sales and justify their new “branding” or strategic initiative. I think there’s a chance that it could be great, and give Nokia a lead position with edge computing and digital twinning for facility automation. Part of that will depend on whether Nokia evolves the capability, but perhaps a bigger part will depend on whether they can get aggressive with their positioning/marketing. Facilities automation needs buy-in from a lot of stakeholders, particularly ones in line organizations that Nokia couldn’t expect to call on even if they had a sales force big enough. Only marketing can reach everyone, and get them onboard, and that’s essential if the full scope of this opportunity is to be realized.

They say that beneath every fable, lie, and marketing message there lies a kernel of truth. Is that statement a self-proof or does it give too much credit to falsehood? I can’t assess that, and probably don’t need to, but I do think I could try to apply it to a question I got on a blog I referenced on LinkedIn. Paraphrasing, the question was whether there was a role that cloud-hosted, cloud-native, microservice-based technology could play in telecom. Well, is there? Not surprisingly, the answer is “Yes, but….”

We have to start with an attempt to categorize what “cloud hosting” and “cloud-native” mean, and in particular how they differ. There are really three models of cloud hosting; IaaS virtual machines, containers, and functions/microservices. I’ve presented them in order of their “closeness” to the real hardware, so it would be fair to say that the progression I offered represents increasing overhead that could be expected to be added to message processing.

We also have to ask what “a role” would mean. It doesn’t make a lot of sense to stick a hosted router instance somewhere in a network and call it a transformation. What operators generally want is a broadly useful strategy, one that can replace enough specialized (vendor-specific, proprietary, expensive) devices with cheap hosted instances to make a difference in capex overall. That puts a lot of pressure on the hardware, hardware that’s designed to host applications and not push bits.

Whatever the model, nearly all “cloud hosting” is based on general-purpose CPUs (x86, ARM), and we wouldn’t have switching chips from players like Broadcom as the basis for white-box network devices if general-purpose CPUs were up to the job. It is possible to use general-purpose servers, in or out of the cloud, to host router instances, but operators aren’t all that excited about the idea.

About a decade ago, I had a long meeting with a Tier One operator about reducing capex. Their hope was that router software (remember Vyatta?) running on servers could replace routers, and they bought licenses to test that idea out. What they found was that it was possible to host what were essentially edge router instances on servers, but anything that had to carry transit traffic (metro or core) needed special hardware.

It wasn’t long after that when the NFV “Call for Action” was published and the NFV ISG was launched. From the first, the emphasis was on “appliances” more than on network routers and switches, and many of the early PoCs focused on virtualizing and hosting what were normally CPE functions, like firewalls. This dodged a lot of the performance problem, but even those PoCs ended up turning to a non-cloud hosting model, that of “universal CPE” or uCPE. NFV’s mission there was simply to load software onto an edge device, which frankly made all the standards work overkill. Would this have happened if virtualizing CPE, which was well within server limits, was really transformational? I don’t think so.

Where does this leave the cloud router? Answer: If by cloud router you mean “hosted in the cloud” router, nowhere. There is only one viable “cloud router” in all the world, and it’s DriveNets’ Network Cloud cluster of white boxes, which don’t rely on general-purpose servers in any form. Public-cloud routing is not cost- or performance-effective. Neither, in most cases, are any server-hosted routers. The only operators who haven’t rejected the hosted-in-the-cloud approach are those who haven’t tested it seriously.

So what does this mean for all the talk about “cloud-native”? I blogged about an article that, referencing an analyst report, predicted operators would move nearly half their network traffic to a “cloud-native” hosted framework. I said that there were zero operators telling me anything like that, but I didn’t go too much into the “why” of it. The answer is that issue of cost/performance effectiveness.

But there’s a deeper question, too, one I referenced HERE. The 3GPP 5G work, and the successor expansion of O-RAN, included the notion of hosting VNFs that handled both the “user plane” and the “control plane” of a 5G network. The standards separate those two planes, but the way the features/functions are divided makes the “user plane” of 5G different from a pure IP transport network, the “data plane”. I speculated that the best way to approach the requirements of the UPF might be to think of them as a functional extension to traditional routing. But what about the control plane? That’s the deeper question.

The control plane of a mobile network is largely aimed at managing registration of devices and managing mobility of those devices. Like an IP network’s control plane (yeah, 3GPP reused a term here and that can create some confusion), the control plane of 5G doesn’t carry traffic but rather carries signaling, and signaling is a whole different world in terms of cloud and cloud-native.

5G signaling is made up of internal messages to support the management of mobile networks. A 5G user sitting in a cafe in NYC watching a 4K video could be pushing a lot of bits but generating essentially zero signaling activity, because they’re in the same cell through the entire experience, and once the path to that user in that cell is established, there’s nothing much going on to require a lot of signal exchanges, at least not exchanges that impact 5G service elements (RAN-level messages might be exchanged). No registration, no mobility management. Thus, signaling message traffic is surely way lower than user data traffic, and that means it’s probably well within levels that cloud elements could handle.

In theory, if 5G signaling is a good application for cloud hosting, we could expect to use any of the three hosting models I cited. However, the way that the 5G standards are written creates “functional boxes” that have “functional interfaces” just as real devices would. That seems to favor the use of virtual devices, which in turn would favor hosting in either VM or container form. You could easily write software to play the role of a 5G signaling element and stick it in a VM or container in the cloud (or, of course, in a data center or other resource pool).

What about “cloud-native”. We can now turn to defining it, and the most-accepted (though not universally accepted) definition is that “cloud-native” means “built on microservices”, and “microservices” are stateless nubbins of functionality. It also means, or should mean, the more general “designed to optimally realize cloud benefits”. The question, IMHO, is whether it would be possible to meet both definitions with a 5G signaling application. The answer is “Not if you strictly conform to the 3GPP/O-RAN model”.

This is the same problem that the NFV ISG created for itself a decade ago, with their release of a functional specification. Defining functions as virtual devices steers implementations relentlessly toward that model, and that model is not cloud-native. I did a presentation for the NFV ISG that described a cloud-native implementation, and what it showed was a pool of primitive functions that could be individually invoked, not a collection of virtual devices. The assignment of functions to virtual devices converts cloud-native into a kind of monolith.

In the cloud-native model, the signal messages would be routed to the primitive function (the microservice) designed to handle them. Since microservices are stateless, the presumption would be that (for example) a mobile device would have a “record” associated with it, wherein we stored its state relative to the mobile service. That state record would be accessed by a “master” signal-message microservice to determine where the message would be steered, so we could say that it would contain a state/event table. There might be any number of instances of any or all of the signal-message microservices, and steering to the right one would likely be done through a service mesh. It’s also possible that signal messages would carry state, and thus would be steered only by the service mesh.

The next obvious question would be how this would tie to the “user plane” where there was a signaling-to-user-plane interplay, like for the UPFs in 5G. This is where you’d need a mechanism for a signal microservice to send a message to a “router sidecar” function that could induce data plane behavior. For example (and only as an example), we could assume that the “router” was an SDN switch and the “router sidecar” that was messaged from the signaling plane microservice was the SDN controller.

My point here is that so far, all the work that telco standards groups have done has pushed features into virtual boxes, thus moving them away from being “cloud-native”. If cloud-native is the preferred model for the cloud, that’s a very bad thing. But even for non-communications applications, cloud-native isn’t always a good idea because all the inter-microservice messages add latency and likely add hosting costs as well. It is very possible that virtual devices would be cheaper to deploy in either public cloud or carrier cloud resource pools, and would function better as well, with lower latency. Frankly, I think that’s very likely to be true for 5G control plane features. That, in turn, would mean that we shouldn’t be talking about “cloud-native” as a presumptive goal for everything involved in telecom-in-the-cloud.

A “cloud” is a resource pool, and while a public cloud today is based on x86 or ARM because that’s where the demand is, there’s no reason why we couldn’t build clouds from any resource, including white boxes. One of the interesting points/questions is whether we could build a hybrid white-box cloud by linking an open data plane to a cloud-native control plane via a user plane that could induce UPF behavior from white-box devices. Another is whether the way to harmonize a virtual device and cloud-native is to say that virtual devices are made up of cloud-native elements that are tightly coupled and so can function as a single element. Maybe we need to think a bit more about what “carrier cloud” really means, if we want to get “cloud-native” right there.

The biggest question of all, IMHO, is whether we should be thinking about re-thinking. Is the old 4G LTE Evolved Packet Core tunnel mechanism even the optimum “user plane” model? We’ve evolved both technology and missions for mobile networks. Maybe, with some thought, we could do better, and that’s a topic I’ll look at in a later blog.

Given the fact that most experts recognize that 5G was over-hyped and is very unlikely to measure up to expectations for either its providers or its users, it’s no surprise that there’s interest in pushing its successor. At MWC there was a session on 6G, and this article described some of the views expressed. It’s worthwhile to take a look at the 6G situation, if for no other reason to lay out what we really need to be doing if we’re to create a useful next-gen mobile wireless technology.

The most insightful thing in the piece is the comment that “The projections are that the likes of you and I will only get 6G into our hot little hands from around 2030 onwards.” A Wikipedia article on 6G notes that “as of January 2023, there is no universally-accepted government or non-government standard for what qualifies as 6G technology.” Given that there was industry activity (the Alliance for Telecommunications Industry Solutions or ATIS) back in 2020, and that there’s almost a quarter-billion hits on “6G” on Google search, it seems that as we did with 5G, we’re getting the cart before the horse with 6G.

The article mentions some of the early-hype expectations: “100 times the capacity of 5G, with sub-millisecond latencies” The panel at MWC also talked about energy efficiency, more deployment scenarios including IoT and edge computing, better security, convergence of satellite and terrestrial networks, resilience, applications of AR/VR, better reception of cell signals in areas like tunnels and elevators, manufacturing robots, 3G mapping, metaverse, and so forth. If you combine these expectations with the reality points in the paragraph before, you can already see some interesting disconnects.

The most obvious problem is the classic “6G is a UFO” problem. It’s not landing in your yard for inspection, so you can assign it any properties you like. If we don’t have any agreed-on technology for 6G at this point, how do we know it will be a hundred times as fast as 5G? Can 6G radio waves travel faster than 5G or 4G? Obviously not, so how would 6G alone create sub-millisecond latency?

The next thing that should, at least, be obvious is that a lot of what we’re saying will come along through 6G was stuff we also promised with 5G, and clearly have not yet delivered. Why? Because a lot of things we promise for wireless standards are things that wireless standards can limit, but cannot create by themselves. In other words, what many standards (including 5G and the rational proposals on 6G) for wireless are doing is advancing communications so that it would not limit applications being contemplated, though not yet available. Will all the other barriers to those applications fall? We don’t know.

Those who’ve read my blogs know I’ve been pointing out that in order for many of the things we think 5G would enable to actually happen, we’d need an entire tech ecosystem to build up all the pieces. Edge computing, for example, doesn’t depend on 5G, it depends first and foremost on applications that drive enough value for the user and profit for the provider to create a business. That depends on broadening “provider” to mean not only the service provider, but the providers of critical facilitating technology to the service provider.

So what we’re saying here is that 6G is really aimed at advancing wireless communications so that it wouldn’t limit the growth of these new applications, not so that these new applications will suddenly burst on the scene. In order for the latter thing to happen, we’d have to see the entire application ecosystems emerge. The truth is that the real war for a rational next-gen wireless standard won’t be fought at the network level at all, it will be fought at the application software level. Maybe even more fundamentally, at the application targeting level, because what’s needed is some initiatives to determine where the application of things like low-latency computing could provide monetizable value.

Does this mean 5G and 6G are then so suppositional as to be essentially useless? No, surely not for 5G and very likely impossible for 6G as well. Why? Because there were, and will be, some learned and justified wireless service requirements mixed in with all the suppositional stuff. 5G hype said that it would increase user bandwidth by roughly ten to twenty times versus 4G LTE, and that it would increase total number of connected devices supported by ten times. The former, hasn’t proved to be true, and in any case there’s little you can do with a mobile device to exploit the higher theoretical speed. The latter is a significant benefit in controlling network costs, and thus service prices. We can expect that there will be 6G features that enhance the network’s economics and help build new business cases, but also things that will happen as a sort of insurance policy to protect the ability to support stuff we’ve not yet really thought of.

There’s a limit to be considered, though, even with respect to something like data capacity. Generally speaking, the amount of information (data) a wireless signal can carry is proportional to its frequency. To carry more, you have to use higher frequencies, which is why millimeter-wave signals can carry more data. The problem is that as frequencies go up, the radio network starts working more like radar, bouncing off things instead of going through them. That means that obstructions block the signals, and if you go high enough in frequency, even trees are a barrier. Some of the 6G hype, talking about terabit bandwidth, can be achieved only by raising frequencies to the point where they’d fail to penetrate almost anything, making them useless for practical cellular networks.

Why then are we having so many 6G discussions? Because “news” means “novelty”, not “truth.” Every tech publication, including this blog, has to consider the regular and awful question “What do we write about now?” There’s just so much that can be said about a given topic before it’s not “novel” and thus not “news”. More significantly, before people stop reading the stories, stop getting served the ads, and stop indirectly paying the sources. Not only that, there’s probably a thousand readers who might be interested in a claim of greater capacity, and almost none would want to read a story on mobile modulation.

The biggest problem with all of this is that it obscures the real, and useful, mission of keeping network and cellular standards ahead of the applications that would be connected. Absent some attention to the network issues, the network could be a barrier to investment in the very ecosystemic elements it depends on for long-term growth. Maybe we really do need 6G, a rational 6G. Whether we’ll get that may mean waiting until 2030 to see what emerges, I guess.