Amazon shook the wireless networking industry last week with their disruptive managed Private 5G offering announcement. Though their statement is short on details and is likely to be heavy on marketing and light on implementation, it is nevertheless a very important milestone for the industry.

‍

WHAT DOES THE ANNOUNCEMENT VALIDATE?

The announcement validates a number of important points:

• Cloudification is now a given: A no brainer—Private 5G is going to be completely software driven with the 5G radio being the only non-cloud hardware component.
• Private 5G is real: I talk to some people who question the need for  Private 5G and hypothesize that Private 5G is years out. Apparently not so, given the push by the most dominant cloud provider in the world.
• 5G pulls edge computing: It appears that Amazon is betting that Private 5G will massively increase the demand of AWS infra for edge computing applications (MEC). AWS is not interested in Private 5G per-say, the real prize is the demand for AWS infra.
• Management plane is the key: The management plane is vital to the solution. The entire 5G + edge computing solution is going to be software (see point#1) and will be spread across 1,000s or 10,000s of edge locations. Also, the environment will change dynamically through DevOps. All of this means that the stress on the management plane will go up exponentially, and Private 5G differentiation will center around the management plane as opposed to the data plane.
• Wifi like pricing: Perhaps the most important aspect of the announcement is the simplicity of pricing, very much akin to Wifi. This is the way it should be. Why should Private 5G pricing be linked to public mobile network metrics such as the number of connected devices?
• Managed services is the future: This announcement is further validation that enterprises are not interested in building or managing IT infrastructure. They would rather have someone else take care of it.

WINNERS and LOSERS

I think telcos will be negatively impacted by this announcement. A number of analysts are taking the view that telcos need not be terribly concerned about the AWS announcement because it’s too lightweight. Or they take the view that ultimately AWS will be dependent on telcos to sell their offering. In fact, recent news states “Verizon CEO Hans Vestberg not worried about AWS private 5G .“ Hmmm… I am not convinced about this bravado.

I think if telcos are not sounding the alarm bells internally, they are going to be sitting ducks. Yes, I think telcos and hyperscalers can collaborate on public networks. But on private networks, I think it’s an either-or situation. Sure, telcos have licensed spectrum and they have the ability to create interesting offerings like PNI-NPN (public network integrated non public network). But I don’t think these features are big enough in the long term to be a substitute for innovation. The only way for telcos to block hyperscalers is to innovate quickly and get interesting Private 5G solutions out in 2022.

Another group that will be impacted is 5G dataplane vendors. Offerings like the AWS along with SDO efforts and open source  projects will increasingly standardize the data plane.

The ultimate winners are enterprise customers. The offering, should AWS pull it off, is in the right direction.

WHAT IT MEANS FOR AARNA

The AWS announcement validates our strategy in a fairly substantial way. The management plane is clearly the critical control point in the AWS announcement.

However, I think AWS is underestimating the problem of multi-domain orchestration. Once the solution goes beyond being a “starter-kit”, it will require integration with radios, SD-WAN, firewalls, edge computing applications, transport networks, heterogeneous multi-clouds, and more.

Aarna leverages open source that enables us to incorporate the learning from numerous customers and use cases, and our packaging will allow users to consume the technology with ease.

Solving this difficult problem is our strength, and this is where we can shine. I am hoping the AWS announcement is the gravity assist that we can use to propel us into orbit in 2022! Stay tuned for more...

5G and Edge Computing enable a wide range of use cases from Industry 4.0, healthcare, precision agriculture, to connected cars. These use cases demand low latency, reliability, mobility, low power, or high bandwidth along with a multi fold increase in the number of connected devices. And 5G is the ideal network to connect end-devices to edge computing applications that will enable these use cases.

‍

However, 5G networks include a number of new innovations that the community may not be familiar with. While there is a ton of marketing material on these technologies, it is very difficult to find insightful technical material short of reading the standards. We at Aarna.mlhave launched a series of Tech Talk Videos, in which our subject matter experts will explain these new 5G and edge computing terms in roughly 5 minutes.

We will cover topics like NWDAF, NonRTRIC, CSMF, NSMF, NSSMF, O-RAN SMO, O-RAN interfaces, MEC orchestration, traffic steering, local breakout and many more. We will ask relevant questions on each topic and let our experts explain these topics in video interviews.

Subscribe to our Youtube channel along with the Tech Talk Playlist and stay up-to-date with the latest 5G and MEC terms.

NWDAF (Network Data Analytics Function) is a network function in 5G Core. With the increase in 5G requirements, a huge number of cell sites and connected devices lead to a surge in requirement of 5G bandwidth. NWDAF provides analytics to 5GC NFs and OAM. It uses standard 3GPP interfaces for centralized data collection and analytics through subscription or by request. NWDAF collects data from various resources like the NFs of the 5GC (AMF, SMF, UPF, etc), Application Functions (AF) and OAM. After collecting all the metrics it analyses and correlates the data and provides the analytics in the form of 3GPP specified APIs.

Analytics reporting information provided by NWDAF are:

• Statistics - NFs/OAM request analytics target period in the past.
• Predictions - NFs/OAM request analytics target period in the future.

NWDAF retrieves network data from 5G NFs and management data from OAM :

• AF  Data ( possibly via NEF)
• UE related data from NFs
• OAM global NF data

‍

The above diagram shows the logical components of NWDAF from Aarna.ml. The NWDAF Service API, as part of 3GPP specs, has Analytics Info Service and Subscription Service. Subscription Service provides data in a periodic fashion. The Data Collector in NWDAF collects data from

NF/AF and pushes it into further layers. Data Transformation layer transforms the data before it reaches the database or data repository. Analytics - Historic is mainly for statistics which consists of Analytics Application and Analytics Algorithm. Analytics Predictions give the predictions and manage the AI/ML Model Catalogue. It also includes the Deployment Model and Training Model. Our partner Predera helps us with the MLOps part. The outputs from NWDAF are then formatted by Output Formatter and finally notifies the subscribers.

Demo Modules consist of -

●       NWDAF : from Aarna.ml

●       NRF: from Free5GC

●       AF: is the consumer of the data from NWDAF

‍

Explaining the NF Load Use Case -

●       NF Load Use case: NWDAF provides NF load analytics of specific NFs in the form of statistics as well as predictions.

●       Input data sources are OAM and NRF.

●       Output analytics  are Network Function Status (whether it is up and running or down), resource usage(cpu, memory, storage) and the NF load.

●       Helps in infrastructure scaling and insights of service experience. Based on NF load analytics autonomous networks can take a decision to scale out and obtain insights of the running status of the NF.

‍

In our demo AMCOP from Aarna.ml is used for deployment and configuration of all these NFs. It can deploy the Network Functions in multiple edge clusters. However in this demo we deployed the NFs on a single edge cluster and monitor the interaction between them. The demo flow has been explained below (in reference to Fig 2).

1. Design and orchestrate NRF,NWDAF registers itself with NRF with the help of NF register request.
2. Design and orchestrate AF. AF      will discover NRF through Day0 configuration and obtain the NWDAF end      points
3. AF queries NWDAF AnalyticsInfo  API to get NF_LOAD data
4. NWDAF analytics info API      implementation internally calls CPU prediction model to get the cpu predictions
5. NWDAF creates output responses      as per the 3GPP standards

To see the demo please follow the  video.

Try out the latest release of AMCOP for a free trial. For further questions please contact us.

The Linux Foundation Open Networking & Edge Summit or the ONE Summit virtual event will be held from October 11-12. The event is promoting end-to-end connectivity solutions powered by Open Source and will showcase collaborative efforts that are defining the future of networking and edge computing. We are participating in two-panel discussions, three presentations, and three demos (explore the schedule). Below is a brief description of the various sessions Aarna.ml is participating in.

‍

1. Keynote Address on Network Slicing for the 5G Super Blueprint (11th October, Monday 9:00 AM PDT)

Recording here

Slides here

In this keynote address, we will discuss the state of network slicing for the 5G Super Blueprint and show a demo of video streaming through two slices, each with a different bandwidth service level agreement.

2. Complex Infrastructure Design and Multi-Domain Orchestration using EMCO and ONAP CDS (12th October, Tuesday 5:00 PM PDT)

Recording & Slides here

In this panel discussion jointly with Equinix, we will cover the Public Cloud Edge Interface – Akraino Blueprint.

Edge computing requires orchestration, management, and automation across multiple domains. These tasks can quickly become complex, especially in a cloud-native environment with a large number of cloud-native network functions (CNF) or cloud-native applications (CNA). The LF Edge Akraino Public Cloud Edge Interface blueprint solves one such use case where the tasks range from edge cloud infrastructure deployment, edge cloud application orchestration, public cloud application orchestration, edge cloud to public cloud network orchestration, and registration of edge cloud applications with the public cloud applications. In this presentation and demo, we will show how two Linux Foundation Network projects: EMCO (a new addition to LFN) and ONAP CDS can be used to automate the various tasks required for end-to-end provisioning.

The purpose of Public Cloud Edge Interface (PCEI) Blueprint is to develop a set of open APIs, orchestration functionalities, and edge capabilities for enabling Multi-Domain Interworking across the Operator Network Edge, the Public Cloud Core and Edge, the 3rd-Party Edge as well as the underlying infrastructure such as Data Centres, Computer Hardware and Networks. In the Infra Design and Multi-Domain Orchestration Demo, we will deploy EMCO 2.0, CDS, and CBAs, publish the cluster info, application helm charts, and Terraform plans to GIT, design the edge and public cloud infrastructure then provision the CDS/Terraform infrastructure be it bare metal (Equinix Metal Cloud), K8S on bare metal and Azure cloud. Thereafter we will interconnect Edge Cloud with Public Cloud and finally deploy the Edge Application - dynamic K8S cluster registration to EMCO and dynamic onboarding of App Helm Charts to EMCO.

‍

3. ONAP for Enterprise Business (11th October, Monday 3:40 PM PDT)

In this joint panel discussion with AT&T and Ericsson, we will cover the role of ONAP for Network Automation, RAN Virtualization and acting as an enabler for Enterprise Market:

Over the last 4 years, the ONAP community has been collaborating with the Industry through cross open-source community engagement and cross-influences with SDOs. We have developed impactful features like 5G Footprint, Network Slicing, and O-RAN integration. We continuously add more cloud-native, modular capabilities, and robust integration. We are also implementing ONAP “best practices” in our source code to offer scalable, reliable, and secure production readiness deployments. All this -- makes ONAP a true enabler for Innovation. While ONAP has primarily been used by Network Service Providers to support their Network Automation Transformation and RAN Virtualization Journey, the ONAP Community also recognizes the value of ONAP in the Enterprise/Vertical markets. A new TSC Task Force was therefore created on January 20th, 2021 in order to define ONAP added-value for Enterprise Business. This session will share the role of ONAP in the “5G Open Source Stack Initiative“ recently launched by the Linux Foundation Networking - Codename « 5G Super Blueprint » We will explain how the ONAP Platform will interact with the Magma open-source platform and with other 5G Super Blueprint components.

We will explain the roadmap of ONAP right from defining Magma Controller CNF and AGW VNF using ONAP Integration to the orchestration of Magma Controller and AGW CNFs using ONAP, Network Slicing Optimization, and many more. We will explain the 5G Open Source Stack Initiative and dive into the applicability of ONAP for Orchestration and Life Cycle Management, Cloud-native Modularity, 5G Network Slicing, supporting ORAN SC SMO and Control Loop Automation. We will explain the compliance of ONAP with Anuket which delivers a common model, standardized reference infrastructure specifications. ONAP / Anuket integration leads to the deployment of ONAP using Kuberef. We will explain the architecture and key points of Magma and then delve into the scope of integration of ONAP with Magma.

4. AI/ML, Data Analytics, Closed Loop Control (12th October, Tuesday 5:00 PM PDT)

The O-RAN Alliance and 3GPP specifications call for analytics functionality to be implemented in the Service Management & Orchestration (SMO) and Operations Administration & Management (OA&M) software. Though the functions span different domains, O-RAN and 5G Core, they have a striking resemblance in what is required of them. In this session, we will show how various components of ONAP DCAE can be used to implement the functionality of NONRTRIC and NWDAF in an architecturally unified manner. We will show what external glue logic (such as the LF AI Acumos project) is needed to build these features and what interfaces are expected from the 5G Core and RAN functions (which can be commercial or open-source).

‍

5. Multi Kubernetes Cluster Networking, Mesh and Application Orchestration in Open Source Way (11th October, Monday 4:20 PM PDT)

Traditional hybrid cloud deployments worked fine with several discrete control planes, one for each functionality – SDN controller for switch & transport automation, individual cloud orchestrators for application deployments, few security control planes for threat security, service assurance central platform for analytics and observability, and many more. As Enterprises adopt multi-cloud and multi-edge strategies for their application deployments that are on-demand and sometimes ephemeral, the industry sees the need for a universal control plane that automates infrastructure in an end-to-end fashion in tune with the application lifecycle. The newly introduced Linux Foundation Networking EMCO project is one such open-source initiative that is striving to address the needs of a universal control plane. In this panel, we will reiterate enterprise requirements, introduce EMCO, its features, the need for open-source, and how it addresses the lock-in issues that enterprises care about.

‍

6. Cloud Native 5G Blueprint Network Slicing Demo

The LF Networking community has enhanced the 5G Super Blueprint foundation by adding network slicing on the 5G cloud-native network demo. This POC is based on the ONAP Honolulu release and demonstrates an open-source approach to improving QoS in 5G networks by optimizing network resources and topologies driven by 5G use cases, MNOs would be able to achieve improved performance and greater flexibility. The demo will also showcase a custom Network Slice Subnet Management Function (NSSMF) that was developed as part of this effort.

See the demo here.

‍

7. LF Edge Akraino Private LTE/5G ICN Blueprint Demo

In this demo, we will showcase the integration of various open-source projects under LF and CNCF to realize an E2E solution for private-5G connectivity. The focus would be automation required to provide 5G connectivity in multiple sites by deploying 5G network services with multiple CNFs, life cycle management of 5G services, and connectivity & security automation. It uses EMCO for automation, Akraino/ICN platform for Edges/Sites with Edge/Telco K8s extensions, and Magma/free5GC for 5GC and simulated 5GRAN.

See the demo here.

‍

8. EMCO + Magma Demo

In this demo, we will show how the new LFN Edge Multi-Cluster Orchestration (EMCO) project can be used to deploy Magma Orchestrator and Access Gateway (AGW) on a Kubernetes cluster with appropriate Day 0 configurations. The benefit of this integration to users is to reduce the manual and error-prone tasks required to deploy Magma. The demo will also talk about the roadmap where Day 1, 2 configurations, lifecycle management, network slicing, and service assurance can all be automated.

See the demo here.

‍

I hope you can join us!

The Aarna.ml Multi-Cluster Orchestration Platform (AMCOP) is an open-source orchestration, lifecycle management, closed-loop automation platform for 5G network services and edge computing applications.

‍

AMCOP consists of:

‍

●   Linux Foundation Edge Multi-Cluster Orchestrator (EMCO) for intent-based orchestration and Day-0 configuration

●   Linux Foundation Open Network Automation Platform (ONAP) components such as CDS for Day 1 & 2 configuration and LCM

●   Select ONAP components for analytics and closed-loop automation

●   Numerous CNCF and related projects (Istio, Prometheus, FluentD, Jaeger…)

●   Proprietary value adds such as 5G network slicing, O-RAN NONRTRIC, NWDAF

‍

In this blog, we will talk specifically about the deployment of AMCOP. AMCOP is a full cloud-native application that can be deployed on a Kubernetes (K8s) environment. In general, the various deployment options for a cloud-native application are:

‍

●        Using Kubectl command line when there is a yaml file

●        Using Ansible scripts that allows automation of these deployments

●        Using Helm charts

●        Using Operators and Custom Resource

‍

With version 2.0 and earlier of AMCOP, it used to be deployed using Helm Charts and Ansible scripts.

The challenges with earlier methods of cloud deployment of AMCOP were:

‍

●        The scheme was static and not capable of dealing with complex setups.

●        Life Cycle Management (LCM) with Helm charts and Ansible was not fully automated and required manual intervention.

●        While deploying, it was not possible to store the state of deployment for retrieving it later or for restoration.

●        The upgrade process was difficult and manual.

‍

With AMCOP 2.1, we have switched to a Kubernetes Operator. What is a Kubernetes Operator?

A Kubernetes operator is a method of packaging, deploying, and managing a Kubernetes application. The Operator has a Controller and Custom Resources. It provides a single package that one can deploy to the K8s cluster and that package will take care of the entire LCM of the application being deployed. Thus an Operator creates, configures, and manages instances of complex applications. Its Controller has the current state and details of the desired state. It monitors the current state and ensures that the application is always in the desired state. It can manage Stateful Set, Config Map, Services, and the different Pods. Once it is deployed the Operator will continue to monitor the application. One can automate the Operator to take backup of the data and if there are failures then it can take care of the recovery process. The Operator can auto-upgrade the application when a newer version is available. The Operator also does not require full security privileges, as it uses a limited set of resources and shared resources.

‍

Advantages of deployment of cloud-native applications using Operators are:

‍

●        Integration with various solutions

●        Helm is supported

●        Can be deployed on Openshift clusters

●        Ansible Playbook can be integrated for doing various tasks

●        Reduces engineering cost and makes maintenance much easier

‍

Operators are purpose-built and are not generic to work with any application. While building the Operator for a specific application, one needs to have knowledge of how the application works, what services it is creating, etc. Thus the Operator is more tailored to the specific needs of the application. One can do complex automation using the Operator.

‍

Specifically, the features of the AMCOP Operator are:

‍

●       Kubernetes Controller built using Operator SDK

●       Built-in logic to address Life Cycle Management requirements of AMCOP

●       Unified handling of Life Cycle Management for AMCOP

●       Functionalities of Helm, Juju Charms, Ansible, and Operator LCM

‍

The AMCOP Operator has a container image, which contains all the logic for deploying the Operator. To initiate this, a yaml file is provided for deploying the Operator on the cluster. Tags are used for downloading various images. There are yaml files for EMCO microservices. Once the Operator is deployed, it can be enabled to allocate all the resources, create the necessary service account, trigger a requirement, and finally, deploy the K8s Pods.

To see the deployment process please follow the steps in the video.

Try out the latest release of AMCOP for a free trial. For further questions please contact us.

Introduction

5G Network Slicing is a new concept to allow differentiated treatment to network traffic depending on each customer's or use case’s requirements. With slicing, it’s now possible for Mobile Network Operators (MNO) to consider customers or use cases as different context types with each having different service requirements. These requirements are governed in terms of what slice types each context is eligible to use based on Service Level Agreements and subscriptions. In order to orchestrate and manage 5G network slicing, the Linux Foundation Open Network Automation Platform (ONAP) project has come with E2E slice management architecture with different choices based upon various 3GPP defined components with specific roles (e.g CSMF, NSMF, NSSMF). In this blog, we shall uncover the architecture of NSSMF and its interaction with other components.

Keywords

3GPP - 3rd Generation Partnership Project

BSS - Business Support System

E2E - End to End

CSMF - Communication Service Management Function

NSMF - Network Slice Management Function

NSSMF - Network Slice Subnet Management Function

NSI - Network Slice Instance

NSSI - Network Slice Subnet Instance

ONAP - Open Network Automation Platform

OSS - Operations Support System

SO - Service Orchestrator

‍

5G ONAP Network Slicing

In ONAP, options 1 & 4 from the various slice management architecture choices are supported — see Figure-1.

Essentially, the choices have evolved from the requirements of service providers and open source community contributors. In Architecture Choice#1, CSMF, NSMF, and NSSMF are internal components of ONAP in reference design and implementation. In this option, OSS/BSS can integrate with the runtime component CSMF hosted in SO for business and operational needs. In Choice#4, CSMF and NSMF are internal components of ONAP and hosted in a runtime component called SO. In Figure-1, CSMF takes the business requirements from OSS/BSS and transforms communication service requirements to network slice requirements and is consumed by NSMF. Moreover, NSMF is responsible for the management and orchestration of NSI and derive network slice subnet requirements. In choice#4, NSSMF is an external component and is responsible for the management and orchestration of NSSI. ONAP has implemented standard APIs defined by 3GPP towards NSSMF and the same is[1] [2]  listed below in Table-1.

‍

NSSMF Architecture

As we uncover architecture choice#4, NSSMF performs communication with the ONAP NSMF component and that integration is done using the standard RestAPI interface as per Table-1 shown above. In our NSSMF architecture as shown below in Figure-2, consists of various elements and is defined as:

• NBI Interface: This is the reception point for all the incoming requests from NSMF using the RestAPIs as detailed in Table-1.
• Model Validator: This component validates the incoming NSMF requests with predefined models for various lifecycle events of a slice.
• NSS Manager: Network Slice Subnet manager decides the role of processing the incoming request in Asynchronous or Synchronous flow mode.
• Egress Manager/Ingress Manager: NSSMF is defined with two internal roles. First being a forwarder and second as a receiver. This helps in a distributed model for processing slice events.
• CnCfgManager: The core network configuration manager is responsible for processing the slice events received from the Ingress manager for event types as AllocateNSSI, ActivateNSSI, DeactivateNSSI, and DeAllocateNSSI. Core network configuration manager was built with the support of NETCONF client and RESTCONF interface to cater deployment of network functions (NF) as PNF and CNF respectively.

We have done a webinar on deep dive on NSSMF architecture wherein we talked about insights and how the slice event lifecycle is processed by NSSMF and provisioning a commercial 5GC Network functions with a demo. You can refer to the video for details. Also, if you want to try out this NSSMF in your setup, reach out to us at info@aarna.ml

References

• 3GPP TS 28.541
• 3GPP TS 28.531
• https://wiki.onap.org/display/DW/R9+E2E+Network+Slicing+use+case

‍