BUSINESS DRIVER

This section describes Business Drivers needs.

Executive Summary  – Goal of this sub-project is to evolve and enhance ONAP Configuration Management and Fault & performance data collection to meet O-RAN specifications.  O-RAN has defined two broad interface specifications for management 5G RAN elements (RU, DU, CU-UP, CU-CP, RAN Intelligent Controller [RIC]) called O1 and A1 interface.  ONAP currently support O1 interface, but small enhancements might to required to fully comply with O-RAN specifications.  A1 interface is between management framework (e.g. ONAP) and RAN Intelligent Controller (RIC).  A1 provide intent based policies to RIC to optimize and manage RAN network performance.

Key Deliverables in R6 release:

• Implement O-RAN defined A1 interface specifications in ONAP controller (e.g. SDN-R).
• Enhance CDS to capture A1 configuration details.
• Enhance VID GUI to invoke intent based policy configuration using A1 interface
• Enhancements to VES events
• Software Upgrade flow enhancement to fully meet O-RAN specifications (beyond R6)

Business Impact - Most ONAP service providers are O-RAN members.  These service providers are expected to support O-RAN specifications with the products they include in their networks.  Modifying ONAP to be O-RAN compliant for FCAP implementation (configuration management, including intent based policy configuration, fault and performance data collection) will be usable by all the service providers, avoid duplicate development effort.

Business Markets - These enhanced ONAP FCAP capabilities, once developed, will be useable by any service provider deploying and using ONAP. This will drive cost savings as configuration, fault and performance data collection functionality doesn't have to be redeveloped multiple times. A1 interface provides a flexible way for the operator to manage wide area RAN network optimization, reducing capex investment needs.  Fault and performance data collection are key enablers for closed-loop automation to collect data to detect anomalous conditions. As such, it can have a large potential OPEX savings impact. 

Funding/Financial Impacts - (The Funding requirements and Financial impacts can describe the financial savings, or CAPEX, OPEX impacts for a Use Case).

Organization Mgmt, Sales Strategies - (It is suggested that you use the following wording): There is no additional organizational management or sales strategies for this use case outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. (This would typically describe the "WHO", but because use cases are all deployed with ONAP itself, these two areas come with the actual ONAP deployment and uses the organizational management and sales strategies of a particular service provider's ONAP deployment)

DEVELOPMENT IMPACTS

List of PTLs:Approved Projects

Areas of impact to ONAP due to 3GPP Harmonization activities and O-RAN O-1 Interface Definition

This section documents the impacted Management Services

Provisioning Management:--R6

1. Define new VES domain to support CM Notifications:

   -notifyMOICreation, notifyMOIDeletion, notifyMOIAttributeValueChange. TS 28.532 Rel 16

These notifications are introduced with the following E2E EPIC (stored in DCAE project, which will benefit the most form this new functionality):
DCAEGEN2-1769 - Getting issue details... STATUS

Fault Supervision:--R6

1. Modify existing fault event or create new fault3gpp event to support Harmonization work in TS 28.532
2. Determine which of the 3GPP supported IS notifications will be supported in ONAP—refine how fault3gpp is filled in for the different notification types

Table 2.2.1.4-1

    3.  Drive the use of IOC objects to configure control operations in ONAP using NetConf commands. Does ONAP agree with the Fault IOC?  I have a proposal for one---its not in the O1 document yet.  I wanted to review it with the Nokia standards guys to see if it makes sense.  The whole notion of how the controller will send these commands should be flushed out in a use case. (See Perf Assurance, Communications Surveillance for added use cases)

   4.  Drive the use of IOC objects to configure subscribe/unSubscribe control on a NF via NetConf commands e.g. Provisioning what notifications a manager wants to receive from a NF. ONAP may not necessarily want to receive everything a NF is capable of sending

Performance Assurance (G Release)

1. Modify the File Ready Notification to support additional Use Cases. It should be used for Performance Assurance but also for a number of other kinds of files—log files that are requested etc.  Propose that ONAP should work with 3GPP reps to change the notification perhaps renaming the changeIdentifier field in the Notification event to a name like fileType so it is more generic.  This will be included in Frankfurt pending 3GPP stabilization in October.
2. ONAP needs to incorporate the job control IOC defined in 3GPP for creating, starting and stopping PM jobs. This should be done via NetConf.

Communications Surveillance (this is at the earliest for the G Release)

1. ONAP needs to define a control/setting of the heartbeat IOC—
   1. -there is a proposal in section 2.6.2 of the O1 spec- Does ONAP agree? 
   2. The generalized use case of how a controller is going to set up these control operations in ONAP needs to be explored.
   3. Are these work flows that an operator might want to define via SO? How automated do we want these to become? 

PNF Registration (this is at earliest for the G Release)

1. Does ONAP support communication with ME behind a NAT? If so will ONAP
   1. Support all the identified methods for providing direct access to MEs behind the NAT?  What restrictions would ONAP add?  Will ONAP insist that the ME does all the configuration?
   2. Will AAI need to be modified to include port number or another identifier so ONAP can communicate with the ME.

PNF SW Management (this is at earliest for the G Release)

1. Resolve differences between the ONAP PNF SW Management and O1 PNF Software Management.
   1. Steps in O1 PNF Software Management are not fully aligned with current ONAP approach—O-RAN advocates more steps—does ONAP agree?
   2. Order of steps is different (pre-check in ONAP happens earlier than in O-RAN)
   3. Additional notifications are required in O-RAN does ONAP agree
2. ResetReason VES notification (defined in PNF SW Management but probably generally applicable notification) Normal during a software upgrade to have a reset so you would want to discount an alarm that was raised. We need to have a community discussion on the scope of this notification.

Call Trace ( this is at earliest for the G Release)

1. Streaming Call trace is being discussed in standards. It likely requires a different kind of interface to ONAP.  Call Trace and Vendor extensions to call trace are very important to O-RAN Suppliers as a mechanism to get input to the Non-RT RIC.  SA5 plans to complete specification in Release 16.  Aligns well with G Release.  Work includes support for streaming trace as well as the introduction of an NRM fragment to specify call trace jobs.

O-RAN A-1 Interface Support in ONAP:

ONAP needs to review work of O-RAN teams on A-1 Definition.  Document will be available in September.  Additionally, OSC (O-RAN Software Community) has been launched April 2019 to realize O-RAN architecture. Frankfurt release must at minimum architect the incorporation of the interface into ONAP and prototype. In this section, we want to keep up-to-dated plan and information on resources relevant to A1 in different communities.  

A1 specs in O-RAN

O-RAN WG2 (https://oranalliance.atlassian.net/wiki/spaces/NonRTRIC/overview) defines both Non-RT (Real Time) RIC and A1. Text in the project overview says Non-RT RIC supports non-real-time intelligent radio resource management, higher layer procedure optimization, policy optimization in RAN and providing AI/ML models to near RT RIC and other RAN functions. A1 interface supports communication & information exchange between Orchestration/NMS layer containing non-RT RIC and eNB/gNB containing near-RT RIC. Key functions of A1 interface include support for policy-based guidance of near-RT RIC functions/use-cases, providing enrichment data to near-RT RIC, and feedback mechanisms from near-RT RIC to ensure SLAs.

O-RAN WG2 plans to release the first A1 specs September 2019. ONAP will need to adopt those A1 specs, which will include both the application protocol and transport protocol aspects.

Relevant development in OSC

Release A (the first release of OSC) is targeted for December 2019. OSC projects include A1-relevant projects such as Non RT RIC (https://wiki.o-ran-sc.org/display/RICNR/Non+real+time+RIC)  and A1 mediator (https://wiki.o-ran-sc.org/display/RICP/A1+Mediator).

The scope of Non RT RIC project includes A1 peer in orchestration layer. Generally, ONAP is not the only platform desirable for Non RT RIC in OSC. However, they are planning to use ONAP El Alto as a base platform for release A.  The scope of release A in Non RT RIC project has not been finalized as of July 2019. General consensus for now is that release A’s scope would not be gating and release B will be their primary target.

Even though O-RAN WG2 has not finished its specs of A1, OSC RIC project already started implementation including A1 mediator. A1 mediator is a RIC component which plays as a single entry peer of A1 to RIC. Here is gerrit repo of A1 mediator: https://gerrit.o-ran-sc.org/r/admin/repos/ric-plt/a1. A1 mediator supports RESTful interface as a policy-syntax agnostic transport of policy.

From OSC to ONAP

Since Non RT RIC project in OSC is planning to use ONAP as a base platform for orchestration layer with A1 scoped in, we will need a plan to ingest OSC code to ONAP. Since A1 implementation in Non RT RIC project is not yet finalized as of July 2019. We need to keep track of the progress in such area.

Impacted systems

SDN-C:  Implement southbound adaption layer to communicate with Near-Real Time RIC using A1 specified protocol (most likely Rest) and encoding.

CDS: Expand CDS to design intent based policy configuration to send to Near-Real Time RIC using A1 interface.

Recommendations on Prioritization:

Recommendations on prioritization

1.a Update existing VES events so NF providers have up to date information

1.b  Equally important to 1a add support for A-1 interface

Introduce simple missing functionality

Plan Use Case Discussions for more complicated scenarios like CM changes and SW Update to work through where components should change.

SUPPORTING DOCUMENTS

PRESENTATIONS

RECORDINGS

Test Cases and Status

Harmonization Integration Test Cases for A1. These can be navigated to from the Integration team page hierarchy.

Test Plans for A1 Adapter (Non RT RIC)

Harmonization Integration Test Cases for O1. These can be navigated to from the Integration team page

Test Plans for O1 Harmonization introduction of cmNotify