As you might have seen, we rolled out a new product two weeks ago—the Aarna.ml Multi Cluster Orchestration Platform (AMCOP) 1.0. This is an open source, lightweight 5G + edge computing orchestration and lifecycle management product optimized for Kubernetes environments. We use the EMCO (Edge Multi Cluster Orchestrator) and CDS (Controller Design Studio) software from the Linux Foundation Networking ONAP project to accomplish this. Our goal is to enable b2b applications where the simplicity of the product is the key consideration.

We showed a demo of AMCOP with the Altran 5GC, Kaloom UPF, and Red Hat OpenShift at last week's ONES keynote (If you don't have access to it, you can watch the demo here). Next week, at the LFN Virtual Technical Event, we will show some additional demos:

1) On Tuesday 13/Oct at 12:15PM UTC, we will show a demo of AMCOP orchestrating the Free5GC 5G core onto a Kubernetes edge cloud.

2) On Tuesday 13/Oct, at 3PM UTC, we will show a demo of AMCOP performing Day 1,2 configuration on an O-RAN-SC O1 interface simulator.

Additionally, on Thursday 15/Oct, at 3PM UTC, we will also give an introduction to ONAP for those who might be new to the project.

Please check out our demos and let us know what you think! If you would like to replicate any of these demos in your lab, try out AMCOP 1.0 for free.

‍

I am pleased to announce a new product—the Aarna.ml Multi Cluster Orchestration Platform (AMCOP) 1.0. A bit of background first: we've come to realize over the past several months that we'd be better off addressing a very specific use case as opposed to our prior strategy of going after the horizontal MANO (management and orchestration) market. That is exactly what we are doing with AMCOP. We are solving the cloud native, B2B, 5G network service + edge computing application orchestration, management, and automation problem. We support only the Kubernetes NFVI. And we focus on B2B applications e.g., Industry 4.0, healthcare, precision agriculture, and more.

By narrowing our focus, we are able to use just two ONAP projects—Edge Multi Cluster Orchestrator (EMCO) and the Controller Design Studio (CDS). This makes the solution very lightweight and easy-to-use. These two projects allow us to perform intent-based orchestration of 5G network services and composite edge computing applications and to manage their lifecycle. Policy-driven control loop automation, network slicing manager, Non-Real Time RIC (NRTRIC), Network Data Analytics Function (NWDAF)/ Management Data Analytics Function (MDAF), Self-Organizing Networks (SON), and more are on our roadmap and will come later this year and into early 2021.

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 at ONES next week:

• 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 installation on bare metal or cloud
• AMCOP orchestration of Altran 5GC on Red Hat OpenShift
• AMCOP orchestration of Free5GC on K8s
• AMCOP orchestration of vFW on K8s

Finally check out two new 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.

‍

Please engage with us at ONES next week. We have four ways for you to check out our 5G orchestration demos and to engage with us at the Linux Foundation Open Networking and Edge Summit next week.

‍

1. We are working on a cloud native 5G orchestration demo with a number of other companies. This demo will be shown during the Keynote on Monday. In this demo you can see our product based on Intel/ONAP EMCO and ONAP CDS orchestrate Altran 5GC onto Red Hat OpenShift. The 5GC also includes a UPF from Kaloom. The end-to-end testing is done using a gNB/UE emulator by Rebaca Technologies.
2. This same demo will also be shown during the expo at the "Onboarding 5G CNFs with ONAP: As Easy as 1, 2, 3 (ONAP, OPNFV, K8s)" virtual booth.
3. We are working on a Private LTE/5G over CBRS blueprint in the Akraino community. See the demo of our first milestone where we orchestrate Free5GC using our new product AMCOP based on Intel/ONAP EMCO and ONAP CDS.
4. We will be there at the "Ask the Expert" session on Monday to answer any questions about 5G Technology and its relationship to LF Networking or LF Edge.

See you next week! If you miss any demos or would like to follow up with us, please contact us.

Introduction

This blog describes onboarding of a TOSCA VNF with ONAP, an exercise that was conducted at the 2020 ETSI NFV & MEC Plugtests Event. This event was conducted online and the participants worked remotely.

Setup

The setup consisted of Aarna.ml ONAP Distribution (ANOD) 4.0 (based on the ONAP El Alto release). ONAP was hosted on bare metal servers and connected to WindRiver Openstack as the NFVI layer. Since the default components of ONAP had unresolved bugs in VFC related functionality, we upgraded a few of them to a higher version:

vfc-nslcm: nslcm:1.3.8

vfc-vnflcm: vnflcm:1.3.8

vfc-generic-vnfm-driver: vnfmgr:1.3.4

vnf-catalog:1.3.8

multicloud-windriver : 1.5.4

multicloud-framework: 1.5.1

‍

The details of all the component versions for ONAP are here.

‍

Next we upgraded the CLI to version 1.5.3. Then we followed the below steps.

1. We downloaded the VNF TOSCA CSAR package to be used. We used the following VNF:

https://git.onap.org/integration/tree/test/vcpe_tosca/local/csar

2. Downloaded the LCM script from below location

https://raw.githubusercontent.com/onap/cli/master/products/onap-dublin/features/integration/src/main/resources/script/vnf-tosca-lcm.py

3. Next we filled the Cloud details in “/opt/oclip/conf/vnf-tosca-lcm.json” file in anod-master:

   "cloud": {

       "identity-url": "http://172.22.38.240:5000/v3",

       "username": "aarnanetworks-etsi",

       "password": "aarnanetworks@etsiPlugtest20",

       "region": "RegionOne",

       "version": "titanium_cloud",

       "tenant": "aarnanetworks-etsi"

   },

4. Next we ran the “setup_cloud_and_subscription” section in vnf-tosca-lcm.py file. This sets up the cloud information in ONAP.

5. We then uploaded the VNF csar and NS csar to UUI and then created and onboarded the VNF using UUI.

6. UUI can be accessed using the following URL. Here the IP address is that of anod-master

https://192.168.122.246:30283/iui/usecaseui/#/home

This concludes the steps required to onboard a TOSCA based ETSI compliant VNF onto ONAP.

Creating xNFs (i.e. VNF, CNF, or PNF) is complex. Not only do xNF vendors have to meet functional requirements, but they also have to think about performance, stability, scalability, security, resilience, manageability, usability, cloud native principles, and more. To add to this complexity, xNFs need to interoperate with MANO software (e.g. ONAP; as a clarification ONAP does a lot more than what’s defined by ETSI MANO) and the NFV infrastructure such as OpenStack or Kubernetes. Thus far, the task of onboarding xNFs to MANO and NFVI software has been a fragmented activity repeated by every operator and oftentimes by vendors.

Clearly, there aren’t enough resources in the industry to do this N x N testing. The problem is further aggravated by CI/CD where products keep getting updated more frequently than before. What if there were onboarding specifications and an industry wide interop program? Fortunately, there is such a program! It’s called the OPNFV Verification Program (OVP) and it is available through the Linux Foundation. The program has different components, and the one that I am going to talk about is the VNF Verification Program. This program consists of static tests that check the VNF package and descriptor against the fairly detailed VNF requirements documented by the ONAP project followed by functional validation tests against an actual ONAP environment. VNFs that successfully pass these tests receive an OVP badge.

In may cases, we find that xNF vendors prefer to outsource ONAP related work. For this reason, we (Aarna) have helped several xNF vendors with ONAP onboarding and interoperability testing. We also help vendors pass the OVP test suite and obtain the VNF Verified badge. In fact, we recently worked with Affirmed Networks to ensure their MCC Platform passed OVP tests and successfully obtained the OVP badge. Affirmed, now part of Microsoft, is redefining the future of mobile networks, with over 100 production customers implementing their virtual EPC solutions, and now, with the recent introduction of UnityCloud, leading the industry in cloud native 5GC innovation. As only the second vendor to receive this OVP badge, Affirmed continues to demonstrate their support of open and standards based solutions, such as OPNFV and ONAP, to ensure that customers have a choice when planning for AnyG environment deployments.

‍

To simplify the experience even more, we at Aarna have introduced a new product — OVP-in-a-Box. With OVP-in-a-Box, the xNF vendor does not even need to install ONAP on-site. We deploy an instance of ONAP in the cloud and provide guidance to run through OVP tests. Of course, we can always deploy the ONAP instance on-prem and/or take over the entire interop effort in the form of a turnkey service.

Find out more about Affirmed Networks products on their website. Find out more about the Aarna.ml OVP-in-a-Box offering here. If you need more background on these topics, download our VNF Onboarding for ONAP whitepaper.

We (Aarna.ml) are deeply involved with the OPNFV 5G Cloud Native Network demo that showcases a subset of ONAP optimized for cloud-native workloads orchestrating Altran’s 5GC onto RedHat Open Shift. Feel free to read my prior blog on this topic and to view the webinar recording.

I’m thrilled to report that the demo was chosen as a Light Reading Leading Lights Awards 2020 finalist. We are in the “Most Innovative 5G Strategy”.

There are two ways to approach cloud-native. One is cloud-native-only-in-name. In this approach, you would keep doing everything as you used to and simply replace OpenStack APIs with Kubernetes APIs. Numerous multicloud solutions take this approach. The second approach is to be fully immersed in the Kubernetes and CNCF ecosystem. This means working with Helm, Operators, Custom Resources, Istio (or some other service mesh), Prometheus, FluentD, Jaeger, Argo, Knative, and more. It’s about fully embracing the entire CNCF/cloud-native mindset.

Our demo takes this second approach. And that’s why I’m so glad that Light Reading gave the demo the recognition it deserves. Another feature of this project is that it is open. This means anybody can join the project, can contribute, and can learn how to replicate the demo in their own environment. Join us! And if you have any questions about what subset of ONAP we are using to work this magic, contact us.

‍