WO2024224142A1 - Transport reporting by radio for analytics - Google Patents

Abstract

A User Equipment (UE) (20) measures transport metrics to provide to a network node (42, 52) in a communication network. The transport metrics, which may include the interarrival time (IAT) between received data packets and a burst length, for example, characterize different types of traffic. The transport metrics also correlate well with different transport and radio issues. Upon receipt, the network node uses the transport metrics measured by the UE 20 as input into one or more machine learning (ML) models. Based on the results of those ML models, the network node obtains an accurate end-to-end (e2e) service quality in real-time.

Description

TRANSPORT REPORTING BY RADIO FOR ANALYTICS

TECHNICAL FIELD

[0001] The present application relates generally to Customer Experience Management (CEM), and more particularly to User Equipment (UEs) configured to measure and report transport metrics to a network node for use in estimating an end-to-end service quality.

BACKGROUND

[0002] Customer Experience Management (CEM) systems, also referred to as Subscriber Analytics systems, are part of the Network Management domain. These systems are designed to monitor and analyze, at the subscriber level, the quality of services and the mobile networks over which the services are provided. Typically, CEM systems are used in Network Operation Centers (NOC), Service Operation Centers (SOC), and by Network Optimization Engineering (Network Performance Management). Recently, however, such systems are also used as part of the functionality provided by the Network Data Analytics Function (NWDAF) specified by the 3GPP for 5G networks.

SUMMARY

[0003] Embodiments of the present disclosure provide techniques for obtaining end-to- end (e2e) service quality (i.e., Quality of Experience (QoE) in real-time based on transport metrics measured by User Equipment (UE). The transport metrics, which may include the interarrival time (IAT) between packets and burst length, for example, characterize different types of traffic and correlate well with different transport and radio issues. Thus, the transport metrics can be input into one or more machine learning (ML) models to obtain the e2e service quality.

[0004] Accordingly, in a first aspect, the present disclosure provides a method for reporting transport metrics to a network node in a communications network. The method is implemented by a User Equipment (UE) (20) and comprises the UE measuring radio metrics and transport metrics for user traffic at the UE, generating a radio reporting message to comprise both the radio metrics and the transport metrics, and sending the radio reporting message to the network node in the communications network.

[0005] In a second aspect, the present disclosure provides a User Equipment (UE) configured to provide measurements to a network node in a communications network. The UE comprises processing circuitry and a memory. The memory contains instructions executable by the processing circuitry whereby the UE is configured to measure radio metrics and transport metrics for user traffic at the UE, generate a radio reporting message to comprise both the radio metrics and the transport metrics, and send the radio reporting message to the network node in the communications network. [0006] In a third aspect, the present disclosure provides a User Equipment (UE) configured to provide measurements to a network node in a communications network. In this aspect, the UE is configured to measure radio metrics and transport metrics for user traffic at the UE, generate a radio reporting message to comprise both the radio metrics and the transport metrics, and send the radio reporting message to the network node in the communications network.

[0007] In a fourth aspect, the present disclosure provides a computer program comprising instructions which, when executed on processing circuitry of a User Equipment (UE), causes the processing circuitry to measure radio metrics and transport metrics for user traffic at the UE, generate a radio reporting message to comprise both the radio metrics and the transport metrics, and send the radio reporting message to the network node in the communications network.

[0008] In a fifth aspect, the present disclosure provides a non-transitory computer readable medium comprising instructions stored thereon. When executed by processing circuity of a User Equipment (UE) that is configured to provide measurements to a network node in a communications network, the instructions cause the UE to measure radio metrics and transport metrics for user traffic at the UE, generate a radio reporting message to comprise both the radio metrics and the transport metrics, and send the radio reporting message to the network node in the communications network.

[0009] In a sixth aspect, the present disclosure provides a communication system comprising a User Equipment (UE) and a network analytics node. The UE in the system is configured to measure radio metrics and transport metrics for user traffic at the UE, generate a radio reporting message comprising both the radio metrics and the transport metrics, and send the radio reporting message to the communications network. The network analytics node is configured to input values representing the transport metrics in the radio reporting message into one or more machine learning (ML) models, and determine an end-to-end (e2e) service quality for the UE based on a result of the one or more ML model.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 is a functional block diagram illustrating some of the components of a communications system configured according to aspects of the present disclosure.

[0011] Figure 2 is a signaling diagram illustrating example messaging between devices in a communications network according to aspects of the present disclosure.

[0012] Figure 3 is a flow diagram illustrating a method for reporting transport metrics to a network node according to aspects of the present disclosure.

[0013] Figure 4 is a functional block diagram illustrating some exemplary components of a User Equipment (UE) configured according to one aspect of the present disclosure. [0014] Figure 5 shows an example of a communication system in accordance with some aspects of the present disclosure.

[0015] Figure 6 is a functional block diagram of a host in accordance with some aspects of the present disclosure.

[0016] Figure 7 shows a communication diagram of a host communicating via a network node with a UE over a partially wireless connection in accordance with some aspects of the present disclosure.

DETAILED DESCRIPTION

[0017] Embodiments of the present disclosure provide techniques for obtaining end-to- end (e2e) service quality (i.e., Quality of Experience (QoE) in real-time based on transport metrics measured by User Equipment (UE). The transport metrics, which may include the interarrival time (IAT) between packets and burst length, for example, characterize different types of traffic and correlate well with different transport and radio issues. Values for the mean of the transport metrics, which provides an average value for the transport metrics, and the standard deviation (stdev) of the transport metrics are reported, thereby enabling the detection of any changes in variation of the transport metric parameters. To accomplish this, the transport metrics measured by the UE are sent to the network for input into service quality Machine Learning (ML) models. The results of the ML models are then used for service quality monitoring and assurance, detection of service quality degradation, and for network optimization, by mobile network operators.

[0018] In more detail, the present disclosure extends the standard terminal radio measurement reports and/or radio application reports that are routinely sent to the network by the UE with the measured transport metrics. The present disclosure also configures the UE such that any additional load that is placed on the UEs, the radio nodes, and the analytics system to measure, report, and analyze the transport metrics is greatly reduced. In one embodiment, for example, the present disclosure configures the UE to measure the transport metrics for specific data flows or sessions. Such flows or sessions may be related, for example, to specific or critical service types (e.g., Ultra-Reliable Low Latency Communications (URLLC)), specific cells or coverage areas, one or more specific core network (CN) nodes, network functions (NF), one or more specific subscriber groups (e.g., VIPs), and the like. The transport metrics measured and reported by the UE are correlated with the radio environment measurements (i.e., also measured and provided by the UE) and can be derived in real-time from cell traces and/or UE trace events for standard network data analytics or management data analytics functions.

[0019] As is described in more detail below, not only do the UEs configured according to the present disclosure function differently from the UEs that report measurements in conventional systems, but they also effect the function and performance of the CEM systems executing in the network. Particularly, conventional CEM systems associated with the NOCs of mobile networks continuously monitor basic network Key Performance Indicators (KPIs). The KPIs are usually based on node and/or network events and counters and are aggregated in time. Often, the KPIs are also aggregated for the node and/or other dimensions. Such dimensions include, but are not limited to, those related to device type, service provider, and the like. However, although the KPIs collected by conventional systems can indicate node or network failures, they are generally not detailed enough for use in troubleshooting procedures. Nor are they suitable for use in identifying e2e user- perceived service quality issues. Thus, conventional troubleshooting often requires the investigation and analysis of more detailed network logs collected from different network nodes and domains.

[0020] Currently, there are a variety of analytics systems available. Some advanced analytics systems, such as Ericsson Expert Analytics (EEA), collect and correlate elementary network events, as well as e2e service quality metrics, and then compute userlevel e2e KPIs based on the available data. These types of systems are suitable for sessionbased troubleshooting and analysis of network issues.

[0021] Event-based subscriber analytics systems, such as the previously mentioned CEM systems, are also used in Service Operation centers. These systems are particularly used 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, per-subscriber basis. Tools such as these are widely used in customer care and other business scenarios.

[0022] Conventionally, event-based analytics systems frequently use real-time data collection and correlation of characteristic node and protocol events from different radio and core nodes. They also probe signaling interfaces (IFs) and sample user-plane traffic. However, these systems themselves require other complex systems to operate. For example, in addition to the features needed for the data collection and correlation functions, event-based analytics systems may also require one or more advanced databases, rule engines, and a big data analytics platform to operate properly.

[0023] Recently, 5G mobile networks have been introduced. Compared to previous network technologies, not only are 5G mobile networks expected to serve a larger variety of new service types, but they are also expected to serve a greater number of devices (e.g., UEs). The increased number of devices and services, however, will significantly increase the rate at which conventional network analytics systems will have to process incoming events. [0024] Currently, there are various techniques for obtaining and/or estimating the enduser QoE in a network. The least intrusive technique utilizes metrics reported by the network to calculate a rough QoE estimation. A more sophisticated technique, however, requires the installation of one or more User-Plane (UP) probes in the network. These UP probes are configured to monitor the subscriber traffic from which the KPI’s that are correlated to network metrics are derived. Although UP-probing techniques are more sophisticated than the network metric-based techniques, they provide a more precise QoE estimation than those provided based on network metrics.

[0025] However, service quality typically depends on multiple network, radio, traffic type, and load related parameters. Since the relationship between these parameters and the QoE is often complex and typically unknown, conventional systems use ML methods and models to estimate the QoE. Systems that use UP probing can measure basic packet level QoS parameters in the network; however, higher protocol layers are not available to probing because these layers are encrypted. Regardless, some conventional system.

[0026] 3GPP TS 38.331 V.16.7.0 (2021-12) for NR: Radio Resource Control (RRC) protocol specification, which is incorporated herein by reference in its entirety, provides one approach to estimating QoE based on metrics obtained and reported by the network. The approach provided in this document, however, relies on existing QoE reports provided by service providers. Many service providers currently have the capability to gather their own service metrics in a non-transparent manner, which are then provided to a 5G network using an Application Function (AF). The main advantage of this approach is that an end device can precisely measure the e2e QoE.

[0027] Additionally, conventionally configured UEs, when they are connected to the network and active (i.e., the UEs are in the RRC_CONNECTED mode) send radio measurement reports containing radio quality indicators like RSRP, RSRQ, SINR, RSCP or EcNO. The reports are sent based on the network configuration for the serving cell(s) and neighboring cells and are defined in various documents, such as 3GPP TS 38.331 V.16.7.0 (2021 -12), 3GPP TS 36.331 for LTE V.16.7.0 (2021-12), and in the paper authored by R Krzanowski entitled “Burst (of packets) and Burstiness,” July 10, 2006, each of which are incorporated herein by reference in their entirety.

[0028] The radio measurement reports are sent by the UE to a network-based radio node (e.g., an eNB or gNB) and contain information related to the serving cell(s) and neighboring cells. These reports are the main facilitators of mobility and are triggered by different event types when the reportType element of a ReportConfigNR Information Element (IE) is set to eventTriggered. Such event types include, but are not limited to, A1 event (i.e., serving cell becomes better than threshold), A2 event (i.e., serving cell becomes worse than threshold), B1 event (i.e., Inter RAT neighbor becomes better than threshold), etc. Additionally, periodic reporting is supported if the reportType is set to periodical.

[0029] To minimize the cost and time that is required to optimize and analyze a network, 3GPP standardization groups have defined a technique to minimize the amount of drive tests by collecting information from mobile users. The collected information can be associated with various kinds of measurements, handovers, or signaling failures. These so- called Minimization of Drive Tests (MDTs) are defined in 3GPP TS 37.320 V.16.7.0 (2021- 12) “Radio measurement collection for Minimization of Drive Tests (MDT); Overall description; Stage 2,” which is incorporated herein by reference in its entirety.

[0030] Two types of MDT are currently defined. These are immediate MDT, where the UEs in the ACTIVE state report measurements to a radio node, and logged MDT, where the UEs in the IDLE state log the measurements with timestamp and location.

[0031] Although the above approaches are useful, there are some that can be problematic. For example, most of the user traffic in mobile networks is currently encrypted. However, as explained above, encryption prevents the UP-probing functions in the network from accessing the content of the traffic, as well as from determining service quality based on observing the content. Further, service quality QoE in per-flow based analytics systems is estimated by service quality ML models based on the measured transport metrics that are available for encrypted traffic types.

[0032] Transport network probes and probing functions, however, are located in the core network (CN). In cases where an unreliable transport protocol is being used to communicate data, (e.g., the transport protocol associated with the new 5G URLLC, delay-critical, and/or real-time services), there is no time for packet retransmissions. Therefore, in most cases, there is no feedback provided in either the transport layer or the application layer regarding packets that are lost, delayed, etc., occurring in the downlink (DL) radio part. Accordingly, the ML models based on transport parameters measured in the CN do not currently indicate related service issues.

[0033] Estimating service quality degradations based on radio measurements is also less accurate than those that are estimated based on probe metrics. Particularly, in many cases, such estimations require training data collected for a variety of different radio conditions, which is difficult to obtain.

[0034] Another approach is to obtain direct QoE data from one or more applications via the Application Function (AF), which is a standardized component in 3GPP standards and has a direct interface to the backend services of applications. Since applications routinely measure QoE or poll end-users for perceived QoE, this data could be shared with network operators via the AF. However, in reality, such data is not widely available due to the large number of service providers. Further complicating matters is that each service provider and operator must agree to share the data via the AF. Another problem is that the data to be shared with others in real-time is often times not available. Further, not only does MDT not report transport metrics, but the unavailability of the data particularly limits its usability in conventional analytics systems. [0035] The present embodiments, however, address these and other issues associated with conventionally configured systems. More particularly, the present embodiments actively configure a UE to measure and report transport layer parameters for estimating the e2e service quality by ML models in analytics systems (e.g., those executing in the MDAF or NWDAF). Additionally, the present embodiments measure and report both the interarrival time (IAT) between two consecutively received packets, and the burst parameters together to cover different type of traffic.

[0036] Additionally, the present embodiments configure the UE to measure and report any alternative/additional parameters for burst and burstiness, as well as both the mean and stdev of these parameters. Particularly, the alternative/additional parameters are sent by the UE to the network in either a radio measurement report or a radio application report.

[0037] The embodiments described herein provide advantages and benefits that conventionally configured analytics systems cannot or do not provide. For example, the transport metrics measured at an end device, such as a UE, correlate well with service quality, network, and radio issues. Therefore, the transport metrics that are obtained according to the present disclosure are suitable for use as input to one or more service quality models. And, because they are measured at the end device (e.g., the UE), the transport metrics are necessarily suitable for estimating e2e service quality.

[0038] Moreover, embodiments of the present disclosure configure the UEs to measure the metrics for encrypted traffic. These metrics can be measured and reported to the network in real-time, which is required for many analytics use cases.

[0039] Another advantage over conventional analytics systems is that together, both the interarrival time (IAT) and the burst parameters accurately characterize the degradations associated with different traffic types. By way of example only, IAT is particularly useful for accurately characterizing the degradations of periodic user traffic, such as voice traffic, for example. The burst parameter, however, is reliable for accurately characterizing degradations due to variable bitrates and bursty traffic, like video. Moreover, these transport metrics are well defined. Therefore, the measurable objective parameters can be standard, as opposed to e.g., QoE measures. Additionally, the subjective part of the service quality analysis described herein can be handled by proprietary ML models, which are not covered in this disclosure.

[0040] Accordingly, the embodiments detailed in the present disclosure require only the extension of standard radio measurement reports. Specifically, a UE configured to function according to the present embodiments sends measurements in existing 3GPP standard reports. Therefore, the present embodiments do not define or implement new 3GPP standard messages or procedures. [0041] Turning now to the drawings, Figure 1 is a functional block diagram illustrating some of the components of a communications system 10 configured according to aspects of the present disclosure. As seen in Figure 1 , system 10 comprises a UE 20, a Radio Access Network (RAN) domain 30, a core domain 40, and an Operations Support System (OSS) domain 50. Those of ordinary skill in the art will readily appreciate that other domains and/or components may exist in system 10. However, because system 10 in Figure 1 is illustrative, these other domains and/or components are not expressly depicted therein.

[0042] The UE in Figure 1 includes one or more application programs 22 that generate the extended radio measurement reports 24 of the present disclosure. According to the present embodiments, the extended radio measurement reports 24 are comprised of two different components - a radio metrics component 26 containing the radio metrics measured by UE 20 and a transport metrics component 28 containing the transport metrics measured by UE 20. According to the present embodiments, the extended radio measurement reports 24 are transmitted by a radio measurement reporting function 29 at UE 20 to a network node 32 (e.g., a gNodeB) in the RAN domain 30. The extended radio measurement reports 24 may, for example, be transmitted by UE 20 periodically.

[0043] Upon receipt, network node 32 provides the transport metrics included in the extended radio measurement reports 24 to analytics functions. The analytics functions may be implemented in, for example, the NWDAF 42 in core domain 40 or the Management Data Analytics Function (MDAF) 52 in OSS domain 50. Other non-standard analytics functions may also be configured to process the data and information included in the extended radio measurement reports 24. In addition, the e2e ML models, which takes the reported transport metrics as input, are also implemented in the NWDAF 42 and/or the MDAF 52. In accordance with this disclosure, the present embodiments are advantageously configured to use the currently existing event correlation functions and e2e models implemented at the NWDAF 42 and the MDAF 52 to analyze the transport metrics included in the extended radio measurement reports 24.

[0044] In accordance with the present disclosure, the analytics functions correlate the transport metrics reported by UE 20 in the extended radio measurement reports 24 with one or more events reported by one or more of a User Plane Function (UPF) 44, a Session Management Function (SMF) 46, and an Application Management Function (AMF) 48. Regardless of the particular analytics function, however, each of the analytics functions illustrated in Figure 1 is configured to process the transport metrics contained in the transport metrics component 28 of the extended radio measurement reports 24 for purposes such as service quality monitoring and assurance, detection of service quality degradation, and network optimization. [0045] There are a variety of transport metrics that can be monitored by UE 20 and subsequently sent to network node 32 in RAN domain 30. For example, in one embodiment, UE 20 measures and reports, in addition to the radio metrics, the packet Interarrival Time (I AT) and a burst length. In the context of the present disclosure, the packet I AT is defined as the elapsed time between the arrival of two consecutive packets of a flow and, although not required, falls within an elapsed time range between 0-10 ms and has a resolution of about 0.1 ms.

[0046] Another transport metric that can be measured and reported by UE 20 is burst length. A burst, as defined herein, is a group of consecutive packets of a flow arriving at the UE 20 within a predetermined interarrival time (e.g.,1 ms). Therefore, the burst length metric that is measured and included in the transport metrics component 28 by UE 20 covers the elapsed time between the receipt of the first and last packets of a given burst received at UE 20. In one embodiment, the burst length may fall within a range of 0-100ms with a resolution of about 1 ms. In addition, a UE 20 configured according to the present embodiments may calculate one or both of the mean and stdev values for each of the measured packet IAT and burst length metrics and send those calculated values to network node 32 in the transport metrics component 28 of the extended radio measurement reports 24.

[0047] Although the packet IAT and burst length transport metrics are useful, those of ordinary skill in the art should readily appreciate that the present disclosure also provides other transport metrics that UE 20 can be configured to measure and send to network node 32. Such metrics include, but are not limited to, burst metrics and burstiness metrics.

[0048] The following Table 1 identifies some additional exemplary transport metrics that UE 20 may be configured to measure and report to the network according to the present embodiments.

Table 1 [0049] In addition to the packet IAT and burst-related measurements described above, as well as the associated mean and stdev values, UE 20 may be configured according to the present disclosure to measure and report one or more specific quantiles of the transport metrics (e.g., 0.01 , 0.05, 0.5, 0.9, 0.95). These values may also be measured and provided in addition to, or in lieu of, the calculated mean and stdev values seen in Table 1 .

[0050] It should be noted here that the specific transport metrics discussed above, as well as their corresponding ranges, resolutions, and mean/stdev values, are identified for illustrative purposes only. Any or all of the ranges and resolution values for the identified metrics can be the same or different from those illustrated herein. Regardless, however, it is expected that UE 20 will report the transport metrics with a relative accuracy of 1%.

[0051] According to the present disclosure, the transport metrics measured and reported by UE 20 can be added to the MeasurementReport and MeasurementReportAppLayer messages for NR, the MeasReportAppLayer message for LTE, or both.

[0052] In more detail, the MeasurementReport and MeasurementReportAppLayer are RRC messages and are encoded in ASN.1 format. The messages are generally used to indicate the results of the radio measurements and are sent by UE 20 to the network on a logical channel, such as the Dedicated Control Channel (DCCH) channel.

[0053] In one embodiment, the present disclosure configures UE 20 to report the transport metrics it measures in RRC events. However, the transport metric values contained in these reports are not necessarily impacted solely by radio conditions. Additionally, the present embodiments conveniently use RRC messaging to report the transport metrics because the RRC reporting function(s) are already available to UE 20. Therefore, enhancing the already-existing RRC messages to contain both radio metrics and transport metrics, as is done by the present disclosure, is advantageously convenient because there is no need to create new message types.

[0054] Further, according to the present disclosure, all the transport metrics measured and reported by UE 20 are defined as optional. Therefore, a UE 20 configured according to the present disclosure can report only its radio metrics, as well as both its radio metrics and transport metrics using the same RRC messaging.

[0055] The following code illustrates the structure of the MeasurementReport message for NR. The fields included in the MeasurementReport message for NR, as well as the RRC information elements in this message, are defined in TS 38.331.

- ASN1 START

- TAG-MEASUREMENTREPORT-START

MeasurementReport ::= SEQUENCE { criticalExtensions CHOICE { measurementReport MeasurementReport-IEs, criticalExtensionsFuture SEQUENCE {}

}

}

MeasurementReport-IEs ::= SEQUENCE { measResults MeasResults, lateNonCriticalExtension OCTET STRING OPTIONAL, nonCriticalExtension SEQUENCER OPTIONAL

}

- TAG-MEASUREMENTREPORT-STOP

- ASN1STOP

[0056] The following code illustrates the structure of the MeasResults element of the MeasurementReport message for NR.

- ASN1 START

- TAG-MEASRESULTS-START

MeasResults ::= SEQUENCE { measld Measld, measResultServingMOList MeasResultServMOList, measResultNeighCells CHOICE { measResultListNR MeasResultListNR, measResultListEUTRA MeasResultListEUTRA, measResultListUTRA-FDD-r16 MeasResultListUTRA-FDD-r16, sl-MeasResultsCandRelay-r17 OCTET STRING - Contains PC5 SL-

MeasResultListRelay-r17

}

OPTIONAL,

[[ measResultServFreqListEUTRA-SCG MeasResultServFreqListEUTRA-SCG OPTIONAL, measResultServFreqListNR-SCG MeasResultServFreqListNR-SCG

OPTIONAL, measResultSFTD-EUTRA MeasResultSFTD-EUTRA

OPTIONAL, measResultSFTD-NR MeasResultCellSFTD-NR

OPTIONAL

]],

[[ measResultCellListSFTD-NR MeasResultCellListSFTD-NR

OPTIONAL

]],

[[ measResultForRSSI-r16 MeasResultForRSSI-r16

OPTIONAL, Iocationlnfo-r16 Locationlnfo-r16

OPTIONAL, ul-PDCP-DelayValueResultList-r16 UL-PDCP-DelayValueResultList-r16

OPTIONAL, measResultsSL-r16 MeasResultsSL-r16

OPTIONAL, measResultCLI-r16 MeasResultCLI-r16

OPTIONAL

]],

[[ measResultRxTxTimeDiff-r17 MeasResultRxTxTimeDiff-r17

OPTIONAL, sl-MeasResultServingRelay-r17 OCTET STRING

OPTIONAL, - Contains PC5 SL-MeasResultRelay-r17 ul-PDCP-ExcessDelayResultList-r17 UL-PDCP-ExcessDelayResultList-r17

OPTIONAL, coarseLocationlnfo-r17 OCTET STRING

OPTIONAL ]]

}

[0057] The following code illustrates the structure of the MeasurementReportAppLayer message for NR. The fields included in the MeasurementReportAppLayer message, as well as the RRC information elements, are defined in TS 38.331 .

- ASN1 START

- TAG-MEASUREMENTREPORTAPPLAYER-START MeasurementReportAppLayer-r17 ::= SEQUENCE { criticalExtensions CHOICE { measurementReportAppLayer-r17 MeasurementReportAppLayer-r17-IEs, criticalExtensionsFuture SEQUENCE {}

}

}

MeasurementReportAppLayer-r17-IEs ::= SEQUENCE { measurementReportAppLayerList-r17 MeasurementReportAppLayerList-r17, lateNonCriticalExtension OCTET STRING OPTIONAL, nonCritical Extension SEQUENCE {} OPTIONAL

}

MeasurementReportAppLayerList-r17 ::= SEQUENCE (SIZE (1 ..maxNrofAppLayerMeas- r17)) OF MeasReportAppLayer-r17

MeasReportAppLayer-r17 ::= SEQUENCE { measConfigAppLayerld-r17 MeasConfigAppLayerld-r17, measReportAppLayerContainer-r17 OCTET STRING OPTIONAL, appLayerSessionStatus-r17 ENUMERATED {started, stopped} OPTIONAL, ran-VisibleMeasurements-r17 RAN-VisibleMeasurements-r17 OPTIONAL

}

RAN-VisibleMeasurements-r17 ::= SEQUENCE } appLayerBufferLevelList-r17 SEQUENCE (SIZE (1 ..8)) OF AppLayerBufferLevel-r17 OPTIONAL, playoutDelayForMediaStartup-r17 INTEGER (0..30000) OPTIONAL, pdu-SessionldList-r17 SEQUENCE (SIZE (1 ..maxNrofPDU-Sessions- r17)) OF PDU-SessionlD OPTIONAL,

}

AppLayerBufferLevel-r17 ::= INTEGER (0..30000)

- TAG-MEASUREMENTREPORTAPPLAYER-STOP

- ASN1STOP [0058] The following code illustrates the structure of the MeasurementReportAppLayer message for LTE. The fields included in the MeasurementReportAppLayer message for LTE, as well as the RRC information elements, are defined in TS 36.331.

- ASN1 START

MeasReportAppLayer-r15 ::= SEQUENCE { criticalExtensions CHOICE { measReportAppLayer-r15 MeasReportAppLayer-r15-IEs_; criticalExtensionsFuture SEQUENCE {} }

}

MeasReportAppLayer-r15-IEs ::= SEQUENCE { measReportAppLayerContainer-r15 OCTET STRING (SIZE(1 ..8000)) OPTIONAL, serviceType-r15 ENUMERATED {qoe, qoemtsi, spare6, spare5, spare4, spare3, spare2, sparel} OPTIONAL, nonCriticalExtension MeasReportAppLayer-v1590-IEs

OPTIONAL }

MeasReportAppLayer-v1590-IEs ::= SEQUENCE { lateNonCriticalExtension OCTET STRING OPTIONAL, nonCriticalExtension SEQUENCE {} OPTIONAL

}

- ASN1STOP

[0059] As previously stated, embodiments of the present disclosure extend the standard terminal radio measurement reports (i.e., the MeasurementReport and MeasurementReportAppLayer messages for NR) and/or the standard radio application reports (i.e., the MeasReportAppLayer message for LTE) that are routinely sent to the network by UE 20 to also include the transport metrics that were measured by UE 20. In one embodiment, extending these standard messages is accomplished by adding a newly- defined TransportMetrics-r18 data structure to the end of the MeasResults field in case of MeasurementReport RRC message and/or to the end of the RAN-VisibleMeasurements-r17 field of the MeasurementReportAppLayer RRC message. The following code identifies the fields of the TransportMetrics-r18 data structure, and Table 2 provides the descriptions for each field in the TransportMetrics-r18 data structure. It should be noted that, according to the present embodiments, the field descriptions are the same for both LTE cases and NR cases.

TransportMetrics-r18 ::= SEQUENCE { meanPacklATime INTEGER (0..100) OPTIONAL, stdevPacklATime INTEGER (0..100) OPTIONAL, meanBurstLength INTEGER (0..100) OPTIONAL, stdevBurstLength INTEGER (0..100) OPTIONAL, meanBurstSize INTEGER (0..100) OPTIONAL, stdevBurstSize INTEGER (0..100) OPTIONAL, meanBurstPack INTEGER (0..100) OPTIONAL, stdevBurstPack INTEGER (0..100) OPTIONAL, meanBurstl intensity INTEGER (0..1000) OPTIONAL, stdevBurstlntensity INTEGER (0..100) OPTIONAL, m ean B u rstS epa rati o n INTEGER (0..100) OPTIONAL, stdevBurstSeparation INTEGER (0..100) OPTIONAL,

}

Table 2

[0060] It should also be noted here that the present embodiments apply to both the MeasurementReport RRC message, which applies to SRB1 and SRB3 signaling radio bearers, as well as the MeasuremntReportAppLayer RRC message, which applies to SRB4 signaling radio bearer. This beneficially provides extra flexibility in activating transport metrics reporting by UE 20 for only a segment of applications and/or radio network.

[0061] Despite this extra flexibility, however, embodiments of the present disclosure can have a heavy impact on the resources of the underlying communication network. Accordingly, the present disclosure provides the ability to selectively activate UEs to report the transport metrics, as well as selectively filter how the UEs operate to measure the transport metrics.

[0062] For example, in one embodiment, UE 20 is activated to measure and report transport metrics for a selected network architecture, such as the Ultra Reliable Low Latency Communication (URLLC). In these cases, the UE 20 may further be activated to measure and report transport metrics only for one or more selected URLLC sessions, devices, or dedicated cells. Because of its low-latency requirements with respect to data transfer, embodiments of the present disclosure would be especially advantageous to situations involving URLLC.

[0063] In another example, embodiments of the present disclosure may activate UE 20 to measure and report transport metrics only for a selected one or more individual subscribers and/or lists/groups of subscribers. By way of example only, VIP users may benefit from network responses that are more accurate due to the measurement and reporting of the transport metrics. Additionally, or alternatively, adding test users to the network can benefit the ML algorithms used in determining the e2e service quality and also provides extra insights to network operators regarding MDT. Further, the present embodiments can provide additional information regarding subscriber(s) having network issues. Although the particular filters that are selected can be any that are needed or desired, one embodiment of the present disclosure uses QCI/5QI/ARP/VCI/VPI/SPID as a filtering parameter. Other embodiments can use any combination of one or more of QCI/5QI/ARP/VCI/VPI/SPID. In at least one embodiment, however, the filters are selected based on a given network operator’s policies and needs.

[0064] Another embodiment of the present disclosure selectively activates UE 20 to measure and report the transport metrics at a radio node level and/or a cell level. A radio node-based selected activation can enhance radio network troubleshooting, as well as provide useful extra information on newly installed radio nodes. Activation at the cell-level can have the same or similar advantages. Regardless of the particular level, however, the present embodiments beneficially provide the network operators, for example, with an option to activate UE 20 to measure and report the transport metrics for one or more specific nodes and/or lists/groups of nodes.

[0065] Figure 2 is a signaling diagram 60 illustrating example messaging between the devices in a system 10 configured according to aspects of the present disclosure. As seen in diagram 60, the devices may include, but are not limited to, the UE 20, the applications 22 executing on UE 20, the gNodeB32 (or an eNodeB) in RAN domain 30, and the CN domain 40 (e.g., the NWDAF 42 in CN 40).

[0066] The messaging seen in the embodiment of Figure 2 illustrates an example measurement flow. Specifically, applications 22 execute at a UE 20 or some other mobile device, while gNodeB 32 (or an eNodeB) is in RAN domain 30. The CN domain enables the extra measurement and reporting of the transport metrics by UE 20 via the RAN domain 30 based on one or more recommended activation/filter criteria, or on some other, custom criteria. Additionally, embodiments of the present disclosure configure the radio nodes associated with the RAN domain 30 and CN domain 40 to handle the extended radio measurement reports 24 having the measured and reported transport metrics.

[0067] Accordingly, as seen in diagram 60, a node in the CN domain 40 (e.g., NWDAF 42) sends a measurement activation message to the gNodeB 32 in the RAN domain 30 (line 62). Alternatively, the MDAF 52 in OSS domain 50 may initiate the activation of UE 20 to begin measuring and reporting one or more selected transport metrics. The gNodeB 32, in turn, sends the measurement activation message to UE 20 (line 64). So activated, UE 20 begins measuring the transport metrics identified by the network (line 66). As stated above, for example, UE 20 may be activated to measure and report the transport metrics for one or more selected network architectures (e.g., the URLLC), sessions, network cells, subscribers, network nodes, service types, and services. In some embodiments, the UE 20 may itself have been selectively activated to measure and report the transport metrics for one or more selected core network nodes.

[0068] At the end of the measurement period, the additional metrics measured by UE 20 are included in the previously described RRC message(s) and sent to gNodeB 32 (line 68) and the NWDAF 42 in CN 40 (or the SDAF 52 in OSS domain 50) (line 70). The counters in UE 20 are also reset. As stated above, the calculation and reporting of transport metrics (lines 66, 68, and 70) is continuous. However, the deactivation of the UE 20 in measuring and reporting the transport metrics is initiated by a node in the CN domain 40 and/or the RAN domain 30 (lines 72, 74). Once UE 20 receives the deactivation message, UE 20 ceases measuring and reporting the specified transport metrics to the network.

[0069] As previously stated, the transport metrics may be included in periodic RRC reports sent to gNodeB 32 (or eNodeB). Advantageously, however, the present embodiments do not impact the RRC level communication mechanisms that exist between UE 20 and the gNodeB 32 (or eNodeB). Rather, these mechanisms continue to function as defined in corresponding standards. Thus, the present embodiments modify (i.e., extend) existing RRC messages only with new and optional data in a backward compatible manner. [0070] Further, the present embodiments beneficially do not require any modifications related to the RRC communication mechanism. Only the payload section of the RRC measurement reports is extended, as previously described.

[0071] Additionally, the present embodiments define the previously described additional measurement fields (i.e., those seen in Table 2) as being OPTIONAL. Thus, transport metric measurement and reporting only when UE 20 has monitorable traffic and when the network nodes in both the RAN domain 30 and CN domain 40 are configured to handle the additional transport metrics.

[0072] Figure 3 is a flow diagram illustrating a method 80 for reporting transport metrics to a network node (e.g., gNodeB32) according to aspects of the present disclosure. As previously described, the functions detailed in method 80 are implemented at UE 20 configured according to the present disclosure.

[0073] As seen in Figure 3, method 80 begins with UE 20 receiving a transport measurement activation trigger from a network node (e.g., gNodeB32) in a communications network (box 82). The transport measurement activation trigger, in one embodiment, comprises a signal, message, or other indication that indicates to UE 20 that it should begin measuring selected transport metrics. In response to receiving the trigger, UE 20 will begin measuring both radio metrics and transport metrics for user traffic at UE 20 (box 84). As stated above, most, if not all UEs, such as UE 20, are already configured to measure radio metrics, as is conventional. However, a UE 20 configured according to the present disclosure is also configured to measure and report one or more selected transport metrics to gNodeB 32. Once measured, UE 20 generates a radio reporting message comprising both the radio metrics and the transport metrics (box 86) and sends the radio reporting message to the network node in the communications network (box 88). As previously described, UE 20 will continuously measure and report selected transfer metrics (boxes 84, 86, 88) until UE 20 receives a transport measurement de-activation trigger from the network node (box 90). Upon receipt, UE 20 ceases the measurement and reporting functions specified in the transport measurement de-activation trigger.

[0074] In one embodiment of the present disclosure, the radio metrics comprise radio quality indicators measured by the UE for a serving cell and one or more neighbor cells, and the transport metrics comprise one or more transport level parameters measured by the UE. [0075] The transport metrics may contain any transport metrics needed or desired, but in one embodiment, the transport metrics measured by the UE comprise a packet interarrival time (IAT) indicating a time between the arrival of at least two consecutive packets of a flow.

[0076] Additionally, in one embodiment, the transport metrics measured by the UE comprise one or more burst parameters associated with a burst of packets. As defined herein, a burst of packets comprises a group of packets arriving at the UE within a specified time period.

[0077] In another embodiment, the one or more burst parameters comprise a burst length indicating a length of time between the arrival of a first packet and a last packet in the burst of packets.

[0078] In other embodiments, however, the one or more burst parameters measured by UE 20 comprise a burst size indicating a sum of the bytes of the burst of packets.

[0079] In at least one embodiment, the one or more burst parameters measured by the UE comprise a number of packets in the burst of packets.

[0080] In other embodiments, however, the one or more burst parameters measured by the UE comprise a number of bursts of packets received per second.

[0081] In one embodiment, the one or more burst parameters measured by the UE comprise a burst separation time indicating an elapsed time between first and second consecutively received bursts of packets.

[0082] In one embodiment, the one or more burst parameters comprise a mean of the one or more burst parameters.

[0083] In one embodiment, the one or more burst parameters comprise a standard deviation of the one or more burst parameters.

[0084] In one embodiment, the one or more burst parameters comprise a predetermined quantile of the one or more burst parameters.

[0085] In one embodiment, the transport metrics are measured by the UE for encrypted user traffic.

[0086] In one embodiment, the transport metrics are measured by the UE based on traffic type.

[0087] In one embodiment, the radio measurement report comprises a Radio Resource Control (RRC) message extended to include the transport metrics. [0088] In some embodiments, the RRC message comprises one of a MeasurementReport message and a MeasurementReportAppLayer message. [0089] In other embodiments, however, the RRC message comprises a MeasReportAppLayer message.

[0090] In one embodiment, the UE is activated to measure selected transport metrics. [0091] In one embodiment, the UE is activated to selectively filter the transport metrics. [0092] In one embodiment, the transport metrics are measured for a selected network architecture. The selected network architecture may be, in one embodiment, Ultra Reliable Low Latency Communication (URLLC).

[0093] In one embodiment, the UE measures the transport metrics for a selected session.

[0094] In another embodiment, the UE is selected by the network node to measure the transport metrics.

[0095] In one embodiment, the UE measures the transport metrics for one or more selected network cells.

[0096] In one embodiment, the UE measures the transport metrics for one or more selected subscribers.

[0097] In one embodiment, the UE measures the transport metrics according to a selected predetermined policy.

[0098] In one embodiment, the UE measures the transport metrics for one or more selected core network nodes.

[0099] In one embodiment, the UE measures the transport metrics for one or more selected service types.

[0100] In one embodiment, the UE measures the transport metrics for one or more selected services.

[0101] In at least one embodiment, the transport metrics are used to estimate an end-to- end service quality for the UE.

[0102] In at least one embodiment, the radio reporting message is sent periodically to the network node.

[0103] Additionally, the present disclosure provides a communication system comprising a User Equipment (UE) and a network analytics node. The UE is configured to measure radio metrics and transport metrics for user traffic, generate a radio reporting message comprising both the radio metrics and the transport metrics, and send the radio reporting message to the communications network. The network analytics node is configured to input values representing the transport metrics in the radio reporting message into one or more machine learning (ML) models and determine an end-to-end (e2e) service quality for the UE based on a result of the one or more ML models. [0104] In one embodiment, the network analytics node comprises a Network Data Analytics Function (NWDAF) in a core network.

[0105] In another embodiment, the network analytics node comprises a Management Data Analytics Function (MDAF) in an Operations Support System (OSS).

[0106] 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 microprocessors 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.

[0107] Figure 4 illustrates some of the main functional components of a UE 100 configured according to one embodiment of the present disclosure. As previously described, UE 100 may be, for example, a mobile end user terminal (e.g., a SMARTPHONE), as previously described. However, according to the present disclosure, UE 100 is not limited as such. Other types of user devices, such as laptop computers, tablet computer, and the like, may be configured to operate according to the embodiments described herein. As seen in Figure 4, UE 100 comprises communication circuitry 102, processing circuitry 106, and memory 108.

[0108] The communication circuitry 102 comprises network interface circuitry (NIC) 104. In one or more embodiments, the NIC 104 comprises network interface circuitry that configures UE 100 for communication with one or more network nodes, core network nodes, and or external systems, such as an CAM entity, for example. The NIC 104 may, for example, comprise an Ethernet interface, optical network interface, or a wireless interface that configures UE 100 to communicate with gNodeB32 via RAN domain 30 over an air interface.

[0109] The processing circuitry 106 comprises one or more microprocessors, hardware, firmware, or a combination thereof that controls the overall operation of the UE 100. The processing circuitry 106 can be configured by software to perform one or more of the methods herein described including methods 60 and 80 seen in Figures 2-3, respectively. [0110] Memory 108 comprises both volatile and non-volatile memory for storing computer program code and data needed by the processing circuitry 106 for operation. Memory 108 may comprise any tangible, non-transitory computer-readable storage medium for storing data including electronic, magnetic, optical, electromagnetic, or semiconductor data storage. Memory 108 stores a computer program 110 comprising executable instructions that configure the processing circuit 106 in the UE 100 to perform one or more of the methods herein described including methods 60 and 80 seen in Figures 2-3, respectively. A computer program 110 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 110 for configuring the processing circuitry 106 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 110 may also be embodied in a carrier such as an electronic signal, optical signal, radio signal, or computer readable storage medium.

[0111] 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 processes described above. A computer program in this regard may comprise one or more code modules corresponding to the means or units described above.

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

[0113] 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.

[0114] 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 UE 100. This computer program product may be stored on a computer readable recording medium. [0115] 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.

[0116] Figure 5 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.

[0117] 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.

[0118] 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.

[0119] 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).

[0120] 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 services. 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.

[0121] As a whole, the communication system 1100 of Figure 5 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. [0122] 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. [0123] 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).

[0124] 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.

[0125] 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. [0126] Figure 6 is a block diagram of a host 1400, which may be an embodiment of the host 1116 of Figure 5, 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.

[0127] 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.

[0128] 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.

[0129] Figure 7 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 5), network node (such as network node 1110a of Figure 5), and host (such as host 1116 of Figure 5) discussed in the preceding paragraphs will now be described with reference to Figure 7.

[0130] 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.

[0131] 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 5) 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.

[0132] 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.

[0133] 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.

[0134] 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.

[0135] 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.

[0136] 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.

[0137] 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.

[0138] 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

1 . A method (80) for reporting transport metrics to a network node (32) in a communications network (10), the method implemented by a User Equipment (UE) (20) and comprising: measuring (84) radio metrics and transport metrics for user traffic at the UE; generating (86) a radio reporting message (24) comprising both the radio metrics and the transport metrics; and sending (88) the radio reporting message to the network node in the communications network.

2. The method of claim 1 : wherein the radio metrics comprise radio quality indicators measured by the UE for a serving cell and one or more neighbor cells; and wherein the transport metrics comprise one or more transport level parameters measured by the UE.

3. The method of any of claims 1 -2, wherein the UE begins measuring the transport metrics responsive to receiving (82) a transport measurement activation trigger from the network node.

4. The method of any of claims 1 -3, wherein the UE ceases to measure the transport metrics responsive to receiving (90) a transport measurement deactivation trigger from the network node.

5. The method of claim 4, wherein the UE continuously measures the transport metrics until the UE receives the transport measurement deactivation trigger from the network node.

6. The method of any of claims 1 -5, wherein the transport metrics measured by the UE comprise a packet interarrival time (IAT) indicating a time between the arrival of at least two consecutive packets of a flow.

7. The method of any of claims 1 -6, wherein the transport metrics measured by the UE comprise one or more burst parameters associated with a burst of packets, and wherein the burst of packets comprises a group of packets arriving at the UE within a specified time period.

30

RECTIFIED SHEET (RULE 91 ) ISA/EP

8. The method of claim 7, wherein the one or more burst parameters comprise a burst length indicating a length of time between the arrival of a first packet and a last packet in the burst of packets.

9. The method of any of claims 7-8, wherein the one or more burst parameters measured by the UE comprise a burst size indicating a sum of the bytes of the burst of packets.

10. The method of any of claims 7-9, wherein the one or more burst parameters measured by the UE comprise a number of packets in the burst of packets.

11 . The method of any of claims 7-10, wherein the one or more burst parameters measured by the UE comprise a number of bursts of packets received per second.

12. The method of any of claims 7-11 , wherein the one or more burst parameters measured by the UE comprise a burst separation time indicating an elapsed time between first and second consecutively received bursts of packets.

13. The method of any of claims 7-12, wherein the one or more one or more burst parameters comprise a mean of the one or more burst parameters.

14. The method of any of claims 7-12, wherein the one or more burst parameters comprise a standard deviation of the one or more burst parameters.

15. The method of any of claims 7-12, wherein the one or more burst parameters comprise a predetermined quantile of the one or more burst parameters.

16. The method of any of claims 1 -15, wherein the transport metrics are measured by the UE for encrypted user traffic.

17. The method of any of claims 1 -16, wherein the transport metrics are measured by the UE based on traffic type.

18. The method of any of claims 1 -17, wherein the radio measurement report comprises a Radio Resource Control (RRC) message extended to include the transport metrics.

19. The method of claim 18, wherein the RRC message comprises one of a MeasurementReport message and a MeasurementReportAppLayer message.

31

RECTIFIED SHEET (RULE 91 ) ISA/EP

20. The method of claim 18, wherein the RRC message comprises a MeasReportAppLayer message.

21 . The method of any of claims 1 -20, wherein the UE is activated to measure selected transport metrics.

22. The method of any of claims 1 -20, wherein the UE is activated to selectively filter the transport metrics.

23. The method of claim 21 or 22, wherein the transport metrics are measured for a selected network architecture.

24. The method of claim 23, wherein the selected network architecture is Ultra Reliable Low Latency Communication (URLLC).

25. The method of claim 21 or 22, wherein the UE measures the transport metrics for a selected session.

26. The method of claim 21 or 22, wherein the UE is selected by the network node to measure the transport metrics.

27. The method of claim 21 or 22, wherein the UE measures the transport metrics for one or more selected network cells.

28. The method of claim 21 or 22, wherein the UE measures the transport metrics for one or more selected subscribers.

29. The method of claim 21 or 22, wherein the UE measures the transport metrics according to a selected predetermined policy.

30. The method of claim 21 or 22, wherein the UE measures the transport metrics for one or more selected core network nodes.

31 . The method of claim 21 or 22, wherein the UE measures the transport metrics for one or more selected service types.

32

RECTIFIED SHEET (RULE 91 ) ISA/EP

32. The method of claim 21 or 22, wherein the UE measures the transport metrics for one or more selected services.

33. The method of any of the preceding claims, wherein the transport metrics are used to estimate an end-to-end service quality for the UE.

34. The method of any of the preceding claims, wherein the radio reporting message is sent periodically to the network node.

35. A User Equipment (UE) (100) configured to provide measurements to a network node

(32) in a communications network (10), the UE comprising: processing circuitry (106); and a memory (108) containing instructions (1 10) executable by the processing circuitry whereby the UE is configured to: measure (84) radio metrics and transport metrics for user traffic at the UE; generate (86) a radio reporting message (24) comprising both the radio metrics and the transport metrics; and send (88) the radio reporting message to the network node in the communications network.

36. The UE of claim 35, whereby the UE is further configured to perform the method of any of claims 2-34.

37. A User Equipment (UE) (100) configured to provide measurements to a network node

(32) in a communications network (10), the UE being configured to: measure (84) radio metrics and transport metrics for user traffic at the UE; generate (86) a radio reporting message (24) comprising both the radio metrics and the transport metrics; and send (88) the radio reporting message to the network node in the communications network.

38. A computer program (110) comprising instructions which, when executed on processing circuitry (106) of a User Equipment (UE) (100), causes the processing circuitry to perform the method of any of claims 1-34.

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

33

RECTIFIED SHEET (RULE 91 ) ISA/EP

40. A non-transitory computer readable medium (108) comprising instructions (110) stored thereon that, when executed by processing circuity (106) of a User Equipment (UE) (100) configured to provide measurements to a network node (32) in a communications network (10), causes the UE to: measure (84) radio metrics and transport metrics for user traffic at the UE; generate (86) a radio reporting message (24) comprising both the radio metrics and the transport metrics; and send (88) the radio reporting message to the network node in the communications network.

41 . A communication system comprising: a User Equipment (UE) (20) configured to: measure (84) radio metrics and transport metrics for user traffic at the UE; generate (86) a radio reporting message (24) comprising both the radio metrics and the transport metrics; and send (88) the radio reporting message to the communications network; and a network analytics node (42, 52) configured to: input values representing the transport metrics in the radio reporting message into one or more machine learning (ML) models; and determine an end-to-end (e2e) service quality for the UE based on a result of the one or more ML models.

42. The method of claim 41 , wherein the network analytics node comprises a Network Data Analytics Function (NWDAF) in a core network.

43. The method of claim 41 , wherein the network analytics node comprises a Management Data Analytics Function (MDAF) in an Operations Support System (OSS).

34

RECTIFIED SHEET (RULE 91 ) ISA/EP