Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Execution Time Epics and Requirements Implications

General Requirements:

Generate Faults for the following conditions:

...

  • Number of requests processed per time interval (???)

TS xApp Requirements:

Will subscribe to A1-P “QoE Based Traffic Steering” policy

...

  • Send predicted QoE to the Non-RT RIC via O1 in support of ongoing reinforcement learning.
  • Ability to configure the xApp to support a subset of the O-CU-CPs in the Near-RT RIC’s management area.

QP xApp Requirements:

Will receive subscription request for QoE Prediction data and determine the UE Ids (F1-C) Ids for which to provide predictions and the prediction interval desired.

...

The QP xApp must be able to render a predicted UePerf measurement for a single UE within latency time period 99% of the time.

Execution Time Epics and Requirements Implications

General Requirements:

Upon being loaded will declare to the Near-RT RIC Platform

...

Receive xApp subscription request to a particular E2 endpoint for a given scope (i.e., UE Class, gNB) and time interval (TBD).

Translates the xApp subscription request into the corresponding E2 subscription request,

Make A1-P data available to the xApp that subscribed to it.

Make E2 data available to the xApp that subscribed to it.

Make QoE Predicted data available to the xApp that subscribed to it.

Handle xApp requests to send E2 Control message to a particular E2 endpoint to request UE handover from the current serving cell to a neighbour cell.

Make available for the xApps the “inventory” of E2 endpoints that the RIC instance supports, and their type of Network Function (gNB, O-DU, O-CU-CP, etc.).

The Near-RT RIC Platform must deliver published metrics to the subscribing xApps, introducing a latency delay of no more than XX 99% of the time.

SMO/Non-RT RIC Platform and Application Requirements

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 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 a Near-RT RIC xNF type is the policy target.

“QoE Based Traffic Steering” Policy will be of the following format: XXXXXXX, <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

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.

DCAE:

Receive faults produced by the TS and QP xApps

Receive PM produced by the TS and QP xApps

ONAP Portal:

...

what data it consumes and what data it publishes.

TS xApp Requirements:

When loaded, the TS xApp will declare to the Near-RT RIC Platform that it consumes “QoE Based Traffic Steering” Policy, UePerf data, and PredictedQoE data. It produces nothing.

QP xApp Requirements:

When loaded will declare to the Near-RT RIC Platform that it consumes UeRf, UePerf, and CellPerf data. It produces PredictedQoE data.