Bracing the backend for virtualization

John C. Tanner
30 Jul 2014

Software-defined networking (SDN) and network functions virtualization (NFV) are both riding pretty high on the hype cycle. It’s not hard to see why: both technologies represent a major shake-up in the networking world by virtualizing control processes that will give network operators of all stripes unprecedented service agility and operational flexibility, and throw in badly needed cost optimization in the bargain.

Not unexpectedly, most operators are approaching SDN and NFV with caution rather than enthusiasm. And for a number of good reasons - it’s a fledgling technology still in development, and it’s based on a concept that’s alien to the average traditional telco mindset. There’s going to be a lot of tire-kicking before SDN and NFV become anywhere close to mainstream.

For those who have been prodding and poking and test-driving various SDN and/or NFV solutions, a significant adoption barrier has already been identified: namely, their creaky old backend.

It’s a familiar story. For years now, long before anyone had ever heard of SDN, operators have found themselves under increasing pressure to roll out new services faster and more flexibly - and put them all on one bill instead of deluging customers with multiple bills for separate services - only to find that their legacy OSS/BSS systems weren’t up to the challenge. Plenty of backend solutions have emerged to address the problem, and many operators have evolved their OSS/BSS systems in various ways.

But the onset of SDN/NFV places even greater demands on the backend. Put simply, most if not all OSS/BSS systems are not designed to deal with the performance requirements of network virtualization - so much so that it’s become a roadblock for operators who want to deploy SDN/NFV, says Ian Watterson, VP and MD of Asia Pacific for CSG International.

“We hear many of today’s CSPs acknowledge that their current B/OSS environments inhibit the launch of - and slow time to profit for - new services,” he says, pointing to a senior executive from AT&T in the US as an example. “He said that in order to deploy ‘elastic network services,’ AT&T will have to retire more than 1,000 OSS applications - that’s significant. He also categorized billing and provisioning as two areas currently inhibiting the process.”

Lack of flexibility

The main reason current OSS/BSS systems can’t cope with SDN and NFV is because the need for the latter is driven by operators’ needs for operational flexibility and business agility, says Dr Eyal Felstaine, VP of product strategy and head of NFV for Amdocs.

“This means a flexible and agile BSS and OSS that allows for short product lifecycles, rapid product launch processes and automated just-in-time capacity management,” he says.

The thing is, many OSS systems just can’t do that, says Tanja De Groot, OSS product manager for NFV & SDN at Alcatel-Lucent.

“The challenges are mainly linked to the fact that OSS systems of today are not designed to cope with the level of automation, flexibility and programmability demanded by NFV and SDN for service fulfillment, nor with the high volume and volatile nature of (near) real-time changes to be managed to assure and auto-repair services in the hybrid NFV/SDN and current network and IT environment,” De Groot explains.

Related content

No Comments Yet! Be the first to share what you think!
This website uses cookies
This provides customers with a personalized experience and increases the efficiency of visiting the site, allowing us to provide the most efficient service. By using the website and accepting the terms of the policy, you consent to the use of cookies in accordance with the terms of this policy.