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

	During the last decade globally Telco’s have seen an outburst of Data traffic almost quadrupling every year however during same Telco’s were not smart enough to monetize the value gain which moved more and more upwards in all this time. This left Telco’s to just act as a Pipe Line having less visibility on Services and offerings from OTT. To make Telco Business and lucrative just like Software companies back in 2012 the Telecom industry leading by many T1 Operators started a move toward Virtualization/NFV I to convert legacy business to a SaaS company. The initial response by whole Telecom Industry was to on-board the Band wagon and start NFV by building their Centralized Telco Data Centres and evolve their Core Networks to the Cloud, however five years from start still Operators find it hard to solve the issues and it seems Idea of Central Service hosting in Cloud cannot deliver desired business results till date.   Why MEC is so important   ETSI launched ETSI MEC group in Sep 2014 to find another way to transform Telecom Operators as Software companies by capitalizing on their Close proximity to users and services and further to Open their Networks to Public Cloud Hosting, 3rd Party Application development to meet Enterprise and Industry verticals requirements.    Historically Telco’s all applications on their Network which make it difficult to launch applications/services specially Targeting Latency, High Bandwidth, Real Time, Proximity awareness, MEC will address all those challenges to offload the Edge Services from the Network.   In this paper I want to share our work experience at ETSI for MEC architecture and it can solve pain points of Telecom Operators to take Off the Network Edge services.   How to Plan Edge Data Centres   The answer varies as it should mainly align with PE-AGG or Access transport facilities. My understanding is that every Aggregation site is an Edge DC as an Operator start to deploy MEC Applications however as more and more complex use cases will deploy like Remote factory, Video Analytics it means to deploy Edge more close to Users. Our combine understanding in ETSI is that for such cases must be required more in Enterprise than for normal users so for complex cases Edge DC can be Enterprise on campus facilities.     So to answer your question of how to deploy an Edge DC, focus on Edge DC < PE-AGG> now and on Access CO or Enterprise on premises later.      How to develop Cost Effective Solutions for MEC   I think this point is complex primarily because legacy vendors are not open to optimize cost metrics for an Agile MEC Site. As an example currently Operator have two choice. First is to select Silow solution where all functions including Complete Openstack can be bundled in One Rack of about 2~10 Servers but the cost of deploying and later operations of this silow approach make it difficult to be adopted widely.   I think if you want to build a scalar solution for this best is to be based on Akraio www.akraino.org and StarlingX www.starlingx.io. I think our direction is clear. If the MEC Site is an Edge DC the MEC can deploy multiple Racks around 4~100 servers, if MEC Site an Access CO it should be 2~10 Servers, for enterprise case it can be 1~2 servers a case most likely in Access Networks.     Again this is my understanding that Open Stack Remote compute project is not something possible to meet Edge MEC requirements especially due to limitations on Rabbit MQ bus and agent scaling hence StarlingX seems like best solution to evolve. A typical Controller /Compute architecture for StarlingX is seen below.      How to solve integration and automation needs for MEC    What we can expect for MEC is huge distribution around 1000 Sites for a typical medium scale country, require integrate management for whole umbrella and ZOOM based operations which are simple, scalable and automated, fast integration and innovation and optimized cost. All of these challenges are addressed or seems will be tacked by Akraino project, so what is Akraino. It will primarily address following points Develop API for Edge VNF’s Middle Ware SDK’s to open cloud to 3rd party Cross platform testing  Full CI/CD pipeline for MEC    Let us try to understand the Akraino High Level Architecture as seen below.      I think in current phase of MEC must be based on deployment and integration and less on integration and automation so still StarlingX is important to watch, however with early 2020 as ONAP based offerings coming to market the Akraino will be important focus, similarly Calico for simple SDN integration and Testing framework are three targets for Edge Deployments for smooth integration.   How to define an Independent Testing Framework    I think this point is complex primarily because still no compromise has been made between definition of Standard and Open. In the Era of NFV industry already faced lot of issues and finally it is not possible to use 3rd party tools in NFV environment for E2E testing. In other cases we know of situations where a mature commercial E2E testing company fail to offer this unless the VNF or VIM/NFVO layer is from them or their preferred partner. The E2E testing for a wide variety of MEC Applications is a further complex topic because the Applications diversity and expected Eco System will be far more complex. This is a hot topic and is under discussion in MEC0025 to be released in March 2019.   In a nutshell except for UE interface which covers FR cases of MEC tests the most relevant test interfaces are Mp1, Mp2, Mm5, Mm6 as marked below.       The biggest question for MEC E2E testing will be API standardization especially for Inter-operability cases (Which is almost there) and Package standardization (Which is still depatable) as most of work of Akraino Agile integration require exposure of above two capabilities of the platform for E2E testing. The second main concern is commercial offerings, believe or not since testing and its conformance require thorough understanding of all components therefore from vendors I have not seen a strong desire to build such agnostic tools leaving Telco’s to open source methods. This area is still debatable and we are continuously working with ETSI and over peers to materialize this with the introduction of MEC in our network.   How MEC can capitalize on Power of Virtualization and Orchestration     In order to get response of this common query I shall recommend audience to please refer to GR MEC 0017 talking about introduction of MEC in NFV environment and since MEC can be on NFV platform or on independent platform like a 3rd party Cloud so to build architecture it is key to develop a solution agnostic of Platform. Therefore the right strategy will be that MEC apps / MEC platforms / MEC Platform Managers is most effective if deployed as VNFs on top of a common NFVI. However, it emerged that a plain NFVO does not fulfill with all the requirements for MEC, and thus it must work in collaboration with a MEC Application Orchestrator (MEAO) to accomplish the MEC-specific tasks. But for the tasks that are the responsibility of NFVO, we do have a common NFVO for MEC and NFV through Mv1 interface. I think as per ETSI architecture early aspirant will not deploy Mv1 with MEAO but with E2E SO primarily because it makes more sense for Digital OSS transformation as well as to deploy single layer of Cross Domain Orchestration in the network.    Capitalizing on Public Cloud strength to offer MEC applications   As per our understanding MEC as platform do support communication between APPs in the edge cloud to the remote cloud which includes Public Cloud. Also, it supports relocating apps from the public cloud to the edge, provided they fulfill with the descriptors and the packaging required and defined by the MEC system. I think this is an exciting Era for Telco’s since we can host Edge Applications on Edge or Access CO’s DC and can use applications on Public Cloud which are more mature now to offer it, what it means is clear SAP, Financials, Geo Location and guess every service Can come to Telco’s in 3~5 years.     To summarize I think in this paper I have tried top 5~6 issues that will help architects how to smoothly evolve the Network to MEC and finally to expose network to 3rd party applications and developers to take best possible business benefit through edge.    Having said author believes still the MEC industry is in infancy at least from commercial offering point of view. Discussion of how to build the right use case is a big topic that requires deep analysis of macro situation and technology alignment.    Still the issues related to Lawful enablement of MEC applications is not mature, we have seen stern specifications of LI and normally it is expected all new Applications /technology abide by it. Obviously this approach need further study as robust and Agile MEC applications need analyze a unique, simple and nimble way to meet regulatory requirements.   Again security is a big concern in MEC in the same way it forced Telco’s to slow evolution to Cloud it will try to slow down MEC. On top of it MEC due to its inherent design is a more concerned platform for security considering a) MEC Applications require cooperation between Private and Public Cloud will require more detailed analysis of both the Architecture (In terms of Network, VNF etc) and b) API’s and End Points Security to develop a Secure and Robust solution. Finally since definition of MEC do involve Access CO or Radio Site means MEC need to address security concerns from IoT, Sensors and a range of networks. These missing topics I shall try to cover in some future Papers.    1. https://events.linuxfoundation.org/wp-content/uploads/2017/11/Akraino-Technical-Overview-OSS-Shane-Wang.pdf 2. https://slideplayer.com/slide/11834236/ 3. https://www.networksasia.net/article/iot-5g-and-significance-fiber.1515370319 4. ETSI GS NFV-TST 002: "Network Functions Virtualisation (NFV); Testing Methodology; Report on NFV Interoperability Testing Methodology". 5. A special thanks to my colleagues in ETSI ISG Alex Reznik (HPE), Sami Kekki (Huawei), Fabio Giust (Athonet), Michele Carignani (ETSI)