Why NFV projects are failing to deliver in Telco networks
To witness how NFV vendors are re-writing the rules of IT infrastructure you need look no further than Salesforce or Microsoft 365. We can also observe the enviable growth of Netflix who utilise Amazon AWS to successfully deliver their latest hit series with the help of NFV technology.
The orchestration of elastic on-demand processing power and bandwidth delivered to providers in a pay-what-you-eat model is unstoppable, and that’s without considering the potential savings made by companies not having to provide or maintain their own networks in order to deliver services.
But does it follow that you can apply this technology to core telecom network infrastructure, and if so why are we increasingly reading reports by industry analysts regarding the lack of any live Telco network NFV rollouts?
“May you live in interesting times”… That apocryphal Chinese curse provides a fitting label for the 2017 telecom market, as we find ourselves mired in an unprecedented mess — one that’s bad for business for everyone in the entire supply chain of next-gen communications…
The root cause? Virtualization! (In both its NFV and SDN flavors.) For years, the industry has been “bigging up” virtualization as the next great telecom revolution”
Steve Saunders, CEO/Founder of Light Reading
Is all the scepticism perhaps down to NFV vendors and service providers trying to force the proverbial square peg into a round hole?
Technology Virtualisation To Date
Looking at the underlying technologies that have been successfully virtualised over the years both databases and client server technology stand out. Databases have been providing clustered, mirrored solutions for decades, allowing for instantaneous replication, providing of course that you have enough storage. I think it’s fair to say that client server technology, again developed decades ago has been nailed, and that both these technologies have been fundamental in driving the exponential growth of the Internet way before NFV appeared.
However, add virtualisation to the mix, and its ability to seamlessly increase processing, memory and storage on demand and you begin to see why the growth in the likes of Netflix and Salesforce has been so dramatic in recent years.
When demand for the latest series of “Game of Thrones“ rockets in Norway Netflix can launch more servers (client servers as well as physical servers) to support viewers streaming the very latest episode. Essentially they’re offering the same service to vast numbers of customers at varying times.
What about Telecoms?
As NFV proves its worth for Internet giants, can it be applied as successfully and seamlessly within telecoms? In todays Telecoms Service Provider networks:
• Subscribers can initiate fundamentally different services, i.e. voice, messaging and data services.
• Subscriber initiated calls immediately connect the subscriber to one or more recipients in real time.
• The recipients can exist outside their service providers network.
Some of these services clearly exist outside the client server model, however they’re not delivering a uniform service to multiple recipients and therefore present a different set of challenges.
The additional challenges and complexities are managed by core network products including switches, STP’s, signalling controllers, DSC’s etc. Telco networks have been designed to revolve around central control points where the orchestration of services or intelligence is not only managing the real time end-to-end connection of subscribers but referring to OSS/BSS infrastructure to ascertain subscriber profiles and business logic in order to optimise routing.
Network design has focused on managing this enormous degree of complexity by separating functionality; Signalling from media, transport from call control, and with IMS architecture going a step further by separating out the application layer.
Vendors have spent decades developing centralised signalling controllers that scale, load balance, provide 99.999% reliability through redundancy, highly sophisticated routing, network troubleshooting via user interfaces, and Element Management Systems that allow a sophisticated and fine granularity of control.
These core network signalling elements can of course run in an orchestrated, virtual environment, however the similarity with the Netflix model where you launch additional identical server function to support increased demand just doesn’t apply to these core telecoms network elements.
So what is NFV good for?
Where the NFV model can apply within telecoms is in the host of other elements connected to the centralised controllers. Those elements that process the media (voice and data) can be virtualised and instantiated as demand dictates as they’re simply “dumb” resources within a network that can be easily replicated. Furthermore the surrounding OSS/BSS infrastructure is a good prospect for NFV, in particular HLR/HSS databases.
An interesting scenario we’re currently working with is that of an MVNE (Mobile Virtual Network Enabler) whose business model is to enable MVNO’s (Mobile Virtual Network Operators). At its simplest level an MVNE has its own network infrastructure that it connects to mobile operators on one side and multiple MVNO clients on the other. In the world of virtualisation would it not make sense to simply replicate this infrastructure for each MVNO client? For all the reasons advocated here we are advising that this isn’t the optimal approach but instead are looking at a solution whereby the main signalling intelligence of the network remains as a single instance in the core of the network and a separate HLR/HSS instance is provided for each MVNO.
Of course let’s not ignore that for an operator to outsource its underlying network infrastructure to a third party, an NFV provider could well be a very desirable option. Here the NFV provider would operate and manage the hardware and network resources whilst their orchestration environment allows the operator to manage their network elements, in turn reaping similar rewards and benefits seen in the IT world, namely:
• Reduction in support and maintenance costs
• Operator focuses on core business strengths
• Commercially moving network infrastructure costs from a CAPEX based model to an OPEX model
This all makes a lot of sense and here at Squire Technologies we continue to work with our clients to address the challenges going forward, such as:
• Can other vendors within their network provide solutions as software only?
• If running on a platform like Amazon AWS then you’re going to need to run applications on commercial off the shelf hardware (COTS). Is this possible?
• Do all vendors support the orchestration standards provided?
The reason for such slow progress in NFV rollout within the telco industry is that operators are being touted “over virtualised” solutions. From the outset they’re trying to virtualise functions that do not fit and realistically don’t need to be virtualised. In doing so they’re over complicating the proposition and creating undeliverable projects, which in turn is feeding scepticism from within the industry.
It could be also be suggested that operators need to take a step back and define clearly what the end goals for implementing virtualised environments are, and crucially what cost savings and process improvements they’re hoping to achieve.
Finally they need to take a pragmatic approach as to which parts, if any, of a virtualised solution they adopt to meet their goals.
Download this article as a PDF document HERE.