Home | Reports | Technical Documents | Tech-Blog | One-Shot Gallery | Korea ICT News | Korea Communication Market Data | List of Contributors | Become a Contributor |    
 
 
Section 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/Video Streaming IoT SDN/NFV Wi-Fi KT SK Telecom LG U+ Network Protocol Samsung   Korean Vendors
 
Real World Private 5G Cases   4 Deployment Models On-Premise Cases 5G Core Control Plane Sharing Cases

5G Core Sharing Cases

   
 
Private 5G Deployment   • Private 5G Frequency Allocation Status in Korea  South Korean government's regulations on private 5G and KT's strategy for entering the market
Cases in Korea   Private 5G Operators |   SK Networks Service (SI) Sejong Telecom (Wire-line Carrier) KT MOS (Affiliate of KT) • Newgens (SI) • NAVER Cloud more >>  
    Enterprise DIY |   Korea Hydro & Nuclear Power (Power Plant) Korea Electric Power Corporation (Energy) • Republic of Korea Navy more >>
 
CHANNELS     HFR Private 5G Solution (my5G)       my5G Solution Components       my5G Key Features        my5G Resources        my5G News          
 
banner
banner
NFV/SDN Platform or Application Driven? Set Right Focus to reach the final Goal
March 26, 2018 | By Saad Sheikh @ Saudi Telecom Company (saads83nfv@gmail.com)
Online viewer:
Comments (1)
11

We are pleased to share with you all an interesting article contributed by Saad Sheikh who is the Chief Architect Consultant in Saudi Telecom Company primarily responsible for Network Deployment and planning for CSP Digital transformation involving domains of NFV, SDN, Telco Cloud, 5G. Always interested in those disruptive technology driving the industry transformation, Author hails from Telco CSP background and since 2013 working on Telco Cloud domain including Amazon, Huawei, Mirantis, VMware, RedHat etc.

 
 

Saad Sheikh

Chief Architect – Consultant NFV, SDN, Telco Cloud, 5G

at Saudi Telecom Company (STC)

 

All Articles by Saad Sheikh

 
     
  How to contribute your article to Netmanias.com !  
     
  List of Contributors  

 

 
     
 

 

As industry enters the Industry4.0 and many world leaders as WEF talk about their country commitments and support for Transformation it is evident we are entering an Era of disruption at scale. However still the true benefits of CSP transformation are not quantified and it is not sure what is told in theory has same significance in practice?

 

So where is the real problem, we still remember NFV was initially set to reduce CAPEX of CSP’s facing decline revenues but later we found every white box cannot fulfil the requirements and NFV COTS cost is tenfold the cost of IT servers so CAPEX dream was never conceived correctly, recently though even ETSI formed new ISG’s for using OPEX as main driver for NFV.

 


but did this the real issue. It actually depends on how NFV is conceived.

 

In whole industry how to take the journey has two approaches.

 

Build Platform first or Build Application first, the proponents of former are main Cloud companies who want to see application as IT service which do not fits well for the Telco Service. After all in CSP’s the revenue is from Application not from platform.

 

The later claims application is the key and platform must be built for it. In a short term this looks more appealing as every CSP want to virtualize a PNF right so is more logical that a heavy vendor with the idea of application leading means more sense but what lies beneath the iceberg is questioning self are we building a platform that can meet future requirements in at least 5-10years. Unfortunately many CSP’s are not long sighted on it primarily due to only one reason that they never faced such issue. So right example to see will be Facebook. If finally Mark decided to take FB to the communication industry (whose signs are quite strong) how they will build. Obviously make a platform irrespective of service. Here I am not saying service is not important but I want to say that Platform must serve every service.

 

An example will make things easy to grab, Vendor X have its VNF (VDU design) if ask platform how to develop will give requirements of NUMA Placements, Pass-through, Bonds and forwarding plan design that will somehow can limit future hosting of new vendor VNF. Similarly for DC L0 the COTS/SAN dimensioning will be in-accurate. E.g based on m1.tiny and m1.large flavor size and VM placement last time I observed multi-vendor scenario may lead to not use your infrastructure more than 65%. This is a big compromise.

 

So it looks promising if we build platform first and irrespective of service, I do understand some limitations will come based on service type like Media and control plan require a different HA /AZ but at scale NE’s from same service class must be supported by a common Reference Architecture. Especially if along the Journey same platform will be open to IT and to Programmers the key is to control the platform not application.

 

In my later blog I will explain how the platform can be planned specially for ICT converged case and how it will help you size the DC and reduce CAPEX but for now we just look down on key Functions of an ICT Platform

 

1. Unified O&M


Rally, Ansible, 3rd party tools, Drive train, vROPS, Functest, Dovetail how to unify them around a simple one click architecture is key and realize config automation. Similarly platform must support same cluster for both Telco and IT DC’s as one platform.

 

2. Supports all Performance (not high performance)

 

Instead of high performance the platform must support all applications with different performance

 

3. Multi Tenancy (with minimum HA/HG’s)

 

vApps from both IT and Telco can onboard using same process and standardized API’s. It looks difficult till micro services architecture comes in place around 2020

 

4. Auto scaling

 

The use of AI in later years in NFV/SDN is only possible if auto scaling works well in scaled network. I mean in many DC’s where resources are in pool. I do not see a quick solution soon because of Super VIM architecture that still need to fit well with concept of hyper scaling. In the current auto scaling as defined in Open-O standardization looks like a issue and auto scaling parameters in VNFD of VNF1 can be very different from VNF2 at least this is our experience. I think ONAP Beijing release will address this issue somehow along the road as confirmed by Confluence team to me last week.

 

5. Distribute DC

 

The main theme is how NFV will work if for same VNF the VM’s are placed in different DC’s, how service will scale and how NFVO will real time optimize NFVI resource, this idea need more refinement because one VIM only controls one DC Infrastructure at this time.

 

Sincerely the list is quite long but above 5 are the key points for Platform if somehow it needs to meet at least next 5 Yr requirements. My next blog should try to find out how to actually plan the NFVi and can we say that VNF requirements of Server/Storage is enough?

     
Juha @ FusionLayer via LinkedIn 2018-03-26 17:34:16

Multiple DCs introduce NFV-I silos that must be synched up for apps and services to be deployed by orchestration. This is solved neither by platform nor applications, so my advise would be to place the focus on networks that bridge these two domains. 

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
Related Contents
 
 
 
 

[HFR Private 5G: my5G]

 

Details >>

 

 

 

     
         
     

 

     
     

Subscribe FREE >>

Currently, 55,000+ subscribed to Netmanias.

  • You can get Netmanias Newsletter

  • You can view all netmanias' contents

  • You can download all netmanias'

    contents in pdf file

     
     

 

     
         
     

 

 

 

View All (854)
4.5G (1) 5G (101) AI (7) AR (1) ARP (3) AT&T (1) Akamai (1) Authentication (5) BSS (1) Big Data (2) Billing (1) Blockchain (3) C-RAN/Fronthaul (18) CDN (4) CPRI (4) Carrier Ethernet (3) Charging (1) China (1) China Mobile (2) Cisco (1) Cloud (5) CoMP (6) Connected Car (4) DHCP (5) EDGE (1) Edge Computing (1) Ericsson (2) FTTH (6) GSLB (1) GiGAtopia (2) Gigabit Internet (19) Google (7) Google Global Cache (3) HLS (5) HSDPA (2) HTTP Adaptive Streaming (5) Handover (1) Huawei (1) IEEE 802.1 (1) IP Routing (7) IPTV (21) IoST (3) IoT (56) KT (43) Korea (20) Korea ICT Market (1) Korea ICT Service (13) Korea ICT Vendor (1) LG U+ (18) LSC (1) LTE (78) LTE-A (16) LTE-B (1) LTE-H (2) LTE-M (3) LTE-U (4) LoRa (7) MEC (4) MPLS (2) MPTCP (3) MWC 2015 (8) NB-IoT (6) Netflix (2) Network Protocol (21) Network Slice (1) Network Slicing (4) New Radio (9) Nokia (1) OSPF (2) OTT (3) PCRF (1) Platform (2) Private 5G (10) QoS (3) RCS (4) Roaming (1) SD-WAN (17) SDN/NFV (71) SIM (1) SK Broadband (2) SK Telecom (35) Samsung (5) Security (16) Self-Driving (1) Small Cell (2) Spectrum Sharing (2) Switching (6) TAU (2) UHD (5) VR (2) Video Streaming (12) VoLTE (8) VoWiFi (2) Wi-Fi (31) YouTube (6) blockchain (1) eICIC (1) eMBMS (1) iBeacon (1) security (1) telecoin (1) uCPE (2)
Password confirmation
Please enter your registered comment password.
Password