Execution Time Epics and Requirements Implications
Receive and process xApp subscription requests for xApp produced data with a given scope (i.e., UE Class, gNB) and time periodicity (TBD). Processing includes passing the subscription request to the xApp that produces the data type. (See "Deployment Time" requirements for more information.) Design constraints:
- Implement in such a way that it is easily extensible to support receipt and processing of xApp subscription request for A1-EI produced data with a given scope (i.e., UE Class, gNB) and time periodicity (TBD).
- Implement in such a way that the subscribing xApp has a common interface with the Platform to request data, irrespective of whether that data is produced via E2, via another xApp, or via A1-EI. The subscribing xApp is unaware of the data source.
- Implement in such a way that the producing xApp is unaware whether one or more subscribing xApps are interested in the same data type, scope and periodicity.
Receive and process TS xApp subscription request for QoE Predicted data.
Properly route xApp-produced data to the appropriate subscribing xApp.
Properly route QP xApp-produced QoE Predicted data to the TS xApp that subscribed to it.
Make available for the xApps the “inventory” of managed Network Function instances that the RIC instance supports, and their type of Network Function (gNB, O-DU, O-CU-CP, etc.). The xApp will use this to select the (subset of) Network Functions that will appear as "scope" in a subscription request.
Allow the subscribing xApp to send a list in the "scope" of a subscription request (e.g., a list of gNBs). For subscription requests whose source resolves to an E2 termination point, the RIC Platform would mediate that request, looping through each of the scope targets sending E2 SUBSCRIBE requests.
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.
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.
The Near-RT RIC Platform will provide a logging service to xApps, so that xApps will have a common way of writing their log records.
The Near-RT RIC Platform will provide a common log repository in which xApp and Platform log records are captured. This repository will natively allow for filtering, sorting and selecting (e.g., a database, not a file).
Deployment Time Epics and Requirements Implications
Near-RT RIC Application Requirements
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.
...
Upon a new xApp instance being loaded, the Platform will catalog the data types consumed and produced, and use this information in the routing of data from xApp to xApp. Particularly, the Platform will be responsible for ensuring that the PredictedQoE data produced by the QP xApp is made available to the TS xApp
...
SMO/Non-RT RIC Platform Requirements
...
.