Skip to end of metadata
Go to start of metadata


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

PROJECTPTLUser Story / EpicRequirement
A&AI

n/a


AAFn/a
APPCn/a


CLAMPn/a
CC-SDK n/a
DCAEnew domain for CM notifications

DCAEGEN2-1769 - Getting issue details... STATUS

DCAEGEN2-1770 - Getting issue details... STATUS

DCAEGEN2-1771 - Getting issue details... STATUS

DMaaPnew domain for CM notifications

DMAAP-1302 - Getting issue details... STATUS

External APIn/a
MODELINGn/a

Multi-VIM /

Cloud

n/a
OOFn/a
POLICY

n/a


PORTALn/a
SDN-C

Epic #1 ORAN/3GPP & ONAP Harmonization

A1 Interface

REQ-38 - Getting issue details... STATUS

CCSDK-1796 - Getting issue details... STATUS

SDCn/a
SOn/a
VIDn/a
VNFRQTSnew VNF requirements to support new events
VNF-SDKn/a
CDS

Epic #1 ORAN/3GPP & ONAP Harmonization  

A1 Interface

REQ-38 - Getting issue details... STATUS

IntegrationIntegration (CSIT) tests covering the cm3gppNotify domain

INT-1258 - Getting issue details... STATUS

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

3GPP IS Notification

TS 28.545 S5-193519 section Reference

notifyNewAlarm

3GPP TS 28.545, S5-193519 Section X.2.2

notifyNewSecurityAlarm

3GPP TS 28.545, S5-193519 Section X.2.3

notifyAckStateChanged

3GPP TS 28.545, S5-193519 Section X.2.4

notifyClearedAlarm

3GPP TS 28.545, S5-193519 Section X.2.5

notifyAlarmListRebuilt

3GPP TS 28.545, S5-193519 Section X.2.6

notifyChangedAlarm

3GPP TS 28.545, S5-193519 Section X.2.7

notifyComments

3GPP TS 28.545, S5-193519 Section X.2.8

notifyPotentialFaultyAlarmList

3GPP TS 28.545, S5-193519 Section X.2.9

notifyCorrelatedNotificationChanged

3GPP TS 28.545, S5-193519 Section X.2.10

notifyChangedAlarmGeneral

3GPP TS 28.545, S5-193519 Section X.2.11

    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


SlidesFiles



PRESENTATIONS

RECORDINGS

Zoom Video & Audio (MP4)

Presentation given at the

Use Case Realization Call August 14, 2019

Use Case Realization Call: August 14, 2019

Audio Only (M4A)

Use Case Realization Call August 14, 2019

Use Case Realization Call: August 14, 2019

Test Cases and Status


#Test CaseStatus
1There should be a test case for each item in the sequence diagram

NOT YET TESTED

2create additional requirements as needed for each discreet step

COMPLETE

3Test cases should cover entire Use Case

PARTIALLY COMPLETE

 Test Cases should include enough detail for testing team to implement the test

 FAILED


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

  • No labels

5 Comments

  1. The Linux Foundation O-RAN SC Non Real-Time RIC (NONRTRIC) project has just kicked off.

    https://wiki.o-ran-sc.org/display/RICNR

    We plan to build a NONRTRIC (including an A1 terminator), hopefully basing any implementation on the ONAP CCSDK work and reusing as much existing ONAP functionality as possible.

    Perhaps we can work together on this?

    Thanks

    John Keeney (ORAN SC NONRTRIC PTL)

    1. JohnKeeney 

      We updated A1 support section in this page so that we consider NONRTRIC project in OSC. 

      We hope that we can ingest some OSC code about A1 to Frankfurt release.

      Very basic functionality to show something like plumbing part without fancy application would be a good start as the first release.

      Thanks

      Dongho

      1. Hi Dongho Kim Marge Hillis Vimal Begwani Benjamin CheungFred Feisullin


        It has been a couple of weeks since the last update. Things have moved on a little more in the O-RAN-SC projects, in particular work/resource planning for the next couple of planned releases. Can you comment on the latest updates on this proposal?


        Can you also comment on whether the proposed changes (requirements) to support A1 and non-RealTime RIC functionality should happen as part of the ONAP projects or in the O-RAN-SC projects?
        It would be a pity to duplicate any of this work in both ONAP and O-RAN-SC projects.  For example:

        • Implement O-RAN defined A1 interface specifications in ONAP controller (e.g. SDN-R): Implementation work to achieve this is currently happening in the O-RAN-SC NONRTRIC project.
        • Enhance CDS to capture A1 configuration details: There has been no decision/discussion how this will be implemented in O-RAN-SC NONRTRIC project. Has this decision been made in ONAP?
        • Enhance VID GUI to invoke intent based policy configuration using A1 interface: There has been no decision/discussion how this will be implemented in O-RAN-SC NONRTRIC project. Has this decision been made in ONAP?


        Thanks,

        John Keeney (ORAN SC NONRTRIC PTL)

        JohnKeeney


        1. JohnKeeney

          As a quick update, Vimal presented this use case to use case call hosted by Alla. (before Frankfurt deadline)
          As a next step, I hope some message flows are agreed and JIRA tickets are created.  

          1) ONAP vs. OSC 
          We believe that ONAP is good for a place to centrally maintain platform code for NON RT RIC and OSC is a good place for packaging application running on top of platform. Detailed plan might be up to the team. e.g. we are fine with starting developing some platform code in OSC and transferring it to ONAP. . but we hope A1 adaptor (which would be platform code) is converging to ONAP Frankfurt.

          2) CDS detail
          I understand that SDN-R team invited Yuriy (CDS PTL) to a regular call tomorrow. I put CDS relevant questions for A1 in question list for him. I hope we can get some feedback from him tomorrow.

          3) VID GUI
          I did not hear about this discussion. hopefully, other person can comment. 

  2. JohnKeeney

    An EPIC has been created. REQ-38 - Getting issue details... STATUS