...
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.
...
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.
