Master Node (MN)-Secondary Node (SN) Cooperation for Session Modification during Quality of Experience (QoE) / Radio Access Network Visible QoE (RVQoE) Measurement

Abstract

Techniques configure Radio Access Network (RAN) nodes involved in multi-connectivity operations of a User Equipment (UE) (24), such as a Master Node (MN) (20) and a Secondary Node (SN) (22), to communicate with each other regarding, for example, configuration of RAN Visual Quality of Experience (RV-QoE) measurements at the UE or modification of existing RV-QoE settings at the UE for an application session being delivered to the UE by one of the RAN nodes.

Description

[Technical Field]

[0001] The present disclosure relates generally to Quality of Experience (QoE) measurement reporting, and more particularly to RAN-visible QoE measurement reporting in multi-connectivity scenarios where session data for an application session is delivered to a user equipment (UE) via multiple Radio Access Network (RAN) nodes. [Background technology]

[0002] The 3rd Generation Partnership Project (3GPP) has specified Quality of Experience (QoE) measurements, also known as "application layer measurements," for Long Term Evolution (LTE), Universal Mobile Telecommunications System (UMTS), and more recently for 5th Generation (5G) New Radio (NR) in 3GPP Release 17 (Rel-17). The purpose of QoE measurements is to measure the end-user experience using several applications. Currently, QoE measurements are specified and supported for mobile telephony services over Internet Protocol (IP) Multimedia Subsystem (IMS) services, and streaming services such as virtual reality (VR).

[0003] QoE Measurement Collection (QMC) enables the configuration of application layer measurements in the UE and the transmission of QoE measurement result files, commonly referred to as QoE reports, to the network via Radio Resource Control (RRC) signaling. Reports with the collected QoE reports are sent from the UE application layer to the UE Access Stratum (AS), which forwards them to the RAN. The RAN transparently forwards the reports to configured receivers, e.g., Measurement Collection Entity (MCE).

[0004] QoE measurements and their reported results are intended for analysis in the Operations and Management (OAM) system (or in other non-core network, non-RAN entities) and subsequent possible non-real-time optimization. However, the RAN may also benefit from receiving measurements of metrics measured or collected at the application layer. Such measurements may complement more radio-related measurements, such as reference signal received power (RSRP), reference signal received quality (RSRQ), and signal-to-interference-plus-noise ratio (SINR). For example, the RAN may use these measurements for real-time or near-real-time adaptation or optimization of the treatment of ongoing application sessions, e.g., with regard to scheduling priority. For this reason, 3GPP introduced the so-called RAN-visible QoE (RVQoE) in Rel-17, which comprises periodic reporting of measured application layer metrics in a format that the RAN can understand.

[0005] However, despite the introduction of RVQoE, a remaining challenge is how to configure a user equipment (UE) for RVQoE reporting in a multi-connectivity scenario where session data for an application session is delivered to the UE via multiple RAN nodes, and how measurement results are reported. Summary of the Invention

[0006] Embodiments of the present disclosure configure network nodes (e.g., a master node (MN) and a secondary node (SN)) involved in multi-connectivity operations of a user equipment (UE) to communicate with each other regarding the configuration of Radio Access Network (RAN) Visible Quality of Experience (QoE) (RVQoE) measurements at the UE, or the modification of existing RVQoE settings at the UE, for application sessions being delivered by one or both of the network nodes.

[0007] A first aspect of the present disclosure provides a method, implemented in a first network node, for multi-connectivity operation for a user equipment (UE) in a communication system including a first network node and a second network node. The first network node and the second network node are involved in the multi-connectivity operation of the UE. In an example embodiment, the first network node determines that the second network node should carry at least a portion of an application session for the UE. In response to making the determination, the first network node sends an indication to the second network node that causes the second network node to configure Radio Access Network (RAN) Visible Quality of Experience (RV-QoE) information for the UE for at least the portion of the application session.

[0008] A second aspect of the present disclosure provides a method, implemented in a second network node, for multi-connectivity operation for a user equipment (UE) in a communication system including a first network node and a second network node. The first network node and the second network node are involved in the multi-connectivity operation of the UE. In an example embodiment, the second network node receives an indication from the first network node to configure Radio Access Network (RAN) Visible Quality of Experience (RV-QoE) information for the UE for at least a portion of an application session. The second network node then sends a response message to the first network node indicating whether the second network node will configure the RV-QoE information for the UE.

[0009] A third aspect of the present disclosure provides a method, implemented in a user equipment (UE), for multi-connectivity operation for the UE. The UE is in a communication system including a first network node and a second network node. The first network node and the second network node are involved in the multi-connectivity operation of the UE, and the UE is configured to send a Radio Access Network (RAN) Visual Quality of Experience (RV-QoE) report for an application session. In an example embodiment, the UE receives RVQoE information from one of the first network node and the second network node, the RVQoE information configuring the UE to send an RVQoE report for the application session to the other of the first network node and the second network node. The UE then obtains metrics for the application session according to the RVQoE information and sends an RVQoE report including the metrics for the application session to the other of the first network node and the second network node.

[0010] A fourth aspect of the present disclosure provides a first network node for multi-connectivity operations for a user equipment (UE) in a communication system, the communication system comprising the first network node and a second network node. The first network node and the second network node participate in the multi-connectivity operations for the UE. In an example embodiment, the first network node comprises a processing circuit and a memory circuit. The memory circuit is configured to store instructions executable by the processing circuit, whereby the network node is configured to: determine that the second network node should carry at least a portion of an application session for the UE; and, in response to determining, send an indication to the second network node that causes the second network node to configure Radio Access Network (RAN) Visible Quality of Experience (RV-QoE) information for the UE for at least the portion of the application session.

[0011] A fifth aspect of the present disclosure provides a first network node for multi-connectivity operation for a user equipment (UE) in a communication system, the communication system comprising the first network node and a second network node. The first network node and the second network node are involved in the multi-connectivity operation of the UE. In an example embodiment, the first network node is configured to: determine that the second network node should carry at least a portion of an application session for the UE; and, in response to determining, send an indication to the second network node that causes the second network node to configure Radio Access Network (RAN) Visible Quality of Experience (RV-QoE) information for the UE for at least the portion of the application session.

[0012] A sixth aspect of the present disclosure provides a computer program comprising instructions stored thereon which, when executed on processing circuitry of a first network node, causes the first network node to perform a method according to the first aspect.

[0013] A seventh aspect of the present disclosure provides a carrier including a computer according to aspect 6. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium.

[0014] An eighth aspect of the present disclosure provides a non-transitory computer-readable storage medium comprising a computer program stored thereon, the computer program comprising executable instructions that, when executed by processing circuitry in a first network node, cause the first network node to perform a method according to the first aspect.

[0015] A ninth aspect of the present disclosure provides a second network node for multi-connectivity operations for a user equipment (UE) in a communication system, the communication system comprising a first network node and a second network node. The first network node and the second network node participate in multi-connectivity operations for the UE. In an example embodiment, the second network node comprises a processing circuit and a memory circuit. The memory circuit is configured to store instructions executable by the processing circuit, whereby the network node is configured to receive, from the first network node, an indication to configure Radio Access Network (RAN) Visible Quality of Experience (RV-QoE) information for the UE for at least a portion of an application session, and to send a response message to the first network node, the response message indicating whether the second network node will configure the RV-QoE information for the UE.

[0016] A tenth aspect of the present disclosure provides a second network node for multi-connectivity operation for a user equipment (UE) in a communication system, the communication system comprising a first network node and a second network node. The first network node and the second network node participate in multi-connectivity operation of the UE. In an example embodiment, the second network node is configured to receive, from the first network node, an indication to configure Radio Access Network (RAN) Visible Quality of Experience (RV-QoE) information for the UE for at least a portion of an application session, and to send a response message to the first network node. The response message indicates whether the second network node will configure the RV-QoE information for the UE.

[0017] An eleventh aspect of the present disclosure provides a computer program comprising instructions stored thereon which, when executed on processing circuitry of a second network node, causes the second network node to perform a method according to the second aspect.

[0018] A twelfth aspect of the present disclosure provides a carrier comprising the computer program of the eleventh aspect, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium.

[0019] A thirteenth aspect of the present disclosure provides a non-transitory computer-readable storage medium comprising a computer program stored thereon. In an exemplary embodiment, the computer program comprises executable instructions that, when executed by processing circuitry in a second network node, cause the second network node to perform a method according to the second aspect.

[0020] A fourteenth aspect of the present disclosure provides a user equipment (UE) in a communication system including a first network node and a second network node. The first network node and the second network node are involved in multi-connectivity operations of the UE, and the UE is configured to send a Radio Access Network (RAN) Visual Quality of Experience (RV-QoE) report for an application session. In an exemplary embodiment, the UE includes a processing circuit and a memory circuit. The memory circuit is configured to store instructions executable by the processing circuit, such that the UE is configured to: receive RVQoE information from one of the first network node and the second network node, the RVQoE information configuring the UE to send an RVQoE report for the application session to the other of the first network node and the second network node; obtain metrics for the application session according to the RVQoE information; and send an RVQoE report for the application session to the other of the first network node and the second network node, the RVQoE report including the metrics.

[0021] A fifteenth aspect of the present disclosure provides a user equipment (UE) in a communication system including a first network node and a second network node. The first network node and the second network node are involved in multi-connectivity operation of the UE, and the UE is configured to send a Radio Access Network (RAN) Visual Quality of Experience (RV-QoE) report for an application session. In an example embodiment, the UE is configured to: receive, from one of the first network node and the second network node, RVQoE information that configures the UE to send an RVQoE report for the application session to the other of the first network node and the second network node; obtain metrics for the application session according to the RVQoE information; and send, to the other of the first network node and the second network node, an RVQoE report for the application session, the RVQoE report including the metrics.

[0022] A sixteenth aspect of the present disclosure provides a computer program comprising instructions stored thereon that, when executed on processing circuitry of a user equipment (UE), causes the UE to perform a method according to the third aspect.

[0023] A seventeenth aspect of the present disclosure provides a carrier comprising the computer program of the sixteenth aspect, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium.

[0024] An eighteenth aspect of the present disclosure provides a non-transitory computer-readable storage medium comprising a computer program stored thereon, the computer program comprising executable instructions that, when executed by processing circuitry in a user equipment (UE), cause the UE to perform a method according to the third aspect. [Brief explanation of the drawings]

[0025] [Figure 1]FIG. 1 illustrates a wireless communication network supporting multi-connectivity, in which session data for an application session is delivered to a UE via multiple RAN nodes, according to one embodiment of the present disclosure. [Figure 2] FIG. 1 illustrates a simplified message flow between a UE, a Master Node (MN), and a Secondary Node (SN) in which the UE is configured to send an RVQoE report to a RAN node, according to one embodiment of the present disclosure. [Figure 3] FIG. 1 illustrates a simplified message flow between a UE, a MN, and a SN, where the UE is configured to send an RVQoE report to a RAN node, according to one embodiment of the present disclosure. [Figure 4] FIG. 1 illustrates a simplified message flow between a UE, a MN, and a SN, where the UE is configured to send an RVQoE report to a RAN node, according to one embodiment of the present disclosure. [Figure 5] FIG. 1 illustrates a simplified message flow between a UE, a MN, and a SN where the UE has been reconfigured to send RVQoE reports to a RAN node, in accordance with one embodiment of the present disclosure. [Figure 6] FIG. 10 illustrates a simplified message flow between two RAN nodes, where one of the RAN nodes is configured to indicate to the other RAN node the type of data carried by a subflow, according to one embodiment of the present disclosure. [Figure 7] 1 is a flow chart illustrating an example method implemented in a first network node for configuring multi-connectivity operation of a user equipment (UE), according to one embodiment of the present disclosure. [Figure 8] 10 is a flow chart illustrating an example method implemented in a second network node for configuring multi-connectivity operation of a user equipment (UE), according to one embodiment of the present disclosure. [Figure 9] 1 is a flow chart illustrating an example method implemented in a user equipment (UE) for configuring multi-connectivity operation of the UE, according to one embodiment of the present disclosure. [Figure 10]FIG. 1 illustrates an exemplary UE configured to perform RVQoE measurements for each RAN node that delivers session data to the UE. [Figure 11] FIG. 1 illustrates an example network node configured to support RVQoE measurement reporting for each RAN node that delivers session data to a UE. [Figure 12] FIG. 1 illustrates an example of a communication system, according to some embodiments. [Figure 13] FIG. 1 is a block diagram of a host in accordance with various aspects described herein. [Figure 14] FIG. 1 is a communication diagram of a host communicating with a UE via a network node over a partial wireless connection, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0026] The following terms are used throughout this specification. In particular, the terms "UE," "terminal equipment," "wireless terminal," and "terminal" are used interchangeably, as are the terms "node," "network node," and "RAN node." The terms "application layer measurement configuration," "application measurement configuration," "RVQoE measurement configuration," "RVQoE configuration," "RVQoE measurement and reporting configuration," and "QoE measurement collection (QMC) configuration" are used interchangeably, but the term "QMC configuration file" is not an equivalent term. Instead, the term "QMC configuration file" refers to a portion of the SN configuration, for example comprising an XML file containing instructions for SN metrics to be collected.

[0027] Additionally, references to a network node throughout this disclosure may be a RAN node, 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, O-eNB, non-real-time RAN intelligent controller (non-RT RIC), real-time RAN intelligent controller (RT-RIC), operations, administration and management (OAM) node, core network (CN) node / function, cloud-based network function (NF), or cloud-based centralized training node.

[0028] Furthermore, all references to an application layer are to the application layer of the UE (as RAN nodes do not have an application layer). Furthermore, the term "service" is often used herein as a shorthand for the term "service type." Thus, the terms "service" and "service type" may be considered interchangeable terms throughout this specification, unless explicitly stated otherwise.

[0029] Embodiments of the present disclosure apply to both signaling-based and management-based RVQoE measurements, but may also optionally be restricted to apply to only one of them (i.e., signaling-based or management-based RVQoE measurements).

[0030] The terms "RVQoE report" and "RVQoE measurement report" are also used interchangeably herein, as are the terms "access stratum" and "radio layer" when referring to a UE. Furthermore, the term "session" refers to the application session to which the RVQoE measurements apply.

[0031] The embodiments of the present disclosure also apply to Universal Mobile Telecommunications Service (UMTS), Long Term Evolution (LTE), and New Radio (NR), as well as future Radio Access Technologies (RATs) such as 6G. However, it should be noted that while the present disclosure is described herein in the context of management-based QoE / RVQoE measurement, this is for illustrative purposes and ease of explanation only. Those skilled in the art should readily appreciate that the present embodiments are equally applicable to both management-based and signaling-based QoE / RVQoE measurements.

[0032] Furthermore, the present embodiments are described in the context of an example of New Radio Dual Connectivity (NR-DC). However, the present disclosure may be generalized to Multi-Radio Dual Connectivity (MR-DC) or similarly to connectivity options with more than two RAN nodes, such as Enhanced Universal Mobile Telecommunications Service Terrestrial Radio Access (E-UTRA) NR Dual Connectivity (EN-DC) and NR-E-UTRA Dual Connectivity (NE-DC).

[0033] This embodiment also applies to carrier aggregation. Furthermore, the terms information element (IE), field, and parameter may be used interchangeably herein in the context of Abstract Notation One (ASN.1). In ASN.1 code and in the procedural text in the 3GPP Radio Resource Control (RRC) specification for 5G / NR, i.e., 3GPP TS38.331 version 17.3.0, the parameters / IEs / fields used are often named with a suffix indicating the release number of the 3GPP standard in which the parameter / IE / field was introduced (e.g., the suffix "-r17" indicates a parameter / IE / field introduced in Release 17 of the 3GPP standard). Furthermore, parameters / IEs / fields that follow this naming convention are generally referred to herein both with and without the suffix. When a name with a suffix is ​​used in ASN.1 code, it defines the legal name from the point of view of an ASN.1 compiler, while the name without the suffix is ​​used in the text, for example, in field descriptions and procedure text. According to this embodiment, both ways of referring to IEs / fields / parameters can be used. Moreover, if / when these terms are used in this disclosure, they are used interchangeably.

[0034] Referring now to the drawings, FIG. 1 shows a communication network 10 supporting multi-connectivity. The communication network includes a core network 14 and a radio access network (RAN) 18. The core network 14 includes a measurement collection entity (MCE) for collecting QoE measurements and RVQoE measurements as described herein. The RAN 18 implements a split RAN architecture with a centralized unit (CU) serving two distributed units (DUs) located in each RAN node, i.e., a master RAN node 20 (also referred to herein as a master node (MN)) and a secondary RAN node (also referred to herein as a secondary node (SN)). The RAN nodes may comprise any network node in the RAN, such as a 5G NodeB (e.g., a gNB or gNodeB), a DU, a CU, a radio unit, or a radio head, which includes a distributed unit (DU) and a centralized unit (CU).

[0035] An application server (AS) 12 generates session data for user equipment (UE) 24, which is distributed over communication network 10. UE 24 may comprise any type of wireless device that communicates with RAN nodes and / or with other UEs 24 in a wireless communication system. Examples of UE 24 include cellular phones, smartphones, tablets, notebooks, laptop computers, laptop-mounted equipment (LME), vehicle-to-vehicle (V2V) communication devices, vehicle-to-everything (V2X) communication devices, machine-type communication (MTC) devices, machine-to-machine (M2M) communication devices, etc.

[0036] In the illustrated embodiment, a UE 24 in multi-connectivity is involved in an end-to-end application session (e.g., a video streaming session comprising an audio sub-stream and a video sub-stream) with an AS 12 operated by a content service provider (CSP). In this example, the wireless communication network 10 is used as a content distribution network for delivering session data to the UE 24. The session data is distributed via a master RAN node 20 and a secondary RAN node 22. Stream A represents the session data output by the AS 12 and is split into two streams at the RAN 18. The first stream is denoted as Stream B and is distributed by the master RAN node 20 (hereinafter referred to as MN 20). The second stream is denoted as Stream C and is distributed by the secondary RAN node 22 (hereinafter referred to as SN 22). Some example scenarios in which session data is distributed by multiple RAN nodes include the following: Packet duplication scenario, where equivalent session data is delivered to the UE 24 via both NR-DC legs. Duplication is typically applied for reliability reasons. In this case, Stream B and Stream C are identical. Situations in which a session for an application contains different subflows / substreams (e.g., a video streaming session comprising an audio substream and a video substream). In some of these situations, some of the subflows / substreams are delivered via one network node (e.g., MN20) and other subflows / substreams are delivered via another network node (e.g., SN22). In such cases, stream B and stream C contain different subflows / substreams. However, in other situations, the subflows / substreams are delivered via both network nodes (i.e., both MN20 and SN22) in an interleaved manner. In these latter cases, stream B and stream C contain different session data for the same subflow / substream. Situations where a session for an application contains only one flow that is composed of multiple sub-flows that cannot be separated at the network level, and the flow / stream is split and delivered via both network nodes MN20 and SN22. In these situations, stream B and stream C contain different session data for the same flow.

[0037] Networks assess Quality of Service (QoS) by monitoring Key Performance Indicators (KPIs) that reflect network performance. However, KPIs do not necessarily correlate to end-user Quality of Experience (QoE). For example, a streaming service may meet some performance criteria for the network, but a customer's perceived QoE may vary depending on whether they are watching on a TV or a small mobile device.

[0038] 3GPP specifies QoE measurements, also called "application layer measurements," to measure end-user experience using several applications. Currently, QoE measurements are specified and supported for Dynamic Adaptive Streaming over HTTP (Hypertext Transfer Protocol) (DASH) streaming, Mobility Telephony Services (MTS) for Internet Protocol Multimedia Subsystem (IMS) (MTSI) services, and Virtual Reality (VR).

[0039] Briefly, QoE Measurement Collection (QMC) enables the configuration of application layer measurements in the UE 24 and the transmission of QoE measurement result files, commonly referred to as "QoE reports," to the network via Radio Resource Control (RRC) signaling. The RAN receives application layer measurement configurations (also called QoE measurement configurations or QoE settings) from the OAM system or CN 14. The application layer measurement configurations are encapsulated in transparent containers, which are forwarded to the UE 24 in downlink RRCReconfiguration messages. The UE access stratum or UE RRC layer receives application layer measurement reports (also called QoE reports) from upper layers (application layers) of the UE. The QoE reports are encapsulated in transparent containers and sent to the network in uplink RRC messages, MeasurementAppLayerReport. The RAN then forwards the QoE reports to a Measurement Collector Entity (MCE).

[0040] A 3GPP Rel-17 study titled "Study on NR QoE Management and Optimizations for Diverse Services," which investigated solutions for QoE measurement in NR, has been finalized and concluded. According to this work item, QoE management in NR will not only collect QoE parameters for streaming services, but also consider the general performance requirements of diverse services, such as augmented reality (AR), virtual reality (VR), and ultra-reliable low-latency communications (URLLC). Of these services, at least VR was covered in 3GPP Rel-17. Based on the requirements of these services, the NR study included a more adaptive QoE management method that enables network optimization to satisfy user experience for diverse services.

[0041] The configuration data related to QoE measurements (commonly referred to in the standard as application layer measurements) comprises a service type indication, an indication of the area where the measurements should be performed (denoted as area coverage), the Internet Protocol (IP) address of an entity (often called the MCE 16) to which the collected measurement results (i.e., QoE reports) should be sent, and a set of instructions specifying the type of measurements to be performed as well as details of how these measurements should be performed. These instructions are targeted to the application layer in the UE 24 and are placed in a "container" that cannot be read or interpreted by the network entity handling the instructions (e.g., by forwarding the instructions to the UE 24 and the UE 24 access stratum). Currently specified service types are MTSI, and streaming service DASH. In 3GPP Rel-17, VR was added.

[0042] An "area range" is defined in terms of a cell or a network-related area. For example, in UMTS, an area range is defined as either a list of cells, a list of routing areas, or a list of tracking areas. In LTE, an area range is defined as either a list of cells or a list of tracking areas. In NR, an area range is defined as either a list of cells (e.g., a list of 5G NR Cell Global Identities (NCGIs)) or a list of tracking areas (e.g., a list of Tracking Area Codes (TACs)).

[0043] QoE, and in particular QoE configuration, comes in two flavors: management-based (m-based) QoE configuration and signaling-based (s-based) QoE configuration. In both cases, the QoE configuration occurs in an OAM system or some other management entity that deals with, for example, customer satisfaction. All of these entities are referred to herein as OAM systems (although the OAM system also includes further entities).

[0044] For m-based QoE, the OAM system is typically interested in general QoE statistics from a certain area, defined as an area range. The m-based QoE configuration is sent directly from the OAM system to the RAN nodes that control cells within the area range. Each RAN node then selects UEs that are within its area range (and that meet any other relevant conditions, such as supporting the application / service type in question) and sends the m-based QoE configuration to these UEs.

[0045] In the case of s-based QoE, the OAM system is interested in collecting QoE measurements from a particular UE 24, for example, because a user of the UE 24 has complained. The OAM system sends the s-based QoE configuration to a Home Subscriber Server (HSS) (in an Evolved Packet System (EPS) / LTE) or a Unified Data Management (UDM) (in a 5G System (5GS) / NR), which then forwards the QoE configuration to the UE 24's current mobility management node (e.g., a Mobility Management Entity (MME) in EPS / LTE or an AMF in 5G / NR) in the CN 14 node. The CN 14 then forwards the s-based QoE configuration to the RAN node serving that UE 24, which forwards the s-based QoE configuration to the UE 24.

[0046] The service type indication and the container with the measurement command are forwarded to the UE 24. The UE 24 is unaware of whether the received QoE configuration is m-based or s-based. In legacy systems, the QoE framework is integrated with the trace function, and a trace identifier (ID) is associated with each QoE configuration. In NR, the QoE function is logically separated from the trace function, but the QoE function will still partially reuse the trace signaling mechanism. In NR, and possibly in LTE, a globally unique QoE reference will be associated with each QoE configuration. The QoE reference is formed by the Mobile Country Code (MCC) + Mobile Network Code (MNC) + QoE Measurement Collection (QMC) ID, where the QMC ID is a 24-bit string. The QoE reference is included in the container with the measurement command and sent to the RAN (i.e., the 5G Node B (gNB) in NR). For communication between the gNB and the UE 24, the QoE reference is replaced by a shorter identifier, denoted as measConfigAppLayerId, which is locally unique within the UE 24 (i.e., there is a one-to-one mapping between measConfigAppLayerId and QoE reference for each QoE configuration provided to the UE 24). The measConfigAppLayerId is stored in the UE 24 access stratum and forwarded in AT commands (which are the type of commands used in communication between the modem part of the UE and the application layer of the UE) together with a container with a service type indication and measurement commands.

[0047] A report with collected QoE reports is sent from the UE24 application layer to the UE24 access stratum, which forwards them to the RAN. The RAN forwards them to the MCE. These QoE reports are placed in a "container," which is opaque to both the UE24 access stratum and the RAN. QoE reports can be configured to be sent periodically or only at the end of an application session. Furthermore, the RAN can instruct the UE24 to pause QoE reporting, for example, if the cell / gNB is overloaded.

[0048] Neither the RAN nor the UE 24 AS is automatically aware when an application session with an associated QoE measurement session is ongoing. Therefore, a session "start" / "stop" indication is introduced, sent from the application layer in the UE 24 to the UE 24 AS and from the UE 24 AS to the RAN. The session "stop" indication can be explicit or can be implicit in the form of a QoE report sent when the application session and associated QoE measurement session are terminated.

[0049] The RAN may decide, as an implementation-based decision, at any time to release the QoE settings in the UE 24. Typically, this is done when the UE 24 moves outside the configured coverage area.

[0050] One opportunity offered by legacy solutions is the ability to retain QoE measurements for the entire session even during handover situations. It is also contemplated to allow the UE 24 to continue QoE measurements for an ongoing application session until the application session is terminated, even if the UE 24 moves outside of the configured coverage area in the meantime.

[0051] As mentioned above, QoE measurements and their reported results are intended for analysis in the OAM system (or in other entities not belonging to the CN or the RAN) and subsequent possible non-real-time optimization. QoE reports are transparently forwarded by the RAN to configured receivers, e.g., MCEs. However, the RAN may also benefit from receiving measurements of metrics measured or collected at the application layer, e.g., as a complement to more radio-related measurements, i.e., radio resource management (RRM) measurements (e.g., reference signal received power (RSRP), reference signal received quality (RSRQ), signal-to-interference-plus-noise ratio (SINR), etc.). For example, the RAN may use such measurements for real-time or near-real-time adaptation or optimization of the treatment of ongoing application sessions, e.g., with regard to scheduling priorities.

[0052] For this reason, 3GPP introduced the so-called RAN Visible QoE (RVQoE) in Rel-17, which comprises periodic reporting of measured application layer metrics in a format that the RAN can understand. These metrics, denoted as RVQoE metrics, are limited to QoE metrics in Rel-17. Example QoE metrics include a buffer level QoE metric for DASH (specified in 3GPP Technical Standard (TS) 26.247, version 17.1.0, which references Annex D.4.5 in ISO / IEC 23009-1, and represented in 3GPP TS 38.331 version 17.2.0 (i.e., the RRC specification) as the AppLayerBufferLevel-r17 field) and a Playout Delay for Media Start-up QoE metric for DASH (specified in 3GPP TS 26.247 version 17.1.0 and represented in 3GPP TS 38.331 version 17.2.0 (i.e., the RRC specification) as the playoutDelayForMediaStartup-r17 field). In addition to these two RVQoE metrics, the MeasurementReportAppLayer message may include a PDU Session ID list (in the form of the pdu-SessionIdList-r17 field) as part of the reported RVQ information (i.e., in the RAN-VisibleMeasurements-r17 information element (IE)).

[0053] The configuration for QoE and RVQoE is performed via an RRC reconfiguration message containing the AppLayerMeasConfig information element shown below. The configuration of legacy QoE metrics is done via the measConfigAppLayerContainer IE, which specifies the configuration as an octet string (following the Extensible Markup Language (XML)) to the application layer in the UE 24. The RVQoE parameters are specified as part of the RAN-VisibleParameters IE. TIFF2026507489000002.tif209170

[0054] In Release 18 (Rel-18), the RAN3 working group is studying support for QoE and RVQoE measurements in NR-DC scenarios. In DC, the UE 24 connects to the MN and SN and switches reporting legs based on instructions from the network, which can be implicitly or explicitly signaled. In DC scenarios, both the MN 20 and the SN 22 can send RVQoE configurations to the UE 24 and receive RVQoE reports directly from the UE 24. However, it has not yet been specified whether the MN 20 can modify the SN 22-generated RVQoE configuration. In some scenarios, one node may configure QoE measurements for the UE 24, and the other node may receive QoE reports and forward those QoE reports directly to the MCE. In this scenario, the node that configured the QoE measurements for the UE 24 should indicate the QoE reference to the node that receives the reports and forwards those reports directly to the MCE. In another scenario, the UE 24 may send the RVQoE report to the MN 20, which may forward the RVQoE report to the SN 22 if necessary, or vice versa.

[0055] In the DC scenario, configuring RVQoE measurement requires some coordination between the MN 20 and the SN 22. The configuration can be initiated by either the MN 20 or the SN 22 in the case of m-based QoE, and by the MN 20 in the case of s-based QoE. The MN 20 and the SN 22 need to coordinate to establish a signaling radio bearer (SRB) for receiving QoE / RV / QoE reports. In the case of m-based QoE, the MN 20 determines which node should perform the QoE measurement configuration. When the MN 20 configures the UE 24 for m-based QoE, the MN 20 may indicate the QoE reference, the MCE 16 IP address, and other relevant information to the SN (e.g., RRC ID). In some embodiments, when the SN 22 receives the m-based QoE measurement configuration, the MN 20 should be aware that the SN 22 has received the m-based QoE measurement configuration. In some embodiments, measures are taken to ensure that the MN 20 is notified when the SN 22 wishes to configure m-based QoE measurements. In some embodiments, the SN 22 can send the RVQoE configuration to the UE 24 via SRB3 or directly to the UE 24 via a split SRB1. In other embodiments, the SN 22 sends the RVQoE configuration over the Xn interface in scenarios where the MN 20 is able to modify the RVQoE.

[0056] Conventionally, performing QoE and / or RVQoE measurements requires coordination between nodes involved in dual connectivity operation for the UE. Furthermore, for RVQoE measurements in NR-DC, it is generally accepted that the node carrying the session should generate the RVQoE measurement configuration and receive the RVQoE report.

[0057] However, it is not entirely clear how conventional systems should ensure that these principles are followed in all scenarios. For example, consider a situation in which the MN 20 has already configured the UE 24 for RVQoE and the session will be delivered through the SN 22 for at least some time. In these cases, the SN 22 may receive RVQoE reports. However, because RVQoE measurements are conventionally performed according to the RVQoE configuration prepared by the MN 20, at least some of the collected RVQoE measurements may not be of interest to the SN 22. Alternatively, the SN 22 may wish to receive a different set of RVQoE measurements and / or different sets of RVQoE measurements / metrics that directly correspond to the type of traffic being carried on the SN 22.

[0058] In the opposite situation, i.e., when the SN 22 has already configured the UE 24 for RVQoE and the session is delivered through the MN 20 for at least some time, the MN 20 may receive an RVQoE report. However, since the RVQoE measurements in these situations are conventionally performed according to the RVQoE configuration prepared by the SN 22, at least some of the collected RVQoE measurements may not be of interest to the MN 20. Alternatively, the MN 20 may wish to receive a different set of RVQoE measurements and / or a different set of RVQoE measurements / metrics that directly correspond to the type of traffic being carried on the MN 20.

[0059] Accordingly, embodiments of the present disclosure address such issues by configuring network nodes (e.g., MN 20 and SN 22) involved in the multi-connectivity operation of UE 24 to communicate with each other regarding the configuration of RVQoE measurements or the modification of existing RVQoE configurations for application sessions that are about to be delivered by one of the network nodes MN 20, SN 22 for a period of time. For example, consider a first network node (e.g., MN 20) and a second network node (e.g., SN 22), each involved in the multi-connectivity operation of UE 24. In some situations, the second network node may carry an application session, and the application session is active only on the second network node. In other situations, the first network node and the second network node may carry application sessions in parallel with each other. However, in any event, this embodiment configures a first network node (e.g., MN20) to instruct a second network node (e.g., SN22) that for that application session, the second network node can configure RVQoE measurements or modify existing RVQoE settings.

[0060] The present embodiments provide advantages and benefits that conventional systems do not or cannot provide. For example, according to the present disclosure, a network node serving a UE in an application layer session is informed that it will be carrying at least a portion of the application session, e.g., due to a leg switch (e.g., a switch in the path used to deliver the application session), and that it may be beneficial for that network node to configure RVQoE measurements for the UE. Because the identity of the particular node that will carry the session is not known a priori, the information provided to the network node helps ensure that the relevant node configures RVQoE measurements.

[0061] In another advantage, the present embodiment can configure two network nodes (e.g., MN 20 and SN 22) to negotiate a new RVQoE reporting configuration for the UE. Furthermore, the present embodiment communicates the RVQoE configuration change to the new network node (e.g., the second network node) as part of the configuration change sent to the UE (e.g., in an RRC reconfiguration message from the first node). Such communication facilitates faster reporting onset and simplifies signaling.

[0062] Another advantage may be realized in situations where two network nodes are serving a UE application as part of a dual connectivity setup (e.g., when transitioning from single connectivity to a multi-connectivity setup or in response to a change of serving node in a multi-connectivity setup). In these situations, the present embodiment advantageously configures and receives RVQoE feedback corresponding to the type of application data (or portion thereof) carried by the network nodes (e.g., MN 20 may carry video and SN 22 may carry the audio component of a DASH streaming session).

[0063] For example, in one embodiment, as seen in FIG. 2 , UE 24 operates in multi-connectivity. That is, UE 24 is communicatively connected to both MN 20 and SN 22, which may be nodes of the same or different types in the same or different networks, via independent communication paths. In this embodiment, data associated with an application session is initially delivered through only one of the RAN nodes (e.g., a first network node functioning as MN 20) and later delivered through another network node (e.g., a second network node functioning as SN 22) or through both MN 20 and SN 22. A common, but not limiting, case is when data for an application session is initially delivered only through MN 20 and, following a leg switch for the bearer(s) carrying the application session, delivered only through SN 22.

[0064] In this embodiment, the UE 24 is configured to operate in multi-connectivity towards the MN 20 and the SN 22. Furthermore, the MN 20 has already prepared an RVQoE configuration for the UE 24 and sent the RVQoE configuration to the UE 24. The RVQoE configuration comprises RVQoE measurements for the UE 24 to perform, and the application session for which the RVQoE measurements are configured is either in progress via the MN 20 or has not yet started.

[0065] 2, the MN 20 determines that an application session for which RVQoE measurements are configured is about to be delivered via the SN 22 (box 30). For example, the MN 20 may determine that a switch in the path used to deliver the application session (i.e., a leg switch) will occur. As another example, the MN 20 may make the decision in response to determining to duplicate delivery of data associated with the application session. In the latter example, the MN 20 may determine to deliver data associated with the application session via both the MN 20 and the SN 22 or to set up a split bearer.

[0066] However, regardless of the reason for making the decision, the MN 20 sends one or more indications for RVQoE setting(s) coordination for the session modification in a message to the SN 22 (line 32), as described in more detail below. The one or more indications for RVQoE setting(s) coordination provide the SN 22 with information that the SN 22 needs to handle the RVQoE setting(s). Upon receiving the message, the SN 22 can either accept or reject the suggested RVQoE setting(s) containing the indication(s). If the SN 22 accepts the suggested RVQoE setting (line 34), the SN 22 may accept it with or without providing an indication of its preferred setting to the MN 20. Regardless, the SN 22 can either configure RVQoE measurements at the UE 24 or modify the existing RVQoE setting at the UE 24 (line 36), so that the UE 24 will measure and provide the information required by the SN 22 for the application session (line 38). If the SN 22 rejects the suggested RVQoE setting (line 40), the SN 22 may reject it with or without providing an indication of its preferred setting.

[0067] In one embodiment, the SN 22 may empirically determine that it is still willing to receive an RVQoE measurement report from the UE 24 even after rejecting the suggested RVQoE configuration received from the MN 20. In these situations, the SN 22 may initiate a coordination procedure towards the MN 20 (line 42), or the SN 22 may configure a set of RVQoE measurements in the UE 24 (line 44) and then accordingly inform the MN 20 of the RVQoE configuration change in the UE 24 (line 46). The UE 24 will then send an RVQoE measurement report to the SN 22 (line 48).

[0068] In a variation of this embodiment, the MN 20 and the SN 22 are operating in dual connectivity mode for the UE 24, and the SN 22 has configured RVQoE measurements in the UE 24 for a specific service type. When the UE 24 has performed RVQoE measurements in accordance with the RVQoE measurement configuration, the UE 24 sends an RVQoE report to the SN 22. Furthermore, either an application of the specified service type is not ongoing in the UE 24, or an application session of the specified service type is ongoing in the UE 24, and the data flow(s) of the application session are carried to the SN 22 by the connectivity leg.

[0069] In one scenario of this embodiment, an application session is in progress. The MN 20 determines that a switch of the connectivity leg for the data flow(s) of the application session will occur or has occurred (i.e., a switch of the connectivity leg toward the MN 20). The decision may be based on a decision by the MN 20 to switch the data flow(s) of the application session (e.g., a switch of the connectivity leg toward the MN 20). The MN 20 then sends a coordination message to the SN 22 to inform the SN 22 that the connectivity leg for the data flow(s) of the application session will be switched or has been switched and that the MN 20 will take over the role of receiver of the RVQoE report from the UE 24.

[0070] In another scenario of this embodiment, the MN 20 determines that an application session of a service type associated with the RVQoE configuration is beginning. This determination may be based, for example, on receiving a session start indication from the UE 24 or from the SN 22 (i.e., forwarded from the UE 24). Alternatively or additionally, the determination may be based on packet inspection (e.g., detecting the transport layer port number used by the application session) involving the data flow(s) of the application session carried on the connectivity leg toward the MN 20. The MN 20 may then decide to take over the role as a receiver of the RVQoE report and send a cooperation message to the SN 22, informing the SN 22 that the MN 20 will be taking over the role as a receiver of the RVQoE report (at which time the SN 22, as one option, discards its stored version of the RVQoE measurement configuration that the SN 22 previously sent to the UE 24).

[0071] In both scenarios of this embodiment, the SN 22 may send to the MN 20 the RVQoE measurement configuration that the SN 22 previously sent to the UE 24 (e.g., unless the SN 22 previously sent this RVQoE measurement configuration to the MN 20). Furthermore, the MN 20 may or may not (re)configure to the UE 24 a new RVQoE measurement configuration (e.g., an RVQoE measurement configuration that includes different metrics or specifies a different reporting periodicity than the RVQoE measurement configuration that the UE previously received from the SN 22).

[0072] The MN 20 may also instruct the UE 24 to send to the MN 20 (e.g., on a connectivity leg towards the MN 20 or on an SRB configured towards the MN 20) an RVQoE report that the UE 24 generates. The instruction may be implicit (e.g., implied by the MN 20 sending an RVQoE (re)configuration to the UE) or explicit (e.g., through (re)configuration of an SRB, e.g., SRB4, SRB3, or SRB5, over which to send the RVQoE report), so that the RVQoE report is sent to the MN 20. In one embodiment, the instruction comprises an explicit instruction, such as an MN / SN instruction, or an identifier (e.g., PCI) of an SpCell of a cell group (MCG or SCG) controlled by the MN 20.

[0073] As mentioned above, instructions for RVQoE setting(s) coordination for session modification are carried in messages. Some examples of those messages include, but are not limited to: S-node modification request XnAP message, S-Node Modification Request Acknowledgement XnAP message, S-node modification request rejection XnAP message, S-node reconfiguration complete XnAP message, S-node needs to modify XnAP message, S-node modification confirmation XnAP message, S-node modified rejection of XnAP messages, and New XnAP messages.

[0074] In another embodiment, the UE 24 receives an instruction from the MN 20 to send an RVQoE report to the SN 22 during the application session or after the RVQoE configuration has been configured but prior to the start of the application session. The instruction may, for example, be applicable for an application session already in progress and may be implicit (e.g., implied by the first network node sending an RVQoE (re)configuration to the UE 24) or explicit (e.g., through the (re)configuration of an SRB (e.g., SRB4, SRB3, or SRB5) over which the RVQoE report should be sent, and thus the RVQoE report is sent to the MN 20). Additionally or alternatively, the instruction may be an explicit instruction, such as an MN / SN instruction, or an identifier (e.g., PCI) of an SpCell of a cell group (MCG or SCG) controlled by the MN 20.

[0075] In another embodiment, the UE 24 may receive an instruction from the MN 20 during an application session to send an RVQoE report to the SN 22. In such an embodiment, the RVQoE report may comprise different parameters than those sent by the UE 24 to the MN 20, and the instruction to send the RVQoE report to the SN 22 may be either an implicit instruction or an explicit instruction as previously described.

[0076] A set of parameters (e.g., RVQoE measurement result parameters, RVQoE metrics) to be sent by UE 24 to SN 22 may be negotiated between MN 20 and SN 22 as part of the RVQoE configuration(s) coordination message described above. For example, MN 20 may inform SN 22 of the switch of connectivity legs and that SN 22 will be the recipient of RVQoE reports from UE 24. Along with informing SN 22 (e.g., in the same inter-node coordination message), MN 20 may request SN 22 to (re)configure RVQoE measurements for UE 24. In response to this request, SN 22 either (re)configures RVQoE measurements for UE 24 and sends the RVQoE measurement (re)configuration to UE 24 or sends the RVQoE measurement (re)configuration to MN 20. In this latter case, the MN 20 includes the RVQoE measurement (re)configuration received from the SN 22 in a message sent to the UE 24 together with instructions to send an RVQoE report to the SN 22 .

[0077] In one embodiment, there is a separate indication sent to the UE 24 that indicates whether the reconfiguration changes are directly applicable for a session already in progress.

[0078] In another embodiment, seen in FIG. 3, UE 24 initially operates in a single connectivity mode but is later reconfigured to operate in a multi-connectivity mode (e.g., dual connectivity). In such a case, data flow(s) associated with an application session are initially delivered to UE 24 via the only available network node (e.g., MN 20) and later delivered via another network node (e.g., SN 22) added to the connection, or via both network nodes. Generally, when data flow(s) for an application session are initially delivered via the only available RAN node (e.g., a gNB functioning as MN 20 in a multi-connectivity scenario), and after the addition of a second RAN node (e.g., the addition of another gNB functioning as SN 22), delivery of the session is switched from MN 20 to SN 22.

[0079] In the embodiment of Figure 3, the UE 24 is initially configured to operate in single connectivity mode towards the MN 20. At some point, the SN 22 is added, for example, in response to the execution of an SN addition procedure. That is, the UE 24 is reconfigured to operate in multiple connectivity mode, which in this case, for purposes of example, is dual connectivity mode. However, before the SN 22 is added, the MN 20 has already prepared and sent RVQoE configuration to the UE 24. Therefore, application sessions for which RVQoE measurements are configured may be ongoing via the MN 20 when the SN 22 is added, or alternatively, may not have started.

[0080] When SN 22 is added to the configuration, MN 20 determines that a session for an application for which RVQoE measurements are configured is about to be delivered via a second network node (box 50). As described above, this determination may be made by MN 20 in response to determining that an upcoming leg switch, session duplication, or split bearer configuration will occur. MN 20 then provides one or more instructions for RVQoE configuration coordination for session modification to SN 22 (line 52). In one embodiment, the instructions for RVQoE configuration coordination for session modification may be carried in one of the following messages: XnAP message requesting the addition of an S-node S-node Addition Request Acknowledgement XnAP Message S-node addition request rejection XnAP message New XnAP messages

[0081] The UE 24 then receives an instruction from the MN 20 during the application session or after it has been set up, but prior to the start of the application session, to send an RVQoE report to the SN 22 (line 54). The instruction may, for example, be applicable for an application session already in progress and may be of any of the forms previously described with respect to the embodiment of FIG. 2.

[0082] In one aspect of this embodiment, the RVQoE report to be sent to the SN 22 may comprise different parameters than those sent in the RVQoE report to the MN 20. Furthermore, the instruction to send the RVQoE report to the SN 22 may be any of the instructions described in more detail below. Furthermore, the set of parameters (e.g., RVQoE measurement result parameters, RVQoE metrics) to be sent by the UE 24 to the SN 22 may be negotiated between the MN 20 and the SN 22 as part of the RVQoE configuration(s) coordination message.

[0083] As in the previous embodiment, there may be a separate indication to the UE 24 indicating whether the reconfiguration changes are directly applicable for sessions already in progress.

[0084] In this embodiment, the SN 22 can either accept or reject the suggested RVQoE configuration, which includes the indication(s). If the SN 22 accepts the suggested RVQoE configuration (line 56), the SN 22 may accept it with or without providing an indication of its preferred configuration to the MN 20. However, the SN 22 can either configure RVQoE measurements at the UE 24 or modify the existing RVQoE configuration at the UE 24 (line 58), so that the UE 24 measures and provides the information required by the SN 22 for the application session (line 60). If the SN 22 rejects the suggested RVQoE configuration (line 62), the SN 22 may reject it with or without providing an indication of its preferred configuration.

[0085] In one embodiment, the SN 22 may empirically determine that it is still willing to receive an RVQoE measurement report from the UE 24 even after rejecting the suggested RVQoE configuration received from the MN 20. In these situations, the SN 22 may initiate a coordination procedure towards the MN 20 (line 64), or the SN 22 may configure a set of RVQoE measurements in the UE 24 (line 66) and then accordingly inform the MN 20 of the RVQoE configuration change in the UE 24 (line 68). The UE 24 will then send an RVQoE measurement report to the SN 22 (line 70).

[0086] 4 is a signaling diagram illustrating the signal flow of another embodiment of the present disclosure in which a UE 24 is operating in a first multi-connectivity mode and then reconfigured to operate in a different multi-connectivity mode involving leg switching, duplication, or split bearers for application session data flows. An example situation is when the UE 24 is connected to the MN 20 and the SN 22 (e.g., a first MN and a first SN, respectively) and then subsequently reconfigured to connect to the MN 20 and a different network node functioning as the SN 22 (e.g., in the case of an MN / SN-initiated SN change, as described in Section 10.5 of 3GPP TS37.340 v17.3.0, which is incorporated herein by reference in its entirety). Another exemplary situation is when UE 24 is to be connected to a different network node functioning as MN 20, with SN 22 functioning as an SN (e.g., in the case of an inter-MN handover without SN change, as described in Section 10.7 of 3GPP TS37.340 v17.3.0). Yet another exemplary situation is when UE 24 is to be connected to two new nodes, such as, for example, when UE 24 connects to a network node functioning as a second MN 20 and another network node functioning as a second SN 22. Such a situation may arise, for example, in the case of an inter-MN handover with SN change, as described in Section 10.7 of 3GPP TS37.340 v17.3.0.

[0087] In this embodiment, the UE 24 is initially configured to operate in multi-connectivity toward the MN 20 (e.g., source MN) and the SN 22 (e.g., source SN). Furthermore, one of the MN 20 and the SN 22 has prepared an RVQoE configuration for the UE 24 and sent the RVQoE configuration to the UE 24.

[0088] In such an embodiment, an application session for which RVQoE measurements are configured is ongoing through the MN 20 (or, alternatively, the application session may not have started). In one aspect, the MN 20 determines that a session for an application for which RVQoE measurements are configured is to be delivered through a different network node 80 (box 82). In another aspect, the MN 20 determines that the application session should be replicated at the different network node 80. In yet another aspect, the MN 20 may decide to configure a split bearer. However, in any of these aspects, the different network node 80 may be the SN 22 (i.e., the source SN), the target MN, or the target SN previously described. However, in any of these aspects, the MN 20 provides one or more instructions for RVQoE configuration coordination for the session modification to the different network node 80 (line 84).

[0089] Alternatively, in such an embodiment, the application session for which RVQoE measurements are configured is ongoing via the SN 22. As described above, the MN 20 may determine that the application session for which RVQoE measurements are configured is about to be delivered via another network node (or, alternatively, the application session may not have started). Alternatively, the MN 20 may determine that the application session should be duplicated or decide to set up a split bearer. In this embodiment, the different network node 80 may be the MN 20 acting as the source MN, or may be another network node acting, for example, as the second target MN 20 or as the second target SN 22. Regardless, the SN 22 then provides one or more of the instructions for RVQoE configuration coordination for session modification to the other network node (potentially via the MN 20).

[0090] The indication for RVQoE setting coordination for session modification is described in more detail below. However, in some aspects, the indication for RVQoE setting(s) coordination for session modification may be carried in one of the following messages: - XnAP message requiring S-node changes, S-node change confirmation XnAP message, S-node change rejection XnAP message, Handover Request XnAP message, Handover Request Acknowledgement XnAP message, S-node addition request XnAP message, S-node Addition Request Acknowledgement XnAP message, S-node addition request rejection XnAP message, S-node reconfiguration complete XnAP message, S-node release request XnAP message, S-node release request acknowledgement XnAP message, S-node release request rejection XnAP message, and New XnAP messages.

[0091] In one aspect, the UE 24 receives (line 86) from the MN 20 (i.e., during the application session or after it has been set up, but prior to the start of the application session) an instruction to transmit the RVQoE report to the other network node 80. The instruction, which may be any of the instructions described in more detail below, may be applicable for a session already in progress.

[0092] In an extension of the above implementation, the UE 24 may receive an instruction from the MN 20 to send an RVQoE report to the SN 22 during an application session. In these cases, the parameters for the RVQoE report sent to the SN 22 may differ from those reported to the MN 20. Indicating that the SN 22 should be the receiver of the RVQoE report may be implemented using any of the instructions described more fully below. Furthermore, the set of parameters (e.g., RVQoE measurement result parameters, RVQoE metrics) to be sent by the UE 24 to the SN 22 may be negotiated between the MN 20 and the SN 22 as part of the coordination message described previously.

[0093] As mentioned above, there may be a separate indication towards the UE 24 indicating whether the reconfiguration changes are directly applicable for sessions already in progress.

[0094] In this embodiment, the other network node 80 can either accept or reject the suggested RVQoE configuration, which includes the indication(s). If the other network node 80 accepts the suggested RVQoE configuration (line 88), the other network node 80 may accept it with or without providing an indication of its preferred configuration to the MN 20. In any event, the other network node 80 can either configure RVQoE measurements in the UE or modify the existing RVQoE configuration in the UE 24 (line 90), so that the UE 24 will measure and provide the information needed by the other network node 80 for the application session (line 92). If the other network node 80 rejects the suggested RVQoE configuration (line 94), the other network node 80 may reject it with or without providing an indication of its preferred configuration.

[0095] In one embodiment, the other network node 80 may empirically determine that it is still willing to receive an RVQoE measurement report from the UE 24 even after rejecting the suggested RVQoE configuration received from the MN 20. In these situations, the other network node 80 may initiate a collaboration procedure towards the MN 20 (line 96), or the other network node 80 may configure a set of RVQoE measurements in the UE 24 (line 98) and then inform the MN 20 accordingly of the RVQoE configuration change in the UE 24 (line 100). The UE 24 will then send an RVQoE measurement report to the network node 80 (line 102).

[0096] FIG. 5 is a signaling diagram illustrating another embodiment of the present disclosure in which a UE 24 initially operates in a multi-connectivity mode but is subsequently reconfigured to operate in a single connectivity mode.

[0097] In this embodiment, the UE 24 is initially configured to operate in multi-connectivity mode toward the MN 20, which functions in the role of an MN, and the SN 22, which functions in the role of an SN. In this embodiment, the SN 22 has prepared and sent an RVQoE configuration to the UE 24. An application session for which RVQoE measurements are configured is in progress via the SN 22, although in one possible alternative scenario, the application session may not have started. In such a case, this embodiment can reconfigure the UE 24 to change from operating in multi-connectivity mode to operating in single-connectivity mode, after which the data flow(s) associated with the application session are switched to the MN 20.

[0098] More specifically, this embodiment requires that MN 20 provides one or more instructions for RVQoE setting coordination for session modification to SN 22 (line 110). (Alternatively, SN 22 may provide one or more instructions for RVQoE setting coordination for session modification to MN 20.) For example, MN 20 may indicate whether an application session currently in progress at SN 22 can continue or will be interrupted at MN 20. Such instructions are described in more detail below, but in at least one aspect, the instruction for RVQoE setting(s) coordination for session modification may be carried in one of the following messages: S-node release request XnAP message, S-node release request acknowledgement XnAP message, S-node release request rejection XnAP message, XnAP message requiring S-node release, S-node release confirmation XnAP message, and New XnAP messages

[0099] During the application session, the UE 24 may receive an instruction from the MN 20 to send an RVQoE report to the SN 22 (line 112). The set of parameters (e.g., RVQoE measurement result parameters, RVQoE metrics) to be sent by the UE 24 to the SN 22 may comprise different parameters than those in the RVQoE report sent to the MN 20 and may be negotiated between the MN 20 and the SN 22 as part of the RVQoE configuration(s) collaboration message described above. Once received, the UE 24 reconfigures the single connectivity mode (box 114) and sends the RVQoE measurements to the MN 20 (line 116).

[0100] As mentioned above, there may be a separate indication to the UE 24 indicating whether the reconfiguration changes are directly applicable for sessions already in progress.

[0101] It should be noted here that the embodiments described herein are also applicable to services such as DASH and VR, as well as other generalized traffic (e.g., web traffic). In such services, application session data flow(s) may comprise multiple subflows. Such subflows are independent from a transport perspective. As an example, application session data flow(s) associated with a DASH service may be split into audio data and video data, which are independently requested by the UE 24 over HTTP. The RAN may infer the different subflows of an application session through shallow inspection performed on packet headers in the user plane. Furthermore, the RAN may infer the different subflows of an application session by calculating the volume of data transferred over each of these connections to identify which of the links carries video data and which of the links carries audio data. The RAN may also explicitly obtain this information via the CN 14 for independent subflows at the DRB during setup of data forwarding tunnels in the user plane.

[0102] 6 illustrates a simplified message flow between two RAN nodes (e.g., MN 20 and SN 22) in which one of the RAN nodes is configured to instruct the other RAN node on the type of data carried by a subflow, according to one embodiment of the present disclosure. As seen in FIG. 6, during any of the reconfigurations described above, and with access to the above information, MN 20 and SN 22 may determine that an application session and corresponding subflow for which RVQoE measurements are configured is about to be delivered via the other of MN 20 and SN 22 (box 120). In such a case, MN 20 provides one or more instructions to SN 22 (or vice versa) for RVQoE configuration coordination for the session modification (line 122). Additionally, MN 20 may provide one or more instructions to SN 22 (or vice versa) regarding the type of data carried on the subflow (line 124).

[0103] As mentioned above, network nodes (i.e., MN 20 and SN 22) may send instructions for RVQoE configuration coordination for session modification. The following instructions are valid for the case of an "ongoing session" (i.e., when an application session has started and associated data flow(s) have been delivered to the UE 24), as well as for application sessions for which associated data flow(s) have not yet been delivered.

[0104] The indication for RVQoE setting(s) coordination for an ongoing application session is provided that the network node receives the indication along with information regarding handling of the RVQoE setting(s). In at least one embodiment, the indication may comprise one or more of the following: an indication that the first network node / second network node (i.e., MN 20, SN 22) has configured QoE and / or RVQoE measurements for the UE; An indication (e.g., identifier) ​​of the RVQoE configuration (e.g., "QoE Reference" or "MeasConfigAppLayerId") that the first network node / second network node (i.e., MN 20, SN 22) has configured or is to configure in the UE, an indication that an application session for the UE will be carried by the first network node / second network node; an indication that an application session for the UE will not be carried by the first network node / second network node. In an embodiment where the UE is reconfigured to operate from dual connectivity mode to single connectivity mode, this indicates that delivery of the application session data flow(s) will be stopped; An indication of the proposed RVQoE configuration to be used by the second node / first network node, an indication that an application session for the UE is to be carried by both the first network node and the second network node, and optionally an indication of which portions of the data flow, or which subflow(s), are to be carried via which nodes (e.g., which network node is to carry voice, which network node is to carry audio, etc.); An indication that a session is in progress or that the UE has been configured but the application session has not yet started; an indication that the UE shall send an RVQoE report to the second network node / first network node; A request or offer to the other network node to provide the UE with RVQoE (re)configuration, which will be sent from the other network node to the UE directly or via a request / offer network node (this will be further detailed below). An indication to the receiving network node (the indication may be implicit or explicit) that the data flow(s) of an ongoing application session are about to be (or will be) delivered through the receiving network node; This indication is valid, for example, in case of SN addition, SN change, SN modification, conditional SN addition, conditional SN change or inter-MN handover with / without SN change; an indication to the receiving network node (the indication may be implicit or explicit) that delivery of one or more data flows of an ongoing application session through the receiving network node is about to be interrupted; This indication is valid, for example, in the case of SN release, Informing the receiving network node that the second network node is / should / can / may (or may not be enabled / should not / cannot / may not) configure new RVQoE settings for the UE for collecting RVQoE reports associated with sessions for applications whose delivery is being switched towards the receiving network node; In one embodiment, the possibility of configuring a new RVQoE configuration depends on whether the maximum number of RVQoE configurations that can be configured for the UE has been reached; In another variant, the notification contains information of available RVQoE metrics (i.e., RVQoE metrics that are available for RVQoE measurement and reporting, and therefore for RVQoE configuration); In another embodiment, the receiving network node may be added as a network node for delivery of data flow(s) associated with an application session for an application (e.g., when data for the session is replicated and sent / received via both the MN 20 and the SN 22). Informing the receiving network node that the second network node is / should / can / may (or may not be enabled / should not / cannot / may not) modify existing RVQoE configuration for the UE for collecting RVQoE reports associated with the application session whose distribution is being switched towards the receiving network node; In one aspect, the possibility to modify an existing RVQoE configuration depends on whether the reporting periodicity can be changed; In one aspect, the notification includes information of available RVQoE metrics (i.e., RVQoE metrics that are available for RVQoE measurement and reporting, and therefore for RVQoE configuration); notifying the receiving network node that the receiving network node is enabled to / should / can / may replace / disable (or is not enabled to / should not / cannot / may not replace / disable) the existing RVQoE configuration for the UE for collecting RVQoE reports associated with the application session whose distribution is being switched towards the receiving network node; In one aspect, the possibility to replace / override existing RVQoE settings depends on whether the reporting periodicity can be changed; In an aspect, the notification includes information of available RVQoE metrics (i.e., RVQoE metrics that are available for RVQoE measurement and reporting, and therefore for RVQoE configuration); one or more parameters provided in the RVQoE configuration that the receiving network node is / should / can / may (or is not enabled / should not / may not) modify (or replace / remove / disable) (or may not) modify (or replace / remove / disable), and an indication of how those parameters are to be modified (or replaced / removed / disabled); As an example, an MN (e.g., a first network node) may instruct an SN (e.g., a second network node) whether it can add one or more RVQoE metrics to an existing RVQoE metric and / or whether it can modify the reporting periodicity; Notification to the receiving node regarding suggested parameters that the receiving node should / may / may use (or should not / cannot / may not use) for new RVQoE configuration for the UE to collect RVQoE reports associated with sessions for applications whose delivery is being switched towards the receiving network node; notification to the receiving network node that an RVQoE configuration has been sent to the UE to collect RVQoE reports associated with the application's session; Notification to a receiving network node that RVQoE measurements are in progress for a session for an application that is being (or will be) delivered via the receiving network node; An indication of the parameters for the RVQoE configuration(s) sent to the UE; Non-limiting examples include measConfigAppLayerId(s), reporting periodicity, whether reporting of RVQoE metrics can be requested upon event trigger (e.g., when a radio-related event is met), whether alignment between RVQoE measurements and radio measurements (e.g., MDT measurements) is ongoing, and whether it should be activated / enabled / started / restarted or deactivated / disabled / stopped / paused.

[0105] The above indications used in network signaling may be used in a preparation stage in the network before sending a reconfiguration message to the UE 24. The reconfiguration message to the UE 24 may include reconfiguring the RVQoE settings of the UE, indicating that RVQoE reports shall be sent to another network node and / or indicating that the reconfiguration shall be applied directly to ongoing sessions, etc.

[0106] If the network node is a split gNB (i.e., the network node consists of a gNB-CU-CP, a gNB-DU, and a gNB-CU-CP), the roles of the first, second, third, and fourth network nodes may be performed by the gNB-DU portions of these nodes or by the gNB-CU-CP portions of these nodes. In this case, coordination messages originate from the gNB-DU (or gNB-CU) and are passed to other network nodes via their respective gNB-CUs.

[0107] The same applies for a CP-UP split architecture, in which the gNB-CU-UP may act as a network node and messages are passed to other network nodes via their respective gNB-CU-CPs.

[0108] It should be noted that throughout this disclosure, MN 20 will be described as being an MN and SN 22 will be described as being an SN. However, this is for illustrative purposes and ease of explanation only. Those skilled in the art should readily understand that the present disclosure is not so limited and that in any of the embodiments, MN 20 could be an SN and SN 22 could be an MN.

[0109] 7 is a flowchart illustrating a method 130 for multi-connectivity operation for a user equipment (UE) in a communication system including a first network node and a second network node. In this embodiment, the first network node and the second network node (i.e., MN 20 and SN 22) are involved in the multi-connectivity operation of the UE, and the method 130 is implemented in the first network node.

[0110] As seen in method 130, a first network node (i.e., MN 20) determines that a second network node (i.e., SN 22) should carry at least a portion of an application session for the UE (box 132). In response to making the determination, the first network node sends an indication to the second network node. The indication causes the second network node to configure Radio Access Network (RAN) Visible Quality of Experience (RV-QoE) information for the UE for at least a portion of the application session (box 134).

[0111] In one embodiment, the first network node determines that the application session for which the RVQoE measurement is configured will be carried by the second network node.

[0112] Further, in one embodiment, the first network node may determine that the second network node should carry at least a portion of the application session for the UE based on a switch in the path used to deliver the data flow of the application session.

[0113] In one embodiment, the first network node may determine that the second network node should carry at least a portion of the application session for the UE based on the determination to duplicate the data flow of the application session, in which case the duplicate data flow of the application session may be delivered to the UE via both the first network node and the second network node.

[0114] In another embodiment, the first network node may determine that the second network node should carry at least a portion of the application session for the UE based on the decision to set up a split bearer.

[0115] In some embodiments, the first network node sends one or more instructions for RVQoE configuration coordination to the second network node, hi such embodiments, the first network node sends instructions to transmit the RVQoE report to the second network node.

[0116] In one embodiment, the first network node receives an acknowledgment from the second network node in response to the one or more indications for RVQoE configuration coordination.

[0117] In another embodiment, the first network node receives a rejection from the second network node in response to one or more indications for RVQoE setting coordination, In these embodiments, the first network node may or may not receive an indication of a preferred RVQoE setting for the second network node along with the rejection.

[0118] In one embodiment, after receiving a rejection from the second network node, the first network node receives an Initiate Coordination Procedure message from the second network node to begin receiving the RVQoE report from the UE.

[0119] In one embodiment, the first network node receives an indication from the second network node to change the RVQoE configuration of the UE.

[0120] In at least one embodiment, the first network node receives the RVQoE report from the UE.

[0121] In one embodiment, the first network node sends an indication to the second network node identifying a type of data carried by a subflow of the application session, in which the subflow carries one of video data and audio data.

[0122] In one embodiment, the first network node configures RV-QoE information for the UE for at least a portion of the application session.

[0123] In one embodiment, the first network node sends an instruction to the UE for the UE to send an RVQoE report comprising one or more RVQoE parameters to the second network node.

[0124] In one embodiment, at least one RVQoE parameter included in the RVQoE report to be sent by the UE to the second network node is different from the RVQoE parameter included in the RVQoE report currently being sent by the UE.

[0125] In one embodiment, the RVQoE parameters comprise RVQoE measurements.

[0126] In one embodiment, one or more RVQoE parameters to be transmitted by the UE to the second network node are negotiated between the first network node and the second network node.

[0127] In another embodiment, the first network node sends a request to the second network node to reconfigure the RVQoE measurement for the UE.

[0128] In one embodiment, the first network node receives a request from the second network node to reconfigure RVQoE measurements for the UE, the request comprising RVQoE measurement reconfiguration for the UE.

[0129] In such an embodiment, the instruction sent to the UE to transmit the RVQoE report to the second network node comprises an RVQoE measurement reconfiguration received from the second network node.

[0130] 8 is a flow chart illustrating a method 140 for multi-connectivity operation for a user equipment (UE) in a communication system including a first network node and a second network node. In this embodiment, the first network node and the second network node are involved in the multi-connectivity operation of the UE, and the method 140 is implemented in the second network node.

[0131] 8, the second network node receives from the first network node an instruction to configure Radio Access Network (RAN) Visible Quality of Experience (RV-QoE) information for the UE 24 for at least a portion of the application session (box 142). Upon so receiving, the second network node sends a response message to the first network node indicating whether the second network node is to configure the RV-QoE information for the UE (box 144).

[0132] In one embodiment, the response message to the first network node is an acknowledgement indicating that the second network node will configure RVQoE information for the UE. In such an embodiment, the second network node may configure RVQoE measurements in the UE, or the second network node may modify an existing RVQoE configuration in the UE.

[0133] In another embodiment, the response message to the first network node is a rejection indicating that the second network node will not configure RVQoE information for the UE. In these embodiments, the second network node can then either send or refrain from sending an indication of a preferred RVQoE configuration with the response message to the first network node.

[0134] In one embodiment, after sending a response message indicating the rejection to the first network node, the second network node sends a collaboration procedure initiation message to the first network node to start receiving the RVQoE report from the UE.

[0135] In these embodiments, the second network node sends an indication to the first network node to change the RVQoE configuration of the UE.

[0136] In one or more embodiments, the second network node receives the RVQoE report from the UE.

[0137] In one embodiment, the second network node receives an indication from the first network node identifying the type of data carried by the subflow of the application session.

[0138] In one embodiment, the second network node sends an instruction to the UE for the UE to send the RVQoE report to the first network node.

[0139] In one embodiment, at least one parameter included in the RVQoE report to be sent by the UE to the first network node is different from a parameter included in the RVQoE report currently being sent by the UE.

[0140] In one embodiment, the RVQoE parameters comprise RVQoE measurements.

[0141] In one embodiment, one or more RVQoE parameters to be transmitted by the UE to the first network node are negotiated between the first network node and the second network node.

[0142] In one embodiment, the second network node sends a request to the first network node to reconfigure the RVQoE measurement for the UE.

[0143] In another embodiment, the second network node receives a request from the first network node to reconfigure RVQoE measurements for the UE, the request comprising RVQoE measurement reconfiguration for the UE.

[0144] In one embodiment, the instruction sent to the UE to transmit the RVQoE report to the first network node comprises an RVQoE measurement reconfiguration received from the first network node.

[0145] 9 is a flow diagram illustrating a method 150 implemented in a user equipment (UE) 24 for multi-connectivity operation for a UE in a communication system comprising a first network node and a second network node (i.e., a MN 20 and a SN 22). In this embodiment, the first network node and the second network node are involved in the multi-connectivity operation of the UE, and the UE is configured to send a Radio Access Network (RAN) Visual Quality of Experience (RV-QoE) report for an application session to the first network node.

[0146] 9, the UE 24 receives RVQoE information from one of the first network node and the second network node, which configures the UE 24 to send an RVQoE report for the application session to the other of the first network node and the second network node (box 152). In response to receiving the RVQoE information, the UE 24 obtains metrics for the application session according to the RVQoE information (box 154) and sends an RVQoE report for the application session to the other of the first network node and the second network node (box 156). The RVQoE report includes the metrics obtained by the UE 24.

[0147] In one embodiment, in response to receiving the RVQoE information, the UE resets its operation mode to the multi-connectivity mode.

[0148] In one embodiment, in response to receiving the RVQoE information, the UE resets the UE's operating mode to the single connectivity mode.

[0149] In one embodiment, the UE receives an indication from one of the first network node and the second network node to begin transmitting the RVQoE report to the other of the first network node and the second network node.

[0150] In one embodiment, at least one parameter included in the RVQoE report to be sent by the UE to the other of the first network node and the second network node is different from a parameter included in the RVQoE report currently being sent by the UE.

[0151] In one embodiment, the RVQoE parameters comprise RVQoE measurements.

[0152] In one embodiment, the instruction to send the RVQoE report to the other of the first network node and the second network node comprises an RVQoE measurement reconfiguration.

[0153] In any of the embodiments shown in FIGS. 7-9, the first network node is a master node (MN) and the second network node is a secondary node (SN).

[0154] Similarly, in any of the embodiments shown in FIGS. 7-9, the first network node is a secondary node (SN) and the second network node is a master node (MN).

[0155] An apparatus may perform any of the methods described herein by implementing any functional means, module, unit, or circuit. In one embodiment, for example, an apparatus comprises a respective circuit or circuitry configured to perform the steps illustrated in a method diagram. The circuit or circuitry, in this regard, may comprise one or more microprocessors along with circuitry and / or memory dedicated to performing certain functional processing. For example, the circuitry may include one or more microprocessors or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), dedicated digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory, such as read-only memory (ROM), random access memory, cache memory, flash memory devices, optical storage devices, and the like. The program code stored in memory may, in some embodiments, include program instructions for executing one or more communication and / or data communication protocols, as well as instructions for performing one or more of the techniques described herein. In embodiments that employ memory, the memory stores program code that, when executed by one or more processors, performs the techniques described herein.

[0156] 10 shows the main functional components of a UE 400. The UE 400 includes an antenna panel or antenna array with multiple antennas 410, communication circuitry 420, processing circuitry 430, and memory 440.

[0157] The communications circuitry 420 connects to the antenna 410 and includes radio frequency (RF) circuitry 422 for communicating over wireless communications links with multiple TRPs in the wireless communications system. The RF circuitry may include, for example, a transmitter and a receiver configured to operate according to a 5G standard or other wireless communications standard. In an exemplary embodiment, the RF circuitry includes two or more receiver chains for receiving signals transmitted from the spatially separated TRPs.

[0158] The processing circuitry 430 comprises one or more microprocessors, hardware, firmware, or a combination thereof that controls the overall operation of the UE 400. The processing circuitry 430 may be configured by software to perform the methods described herein, including the method 150 shown in FIG.

[0159] The memory 440 comprises both volatile and nonvolatile memory for storing computer program code and data required by the processing circuit 430 for operation. The memory 440 may comprise any tangible, non-transitory computer-readable storage medium for storing data, including electronic, magnetic, optical, electromagnetic, or semiconductor data storage. The memory 440 stores a computer program 450 comprising executable instructions that configure the processing circuit 430 in the UE 400 to perform the methods described herein, including method 150 shown in FIG. 9. The computer program 450 may comprise one or more code modules corresponding to the means or units described above in this regard. Generally, computer program instructions and configuration information are stored in non-volatile memory, such as ROM, erasable programmable read-only memory (EPROM), or flash memory. Temporary data generated during operation may be stored in volatile memory, such as random access memory (RAM). In some embodiments, the computer program 450 for configuring the processing circuit 430 as described herein may be stored on a removable memory, such as a portable compact disc, a portable digital video disc, or other removable medium. The computer program 450 may also be embodied in a carrier, such as an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium.

[0160] 11 illustrates the main functional components of a network node 500 (e.g., MN 20 and / or SN 22), which may comprise, by way of example, a base station (BS), a distributed unit (DU), a centralized unit (CU), or other RAN node. The RAN node 500 comprises communication circuitry 510, processing circuitry 520, and memory 530.

[0161] In some embodiments, the communications circuitry 510 comprises a radio frequency (RF) circuitry 512 and a network interface circuitry (NIC) 514. However, in other embodiments, a network node may comprise only the NIC 514. More particularly, the RF circuitry 512 may be located in one or more TRPs and comprises the RF components necessary to communicate with UEs over a wireless communications link. According to this embodiment, the RF circuitry 512 may comprise, for example, a transmitter and receiver configured to operate in accordance with the 5G standard or other wireless communications standards.

[0162] The communications circuitry 510 includes network interface circuitry (e.g., a NIC 514) for communication with other RAN nodes, core network nodes, and / or external systems. The network interface circuitry may include, for example, an Ethernet interface, an optical network interface, or a wireless interface.

[0163] The processing circuitry 520 comprises one or more microprocessors, hardware, firmware, or a combination thereof that controls the overall operation of the RAN node 500. The processing circuitry 520 may be configured by software to perform one or more of the methods described herein, including the methods 130, 140 shown in Figures 7 and 8.

[0164] The memory 530 comprises both volatile and non-volatile memory for storing computer program code and data required by the processing circuitry 520 for operation. The memory 530 may comprise any tangible, non-transitory computer-readable storage medium for storing data, including electronic, magnetic, optical, electromagnetic, or semiconductor data storage. The memory 530 stores a computer program 540 comprising executable instructions for configuring the processing circuitry 520 in the network node 500 to perform one or more of the methods described herein, including methods 130, 140 shown in Figures 7 and 8, respectively. The computer program 540 may comprise one or more code modules corresponding to the means or units described above in this regard.

[0165] Generally, computer program instructions and configuration information are stored in non-volatile memory, such as ROM, erasable programmable read-only memory (EPROM), or flash memory. Temporary data generated during operation may be stored in volatile memory, such as random access memory (RAM). In some embodiments, the computer program 550 for configuring the processing circuit 520 as described herein may be stored in removable memory, such as a portable compact disc, portable digital video disc, or other removable medium. The computer program 540 may also be embodied in a carrier, such as an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium.

[0166] Those skilled in the art will also appreciate that the embodiments herein further include corresponding computer programs comprising instructions that, when executed on at least one processor of the device, cause the device to perform any of the respective processes described above. The computer program may comprise one or more code modules corresponding to the means or units described above in this regard.

[0167] Embodiments further include a carrier containing such a computer program, which may comprise one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium.

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

[0169] Embodiments further include a computer program product, which may be stored on a computer-readable recording medium, comprising program code portions for performing the steps of any of the embodiments herein when the computer program product is executed by a computing device.

[0170] Additional embodiments are now described, at least some of which may be described, for illustrative purposes, as applicable in certain contexts and / or wireless network types, although the embodiments may likewise be applicable in other contexts and / or wireless network types not explicitly described.

[0171] FIG. 12 illustrates an example of a communication system 1100, according to some embodiments.

[0172] In this example, the communications system 1100 includes a communications network 1102 including an access network 1104, such as a radio access network (RAN), and a core network 1106 including one or more core network nodes 1108. The access network 1104 includes one or more access network nodes (one or more of which may be generally referred to as network nodes 1110), such as network nodes 1110a and 1110b, or any other similar Third Generation Partnership Project (3GPP) access nodes or non-3GPP access points. The network nodes 1110 facilitate direct or indirect connectivity of user equipment (UE) 1112a, 1112b, 1112c, and 1112d (one or more of which may be generally referred to as UEs 1112) to the core network 1106 over one or more wireless connections.

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

[0174] The UE 1112 may be any of a wide variety of communication devices, including a wireless device configured, configured, and / or operable to communicate wirelessly with the network node 1110 and other communication devices. Similarly, the network node 1110 is configured, capable of, configured, and / or operable to communicate, directly or indirectly, with the UE 1112 and / or with other network nodes or equipment in the communications network 1102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the communications network 1102.

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

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

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

[0178] In some examples, the communication network 1102 is a cellular network that implements 3GPP standardized features. Thus, the communication network 1102 may support network slicing to provide different logical networks to different devices connected to the communication network 1102. For example, the communication network 1102 may provide Ultra-Reliable Low Latency Communication (URLLC) services to some UEs, while providing enhanced Mobile Broadband (eMBB) services to other UEs and / or providing Massive Machine-Based Communication (mMTC) / Massive IoT services to still further UEs.

[0179] In some examples, the UE 1112 is configured to transmit and / or receive information without direct human interaction. For example, the UE may be designed to transmit information to the access network 1104 on a predetermined schedule, when triggered by an internal or external event, or in response to a request from the access network 1104. Furthermore, the UE may be configured to operate in a single or multi-RAT or multi-standard mode. For example, the UE may operate on any one or a combination of Wi-Fi, NR (New Radio), and LTE, i.e., configured for Multi-Radio Dual Connectivity (MR-DC), such as E-UTRAN (Enhanced UMTS Terrestrial Radio Access Network) New Radio-Dual Connectivity (EN-DC).

[0180] In this example, the hub 1114 communicates with the access network 1104 to facilitate indirect communication between one or more UEs (e.g., UEs 1112c and / or 1112d) and a network node (e.g., network node 1110b). In some examples, the hub 1114 may be a controller, a router, a content source, a content analyzer, or any of the other communication devices described herein with respect to UEs. For example, the hub 1114 may be a broadband router that enables access to the core network 1106 for the UE. As another example, the hub 1114 may be a controller that sends commands or instructions to one or more actuators in the UE. The commands or instructions may be received from the UE, the network node 1110, or may be due to executable code, scripts, processes, or other instructions in the hub 1114. As another example, the hub 1114 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 1114 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker, or other media distribution device, the hub 1114 may retrieve, via a network node, VR assets, video, audio, or other media or data related to sensory information, which the hub 1114 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In yet another example, the hub 1114 acts as a proxy server or orchestrator for the UEs, particularly if one or more of the UEs are low-energy IoT devices.

[0181] The hub 1114 may have a constant / permanent or intermittent connection to the network node 1110b. The hub 1114 may also enable different communication schemes and / or schedules between the hub 1114 and UEs (e.g., UEs 1112c and / or 1112d) and between the hub 1114 and the core network 1106. In other examples, the hub 1114 is connected to the core network 1106 and / or one or more UEs via a wired connection. Moreover, the hub 1114 may be configured to connect to an M2M service provider over the access network 1104 and / or to another UE over a direct connection. In some scenarios, a UE may establish a wireless connection with the network node 1110 while still connected via a wired or wireless connection through the hub 1114. In some embodiments, the hub 1114 may be a dedicated hub, i.e., a hub whose primary function is to route communications from / to the UE to / from the network node 1110b. In other embodiments, the hub 1114 may be a non-dedicated hub, i.e., a device that is capable of operating to route communications between the UE and the network node 1110b, but that is further capable of operating as a communication initiation and / or termination point for some data channels.

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

[0183] Host 1400 includes a processing circuit 1402 operably coupled to an input / output interface 1406, a network interface 1408, a power supply 1410, and a memory 1412 via a bus 1404. In other embodiments, other components may be included. Features of these components may be substantially similar to those described with respect to the devices of the previous figures, and therefore, those descriptions are generally applicable to the corresponding components of host 1400.

[0184] Memory 1412 may include one or more computer programs, including one or more host application programs 1414 and data 1416, which may include user data, e.g., data generated by a UE for host 1400 or data generated by host 1400 for a UE. Embodiments of host 1400 may utilize only a subset or all of the shown components. Host application program 1414 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UE (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application program 1414 may also provide user authentication and license checks, and may periodically report health, route, and content availability to a central node, such as a device in the core network or a device on the edge of the core network. Thus, the host 1400 may select and / or direct different hosts for over-the-top services for the UE. The host application program 1414 may support various protocols, such as HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[0185] 14 shows a communication diagram of a host 1602 communicating with a UE 1606 via a network node 1604 over a partial wireless connection, according to some embodiments. Exemplary implementations according to various embodiments of a UE (such as the UE 1112a of FIG. 12), a network node (such as the network node 1110a of FIG. 12), and a host (such as the host 1116 of FIG. 12) described in the previous paragraph will now be described with reference to FIG.

[0186] Similar to the host 1400, an embodiment of the host 1602 includes hardware such as a communications interface, processing circuitry, and memory. The host 1602 also includes software stored on or accessible by the host 1602 and executable by the processing circuitry. The software includes a host application that may be operable to provide services to a remote user, such as a UE 1606 connecting via an over-the-top (OTT) connection 1650 extending between the UE 1606 and the host 1602. In providing services to the remote user, the host application may provide user data that is transmitted using the OTT connection 1650.

[0187] The network node 1604 includes hardware that enables the network node 1604 to communicate with the host 1602 and the UE 1606. The connection 1660 may be direct or may pass through one or more other intermediate networks, such as a core network (similar to the core network 1106 of FIG. 10) and / or one or more public, private, or hosted networks. For example, the intermediate network may be a backbone network or the Internet.

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

[0189] The OTT connection 1650 may extend via a connection 1660 between the host 1602 and a network node 1604 and via a wireless connection 1670 between the network node 1604 and the UE 1606 to provide connectivity between the host 1602 and the UE 1606. The connections 1660 and wireless connections 1670 over which the OTT connection 1650 may be provided are depicted abstractly to show communication between the host 1602 and the UE 1606 via the network node 1604, without explicit reference to intermediary devices and the precise routing of messages through these devices.

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

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

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

[0193] In some examples, measurement procedures may be provided for the purpose of monitoring data rates, latency, and other factors that one or more embodiments improve upon. There may further be optional network functionality for reconfiguring the OTT connection 1650 between the host 1602 and the UE 1606 in response to fluctuations in the measurement results. The measurement procedures and / or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware in the host 1602 and / or the UE 1606. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection 1650 passes, and the sensors may participate in the measurement procedures by providing values ​​of the monitored quantities exemplified above, or other physical quantities from which software may calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 1650 may include message formats, retransmission settings, preferred routing, etc., and the reconfiguration need not directly change the operation of the network node 1604. Such procedures and functionality may be known and practiced in the art. In some embodiments, the measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation time, latency, etc. by the host 1602. The measurements may be implemented in software causing messages, particularly empty or "dummy" messages, to be sent using the OTT connection 1650 while monitoring propagation time, errors, etc.

[0194] The present embodiments may, of course, be practiced in other ways than as specifically set forth herein without departing from the features described therein. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive, and all changes that come within the meaning and range of equivalency of the appended claims are intended to be embraced therein.

Claims

1. A method (130) for multi-connectivity operation for a user equipment (UE) (24) in a communication system comprising a first network node (20) and a second network node (22), the first network node and the second network node being involved in the multi-connectivity operation of the UE, the method being implemented in the first network node; determining (132) that the second network node should carry at least a portion of an application session for the UE; sending (134) an indication to the second network node in response to said determining, causing the second network node to configure Radio Access Network (RAN) Visual Quality of Experience (RV-QoE) information for the UE for the at least part of the application session; A method (130) comprising:

2. The method of claim 1 , wherein the first network node determines that the application session for which RVQoE measurements are configured will be carried by the second network node.

3. 3. The method of claim 1, wherein determining that the second network node should carry at least a portion of an application session for the UE is based on switching a path used to deliver a data flow of the application session.

4. 3. The method of claim 1, wherein determining that the second network node should carry at least a portion of an application session for the UE is based on a decision to duplicate a data flow of the application session and deliver the duplicated data flow via both the first network node and the second network node.

5. The method of claim 1 or 2, wherein determining that the second network node should carry at least a part of an application session for the UE is based on a decision to set up a split bearer.

6. The method of any one of claims 1 to 5, further comprising the first network node sending (32, 52, 84, 110, 122) one or more indications for RVQoE configuration coordination to the second network node.

7. The method of any one of claims 1 to 6, further comprising the first network node sending (54, 86, 112) an indication for transmitting an RVQoE report to the second network node.

8. 8. The method of claim 6 or 7, further comprising the first network node receiving (34, 58, 88) an acknowledgement from the second network node in response to the one or more indications for RVQoE configuration coordination.

9. 8. The method of claim 6 or 7, further comprising the first network node receiving (40, 62, 94) a rejection from the second network node in response to the one or more indications for RVQoE setting coordination.

10. 10. The method of claim 9, wherein the first network node receives, together with the rejection, an indication of a preferred RVQoE setting for the second network node.

11. 10. The method of claim 9, wherein the first network node does not receive an indication of a preferred RVQoE setting for the second network node together with the rejection.

12. 12. The method of claim 9, wherein after receiving the rejection from the second network node, the method further comprises the first network node receiving (42, 64, 96) a cooperation procedure initiation message from the second network node to begin receiving RVQoE reports from the UE.

13. 12. The method of any one of claims 9 to 11, further comprising the first network node receiving (46, 68, 100) an indication of a change in RVQoE configuration of the UE from the second network node.

14. The method of any one of claims 1 to 13, further comprising receiving (116) an RVQoE report from the UE.

15. 15. The method of claim 1, further comprising sending (124) an indication to the second network node identifying the type of data carried by a subflow of the application session.

16. The method of claim 15 , wherein the subflow carries one of video data and audio data.

17. The method of any one of claims 1 to 16, wherein the first network node configures the RV-QoE information for the UE for the at least part of the application session.

18. 18. The method of claim 1, further comprising sending an instruction to the UE for the UE to send an RVQoE report to the second network node comprising one or more RVQoE parameters.

19. 19. The method of claim 18, wherein at least one RVQoE parameter included in the RVQoE report to be sent by the UE to the second network node is different from the RVQoE parameter included in the RVQoE report currently being sent by the UE.

20. 20. The method of claim 19, wherein the RVQoE parameters comprise RVQoE measurements.

21. 21. The method of claim 18, wherein the one or more RVQoE parameters to be transmitted by the UE to the second network node are negotiated between the first network node and the second network node.

22. 22. The method of any one of claims 18 to 21, wherein the first network node sends a request to the second network node to reconfigure the RVQoE measurements for the UE.

23. 23. The method of any one of claims 18 to 22, wherein the first network node receives a request from the second network node to reconfigure the RVQoE measurements for the UE, the request comprising an RVQoE measurement reconfiguration for the UE.

24. 24. The method of claim 23, wherein the instruction sent to the UE to transmit the RVQoE report to the second network node comprises the RVQoE measurement reconfiguration received from the second network node.

25. A method (140) for multi-connectivity operation for a user equipment (UE) (24) in a communication system comprising a first network node (20) and a second network node (22), the first network node and the second network node being involved in the multi-connectivity operation of the UE, the method being implemented in the second network node; receiving (142) from the first network node an indication to configure Radio Access Network (RAN) Visual Quality of Experience (RV-QoE) information for the UE for at least a portion of an application session; sending a response message to the first network node (144), the response message indicating whether the second network node will configure the RVQoE information for the UE; A method (140) comprising:

26. 26. The method of claim 25, wherein the response message to the first network node is an acknowledgement indicating that the second network node will configure the RVQoE information for the UE.

27. 27. The method of claim 25 or 26, further comprising the second network node configuring (36, 58, 90) RVQoE measurements in the UE.

28. 27. The method of claim 25 or 26, wherein the configuring the RVQoE measurements at the UE comprises the second network node modifying an existing RVQoE configuration at the UE.

29. 26. The method of claim 25, wherein the response message to the first network node is a rejection indicating that the second network node will not configure the RVQoE information for the UE.

30. 30. The method of claim 29, further comprising sending an indication of a preferred RVQoE setting with the response message to the first network node.

31. 30. The method of claim 29, further comprising refraining from sending an indication of a preferred RVQoE setting to the first network node with the response message.

32. 32. The method according to any one of claims 29 to 31, wherein after sending the response message indicating the rejection to the first network node, the method further comprises the second network node sending (42, 64, 96) a collaboration procedure initiation message to the first network node to start receiving RVQoE reports from the UE.

33. 33. The method of any one of claims 29 to 32, further comprising sending (46, 68, 100) to the first network node an indication of a change in RVQoE settings of the UE.

34. 34. The method of any one of claims 25 to 33, further comprising receiving (38, 48, 60, 70, 92, 102) a RVQoE report from the UE.

35. 35. The method of any one of claims 25 to 34, further comprising receiving (122) from the first network node an indication identifying a type of data carried by a subflow of the application session.

36. 36. The method of any one of claims 25 to 35, further comprising sending an instruction to the UE for the UE to send an RVQoE report to the first network node.

37. 37. The method of claim 36, wherein at least one parameter included in the RVQoE report to be sent by the UE to the first network node is different from a parameter included in the RVQoE report currently being sent by the UE.

38. 38. The method of claim 37, wherein the RVQoE parameters comprise RVQoE measurements.

39. 39. A method according to any one of claims 36 to 38, wherein one or more RVQoE parameters to be transmitted by the UE to the first network node are negotiated between the first network node and the second network node.

40. 40. A method according to any one of claims 36 to 39, wherein the second network node sends a request to the first network node to reconfigure the RVQoE measurements for the UE.

41. 41. The method of any one of claims 36 to 40, wherein the second network node receives a request from the first network node to reconfigure the RVQoE measurements for the UE, the request comprising an RVQoE measurement reconfiguration for the UE.

42. 42. The method of claim 41 , wherein the instruction sent to the UE to transmit the RVQoE report to the first network node comprises the RVQoE measurement reconfiguration received from the first network node.

43. A method (150) for multi-connectivity operation for a user equipment (UE) (24) in a communication system comprising a first network node (20) and a second network node (22), the first network node and the second network node being involved in the multi-connectivity operation of the UE, the UE being configured to send a Radio Access Network (RAN) Visual Quality of Experience (RV-QoE) report for an application session, the method being implemented in the UE; receiving RVQoE information from one of the first network node and the second network node, the UE configuring the UE to send an RVQoE report for the application session to the other of the first network node and the second network node (152); obtaining metrics for the application session according to the RVQoE information (154); sending (156) the RVQoE report for the application session to the other of the first network node and the second network node, the RVQoE report including the metric; A method (150) comprising:

44. 44. The method of claim 43, wherein the UE reconfigures (114) an operation mode of the UE to a multi-connectivity mode in response to receiving the RVQoE information.

45. 44. The method of claim 43, wherein the UE reconfigures (114) an operation mode of the UE to a single connectivity mode in response to receiving the RVQoE information.

46. 46. ​​The method of any one of claims 43 to 45, further comprising receiving an indication from the one of the first network node and the second network node to begin sending RVQoE reports to the other of the first network node and the second network node.

47. 47. The method of claim 46, wherein at least one parameter included in the RVQoE report to be sent by the UE to the other of the first network node and the second network node is different from a parameter included in the RVQoE report currently being sent by the UE.

48. 48. The method of claim 47, wherein the RVQoE parameters comprise RVQoE measurements.

49. 49. The method of claim 48, wherein the instruction to send the RVQoE report to the other of the first network node and the second network node comprises an RVQoE measurement reconfiguration.

50. 50. The method of any one of claims 43 to 49, wherein the first network node is a master node (MN) (20) and the second network node is a secondary node (SN) (22).

51. 51. The method of any one of claims 43 to 50, wherein the first network node is a secondary node (SN) (22) and the second network node is a master node (MN) (20).

52. 52. The method of any one of claims 43 to 51, wherein the first network node and the second network node are Radio Access Network (RAN) (18) nodes.

53. A first network node (500) for multi-connectivity operation for a user equipment (UE) (24) in a communication system, the communication system comprising the first network node and a second network node (22), the first network node and the second network node being involved in the multi-connectivity operation of the UE, the first network node comprising: a processing circuit (520); a memory circuit (530) configured to store instructions (540) executable by said processing circuit; whereby the first network node determining (132) that the second network node should carry at least a portion of an application session for a UE; sending (134) an indication to the second network node in response to said determining, causing the second network node to configure Radio Access Network (RAN) Visual Quality of Experience (RV-QoE) information for the UE for the at least part of the application session; a first network node (500) configured to:

54. 54. The first network node of claim 53, wherein the first network node is further configured to perform a method according to any one of claims 2 to 24 and 50 to 52.

55. A first network node (500) for multi-connectivity operation for a user equipment (UE) (24) in a communication system, the communication system comprising the first network node and a second network node (22), the first network node and the second network node being involved in the multi-connectivity operation of the UE, the first network node comprising: determining (132) that the second network node should carry at least a portion of an application session for a UE; sending (134) an indication to the second network node in response to said determining, causing the second network node to configure Radio Access Network (RAN) Visual Quality of Experience (RV-QoE) information for the UE for the at least part of the application session; a first network node (500) configured to:

56. 56. The first network node of claim 55, wherein the first network node is further configured to perform a method according to any one of claims 2 to 24 and 50 to 52.

57. 52. A computer program (450) comprising instructions stored thereon which, when executed on a processing circuit (520) of a first network node (500), causes the first network node to perform a method according to any one of claims 1 to 24 and 50 to 52.

58. 58. A carrier containing the computer program of claim 57, the carrier being one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

59. 52. A non-transitory computer-readable storage medium (530) having a computer program (540) stored thereon, the computer program comprising executable instructions that, when executed by processing circuitry (520) in a first network node (500), cause the first network node to perform the method of any one of claims 1 to 24 and 50 to 52.

60. A second network node (500) for multi-connectivity operation for a user equipment (UE) (24) in a communication system, the communication system comprising a first network node (20) and the second network node, the first network node and the second network node being involved in the multi-connectivity operation of the UE, the second network node comprising: a processing circuit (520); a memory circuit (530) configured to store instructions (540) executable by said processing circuit; whereby the second network node receiving (142) from the first network node an indication to configure Radio Access Network (RAN) Visual Quality of Experience (RV-QoE) information for the UE for at least a portion of an application session; sending a response message to the first network node (144), the response message indicating whether the second network node will configure the RVQoE information for the UE; a second network node (500) configured to:

61. 61. The second network node of claim 60, wherein the second network node is further configured to perform a method according to any one of claims 26 to 42 and 50 to 52.

62. A second network node (500) for multi-connectivity operation for a user equipment (UE) (24) in a communication system, the communication system comprising a first network node (20) and the second network node, the first network node and the second network node being involved in the multi-connectivity operation of the UE, the second network node comprising: receiving (142) from the first network node an indication to configure Radio Access Network (RAN) Visual Quality of Experience (RV-QoE) information for the UE for at least a portion of an application session; sending a response message to the first network node (144), the response message indicating whether the second network node will configure the RVQoE information for the UE; a second network node (500) configured to:

63. 63. The second network node of claim 62, wherein the second network node is further configured to perform a method according to any one of claims 26 to 42 and 50 to 52.

64. 52. A computer program (540) comprising instructions stored thereon which, when executed on a processing circuit (520) of a second network node (500), causes the second network node to perform the method of any one of claims 25 to 42 and 50 to 52.

65. 65. A carrier containing the computer program of claim 64, the carrier being one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

66. 52. A non-transitory computer-readable storage medium (530) having a computer program (540) stored thereon, the computer program comprising executable instructions that, when executed by a processing circuit (520) in a second network node (500), cause the second network node to perform the method of any one of claims 25 to 42 and 50 to 52.

67. A user equipment (UE) (400) in a communication system comprising a first network node (20) and a second network node (22), wherein the first network node and the second network node are involved in a multi-connectivity operation of the UE, and the UE is configured to send a Radio Access Network (RAN) Visual Quality of Experience (RV-QoE) report for an application session, the method being implemented in the UE; a processing circuit (430); a memory circuit (440) configured to store instructions executable by said processing circuit; whereby the UE receiving RVQoE information from one of the first network node and the second network node, the UE configuring the UE to send an RVQoE report for the application session to the other of the first network node and the second network node (152); obtaining metrics for the application session according to the RVQoE information (154); sending (156) the RVQoE report for the application session to the other of the first network node and the second network node, the RVQoE report including the metric; A user equipment (UE) (400) configured to:

68. 68. The UE of claim 67, wherein the UE is further configured to perform a method according to any one of claims 44 to 52.

69. A user equipment (UE) (400) in a communication system comprising a first network node (20) and a second network node (22), wherein the first network node and the second network node are involved in a multi-connectivity operation of the UE, and the UE is configured to send a Radio Access Network (RAN) Visual Quality of Experience (RV-QoE) report for an application session, the UE comprising: receiving RVQoE information from one of the first network node and the second network node, the UE configuring the UE to send an RVQoE report for the application session to the other of the first network node and the second network node (152); obtaining metrics for the application session according to the RVQoE information (154); sending (156) the RVQoE report for the application session to the other of the first network node and the second network node, the RVQoE report including the metric; A user equipment (UE) (400) configured to:

70. 70. The UE of claim 69, wherein the UE is further configured to perform a method according to any one of claims 44 to 52.

71. 53. A computer program (450) comprising instructions stored thereon which, when executed on a processing circuit (430) of a user equipment (UE) (400), causes the UE to perform the method of any one of claims 43 to 52.

72. 72. A carrier containing the computer program of claim 71, the carrier being one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

73. 53. A non-transitory computer-readable storage medium (440) having a computer program (450) stored thereon, the computer program comprising executable instructions that, when executed by a processing circuit (430) in a user equipment (UE) (400), cause the UE to perform the method of any one of claims 43 to 52.

Images