SMO/Non-RT RIC Platform and Application Epics and Requirements Implications

Execution Time Epics and Requirements Implications

The particular SMO/Non-RT RIC implementation assumed for this use case is based on an ONAP Frankfurt Release implementation.

Policy:

Policy will support a new category of policies, "external policies", such that the enforcement point of the policy is external to ONAP.  Metadata will indicate the enforcement point target type of an "external policy" type.

Policy will maintain a repository of policy instances of external policies, each being assigned a unique id.  Associated with each policy instance will be a "state":

• Pending: The policy instance has been created but has not yet been propagated to any enforcement point instances.
• In Effect: The policy instance has been propagated to at least one enforcement point instance.
• Pending Cancel: The policy instance has been canceled, but the cancellation has not yet been propagated to the enforcement point instances.
• Historic: The policy instance cancellation has been propagated to all enforcement point instance.

Policy will be able to bulk send all Pending and In Effect policies to SDN-R

Policy will support a new Policy type of “QoE Based Traffic Steering” that will be of an "external policy" category.

The Metadata of "QoE Based Traffic Steering" external policy type will indicate that the xNF that terminates the A1-P interface is the policy target.

“QoE Based Traffic Steering” Policy will be of the following format: XXXXXXX".  Metadata will indicate the <TargetRicInstance>

When an instance of “QoE Based Traffic Steering” Policy is created, Policy will direct it to SDN-R

Policy GUI:

The Policy GUI will allow an ONAP user to create an instance of QoE Based Traffic Steering Policy and populate the metadata that indicates the <TargetRicInstance>

SDN-R:

Upon receipt of a “QoE Based Traffic Steering” Policy instance, SDN-R will send that Policy instance across the A1-P interface to the Near-RT RIC instance described in that Policy metadata.

DCAE:

Receive faults produced by the TS and QP xApps

Receive PM produced by the TS and QP xApps

ONAP Portal:

Provide Operator Visibility into TS xApp and QP xApp Performance (THIS IS A PLACEHOLDER; NEED TO FLESH THIS OUT TO ENSURE xAPPs PRODUCE SUFFICIENT DATA)

Deployment Time Epics and Requirements Implications

Because ONAP does not support xApps as separately managed objects in the Frankfurt release, xApp deployment in Release B will be handled as if the TS and QP xApps were software modules of the Near-RT RIC itself.