Near-RT RIC Application Requirements
General Requirements:
Generate Faults for the following conditions:
- Unrecognized data input received
- Critical error encountered (error text)
Generate PM:
- Number of requests processed per time interval (???)
TS xApp Requirements:
Will subscribe to A1-P “QoE Based Traffic Steering” policy
Will receive policy instance and determine from it:
- The class of UE that the policy targets
- The QoE Target for that UE class
- The desired prediction time window
Will determine from Near-RT RIC the set of O-CU-CP (???? TBD???) instances that are within the management area of this Near-RT RIC instance.
Will send to the Near-RT RIC Platform a separate subscription request for each O-CU-CP instance, each requesting a REPORT of CellPerf with a reporting interval as provided in the received policy.
Will receive CellPerf KPIs and based on that calculate and maintain a “congestion score” for each. (???HOW???)
Will send to the Near-RT RIC Platform a separate subscription request for each O-CU-CP instance, each requesting a REPORT of UE Perf KPIs for the UE class with a reporting interval as provided in the received policy.
Will receive UE Perf KPIs and based on that determine which UEs are within the RIC instance’s serving area. Will determine the F1-C UE Id (???) of each UE.
Will use the KPI values returned to determine which UEs are “active” and which are “inactive” for that reporting interval. (HOW???)
Will subscribe to QoE Predicted (serving, neighbors) for the “active” UEs with a reporting interval as provided in the received policy. The UEs will be identified via their F1-C UE Id (???).
Will receive QoE Predicted (serving) and compare to QoE Target. If QoE Predicted (serving) < QoE Target:
- It will examine the timestamp of the QoE Predicted (neighbors) to verify that the data is still useful
- It will examine QoE Predicted (neighbors) to determine which neighbor cells would provide a QoE Predicted (neighbour) > QoE Target
- For the neighbour cells that provide > QoE Target, determine their “congestion score”.
- Eliminate any cell with a “congestion score” > 80% (???)
- Select from the remaining neighbour cells (if any) the cell with the least “congestion score” as the cell to which to handover the UE.
Will send an E2 handover request to the CU-CP requesting handover to the selected neighbour cell. It will identify the UE via the same Id that was received on the KPIs.
The QP xApp must be able to analyse XXX predictions per time period, measured from receipt at the xApp of the Predicted QoE data.
The QP xApp must be able to generate an E2 control handover request to the Near-RT RIC Platform within latency time period 99% of the time.
In the future the following additional may be supported. This section is useful in the Release B timeframe only for planning purposes.
- 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.
Will determine from Near-RT RIC the set of O-CU-CP (???? TBD???) instances that are within the management area of this Near-RT RIC instance.
Will send to the Near-RT RIC Platform a separate subscription request for each O-CU-CP instance, each requesting a REPORT of UeRf and UePerf with a reporting interval as provided in the received subscription request.
Will send to the Near-RT RIC Platform a separate subscription request for each O-CU-CP instance, each requesting a REPORT of CellPerf with a reporting interval as provided in the received subscription request.
Will receive UeRf and CellPerf KPIs.
For each neighbour cell indicated in the UeRf KPI: Derive a current predicted UePerf (PDCP Throughput) for that neighbour cell by feeding the UeRf KPIs for that neighbour cell along with the CellPerf KPIs for that cell into the trained QoE Predictor Model
Calculate a Predicted QoE “score” for each Predicted UePerf. In Release B the QoE score will simply be the PDCP Throughput value itself. In future releases the QoE score may take into consideration other factors, such as transmit errors, etc.
Calculate a QoE “score” for the UePerf actual for the serving cell. In Release B the QoE score will simply be the PDCP Throughput value itself.
Report to the Near-RT RIC Platform the calculated QoE “current” for the serving cell, along with the predicted QoE “current” for each neighbour cell, applying a timestamp to the data.
In the future the following additional may be supported. This section is useful in the Release B timeframe only for planning purposes.
- Ability to configure the xApp to support a subset of the O-CU-CPs in the Near-RT RIC’s management area.
The QP xApp must be able to support XXX predictions per time period, measured from receipt at the xApp of the UeRf and CellPerf KPIs.
The QP xApp must be able to render a predicted UePerf measurement for a single UE within latency time period 99% of the time.
Near-RT RIC Platform Requirements
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 Policy type of “QoE Based Traffic Steering”
“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:
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)