Analysis Background for the Proposed Solution

Owned by GilBullard
Last updated: Jan 20, 2020
8 min read

This page provides background information on the analysis that went into the definition of the proposed solution.

Functional Components Involved in the Use Case

The functional components involved in the execution time behaviour of this use case are as follows:

  1. UE Identifier:
    1. Includes an interface to the Mobile core or BSS to determine the desired “Target QoE”, or (QoE) Target, for the UEs of interest. In Rel B this interface would be stubbed off.
    2. In Release B the UEs of interest will be identified through a group id such as QCI or SPID.  In future releases the UEs of interest could be identified via some global UE Id.  
    3. OPEN ISSUE: Is it reasonable for the O-DU to know which UEs would correspond to one of these identifiers such that the O-DU would collect KPIs for those UEs?  If not, perhaps we would ensure that the RIC will have a QCI to UE Id mapping in its database, such that the RIC could send an E2 KPI SUBSCRIBE per UE Id.  The UE Id in question would presumably be the F1-C Id 


    4. Makes the UE (group) identifier(s) and associated (QoE) Target to the other functional components described below.
  2. UE Filterer:
    1. Collects “Per-UE Performance Data” KPIs from the RAN, or (UePerf) Actual, for the UEs identified by the UE Identifier. See SECTION XXX for the specific KPIs included in this data class.
    2. Can filter the set of UEs being monitored as needed.
    3. Makes this filtered list of UEs available to “QoE Predictor Model” (see below).
  3. QoE Predictor (trained ML model):
    1. Collects “Per-UE RF Data” KPIs, or (UeRf) Actual, and “Per-Cell Utilization Data” KPIs, or (CellPerf) Actual. See SECTION XXX for the specific KPIs included in this data class. Note that the “Per-UE RF Data” includes RF signal measurements reported by the UE for both the “serving” and the “neighbor” cells.
    2. It uses that UeRf and CellPerf KPI data to make predictions of UePerf. These predictions can be “what if” predictions at the current time, (UePerf) Current. Or these predictions can be temporal predictions about the future, (UePerf) Future.
    3. In Release B it makes a “what if” prediction of “what would the UE report as its Per-UE Performance Data KPIs of interest if that UE were connected instead to a neighbor cell.” I.e., given (UeRf, CellPerf) Actual: Neighbor it will predict (UePerf) Current: Neighbor
    4. In Release C it will, in addition, make the following temporal predictions with a given time window (e.g., 10 seconds) provided as a configuration parameter.
      1. A future prediction of “what will the UE report as its Per-UE Performance Data KPIs of interest if that UE were to remain on the serving cell until the end of the input time window.” I.e., given (UeRf, CellPerf) Trending, Serving it will predict (UePerf) Future: Serving
      2. A future “what if” prediction of “what would the UE report as its Per-UE Performance Data KPIs of interest if that UE were connected to a neighbor cell at the end of the input time window.” I.e., given (UeRf, CellPerf) Trending: Neighbor it will predict (UePerf) Future: Neighbor
    5. Leverages the services of QoE Calculator to convert “UePerf” (either actual or predicted) into a QoE metric (a.k.a., QoE score).
    6. Output of the QoE Predictor is a data structure consisting of a QoE-ranked list of neighbor cell alternatives.
  4. QoE Calculator:
    1. Takes as input UePerf data and calculates the corresponding QoE score.
    2. Note that this function doesn’t know or care whether it is being provided UePerf as known through KPIs, or (UePerf) Actual, or being provided predicted UePerf, i.e., (UePerf) Current, Neighbor or (UePerf) Future. Thus it doesn’t know whether it is calculating a current (QoE) Current: Serving, or a “what if” predicted (QoE)Current: Neighbor, or a “temporal” predicted (QoE) Future.
    3. In Release B we will assume QoE == DL UE PDCP throughput”
  5. UE Intervention Selector:
    1. Determines which UEs could benefit from intervention. Specifically:
      1. In Release B it will compare the (QoE) Target to the calculated (QoE) Current: Serving and determine if UE QoE is suffering and hence intervention is needed. If so, it will compare (QoE) Target to the “what if” predicted: (QoE) Current: Neighbor to determine to which cell to drive handover
      2. In Release C it will, in addition to the above, compare the (QoE) Target to the predicted: (QoE) Future: Serving and determine if UE QoE is anticipated to suffer, and hence intervention will soon be needed. If so, it will compare (QoE) Target to the predicted (QoE) Future: Neighbor for each neighbor cell to determine to which cell to drive handover.
    2. Having determined that intervention is needed for a given UE, it will provide to the Traffic Steerer the list of neighbor cell handover options that will maintain the QoE needs of that UE.
  6. Traffic Steerer
    1. Receives the list of cell handover options and evaluates the extent to which it can act on it given other considerations.
    2. If possible to act, it will instruct the RAN to initiate handover of the UE to the selected neighbor cell.

Assumption 7.1-1: It will be useful for Traffic Steerer function to be able to operate in a “standalone” deployment configuration. For example, if it has access to cell utilization or anticipated utilization information, it could use that information to direct UE handovers (though in this example not autonomously acting to the RAN but by triggered by the RAN for handover decision assistance).

Analysis of the Runtime Environment

Because E2 is the only viable O-RAN Alliance interface via which a Traffic Steerer could initiate UE handover actions to the RAN, the Traffic Steerer function must reside in the Near-RT RIC.

Because the UE Identifier has an interface to the Business Applications and/or the Core, that function must reside on the Non-RT RIC.

Determining the execution environment for the UE Filterer, QoE Predictor, QoE Calculator and UE Intervention Selector will require some further analysis to weigh the Non-RT RIC and Near-RT RIC options. Data movement costs and interaction latency considerations will factor heavily into this analysis. Figure XXX provides a schematic that illustrates the data movement and other interfaces between the functional components described above.

Figure 1 – Data Movement Between Functional Components

Both the UE Filterer and the QoE Calculator require high volume Per-UE Performance data for the serving cell: (UePerf) Current, Serving. In addition, the QoE Predictor requires the high volume fine grained Per-UE RF data for the serving and neighbor cells: (UeRf, CellPerf) Current. (See [REF] section 3.1.4 for a description of these data items.)

Because the Traffic Steerer is assumed to be capable of making handover decisions for UEs that are not of interest to the QoE Predictor Model (see Assumption 7.1-1), it will likely also require access to the high volume “Per-UE RF” or “Per-UE Perf” data. Because the Traffic Steerer will execute on the Near-RT RIC, this data would be delivered across the E2 interface.

Because the UE Filterer, QoE Calculator and QoE Predictor Model also require access to the voluminous “Per-UE RF” and/or “Per-UE Perf” data for its UEs of “interest”, data movement could be minimized by co-locating the QoE Predictor Model on the Near-RT RIC with the Traffic Steerer function. Thus the QoE data would be passed between functions through a mechanism internal to the Near-RT RIC.

Because any Predicted QoE must be acted on in a timely manner, it would make sense to also co-locate the UE Intervention Selector on the Near-RT RIC to avoid adding an A1 interaction between the QoE Predictor and the Traffic Steering functions.

Because the UE Identifier will execute on the Non-RT RIC, the “UE Group, Target QoE” data must be passed across the A1 interface to be made available to the UE Filterer and the UE Intervention Selector. Because the “Target QoE” can be thought of as being an expression of “Policy”, A1-P is a reasonable mechanism.

Given the above, the implementation architecture for this use case will be such that the “UE Identifier” functional component is included in an rApp running on the SMO. All other functions will reside on the Near-RT RIC.

As per Assumption 7.1-1, the “Traffic Steerer” functional component will be packaged as a modular xApp capable of being deployed standalone on the Near-RT RIC. Because we envision that the Traffic Steerer function will, certainly in the future, need to take into consideration other factors besides just UE QoE in its traffic steering function, we will include all decision making in the same xApp as the Traffic Steerer function. Thus the UE Intervention Selector as well as the UE Filterer will be co-resident in the same xApp as the Traffic Steerer function: the Traffic Steering xApp (TS xApp). The other functions will be grouped into a separate QoE Prediction xApp (QP xApp).

Thus, the Traffic Steering xApp will be organized as a standalone xApp that supports a “base” functionality that can work without QoE prediction. Such “base” functionality will exercise only the Traffic Steerer function. This xApp will also be assumed to be extensible to work off of QoE prediction data if it is available (i.e., if a QP xApp is co-resident with it on the same RIC instance). Such an extended xApp would also exercise the UE Filterer and UE Intervention Selector functionality.

Analysis of the Training Environment

The location of the training environment, co-located with the SMO/Non-RT RIC versus a central data lake, is a decision that depends mostly on business needs rather than technical considerations given that different business entities will decide differently how to weigh the relative cost of transporting massive amounts of data to a central data lake versus the benefit of having this data in such a data lake. This section will limit itself to describing the data needed during training and the high level training process envisioned.

Figure 2 – Initial Training

Two of the data items required are quite voluminous: Per-UE RF and Per-UE Performance data. In Release B the desired training location will hence be a business decision that must be made evaluating the cost of transporting the data to a central data lake versus the benefits of having that data in a central data lake for initial training.

For ongoing model improvement training, however, it would be useful to have access to the output of the QoE Predictor Model in runtime. This would allow ML training to refine the prediction ability of the ML Model. In order for this “reinforcement training” to work, it will be necessary to correlate the Predicted value of the UE performance on its neighbour cell, (UePerf) Current, Neighbor, with the actual measured performance of that UE post-handover. This comparison would require a common or mapped identifier for the UE both before and after handover. However in some cases the UE identifier will change with the handover, particularly when the CU-CP changes. Multiple ways exist to respond to this:

  1. Limit the “reinforcement training” to those handovers in which the UE Identify does not change post-handover.
  2. Determine a “global UE identifier” and make it available via E2 or a mapping from an E2 identifier.
  3. Determine a method to map between the pre-handover UE identifier and the post-handover. (E.g., have the pre-handover UE identifier reported via E2 by the new cell post-handover.)
  4. Do not attempt “reinforcement training”.

In Release B we will go with approach “4”.

In Release C we will go with approach “1”.

Figure 3 – Reinforcement Training – Release C

Being unable to speak for all Service Providers on their business decisions, we will simply choose between the reasonable alternatives that which allows us to more fully exercise the named components in the O-RAN architecture. Namely, we will assume that initial training occurs in the SMO, co-located with the Non-RT RIC functionality. The SMO will collect the data across the O1 interface and make it available to the Model-in-training at the Non-RT RIC. The Near-RT RIC will report (UePerf) Current, Neighbor to the Non-RT RIC via O1. However this may not be achievable in the Release B timeframe given limitations in the available SMO functionality, and so we will take the following approach:

  • Release B: Offline training in a lab environment
  • Release C: Training in the SMO environment.