Suppose that network operators and vendors accepted the notion that profitable “new” operator services had to be built in a network-integrated way, like IMS/EPC or CDN? What would the framework of these services then look like? How would they have to be offered and used? It’s time to dig deeper into a network-operator-centric view of services, something not so much “over the top” as on the top—of the network.
We have to start this from a regulatory perspective because that frames how operators have to consume technology and price and offer services. Right now, regulators tend to see services as “Internet” and “not-Internet”, with very different rules applying to the two. The most significant truth is that Internet services are bill-and-keep and pretty much everything else is subject to normal global settlement practices—everyone in the service food chain shares the retail pie. There are two factors that complicate this division—one favorably and the other unfavorably.
The unfavorable one is that regulators tend to warn operators against creating new services outside the Internet that offer Internet-like capabilities. In the US, the FCC has warned explicitly against that behavior, and in Europe regulators have also signaled their concern in this area. That means that it’s not feasible to think of a new services as being an outside-the-Internet application of IP technology. If it can be done over the Internet and is offered to consumers, then it’s probably close enough to being an Internet service that separating it based on the mission and expecting no net neutrality rules to apply is a dream.
The favorable thing is that regulators have accepted some aspects of Internet service where separation of features from neutrality regulation is already in place. Service control planes such as those offered in IMS/EPC are one example, and content delivery networks (CDNs) are perhaps a better one. Most traffic delivered to Internet users is content, and most content delivered is handled by a CDN. CDN providers (Akamai, for example) are paid for their service by content owners and sometimes by ISPs, so we have a model in CDNs where a network service feature is paid for by someone other than the Internet user who consumes the service the features is a part of. That, to me, establishes the CDN as the model for what a new service feature has to look like.
A CDN is a combination of a control-plane behavior (customized decoding of a URL) and a cache, which is a hosting/server behavior. Think of a CDN as being a set of microservices. One is used to get an IP address that represents a content element in a logical sense, not a resource that’s tied to a specific IP address, server, etc. The other is simply a delivery engine for content elements.
Let’s now look at how this approach could be applied to a new opportunity, like IoT. For the example, let’s assume you’re in a vehicle driving through a city and you want to get traffic status/guidance. The CDN model says that you might make an information request (the content URL click analogy) for traffic data ahead of you (the cache analogy). The control-plane element has to know where “ahead of you” is, and from that knowledge and perhaps some policies on how distant “ahead” might be (just because you’re heading north doesn’t mean you want to look at traffic in Greenland!) associate your request with the proper resource.
The approach here, both for CDN and my IoT driving example, can be described as “I know what I want and don’t know where it is”, which is a request for a service and not a resource. That’s the critical point in a regulatory sense. Resources are on the Internet; services are integrated with it. It’s my view that explicit following of that model would be the pathway to solving the regulatory problems with advanced services.
Let’s look at the technical framework here. We have two components to deal with—a kind of service control plane and a set of feature microservices that are used to compose overall service behaviors behind the scenes. These two pieces are critical, I think, not only for positioning our network evolution and transformation in a regulatory sense, but also for framing what SDN and NFV should evolve to support.
Both SDN and NFV advocates push their wares in the context of current services; we create “new” services only in the sense that we use new mechanisms. In a future of “on top” services we use new mechanisms but to support new service behaviors, behaviors that are more agile because they’re signaled dynamically. In this model, we justify SDN and NFV to support that agility, to enable the two-tier control-and-feature-plane model.
This is not to say that that we wouldn’t use SDN and NFV for current services, or couldn’t. The goal would be to frame those services in the on-top model described here. In short, what we’d be doing is creating a framework for services, a kind of next-gen architecture, that harmonizes with regulatory reality and at the same time builds a model for both current and next-gen services.
The service signaling part of this model can be based on the CDN model and/or on what I’ll call the “IMS model” meaning the model used in mobile networks for subscriber and mobility management. What that means is that the signaling plane of a new network could be reached either because it was extended explicitly to the subscriber (phone registration, dialing, movement) or because it was “gatewayed” from the customer data plane (clicking a media URL).
The hosted feature plane of the model would differ from Internet models in that it would not be addressable on the customer data plane level in a direct way. You can’t pick your own CDN cache point. Instead, the service feature would be connected/delivered through a gateway, which we could visualize as a kind of virtual microservice.
Let’s look at IoT in this context. We presume that there is a “traffic” service that is represented on the Internet. The service offers users the ability to either assess a current route or to optimize a path to a destination from a specified (or current) location. Our hypothetical driver would exercise this service to see what’s happening ahead, by clicking on what would look something like a content URL. The service request would be gated into the signaling plane, where a suitable route analyzer can be found. This gating process could involve access to the customer records, a billing event, etc.
The route analyzer would create a response to the request and return it to the service in the form of the results of the click, just like a CDN does, and the result is then available to either a mobile app or a web page display. Any of the data paths (except to the customer via the Internet service) could be prioritized, built with SDN. Any feature could be deployed with NFV. So we have blended IMS and CDN principles into a single model, used our new network technologies, and created something that could dodge neutrality problems.
“Could”, because if operators or others were to adopt this model the wrong way (letting priority pathways bleed onto the customer data plane) they’d be at risk in at least some major regulatory jurisdictions. You can’t get greedy here and try to re-engineer the Internet without bill-and-keep and with settlement for traffic handling.
The point of all of this is to demonstrate two things. First, we can make “new services” work even with neutrality/regulatory barriers in place. Second, we have to think about these new services differently to get us there.