The Aarna.ml Multi-Cluster Orchestration Platform (AMCOP) performs orchestration, lifecycle management, and analytics/closed-loop automation for cloud-native 5G network services and edge computing applications. The last part of the functionality is through a component called the Aarna Analytics Platform (AAP). The AAP uses open source software from ONAP DCAE (Data Collection Analytics and Events) and the DMaaP (Data Movement as a Platform, which is based on Kafka). Aarna Analytics Platform includes both the 3GPP NWDAF and the O-RAN Non-Real-Time Radio Intelligent Controller (Non-RT RIC) functionality.

NWDAF or Network Data Analytics Function provides analytics to 5G Core Network Functions (NFs) and the OAM platform. NWDAF has 3GPP defined interfaces using which NFs can request analytics information. There can be multiple instances of NWDAF deployed in the 5G Core. Each NWDAF is identified by the NF-ID and the Analytics ID. Like other NFs, NWDAF registers itself with NRF (Network Repository Function) of the 5G Core, enabling other NFs to reach it.

‍

NWDAF provides statistics and predictions. For prediction, it can make use of ML models, which would be embedded into NWDAF. This ML Model can address specific use cases of 5G.

The Non-RT RIC is a component in the Service Management and Orchestration (SMO) framework specified by the O-RAN Alliance. It enhances the functionality of the RAN by communicating with the Near Real Time RIC (Near-RT RIC) which resides in the edge/remote cluster. The Non-RT RIC provides policies and enrichment information for the RAN to the Near-RT RIC over the A1 interface. The Non-RT RIC is an extensible platform and includes modular applications called rApps. These modular apps can be added in the Non-RT RIC based on specific use cases. Along with rApps, the Non-RT RIC contains A1 Policy function, A1 Enrichment Function and A1 Termination Function. The Non-RT RIC provides enrichment information and the latest A1 policies to the Near-RT RIC over the A1 interface. Using rapid closed-loop automation, the Non-RT RIC can also enable additional advanced SON use-cases. The Non-RT RIC also includes AI/ML functions.

Thus, AMCOP is capable of orchestrating NWDAF in the 5G Core and AMCOP also has the SMO functionality for O-RAN and thus includes the Non-RT RIC functionality. AMCOP utilizes ML models but is not capable of training these models or managing the lifecycle of these models as mentioned above. In order to address the gap Aarna.ml has partnered with Pradera. AMCOP along with Predera’s MLOps AIQ platform serves end-to-end use cases of NWDAF and Non-RT RIC.

AMCOP provides raw training data to Predera’s MLOps AIQ platform by sending telemetry data (metrics, logs, alarms, events) to an external datalake. AIQ uses this raw data to train ML models. These ML models are stored in a catalog such as the LF AI Acumos project. AMCOP then pickes up these MLOps models and uses them for use cases such as the Non-RT RIC, NWDAF, closed-loop automation, and more.

To learn more about Aarna.ml AMCOP, Non-RT RIC, or NWDAF offerings, please contact us. Alternatively, if you are an rAPP vendor that wants to collaborate with us, please do not hesitate to contact us.

To learn more about the AIQ platform, please contact Predera.

‍

‍

‍

‍

‍

‍

This blog is focused on the installation of AMCOP Release 2.1 on any existing Kubernetes deployment using AMCOP Operator. See demo here.

Pre-requisites:

A Kubernetes cluster, which will host AMCOP deployment. AMCOP is validated to work with a minimal single node all-in-one cluster with following hardware configuration

• 8 vCPUs, 32 GB RAM and 80 GB SSD

‍

Storage Class:

AMCOP requires usage of persistent volumes to manage stateful information. These persistent volumes are required to be provided by a default storage class configured with a persistent volume provisioner, more details are available at kubernetes storage class.

Check if there is already a default storage class available in your kubernetes cluster

kubectl get storageclass

If you’re using public cloud, chances are you’ll already be having a default storage class.

Otherwise for the deployment you can proceed with the following to create your own storage class with persistent volume provisioner, where persistent volumes will be backed by local SSD.

kubectl apply -f https://aarna-network.gitlab.io/amcop-deployment/amcop-k8s-operator/storage.yaml

‍

AMCOP Operator:

Once availability of storage class is ensured, we will roll out AMCOP Operator itself

kubectl apply -f https://aarna-networks.gitlab.io/amcop-deployment/amcop-k8s-operator/v2.1.0/operator.yaml

This will deploy the AMCOP Operator deployment along with necessary constructs for RBAC and CRD. This AMCOP Operator deployment carries the intelligence about the components required for AMCOP Release 2.1, dependencies between them and information about ordered roll out of these components.

Additionally, it introduces the Custom Resource Definition (CRD) for defining properties of AMCOP deployment

• Enabling disabling certain components
• Choosing specific storage class instead of the default

‍

AMCOP Custom Resource:

Once AMCOP operator deployment is available, you can now use the Custom Resource of type Installer to customize AMCOP deployment.

apiVersion: amcop.aarnanetworks.com/v1alpha1

kind: Installer

metadata:

name: default

spec:

db:

persistent:

storageClass: ""

debug: enable

cds: enable

‍

In Most of the cases, you will not require to change these parameters and can safely execute creation of Custom Resource using following

kubectl apply -f https://aarna-networks.gitlab.io/amcop-deployment/amcop-k8s-operator/v2.1.0/default.yaml

Upon creation of this Custom Resource, AMCOP Operator starts deployment of various AMCOP components in a staged manner. Progress of deployment can be monitored by watching kubernetes pods in amcop-system namespace or by watching the status of Custom Resource itself.

kubectl get installer.amcop

Over time, when all the components of AMCOP are rolled out successfully. The status of deployment will change from “RollingOut” to “Deployed”, beyond this you can then start using AMCOP.

See a recording of the technical meetup that covered this topic in more depth along with a hands-on demo. If you would like to replicate any of this work in your environment, please contact us.

Interested in an AMCOP presentation and demo meeting? Let us know at info@aarna.ml and we can schedule it.

This blog describes a 5G network slicing demo we did with ONAP as the network slice management component and Capgemini Engineering 5G Core along with the Kaloom UPF.

In an end-to-end 5G network, there are typically three components that come into play:

• Radio Access Network
• Transport Network
• Core Network

These same three components act together and participate in forming an End-to-End 5G network slice. In addition, a slice management component is required, and the Linux Foundation Open Network Automation Platform (ONAP) is one comprehensive solution for this. To learn more, see our prior blog on End-to-End 5G network slicing with ONAP. See a conceptual diagram of end-to-end 5G network slicing below.

‍

Next, the diagram below shows a high-level 3rd Generation Private Partnership (3GPP) view of how a network slice looks and lists the different components:

‍

3GPP has the notion of Communication Service Management Function (CSMF) through which the BSS layer can easily order details of the slice with associated characteristics. Southbound of the CSMF is the Network Slice Management Function (NSMF) which then talks to domain specific Network Slice Subnet Management Functions (NSSMF).

ONAP has constantly been updating the slice management functionality. Currently Options 1 and 4 below are supported. In a recent demo, we at Aarna.ml showed a demo of Option#4 for 5G Core slicing where we used an external NSSMF.

‍

Helicopter View of ONAP Slice Management Functionality:

There is a design-time and runtime dileniation in ONAP; hence with respect to slicing, we also have to design certain models in ONAP which act as the design time aspect of the network slicing. The design part is hosted under a component, known as SDC or Service Design & Creation. Next those models are distributed to runtime that consists of CSMF, NSMF, and NSSMF functions. See diagram below.

‍

Process flow for 5G Network Slicing with ONAP:

• User orders a slice using CSMF
• ONAP NSMF processes the request and identifies the correct slice template
• Slice allocates request submitted to internal of external NSSMFs; in this demo we use an external NSSMF for 5G Core
• The core external NSSMF will call the Capgemin Engineering 5GC REST APIs to configure the slice parameter
• 5GCore components will configure the components and set the slice values

See the flow below.

‍

To see a thorough explanation of these concepts and a recording of a hands-on demo, view a recording of our 5G Core network slicing using ONAP with Capgemini Engineering 5GC and Kaloom UPF technical meetup from one week ago (45 minutes at 1x speed). If you don't have the time, you can watch just the demo portion of the meetup (20 minutes at 1x speed).

A surprisingly large number of companies want to try ONAP network slicing in their labs. If you are one of these companies and need some help, feel free to contact us.

I am pleased to announce version 2.1 of the Aarna.ml works Multi Cluster Orchestration Platform (AMCOP). As a quick recap, AMCOP addresses the orchestration, life-cycle management, and automation of cloud native, B2B, 5G network service + edge computing applications. We support only the Kubernetes NFVI. And we focus on B2B applications e.g., Industry 4.0, healthcare, precision agriculture, and more.

AMCOP 2.1 Free Trial here.

AMCOP supports intent-based orchestration of 5G network services and composite edge computing applications, manages their lifecycle and enables creation of policy-driven control loop automation. In the latest version 2.1, AMCOP added support for edit/modification of Network Services that have already been deployed, comprehensive O-RAN SMO functionality, and also an early access version of network slicing manager, Non-Real Time RIC (NRTRIC) and Network Data Analytics Function (NWDAF)/Management Data Analytics Function (MDAF).

AMCOP is a fully cloud-native application that can run on a variety of Kubernetes clusters (open source k8s, LFN Anuket, as well as all the public cloud variants - GKE, AKS and EKS). It has been integrated with Prometheus, Istio and Keycloak, and will be supporting Jaeger integration soon. AMCOP is installed using the AMCOP Operator, which will manage the complete life-cycle of AMCOP, and enables seamless upgrades to future versions of AMCOP. Support for RedHat OpenShift is coming shortly!

See the AMCOP product page for more information. The product is open source (based on LF Networking and CNCF projects), so you can try it out for free as well.

Also, check out AMCOP demos:

• AMCOP demo of Altran/Kaloom 5G Core orchestration on Red Hat OpenShift (keynote or booth)
• AMCOP demo of Free5GC (5G Core) orchestration on K8s

Alternatively, check out the demos on our YouTube channel:

• AMCOP 2.1 installation using k8s operator on any k8s cluster
• AMCOP 2.1 installation (using AMCOP operator) and vFW orchestration installation on bare metal
• AMCOP demo of SMO functionality
• AMCOP orchestration of Free5GC on K8s
• AMCOP orchestration of Altran 5GC on Red Hat OpenShift

Finally, check out our white papers. They are purely educational and 100% product-free:

• Why Private 5G + edge computing?
• 5G network service + edge computing application orchestration requirements

Interested in an AMCOP presentation and demo meeting? Let us know at info@aarna.ml and we can schedule it.

‍

SAN JOSE, CA, USA, June 15, 2021 /EINPresswire.com/ -- Aarna.ml, Inc., an innovative open source software company, announced today that its flagship product Aarna.ml Multi Cluster Orchestration Platform (AMCOP) is now available on the Intel Commercial Edge Applications portal at https://networkbuilders.intel.com/commercial-applications/aarna.ml. The portal is a resource for cloud service providers, communications service providers, and enterprises (among others) to identify products or solutions fueled by Intel Xeon Scalable processors and have been optimized for Open Network Edge Services Software (OpenNESS), the Intel Distribution of OpenNESS, and/or Intel Smart Edge.

“The portal will help drive visibility for our AMCOP product and expand market reach through Intel’s edge ecosystem,” said Amar Kapadia, co-founder and CEO at Aarna.ml. “Our customers rely on partners such as Intel for leadership products and ideas, and by optimizing our products with OpenNESS, we can increase the value of the overall solution for our customers.”

AMCOP is an open source platform for orchestration, life cycle management, control loop automation and network slicing of 5G network services and edge computing applications. The core network function virtualization orchestration (NFVO) and multi-access edge computing application orchestration (MEAO) functions in AMCOP are based on the OpenNESS Edge Multi-Cluster Orchestrator (EMCO) project. In addition, AMCOP also includes a few select projects from the Linux Foundation Networking Open Network Automation Platform (ONAP).

A number of 5G demos based on AMCOP can be viewed at bit.ly/AMCOPDEMOS and to learn more about Aarna.ml new membership with the portal, please visit https://networkbuilders.intel.com/commercial-applications/aarna.ml.

Intel, the Intel logo, and other Intel marks are trademarks of Intel Corporation or its subsidiaries.

About Aarna.ml

Aarna.ml is an open source software company that enables orchestration, management, and automation of 5G networks and edge computing applications. 5G and Edge are a once in a generation disruption that will fundamentally change how we work and live, and Aarna.ml is well positioned to take advantage of this trend. The company uses the Linux Foundation open source projects for its products and is based in San Jose, CA and Bengaluru, India. Please visit us at https://www.aarna.ml or follow us on Twitter at @aarna.ml.

Linux Foundation Networking is holding a Developer & Testing Forum next week (from June 7 to June 10). We are presenting four sessions (see agenda). Below is a brief description of the sessions:

1. CDS and Terraform for Multi-Domain Orchestration and Interconnection of Cloud and Edge (Tuesday 5:30-6:00AM PDT)

Recordings & slides here.

In this joint presentation with Equinix, we will cover the following:

Most practical deployments of edge infrastructure and applications are hybrid in nature, where an application deployed at the edge often needs to access services residing in the core cloud. In addition, there is a need for efficient and performant interconnection between edge and cloud as well as between the distributed edges proximal to end users. However, each individual service domain (e.g. edge, cloud, network fabric) often presents their own specific APIs and/or other provisioning methods (e.g. CLI), thus making end-to-end deployment challenging both in complexity and in time. Therefore a multi-domain orchestration solution is required to handle edge, cloud and interconnection in a uniform and consistent manner. Terraform is rapidly emerging as a common way to orchestrate and configure services rather than having to deal with APIs for each different domain: public or private cloud, edge and interconnection. In this presentation and hands-on demo, Equinix and Aarna.ml will show how an end-to-end application can be deployed, configured and interconnected between the edge and core clouds  by using ONAP/CDS orchestration in combination with Terraform.

2. CDS to Manage OLT Configuration (Wednesday 8:00-8:30AM PDT)

Recordings & slides here.

In this joint presentation with TIGO, we will cover the following:

With FTTx rollouts progressing, there is an increasing need to manage 10s or 100s of thousands of OLT switches. CDS provides an elegant solution to manage the configuration of these OLT switches. In this talk and hands-on demo we will discuss the CDS Blueprint Archive we developed to solve this issue. After watching this presentation, you will be able to understand how to use CDS to configure PNFs using Telnet.

3. Network Slicing using ONAP and a commercial 5G Core (Thursday 6:00-6:30AM PDT)

Recordings & slides here.

In this joint presentation with Tech Mahindra and Wipro, we will cover the following:

In this session, we will show how to integrate ONAP network slicing with a commercial 5G core. We present the options that are available in ONAP for such an integration, and show a demo of the feature, by creating network slicing templates from ONAP SDC, create a core network slice, activating it (from ONAP UUI), and running a test using a commercial UE/gNB simulator. We also present the future roadmap, and what other possible integration options are available with ONAP Network slicing.

4. Magma Core integration with ONAP as part of the ONAP Enterprise WG Update (Tuesday 7:30-8:30AM PDT)

Recordings & slides here.

A new TSC Task Force was 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 Super Blueprint and share how the ONAP Platform will interact with the Magma open source platform

I hope you can join us!