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.