Getting closer to the buyer and to the dollars is always good advice in positioning a product or service. For network operators, that means looking at what services they sell, and for network operators reviewing the potential of SDN/NFV, it means looking at how these new technologies can improve their services. But “services” doesn’t necessarily mean “all services.” In my last two blogs, I used a combination of operator comments to me on their view of NFV’s value and future, and Verizon’s SDN/NFV architecture paper, to suggest that operators were looking at NFV now mostly in a service-specific sense. Holistic NFV, then, could arise as an almost-accidental byproduct of the sum of the service-specific deployments.
One question this raises is just how far “holistic NFV” can go, given that early projects might tend to wipe low-hanging benefits off the table. Another is whether silos of NFV solutions, per service, might dilute the whole holistic notion. I don’t propose to address either of these at this point, largely because I’ve talked about these problems in prior blogs. What I want to do instead is look at what “service-driven NFV” might look like.
Service-driven NFV has to start with service objectives, first and foremost. There is relatively little credibility for capex reduction as an NFV driver overall, and I think less in the case of service-driven NFV. Few “services” offer broad opportunities to reduce capex, broad enough to impact the bottom line and justify taking some risks. There are some credible opex benefits that might be attained on a per-service basis, but again the issue of breadth comes in. In addition, there’s a risk that specialized NFV operations within a single service could create islands of opex practices that would end up being confusing and inefficient. That means revenue-side, or “service agility” benefits would have to be the key.
That’s a conclusion consistent with both my operator survey and the content of the Verizon paper, I think. Operators told me they liked mobile services and business services as NFV targets, and their specific comments focused on portal provisioning and customer care, agile deployment of incremental managed service features, etc. The big focus in Verizon seems to be the same, with the specific adjustment that “mobile” probably means “5G”. In fact, about half of the over-200 page Verizon paper is devoted to mobile issues and applications.
Everyone these days thinks “services” mean “portals”, and that’s true at one level. You need to have self-service user interfaces to improve agility or the operator’s customer service processes are just delays and overhead. However, a portal is a means of activation and presentation, and that’s all it is. You still need to have something to process the activations and to generate what you propose to present.
If customers are going to have a portal that provides them both service lifecycle information and the ability to make changes to services or add new ones, then the critical requirement is to have a retail representation of a service that can be decomposed into infrastructure management, including the deployment of virtual functions (NFV) and the creation of ad hoc network connectivity (SDN). In the Verizon paper this is accomplished through a series of hierarchical models. There is a model that represents the service as a portal or operations system would offer it—the retail vision. Another model represents the connectivity options available from the underlying infrastructure, and yet another the “abstract devices” that create the connectivity. The models build up to or decompose from (depending your perspective) their neighbors.
Implicitly, the service-driven vision of NFV would start with the creation of this model hierarchy. The retail presentation (analogous to the TMF’s “Product”) would decompose into functional elements (TMF Customer-Facing Services?) and then into the infrastructure connectivity elements (TMF Resource-Facing Services?) that would be built from the abstract devices. To make this process amenable to portal-driven ordering, you’d need the model hierarchy to define the service based on all of the possible infrastructure options that might be associated with a given order, meaning that the model would have to support selective decomposition based on a combination of the order parameters and the service-versus-network topology-to-infrastructure relationships. A portal order could then initiate a selective decomposition of the model, ending in a deployment.
Automated deployment doesn’t address all the issues, of course. A user who depends on a portal for service orders and changes is likely to depend on it for service status as well. Thus, it’s reasonable to assume that the retail model of the service defines parameters on which the service is judged by the buyer—the SLA. The model would then have to create a connection between these parameters and the actual state of the service, either by providing a specific derivation of SLA statistics from lower-level model statistics, or by doing some sort of status query on an analytics database.
Both the deployment and lifecycle management activities associated with service-driven NFV pose a risk because a “service” may not expose the full set of requirements for either step, and thus new services might not fit into current models of NFV as operators seek to expand their NVF story. Put another way, each service could end up being a one-off, sharing little in the way of software with others. It’s even possible that early services would not develop generally reusable resource pools.
vCPE is a good example of this. There is no question that the best model for managed service deployment would be an agile CPE device on which feature elements could be loaded. Every model I’ve run on this suggests that it would always beat a cloud-hosted model of deployment for business service targets, which is where most operators want to use it. Obviously, though, CPE resources to host VNFs wouldn’t be generally helpful in building a resource pool. Less obvious is the fact that software to deploy VNFs on CPE wouldn’t have to consider all the issues of general pooled-resource infrastructure. There’s no selection optimization, no connection of features through the network, and the derivation of management data is much easier (the CPE device knows the status of everything).
A general solution to service-specific deployments via evolving SDN/NFV technology could be created by expanding the OSS/BSS role, but Verizon’s architecture seems to focus on the opposite—containing that role. Operators seem to think that pushing more details of SDN/NFV into the OSS/BSS is a bad move overall, and the TMF has yet to publish an open model that supports the necessary absorption. At this point, I think that’s a dead issue, which is why I appended the question-marks on TMF references earlier.
A final consideration in a service-driven model of NFV is whether new services might be a major contributor. Even in mobile NFV, Verizon and other operators seem to think that it would be difficult to drive NFV without a broader mobile change, like 5G, to help bear the cost and justify the disruption. That suggests that a green-field service would be even more helpful. IoT is the obvious one, and Nokia has recently suggested it thinks that some medical applications (which could be considered a subset of IoT) could also drive network change. However, focusing on NFV as a platform for new services would be facilitated if there were a generic NFV model to build on, and getting that model in place may be more than new services can justify.
