Hyper-scalers and Telco world .. new alignments..

 

Hyperscaler is recently added,  new term in Telecom World.

In computing, hyperscale is the ability of an architecture to scale appropriately as increased demand is added to the system. In short, when we say hyperscalers, we mean huge companies like Google, Microsoft, Facebook, Alibaba and Amazon who owns huge datacenters and provide  scalability to host growing data subscribers and traffic. 

 In recent years, we are seeing growing partnership  between Hyperscalers and Telco Providers in edge computing as shown at  https://stlpartners.com/research/telco-edge-computing-how-to-partner-with-hyperscalers/) (See figure below )

Relationship between Hyper-scaler and Telco company is edge computing is based on following principles

•   Sharing customers for use-case such as MEC and Private VoLTE
•   Sharing  Datacenters  for Edge computing use-cases. 
•  Developing Edge applications by using  each other’s software development ecosystem

Ref: https://venturebeat.com/2022/02/28/att-partners-with-microsoft-to-develop-new-5g-edge-computing-ecosystem/

Migration to Hyperscaler

Apart, from collaboration in Edge computing, there are other areas where Telcos can work with Hyperscalers e.g. migration of networking and non-networking  applications to Hyperscaler cloud for cost and operational efficiency. By definition Networking applications are Applications which serves directly or in-directly  basic telecom & data functions such as  gateway routers (Packet-GW, UPF), control plane elements(MME), authentication servers (HSS) etc. Non-Networking applications are  Applications which serves business functions such as billing & mediation services, human resource management applications (SAP),  etc.

Key consideration for Hyperscaler migration for Telco 

Following the key considerations  for Telco's Hyperscaler migration:

• Transitioning from Cost to Expense financial model
• Adaptation  of Hyperscaler Billing & subscription based hierarchy
•  Controlling network egress bandwidth Cost
•  Defining CI/CD pipelines for external and internal application using Hyperscaler devops tools
• Controlling cost of  High availability and Disaster recovery in Hyperscaler enviroment

 (to be continued) 

 

CNF Migration for Telco..

 

This Blog discuss about possible approaches deploy Telco CNF (Container network function)

In late 2014, Telecom operators started new technological trend to implement application virtualization principles under name NFV i.e. network functions virtualization. NFV primarily implemented using OpenStack Cloud infrastructure. Under NFV framework, virtualized instance of telecom application is referred as VNF (virtual network function).

As other enterprise infrastructure are moving from virtual machines to containers, Telco providers has also started thinking about deploying CNF i.e. Container network function. Just as Openstack was cloud orchestration framework for VNFs, container orchestration framework such as  Kubernetes  can be used for CNF orchestration.

CNF Migration

There are mainly three specifications are published in providing high level architectural guidance for CNF migration:

1)   Cloud Native Task Force(CNTT)’s Reference Architecture 2 (RA-2):

CNTT RA-2 describes the high level system components and their interactions based on CNTT Reference Model and mapping them to real-world containerized components, including Kubernetes (and related) elements. One key aspect of RA-2 is to identify the relevant Kubernetes features (e.g SRIOV, CPU pinning etc) and extensions that are best used to support telecom network deployments (Ref https://cntt-n.github.io/CNTT/)

2) GSMA NG.126 Cloud Infrastructure Reference Model v1.0: This document has is based on CNTT RA2. This specification provides common set of virtual infrastructure resources details  that Telco cloud infrastructure will need to host typical VNF/CNF telco workloads.    Ref: https://www.gsma.com/newsroom/wp-content/uploads//NG.126-v1.0-1.pdf 

3)   ETSI GR NFV-IFA 029 V3.3.1 (2019-11): This specification provides the potential impact on the NFV architecture of providing "PaaS"-type capabilities and supporting VNFs which follow "cloud-native" design principles, in particular the utilization of container technologies. Ref: https://www.etsi.org/deliver/etsi_gr/NFV-IFA/001_099/029/03.03.01_60/gr_NFV-IFA029v030301p.pdf 

GSMA NG. 126  describes three approaches to deploy CNF workloads in Telco cloud (see Section 3.7 of GSMA NG. 126), as shown in figure below:

1)       a typical IaaS using VMs and a hypervisor for virtualization

2)       a CaaS on VM/hypervisor

3)       a CaaS on bare metal.

This picture can be simplified as below:

Container inside VM (Approach B)

This blog is dedicated to discuss Approach B as specified by ETSI GR NFV-IFA 029 V3.3.1 (2019-11), section 5.3.4.

Telco has spent considerable time in transforming their legacy applications to run as virtual machines. Therefor transforming from openstack based VNF to Kubernetes based CNF will not be overnight transition. Approach B (as suggested above) can provide smooth  migration roadmap for CNF deployment, for following reasons:

-      Application can be refactored for microservices using VM’s host OS. This will provide less development work compared to running directly on bare-metal.

 

-      There will no shared kernel among Telco PoDs. This will address security concerns. Each CNF can run on it’s own namespace.

 

-     Running k8 cluster on VM, will enhance portability. For example if CNF requires to run on hyperscaler such as  Azure Kuberneters Service(AKS), User can create  Azure virtual machine (VM)/k8 Node to host the CNF without worrying about underlying OS structure.

Approach B Requirements:

Requirements to implement Approach B, are as follow:

-      Telco workloads monolithic software architecture should  to be broken down into smaller microservices.

-      Those microservice should be able to be hosted as Pod, orchestrated by Kubernetes

-      Number of Pods will make up CNF( as number or VMs made VNF). Each CNF should have it’s own namespace.

-      Kubernetes PaaS/CaaS elements should be able to manage microservices for ingress/egress traffic management, log and metrics collections, state preservation by external DB, tracing, Secured communication between microservices, etc

-      K8 Node VM should have sufficient capacity to host designed CNF Pods.

-      Number of CNFs can create k8 cluster. Single k8 cluster can consist of all the pods delivering network functionality e.g UPF. Or single k8 cluster belong to particular Telco Vendor, providing multiple functionalities.  

-      Each k8 cluster will have master & worker node. Master node will host k8 PaaS services such as etcd server, istioD, kublet k8 scheduler etc Worker node will host the application pods(more details on k8 cluster : https://kubernetes.io/docs/concepts/overview/components/)

Figure below shows illustration of approach B implementation, where:

 

1)   3 Linux VMs are created to form single k8 cluster

2)   VM 1 is acting as k8 worker node, where four Pods/Microservices delivers 5G element SMF functionality. All SMF pods are running on SMF namespace.

3)   VM 2 is acting as k8 worker node, where four Pods/Microservices delivers  5G element AMF functionality. All AMF pods are running AMF  namespace.

4)   VM 3 is acting as k8 control node where four Pods/Microservices delivers  k8 control  services (e.g Etcd, kublet, kube-schedular, etc)  functionality.

5)   Microservices are interconnected via service mesh provided by Istio.

6)   Pod-level redundancy are provided by replica-set feature of Kubernetes

As I have explained, ETSI has tentatively defined three approaches for Telco’s CNF migration. We have discussed about approach where Application containers run inside host VM. In this scenario, Telco requires openstack and Kubernetes orchestration systems work in parallel.

In upcoming blogs, I will share my knowledge on CNF networking and K8 PaaS services. 

 

5G MEC API

5G technology brings 1ms data latency (between mobile device and base station) , while providing 1-10 Gbps of speed (100X more 4G) , as you can see below:

U.S. researchers have discovered that the human brain can interpret images that the eye sees in just 13 milliseconds. With 1 ms of point to point latency, 5G has surpassed  the human brain processing speed.

This advancement  in latency and bandwidth opens plethora of new opportunities, such as supporting mission critical, time sensitive applications e.g AR and VR applications where digital objects are over-layered on physical world and user interaction is in real or near real time.

For 5G to support new types of applications which requires ultra low latency,  processing of data has to be closer to user  and that’s the basic objective behind Edge computing.  

Edge computing is brining data processing near to customer from existing data center, where server is located. That data center can be private datacenter or public cloud provider data center

As we can see in picture below, a video game application has requirement of ultra low latency ( >10 ms). If game server is hosted at centralized cloud location, latency would be appx. 500ms or more.

By hosting game server at edge location, latency targets can be met.  We can also see that game server has moved to edge but the data back-up server (non real time application) has remained at centralized cloud location. Reason for this design is that edge location should have smaller footprint that centralized location and hence only mission critical functionality should be hosted at Edge. Other non mission critical functionality should be at centralized location. 

What is MEC

MEC is mutli access compute, an edge application server defined by  ETSI and included as part of 5G service architecture by 3GPP.  The basic idea behind MEC is that by running applications and performing related processing tasks closer to the cellular customer, network congestion is reduced and applications perform better. As in eksample above Application server(green box) can be designed as MEC with video analytics as core functionality.  Apart of providing generic architecture of MEC application,

 

MEC Service APIs

ETSI  has also defined MEC service APIs with can be used by developers to develop edge application. Details of released MEC APIs can be found here: https://forge.etsi.org/gitlab/mec

The original API frameworks released are as following:

GS MEC 009 — General Principles for Mobile Edge Service APIs: These principles are the processes for documenting RESTful multi-access edge service APIs, including naming conventions, directions for making APIs compliant to the OpenAPI specification, and outlining API patterns.

GS MEC 010-2 — Mobile Edge Management; Part 2: Application Lifecycle, Rules and Requirements Management: This standard details the application’s lifecycle management while using the edge of a network.

GS MEC 011 — Mobile Edge Platform Application Enablement: This standard provides how the information flows between the application and the platform, what information is necessary for the communication to work, and illustrates the data model.

GS MEC 012 — Radio Network Information API: This provides radio network-related information to mobile edge applications and to mobile edge platforms

GS MEC 013 — Location API: The purpose of this API is that the “edge platform or applications perform the active device location tracking, location-based service recommendation, etc.”

GS MEC 014 — UE Identity API: This API tags the user’s equipment (UE) to map it in the network operator’s system so the system can enforce its traffic rules for that UE.

GS MEC 015 — Bandwidth Management API: The API for the Bandwidth Management Service (BWMS) allows applications to register for the bandwidth allocation needed to run.

Above mentioned, MEC service APIs bridge two  the distinct worlds : 1)  global communication service providers (CSPs) and 2) application developers that need to use services exposed by the CSPs.  

By providing these API frameworks, Telecom has opened doors to application developers worldwide to develop AR & VR types applications using 5G edge computing technology. For eksampel, now VR gaming developers can use  Bandwidth Management APIs to register required bandwidth in order to provide optimal experience to their users.  Developers can directly connect with Telecom network infra, and communicate their needs, rather than work in silo.

Reference:

https://www.etsi.org/technologies/multi-access-edge-compu

https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp28_mec_in_5G_FINAL.pdf

https://www.3gpp.org/news-events/partners-news/1969-mec

https://www.sdxcentral.com/edge/definitions/mec-applications/