Versions Compared

Old Version 1

changes.mady.by.user Gil Bullard

Saved on

compared with

New Version Current

changes.mady.by.user Gil Bullard

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  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: Need to identify the group id to be used in Release B.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.

...

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.

PICTURE HEREImage Added

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

...

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.

PICTURE HEREImage Added

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.

...

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

PICTURE HEREImage Added

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:

...