Earlier this month, Iain Morris from Light Reading reported that Orange is starting their '5G Plus Automation' RFP effort this year and the message to vendors is clear, "If you can't support ONAP interfaces, don't bother responding."
As an ONAP products & services, company, this news could not have been better. ONAP is about 1.5 years old and the commercial activity around the project has had a slow start. However, this announcement should change that. Once an operator adopts ONAP, vendors will have no option but to ensure interoperability. As more vendors support ONAP, more operators will adopt, thus kicking off the proverbial virtuous cycle.
But what does supporting ONAP interfaces mean? There are three broad categories of interfaces:
- Northbound API: that interface to OSS/BSS applications, E-Services (e.g. self-service web/mobile applications for end-users), big data applications
- Southbound interfaces: to OpenStack other SDN controllers
- Onboarding interfaces: for VNFs, PNFs, analytic microservices/applications, policies etc. I'm speculating here, but I imagine MEC application onboarding specs could come soon.
While all interfaces are important, the most critical one at this time is VNF/PNF (aka xNF) onboarding due to the sheer magnitude of xNFs out there. The ONAP community provides very detailed guidelines/documentation on how to write and package an xNF for ONAP consumption. The main requirements are:
- Cloud optimized/native VNF (the specification covers topics such as design, resiliency, security, modularity and DevOps) image
- xNF descriptor (OpenStack Heat or TOSCA)
- xNF lifecycle management support (with or without a sVNFM)
- xNF configuration template (e.g. YANG model)
- xNF monitoring (e.g. via VES or Google Protocol Buffers; with or without an EMS)
- xNF CI tests
- xNF license metadata
- xNF documentation
- Additional artifacts e.g. error-code XML file
As you can see, while VNF vendors might be able to get away with a quick demo with just item number 2, a full ONAP interop is a LOT more involved. Furthermore, even within a category e.g. monitoring, a vendor can support just 1 event for a demo, but will have to support the full set of events for production use.
The above article is just the start. More and more operators will require ONAP compatibility as 5G RFPs start to roll out. As a VNF vendor, I think your two choices are: A) Get a head-start and use ONAP compatibility as a competitive advantage, or B) Wait for the RFP and scramble. Not supporting ONAP at all, I don't think is a realistic option.
In either scenario, Aarna.ml is ready to help. If you are new to ONAP, check out our free eBook. Or request one of our popular ONAP trainings. When you are ready to play with ONAP, request our ONAP deployment or ONAP VNF onboarding professional services.