...

Provisioning Management:

1. Define minimum supported NETCONF operations and capabilities. (VNF requirements ask for everything.  We should make sure that NFs and Controller support absolutely required operations and capabilities)new VES domain to support CM Notifications:

   -notifyMOICreation, notifyMOIDeletion, notifyMOIAttributeValueChange. TS 28.532 Rel 16

Fault Supervision:

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

...

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.

File Management

1. Same as PM comment one.  File Management supports the more general use case of the ME informing the manager that it has a file available for upload.

Communications SurveillanceCommunications 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 ( suggest 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:

...

List of PTLs: Approved Projects

...