ONAP covers a wide range of use cases for Communication Service Providers (CSP) and the open source networking industry. See the current list of verified use cases and functional requirements. Upon reaching a certain level of maturity, use cases become ONAP Blueprints.
Honolulu Use Cases & Requirements
|
Cloud Native |
Modular Approach to Cloud Native ONAP |
|
5G SON Use Case |
Optimization and SON functions for 5G RAN which provide for self-optimization, self-healing and self- configuration |
|
End to End Network Slicing |
5G Network Slicing defines slices to be used in 5G RAN systems. Network Slicing is a long-lead multi- release development. |
|
ONAP/3GPP & O-RAN Alignment: Standard Defined VES |
This requirement enhances the A1 interface capabilities provided in Rel 6 as part |
|
Smart Operator Intent Translation in UUI based on IBN – R8 5G Slicing Support |
A lightweight and high-cohesion Nature Language Processing (NLP) function is proposed to add in the UUI project |
|
Support for Vertical Industry |
Intent framework is a system that helps to implement and operate networks that can improve network availability and agility, End to End Network Slicing |
ONAP Blueprints
5G Blueprint
The 5G blueprint is a multi-release effort, with five key initiatives around end-to-end service orchestration, network slicing, PNF/VNF lifecycle management , PNF integration, and network optimization. The combination of eMBB that promises peak data rates of 20 Mbps, uRLLC that guarantees sub-millisecond response times, MMTC that can support 0.92 devices per sq. ft., and network slicing brings with it some unique requirements. First ONAP needs to manage the lifecycle of a network slice from initial creation/activation all the way to deactivation/termination. Next, ONAP needs to optimize the network around real time and bulk analytics, place VNFs on the correct edge cloud, scale and heal services, and provide edge automation. ONAP also provides self organizing network (SON) services such as physical cell ID allocation for new RAN sites. These requirements have led to the five above-listed initiatives and have been developed in close cooperation with other standards and open source organizations such as 3GPP, TM Forum, ETSI, and O-RAN Software Community. See the 5G E2E Network Slicing Technical Overview Document.
Virtual CPE (vCPE)
Currently, services offered to a subscriber are restricted to what is designed into the broadband residential gateway. In the blueprint, the customer has a slimmed down physical CPE (pCPE) attached to a traditional broadband network such as DSL, DOCSIS, or PON (Figure 5). A tunnel is established to a data center hosting various VNFs providing a much larger set of services to the subscriber at a significantly lower cost to the operator. In this blueprint, ONAP supports complex orchestration and management of open source VNFs and both virtual and underlay connectivity.
Broadband Service (BBS)
This blueprint provides multi-gigabit residential internet connectivity services based on PON (Passive Optical Network) access technology. A key element of this blueprint is to show automatic re-registration of an ONT (Optical Network Terminal) once the subscriber moves (nomadic ONT) as well as service subscription plan changes. This blueprint uses ONAP for the design, deployment, lifecycle management, and service assurance of broadband services. It further shows how ONAP can orchestrate services across different locations (e.g. Central Office, Core) and technology domains (e.g. Access, Edge).
Voice over LTE (VoLTE) Blueprint
This blueprint uses ONAP to orchestrate a Voice over LTE service. The VoLTE blueprint incorporates commercial VNFs to create and manage the underlying vEPC and vIMS services by interworking with vendor-specific components, including VNFMs, EMSs, VIMs and SDN controllers, across Edge Data Centers and a Core Data Center. ONAP supports the VoLTE use case with several key components: SO, VF-C, SDN-C, and Multi-VIM/ Cloud. In this blueprint, SO is responsible for VoLTE end-to-end service orchestration working in collaboration with VF-C and SDN-C. SDN-C establishes network connectivity, then the VF-C component completes the Network Services and VNF lifecycle management (including service initiation, termination and manual scaling) and FCAPS (fault, configuration, accounting, performance, security) management. This blueprint also shows advanced functionality such as scaling and change management.
Cross Domain and Cross Layer VPN (CCVPN) Blueprint
The CCVPN (Cross Domain and Cross Layer VPN) blueprint is a combination of SOTN (Super high-speed Optical Transport Network) and ONAP, which takes advantage of the orchestration ability of ONAP, to realize a unified management and scheduling of resources and services. It achieves cross-domain orchestration and ONAP peering across service providers. In this blueprint, SO is responsible for CCVPN end-to-end service orchestration working in collaboration with VF-C and SDN-C. SDN-C establishes network connectivity, then the VF-C component completes the Network Services and VNF lifecycle management. ONAP peering across CSPs uses an east-west API which is being aligned with the MEF Interlude API. The key innovations in this use case are physical network discovery and modeling, cross-domain orchestration across multiple physical networks, cross operator end-to-end service provisioning, close-loop reroute for cross-domain service, dynamic changes (branch sites, VNFs) and intelligent service optimization (including AI/ML). The Frankfurt release adds support for end-to-end E-LINE services over optical transport network (OTN) network-to-network interface (NNI).
Multi-Domain Optical Network Service (MDONS) Blueprint
While CCVPN addresses the automation of networking layers 2 and 3, it does not address layers 0 and 1. Automating these layers is equally important because providing an end-to-end service to their customers often requires a manual and complex negotiation between CSPs that includes both the business arrangement and the actual service design and activation. CSPs may also be structured such that they operate multiple networks independently and require similar transactions among their own networks and business units in order to provide an end-to-end service. The MDONS blueprint created by AT&T, Orange, and Fujitsu solves the above problem. MDONS and CCVPN used together can solve the OTN automation problem in a comprehensive manner.