EP4674162A1

EP4674162A1 - Uplink signal power in analytics

Info

Publication number: EP4674162A1
Application number: EP23711149.7A
Authority: EP
Inventors: Attila BÁDER; András CSÁSZÁR
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2023-02-27
Filing date: 2023-02-27
Publication date: 2026-01-07
Also published as: WO2024180365A1

Abstract

This disclosure provides techniques for estimating downlink (DL) service quality. A network node (210), for example, obtains (192) one or more transport parameters that indicate the transport characteristics of a core network (CN) (12), as well as one or more radio uplink (UL) parameters that indicate the characteristics of an UL between a node(18) in a Radio Access Network (RAN) and a user device (16), such as a User Equipment (UE). Responsive to obtaining these parameters, the network node correlates (198) the transport parameters with the radio UL parameters and estimates (200) a DL service quality based on those correlated parameters.

Description

UPLINK SIGNAL POWER IN ANALYTICS

TECHNICAL FIELD

This application is generally related to network analytics and network management, and more particularly to techniques for estimating the downlink (DL) service quality for traffic types that use unreliable transport protocols.

BACKGROUND

New generation 5G mobile networks will soon be required to support new types of services and use cases. For example, 5G New Radio (NR), developed by the Third Generation Partnership Project (3GPP), is designed to satisfy the demands of emerging Ultra-Reliable Low- Latency Communication (URLLC) services. Such services include, but are not limited to, 360- degree video streaming, cloud gaming, immersive Augmented Reality (AR) and/or Virtual Reality (VR) applications, and remote control and industrial automation.

As opposed to legacy Mobile Broadband (MBB) traffic, which typically needs high- bandwidth with only best-effort latency, URLLC and similar services have stringent requirements on latency and reliability due to their “real-time” nature. By way of example only, adaptive video streaming is typically tolerant to network Quality of Service (QoS) changes because client-side buffers can mask delay fluctuations originating from either the underlying transport mechanisms or the application itself. In contrast, new URLLC traffic types require low-latency communication data delivery. This means ensuring specific latency bounds on the order of 10ms, and a packet loss of only 0.1 - 0.01 percent, with a high percentage of probability (e.g., 99.999 percent probability). Monitoring the actual performance and estimating and ensuring the service quality in 5G networks, therefore, is essential.

SUMMARY

Embodiments of the present disclosure provide a per-flow analytics system and method that uses uplink (UL) radio transmitting power in addition to downlink (DL) transport characteristics and DL radio environment measurements to estimate the end-to-end (E2E) service quality of traffic types that use unreliable transport protocols.

A first aspect of the present disclosure provides a method, implemented at a network node in a communication network, for estimating downlink (DL) service quality. In this aspect, the network node obtains one or more transport parameters indicating transport characteristics of a core network (CN), as well as one or more radio uplink (UL) parameters indicating characteristics of an UL between a base station and a user device. Then, responsive to obtaining the one or more transport parameters and the one or more radio UL parameters, the network node correlates the one or more transport parameters with the one or more radio UL parameters and estimates a DL service quality based on the correlated one or more transport parameters and the one or more radio UL parameters. A second aspect provides a network node comprising processing circuitry and memory circuitry. The memory circuitry is configured to store instructions executable by the processing circuitry whereby the network node is configured to obtain one or more transport parameters indicating transport characteristics of a core network (CN), as well as one or more radio uplink (UL) parameters indicating characteristics of an UL between a base station and a user device. Responsive to obtaining the one or more transport parameters and the one or more radio UL parameters, the network node is further configured to correlate the one or more transport parameters with the one or more radio UL parameters and estimate a DL service quality based on the correlated one or more transport parameters and the one or more radio UL parameters.

A third aspect of the present disclosure provides a network node for estimating downlink (DL) service quality. In this aspect, the network node is configured to obtain one or more transport parameters indicating transport characteristics of a core network (CN), and one or more radio uplink (UL) parameters indicating characteristics of an UL between a base station and a user device. Then, responsive to obtaining the one or more transport parameters and the one or more radio UL parameters, the network node is configured to correlate the one or more transport parameters with the one or more radio UL parameters and estimate a DL service quality based on the correlated one or more transport parameters and the one or more radio UL parameters.

A fourth aspect of the present disclosure comprises a computer program for a network node in a wireless communication system. The computer program comprises executable instructions that, when executed by processing circuitry in the network node, causes the network node to perform the method according to the first aspect.

A fifth aspect of the present disclosure provides a carrier containing a computer program according to the fourth aspect. In this aspect, the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

A sixth aspect of the present disclosure provides a non-transitory computer-readable storage medium comprising a computer program stored therein. The computer program comprises executable instructions that, when executed by processing circuitry in a network node, causes the network node to perform the method according to the first aspect.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a functional block diagram illustrating an exemplary architecture for a per-flow analytics system configured according to one embodiment of the present disclosure.

Figure 2 is a functional block diagram illustrating a ML model for estimating service quality according to one embodiment of the present disclosure.

Figure 3 is a functional block diagram for training a ML model to estimate service quality, and for using the ML model to estimate service quality, according to one embodiment of the present disclosure. Figures 4A-4C are graphs representing example measurements for Web Real-Time Communication (RTC) video traffic in which service quality does not correlate to Reference Signal Received Power (RSRP).

Figures 5A-5C are graphs representing example measurements for Web Real-Time Communication (RTC) video traffic in which service quality does not correlate to Reference Signal Received Power (RSRP), but does correlate to UL transmit power according to one embodiment of the present disclosure.

Figure 6A is a graph indicating the accuracy of an ML model configured to estimate service quality according to the present disclosure compared to the accuracy of a conventional ML model.

Figure 6B is a graph indicating the probability of detecting a service quality issue using an ML model configured according to the present disclosure compared to the probability of detecting a service quality issue using a conventional ML model.

Figure 6C is a graph indicating the probability of obtaining a false positive indicating a service quality issue using an ML model configured according to the present disclosure compared to the probability of obtaining a false positive indicating a service quality issue using a conventional ML model.

Figure 7 is a flow diagram illustrating a method for using UL radio transmit power measurements in addition to DL transport characteristics and DL radio environment measurements to estimate the service quality of traffic types that use unreliable transport protocols according to one embodiment of the present disclosure.

Figure 8 is a functional block diagram illustrating a network node configured to estimate the service quality of traffic types communicated via unreliable transport protocols using UL radio transmit power measurements in addition to DL transport characteristics and DL radio environment measurements, according to one embodiment of the present disclosure.

Figure 9 shows an example of a communication system in accordance with some embodiments.

Figure 10 is a block diagram of a host in accordance with various aspects described herein.

Figure 11 shows a communication diagram of a host communicating via a network node with a UE over a partially wireless connection in accordance with some embodiments.

DETAILED DESCRIPTION

Network analytics and automatic features based on network analytics are now fundamental functions in 5G networks. For example, consider a Network Data Analytics Function (NWDAF) defined by the 3GPP. As is known in the art, the NWDAF is in the core network. Its primary goal is to ensure service quality and improve customer experiences. To achieve its goals, the NWDAF can perform automatic network error correction. However, in addition to this function, the NWDAF can also enable predictive and proactive network operations.

The NWDAF primarily collects data from other 5G core network functions. Based on this data, the NWDAF can perform network analytics as well as provide insights with closed loop automation to authorized data consumers. However, performing end-to-end (E2E) service quality monitoring and root cause analysis requires access to radio information.

The NWDAF is part of the architecture specified in the 3GPP document TS 23.501

V18.0.0 entitled “System architecture for the 5G System (5GS),” which is incorporated herein by reference in its entirety. The NWDAF uses the mechanisms and interfaces specified for 5GC in TS 23.501 , as well as information and services from an Operation and Management System. Additionally, the 3GPP document TS 23.288 V17.6.0 entitled “Architecture Enhancements for 5G System (5GS) to Support Network Data Analytics Services,” which is incorporated herein by reference in its entirety, describes the 5GS architecture enhancements needed to support such network data analytics services. TS 23.288 particularly describes the User Equipment (UE) level network data, which is obtained from radio parameters via the OAM, relative to a Quality of Service (QoS) profile. These parameters include:

• Reference Signal Received Power (RSRP);

• Reference Signal Received Quality (RSRQ);

• Signal-to-noise and interference ratio (SINR);

• The mapping information between cell ID and frequency; and

• Cell Energy Saving State.

Currently, there are different types of analytics systems used to provide insight into the operation of a network. For example, per-session advanced analytics systems collect and correlate elementary network events from different network domains, such as the core network domain and the radio and transport network domains. Generally, per-session advanced analytics systems calculate user and session level end-to-end (E2E) service quality metrics (S- KPIs or QoE), as well as radio and network resource KPIs (R-KPIs), that characterize the radio environment or network operation at the user and session levels. These types of solutions are suitable for session-based troubleshooting and analysis of network issues.

Event-based analytics systems are also used in Service Operation Centers (SOC) to monitor the quality of a wide variety of services used at the network level, as well as to monitor the customer experience on an individual (i.e., per-subscriber) level. Such event-based tools are widely used in customer care and other business scenarios. However, event-based analytics systems require “real-time” collection and correlation of characteristic node and protocol events from different radio and core nodes, the probing of signaling interfaces (IFs), and the sampling of user-plane traffic. Additionally, besides the data collection and correlation functions, such systems require accessibility to an advanced database, a rule engine, and a big data analytics platform. As previously stated, URLLC traffic types have very strict E2E delay requirements. Therefore, with such services, there is typically no time for packet retransmission responsive to degradations occurring in the transport and/or radio environments along the data path. These traffic types usually rely on unreliable transport protocols, such as User Datagram Protocol (UDP)/Real-Time Transport Protocol (RTP) and UDP/ Quick UDP Internet Connections (QUIC). The user plane traffic can be probed in the core network. However, if degradation occurs in the downlink radio path, it may not be reflected in the user plane probe reports in situations where the transport path also experiences degradation. Moreover, neither the network operators nor the NWDAF have direct access to end user terminal data and measurements. Therefore, service quality cannot be measured and obtained at UE.

To have visibility on the degradations in the DL radio interface, service quality models include the DL radio metrics reported by UE. These measurements are used by the network for handover decisions, and therefore, are available at, and reported by, radio base stations. These measurements are correlated with service quality but do not indicate service quality issues in all cases. The accuracy of detecting service quality issues is especially low when RSRP is in the [- 100, -110] dBm range, where the signal power is weak but not considered to be completely bad. In this problematic signaling power range the RSRP, SINR radio metrics alone are not good indicators of potential service quality issues.

To address these and other issues, the present disclosure estimates E2E service quality and indicates potential service quality issues by considering radio UL transmit power measurements in addition to transport metrics and DL radio measurements in estimating the service quality. In more detail, UL transmit power is a more sensitive measure than DL RSRP. Therefore, using the UL transmit power together with DL RSRP can help bridge the uncertain indication range of RSRP measurements (-115 dBm to -100 dBm). Specifically, the UL transmit power value is added as an input parameter into a service quality machine learning model. The model is trained with various test scenarios, including those where the UL transmit power and/or measured UL and DL parameters indicate service quality issues and where DL signaling power did not indicate service quality issues. To support these functions, the present disclosure extends the 3GPP TS 23.288 standard so that UL transmit power metrics are provided by an operation and management system (OAM) to the NWDAF.

The present embodiments provide advantages and benefits that are not provided, or cannot be provided, by conventional analytics systems. For example, the present embodiments enable the estimation of the E2E service quality of a session based on per-flow monitoring of degradations in the E2E data path. To accomplish this, the present embodiments look at parameters in the external network or UL radio path, the core network, and the DL radio interface. Particularly, by monitoring transport characteristics in the core network, it is possible to detect service quality issues occurring in the external UL radio path and the core network. However, in cases of unreliable transport mechanisms, there is no feedback about degradations that may occur in the transport layer. Therefore, it is not possible to detect degradations in the DL radio path based on transport metrics. However, such detection is important for 5G penetration. One major function of 5G is its URLLC capabilities supporting low-latency communication for various applications, such as industrial control use-cases, Extended Reality (XR) gaming or similar challenging novel applications.

However, by adding UL radio environment measurements as input into the service quality models, it is possible to indicate issues in the DL radio path as well. Further, by extending the service quality model with UL transmit power measurements, indicating service quality issues, and the accuracy with which they are detected, are significantly increased. This is true especially beneficial in cases where a measured DL signaling power is in an operable range but is less than optimal. In such cases, conventional service quality ML models cannot recognize the degradation using transport parameters, and optionally, DL parameters as input.

Additionally, the present embodiments significantly decrease the probability of falsely or incorrectly indicating issue with DL service quality by measuring both the UL transmit power and the DL signaling power and using both as input into the service quality model. This is because UL signaling power measurements are faster and more sensitive than RSRP measurements, and therefore, can be used for the early detection of service quality issues and/or the detection of smaller service quality issues than with RSRP measurements alone.

Accordingly, embodiments of the present disclosure provide a per-flow analytics system and method that uses UL radio transmit power measurements in addition to the DL transport characteristics and DL radio environment measurements to estimate the E2E service quality of traffic types that use unreliable transport protocols. According to the present embodiments, transport metrics indicating the DL transport characteristics are captured at user plane functions in the core network and reported in transport protocol measurement reports to a network node, such as a Network Data Analytics Function (NWDAF) or a Management Data Analytics Function (MDAF). The DL radio environment measurements and the UL transmit power are measured by a User Equipment (UE) and reported to the network operation and management system (GAM).

Table 1 identifies some of the transport level parameters that can be obtained according to one embodiment of the present disclosure. It should be noted here that the service quality ML model may be trained with some or all of these parameters and/or other parameters, as needed or desired.

Table 1

Table 2 identifies some of the UL and DL radio parameters that can be obtained according to one embodiment of the present disclosure. These parameters, as well as other parameters not specifically listed herein, may also be used to train the service quality ML model, as needed or desired.

Table 2

The per-flow analytics system described herein can be implemented by the NWDAF or the MDAF. When implemented by the NWDAF, the DL radio environment measurements and UL transmit power measurements are sent to the NWDAF by the OAM. When implemented by the MDAF, the transport metrics indicating the DL transport characteristics are sent to MDAF. In either case, however, the per-flow analytics system of the present disclosure comprises a Machine Learning (ML) model (e.g., a service quality ML model) that estimates service quality metrics based on the transport metrics, the DL radio environment measurements, and the UL transmit power measurements. Additionally, in at least one embodiment, the ML model of the present disclosure is trained using scenarios that contain maximum values for UL transmit power, as well as transport metrics and DL radio environment measurements.

Turning now to the drawings, Figure 1 illustrates an architecture for a per-flow analytics system 10 configured according to one embodiment of the present disclosure. As seen in Figure 1 , system 10 comprises a core network (CN) 12 that communicatively interconnects one or more application servers (ASs) 14 to a user equipment (UE) 16 via one or more Radio Access Networks (RANs) 18. Although not explicitly shown, system 10 may also comprise one or more other public and/or private communication networks as is known in the art. Generally, AS 14 provides services to UE 16, such as URLLC services (e.g., 360-degree video streaming, cloud gaming, immersive AR/VR applications, and remote control and industrial automation services) having strict latency requirements. The traffic related to those services (i.e., the data and information communicated between AS 14 and UE 16) are processed by a variety of network nodes 20 and provided to the AS 14 and UE 16 via gateway nodes 22, 24, respectively.

According to the present embodiments, transport metrics representing the transport characteristics of the downlink data user flow are captured at collection point 28 (e.g., a user plane function) in CN 12. Depending on implementation, the captured transport metrics are then sent to a ML service quality model implemented in one of an NWDAF 28 and a MDAF 32 associated with an Operations, Administration, and Maintenance (OAM) system 30. The UE 16 also measures the DL radio environment and its UL transmit power and continually sends values representing those measurements to a base station in RAN 18. The base station then reports both the DL radio environment measurements and the UL transmit power measurements to the MDAF 32 or OAM 30 in one or more Radio Resource Control (RRC) measurement reports.

Particularly, when the ML service quality model is implemented in MDAF 32, the RAN 18 sends both the DL radio environment measurements and the UL transmit power measurements provided by UE 16 to the MDAF 32 in RRC measurement reports. Gateway node 24 sends the collected transport metrics to MDAF 32 in one or more transport protocol measurement reports. However, when the ML service quality model is implemented in NWDAF 28, gateway node 24 sends the transport protocol measurement reports to NWDAF 28, while OAM 30 sends the DL radio environment measurements and the UL transmit power measurements provided by UE 16 to NWDAF 28. Regardless of the implementation, however, the metrics and measurements collected at collection points 28 and 40 are provided on a per-flow basis, and thus, are correlated per user session record. The correlated data and information is then provided as input into the ML service quality model in order to estimate the service quality for a given flow.

Various techniques may be used to correlate the metrics and measurements collected at collection points 28 and 40. For example, the RRC measurement reports, which as stated above comprise both the DL radio environment measurements and the UL transmit power measurements, are included in node events (e.g., a Cell Traffic Recording (CTR) event). These events are periodically sent in real-time to the MDAF 32 or the NWDAF 28. Additionally, core network functions are also generate real-time events. By way of example, control functions such as the Access and Mobility Management Function (AMF) and the Session Management Function (SMF) send signaling information, while the User Plane Function (UPF) periodically sends transport measurements to the MDAF 32 or the NWDAF 28. According to one embodiment, these events are correlated in the MDAF 32 or NWDAF 28 based on the International Mobile Subscriber Identity (IMSI) and a time stamp as a correlation key. Figure 2 illustrates a ML service quality model 50 configured to estimate service quality according to one embodiment of the present disclosure. As will be seen in more detail below, model 50 is trained using reference quality data. Additionally, one or more transport parameters (e.g., representing the collected transport metrics), one or more radio DL parameters (e.g., representing Key Performance Indicators (KPIs) measured by UE 16 on the DL), and one or more radio UL parameters (e.g., representing the UL transmit power measured by UE 16) are input into model 50. Based on the provided parameters, and in accordance with the reference quality training data, model 50 outputs an estimated quality value.

The data used to train model 50 can be data obtained either from a lab, or from real network conditions. In the latter case, the end user service quality can be directly observed together with the transport metrics and the radio UL and DL parameters input to model 50. Thus, in accordance with the present embodiments, it is beneficial to train model 50 with additional measurement scenarios, where RSRP values are in the uncertainty range Regardless, however, model 50 should be configured according to the present embodiments to output an estimated QoE value indicating at least the following scenarios.

1 . No service quality degradation (for a variety of measured RSRP and PUSCH values);

2. Service quality degradations in transport (where no RSRP values and PUSCH indications are reported);

3. Service quality degradation in a radio link (where “bad” RSRP values and “good” PUSCH values are reported); and

4. Service quality degradation in a radio link (where “good” RSRP values and “bad” PUSCH values are reported).

Table 3 defines some exemplary “good,” “bad,” and “uncertain” ranges within which the UL and DL values may fall according to the present disclosure. Note that for DL values, a higher received signal typically correlates to better signal quality. Additionally, the UL transmit power is automatically adjusted. Therefore, where the UL values are concerned, the transmit power of the UE is inversely proportional to the quality of the connection (i.e. , the higher power the UE has to transmit, the worse the connection is).

Table 3

Figure 3 is a functional block diagram for training a ML model to estimate service quality, and for using the ML model, once trained, to estimate service quality according to one embodiment of the present disclosure. As seen in Figure 3, model 50 may be an E2E service quality model trained using radio parameters 60 and subjective QoE measurement parameters

68. Parameters 60 include both UL and DL radio training parameters 62 as well as transport training parameters 64 representing the transport characteristics of CN 12. As stated above, these parameters may be obtained from experimental lab data and/or from actual network conditions. In operation, actual measured parameters 70 (i.e., measured UL and DL radio parameters 92 and actual transport parameters 74) are input into model 50. Then, based on the values of the actual parameters 70, model 50 outputs a DL QoE value 90.

In another embodiment, model 50 is a Web Real-Time Communication (WebRTC) ML model. In this embodiment, model 50 is trained using test radio parameters 60 (including both UL and DL radio training parameters 62, 64) and WebRTC parameter measurements 66. In operation, model 50 takes, as input, the actual measured parameters 70 and outputs a set of W3C WebRTC parameters 80 (e.g., packet parameters, frame parameters, and buffer

Table 4

Figures 4A-4C are graphs 100, 110, 120 representing example measurements for WebRTC video traffic in which service quality does not correlate to Reference Signal Received Power (RSRP). As seen in these graphs, there are 4 measurement periods numbered 1 ..4. In this example, the UE is shielded starting from the second measurement period 2 (graph 100 in Figure 4A), and thus, the RSRP characterizing the DL signal strength drops to about -120 dBm. However, as seen in graph 110 of Figure 4B, the UL transmit power adaptively increases towards its maximum value. In these scenarios, both the RSRP and the UL radio parameters strongly correlate with the DL burst parameters (graph 120 of Figure 4C), where the fluctuation and increased value indicate service quality issues. However, in situations where the transport network is unreliable, these burst issues are not visible if degradation occurs after the transport collection point 28 (e.g., in the DL radio interface). Therefore, it is not possible to detect degradation based solely on the collection of transport metrics.

Figures 5A-5C are graphs 130, 140, 150 representing example measurements for WebRTC video traffic in which service quality does not correlate to Reference Signal Received Power (RSRP) but does correlate to UL transmit power according to one embodiment of the present disclosure. In this example, the RSRP is improved as a consequence of a handover (HO) (graph 130 of Figure 5A). However, the service quality did not improve, as indicated by the burst length (graph 150 of Figure 5C). However, the UL transmit power, especially PUSCH (graph 140 of Figure 5B), adaptively increases towards its maximum value of -23 dBm and still indicates the service quality issue. Thus, as can be seen from these graphs, adding the UL transmit power measured by the UE as input into the ML model 50 enables the detection of service quality issues on the DL where RSRP parameters alone do not.

To show the benefit of using UL transmit power in service quality ML models such as model 50, a simple model calculation was performed to obtain the expected accuracy of ML model 50. As defined herein, “expected accuracy” means the maximum accuracy, which can be achieved by an ML model (assuming that it is properly trained) based on the available input data.

Figure 6A is a graph 160 indicating the expected accuracy of an ML model 50 configured according to the present embodiments. As can be seen in Figure 6A, the expected accuracy of ML model 50 was estimated in cases where the UL PUSCH was used (i.e. , the solid line) and was not used (i.e., the dashed line) as an input parameter when a coverage issue occurs in the DL radio path. When only RSRP is used as input parameter, the accuracy of model 50 is relatively low, especially in the uncertainty range of -115 dBm to -100 dBm (i.e., where there is a weak signal but connectivity is nevertheless maintained). Adding the UL PUSCH parameter as input into model 50, however, significantly improves the accuracy of model 50 at any signal strength, but especially in the uncertainty range of -115 dBm to -100 dBm.

In some embodiments, the output of model 50 is a binary function indicating whether a service quality issue occurred (i.e., incident detection). Figure 6B is a graph 170 indicating the probability of detecting a service quality issue using an ML model 50 configured according to the present disclosure.

As seen in Figure 6B, the dotted line (i.e., labeled ’’ISSUE”) indicates the probability of having service quality issue due to low signal strength (i.e., low RSRP). The dashed line (i.e., labeled “RSRP”) indicates the probability of detecting a service quality issue based on a given RSRP value by model 50. The solid line (i.e., labeled “RSRP AND PUSCH) indicates the probability of detecting service quality issues when the UL PUSCH parameters are input into model 50 along with the RSRP values. Thus, as can be seen in Figure 6B, the detection of service quality issues on the DL also significantly improves when UL transmit power parameters are added as input into model 50.

Figure 6C is a graph 180 indicating the probability of obtaining a false positive indicating a service quality issue using ML model 50 configured according to the present disclosure. Particularly, as can be seen from Figure 6C, using both RSRP and UL PUSCH for detecting a radio issue (i.e., solid line) considerably decreases the probability of obtaining a false positive indicating a service quality issue on the DL when compared to using only RSRP values (i.e., dashed line).

As previously stated, the current standard related to estimating the E2E service quality in NWDAF 26 is being extended by adding various radio measurement parameters as input into a service quality ML model and by specifying an interface for obtaining the parameters from MDAF 32 in OAM 30. As an example, these parameters include:

• Reference Signal Received Power (RSRP);

• Reference Signal Received Quality (RSRQ);

• Signal-to-noise and interference ratio (SINR);

• The mapping information between cell ID and frequency; and

• Cell Energy Saving State.

The present disclosure extends this list of parameters by also adding the radio UL transmit power measurements PUSCH and PUCCH. Other parameters not specifically identified here may also be added as needed or desired.

The embodiments described herein can be applied in closed loop NWDAF use cases, in which the primary trigger is a detected degradation in the service quality (QoE). The applicability of the present embodiments in a closed loop function is determined by the latency of data. The availability of radio measurements in NWDAF is in the order of 1s, which makes it possible to target the near-real-time operation, e.g., shifting affected traffic to a higher priority 5QI class or shaping lower priority traffic in cases where radio issues are detected. Of course, the present embodiments also support non-real-time use cases. Such non-real-time embodiments include, for example, antenna tilt optimization, adjusting radio to daily traffic profiles, and handover (neighbor cell relation) optimization.

The service ML model decision is relatively fast. Therefore, latency is limited by the availability of the radio data. Since PUSCH measurements are faster than DL radio environment measurements, the period of closed loop action could be decreased using only PUSCH as input to the service quality ML model. However, in such cases, the accuracy of the service quality ML model is lower.

Compared to the strict delay requirements of URLLC traffic, which is in the order of 10ms, it is not possible, due to the latency of the possible closed loop actions, to detect and fix a detected service quality issue without any degradation if the primary trigger is the QoE degradation. However, with the present embodiments, it is possible to avoid abnormal session termination and recover the service quality in a relatively short time. More particularly, the present embodiments make it possible to perform one or more corrective actions to avoid future service degradation in the same location.

Further, the present disclosure facilitates taking preventive action to minimize or eliminate the service degradation if the radio measurements PUSCH and RSRP are used as primary trigger of the action. The services usually have usually some tolerances to network degradation (due to forward error correction, jitter buffer, etc.). In cases where the degradation is within the tolerance limit, issues can be corrected without affecting the end user service quality. Figure 7 is a flow diagram illustrating a method 190 for using UL radio transmit power measurements in addition to transport characteristics and DL radio environment measurements to estimate the service quality of traffic types that use unreliable transport protocols according to one embodiment of the present disclosure. As seen in method 190, a network node (e.g., either the NWDAF 26 or the MDAF 32) obtains one or more transport parameters indicating the transport characteristics of CN 12 (box 192). The network node also obtains one or more radio UL parameters indicating the characteristics of an UL between a base station in RAN 18 and user device 16 (box 194), and one or more radio DL parameters indicating the characteristics of the DL between the base station and the user device (box 196). Responsive to obtaining the parameters, the network node correlates the one or more transport parameters with the one or more radio UL parameters (box 198) and estimates the DL service quality based on the correlated one or more transport parameters and the one or more radio UL parameters (box 200).

In one embodiment, the one or more radio DL parameters are measured by the user device 16. In cases where the network node obtains the one or more DL parameters, the network node correlates the one or more DL parameters with the one or more transport parameters and the one or more radio UL parameters, and then estimates the DL service quality based on the correlated DL parameters, transport parameters, and the radio UL parameters.

In one embodiment, the one or more radio UL parameters comprise a UL transmit power of the user device measured by the user device.

In another embodiment, the one or more radio UL parameters comprise a UL transmit power of the user device measured by the base station.

In at least one embodiment of the present disclosure, however, the one or more radio UL parameters comprise one or more Key Performance indicators (KPIs).

In one embodiment, the one or more transport parameters are obtained from transport protocol measurement reports received from one or more user plane functions in the CN.

In one embodiment, the one or more transport parameters, the one or more radio UL parameters, and the one or more radio DL parameters are correlated on a per-user session record basis.

In one embodiment, the one or more transport parameters, the one or more radio UL parameters, and the one or more radio DL parameters are input into a DL service quality machine learning (ML) model.

In one embodiment, the DL service quality is estimated in real time. As defined herein, “real time” means that the DL service quality ML model generates the value indicating the estimated DL service quality less than 1 second after the one or more transport parameters and the one or more radio UL parameters are input into the DL service quality ML model. In another embodiment, the DL service quality is estimated in “near real time.” As defined herein, “near real time” means that the DL service quality ML model generates the value indicating the estimated DL service quality during a time period of 1 second to 10 seconds.

In one embodiment, the DL service quality ML model is an End-to-End (E2E) service quality ML model.

In one embodiment, the DL service quality ML model is a Web Real-Time Communication (RTC) service quality ML model.

In such embodiments, the WebRTC ML model generates a set of parameters comprising one or more packet parameters, one or more frame parameters, and one or more buffer parameters.

In one embodiment, the DL service quality ML model generates a value indicating the estimated DL service quality.

In one embodiment, the DL service quality is estimated on a per-flow basis.

In one embodiment, the network node is one of a Network Data Analytics Function (NWDAF) and a Management Data Analytics Function (MDAF).

In embodiments where the network node is a NWDAF, the one or more radio UL parameters and the one or more radio DL parameters are obtained from an Operations, Administration, and Maintenance (OAM) entity.

In embodiments where the network node is a MDAF, the one or more radio DL parameters and the one or more radio UL parameters are obtained from Radio Resource Control (RRC) measurement reports sent by the user device.

In one embodiment, the one or more radio UL parameters comprise one or more Reference Signal Received Power (RSRP) values.

In one embodiment, the one or more radio UL parameters comprise one or more Physical Uplink Shared Channel (PUSCH) values.

In one embodiment, the one or more radio UL parameters comprise one or more Physical Uplink Control Channel (PUCCH) values.

In one embodiment, the DL service quality is estimated for a Ultra-Reliable Low Latency Communications (URLLC) traffic flow.

In one embodiment, the network node corrects a service quality issue in a closed loop process based on the estimated DL service quality.

In one embodiment, the network node monitors the estimated DL service quality against one or more predetermined target service qualities.

In one embodiment, the service quality ML model is trained using one or more training scenarios in which no service quality degradation in a transport layer occurs for a plurality of different DL parameters and UL parameters, one or more training scenarios in which there is service quality degradation in the transport layer, where no DL parameters and no UL parameters are reported, one or more training scenarios in which there is service quality degradation in a radio link, where values for the reported DL parameters are lower than values in an uncertainty range, and one or more training scenarios in which there is service quality degradation in a radio link, where values for the reported DL parameters are higher than values in an uncertainty range.

In one embodiment, the service quality ML model is trained using a measurement scenario where the DL parameters are in an uncertainty range.

An apparatus can perform any of the methods herein described by implementing any functional means, modules, units, or circuitry. In one embodiment, for example, the apparatuses comprise respective circuits or circuitry configured to perform the steps shown in the method figures. The circuits or circuitry in this regard may comprise circuits dedicated to performing certain functional processing and/or one or more microprocessors in conjunction with memory. For instance, the circuitry may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory may include program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein, in several embodiments. In embodiments that employ memory, the memory stores program code that, when executed by the one or more processors, carries out the techniques described herein.

Figure 8 illustrates some of the main functional components of a network node 210 configured according to one embodiment of the present disclosure. As previously described, network node 210 may be a NWDAF 26 or a MDAF 32, as previously described, but is not limited to those nodes. Other nodes in network 12 and/or OAM 30 may be configured to operate according to the embodiments described herein. As seen in Figure 8, network node 210 comprises communication circuitry 212, processing circuitry 216, and memory 218.

The communication circuitry 212 comprises network interface circuitry (NIC) 214. In one or more embodiments, the NIC 214 comprises network interface circuitry that configures network node 210 for communication with one or more other nodes, core network nodes, and or external systems, such as OAM 30, for example. The network interface circuitry may, for example comprise an Ethernet interface, optical network interface, or a wireless interface.

The processing circuitry 216 comprises one or more microprocessors, hardware, firmware, or a combination thereof that control the overall operation of the network node 210. The processing circuitry 216 can be configured by software to perform one or more of the methods herein described including method 190 seen in Figure 7.

Memory 218 comprises both volatile and non-volatile memory for storing computer program code and data needed by the processing circuitry 216 for operation. Memory 218 may comprise any tangible, non-transitory computer-readable storage medium for storing data including electronic, magnetic, optical, electromagnetic, or semiconductor data storage. Memory 218 stores a computer program 220 comprising executable instructions that configure the processing circuit 216 in the network node 210 to perform one or more of the methods herein described including method 190 described in Figure 7. A computer program 220 in this regard may comprise one or more code modules corresponding to the means or units described above. In general, computer program instructions and configuration information are stored in a non-volatile memory, such as a ROM, erasable programmable read only memory (EPROM) or flash memory. Temporary data generated during operation may be stored in a volatile memory, such as a random access memory (RAM). In some embodiments, computer program 220 for configuring the processing circuitry 216 as herein described may be stored in a removable memory, such as a portable compact disc, portable digital video disc, or other removable media. The computer program 220 may also be embodied in a carrier such as an electronic signal, optical signal, radio signal, or computer readable storage medium.

Those skilled in the art will also appreciate that embodiments herein further include corresponding computer programs. A computer program comprises instructions which, when executed on at least one processor of an apparatus, cause the apparatus to carry out any of the respective processing described above. A computer program in this regard may comprise one or more code modules corresponding to the means or units described above.

Embodiments of the present disclosure further include a carrier containing such a computer program 220. This carrier may comprise one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

In this regard, embodiments herein also include a computer program product stored on a non-transitory computer readable (storage or recording) medium and comprising instructions that, when executed by a processor of an apparatus, cause the apparatus to perform as described above.

Embodiments further include a computer program product comprising program code portions for performing the steps of any of the embodiments herein when the computer program product is executed by network node 210. This computer program product may be stored on a computer readable recording medium.

Additional embodiments will now be described. At least some of these embodiments may be described as applicable in certain contexts and/or wireless network types for illustrative purposes, but the embodiments are similarly applicable in other contexts and/or wireless network types not explicitly described.

Figure 9 shows an example of a communication system 1100 in accordance with some embodiments. In the example, the communication system 1100 includes a telecommunication network 1102 that includes an access network 1104, such as a radio access network (RAN), and a core network 1106, which includes one or more core network nodes 1108. The access network 1104 includes one or more access network nodes, such as network nodes 1110a and 1110b (one or more of which may be generally referred to as network nodes 1110), or any other similar 3rd Generation Partnership Project (3GPP) access node or non-3GPP access point. The network nodes 1110 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 1112a, 1112b, 1112c, and 1112d (one or more of which may be generally referred to as UEs 1112) to the core network 1106 over one or more wireless connections.

Example wireless communications over a wireless connection include transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 1100 may include any number of wired or wireless networks, network nodes, UEs, and/or any other components or systems that may facilitate or participate in the communication of data and/or signals whether via wired or wireless connections. The communication system 1100 may include and/or interface with any type of communication, telecommunication, data, cellular, radio network, and/or other similar type of system.

The UEs 1112 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and/or operable to communicate wirelessly with the network nodes 1110 and other communication devices. Similarly, the network nodes 1110 are arranged, capable, configured, and/or operable to communicate directly or indirectly with the UEs 1112 and/or with other network nodes or equipment in the telecommunication network 1102 to enable and/or provide network access, such as wireless network access, and/or to perform other functions, such as administration in the telecommunication network 1102.

In the depicted example, the core network 1106 connects the network nodes 1110 to one or more hosts, such as host 1116. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 1106 includes one more core network nodes (e.g., core network node 1108) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and/or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 1108. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and/or a User Plane Function (UPF).

The host 1116 may be under the ownership or control of a service provider other than an operator or provider of the access network 1104 and/or the telecommunication network 1102, and may be operated by the service provider or on behalf of the service provider. The host 1116 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio/video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

As a whole, the communication system 1100 of Figure 9 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and/or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and/or any low- power wide-area network (LPWAN) standards such as LoRa and Sigfox.

In some examples, the telecommunication network 1102 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 1102 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 1102. For example, the telecommunications network 1102 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and/or Massive Machine Type Communication (mMTC)ZMassive loT services to yet further UEs.

In some examples, the UEs 1112 are configured to transmit and/or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 1104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 1104. Additionally, a UE may be configured for operating in single- or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

In the example, the hub 1114 communicates with the access network 1104 to facilitate indirect communication between one or more UEs (e.g., UE 1112c and/or 1112d) and network nodes (e.g., network node 1110b). In some examples, the hub 1114 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 1114 may be a broadband router enabling access to the core network 1106 for the UEs. As another example, the hub 1114 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 1110, or by executable code, script, process, or other instructions in the hub 1114. As another example, the hub 1114 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 1114 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 1114 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 1114 then provides to the UE either directly, after performing local processing, and/or after adding additional local content. In still another example, the hub 1114 acts as a proxy server or orchestrator for the UEs, in particular, if one or more of the UEs are low energy loT devices.

The hub 1114 may have a constant/persistent or intermittent connection to the network node 1110b. The hub 1114 may also allow for a different communication scheme and/or schedule between the hub 1114 and UEs (e.g., UE 1112c and/or 1112d), and between the hub 1114 and the core network 1106. In other examples, the hub 1114 is connected to the core network 1106 and/or one or more UEs via a wired connection. Moreover, the hub 1114 may be configured to connect to an M2M service provider over the access network 1104 and/or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 1110 while still connected via the hub 1114 via a wired or wireless connection. In some embodiments, the hub 1114 may be a dedicated hub - that is, a hub whose primary function is to route communications to/from the UEs from/to the network node 1110b. In other embodiments, the hub 1114 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 1110b, but which is additionally capable of operating as a communication start and/or end point for certain data channels.

Figure 10 is a block diagram of a host 1400, which may be an embodiment of the host 1116 of Figure 9, in accordance with various aspects described herein. As used herein, the host 1400 may be or comprise various combinations hardware and/or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. The host 1400 may provide one or more services to one or more UEs.

The host 1400 includes processing circuitry 1402 that is operatively coupled via a bus 1404 to an input/output interface 1406, a network interface 1408, a power source 1410, and a memory 1412. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such that the descriptions thereof are generally applicable to the corresponding components of host 1400. The memory 1412 may include one or more computer programs including one or more host application programs 1414 and data 1416, which may include user data, e.g., data generated by a UE for the host 1400 or data generated by the host 1400 for a UE. Embodiments of the host 1400 may utilize only a subset or all of the components shown. The host application programs 1414 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application programs 1414 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, the host 1400 may select and/or indicate a different host for over-the-top services for a UE. The host application programs 1414 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

Figure 11 shows a communication diagram of a host 1602 communicating via a network node 1604 with a UE 1606 over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with various embodiments, of the UE (such as a UE 1112a of Figure 9), network node (such as network node 1110a of Figure 9), and host (such as host 1116 of Figure 9) discussed in the preceding paragraphs will now be described with reference to Figure 11 .

Like host 1400, embodiments of host 1602 include hardware, such as a communication interface, processing circuitry, and memory. The host 1602 also includes software, which is stored in or accessible by the host 1602 and executable by the processing circuitry. The software includes a host application that may be operable to provide a service to a remote user, such as the UE 1606 connecting via an over-the-top (OTT) connection 1650 extending between the UE 1606 and host 1602. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection 1650.

The network node 1604 includes hardware enabling it to communicate with the host 1602 and UE 1606. The connection 1660 may be direct or pass through a core network (like core network 1106 of Figure 9) and/or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network may be a backbone network or the Internet.

The UE 1606 includes hardware and software, which is stored in or accessible by UE 1606 and executable by the UE’s processing circuitry. The software includes a client application, such as a web browser or operator-specific “app” that may be operable to provide a service to a human or non-human user via UE 1606 with the support of the host 1602. In the host 1602, an executing host application may communicate with the executing client application via the OTT connection 1650 terminating at the UE 1606 and host 1602. In providing the service to the user, the UE's client application may receive request data from the host's host application and provide user data in response to the request data. The OTT connection 1650 may transfer both the request data and the user data. The UE's client application may interact with the user to generate the user data that it provides to the host application through the OTT connection 1650.

The OTT connection 1650 may extend via a connection 1660 between the host 1602 and the network node 1604 and via a wireless connection 1670 between the network node 1604 and the UE 1606 to provide the connection between the host 1602 and the UE 1606. The connection 1660 and wireless connection 1670, over which the OTT connection 1650 may be provided, have been drawn abstractly to illustrate the communication between the host 1602 and the UE 1606 via the network node 1604, without explicit reference to any intermediary devices and the precise routing of messages via these devices.

As an example of transmitting data via the OTT connection 1650, in step 1608, the host 1602 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE 1606. In other embodiments, the user data is associated with a UE 1606 that shares data with the host 1602 without explicit human interaction. In step 1610, the host 1602 initiates a transmission carrying the user data towards the UE 1606. The host 1602 may initiate the transmission responsive to a request transmitted by the UE 1606. The request may be caused by human interaction with the UE 1606 or by operation of the client application executing on the UE 1606. The transmission may pass via the network node 1604, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step 1612, the network node 1604 transmits to the UE 1606 the user data that was carried in the transmission that the host 1602 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 1614, the UE 1606 receives the user data carried in the transmission, which may be performed by a client application executed on the UE 1606 associated with the host application executed by the host 1602.

In some examples, the UE 1606 executes a client application which provides user data to the host 1602. The user data may be provided in reaction or response to the data received from the host 1602. Accordingly, in step 1616, the UE 1606 may provide user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via an input/output interface of the UE 1606. Regardless of the specific manner in which the user data was provided, the UE 1606 initiates, in step 1618, transmission of the user data towards the host 1602 via the network node 1604. In step 1620, in accordance with the teachings of the embodiments described throughout this disclosure, the network node 1604 receives user data from the UE 1606 and initiates transmission of the received user data towards the host 1602. In step 1622, the host 1602 receives the user data carried in the transmission initiated by the UE 1606.

One or more of the various embodiments improve the performance of OTT services provided to the UE 1606 using the OTT connection 1650, in which the wireless connection 1670 forms the last segment. More precisely, the teachings of these embodiments may enable the UE to adapt faster to radio conditions and realize higher data throughput. In an example scenario, factory status information may be collected and analyzed by the host 1602. As another example, the host 1602 may process audio and video data which may have been retrieved from a UE for use in creating maps. As another example, the host 1602 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, the host 1602 may store surveillance video uploaded by a UE. As another example, the host 1602 may store or control access to media content such as video, audio, VR or AR which it can broadcast, multicast or unicast to UEs. As other examples, the host 1602 may be used for energy pricing, remote control of non-time critical electrical load to balance power generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices), or any other function of collecting, retrieving, storing, analyzing and/or transmitting data.

In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 1650 between the host 1602 and UE 1606, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host 1602 and/or UE 1606. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection 1650 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 1650 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node 1604. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host 1602. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 1650 while monitoring propagation times, errors, etc.

The embodiments described herein may, of course, be carried out in other ways than those specifically set forth herein without departing from essential characteristics of the disclosure. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, and all changes coming within the meaning and equivalency range of the appended claims are intended to be embraced therein.

Claims

CLAIMS What is claimed is:

1 . A method (190) for estimating downlink (DL) service quality, the method implemented at a network node (210) in a communication network (10) and comprising: obtaining (192) one or more transport parameters indicating transport characteristics of a core network (CN) (12); obtaining (194) one or more radio uplink (UL) parameters indicating characteristics of an UL between a base station (18) and a user device (16); and responsive to obtaining the one or more transport parameters and the one or more radio UL parameters: correlating (198) the one or more transport parameters with the one or more radio UL parameters; and estimating (200) a DL service quality based on the correlated one or more transport parameters and the one or more radio UL parameters.

2. The method of claim 1 , further comprising obtaining (196) one or more radio DL parameters indicating characteristics of a DL between the base station and the user device, wherein the one or more radio DL parameters are measured by the user device.

3. The method of claim 2, wherein the one or more transport parameters and the one or more radio UL parameters are further correlated with the one or more radio DL parameters, and wherein the DL service quality is estimated based on the correlated one or more transport parameters, the one or more radio UL parameters, and the one or more radio DL parameters.

4. The method of any of claims 1-3, wherein the one or more radio UL parameters comprise a UL transmit power of the user device measured by the user device.

5. The method of any of claims 1-3 wherein the one or more radio UL parameters comprise a UL transmit power of the user device measured by the base station.

6. The method of any of claims 1-5 wherein the one or more radio UL parameters comprise one or more Key Performance indicators (KPIs).

7. The method of claim any of claims 1 -6, wherein the one or more transport parameters are obtained from transport protocol measurement reports received from one or more user plane functions in the CN.

8. The method of any of claims 1-7, wherein the one or more transport parameters, the one or more radio UL parameters, and the one or more radio DL parameters are correlated on a peruser session record basis.

9. The method of any of claims 1-8, wherein the one or more transport parameters, the one or more radio UL parameters, and the one or more radio DL parameters are input into a DL service quality machine learning (ML) model.

10. The method of claim 9 wherein the DL service quality is estimated in real time.

11 . The method of claim 9 wherein the DL service quality is estimated in near real time.

12. The method of claim 9, wherein the DL service quality ML model is an End-to-End (E2E) service quality ML model (50).

13. The method of claim 9, wherein the DL service quality ML model is a Web Real-Time Communication (RTC) service quality ML model.

14. The method of claim 13, wherein the WebRTC ML model generates a set of parameters (80) comprising: one or more packet parameters; one or more frame parameters; and one or more buffer parameters.

15. The method of any of claims 9-14, wherein the DL service quality ML model generates a value (90) indicating the estimated DL service quality.

16. The method of any of the preceding claims, wherein the DL service quality is estimated on a per-flow basis.

17. The method of any of the preceding claims, wherein the network node is one of a Network Data Analytics Function (NWDAF) (26) and a Management Data Analytics Function (MDAF) (32).

18. The method of claim 17, wherein when the network node is a NWDAF, the one or more radio UL parameters and the one or more radio DL parameters are obtained from an Operations, Administration, and Maintenance (OAM) entity (30).

19. The method of claim 17, wherein when the network node is a MDAF, the one or more radio DL parameters and the one or more radio UL parameters are obtained from Radio Resource Control (RRC) measurement reports sent by the user device.

20. The method of any of the preceding claims, wherein the one or more radio UL parameters comprise one or more Reference Signal Received Power (RSRP) values.

21 . The method of any of the preceding claims, wherein the one or more radio UL parameters comprise one or more Physical Uplink Shared Channel (PUSCH) values.

22. The method of any of the preceding claims, wherein the one or more radio UL parameters comprise one or more Physical Uplink Control Channel (PUCCH) values.

23. The method of any of the preceding claims, wherein the DL service quality is estimated for a Ultra-Reliable Low Latency Communications (URLLC) traffic flow.

24. The method of any of the preceding claims further comprising correcting a service quality issue in a closed loop process based on the estimated DL service quality.

25. The method of any of the preceding claims further comprising monitoring the estimated DL service quality against one or more predetermined target service qualities.

26. The method of any of the preceding claims wherein the service quality ML model is trained using: one or more training scenarios in which no service quality degradation in a transport layer occurs for a plurality of different DL parameters and UL parameters; one or more training scenarios in which there is service quality degradation in the transport layer, where no DL parameters and no UL parameters are reported; one or more training scenarios in which there is service quality degradation in a radio link, where values for the reported DL parameters are lower than values in an uncertainty range; and one or more training scenarios in which there is service quality degradation in a radio link, where values for the reported DL parameters are higher than values in an uncertainty range.

27. The method of any of the preceding claims wherein the service quality ML model is trained using a measurement scenario where the DL parameters are in an uncertainty range.

28. A network node (210) comprising: processing circuitry (216); and memory circuitry (218) configured to store instructions (220) executable by the processing circuitry whereby the network node is configured to: obtain (192) one or more transport parameters indicating transport characteristics of a core network (CN) (12); obtain (194) one or more radio uplink (UL) parameters indicating characteristics of an UL between a base station (18) and a user device (16); and responsive to obtaining the one or more transport parameters and the one or more radio UL parameters: correlate (198) the one or more transport parameters with the one or more radio UL parameters; and estimate (200) a DL service quality based on the correlated one or more transport parameters and the one or more radio UL parameters.

29. The network node of claim 28, wherein the network node is further configured to perform the method according to any one of claims 2-27.

30. A network node (210) for estimating downlink (DL) service quality, the network node being configured to: obtain (192) one or more transport parameters indicating transport characteristics of a core network (CN) (12); obtain (194) one or more radio uplink (UL) parameters indicating characteristics of an UL between a base station (18) and a user device (16); and responsive to obtaining the one or more transport parameters and the one or more radio UL parameters: correlate (198) the one or more transport parameters with the one or more radio UL parameters; and estimate (200) a DL service quality based on the correlated one or more transport parameters and the one or more radio UL parameters.

31 . The network node of claim 30, wherein the network node is further configured to perform the method according to any one of claims 2-27.

32. A computer program (220) comprising instructions that, when executed on processing circuitry (216) of a network node (210), cause the network node to perform the method according to any of claims 1-27.

33. A carrier containing the computer program of claim 32, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

34. A non-transitory computer-readable storage medium (218) comprising a computer program (220) stored thereon, the computer program comprising executable instructions that, when executed by processing circuitry (216) in a network node (210), causes the network node to perform the method of any one of claims 1-27.