dimanche 31 décembre 2017

5 lessons for a successful virtualized EPC RFP

vEPC or virtual Evolved Packet Core is the most important platform in the telecom operator architecture.

EPC is the core network of LTE system and responsible of handling the payload efficiently from performance and costs perspective. Modern EPC architecture platforms separate the user plan from the control plane in order to make the scaling independent. Thanks to this architectural split, the operators can dimension and adapt their network easily.

Many operators have started virtualizing some not data intensive applications (IMS,TAS, PCRF, ..) and are looking today to continue the virtualization effort across the data core functions.

Here is the list of some common functions that are becoming candidates for virtualization within the packet core:

·       Packet Data Serving Node Gateway (PGW)

·       Serving Gateway (SGW)

·       Mobile Mangement Entity (MME)

·       Policy and Charging Enforcement (PCEF)

·       Policy and Charging Rules Function (PCRF)

·       Evolved Wireless Access Gateway (eWAG), ePDG

·       Firewall (FW)

·       Deep Packet Inspection (DPI)

·       Value Added / IP services (Video/Content Caching/Optimizing)

·       Carrier Grade Network Address Translation (CGN)

·       Routers

·       Switches

·       Load Balancers (LB)

·       Session Border Controller (SBC)

·       Security Gateway (SecGW)

I have been involved, since last few years, in many RFP process to evaluate vEPC readiness and maturity for a virtualized deployment. I can confirm that vEPC including data intensive functions (SPGW) is the most challenging VNF for VIM layer including Openstack and VMware VIM products.

From functional point of view, the major change is the split of user plan and control plan. Many vEPC products still adapting their new software architecture to benefit from this new model in term of scale and dimension. Actually, virtual EPC vendor are focusing on virtualization: How to build a virtualized vEPC product taking on consideration performance, scaling, redundancy and throughput per VNF component or VM.

If today you manage to lunch a vEPC RFP, here is some lessons to consider during your long journey.

Lesson 1: Split the technical RFP in two domains:  Functional domain and Virtualization domain

This first step is quiet important from operator and vendor point of view.

Since vEPC is most about how we can implement a virtualized EPC, it is very important that your vendors receive a spate and clear virtualization part.

Why this split is very important?

Usually, EPC solution or others telecom product has been packaged as End-to-End solution. The vendor respond to your RFP by a solution that includes software, hardware and services.

Within the NFV shift, vEPC vendors will propose only a software package within the requested professional services without proposing a hardware solution.

Of course, I am supposing here that operator had already started his virtualization journey and had already selected and defined his virtualization strategy and reference architecture.

Lesson 2: Define virtualization strategy for your vEPC.

Since we are speaking about VNF, ETSI NFV has defined a set of rules and standard to follow in order to facilitate the adaption of cloud native application in the telecom world.

After deciding to split the virtualization requirement from the functional requirements, virtualization team should be able to include specific requirements to measure later the maturity of vEPC solution that will participate in the company RFP. 

To define the set of requirements, virtualization team should listen carefully to Core network team and well understand their sizing and dimension for the coming 5 years.

Site selection, type of deployment (central, regional,), hosting strategy, security challenge, network architecture are a very hot topic that should be discussed in order to include the right requirement in the RFP document.

Lesson 3: Define your on-boarding process

Although virtualization bring many benefits to operators in term of resources management, flexibility and scalability. It complicates integration process and request more effort between different vendors ( VIM vendor, VNF vendor).

Its quiet important that on-baording process is well developed before submitting your RFP. Why ?

On-boarding phase defines the step of VNF installation and instantiation in your cloud infrastructure.

Usually, VIM vendor with joining workshops with VNFs vendor masters on-baording. ETSI NFV has defined a VNFD as an important element that facilitates what VNF is requiring from the underlying infrastructure layer. I have been involved in many on-boarding projects, VNFD is not enough to define the global network architecture across different sites.

It is important that your vEPC RFP include On-boarding professional services from infrastructure and VIM point of view. vEPC vendor will get the opportunity to understand your process and the integration effort to offer as response of their proposed solution.

Lesson 4: Virtualization dimension file

In the virtualization world, we adapt new rules for dimension: vCPU, vRAM, vdisk, vNIC

Your dimension file that will be part of the files requested in the response of vendors should be similar and follow the same shape. Why ?

Regarding the operator throughput required per site or per VNF, the vEPC vendor will size his VNF components to respond to your scenarios. Virtualization team requests to have a detailed sizing information per VM to allocate the right virtualization resource. Virtual machine dimension parameters are :

·       vCPU

·       vRAM

·       vDisk

·       vNIC

For data intensive VNF, its very recommended to include in the dimension file rows that specify the requested acceleration technics from the virtualization layer.

Lesson 5: Acceleration technics for data intensive workload

vEPC is composed of many data intensive and user plane VNFs.

These kinds of VNFs require acceleration technics that should be set in the virtualization layer in order to not affect performance.

Virtualization team should include annexes describing different acceleration technics that the underlay virtualization layer is able to provide for data intensive workload.

SR-IOv, OVS-DPDK, VMXNET3(VMware) and SMartNIC are different technics that accelerate data forwarding packet from virtualized network layer.

VNF are also including and enhancing their software to be more adapted to virtualization environment( less OVS hope, DPDK VNF enable,..)

Aucun commentaire:

Enregistrer un commentaire