Skip to end of metadata
Go to start of metadata
  • Use case goals

    • Showcase ONAP features capabilities

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

    • Provide functional requirements to ONAP projects

 Project functional requirements for each release will be derived from the approved use cases

    • 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 end-to-end test suite

To validate end to end ONAP platform, it is mandatory to launch a full test suite based on a set of use-case

    • 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

    • Address emerging industry needs

Keep ONAP at the forefront of innovation by addressing emerging domains

(E.g. use cases related to 5G as the 3GPP specifications become available)

  • 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/requirement coming from the use case should consider the following criteria

    • Is it aligned with the release goals?
        it should be examined if new proposal is aligned with release goals. For example, if release goals is platform hardening (and not new functional extensions), such requirements should be selected that they contribute to this goal.

    • 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?