Month: April 2021

Is there something going on with speech recognition, beyond the obvious? Microsoft’s deal for Nuance and its Dragon voice recognition could be seen as a speech-to-text enhancement to Office, but it could also be seen as a way of bringing speech recognition into a higher plane of productivity and personal activity support. Or both.

Speech to text is one of those things that’s been around forever but hasn’t really made much news lately. The idea is to have a person talk naturally and a computer tool transcribe the speech directly into an application like a word processor, browser, or other productivity tool. I used Microsoft’s embedded speech to text feature when an accident with a cleaning service resulted in a burn to my right hand that kept me from typing at my usual speed for about two weeks. It worked, but not perfectly, and once I recovered my typing, I gladly abandoned the speech to text model.

Dragon from Nuance is arguably the best of the tools available, and it’s widely used not so much by writers as by people like doctors who have to transcribe impromptu notes. It’s much more efficient to have verbal comments transcribed than to sit down at a computer, particularly since professionals who do have transcription needs are often not facile typists in the first place. But Microsoft has tools here already, and would Dragon be worth buying for almost $20 billion, well above the rumored premium, if the only motivation was the traditional speech recognition and speech to text?

Nuance’s stock was stagnant until the start of the pandemic, and from there it took a sharp upward path. The presumption here is that WFH has disconnected a lot of people from their normal administrative aid, making it necessary for key people to produce documents on their own. In addition, Zoom or Teams meetings are things that can benefit from transcribed notes, since the meetings in raw video-recording form are hard to find things in quickly. Most users say that the embedded transcription services in videoconference tools are pretty limited.

Whatever the case, the problem here is that the pandemic is ending. It would have made a lot of sense for Microsoft to buy Nuance in March, when the upside was just developing, but less so when the only real driver for a change in the value of Nuance for over a decade is likely to wind down. I think that it’s unlikely that Microsoft would want to buy Nuance at a higher-than-expected premium when Nuance’s current revenue sources are either static or at risk of a decline. There would have to be something else on the table.

A hint of what that might be has been dribbling out of conversations I’ve been having with vendor and cloud technology planners. Some of these have been telling me that Amazon, Apple, Google, and even Microsoft have been looking at how “personal assistant” technology could relate to something I’ve blogged about for years—contextual services. A contextual service is one that’s delivered to someone based on a highly developed notion of what the individual is trying to do. It’s a step beyond the normal notion of an “assistant”, and you can actually see some of the tentative movement in the new direction already.

Have you noticed that your personal assistant seems to be getting more attentive? That there are situations where it jumps into your life even if you haven’t said the traditional wake-up phrase? According to some of my vendor contacts, that’s because the design of these tools is changing, taking the personal assistant into what’s an almost-human role of a co-party in all your conversations. There are obviously major privacy constraints on this sort of evolution, so we shouldn’t expect to have personal assistant providers shouting their intentions from rooftops, but there are major benefits as well.

Imagine that you’re having a conversation with a friend, family member, or co-worker, and sitting in on the conversation is a discrete, trusted, third party. Most of the time, being discrete, that phantom member of your conversation stays quiet, but it’s following along and from time to time, when there’s some particularly compelling contribution to be made, it quietly inserts its contribution. That, according to one of my sources, is what personal-assistant developers are looking at. It would be valuable in itself if done correctly, and it could be an on-ramp to contextual services.

For those who didn’t read my blogs on that topic (or didn’t find them that memorable!), contextual services are services delivered to an individual based on an inference of what the individual is trying to do, and designed to facilitate that action or action set. The foundation of this sort of service isn’t what you deliver, but how you know what to deliver, meaning how you can understand the context of the user of the service and interpret requests or inject information based on it.

My presumption in the contextual services space has always been that the first step would be to apply contextual knowledge in creating a response to an explicit request. My friends in the personal assistant space have suggested that’s shooting behind the duck, that contextual services would necessarily be an evolution of the personal assistant, reflecting the assistant’s shift in role from asking questions to volunteering information.

This shift isn’t a universal factor in contextual services, it’s a factor in applications that involve voice communications between involved parties. If a worker is ranging through a railroad yard looking for an axle, the search isn’t likely to involve the worker asking the axle where it is, so there’s no voice to analyze. On the other hand, a discussion between two workers on how to find it could create a voice trail that would lead an augmented personal assistant to cut through the crap and tell the pair where the axle is likely to be found based on database records.

The reason this is important is that the pandemic and WFH have created an environment where collaboration via electronic means is more accepted; people are habituated to it. That could mean that they are more prepared for an aggressive personal assistant, and that their behavior is more likely to include significant conversational components that can be interpreted to determine context.

There are a lot of implications if it is true that Microsoft sees the conversational gold in Nuance. If conversation analysis can establish behavioral context reliably, then you could apply contextual computing to enhancing productivity or quality of life without having to deploy a vast number of sensors to develop a model of the real world and the user’s place in it. In fact, a conversational basis for context could be applied quickly to a small number of people, where something based on IoT or “information fields” created by retail operations could require considerable up-front investment to get to a point where a single user could be served. You might also promote edge computing, because one model of implementation would involve an edge-hosted “user agent” that did the conversational analysis and gathered the useful information for presentation.

There’s no assurance that this is what Microsoft sees in Nuance, of course. Corporations often have blinders on with respect to opportunity; they see the future as a linear evolution of their own past. Maybe Microsoft does believe that Dragon speech to text is worth twenty billion. I don’t think it is, and I’m hoping they see something more exciting instead.

What is the right model for the software that’s used to create network services? Sure, we can say that it’s “virtualized” or “containerized” or even “cloud-native” but are those terms really enough to define the properties of the stuff we hope will play a big role in network services? I don’t think so, but I do think we can evolve from them to some useful conclusions about what is needed.

A good place to start is with the concept of virtualization. Virtualization in a software-and-hardware infrastructure sense means creating a model of hardware which is recognized by software as real and specific, but can be applied instead to a pool of resources. This capability is what really permits the separation of software and hardware, and allows better scaling and availability. We need software that works in the virtual world in order to build our transformed network infrastructure.

The next question is just what a pool of resources really means. Obviously, it means more than a singular number of resources, and it also means that there’s a presumption of multi-use in play. We have a pool because we have multiple consumers, and the consumers need some redundancy. By sharing the pool, that can be provided at a higher level of efficiency, meaning a smaller number of resources. That, in turn, lowers both capex and opex.

If the consumers of resources, the features that make up services we’re creating, require different resource types, then a single pool won’t serve; we’d need a pool of resources for each distinct mission. In addition, a resource pool isn’t likely as useful, or useful at all, if there is at the point of consumption only one mission or user to share the resources. That means that the value of the pool is greatest at the point of largest mission diversity.

From this, we could say that the value of a resource pool would graph into something like a bell curve. Near the network’s edge at the left of our hypothetical graph, mission and consumer density is low, and so pool value is low. On the right, representing the core, we really have only one mission, which is to push bits. That mission can benefit from a resource pool, but not a pool of servers. Think instead of a pool of white boxes.

The middle of our curve represents the metro piece of the network, the part that begins at the inside edge of the access network, after primary traffic concentration has occurred, and ends when the traffic load effectively prohibits any service-specific manipulation of the network’s flows. It’s here, where we have an opportunity to add specific service features and where we have enough traffic to make economy of scale meaningful, that we need to think about the network as a cloud.

We have to start with a bit more on missions. Network services are made up of components at three levels, the lowest being the data plane, then the control plane, and finally the “service plane” where the actual user experience is created. The latter is where “higher-layer” services live, and where development efforts by web social media players typically focus. This service plane is really, or should be, cloud computing pure and simple, so it’s the data and control plane we need to look at more deeply.

Operators almost universally believe that large-scale data-plane handling is best handled by specialized hardware, which in an open-model network means white boxes with specialized switching chips. It’s possible to use traditional servers or white boxes without specialized chips in the access network or even metro-edge or edge aggregation, but operators who have thought their metro architecture through believe that using servers as data-plane handlers deeper in metro is likely to be justified primarily where there’s another set of missions that would justify creating a significant resource pool at the location.

Control-plane applications are a bit more complicated, because the term applies to both the data-plane protocol’s control-packet exchanges and coordination of data plane services that live a level higher, such as 5G’s control plane. To the extent that the control plane is tightly coupled to data-plane behavior, as it is with traditional IP networks, the control-plane processing has to be fairly local to the data plane or the latency could create a problem in performance during periods of “convergence” on a new route set. That doesn’t necessarily mean that control and data plane have to be supported on the same hardware, only that they would have to be supported in proximity to one another.

What we have, then, in a mission sense, is a service-plane requirement that would be hosted in a traditional cloud manner. Where this hosting was available, it’s likely that some local control-plane hosting could be provided, and even limited data-plane hosting. The configuration of the data center where all this was happening would have to ensure that the latency between data-plane devices and control-plane hosting points was suitable. Thus, white boxes might be co-located with traditional servers.

Within a given resource type, a pool could be created in the metro areas because of opportunity/mission density. Within that pool there needs to be some specific mechanism to deploy, redeploy, and scale elements, which gets to two topics. First, what’s the foundation of that deploy-and-so-forth process, and second, what can we say about the relationship between the foundation theory and the cloud’s specifics.

Virtualization requires that there be a mapping between the model element (a container, virtual machine, intent model, or whatever you like) and the realization of that element on the resources available. In networking applications in particular, given the fact that resource requirements aren’t uniform, we need to distinguish between what we’ll call resource sets and resource pools.

A “resource set” here means a collection of resources that are managed so as to support virtual-to-resource mapping. They have a consistent set of properties, so they’re “equivalent” in resource terms. A “resource pool” is an overlay on one or more resource sets that extend that equivalence through the entire overlay. Thus, three data centers would make up three resource sets, and could host one or more resource pools across some or all of those sets. The number and extent of pools would depend on the properties that could be “equivalent”, meaning that we could extend a pool as long as the extension didn’t compromise the properties that the pool advertised to the mapping process. So if we had adequate latency for “Pool A” across two of our three resource sets but not the third, we could define Pool A across the two suitable sets only.

What’s inside a resource pool would, of course, depend on the missions to be supported. I think it’s fair to propose that servers and white boxes would have to coexist as resource sets, and it’s also likely that there would be a combination of virtual-machine and containerized deployments, perhaps even bare metal. That would allow resource pools to be built considering the hosting capabilities of the resources, including special chip support such as GPUs or networking chips. We can then define “adequate” as including both the inherent features of the resources and their topology as it relates to latency and perhaps the risk of a common failure such as a flood or power loss.

For data-plane applications, as I’ve noted, higher traffic levels will require special networking chips, and that would create a resource set. Lower-traffic data plane applications and most control-plane applications would require servers, either VMs or containers depending on traffic requirements. Containers, being lower-overhead constructs, are better for lighter-duty control-plane activity because you can stack more of them on a server.

Just getting stuff deployed isn’t the end of the issues relating to the software model. Part of the adequacy consideration is in the workflow connectivity support available. Latency, obviously, is related to the efficiency of connectivity. A distributed application is an application whose components interact via workflows, and if the interactions are limited by capacity or latency, then at some point the connectivity support becomes inadequate and the resources or resource sets don’t belong in a pool that requires a better level of connectivity. But connectivity is more than just supporting workflows, it’s also about being able to find the next hop in the workflow, to balance work among instances of the same process, and to replace broken resources with new ones.

The point here is that “orchestration” isn’t just about creating a mapping between the model and the resource, it’s also about mapping the workflows effectively. The workflow mapping is likely more dynamic than the component-to-resource mapping, because there are conditions outside a given component/resource pairing that could impact effective workflow exchanges. For example, if you add a second instance of the component, does the introduction and the need for load balancing that’s created now reduce the performance to the point where the distributed application won’t meet spec?

The connectivity requirements created among mapped resource points identified by “deployment” mapping has a real-time, ongoing, component to it. In the cloud, the former is handled by things like DevOps tools or Kubernetes, and the latter by things like service mesh technology. There’s obviously an interdependence in play, too. Where you put something could/should be influenced by the connectivity that could be made available. This might be something that Juniper will be enhancing as it integrates its Apstra approach, because Apstra takes some resource set and resource pool operations activities from pure static deployment into something more adaptive.

You don’t need a service mesh, containers, or Kubernetes for this; a resource set should contain its own orchestration and connection tools. What you do need is some federation tool, something like Google’s Anthos, and you need to have the resource-set tools subordinate to that federation tool so you can apply global policies. Since we don’t today recognize “federation” at the connection layer, we would either have to create a service mesh across all resource sets to be used by the resource pools, or devise a connection federation strategy. Virtual-network capabilities like SD-WAN could be used to frame such a connection layer, but you still need discovery and load balancing, and the mechanisms for these could reside either with the connection-layer support (as it does with the Istio service mesh) or within the deployment layer (Kubernetes has some support for it).

Now for the question of “cloud-native”. In order for software to be scalable and replaceable on demand, the components have to be stateless, meaning microservices. They don’t necessarily have to be functions or lambdas, which is a subset of microservices where stateless behavior is achieved by requiring that the output always be a function of the input; no other data can be required so other forms of state control (like the most-popular back-end state control) are valid, if a purist view is taken.

Stateless data planes aren’t realistic; you need forwarding tables at the least. For the control plane, you could implement a stateless set of components if the interactions were controlled via a state/event table that maintained state externally, and invoked the components when an event was received. Protocol handlers have been written this way for at least 40 years. I don’t believe that serverless or function implementation of most control-plane activities is useful because you wouldn’t want to introduce the latency of loading the function every time an event occurred. Traditional persistent microservices would appear to be the best approach.

Management functions, especially service lifecycle automation, are part of the service plane and they’re an example of a service-plane application that can be treated as a control-plane application, with microservice and state/event implementation. This is what my ExperiaSphere project demonstrated, and also what I’d recommended to the NFV ISG as an implementation model. It’s based on the TMF’s NGOSS Contract approach, dating to the 2000s and since apparently dropped by the TMF, and I believe that it’s the model ONAP should have been based on.

The advantage of state/event implementations for control and data plane is that it provides for elasticity, parallelism, and all the good stuff we expect from cloud-native. There is a single specific data model that represents the system (the interface, service component, etc.) you’re automating, and within it there’s a state/event table that lists the operating states the system could take and the events that are recognized. For each state/event intersection, there’s an identified process (or process set) and a “next-state” indicator. When an event occurs, it’s looked up, the process set is executed (passing the data model as the variables), and the next state is then set. Again, this is how protocol handlers have been written for decades.

The nice thing about this is that it facilitates a kind of distributed model of event-handling. You could parcel out a service data model to the specific areas where a given feature/function implementation resided. Each of these “sub-models” would have the same properties in terms of state/event management and microservice implementation, and each sub-model could generate an event to a higher-level sub-model, or to the main model, when something required action that the area sub-model could handle, such as a total failure. There’s not much point to having distributable components in a cloud-native model without having a mechanism to manage them in a distributed way.

So that’s my view. We are not there yet with respect to this vision, but I believe we could get there pretty quickly. If we do, then there’s a good chance that we’ll have the formula needed for a transformation to a software-centric network future.

How would experts on both the buyer and vendor/seller side see edge computing evolution? I had an opportunity to ask a half-dozen in each of these two groups what they believed would, could, and should happen. The results were very interesting.

The first question, obviously, is “What is edge computing”, and all my experts had fairly consistent views on the question at the high level. Edge computing is the deployment of compute resources close to a point of transactions or events. In a sense, it’s decentralization, something that seems to fly in the face of some of the past priorities, such as server consolidation. As we’ll see, that contradiction causes some discomfort.

The second question is “What justifies edge computing”, and experts gave IoT as the answer by almost a 2:1 margin. This dodges the server consolidation contradiction by linking edge computing to an application set that wasn’t responsible for server distribution to start with. In other words, past IT practices (and mistakes) were related to how transaction processing or productivity support for workers (empowerment) was handled, and edge computing is different because of the IoT mission.

Those who didn’t have that view were largely (all but 1) on the vendor/seller side, and this group believed that edge computing was a response to latency-sensitive applications in general. This group was admitting to the possibility that edge computing might be applied to transaction processing and empowerment applications, which clearly wasn’t what the users were willing to buy into.

One reason for this is that vendor/seller (cloud provider) people have seen the way that functional/lambda computing is applied to what’s effectively a GUI in social media applications, and recognize that this application would be potentially valuable to support workers. Prospective edge buyers generally have not seen these applications, and thus haven’t really thought about whether they might promote edge deployment.

The third question, which is “Where would the edge deploy?”, resulted in even less consensus. Users/buyers thought by a 4:2 margin that the edge would deploy on their premises, and vendors/sellers believed the opposite by a 5:1 margin.

To me, the user/buyer perspective was simply a reflection of how they saw IoT evolving. Most IoT applications already have local controllers deployed, and most user/buyer organizations are reluctant to push a critical piece of IoT out of the space they can control, over a network connection they’re not convinced is reliable, and into the hands of a player they may have little or no experience with. All of the buyers who wanted the edge on their premises said that they also believed that latency control with a “remote edge” was problematic because they had no idea what latency such a configuration would generate.

The vendors, even those representing IT elements that could figure in an edge deployment, were cagey about why they felt the edge would not be on the user premises. With some discussion, I got the impression that the big problem with that was too much application exposure in the value proposition that would have to drive sales. You could sell gear today to a cloud provider or telco who wanted to get into the edge computing business, basing your sale largely on media-driven “market trends”. Actual users meant linking the edge to an application, and making what started to look and sound like a one-off consultative sale to every prospect, which obviously no seller wants to get involved in.

I wanted to dig a bit on this point, which led to my next question, “Is there a generalized edge computing market somewhere off-premises?” For this, after some clarification of what that meant, only one user in six said “Yes” and all the vendor/sellers said “Yes”. I think that here again we see the IoT mindset of users/buyers in play. They see IoT applications as justifying their own edge elements, because the “edge” would be close to the IoT sensors and controllers or they wouldn’t be “edge”. Vendors/sellers, recall, see themselves selling to or offering generalized IoT, so naturally they believe there’s a market for it.

Do they really, though? When you press vendors/sellers for details on how edge computing will be used rather than sold, you find that 4:2, they believe that “applications” will build the edge business case for buyers, and that IoT will likely be the application that does most of the heavy lifting. They also believe that the buyers will have to drive the applications. The two with a different view thought that integrators would be the vehicle that linked user/buyer applications to generalized edge hosting. The one user who believed there was a generalized edge market also thought that integrators would make the application connection.

To me, it’s clear that vendors/sellers of edge technology are hoping for the classic “Field of Dreams”, but interestingly, the cloud providers here are the bridge in attitude. They believe that without an offering in place, there will be no buyer consideration of edge-in-the-cloud services. Thus, they’re taking the lead in publicizing edge capability, knowing that their commitment of resources can be timed with the pace of developing opportunity.

How long might it take for edge computing to become a reality? Here we had another separation based on buyer versus seller. Among buyers, the majority thought edge computing would come about somewhere between late 2022 to mid-2023. Among sellers, it was early to mid-2022, meaning about a year. I don’t think this means much beyond that sellers are always more optimistic about adoption than buyers are, but it might also be because buyers see that specific application connection with IoT, and thus are linking edge computing to a significant advance in their own IoT usage. Sellers see (or hope for) somebody to build edge computing and expect comers to evolve naturally.

My last question relates to the role of the cloud provider, and I found this really interesting. All the vendor/sellers, even ones that I’d have expected to hope for end-user deployment, thought that the cloud providers would be the dominant players in the edge space. Among buyers, it was only 2:4 in favor of the cloud.

I again attribute this to the IoT mission-centricity of buyers. Despite what the cloud providers would like you to believe, and would like to believe themselves, the majority of buyers don’t see the cloud as playing a major role in IoT. Transportation obviously would likely have a different view, but across most verticals, IoT is still an in-house thing. That’s another reason for cloud providers to push their own edge vision; it primes the planning and awareness pump.

One interesting point is that two of the four anti-cloud buyer experts volunteered that while they didn’t see the cloud playing a big role, they believed their senior management had a different view. If senior management shifted those two, then the balance would be 4:2 in the cloud’s favor, which made me wonder whether the other two might also be influenced by senior management shifts.

Through all of these questions answers, there was a single thread, which is that the justification for edge computing, if you take it out of the users’ facilities, is extremely vague. Vendors have great hopes, which is true all the time for sellers. Users have a kind of cautious and watchful interest, but that’s all they can muster at this point. The net of this is that there’s not likely to be an edge explosion driven by business applications. What could happen is that edge computing off-premises could grow out of available edge hosting resources justified by something else.

There’s no “else” on the horizon other than 5G and O-RAN at this point. We don’t know exactly how and where O-RAN will be hosted, but we can be fairly sure it won’t be on enterprise premises. If public cloud providers, with or without partnerships with network operators for real estate, deploy edge computing for 5G, it’s there and ready to be exploited. If operators do it on their own, same effect. The future of the edge is the future of O-RAN, and all the edge proponents need to accept that reality and think about its consequences.

Verizon seems to be recognizing that the path to 5G success isn’t fantasy services, but the symbiosis between 5G, mobile services, and home broadband. It’s hard to overstate the importance of that, not only for Verizon but also for 5G and the networking industry. Of course, that fact that even a giant Tier One can face the truth isn’t necessarily a victory for the truth, so we’ll have to consider not only what this could mean, but how it might not work out.

Operators didn’t create 5G’s problems. They considered 5G an essential evolution of wireless technology, and they budgeted for its deployment in much the same way as they had for the deployment of earlier wireless generations. There is not now, nor has there ever been, a chance that 5G would “fail”.

The problem is that this orderly evolution is not only unlikely to quickly fatten vendor coffers, it’s as dull as dishwater to the media/analyst community, for whom anything less than a revolution isn’t worth of note. The desire of the media to make excitement, and the opportunity that creates for vendors to hype something beyond its dull, orderly, and certain progress, combined to make everyone believe that 5G had to be a revolution to succeed.

This belief hid some of the most important truths about 5G, truths beyond simple mobile evolution. Objectively, 5G offers higher bandwidth per cell and per user connection. In millimeter-wave form, 5G can deliver bandwidth that would challenge everything except fiber to the home (FTTH). In its mobile form, it can beat copper-loop DSL handily as a home networking replacement. Thus, it’s always been true and always been known that the most likely first step 5G might take beyond mobile networking would be wireline replacement.

I’ve blogged before, most recently yesterday, about what 5G might bring to that market. The biggest problem with bringing quality broadband to thin-demand areas is the cost of connecting the user to a fiber-fed nodal junction, and the second-biggest is the cost of connecting those nodal junctions back to the Internet. 5G doesn’t make it possible to feed 100Mbps broadband to everyone. There is no current technological answer to that within the reach of a rational public policy. It does make it possible to feed it to a lot more people, and to lower the cost of doing that to the point where subsidies could be significantly lower.

What’s important about the Verizon story is that it’s proof that big operators are seeing 5G more clearly, and that they’re asking what everyone should now realize is the critical question. That is whether the deployment of 5G in both wireless and wireline missions could create more than simple financial symbiosis between wireless and wireline.

From an infrastructure perspective, 5G is important for a number of reasons beyond those related to the transformation to the radio access network (RAN) that enables high-speed broadband delivery. First, it’s an attempt to move mobile networking and its infrastructure into the virtual age. Second, there is broad support for open implementations of 5G, particularly the Open RAN or O-RAN initiative. Third, the spread of 5G into wireline could promote a shift in how we think about the relationship between network connections and services. We’ll look at all three of these further, here and now.

In the promotion of virtualization, it’s not all beer and roses, as the saying goes. The 3GPP’s intentions with their shift toward virtual functions is positive, but the specific mechanism of NFV is not. We should have learned the lesson that virtual anything had to mean “cloud-native”, meaning that cloud technology should have been the foundation of 5G, not NFV. Instead, what happened was almost as bad as it would have been for the 3GPP to mandate that everyone had to create custom chips for every piece of 5G. You build virtual-function hosting from cloud tools, period, and we’re still not accepting that truth. However, we’re drifting toward the right place in any event, because specifications like O-RAN don’t really mandate NFV as much as use it as an example.

Network slicing is another form of virtualization, and one that’s really important more for what it could turn into than for what’s being suggested for it today. We know about the concept of “virtual networks”; it’s embodied in VPNs, SD-WAN, and so forth. We also have examples of network separation in fiber transport based on wavelength (lambda), and network slicing gives us something very similar with radio-network technology. It may be that the first real, good, applications of network slicing are involving the separation of wireless and wireline replacement services.

Virtualization is a good jumping-off point to O-RAN. If we were to follow 3GPP specifications blindly, 5G RAN would inherit NFV explicitly because the primary mobile network vendors are fixated on formal standards. On the other hand, O-RAN is very explicit about APIs and functional elements and not so specific about how exactly they’re hosted, orchestrated, and managed. That stuff tends to be outside the O-RAN diagrams, meaning that implementations could tweak things a bit more toward the cloud. Given that many (even perhaps most) O-RAN implementations are being promoted by vendors who live more on the cloud side than in the network, it seems inevitable that this will result in cloud-native O-RAN options.

The reason that’s important is that cloud-native has to grow from a seed, in both operators’ infrastructure and in their hearts and minds. 5G O-RAN can be that seed, the reference implementation for cloud-native that’s fully budgeted and approved. The techniques operators can learn in O-RAN can then spread to the rest of the network, and eventually be the collective infrastructure and software framework for carrier cloud and all its possible applications.

That’s the opening to the last of the possible real impacts of 5G, and in particular the use of 5G in both wireless and wireline replacement missions. What is a “service”? Is it a connection delivered in a specific way to a location (wireline) or user (wireless), or is it something that’s fuzzier, and because of the fuzz more potentially exciting in its definition?

We’ve already glimpsed some of this service fuzz in WiFi calling. Many mobile network plans (and phones) will support making and receiving calls and messages on a mobile number while connected to WiFi rather than to traditional cellular service. This often takes some special technology, but suppose 5G in general or O-RAN in particular were used for both connections?

Let’s start by acknowledging that 5G mm-wave technology might or might not be implemented using the same technology (notably O-RAN) as mobile 5G. If it is not, then for 5G/FTTN hybrid applications, the use of 5G doesn’t impact this particular point. If it is, then do we have a notion of a “portable” service?

5G might be used to create what’s effectively a mobile demarcation (mmarc) that’s independent of the delivery mechanism. Such an mmarc, when the user is truly mobile, is supported by the user’s 5G service. If the user is at home, the mmarc might map through WiFi back to the 5G-to-the-home service. All that is logical, but suppose that the user was in someone else’s home, or in a specialty public hot spot?

5G could allow us to define service to the mmarc rather than to the connection point, which means that a user who had a high level of service might still enjoy it if they were in a location whose service was limited to a lower speed. I go visit Charlie (with proper COVID precautions), and he has 30Mbps broadband via 5G to his home. I have 100Mbps broadband, so when I visit Charlie, I’ve got that capability on my device, over his WiFi and his connection, because the 5G delivery to Charlie’s home keeps him at 30 Mbps while letting me ride up to what I’ve paid for. Maybe I pay for this “mobile flexibility” and maybe Charlie has to offer it, but it could be done.

We could also see public areas like airports offering “rateless 5G”, which takes on the personality of the user’s plan whoever the user is. Something like this could be a promotable feature for 5G in hospitality settings, versus WiFi. A complete notion of service portability could transform everything, and spreading 5G concepts fully through the network could be a step toward getting to that, not to mention a step toward a true “network-as-a-service” or NaaS.

5G symbiosis and NaaS is just a slightly deeper model of NaaS than SD-WAN offers, a way to make a virtual network more virtual by taking it downward a bit. Could this combination be the future of networking? Could be.

The US may get funding from a proposed infrastructure package to “close the digital divide”. While this could be a boon for areas that lack good broadband services, these sorts of initiatives have been tried before, and some technologies have failed. Others may improve broadband based on current definitions of “good” quality, but have little chance of meeting future bandwidth standards. Finally, it’s obviously possible to set standards for quality broadband too high, or too low. What can be said about some ideas?

Light Reading offered a piece on improving broadband to rural areas, and there have been stories on AT&T’s opposition to having universal fiber included in a broadband infrastructure package. I’ve blogged several times about 5G mm-wave and even mobile 5G as a possible broadband technology solution to areas with limited services today, and on some of the challenges. I’ve also chatted with players who want to offer rural services, and vendors who want to help. It’s been interesting, but somewhat disheartening.

The first point is that I’ve found little awareness of the critical role that demand density plays in planning services in thin-demand areas. Imagine that you take ten miles of fiber and plop it down at random on the world’s landmass. If you hit Antarctica, you likely won’t find anyone living along the footprint of that fiber, so obviously there’s no profit to be made and nobody to serve. If you land in Singapore, you could find millions of dollars in network spending along your route, and other possible fiber landing sites will offer something in between.

Infrastructure pays back in proportion to the revenue that a given footprint will deliver from whatever lives or works within it. Where population density is low or household capacity to exploit broadband is limited, it will be a challenge to come up with a technology that can create a service footprint that’s not totally dependent on taxpayer subsidies. That’s important because I doubt that the government’s appetite for subsidization is limitless.

Another factor I’ve found isn’t generating much awareness is the risk of having a broadband subsidy end up creating toys for the wealthy at taxpayer expense. Let’s suppose there’s a fancy log home on the side of a lonely mountain in the west. The home cost millions, its owner is rich. Does a broadband subsidy fund fiber to this location, traversing perhaps tens or hundreds of miles of wilderness?

But the big problem I’ve seen is a lack of a vision of the service goal itself. We do need some standard for what constitutes broadband “right”, if we decide broadband is a right. AT&T, in their often-quoted and usually maligned view that 10 Mbps is fast enough for upload, is suggesting a standard, but is it a good one? As we’ll see, they’ve also suggested other numbers. If we were to say that 1G symmetrical was the standard instead, we’d be citing a broadband right that current broadband customers in most areas can’t even buy, and where they can, don’t elect to pay for. Even 100 Mbps may be more than you can really justify as a “right”, and setting a standard there limits technology choices.

I’m not going to argue public policy; let the wonks who specialize in that take that on. My point is that the characteristics of the service area and the definition of the service goal combine to set the requirements for a “useful” broadband technology. Whatever policy we elect to follow, it has to be grounded in these realities.

Wireline, meaning all services delivered over a physical media like copper, CATV, or fiber, has to be used to create a path from a point where there’s capacity to deliver, and each user. The further the users are from each other, the more difficult it is to do that economically. That’s the reason why we have under-served areas to begin with, and these areas are the ones I’ve characterized as having “low demand density”. If the service goal is set high enough, even to the 100 Mbps symmetrical goal that some lawmakers are proposing, it then becomes very difficult to achieve the goal if demand density falls far enough. Let me offer some model data.

If we take the demand density of the US as a whole as being 1.0, then we could say that where demand densities are on the order of 10, it’s possible to offer PON fiber, with the 100 Mbps symmetrical target, to about 80% of customers without significant subsidies. If you cut the demand density in half, the potential fiber penetration drops to about 65%. Cut it to 2.0 and things drop to 50%, and by the time you get down to a real rural level (0.1), only about 10% of users could be served with fiber without significant subsidies.

To put some sense to these numbers, Verizon’s territory has a demand density of nearly 11. AT&T’s has a demand density of about 1.3, there are only 12 states with demand densities higher than 5, 23 states with demand densities higher than 2, and 4 states with demand densities of 0.1 or less. It’s also generally true that the cost multiple for fiber service to those who cannot be served will rise from roughly 1.8x for demand densities of 10, to 24x for demand densities of 0.1, and as you drop from there, costs explode. This means, IMHO, that providing 100 Mbps symmetrical FTTH as a baseline service would not be feasible; the cost for fully serving users would be too high.

There are some caveats to this point. First, as demand density falls below 1.0, the way that the demand is distributed becomes critically important. Some rural areas have most of their population concentrated in small towns, and these towns are suitable for FTTH providing that the equipment cost is controlled. That’s likely the truth behind Adtran’s recent announcement of a thin-area FTTH cabinet. Second, where demand isn’t concentrated, satellite broadband may be the best solution, providing the service targets are adjusted to fit that service’s capabilities. If that becomes the presumed ultra-out-there solution, then the cost premium to serve the remainder of a low-density area would of course decline. My model says that for demand densities of 0.1 or less, fully two-thirds of users on the average would probably be served by satellite broadband at a reasonable cost, reducing the overall cost to connect them.

However, the service target of 100 Mbps symmetrical may have less impact that one might think. Obviously, it doesn’t matter too much for those users connected by fiber; the only value of lowering the service target is to qualify a technology other than fiber. CATV cable could meet a 100 Mbps download standard with reasonable costs, but there could be challenges with symmetrical service.

DSL, in my view, has little chance of meeting that 100 Mbps goal no matter how you maintained the loop plant; only shortening the loops drastically would help. You can’t do that in rural areas because population density is too low and you’d need to feed DSL from more cabinets than you can afford to connect. To make DSL work, you’d have to go to the AT&T suggestion of 25/3 Mbps. That would be about as far as DSL would go, and my model says that even that would be achievable on only about 60% of loops.

Deploying more fiber to nodes would be a better approach, providing you had a good way of getting the connection from the node to the home. This is where 5G could come in, but it’s difficult with the data generally available to determine exactly what the impact of either mm-wave or 5G mobile in a wireline replacement application might have. The problem is that the number of 5G nodes (towers, in effect) depends on the distribution of the prospective users, not just area demand density, because 5G mm-wave is short-range (likely maximum is 2 miles) and 5G mobile distribution would depend on getting a profitable number of users within the range of the tower. The maximum would be limited by the overall capacity of 5G at that point, of course, in combination with the selected service level.

That leads us to the last point that’s come out of my conversations. Everyone seems more interested in qualifying for subsidies than in delivering utility. Worse, as I’ve suggested already, it probably doesn’t matter. We cannot deliver broadband at a level that brings rural areas into what would even approach functional parity with dense geographies using DSL. The largest portion of the cost of providing new medium for broadband delivery is the cost of the installation, including of course the path from the nodal point to the customer. If DSL won’t work then new media is required, and unless we want to propose more subsidies than I believe are likely to be accepted, that means using RF for that node-to-customer connection.

RF doesn’t mean things like WiFi meshes, either. As rural density reduces, the space between users increases beyond WiFi range, and it’s not possible to mesh the sites through WiFi. Every user would have to be supported with a feed to their WiFi network, which puts you back where you started, without a way to create that feed economically.

This is a 5G problem to solve, if solution is to be had any time soon. It’s time we stop diddling on the topic and look at the situation realistically. It’s also time for those policy wonks to consider how much subsidy money will end up wasted if they don’t mandate something sensible, for a change.

Open-source technology is making headway in networking despite some very visible failures. In many respects, that’s good news, but the way the success is evolving may point to some challenges for the industry down the line. The biggest challenge it faces is its relationship with traditional network standards and industry group activity, and the second-biggest is a loss of a collective vision to built toward.

In my last blog, I noted that the traditional generational, long-cycle, standards-driven processes that have defined network infrastructure progress have to be set aside in favor of something more cloud-like. I also noted that while open-source is a part of the answer on how software-driven transformation should take place, there are issues already arising. We can see some of them in the shifting attitude toward open-source networking elements.

In my surveys of enterprises, I find that 100% of them rely “heavily” on open-source software by their own definition. Among network operators, only about two-thirds say that’s true, and of that group, well over 80% say their reliance is in the domain of the CIO, meaning somewhere in their operations software. Neither enterprises nor network operators say they rely heavily on open-source in networking. In the former group, less than a fifth say they have any significant reliance on open-source networking technology, and even in the latter group, less than a third say they rely in any sense on open-source.

An interesting corollary to that point comes when you ask how much they expect to rely on open-source in networking in the next five years. Enterprises will then say they expect heavy reliance about half the time, but 100% of network operators think they’ll be relying heavily on open source for networking in that five-year future. Why is there such a difference, and what’s going to change that makes the future look brighter for open-source networking?

One thing that I’ve noticed, and that the referenced article suggests, is that open-source networking projects tend to have a fairly narrow scope. That’s also true for cloud projects, but we have a lot deeper and broader experience pool with the cloud than with networking. The reason scope is important is that most business problems or service requirements span a fairly broad functional area, which means they’re likely to require multiple open-source elements to fulfill requirements. That, in turn, means integration, which turns off enterprises more than it does network operators, at least in the planning stages.

One reason why operators are more likely to accept a multi-element, integrated, solution is that they have specific players offering the integration. All of the major cloud providers and all the major software players who offer open tools also offer a “telco” version. The likely reason that’s the case is another reason why operators accept the integrated model of open networking; enterprises see themselves consuming the results of a shift to open-model, open-source, networking, as services. Operators have to create the services from the open-model elements.

You could make a strong case for the position that the way open-source projects in networking are developing directly promotes operator reliance on “master software” players like IBM/Red Hat, HPE, and VMware. They assemble the pieces and create a sense of ecosystem for what could otherwise be seen as a disorganized set of developments. However, after-the-fact integration doesn’t bring pre-development insight to the picture. Can open-source network software projects create the best strategy without design-level integration of the separate concepts. You can build a boat from car parts, but you could surely build a better one if you knew, before you got the parts, that a boat was the goal.

We could go back to the cloud to rebut this, though. We’ve had a bit of a wild-west cloud development environment for a decade, and it’s worked to provide us with excellent tools, right? Yes, but it’s taken time. Kubernetes, for example, has evolved significantly under market pressure, through the addition of features to the software project itself, and through adjacent projects. Could we have done better had we understood where we were going from the first?

There’s also the question of just how many insights about open-source software we can safely transfer from the cloud to networking. I think one of the major problems we have in open-source networking is that proponents have, from the first, assumed that their needs were different and that they couldn’t simply endorse the cloud approach. Networks were “different”.

Whatever network insights might have been brought to cloud development were diverted into network-specific projects. NFV was originally charged with identifying standards, but the first steps they took disqualified almost all the work the cloud had done, and that could have been adopted by reference. Instead, new stuff was defined. Networking is a smaller-scope opportunity than the cloud; can we expect a thriving community of developers to build a network-specific strategy from open-source software?

The answer to the latter question may be the critical point here. Telcos have already demonstrated that they not only tolerate but encourage long-cycle technology evolutions. For vendors who hope to profit from change, that means long delays in revenue realization for any efforts they put forth. That discourages participation, but it also narrows project scope so that things focus on quickly achievable things that are easier to introduce because they require less, in terms of displacement of assets or changes in practices.

The edge trends that the article cites may be the pathway to hope for both vendors and operators. It’s easier to adopt new technology at the edge because edge technology is deployed per-user, and there doesn’t have to be a systemic shift in strategy to accommodate it. However, there are signs that if the edge has a role in the creation of a service rather than a point-of-connection feature, then some of that agility in terms of replacement or introduction of edge elements may go away. Is NaaS, because it’s personalized, something created only at each user’s edge point? It depends on how it’s framed.

There are also questions on the value of harmonizing on an operating system or other “platform” tool. We have many Linux distros and Linux has prospered. Would something like SONiC actually have to emerge to create open edge platforms? We already have Linux running on very small white-box elements. The key things in an edge platform might be things that lie above the operating system, that control the operationalization of an edge-centric service. Even there, the requirement is less that we standardize on a specific product, than that we standardize on a specific set of APIs.

Which really leads us to what’s now called “intent modeling”. An element in an intent-modeled world is a black box that presents APIs. Anything inside the black box that presents the required APIs is conformant. Which, of course, means that the thing we should be looking at to promote open-source is first a great intent-model API definition set. Lay out how the new element is expected to react with other cooperating elements, and you give development a specific goal set to meet. You also require a top-down vision of functionality and relationships, which is where everything should be starting in any case.

Intent modeling could ensure that open-source software meets the most critical test, which is the test of value. What’s the point of software-centric network infrastructure if you constrain it to work exactly like a box network would? But there has to be some framework in which software elements cooperate to form services, as there is for boxes. If intent modeling creates such a framework with its APIs, then it’s done a major service for the industry.