The next release of ONAP software will focus on making the overall platform more mature and developing functional requirements that can support multiple end-to-end use cases, says one individual involved in developing Beijing, due out next spring.

Alla Goldner, director of technology, strategy and standardization for Amdocs Ltd. (NYSE: DOX), was a presenter at last week's ONAP Beijing Release Developer Forum, held in Santa Clara, and responsible for reviewing the use cases to be included in Beijing, as use case chair. She says in an interview that this second software release will take a different approach from the first, Amsterdam, which spelled out the Open Network Automation Platform (ONAP) platform's use for two specific end-to-end use cases.

For that first release, it was critical to merge the code bases of the two founding groups of ONAP -- Open ECOMP and Open Orchestration -- Goldner says, and to show the resulting platform could be used practically to support in-demand use cases.

"We had six months to do that, and we were successful," she comments. "But the second thing is not to be concentrated on end-to-end use cases but on an enhanced and enriched platform. This is something I faced as use case chair; we received the requests to concentrate now on introducing functional requirements extracted from the use cases but done in such a way that they can be a basis for several potential use cases."

Goldner believes this approach will hold true not only for Beijing but for future releases as well, with functional requirements extracted from the specific use cases, and used instead in combination to support future applications.

That approach would mollify critics who say ONAP's Amsterdam release is limited in appeal because it addressed two specific use cases. ONAP backers previously said such criticism was unfounded since ONAP is intended to be a platform, providing a network operating system in modules that can be used in a wide variety of ways.

Want to know more about NFV and Open Source strategies? Check out our dedicated NFV content channel here on Light Reading.

Goldner says the move to focus on functional requirements is being driven by the service provider members of ONAP, which include AT&T, BCE, Orange, Vodafone and China Mobile, among others.

She says there are currently 13 functional requirements "on the table" and that her committee is "deeply engaged in final proposals for specific functional requirements."

"We will see if we get all of them into Beijing or not," Goldner says. "That will also depend on the amount of network hardening that we can get on the table in January -- it will be up to the project leaders to decide how much they are taking into the project. That will happen in January."

Amdocs remains heavily engaged in ONAP -- Goldner says 11 Amdocs team members attended last week's developer forum -- but she is also quick to say ONAP's contribution base is broadening.

According to the Linux Foundation , more than 260 people attended the ONAP Beijing Release Developer Forum, up from 160 who attended a previous developer event in Paris. Among the presentations at the event were deeper dives into the implementations of the two previous use cases, residential virtual CPE and voice-over-LTE (VoLTE). Some of the presentations can be viewed here.

Related posts:

— Carol Wilson, Editor-at-Large, Light Reading