...

Goal

A planned list of 5G Nodes nodes are on-boarded into ONAP, and ONAP configures the Nodes nodes to the level that they are ready to handle traffic. ONAP begins to actively monitor and manage the nodes.

Assumptions

• The 5G nodes consist of both PNFs (DU) and VNFs (CU). A single CU may consist of several VNFs.
• Scope is limited to one PLMN without slicing.
• A single vendor delivers RAN equipment and software.
• A single service provider:
• Owns or leases data center equipment, cell sites, physical transport, and any new equipment installed on these sites
• Owns and operates the resulting RAN
• Is the single user of the entire ONAP based management system
• Use case covers only initial deployment of nodes. Thus, change management such as software upgrade is out of scope.

Preconditions

To clarify the limits of this use case for this release of ONAP the following preconditions are assumed:

• Requirements on RAN coverage is well defined and documented (frequencies, power levels, coverage, and capacity)
• A planned realization of these requirements exists (planning of cell Based on requirements network planning has been performed including:
  • Cell sites, equipment
  an
  • and cell structure
  • Transport network and fronthaul infrastructure
  • Data center usage
  • Other infrastructure components that may be needed such as CA/RA server
• Needed new hardware has already been delivered and installed, both outside the data center (new PNFs and their cabling) and inside the data center
• Additional infrastructure components have been deployed and configured
• The Core Network with its VNFs and transport network is operational and known to ONAP (is managed by the same ONAP instance or is known and can be addressed and connected to according to 3GPP defined methods)
• The infrastructure is prepared for the RAN deployment; Initial network and hardware planning and procurement is completed, resulting in
  • any new hardware needed has already been delivered and installed, both outside the data center (new PNFs and their cabling) and inside the data center
  • descriptions of the new hardware and basic transport to the data center external hardware have been on-boarded
    Question: Shall this bullet be part of the UC (instead of beeing a pre-condition) so that we include the formulation of and on-boarding of such descriptions into the UC?
• Radio Configuration Data, software products and license information has been provided by the RAN vendor and is now accessible to the RAN Integrator
• A single RAN Vendor delivers RAN equipment and functionality
• A single Telecom operator…
• Owns or leases data center equipment, cell sites, physical transport, and any new equipment installed on these sites
• Owns and operates the resulting RAN
  (e.g., no slicing, RAN sharing or other cooperation requiring elaborate isolation between multiple parties)
Is the single user of the entire ONAP based management systemSoftware packages and licenses have been procured and provided by the RAN vendor

Postconditions

The 5G RAN is providing RAN service for the user equipment according to expectations:

• All planned services are on-line, providing FCAPS data through the relevant channels
• RAN NOC personnel have full access to the FCAPS data and ONAP automation framework
• Dashboard or other NOC tools configured to display relevant RAN data
• Calculation and monitoring of key performance indicators is activated, used to verify the capacity requirements
a
• A first automation use-case reacting on an incident or state change have been implemented

Steps

...

Step 1:

...

• Define model/attributes 5G VNF/PNF Resources
• Define the ONAP view of the service entities to be provided by VNF/PNF resources
• Design parameters needed for use by ONAP Optimization Framework (HAS) for placement of 5G VNF resources
• Define the policies (e.g. including placement constraints) associated with each radio network function and its management
• Design the configuration aspects for each of the emulated network elements (testing purposes) based on the services that need to be supported and sample Radio Configuration Data
• Testing of these concepts in an emulated environment

Step 2: Onboarding of RAN functionality and initial trial rollout (limited area):

• Design the configuration aspects for each of the network elements based on the services that need to be supported and the Radio Configuration Data and license information provided by the vendor
• Design parameterized Recipes/models for instantiating various disaggregated Radio Access Network elements and associated network connectivity (front haul and backhaul).
• Design recipes for Data Collection, Analytics, service level metrics, and associated corrective actions when defined levels are breached for each network RAN element and the RAN network
• Policy definition and Policy enforcement points (NF, Controllers, DCAE / SO, etc.) taking corrective actions when anomalous condition is detected
• Instantiate a selected few services and related VNFs and PNFs:
  • At least one service that will require new instantiation of both a PNF and a VNF
  • At least one service that re-uses and existing PNF or VNF
• Verify that service is provided and can be monitored through dash boards and NB App API using basic observability data and calculated KPIs.
• Verify that policy definitions and their corrective actions are active and has intended effect.

Step 3:  Full rollout of remaining parts of RAN:

• Re-using the descriptors and the recipes developed in step 1 and 2 to instantiate the remaining services.
• Verify that service is provided and can be monitored through dash boards and NB App API using basic observability data and calculated KPIs.

---------------------- Temporary Text ---------------------

The following is working material to be rewritten and incorporated in the text or removed.

Open issues

• What is a unit of a RAN service? For a 4G RAN the EUtranCell can be a suitable service, or for RAN sharing situations, even a prioritized portion of a cell and its capacity.
• How to model/describe a mapping between a generic service model for the RAN and a vendor specific implementation, allowing the ONAP user to operate seamlessly over the borders of a multi-vendor system?  

Old text: (to be part of the realization description?)

The ONAP execution environment must support the following flow:

...

Service design (design-time environment)

• Onboard SW packages and any other artefacts provided by the RAN vendor
• Onboard any planning data that is common across all nodes
• Design RAN-level templates, recipes and workflows covering common network elements, transport network, data collection and analytics, policies and corrective actions
• Design node-level templates, recipes and workflows covering network elements (PNFs and VNFs), transport network, placement or QoS constraints, data collection and analytics, policies and corrective actions

Step 2: Design verification (design-time/run-time)

• Verify templates and recipes from step 1, using dedicated test environment or limited trial following steps below. If necessary, make adjustments according to step 1.

Step 3: Deploy shared services (run-time environment)

• This step refers to deployment of any shared RAN services and functions defined by templates, recipes and workflows in step 1. Note that some of the functions below may be partially inactive until nodes are added in step 4.
  • On receiving request, SO and controllers will decompose the request, and allocate and connect the various resources.
  • DCAE will start fault, performance, and log data collection as described during design time.
  • DCAE will perform data analytics as configured in recipes, to monitor the environment and publish anomalous conditions.
  • Corrective/remedial action for network impairments and for violations of service levels as described by defined policies are initiated using the SO and/or controllers

Step 4: Add nodes (run-time environment)

• This step refers to deployment of services and functions defined by templates, recipes and workflows in step 1 for a new 5G node.
  • A sub-flow includes the onboarding process for related PNFs.
  • In this step node-specific data from planning is also inserted.
  • On receiving request, SO and controllers will decompose the request, and allocate and connect the various resources.
  • DCAE will start fault, performance, and log data collection as described during
  the Compute analytics, as necessary
  • design time.
• Track inventory/topology of slices and their states with AAI
• • DCAE will perform data analytics as configured in recipes, to monitor the environment and publish anomalous conditions.
  Trigger corrective
  • Corrective/remedial action for network impairments and for violations of service levels
  Closed loop actions
  • as described by defined policies are initiated using the SO and/or controllers
• This step is repeated for each added node. Bulk deployment should be possible to handle a larger number of nodes in an efficient way.

Step 5: Final verification (run-time including dashboard)

• Verify that service is provided and can be monitored through dashboards and northbound APIs using basic observability data and calculated KPIs.
• Verify that policy definitions and their corrective actions are active and has intended effect.