The LFN DDF held from June 11-14 in Stockholm was a very pleasant experience! The weather was wonderful, Stockholm is beautiful, and it was bright & sunny all the time (I literally mean all the time, I didn't see darkness for a week). We had 4 presentations on the following ONAP related topics:

• FlexRAN onboarding to ONAP: Virtual Radio Area Network (vRAN) is a critical piece for upcoming 5G networks. In this joint presentation/demo with Intel, we showed how to build the FlexRAN (an open source vRAN approximation VNF from Intel), onboard it onto ONAP, and then deploy it onto OpenStack. Once the service was deployed, the FlexRAN service performs basic operations in a simulated environment.
• ONAP OOM GUI based installer: Remember how during the early days OpenStack installation was super difficult and a number of vendors made it easier through a GUI based installer? We are doing the same with ONAP. We showed a demo of our GUI based installer, built on top of OOM, that can install ONAP with a single click using model driven inputs.
• 4th ETSI NFV Plugtests Summary & Learnings for ONAP:  Here we provided a brief description of the ONAP interop activities at the 4th ETSI NFV Plugtests held from June 3-7, 2019. We also covered our learnings. See related blog where we talk about our Plugtests experience.
• ONAP COP Exam Review: In this session, we reviewed the status of the upcoming Certified ONAP Professional exam, discussed the challenges faced, and invited community members to help with specific questions/API documentation and to be alpha/beta testers

Presentations and recorded demos are available here. Wanting to try out ONAP? Consider our Aarna.ml ONAP Distribution that can be deployed on GCP in under a half day.

ETSI conducts NFV Plugtests where MANO, VNF, NFVI/VIM (i.e. Cloud), and other NFV vendors come together to perform interoperability testing. We were fortunate enough to participate in the 4th ETSI Plugtests as a MANO vendor with the goal of testing our Aarna.ml ONAP Distribution (ANOD) with VNF and NFVI/VIM (OpenStack) vendors. Rajendra Mishra and I (Sandeep Sharma) attended the event in person.

ETSI was a wonderful host. The participants were welcomed with an ETSI T-shirt and other goodies. A dinner was hosted by ETSI for all the participants at a beach side restaurant in Antibes, where we got to know some of the other participants better. And of course there were drinks and some great tasting food!

Before going to the event, we were involved in the pre-testing phase. The weekly calls that were organised by ETSI for the preparation of the event were really helpful. As a first time participant, we had a smooth preparation process. Getting involved in pre-testing with a cloud vendor and a VNF vendor gave us a great head start. The private HIVE network used for the Plugtests, played a key role in the pre-testing phase. Additionally, before the start of the event, every vendor was asked to fill up a form specifying the test cases they were going to execute during the event. This data collected before hand saved a lot of time which would otherwise have been wasted in planning test sessions during the event.

At the event, test sessions were organized such that each of the vendors from MANO, Cloud, and VNF categories could participate in single-vendor Network Service (NS) and Multi-vendor NS test execution. We participated in single-vendor NS testing with 5 VNF vendors and 2 VIM (OpenStack) providers. We also were able to create a multi-vendor NS which involved 2 VNF vendors and 1 VIM vendor. It was a great learning experience where we worked with multiple vendors and understood their product/service. We can leverage from these learnings and add value to the ONAP MANO solution that we provide. Some things worked very well for us and, of course, there were test cases which we could not execute successfully.  The failed test cases taught us the shortcomings of our solution that we already have started to address.

In general, this was a very positive experience. Our initial trepidation as a first time attendee was without merit. We would highly recommend other NFV vendors to attend. The one learning we can share is to invest in pre-testing. Having spent time in this activity made our experience at the Plugtests that much smoother. The other observation is that building working VNF Descriptors on the fly is challenging. Having the full week for a couple of trial-and-error rounds to reach a working model was very helpful.

First let me explain the first two terms and then describe the connection to ONAP.

RIFEE

RIFEE is my term that means Rakuten's Infrastructure for Everyone Else.

There's tremendous buzz about how an IT company is aggressively jumping into mobile connectivity by building a cloud-native 5G-ready network, and in doing so outflanking traditional telcos on technology. I believe many mobile operators are asking themselves, privately I'm sure, how they can have an infrastructure just like Rakuten's, and how they can build a solution with the same speed.

In a TelecomTV interview, Tareq Amin, CTO Rakuten Mobile Network (along with Manish Singh from Tech Mahindra), talks about how they are working to achieve such an aggressive goal. It's worth a listen.

I have two suggestions on RIFEE. One is non-technical by adopting ideas from the Loonshots book. The other is technical by taking advantage of the Linux Foundation Open Network Automation Platform (ONAP) project.

Loonshots

Loonshots is a book by Safi Bahcall where he explores "how to nurture the crazy ideas that win wars, cure diseases, and transform industries." This is an interesting book that states that structure rather than culture is the reason innovation happens or not. An example used in the book is Nokia, a company that innovated from selling rubber boots and toilet paper in the '70s to selling half the smartphones on the planet by early 2000s. But that same company killed an internal iPhone like project along with an app store in 2004. What happened internally to create such a massive reversal? Did the culture suddenly change? Of course not. And the author argues that it was the company structure that changed and in doing so it stifled innovation.

Loonshots provides a very comforting message on the non-technical aspect of RIFEE. As a mobile operator, you should focus on structure, where it may be as straighforward as creating a new cloud-native software group in your company, to get the ball rolling. This group would have complete autonomy in terms of picking technologies, processes, and choosing vendors. This concept is obviously much simpler than trying to change your company culture.

ONAP

ONAP is a network automation project under the Linux Foundation umbrella with terrific momentum. It provides classic SDN/NFV management and orchestration, but also service assurance and automation.

As a mobile operator, you can use the ONAP 5G use-case blueprint along with say OPNFV VCO 3.0 to solve the technical aspect of RIFEE. (NOTE: The 5G blueprint and VCO 3.0 are not fully ready yet, but should be by end of 2019.)

By combining Loonshots and ONAP, you can get a 5G network by end of 2019. In fact, with this approach, you can not only match RIFEE, but beat in terms of technical superiority.

We moved to our new office in India’s Silicon Valley, Bangalore!

We are now  located in the most happening neighborhood in Bangalore  — Koramangala.

Our new coordinates are:

Aarna.ml LLP

Davanam Golden Square Prime,

4th Floor, Davanam Sarovar Portico Hotel,

Opposite Madiwala Police Station,

Koramangala, Bangalore 560 068

Tel: +91 49116666

We have a band of highly talented and super-experienced engineers in our Bangalore development center working on the Linux Foundation ONAP project!

The 4th ETSI Plugtests event is round the corner, and in this blog, I will explain how NFVI/VIM vendors, VNF vendors and hardware vendors can work with us to test ANOD (Aarna.ml ONAP Distribution) with their respective offerings at the Plugtests. This is the first time ONAP will be at a Plugtests, and we are very excited to gain end-to-end ONAP testing experience.

‍

‍

‍

NFVI/VIM

First, let us look at NFVI/VIM vendors. The Aarna.ml ONAP Distribution can be connected to any other Openstack/StarlingX deployment that complies to Ocata or later APIs. At the Plugtests, we would like to verify the interoperability with Openstack deployments from various NFVI/VIM vendors.

VNF Vendors

Next, let us look at VNF vendors. ANOD provides two orchestration paths (SO NFVO/gVNFM for Heat VNF descriptors and SO→VF-C NFVO for TOSCA VNF descriptors using an external sVNFM).

There are broadly 3 areas that need attention from VNF vendors’ point of view for onboarding their VNF’s onto ONAP.

1. If the VNF/Network Services are going to be orchestrated using SO in ONAP, they need to create HEAT descriptors for their VNFs. If these descriptors already exist ( i.e. if these VNFs are already running as Virtual Machines under Openstack), these descriptors can be reused, with some changes needed as part of ONAP onboarding.  
2. If the VNF/Network Services are going to be orchestrated using VFC in ONAP, they need TOSCA descriptors  for the VNFs. Additionally, there needs to be a ETSI SOL-003 compliant sVNFM as well.  
3. Lastly, the VNF vendors can use ONAP tools to test their VNF descriptors for compliance, using VVP (for HEAT based templates) or VNFSDK (for TOSCA based templates).

Once the above steps are completed, we can work together with the VNF vendor to execute the official Plugtests test plan. The test plan can include an NFVI/VIM vendor or we can use the OPNFV scenario included with ANOD. Time permitting, we can also perform some closed-loop automation testing by creating a collector, analytics pipeline and a Policy.

Hardware Vendors

The Plugtests can also be used to ensure that ONAP functionality is validated on the target hardware platform. This will involve deploying ANOD on the target servers, and using ONAP and Openstack (either the OPNFV scenario included with ANOD or from any other NFVI/VIM vendor) to test end to end functionality of deploying VNFs (open source or from one of the above vendors). This activity could bring  all 4 players together - NFVI/VIM, VNF vendors and hardware vendors along with the Aarna.ml ONAP Distribution to execute the official Plugtests test plan.

A couple of  weeks ago, the Linux Foundation announced the expansion of the OVP program to include ONAP VNF compliance testing. Vendors will be able to test their VNFs against ONAP using a self-service model, submit their results, and get a compliance badge. These VNFs will also get listed on the OVP site.

I think this is a very positive development. The program should contribute to the growth of the ONAP ecosystem that is critical for ONAP's long term success. There is plenty of information about the program and the benefits to Communication Service Providers (CSPs) and VNF vendors in the above links. So I'm not going to repeat this.

Instead I am going to address a key question: As a VNF vendor, should you engage now or wait & watch? That of course, depends on a cost-benefit analysis.

Cost-benefit of passing OVP testing in 2019

Since the tests are very light right now, the cost of passing OVP is simply to create an ONAP compliant VNF descriptor (VNFD). The program has only static tests and there are no functional, lifecycle management, monitoring or performance tests at this time.

‍

In our view, the effort required for simple VNFs is:

• If a Heat/TOSCA VNFD already exists, the effort is in the 1-2 man-week range  
• If a VNFD does not exist, the effort is in the 2-4 man-week range

‍

At a $250K burdened salary, we are talking about a roughly $10K investment.

‍

What's the benefit? That's not as easy to quantify, but qualitatively:

• Your VNF will be listed on the LFN OVP site as an ONAP compliant VNF. Along with this comes the visibility and PR/marketing benefit.  
• Ability to say "yes" to RFPs that require ONAP compliance and entering a shortlist of VNFs could put you ahead of your competitors.  
• Ability to participate in open community-based ONAP blueprints or create private demos; these demos will not require any licensed MANO software.  
• Benefit of appeasing CSPs that have committed to OVP even if immediate RFPs don't require ONAP compliance.

‍

Is the benefit much greater than $10K? We think so, but ultimately you have to be the judge of that.

‍

Cost-benefit of waiting on OVP until 2020 or later

‍

The benefit of waiting on OVP until 2020 or later is obviously the ~$10K savings in 2019. What is the cost? The cost again cannot be quantified, but qualitatively:

• Inability to participate in ONAP based RFPs.  
• Perceived lack of open source community thought leadership.  
• Facing a higher bar in 2020; OVP tests will be more complex, and you will have to catch up with competitors that already have a badge from earlier, easier testing.

‍

In summary, as a VNF vendor, you need to determine whether passing OVP in 2019 makes sense or not. We feel it should be an easy "Yes" based on the cost-benefit analysis above. If you agree but are not sure where to start, read our "VNF Onboarding for ONAP Whitepaper".

‍

We can also help with our Aarna.ml ONAP Distribution (ANOD) along with ONAP training and ONAP deployment/VNF onboarding services. Feel free to contact us on any of these ONAP related topics.