Month: January 2023

What, exactly, is the potential for edge computing? It seems to me that we’re seeing more of a need for the “what-is-the-potential” or “what’s-the-justification” sort of pieces every week. Most of that, I think, is generated because there’s an endless appetite for exciting things, and less so for true things. The problem is that excitement doesn’t translate directly into technology opportunities. Is there any opportunity for edge computing?

The popular themes on edge computing make points like “the edge will be much bigger than (or will replace) the cloud” and “business applications need very low latency to be effective.” We even have “the edge is eating the Internet.” None of these points are valid, but for the first two, we could make similar statements that would be true, so maybe the best way to open this is to contrast the stuff that’s not real with that which is.

The size of the edge opportunity is a good place to start an edge discussion. Edge computing is the subset of cloud computing that deals with a need for exceptionally short control loops, largely because of real-time, IoT-like, applications. There are many such applications today, but they are realized using “edge” facilities on the users’ premises. There is IMHO no reason to believe that these current edge applications would move to a public edge computing model, any more than there is to believe that everything is moving to the cloud. I don’t know any serious application architect who believes otherwise.

So how much of an opportunity is there? Today, it’s in the noise level. However, I’ve been saying for a decade that there is a class of new application, a new model of applications, that I’ve called “contextual services”, and this new class could generate significant incremental revenue in both the business and consumer space. If that new class of application were to be deployed optimally in both spaces, it could justify the deployment of about a hundred thousand new edge data centers. The great majority of them would be “micropools” of resources, though, comprising a couple racks of servers. In terms of real edge hosting revenue, the potential of these pools would be roughly three-quarters of what I believe the total revenue potential for cloud computing would be.

If close to the user is a justification for the edge, because latency is a barrier to an application, then with the user is better than any other place you could put edge resources. Today, industrial, warehouse, and process control edge applications run (according to enterprises) an average of 450 feet from what they’re controlling. Ten miles of latency is what you might expect, optimistically, for the distance to a reasonably efficient public edge pool, and that’s almost one hundred twenty times as far.

Couldn’t you run today’s cloud applications at the edge, though? Isn’t that a reason for edge computing to displace cloud computing? Yes you could, but no it isn’t. The problem is that edge computing economies of scale are limited by the relatively small population that are close enough to an edge point to justify using it. Micropool, remember? Public cloud computing offers better operations and capital economies than you could enjoy at the edge.

But what about the benefit of low latency to those cloud applications? Human reaction time is around 300 ms, which is 6 times the round-trip delay associated with transcontinental fiber transport of information. So let me get this straight. You want to deploy thousands of edge data centers to reduce transport delay that’s already a sixth of human reaction time? At the least, it would be cheaper to improve the connection from the users’ access network to the cloud.

That raises the second point, which is that business applications only work with low latency. Well, we’ve built a multi-trillion-dollar online economy on much higher latency. Transactional applications work at a global scale today without edge computing. We can take orders, support content delivery, and manage businesses with applications that haul data all the way back to a corporate data center from anywhere in the world. How much latency do you suppose that involves?

So, you might be thinking, that’s it for edge computing. Not so. As I said, you could modify the statements I opened with to create new ones that could well be true.

“The edge will be bigger than the cloud”, for example, could become “The potential growth in edge computing revenue is bigger than the potential growth in cloud computing revenue”. That’s true. “Business applications require very low latency to be effective” becomes “New applications that would transform business productivity require very low latency to be effective”. That’s also true, and the combination of those truths is what either justifies the edge or proves an impossible barrier for it to scale.

Why is low latency important for an application? The answer is that the application has to be synchronized with real-world activity, both in terms of sensing it and in terms of controlling it. There is no other meaningful application for low latency. Why can’t that be achieved with local processing? Answer: Because available local process points cannot do the job. When would that be true? Answer: When users are highly distributed and users are mobile.

What I’ve called “contextual services” are information services targeted to users moving around in the real world, wanting computing/information support for their activities there, delivered automatically in response to a service knowledge of what the users are trying to do. The only credible conduit for the delivery of a contextual service is a smartphone (perhaps married to a smart watch), which clearly can’t host a lot of application logic.

Contextual services require an “agent” process that runs in the edge/cloud and collects stuff for delivery, as well as interpreting contextual information either received from the user’s phone or is inferred from user searches, calls, texts, location, and so forth. To be relevant, it has to be able to absorb context from the user (directly or indirectly) and deliver insights that are real-time relevant.

So isn’t this a business application that demands low latency? Yes, but it’s not a current application, or even a justification for an application that could be considered validated by demonstrated opportunity and supported by available technology. Contextual services are created from an ecosystem, no element of which is currently in place. To say that they validate the edge makes too many presumptions, even for someone like me whose modeling has predicted that the market would be justified by the mission. We need to see more of the contextual services model before we can start using it to justify edge deployment, or claim it could rival the cloud.

I object to the kinds of statements I’ve opened with, because not only are they not currently true at all, but also because what’s needed to make them sort-of-true is a long way from happening. And, sadly, the statements could hurt the evolution of the real opportunity by promoting the idea that a mountain of real work doesn’t lie ahead, when it does. It will stay a mountain if we never get started because we think we’ve already climbed it.

It’s tempting to attribute the growing interest in capex reduction among network operators to the current economic malaise. The problem is that the push to buy less gear, or at least spend less on it, has been around for well over a decade. The recent interest in capex plans by AT&T and Verizon, then, are investor reflections of an old problem, one that investors can’t solve themselves, and that capex reduction may not be able to solve either. And there are new problems to confront too.

Over the long haul, operators have typically spent about twenty cents of every dollar on capex, but the current trend is slowly downward. My 2022 data says that the industry was targeting a bit more than 19 cents per revenue dollar for 2023, which doesn’t sound like a lot but which is alarming many of the vendors who depend on network operator spending for a big chunk of their revenue.

The reason for the dip is what can be only described as an alarming negative trend in return on infrastructure, most of which can be attributed ironically to the most successful network venture of all time, the Internet. Broadband Internet has transformed our lives and the fortunes of operators, largely because it enabled the development of a host of new applications that operators have largely been unable to profit from. Yes, many will claim that regulatory limitations kept them from getting into these areas, but even without the barriers, operators have largely been unable to make a go of higher-level services, including content. Orange recently announced it was selling off its content unit, one of the pioneer ventures in the space for telcos, and AT&T’s retreat from the TV business is well-known.

When you ask operators why they’re under pressure in 2023, the most common response is that “5G didn’t generate the expected bump in revenue”, and while there’s some truth in the answer, it’s the truth behind it that really matters.

Historically, users have tended to spend a fixed portion of their disposable income on communications services. While 5G offers clear benefits to a telco in terms of capacity per cell, the value of its supposedly higher speed turns out to be hard to see from the perspective of the 5G consumer. Yes, mobile downloads might go a bit faster with 5G, but with phone storage limited and the value of downloaded files on a small device at least as limited, most users didn’t find much to sing about. That meant that there was no appetite for higher 5G charges.

The question is why operators didn’t see this, and continue to miss more subtle 5G benefit shortfalls like the value of network slicing and 5G Core. There’s no question that a big part of the problem is that an industry that has thrived for over a century on supply-side thinking doesn’t get a strong handle on consumerism. There’s no question that self-delusion is another part of the story, and all technology companies tend to push new technology stories if they think it will help them with Wall Street. And yes, the media plays a role by playing up sensational stories about what something like 5G will do, on the grounds that the truth is rarely exciting enough to generate clicks. But every single network operator I’ve chatted with has senior planners who are frustrated by what they see as clear failures to exploit opportunities.

The cloud is a good example. Verizon bought Terremark in 2011, which gave it an early foot in the door of what’s arguably the most important technology sector of the decade, then sold it off six years later to IBM. While IBM hasn’t set the cloud world on fire, they’ve certainly earned a place for themselves in recent years, so why couldn’t Verizon do the same? Sure, telcos are conservative companies, but who ever said IBM was anything but conservative? Verizon also sold off its data centers to Equinix, which got them out of another aspect of the cloud business that’s now hot on Wall Street.

Is there something fundamental here? Some reason why the network operators have difficulties with anything but same-old-same-old? Maybe. Some have suggested that since they were late into the cloud, they couldn’t compete with other providers on economy of scale, but as I’ve pointed out, economy of hosting follows an Erlang curve, so it doesn’t improve continuously as the size of the pool grows. I think the problem is a different kind of economy, economy of scope.

Network operators have the great majority of their staff and real estate concentrated in their home market areas. If you live in the northeast US, you’re probably only a few miles from some Verizon facility, and same for AT&T if you live in California. You need buildings to house cloud resource pools and staff to operate them. A credible cloud offering has to be at least national, and increasingly multinational in scope. In order to make a real entry into the cloud market, an operator would have to either spread out beyond its own staff-and-facilities border (at great cost) or “federate” with other operators, something like was done in telecommunications through interconnection. This doesn’t just impact the cloud, either. It’s hard to think of a “higher-layer” service that isn’t built on hosted software features, which of course require something to host them on.

Federation to support higher-layer features was actually one of the goals of the IPsphere Forum (IPSF), a body I was heavily involved in over a decade ago. Little has been done since then, and even in the public cloud space you don’t see much interest in federation for the same reason that it’s not all that hot among operators; big operators don’t want to enable more competition.

Because mobile services have a much broader footprint than traditional wireline, it’s tempting to ignore the issue of footprint when talking about creating resource pools, but I don’t think that’s a valid connection. Things like tower-sharing have been in place to reduce the cost of extending mobile infrastructure, and few operators have deployed significant incremental facilities to support out-of-region mobile operations. In any event, mobile services are not feature-differentiated; operators are either vying for price leadership, total coverage, or the best phone deals. Mobile experience, then, isn’t contributing to operator literacy.

Mobile isn’t contributing to profit relief, either. 5G, in my view, may turn out to be more of a curse for operators than the blessing they’d hoped for. They had to increase capex to deploy it, and yet it hasn’t opened new market areas as they’d hoped it would. How much of the current capex crunch started with that low-return 5G investment, an investment that looks increasingly unlikely to yield any meaningful incremental return?

Operators need to be thinking about all of this, because as I noted in a blog earlier this week, the cloud is encroaching on the whole model of “higher-layer” services, to the point where network as a service may end up being a cloud application and not a network service in the sense that operators offer it. If that happens, then getting out of the profit basement may be very difficult for operators indeed.

Will this, as an SDxCentral article suggests, be the year of NaaS? I think somebody has suggested that every year for the last five years or so was going to be just that, so it might be interesting to look at why we’ve not achieved NaaS so far, starting with an inability to define what it is or what its value proposition might be. NaaS, of course, stands for “network as a service”, and one thing the article does is outline an actual driver for the concept, a driver that takes a step toward developing a definition. It also ends up introducing a question, which is whether NaaS has already snuck up on us, from an unexpected direction.

One of the problems with NaaS is that most network services are as-a-service models already. Look at MPLS VPNs, which frame what used to be private networks built from digital trunks and routers into a service that replaces all that interior plumbing. The article notes that “NaaS replaces legacy network architecture like hardware-based VPNs and MPLS connections or on-premises networking appliances like firewalls and load balancers. Enterprises use NaaS to operate and control a network without needing to purchase, own, or maintain network infrastructure.” That could be interpreted two ways. First, NaaS extends the VPN concept to network-related on-prem technologies like firewalls and load balancers, so it’s more comprehensive. Second, NaaS allows users to expense their networks rather than build them with capital equipment.

Companies like Cisco tried to offer that second option by “selling” equipment via an expensed service, so the architecture of the network didn’t really change but the way it was paid for did. Some companies like this approach, but it’s not been a stirring success, and it’s not accepted as NaaS by the majority of enterprises. Thus, it’s the first NaaS interpretation that seems to matter.

The reason for that is the increased mobility of workers. Work-from-home during the lockdown not only created an almost-instant need to empower people who were in places that fixed network connections didn’t serve, but also convinced many workers of the lifestyle benefits of out-of-office work. That meant that somehow these workers had to be connected effectively and securely. And since mobile workers are mobile, the mechanisms of NaaS would have to be agile enough to respond to changes in worker location. Arguably, they should also be elastic in terms of capacity and other SLA attributes too.

The basic notion of NaaS as presented in the article is that NaaS would absorb into the network the edge elements that today are on-premises. If you think about this model, it’s hard not to see it as either an implementation of an old idea or the target of a new technology that’s not really considered network technology at all.

The old idea is network functions virtualization, NFV. If you’re going to eliminate on-prem capital equipment it makes zero sense to install the same gear in an operator location; you’d have to charge more for NaaS if you couldn’t deliver any technology efficiencies to cover operator profit margins. Thus, the assumption is that you would host virtual forms of those previously premises devices, which is what NFV was all about.

The interesting thing, though, is that since its inception in 2012, NFV has evolved toward the “universal CPE” or uCPE model, which relied on a premises device to serve as a kind of agile hosting point for service features. This doesn’t address the problem of mobile workers, but uCPE isn’t mandatory for NFV, just a focus of convenience. The question is whether NFV is really the right approach to NaaS, given that it’s not exactly swept the market over the last decade.

That’s particularly true when you consider that new technology I mentioned, which is the cloud.

Companies have been adopting cloud computing to create “portals” for prospects and customers, front-end elements to their legacy applications. Since prospects and customers can hardly be expected to install specialized hardware on their premises, and since companies are unlikely to pay to do that for them, this portal model demands that the business network ride on a universally available service, the Internet, and that the cloud provide things like security and even VPN access. During the lockdown-and-WFH period, companies started to play with the idea of using the same strategy for worker access.

Cloud tools like SASE and SSE are examples of the absorption of network features into the cloud. The fact is that we’ve been developing what the article defines as NaaS as an element of cloud hosting. Public cloud providers are, in effect, doing the absorbing of those additional on-prem devices, and as I’ve noted in other blogs, the “cloud network” is increasingly a full implementation of NaaS.

So what we seem to have here is a realization of NaaS that’s not due this year, but has already happened. If you look at the pace of cloud adoption of network security and VPN features, we could argue that 2022 was actually the “Year of NaaS”.

This raises the question of whether we’re seeing perhaps the ultimate form of “disintermediation”, where network operators find themselves excluded from a potentially profitable service set. Through 2022, almost three-quarters of operators told me they believed NaaS was a logical extension of their current service set that could raise revenues. I think they were correct, but I also think that operators sat on the sidelines as the NaaS concept was implemented downward from the application side.

Ultimately, networks connect stuff, they don’t create stuff, and it’s the “stuff” that businesses and people want. With the advent of the Internet, we saw a fundamental shift in the mission of networks. In the past, it facilitated connection, presuming that what it connected took care of the “stuff”. When the Internet came along, it bundled connection and experience, network and “stuff”. The cloud built on that. But operators didn’t recognize the importance of the Internet transformation, other than to bemoan its “disintermediating” operators from higher-value services. All the factors that could have driven us to “smart” networks if operators had recognized conditions, drove us instead to consign advanced network features to that “stuff” category, a category operators had already lost.

The cloud is an external-to-the-network resource. The Internet represents universal connectivity. Combine the two, which has already happened, and you get what’s arguably the most logical, efficient, and ubiquitous platform for delivering NaaS. This means that operators disintermediated themselves, and failed to realize a fundamental truth about the supply-side, build-it-and-they-will-come nature of telco planning. You have to build it, or they will come to someone who does.

I’ve done a couple of recent blogs on the elements of “contextual” services, and drawn on driving and walking as examples of places where they could be applied. This can, I learned, lead to intermingling the notion of “contextual” with another term, “autonomous”, and I want to clarify the separation.

“Autonomous” is a popular term these days, and it’s usually related to what might also be called “artificial intelligence”, but with a more specific focus. “Autonomous” seems to mean “the ability to do things in the real world without direct human control, but presuming some supervision and intervention.” We have relatively little high-level material available on the topic, even though one form of it (robotics) has been around for decades. I actually diddled around with robotics then, and since then, and I want to offer my own views of the subject of “autonomy” and how it probably needs to be implemented. I also want to tie it to artificial intelligence and even metaverse concepts.

To me, an autonomous-something starts with the presumption that there exists a “something” that’s controlled directly by humans. That’s obviously true of autonomous vehicles, for example, and from the first I’ve believed that the best way to address the design of something autonomous is to start with the human-controlled version, and with how human control works at a fundamental level. This latter thing can be understood best by looking at the ultimate human-controlled thing, the human.

When I started looking at this problem in the 1990s, it was my view that we could divide our “control system” into three layers. At the top was the mission layer, which represents the overall goal. “I’m driving to Cleveland” is an example of a mission. Next was the action layer, which determined what to do when the mission interacted with the perceptive process layer that paralleled and fed all three layers. “I’m turning on to the Pennsylvania Turnpike” is an example of an action. The final layer, also linked to the perceptive process layer, is the reaction layer, which represents imperative overrides of mission and action based on perceptions. “The car in front of me has stopped suddenly” is a reaction-layer issue.

My assumption was that the layers interacted among themselves, but I later decided that this interaction could only take place between adjacent layers (for those that followed my ExperiaSphere project, that’s why I specified that objects could only interact with subordinate/superior objects in the hierarchy). Interactions with adjacent layers, and the perceptive process layer that was adjacent to at least the action and reaction layers, could trigger the need for a control process.

The easiest way to understand this is to take something like our drive to Cleveland as an example. The mission layer here would be where trip and route planning took place, meaning that this is the layer that knows at the high level where we’re going. The mission layer, at the start of the trip, would signal the action layer to undertake the first portion of travel, meaning to the next point where action (a turn, for example) would be needed. At that point, the action layer would be signaled to make the turn (with adequate warning, of course). The trip, signaled as a number of specific “legs”, would complete using the same sequence.

It’s possible that traffic or road construction, signaled to the mission layer from the perceptive process layer, would require restructuring the route. In that case, the mission layer would send a new leg to the action layer, and the route change would then control movement.

At this point, our autonomous vehicle would look exactly like a human-driven car with a GPS. Where things get complicated is where our perceptive process layer signals the reaction layer, and there’s more to that than not hitting the car in front of you.

The highest priority behavior in an autonomous system is damage prevention and control, and obviously avoiding something falls into that category. Hitting the brakes is an obvious response, and in many cases would be an automatic assumption. However, how about if conditions are icy? Suppose that there isn’t time to stop at the current speed? We could assume that road conditions, stopping distance, and so forth could be used as input to a decision process. Even maneuvering might be automatic providing that the vehicle had “situational awareness”, which is clearly a product of a sophisticated perceptive process layer. I envision the reaction layer maintaining a list of possible reactions based on that situational awareness, including what do do for a flat, how to steer safely off the road, and more.

Obstacles aren’t the only complication either. Suppose you can’t make the next turn because the road is closed, but there’s no real-time notification of the sort that GPS systems get (or Waze delivers through crowdsourcing)? Could we have a computer vision system sophisticated enough to interpret a road-close condition? Eventually, probably, but in the meantime what’s needed is human input. Either a human signal that the road is closed (given verbally perhaps) or a situation where human control overrides the next action would be required.

Even terrain has an impact, and particularly if your autonomous-something is an anthropomorphic robot or an off-road vehicle. You have to regulate speed in general, but your perceptive process layer may also have to measure incline, bumps, etc. The more input you can get on conditions from an external source like a GPS and map, the better.

A final perceptive process layer requirement is addressing a malfunction of some sort. Things like loss of engine power, a flat tire, or other vehicular issue are fairly routine happenings, but the response to one of them would be similar to the response to an obstacle, qualified by taking into account the possible impact of the malfunction on the maneuvering required. It’s also possible that the autonomous-operations system itself could fail, and a complete failure would require a failover to manual operation. To avoid that, I presumed that each layer in the process described would be implemented by an independent device connected via a local interface, and that every layer would have to be able to take action based on cached information should one of its adjacent layers fail.

As I dug through the details of how this might be implemented, I realized I needed another layer, which I’ll call the “autonomic” layer, to abstract the actual motion-creating hardware systems from the higher-level structure. Without this, things become too brittle if you have to make changes in the hardware systems. You also need a “perception abstraction” layer to do the same thing for the perceptive process layer, to account for changes in sensor technology and the way you’d receive information from the outside.

What about “the outside”? Could we assume that autonomous operation was a cloud or edge computing function? I never believed that; you really need most of the intelligence resident locally to ensure that something awful doesn’t happen if you lose connection with the outside world. I think that you’d have to assume a local map and GPS were available, that current conditions (from the perceptive process layer) were cached to use as a last resort.

Does this all sound complicated? It sure does, because it is. It illustrates that true, full, autonomy in vehicles is likely to lead to safety issues, because it’s not possible to make the systems truly autonomous with current technology limits, particularly given the need to be fully redundant at all levels and to ensure that a fallback to human control is always possible. The value of an autonomous vehicle that needs a driver is limited, and if the vehicle is supposed to be autonomous then what are the chances that any driver involved is alert enough to take control in an emergency?

What was missing in my robotic experiments was the way of dealing with complexity, and that way is where new concepts like AI and the metaverse could play a big role. AI can support two important things, optimization and anticipation. When we move about in the world we live in, we instinctively optimize our decisions on movement and even body position to the situation. That optimization has to take into account our own capabilities (and limitations), the situation of the moment, and the way we see that situation evolving in the near term. That’s where anticipation comes in; we look ahead. You can’t catch a ball or dodge an object without having the ability to project where it’s going.

The metaverse concept is just as important, because effective AI means that we have a model of the aspects of the current real-world situation and can use that model to forecast what’s going to happen, and even to manage our optimized response. We could model the path of a ball, for example, to show whether it would intercept an autonomous element or not. Whether our goal was to catch or to dodge, the knowledge of the path could be used to activate movement controls to accomplish our goal. But the more complex the real-world situation, the more challenging it is to model it and to apply AI to the model to support realistic, useful, autonomous operation.

You might wonder how my contextual information fields could play into this. My view is that they would impact the mission and action layer and become an input to the perceptive process layer, but not the lower layers. I think it would be a mistake to have issues like avoiding obstacles handled through a lot of back-and-forth cooperative exchanges. However, I can see that in collision avoidance, for example, it might be helpful to coordinate what direction two vehicles might elect to steer to avoid, so that they don’t end up setting up another collision.

All this is complicated, but it doesn’t mean that autonomous operation and robots can’t work. The key is simplification of the environment in which the autonomous-something is operating. A robotic vacuum doesn’t require all this sophistication because even if it fails or runs amok, it can’t really do serious damage to somebody, and fail-safe operation consists of stopping all movement immediately if something goes wrong. Vehicles operating in warehouses or closed environments can also be safe without all the issues I’ve cited here. We should expect to walk before we run, in autonomy, and that suggests that self-driving vehicles may be more of a risk to the concept than an indication it’s advancing. The real world is a complicated place, and in autonomous operation, complicated may often mean too complicated.

Our podcasters review the week’s economic and stock news, and talk about some of the fuzzy, uncertain, aspects of tech.

Podcast: Things Past and Things to Come January 9 2023

Some of the questions and comments I’ve gotten on my blog on contextual services and point-of-activity empowerment ask at least implicitly for an expansion in one key point. I noted the importance of relating “location” of a service user to what is nearby, meaning “contextual location”. I didn’t note how one did that or how the capability would be used. Actually I did mention that back in 2019, and I did a three-part series on new contextual services in September of 2022 (HERE, HERE, and HERE). What I think people are asking for is an application of the concepts of those past blogs to the examples I presented on January 5^th, so let’s give that a shot.

My view of a service user driving or walking along is one of a digital-twin metaverse-like model that represents that user in relation to surroundings. Rather than offering user location in latitude and longitude terms, offer it relative to elements of the real world that are relevant to user interests, missions, and so forth. The question is how that relative/relevant property set is reflected in the metaverse of the specific user.

In 2019 I introduced a concept I called an “information field”. This is a data set that is asserted by everything that impacts the users’ metaverses. Some information fields are asserted by fixed objects like lamp posts or buildings or curbs. Others are asserted by other users, by moving objects, and even by things like time of day or weather. Information fields are asserted, and each user metaverse model includes what I’ll call an “information receptor”, which represents the things that the user is, explicitly or implicitly, sensitive to. When an information field that’s asserted meets the receptor’s sensitivity properties, the field becomes a stimulus input to the user’s metaverse.

Say our user is driving down a road, and there’s a vehicle approaching. That vehicle asserts an information field, and our user is deploying an information receptor. We might say that the receptor is sensitive to another vehicle if it is within a given distance or closing at a specific rate. If the field matches the sensitivity thresholds, then the “logic” of the user contextual metaverse gets a generated event.

Or let’s say our user is shopping. Stores assert information fields that represent what is available there, and at what price. Our user sets explicit sensitivity to the goal of the shopping trip, and if the information field of a shop matches that goal sensitivity, the user gets an event.

Or maybe our user is a worker trying to locate a valve to repair. The valve asserts an information field, and the state of the valve can be a part of it. If the state matches the worker’s receptor sensitivity, and if any other factors known about the target valve match too, the worker would get an event notice, and using it could home in on the thing that needs fixing.

What we could say is that in any given location there exists a set of information fields that could be relevant to a user in that location. This set would change over time as mobile elements shifted into or out of proximity to the location, and a given user’s focus location could also change if the user were mobile. The user’s receptor sensitivity would determine which of the information fields were relevant, so a user walking on the street toward a shop wouldn’t be bothered by the fact that they were passing over a manhole access to a wiring closet, while a repair team might be sensitive to that manhole and not to the shop.

You can see (I hope) how this relates to contextual services and point-of-activity empowerment. The approach would give a user an event, which could (in their metaverse model of their activity), trigger some information delivery. You can also see, perhaps, how this could be linked to some of my musings about a generalized architecture for a metaverse.

In early March of 2022, I did a series of blogs on modeling digital-twin systems and the role a metaverse architecture might play. One of the notions in the series was the “locale”, which I defined as a virtual place that collected inhabitants who could interact with each other. That concept could be applied to our contextual services discussion, with perhaps a bit more elasticity.

First, the locale in contextual services is a virtual model of a real place. One useful way to think of it is that a user of a contextual service is surrounded by a “field” that represents the user’s locale. The user can be aware of things within the locale, and would be expected to be unaware of things outside it. The exact size of a locale would likely need to be adjusted based on the user’s position, speed of motion, and mission. A driver, for example, might have a locale that’s perhaps a block or two around the driver’s current location. Other vehicles and pedestrians outside the driver’s locale need not be considered when looking at how their information fields matched with user’s receptors. That simplifies the processing of these intersections.

We could also consider locales to be fixed in location, based on a number of factors like traffic flow and direction, the nature of the structures, speed limits, and so forth. If this were done, then all of the vehicles within the locale would have the same information fields presented, and so sensitivity receptors for all of them could be matched against that set of fields in a single step.

I think the first of the models probably works best for vehicular motion because the pace of changes in conditions is faster and because maneuvering to avoid things is more critical. For pedestrian movement I think the latter approach is better, because it’s reasonable to think of “walking” as moving between locales, each of which has contents (shops, restaurants, service stations, banks, etc.) that would assert information fields. On entry, a user would then be “presented” with these fields to match against receptors.

Contextual services, obviously, require context first and foremost, and context requires both the assembly of information that is both physically and “philosophically” local to the service user. That’s more than just reading sensors, it’s interpreting the meaning of the relationships the data uncovers. It’s hard for me to see how this can be accomplished without a digital-twin concept, which is my basis for an entry-level metaverse.

But it’s also hard to see how you get all of this stuff in place. Certainly we can’t expect immediate wide deployment of this sort of thing, which of course relies largely on edge computing, at least “metro edge”. The good news is that a “locale” is inherently local, which means contextual services could be offered in a limited area to support limited missions. It may be that contextual services, metaverses, and edge computing all depend on identifying these local opportunities, then building on their success.

The next Things Past and Things to Come podcast will be posted on the morning of January 9th on the blog.tmtadvisor.com website, and the Mastodon chat on its topics will be held at 11 AM Eastern US Time on January 10th. If you have not yet sent me your Mastodon ID and followed the instructions in the email confirming your setup, please do so before then or you won’t be able to participate.

For Tuesday’s Mastodon chat on the TMT Advisor podcast, please make note of the following points, referring to the instructions you received on signing up to participate.

First, you must follow my Mastodon ID in order to see my comments and answers.

Second, you must ask questions and make comments with toots designated as public, and tag your toots with the TMT Advisor hashtag, so that others will be able to see your questions and comments. If it doesn’t interfere with your other uses of Mastodon, I recommend that you go to Preferences>Other>Posting privacy and set your default to “Public – Everyone can see”. Hashtags aren’t processed in Mastodon except for toots that are designated as “Public”.

In our first test of Mastodon chats on podcasts, conducted on January 4^th, I think that it would be fair to say that edge computing and its impact on tech spending was the big topic. Within that big tent, there seems to me to be two supports. One is just where “the edge” really should be. The further outward you go, the lower the efficiency and the greater the impact on sustainability. The other is what applications for the edge would need to have in the way of baseline “platform” services. Absent some middleware support at our hypothetical edge, it could become the grand and glorious mother of all silos.

I think most who follow my blogs know that I am not a subscriber to the “extreme edge” theory, of pushing edge hosting all the way out to the central office locations (roughly 14 thousand in the US) or even the cell towers. I favor the “metro” strategy, which would place edge hosting in population centers that could support low-latency connectivity to the access network, fixed and mobile. I’ve tried to model that placement, and come up with roughly 250 in the us and about two thousand worldwide. As I said on the Mastodon chat, the higher the overall demand density of a market area (like the US or any other country), the smaller the number of metro sites would likely be required for a given total population. Smaller area, fewer metro sites.

The thing about metro hosting as “the edge” is that the positive of greater efficiency depends on having a fairly universal hosting model. If you have to subdivide your metro pool of resources into five or six mission-specific segments, you lose economy of scale. At the same time, though, tech in general and hosting in particular normally achieves universality through loss of specificity of features. If you have six missions, then you pick a subset of all possible middleware features that can support all six, right?

The problem with that is that you still need some uniform feature set within each of those six missions, and if you don’t provide that in the edge platform, you invite every collection of applications within every mission to build their own tools, creating more silos than before. Further, there’s a pretty good chance that within those six (or whatever number you like) missions, there are some common requirements for groups of two or three, and maybe even a few common to them all. A lot of development time could be wasted and resource and operations efficiency could suffer.

Again citing our Mastodon toots, “contextual” or “point of activity” services represent a general class of features, and my view has been that we should consider the edge as a platform-as-a-service framework that supports that general class of features, and that offers guidance on how the general feature set could be augmented with mission-specific capabilities. In short, we need a PaaS that has an inclusive architectural model that encourages extensibility, and those two terms define what our model has to supply.

The thing that’s common across our two terms is the integration of a hosted service into the details of our work and lives. Both involve “activities”, and in order to integrate something with those activities, we need to understand our “context”, which means the frame of reference into which we are placing events, objects, people, and (yes) assisting technologies. The baseline requirement for our model, then, is an understanding of our context and our activities. Place us in a mission (activity) and locate us in the real world in all the dimensions that our senses can register.

When I take a walk (or, as some of my detractors might say, a totter), my phone will make an assessment of my movement, and finding it taking me away from my home location, it declares it to be a walk. Thus, my location is a key element in both context and activity identification. In fact, I believe that location is fundamental to our new model, and the more precise it is the better.

We can establish location through GPS, through triangulation of cell signals, through proximity sensing using multiple technologies, and so forth. It would be madness to assume that all applications that needed location would have to be aware of all the possible options and the technology required to access each of them. A “location service” that presents user location via an API would be the smart way to approach this. But what does that location service deliver? Location is abstractly latitude and longitude, which almost surely does little good for most applications. We really need to think about location the way my phone did on my walk/totter, and consider location relative to something. Context.

I have the option, with my phone, of starting an activity explicitly, in which case my phone knows exactly what I’m doing. One essential input to our process of activity identification is direct identification by the user/worker. It may not be meaningful in all cases to get the sort of precision that direct identification brings; if I’m walking around the neighborhood does it matter whether I’m walking to “clear my head”, for “exercise”, or whatever? But if I’m walking down a street in a town or city, it might matter a lot if I’m strolling, heading to lunch, or shopping. Why, because what I get in the way of information from contextual point-of-activity services would vary across those options.

If I’m shopping, I’m probably shopping for something. Suppose my contextual service knows what that something is, and suppose it can use that to inquire into the websites of the places I’m passing or likely to pass in order to determine if they have an item I’m looking for and how their price compares. But of course I may be strolling, and have a few items I’m just thinking of picking up. If I happen to pass a sale on one, couldn’t it be helpful for my service to alert me?

Useful services that support work or life have to know what you’re working on and how you’re living. In order to do that in a practical way, we have to define a general process of gathering information about context and activity and presenting it to an application set through a standard set of APIs. We can’t allow those APIs to be too low-level (like presenting location as latitude and longitude) or we’ll make development of contextual applications horrendously expensive, and hosting them an efficiency and operations mess. We need that PaaS.

And, of course, we need a business case, and that’s another part of the reason for a PaaS. You can’t expect applications to develop in anticipation of both a suitable hosting platform and a reasonable ROI. Everyone accepts that “edge” differs from “cloud” primarily in that the former distributes hosting closer to the point of activity in order to ensure that the contextual vision of the applications is closely synchronized with the real world. A PaaS model, designed to get something into play, justified by current applications like NFV or 5G, could support gradual introduction of contextual applications, paced at the speed of acceptance and generation of returns.

The point here is that context is complicated, and so are the processes of identifying and supporting activities. This is why I’ve come to believe that all contextual services would have to be supported using a digital twin modeling, which would make it in my view a form of a metaverse application. I don’t know how to think of the challenge of contextual or point-of-activity services in any other way, architecturally speaking. To expand on what I said in the last paragraph, you need a model of at least an abstract piece of the real world to help people live and work in it.

Any fortune-teller loves it when their predictions come true, but they also love it when others begin to agree with some of their early-stage prognostications. So it is for me (being an analyst isn’t far from being a fortune teller) with the future of the metaverse. A VC-centric publication has picked up on many of the things I’ve said about the metaverse’s future, not necessarily because I said them but based on the view of another of those analyst/fortune-tellers. Could awareness be growing for some of the issues I noted yesterday? Let’s look at what was said and what it might mean.

The basic theme of the piece is one my readers will surely find familiar; the “metaverse” of the future is really about digital twin technology, applied to things other than social media. Since I’ve been blogging about this slant from the start of the metaverse hype (including just yesterday), it shouldn’t be a surprise that I agree with these points. The same can’t be said for everything in the rest of the piece, and my objections there may seem familiar too.

Let’s start with a positive, which is that the article divides the metaverse into three segments, “consumer” (what I’ve been calling the “social metaverse”), enterprise, and industrial. I’m not totally comfortable with the latter pair being different enough to consider them as independent segments, but there is a justification, which I’ll get into in a minute.

OK, let’s now look at some issues I have, starting with the definition. The article offers the following: The metaverse is a confluence of interconnected open platforms bringing the virtual world and the physical space together under a single technology ecosystem.” I’m far from sure that we could call the metaverse a confluence, interconnected, or open. To me, the metaverse is a model of elements of a real-world system, synchronized with that real-world system and used to facilitate control of aspects of that system through control of the model.

You can see from my definition that I believe that the essential element of a metaverse is the digital-twin notion. All metaverse applications will have to synchronize with aspects of the real world and model the relationships of the selected elements. The scope, in a distributed/interconnected sense, of a metaverse then depends on the scope of the real-world things it represents. For wide-scope metaverses, the property of interconnectivity is surely important, and there may be a value to open technology, depending on just what real-world systems the metaverse represents.

In truth, many industrial and enterprise metaverses, and maybe even many consumer metaverses, gain little from openness at the metaverse level. An industrial process is localized, and just as much of the industrial IoT today is linked to the machines used, we could expect the metaverse to be bound to the equipment. To require openness here would be to mandate standardization on which the interconnectivity and digital twinning could be based, and we don’t have that. Our industry has proven fairly ineffective in creating anticipatory standards; we do better trying to harmonize things once we have exemplars from which we can determine requirements and properties.

Even distributed metaverses don’t necessarily have to be open, as long as they can interconnect. We built almost every network today from devices that can interconnect and cooperate but are proprietary. There might actually be a benefit, particularly in “social” and “enterprise” metaverse models, of creating a metaverse by interconnecting proprietary components in a standard way. Competition among implementations could advance the process overall.

The next issue I want to raise with the article is the focus on visualization. At one level, any metaverse is a digital twin process and a model-representation process, but the latter doesn’t necessarily mean visualization is the key element in the representation, or is even present at all. A model of the real world (the digital twin) that, when it’s manipulated, reflects the manipulation results back to the real world depends on the reflection piece, and that in turn depends on what you’re trying to accomplish. If, for example, we had an industrial process we were looking to control via AI, visually representing the model wouldn’t facilitate the control, and it might be more work to visualize it than it’s worth if all you gain is letting a human watch what’s supposed to be a fully automated process.

This point illustrates my issue with separating “enterprise” and “industrial” metaverses. The way that a model is reflected back into the real world, for missions like education or process management, depends on the goal, and it’s a bit elastic. Might a warehouse metaverse, for example, provide a means of visualization given that workers in a warehouse might need to see what a given container looked like in order to ensure they have the right thing? On the other hand, the same application could require that an AI system route a forklift to the place where the thing is supposed to be, taking into account other forklifts in motion, optimum routes, etc.

This now raises the question of the “social” metaverse. Is it really justifiably separate from the enterprise/industrial metaverses? There is, I think, a major difference, and that is that creating a realistic visual experience from a distributed set of digital twins is central to the social metaverse. This is perhaps the clearest application of augmented reality to metaverse thinking, because absent a truly realistic rendering of the distributed model, the whole thing falls apart.

Even here, though, we can find other AR applications in the enterprise/industrial space, most significantly in health care specifically and robot control in general. Remote surgery demands good visualization, and you could say the same thing with remote repair. These applications could demand multiple synchronized AR visualizations and also model-driven process controls, so they may be hybrids of the other possible metaverse opportunity segments. Thus, we could rightfully say that there are three elements to a metaverse: 1) the digital twin model, 2) the process control interplay with the model, and 2) the AR visualization. It’s possible that the latter two may range from being minimal to being highly critical, and the mission frames the relative importance of each. Whatever opportunity segments exist, we can address them with a uniform technology.

Which, according to the article, involves Web3. I highly doubt that Web3 is actually a required element, and in most cases I’m not even convinced it’s a useful element. Unless we redefine Web3 to make it a success retrospectively, the concept is about a distributed form of validation/authentication. Obviously, only highly distributed metaverses would have any need for validation; it’s not a requirement for “industrial” metaverses. It also seems obvious to me that simple ID/password validation would be sufficient for most of those applications. Where a metaverse is created by “federating” different digital-twin instances, it’s hard to see how any would really benefit from Web3 blockchain-based authentication.

So, given my points, why did I bother to highlight this piece in a blog? The answer is that the startup community is all about exit strategies, and so it’s not surprising for it to validate thinking that led to some of the current startups, who will shortly need exits. However, that same community may be essential if we’re to make the metaverse, the realistic metaverse, a reality. It may be a good sign that it’s trying to wrestle some sanity out of the concept, and merge it with some healthy opportunism. As long as it doesn’t get stuck on the thorns of older concepts, that merging could lead to a good outcome.

The metaverse seems to be one of those topics you can’t stop blogging about. There’s a lot going on for sure, the concept is important for sure, and others keep writing about it and raising issues. For example, Light Reading talks about how telcos “marvel at the metaverse”. CNBC says that the metaverse is “off to an ominous start” because VR headset sales shrank in 2022. There have been many other tales, too, and another piece in Light Reading on SASE seems to invite some parallels. Can we navigate this mess?

Let’s start our journey with the SASE angle. According to the LR article, “The telecom industry could certainly benefit from resolving to clear up confusion surrounding SASE.” Darn straight; any industry in fact could benefit from resolving to clear up confusion in almost any new-ish tech concept. That’s surely true of the metaverse, and you have to wonder why concepts like these end up having confused definitions in the first place. PR and analyst firms, I think.

For a decade or more, a product manager or marketeer’s idea of nirvana was “creating a new product category”. If you announced a box or piece of software that fit into an existing category, you ended up being a slave to those who got there earlier and were able to define the category first. Analysts loved the notion too because it let them write another set of reports on the new category. For the media, a nice category name (like “metaverse” or “SASE”) made covering stuff easier. The problem is that haste makes waste, and with everyone jumping out to define stuff it’s no surprise that you end up with definitions in search of clarification.

At a deeper level, these new and loose terms are what I’ve been calling “UFOs”. A UFO is great because, since one isn’t likely to land in your yard and present itself for inspection, you’re free to assign one any characteristics you like. Telcos marvel at the metaverse, of course, because everyone is supposed to, but why in particular should telcos be doing that? Because they see 5G/6 G connections and a long-sought-after driver for new revenue from those services. Who guarantees that will happen? Nobody, but a metaverse is a UFO, so you can say what you like.

The CNBC story says that because artificial or virtual reality headsets have seen a sales dip, the metaverse is in trouble. Well, that could be true depending on what UFO-like characteristics a given vendor or provider happens to have assigned to it. CNBC is apparently taking Meta’s social-metaverse view, and that’s pretty clearly linked to VR headsets. But remember the “industrial metaverse” I blogged about earlier this week? You don’t need VR headsets for that, and it may well be a bigger contributor to the future of the metaverse concept than Meta’s own vision.

The problem with meta-fuzziness is that it risks a loss of credibility for a whole universe of concepts that might, in fact, not even belong together. Remember that we have another concept called the “Internet of Things” or IoT, and our industrial metaverse might be an IoT application. We also have the concept of “digital twin”, and that could be what industrial IoT is based on. Or maybe the metaverse is a digital twin and we shouldn’t be using a different name for it. Or maybe it’s virtual reality. We have at least three or four concepts that are kind of rolled into the “metaverse” term, and none of them are precisely defined either. Most of the “things” in our IoT reality, for example, aren’t on the Internet.

There are legitimate reasons for adopting collective terms, and they boil down to the question of whether the collection is actually a functional whole. Read Vonnegut’s “Cat’s Cradle” and you’re introduced to the concepts of kakrasses and granfalloons. The former refers to a group of people who are meaningfully if not always obviously collected, and the latter to groups that have no significance, only a name. The metaverse concept is valuable if it’s a karass, a significant grouping of functional elements that generate a higher-level something. All the current confusion over metaverse definitions, elements, or features is proof we haven’t achieved that yet. Today’s metaverse is a granfalloon. If that’s the case, then we either need to firm up our metaverse concept or stop using a collective term for something we can’t define as a real collection of stuff. In software terms, if we can create a metaverse architecture, then metaverses are meaningful.

Why do we have a term that we can’t really make into a karass? It goes back to the marketing angle. In today’s world, it’s common to announce things before they’re real, often even before we know how to make them real. Another thing I told consulting clients over the last couple decades applies here; “The truth is a convenient place from which you launch a good marketing fable.” Suppose you forget the launch pad and just concentrate on the fable part?

I think that a metaverse architecture can be defined in such a way as to include the missions that we normally assign to a metaverse, and also some missions I believe are related. A metaverse is first a collection of digital twins that represent semi-autonomous pieces of a real-world system. Second, it’s a model of models that describe the nature of that collection. Third, it’s a telemetry and control framework that synchronizes the model with the real world, taking data from the real world to alter the model state into correspondence, and taking changes to the model and communicating them to control elements that then bring the real world into synchrony with the mode. Finally, it’s a visualization framework that allows the model to be externalized, including making it or an abstraction of it visible to people.

You could visualize an implementation as a collection of “black boxes” or objects, each representing something, linked by APIs. If we were to define the objects and APIs, we could allow any implementation that met the specifications as being a conformant piece. Thus, a full specification of the architecture would allow people to build on an open framework and would not demand all implementations of each object be open-source.

The challenge we face, metaverse-wise, for 2023 is who might define the architecture. I don’t think that a working approach would be difficult to create, one that handled what we can visualize in the way of missions now, and that can be extended if we missed something. But who spends the effort? Meta, maybe, if it does spin out of Facebook overall, but would they just focus on the social angle and miss the rest? The cloud providers are probably a better hope, and I hear that all of them are at least exploring the question.

It’s tempting to see the metaverse as an evolution of a failing social-media-ad-sponsored past, and while that still may be an option it’s not likely to generate enough revenue in the near term to sustain technical investment. That would be short-sighted in my view, because the metaverse is the way forward for IoT and digital-twin concepts overall, and it’s those areas that hold near-term promise. We might see progress, even convincing progress, in 2023, and if we do then the metaverse could be one of the year’s most important developments.