• Use case goals

  • Showcase ONAP features capabilities

A use case should demonstrate how NFV orchestration and lifecycle management can be performed using ONAP

• • Provide a common set of test cases for ONAP releases

The release test cases should be derived from the use cases

• • Serve as a reference for other use cases that may be deployed using ONAP

Operators and vendors building their own use cases may refer to the ONAP use cases to get an idea of the proper usage of ONAP features

• Non goals - What use cases are not

• A strict definition of what is in or out of scope for an ONAP release

E.g., it is perfectly OK to have functionality in ONAP that is not necessarily being consumed by any use case

• A strict definition of what functionality is “supported” or “unsupported” by ONAP

It should be possible to use a feature in a way that is not used by any of the use cases.

It should be possible to deploy a new type of service using a specific release of ONAP even if the service is not one of the ONAP use cases for that release

• Selection criteria

Examining a new use case should consider the following criteria

• Does it showcase new ONAP functionality that other use cases did not?

If a proposed use case deals with a new type of communications service, but the set of features used by it is fully overlapping with the existing use cases, then there is no justification for inclusion as an ONAP use case.

• Are all the relevant VNFs available as open source or trial license?

This will ensure any interested community member may deploy the use case in their lab

• What will be the cost (in terms of complexity, test duration, etc.) of adding the use case to the set of release tests?

Will adding the new use case require adding system tests to ONAP that might have a negative impact on development pace?

• What will be the impact of the use case on core developers?

Will the new use case require diversion of a significant portion of the ONAP community developers to work on it?