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.