Execution Time Epics and Requirements Implications

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.

Execution Time Epics and Requirements Implications

General Requirements:

Upon being loaded will declare to the Near-RT RIC Platform 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.

Browser not supported