JP7854107B2 - Inter-node coordination for reporting visible and perceived quality of wireless access networks in dual connectivity - Google Patents

Description

This disclosure relates to wireless communication, and more specifically, to inter-node coordination for reporting in a multi-node connectivity environment.

The Third Generation Partnership Project (3GPP) is developing and is developing standards for fourth-generation (4G) wireless communication systems (also known as Long Term Evolution (LTE)) and fifth-generation (5G) wireless communication systems (also known as New Radio (NR)). Among the features of such systems is the provision of broadband communication between network nodes, such as base stations, and mobile user devices (UEs) (sometimes called wireless devices (WDs)), as well as communication between network nodes and between UEs. 3GPP is also developing standards for sixth-generation (6G) wireless communication systems.

Furthermore, wireless communication systems, such as 5G and 6G systems, may comprise at least one radio access network (RAN) and/or one or more RAN network nodes. Figure 1 shows an exemplary overall architecture of a next-generation RAN (NG-RAN). The NG-RAN includes a set of gNBs (i.e., network nodes) connected to a 5G core (5GC) through an NG interface.

Note: NG-RAN may also include a set of next-generation e-nodes B (ng-eNBs), as specified, for example, in 3GPP Technical Specification (TS) 38.300 v17.1.0. An ng-eNB may include an ng-eNB centralized unit (NG-eNB-CU) and one or more ng-eNB distributed units ((one or more) ng-eNB-DUs). The ng-eNB-CU and ng-eNB-DUs may be connected via a W1 interface. Furthermore, the general principles described herein may apply to the ng-eNB and the W1 interface, for example, unless otherwise explicitly specified. gNBs can support frequency-division duplex (FDD) mode, time-division duplex (TDD) mode, or dual-mode operation. Additionally, gNBs may be interconnected via an Xn interface.

Furthermore, a gNB may include a gNB-CU and one or more gNB-DUs. The gNB-CU and gNB-DUs may be connected via an F1 interface. One gNB-DU may be connected to one gNB-CU.

Note: In the case of network sharing via multiple cell ID broadcasting, each cell identification information associated with a subset of the PLMN corresponds to a gNB-DU and the gNB-CU to which the gNB-DU is connected; that is, the corresponding gNB-DUs share the same physical layer cell resources.

Note: For resilience, a gNB-DU can be connected to multiple gNB-CUs through appropriate implementation.

NG, Xn, and F1 can be logical interfaces. In the case of NG-RAN, the NG and Xn-C interfaces for a gNB consisting of a gNB-CU and a gNB-DU terminate at the gNB-CU. In the case of dual connectivity between E-UTRA and NR (EN-DC), the S1-U and X2-C interfaces for a gNB consisting of a gNB-CU and a gNB-DU terminate at the gNB-CU. The gNB-CU and connected gNB-DU are visible, and are only visible as gNBs to other gNBs and 5GCs, for example.

Nodes hosting the user plane portion of the NR PDCP (e.g., gNB-CU, gNB-CU user plane (UP), and, in the case of EN-DC, the master eNB (MeNB) or secondary gNB (SgNB) depending on the bear split) may perform user inactivity monitoring and further notify nodes with C-plane connections to the core network (e.g., on E1, X2) of such inactivity or (re)activation. Nodes hosting the NR RLC (e.g., gNB-DU) may perform user inactivity monitoring and further notify nodes hosting the control plane, such as the gNB-CU or gNB-CU control plane (CP), of such inactivity or (re)activation.

Uplink (UL) packet data control protocol (PDCP) settings (i.e., how the UE uses UL at the support node) are instructed via X2-C (for EN-DC), Xn-C (for NG-RAN), and F1-C. Radio link shutdown/restart for downlink (DL) and/or UL is instructed via X2-U (for EN-DC), Xn-U (for NG-RAN), and F1-U. NG-RAN is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). The NG-RAN architecture, i.e., the NG-RAN logical nodes and the interfaces between NG-RAN logical nodes, is defined as part of the RNL. For each NG-RAN interface (NG, Xn, F1), the relevant Transport Network Layer (TNL) protocols and functions are specified. TNL provides services for user-plane transport and signaling transport.

In an NG-Flex configuration, each NG-RAN node may be connected to all AMFs in an AMF set within an Access and Mobility Function (AMF) area that supports at least one slice also supported by the NG-RAN node. The AMF set and AMF area may be those defined in 3GPP TS23.501 v17.5.0. If security protection for control plane and user plane data on the TNL of the NG-RAN interface must be supported, Network Domain Security/Internet Protocol (NDS/IP) 3GPP TS33.501 v17.6.0 may apply.

Overall Architecture for Separating gNB-CU-CP and gNB-CU-UP An overall architecture for separating gNB-CU-CP and gNB-CU-UP is shown in the example in Figure 2 and may be the overall architecture specified in 3GPP TS37.483. As described above, a gNB may include a gNB-CU-CP, a plurality of gNB-CU-UPs, and a plurality of gNB-DUs. A gNB-CU-CP is connected to a gNB-DU through an F1-C interface. A gNB-CU-UP is connected to a gNB-DU through an F1-U interface. A gNB-CU-UP is connected to a gNB-CU-CP through an E1 interface. One gNB-DU is connected to only one gNB-CU-CP. One gNB-CU-UP is connected to only one gNB-CU-CP.

Note 1: For resilience, gNB-DU and/or gNB-CU-UP can be connected to multiple gNB-CU-CPs through appropriate implementation.

One gNB-DU may be connected to multiple gNB-CU-UPs under the control of the same gNB-CU-CP. One gNB-CU-UP may be connected to multiple DUs under the control of the same gNB-CU-CP.

Note 2: Connectivity between gNB-CU-UP and gNB-DU is established by gNB-CU-CP using the bearer context management function.

Note 3: The gNB-CU-CP selects one or more appropriate gNB-CU-UPs for the requested service for the UE. If there are multiple CU-UPs, they belong to the same security domain as defined in 3GPP TS33.210 v17.0.0.

Note 4: Data forwarding between gNB-CU-UP during a gNB-CU-CP handover within a gNB may be supported by Xn-U.

Dual Connectivity In dual connectivity (DC), multiple transmit/receive UEs may be connected to two or more RAN nodes. These RAN nodes may be of the same radio access technology (RAT) (both master and secondary nodes in NR or LTE, respectively), or of different RATs, for example, one master LTE node and one secondary NR node. Specification 3GPP TS37.340 v17.1.0 describes the principle of multi-radio dual connectivity.
==
General MR-DC Principle Multi-Radio Dual Connectivity (MR-DC) is a generalization of intra-E-UTRA dual connectivity (DC) as described in 3GPP TS36.300, in which multiple Rx/Tx-enabled UEs can be configured to utilize resources provided by two different nodes connected via a non-ideal backhaul: one providing NR access and the other providing either E-UTRA access or NR access. One node acts as the master node (MN) and the other as the secondary node (SN). The MN and SN are connected via a network interface, with at least the MN connected to the core network.
MN and/or SN may operate with shared spectral channel access.
All functions specified for UE may be used for IAB-MT unless otherwise specified. Similar to those specified for UE, IAB-MT can access the network using either a single network node or two different nodes with EN-DC and NR-DC architectures. Backhaul traffic on the E-UTRA radio interface is not supported in EN-DC.
Note 1: MR-DC is designed based on the assumption of non-ideal backhaul between different nodes, but it can also be used in the case of ideal backhaul.
Note 2: All MR-DC normative texts and procedures in this version of the specification refer to the case of aggregated nodes. Details regarding non-aggregated nodes for MR-DC operation are described in 3GPP TS38.401.
MR-DC with EPC
E-UTRAN supports MR-DC via E-UTRA-NR Dual Connectivity (EN-DC), where the UE is connected to one eNB acting as MN and one en-gNB acting as SN. The eNB is connected to the EPC via the S1 interface and to the en-gNB via the X2 interface. The en-gNB may also be connected to the EPC via the S1-U interface and to other en-gNBs via the X2-U interface. An exemplary EN-DC overall architecture is shown in Figure 3.
MR-DC with 5GC
E-UTRA-NR Dual Connectivity NG-RAN supports NG-RAN E-UTRA-NR Dual Connectivity (NGEN-DC), where the UE is connected to one ng-eNB acting as MN and one gNB acting as SN.
NR-E-UTRA Dual Connectivity NG-RAN supports NR-E-UTRA Dual Connectivity (NE-DC), where the UE is connected to one gNB acting as MN and one ng-eNB acting as SN.
NR-NR Dual Connectivity NG-RAN supports NR-NR Dual Connectivity (NR-DC), where a UE is connected to one gNB acting as an MN and another gNB acting as an SN. Furthermore, NR-DC can also be used when a UE is connected to two gNB-DUs, one serving an MCG and the other serving an SCG, which are connected to the same gNB-CU and act as both MN and SN.
=====================End of excerpt from 3GPP TS37.340=

One or more flows for setting up dual connectivity may be the flows described in Chapter 10 of 3GPP TS37.340, as shown in Figure 4, i.e., the procedure for adding a second node.

Overview of the QoE Framework: "Normal" QoE
Quality of Experience (QoE) measurement, also known as "Application Layer Measurement," is specified for LTE and UMTS, and for NR in 3GPP Release 17 (Rel-17). The purpose of Application Layer Measurement is to measure the end-user experience when using certain applications. Currently, QoE measurement is supported for streaming services and for mobility telephony services for internet protocol-based media systems (MTSI). For NR, at least VR may be added to the list of services for which QoE measurement is specified and supported.

The solutions in LTE and UMTS are similar in overall principle as follows: Experienced Quality 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 RRC signaling. The application layer measurement settings (also called QoE measurement settings or QoE settings) received by the RAN from the Operations and Maintenance (OAM) system or CN are encapsulated in a transparent container and forwarded to the UE in downlink radio resource control (RRC) messages. The application layer measurement reports (also called QoE reports) received by the UE Access Hierarchy (UE AS) layer or UE RRC layer from higher layers of the UE (application layers) are encapsulated in a transparent container and sent to the network in uplink RRC messages. The RAN then forwards the QoE reports to the Measurement Collector Entity (MCE).

In 3GPP Rel-17, a new research item was initiated for NR, titled "Research on NR QoE Management and Optimization for Diverse Services." Specification work for 3GPP Rel-17 is still ongoing. The objective of the research item is to study solutions for QoE measurement in NR. QoE management in NR will not only collect perceived quality parameters for streaming services but also consider the general performance requirements of diverse services (e.g., Augmented Reality/Virtual Reality (AR/VR) and Ultra-High Reliability and Low Latency Communications (URLLLC), of which at least VR appears to be covered in 3GPP Rel-17). Based on service requirements, NR research also includes more adaptable QoE management schemes that enable network optimization to satisfy user experience for diverse services.

The configuration data related to QoE measurements (commonly referred to as application layer measurements in the standard specification) consists of a service type instruction, an instruction for the area (indicated as the area scope) in which the measurement should be performed, the IP address of the entity (often spelled out as the measurement collector entity or measurement collection entity, and referred to as the MCE, although the entity is sometimes called the trace collection entity) to which the collected measurement results (i.e., the QoE report) should be sent, and a set of instructions on what types of measurements should be performed and details on how these measurements should be performed. These instructions are placed in a "container" that cannot be interpreted and not attempted to read by the UE, for example, the application layer in the WD, the network entity that handles the instructions, for example, the network entity that forwards the instructions to the UE, and the UE access hierarchy. The currently specified service types are MTSI and Streaming Services (DASH), and at least the service type VR will be added in 3GPP Rel-17. The area scope is defined in terms of a cell or network-related area. In UMTS, the area range is defined as either a list of cells, a list of routing areas, or a list of tracking areas. In LTE, the area range is defined as either a list of cells or a list of tracking areas. In NR, the area range will be defined as either a list of cells or a list of tracking areas.

QoE, and especially QoE configuration, can take two forms: management-based QoE configuration and signaling-based QoE configuration. In both cases, QoE configuration occurs in an OAM system or some other management entity, for example, one that addresses customer satisfaction. All of these entities are referred to herein as the OAM system (the OAM system also includes further entities). In the case of management-based QoE (m-based QoE), the OAM system is generally interested in general QoE statistics from a given area (defined as an area range). The m-based QoE configuration is sent directly from the OAM system to the RAN nodes that control the cells within the area range. Each RAN node then selects UEs within the area range (and also meets any other relevant conditions, such as supporting the application/service type in question) and sends the m-based QoE configuration to these UEs.

In the case of signaling-based QoE (s-based QoE), the OAM system is interested in collecting QoE measurement results from a particular UE, for example, because a user of that UE has filed a complaint. The OAM system sends the s-based QoE settings to the HSS (in EPS/LTE) or UDM (in 5GS/NR), which forwards the QoE settings to the UE's current core network node (CN), for example, the MME in EPS/LTE or the AMF in 5G/NR. The CN then forwards the s-based QoE settings to the RAN node serving the UE, which forwards the s-based QoE settings to the UE.

A container containing a service type instruction and a measurement instruction is forwarded to the UE. The UE is unaware of whether the received QoE configuration is m-based or s-based. In legacy systems, the QoE framework is integrated with the tracing function, and a trace ID is associated with each QoE configuration. In NR, the QoE function is logically separated from the tracing function, but it still partially reuses the trace signaling mechanism. In NR and LTE, a globally unique QoE reference (formed from Mobile Country Code (MCC) + Mobile Network Code (MNC) + QMC ID, where the QMC ID is a 24-bit string) is associated with each QoE configuration. The QoE reference is contained within the container with the measurement instruction and is also sent to the RAN (i.e., gNB in NR). In the case of communication between the gNB and the UE, the QoE reference is replaced by a shorter identifier, indicated as measConfigAppLayerId, which is locally unique within the UE (i.e., there is a one-to-one mapping between measConfigAppLayerId and the QoE reference for each QoE configuration provided to the UE). The measConfigAppLayerId is stored in the UE access layer and forwarded in AT commands (the type of command used in communication between the modem portion of the UE and the application layer of the UE) along with a container containing service type indications and measurement instructions.

Reports containing the collected QoE measurements (QoE reports) are sent from the UE application layer to the UE access layer, which forwards these reports to the RAN, and the RAN forwards these reports to the MCE. These QoE measurements are placed in a "container," which is uninterpretable to the UE access layer and the RAN. QoE reports can be configured to be periodic or sent only at the end of an application session. Furthermore, the RAN can instruct the UE to pause QoE reporting, for example, if a cell/gNB is overloaded.

The RAN (Random Access Network) is unaware of when application sessions with associated QoE measurement sessions are in progress, and the UE (User Environment) access hierarchy is also unaware of this automatically. A relaxation of these session start/stop instructions, which are sent from the application layer in the UE to the UE AS (Application Environment System) and from the UE AS to the RAN, may be introduced. The session stop instruction may be implicit in the form of a QoE report sent when the application session and associated QoE measurement session have ended.

RAN, as an implementation-based decision, may decide to release the QoE settings for a UE at any given time. Generally, this occurs when the UE moves outside the area set for QoE measurement, commonly referred to as the area range.

Furthermore, one opportunity offered by legacy solutions is the ability to maintain QoE measurement for the entire session, even during handover situations. It is also discussed that even if the UE moves outside the defined area range during this time, it should continue to measure the QoE of the ongoing application session until the application session ends.

RAN visible QoE (RVQoE)
In NR, 3GPP Rel-17 introduced RAN-visible QoE measurement. A general explanation can be found in 3GPP TS38.300 v17.0.0 section 21.4.

RAN Visible QoE measurements are configured by NG-RAN nodes, where a subset of QoE metrics is reported by the NG-RAN node from the UE as readable explicit information elements (IEs). RAN Visible QoE measurements (e.g., RAN Visible QoE metrics, RAN Visible QoE values) can be used by NG-RAN nodes for network optimization. RAN Visible QoE measurements are supported for DASH streaming services and VR services. NG-RAN nodes configure RAN Visible QoE measurements to collect all or part of the available RAN Visible QoE metrics, where metric availability indications are received from the OAM or CN. The set of available RAN Visible QoE metrics is a subset of metrics already configured as part of the QoE measurement configuration encapsulated in a transparent container. The Packet Data Unit (PDU) session IDs (one or more) corresponding to the service undergoing QoE measurement may also be reported by the UE along with the RAN-visible QoE measurement results.

A request to collect QoE measurements that are not visible in the RAN (also called OAM-QoE in R3-223290) is initiated by the OAM and identified by a QoE reference. The definition for this identifier can be found, for example, in 3GPP TS28.405 v17.1.0, section 5.2.
The QoE reference parameter specifies the network request session. The QoE reference is globally unique and is therefore constructed as follows:
■ MCC + MNC + QMC ID, where MCC and MNC are associated with a QMC activation request from the management system to identify a single PLMN containing the management system, and the QMC ID is a 3-byte octet string.
■ QMC IDs are generated by the management system or operator.
■ The QMC ID is used to identify QoE measurement collection jobs at traffic nodes and measurement collection centers.

The UE AS layer can report RAN-visible QoE measurements to the gNB in RRC format, and the UE application layer can be configured to perform more application layer measurements simultaneously (up to 16 in NR Rel-17). For example, in 3GPP TS38.331, application layer measurements are identified by MeasConfigAppLayerId IE.

In gNB, RAN-visible QoE information can be transferred from gNB-CU to gNB-DU in a procedure described in 3GPP TS38.473 v17.0.0. The procedure is UE-related; that is, it is specific to the UE.

QoE Information Transfer The purpose of the QoE information transfer procedure is to transfer RAN-visible QoE information from the gNB-CU to the gNB-DU. The procedure uses UE-related signaling. Figure 5 shows the QoE transfer procedure. The gNB-CU initiates the procedure by sending a QoE information transfer message to the gNB-DU. If a QoE information list IE is included in the QoE information transfer message, the gNB-DU may take the QoE information list IE into consideration in accordance with 3GPP TS38.300.

To indicate information related to RAN-visible QoE, a message is sent from the gNB-CU to the gNB-DU. Direction: gNB-CU → gNB-DU. Figure 6 shows two tables containing parameters related to QoE information transfer.

QoE Metric Figure 7 shows a typical QoE metric. IE provides RAN-visible QoE measurement reports to gNB-DU.

In contribution document R3-223128 to the 3GPP TSG-RAN WG3 meeting #116-e, the association of RAN-visible QoE reports with references was discussed.
In F1AP, a list containing the currently agreed-upon RVQoE metrics is transmitted over F1 using UE-related signaling. However, the reports are not associated with any reference or other IDs, for example. Therefore, the gNB-DU will not know how many different application sessions are providing reports, and thus the currently defined signaling will not enable the gNB-DU to distinguish between QoE reports coming from different application sessions. Furthermore, the gNB-DU will not be able to group reports that it receives sequentially from a given application session, and therefore, for example, will not be able to track trends in the reported data.
Candidate references or other IDs that can resolve this issue are generally QoE references or short RRC IDs (measConfigAppLayerId) assigned by the UE. The F1AP CR submitted to this conference in R3-223131 proposes using QoE references, but the final selection may be subject to further evaluation.

In the same contribution document, the following proposals are made in accordance with the reported discussions.
Proposal 3: Discuss and agree to identify RVQoE reporting information on F1 using a QoE reference or short RRC id (measConfigAppLayerId) in RAN3.

Signaling Radio Bearer (SRB)
The signaling radio bearer is configured in the UE for sending control plane messages to and from the UE. The current specification allows for the configuration of five different SRBs. SRB0 is used for initial RRC setup before security is activated. SRB1 is used for most RRC messages, and SRB2 is used for NAS messages.

When Dual Connectivity (DC) is configured on the UE, SRB1 is used to communicate with the Master Node (MN). Additionally, in a DC, SRB3 may be configured on the UE for direct communication between the UE and the Secondary Node (SN).

A dedicated SRB4 was defined for the transmission of QoE and RVQoE reports. In Rel-17, SRB4 is used solely for the transmission of QoE and RVQoE reports within the RRC message MeasurementReportAppLayer to the master node.

In management-based (m-based) QoE and RVQoE measurement acquisition, a possible scenario is that both nodes serving the UE in NR Dual Connectivity (NR-DC) (e.g., MN and SN) are, for example, within the same management-based (m-based) QoE measurement setting area range, and therefore within the group of RAN nodes receiving the m-based setting. Based on the information received along with this QE setting, the RAN nodes (MN and/or SN) may configure the UE to also perform RVQoE measurements for the same application session.

In management-based (m-based) QoE and RVQoE measurement acquisition, a possible scenario is that both nodes serving the UE in NR Dual Connectivity (NR-DC) (e.g., MN and SN) are, for example, within the same management-based (m-based) QoE measurement setting area range, and therefore within the group of RAN nodes receiving the m-based setting. Based on the information received along with this QE setting, the RAN nodes (MN and/or SN) may configure the UE to also perform RVQoE measurements for the same application session.

According to the 3GPP specification, a UE will deliver QoE and RVQoE reports to the network by using SRB4. In this regard, a UE can only establish one type of SRB, which means that a UE cannot establish SRB4 for both nodes serving the UE. Furthermore, a possible scenario is that an application session receiving QoE and RVQoE measurements is carried to a dual-connected UE via only one leg, where the RAN does not know (or at least does not know in advance) which bearer maps to which application session, and therefore has no control or direct knowledge of which leg carries this application session. Therefore, the corresponding RVQoE report will only be useful for one of the two RAN nodes serving the UE (the RAN node that delivers data about the application session to the UE), and the RVQoE report will not be useful for the other RAN node serving the UE, even if this RAN node is the one that configured the RVQoE metric for the UE.

In other words, it remains unclear how to ensure that the "correct" RAN node (of the two serving the UE in the NR-DC) receives the RVQoE report. Note that even if the UE in the NR-DC is allowed to establish SRB4 to both RAN nodes serving that UE, problems will still exist.

Furthermore, a RAN node can only set an RVQoE measurement on a UE if the corresponding QoE measurement is simultaneously set on the UE. This effectively means that a RAN node can only set an RVQoE measurement on a UE if OAM approves it.

Another aspect to consider is that even if the UE can only configure one SRB4, the UE may receive multiple RVQoE configurations corresponding to different service types from different RAN nodes (for example, the UE receives a first RVQoE configuration for service type 1 from a first node, and (later) a second RVQoE configuration for service type 2 from a second node). It is also unclear how to ensure that each node receives RVQoE reports related to the (one or more) service types for which it issued the corresponding RVQoE configuration to the UE (in this example, how to ensure that the first node receives the RVQoE report related to service type 1 and the second node receives the RVQoE report related to service type 2).

Several embodiments advantageously provide methods, systems, and apparatus for inter-node coordination for reporting in a multi-node connectivity environment. In some embodiments, a mechanism (i.e., a method) is described. This method enables RAN nodes (i.e., network nodes) serving UEs in an NR-DC or any other multi-radio connectivity setup to coordinate, inform each other of which of them has configured RVQoE measurements for a particular service type, identify which of them is carrying data application sessions subject to RVQoE measurements related to that particular service type, and forward the corresponding RVQoE reports to the node carrying data about the application sessions subject to RVQoE measurements.

In some other embodiments, the UE is configured to send one or more reports to relevant nodes (i.e., network nodes) or to instruct the UE which nodes the RVQoE should target. (With respect to the solutions proposed in this invention) a mechanism for a RAN node to acquire UE capabilities is described.

In the UE of NR-DC, one or more embodiments ensure that RVQoE reports related to a certain service type are forwarded to the correct location, i.e., to RAN nodes where the reports can be utilized, and to nodes that deliver data about application sessions receiving RVQoE measurements to the UE.

In some embodiments, the UE and RAN nodes in the DC are configured to infer which of the serving RAN nodes will carry the data for the application session receiving the RVQoE measurement, which allows, for example, forwarding the RVQoE report to the correct node.

In one embodiment, a method is described in which a first network node is configured to communicate with a user equipment (UE) and a second network node. At a minimum, the UE can be configured to communicate with the first and second network nodes using multi-radio connectivity. The method includes coordinating with the second network node to determine which of the first and second network nodes has reports corresponding to service types associated with the UE; determining which of the first and second network nodes carries data about application sessions receiving perceived quality measurements related to the reports; and performing one or more actions to ensure that one of the first and second network nodes carrying the data obtains the reports.

In some embodiments, the coordination includes the first network node sending a first instruction to the second network node indicating that it has received a report from the UE, or the second network node receiving a second instruction from the second network node indicating that it has received a report from the UE.

In some other embodiments, the reporting includes one or more of the following: a data radio bearer (DRB) identifier (ID), a quality of service (QoS) flow ID, and a packet data unit (PDU) session ID. Determining which of the first and second network nodes carries the data for an application session is based on one or more of the DRB ID, QoS flow ID, and PDU session ID.

In some embodiments, the method further includes receiving reports from the UE.

In some other embodiments, performing one or more actions includes sending a report to the second network node when the second network node is carrying data about an application session. The transmitted report is available to the second network node to either or both send and receive service type-related signaling to and from the UE.

In some embodiments, performing one or more actions includes receiving a report from a second network node when the first network node is carrying data about an application session. The received report can be used by the first network node to either or both send and receive service type-related signaling to and from the UE.

In some other embodiments, the method further includes causing the UE to be configured to either or both transmit a report to at least one of the first and second network nodes, and to indicate which of the first and second network nodes the perceived quality should target.

In some embodiments, the first and second network nodes are wireless access network (RAN) nodes, and the perceived quality measurement is either or both perceived quality (QoE) measurement and RAN visible perceived quality (RVQoE) measurement.

In some other embodiments, the report includes one or more of the following: a Quality of Experience (QoE) report and a Wireless Access Network (RAN) Visible Quality of Experience (RVQoE) report.

In some embodiments, the method further includes receiving a capability instruction from the UE indicating one of a first network node and a second network node to carry the application session.

In another embodiment, a first network node configured to communicate with a user device (UE) and a second network node is described. At a minimum, the UE can be configured to communicate with the first and second network nodes using multi-radio connectivity. The first network node is configured to cooperate with the second network node to determine which of the first and second network nodes has reports corresponding to service types associated with the UE; to determine which of the first and second network nodes carries data about application sessions subject to perceived quality measurements related to the reports; and to perform one or more actions to ensure that one of the first and second network nodes carrying the data obtains the reports.

In some embodiments, the coordination includes the first network node sending a first instruction to the second network node indicating that it has received a report from the UE, or the second network node receiving a second instruction from the second network node indicating that it has received a report from the UE.

In some other embodiments, the reporting includes one or more of the following: a data radio bearer (DRB) identifier (ID), a quality of service (QoS) flow ID, and a packet data unit (PDU) session ID. Determining which of the first and second network nodes carries the data for an application session is based on one or more of the DRB ID, QoS flow ID, and PDU session ID.

In some embodiments, the first network node is further configured to receive reports from the UE.

In some other embodiments, performing one or more actions includes sending a report to the second network node when the second network node is carrying data about an application session. The transmitted report is available to the second network node to either or both send and receive service type-related signaling to and from the UE.

In some embodiments, performing one or more actions includes receiving a report from a second network node when the first network node is carrying data about an application session. The received report can be used by the first network node to either or both send and receive service type-related signaling to and from the UE.

In some other embodiments, the first network node is further configured to cause the UE to be configured to either or both send a report to at least one of the first and second network nodes, and to instruct which of the first and second network nodes the perceived quality should target.

In some embodiments, the first and second network nodes are wireless access network (RAN) nodes, and the perceived quality measurement is either or both perceived quality (QoE) measurement and RAN visible perceived quality (RVQoE) measurement.

In some other embodiments, the report includes one or more of the following: a Quality of Experience (QoE) report and a Wireless Access Network (RAN) Visible Quality of Experience (RVQoE) report.

In some embodiments, the first network node is further configured to receive capability instructions from the UE that direct one of the first and second network nodes to carry the application session.

According to one embodiment, a method is described for a user device (UE) configured to communicate using multi-radio connectivity with a first network node and a second network node. This method includes transmitting a report to one of the first and second network nodes corresponding to the service type associated with the UE. The report includes one or more of the following: a data radio bearer (DRB) identifier (ID), a quality of service (QoS) flow ID, and a packet data unit (PDU) session ID. Which of the first and second network nodes carries the data about the application session is determined based on one or more of the DRB ID, QoS flow ID, and PDU session ID.

In some embodiments, the method further includes determining which of the first and second network nodes will carry data about an application session receiving a perceived quality measurement related to the report, and determining the capability instructions available to one or both of the first and second network nodes in order to perform one or more actions to ensure that one of the first and second network nodes carrying the data acquires the report. The method further includes transmitting the capability instructions to one or both of the first and second network nodes.

In some other embodiments, when a report is sent to the first network node, one or more actions include the first network node sending the report to the second network node when the second network node is carrying data about the application session. The transmitted report is available to the second network node to either or both send and receive service type-related signaling to and from the UE.

In some embodiments, one or more actions include a first network node receiving a report from a second network node when the first network node is carrying data about an application session. The received report can be used by the first network node to either or both send and receive service type-related signaling to and from the UE.

In some other embodiments, perceived quality measurement is either or both perceived quality (QoE) measurement and/or wireless access network (RAN) visible perceived quality (RVQoE) measurement.

In some embodiments, the method further includes indicating whether the perceived quality targets the first network node or the second network node.

In some other embodiments, the first network node 16a and the second network node 16b are wireless access network (RAN) nodes.

In some embodiments, the report includes a Quality of Experience (QoE) report.

In some other embodiments, the report includes a Wireless Access Network (RAN) Visible Quality of Experience (RVQoE) report.

In some embodiments, the method further includes determining the report based on one or both of the first and second settings received from one or both of the first and second network nodes.

In another embodiment, a user device (UE) is configured to communicate using multi-radio connectivity with a first network node and a second network node. The UE is configured to trigger the transmission of a report corresponding to the service type associated with the UE to one of the first and second network nodes. The report includes one or more of the following: a data radio bearer (DRB) identifier (ID), a quality of service (QoS) flow ID, and a packet data unit (PDU) session ID. Which of the first and second network nodes carries the data about the application session is determined based on one or more of the DRB ID, QoS flow ID, and PDU session ID.

In some embodiments, the UE is further configured to determine which of the first and second network nodes will carry data about application sessions receiving the perceived quality measurements related to the report, and to perform one or more actions to ensure that one of the first and second network nodes carrying the data acquires the report, by determining the capability instructions available to one or both of the first and second network nodes. The UE is further configured to trigger the transmission of capability instructions to one or both of the first and second network nodes.

In some other embodiments, when a report is sent to the first network node, one or more actions include the first network node sending the report to the second network node when the second network node is carrying data about the application session. The transmitted report is available to the second network node to either or both send and receive service type-related signaling to and from the UE.

In some embodiments, one or more actions include a first network node receiving a report from a second network node when the first network node is carrying data about an application session. The received report can be used by the first network node to either or both send and receive service type-related signaling to and from the UE.

In some other embodiments, perceived quality measurement is either or both perceived quality (QoE) measurement and/or wireless access network (RAN) visible perceived quality (RVQoE) measurement.

In some embodiments, the UE is further configured to indicate whether the perceived quality should target the first network node or the second network node.

In some other embodiments, the first network node (16a) and the second network node (16b) are radio access network (RAN) nodes.

In some embodiments, the report includes a Quality of Experience (QoE) report.

In some other embodiments, the report includes a Wireless Access Network (RAN) Visible Quality of Experience (RVQoE) report.

In some embodiments, the UE is further configured to determine the report based on one or both of the first and second settings received from one or both of the first and second network nodes.

When considered in conjunction with the attached drawings, a more complete understanding of this embodiment, as well as its associated advantages and features, will be more readily apparent by referring to the following detailed description.

This diagram shows the overall architecture of NG-RAN. This figure shows the overall architecture for separating gNB-CU-CP and gNB-CU-UP. This is a diagram showing the overall architecture of EN-DC. This diagram shows the procedure for adding the second node. This diagram shows the QoE transfer procedure. This figure shows two tables containing parameters related to QoE information transfer. This figure shows a typical QoE metric. This is a schematic diagram of an exemplary network architecture illustrating a communication system connected to a host computer via an intermediate network, based on the principles described herein. This is a block diagram of a host computer communicating with user equipment via a network node, at least partially over a wireless connection, according to some embodiments of the present disclosure. This flowchart illustrates an exemplary method implemented in a communication system including a host computer, a network node, and user equipment for running a client application on user equipment, according to some embodiments of the present disclosure. This flowchart illustrates an exemplary method implemented in a communication system including a host computer, a network node, and a UE for receiving user data on user equipment, according to some embodiments of the present disclosure. This flowchart illustrates an exemplary method implemented in a communication system including a host computer, a network node, and user equipment for a host computer to receive user data from user equipment, according to some embodiments of the present disclosure. This flowchart illustrates an exemplary method implemented in a communication system including a host computer, a network node, and user equipment for receiving user data on a host computer, according to some embodiments of the present disclosure. This is a flowchart of an exemplary process in a network node according to some embodiments of the present disclosure. This is a flowchart of an exemplary process in a user device according to some embodiments of the present disclosure. This is a flowchart of another exemplary process in a network node according to some embodiments of the present disclosure. This is a flowchart of another exemplary process in a user device according to some embodiments of the present disclosure.

Before describing exemplary embodiments in detail, it should be noted that embodiments primarily exist in combinations of device components and processing steps relating, for example, to inter-node coordination for reporting in a multi-node connectivity environment. Accordingly, where appropriate, components are represented by conventional symbols in the drawings, and only their specific details relevant to understanding the embodiments are shown, so as not to obscure this disclosure with details that would be readily apparent to those skilled in the art who are interested in the description herein. Similar numbers refer to similar elements throughout the description.

As used herein, relational terms such as “first” and “second,” “upper” and “lower” may be used simply to distinguish one entity or element from another, without necessarily requiring or implying any physical or logical relationship or order between such entities or elements. The terminology used herein is for the purpose of describing specific embodiments and does not limit the concepts described herein. As used herein, the singular forms “a,” “an,” and “the” also include the plural form unless the context explicitly indicates otherwise. Furthermore, as used herein, the terms “composes,” “comprising,” “includes,” and/or “including” specify the presence of the described features, completes, steps, actions, elements, and/or components, but do not exclude the presence or addition of one or more other features, completes, steps, actions, elements, components, and/or groups thereof.

In the embodiments described herein, joining terms such as "in communication with" may be used to indicate electrical or data communication, which can be achieved, for example, by physical contact, induction, electromagnetic radiation, radio signaling, infrared signaling, or optical signaling. Those skilled in the art will understand that multiple components can interact with each other, and that modifications and variations are possible for achieving electrical and data communication.

In some embodiments described herein, terms such as “coupled” and “connected” may be used herein to indicate a connection, though not necessarily directly, and may include wired and/or wireless connections.

As used herein, the term “network node” can refer to any type of network node (and/or node) present in a radio network, which may further comprise any of the following: base stations (BS), radio base stations, base transceiver stations (BTS), base station controllers (BSC), radio network controllers (RNC), g-node B (gNB), evolved node B (eNB or e-node B), node B, MSR radio nodes such as multi-standard radio (MSR) BS, multi-cell/multicast coordinating entities (MCE), radio access backhaul integrated transmission (IAB) nodes, relay nodes, donor node control relays, radio access points (AP), transmit points, transmit nodes, remote radio units (RRU), remote radio heads (RRH), core network nodes (e.g., mobile management entities (MME), self-organizing network (SON) nodes, coordinating nodes, positioning nodes, MDT nodes, etc.), external nodes (e.g., third-party nodes, nodes outside the current network), nodes in a distributed antenna system (DAS), spectrum access system (SAS) nodes, element management systems (EMS), etc. Network nodes may also include test equipment. The term “wireless node” as used herein may also be used to refer to a UE (such as a wireless device (WD) or wireless network node).

In some embodiments, the non-limiting terms User Equipment (UE) or Wireless Device (WD) are used interchangeably. A UE as used herein may be any type of user equipment (e.g., a wireless device) capable of communicating with a network node or another UE via wireless signals. A UE may also be a wireless communication device, a target device, a device-to-device (D2D) UE, a machine-type UE or a machine-to-machine (M2M) capable UE, a low-cost and/or low-complexity UE, a sensor equipped with a UE, a tablet, a mobile terminal, a smartphone, a laptop embedded equipment (LEE), a laptop-based equipment (LME), a USB dongle, customer premises equipment (CPE), an Internet of Things (IoT) device, or a narrowband IoT (NB-IoT) device. While UEs have been described, any WD may be implemented. Furthermore, a UE may be considered identical to a WD and not limited to a specific type of wireless device.

Furthermore, in some embodiments, the general term "wireless network node" is used. A wireless network node can be any type of wireless network node, which may comprise a base station, wireless base station, base station transceiver station, base station controller, network controller, RNC, evolved node B (eNB), node B, gNB, multicell/multicast cooperative entity (MCE), IAB node, relay node, access point, wireless access point, remote radio unit (RRU), or remote radio head (RRH).

In one or more embodiments, one or more of the following may apply:
● The solutions described herein are illustrated with respect to an example of two RAN nodes serving UEs in an NR-DC, but the solutions described herein can be generalized to any number of nodes serving UEs simultaneously.
● The solutions described herein are explained in relation to an example of NR-DC, but the solutions described herein can be generalized to multi-radio dual connectivity (MR-DC), or similarly to connectivity options with three or more RAN nodes.
● The terms "Application Layer Measurement Settings,""Application Measurement Settings,""QoE Measurement Settings,""QoESettings,""QoE Measurement and Reporting Settings," and "QMC Settings" are used interchangeably. However, please note that "QMC Settings File" is not an equivalent term and instead refers to the portion of the QoE settings consisting of an XML file or similar containing instructions for the QoE metrics to be collected.
● All references to the application layer refer to the application layer of the UE (since RAN nodes do not have an application layer).
● The term "service" is often used as a shortened form of "service type." Therefore, "service" and "service type" may be interchangeable unless explicitly stated otherwise.
● The solutions proposed in this invention can be applied to both signaling-based QoE measurement and control-based QoE measurement (however, they may be optionally restricted to be applied to only one of them).
● The terms "QoE report" and "QoE measurement report" are used interchangeably. Similarly, the terms "RAN-Visible QoE report,""RAN-Visible QoE measurement report,""RV QoE report," and "RV QoE measurement report" are used interchangeably.
● The terms "access layer" and "wireless layer" are used interchangeably when referring to the UE.
● The term "session" may refer to either a QoE measurement session, an application session, or an application session to which QoE measurement is applied.
● The term "session" may refer to either a QoE measurement session, an application session, or an application session to which QoE measurement is applied.
● The solutions proposed in this invention are applicable to UMTS, LTE, and NR, as well as future RATs such as 6G.
● This solution is described in relation to an example of a control-based QoE measurement (i.e., their corresponding RVQoE measurement), but the solution is equally applicable to both control-based and signaling-based QoE measurements, as well as their corresponding RVQoE measurements.

This disclosure may use terminology from a specific radio system, such as 3GPP LTE and/or New Radio (NR), but it should be noted that this should not be considered to limit the scope of this disclosure to the aforementioned system only. While not limiting, other radio systems, including Wideband Code Division Multiple Access (WCDMA), Global Interoperability for Microwave Access (WiMax), Ultra-Mobile Broadband (UMB), and Global System for Mobile Communications (GSM), may also benefit from leveraging the ideas covered within this disclosure.

Furthermore, it should be noted that the functions described herein as being performed by user equipment or network nodes may be distributed across multiple user equipment (UEs) and/or network nodes. In other words, the network node and user equipment functions described herein are not limited to implementation by a single physical device, but can actually be distributed across several physical devices.

Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meanings as those ordinarily understood by those skilled in the art to which this disclosure belongs. Terms used herein should be interpreted as having the meanings of those terms in the context of this specification and the related art, and should not be interpreted in an ideal or overly formal sense unless expressly provided herein.

Referring again to the drawings, similar elements are referenced by similar reference numbers, and Figure 8 shows a schematic diagram of a communication system 10, such as a 3GPP type cellular network capable of supporting standards such as LTE and/or NR (5G), comprising an access network 12, such as a wireless access network, and a core network 14, according to one embodiment. The access network 12 comprises a plurality of network nodes 16a, 16b, 16c (collectively referred to as network nodes 16), such as NBs, eNBs, gNBs, or other types of wireless access points, each defining a corresponding coverage area 18a, 18b, 18c (collectively referred to as a coverage area 18). Each network node 16a, 16b, 16c is connectable to the core network 14 via a wired or wireless connection 20. A first user equipment (UE) 22a located in a coverage area 18a is configured to connect wirelessly to a corresponding network node 16a or to be paged by a corresponding network node 16a. A second UE 22b in coverage area 18b can wirelessly connect to the corresponding network node 16b. While multiple UEs 22a, 22b (collectively referred to as UE22) are shown in this example, the disclosed embodiments are equally applicable to situations where only one UE is in the coverage area, or where only one UE is connected to the corresponding network node 16. For convenience, only two UEs 22 and three network nodes 16 are shown, but it should be noted that the communication system may include more UEs 22 and network nodes 16.

Furthermore, it is conceivable that UE22 may be configured to communicate simultaneously with two or more network nodes 16 and two or more types of network nodes 16, and/or to communicate with them separately. For example, UE22 may have dual connectivity with a network node 16 that supports LTE and the same or different network nodes 16 that support NR. As an example, UE22 may communicate with an eNB for LTE/E-UTRAN and a gNB for NR/NG-RAN.

The communication system 10 may itself be connected to a host computer 24, which may be embodied in the hardware and/or software of a standalone server, a cloud implementation server, a distributed server, or as a processing resource in a server farm. The host computer 24 may be owned or controlled by a service provider, or may operate by or on behalf of a service provider. Connections 26, 28 between the communication system 10 and the host computer 24 may extend directly from the core network 14 to the host computer 24, or via an optional intermediate network 30. The intermediate network 30 may be one of a public network, a private network, or a hosted network, or a combination of two or more of these. The intermediate network 30 may be a backbone network or the internet, if any. In some embodiments, the intermediate network 30 may comprise two or more subnetworks (not shown).

The communication system in Figure 8, as a whole, enables connectivity between one of the connected UEs 22a, 22b and the host computer 24. This connectivity can be described as an over-the-top (OTT) connection. The host computer 24 and the connected UEs 22a, 22b are configured to communicate data and/or signaling over the OTT connection, using the access network 12, the core network 14, an optional intermediate network 30, and possible further infrastructure (not shown) as intermediaries. The OTT connection can be transparent in the sense that at least some of the participating communication devices through which the OTT connection passes are unaware of the routing of uplink and downlink communications. For example, network node 16 may not be aware of, or does not need to be aware of, the past routing of incoming downlink communications with data originating from the host computer 24 that should be forwarded (e.g., handed over) to the connected UE 22a. Similarly, network node 16 does not need to be aware of the future routing of outgoing uplink communications originating from UE22a and destined for host computer 24.

Network node 16 is configured to include an NN coordinating unit 32 configured to perform any of the steps and/or tasks and/or processes and/or methods and/or features described herein, for example, transmitting to the second network node information on which of the first and second network nodes has set up an experienced quality measurement for a given service type related to the UE, and/or determining which of the first and second network nodes will carry data for an application session undergoing an experienced quality measurement for a given service type, and/or, when the second network node carries data for an application session undergoing an experienced quality measurement, forward an experienced quality report corresponding to the application session to the second network node. The user device 22 is configured to include a UE cooperation unit 34, which is configured to perform any of the steps and/or tasks and/or processes and/or methods and/or features described herein, for example, determining that data for an application session undergoing perceived quality measurement for a given service type related to the UE 22 is transported by a second network node, and/or sending instructions to at least the first network node 16a, the instructions of which indicate that data for an application session undergoing perceived quality measurement for a given service type is transported by the second network node, and the instructions of which indicate that the perceived quality report corresponding to the application session is available to the first network node for forwarding to the second network node.

Next, an exemplary implementation of the UE 22, network node 16, and host computer 24 described in the previous paragraph, according to one embodiment, will be described with reference to Figure 9. In the communication system 10, the host computer 24 includes hardware (HW) 38, including a communication interface 40 configured to set up and maintain wired or wireless connections to the interfaces of different communication devices of the communication system 10. The host computer 24 further includes a processing circuit 42 which may have storage and/or processing capabilities. The processing circuit 42 may include a processor 44 and memory 46. In particular, in addition to or instead of a processor and memory such as a central processing unit, the processing circuit 42 may include integrated circuits for processing and/or control, such as one or more processors and/or processor cores and/or FPGAs (field-programmable gate arrays) and/or ASICs (application-specific integrated circuits) adapted to execute instructions. The processor 44 may be configured to access memory 46 (for example, by writing to and/or reading from memory 46), and memory 46 may include any type of volatile and/or non-volatile memory, such as cache and/or buffer memory and/or RAM (random access memory) and/or ROM (read-only memory) and/or optical memory and/or EPROM (erasable programmable read-only memory).

The processing circuit 42 may be configured to control any of the methods and/or processes described herein, and/or to cause such methods and/or processes to be implemented, for example, by the host computer 24. The processor 44 corresponds to one or more processors 44 for performing the host computer 24 functions described herein. The host computer 24 includes memory 46 configured to store data, programmatic software code, and/or other information described herein. In some embodiments, the software 48 and/or host application 50 may include instructions that, when executed by the processor 44 and/or processing circuit 42, cause the processor 44 and/or processing circuit 42 to perform the processes described herein with respect to the host computer 24. These instructions may be software related to the host computer 24.

Software 48 may be executable by processing circuit 42. Software 48 includes a host application 50. The host application 50 may be able to operate to provide services to a remote user, such as a UE 22 connected via an OTT connection 52 that terminates at the host computer 24. When providing services to a remote user, the host application 50 may provide user data transmitted using the OTT connection 52. "User data" may be data and information as described herein to implement the functions described. In one embodiment, the host computer 24 may be configured to provide control and functionality to a service provider and may be operated by or on behalf of the service provider. The processing circuit 42 of the host computer 24 may enable the host computer 24 to observe, monitor, and control the network node 16 and/or user equipment 22, transmit to the network node 16 and/or user equipment 22, and/or receive from the network node 16 and/or user equipment 22. The processing circuitry 42 of the host computer 24 may include a host cooperation unit 54 configured to enable the service provider to perform any of the steps and/or tasks and/or processes and/or methods and/or features described in this disclosure, such as observing/monitoring/controlling/transmitting to/receiving from the network node 16 and/or user equipment 22.

The communication system 10 further includes a network node 16 provided within the communication system 10, the network node 16 including hardware 58 that enables the network node 16 to communicate with the host computer 24 and the UE 22. The hardware 58 may include a communication interface 60 for setting up and maintaining wired or wireless connections with the interfaces of different communication devices in the communication system 10, and a wireless interface 62 for setting up and maintaining at least a wireless connection 64 with the UE 22 located in the coverage area 18 served by the network node 16. The wireless interface 62 may be formed, or include, for example, one or more RF transmitters, one or more RF receivers, and/or one or more RF transceivers. The communication interface 60 may be configured to facilitate a connection 66 to the host computer 24. The connection 66 may be direct, or it may pass through the core network 14 of the communication system 10 and/or one or more intermediate networks 30 outside the communication system 10.

In the embodiment shown, the hardware 58 of the network node 16 further includes a processing circuit 68. The processing circuit 68 may include a processor 70 and a memory 72. More specifically, in addition to, or instead of, a processor and memory such as a central processing unit, the processing circuit 68 may include integrated circuits for processing and/or control, such as one or more processors and/or processor cores and/or FPGAs (Field-Programmable Gate Arrays) and/or ASICs (Application-Specific Integrated Circuits) adapted to execute instructions. The processor 70 may be configured to access the memory 72 (e.g., write to and/or read from memory 72), and the memory 72 may include any kind of volatile and/or non-volatile memory, such as cache and/or buffer memory and/or RAM (Random Access Memory) and/or ROM (Read-Only Memory) and/or optical memory and/or EPROM (Erasable Programmable Read-Only Memory).

Therefore, the network node 16 further has software 74 stored either internally in memory 72 or in external memory (e.g., a database, storage array, network storage device, etc.) accessible by the network node 16 via an external connection. The software 74 may be executable by a processing circuit 68. The processing circuit 68 may be configured to control any of the methods and/or processes described herein, and/or to cause such methods and/or processes to be carried out by the network node 16, for example. The processor 70 corresponds to one or more processors 70 for carrying out the network node 16 functions described herein. Memory 72 is configured to store data, programmatic software code, and/or other information described herein. In some embodiments, the software 74 may include instructions that, when executed by the processor 70 and/or the processing circuit 68, cause the processor 70 and/or the processing circuit 68 to carry out the processes described herein with respect to the network node 16. For example, the processing circuit 68 of the network node 16 may include a UE cooperation unit 34 configured to perform any of the steps and/or tasks and/or processes and/or methods and/or features described herein, such as transmitting to the second network node information on which of the first and second network nodes has set up an experienced quality measurement for a given service type related to the UE, and/or determining which of the first and second network nodes will carry data for an application session undergoing an experienced quality measurement for a given service type, and/or, when the second network node carries data for an application session undergoing an experienced quality measurement, forward an experienced quality report corresponding to the application session to the second network node.

The communication system 10 further includes the UE 22 already mentioned. The UE 22 may have hardware 80, which may include a radio interface 82 configured to set up and maintain a radio connection 64 with a network node 16 serving the coverage area 18 where the UE 22 is currently located. The radio interface 82 may be formed, or include, for example, one or more RF transmitters, one or more RF receivers, and/or one or more RF transceivers.

The UE22 hardware 80 further includes a processing circuit 84. The processing circuit 84 may include a processor 86 and a memory 88. More specifically, in addition to, or instead of, a processor and memory such as a central processing unit, the processing circuit 84 may comprise integrated circuits for processing and/or control, such as one or more processors and/or processor cores and/or FPGAs (Field-Programmable Gate Arrays) and/or ASICs (Application-Specific Integrated Circuits) adapted to execute instructions. The processor 86 may be configured to access the memory 88 (e.g., write to and/or read from memory 88), and the memory 88 may include any kind of volatile and/or non-volatile memory, such as cache and/or buffer memory and/or RAM (Random Access Memory) and/or ROM (Read-Only Memory) and/or optical memory and/or EPROM (Erasable Programmable Read-Only Memory).

Therefore, the UE22 may further comprise software 90, which may be stored, for example, in memory 88 in the UE22, or in external memory accessible by the UE22 (e.g., a database, storage array, network storage device, etc.). The software 90 may be executable by processing circuitry 84. The software 90 may include a client application 92. The client application 92 may operate to provide services to human or non-human users via the UE22, with the support of the host computer 24. On the host computer 24, a running host application 50 may communicate with the running client application 92 via an OTT connection 52 terminating in the UE22 and the host computer 24. When providing services to a user, the client application 92 may receive request data from the host application 50 and provide user data in response to the request data. The OTT connection 52 may transfer both the request data and the user data. The client application 92 may interact with the user to generate the user data that the client application 92 provides.

The processing circuit 84 may be configured to control any of the methods and/or processes described herein, and/or to cause such methods and/or processes to be carried out, for example, by the UE22. The processor 86 corresponds to one or more processors 86 for carrying out the UE22 functions described herein. The UE22 includes a memory 88 configured to store data, programmatic software code, and/or other information described herein. In some embodiments, the software 90 and/or client application 92 may include instructions that cause the processor 86 and/or the processing circuit 84 to carry out the processes described herein with respect to the UE22 when executed by the processor 86 and/or the processing circuit 84. For example, the processing circuit 84 of the user device 22 may include a UE cooperation unit 34 configured to perform any of the steps and/or tasks and/or processes and/or methods and/or features described herein, such as determining that data for an application session undergoing perceived quality measurement for a given service type related to the UE is transported by a second network node, and/or sending instructions to at least a first network node, the instructions indicating that data for an application session undergoing perceived quality measurement for a given service type is transported by the second network node, and the instructions indicating that the perceived quality report corresponding to the application session is available to the first network node for forwarding to the second network node.

In some embodiments, the internal workings of the network node 16, UE 22, and host computer 24 may be as shown in Figure 9, while the surrounding network topology may be as shown in Figure 8.

In Figure 9, the OTT connection 52 is depicted abstractly to show communication between the host computer 24 and the user equipment 22 via the network node 16, without explicit reference to the intermediary devices and the precise routing of messages through these devices. The network infrastructure may determine the routing, and it may be configured to hide the routing from the UE 22, the service provider operating the host computer 24, or both. While the OTT connection 52 is active, the network infrastructure may also make decisions to dynamically change the routing (for example, based on network load balancing considerations or reconfiguration).

The wireless connection 64 between UE22 and network node 16 follows the teachings of embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of the OTT services provided to UE22 by using an OTT connection 52, in which the wireless connection 64 may form the final segment. More precisely, some teachings of these embodiments may improve data rate, latency, and/or power consumption, thereby providing benefits such as reduced user latency, relaxed file size limitations, better responsiveness, and extended battery life.

In some embodiments, a measurement procedure may be provided for the purpose of monitoring data rate, latency, and other factors, which one or more embodiments improve. Further optional network functions may be provided for reconfiguring the OTT connection 52 between the host computer 24 and the UE 22 in response to variations in the measurement results. The measurement procedure and/or network functions for reconfiguring the OTT connection 52 may be implemented in the software 48 of the host computer 24, or in the software 90 of the UE 22, or both. In embodiments, a sensor (not shown) may be deployed in or in relation to a communication device through which the OTT connection 52 passes, and the sensor may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or values of other physical quantities through which the software 48, 90 can calculate or estimate the monitored quantities. Reconfiguring the OTT connection 52 may include message formatting, retransmission settings, preferred routing, etc., and the reconfiguration may not need to affect the network node 16, and may be unknown to or imperceptible to the network node 16. Several such procedures and functions are known and practiced in the art. In some embodiments, the measurement may involve proprietary UE signaling that facilitates the measurement of the host computer 24, such as throughput, propagation time, and latency. In some embodiments, the measurement may be implemented such that software 48, 90 monitors propagation time, errors, etc., and the software 48, 90 uses the OTT connection 52 to send messages, in particular empty or "dummy" messages.

Therefore, in some embodiments, the host computer 24 includes a processing circuit 42 configured to provide user data and a communication interface 40 configured to forward the user data to the cellular network for transmission to the UE 22. In some embodiments, the cellular network also includes a network node 16 having a wireless interface 62. In some embodiments, the network node 16 is configured to perform the functions and/or methods described herein for preparing/starting/maintaining/supporting/terminating transmissions to the UE 22 and/or preparing/terminating/maintaining/supporting/terminating transmissions from the UE 22, and/or the processing circuit 68 of the network node 16 is configured to perform them.

In some embodiments, the host computer 24 includes a processing circuit 42 and a communication interface 40, the communication interface 40 being configured to receive user data originating from transmissions from the UE 22 to the network node 16. In some embodiments, the UE 22 includes a wireless interface 82 and/or processing circuit 84 configured to perform the functions and/or methods described herein for preparing/starting/maintaining/supporting/terminating transmissions to the network node 16 and/or preparing/terminating/maintaining/supporting/terminating transmissions from the network node 16.

Figures 8 and 9 show various "units," such as the NN coordinating unit 32 and the UE coordinating unit 34, within their respective processors. These units can be implemented such that a portion of them is stored in corresponding memory within the processing circuit. In other words, the units can be implemented in hardware or as a combination of hardware and software within the processing circuit.

Figure 10 is a flowchart illustrating an exemplary method implemented in a communication system, such as the communication system in Figures 8 and 9, according to one embodiment. The communication system may include a host computer 24, a network node 16, and a UE 22, which may be described with reference to Figure 9. In a first step of the method, the host computer 24 provides user data (block S100). In an optional substep of the first step, the host computer 24 provides user data by executing a host application, such as host application 50 (block S102). In a second step, the host computer 24 initiates a transmission to carry the user data to the UE 22 (block S104). In an optional third step, the network node 16 transmits the user data carried in the transmission initiated by the host computer 24 to the UE 22, in accordance with the teachings of the embodiments described throughout this disclosure (block S106). In an optional fourth step, the UE 22 executes a client application, such as the client application 92, which is related to the host application 50 executed by the host computer 24 (block S108).

Figure 11 is a flowchart illustrating an exemplary method implemented in a communication system, such as the communication system in Figure 8, according to one embodiment. The communication system may include a host computer 24, a network node 16, and a UE 22, which may be described with reference to Figures 8 and 9. In a first step of the method, the host computer 24 provides user data (block S110). In an optional substep (not shown), the host computer 24 provides user data by executing a host application, such as host application 50. In a second step, the host computer 24 initiates a transmission to carry the user data to the UE 22 (block S112). The transmission may proceed via the network node 16, as taught in the embodiments described throughout this disclosure. In an optional third step, the UE 22 receives the user data carried in the transmission (block S114).

Figure 12 is a flowchart illustrating an exemplary method implemented in a communication system, such as the communication system of Figure 8, according to one embodiment. The communication system may include a host computer 24, a network node 16, and a UE 22, which may be described with reference to Figures 8 and 9. In an optional first step of the method, the UE 22 receives input data provided by the host computer 24 (block S116). In an optional substep of the first step, the UE 22 runs a client application 92 that provides user data in response to the received input data provided by the host computer 24 (block S118). In an optional second step, either additionally or alternatively, the UE 22 provides user data (block S120). In an optional substep of the second step, the UE provides user data by running a client application, such as the client application 92 (block S122). When providing user data, the runnable client application 92 may further consider user input received from the user. Regardless of the specific format in which the user data is provided, UE22 may, in an optional third substep, initiate the transmission of the user data to the host computer 24 (block S124). In a fourth step of the method, the host computer 24 receives the user data transmitted from UE22 in accordance with the teachings of the embodiments described throughout this disclosure (block S126).

Figure 13 is a flowchart illustrating an exemplary method implemented in a communication system, such as the communication system in Figure 8, according to one embodiment. The communication system may include a host computer 24, a network node 16, and a UE 22, which may be described with reference to Figures 8 and 9. In an optional first step of the method, the network node 16 receives user data from the UE 22 (block S128), in accordance with the teachings of the embodiments described throughout this disclosure. In an optional second step, the network node 16 initiates a transmission of the received user data to the host computer 24 (block S130). In a third step, the host computer 24 receives the user data carried in the transmission initiated by the network node 16 (block S132).

Figure 14 is a flowchart of an exemplary process at a network node 16 (for example, a first network node 16a). One or more blocks described herein may be implemented by one or more elements of the network node 16, such as by one or more of the processing circuit 68 (including the NN coordinating unit 32), the processor 70, the radio interface 62, and/or the communication interface 60. The network node 16, via the processing circuit 68 and/or processor 70 and/or wireless interface 62 and/or communication interface 60, is configured to: transmit information to the second network node 16b regarding which of the first network node 16a and the second network node 16b has set up the perceived quality measurement for a predetermined service type related to the UE 22 (block S134); determine which of the first network node 16a and the second network node 16b will carry the data for the application session undergoing the perceived quality measurement for the predetermined service type (block S136); and, when the second network node 16b carries the data for the application session undergoing the perceived quality measurement, forward the perceived quality report corresponding to the application session to the second network node 16b (block S138).

In some embodiments, the method further includes configuring the UE 22 to perform at least one of the following: sending a perceived quality report to at least one of the first network node 16a and the second network node 16b; and indicating which of the first network node 16a and the second network node 16b the perceived quality should target.

In some other embodiments, the first network node 16a and the second network node 16b are radio access network (RAN) nodes, the UE 22 is configurable to transmit capability instructions to at least one of the first network node 16a and the second network node 16b, the perceived quality measurement is RAN visible perceived quality (RVQoE) measurement, and the perceived quality report is an RVQoE report.

Figure 15 is a flowchart of an exemplary process in a user device 22 according to several embodiments of the present disclosure. One or more blocks described herein may be implemented by one or more elements of the user device 22, such as by one or more of the processing circuit 84 (including the UE cooperation unit 34), the processor 86, the wireless interface 82, and/or the communication interface 60. Through the processing circuit 84 and/or the processor 86 and/or the wireless interface 82, etc., the user device 22 is configured to determine (block S140) that data for an application session undergoing perceived quality measurement for a predetermined service type associated with the UE 22 will be carried by the second network node 16b, and to transmit an instruction to at least the first network node 16a (block S142). The instruction indicates that data for an application session undergoing perceived quality measurement for a predetermined service type will be carried by the second network node 16b. The instruction is available to the first network node 16a for forwarding the perceived quality report corresponding to the application session to the second network node 16b.

In some embodiments, UE22 is configured by at least one of the first network node 16a and the second network node 16b to transmit a perceived quality report to at least one of the first network node 16a and the second network node 16b.

In some other embodiments, the first network node 16a and the second network node 16b are radio access network (RAN) nodes, the UE 22 is configurable to transmit capability instructions to at least one of the first network node 16a and the second network node 16b, the perceived quality measurement is RAN visible perceived quality (RVQoE) measurement, and the perceived quality report is an RVQoE report.

Figure 16 is a flowchart of an exemplary process in network node 16 (for example, the first network node 16a). One or more blocks described herein may be implemented by one or more elements of network node 16, such as by one or more of the processing circuit 68 (including the NN coordinating unit 32), the processor 70, the radio interface 62, and/or the communication interface 60. Network node 16 (for example, the first network node 16a), via the processing circuit 68 and/or the processor 70 and/or the radio interface 62 and/or the communication interface 60, etc., is configured to coordinate with the second network node 16b to determine which of the first network node 16a and the second network node 16b has reports corresponding to service types related to UE22 (block S144), and to determine which of the first network node 16a and the second network node 16b carries data about application sessions that receive perceived quality measurements related to the reports (block S142). Network node 16 (for example, the first network node 16a) is further configured to perform one or more actions to ensure that one of the first network node 16a and the second network node 16b, which are carrying the data, receives the report.

In some embodiments, the coordination includes the first network node 16a sending a first instruction to the second network node 16b indicating that it has received a report from the UE, or the second network node 16b receiving a second instruction from the second network node 16b indicating that it has received a report from the UE.

In some other embodiments, the reporting includes one or more of the following: a data radio bearer (DRB) identifier (ID), a quality of service (QoS) flow ID, and a packet data unit (PDU) session ID. Determining whether the first network node 16a or the second network node 16b carries data for an application session is based on one or more of the DRB ID, QoS flow ID, and PDU session ID.

In some embodiments, the method further includes receiving reports from the UE.

In some other embodiments, performing one or more actions includes sending a report to the second network node 16b when the second network node 16b is carrying data about the application session. The transmitted report is available to the second network node 16b for either or both sending and receiving service type-related signaling to and from the UE.

In some embodiments, performing one or more actions includes receiving a report from a second network node 16b when the first network node 16a is carrying data about an application session. The received report is available to the first network node 16a for either or both of sending and receiving service type-related signaling to and from the UE.

In some other embodiments, the method further includes causing the UE to be configured to either or both transmit a report to at least one of the first network node 16a and the second network node 16b, and to instruct which of the first network node 16a and the second network node 16b the perceived quality should target.

In some embodiments, the first network node 16a and the second network node 16b are wireless access network (RAN) nodes, and the perceived quality measurement is either or both perceived quality (QoE) measurement and RAN visible perceived quality (RVQoE) measurement.

In some other embodiments, the report includes one or more of the following: a Quality of Experience (QoE) report and a Wireless Access Network (RAN) Visible Quality of Experience (RVQoE) report.

In some embodiments, the method further includes receiving a capability instruction from the UE indicating one of the first network node 16a and the second network node 16b to carry the application session.

Figure 17 is a flowchart of an exemplary process in a user device 22 according to some embodiments of the present disclosure. One or more blocks described herein may be implemented by one or more elements of the user device 22, such as by one or more of the processing circuit 84 (including the UE cooperation unit 34), the processor 86, the radio interface 82, and/or the communication interface 60. The user device 22, via the processing circuit 84 and/or processor 86 and/or wireless interface 82, is configured to transmit a report (block S150) to one of the first network node 16a and the second network node 16b, corresponding to the service type associated with the UE 22, wherein the report comprises one or more of the data radio bearer (DRB) identifier (ID), quality of service (QoS) flow ID, and packet data unit (PDU) session ID, and which of the first network node 16a and the second network node 16b carries the data about the application session is determined based on one or more of the DRB ID, QoS flow ID, and PDU session ID.

In some embodiments, the method further includes determining which of the first network node 16a and the second network node 16b will carry data about an application session receiving a perceived quality measurement related to the report, and determining the capability instructions available to one or both of the first network node 16a and the second network node 16b in order to perform one or more actions to ensure that one of the first network node 16a and the second network node 16b that carries the data acquires the report. The method further includes transmitting the capability instructions to one or both of the first network node 16a and the second network node 16b.

In some other embodiments, when a report is transmitted to the first network node 16a, one or more actions include the first network node 16a transmitting the report to the second network node 16b when the second network node 16b is carrying data about the application session. The transmitted report is available to the second network node 16b to either or both transmit and receive service type-related signaling to and from the UE 22.

In some embodiments, one or more actions include the first network node 16a receiving a report from the second network node 16b when the first network node 16a is carrying data about an application session. The received report is available to the first network node 16a to either or both send and receive service type-related signaling to and from the UE 22.

In some other embodiments, perceived quality measurement is either or both perceived quality (QoE) measurement and/or wireless access network (RAN) visible perceived quality (RVQoE) measurement.

In some embodiments, the method further includes indicating whether the perceived quality targets the first network node 16a or the second network node 16b.

In some other embodiments, the first network node 16a and the second network node 16b are wireless access network (RAN) nodes.

In some embodiments, the report includes a Quality of Experience (QoE) report.

In some other embodiments, the report includes a Wireless Access Network (RAN) Visible Quality of Experience (RVQoE) report.

In some embodiments, the method further includes determining the report based on one or both of the first and second settings received from one or both of the first network node 16a and the second network node 16b.

Having described the general process flow of the configuration of this disclosure and provided examples of hardware and software configurations for implementing the processes and functions of this disclosure, the following sections provide details and examples of configurations for inter-node coordination, such as for reporting in a multi-node connectivity environment.

Some embodiments provide a UE22 (e.g., WD), a first network node 16a (e.g., the first node), and a second network node 16b (e.g., the second node).

First exemplary solution: UE-based solution The first solution includes at least one of the following steps:
1. UE22 establishes NR-DCs to the first network node 16a and the second network node 16b, which each serve as either the MN and SN, or the SN and MN, respectively.

2. A network entity, for example, OAM, assembles a management-based QoE metric configuration (referred to herein as the first configuration) and distributes that configuration to several RAN nodes in the area, including a first network node 16a and a second network node 16b. The first network node 16a configures a QoE metric for a service, for example, a first service, on UE22 according to the first configuration, and the first network node 16a configures an RVQoE metric on UE22 according to the second configuration and sets up an SRB 4 on UE22. Note that UE22 may establish only one SRB of each type on the network, meaning that in this scenario, unless reconfigured, the SRB 4 will always be established on either the first network node 16a or the second network node 16b, but not on both. UE22 activates an application session for a service, for example, the first service, which triggers QoE and RVQoE measurements in UE22, as well as their reporting.
a. In the case of signaling-based (s-based) QoE, QoE settings are distributed from the OAM to the MN via the core network.
b. In the case of a management-based (m-based) QoE, it is possible that both the first network node 16a and the second network node 16b have received the first configuration (directly from the OAM) because, for example, they are both within the area range of the first configuration or within one or more configured PLMNs.

3. The first node 16a and the second node 16b inform each other whether they have both received the first setting and whether they intend to set the first setting on UE22. They may also indicate to each other whether they are interested in receiving RVQoE reports related to each measurement setting. Each node may also inform the other node whether it has established an SRB4 to UE22.

In one solution, one node (typically the master node) decides to configure SRB4 as a split bearer. This means that UE22 splits transmissions between the first network node 16a and the second network node 16b. In existing solutions, the split is based on the amount of data to be transmitted. Here, several new criteria can be defined for how UE22 splits transmissions. For example, the split could be based on whether the data is for a service of the first network node or for a service of the second network node 16b. If the data is for a service of the first network node 16a, UE22 sends the data to the first network node 16a on the leg; if the data is for a service of the second network node 16b, UE22 sends the data to the second network node 16b on the leg. An example of split transmission might be when, according to a configuration provided to at least one of the first node 16a or the second node 16b, data related to VoNR services is sent to the first network node 16a and data related to streaming is sent to the second network node 16b. An additional criterion is that one of the legs is preferred or always used instead of the other until an overload (or near-overload) situation is detected by the node corresponding to the preferred leg. For example, SRB4 is configured as a split bearer, and the preferred leg corresponds to the node that configured SRB4 (e.g., MN). According to the provided configuration, UE22 sends data using the MN leg. When MN detects an overload (e.g., MN detects that too much data has arrived via SRB4 over a given period of time), MN reconfigures SRB4 so that UE22 will now send data related to QoE/RVQoE reporting via the other leg.

In an alternative solution, one node (typically the master node) decides to configure SRB4 as a replicated bearer. This means that data is sent to both the first network node 16a and the second network node 16b. Each node then determines whether the data pertains to a service of that particular node or the other node, and can retrieve the relevant data for its own node.

In the alternative solution, the message carrying the RVQoE report, for example, MeasurementReportAppLayer, is allowed to be transmitted over different SRBs in the first network node 16a and the second network node 16b, i.e., different SRBs are defined. This may include using SRB4 in the first network node 16a and using SRB1, SRB3, or a new SRB5 in the second network node 16b. One of the SRBs may be defined as the master node bearer and the other as the secondary node bearer, or both may be defined as master node bearers or both as secondary node bearers.

In another exemplary solution, the same SRB is used for RVQoE reporting for both the first and second nodes, but in some cases, along with instructions from UE22 regarding which node those reports should be directed to. See Step 4.
a. The first network node 16a and the second network node 16b can inform each other whether they have received the first configuration and whether they intend to configure the UE22 with the first configuration during the execution of one of the procedures related to multiconnectivity operation, such as when the UE22 is reconfigured from single connectivity to multiconnectivity (e.g., by adding a secondary node) or when the UE22 is reconfigured from a first configuration in multiconnectivity to a second configuration in multiconnectivity (e.g., by modifying a secondary node - starting an MN or starting an SN, changing a secondary node - starting an MN or starting an SN, or an MN handover with or without an SN change).
b. One of the nodes involved in the NR-DC (or MR-DC) instructs/requests the other node to forward RVQoE reports related to the services for which they provided the corresponding RVQoE settings to UE22, and the instruction/request is carried over a new or existing procedure.
i. In some cases, the first network node 16a and the second network node 16b are already in use in the MR-DC, and only one of the nodes is included in the area range. The node receiving the m-base configuration (either the MN node or the SN node) can configure UE22 for RVQoE and instruct/request the other node (SN or MN, respectively) to forward the RVQoE report to the node receiving the m-base configuration.
ii. In another case, one of the nodes (generally the MN node) configures UE22 to collect RVQoE for a first service according to the s-based QoE configuration. In this case, MN is not included in the area range related to the m-based QoE configuration, but the other node (SN) is included in the area range related to the m-based QoE configuration. The other node (SN) configures UE22 to collect RVQoE for a second service. MN instructs/requests SN to forward RVQoE reports related to the first service to MN, and SN instructs/requests MN to forward RVQoE reports related to the second service to SN.
iii. In another case, at least one of the first network node 16a and/or the second network node 16b receives an m-based QoE setting to be sent to UE22 and/or decides to prepare an RVQoE setting for UE22. For example, if it is the first network node 16a, the first network node 16a can inform the second network node 16b that the first network node 16a has set up UE22 for RVQoE and is interested in receiving RVQoE reports. The second network node 16b then realizes that future RVQoE reports to be received for UE22 at the second network node 16b need to be sent to the first network node 16a. There is a possible race condition in which both the first network node 16a and the second network node 16b may attempt to set up the same RVQoE setting for UE22. In this case, one subcase is that the newest setting overrides the older setting (RVQoE setting modification is not enabled). In another subcase, each node receives instructions that the other node is interested in receiving RVQoE reports from the other node. In yet another subcase, the node that sent the RVQoE setting to UE22 as the last of the two nodes is the node that should receive the RVQoE report. In yet another subcase, the node that sent the RVQoE setting before the other is the node that should receive the RVQoE report.
c. When one of the nodes is removed from the NR-DC (or MR-DC) configuration, it instructs/requests the other node to receive RVQoE reports related to the services for which it provided the corresponding RVQoE configuration to UE22, and this instruction/request is carried over a new or existing procedure.

It can be assumed that the first network node 16a has configured QoE and RVQoE measurements on UE22 and established SRB4 to UE22. This is a non-limiting example, as it is possible, for example, that the second network node 16b has configured the first and second settings on UE22. At this point, neither of the two nodes is aware of which of them will carry the data about the application session for the first service.

4. UE22 understands that data for the first service will be transported via the second network node 16b. This may be done by the UE Access Layer (AS) layer based on knowledge of the application session's DRB ID, QoS flow ID, or PDU session ID, and the corresponding connectivity leg. Note that as part of the DC setup procedure, MN instructs SN on the available DRB IDs to be used by SN for the SCG-terminated DRB, ensuring the uniqueness of the DRB IDs set up for UE22 in the DC. Alternatively, or in combination with this, UE22 may also use one of the methods described below (in the section “How UE Identifies Legs Carrying Application Data Flows”) to identify the connectivity leg. UE22 already knows that SRB4 will be established for the first network node 16a. Therefore, UE22 sends an instruction to the first network node 16a that data about the application session will be transported via the second network node 16b, which means that the second network node 16b should receive the RVQoE report transported from UE22 to the first network node 16a via SRB4.

Alternatively, UE22 may send an instruction along with the RVQoE report indicating which node the report is directed to. This instruction may be sent always, or only in certain circumstances, for example, when the report targets the other node, or when the target node has changed since the last report.

5. Based on the instructions received from UE22 in step 4, the first network node 16a sends instructions to the second network node 16b, informing the second network node 16b that an RVQoE report in accordance with the second configuration relates to a leg between UE22 and the second network node 16b.
a. In one variant, an instruction from the first network node to the second network node 16b may be a notification of the above (instruction A).
b. In another variant, the instruction may be a query to the second network node 16b (interest pole) regarding whether the second network node 16b is interested in receiving RVQoE reports from UE22 via the first network node 16a (instruction B).
c. In another variant, the instruction may be a query that "requests" the second network node 16b to provide parameters for RVQoE measurement in UE22 (instruction C).
d. Any of these instructions may include a request to the second network node 16b to set up the SRB4 on the UE22.
e. Note that the above does not depend on whether both the first network node and the second network node 16b are within the area range of the first and second configurations.
f. Note that the above also applies if one of the nodes used for NR-DC (or MR-DC) connectivity and configured UE22 for RVQoE is later removed from the UE22 configuration (for example, if UE22 is reconfigured from multi-connectivity to single connectivity, or if a different NR-DC (or MR-DC) configuration is reconfigured for UE22).

6. The second network node 16b responds to the instruction received from the first network node 16a in step 5.
a. When the second network node 16b receives instruction A, the second network node 16b can confirm receipt.
b. If the second network node 16b receives instruction B, the second network node 16b may respond whether it is interested in receiving from the first network node 16a an RVQoE report relating to the second configuration received from UE 22.
i. If the second network node 16b is interested in receiving the RVQoE report, the second network node 16b may also instruct the first network node 16a whether it requests that the SRB4 be set up between the UE22 and the second network node 16b instead of between the first network node 16a and the UE22.
ii. If the second network node 16b is not interested in receiving RVQoE reports from UE22 via the first network node 16a, the first network node 16a may deactivate the RVQoE measurements related to the second configuration.
c. When the second network node 16b receives instruction C, the second network node 16b may instruct the desired RVQoE setting parameters.

7. Based on the response received from the second network node 16b in step 6, the first network node 16a takes one or more of the following actions (any meaningful combination of the following actions is possible):
a. If the second network node 16b acknowledges receipt of instruction A, the first network node 16a may then forward the RVQoE report related to the second configuration received from UE22 to the second network node 16b.
Alternatively, the first network node 16a may decide to request the second network node 16b to set up SRB4 on the UE22 side, which would deconfigure the SRB4 currently existing between the first network node 16a and the UE22. This would mean that in the future, RVQoE reports would be sent directly from the UE22 to the second network node 16b. In another variant, the first network node 16a may retain SRB4 with the UE22 but instruct the UE22 to send RVQoE reports to the second network node 16b via an already established SRB, for example, SRB3.
b. If the second network node 16b responds, based on the received instruction B, that it is interested in receiving the RVQoE report, the first network node 16a may perform one or more of the actions described in time a. of this step (step 7).
c. If the second network node 16b responds with a desired RVQoE measurement setting different from the current second setting based on the received instruction C, the first network node 16a may modify the second setting accordingly.

The RVQoE report may be delivered to the second network node 16b based on an action performed in at least one of steps 1 to 7.

Second exemplary solution: Network-based solution The second solution may include at least one of the following steps:
1. Same as (or similar to) the first solution.

2. Same as (or similar to) the first solution.

3. Same as (or similar to) the first solution.

It can be assumed that the first network node 16a then configures QoE and RVQoE measurements on UE22 and establishes SRB4 (and/or another SRB from which UE22 can send RVQoE reports) to UE22. This is a non-limiting example, as it is possible, for example, that the second network node 16b instead configures the first and second settings on UE22. At this point, neither of the two nodes is aware of which of them will carry the data about the application session for the first service.

4. The first network node 16a receives an RVQoE report from UE22 relating to the second configuration. The RVQoE report may include the DRB ID and/or QoS flow ID and/or PDU session ID of the application session undergoing RVQoE measurement. When the contents of the RVQoE report are visible to the first network node 16a, based on the service type referenced by the RVQoE measurement, and the DRB ID and/or QoS flow ID and/or PDU session ID within it, the first network node 16a understands that data about the application session undergoing RVQoE measurement will be delivered to UE22 via the second network node 16b. For example, the first network node 16a may infer, based on the DRB ID in the RVQoE report, that the session is carried through the second network node 16b, since the MN instructs the SN what the available DRB IDs should be used by the SN for the SCG termination DRB, and ensures the uniqueness of the DRB IDs set up on the UE 22 in the DC. Alternatively, or in combination with this, the UE may identify the legs carrying (one or more) application data flows, as described in the section “How the UE identifies the legs carrying (one or more) application data flows,” where the application includes socket information in the RVQoE report, which can be used to identify the connectivity leg. Thus, the first network node 16a understands that the second network node 16b should have received the RVQoE report carried from the UE 22 to the first network node 16a via the SRB 4.

Alternatively, UE22 may send instructions along with the RVQoE report indicating which node the report should be directed to. These instructions may always be sent, or only in certain circumstances, such as when the report targets the other node, or when the target node has changed since the last report.
a. In one option, the first network node 16a may determine that data about application sessions subject to RVQoE measurement is fully delivered to the UE22 via the second network node 16b by using one or more of the following indications: service type, DRB ID associated with the application session, QoS flow ID, PDU session ID, timestamp received in or with the RVQoE report, and an indication (or absence of indication) that there was no user plane activity for the UE22 with the first network node 16a during the time period referenced by the RVQoE report.
b. The first network node 16a may further determine that data about the application session receiving the RVQoE measurement has been partially delivered to the UE 22 via the first network node 16a (for example, based on a timestamp sent in or with the RVQoE report and instructions collected at the first network node 16a indicating user plane activity for the UE 22, involving the first network node 16a), and may retain the RVQoE measurement for optimization at the first network node 16a.

5. Same as (or similar to) the first solution.

6. Same as (or similar to) the first solution.

7. Same as (or similar to) the first solution.

8. Same as (or similar to) the first solution.

In one embodiment, the first network node 16a and the second network node 16b may agree to send the RVQoE measurements received from UE22 to the node that configured UE22 for RVQoE before the RVQoE configuration is issued to UE22. This coordination may be achieved, for example, during the execution of one of the procedures related to multi-connectivity operation, such as when UE22 is reconfigured from single connectivity to multi-connectivity (e.g., adding a secondary node). UE22 may then be reconfigured from a first configuration in multi-connectivity to a second configuration in multi-connectivity (e.g., secondary node modification - MN start or SN start, secondary node change - MN start or SN start, MN handover with or without SN change). A node interested in receiving RVQoE reports (e.g., MN) can signal a flag to another node (e.g., SN) to instruct it to request RVQoE reports that UE22 may send to the other node (this request could be general, i.e., applicable to RVQoE reports, or more granular, for example, indicating that MN is interested in receiving RVQoE reports only for a specific service).

In another embodiment, the first network node 16a (second network node 16b) may agree with the second network node 16b (first network node 16a) by sending RVQoE measurements related to the data distributed to the UE22 via the first network node 16a (second network node 16b) before the RVQoE settings are issued to the UE22. This can be implemented if both the first network node 16a and the second network node 16b are used in an NR-DC (or any other form of MR-DC), provided that the second network node 16b hosts (or is connected to) an AI/ML training function where RVQoE measurements are used as input data and requests to receive such RVQoE measurements.

How the UE identifies the leg carrying (one or more) application data flows: To determine which connectivity leg (towards the MN or SN) a data flow subject to RVQoE measurement is carried on, the UE 22 may rely on intrinsic knowledge within the application.

An application may create a network socket for its application data flow, and the socket may have several relevant parameters that can be used to identify the socket and the (one or more) application data flows passing through it. These parameters may include at least one of the following:
- Local IP address (i.e., source IP address for outgoing data flows and destination IP address for incoming data flows)
- Remote IP address (i.e., source IP address for incoming data flow and destination IP address for outgoing data flow)
- Local transport protocol ports (i.e., source transport protocol ports for outgoing data flows and destination transport protocol ports for incoming data flows)
- Remote transport protocol ports (i.e., source transport protocol ports for incoming data flows and destination transport protocol ports for outgoing data flows)
- Transport protocols (e.g., Transport Control Protocol (TCP), Stream Controlled Transfer Protocol (SCPP), Real-Time Protocol (RTP))

Of the above, the local IP address is potentially known by UE AS because it is the IP address assigned to UE22.

To enable the UE AS to identify the DRBs and connectivity legs (one or more) carrying a given application data flow, the application (in the UE application layer) informs the UE AS of all or a subset of the socket parameters listed above for each incoming and outgoing data flow (e.g., optionally excluding the local IP address). The UE AS can use this information (hereinafter referred to as socket information) to check which DRBs and connectivity legs a packet matching this information is sent on and received.

Socket information from the UE application layer can be forwarded upon request from the UE AS, either as a one-time request (e.g., upon receiving an RVQoE report from the UE application layer) or as a more general request (e.g., when an RVQoE configuration is sent to the UE application layer, or when a session start instruction is received from the UE application layer). Such a more general request would cause the application to send socket information at the start of each application session undergoing RVQoE measurement (and to send updated information during the session if the information changes). Alternatively, the application could send socket information to the UE AS each time it creates a socket as a result of a general request from the UE AS. Another alternative is that such a more general request would cause the application to send socket information with each RVQoE report.

Another option would be to instruct the RVQoE configuration that, instead of relying on requests from the UE AS, the application should send this information to the UE AS at the start of each application session (with in-session updates if necessary), when creating the socket, and/or with each RVQoE report.

Another possible option is to completely bypass the UE AS and instead have the application (at the UE application layer) include socket information in the RVQoE report (governed by the RVQoE configuration). In that case, it would be up to the RAN node receiving the RVQoE report to determine which (one or more) application data flows are carried over by (one or more) DRBs (and therefore which connectivity legs).

For communication of socket information between the application and the UE AS, AT commands (which are part of the AT command framework), AT command responses, and/or unsolicited result codes may be used.

Additional Considerations The 3GPP specification allows UE22 to establish only one type of SRB, which was an assumption taken in the present invention. However, the solution presented herein is also applicable when UE22 is enabled to set up SRB4 on both the first network node 16a and the second network node 16b. In this case, since SRB4 can already be set up between UE22 and both nodes, the first network node 16a may not need to request the second network node 16b to set up SRB4. In this case,
● The first network node 16a may instruct the second network node 16b that RVQoE reports related to the second configuration will be directly delivered to the second network node 16b from UE22 via SRB4 in the future.
● If the first network node 16a understands that data for a session undergoing RVQoE measurement will be delivered to the UE 22 via the second network node 16b (Solution 2), or if it receives such instructions from the UE 22 (Solution 1), the first network node 16a may instruct the UE 22 to send the RVQoE report related to the second configuration directly to the second network node 16b.
Alternatively, UE22 may independently decide to send the RVQoE report directly to the second network node 16b and notify the first network node 16a of this decision.

CG-Config
Messages are used to transmit SCG radio configurations generated by SgNB or SeNB. These messages may also be used by CUs to request that DUs perform certain actions, for example, to request that DUs implement new lower-layer configurations.

Direction: From secondary gNB or eNB to master gNB or eNB; alternatively, from CU to DU.

A non-exclusive example of a CG-Config message is as follows:

A non-restrictive example of a CG-ConfigInfo field description is included in the table below.
Table 1: Description of CG-ConfigInfo fields.

UE Capability Directives UE22 may be configured to direct the network to its ability to perform actions related to the described solution (for example, it may need to). As part of UE capability signaling (enhanced existing signaling or newly defined signaling), UE22 directs the network to its ability to work in accordance with embodiments of the disclosure, namely sending instructions to the network for nodes to carry application sessions, configuring the aforementioned SRB settings, and forwarding RVQoE reports directly to the appropriate network nodes.

The following is a non-exclusive list of exemplary embodiments.
Embodiment A1. A first network node configured to communicate with a user device (UE) and a second network node, wherein the UE is configured to communicate using multi-radio connectivity, and the first network node is
The first network node and the second network node transmit to the second network node information regarding which of the two network nodes has set up the perceived quality measurement for a given service type related to the UE.
Determining which of the first and second network nodes will carry data for application sessions undergoing perceived quality measurement for a given service type,
A first network node having a wireless interface and/or processing circuit configured to forward an application session-related

Embodiment A2. The processing circuit is:
The first network node,
The system transmits a perceived quality report to at least one of the first and second network nodes.
The first network node according to Embodiment A1, configured to cause the UE to configure itself to do at least one of the following: to instruct which of the first and second network nodes the perceived quality should target.

Embodiment A3.
The first network node and the second network node are radio access network (RAN) nodes.
The UE can be configured to send capability instructions to at least one of the first and second network nodes.
The perceived quality measurement is RAN Visible Perceived Quality (RVQoE) measurement, and the perceived quality report is an RVQoE report.
A first network node according to embodiment A1 or A2, which is at least one of the above.

Embodiment B1. A method in a first network node configured to communicate with a user device (UE) and a second network node, wherein the UE is configured to communicate using multi-radio connectivity, and the method is:
The first network node and the second network node transmit to the second network node information regarding which of the two network nodes has set up the perceived quality measurement for a given service type related to the UE.
Determining which of the first and second network nodes will carry data for application sessions undergoing perceived quality measurement for a given service type,
A method comprising forwarding an application session-related experience quality report to a second network node when the second network node is carrying data about an application session undergoing experience quality measurement.

Embodiment B2. The method is:
The system transmits a perceived quality report to at least one of the first and second network nodes.
The method according to Embodiment B1, further comprising configuring the UE to do at least one of the following: instructing which of the first and second network nodes the perceived quality should target.

Embodiment B3.
The first network node and the second network node are radio access network (RAN) nodes.
The UE can be configured to send capability instructions to at least one of the first and second network nodes.
The perceived quality measurement is RAN Visible Perceived Quality (RVQoE) measurement, and the perceived quality report is an RVQoE report.
The method according to embodiment B1 or B2, which is at least one of the following.

Embodiment C1. User equipment (UE) configured to communicate with a first network node and a second network node, wherein the UE is configured to communicate using multi-wireless connectivity, and the UE is
It is determined that data for application sessions undergoing perceived quality measurement for a given service type related to UE will be transported by a second network node,
User equipment (UE) comprising a wireless interface and/or processing circuit configured to transmit instructions to at least a first network node, the instructions indicating that data about an application session undergoing perceived quality measurement for a given service type is to be transported by a second network node, and the instructions are made available to the first network node for forwarding perceived quality reports corresponding to the application session to the second network node.

Embodiment C2. UE is
The UE according to Embodiment C1, configured by at least one of the first and second network nodes to transmit a perceived quality report to at least one of the first and second network nodes.

Embodiment C3.
The first network node and the second network node are radio access network (RAN) nodes.
The UE can be configured to send capability instructions to at least one of the first and second network nodes.
The perceived quality measurement is RAN Visible Perceived Quality (RVQoE) measurement, and the perceived quality report is an RVQoE report.
A UE according to embodiment C1 or C2, which is at least one of the following.

Embodiment D1. A method in a user device (UE) configured to communicate with a first network node and a second network node, wherein the UE is configured to communicate using multi-radio connectivity, and the method is:
It is determined that data for application sessions undergoing perceived quality measurement for a given service type related to UE will be transported by a second network node,
A method comprising sending an instruction to at least a first network node, the instruction indicating that data about an application session undergoing perceived quality measurement for a given service type is to be transported by a second network node, and the instruction making available to the first network node for forwarding perceived quality reports corresponding to the application session to the second network node.

Embodiment D2. UE is
The method according to Embodiment D1, wherein at least one of the first and second network nodes is configured to transmit a perceived quality report to at least one of the first and second network nodes.

Embodiment D3.
The first network node and the second network node are radio access network (RAN) nodes.
The UE can be configured to send capability instructions to at least one of the first and second network nodes.
The perceived quality measurement is RAN Visible Perceived Quality (RVQoE) measurement, and the perceived quality report is an RVQoE report.
The method according to embodiment D1 or D2, which is at least one of the following.

As those skilled in the art will understand, the concepts described herein may be embodied as methods, data processing systems, computer program products, and/or computer storage media for storing executable computer programs. Accordingly, the concepts described herein may take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware embodiments, all of which may be generally referred to herein as “circuits” or “modules.” Any process, step, action, and/or function described herein may be implemented by and/or associated with a corresponding module, which may be implemented in software and/or firmware and/or hardware. Furthermore, this disclosure may take the form of a computer program product on a tangible computer-readable storage medium having computer program code embodied on a medium executable by a computer. Any suitable tangible computer-readable medium may be used, including hard disks, CD-ROMs, electronic storage devices, optical storage devices, or magnetic storage devices.

Several embodiments have been described herein with reference to flowcharts and/or block diagrams illustrating methods, systems, and computer program products. It will be understood that each block in the flowcharts and/or block diagrams, as well as combinations of blocks in the flowcharts and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to the processor of a general-purpose computer, a dedicated computer, or other programmable data processing device for creating a machine (thereby creating a dedicated computer), and therefore, those instructions executed via the processor of the computer or other programmable data processing device create means for implementing the functions/actions specified in one or more blocks of the flowcharts and/or block diagrams.

These computer program instructions may also be stored in computer-readable memory or storage media that can instruct a computer or other programmable data processing device to function in a specific manner. Therefore, instructions stored in computer-readable memory produce a product containing instruction means that implement functions/actions specified in one or more blocks of a flowchart and/or block diagram.

Computer program instructions can also be loaded into a computer or other programmable data processing device to cause a series of operational steps to be performed on the computer or other programmable device in order to create a computer implementation process. Therefore, instructions executed on the computer or other programmable device provide steps for implementing a function/action specified in one or more blocks of a flowchart and/or block diagram.

Please understand that the functions/actions mentioned within a block may occur in a different order than those shown in the illustrative diagram of the operation. For example, depending on the functions/actions involved, two blocks shown consecutively may, in effect, be executed substantially concurrently, or blocks may sometimes be executed in reverse order. While some diagrams include arrows on the communication path to indicate the primary direction of communication, please understand that communication may occur in the opposite direction to the illustrated arrows.

Computer program code for performing the operations of the concepts described herein may be written in object-oriented programming languages such as Python, Java®, or C++. However, computer program code for performing the operations of the disclosure may also be written in conventional procedural programming languages such as the C programming language. The program code may run entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer. In the latter scenario, the remote computer may be connected to the user's computer via a local area network (LAN) or wide area network (WAN), or the connection may be made to an external computer (for example, via the Internet using an Internet service provider).

Many different embodiments have been disclosed herein with respect to the above description and drawings. It will be understood that a literal description and illustration of every combination and partial combination of these embodiments would be excessively repetitive and obscure. Therefore, all embodiments may be combined in some way and/or in combination, and this specification, including the drawings, should be construed as constituting a complete written description of all combinations and partial combinations of the embodiments described herein, and all combinations and partial combinations of the modes and processes of making and using them, and shall support any claims for any such combination or partial combination.

The abbreviations that may be used in the above explanation include the following:
3GPP (Third Generation Partnership Project), 5G (Fifth Generation 5GC), 5G Core Network (5GS), 5th Generation System (AS), Access Layer (AMF), Access and Mobility Management Function (ASN.1), Abstract Syntax Notation (1)
AT (Attention AR), Augmented Reality (AS), Access Hierarchy (BAP), Backhaul Adaptive Protocol (CGI), Cell Global Identification Information (CN), Core Network (CP), Control Plane (CU), Central Unit (CU-CP), Central Unit Control Plane (CU-UP), Central Unit User Plane (DU), Distributed Unit (DASH), Dynamic Adaptive Streaming over HTTP
DC Dual Connectivity DL Downlink DNS Domain Name System E-CGI
E-UTRAN CGI: eNB Evolved Node B / E-UTRAN Node Ben-gNB. gNB that acts as a secondary node in an EN-DC scenario (i.e., a DC scenario with eNB as the master node and gNB as a secondary node).
EN E-UTRAN-NR
EPC Evolved Packet Core EPS Evolved Packet System E-UTRA Extended UTRA
E-UTRAN/
EUTRAN Extended UTRAN
gNB NR Wireless base station HSS Home subscriber server HTTP Hypertext Transfer Protocol IAB Wireless access backhaul integrated transmission ID Identifier/identification information IE Information element LTE Long Term Evolution
MAC (Media Access Control), MCC (Mobile Country Code), MCE (Measurement Collection Entity/Measurement Collector Entity), MDT (Drive Test Minimization Entity), MN (Mobility Management Entity), MNC (Master Node), MTSI (Mobile Network Code), N3IWF (Multimedia Telephony Service for IMS), NG (Non-3GPP Interworking Function), Next Generation NG (NG-RAN - Interface between 5GC).
NGAP (NG Application Protocol), NG-RAN (NG Wireless Access Network), NID (Network Identifier), NR (New Wireless NWDAF), O&M (Operations and Maintenance), OAM (Operations and Maintenance), PDCP (Operations and Maintenance), Packet Data Convergence Protocol (PDU), Protocol Data Unit (PLMN), Public Land Mobile Network (QMC), QoE Measurement and Collection (QoE), Perceived Quality (QoS), Service Quality (RAN), Wireless Access Network (RAT), Wireless Access Technology (RLC), Wireless Link Control (RNC), Wireless Network Controller (RRC), Wireless Resource Control (RVQoE), RAN Visible QoE
S1: The interface between RAN and CN in LTE.
S1AP (S1 Application Protocol) S-NSSAI (Single Network Slice Selection Support Information) SMO (Service Management and Orchestration SN) Secondary Node SRB (Secondary Node SRB) Signaling Wireless Bearer TA (Terminal Aid) Tracking Area TCE (Tracking Area Equation) Trace Collection Entity/Trace Collector Entity TNGF (Trust Non-3GPP Gateway Function TWIF (Trust WLAN Interworking Function UDM (Unified Data Management UE (UE) User Equipment UMTS (Universal Mobile Telecommunication System))
URI Uniform Resource Identifier URL Uniform Resource Locator UTRA Universal Terrestrial Radio Access UTRAN Universal Terrestrial Radio Access Network WLAN Wireless Local Area Network Xn NR Interface between two gNBs XnAP Xn Application Protocol

It will be understood by those skilled in the art that the embodiments described herein are not limited to those specifically shown and described herein. Furthermore, it should be noted that not all of the accompanying drawings are to a single scale unless otherwise stated above. In light of the above teachings, various modifications and variations are possible without departing from the following claims.

Claims (15)

A method in a first network node (16a) configured to communicate with a user equipment (UE) (22) and a second network node (16b), wherein the UE (22) is configurable to communicate using multi-radio connectivity with the first network node (16a) and the second network node (16b), the method is performed by the first network node (16a) while the multi-radio connectivity is established and maintained, and the method is
To determine which of the first network node (16a) and the second network node (16b) has a report corresponding to the service type related to the UE (22), the second network node (16b) is coordinated with (S144),
Determining which of the first network node (16a) and the second network node (16b) will carry the data for the application session that is subject to the perceived quality measurement related to the report (S146),
A method comprising performing one or more actions (S148) to ensure that one of the first network node (16a) and the second network node (16b) that transports the data receives the report. The aforementioned coordination,
The first network node (16a) transmits a first instruction to the second network node (16b) indicating that it has received the report from the UE (22),
The method according to claim 1, comprising receiving a second instruction from the second network node (16b) indicating that the second network node (16b) has received the report from the UE (22). The aforementioned report comprises one or more of the following: a data radio bearer (DRB) identifier (ID), a quality of service (QoS) flow ID, and a packet data unit (PDU) session ID.
The determination of which of the first network node (16a) and the second network node (16b) will carry the data for the application session is based on one or more of the DRB ID, the QoS flow ID, and the PDU session ID.
The method according to claim 1. The method described above is
The method according to claim 1, further comprising receiving the report from the UE(22). Performing one or more of the aforementioned actions means
The method of claim 4, comprising transmitting the report to the second network node (16b) when the second network node (16b) carries the data for the application session, the transmitted report being available to the second network node (16b) for either or both of transmitting and receiving signaling related to the service type to the UE (22). Performing one or more of the aforementioned actions means
The method according to claim 1, wherein when the first network node (16a) carries the data for the application session, the receiving of the report from the second network node (16b), the received report being available to the first network node (16a) for either or both of sending and receiving signaling related to the service type to the UE (22). A first network node (16a) configured to communicate with a user equipment (UE) (22) and a second network node (16b), wherein at least the UE (22) is configurable to communicate using multi-wireless connectivity with the first network node (16a) and the second network node (16b), and the first network node (16a) is configured to communicate while the multi-wireless connectivity is established and maintained.
To determine which of the first network node (16a) and the second network node (16b) has a report corresponding to the service type related to the UE (22), the second network node (16b) is coordinated with the second network node (16b),
To determine which of the first network node (16a) and the second network node (16b) will carry the data for the application session undergoing the perceived quality measurement related to the report,
A first network node (16a) is configured to perform one or more actions to ensure that one of the first network node (16a) and the second network node (16b) that transports the data receives the report. A first network node according to claim 7, further configured to carry out the method described in any one of claims 2 to 6. A method in a user equipment (UE) (22) configured to communicate using multi-radio connectivity with a first network node (16a) and a second network node (16b), wherein the method is performed by the UE (22) while the multi-radio connectivity is established and maintained, and the method is
S150 transmits a report to one of the first network node (16a) and the second network node (16b) corresponding to a service type associated with the UE (22), wherein the report comprises one or more of a data radio bearer (DRB) identifier (ID), a quality of service (QoS) flow ID, and a packet data unit (PDU) session ID, and which of the first network node (16a) and the second network node (16b) carries data for an application session is determined based on one or more of the DRB ID, the QoS flow ID, and the PDU session ID.
Methods that include... The aforementioned method,
Determine which of the first network node (16a) and the second network node (16b) will carry the data for the application session receiving the perceived quality measurement related to the report, and determine the capability indications available to one or both of the first network node (16a) and the second network node (16b) in order to perform one or more actions to ensure that one of the first network node (16a) and the second network node (16b) that carries the data acquires the report,
The method according to claim 9, further comprising transmitting the capability instruction to one or both of the first network node (16a) and the second network node (16b). When the report is transmitted to the first network node (16a), the one or more actions are:
The method according to claim 10, wherein the first network node (16a) transmits the report to the second network node (16b) when the second network node (16b) is carrying the data for the application session, the transmitted report being available to the second network node (16b) for either or both of transmitting and receiving signaling related to the service type to the UE (22). The one or more actions described above are:
The method according to claim 10, wherein the first network node (16a) receives the report from the second network node (16b) when the first network node (16a) carries the data for the application session, the received report being available to the first network node (16a) for either or both of sending and receiving signaling related to the service type to the UE (22). The method according to claim 10, wherein the perceived quality measurement is one or both of perceived quality (QoE) measurement and wireless access network (RAN) visible perceived quality (RVQoE) measurement. A user device (UE) (22) configured to communicate using multi-wireless connectivity with a first network node (16a) and a second network node (16b), wherein the UE (22) is configured to communicate while the multi-wireless connectivity is established and maintained.
User equipment (UE) (22) is configured to cause a transmission to one of the first network node (16a) and the second network node (16b) of the UE (22) of a report corresponding to a service type associated with the UE (22), wherein the report comprises one or more of a data radio bearer (DRB) identifier (ID), a quality of service (QoS) flow ID, and a packet data unit (PDU) session ID, and which of the first network node (16a) and the second network node (16b) carries data about the application session is determined based on one or more of the DRB ID, the QoS flow ID, and the PDU session ID. The UE according to claim 14, further configured to cause the UE to carry out the method described in any one of claims 10 to 13.