NFV - The dilemma of Telco Operators (Part 1)

Feb 1, 2016
NFV is one of the booming technologies and trends in 2016 and has been there for
the last couple of two years dragging the Telco operators from their Stable, i'd
say traditional deployments to a complete virtualized environment with the Network
Functions (Applications) such as GGSN, SGSN, EPC, SBS, etc. completely decoupled
from Hardware or Bare-metal.
Network Function Virtualization (NFV) offers a way to design, deploy, & manage
Network Services via decoupling the Network Functions from proprietary Hardware
enabling them to run in software environment.
It is not an easy decision taken by Telco Operators to start the virtualization
journey as there are many challenges that arise as concrete facts and not even as
foreseen risks.
Adopting the Operators' point of view, I will list all the challenges that we see
throughout a chain of LinkedIn posts.
1. Exposure to new players in the market (A brand new big List!)
In Telco networks, The old good Core vendors are well-known (Ericsson, Nokia,
Cisco, & Huawei). List can cater for ZTE also.
So, What is the case with NFV/SDN?
Let's have a look on the below digram with a try from my side to map every vendor
to its specific area referenced to ETSI Architecture Reference model
It ended-up with this messy digram illustrating how messy the reality is!
Excluding some Openstack distros & Security VNF Vendors, we end up with Twenty X
vendors!.

The problem arises when IT Vendors and open source solutions providers try to
approach the Telco Technical departments to market their Cloud/NFV Solution with
the Lack of knowledge about the Special Telco Requirements, workloads, &
Corresponding Data Center Architecture.
A lot of IT concepts are simply not applicable in a Telco environment.
Confusion arises also with the partnership of those new players (e.g. Redhat &
Mirantis) with Telco vendors which is a way or another to make the customer
confident to acquire a fully vertical NFV Architecture from one vendor. So you
choose Ericsson for VNF & Infrastructure and you get Mirantis in VIM. Same with the
case for Cisco/Redhat, Nokia/Redhat & Cisco/Vmware.
However, Open source SW providers always stress that they are not only bound to
certain Telco Providers. You see it in the case of Redhat being marketed by both
Cisco & Nokia as their recommended Openstack VIM. So, If you are having an RFP for
NFVI, you will get Redhat proposal three times. One as a standalone vendor (VIM
provider) and the other two as a VIM component for Cisco & Nokia NFVI Solutions!

The Confusion doubles with the concept of the openness that those vendors adopt ..
We "Telco-minded" are more to standards rather than to Open Interfaces and APIs. So
If you can't guarantee the Integration to others systems with standard reference
points and you just keep saying that you are "open" then we are in a big risk! at
least from the Telco perspective.

One of my big issues personally with the Cloud providers is the trend of
criticising ETSI ! Yes, Standards are not mature enough same as NFV technology but
capitalising on your Cloud experience or IT background doesn't force us to jump
over the concept of Standardization that we rely on, to operate our Telco Network.
Instead of criticizing, I am looking forward for all vendors to contribute heavily
in ETSI same like they do with OpenStack & OPNFV because once the NFV is
standardized "Somehow" , Organizations will be confident to start the Journey.
ETSI Phase 2 is anticipated and l hope that it will bring more Standardization to
the whole NFV Architecture model.
Finally, It is a long journey that even we as individuals have to take it order not

be left behind. You have to adapt and you have to read and work individually and
within your Organization to build a strategy especially that at this stage, we all
still have inputs.

Thank you and see you in the next post.

NFV - The dilemma of Telco Operators (Part 2)

Feb 15, 2016

Taking a further step analyzing the Telco Operators perception of deploying Telco
Cloud and for the Network Functions Virtualization (NFV) in general, I am resuming
the talk and explaining below one of the main concerns.
2) The strive to preserve the Carrier Grade performance
I can describe the Telco applications with some simple terms such as Latency-
sensitive, E2E Carrier Grade, Fully Redundant, High Signalling, Different
Workloads, Very High Throughput, Transcoding, & Encryption.
Regardless of what the evolution is, Telco Operators are not willing to loose the
carrier grade performance that is there with the legacy Networks. This is why Telco
Operators get stuck with messages communicated by vendors with E2E System
Integration profile. In a way or another, the message is as follows
“..You will never be able to achieve your E2E KPIs if you build your Telco Cloud
using A la carte model from different vendors, we do recommend to have the Full
vertical NFV architecture from one vendor...”
Ok... But Isn’t that contradicting with the Concept of virtualization? Network
Functions being decoupled from HW giving customers the opportunity to avail
different services from different vendors on let’s say a pool of HW Resources that
is not vendor-dependent?!
Adopting this approach and relying on one Telco Vendor to build the cloud simply
means that I am taking the "black horses" vendors off the list.. Those are the new
vendors that has a broad portfolio of only VNFs independent of the infrastructure
such as Affirmed & Mitel.
The Risk of Multi-vendors NFV Deployments
The IoT between Vendors is an important step prior to any Commercial deployment
though 3GPP Standards is there.

It is definitely not a relieving story if the new network ends up with virtual MME
from Cisco, HW Infrastructure from Nokia, SW Distro (Fusion Sphere) from Huawei!
Though every vendor might be excelling in its domain but an NFV architecture with
multiple “competitors” doesn’t sound like a nice idea. Actually with no standards,
it is more like what the lady is trying to do in the photo!
So, let me give you an example to show some of the operational concerns..
Suppose that an operator with a Multi-Vendor NFV Architecture has experienced a
degradation in a KPI such as the Successful Attachment with some causes related to
Congestion or CPU utilisation.

How to troubleshoot that? If the Operator is relying on Managed Services then

which vendor is supposed to troubleshoot & own that? The VNF Vendor? The VIM
provider? Maybe, the Infrastructure vendor?
How the the different vendors will cooperate? In a similar environment where
multiple vendors exist, they simply work in isolated islands.
One more point that applies even for the One-vendor show, For an operator to trust
a fully virtualized environment, it is not enough that vendor provides an OSS
Solution taking care of VNFs KPIs & Counters and a distinct solution to have a
similar function on the VIM & bare-metal level.
Telco Operations Team need a solution that correlates the Counters from different
domains (VNF, Hypervisor, & Infrastructure) of the ETSI Architecture Framework..
This is my advice to all vendors, you need to have this correlation.
In the next Post, I will talk about a crucial challenge which is the Roadmap to 5G
and how the NFV is contributing.
Thanks and see you in next post.