...
Figure 6 – Data Movement Between Functional Components
The above diagram is summarized in the following sequence diagram.
Note that this organization of functionality into xApps also allows for future extensions. E.g., if another xApp exists that can predict the travel path of a given UE, then the QP xApp could use such travel path information to give a better Predicted: (QoE) Future. The TS xApp could also use such travel path information to determine a “cost” of each neighbor cell as part of intervention handling, so as to minimize future handovers.
Note the attempt to standardize interactions between xApps and the Near-RT RIC Platform. Each xApp that is a consumer of data, whether it be data whose eventual source is E2, another xApp, or in the future A1-EI, would declare that data need to the Platform through a standard "subscribe" interaction. The Platform would be responsible for determining the data source with which to fulfill that request. The Platform would know about xApp data sources via an interaction at the time the time an xApp is loaded through which the xApp would declare that it is a producer of a particular data type. In the example above the QP xApp is a producer of Calculated: (QoE) and Predicted (QoE) data in two separate dimensions:
- Predicted: (QoE) at the current time for neighbor cells.
- Predicted: (QoE) at a future time for both the serving and neighbor cells
For expediency in this Bronze deliverable we will leverage the KPIMON xApp from the Amber release as shown in Figure 7 below.
Figure 7: Leveraging the KPIMON xApp to Collect E2 Data
Because the KPIMON xApp already has a subscription path for E2 data that does not leverage the general interaction pattern of xApps with the Platform, we need not reimplement that in this Bronze release. Rather we will assume that the KPIMON xApp has previously been loaded to the Near-RT RIC instance, and has already subscribed to and is writing the needed E2 data to the RIC Platform. Thus, when the TS and QP xApps subscribe to data that would otherwise (in the absence of the KPIMON xApp) resolve to the Platform sending an E2 SUBSCRIBE to the appropriate RAN nodes, instead the Platform will resolve the subscription request to the local shared data repository.
The above diagram is summarized in the following sequence diagram, illustrating changes from Figure 6 when KPIMON is introduced.
