Content for TR 23.700-36 Word version: 18.1.0
6.2.1.2 Procedure on VAL UE / session performance analytics
6.2.2 Corresponding Analytics API
6.2.3 Solution evaluation
...
...
6.2.1.2 Procedure on VAL UE / session performance analytics p. 19
Figure 6.2.1.2-1 illustrates the procedure where the VAL session performance analytics are performed based on data collected from the ongoing VAL sessions.
Pre-conditions:
- ADAEC is connected to ADAES
Figure 6.2.1.2-1: ADAES support for VAL session performance analytics
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
A session starts between the VAL UE #1 and a VAL server.
The consumer of the ADAES analytics service sends a subscription request to ADAES and provides the analytics event ID e.g. "VAL UE perf prediction", the target VAL UE ID, VAL server ID/VAL application ID, the time validity and area of the request, the required confidence level, exposure level for providing UE analytics. If the consumer is the VAL server, the VAL server can provide to ADAEC application data related to the UE expected route/trajectory and VAL application traffic schedule / expected session time.
Step 2.
The ADAES sends a subscription response as an ACK to the consumer.
Step 3.
The ADAES selects the corresponding ADAEC of the VAL UE for which the local analytics need to be performed.
Step 4a.
The ADAES sends a subscription request to the ADAEC with the analytics event ID and the configuration of the reporting required (e.g. periodic, based on threshold or event)
Step 4b.
The ADAEC sends a subscription response to ADAES
Step 5.
The ADAEC maps the analytics event ID to a list of data collection event identifiers or data collected IDs at the VAL UE or other UEs within the service and in proximity (in group-based communications)
Step 6.
The ADAEC subscribes to the VAL clients and/or requests UE local data based on the respective Data Collection Event ID (or the analytics event ID if they already know the mapping). This data may come from the PDU layer of the UE (via listening the traffic), or via VAL client of one or more UEs (if an application consists of a group of UEs).
Step 7.
The ADAEC (after being aware from the VAL client that the session started) sends a notification to ADAES that a session started, and it could be possible to provide real-time data analytics for VAL UE performance in the target area.
Step 8.
The ADAEC starts collecting data from the corresponding VAL UE(s) based on subscription. Such data can be about the RTT, throughput, jitter, QoE measurements, QoS profile load, etc. It can be also possible that VAL client provides to ADAEC application data related to the UE expected route/trajectory and VAL application traffic schedule / expected session time.
Step 9.
The ADAEC filters or correlates the data based on the analytics event and the data collection configuration.
Step 10.
When the VAL UE session finishes, the ADAEC (optionally) derives VAL session analytics to ADAES on VAL UE #1 performance, based on the analytics ID and type of request. Such analytics (if performed at the ADAEC can be stats or predictions on the RTT or RTT deviation, average/peak throughput, av. jitter, QoE measurements (MOS, stalling events, buffer related events), QoS profile load, VAL application traffic load etc. In case of prediction, a confidence level shall be also present and a time horizon for the predicted parameters.
Step 11.
The ADAEC sends the data of step 8 or the analytics of step 9 (if ADAEC performs analytics) to the ADAES.
Step 12.
The ADAES derives application layer analytics on VAL session performance (based on the data or analytics received by the ADAEC), based on the analytics ID and type of request. Such analytics can be stats or prediction for a given area/time and based on the event type for a given network configuration. Such analytics (if no analytics is performed at ADAEC) at ADAES can be stats or predictions on the RTT or RTT deviation, average/peak throughput, av. jitter, QoE measurements, QoS profile load, VAL application traffic load etc. In case of prediction, a confidence level shall be also present and a time horizon for the predicted parameters.
Step 13.
The ADAES sends the analytics to the consumer, where these analytics include the VAL UE 1 session predicted performance for a given area and time horizon, including also the confidence level, whether offline/online analytics were used.
6.2.2 Corresponding Analytics API p. 21
This subclause provides a summary on the corresponding Analytics API for solution #1.
For VAL server performance analytics, this includes:
- Inputs: per VAL server performance measurements (application QoS measurements such as latency, channel losses, data rate, jitter), historical data/stats for VAL server performance, network/KPI monitoring from 5GS
-
List of Data Sources
- Data Source #1 information: VAL UE #1 (or more VAL UEs having a session with VAL server #1), VAL Server #1
- Data required from Data Source #1: application QoS measurements
- Data Source #2 information: OAM
- Data required from Data Source #1: PM data
- Data Source #3 information: 5GC
- Data required from Data Source #3: service experience analytics, network and QoS monitoring
- Output: Predicted application QoS metrics per VAL server, Statistics on VAL server application QoS/performance metrics
- Inputs: per VAL session performance measurements (application QoS measurements such as latency, channel losses, data rate, jitter)
-
List of Data Sources:
- Data Source information: VAL UE #1, VAL Server #1
- Data required from Data Source: application QoS measurements
- Output: Predicted application QoS metrics per VAL session
6.2.3 Solution evaluation p. 22
This solution addresses Key Issue #1 and introduces application layer analytics to predict the performance of a VAL server or an application session between a VAL UE and a VAL server. Such solution enables the VAL layer to get statistics or predictions for expected deviations of application performance metrics (e.g. RTT) based on data collected from the ADAE clients, as well as from 5GS. This solution is complementary to Solution #4 which covers only the VAL UE-to-UE sessions. Also, this Solution doesn't overlap with Solution #2 which provides a generic mechanism for data analytics enablement (and could be re-used).
This solution is technically viable and doesn't introduce any impact on 5GS.
