I’ve been recently in a set of conversations at work about service enablement in carrier networks. Somewhere in the middle of the discussion someone inevitably asks: “How does your proposal integrate with the OSS ?” and down the rabbit hole we go…
The dissonance between my personal views and what seems to be the majority of the industry starts with the name of the conversation. The meeting invitation will invariantly be about “NFV” (that is Network Function Virtualization). I strongly dislike the acronym. In my mind it conveys the meaning that the issue is how one migrates existing network equipment to a x86 based CPU as a cost saving measure. Defining the problem that way misses the forest for the trees, in my opinion.
When it comes to wireline services, carriers drive most of their revenue from enterprise customers. These customers are now being served by a range of infrastructure (e.g. Amazon), software (e.g. Salesforce, Workday) and services companies that are capable of rolling dozens of new offerings a year.
Defining the problem as “Virtualization” misses the mark. The problem definition is how can carriers manage to roll out new value added services in time frames that are comparable to over-the-top offerings. They may not ever achieve the agility of an Amazon or Google but they need at least be within an acceptable range if that enterprise revenue stream is not going to be fully captured by over-the-top players.
The correct problem definition is, in my opinion, “how to you roll out a new service every 3 months ?”.
It is easy to come up with some self-evident “DOs” and “DON’Ts”. Chiefly on the “to be avoided” list is: form a design team to create a proposal on how to build an infrastructure that can provide support any arbitrary service.
Realistically, the only way to achieve the goal stated above is to take an experimental approach: take one concrete service; remove all obstacles out of the way and get to the point where the new service can be validated by customer. Scale is a problem to be solved only for services that customers are willing to pay for; over designing a solution before validation is not cost effective.
There are a set of principles that quickly become evident by chasing a concrete goal:
- One can’t wait for hardware to be procured; the initial instances of a service must be deployed in a small set of regional resource pools (i.e. data-centers) that consist of general purpose hardware;
- The service must be self-service and automatically provisioned; humans can’t be involved in the provisioning and operation: 3 months is not enough time to device operational procedures and train an operations staff.
The latter point brings us back to the OSS. A significant piece of the answer around OSS integration is that the service should not be managed or operated in a traditional way. The standard mode of operations requires an integration cycle that is 12 to 18 months at best; that is just not acceptable in the current environment. As much as that may be a culture chock, tools need to satisfy business goals.
Of course there still needs to be a billing system. There still needs to be a way for customer support to understand what services are enabled for a particular customer and what is their status. But these will most likely have to be developed as a parallel system to the existing OSS.
This is not a very popular answer. It is however the logical conclusion of following our problem definition.
The reality is that cloud based services and wireless devices have been slowly eroding the traditional value that carriers bring to their larger enterprise customers. “NFV” doesn’t do anything to address that problem. Rapid service enablement may…