...

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)

AREAS OF INTEREST

...

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:

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)

Fault Supervision:

1. Modify existing fault event or create new fault3gpp event
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

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.
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 Surveillance

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

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

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.

A-1 Interface Support in ONAP

ONAP needs to review work of O-RAN teams on A-1 Definition.  Document to be available in September.  Frankfurt release must at minimum architect the incorporation of the interface into ONAP and prototype.

...

Development Status

...