Deployment of modern telecoms networks is changing markedly. It seems barely has one technology become the standard before it is being viewed as obsolescent. It makes deploying major new network elements something of a lottery in terms of the technology choice.

Another facet of the same phenomena is the segmentation of the industry with the tier1 vendors downplaying new technology initiatives until they have managed to port their own product lines creakingly across to adopt them, and the smaller nimbler innovative companies talking up the latest and greatest as the only viable way forward.

Many operators are wringing their hands over the right approach to virtualisation, 18 months ago the question would probably have been whether to invest in Openstack with its improved maintenance and network operations and pay the downside complexity price. Today they are probably wringing their hands over whether to use containers or virtual machines, with containers winning the day. Of course, you can always ask your friendly vendor, but alas the answer you will get will probably match exactly what the development of their current product set has achieved.

Virtualization is not a new concept. It was deployed on IBM mainframes in the 1960s. it was only around 2006 that Intel introduced hardware support for virtualization on x86 processors, though its adaption in the mobile core is still somewhat bizarrely far from ubiquitous.

The NFV infrastructure and architecture was one of the first NFV recommendations to be adopted by ETSI. Appliances such as gateway nodes, policy controllers and subscriber data management were ported from physical hardware onto virtual machines. ETSI defined the framework for compute, storage, OSS and networking capabilities.

Other vendors that have emerged in recent years have specifically developed their functions (VNFs) to run exclusively as NFV. This is known as cloud native application development. So, we have two approaches. Approach 1 – port the application from a physical appliance to virtual machines and approach 2 – develop and deploy VNFs on NFV known as cloud native.

We have now seen that the NFV approach is also changing with the VNFs being further decomposed into what are called microservices. ‘Microservices’ is an architecture style where complex applications are composed of small independent processes and communicate with each other using APIs and use HTTP or JSON as the protocol. This is the fundamental approach being considered in 5G networks, very relevant over the next 2 years as operators fall over each other to implement 5G standalone architectures. Using APIs affords us the opportunity to move to stateless processing and exploit HTTP transactions with an adjunct state store. HTTP has the built-in ability to find the correct state store that uniquely identifies the session.

Once microservices are introduced, they can be run more efficiently in what are termed ‘containers’. Containers provide an alternative approach to virtualization using a long-standing method for partitioning in Linux known as namespaces. The biggest difference between containers and virtual machines is that containers use the host software and host operating system and have no requirement for a hypervisor whereas virtual machines do need to have their own operating system installed.

At Azenby we are beginning to see most applications from PGW, PCRF, HSS, IMS and all the newly defined 5G nodes, move towards a cloud native and container approach, this is a prerequisite to a 5G SA core.

Maintenance and orchestration (MANO) has now become a crucial part of the NFV and containerization strategy. There is more need than ever to have a MANO layer for the daily operation of virtual machines and containers. Some virtualization vendors such as VMWare and OpenStack have a degree of MANO already built into them.

Figure 1 Containerized Applications and virtual machine side by side.

We believe that the orchestration layer is essential, and the introduction of VNFs and containers suggests that MNOs will need to have a best-in-class MANO layer though in our opinion orchestration is still immature, highly complex and seems to be in constant evolution.

Containers are much simpler to orchestrate than VMs. Containers have far fewer management and configuration requirements. As a result, container orchestration is a much simpler problem to solve and a number of solutions exist today, some examples are given below.

• Kubernetes is an opensource container orchestration solution from Google and generally considered to be one of the best-in-class solutions and almost the de-facto standard. It has been adopted by many Telco’s. Many vendors are providing Kubernetes branded distribution.
• Docker provides an infrastructure to create, manage and deliver containers. It is independent of Kubernetes but when combined with it, provides an extremely powerful option for container delivery and orchestration.
• Puppet provides a container infrastructure and orchestration layer.
• Red Hat OpenShift container platform is a leading enterprise distribution of Kubernetes optimized for continuous application development and multi-tenant platforms.

Network Function Virtualization has been at the heart of recent network transformation. The view from Azenby is that this is a fast evolving arena and as such due consideration must be given to ensure that the correct virtualization plan is in place, a plan that will last well into the future and accommodate the fast-changing technical landscape, including micro services and containers.

Formulating your strategy for virtualisation is a crucial element for determining your overall approach to 5G deployments. These decisions are probably the most crucial calls your business has to make in getting the 5G architecture right. At Azenby, we would be happy to help you make sure that you get it right. Contact Azenby and let’s start a discussion.