What the future service plane will look like

In my blog of April 22, 2021, I postulated there would be three “planes” in a 5G network, the top plane of which being the “service plane”. I mentioned it a bit but didn’t get too far into it, despite the fact that if there’s a broad opportunity for new telco revenue to be had, the service plane is a likely place for it to be built. I’m trying to get operator information on the service plane topic, but with little success so far, so I’m going to outline the hopes and promises here, offering some of my own views. I’ll revisit the topic later when I have more data.

Functionally, the service plane represents the set of features and hosting facilities that are associated with building a value-add to the basic mission of connectivity. We have some very limited examples of service-plane behavior in content delivery networks (CDNs), which provide a combination of content caching and URL redirection to ensure video quality of experience (QoE). It’s also possible to conceptualize modern OTT services as being “service plane”, but I’m suggesting that because those services are really just network destinations, as users are, we avoid doing that.

The technical distinction between a service-plane offering and an OTT offering would be that the former involves coordination between the delivery of something and connectivity. In the case of a CDN, users ask for content based on a generic source, and are directed to the appropriate cache point. A more general difference could be that a service-plane offering is offering not a specific connection, but a specific experience, and that’s the definition I’ll adopt here.

There are some areas where operators see beyond-connectivity opportunity, but only some of these would fit my service-plane definition. Cloud and edge computing, in the basic form of offering hosting, is an OTT service because today’s cloud model shows that it’s consumed that way now. IoT could be mapped to my three planes in multiple ways, and so it’s probably a good way to dig a bit into what we can know about the service plane today.

Most operators are still fixated on the idea that IoT will bring revenue by having people or organizations pay to network their “things” rather than their personal communications devices. This model of IoT is a connection service, consuming resources in the data/user and control planes only. The obvious problem is that the great majority of IoT applications and devices wouldn’t require a for-pay 5G or any other kind of connection service; building WiFi or one of many local IoT protocols would serve (and are already serving).

What would create a service-plane relationship for IoT would be having operators make some aspects of IoT into a CDN-like service. That doesn’t mean that the service would have to relate to content delivery, or even that it would have to be available on the Internet, but it could be. There seem to be ## broad options for service presentation available, and we’ll look at each.

The first option would be that the service would in fact be Internet-visible, as a CDN is. There could be, as there is with CDN, a generalized URL associated with it, and that would decode to a specific service instance based on the location of the user, the parameters of the service request, etc. This would be a reasonable way of presenting a service that would be expected to link to a web page for access (as CDNs are) and it would make service availability widespread. There would have to be some mechanism to journal use so the operator who deployed the service could get revenue from it, and the link with the Internet could make monetization problematic in the shifting sands of net neutrality.

The second option would be to expose the service as a function or component, designing it to be composed by someone into a retail offering rather than being a retail offering in itself. Within this option are two forks, one that still uses a URL and makes the function visible, but with access control, and the other one that uses an API and exposes the service inside a composition sandbox, something like the way that functions should be used in NFV. The challenge here is creating the composition sandbox and the rules for federating the use of the service, so that the owner can be paid for usage.

The third option would be to treat the service as a cloud component, a web service of the kind already offered by Amazon, Google, and Microsoft (among others). In this case, the service lives inside a cloud service, one created by the service owner or by a third party, and would be paid for as any cloud service is paid for. The operator who took this path could use one or more public cloud providers to host the service, but would have to pay them a part of the revenue the service would generate (actually, they’d likely receive something from the public cloud provider in settlement, since users would pay the cloud provider). If the operator self-hosted, they’d be creating their own cloud-like service framework to contain their offerings.

We could debate which of these options would be best, but before we do that we have to consider another factor, which is how we get to service-plane behavior in infrastructure transformation. It seems pretty clear to me that things like “carrier cloud” or “edge computing” are simply abstract descriptions of the outcome of a transformation, not a driver to transform. The real driver in transformation today, the only real driver, is 5G O-RAN. This is an architecture that is popular with operators, and that supports a budgeted mission. How will it impact our three options?

I think it forecloses option one, which I think was foreclosed anyway. Operators aren’t going to frame elements of their transformed infrastructure as being part of the Internet, for fear that Internet settlement rules (which often mean no settlement at all) and sharing rules would end up ceding the fruits of their investment to others. The choice is then between the second and third options, and I think the choice will be made by default, by whether operators do in fact get 5G-as-a-Service from public cloud providers.

The problem with the third, public-cloud, option is that the operators investing in 5G are trying to avoid creating their own public cloud by hosting some of O-RAN on current public cloud providers. That decision would cede the way 5G functions were virtualized to the public cloud giants. Those players will obviously choose option 3 because it perpetuates their current business model.

If the operators see this risk, and respond by insisting that either they don’t use public cloud services at all, or use them only in basic IaaS-hosting form, then the operators will shape function virtualization. However, given the operators lackluster performance in framing their own strategies, the real decision may be made by the vendors who would supply that virtual infrastructure framework.

This is a high-stakes game. If the Dell, HPE, IBM/Red Hat, and VMware product teams get their acts together, they could own this space, which you may recall could add a hundred thousand data centers worldwide in a decade. I’m seeing some signs that the upside for a winner is now being recognized, but not so much that the way that 5G and O-RAN are being treated by the vendors, and positioned for the market, has tracked opportunity realization. I suspect that’s going to change, perhaps as early as this year.

The author of this blog is Tom Nolle, President of CIMI Corp