Developing Edge Solutions for Telcos and Enterprise

According to Latest market research most of 5G Edge use cases will be realized in next 12-24 months however time to act now for Telco’s to leave them a chance , reason is very clear this is enough time for Hyperscalers to cannibalize the market something we already witnessed with OTT’s in 3G and with VoD and Content Streaming in 4G

Below are my thoughts on

  • What is Edge definition
  • What is Edge Differentiation
  • Why Telco should care about it
  • Why Software architecture so vital for Telco Edge Success

5G Site Solutions Disaggregation using Open RAN

According to Latest Market insights the RAN innovation for Telecom Lags behind others initiative by 7years which means call for more innovative and Disruptive delivery models for the Site solutions specially for next Wave of 5G Solutions .

However to reach the goal of fully distribute and Open RAN there needs to build a pragmatic view of brown fields and finding the Sweet Spot for its introduction and wide adoption .

Here are my latest thoughts on this and how Telecom Operators should adopt it . There is a still a time for industry wide adoption of Open RAN but as yo will find time to act is now .

What you will

What you will learn

  • Building Delivery Models for Open RAN in a brownfield
  • Understand what,when and how of Open RAN
  • What is Open RAN and its relation with 5G
  • Current Industry solutions
  • Define phases of Open RAN delivery
  • Present and Next Steps 5. Architecture and State of Play

Using Cloud and AI to Differentiate your 5G Investment

Source: Disney

In a recent Webinar about how to build a successful 5G networks a question that took my mind was .

“How successful we can be if we address a fundamentally new Problem using a new Technology if we still use old principles to build our Telecom Networks and with out disrupting the supply chains”

I think the answer for these type of questions in the context of 5G fundamentally will depends on following two key initiatives.

  1. How to use Radio spectrum to gain strategic advantage over competitors
  2. How to use Cloud to gain advantage for 5G

The Radio Spectrum is a complex topic primarily driven by many factors like regulatory and existing use of Spectrum making real 5G a slight different than what is really possible with Spectrum of today . This alone is not enough as Smart cells vs Wifi6 will be again something that will really depend on Spectrum use of 5G .These details i will leave it for now for future discussion and want to focus on Cloud and how really it will make your 5G successful.

During our recent work with in ETSI NFV Release4 Sol WG , GSMA and LFN CNTT we have discussed and agreed on a number of ways really Cloud can support you to differentiate your 5G network . Knowing this can be a real game changer for Opcos who are investing in 5G and Future Networks


A homogeneous Infrastructure Platform on 5G that can be used by all applications like traditional 5G CNF’s , MEC , Developer applications and any legacy IT /OTT applications that are required to be offered to users . One such example is OpenShift or VMware Edge and Last mile solutions using technologies like CNV or VCF7.0/NSXT3.0 that will build the edge clouds in an automated manners and enable day 2 through standard tools whether use VM or containers or BM’s as a baseline architecture

A uniform IPI that can be deployed using standard Red Fish solutions such as the one from HPE really will make is possible to build 5G using the Clone technology as used in most automotive industry today and that really enabled them to produce with minimum toil


Scalability in the last mile is the most important criteria for 5G Success . For example a compute solution that can scale and can provide power to process really all sort of workloads at the Edge is certainly a make or break for 5G . When it comes to Data one such example is storage and Disk , with solutions like RedHat Ceph3.0 that supports compression from Q3 2020 using its blue store offering and can integrate CephFS with NFS support makes the real convergence possible .

Convergence vs Automation

IT SRE and DevOps has gained lot of traction recently and this is not without a reason . It has certainly reduced the CFO bills and that is why the Telco’s want to achieve the same . However the requirements of workloads are really unique and that makes us to understand that real automation with out standard modeling is never possible .

On the Cloud side we can make use of TOSCA models together with solutions like automation hub together with secure catalog and registry means we can do both modeling for varying workload requirements and to automate it in the same fashion . Further we can do some advanced testing like the one we have been doing in PyATS

Registries and Repositories

The concept of 5G factory that we have been rigorously trying to achieve in Middle East Telco projects are really made possible using secure registries like Quay for containers , Dockerhub and its integration with Jenkins and CI/CD tools for Telco.

It is no surprise if i tell you these are most important differentiators as we introduce public clouds for 5G


The programmability of Immutable infrastructure is the biblical principle for 5G Networks . Both Service Mesh , NSM and Server less are deployed as operators which a practically CNI programs that makes your infra follow software YAML instead of tight and coupled instructions .Further to that the Operator supports full automation of both day0 and day2 Infrastructure tasks .

For K8S it is currently supported while for VM’s it will be available fully in Dec 2020

Openshift service mesh for 5G CP CNF’s is possible today with

  • Istio
  • Grafana
  • Prometheus
  • Kiali
  • Jaeger

Further to that today we faced a number of issues in Docker to Telco and use of CRI-O and PodMan will certainly support to advance the 5G .

“Podman is more light weight compared to CRI-O so you should expect it better performing on 5G Edge compared to PoDman .

5G Integration

Redhat Fuse online is one of solutions which abstracts Infrastructure and make it possible to integrate developer , integrator and tester using one tool . Except of container it also standardized your VM’s . E.g VM in Openshift running FTP service and that make it possible to run on native containers itself .Fuse Online provides a data mapper to help you do this. In a flow, at each point where you need to map data fields, add a data mapper step. Details for mapping etc

Red Hat® Fuse is a distributed integration platform with standalone, cloud, and iPaaS deployment options. Using Fuse, integration experts, application developers, and business users can independently develop connected solutions in the environment of their choice. This unified platform lets users collaborate, access self-service capabilities, and enforce governance.

An SDK is definitely helpful for 5G platform specially when it comes to open your networks for the developer who need .NET or JAVA . Quarkus from RedHat is a Kubernetes-Native full-stack Java framework aimed to optimize work with Java virtual machines.

Quarkus provides tools for Quarkus applications developers, helping them reduce the size of Java application and container image footprint, eliminate programming baggage, and reduce the amount of memory required.

Advanced Cluster Management

With huge number of 5G sites and future scnerio of site sharing between operators . It will be a real need to deploy Apps and manage them in a hybrid Cloud scnerio and nothing explains it better than burr sutter demo at the RedHat summit . A cool video from RedHat team is available there if you want to learn it more

In a summary you can mange

  • 5K+ poD’s
  • Create clusters in hybrid cloud like AWS,GCP,Azure, Bare metal and On prem
  • Policy management
  • Secure deployment by validating YAML and images using Quay/clair sorted by Labels
  • Possibility for developer to create and deploy policy using GUI

Above all RHACM makes is possible to measure SLA of Clusters and Optimize workloads e.g shift to other clusters in an automated manner .Certainly a Cool thing for 5G to serve heavy lift and Content driven applications

Heavy Lifting of Workloads

The proponents of silo vendor solutions often tell us that 5G Base band processing and e-CPRI heavy lifting with parallel processing will make X-86 a non practical choice to adopt classical cloud way .

However the latest Intel atomic series with FPGA’s and NVIDIA GPU’s means we can not only solve the Radio issues such as the ones we are trying to solve in Open-RAN but will enable to introduce latest technologies like AI and ML in 5G era networks . Those who are more interested in this domain can refer to latest work in ITU here

For ML/AI use cases in 5G there are many made possible in both Telco and vertical industry like Automobiles, warehouse monitoring etc today using GPU operator , Topology manager like shows visibility in to GPU ,NIC,BW,Performance etc.

Open Policy Pipeline can optimize the ML model itself using analytics functions of the Cloud

When it comes to Cloud value to data scientist in 5G using platforms like OCP or HPE Blue Data as follows

  • Anaconda tool sets for programming
  • Jupyter notebooks
  • CUDA and other similar libraries
  • Report on both Log and Policy compliance
  • Tekton Pipeline in OCP for CI/CD of ML/AI use cases
  • Models are made in Jupyter by scientists while it is triggered in the Tektron pipeline

Finally using OCP Open Model Manager we can Register, deploy and monitor open source models in one central environment, uniting data scientists and IT/DevOps.


The most important takeaway is that if we have to take full advantage from 5G we not only need to follow 3GPP and traditional Telecom SQI’s but also those advantages offered by Cloud . This is only way to not only manage a TCO attractive 5G but also will enable to introduce both Niche players and new services that will be required to build and drive a Post COVID-19 world economy .

Running Containerized Applications in a Cloud Environment

The use of containers and kubernetes in the industry has made a decent progress since the first time it first made its way back in 2013-2014 . However there is still lot of enigma around its use in a production environment . Recently there is a OpenDev workshop organized by Openstack where many domain experts from the industry including Telcos,vendors,system integrators and Enterprise spent a handful of time to clarify many of mis-conceptions and share experiences about how to use in a large scale Enterprise of Telco Environment .

The Purpose of this paper is to share some key insights around this .

How to use containers

There are different industry use cases that need to support different scnerios of deployment . For example some common views are follows

Telco Architects think the containers must be deployed on top of Existing Clouds mainly Openstack or VMware VCF (Through Pacific Project)

Enterprise folks believe containers should run with or without Kubernetes . Mainly wide use support on bare-metal is required

Application or IT guys think everything should run on Kubernetes (A.k.A K8S) . This is same view as the Developers

Build and Test Images

To build images there are different approaches and best approach is to give as many as possible flexibility to the Developer by using base images from where to build . However some best industry recommendations are as follows

  • Start from carrier grade images like CentOS . Although it is a little Fat image but it will offset time in troubleshooting and enhancing , a definite value
  • Second best aproach is to extract images using Mirror Tags like CoreDNS . This is a favorable direction from IT/Developer view point
  • Other approach it to use simple images but with complete support on build utilities , E.g Debian Selenium
  • Use of minimum base images like Alpine is also one direction depending on use case

Once the images are built the most important process will be to test and validate them , for this also our best suggestion is to

  • Start from base images (So that minimum certification cases already tested)
  • First check everything , the deployment approach
  • Run tests in isolated environment first following by multi stage CI to separate test from production
  • Use Utilities like buildX that can support both X86-64 and AMD Architectures


Which Registries to use in Cloud again depends on use cases and industry .For example for Telco the customer wants to have something adaptable with open stack so use of Zull registry is common followed by obviously Docker and Goharbor . Zull is specially convenient as it can tag/push images to docker hub with Zull jobs with wide use of image scan support using Clair

Container Runtimes

Docker is still believed to be the native and widely support run time environment specially in its Enterprise offering from Mirantis . The PodMan from RedHat is specially taking popularity however there are still a number of behavior issues in PoDMan specially on bind mounts and that need to be standardized before this move .OCI and CRIO are taking wider community support and i believe by Kubernetes 1.19 they may surpass PodMan .

For Telecom industry due to tenant isolation and security requirements the use of Kata is important , for some workloads like vIMS , vMME it becomes not a matter of software but regulatory to use certain architecture over other .

Deploy Containers in OpenStack

When it comes to deployment of containers on open stack there can be many approaches like in case of Magnum to build a Kubernetes controller or as simple as just a kernel configuration file using a set of utilities like Spyros that ensure complete LCM and fast deployment of containers on VM’s .

Similarly containers can use storage from Openstack in a number of ways including

  • Cinder API
  • Manila using NFS or Ceph FS
  • Open ebs
  • etcd

Obviously like in openstack the ephemeral storage has disadvantages like you can not know the implementation of provider and that is why implementation using Ceph3.0/Rook looks like the best direction in a hybrid cloud environment

Using the Containers

Networking and exposing containers outside is still a debatable topic and shall be the subject of separate writeup primary due to reasons that many workloads are still stateful and NIC is not floating instance for many workload specially in Telecom . Having said this still there are some suggestion to access containers in a stanard way like

  • Use of Floating IP like in Calico and Flannel
  • Ingress
  • Customer CRD’s
  • Octavia

Again if we are deploying these solution on openstack we may need to use some encapsulation solutions like Kuryr to avoid double encapsulation or disable port security and supplement it using kube router or calico

Cloud Provider SIG

If you are a Telecom provider who already built Telco Cloud in recent years than this will be something really important for you as Cloud Provider supports a way to integrate Kubernetes (K8S) in Openstack using a number of cluster management tools like

  • Magnum
  • Kubermatic
  • Gardener
  • KoPs
  • Cluster API

HPC and Scientific SIG

HPC use cases are becoming extremely important in Telco’s primarily due to ushering of new Tech wave and use cases around Cloud and 5G .

NVIDIA T-Series GPU is specially popular to run ML/AI workloads in Telecom . It can support high performance on VM’s using efficient resource utilization like 1:4 and for containers 1:8 by exposing GPU’s to VM’s running Kubernetes . In addition for special use cases like GIS and Image profiling can support pass through like the famous SR-IOV use cases of Telecom 5G CNF’s like UPF .


In a nutshell the containers are ready for production . However just like other cloud solution there is no one picture that fits all screens so a careful selection of components and solutions is required to ensure maximum advantage coming from the Cloud .This is why to ensure as community and industry we do not miss the boat like somehow we experience in Openstack VM journey it is very important to define and standardize both the consumption models and deployments scnerios that can support to achieve a real carrier grade evolution to containers .The Cloud iNFrastructure Telco Taskforce (CNTT) has recently launched new initiative to help bring focus on cloud-native network functions (CNF) and Kubernetes based platforms. A working group within Reference architecture 2 ( K8s based ), RA-2 has kicked off a short survey to collect data on Kubernetes adoption in telecom. The link is below , i do expect you will play active part to share your insights to uplift the infrastructure to the Cloud Native era .

Enterprise and 5G Software Application packaging using Helm

Enterprise and 5G Software Application packaging using Helm

Always great to start as a programmer


As most prolific developers consider Kubernetes as the future platform for application development , obviously against odds of Project Pacific . It is certainly worthy to know a platform that holds the future by learning how to best use it .

An investigation in to Kubernetes platform will reveal that although Kubernetes as platform is a kitchen with Recipe for all sort of applications in any vertical  however things can become very complex as we implement H/A , Load balancers  and other complex scnerio each of which require its own YAML definition and instance creation. In addition, as we apply more and more complex concepts like node affinity and taints it becomes more difficult to remember parameter definitions and to build configurations. Then in addition to this there are so many tools both in community and provided by partner distros followed by Geeks who are always willing to build their own tools so question is how to unify and address the challenges in the most efficient manner.

Can I use a collection of tools like Ansible + Mesos + Vagrant + Helm to use the best of all solve the Infra provisioning and monitoring issues?

 Obviously, no one tool can satisfy all but how to unify the pipeline and packaging and where to start, let us discuss some details to solve these very vital issues of future infrastructure. Most of these tools like HELM are available in community to accelerate development and find and fix bugs. Users of these tools also share deployment playbooks, manifests, recipes, etc  distributing via repos like GitHub and build platforms like Jenkins , mostly community and partners hardened this knowledge and also share it on secure and trusted repos and libraries like Ansible Galaxy  to which reader can refer to following to get more details


Source: RedHat

All of this require a novel approach to manage the containerized infrastructure , HELM® which is a seed project with in CNCF® is a packaging solution that can address most of the challenges defined above . Just like Kubernetes it also supprots operators through which vendors and ISG can publish their software artefacts and packages to onboard it . This is also a way through which 5G CNF will be onboarded through NFVO (NFV Orchestrator) to the Infrastructure. This is exciting way to manage applications through easy to play charts , template files and easy to manage and control dependencies .

So let us try to understand some key concepts on Helm charts and Helm Operators.


Source: RedHat

Helm Charts:

A Helm chart is a single repository or artefact that contain all objects like deployment , services , policy , routes ,PV’s etc into a single .tgz (ZIP) file that can be instantiated on the fly . Helm also supprots aggregation concept which means you can either deploy each micro service or a collection of them altogether through one deployment process . The later is important specially in Telecom CNF’s . A good collection of helm charts are available at which we can customize and also integrate with CI pipeline like Jenkins to do all operations on the fly .

When it comes to telecom and 5G CNF’s it is important to understand following terms before understanding contents of the package


Source: K8S and ETSI NFV Community


Source: Kodecloud and Project experience

Chart: A collection of resources which are packaged as one and will be used to run an application, too or service etc

Repo: A collection like an RPM used to manage and distribute resources as packages. Satellite can be used to integrate both VIM and CIM Repos in a 5G world

Release: A helm supprots to run a Canary release in a Telco environment, each time a chart is instantiated obviously including incremental changes each time will be considered a Release

Helm latest version is 3.0 release in ONS North Americas In Nov 2019 and includes a major change like removal of Tiller (Major security bottleneck) which was major impediment to use helm on more secure clusters.

Just like VNFD and NSD which follows ETSI ® SOL1 and SOL4 which defines VNF packages and its structure using TOSCA in Kubernetes we follow helm chart standard which YAML descriptors and structure that can be instantiates using helm create chart name , further it can be enriched and customized as per need , the mandatory manifests are values.yaml contains details like IP’s ,networks , template.yaml consumes the values ,chart.yaml the master file to manage charts , NOTES.txt  a comment files and Test.yaml to conduct chart testing once deployed . requirements.yaml is a file that list the dependencies

Happy and ready to apply your own helm charts , then try this out .  Although helm charts provide an easy way to manage applications however not all the changes are acceptable directly specially for the case of stateful CNF’s which are very relevant to the Telecom use case. In this case we need to use the Helm operator which first version 1.0 is GA now and let us discuss its key points below. Similarly Kubernetes operator need to be installed first via CRD’s , Helm charts behave in the same manner with a difference it is installed using Software developer provided charts .

 Helm Operators:

A helm chart and its packaging can be compared to Functions of Kubernetes operator which makes it easy to deploy and manage application across its life cycle using CRD and customer defined definition .

The helm operator is doing the next step of what Kubernetes is by enabling complete GitOps  for helm .It focused on defining a custom resource for the helm release itself thereby making it simple to manage complete artefacts as it is being deployed and managed .

As of April 2020 following are major features already added in Helm1.0 Operator

  • Declaratively installs, upgrades, and deletes Helm releases
  • Pull charts from anychart source;
  • Public or private Helm repositories over HTTP/S
  • Public or private Git repositories over HTTPS or SSH
  • Any other public or private chart source using one of the availableHelm downloader plugins
  • Allows Helm values to be specified;
  • In-line in the HelmRelease resource
  • In (external) sources, e.g. ConfigMap and Secret resources, or a (local) URL
  • Automated purging on release install failures
  • Automated (optional) rollback on upgrade failures
  • Automated image upgradesusing Flux
  • Automated (configurable) chart dependency updates for Helm charts from Git sources on install or upgrade
  • Detection and recovery from Helm storage mutations (e.g. a manual Helm release that was made but conflicts with the declared configuration for the release)
  • Parallel and scalable processing of different Helm Release resources using workers


Helm Operator can also work with other Kubernetes operators and address any dependency constraints infact all those can be expressed as part of the Chart itself. This is certainly needed in CNF’s and Telco use cases where there are lot of dependencies between API versions and cluster components for all rolling updates and each of this will require testing and validation. Traditional Helm obviously can not address it and it is almost impossible for user to address all such changes in an ever changing and complex world of network meshes, Helm operator ensures these requirements are fulfilled with in the GitOps frameworks.

Helm basic commands:

Below is a good jump start to some of basic helm commands .

  • helm repo add

command to add a helm chart from a repo

  • helm create chart-name

command to add a helm chart , a directory with basic files

  • helm install –dry-rundebug ./mychart

Run dry run to install and show debug instructuctions

  • helm package ./mychart

Will prepare the .tgz package and a user can install the application from this package.

  • helm get all UPF -n CNF

Will retrieve the details of application deployed via helm in a give NS

  • helm –help

Want to know all just try it out


Although I have explained the Helm and Kubernetes in a way that one can believe that Helm chart is the replacement of Operator which is not the case. Infact the Helm is mainly aimed to deploy and manage Day1 tasks while still along the LCM of application you rely on CRD’s and Operators with one caveat why I do not like is that each time a new CRD we have to install and manage them. It will definitely change over time as Helm operator will target to resolve for most of day2 issues and that’s why I will encourage to get involved in Kubernetes SIG community.

Finally, as we will standardize the Dev Pipeline for Telco’s as well which is still too much invisible to us it will enable us to build hybrid cloud environment that will certainly solve so many fundamental architecture and business challenges. As an example, in the COVID-19 scnerio so many of the business face challenge to expand their networks to cater for increased load. If Telco’s already have figured out this pipeline it would have been both economical and responsible to share load between Onprem and Public cloud to address the hour need. This is why the journey to Hybrid cloud and software package standardization and delivery is too vital for both growth and sustainability of the Telco industry and national growth.



@Oreily Kubernetes book sponsored by RedHat

The comments in this paper do not reflect any views of my employer and sole analysis based on my individual participation in industry, partners and business at large. I hope sharing of this information with the larger community is the only way to share, improve and grow. Author can be reached at


Application Aware Infrastructure Architecture of Future Enterprise and Telecom Networks

Application Aware Infrastructure Architecture of Future Enterprise and Telecom Networks 

An architect’s perspective in 2020+ era


The recent global situation and use of Critical Telecom infrastructure and Security solutions in the Cloud has shown to many critics as well the esoteric of  terms like Hybrid Cloud , AI , Analytics and modern applications is so vital to bring society and economy forward .

Seeing the latest development where we have been actively joining the community in both Infrastructure and Application evolution both in the Telco and Enterprise Application world i can safely conclude that days where Infrastructure is engineered or built to serve application requirements are over . On the contrary with the wide range of adoption of application containerization and Kubernetes as platform of choice the future direction is to design or craft the application that can best take advantage from a standard cloud infrastructure.

Understanding this relation is key impetus between business who will flay and those who will crawl to serve the ever-moving parts of the Eco System which are the Applications


Source: Intel public

In this paper let us try to investigate some key innovations on Infrastructure both Physical and Cloud which is changing the industry Pareto share from Applications to Infra thereby enabling the developers to code and innovate faster.

Industry readiness of containerized solutions

The adoption of micro services and application standardization around the 12 factor App by cloud Pioneer Heroku in 2012 gave birth to the entire new industry that has matured far quickly compared to virtualization. A brief description of how it is impacting market and industry can be referenced in Scott Kelly paper in Dynatrace blog . This innovation is based on standardization of Cloud native infrastructure and CNCF principles around Kubernetes platforms aimed at following key points


The Covid-19 has proved the fact that if there  a single capability that is necessary for modern era business to survive then this is scalability , in recent weeks we have seen millions of downloads of video conferencing applications like Zoom , Webex , blue Jeans then similarly we have seen surge demand of services in the Cloud . Obviously, it would have been an altogether different story if still we were living in legacy Telco or IT world.  3


Immutable but Programmable

On every new deployment across the LCM of applications the services will be deployed on new infrastructure components, however all this should be managed via an automated framework. Although Containers in Telco space do require stateful and somehow mutable infrastructure however the beauty of Infra will keep the state out of its Core and managed on application and 3rd party level ensuring easy management of the overall stack

Portable with minimum Toil

Portability and ease of migration across infrastructure PoPs is the most important benefit of lifting applications to the containers, infact the evolution of Hybrid clouds is the byproduct business can reap by ensuring applications portability in

Easy Monitoring and Observability of Infra

There is large innovation happening on the Chip set, Network Chips (ASIC), NOS i.e P4 etc however the current state of Infra do not allow the applications and services to fully capitalize on these advantages. This is why there  are many workarounds and complexity both around application assessment and application onboarding in current Network and Enterprise deployments

One goof example of how the Container platforms is changing the business experience on observability is Dynatrace which allows the code level visibility , layers mapping and digital experience across all hybrid clouds .


Source: dynatrace

Composable Infrastructure

Already there looks a link from platform to infrastructure which will support delivery of all workloads with different requirements over a shared infrastructure. The Kubernetes as a platform already architecting to fulfill this promise however it requires further enhancements in Hardware, the first phase of this enhancement is using HCI, our recent study shows in a central DC using of HCI will save CAPEX by 20% annually. The further introduction of open hardware and consolidation of open hardware and open networking as explained in the later section of this paper will mean services will be built, managed and disposed on the fly.

From automated Infrastructure to Orchestrated delivery

Infrastructure and Network automation is no longer a myth and there are many popular frameworks to support it like Ansible , Puppet , Jenkins and Cisco DevNet .

However, all those who work on IT and Telco Applications design and delivery will agree the cumbersomeness of both application assessment/onboarding and application management with little infrastructure visibility. This is because the mapping between application and infrastructure is not automated. The global initiatives of both the OSC and SDO’s like prevalent in TMT industry has primarily focused on Orchestration solutions that is leveraging the advantages of the infrastructure specially on chip sets driven by AI/ML and enabling this relationship to solve business issues by ensuring true de-coupling between the Application and Infrastructure


Although the reader can say the platforms like Kubernetes has played a vital part for this move however without taking advantages of physical infrastructure simply it could not be possible. For example both Orchestration in IT side primarily driven by K8S and on Telco Side primarily driven by initiatives like OSM and ONAP is relying on infra to execute all pass through and accelerations required by the applications to fulfill business requirements  .

Infact the Nirvana state of Automated networks a more cohesive and coordinate interaction between application and infrastructure under the closed loop instructions of Orchestrator to enable delivery of Industry4.0 targets.

Benefiting from the Advantages of the Silicon

Advantages of Silicon were, are and will be the source of innovation in the Cloud and 5G era . When it comes to Hardware infrastructure role in whole Ecosystem, we must look to capitalize on following


The changing role of Silicon Chips and Architectures (X-86 vs ARM)

The Intel and AMD choices are something familiar to many Data center teams, somehow in data centers where performance is a killer still Intel XEON family outperforms AMD whose advantages of lower floor print (7nm) and better Core/Price ratio has not built a rational to select them. Other major direction supporting Intel is their supremacy in 5G , Edge and AI chips for which AMD somehow failed to bring a comparative alternative. The most important drawback as the author views is basically the sourcing issues and global presence which makes big OEM/ODM’s to prefer Intel over AMD.

However the Hi-Tec industry fight to dominate the market with multiple supply options specially during recent US-China trade conflict has put TMT industry in a tough choice to consider non X-86 Architectures something which obviously no one like to have as its Eco system is not mature and the author believes a un-rational selection will mean the future business may not be able to catch advantages coming from disruptors and open industry initiatives like ONF ,  TIP , ORAN etc

Following points should be considered while evaluating

  1. Ecosystem support
  2. Use cases (The one which support Max should win)
  3. Business case analysis to evaluate performance vs high density
            Except Edge and C-RAN obviously Intel beats ARM
  1. Aggregate throughput per Server
  2. NIC support specially FPGA and Smart NIC
          Obviously, Intel has a preference here
  1. Cache and RAM, over years Intel has focused more on RAM and RDIMM innovation so somehow on Cache side its thing ARM has an edge and should be evaluated. However consider fact not all use cases require it makes it a less distinct advantage
  2. Storage and Cores , this will be key distinguisher however we find both vendors are not good in both. Secondly their ready configuration means we have to compromise one over other
           This will be the killer point for the future silicon architecture selection
  1. Finally, the use of inbuilt switching modules in ARM bypassing totally the TOR/SPINE architecture in Data centers in totally may got proponents of Pre-Data center architecture era however promise of in-built switching in scaled architecture is not tested well. For example, it means it is a good architecture to be used in dense edge deployments but obviously as far as my say is not recommended for large central Data centers.

However only the quantitative judgement is not enough as too much dominance of intel meant they do not deliver the necessary design cadence as expected by business and obviously opened gates for others, it is my humble believe in the 5G and Cloud era at least outside the Data centers both Intel and ARM will have deployments and that they need to prove their success in commercial deployments so you should expect both XEON® and Exynos silicon recently .

FPGA ,SmartNICs and vGPU’s:

Software architecture has recently moved for C/C++/JS/Ruby to more disruptive Python/Go/YAML schemes primarily in a drive of business to adopt the Cloud . Business is addressing these challenges by requiring more and more X-86 compute power however improving the efficiency is equally important as well. As an example, Intel Smart NIC family PAC 3000 we tested for a long time to ensure we validate power and performance requirements for throughput heavy workloads.

Similarly, Video will be vital service in 5G however it will require SP’s to implement AI and ML in the Cloud. The engineered solutions of RedHat OSP and Openshift with NVIDIA vGPU means the data processing that was previously only possible in offline analytics using static data source of CEM and Wirefilters.



Envisaging the future networks that combines power of all hardware options like Silicon Chips, FPGA, Smart NICs, GPU’s is vital to solve the most vital and business savvy challenges we have been facing in the Cloud and 5G era.

Networking Infrastructure


There is no doubt networking has been the most important piece in Infrastructure and the networking importance has only increased with virtualization and with a further 10-Fold increase with Containers primarily as Data centers fight to deliver best solutions for East-West Traffic. Although there are a number of SDN or automation solutions however there performance has scale has really shifted the balance towards infrastructure where more and more vendors are now vesting on the advantages of ASIC’s and NPC’s to improve both the forward plane performance but also to make the whole stack including fabric and overlay automated and intelligent fulfilling IDN dream by using latest Intel chips that comes with inherent AI and ML capabilities .

The story of how hardware innovation is bringing agility to network and services do not ends here for example use of Smart NICS and FPGA to deploy SRV6 is a successful business reality of today to converge compute and networking infrastructure around shared and common infrastructure.

Central Monitoring

Decoupling, pooling and centralized monitoring is the target to achieve and already we know with so many solutions which are somehow totally different in nature like on networking side between fabric and overlay means to harmonize the solutions through concept of single view visibility. This will mean that when an application demands elasticity hardware does not need to be physically reconfigured. More compute power, for instance, can be pulled from the pool and applied to the application.

 From Hyperscale’s to innovators

The dominance of hyperscale’s in Cloud is well known however recently there had been some further movements that is disrupting the whole chain. For example, now ONF Open EPC can be deployed on OCP platform. Similarly, the TIP Open-RAN initiative is changing the whole landscape to image something which was not even in discussion a few years before.

Since the ONF is too focused on Software and advantage brought forward by NOS and P4 programming so I think it is important just to talk about OCP . The new innovations in rack design and open networking will ensure to define new compute and storage specifications that best meet the requirements for the unique business requirements  .Software for Open Networking in the Cloud (SONiC) was built using the SAI (Switch Abstraction Interface) switch programming API and has been adopted unsurprisingly by Microsoft, Alibaba, LinkedIn, Tencent and more. The speed at which adoption is taking place is phenomenal and new features are being added to the open source project all the time, like integration with Kubernetes and configuration management

Summary review

Finally, I am seeing a new wave of innovation and this time it is coming via harmonizing of architecture around Hardware, thanks to the effort in last few years around Cloud , Open Stack and Kubernetes. However, these types if initiatives will need a more collaborative efforts between OSC and SDO’s i.e TIP and OCP Project harnessing the best of both Worlds

However, with proliferation of so many solutions and offerings the standardization and alignment of common definitions of Specs for the Shared Infrastructure is very important.

dis SDN

Source: Adva

Similarly to ensure innovation delivers the promise the involvement of End user community will be very important , the directions like LFN CNTT , ONAP , ETSI NFV , CNCF and GSMA TEC are some of the streams which require operator community wide support and involvement to come out of clumsy picture of NFV/Cloud of last  decade to replace by true innovative picture of Network and Digital Transformation .A balanced approach from Enterprise and Telco industry will result the business of today to become the hyperscale’s of tomorrow .

I believe this is why after a break this is the topic I selected to write. I am looking forward for any comments and reviews that can benefit community at large


 The comments in this paper do not reflect any views of my employer and sole analysis based on my individual participation in industry, partners and business at large. I hope sharing of this information with the larger community is the only way to share, improve and grow. Author can be reached at


How Open Orchestration enhances  Enterprise, 5G , Edge and Containerized applications in Production


Source: ETSI <>


How Open Orchestration (OSM Release-7) enhances  Enterprise, 5G , Edge and Containerized applications in Production

An architect’s perspective from ETSI® the Standards People


As highlighted in the Heavy reading latest End-to-End Service Management for SDN & NFV all the major T1 Telco’s are currently refining their Transformation journey to bring standard Orchestration and Service modeling in their networks , one of such standard approach is promised by ETSI OSM a seed project from ETS® the standards people .

Recently in Q4 2019 ETSI OSM release the Release7 which address surmount challenges of brings CNF and Containerized applications to the production ETSI OPEN SOURCE MANO UNVEILS RELEASE SEVEN, ENABLES MORE THAN 20,000 CLOUD-NATIVE APPLICATIONS FOR NFV ENVIRONMENTS

This capability of ETSI® OSM is specifically important considering the ushering of 5G SA architecture and solutions which already find its way to the market thanks to early work from CNCF and specifically CNTT K8S specs . OSM brings value to the picture as it will allow to design, model, deploy and manage CNF’s (As ETSI NFV call is a containerized VNF) without any translation or modeling. It also lets operators experience early commercial use case of integration Helm2.0 in their production environments. On top of it will allow a NS (Network Service) to combine CNF’s with existing VNF’s or legacy PNF’s to deliver complex services in an easy to deploy and manageable manner.

In the following part of this paper I will try to share my understanding on OSM release7 and sum up results from ETSI OSM webinar on this subject held on JAN 16th 2020 . For details you may need to refer to webinar content itself and can be found  

Why Kubernetes is so important for Telco and Enterprise

Telco industry has experienced lot of pain points the way NFV journey has steered with focus on migrating existing PNF’s to the Cloud. K8S offers opportunity for all Platform providers, application vendors, assurance partners to build something on modern principles of micro services, DevOps and Open API’s driven. This is something that already made its way to Telco’s in OSS and IT systems as an example mycom OSI UPM , OSM and  infact ONAP all are already based on Kubernetes , the arrival of 5G SA and uCPE branches has driven almost all operators adopt networks to use Kubernetes . Further it is principally agreed as CSP’s move to Edge the K8S will be the platform of choice.

Foundation for K8S Clusters

Kubernetes made it simple for the applications and CNF’s to use API’s in a standard fashion using K8S Clusters which are deployed either in an open source manner or via Distros. The early adoption of CNF’s in Telco largely supports the consumption model of vendor Distros like RedHat OpenShift, Vmware PKS, Ericsson CCD to mention the most important ones.

Since containers are like a floating VM’s so networking architecture specially the one promised by L3 CNI plugin and Flannel is important direction to be supported in Platforms as it is supported in OSM .

The reusability of API makes it simple for application to craft unique application in form a build configuration files using artifacts of PoD, services, cluster, config map and persistent volumes which are defined in a very standard manner in K8S by which I mean deploy all artifacts through a single file.

ETSI® OSM can be deployed using both HELM2.0 as well as Juju charmed bundles


Foundation for Helm

Helm gives teams the tools they need to collaborate when creating, installing, and managing applications inside of Kubernetes. With Helm, you can… Find prepackaged software (charts) to install and use Easily create and host your own packages , Install packages into any Kubernetes cluster Query the cluster to see what packages are installed and running Update, delete, rollback, or view the history of installed packages Helm makes it easy to run applications inside Kubernetes. For details please refer to details HELM packages on

In a nut shell all day1 and day2 tasks required for the CNF’s are made possible using Helm and its artifacts known as Helm charts including application primitives, network connectivity and configuration capabilities.

Key Features of OSM Release7

OSM Release 7 is a carrier grade and below are its key features as per wiki

  • Improved VNF Configuration interface (One stop shop) for all Day0/1/2 operations
  • Improved Grafana dashboard
  • VNFD and NSD testing
  • Python3 support
  • CNF’s support in both options where OSM creates the Cluster or rely on OEM tools to provision it
  • Workload placement and optimization (Something very important for Edge and Remote clouds)
  • Enhancement in both Multi VIM and Multi SDN support
  • Support for Public Clouds

How OSM handles deployment of CNF’s

For most Telco guys this is most important question e.g how VNF package will be standardized with arrival of CNF’s , Will it mean a totally new Package or enhancement of existing.

Fortunately, OSM approach on this is modeling of Application in a standard fashion which means same package can be enhanced to reflect containerized deployment. On a NS level it can flexibly interwork with VNF/PNF as well, the deployment unit used to model CNF specific parameters is called KDU’s (Kubernetes Deployment Unit) other major change is K8S cluster under resources. It is important as it explains most important piece the Networking and related CNI interfaces.

OSM can deploy the K8S cluster using API integration or rely on 3rd party tools like Openshift® or PKS deploy it on instructions of OSM

Picture7Changes to NFVO interfaces

Just like Or-Vi is used for infrastructure integration with Orchestration the Helm2.0 (Will support 3.0 in near future) is used for infrastructure integration with K8S applications. Since the NBI supports mapping of KDU’s in same NSD it means only changes from orchestration point of view is on the south side only.

Workload Placement

As per latest industry standing and experience sharing in Kubecon and Cloud Native  summit Americas  there is a growing consensus that Container is the platform of choice for the Edge primarily due to its robustness , operational model and lighter foot print . As per our experience of containers here in STC a 40% reduction in both CAPEX and Foot print will be realized on DC’s if deployed Edge using Containers.

However, definition of business definition of Edge raise number of queries the most important of it are work load identification, placement and migration specially consider the fact the Edge is a lighter foot print that in future will host carrier mission critical applications.

Optimization of Edge from CSP perspective has to address following  Cost of compute in NFVI PoP’s , Cost of connectivity and VNFDFG something implemented by SFC’s and Constraints on service like SLA, KPI and Slicing


The issues with the Upgrades and How OSM addresses

Compared to early release the OSM ns action primitives allow the CNF to be upgrades to the latest release and execute both dryrun and  Juju tests to ensure the application performance bench mark is same like before  .Although this works best for small applications like LDAP the same is difficult to achieve with more complex CNF’s like 5G SA . Through liaison with LFN OVP program I am sure soon the issue will be addressed. We as operator have a plan to validate it on a 5G SA nodes.


My final thoughts on this that  Container journey for CSP is already a reality and coming very shortly in 2020+ and OSM ecosystem supports the commercialization of CNF’s through early use cases of 5G SA , Enterprise branch uCPE and most important Edge including MEC for which OSM seems to reach maturity  For details and how to participate and use do get involved in upcoming OSM Hackfest IN MARCH OSM-MR8 Hackfest

Many thanks to colleague , mentor and industry collaborator Jose Miguel Guzman , Francisco Javier Ramón Salguero  Gerardo García and Andy Reid for OSM growth in recent years … See you in Madrid




Linux Foundation


Delivering 5 9’s Security for Mission Critical 5G Systems


“Can an Open Cloud Based System be more secure for Mission Critical Applications”


So finally the Frenzy of 5G Networks and how they will bridge the gaps between different industries and societies seems finally come to materialization .As most of the Tier1 Operators are working to build the Use cases that will support for early launch and market capture catalyst for early movers in the area still the area of 5G security seems gloomy with still lacking much detailed standards being output by ETSI and other SDO’s compared to 5G technology itself.

There are many questions in the air need to address both from architecture point of view and from End to End working solution perspective. For example

1.     Is 5G security same or conflicting with NV/SDN security?

2.     How operators will develop a unified solution that can meet requirements from all industries

3.     If a standard solution exist will it scale? Or finally in 2-3 Years down the road we need to live with lot of customized solution difficult to assure?

4.     What about solution relevance in Open source networks with many players around

5.     Finally how to imbue Cyber security dilemmas in the 5G Telco Networks.

6.     Will End user privacy will be a killer decision in 5G

I think this list gives author enough challenges faced by 5G and verticals and in this paper I shall try to build a high level model to address them in a unified UML model.

  In a world where computing is ubiquitous, where a mist of data and devices diffuses into our lives, where that mist becomes inseparable— indistinguishable—from reality, trustworthy computing is but axiomatic. ( David James Marcos /NSA)

Before dig deep to formulate the security architecture we should know at a high level the 5G system security will no longer be like 4G networks because of reason no single domain like traditionally Core/UE can promise complete security solution . The enigma of 5G security is huge involving devices like Malware , MitM, low cost devices , Air interface jamming , frequency scan , Back haul DDOS , packet sniffing , NFV and virtualization vulnerabilities , API issues , NW security , VNF application ,platform and IP vulnerabilities and hence we should analyze 5G system in depth from whole system aspect and need look in following important dimensions

1.     Decentralized Architecture: The biggest problem that lies ahead is that the Telco Networks are programmed to work not the way around. It actually means they do not predict and obviously do not interpolate to the scale of issues 5G will go to face. This is an architecture issue because like in 3G/4G source of security seems like in Core Network, in NFV/SDN it seem to imbue in the platform but for 5G planning a single control unit to handle and process all data seems impossible. But if we decentralize how to control it. We cannot decentralize without control it and how to control a device we do not trust? I think 5G must model a concept like Block Chain in Banking sector to share security but in a trusted manner and in addition not point of failure due to compromise in a unit or layer

The understanding of 5G System architecture and how it will influence the present Telco Services migration along with how it can make a thriving eco system is key area of interest for the architect. There are different dimensions like first we need to understand 5G is based on a SBA architecture which requires whole network separated from Infrastructure which makes NFV/SDN almost an inevitable enabler for it . It will allow the deployment of network a slice to support each use case separately. Currently how to model one solution and can it be applicable to customize it for each offering is key area of discussion in ETSI.



  2.     Resource demarcation: This is a scary topic because IMT2000 already divided network in three domains as per latency use case requirement. The dilemma is that it require different RF resource need to map to a different NFV/SDN DC resource in the Cloud is biggest problem that lies ahead is that the Telco Networks are programmed to work not the way around. It actually means they do not predict and obviously do not interpolate to the scale of issues 5G will go to face. This is an architecture issue because like in 3G/4G source of security seems like in Core Network, in NFV/SDN it seem to imbue in the platform but for 5G planning , so in a broad sense multi RAT for each slice may not be the right approach

3.     5G Network Threat Model extension: This host VNF’s which are source or sunk of user workload like DNS , AAA ,IPAM is east use case but introducing middle Box VNF like AS , Control plan and Media boxes means we need to introduce Telco Concepts like multi homing , A/S architectures , CSLB and on top of it complex dependence on IT Network redundancy like Bonds ,bridges and it makes the Security a big issue of concern . Obviously introducing a disparate solution means security threat boundary will extend than it is originally supposed to be


4.     5G Security Frame work for 5G SA System: Well I will not go in to the details here because an expert buddy has just done it perfectly watch Hitchhikers guide here

However I do want summarize a bit as follows the 5G Rel15 specifications consider EN-DC (E-UTRAN New Radio Dual Connectivity) as the defacto standard for 5G security at least in 2018 or let’s say till H1 2019 reason is obvious because the final Standalone Security specification TS33.501 will freeze in Dec ,2018 . Why EN-DC security is important but same time not very difficult to embrace is that The EN-DC security is based on the existing LTE security specification, TS 33.401 with EN-DC enhancement as shown below


The Good news about EN-DC is that it works almost the same way the LTE-DC runs the concepts of Key Generation, Key Management, Ciphering and Integrity Protection are re-used from LTE –DC concept TS23.501 while the DRB <Data Radio Bearer Security> context is added with regard to 5G Core Network. For EN-DC security, new X2 Information Elements, “SgNB security Key” and “UE Security Capabilities” is newly defined.


Here shows EN-DC bearers and PDCP termination points from Network side. MN is the master eNB and SN is the secondary gNB. If the PDCP/NR-PDCP is terminated in the MN, LTE security works, on the other hand, if the NR-PDCP is terminated in the SgNB, NR security covers. EEA is redefined as NEA, EIA is also now called NIA. As you can guess NEA, NIA stands for NR Encryption Algorithm and NR Integrity Algorithm

A good analysis of 5G security protocol can be seen in below


•       In 2018 implement EN-DC architecture almost same as LTE DC

•       Use existing USIM but program USIM/UICC it need USIM vendor support

•       5G Success depend on e-SIM trial special for IoT

5.     Assuring NFV/SDN security for 5G: 5G Network is not about a network but about a system. It involves a plethora of NFV, SDN and Network automation in context of Enablers for 5G to support the future SBA based architecture. These days biggest question we have been talking in the ETSI ISG Security group and in TMforum is actually do Network automation a bliss or curse for security assurance.

6.     Scalable Security solution : Historically the Telco companies and 3GPP must be credited of building a robust security architecture , it can be reflected in 2G/3G/4G and same is expected in 5G with only problem that scale of 5G devices is billions not millions and a solution to expand only Core network and related Authentication servers is not enough . It require inclusion of distributed security architectures and above all IAM solutions which best use network API exposure to guarantee security. It means in future Security as a service can be possible and that an operator can open the network to guarantee whole system security using best offering from the third party. Anyways it will not change 5G Security Frame work for 5G SA System as I explained in Point5 of this paper.

The scalable solution also means that security can be provisioned for each use case in an orchestrated manner something very similar like VNF OLM management where security policy, test criteria all can be customizable as per required use case and SLA.

7.     Security assessment and Verification: The 5G system is complex and include plethora of many technologies. The security context of IT , Cyber , Information security all are added along with the Telco security but till now even ETSI SA3 have not finalized the detailed scenario

The 5G System is big and complex , the 3GPP SA3 is doing a remarkable work to get the standard readiness and proto type before Rel-16 Stage-3 specs are output in June this year . The main focus of this year SA3 key targets are 1. Key hierarchy 2. Key derivation 3. Mobility 4. Access Stratum security 5. Non-Access Stratum security 6. Security context 7. Visibility and Configuration 8. Primary authentication 9. Secondary authentication 10. Inter working 11. non-3GPP access 12. Network Domain Security 13. Service based architecture 14. Privacy . I hope to refresh the material for whole 5G security by the time i got more visibility based on SA3 work and till the time got more inputs from vendors of exactly how they will be approaching this critical but important point in 5G .


National Security Agency review of Emerging Technologies

3GPP TR.501

3GPP TS28.891

3GPP TS 23.799

3GPP TS28.531

3GPP TS38.300


NFV SOL03 ,04


Addressing Solvency of Open source production and adoption models for TMT and Telco industry


Addressing Solvency of  Open source production and adoption models for TMT and Telco industry

An architect’s perspective



Technology, Media and Telecom industry known as TMT by commoners is going through major transformation programs globally. One of the prime recipes of this revolution are their vigor and participation in Open source. However, over years of experience in Open source revealed some key points to us, For example most of industry believes opensource is

  • Open (without defining what is Open)
  • Cheaper (with our a valid Business case and TCO working)
  • Simple to deploy and use (with out analyzing ecosystem and interworking).

On one hand I believe Opensource is a bandwagon every one wants to sit but is also a wagon no one want to drive at least in a commercial and production environment. Therefore, it is very important to share my views on this .

Understanding the Story of TMT Industry at a Glance 

Pictures are always an easy way to summarize and let me share some very useful insights from lumina networks  in recent #ONS Days Melbourne showing Opensource will address solve business issues around . Thanks for IldikoVancs for sharing this summary .

  • Automate any network with any form factor
  • Resource optimization and utilization
  • Offer NaaS and Slicing to Verticals most important 

Attracting business to Opensource is the most important challenge for Architects , Will building a best of breed staff fulfills TCO and CXO transformation objectives ? 


Source: @lunminanetworks

Let us see now results of applying story to practice through Impacts of Open source Glory in TMT industry

Use of open source in Telco has definitely a long-term value but because still as a community we have failed to transfer Open source frameworks to MVP of vendor products, some thing that can drive and navigate our Sourcing, RFX and vendor selection process. I think this was something that was supposed to be done at the outset of this journey but what really happened. I think some smart marketing crooks sold dreams to Telco’s that they will become future Google and hyper scales which was never the purpose and direction of a service industry like ours.

The long term repercussions of this was that still down the road of almost a decade we found ourselves surrounded by vendors that come with a proprietary and engineered solutions  that they say is aligned with Opensource like ONAP , OPENSTACK,K8S etc but the sad story reveals its just the concept or in SDK terms the front end that is something like Open while all backend and software forking is proprietary .

So despite I lead my company in many of these initiatives I am still circumspect of the approach we have taken or at least we should agree that we need to really now think about value quantification to put business metrics in perspective and to ponder how to really make these initiatives work.

Grow adoption through power of synergy


Openstack is one of the most successful example of Opensource adoption and summing our experiences in Cloud may support to build the best prospective in other domains, may it be technical issues , licensing models or operators and TMT’s transformation journeys . The wide adoption of Openstack in IT , application, Telco and verticals proved that opensource frameworks that can serve a wide use cases not limited to particular industry is the best way to proceed. It has really enabled to adjoin industries which were traditional on a minimum of an Isle’s distance.

However balancing an opensource adoption in a balanced way with out skewness towards a particular segment is still a big challenge, it comes a life line when we consider each industry requires unique characteristics and building something for commoners cannot fulfill business needs.  This is what leads industry to collaboration or which in business or RFX we name as partnership and ecosystems.

Sharing and not swallowing

As Johanne Mayer, Director MayerConsult and TM Forum Distinguished Fellow at the Layer123 Network Transformation Congress in San Jose the Telco’s in 5G era can not find a solution that comes from a single vendor. It simply is not possible as more and more verticals will come in to the picture. The success of such initiatives will depend more on working together then to get community outputs and build end to end solutions and products that simply are not aligned with open standards and concept of mixing best of the breed approach.

Integrating the Open source solutions


Open source is a journey of software and idea that future the solution will come from a hefty number of vendors. However, it is still a reality that at least till the decade Telco’s will run the hybrid networks including Cloud , PNF , VNF etc . So we need to solve these issues on API , standards and Fitness for use at the outset .

Also we need to see use of open source in customer X can be totally different than the use in vendor Y because the end product and business case will require some solution tailoring. The Personalization of each customer solution is very important.

RFX of Open source solutions

One of the bigger pain points in Open source solution adoption is to do with sourcing and RFX process. It is easier part for Telco to give requirements of an open solution but fact is which vendor will take end to end responsibility of third party in such multi-vendor offering.

Then how an Operator can be sure the vendor is not pushing its solution whereas ideal solution must be the Pull solution where based on requirements each component should be selected and then integrator to work on modalities of integrating them all . It is easier said than done however failure to adopt this direction means we find an integrator that can only work with certain vendors or at least can only take project if certain vendors on certain later are there. This is a frightening situation that will impede to slow adoption and commercialization of open source technology. If we address these points not only on technology level but also process and sourcing model then I am sure adoption will be as freely distributed as the Windows of today.

Its Services not the solutions

Some time ago I was reading a blog from NetApp  with a sentence that caught me in the moment

“You Can’t Change Your DNA – EMC Thinks Mainframe; Dell Thinks PC; NetApp Thinks Open Systems”

That is so true for the TMT and specifically the Telco industry , we must not be lured by story of openness and innovation that we forget our purpose. I think key to our survival in new era of digital transformation is fail fast and to deliver services .  Focusing on services and not on solution is so vital for Long term sustainability.



 When ROI of Open source solutions will realize

Although painful but reality is that no CSP unless the giants with big R&D arms have achieved real ROI or a fair visibility into it at least till now. One practical result of this is slow down strategy by many CSP’s and Telco adopted , however slowdown simply solves issue but delays it only .

Lately I have seen many Telco’s in EMEA to solve issue by breaking stack from the top or North side then to fix it from ground (NFVI upwards) however it a child’s cry unless we  at least agree and define clearly what is the definition of automation

The risk of industry failure to solve this issue is all major Telco’s are considering proprietary solutions of orchestration and automation to have a feel of something practical that can do something realistic on automation.

Then for real ROI we must agree on something which will finally scale , as an example spending X years while building two Data centers NFV stack we find once we will scale to lets say 10 the advantages of scale is simply not there. The issue of Open source introduction at the Edge will make this discussion more prevalent as simply an Operator can not afford to go to Edge with high setup cost, had open source solution not fix this side will obviously result in the slowdown of Edge as a whole.

Finally, just solving OSM and ONAP architectures with out ensuring vendors MVP align with it and that finally automation stacks can be built by combing best of breed from different vendors is and will remain a dream unless definition , reference architecture , reference implementation and testing/validation is not agreed and vendor’s are not enforced to apply this across their products . Although latest work on hackathons (LFN developer and testing forum)  have tried to address the same concern however still author believes it is not production ready . This is how LFN defines it and I think this is where standardization and SDO’s need catch vendors to align their MVP with architecture frameworks and standard .

“Co-hosted with GSMA, this LFN Developer & Testing Forum brings together developers across ONAP, CNTT, and OPNFV, with a special focus on VNF compliance and verification testing. As the principal event for LFN open source projects, the technical gathering provides a platform for community members to collaborate, plan future releases, conduct a plugfest, and perform interoperability, compliance, and integration testing across the full network stack, including NFVI, MANO, and VNFs”


 Future lies at the intersection of our path


With so many things happening in the industry around both open source development and testing and its commercialization, it is not surprising that many carriers especially those outside U.S and EU to follow a more conservative strategy

However my takeaway to CXO will be to ask technical team focus on bigger picture to know how and when the proprietary automation or Open source solution will converge to real open solution opening choices and offerings for the service providers , had this not addressed the Open spruce journey will remain a glory which every body want to talk about but a road no business wish to take finally .


My final thoughts on this topic is actually best described by a session on O-RAN by Orange in ONS Europe 2019 which is

“The Price to pay for Open source greater flexibility, innovation and openness is the complexity of test and integration” .

So finally, all will come to one line how to define MVP products, benchmark the solutions and about all develop a common test and integration model. It is clear that open source bring value but if we do not know how to deploy and fix the issue it becomes a nightmare nobody wish to keep. This is where SDO’s and Operator community needs to focus in 2020 . One such direction is the CNTT (Common NFVI Task Force) and CNCF TUG (Telecom User Group) which are expected to solve very issues highlighted above .

Currently we are working on the CNTT R2 which is expected to be a GA by JUNE 2020 . Similarly R2 of CNCF will combine the testing and validation of open source solutions to adress the issues that had been faced by TMT clients .