Versions Compared

Old Version 1

changes.mady.by.user Shekar Sundaramurthy

Saved on

compared with

New Version Current

changes.mady.by.user N.K. Shankaranarayanan

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


The OOF and PCI use case started in Casablanca release. Please see the following links:

Base page for OOF-PCI use case: 5G - OOF (ONAP Optimization Framework) and PCI (Physical Cell ID) Optimization

Use Case template for Dublin release with Hi-level requirements: OOF-PCI Use Case - Dublin Release - ONAP based SON for PCI and ANR 

Use Case page for Rel 6 (Frankfurt) and Rel 5 (El Alto): OOF (SON) in R5 El Alto, OOF (SON) in R6 Frankfurt

BUSINESS DRIVER

This section describes Business Drivers for this Use Case.

Executive Summary

SON (Self-Organizing Networks) functionality is an essential part of existing 4G mobility networks, and will be even more critical for 5G. SON enables automation to improve network performance and efficiency, improve user experience, and reduce operational expenses and complexity. The objective of the OOF-SON (new name for OOF-PCI) use case is to develop an ONAP-based SON platform using the ONAP Optimization Framework (OOF). We have taken a phased approach since SON is complex, and SON for 5G is still evolving. We started with the Physical Cell Identity (PCI) optimization SON use case in Casablanca, then added some centralized Automated Neighbor Relations (ANR) aspects in Dublin. For Frankfurt, we will address gaps such as PCI assignment during new cell addition, alignment with RAN inventory, etc., In addition, we aim to have enhancements such as: additional optimization functionality (e.g. include the use of AI/ML), use of control loop co-ordination in Policy, and alignment with industry trends for open interfaces and open models for the RAN interactions.

Business Impact

SON is an essential feature in mobility networks, and relevant to every operator. Any ONAP-based network deployment for 5G will benefit from an ONAP-based SON solution, which provides a disaggregation of SON functions into modules aligned with the ONAP architecture. Operators and vendors will both benefit from the ability of vendors to bring best-in-class solutions to each module, while leveraging the benefits of a community-supported open platform. This will enable faster development of innovative solutions. The approach taken could very well be evolved to address SON use cases whose scope extends beyond just the RAN.

Business Markets

SON for 5G is relevant to all 5G operators and markets.

Funding/Financial Impacts

SON functions reduce Opex since the automated self-organizing functions are an efficient approach to continuously optimize network configurations to improve performance and respond to network conditions.

Organization Mgmt, Sales Strategies

There are no additional organizational management or sales strategies for this beyond whatever is required for ONAP deployment to support 5G.

Summary of Dublin Release plan:

  • Onboard PCI Handler MS to DCAE, and include in SDC Catalog
  • SDN-R use cases moved from Casablanca to Dublin
    • SDNC-430: Modify RAN informational model and yang model for RAN
    • SDNC-431: Implement config DB and REST API (SDN-R / OOF interface)
    • SDNC-432: Interfacing SDN-R with Policy: Receive DMaaP message in CL format from Policy (Modify Config message using existing LCM API), send netconf message changing PCI value to cellID as specified, update config DB, and publish change on DMaaP (DMaaP client is available and can be called)
    • SDNC-432: Receive netconf notification from RAN, update configDB, and publish change on DMaaP
  • Include FM/PM input for SON:
    • Enhance PCI Handler MS to receive FM/PM data from DMaaP
    • Send FM/PM data from RAN Simulator to DCAE Collector (e.g. PCI confusion alarm)
    • Implement KPI Database for stored data to be available for SON
  • Include flow to request PCI assignment for new cell (optional stretch goal)
    • Enhance PCI Handler MS to receive request for PCI allocation for new cell
    • Enhance ConfigDB to support active, activation-pending, and non-active cells
    • Orchestration for new cell addition is out of scope
  • Common RAN Information Model
    • Build on Casablanca RAN Information Model, and target consensus among vendors for complete common RAN information model
  • SDN-C/SDN-R Controller enhancements (may be separate use case for 5G Configuration Management)
    • Implement both Configuration Database and Operational Database as per ODL industry practice, leveraging Casablanca POC work on ConfigDB database
    • Configuration Database – values needed to perform / initiate configuration
    • Operational Database – dynamically changing network parameters relevant to ONAP and SDN-C/SDN-R
    • Support history of config state as needed for Change Management
    • Support both reactive and predictive network change actions
  • Inventory & Configuration Management synchronization
    • Develop models and relationship between A&AI Database and SDN-C Configuration Database and Operational Database
    • A&AI is primary reference for inventory and id of VNF, PNF, elements
  • Policy Enhancements
    • Enhance the Policy functionality for Control Loop Coordination (CLC) – build on basic functionality in Casablanca
    • POC to implement two Control Loops (one could be PCI-SON) and demonstrate coordination using CLC
  • OOF Enhancement
    • Add optimization objectives for PCI Optimization
    • Add another optimization for ANR (Automated Neighbor Relations) SON functionality, which is closely coupled to PCI SON.
      • Handler microservice is now ANR/PCI Handler MS
      • RAN Simulator functionality has to provide (simulated) FM/PM data (e.g. Handover KPI)
      • Implement messages between SDN-R and RAN Simulator to support ANR function (e.g. cell relationship table, neighbor add and delete actions)