‍

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!

I attended the Private Networks Forum on Tuesday. My interest of course was to understand the management plane (orchestration, lifecycle management, closed loop automation) perspective, especially for Private 5G. Here is what I learnt:

1. It was fascinating to see that almost every time the management topic came up, the number one comment was around the need for simplicity. Enterprises, unlike telcos, are not in the business of running networks and are unable to put together a complex 5G network.
2. Another requirement is flexibility — flexibility in supporting Standalone Non Public Networks (S-NPN) vs. Public Network Integrated NPN (PNI-NPN), choosing different 5G core and RAN vendors for eMBB vs. uRLLC vs. MMTC workloads, placing network functions differently depending on the performance requirements, and E2E 5G network slicing.
3. Next speakers echoed how Private 5G deployment will include edge computing applications. There are of course scenarios where purely a high performance, low latency, highly reliable wireless network makes sense as an alternative to wired networks; but by and large the speakers talked about the need for edge computing applications to extract business value. From my point of view, a Private 5G network is a means to an end, rather than the ultimate goal in itself.
4. A Private 5G network will be a very dynamic environment. There will be major upgrades going on e.g. Rel 15 to Rel 16 (the underlying assumption being that  Network Functions will be virtualized or containerized). Network functions might get updated every so often. Dynamic slicing may be going on. All of this makes it very important to plan for a dynamic environment.
5. Finally, the speakers talked about the need for tailored solutions based on use cases. Extrapolating, I can imagine solutions tailored for hospitals, factories, farms, etc. that include the right network functions in the best proven reference architectures, provided along with most popular edge computing applications for that use case.

As you can imagine, these requirements are a great fit for us. The Aarna.ml Multi Cluster Orchestration Platform (AMCOP) product is specifically designed for the orchestration, management, automation, and network slicing of Private 5G networks and edge computing applications. Try AMCOP for free today! Or if you would like to see a private demo of any of the aspects described including network slicing, please contact us.

With 5G, the entire environment becomes cloud/edge and software-driven, unlike 4G. This makes network service management which includes orchestration, lifecycle management (configuration and security settings), and service assurance complex and not viable via existing mechanisms. Given the flexibility with software, the permutations of configuration and security settings for 5G result in a very large number, and choosing the right settings becomes very challenging. So, having to sort through these different configurations and combinations makes the eventual network service deployment a big challenge.

‍

AARNA and REBACA Joint Offering:

The solution has two key components:

• AMCOP – Aarna.ml Multi-Cluster Orchestration Platform
• REBACA’s ABot – 4G/5G Network Tester

One of the key elements in the process of automation is to validate the setup, be it some device under test or an emulator. ABot is a uniquely different from other emulators as follows:

• Emulation of any 4G/5G network components for validation as per 3GPP standard
• Ability to support any IP based protocol like SIP, MQTT
• Interop, Performance Benchmark and Integration Testing support
• Reusable test templates in natural language for easy user acceptance and faster deployment
• Test results analysis for detecting failure of procedures, messages, events, and associated KPIs
• Insight like: Coverage, Product Maturity, Consistency, Build-by-build analysis
• Redundant or missing test vectors in a test suite identification
• Root Cause Analysis and Event Suppression thus facilitating in debugging
• Completely cloud-native and seamless integration with any Orchestrator and CI/CD pipeline
• Distributed deployment across Operator’s Network, Cloud Provider’s Data Centre and Edge Network
• Network functions simulated by ABot can be deployed as Kubernetes pod on any hypervisor
• Can be managed by any Network Orchestrator like AMCOP, OSM, Juju, Cloudify, etc.

‍

Key Features of AMCOP:

1. Kubernetes cluster registration
2. Cloud-Native Network Function (CNF) and Cloud-Native Application (CNA) onboarding
3. Network Service (with CNFs) or Composite Application (with CNAs) design
4. Intent-Based Orchestration of network service or composite application
5. Ongoing lifecycle management and day 1, 2 configuration of network service or composite application
6. Monitoring of CNFs or CNAs resulting in real-time policy-driven closed-loop automation

A high-level block diagram of AMCOP is shown below:

‍

A joint solution with AMCOP and ABot results in seamless design of a 5G core as follows:

• AMCOP is used to configure and provision any 4G and 5G Network Function with both SUT and ABot emulated nodes
• AMCOP then invokes ABot end-to-end test scenarios to exercise different use cases
• ABot Analytics captures different Mobility KPIs, Infra KPIs, and other test statistics
• ABot Analytics can provide relevant analytics insights to AMCOP (as events)
• AMCOP’s Analytics Program (AAP) drives orchestration and configuration changes, and if needed, reruns the tests to make sure the new configuration is what we desired.

‍

With AMCOP and ABot working together, one can automate the entire process by going through this closed-loop repeatedly and arrive at an ideal environment/configuration. It will also help the user understand how the network would work under different configurations. In this manner when the 5G Core is put into production, the user is assured that it will work optimally to meet their specific requirements.

‍

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.

In my previous two blogs in this three-part series, I covered O-RAN Architecture and SMO and Non-Real-Time Radio Intelligent Controller (non-RT RIC) : Data driven RAN optimizer topics. In this last blog of the series, we will look at a traffic steering example Non-RT RIC use case that deals with optimizing traffic management or achieving balanced cell load.

Traffic management Use case

The Non-RT RIC configures the desired optimization policies, utilizes the right performance criteria, and leverages machine learning to enable intelligent and proactive traffic steering control. This use case is primarily based on the O-RAN architecture and its constituent entities.

Roles

As a refresher from the first blog in this series, here are the roles of each of the entities from a traffic steering use case point of view:

SMO/Non-RT RIC

1. Retrieve necessary performance, configuration, and related data for defining and updating policies to guide the behavior of traffic steering function in the near-RT RIC.

2. Support communication of policies and enrichment information to the near-RT RIC and measurement configuration parameters to RAN nodes.

Near-RT RIC

1. Support interpretation and enforcement of policies from non-RT RIC.

2. Use enrichment information to optimize control function.

CU/DU/RU Nodes

1. Send FM/PM/other data with required granularity to SMO.

The Non-RT RIC platform resides inside the SMO, collects the data, and derives analytics information which is used in the traffic steering use case and same can be extended to other use cases as well.

Policy Management

This section deals with the traffic management in RAN according to defined policies and configuration.

Prerequisites:

• All the RAN components (CU, DU, Near-RT RIC etc.) and SMO are deployed
• A1 and O1 interfaces are configured correctly
• SMO collects the data and send it to the Non-RT RIC platform that derives analytics out of this data

Trigger:

The Non-RT RIC platform monitors the performance data and different counters from the various E2 nodes. Based on the trigger (defined by operator) or a generated event, the Non-RT RIC initiates a change.

Operations:

1. The Non-RT RIC decides upon an action and communicates relevant policies to the Near-RT RIC over the A1 interface. The example policies may include:
2. QoS targets
3. Preferences on which cells to allocate control plane and user plane
4. The Near-RT RIC receives relevant information from Non-RT RIC over A1 interface, interprets the policies and enforces them.
5. The Non-RT RIC decides that conditions to continue the policy are no longer valid.
6. The Non-RT RIC deletes the policy.
7. The Non-RT RIC continues to monitor the performance data (events and counters from E2 nodes).

Example:

Let us look at an example scenario to describe the use of A1 for traffic steering, where the Non-RT RIC sends policies for allocation of the control plane (RRC) and the user plane for different services, identified by their 5QI (5G Quality Service Indicator).

‍

Cell A & B:

• Low band, narrow bandwidth, low latency
• Ideal for voice and control plane

Cell C & D:

• High band, wide bandwidth, high latency
• Ideal for data connection

In the scenario a UE with UEid=9999999999, belonging to a subnet slice identified by S-NSSAI=10, having a Voice (5QI=1) and an MBB (5QI=9) connection established, enters an area covered by four frequency bands.

The Non-RT RIC understands the requirements and characteristics of the services and decides to let the Voice and RRC connection reside on the low band (here covered by a macro cell B becoming the PCell), while the MBB (MobileBroadBand) connection should preferably use the higher band (here provided by small cells C and D becoming the SCells) and avoid the low band if possible. Cell A is used for MBB if required for coverage reasons.

NonRTRIC policy change directs control pane and voice on cell B:

‍

Policy change from NonRTRIC related to MBB:

‍

Summary

We have seen how the Non-RT RIC can take decisions on pushing the optimal policies to the Near-RT RIC based on the cell characteristics. This use case explains this capability of the Non-RT RIC in the traffic steering example and the same principles can be applied to various other scenarios as well.

References: O-RAN specification documents

Images credit: O-RAN-SC

5G network slicing holds tremendous promise in terms of allowing services with completely different characteristics to share a particular 5G network. Even in a private 5G network, enterprises will be able to use the network for multiple applications. When we talk about a 5G network, there are typically three components that come into play:

• Radio Access Network
• Transport Network
• Core Network

When we say we are creating a slice, the slice needs to be created end-to-end across these three domains: RAN slice, Transport slice, and Core slice.

‍

‍

The Linux Foundation Open Network Automation Platform (ONAP) provides comprehensive support for end-to-end network slicing. It can be used to create a slice and configure the above three domains and/or spin up new instances of network functions. The slice can be activated once we have set the different configuration parameters.

The diagram below shows a high-level 3rd Generation Private Partnership (3GPP) view of how a network slice should look the different constituent components:

‍

‍

ONAP can be used to design network slice template and then an operator can order a slice using APIs or a graphical user interface via the communication service management function (CSMF). Next, the network slice management function (NSMF) chooses the network slice instance and hands off the actual domain specific tasks to specific RAN, Core, or Transport network slice subnet management function (NSSMF). External NSSMFs are also supported.

To see a thorough explanation of these concepts and to see a recording of a hands-on demo using ONAP's upcoming Honolulu release, view a recording of our End-to-End Network Slicing technical meetup from two weeks ago (1 hour at 1x speed). If you don't have the time, you can watch just the demo portion of the meetup (10 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.