This page contains work in progress! |
---|
Questions and comments are inserted in the text as needed, prefix them with "Question:" or "Comment:". Text below the line "----temporary text ----" is a placeholder for text that may or may not be used later on. |
Use Case Name
5G Network Deployment, Slicing, Optimization and Automation
Use Case Authors
Amdocs, AT&T, Cisco, Ciena, Ericsson, Intel, Viavi, VMware
History
Revision | Author | Comment |
8/10/2017 | AT&T (Vimal Begwani, Shekar Sundaramurthy) | Initial version |
8/17/2017 | Multiple | Multiple editorial changes adopted |
For discussion on 8/24/17 | Ciena: Raghu Ranganathan | Suggestions/edits/comments |
For discussion on 8/24/17 | Ericsson: John Quity, Peter Loborg, Oskar Malm | Suggestions/edits for goal/pre-/post-conditions for use cases |
For discussion on 8/31/17 | AT&T (Sarat Puthenpura), VMware (Ramki Krishnan) | Added section on Optimization Framework and Multi Cloud – applicable to all 5G use cases |
On 8/28/17 | Cisco (Vladimir Yanover) | Edits on slicing and SON |
On 8/28/17 | AT&T (Sarat Puthenpura, Ioannis Broustis), VMware (Ramki Krishnan) | Further edits on Optimization Framework and Multi-Cloud |
On 8/31/17 | Ericsson: John Quity, Peter Loborg, Oskar Malm | Further discussion/edits for goal/pre-/post-conditions for use cases |
9/13/17 | Ericsson: Oskar Malm | Editorial & other comments |
9/14/17 | Amdocs: Gavin SC | Added comments on MEC |
9/20/17 | AT&T: Shekar S. | Addressed Oskar M. comments |
10/5/17 | AT&T: Vimal B. et al | Added summary of key enhancements needed based on feedback from Paris meeting |
10/12/17 | AT&T: Shekar S. et al | Incorporated further comments from team review; also added references to gaps already identified as candidates for R2 work |
Motivation and Business Drivers:
There are three sub-cases in the proposed 5G use case for ONAP R2. Each use case identifies how it can leverage unique ONAP capabilities and identify potential gaps or challenges. Many service providers from ONAP community are planning 5G deployment in near future. Demonstrating ONAP capabilities in these areas will increase service providers’ confidence in ONAP and could identify potential areas of improvement in ONAP.
The ONAP teams have already identified the following items as “missing platform capabilities” – these items are particularly relevant to realizing the 5G use case as called out in each sub-case:
- Enhanced Platform Awareness (e.g. access to real-time VIM features)
- Enhance SDC (e.g. PNF onboarding)
- Enhance SO (e.g. PNF, nested services )
- Integrated design environment (e.g. complex service composition)
- PNF Modelling Capability (e.g. PNF modeling, connections)
- Service Aggregation Capability (e.g. complex service hierarchy)
- Service Chaining Capability (e.g. chaining across multiple clouds, service path)
- Service Modification Capability (e.g. modifying without downtime)
Here is a summary of key enhancements & areas with challenges for each of the 3 sub-cases
ONAP Support for 5G RAN Deployment:
Disaggregated 5G RAN consists of hybrid network elements (PNF and VNF) and will require a cloud infrastructure deployment at the edge. This sub-case will expand/enhance ONAP capabilities to support different lifecycle management aspects of PNF (including enhancements in SDK / certification, PNF onboarding, and SO, DCAE, A&AI support for PNF). Finally, ONAP’s multi-cloud layer’s scope needs to be expanded to support Edge Cloud (which could have a different flavor of hardware, different networking requirements and support).
REQUIREMENTS: Needs 1, 2, 3, 4, 5
ONAP Support for Network Slice Segments, Network Slices, Services riding on various network slices:
Many providers are interested in using ONAP to manage the general concept of Slicing (Extending the cloud notion of sharing network/compute/storage to sharing network functions and Services implemented across PNFs & VNFs). Supporting such a generic slicing concept could require ONAP enhancements in the areas of SDC/AAI modeling and service definition, lifecycle management of slices (whether done within the existing SO/controller context or via a new layer of control e.g. slice controller) since slices could have their own state, metrics and scaling procedures different and distinct from those of the underlying network functions (e.g. service/slice across multiple NFs from different providers).
REQUIREMENTS: Needs 2, 3, 4, 5, 6
Model/support complex services (related to 8)
Service Path features (correlation, visibility – related to 7)
ONAP Support for Network Optimization and Optimization Framework:
Many providers are interested in flexibly deploying network optimization functions from various vendors into the ONAP framework. We need such an ONAP Optimization Framework (OOF) to support two aspects. The first one is for the optimal placement of 5G virtual network functions. The second one is for performance optimization, where SON is a key functionality. Since optimization problems in general have a common structure (viz. maximizing/minimizing an objective subject to various constraints), a framework exploiting this commonality would render significant efficiency in creating optimization functions in these two areas. Also, when different optimization capabilities are deployed, there is a need for potential conflict resolution across these different schemes (both at design and run time). Hence the OOF should support policy-driven optimization capabilities that can be quickly developed and on-boarded. To support OOF, the data collection/processing in DCAE need to satisfy the needed latency requirements based on various use cases.
REQUIREMENTS: OOF enhancements (constraints framework)
Policy enhancements (conflict detection/rationalization)
DCAE enhancements (low-latency data distribution)
<Question / Comment: Karpura S> Should we clarify how OOF is related (or unrelated) to CLAMP ? Presumably, CLAMP is addressing the needs of some of the closed loop optimization use cases that require configuration management. Isn't this the case?
SUMMARY:
- For the first 2 sub-cases, the needs have either already been identified or the identified items could include additional, related requirements; the priorities of the identified items should be validated against the 5G use case needs
- The Optimization sub-case has additional enhancements that need to be specified further so that they can be considered for inclusion in R2
General Description
The purpose of this document is to present a high-level use case for the deployment and optimized management of a 5G network while using the slicing concept for management of shared resources using ONAP. While the intent of the use case is the management of the overall 5G network, the initial focus will be on the RAN. The use case describes a Service Provider (SP) need to deploy a disaggregated 5G Radio Access Network (3GPP 5G Option 2-2 configuration). Some of the disaggregated network functions are expected to be virtualized (VNF), running on a cloud infrastructure and while others will be PNF (e.g. appliance based peripherals).
The network elements in scope for such a disaggregated 5G RAN (in this release) are:
- Distributed Radio Element
- Distributed BBU
- Centralized BBU and nrt-L2 function (CU-UP)
- Centralized Radio Control Unit (CU-CP)
This disaggregation can include moving processing closer to the edge, and require deployment of Multi-access Edge Computing (MEC) components and applications in order to meet 5G performance goals.
ONAP should support the complete lifecycle management of this 5G Radio Access Network, using Service Design and Creation (SDC) for design and onboarding of the various models and artifacts for physical and virtual network functions, including creation of recipes/descriptors and policies for their initial deployment, and associated transport (front/mid/back-haul) connectivity. Further, to support the SP needs for lifecycle management of the shared resources, ONAP should support the data collection and analysis, policies and analytics to identify actionable conditions, and support automatic closed loop actions for the RAN deployment, optimization and slicing management.
The use case is divided into three sub cases that are described in the following sections:
- Disaggregated RAN Deployment
- RAN Slicing
- RAN Optimization
The description of the use cases will address at least 3 different ONAP related roles:
- VNF/PNF Provider: The supplier of the network/service function (and it’s underlying infrastructure) – e.g. VNF/PNF vendors; the VNF/PNF provider will supply the artifacts necessary for the on-boarding into ONAP (this includes both the VNF and PNF that are supplied)
- ONAP Service Designer: The user of ONAP design studio that is used to on-board the VNF/PNF and who defines, models the workflows, analytics, policies and extensions needed for management & automation (i.e. making the RAN operational)
- Service/Network Operator: The ONAP operations user (operator of the realized service managed by ONAP) that processes or consumes the various dashboards/reports/logs and is responsible for various management functions (change/configuration etc.); the Operations user either directly (via a portal) or indirectly (via system APIs) enables the initial deployment of resources and services that make the RAN operational
During the realization phase of the use case, there may be further decisions made on scoping the use case in terms of its realization across various ONAP Releases.
------------------------------------------------------------------temporary text---------------------------------------------------------------------
None yet.