How to configure RAN-visible (lightweight) QOE and how to coordinate measurements between RAN nodes

Abstract

A first exemplary method for managing quality of experience (QoE) measurements by a user equipment (UE), the first exemplary method being performed by a first Radio Access Network (RAN) node includes transmitting (1010) configuration information for one or more RAN-visible QoE measurements configured by the first node for the UE to a second node in the RAN, the second node being associated with the first node for at least one of: a configuration change of the UE for multi-connection, UE mobility, an RRC resumption or RRC re-establishment of the UE, and switching forwarding of service data from a path towards the UE via the first RAN node to a path towards the UE via the second RAN node.

Description

[Technical field]

[0001] The present invention relates generally to wireless communication networks, and more particularly to efficient techniques for configuring, performing and reporting various Quality of Experience (QoE) measurements by User Equipment (UE) in a wireless network. [Background technology]

[0002] Long Term Evolution (LTE) is a general term for the fourth-generation (4G) radio access technology, also known as Evolved UMTS Radio Access Network (E-UTRAN), developed within the 3rd Generation Partnership Project (3GPP) and initially standardized in Release 8 (Rel-8) and Release 9 (Rel-9). LTE covers various licensed frequency bands and typically involves improvements in non-radio aspects, called System Architecture Evolution (SAE), including the Evolved Packet Core (EPC) network. LTE has continued to evolve through subsequent releases.

[0003] 3GPP's LTE Release 10 (Rel-10) supports bandwidths greater than 20 MHz. One of the key requirements for Rel-10 is backward compatibility with LTE Rel-8, including spectrum compatibility. Thus, a wideband LTE Rel-10 carrier (e.g., wider than 20 MHz) should appear as multiple carriers ("component carriers" or CCs) to LTE Rel-8 ("legacy") terminals. Legacy terminals can be scheduled on any part of the wideband LTE Rel-10 carrier. One way to achieve this is through Carrier Aggregation (CA), which allows a Rel-10 terminal to receive multiple CCs, each preferably with the same structure as a Rel-8 carrier. Additionally, LTE Rel-12 introduces Dual Connectivity (DC), which allows a UE to connect to two network nodes simultaneously, improving the robustness and capacity of the connection.

[0004] Currently, the fifth generation of cellular systems ("5G"), also known as New Radio (NR), is being standardized within the Third Generation Partnership Project (3GPP). NR was developed to allow maximum flexibility to support a number of substantially different use cases. These include enhanced Mobile Broadband (eMBB), Machine Type Communications (MTC), Ultra-Reliable Low Latency Communications (URLLC), Sidelink Device-to-Device (D2D), and several other use cases.

[0005] 5G / NR technology has many similarities with LTE. For example, NR uses CP-OFDM (Cyclic Prefix Orthogonal Frequency Division Multiplexing) on ​​the downlink (DL, i.e., transmission from the network) and both CP-OFDM and DFT-Spread OFDM (DFT-S-OFDM) on the uplink (UL, i.e., transmission to the network). As another example, in the time domain, NR DL and UL physical resources consist of equal-sized subframes, each of 1 ms. The subframes are further divided into multiple slots of equal duration, with each slot containing multiple OFDM-based symbols.

[0006] However, time-frequency resources can be configured much more flexibly in NR cells than in LTE cells. Furthermore, in addition to providing coverage via "cells" as in LTE, NR networks also provide coverage via "beams". In general, a DL "beam" is a coverage area of ​​a network-transmitted reference signal (RS) that can be measured or monitored by a user equipment (UE, e.g., a wireless communication device).

[0007] Quality of Experience (QoE) measurements are specified for UEs operating in LTE networks and previous generation UMTS networks. Measurements in both networks operate according to the same high-level principles. The objective is to measure the end user's experience when using a particular application over the network. For example, QoE measurements for streaming services and MTSI (Mobile Telephony Services in IMS) are supported in LTE. QoE measurements are also required for UEs operating in NR networks, so QoE measurements are also specified in NR.

[0008] The solutions for LTE and UMTS are similar and the overall principles are: Quality of Experience Measurement Collection (QMC) enables the configuration of application layer measurements in the UE and the transmission of QoE measurement results by Radio Resource Control (RRC) signalling. Application layer measurement configuration received from OAM or Core Network (CN) is encapsulated in a transparent container and forwarded in a downlink RRC message to the UE. Application layer measurements received from higher layers in the UE are encapsulated in a transparent container and sent to the network in an uplink RRC message. The result container is forwarded to the Trace Collection Entity (TCE).

[0009] A new study item, "Study on NR QoE management and optimization for diverse services," was approved in NR Rel-17. The purpose is to study solutions for QoE measurement in NR not only for streaming services like LTE, but also for other services such as augmented reality / virtual reality (AR / VR), URLLC, etc. Based on various service requirements, the NR study includes a more adaptive QoE management scheme that enables intelligent network optimization to meet the user experience of diverse services.

[0010] Radio Resource Control (RRC) signaling is used to configure application layer measurements for the UE and to collect QoE measurement result files from the configured UE. In particular, application layer measurement configurations from the core network (e.g., EPC) or network operations, administration and maintenance (OAM) functions (also called "Network Management System" or "NMS") are encapsulated in transparent containers and sent to the UE's serving RAN node, which forwards them in RRC messages to the UE. Application layer measurements made by the UE are encapsulated in transparent containers and sent in RRC messages to the serving RAN node, which forwards the containers to a Trace Collection Entity (TCE) or Measurement Collection Entity (MCE) associated with the core network.

[0011] Measurements may be initiated in a management-based manner, i.e. from the O&M node towards the RAN in a generic manner, e.g. for a group of UEs, or in a signaling-based manner, e.g. from the CN towards the RAN for a single UE. The measurement configuration contains the details of the measurement and is encapsulated in a container that is transparent to the RAN.

[0012] When initiated via the core network, measurements are started directed towards a specific UE. In the case of LTE, a "TRACE START" S1AP message is used, which carries, among other things, details about the measurement configuration that the application should collect (in an "Application Layer Measurement Configuration Container" information element, transparent to the RAN) and details to reach the trace collection entity to which the measurements should be sent.

[0013] The RAN is not aware when a streaming session is ongoing in the UE access stratum, nor is it aware when measurements are ongoing. It is an implementation decision when the RAN stops measuring. Typically this is done when the UE moves out of the measurement area.

[0014] One of the opportunities offered by traditional solutions is the ability to maintain QoE measurements throughout the session, even in handover situations. The background to the LTE (E-UTRAN) solution is described below.

[0015] E-UTRAN - Application Layer Measurement Capabilities For E-UTRAN, UE Capability Transfer is used to transfer UE radio access capability information from the UE to the E-UTRAN, as shown in Figure 1.

[0016] The UE-EUTRA-Capability information element (IE) is used to convey E-UTRA UE radio access capability parameters and functional group indicators of mandatory capabilities to the network.

[0017] The UE may include the "UE-EUTRA-Capability" IE in the response message "UECapabilityInformation". The "UE-EUTRA-Capability" IE may contain the UE-EUTRA-Capability-v1530-IE, which may be used by the UE to indicate whether it supports QoE measurement collection for streaming services and / or MTSI services, as detailed in the "MeasParameters-v1530" encoding below.

[0018] 3GPP® TS 36.331 v16.0.0 document CR4297 (R2-2004624) at meeting #110 of 3GPP® TSG RAN2 proposes an extension to "UE-EUTRA-Capability" that may include "measParameters-v16xy" which contains a qoe-Extensions-r16 IE within the "UE-EUTRA-Capability-v16xy-IE". The qoe-Extensions-r16 IE may be used to indicate whether the UE supports Release 16 extensions of QoE measurement collection, i.e., whether the UE supports multiple QoE measurement types at a time, and whether the UE supports the signaling of withinArea, sessionRecordingIndication, qoe-Reference, temporaryStopQoE and restartQoE.

[0019] E-UTRAN - Application Layer Measurement Report The purpose of the "Application Layer Measurement Reporting" procedure described in 3GPP TS 36.331 and illustrated in Figure 2 is to signal application layer measurement reports to the E-UTRAN.

[0020] A UE capable of application layer measurement reporting in RRC_CONNECTED may initiate the procedure when application layer measurements are configured, i.e. when measConfigAppLayer is configured by E-UTRAN.

[0021] When initiating the procedure, the UE should: 1> If application layer measurements are configured, SRB4 is configured, and the UE has received application layer measurement report information from higher layers: 2>Set measReportAppLayerContainer in the MeasReportAppLayer message to the value of the application layer measurement report information; 2>Set serviceType in the MeasReportAppLayer message to the type of application layer measurement report information; 2> Send the MeasReportAppLayer message to the lower layer to be sent via SRB4.

[0022] E-UTRAN - Setting up and releasing QoE measurement configuration - RRC signalling The RRCConnectionReconfiguration message is used to reconfigure the UE and set up or release it for application layer measurements, which is signaled in the measConfigAppLayer-15 IE within the "OtherConfig" IE.

[0023] The configuration includes a transparent container measConfigAppLayerContainer that specifies the QoE measurement configuration for the target application, and a serviceType IE that indicates the application (or service) for which the QoE measurement is configured. Supported services are streaming and MTSI.

[0024] 3GPP® TS36.331 v16.0.0 document CR4297 (R2-2004624) at 3GPP® TSG RAN2 Meeting #110 proposes to extend the QoE measurement configuration.

[0025] The measConfigAppLayerToAddModList-r16 may be used to add or modify multiple QoE measurement configurations (up to maxQoE-Measurement-r16). The measConfigAppLayerToReleaseList-r16 IE may be used to remove multiple QoE measurement configurations (up to maxQoE-Measurement-r16).

[0026] E-UTRAN-QoE Measurement Reporting-RRC Signalling As specified in 3GPP TS 36.331, the MeasReportAppLayer RRC message is used by the UE to transmit the QoE measurement results of an application (or service) to an E-UTRAN node. The service for which the report is being sent is indicated in the "serviceType" IE.

[0027] 3GPP® TS 36.331 v16.0.0 document CR4297 (R2-2004624) at 3GPP® TSG RAN2 Meeting #110 proposes to extend the MeasReportAppLayer IE to introduce a QoE reference that includes a PLMN identifier and an identifier for QoE measurement collection.

[0028] For E-UTRAN, examples of desired UE behavior for application layer measurement reports are given in CR4297 (R2-2004624).

[0029] UE Application Layer Measurement Configuration The "UE Application Layer Measurement Configuration" IE is described in 3GPP TS 36.413 v16.3.0 and TS 36.423 v16.3.0.

[0030] Area scope for QoE measurements According to 3GPP TS 28.405, the area scope parameter defines the area in terms of cells or tracking / routing / location areas where QoE Measurement Collection (QMC) is performed. If the parameter is not present, QMC is performed in the whole PLMN identified in the PLMN target.

[0031] The UMTS area scope parameters are: - A list of cells identified by their CGI. Up to 32 CGIs can be defined. - A list of Routeing Areas identified by RAIs. Up to eight RAIs may be defined. - A list of location areas identified by LAIs. Up to eight LAIs can be defined.

[0032] The LTE area scope parameters are: - A list of cells identified by E-UTRAN-CGI. Up to 32 CGIs can be defined. - A list of tracking areas identified by TACs. Up to eight TACs may be defined. The parameter is mandatory if area-based QMC is required. Summary of the Invention [Problem to be solved by the invention]

[0033] Embodiments of the techniques and apparatus described herein enable coordinated processing of configurations for RAN visible (lightweight) QoE measurements among RAN nodes. [Means for solving the problem]

[0034] Some embodiments of the present disclosure include example methods (e.g., procedures) for managing Quality of Experience (QoE) measurements in a Radio Access Network (RAN). These example methods may be performed by a user equipment (UE, e.g., wireless device, IoT device, modem, etc.) in communication with a Radio Access Network (RAN) node (e.g., base station, eNB, gNB, ng-eNB, en-gNB, etc.).

[0035] An exemplary method according to some embodiments described herein is performed by a first node in a Radio Access Network (RAN) for managing Quality of Experience (QoE) measurements by a User Equipment (UE). The exemplary method includes transmitting configuration information of one or more RAN visible (lightweight) QoE measurements configured by the first node in the UE to a second node in the RAN.

[0036] A corresponding method according to some embodiments described herein is performed by a second node in a Radio Access Network (RAN) for managing Quality of Experience (QoE) measurements by a User Equipment (UE). The exemplary method includes receiving, from a second node in the RAN, configuration information for one or more RAN visible (lightweight) QoE measurements configured in the UE by the first node.

[0037] Another embodiment includes a method in a user equipment (UE) for processing configuration of quality of experience (QoE) measurements in a radio access network (RAN). The exemplary method includes receiving a RAN visible (lightweight) QoE measurement configuration from a RAN node and determining that the UE already has a QoE configuration for the same service type or application. The method further includes taking one or more of the following actions upon the determination: discarding the new RAN visible (lightweight) QoE configuration; releasing the old RAN visible (lightweight) QoE configuration and configuring itself and higher layers with the new RAN visible (lightweight) QoE configuration; suspending the new configuration; suspending the old configuration and activating the new configuration; and if the old configuration is already in a suspended state when the new configuration is received, leaving the new configuration active and releasing the old configuration or leaving the old configuration suspended. If a service / application type or a service subtype is specified by a new RAN visible (lightweight) QoE configuration, configure itself and the target service type or subtype and / or upper layers of the target application with the specified service and keep the old RAN visible (lightweight) QoE configuration for the remaining applications. In a dual connectivity scenario, if one of the RAN visible (lightweight) QoE configurations is received from the master node and the other one from the secondary node, release the RAN visible (lightweight) QoE configuration received from the secondary node and keep the RAN visible (lightweight) QoE configuration received from the master node active. In a dual connectivity scenario, if one of the RAN visible (lightweight) QoE configurations is received from the master node and the other one from the secondary node, suspend the RAN visible (lightweight) QoE configuration received from the secondary node and keep the RAN visible (lightweight) QoE configuration received from the master node active.If an ongoing application session (or all such ongoing application sessions, if more than one is ongoing) of a service type and / or service subtype covered by the RAN visible (lightweight) QoE configuration is currently using a radio bearer to the RAN node from which the old configuration was received, maintain the old configuration and release or suspend the new configuration.If an ongoing application session (or all such ongoing application sessions, if more than one is ongoing) of a service type and / or service subtype covered by the RAN visible (lightweight) QoE configuration is currently using a radio bearer to the RAN node from which the new configuration was received, maintain the new configuration and release or suspend the old configuration.

[0038] Various embodiments of the solutions described herein enable mechanisms for transferring RAN visible (lightweight) QoE measurement configuration and status information between RAN nodes, enabling appropriate processing of the measurements by the node receiving the information, the node transmitting the information, and / or both. Additionally, these mechanisms enable the gNB-CU to forward RAN visible (lightweight) QoE reports to the gNB-DU so that the gNB-DU can use the RAN visible (lightweight) QoE measurements in optimizations and algorithms. For example, the gNB-DU can use RAN visible QoE metrics such as buffer levels to adjust link adaptation and scheduling policies.

[0039] These and other objects, features, and advantages of embodiments of the present disclosure will become apparent from the following detailed description taken in conjunction with the drawings, which are briefly described below. [Brief description of the drawings]

[0040] [Figure 1] FIG. 1 illustrates UE capability transfer in LTE (E-UTRAN). [Diagram 2] A diagram showing application layer measurement reports for E-UTRAN. [Diagram 3]1 is a high-level block diagram of an example architecture of a Long Term Evolution (LTE) Evolved UTRAN (E-UTRAN) and Evolved Packet Core (EPC) network, as standardized by 3GPP. [Figure 4] Diagram showing two high-level views of 5G / NR network architecture. [Diagram 5] Diagram showing two high-level views of 5G / NR network architecture. [Figure 6] A diagram showing an example configuration of the NR user plane (UP) and control plane (CP) protocol stacks. [Figure 7A] FIG. 1 illustrates various procedures between UTRAN and UE for Quality of Experience (QoE) measurements in a legacy UMTS network. [Figure 7B] FIG. 1 illustrates various procedures between UTRAN and UE for Quality of Experience (QoE) measurements in a legacy UMTS network. [Figure 7C] FIG. 1 illustrates various procedures between UTRAN and UE for Quality of Experience (QoE) measurements in a legacy UMTS network. [Figure 7D] FIG. 1 illustrates various procedures between UTRAN and UE for Quality of Experience (QoE) measurements in a legacy UMTS network. [Figure 8A] FIG. 2 illustrates various aspects of a UE's QoE measurement configuration in an LTE network. [Figure 8B] FIG. 2 illustrates various aspects of a UE's QoE measurement configuration in an LTE network. [Figure 9A] FIG. 2 illustrates various aspects of UE QoE measurement collection in an LTE network. [Figure 9B] FIG. 2 illustrates various aspects of UE QoE measurement collection in an LTE network. [Figure 9C] FIG. 2 illustrates various aspects of UE QoE measurement collection in an LTE network. [Figure 10]FIG. 2 is a flow diagram illustrating an example method (e.g., procedure) at a first RAN node (RNN, e.g., eNB, gNB, ng-eNB, etc., or components thereof) in accordance with various example embodiments of the present disclosure. [Figure 11] FIG. 1 is a flow diagram illustrating an example method (e.g., procedure) at a second RAN node (RNN, e.g., eNB, gNB, ng-eNB, etc., or components thereof), in accordance with various example embodiments of the present disclosure. [Figure 12] 1 is a flow diagram illustrating an example method (e.g., procedure) in a user equipment (UE, e.g., wireless device, IoT device, etc., or components thereof), in accordance with various example embodiments of the present disclosure. [Figure 13] 1 is a block diagram of an example wireless device or UE, in accordance with various example embodiments of the present disclosure. [Figure 14] 1 is a block diagram of an example network node, in accordance with various example embodiments of the present disclosure. [Figure 15] FIG. 1 is a block diagram of an example network configured to provide over-the-top (OTT) data services between a host computer and a UE, in accordance with various example embodiments of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0041] Some of the embodiments contemplated herein are more fully described with reference to the accompanying drawings, however, other embodiments are within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as being limited to only the embodiments described herein, but rather, these embodiments are provided as examples to convey the scope of the subject matter to those skilled in the art.

[0042] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field unless a different meaning is clearly given and / or is implied by the context in which they are used. References to elements, apparatus, components, means, steps, etc. are to be interpreted openly as referring to at least one of the elements, apparatus, components, means, steps, etc., unless expressly stated otherwise. The steps of the methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is clearly described as following or preceding another step, and / or unless it is implicitly indicated that a step must precede or follow another step. Any feature of an embodiment disclosed herein may be applied to other embodiments, as appropriate. Similarly, any advantage of an embodiment may be applied to other embodiments, and vice versa.

[0043] Additionally, the following terminology is used throughout the following description:

[0044] Wireless Node: As used herein, a "wireless node" is either a "wireless access node" or a "wireless device."

[0045] Radio Access Node: As used herein, a “radio access node” (or “radio network node”, “radio access network node” or “RAN node”) may be any node in a Radio Access Network (RAN) of a cellular communications network that operates to transmit and / or receive signals wirelessly. Some examples of a radio access node include a base station (e.g., a New Radio (NR) base station (gNB / en-gNB) in a 3GPP® Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB / ng-eNB) in a 3GPP® LTE network), base station distributed components (such as CU and DU), base station control and / or user plane components ( The RAN node may include, but is not limited to, a base station (e.g., a CU-CP, CU-DU, etc.), a high power or macro base station, a low power base station (e.g., a micro, pico, femto or home base station, etc.), an integrated access backhaul (IAB) node, a transmission point, a remote radio unit (RRU or RRH), and a relay node. Thus, the term "RAN node" may apply to any of, for example, a gNB, eNB, en-gNB, ng-eNB, gNB-CU, gNB-CU-CP, gNB-CU-UP, eNB-CU, eNB-CU-CP, eNB-CU-UP, IAB node, IAB donor DU, IAB donor CU, IAB-DU, IAB-MT, O-CU, O-CU-CP, O-CU-UP, O-DU, O-RU, or O-eNB.

[0046] Core Network Node: As used herein, a "core network node" is any type of node in a core network. Examples of core network nodes include a Mobility Management Entity (MME), a Serving Gateway (SGW), a Packet Data Network Gateway (P-GW), an Access and Mobility Management Function (AMF), a Session Management Function (AMF), a User Plane Function (UPF), a Service Capability Exposure Function (SCEF), etc.

[0047] Wireless Device: As used herein, a "wireless device" (or "WD" for short) is any type of device that can access (i.e., be served by) a cellular communications network by wirelessly communicating with network nodes and / or other wireless devices. Wireless communication may include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared, and / or other types of signals suitable for carrying information over the air. Examples of wireless devices include, but are not limited to, smartphones, mobile phones, cell phones, voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback appliances, wearable devices, wireless endpoints, mobile stations, tablets, laptops, laptop embedded equipment (LEE), laptop mounted equipment (LME), smart devices, wireless customer premises equipment (CPE), mobile type communication (MTC) devices, Internet-of-Things (IoT) devices, in-vehicle wireless terminal devices, and the like. Unless otherwise noted, the term "wireless device" is used interchangeably with "user equipment" (or "UE").

[0048] Network Node: As used herein, a "network node" is any node that is part of either the radio access network (e.g., radio access node or equivalent names as described above) or the core network (e.g., core network node as described above) of a cellular communications network. Functionally, a network node refers to a device that is configured, arranged and / or operable to communicate directly or indirectly with wireless devices and / or to communicate with other network nodes or equipment in the cellular communications network to enable and / or provide wireless access for wireless devices and / or to perform other functions (e.g., management) in the cellular communications network.

[0049] · The terms "QoE measurement report", "QoE report", "measurement report", and "report" are used interchangeably.

[0050] · The terms "QoE measurement configuration", "QoE measurement", "QoE configuration" and "application layer measurement configuration" are used interchangeably.

[0051] · The terms "Service" and "Application" are used interchangeably.

[0052] · The terms "MCE" and "TCE" are used interchangeably.

[0053] It should be noted that the description herein focuses on 3GPP® cellular communication systems, and thus 3GPP® terminology or terms similar to 3GPP® terminology are often used. However, the concepts disclosed herein are not limited to 3GPP® systems. Furthermore, although the term "cell" is used herein, it should be understood that a beam is used instead of a cell (particularly with respect to 5G NR), and thus the concepts described herein apply equally to both cells and beams.

[0054] As briefly summarized above, 3GPP Rel-17 agreed to provide visibility of QoE reports to RAN nodes so that the RAN nodes can adapt various aspects of performance based on UE QoE measurements. However, various issues, challenges, and / or difficulties exist in adapting traditional QoE measurements for use by RAN nodes in this manner, as will be explained in more detail after the description of LTE and NR network architectures.

[0055] One approach for handling QoE measurements for a UE when setting up and operating a dual connection in which a first network node acts as a MN and a second network node acts as a SN is to perform QoE measurements by a first RAN node, - Creating a QoE configuration for a UE; and -Transmitting all or a part of the QoE configuration to the UE; - transmitting all or part of the QoE configuration to the second network node when configuring or reconfiguring the SN, where the SN-related QoE configuration and the MN-related QoE configuration may be different; Possibly receiving QoE measurement data from a second network node; and The method may include the steps of:

[0056] This approach may also satisfy the requirement that measurements should continue until the end of a session even if the UE moves out of the area during the session, which can be achieved, for example, by having the network control the start and stop of measurements by area updates. For example, in one approach, the network may send a release command to release the QoE measurements. Session feedback indications may be used by the network, for example, as an aid to know when to stop the measurements. These approaches may be used, for example, when the UE performs a handover or re-establishes a connection to a cell controlled by a node outside the configured area.

[0057] Another approach to QoE measurements involves what are referred to as "lightweight" QoE measurements, which are QoE-related measurements that complement QoE metrics (also referred to as "traditional QoE measurements" in the remainder of this document). According to this approach, the RAN node can configure wireless terminals with lightweight QoE measurements.

[0058] As used herein, the term "lightweight QoE measurement" (or "lightweight QoE metric") refers to a measurement that differs at least from any of the legacy QoE measurements defined in 3GPP TS 26.247, 26.114, 26.118, and 26.346 and requires fewer information bits to be transmitted than the corresponding legacy QoE measurement. The term "RAN-visible" is used synonymously herein with "lightweight QoE measurement." Similarly, the terms "condensed," "compact," "simplified," and "more abstract" may be used synonymously with "lightweight" in the context of a format or representation of a QoE measurement, metric, or data. For example, a lightweight QoE measurement may be an encoded and / or compressed version of a legacy QoE measurement, and the lightweight QoE measurement may not convey the same granularity of information as the legacy QoE measurement. As a more specific example, the lightweight QoE measure may be an integer, or may be a binary flag representing a corresponding legacy QoE measure that is a larger integer, a real value, an array of values, etc.

[0059] In some cases, the above "encoding" may be a mapping between the actual measurements and binary, integer, or enumerated values. In other cases, the legacy QoE measurements may be input to an artificial intelligence (AI) / machine learning (ML) system, neural network-based model, or other algorithm to generate a simplified metric of the user's QoE (e.g., a single-valued quality rate / score / index, etc.) for implementing a particular service. In some cases, multiple legacy QoE measurements (e.g., data throughput, delay, jitter, etc.) may be input to such an algorithm to generate a single metric that represents all QoE aspects covered by the multiple legacy QoE measurements. However, in other cases, the single metric may represent only a subset of all QoE aspects covered by the legacy QoE measurements, such as those deemed most relevant based on pre-determined criteria.

[0060] However, there are some open issues, e.g., no coordination mechanism between RAN nodes for handling lightweight QoE has been defined. In some scenarios where both the first and second RAN nodes are involved in attachment procedures (MR-DC, mobility, resume and re-establishment, etc.) for a wireless terminal / UE and the first RAN node configures the UE with RAN visible (lightweight) QoE measurements in addition to or independent of legacy QoE measurements, the second RAN node is not aware of the following: - status information of RAN visible (lightweight) QoE measurements configured in the radio terminal; - the status of radio measurements (e.g. MDT) configured in the radio terminal and associated with the RAN visible (lightweight) QoE measurements; -Actions to be performed regarding QoE measurements configured in the wireless terminal: Request of the first RAN node to receive, for example, a RAN visible QoE measurement report For example, a request to forward a RAN visible QoE measurement report to the first RAN node -Whether the RAN visible (lightweight) QoE measurement reports have been notified to the TCE.

[0061] Since the second RAN node is not aware of the above mentioned status and actions, it may tamper with (e.g., overwrite) the ongoing QoE measurements configured for the UE. Furthermore, currently, it is not possible for a distributed unit of the gNB, e.g., gNB-DU, to read and use the contents of the RAN visible (lightweight) QoE reports.

[0062] In this document a solution is introduced that enables coordination between RAN nodes (directly, e.g. via Xn or X2 interfaces, or indirectly, e.g. via core network and NG or S1 interfaces) and between RAN nodes and radio terminals via transfer of configuration and configuration status information of configured RAN visible QoE. The solution described here can be applied to any scenario involving at least two RAN nodes, such as mobility (handover, conditional handover, DAPS handover, etc.), dual or multi-connectivity, RRC resumption and RRC re-establishment.

[0063] These solution embodiments may include some or all of the following actions for the first RAN node, the second RAN node and the wireless terminal:

[0064] 1. According to some methods proposed herein, the first RAN node transmits the following information about the radio terminal to the second RAN node during a mobility procedure (e.g. handover, conditional handover, DAPS handover, etc.), a dual connectivity procedure, an RRC connection resumption procedure or an RRC connection re-establishment procedure, the information including at least one of the following RAN visible (lightweight) QoE measurement configuration information: Indication of the service type for which RAN visible (lightweight) QoE is configured; · An indication of whether a session related to an application of a service type for which RAN visible (lightweight) QoE configuration is configured is ongoing; An indication of the type of QoE measurement, such as managed, signaling-based, or hybrid (a combination of managed and signaling-based QoE); An indication of whether the first RAN node is interested in receiving RAN visible (lightweight) QoE measurement results (or parts of the RAN visible QoE measurements) when the QoE measurements are delivered from the wireless terminal to the second RAN node. In other words, if the indication indicates that the first RAN node is interested in receiving RAN visible (lightweight) QoE measurement results, this indication indicates a request from the first RAN node to the second RAN node to have the RAN visible (lightweight) QoE measurement report shared with the first node when the RAN visible (lightweight) QoE measurement report is delivered from the wireless terminal to the second RAN node. The second RAN node may send the normal QoE report, i.e. the non-RAN visible part, to the TCE / MCE without forwarding it to the first RAN node. An indication that a RAN visible (lightweight) QoE report has been received along with information about a second RAN node; · An indication signalled together with the RAN visible (lightweight) QoE report, indicating whether the report has already been signalled to the TCE; Such indications are signaled together with QoE measurement configuration information, including the size of the report to be signaled to the TCE, and optionally the frequency with which QoSE reports are signaled to the TCE. ·RAN visible (lightweight) QoE reports received from wireless terminals; The transfer of this information may optionally be conditioned on; the RAN visible (lightweight) QoE report includes information about the second RAN node; and / or o that the second RAN node has previously indicated that it wishes RAN visible (lightweight) QoE reports from the wireless terminal to be forwarded to the second RAN node; Transferring one or a list of RAN visible (lightweight) QoE reports or a part of the RAN visible (lightweight) QoE measurements of one or more UEs from a central unit (e.g. gNB-CU) to a distributed unit (e.g. gNB-DU), e.g. via the 3GPP® F1 interface.

[0065] 2. In another method according to the techniques described herein, a second RAN node receiving the RAN visible (lightweight) QoE configuration and status information may perform at least one of the following actions: · Receive RAN visible (lightweight) QoE measurement configuration from the first RAN node. Configure the radio resources required to receive RAN visible (lightweight) QoE measurements from the UE. The radio resources may include any type of radio bearer, such as SRB1, SRB2, SRB3, SRB4, etc. Based on the received RAN visible (lightweight) QoE configuration status information, determining whether to reconfigure the wireless terminal with a new RAN visible (lightweight) QoE configuration. o In one non-limiting exemplary embodiment, the second RAN node must not reconfigure the UE with existing / pre-configured signaling based on the lightweight QoE configuration. · Prepare for receiving RAN visible (lightweight) QoE measurement reports from radio terminals via radio bearers such as SRB1, SRB2, SRB3, and SRB4. · Receive RAN visible (lightweight) QoE measurement reports from wireless terminals. · Forwarding the RAN visible (lightweight) QoE measurement report or at least a part of the RAN visible (lightweight) QoE measurement report to the first RAN node. · Forwarding the RAN visible (lightweight) QoE measurement report to at least one RAN node responsible for at least one of the cells having a cell ID indicated in the list of cell IDs attached to the RAN visible QoE measurement report. o As a further option, there may be one or more radio terminal context identifiers, such as one or more I-RNTIs, added to the RAN visible (lightweight) QoE report, such context identifiers being associated with one of the optionally added cell IDs. As another option, the cell ID added to the RAN visible (lightweight) QoE report can be replaced with a radio terminal context identifier such as the I-RNTI. Optionally, the RAN visible (lightweight) QoE report may be included in a message requesting context acquisition (i.e. acquisition of information related to the wireless terminal) in conjunction with an RRC connection re-establishment procedure or an RRC connection resumption procedure. Transferring one or a list of RAN visible (lightweight) QoE reports or a part of the RAN visible (lightweight) QoE measurements of one or more UEs from the central unit (e.g. gNB-CU) to the distributed unit (e.g. gNB-DU), for example via the 3GPP® F1 interface. Sending an indication to the first RAN node that a RAN visible (lightweight) QoE report has been received from the wireless terminal. This may be conditioned by the RAN visible (lightweight) QoE report including information about the first RAN node. Sending an indication to at least one RAN node serving at least one of the cells having a cell ID indicated in the list of cell IDs appended to the lightweight QoE measurement report, which indication informs each of the other RANs (which received the indication) that a RAN visible (lightweight) QoE report has been received from a radio terminal, the indication may include a radio terminal context identifier such as an I-RNTI and / or a QoE Reference ID. (A RAN node receiving such an indication may then choose to obtain a RAN visible (lightweight) QoE report from a second RAN node, more preferably selectively obtaining only the part of the RAN visible (lightweight) QoE report that is relevant (concerning) the RAN node.) If the second RAN node receives an indication of whether a RAN visible (lightweight) QoE report has been signaled to the TCE, together with a report size and / or a reporting frequency to the TCE, the second RAN node: Check whether the RAN visible (lightweight) QoE report received from the first RAN node has been signaled to the TCE, and if not, Continue adding new QoE measurements to the QoE report until the report reaches the report size configured as part of the QoE measurement configuration, and / or Continue adding new QoE measurements to the QoE report until the QoE reporting period (derived from how often the RAN reports QoE reports to the TCE) ends, after which the RAN acknowledges the report to the TCE. o If both the QoE report size and the reporting frequency of the QoE report are configured as part of the QoE measurement configuration, the RAN must signal a QoE report to the TCE when the first of these two conditions (report size or reporting period elapsed) is met.

[0066] 3. In another method according to the techniques described herein, a wireless terminal receiving a RAN visible (lightweight) QoE configuration from a first RAN node may perform at least one of the following actions: - Log RAN visible (lightweight) QoE measurement reports when they are received from higher layers (such as the application layer). Logging serving cell measurements as part of a list next to the RAN visible QoE measurements. Serving cell measurements can be logged periodically or based on configured events and thresholds. · Logging the list of serving cells associated with cell identifiers such as global cell ID, physical cell ID, cell frequency etc., and active BWP information configured as part of RAN visible QoE measurements. Logging the context identifiers of the wireless terminals associated with the serving cell. · Reporting RAN visible (lightweight) QoE measurements comprising the above mentioned information to at least one serving cell via a radio bearer configured for QoE measurement reporting. Optionally, the wireless terminal may add a list of cell IDs to the RAN visible (lightweight) QoE report, the cell IDs representing the cells for which the content of the RAN visible (lightweight) QoE report was collected or created. o As another option, the radio terminal may add a list of radio terminal context identifiers associated with cells for which the contents of the RAN visible (lightweight) QoE report have been collected or created.

[0067] In various embodiments or examples, the above-mentioned actions of the first and second RAN nodes are performed in any mobility scenario (handover, conditional handover, DAPS handover, etc.) or any dual connectivity scenario (LTE-DC, EN-DC, NE-DC, NR-DC, etc.) where the first and second RAN nodes serve the wireless terminal simultaneously. This solution can also be applied to RRC restart and RRC re-establishment procedures. Some actions can be performed in conjunction with the RRC connection restart procedure.

[0068] These solutions enable mechanisms for transferring RAN visible (lightweight) QoE measurement configuration and status information between RAN nodes, allowing for appropriate processing of the measurements by the node receiving the information, the node transmitting the information, and / or both. Additionally, these mechanisms enable the gNB-CU to forward RAN visible (lightweight) QoE reports to the gNB-DU, so that the gNB-DU can use the RAN visible (lightweight) QoE measurements in its optimizations and algorithms. For example, the gNB-DU can use RAN visible QoE metrics such as buffer levels to adjust link adaptation and scheduling policies.

[0069] To put these technologies into context, Figure 3 illustrates an example overall architecture of a network including LTE and SAE as shown in Figure 1. E-UTRAN 100 includes one or more evolved Node Bs (eNBs), such as eNBs 105, 110, 115, and one or more user equipment (UE), such as UE 120. As used within 3GPP® standards, "user equipment" or "UE" refers to any wireless communication device (e.g., a smartphone or computing device) capable of communicating with network equipment conforming to 3GPP® standards, including E-UTRAN, UTRAN, and / or GERAN, commonly known as third generation ("3G") and second generation ("2G") 3GPP® RANs.

[0070] As specified by 3GPP, E-UTRAN 100 is responsible for all radio related functions in the network, including radio bearer control, radio admission control, radio mobility control, scheduling, dynamic allocation of resources to UEs in the uplink and downlink, and security of communications with UEs. These functions reside in eNBs, such as eNBs 105, 110, and 115. Each eNB can serve a geographic coverage area that includes one or more cells, including cells 106, 111, and 116 served by eNBs 105, 110, and 115, respectively.

[0071] The eNBs of the E-UTRAN communicate with each other via the X2 interface, as shown in Figure 1. The eNBs are also responsible for the E-UTRAN interface to the EPC 130, and in particular the S1 interface to the Mobility Management Entity (MME) and Serving Gateway (SGW), shown collectively in Figure 1 as MME / S-GW 134 and 138. In general, the MME / S-GW handles both the overall control of the UE and the data flow between the UE and the rest of the EPC. More specifically, the MME handles the signaling (e.g., control plane) protocols between the UE and the EPC, known as the non-access (NAS) protocols. The S-GW handles all Internet Protocol (IP) data packets (e.g., data or user plane) between the UE and the EPC, and serves as the local mobility anchor for data bearers as the UE moves between eNBs, such as eNBs 105, 110, and 115.

[0072] The EPC 130 may include a Home Subscriber Server (HSS) 131 that manages user and subscriber related information. The HSS 131 may also provide support functions for mobility management, call and session setup, user authentication and access authentication. The functions of the HSS 131 may be related to traditional Home Location Register (HLR) and Authentication Center (AuC) functions or operations. The HSS 131 may also communicate with the MMEs 134 and 138 via their respective S6a interfaces.

[0073] In some embodiments, the HSS 131 can communicate with a User Data Repository (UDR) (labeled EPC-UDR 135 in FIG. 3) via a Ud interface. The EPC-UDR 135 can store the user's credentials after they are encrypted by AuC algorithms. Because these algorithms are not standardized (i.e., vendor-specific), the encrypted credentials stored in the EPC-UDR 135 are not accessible to vendors other than the vendor of the HSS 131.

[0074] The multiple access scheme of the LTE PHY is based on Orthogonal Frequency Division Multiplexing (OFDM) with Cyclic Prefix (CP) in the downlink and Single Carrier Frequency Division Multiple Access (SC-FDMA) with Cyclic Prefix in the uplink. To support transmission in paired and unpaired spectrum, the LTE PHY supports both Frequency Division Duplex (FDD) (including both full-duplex and half-duplex operation) and Time Division Duplex (TDD). An LTE FDD downlink (DL) radio frame is of fixed duration of 10 ms and consists of 20 slots, labeled 0 to 19, each of which is of fixed duration of 0.5 ms. A 1 ms subframe consists of two consecutive slots, where subframe i consists of slots 2i and 2i+1.

[0075] As briefly mentioned above, the Dual Connectivity (DC) framework was introduced in LTE Rel-12. In LTE DC, a UE is configured with a Master Cell Group (MCG) associated with a Master eNB (MeNB) and a Secondary Cell Group (SCG) associated with a Secondary eNB (SeNB). Each CG contains a Primary Cell (PCell) and optionally one or more Secondary Cells (SCells). The term "Special Cell" (or "SpCell" for short) refers to the PCell of the MCG or the PSCell of the SCG depending on whether the Medium Access Control (MAC) entity of the UE is associated with an MCG or an SCG, respectively. In non-DC operation (e.g. CA), the SpCell refers to the PCell. The SpCell is always activated and supports Physical Uplink Control Channel (PUCCH) transmissions and contention-based random access by the UE.

[0076] 4 illustrates a high-level view of an example 5G network architecture including a Next Generation RAN (NG-RAN) 299 and a 5G Core (5GC) 298. The NG-RAN 299 may include a set of gNodeBs (gNBs) connected to the 5GC via one or more NG interfaces, such as gNBs 200, 250 connected via interfaces 202, 252, respectively. Additionally, the gNBs may be interconnected via one or more Xn interfaces, such as Xn interface 240 between gNBs 200 and 220. With respect to the NR interface to the UE, each gNB may support Frequency Division Duplexing (FDD), Time Division Duplexing (TDD), or a combination thereof.

[0077] NG-RAN 299 defines the NG-RAN architecture layered into Radio Network Layer (RNL) and Transport Network Layer (TNL), i.e. NG-RAN logical nodes and the interfaces between them are defined as part of the RNL. For each NG-RAN interface (NG, Xn, F1), the associated TNL protocols and functions are specified. The TNL provides user plane transport and signaling transport services. In some example configurations, each gNB is connected to all 5GC nodes within the "AMF domain" defined in 3GPP TS 23.501. If supported, NDS / IP is applied to secure CP and UP data over the TNL of the NG-RAN interface.

[0078] The NG-RAN logical node shown in FIG. 4 includes a central (or centralized) unit (CU or gNB-CU) and one or more distributed (or decentralized) units (DU or gNB-DU). For example, gNB 200 includes gNB-CU 210 and gNB-DU 220 and 230. The CU (e.g., gNB-CU 210) is a logical node that hosts higher layer protocols and performs various gNB functions such as controlling the operation of the DU. Each DU is a logical node that hosts lower layer protocols and may include various subsets of gNB functions depending on the functional division. Each of the CU and DU may include various circuits necessary to perform their respective functions, including processing circuits, transceiver circuits (e.g., for communication), and power circuits. Additionally, the terms "central unit" and "centralized unit" are used interchangeably herein, as are the terms "distributed unit" and "decentralized unit."

[0079] The gNB-CU connects to the gNB-DU via respective F1 logical interfaces, such as interfaces 222 and 232 shown in Figure 4. The gNB-CU and the connected gNB-DU are seen only as gNBs by other gNBs and 5GCs. In other words, the F1 interface is not visible beyond the gNB-CU. In the gNB split CU-DU architecture shown in Figure 4, DC can be realized by allowing a UE to connect to multiple DUs served by the same CU, or by allowing a UE to connect to multiple DUs served by different CUs.

[0080] FIG. 5 illustrates a high-level view of an exemplary 5G network architecture including a Next Generation Radio Access Network (NG-RAN) 399 and a 5G Core (5GC) 398. As illustrated, the NG-RAN 399 may include gNBs 310 (e.g., 310a,b) and ng-eNBs 320 (e.g., 320a,b) interconnected via respective Xn interfaces. The gNBs and ng-eNBs are connected to the 5GC 398 via an NG interface, and more specifically, to an AMF (Access and Mobility Management Function) 330 (e.g., AMF 330a,b) via respective NG-C interfaces and to a UPF (User Plane Function) 340 (e.g., UPF 340a,b) via respective NG-U interfaces. Additionally, the AMFs 330a,b may communicate with one or more Policy Control Functions (PCFs, e.g., PCFs 350a,b) and Network Publication Functions (NEFs, e.g., NEFs 360a,b).

[0081] Each gNB 310 can support an NR radio interface including frequency division duplexing (FDD), time division duplexing (TDD), or a combination thereof. Each ng-eNB 320 can support an LTE radio interface. However, unlike a conventional LTE eNB, the ng-eNB 320 connects to the 5GC via an NG interface. Each of the gNBs and ng-eNBs can serve a geographic coverage area that includes one or more cells, such as cells 311a-b and 321a-b shown in FIG. 3. Depending on the particular cell in which it is located, the UE 305 can communicate with the gNB or ng-eNB serving that particular cell via an NR or LTE radio interface, respectively. Although the gNB and ng-eNB are shown separately in FIG. 3, it is also possible for a single NG-RAN node to provide both types of functionality.

[0082] Figure 6 shows an example of the configuration of NR User Plane (UP) and Control Plane (CP) protocol stacks between the UE, gNB and AMF as shown in Figures 4 and 5. The physical (PHY), medium access control (MAC), radio link control (RLC), and packet data convergence protocol (PDCP) layers between the UE and gNB are common for UP and CP. The PDCP layer provides encryption / decryption, integrity protection, sequence numbering, reordering, and duplicate detection for both CP and UP. In addition, PDCP provides header compression and retransmission of UP data.

[0083] On the UP side, Internet Protocol (IP) packets arrive at the PDCP layer as Service Data Units (SDUs), and PDCP creates Protocol Data Units (PDUs) and delivers them to the RLC. As each IP packet arrives, PDCP starts a discard timer. When this timer expires, PDCP discards the associated SDU and the corresponding PDU. If the PDU is delivered to the RLC, PDCP indicates the discard to the RLC.

[0084] The RLC layer transfers PDCP PDUs to the MAC via logical channels (LCHs). RLC provides error detection / correction, concatenation, segmentation / reassembly, sequence numbering, and reordering of data transferred to and from the upper layers. If RLC receives a discard indication from an associated PDCP PDU that it has not sent to the lower layers, it discards the corresponding RLC SDU (or a segment of it).

[0085] The MAC layer provides mapping between LCH and PHY transport channels, LCH prioritization, multiplexing to / demultiplexing from transport blocks (TBs), Hybrid ARQ (HARQ) error correction, and dynamic scheduling (gNB side). The PHY layer provides transport channel services to the MAC layer and handles transmission over the NR air interface via modulation, coding, antenna mapping, beamforming, etc.

[0086] On the UP side, the Service Data Adaptation Protocol (SDAP) layer handles Quality of Service (QoS), including mapping between QoS flows and Data Radio Bearers (DRBs) and marking QoS Flow Identifiers (QFIs) in UL and DL packets. On the CP side, the Non-Access Stratum (NAS) layer sits between the UE and the AMF and handles UE / gNB authentication, mobility management, and security control.

[0087] The RRC layer is located below the NAS of the UE, but terminates in the gNB instead of the AMF. The RRC controls the communication between the UE and the gNB over the air interface and the mobility of the UE between cells in the NG-RAN. The RRC also broadcasts System Information (SI) and performs the establishment, configuration, maintenance, and release of DRBs and Signaling Radio Bearers (SRBs) used by the UE. In addition, the RRC controls the addition, modification, and release of the Carrier Aggregation (CA) and Dual Connectivity (DC) configurations of the UE. The RRC also performs various security functions such as key management.

[0088] After the UE is powered on, the UE is in RRC_IDLE state until an RRC connection with the network is established, at which point the UE transitions to RRC_CONNECTED state (e.g., data transfer may occur). After the network is disconnected, the UE returns to RRC_IDLE. In RRC_IDLE state, the UE radio is active with a discontinuous reception (DRX) schedule configured by higher layers. During the DRX active period (also called "DRX on period"), a UE in RRC_IDLE receives SI broadcasts in the cell where the UE is camped, performs measurements on neighboring cells to support cell reselection, and monitors the paging channel on the PDCCH for paging via the gNB from 5GC. An NR UE in RRC_IDLE state is not known to the gNB serving the cell where the UE is camped. However, NR RRC includes an RRC_INACTIVE state where the UE is known by the serving gNB (e.g., via the UE context). RRC_INACTIVE has some properties similar to the "suspended" state used in LTE.

[0089] As mentioned above, QoE measurements are specified for UEs operating in LTE networks and previous generation UMTS networks. Measurements in both networks operate according to the same high level principles. The aim is to measure the end user's experience when using a particular application on the network. For example, QoE measurements for streaming services and MTSI (Mobile Telephony Services over IMS) are supported in LTE.

[0090] QoE measurements can be initiated from the OAM node towards the RAN generally for a group of UEs (e.g. all UEs that meet one or more criteria) or from the CN towards the RAN for a specific UE. The measurement configuration contains the details of the measurement and is encapsulated in a container that is transparent to the RAN.

[0091] The "TRACE STAR" S1AP message is used by the LTE EPC to initiate QoE measurements by a specific UE. This message carries details about the measurement configuration that the application should collect in the "Application Layer Measurement Configuration Container" IE, which is transparent to the RAN. This message also contains the details necessary to reach the TCE to which the measurements should be sent.

[0092] Figures 7A-7D show various procedures between UMTS RAN (UTRAN) and UE for QoE measurements in legacy UMTS networks. These are similar to those specified in LTE (E-UTRAN). As shown in Figure 7A, UTRAN can send a UE Capability Inquiry message to request the UE to report its application layer measurement capabilities. As shown in Figure 7B, the UE can provide its application layer measurement capabilities to the UTRAN via a UE Capability Information message, in particular a "Measurement Capability" IE which contains information related to the UE capability to perform QoE measurement collection for streaming services and / or MTSI services. Table 1 below shows an example of the content of this IE.

[0093] [Table 1]

[0094] The UTRAN can respond with a UE Capability Information Confirm message. Figure 5C shows that the UTRAN can send a Measurement Control message including an "Application Layer Measurement Configuration" IE to configure QoE measurements in the UE. Table 2 below shows an example of the content of this IE.

[0095] [Table 2]

[0096] Figure 7D shows that the UE can send the QoE measurement results to the TCE via the UTRAN using a Measurement Report message that includes the "Application Layer Measurement Report" IE. Table 3 below shows an example of the content of this IE.

[0097] [Table 3]

[0098] As mentioned above, Figures 1 and 2 show the procedure between E-UTRAN and UE for configuring QoE measurements in an LTE network. Figure 1 shows an example of a UE capability transfer procedure used to transfer UE radio access capability information from the UE to the E-UTRAN. First, the E-UTRAN can send a UECapabilityEnquiry message similar to the configuration shown in Figure 7A. The UE can respond with a UECapabilityInformation message including the "UE-EUTRA-Capability" IE.

[0099] This IE may further include a UE-EUTRA-Capability-v1530 IE, which may be used to indicate whether the UE supports QoE measurement collection for streaming services and / or MTSI services. In particular, the UE-EUTRA-Capability-v1530 IE may include a measParameters-v1530 IE, which includes information about the measurement support of the UE. In some cases, the UE-EUTRA-Capability IE may include a "UE-EUTRA-Capability-v16xy-IE", which may include a qoe-Extensions-r16 field. Figure 8A shows an example ASN.1 data structure of these various IEs with the various fields defined in Table 4 below.

[0100] [Table 4]

[0101] FIG. 8B illustrates an example ASN.1 data structure for the qoe-Reference parameter described in Table 4 above.

[0102] 9A-9C illustrate various aspects of UE QoE measurement collection in an LTE network. In particular, FIG. 9A illustrates an example signal flow of a QoE measurement collection process in LTE. To initiate QoE measurements, the serving eNB sends an RRCConnectionReconfiguration message including a QoE configuration file (e.g., measConfigAppLayer IE in OtherConfig IE) to the UE in RRC_CONNECTED state. As described above, the QoE configuration file is an application layer measurement configuration received by the eNB (e.g., from the EPC) encapsulated in a transparent container and forwarded to the UE in an RRC message. The UE responds with an RRCConnectionReconfigurationComplete message. The UE then performs the configured QoE measurements and sends a MeasReportAppLayer RRC message including a QoE measurement result file to the eNB. Although not shown, the eNB can forward this result file transparently (e.g., to the EPC).

[0103] Figure 9B shows an example of the ASN.1 data structure of the measConfigAppLayer IE. The configuration includes a transparent container, measConfigAppLayerContainer, that specifies the QoE measurement configuration of the target application. In the serviceType field, a value of "qoe" indicates quality of experience measurement collection for streaming services, and a value of "qoemtsi" indicates extended quality of experience measurement collection for MTSI. This field also includes various reserved values.

[0104] 9C shows an example ASN.1 data structure of the measReportAppLayer IE, which allows the UE to send QoE measurements of an application (or service) to the E-UTRAN (e.g. via SRB4). The service for which the report is being sent is indicated in the serviceType IE.

[0105] As specified in 3GPP TS 28.405, an LTE RAN node (i.e., eNB) can temporarily stop and resume QoE measurement reporting if an overload situation is observed. This behavior can be summarized as follows: In case of RAN overload, the eNB can temporarily stop UE reporting by sending an RRCConnectionReconfiguration message to the associated UE with a measConfigAppLayer IE (in otherConfig) configured to temporarily stop application layer measurement reporting. The application may stop reporting and stop recording further information. Once the overload situation in the RAN ends, the eNB can resume UE reporting by sending an RRCConnectionReconfiguration message to the associated UE with a measConfigAppLayer IE (in otherConfig) configured to resume application layer measurement reporting. The application resumes reporting and recording if they were stopped.

[0106] In general, the RAN (such as E-UTRAN or NG-RAN) is not aware of the ongoing streaming session of the UE or when QoE measurements are performed by the UE. Nevertheless, it is important for the client or management function analysing the measurements to measure the entire streaming session. Therefore, it is beneficial for the UE to keep the QoE measurements throughout the session, even during handover situations. However, it is an implementation decision when the RAN stops the QoE measurements. It may be done, for example, when the UE moves out of the measurement area, due to a handover, etc.

[0107] In addition to QoE measurements, the UE may be configured to perform and report measurements in support of Minimization of Drive Testing (MDT), which aims to mitigate and / or minimize the requirement for manual testing of real network performance (i.e., by driving near the geographical coverage of the network). The MDT functionality was first studied in LTE Rel-9 (e.g., 3GPP TR36.805) and first standardized in Rel-10. MDT can address various network performance improvements such as coverage optimization, capacity optimization, mobility optimization, quality of service (QoS) verification, parameterization of common channels (e.g., PDSCH), etc.

[0108] The UE may be configured to perform logged MDT measurements and / or instantaneous MDT measurements. A UE in RRC_IDLE state may be configured (e.g., via a LoggedMeasurementConfiguration RRC message from the network) to perform periodic MDT measurement logging. The received MDT configuration may include logginginterval and loggingduration. Upon receiving the configuration, the UE starts a timer (T330) set to loggingduration (e.g., 10-120 minutes) and performs periodic MDT logging every logging interval (1.28-61.44 seconds) within loggingduration while the UE is in RRC_IDLE state. In particular, the UE collects received strength and quality of DL reference signals (i.e., RSRP, RSRQ) based on existing measurements required for cell reselection purposes. The UE reports the collected / logged information to the network upon returning to RRC_CONNECTED state. Figure 4 shows an example of a logged MDT procedure performed by a UE.

[0109] In contrast, a UE may be configured to perform and report instantaneous MDT measurements when in RRC_CONNECTED state. Similar to logged MDT, instantaneous MDT measurements are based on existing UE and / or network measurements performed while the UE is in RRC_CONNECTED and may include any of the following measurement quantities: M1: RSRP and RSRQ measurements by UE M2: Power headroom measurement by UE M3: Received interference power measurement by eNB M4: eNB measures DL and UL data volume per QoS Class Indicator (QCI) per UE M5: Scheduled IP layer throughput per RAB per UE per DL and per UL MDT measurement by eNB, per UE per DL and per UE per UL M6: DL and UL packet delay measurements per QCI per UE, refer to UL PDCP delay by UE and packet delay in DL per QCI by eNB M7: Measurement of DL and UL packet loss rate per QCI per UE by eNB M8: Received signal strength (RSSI) measurements by the UE M9: Measurement of round trip time (RTT) by UE

[0110] For example, reporting of M1 measurements may be event triggered according to existing RRM configurations for either events A1-A6 or B1-B2. Furthermore, M1 reporting can be periodic, A2 event triggered, or A2 event triggered periodic according to MDT specific measurement configurations. As another example, reporting of M2 measurements may be based on receipt of a Power Headroom Report (PHR), while reporting of M3-M9 may be triggered by expiration of a measurement collection period.

[0111] However, as mentioned above, reconfiguring the UE's connection after the first RAN has configured it for lightweight QoE measurements may result in the second RAN unknowingly tampering with ongoing measurements. Transferring configured RAN visible QoE configuration and configuration status information allows coordination between RAN nodes (e.g. directly via Xn or X2 interfaces, or indirectly via the core network and NG or S1 interfaces) and the wireless terminal. The solution described here may be applied to any scenario involving at least two RAN nodes, such as mobility (handover, conditional handover, DAPS handover, etc.), dual or multi-connectivity, RRC resumption, and RRC re-establishment.

[0112] These solutions may be explained by first detailing techniques related to a first RAN node, i.e., a node that configures a UE with QoE measurements in some of the scenarios briefly described above. According to various scenarios, this first RAN node is associated with a second RAN node by actions or signaling procedures involving both the first and second RAN nodes, such as dual connectivity, mobility, RRC resumption, RRC re-establishment, switching the transfer of data for a service from a path towards the UE via the first RAN node to a path towards the UE via the second RAN node (non-limiting examples). The first RAN node configures the wireless terminal with RAN visible (lightweight) QoE measurements or forwards the RAN visible (lightweight) QoE configuration that may be received from the OAM to the wireless terminal.

[0113] Figure 10 is a process flow illustrating an exemplary method in accordance with the techniques described immediately above and generally herein for a first RAN node. In a first approach in accordance with various presently disclosed techniques, the first RAN node transmits configuration information regarding RAN-visible (lightweight) QoE measurements to the second RAN node, the configuration information being associated with at least one of the RAN-visible (lightweight) QoE measurement configurations that the first RAN node has configured in the wireless terminal for QoE purposes. This is illustrated in block 1010 of Figure 10. The configuration information regarding RAN-visible (lightweight) QoE measurements may include one or more of the following: - Information about configured RAN visible (lightweight) QoE measurements o An indication of the wireless terminals for which the first RAN node has configured lightweight QoE measurements, or a list of such wireless terminals. This indication may have the form of an identifier of the wireless terminal. o RAN visible (lightweight) QoE measurement configurations and / or QoE measurement reports sent by the first RAN node to UEs currently being served (or soon to be served) by the second RAN node ■ Optionally, together with such configuration, the first RAN node may include an indication of whether an application session of the service type or service subtype that is the subject of the QoE measurement configuration is in progress. An indication or a list of indications indicating at least one of the lightweight QoE measurements configured on the wireless terminal. ■ Optionally, along with such an indication, the first RAN node may include an indication of whether an application session of the service type or service subtype that is subject to the QoE measurement configuration is ongoing. A reference or list of references, such as a list of one or more QoE Reference IDs associated with the configured lightweight QoE measurement ■ Optionally, along with such reference, the first RAN node may include an indication of whether an application session of the service type or service subtype that is the subject of the QoE measurement configuration is ongoing. Indication of the type of RAN visible (lightweight) QoE measurements configured, such as management-based QoE, signaling-based QoE, or a hybrid / combined type of management-based and signaling-based A list of indications of the service types or service subtypes for which RAN visible lightweight QoE is configured o An indication per service type or per service subtype, or a list of indications per service type or per service subtype, indicating whether each RAN visible lightweight QoE measurement is configured but not activated, activated, suspended or deactivated. Indication that per-slice RAN visible (lightweight) QoE measurements are enabled and a list of the corresponding S-NSSAIs An indication or list of indications regarding the MCE associated with the configured RAN visible lightweight QoE measurements An indication that the second RAN node considers the configured RAN visible lightweight QoE measurements to be valid for a certain period of time or up to a given time of day. - An indication of the time when a radio measurement was made, e.g. an MDT measurement, linked to the QoE measurement. * Application session indication an indication that an application session has been initiated at the wireless terminal if the first RAN node has transmitted to the second RAN node a lightweight QoE measurement configuration targeted at the service type or service subtype to which the application belongs, or an indication that such a lightweight QoE measurement configuration has been configured at the wireless terminal. ■Optionally, a lightweight QoE measurement configuration targeted at the service type or service subtype to which the application belongs, or an indication that such a configuration has been sent to the wireless terminal, may be sent to the second RAN node in the same message as an indication of the start of the application session. if the first RAN node has transmitted to the second RAN node a lightweight QoE measurement configuration targeted to the service type or service subtype to which the application belongs, an indication that such a lightweight QoE measurement configuration has been configured in the wireless terminal, and / or an indication that a related application session has been started in the wireless terminal, an indication that the application session has been stopped in the wireless terminal. ■ Optionally, the RAN visible (lightweight) QoE report received from the wireless terminal may be sent to the second RAN node along with an indication that the application session has stopped at the wireless terminal. ■As another option, an indication of the presence of a RAN visible (lightweight) QoE report received from the wireless terminal may be sent to the second RAN node along with an indication that the application session has stopped at the wireless terminal. an identifier or list of identifiers (e.g. QoE Reference ID or a newly defined Reference ID) that links this lightweight QoE measurement (or list of lightweight QoE measurements) to a legacy QoE measurement (or list of legacy QoE measurements) and / or an MDT measurement (or list of legacy QoE measurements) o Information about the type of radio measurements, such as MDT measurements, that were performed in coupling with the QoE measurements. As MDT measurements may not be continued at handover, this information allows the target to configure the same type of radio measurements at the target node. The information may for example be in the form of measConfig or measID connected to measConfig. This information may be any kind of identification of the radio measurements. If a group of UEs is simultaneously undergoing one of the above signaling procedures of interest (dual connectivity, mobility, RRC resumption, RRC re-establishment, etc.), the actions and corresponding measurement status transfer signaling described herein may carry multiple UEs (e.g., a list of measurements configured for all UEs currently undergoing handover). Note that, for example, signaling procedures for mobility, RRC resumption and RRC re-establishment are typically performed for one UE at a time, so the above-mentioned status information transfer for a group of UEs may be performed with a newly defined procedure.

[0114] In a second technique according to various embodiments disclosed herein, the first RAN node sends a request to the second RAN node for a lightweight QoE measurement associated with one (or a list) of RAN visible lightweight QoE measurements that the first RAN node has configured the wireless terminal for QoE measurement. An example is shown in block 1020 of Figure 10. The request may include one or more of the following: -Requirements for configured RAN visible lightweight QoE measurements A request to transmit (or buffer and subsequently transmit to the first RAN node) the QoE reports received by the second RAN node. The request optionally contains the following additional conditions related to starting and stopping such reports: ■ (Signaling) radio bearer reconfiguration in the UE resulting in switching of the RAN node receiving the QoE report, overload indication sent from the first RAN node to the second RAN node, time period until session termination, time period until a subsequent mobility event is triggered, time period until further UE reconfiguration, service type or service subtype, slice or list of slices, etc. * Requirement to support receipt of RAN visible lightweight QoE reports A request to suspend one or a list of activated RAN visible lightweight QoE measurements A request to resume one or a list of paused RAN visible lightweight QoE measurements A request to release or stop one or a list of activated RAN visible lightweight QoE measurements ■In a first example relating to inter-RAT or inter-system mobility, the second RAN node belongs to a RAT or system that does not support one or more of the service types or service subtypes relevant to the ongoing RAN visible lightweight QoE measurements, which means that the measurements related to these service types and / or subtypes are released or suspended. In another example, when a procedure (e.g., related to dual connectivity operation) is about to be triggered and the first RAN node that configured the UE for QoE measurements receives an indication (e.g., from OAM) that the complete set or a portion of the ongoing QoE measurements have been stopped or paused. A requirement to configure the UE with a specific configuration of RAN visible lightweight measurements or a specific configuration of radio measurements linked to QoE measurements - An indication, signaled together with the RAN visible (lightweight) QoE report, of whether the report has already been signaled to the TCE Such indications are signaled together with QoE measurement configuration information, including the size of the report to be signaled to the TCE and, optionally, the frequency with which QoSE reports are signaled to the TCE. - If the operations related to the second embodiment need to be performed for a group of UEs, the described requests related to multiple UEs can be carried in the same message (e.g. a list of measurements configured for all UEs currently undergoing handover is carried in the same Xn / X2 / NG / S1 message). Note that, since signaling procedures for e.g. mobility, RRC resumption and RRC re-establishment are usually performed for one UE at a time, the above mentioned status requests for a group of UEs can be performed with newly defined procedures. o In a sub-embodiment, requests relating to multiple UEs may be of the same type for all UEs (in which case a single request type indication is needed for the entire list of UEs) or may be of different types for different UEs (where this includes UEs having the same request type indicated in various request type lists for a group of multiple UEs).

[0115] In all of the above, multiple types of requests relating to the same UE or the same QoE measurement configuration may be conveyed in the same message (i.e. multiple requests per UE or QoE measurement configuration may be included in the same message from the first RAN node to the second RAN node).

[0116] Other aspects of the techniques disclosed herein may be described with respect to the second RAN node described in the various scenarios above, i.e., a node that receives specific information from the first RAN node regarding previous QoE measurement configurations for the UE. This second RAN node is associated with the first RAN node by operations or signaling procedures involving both the first and second RAN nodes, such as dual connectivity, mobility, resumption, re-establishment, etc. Figure 11 is a process flow diagram of an exemplary method in the second RAN node in accordance with these techniques.

[0117] In some embodiments, the second RAN node receives configuration information from the first RAN node regarding RAN visible lightweight QoE measurements associated with one (or a list) of lightweight QoE measurements that the first RAN node has configured in the wireless terminal for RAN visible (lightweight) QoE measurements. This is shown in block 1110 of Figure 11. This configuration information for RAN visible lightweight QoE measurements may include information detailed in the embodiment regarding the first RAN node above.

[0118] In some of these and other embodiments, the second RAN node receives requests from the first RAN node for RAN visible lightweight QoE measurements associated with one (or list) lightweight QoE measurements that the first RAN node has configured in its radio communications for QoE measurements. An example is shown in block 1120 of Figure 11. These requests may include any of the requests detailed in the embodiments for the first RAN node above.

[0119] Upon receiving the RAN visible lightweight QoE measurement results from the wireless terminal (e.g. within or added / associated with the QoE report) in response to the request for RAN visible lightweight QoE measurements from the first RAN node, the second RAN node forwards at least a portion of the RAN visible (lightweight) QoE measurement results to the first RAN node. The forwarding of the RAN visible lightweight QoE measurement results may be performed by any of the following approaches: Through the Xn interface, if there is a direct Xn interface between the two RAN nodes. The information can be encapsulated in containers in the form of inter-node RRC messages within XnAP messages. Through the X2 interface, if there is a direct x2 interface between the two RAN nodes. The information can be encapsulated in containers in the form of node-to-node RRC messages within X2AP messages. Through the NG interface, if there is an NG interface between the two RAN nodes through the core network. The information can be encapsulated in containers in the form of node-to-node RRC messages within network messages. - Via NG and S1 interfaces, in case of inter-system mobility or multi-connectivity scenarios, when two RAN nodes are connected via NG and S1 interfaces. The information can be encapsulated in containers in the form of node-to-node RRC messages within network messages. In another embodiment, if the second RAN node receives an indication of whether a RAN visible (lightweight) QoE report has been signaled to the TCE along with a QoE measurement configuration including report size and / or reporting frequency to the TCE, the second RAN node should: Check whether the RAN visible (lightweight) QoE report received from the first RAN node has been signaled to the TCE, and if not, ■Continue adding new QoE measurement results to the QoE report until the report reaches the report size configured as part of the QoE measurement configuration, and / or ■ Continue adding new QoE measurement results to the QoE report until the QoE reporting period (derived from how often the RAN reports QoE reports to the TCE) ends, after which the RAN notifies the TCE of the report. ■If both the QoE report size and the reporting frequency of the QoE report are configured as part of the QoE measurement configuration, the RAN must signal a QoE report to the TCE when the first of these two conditions (report size or reporting period expiration) is met. As a further option, the RAN node can signal a QoE report to the TCE if the UE leaves its current serving cell and thereby also leaves at least the area scope configured for the RAN visible (lightweight) QoE configuration. In response to a request of one of the previously indicated types from the first RAN node, the second RAN node may transmit an indication of the status of the execution of the request, such status indication may indicate "success", "rejected", "pending", "partially successful-partially rejected", or "partially pending-partially rejected" (other indications of execution status are not excluded). In one embodiment, upon receiving a QoE measurement configuration associated with the UE or an indication of a QoE measurement configuration associated with the UE from the first RAN node (the UE is being served by the second RAN node or will be served by the second RAN node after completion of an ongoing or prepared mobility or dual / multiple connectivity operation), or at any time when the UE is being served by the second RAN node and the associated QoE measurement configuration is still present and valid, the second RAN node may send an MDT or RRM measurement configuration to the first RAN node for forwarding to the UE, which MDT or RRM measurement configuration may optionally be linked to the QoE measurement configuration, e.g. for synchronization and / or coordination between the QoE measurements and the MDT and / or RRM measurements. In another embodiment, upon receiving a QoE measurement configuration associated with the UE or an indication of a QoE measurement configuration associated with the UE from the first RAN node (the UE is being served by the second RAN node or will be served by the second RAN node after completion of an ongoing or prepared mobility or dual / multiple connectivity operation), or at any time while the UE is being served by the second RAN node and the associated QoE measurement configuration is still present and valid, the second RAN node may send a request to the first RAN node to configure the UE with MDT or RRM measurements that may be linked to the particular QoE measurement configuration, e.g. for synchronization and / or coordination of QoE measurements with MDT and / or RRM measurements.

[0120] In yet another embodiment, upon receiving a QoE measurement configuration associated with the UE or an indication of a QoE measurement configuration associated with the UE from the first RAN node (the UE is being served by the second RAN node or will be served by the second RAN node after an ongoing or prepared mobility or dual / multiple connectivity operation is completed), or at any time when the UE is being served by the second RAN node and the associated QoE measurement configuration is still present and valid, the second RAN node may send an MDT or RRM measurement configuration to the UE, which may optionally be linked to the QoE measurement configuration, e.g. for synchronization and / or coordination between the QoE measurements and the MDT and / or RRM measurements.

[0121] In the above, if multiple UEs simultaneously execute the procedure triggering the above action (sending status information or sending a request), the corresponding network signaling (Xn / X2 / NG / S1) may carry in the same message a status indication and / or a request for one or more of these UEs. Similarly, a response to such a request may contain information about multiple UEs and / or multiple RAN visible (lightweight) QoE configurations. For example, if a second RAN node receives a message from a first RAN node containing multiple requests (one or more of the above types of requests), the second RAN node may respond with an indication of the execution status of each request of the first RAN node. The indication may be a per UE or per RAN visible (lightweight) QoE measurement configuration, each indication may be, for example, one of "success", "reject", "pending", "partial success-partial rejection", or "partial pending-partial rejection" (indications of other execution statuses are not excluded).

[0122] The techniques described herein may be described with respect to a UE in the various scenarios described above.

[0123] Upon receiving the RAN visible lightweight QoE configuration configuration, the wireless terminal starts logging the link quality of the serving cell and adds it to the RAN visible lightweight QoE measurements. In one embodiment, the serving cell quality measurements may be in the form of RSRP, RSRQ, SINR, etc. at cell level and / or for each beam (e.g. the SSB beam or CSI-RS beam to which the measurements are associated) and / or the measurements may include indications or snapshots of application layer measurements such as buffer content sizes of various buffers and / or bit rates of downlink (or uplink) application media streams, selected media coding quality / format, playout rate, etc. In another embodiment, the UE logs serving cell measurements upon receiving an indication from the application layer (eg, a session start indication). In yet another embodiment, the UE logs serving cell measurements upon receiving an indication from the application layer indicating the start of RAN visible lightweight QoE measurements (eg, a session start indication). In yet another embodiment, the UE periodically logs serving cell measurements, during which the sampling rate and periodicity are configured by the RAN node as part of the RAN visible lightweight QoE measurements. In yet another embodiment, the UE logs serving cell measurements based on events and specific thresholds configured by the RAN node as part of the RAN visible lightweight QoE measurements. In yet another embodiment, if the UE receives a configuration of MDT and / or RRM measurements linked to QoE measurements and / or a report of RAN visible (lightweight) QoE measurements, the UE may log information indicative of or derived from the link, e.g. an indication of measurement samples or measurement periods that are synchronized between linked measurement types, e.g. to enable synchronized or coordinated QoE measurements and MDT and / or RRM measurements. In yet another embodiment, the serving cell measurements are a list including measResultServingCell as part of 3GPP TS 38.331.

[0124] MeasResultServingCellList ::= SEQUENCE (SIZE (1..maxMeasReport)) OF MeasResultNR MeasResultNR ::= SEQUENCE { PhysCellId PhysCellId OPTIONAL, measResult SEQUENCE { cellResults SEQUENCE { resultsSSB-Cell MeasQuantityResults OPTIONAL, resultsCSI-RS-Cell MeasQuantityResults OPTIONAL }, rsIndexResults SEQUENCE { resultsSSB-Indexes ResultsPerSSB-IndexList OPTIONAL, resultsCSI-RS-Indexes ResultsPerCSI-RS-IndexList OPTIONAL } OPTIONAL }, ..., }

[0125] To resolve the situation where the UE RRC receives two RAN visible (lightweight) QoE configurations for the same service type (or application) from two different RAN nodes, the UE RRC can perform several actions without network involvement (i.e., without signaling of QoE configuration status between the first and second RAN nodes).

[0126] 12 illustrates an example approach. The UE receives a RAN visible (lightweight) QoE measurement configuration from a RAN node, as shown in block 1210. Upon receiving this RAN visible (lightweight) QoE measurement configuration for a service type or application, the UE may check whether the RRC and higher layers are already configured with an existing RAN visible (lightweight) QoE configuration for the same service type or application, as shown in block 1220. If a RAN visible (lightweight) QoE configuration for the same service type exists, as shown in block 1230, the UE RRC may perform one of the following actions: * Discard new RAN visible (lightweight) QoE configuration Release the old RAN visible (lightweight) QoE configuration and configure itself and higher layers with the new RAN visible (lightweight) QoE configuration * Pause new configurations * Pause the old configuration and activate the new one If an application type or a subtype of a service is specified by a new RAN visible (lightweight) QoE configuration, configure itself and the target subtype of the service and / or upper layers of the target application with the specified service, and maintain the old RAN visible (lightweight) QoE configuration for the remaining applications. In a dual connectivity scenario, if one of the RAN visible (lightweight) QoE configurations is received from the master node and the other from the secondary node, release the RAN visible (lightweight) QoE configuration received from the secondary node and keep the RAN visible (lightweight) QoE configuration received from the master node. In a dual connectivity scenario, if one of the RAN visible (lightweight) QoE configurations is received from the master node and the other from the secondary node, suspend the RAN visible (lightweight) QoE configuration received from the secondary node and maintain the RAN visible (lightweight) QoE configuration received from the master node. If an ongoing application session (or, in case multiple application sessions are ongoing, all such ongoing application sessions) of a service type and / or service subtype covered by the RAN visible (lightway) QoE configuration is currently using a radio bearer to the RAN node from which it received the old configuration, it shall maintain the old configuration and release or suspend the new configuration. If an ongoing application session (or, in case multiple application sessions are ongoing, all such ongoing application sessions) of a service type and / or service subtype covered by a RAN visible (lightway) QoE configuration is currently using a radio bearer to the RAN node from which it received the new configuration, it shall maintain the new configuration and release or suspend the old configuration.

[0127] As a non-limiting example of the implementation of these techniques in the NG-RAN specifications, the RAN visible lightweight QoE measurement configuration information may be implemented as part of the UE application layer measurement configuration IE in part of the 3GPP XnAP interface TS38.423.

[0128] -----------Start of proposed 3GPP specification--------- 9.2.3.X UE Application Layer Measurement Configuration The IE defines configuration information for the QoE Measurement Collection (QMC) function. [Table 5] TIFF0007620708000006.tif239164TIFF0007620708000007.tif225165TIFF0007620708000008.tif62163----------End of Proposed 3GPP Specification----------

[0129] The new information element can be passed as part of the trace activation IE as part of any RAN node signaling for mobility or dual connectivity scenarios and as part of RRC restart and re-establishment procedures that require the trace activation IE for QoE measurements. Some of the signals that carry the trace activation IE are as follows: HANDOVER REQUEST ·RETRIEVE UE CONTEXT RESPONSE SGNB ADDITION REQUEST · S-NODE ADDITION REQUEST ·TRACE START In the example below, a trace activation IE is shown that includes a UE application layer measurement configuration IE that includes RAN visible lightweight QoE measurements.

[0130] -----------Start of proposed 3GPP specification--------- 9.2.3.Y Trace Activation This IE defines the parameters for trace activation. [Table 6] TIFF0007620708000010.tif224157TIFF0007620708000011.tif148156 -----------End of Proposed 3GPP Specification---------

[0131] Upon receiving the RAN visible QoE measurements from the wireless terminal, the second RAN node may transmit the lightweight QoE measurements to the first node. This may be implemented as part of a standard interface between RAN nodes, such as 3GPP TS 38.423 or 3GPP TS 38.413. In a non-limiting example, this solution is implemented as part of the access and mobility indication signaling as part of 38.423.

[0132] -----------Start of proposed 3GPP specification--------- 9.1.3.25 Access and mobility indications This message is sent by NG-RAN node 1 to transfer access and mobility related information to NG-RAN node 2. Direction: NG-RAN node 1 → NG-RAN node 2 [Table 7] [Table 8] -----------End of Proposed 3GPP Specification---------

[0133] A RAN node that receives the RAN visible (lightweight) QoE measurement report can forward the report from the CU to the DU. A non-limiting implementation example of forwarding the RAN visible (lightweight) QoE measurement report is shown in the Access and Mobility Indication signal sent from the gNB-CU to the gNB-DU as part of 3GPP TS 38.473.

[0134] -----------Start of proposed 3GPP specification--------- 9.2.10.1 Access and mobility indications This message is sent by the gNB-CU to the gNB-DU to provide access and mobility information to the gNB-DU. Direction: gNB-CU → gNB-DU [Table 9] TIFF0007620708000015.tif228166 [Table 10] -----------End of Proposed 3GPP Specification---------

[0135] While various embodiments are described above in terms of methods, techniques and / or procedures, those skilled in the art will readily appreciate that such methods, techniques and / or procedures may be embodied in various combinations of hardware and software in a variety of systems, communication devices, computing devices, control devices, apparatus, non-transitory computer readable media, computer program products, and the like.

[0136] 13 is a block diagram of an example wireless device or user equipment (UE) 1300 (hereinafter "UE 1300") in accordance with various embodiments of the present disclosure, including those described above with reference to other figures. For example, the UE 1300 may be configured by execution of instructions stored on a computer-readable medium to perform operations corresponding to one or more of the example methods described above.

[0137] The UE 1300 may include a processor 1310 (also referred to as “processing circuitry”) that may be operatively coupled to a program memory 1320 and / or a data memory 1330 via a bus 1370, which may include a parallel address and data bus, a serial port, or other methods and / or structures known to those skilled in the art. The program memory 1320 may store software codes, programs, and / or instructions (collectively shown in FIG. 13 as computer program product 1321) that, when executed by the processor 1310, may configure and / or facilitate the UE 1300 to perform various operations, including operations corresponding to the various example methods described above. As part of such operations, or in addition, execution of such instructions may configure and / or prompt UE 1300 to communicate using one or more wired or wireless communication protocols, including one or more wireless communication protocols standardized by 3GPP, 3GPP2 or IEEE, such as 5G / NR, LTE, LTE-A, UMTS, HSPA, GSM, GPRS, EDGE, 1xRTT, CDMA2000, 802.11, WiFi, HDMI, USB, Firewire, etc., or other current or future protocols that may be utilized in combination with wireless transceiver 1340, user interface 1350, and / or control interface 1360.

[0138] As another example, the processor 1310 may execute program code stored in the program memory 1320 corresponding to MAC, RLC, PDCP, and RRC layer protocols standardized by 3GPP (e.g., for NR and / or LTE). As a further example, the processor 1310 may execute program code stored in the program memory 1320, which, in conjunction with the wireless transceiver 1340, implements corresponding PHY layer protocols such as Orthogonal Frequency Division Multiplexing (OFDM), Orthogonal Frequency Division Multiple Access (OFDMA), and Single Carrier Frequency Division Multiple Access (SC-FDMA). As another example, the processor 1310 may execute program code stored in the program memory 1320, which, in conjunction with the wireless transceiver 1340, implements device-to-device (D2D) communications with other compatible devices and / or UEs.

[0139] The program memory 1320 may also include software code executed by the processor 1310 to control the functionality of the UE 1300, including configuration and control of various components such as the wireless transceiver 1340, the user interface 1350, and / or the control interface 1360. The program memory 1320 may also include one or more application programs and / or modules including computer-executable instructions embodying any of the example methods described herein. Such software code may be written or specified using any known or future developed programming language, such as Java, C++, C, Objective C, HTML, XHTML, machine code, assembler, etc., so long as the required functionality as defined by the method steps to be implemented can be preserved. Additionally or alternatively, the program memory 1320 may comprise an external storage device (not shown) separate from the UE 1300, from which instructions may be downloaded to the program memory 1320 within the UE 1300 or removably coupled to the UE 1300 to enable execution of such instructions.

[0140] The data memory 1330 may include memory areas for the processor 1310 to store variables used in protocol, configuration, control, and other functions of the UE 1300, including operations corresponding to or including any of the example methods described herein. Additionally, the program memory 1320 and / or the data memory 1330 may include non-volatile memory (e.g., flash memory), volatile memory (e.g., static or dynamic RAM), or a combination thereof. Additionally, the data memory 1330 may include a memory slot into which removable memory cards of one or more formats (e.g., SD card, memory stick, compact flash, etc.) can be inserted and removed.

[0141] Those skilled in the art will appreciate that the processor 1310 may include multiple individual processors (including, for example, a multi-core processor), each performing some of the functions described above. In such cases, the multiple individual processors may be commonly connected to the program memory 1320 and data memory 1330, or may be individually connected to multiple individual program memories and / or data memories. More generally, those skilled in the art will appreciate that the various protocols and other functions of the UE 1300 may be implemented in many different computer configurations, including various combinations of hardware and software, including, but not limited to, application processors, signal processors, general purpose processors, multi-core processors, ASICs, fixed and / or programmable digital circuits, analog baseband circuits, radio frequency circuits, software, firmware, and middleware.

[0142] The wireless transceiver 1340 may include radio frequency transmitter and / or receiver functionality that facilitates the UE 1300 to communicate with other devices supporting wireless communication standards and / or protocols, etc. In some demonstrative embodiments, the wireless transceiver 1340 includes one or more transmitters and one or more receivers that enable the UE 1300 to communicate in accordance with various protocols and / or methodologies proposed for standardization by the 3GPP and / or other standards organizations (SSOs). For example, such functionality may operate in coordination with the processor 1310 to implement a PHY layer based on OFDM, OFDMA, and / or SC-FDMA techniques, as described herein with respect to other figures.

[0143] In some exemplary embodiments, the wireless transceiver 1340 includes one or more transmitters and one or more receivers that may facilitate the UE 1300 to communicate with various LTE, LTE-Advanced (LTE-A), and / or NR networks in accordance with standards promulgated by 3GPP. In some exemplary embodiments of the present disclosure, the wireless transceiver 1340 includes the necessary circuitry, firmware, etc. for the UE 1300 to communicate with various NR, NR-U, LTE, LTE-A, LTE-LAA, UMTS, and / or GSM / EDGE networks in accordance with 3GPP standards. In some embodiments, the wireless transceiver 1340 may include circuitry to support D2D communications between the UE 1300 and other compatible devices.

[0144] In some embodiments, the wireless transceiver 1340 includes the circuitry, firmware, etc. necessary for the UE 1300 to communicate with various CDMA2000 networks in accordance with 3GPP2 standards. In some embodiments, the wireless transceiver 1340 can communicate using wireless technologies operating in unlicensed frequency bands, such as IEEE 802.11 WiFi operating using frequencies in the 2.4, 5.6, and / or 60 GHz range. In some embodiments, the wireless transceiver 1340 can include a transceiver capable of wired communication, such as by using IEEE 802.3 Ethernet technology. The functionality particular to each of these embodiments can be coupled to and / or controlled by other circuitry of the UE 1300, such as the processor 1310 executing program code stored in the program memory 1320 in conjunction with and / or supported by the data memory 1330.

[0145] The user interface 1350 may take various forms or may not be present in the UE 1300 entirely depending on the particular embodiment of the UE 1300. In some embodiments, the user interface 1350 may include a microphone, a loudspeaker, a slidable button, a depressible button, a display, a touch screen display, a mechanical or virtual keypad, a mechanical or virtual keyboard, and / or any user interface features common in other mobile phones. In other embodiments, the UE 1300 may include a tablet computing device including a larger touch screen display. In such embodiments, one or more mechanical features of the user interface 1350 may be replaced by an equivalent or functionally equivalent virtual user interface feature (e.g., a virtual keypad, virtual buttons, etc.) implemented using a touch screen display familiar to those skilled in the art. In other embodiments, the UE 1300 may be a digital computing device, such as a laptop computer, desktop computer, workstation, etc., with an integrated, detached, or removable mechanical keyboard depending on the particular exemplary embodiment. Such a digital computing device may also include a touch screen display. Many exemplary embodiments of a UE 1300 having a touch screen display can receive user input, such as input associated with the exemplary methods described herein or known to those skilled in the art.

[0146] In some embodiments, the UE 1300 may include an orientation sensor that may be used in a variety of ways depending on the features and capabilities of the UE 1300. For example, the UE 1300 may use the output of the orientation sensor to determine when a user has changed the physical orientation of the UE 1300's touch screen display. The indication signal from the orientation sensor is available to any application program executing on the UE 1300, such that the application program may automatically change the orientation of the screen display (e.g., from portrait to landscape) when the indication signal indicates that the physical orientation of the device has changed by approximately 90 degrees. In this exemplary manner, the application program may maintain the screen display in a manner that is readable by the user regardless of the physical orientation of the device. Additionally, the output of the orientation sensor may be used in conjunction with various exemplary embodiments of the present disclosure.

[0147] The control interface 1360 of the UE 1300 may take a variety of forms, depending on the particular example embodiment of the UE 1300 and the particular interface requirements of other devices with which the UE 1300 is intended to communicate and / or control. For example, the control interface 1360 may include an RS-232 interface, a USB interface, an HDMI interface, a Bluetooth interface, an IEEE ("Firewire") interface, an I2C interface, a PCMCIA interface, etc. In some example embodiments of the present disclosure, the control interface 1360 may include an IEEE 802.3 Ethernet interface as described above. In some example embodiments of the present disclosure, the control interface 1360 may include analog interface circuitry including, for example, one or more digital-to-analog (D / A) converters and / or analog-to-digital (A / D) converters.

[0148] Those skilled in the art will recognize that the above list of features, interfaces, and radio frequency communication standards is merely exemplary and not limiting to the scope of the present disclosure. In other words, the UE 1300 may include more functionality than shown in FIG. 13, including, for example, a video and / or still image camera, a microphone, a media player and / or recorder, etc. Additionally, the wireless transceiver 1340 may include circuitry necessary to communicate using additional radio frequency communication standards, including Bluetooth, GPS, and / or others. Additionally, the processor 1310 may execute software code stored in the program memory 1320 to control such additional functionality. For example, directional speed and / or position estimates output from the GPS receiver may be available to any application program executing on the UE 1300, including computer program code that corresponds to and / or embodies methods (e.g., methods) corresponding to exemplary embodiments (e.g., methods) of the present disclosure.

[0149] FIG. 14 is a block diagram of an exemplary network node 1400 according to various embodiments of the disclosure, including those described above with reference to other figures. For example, the exemplary network node 1400 may be configured by execution of instructions stored on a computer-readable medium to perform operations corresponding to one or more of the exemplary methods described above. In some exemplary embodiments, the network node 1400 may include a base station, an eNB, a gNB, or one or more components thereof. For example, the network node 1400 may be configured as a central unit (CU) and one or more distributed units (DUs) in accordance with the gNB architecture for NR specified by 3GPP. More generally, the functionality of the network node 1400 may be distributed across various physical devices and / or functional units, modules, etc.

[0150] Network node 1400 may include a processor 1410 (also referred to as “processing circuitry”) that may be operatively connected to program memory 1420 and / or data memory 1430 via a bus 1470, which may include a parallel address and data bus, a serial port, or other methods and / or structures known to those skilled in the art.

[0151] The program memory 1420 can store software codes, programs, and / or instructions (collectively shown in FIG. 14 as computer program product 1421) that, when executed by the processor 1410, can configure and / or facilitate the network node 1400 to perform various operations, including operations corresponding to the various example methods described above. As part of such operations and / or in addition, the program memory 1420 can also include software code executed by the processor 1410 that can facilitate and / or configure the network node 1400 to communicate with one or more other UEs or network nodes using other protocols or protocol layers, such as one or more of the PHY, MAC, RLC, PDCP, and RRC layer protocols standardized by 3GPP for LTE, LTE-A, and / or NR, or any other higher layer (e.g., NAS) protocols utilized in combination with the radio network interface 1440 and / or the core network interface 1450. As an example, the core network interface 1450 may include an S1 or NG interface, and the wireless network interface 1440 may include a Uu interface standardized by 3GPP. The program memory 1420 may also include software code that is executed by the processor 1410 to control the functionality of the network node 1400, including configuration and control of various components such as the wireless network interface 1440 and the core network interface 1450.

[0152] Data memory 1430 may include memory areas for processor 1410 to store variables used in protocol, configuration, control, and other functions of network node 1400. Program memory 1420 and data memory 1430 may include non-volatile memory (e.g., flash memory, hard disk, etc.), volatile memory (e.g., static or dynamic RAM), network-based (e.g., "cloud") storage, or combinations thereof. Those skilled in the art will recognize that processor 1410 may include multiple individual processors (not shown), each performing some of the functions described above. In such cases, the multiple individual processors may be commonly connected to program memory 1420 and data memory 1430, or may be individually connected to multiple individual program memories and / or data memories. More generally, those skilled in the art will recognize that the various protocols and other functions of network node 1400 may be implemented in many different computer configurations including various combinations of hardware and software, including but not limited to application processors, signal processors, general purpose processors, multi-core processors, ASICs, fixed digital circuitry, programmable digital circuitry, analog baseband circuitry, radio frequency circuitry, software, firmware, and middleware.

[0153] The radio network interface 1440 may comprise transmitters, receivers, signal processors, ASICs, antennas, beamforming units, and other circuitry that enables the network node 1400 to communicate with other devices, such as, in some embodiments, multiple compatible user equipment (UE). In some embodiments, the interface 1440 may also enable the network node 1400 to communicate with compatible satellites of a satellite communications network. In some exemplary embodiments, the radio network interface 1440 may include various protocols or protocol layers, such as PHY, MAC, RLC, PDCP, and / or RRC layer protocols standardized by 3GPP, such as LTE, LTE-A, LTE-LAA, NR, NR-U, or improvements as described above, or any other higher layer protocols utilized in combination with the radio network interface 1440. According to further exemplary embodiments of the present disclosure, the radio network interface 1440 may include a PHY layer based on OFDM, OFDMA, and / or SC-FDMA technology. In some embodiments, such PHY layer functionality may be provided cooperatively by the wireless network interface 1440 and the processor 1410 (including program code in memory 1420).

[0154] The core network interface 1450 may comprise a transmitter, a receiver, and other circuitry that enables the network node 1400 to communicate with other devices in a core network, such as, in some embodiments, a circuit switched (CS) and / or packet switched core (PS) network. In some embodiments, the core network interface 1450 may include an S1 interface standardized by 3GPP. In some embodiments, the core network interface 1450 may include an NG interface standardized by 3GPP. In some exemplary embodiments, the core network interface 1450 may include one or more interfaces to one or more AMFs, SMFs, SGWs, MMEs, SGSNs, GGSNs, and other physical devices, including functions found in GERAN, UTRAN, EPC, 5GC, and CDMA2000 core networks known to those skilled in the art. In some embodiments, these one or more interfaces may be multiplexed together on a single physical interface. In some embodiments, the lower layers of the core network interface 1450 may include one or more of Asynchronous Transfer Mode (ATM), Internet Protocol (IP) over Ethernet, SDH over optical fiber, T1 / E1 / PDH over copper wire, microwave radio, or one or more other wired or wireless transmission technologies known to those skilled in the art.

[0155] In some embodiments, the network node 1400 may include hardware and / or software that configures and / or facilitates the network node 1400 to communicate with other network nodes in a RAN (also referred to as a "radio network"), such as other eNBs, gNBs, ng-eNBs, en-gNBs, IABs, etc. Such hardware and / or software may be part of the radio network interface 1440 and / or the core network interface 1450, or may be a separate functional unit (not shown). For example, such hardware and / or software may configure and / or facilitate the network node 1400 to communicate with other RAN nodes over an X2 or Xn interface, as standardized by 3GPP.

[0156] OA&M interface 1460 may comprise transmitters, receivers, and other circuitry that enable network node 1400 to communicate with external networks, computers, databases, etc., for purposes of operation, management, and maintenance of network node 1400 or other network equipment operatively connected thereto. The lower layers of OA&M interface 1460 may include one or more of Asynchronous Transfer Mode (ATM), Internet Protocol (IP) over Ethernet, SDH over optical fiber, T1 / E1 / PDH over copper wire, microwave radio, or other wired or wireless transmission technologies known to those skilled in the art. Additionally, in some embodiments, one or more of wireless network interface 1440, core network interface 1450, and OA&M interface 1460 may be multiplexed together onto a single physical interface, as in the examples above.

[0157] 15 is a block diagram of an example network configured to provide over-the-top (OTT) data services between a host computer and a user equipment (UE), in accordance with various example embodiments of the present disclosure. The UE 1510 can communicate with a radio access network (RAN, also referred to as a "radio network") 1530 via an air interface 1520, which may be based on the above protocols, including, for example, LTE, LTE-A, and 5G / NR. For example, the UE 1510 may be configured and / or arranged as shown in the other figures discussed above.

[0158] The RAN 1530 may include one or more terrestrial network nodes (e.g., base stations, eNBs, gNBs, controllers, etc.) capable of operating in licensed spectrum bands, and one or more network nodes capable of operating in unlicensed spectrum (e.g., using LAA or NR-U technologies), such as the 2.4 GHz band and / or the 5 GHz band. In such cases, the network nodes including the RAN 1530 may operate cooperatively using licensed and unlicensed spectrum. In some embodiments, the RAN 1530 may include or communicate with one or more satellites that comprise a satellite access network.

[0159] The RAN 1530 may further communicate with the core network 1540 according to the various protocols and interfaces described above. For example, one or more devices (e.g., base stations, eNBs, gNBs, etc.) including the RAN 1530 may communicate with the core network 1540 via the core network interface 1550 described above. In some example embodiments, the RAN 1530 may be configured and / or arranged as shown in other figures discussed above. For example, an eNB including the E-UTRAN 1530 may communicate with the EPC core network 1540 via an S1 interface. As another example, a gNB and a ng-eNB including the NG-RAN 1530 may communicate with the 5GC core network 1530 via an NG interface.

[0160] The core network 1540 can further communicate with an external packet data network, shown in FIG. 15 as the Internet 1550, according to various protocols and interfaces known to those skilled in the art. Many other devices and / or networks, such as a host computer 1560, can also connect to the Internet 1550 and communicate via the Internet 1350. In some exemplary embodiments, the host computer 1560 can communicate with the UE 1510 using the Internet 1550, the core network 1540, and the RAN 1530 as intermediaries. The host computer 1560 can be a server (e.g., an application server) under the ownership and / or control of the service provider. The host computer 1560 can be operated by the OTT service provider or by another entity on behalf of the service provider.

[0161] For example, the host computer 1560 may provide over-the-top (OTT) packet data services to the UE 1510 using facilities of the core network 1540 and the RAN 1530, where the OTT packet data services are unaware of the routing of communications to and from the host computer 1560. Similarly, the host computer 1560 is unaware of the routing of transmissions from the host computer to the UE, e.g., through the RAN 1530. Various OTT services may be provided using the exemplary configuration shown in FIG. 15, including, for example, streaming (one-way) audio and / or video from the host computer to the UE, interactive (two-way) audio and / or video between the host computer and the UE, interactive messaging or social communications, interactive virtual or augmented reality, etc.

[0162] The exemplary network shown in Figure 15 may also include measurement procedures and / or sensors that monitor network performance metrics including data rates, delays, and other factors that are improved by the exemplary embodiments disclosed herein. The exemplary network may also include functionality for reconfiguring links between endpoints (e.g., host computers and UEs) in response to fluctuations in the measurements. Such procedures and functionality are known and practiced, and in cases where the network hides or abstracts the air interface from the OTT service provider, the measurements may be facilitated by proprietary signaling between the UE and the host computer.

[0163] The embodiments described herein provide novel techniques for configuring, implementing, and reporting lightweight QoE metrics by UEs. Such techniques can facilitate better analysis and optimization decisions in the RAN while avoiding unnecessary network traffic caused by traditional measurement reports that include a large amount of information, such as traditional QoE metrics. When used in a NR UE (e.g., UE 1510) and a gNB (e.g., a gNB with a RAN 1530), the embodiments described herein can provide various improvements, benefits, and / or advantages that can optimize the QoE determination and network of OTT applications and / or services. As a result, this improves the performance of these services as expected by OTT service providers and end users, including more accurate delivery of services with lower latency without excessive UE energy consumption or other degradation of the user experience.

[0164] The foregoing merely illustrates the principles of the present disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. Thus, it will be appreciated that those skilled in the art can devise numerous systems, arrangements and procedures that, although not explicitly shown or described herein, embody the principles of the present disclosure and thus are within the spirit and scope of the present disclosure. As should be understood by those skilled in the art, the various exemplary embodiments can be used together and interchangeably with one another.

[0165] As described herein, a device and / or an apparatus may be represented by a semiconductor chip, a chipset, or a (hardware) module including such a chip or chipset, but this does not exclude the possibility that the functionality of the device or apparatus is not implemented in hardware but is implemented as a software module, such as a computer program or computer program product including executable software code portions executed or performed by a processor. Furthermore, the functionality of a device or an apparatus may be implemented by any combination of hardware and software. A device or an apparatus may also be considered as an assembly of several devices and / or apparatus, whether functionally cooperating with each other or independent of each other. Furthermore, devices and apparatus may be implemented distributed throughout a system, as long as the functionality of the device or apparatus is maintained. Such similar principles are deemed to be known to those skilled in the art.

[0166] Any suitable steps, methods, features, functions, or advantages disclosed herein may be performed through one or more functional units or modules of one or more virtual devices. Each virtual device may include several of these functional units. These functional units may include processing circuitry, which may include one or more microprocessors or microcontrollers, and other digital hardware, which may include digital signal processors (DSPs), dedicated digital logic, and the like. The processing circuitry is configured to execute program code stored in memory, which may include one or more types of memory, such as read-only memory (ROM), random access memory (RAM), cache memory, flash memory devices, optical storage devices, and the like. The program code stored in memory includes program instructions for implementing one or more communication and / or data communication protocols and, in some embodiments, program instructions for implementing one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause each functional unit to perform corresponding functions according to one or more embodiments of the present disclosure.

[0167] Furthermore, functionality described herein as being performed by a wireless device or a network node may be distributed across multiple wireless devices and / or network nodes, in other words, the functionality of the network nodes and wireless devices described herein is not limited to being performed by a single physical device, but may in fact be distributed among several physical devices.

[0168] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by those skilled in the art to which this disclosure belongs. Furthermore, terms used herein should be interpreted to have a meaning consistent with their meaning in the context of this specification and related art, and should not be interpreted in an ideal or overly formal sense unless expressly defined herein.

[0169] Additionally, certain terms used in this disclosure, including the specification, drawings, and example embodiments, may be used synonymously in certain instances, including, but not limited to, data and information. It is understood that these words and / or other words that may be synonymous with each other may be used synonymously herein, although it may be intended that such words not be used synonymously. Additionally, to the extent that prior art knowledge is not expressly incorporated by reference above, it is expressly incorporated herein in its entirety. All publications referenced are incorporated herein by reference in their entirety.

[0170] As used herein, unless expressly stated to the contrary, the phrases "at least one" and "one or more" followed by a conjunction list of enumerated items (e.g., "A and B," "A, B, and C") mean "at least one item selected from the list that includes the enumerated items." For example, "at least one of A and B" is intended to mean either A, B, or A and B. Similarly, "one or more of A, B, and C" is intended to mean either A, B, C, A and B, B and C, A and C, or A, B, and C.

[0171] Unless expressly stated to the contrary herein, the phrase "a plurality of" followed by a conjunction list of enumerated items (e.g., "A and B," "A, B, and C") is intended to mean "a plurality of items," where each item selected from the list consists of the enumerated items. For example, "a plurality of A and B" is intended to mean either a plurality of A's, a plurality of B's, or at least one A and at least one B.

[0172] Embodiments of the techniques and apparatus described herein include, but are not limited to, the examples listed below.

[0173] A1. A method in a User Equipment (UE) for processing configuration of Quality of Experience (QoE) measurements in a Radio Access Network (RAN), comprising: receiving a RAN visible lightweight QoE configuration from a RAN node; Determining whether the UE already has a RAN visible lightweight QoE configuration for the same service type or application; In making the above determination, Discarding the new RAN visible (lightweight) QoE configuration; Releasing the old RAN-visible (lightweight) QoE configuration and configuring itself and higher layers with the new RAN-visible (lightweight) QoE configuration, o Suspending new configurations, o Suspending the old configuration and activating the new one, If a new configuration is received and the old one is already in a paused state, the new configuration will remain active and the old one will be released, or the old one will remain paused. If a service / application type or a subtype of a service is specified by a new RAN visible (lightweight) QoE configuration, configure itself and the upper layers of the target type or subtype of service and / or the target application with the specified service and maintain the old RAN visible (lightweight) QoE configuration for the remaining applications; In a dual connectivity scenario, if one of the RAN visible (lightweight) QoE configurations is received from a master node and the other from a secondary node, releasing the RAN visible (lightweight) QoE configuration received from the secondary node and keeping the RAN visible (lightweight) QoE configuration received from the master node; In a dual connectivity scenario, if one of the RAN visible (lightweight) QoE configurations is received from the master node and the other is received from the secondary node, suspending the RAN visible (lightweight) QoE configuration received from the secondary node and maintaining the RAN visible (lightweight) QoE configuration received from the master node; - releasing or pausing the new configuration if an ongoing application session (or, in case multiple application sessions are ongoing, all such ongoing application sessions) of the service type and / or service subtype covered by the RAN visible (lightway) QoE configuration are currently using a radio bearer to the RAN node from which the old configuration was received; - if an ongoing application session (or, in case multiple application sessions are ongoing, all such ongoing application sessions) of a service type and / or service subtype covered by the RAN visible (lightway) QoE configuration are currently using a radio bearer to the RAN node from which the new configuration was received, releasing or suspending the old configuration; and performing one or more of the following actions: The method includes:

[0174] B1. A method in a first node of a Radio Access Network (RAN) for managing Quality of Experience (QoE) measurements by a User Equipment (UE), comprising: A method comprising: transmitting configuration information of one or more RAN visible (lightweight) QoE measurements configured in a UE by a first node to a second node in the RAN.

[0175] B2. The method of embodiment B1, wherein the second node is associated with the first node with respect to a configuration change of the UE, such as dual connectivity, mobility, RRC resumption, RRC re-establishment, switching the transfer of service data from a path towards the UE via the first RAN node to a path towards the UE via the second RAN node, etc.

[0176] B3. The method of embodiment B1 or B2, comprising, prior to the transmitting, configuring the UE for one or more RAN visible (lightweight) QoE measurements.

[0177] B4. The method of any one of embodiments B1 to B3, wherein the configuration information comprises: -An indication of a service type for which RAN visible (lightweight) QoE is configured; - an indication of whether a session related to an application of a service type for which a RAN visible (lightweight) QoE configuration is configured is in progress; - an indication of the type of QoE measurement, such as management-based, signaling-based, or hybrid (a combination of management-based and signaling-based QoE); an indication of whether the first RAN node is interested in receiving RAN visible (lightweight) QoE measurement results (or parts of RAN visible lightweight QoE measurement results) upon delivery of QoE measurement results from the wireless terminal to the second RAN node; an indication that a RAN visible (lightweight) QoE report has been received, the RAN visible (lightweight) QoE report including information about a second RAN node; -An indication, signaled together with the RAN visible (lightweight) QoE report, indicating whether the report has already been signaled to the TCE; - RAN visible (lightweight) QoE reports received from a wireless terminal; and The method includes one or more of the following:

[0178] B5. The method of any one of embodiments B1-B4, wherein the status information is sent to the second node along with status information regarding one or more additional UEs.

[0179] B6. The method of any one of embodiments B1-B5, further comprising sending a request for one or more RAN visible lightweight QoE measurements to the second node.

[0180] B7. The method of embodiment B6, wherein the request comprises: a request to transmit (or buffer and subsequently transmit to) the first RAN node a QoE report received by the second RAN node, ■A request optionally including additional conditions associated with the start and stop of such reports, such as (signaling) radio bearer reconfiguration at the UE resulting in a switch of the RAN node receiving the QoE report, an overload indication sent from the first RAN node to the second RAN node, time until session termination, time until a subsequent mobility event is triggered, time until further UE reconfiguration, service type or service subtype, slice or list of slices, etc.; A requirement to support receipt of RAN visible lightweight QoE reports; and A request to suspend one or a list of activated RAN visible lightweight QoE measurements; A request to resume one or a list of suspended RAN visible lightweight QoE measurements; A request to release or stop one or a list of activated RAN visible lightweight QoE measurements; A request to configure the UE with a specific configuration of RAN visible lightweight measurements or a specific configuration of radio measurements linked to QoE measurements; A method comprising:

[0181] B8. The method of embodiment B6 or B7 including receiving a message from the second node positively confirming the request or indicating an inability or failure to comply with the request.

[0182] B9. The method of any one of embodiments B6-B8, wherein the request pertains to multiple UEs.

[0183] B10. A method in a second node of a Radio Access Network (RAN) for managing Quality of Experience (QoE) measurements by a User Equipment (UE), comprising: A method comprising: receiving, from a first node of a RAN, configuration information for one or more RAN visible (lightweight) QoE measurements configured in a UE by the first node.

[0184] B11. The method of embodiment B10, wherein the second node is associated with the first node with respect to a configuration change of the UE, e.g., dual connectivity, mobility, RRC resumption, RRC re-establishment, switching the transfer of service data from a path towards the UE via the first RAN node to a path towards the UE via the second RAN node.

[0185] B12. The method of embodiment B10 or B11, wherein the configuration information comprises: -An indication of a service type for which RAN visible (lightweight) QoE is configured; - an indication of whether a session related to an application of a service type for which a RAN visible (lightweight) QoE configuration is configured is in progress; - an indication of the type of QoE measurement, such as management-based, signaling-based, or hybrid (a combination of management-based and signaling-based QoE); an indication of whether the first RAN node is interested in receiving RAN visible (lightweight) QoE measurement results (or parts of RAN visible lightweight QoE measurement results) upon delivery of QoE measurement results from the wireless terminal to the second RAN node; an indication that a RAN visible (lightweight) QoE report has been received, the RAN visible (lightweight) QoE report including information about a second RAN node; -An indication, signaled together with the RAN visible (lightweight) QoE report, indicating whether the report has already been signaled to the TCE; - RAN visible (lightweight) QoE reports received from a wireless terminal; and The method includes one or more of the following:

[0186] B13. The method of any one of embodiments B10-B12, further comprising: refraining from configuring or modifying a configuration of QoE measurements by the UE in response to the status information.

[0187] B14. The method of any one of embodiments B10-B13, further comprising receiving a request from the first node for one or more RAN visible lightweight QoE measurements.

[0188] B15. The method of embodiment B14, wherein the request comprises: a request to transmit (or buffer and subsequently transmit to) the first RAN node a QoE report received by the second RAN node, ■A request optionally including additional conditions associated with the start and stop of such reports, such as (signaling) radio bearer reconfiguration at the UE resulting in a switch of the RAN node receiving the QoE report, an overload indication sent from the first RAN node to the second RAN node, time until session termination, time until a subsequent mobility event is triggered, time until further UE reconfiguration, service type or service subtype, slice or list of slices, etc.; A requirement to support receipt of RAN visible lightweight QoE reports; and A request to suspend one or a list of activated RAN visible lightweight QoE measurements; A request to resume one or a list of suspended RAN visible lightweight QoE measurements; A request to release or stop one or a list of activated RAN visible lightweight QoE measurements; A request to configure the UE with a specific configuration of RAN visible lightweight measurements or a specific configuration of radio measurements linked to QoE measurements; A method comprising:

[0189] B16. The method of embodiment B14 or B15, further comprising responding with an indication of the execution status of the request.

[0190] B17. The method of embodiment B14 or B15, including sending a message to the first node in response to the request positively acknowledging the request or indicating an inability or failure to comply with the request.

[0191] B18. The method of any one of embodiments B10-B17, wherein the request pertains to a plurality of UEs.

[0192] C1. A user equipment (UE) configured to perform quality of experience (QoE) measurements in a radio access network (RAN), comprising: a radio transceiver circuit configured to communicate with at least one RAN node; A user device comprising: a processing circuit operably coupled to a wireless transceiver circuit, the processing circuit and the wireless transceiver circuit configured to perform operations corresponding to the method of embodiment A1.

[0193] C2. A user equipment (UE) configured to perform quality of experience (QoE) measurements in a radio access network (RAN), the user equipment being further adapted to perform operations corresponding to the method described in embodiment A1.

[0194] C3. A non-transitory computer-readable storage medium storing computer-executable instructions that, when executed by processing circuitry of a user equipment (UE) configured to perform quality of experience (QoE) measurements in a radio access network (RAN), configure the UE to perform operations corresponding to the method described in embodiment A1.

[0195] C4. A computer program product storing computer-executable instructions that, when executed by processing circuitry of a user equipment (UE) configured to perform quality of experience (QoE) measurements in a radio access network (RAN), configure the UE to perform operations corresponding to the method described in embodiment A1.

[0196] D1. A Radio Access Network (RAN) node adapted to configure a User Equipment (UE) to perform Quality of Experience (QoE) measurements, comprising: a communications interface circuit configured to communicate with a network node or function external to the UE and the RAN; a processing circuit operably coupled to the communication interface circuit; Equipped with A radio access network node, wherein the processing circuitry and the communications interface circuitry are configured to perform operations corresponding to the method described in any one of embodiments B1 to B18.

[0197] D2. A Radio Access Network (RAN) node adapted to configure a user equipment (UE) to perform quality of experience (QoE) measurements, the RAN node adapted to perform operations corresponding to the method described in any one of embodiments B1 to B18.

[0198] D3. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by processing circuitry of a Radio Access Network (RAN) node adapted to configure a User Equipment (UE) to perform Quality of Experience (QoE) measurements, configure the RAN node to perform operations corresponding to the method described in any one of embodiments B1 to B18.

[0199] D4. A computer program product storing computer-executable instructions that, when executed by processing circuitry of a Radio Access Network (RAN) node adapted to configure a User Equipment (UE) to perform Quality of Experience (QoE) measurements, configure the RAN node to perform operations corresponding to the method described in any one of embodiments B1-B18.

[0200] Abbreviation 3GPP (registered trademark) 3rd Generation Partnership Project 5GCN 5G Core Network 5GS 5G System AF Application Features AMF Access and Mobility Management Functions AN Access Network API Application Programming Interface AGV Automated Guided Vehicle BAP Backhaul Adaptation Protocol CN Core Network CP Control Plane CU Central Unit DC Dual Connectivity DU Distributed Unit eNB E-UTRAN Node B EN-DC E-UTRA-NR dual connectivity E-UTRA Evolved UTRA E-UTRAN Evolved UTRAN gNB NR radio base station IAB Integrated Access and Backhaul ID Identifier IE Information Elements LTE Long Term Evolution MCE Measurement Collection Entity Minimizing MDT Drive Test MME Mobility Management Entity MN Master Node MR-DC Multi-Radio Dual Connectivity NE-DC NR-E-UTRA dual connectivity NG Next generation NGEN-DC NG-RANE-UTRA-NR Dual Connectivity NG-RAN NG Radio Access Network NR New Radio OAM / O&M operations management PCF Policy Control Function QCI QoS Class Identifier QMC QoE measurement collection QoE quality of experience QoS Quality of Service RAN Radio Access Network RAT Radio Access Technology RRC Radio Resource Control S1 Interface between RAN and LTE CN. S1AP S1 Application Protocol SMF Session Management Facility SMO Service Management and Orchestration SN Secondary Node S-NSSAI Single Network Slice Selection Assistance Information TCE Trace Collection Entity UE User Equipment UPF User Plane Function

Claims

1. A method in a first node of a Radio Access Network (RAN) for managing Quality of Experience (QoE) measurements by a User Equipment (UE), comprising: transmitting configuration information of one or more RAN visible QoE measurements configured in the UE by the first node to a second node of the RAN; sending a request to the second node to transmit to the first node QoE reports received by the second node until a subsequent mobility event is triggered; A method comprising:

2. 2. The method of claim 1 , The second node is Changing the configuration of the UE for multiple connections; and Mobility of the UE; and RRC resumption or RRC re-establishment of the UE; switching forwarding of data for a service from a path towards the UE via the first node to a path towards the UE via the second node; a first node associated with at least one of

3. 3. The method according to claim 1 or 2, Prior to said transmitting, configuring the UE for the one or more RAN visible QoE measurements.

4. 4. The method according to claim 1 , further comprising: The configuration information is an indication of a service type for which the RAN visible QoE is configured; and an indication of whether a session associated with an application of the service type for which the RAN visible QoE configuration is configured is ongoing; and an indication of a type of the QoE measurement; and an indication of whether the first node is interested in receiving results of the RAN visible QoE measurements upon delivery of the RAN visible QoE measurements from the UE to the second node; and an indication that a RAN visible QoE report has been received, the RAN visible QoE report including information regarding the second node; and an indication, signaled together with the RAN visible QoE report, of whether said report has already been signaled to the TCE; a RAN visible QoE report received from the UE; The method includes one or more of the following:

5. 5. The method according to any one of claims 1 to 4, The request may further include: A request to support receiving RAN visible QoE reports; a request to suspend one or a list of the activated RAN visible QoE measurements; a request to resume one or a list of the suspended RAN visible QoE measurements; a request to release or stop one or a list of the activated RAN visible QoE measurements; - a request to configure the UE with a specific configuration of RAN visible measurements or a specific configuration of radio measurements linked to the QoE measurements; The method includes any one of the following:

6. 6. The method of claim 5, the request includes additional conditions related to starting and stopping the QoE report; The additional condition is: - reconfiguration of radio bearers in the UE resulting in a switch in the node receiving the QoE report; an overload indication transmitted from the first node to the second node; For a certain period of time, Until the end of the session, Until further UE reconfiguration, A service type or a service subtype; a slice or a list of slices; The method includes at least one of the following:

7. 7. The method according to claim 5 or 6, receiving 1030 a message from the second node either acknowledging the request or indicating an inability or failure to comply with the request.

8. 8. The method according to any one of claims 1 to 7, comprising: The method, wherein the request pertains to a plurality of UEs.

9. A method in a second node of a Radio Access Network (RAN) for managing Quality of Experience (QoE) measurements by a User Equipment (UE), comprising: receiving, from a first node of the RAN, configuration information for one or more RAN visible QoE measurements configured by the first node in the UE; receiving a request from the first node to transmit QoE reports received by the second node to the first node until a subsequent mobility event is triggered; A method comprising:

10. 10. The method of claim 9, The second node is Changing the configuration of the UE for multiple connections; and Mobility of the UE; and RRC resumption or RRC re-establishment of the UE; switching forwarding of data for a service from a path towards the UE via the first node to a path towards the UE via the second node; a first node associated with at least one of

11. 11. The method according to claim 9 or 10, The configuration information is an indication of a service type for which the RAN visible QoE is configured; and an indication of whether a session associated with an application of the service type for which the RAN visible QoE configuration is configured is ongoing; and an indication of a type of the QoE measurement; and an indication of whether the first node is interested in receiving results of the RAN visible QoE measurements upon delivery of the RAN visible QoE measurements from the UE to the second node; and an indication that a RAN visible QoE report has been received, the RAN visible QoE report including information regarding the second node; and an indication, signaled together with the RAN visible QoE report, of whether said report has already been signaled to the TCE; a RAN visible QoE report received from the UE; The method includes one or more of the following:

12. 12. The method according to any one of claims 9 to 11, The request may further include: A request to support receiving RAN visible QoE reports; a request to suspend one or a list of the activated RAN visible QoE measurements; a request to resume one or a list of the suspended RAN visible QoE measurements; a request to release or stop one or a list of the activated RAN visible QoE measurements; - a request to configure the UE with a specific configuration of RAN visible measurements or a specific configuration of radio measurements linked to the QoE measurements; The method includes any one of the following:

13. 13. The method of claim 12, the request includes additional conditions related to starting and stopping the QoE report; The additional condition is: - reconfiguration of radio bearers in the UE resulting in a switch in the node receiving the QoE report; an overload indication transmitted from the first node to the second node; For a certain period of time, Until the end of the session, Until further UE reconfiguration, A service type or a service subtype; a slice or a list of slices; The method includes at least one of the following:

14. 14. The method of claim 12 or 13, further comprising: responding with an indication of the execution status of the request.

15. 14. The method according to claim 12 or 13, in response to the request, transmitting a message to the first node positively acknowledging the request or indicating an inability or failure to comply with the request.

16. 16. The method according to any one of claims 9 to 15, The method, wherein the request pertains to a plurality of UEs.

17. 1. A node of a Radio Access Network (RAN) adapted to configure a User Equipment (UE) to perform Quality of Experience (QoE) measurements, comprising: a communications interface circuit configured to communicate with a plurality of UEs and a network node or function external to the RAN; a processing circuit operably coupled to the communication interface circuit; Equipped with A node, wherein the processing circuitry and the communications interface circuitry are configured to perform a method according to any one of claims 1 to 16.

Images