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 SCAdded 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:


  1. Enhanced Platform Awareness  (e.g. access to real-time VIM features)
  2. Enhance SDC (e.g. PNF onboarding)
  3. Enhance SO (e.g. PNF, nested services )
  4. Integrated design environment (e.g. complex service composition)
  5. PNF Modelling Capability (e.g. PNF modeling, connections)
  6. Service Aggregation Capability (e.g. complex service hierarchy)
  7. Service Chaining Capability (e.g. chaining across multiple clouds, service path)
  8. 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.


  • No labels