Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TR 23.700-36  Word version:  18.1.0

Top   Top   Up   Prev   Next
0…   4…   5…   5.3.3…   6…   6.2…   6.2.1.2…   6.3…   6.4…   6.5…   6.6…   6.7…   6.8…   6.9…   6.10…   7…   8…   9…

 

6.2  Solution #1: Support for application performance analyticsp. 17

6.2.1  Solution descriptionp. 17

This solution addresses Key Issue #1.
This solution introduces application layer analytics to provide insight on the operation and performance of an application (VAL server or EAS, application session) and in particular statistics or prediction on parameters related to e.g. VAL server number of connections for a given time and area, VAL server rate of connection requests, connection probability failure rates, RTT and deviations for a VAL server or VAL UE session, packet loss rates etc.
In this solution, two procedures are described in more detail:
  • one procedure for VAL server related analytics where an example in provided for VAL server performance,
  • one procedure for VAL session/UE related analytics.
Up

6.2.1.1  Procedure on VAL server performance analyticsp. 17

Figure 6.2.1.1-1 illustrates the procedure where the VAL server performance analytics are performed based on data collected from the ongoing VAL sessions as well as data from the DN (VAL server, DN database or networking stack at DN).
Pre-conditions:
  1. ADAEC is connected to ADAES
Copy of original 3GPP image for 3GPP TS 23.700-36, Fig. 6.2.1.1-1: ADAES support for VAL server performance analytics
Up
Step 1.
The consumer of the ADAES analytics service sends a subscription request to ADAES and provides the analytics event ID e.g. "VAL perf prediction", the target VAL server ID, the time validity and area of the request, the required confidence level, whether offline and/or online analytics are needed etc.
Step 2.
The ADAES sends a subscription response as an ACK to the consumer.
Step 3.
The ADAES maps the analytics event ID to a list of data collection event identifiers, and optionally a list of data producer IDs. Such mapping may be preconfigured by OAM or may be configured at ADAES based on the analytics event type / vertical type.
Step 4.
The ADAES sends a subscription request to the Data Producers (at the DN side or UE side) with the respective Data Collection Event ID and the requirement for data collection. This message includes the Data Collection event ID and/or the analytics event ID, the target VAL server ID, the ADAES ID, the time validity and area of interest, the required confidence level etc.
Step 5.
The Data Producer(s) sends a subscription response as an ACK to the ADAES.
Step 6.
The ADAES based on subscription, may receive offline stats/data on the VAL server performance based on the analytics/data collection event ID. Such offline data can be average/peak throughput, average/maximum e2e delay, jitter, av. PER, availability, VAL server load, number of failed transactions, and can be for a given area and time of the day (based on the time/area of the request). The edge / cloud DB depending on the deployment can be also part of ADRF (for MNO-deployed ADAES).
A session starts between the VAL server #1 and a UE (this could happen for more than one UEs)
Step 7.
The Data Producer starts collecting/listening to real-time networking or application data (from networking start at DN or VAL server itself). Such data can be the RTT, the PER, throughput etc.
Step 8a.
The Data Producer sends the real-time data to the ADAES, where the data correspond to the data collection ID or the analytics event ID for which the ADAES subscribed.
Step 8b.
The ADAES may receive also data (periodically or if a threshold is reached based on configuration) from the application of the UE within the ongoing session (via ADAEC). Such data can be about the RTT, average/peak throughput, jitter, QoE measurements (MOS, stalling events, stalling ratios, etc), QoS profile load, VAL server load, etc.
Step 9.
When the VAL UE session with VAL server finishes, the ADAEC notifies the ADAEC of the completion of the reporting.
Step 10.
The ADAES abstracts or correlates the data based on the analytics event and the data collection configuration. Such correlation can be filtering of data for the same metrics but with different granularities or be combining/aggregating the data of segments of the end-to-end path (end to end is between VAL client and server). The outcome is an abstracted/correlated/filtered set of data.
Step 11.
The ADAES derives application layer analytics on VAL server #1 performance, 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.
Step 12.
The ADAES sends the analytics to the consumer, where these analytics include the VAL server 1 predicted or statistic performance for a given area and time horizon, including also the confidence level, whether offline/online analytics were used.
Up

Up   Top   ToC