/
EXTAPI R8 - Release Planning

EXTAPI R8 - Release Planning

Jan 25, 2021




Overview

Project Name

Enter the name of the project

Project Name

Enter the name of the project

Target Release Name

Honolulu Release

Project Lifecycle State

Incubation.( Refer to ONAP Charter, section 3.3 Project Lifecycle for further information)

Participating Company 

AT&T, CenturyLink, China Mobile, Huawei, Orange, Verizon, Amdocs, Ciena, Wipro, HCL, Tech Mahindra, Netcracker, MEF, TMF

Scope

What is this release trying to address

Use Cases

The existing use cases should still be supported ( BBS, CCVPN ) in the Honolulu Release as the APIs are built to be non use case specific.

5G E2E Network Slicing Use 

The stretch goal impact is for the specification and design work to support Performance Management API, via an enhanced TMF 628 worked with MEF  - Dependant on release of appropriate swagger from the SDOs

Platform Maturity

 Platform Maturity (i.e., S3P items)  Honolulu Release Platform Maturity 

Minimum Viable Product

  • Documentation of User Stories; Use Cases and Interactions (e.g., swagger ); Data Models (e.g., JSON); Interface Profiles and Functional Definition; 

  • ONAP Component Mapping and Functional Analysis; 

  • Code contribution for External API Framework functionality.

Functionalities

List the functionalities that this release is committing to deliver by providing a link to JIRA Epics and Stories. In the JIRA Priority field, specify the priority (either High, Medium, Low). The priority will be used in case de-scoping is required. Don't assign High priority to all functionalities.

Epics

key summary type created updated due assignee reporter priority status resolution
Refresh

Stories

key summary type created updated due assignee reporter priority status resolution
Refresh

Longer term Roadmap

Indicate at a high level the longer term roadmap. This is to put things into the big perspective.

Provide a clear and unambiguous ONAP service abstraction so that the BSS/OSS can exchange service requirements and service capabilities in a common and consistent fashion.
Provide a way to rapidly integrate new Services and Service Components into ONAP so that they can quickly introduce capabilities for their customers and within their infrastructure.
Enable management the entire lifecycle of Services within ONAP in a common way so that they can ensure orchestration, manageability and control of each Service in an easily integrateable and low cost way.
Model Driven approach: a cohesive way to have a shared view of information across ONAP external interfaces that can be used for or be input into a model driven process whereby the cost of delivering platform functionality is drastically reduced and the time to delivery is dramatically decreased.

It is envisioned that from a Service Provider to BSS/OSS interaction context (i.e. MEF Legato), the ONAP External API will support the following types of interacts:

  • BSS/OSS retrieves Service Models

  • BSS/OSS requests service feasibility determination.

  • BSS/OSS requests reservations of capabilities related to a potential Service.

  • BSS/OSS requests activation of Service.

  • BSS/OSS receives Service activation tracking status updates.

  • BSS/OSS retrieves Service Inventory

  • BSS/OSS receives usage events due to a Customer initiating dynamic activity on their Service (e.g., increase in bandwidth).

  • BSS/OSS receives a summary of Service quality and usage information.

  • BSS/OSS receives a summary of Service Performance

  • BSS/OSS receives Service state and fault event information

  • BSS/OSS receives Service Activation Testing results.

  • BSS/OSS receive capability information about the Service layer.

  • BSS/OSS manages Licenses

  • BSS/OSS receives License Usage information

It is envisioned that from a Service Provider to Partner Provider interaction context (i.e. MEF Interlude), the ONAP External API will support the following types of interacts:

  • Service Provider controls aspects of the Service within the Partner domain (on behalf of the Customer) by requesting changes to dynamic parameters as permitted by service policies.

  • Service Provider queries state of the Service.

  • Service Provider requests change to administrative state or permitted attributes of a Service.

  • Service Provider request creation of connectivity between two Service Interfaces as permitted by established business arrangement.

  • Service Provider request instantiation of functional service components as permitted by established business arrangement.

  • Service Provider queries the Partner for detailed information related to Services provided by the Partner to the Service Provider.

  • Service Provider receives Service specific event notifications (e.g., Service Problem Alerts) from the Partner.

  • Service Provider receives Service specific performance information from the Partner.

  • Service Provider request Service related test initiation and receive test results from the Partner.