RVQOE measurement and reporting for dual connectivity

Abstract

According to some embodiments, a method is implemented by a wireless device operating in dual connectivity with a first network node and a second network node. The method includes receiving a radio access network visible quality of experience (RVQoE) configuration associated with an application session; determining whether the application session is provided through communication with both the first network node and the second network node; and sending an RVQoE report for the application session based on determining whether the application session is provided through communication with both the first network node and the second network node.

Description

Technical Field

[0001] Embodiments of the present disclosure relate to wireless communication, and more particularly, to radio access network (RAN) visible quality of experience (RVQoE) measurement and reporting for dual connectivity (DC). Background Art

[0002] Figure 1 The current Next Generation (NG) Radio Access Network (RAN) architecture (3GPP TS 38.401) is shown. The NG-RAN includes a set of gNBs connected to the 5th Generation Core (5GC) via the NG interface. As specified in 38.300, the NG-RAN may also include a set of ng-eNBs, which may include an ng-eNB Central Unit (CU) and one or more ng-eNB Distributed Units (DUs). The ng-eNB-CU and the ng-eNB-DU are connected via the W1 interface. Unless otherwise explicitly specified, the general principles described herein also apply to ng-eNBs and the W1 interface.

[0003] The gNB may support Frequency Division Duplexing (FDD) mode, Time Division Duplexing (TDD) mode, or dual-mode operation. The Xn interface interconnects the gNBs.

[0004] The gNB may include a gNB-CU and one or more gNB-DUs. The gNB-CU and the gNB-DU are connected via the F1 interface. One gNB-DU is only connected to one gNB-CU. NG, Xn, and F1 are logical interfaces.

[0005] For the NG-RAN, the NG and Xn-C interfaces for the gNB including the gNB-CU and the gNB-DU terminate at the gNB-CU. For EN-DC, the S1-U and X2-C interfaces for the gNB including the gNB-CU and the gNB-DU terminate at the gNB-CU. The gNB-CU and the connected gNB-DUs are only visible as a gNB to other gNBs and the 5GC.

[0006] The node hosting the user plane part of the New Radio (NR) Packet Data Convergence Protocol (PDCP) (e.g., gNB-CU, gNB-CU-UP, and for EN-DC, MeNB or SgNB, depending on bearer separation) shall implement user inactivity monitoring and further notify its inactivity or (re)activation to the node having a control plane connection to the core network (e.g., via E1, X2). The node hosting the NR Radio Link Control (RLC) (e.g., gNB-DU) may implement user inactivity monitoring and further notify its inactivity or (re)activation to the node hosting the control plane, e.g., gNB-CU or gNB-CU-CP.

[0007] The uplink (UL) PDCP configuration (i.e., how the UE uses the UL at the secondary node) is indicated via X2-C (for EN-DC), Xn-C (for NG-RAN), and F1-C. The radio link interruption / resumption for the downlink (DL) and / or UL is indicated via X2-U (for EN-DC), Xn-U (for NG-RAN), and F1-U.

[0008] The 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 them, is defined as part of the RNL. For each NG-RAN interface (NG, Xn, F1), the relevant TNL protocols and functions are specified. The TNL provides services for user plane transport and signaling transport.

[0009] In the NG-Flex configuration, each NG-RAN node is connected to all Access and Mobility Management Functions (AMF) within an AMF set in an AMF area that supports at least one slice also supported by the NG-RAN node. The AMF set and the AMF area are defined in 3GPP TS 23.501.

[0010] If security protection for the control plane and user plane data on the TNL for the NG-RAN interface is to be supported, then NDS / IP 3GPP TS 33.501 should be applied.

[0011] Figure 2 The overall architecture for the separation of gNB-CU-CP and gNB-CU-UP is shown and specified in TS 37.483. A gNB can include a gNB-CU-CP, multiple gNB-CU-UPs, and multiple gNB-DUs. The gNB-CU-CP is connected to the gNB-DU via the F1-C interface. The gNB-CU-UP is connected to the gNB-DU via the F1-U interface. The gNB-CU-UP is connected to the gNB-CU-CP via the E1 interface. One gNB-DU is only connected to one gNB-CU-CP. One gNB-CU-UP is only connected to one gNB-CU-CP.

[0012] For resilience, the gNB-DU and / or gNB-CU-UP can be connected to multiple gNB-CU-CPs through appropriate implementation.

[0013] One gNB-DU can be connected to multiple gNB-CU-UPs under the control of the same gNB-CU-CP. One gNB-CU-UP can be connected to multiple DUs under the control of the same gNB-CU-CP.

[0014] The connection between gNB-CU-UP and gNB-DU is established by gNB-CU-CP using the bearer context management function. gNB-CU-CP selects an appropriate gNB-CU-UP for the service requested for the UE. For multiple CU-Ups, they belong to the same security domain as defined in TS 33.210. Xn-U can support data forwarding between gNB-CU-UPs during handover within gNB-CU-CP in the gNB.

[0015] In dual connectivity (DC), a UE with multi-transmit / receive capabilities can be connected to more than one RAN node. The RAN nodes can have the same radio access technology (RAT) (both the master node and the secondary node in NR or Long Term Evolution (LTE) respectively) or different RATs, e.g., a master LTE node and a secondary NR node. The specification TS 37.340 describes the principle of multi-radio dual connectivity as follows:

[0016] ==========================================================================Excerpt from TS 37.340 starts==========================================================================4.1 General overview

[0017] 4.1.1 Common MR-DC principles

[0018] Multi-radio dual connectivity (MR-DC) is a generalization of the dual connectivity (DC) within E-UTRA described in TS 36.300, where a UE with multi Rx / Tx capabilities 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 E-UTRA or NR access. One node acts as the MN and the other as the SN. The MN and the SN are connected via a network interface, and at least the MN is connected to the core network.

[0019] The MN and / or the SN can be operated using shared spectrum channel access.

[0020] Unless otherwise specified, all functions specified for the UE are available for the IAB-MT. Similar to that specified for the UE, the IAB-MT can access the network using one network node or, in the case of EN-DC and NR-DC architectures, two different nodes. In EN-DC, backhaul traffic via the E-UTRA radio interface is not supported.

[0021] Note 1: MR-DC is designed based on the assumption of non-ideal backhaul between different nodes, but can also be used for the case of ideal backhaul.

[0022] Note 2: All MR-DC normative texts and procedures in this version of the specification show the aggregated node scenario. Details of non-aggregated nodes for MR-DC operations are described in TS 38.401.

[0023] 4.1.2 MR-DC with EPC

[0024] E-UTRAN supports MR-DC via E-UTRA-NR dual connectivity (EN-DC), where the UE is connected to an eNB acting as the MN and an en-gNB acting as the SN. The eNB is connected to the EPC via the S1 interface and to the en-gNB via the X2 interface. The en-gNB can also be connected to the EPC via the S1-U interface and to other en-gNBs via the X2-U interface.

[0025] The EN-DC architecture is as shown in Figure 4 .1.2-1 (reproduced as Figure 3 in this document).

[0026] 4.1.3 MR-DC with 5GC

[0027] 4.1.3.1 E-UTRA-NR dual connectivity

[0028] NG-RAN supports NG-RAN E-UTRA-NR dual connectivity (NGEN-DC), where the UE is connected to an ng-eNB acting as the MN and a gNB acting as the SN.

[0029] 4.1.3.2 NR-E-UTRA dual connectivity

[0030] NG-RAN supports NR-E-UTRA dual connectivity (NE-DC), where the UE is connected to a gNB acting as the MN and an ng-eNB acting as the SN.

[0031] 4.1.3.3 NR-NR dual connectivity

[0032] NG-RAN supports NR-NR dual connectivity (NR-DC), where the UE is connected to a gNB acting as the MN and another gNB acting as the SN. Additionally, NR-DC can also be used when the UE is connected to two gNB-DUs (one serving the MCG and the other serving the SCG, connected to the same gNB-CU, acting as both the MN and the SN). ======= Excerpt from TS 37.340 ends =======

[0033] The procedures for setting up dual connectivity are described in Chapter 10 of TS 37.340. Figure 10 .2.1-1 is a signaling diagram showing the secondary node addition procedure (reproduced as Figure 4 in this document).

[0034] Quality of Experience (QoE) measurement, also known as "application layer measurement", has been specified for LTE and Universal Mobile Telecommunications Service (UMTS) and will be specified for NR in 3GPP Release 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 MTSI (Mobile Telephone Service for IMS) services. For NR, it is very likely that at least Virtual Reality (VR) will be added to the list of services for which QoE measurement is specified and supported.

[0035] The solutions in LTE and UMTS are similar to the following general principles. Quality of Experience Measurement Collection (QMC) enables the configuration of application layer measurement in the User Equipment (UE) and the transmission of the QoE measurement result file (commonly known as the QoE report) to the network via Radio Resource Control (RRC) signaling. The application layer measurement configuration (also known as QoE measurement configuration or QoE configuration) received by the Radio Access Network (RAN) from the Operation and Management (OAM) system or the Core Network (CN) is encapsulated in a transparent container and forwarded to the UE in a downlink RRC message. The application layer measurement report (also known as the QoE report) received by the UE Access Stratum (UE AS) or the UE RRC layer from the higher layer (application layer) of the UE is encapsulated in a transparent container and sent to the network in an uplink RRC message. The RAN then forwards the QoE report to the Measurement Collection Entity (MCE).

[0036] In 3GPP Release 17, a new research project on "NR QoE Management and Optimization for Multiple Services" for NR has been approved and concluded. The specification work for 3GPP Release 17 is still in progress. The purpose of this research project is to study solutions for QoE measurement in NR. QoE management in NR will not only collect Quality of Experience parameters for streaming services but also consider the typical performance requirements of multiple services (e.g., Augmented Reality (AR) / VR and Ultra-Reliable Low-Latency Communication (URLLC), where at least VR seems to be covered in 3GPP Release 17). Based on the requirements of the services, the NR research also includes more adaptable QoE management schemes, which enable network optimization to meet the user experience of various services.

[0037] Configuration data related to QoE measurement (commonly referred to as application layer measurement in the standard specifications) includes service type indication, indication of the area in which the measurement should be implemented (expressed as an area scope), the Internet Protocol (IP) address of the entity to which the collected measurement results (i.e., QoE reports) should be sent (commonly referred to as the MCE, but this entity may sometimes also be referred to as the Trace Collection Entity (TCE)), and a set of instructions on details of what type of measurement should be implemented and how to implement the measurement. The instructions are intended for the application layer in the UE and are placed in a "container" that cannot be interpreted and will not be attempted to be read by the network entity that processes it (such as forwarding it to the UE) and the UE access layer.

[0038] The currently specified service types are MTSI and Streaming Service (DASH), and in 3GPP Release 17, at least the service type VR will be added.

[0039] The area scope is defined according to the cell or network-related area. In UMTS, the area scope is defined as a list of cells, a list of routing areas, or a list of tracking areas. In LTE, the area scope is defined as a list of cells or a list of tracking areas. In NR, the area scope will be defined as a list of cells or a list of tracking areas.

[0040] QoE, especially QoE configuration, has two types: management-based QoE configuration and signaling-based QoE setting. In both cases, the QoE configuration originates from the OAM system or some other management entity, such as handling customer satisfaction. All these entities are referred to as the OAM system in this article (where the OAM system also includes other entities). In the case of management-based QoE (m-based QoE), the OAM system is usually interested in general QoE statistics from a specific area (which is configured as the area scope). The m-based QoE configuration is sent directly from the OAM system to the RAN node that controls the cells within the area scope. Then, each RAN node selects the UEs within the area scope (and also meets any other relevant conditions, such as supporting the relevant application / service type) and sends the m-based QoE configuration to these UEs.

[0041] In the case of signaling-based QoE (s-based QoE), the OAM system is interested in collecting QoE measurement results from a specific UE, for example because the user of the UE has filed a complaint. The OAM system sends the s-based QoE configuration to the Home Subscriber Server (HSS) (in the Evolved Packet System (EPS) / LTE) or the Unified Data Management (UDM) (in 5GS / NR), which forwards the QoE configuration to the UE's current core network node, such as the Mobility Management Entity (MME) in EPS / LTE or the Access and Mobility Management Function (AMF) in 5G / NR. The core network then forwards the s-based QoE configuration to the RAN node serving the relevant UE, and the RAN forwards it to the UE.

[0042] What is forwarded to the UE is the service type indication and a container with measurement instructions. The UE does not know whether the received QoE configuration is m-based or s-based. In legacy systems, the QoE framework was integrated with the tracing function, and a tracing identifier was associated with each QoE configuration. In NR, the QoE function will be logically separated from the tracing function, but it will still partially reuse the tracing signaling mechanism.

[0043] In NR and LTE, a globally unique QoE reference (formed by the Mobile Country Code (MCC) + Mobile Network Code (MNC) + QoE Measurement Collection (QMC) Identifier (ID), which is a 24-bit string) will be associated with each QoE configuration. The QoE reference is included in the container with the measurement instructions and is also sent to the RAN (i.e., the gNB in NR). For the communication between the gNB and the UE, the QoE reference is represented by a shorter identifier of 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). measConfigAppLayerId is stored in the UE access stratum and is forwarded in the Attention (AT) command (which is a type of instruction used in the communication between the modem part of the UE and the UE's application layer) together with the service type indication and the container with the measurement instructions.

[0044] A report with the collected QoE measurement results (QoE report) is sent from the UE application layer to the UE access stratum, which forwards it to the RAN, and the RAN forwards it to the MCE. These QoE measurement results are placed in a "container" that is not interpretable by the UE access stratum and the RAN. The QoE report can be configured to be periodic or sent only at the end of the application session. In addition, the RAN can instruct the UE to pause the QoE report, for example, if the cell / gNB is overloaded.

[0045] RAN does not know when an application session with an associated QoE measurement session is in progress, and the UE access stratum does not automatically know this either. To alleviate this situation, a session start / stop indication can be introduced, which will be sent from the application layer in the UE to the UE AS and from the UE AS to the RAN. The session stop indication can be implicit, in the form of a QoE report that is sent when the application session and the associated QoE measurement session end.

[0046] As an implementation-based decision, the RAN can decide at any time to release the QoE configuration in the UE. Typically, this is done when the UE has moved outside the area configured for QoE measurement (commonly referred to as the area scope).

[0047] An opportunity provided by legacy solutions is to maintain QoE measurements for the entire session even during handover scenarios. It has also been discussed to have the UE continue QoE measurements on an ongoing application session until the application session ends, even if the UE moves outside the configured area scope during that time.

[0048] In NR, 3GPP Rel-17 introduced RAN-visible QoE measurements, and a general description can be found in Section 21.4 of 3GPP TS 38.300 v17.0.0.

[0049] RAN-visible QoE measurements are configured by the NG-RAN node, where a subset of QoE metrics is reported from the UE as explicit information elements (IEs) readable by the NG-RAN node. The NG-RAN node can use the RAN-visible QoE measurements (e.g., RAN-visible QoS metrics, RAN-visible QoS values) for network optimization. RAN-visible QoE measurements are supported for DASH streaming and VR services. The NG-RAN node configures the RAN-visible QoE measurements to collect all or some of the available RAN-visible QoE metrics, where an indication of metric availability is received from the OAM or the CN. The set of available RAN-visible QoE metrics is a subset of the metrics that are part of the QoE measurement configuration configured to be encapsulated in a transparent container. The UE can also report the protocol data unit (PDU) session identifier corresponding to the service undergoing QoE measurement together with the RAN-visible QoE measurement results.

[0050] The request to collect QoE measurements not visible to the RAN (also known as OAM-QoE in R3-223290) originates from the OAM and is identified by a QoE reference. The definition of this identifier can be found in Section 5.2 of 3GPP TS28.405 v17.1.0.

[0051] The QoE reference parameter specifies a network request session. The QoE reference shall be globally unique and thus consists of: MCC + MNC + QMC ID, where MCC and MNC accompany the QMC activation request from the management system to identify a Public Land Mobile Network (PLMN) containing the management system, and the QMC ID is a 3 - byte octet string. The QMC ID is generated by the management system or the operator. It is used to identify QoE measurement collection jobs in the service node and the measurement collection center.

[0052] 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), and for example in TS 38.331, the application - layer measurements are identified by the MeasConfigAppLayerId IE.

[0053] In the gNB, RAN - visible QoE information can be transferred from the gNB - CU to the gNB - DU in the process described in TS 38.473v17.0.0. This process is UE - associated, i.e., it is specific to the UE.

[0054] The purpose of the QoE information transfer process is to transfer RAN - visible QoE information from the gNB - CU to the gNB - DU. This process uses UE - associated signaling. Figure 5 Examples are shown.

[0055] Figure 5 is a signaling diagram showing the QoE information transfer process. The gNB - CU initiates this process by sending a QOE information transfer message to the gNB - DU. If the QoE Information List (QoE information list) IE is included in the QoE information transfer message, the gNB - DU can take it into account according to TS 38.300.

[0056] The gNB - CU sends a QOE information transfer message to the gNB - DU to indicate information related to RAN - visible QOE.

[0057]

[0058] Range boundary Explanation maxnoofQoEInformation The maximum number of QoE information for a UE, with a maximum value of 16.

[0059] The QoE metric IE provides a RAN - visible QoE measurement report to the gNB - DU.

[0060] IE / Group name Existence Range IE type and reference Semantic description Buffer level O Octet string As defined in TS 38.331. Playback delay O Octet string As defined in TS 38.331.

[0061] In contribution R3-223128 to 3GPP TSG-RAN WG3 meeting #116-e, the association of RAN visible QoE reports with references was discussed.

[0062] In F1AP, a list containing RVQoE metrics is transmitted over F1 using UE-associated signaling, but the reports are not associated with any reference or other identifier, 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 QoE reports from different application sessions. In addition, the gNB-DU will not be able to group the reports it receives continuously from a given application session, and thus will not be able to track any trends in the reported data, for example.

[0063] Candidate references or other identifiers that could solve this problem would typically be the QoE reference assigned by the UE or the short RRC ID (measConfigAppLayerId). The F1AP change request R3-223131 proposes using the QoE reference, but the final selection may require further evaluation.

[0064] The same contribution discussed using the QoE reference or short RRC ID (measConfigAppLayerId) to identify RVQoE report information over F1.

[0065] Signaling Radio Bearers (SRBs) are configured in the UE for the transmission of control plane messages to and from the UE. In the current specification, five different SRBs can be configured. SRB0 is used for initial RRC setup before any security is activated. SRB1 is used for most RRC messages, and SRB2 is used for non-access stratum (NAS) messages.

[0066] If the UE is configured with dual connectivity (DC), then SRB1 is used for communication with the master node (MN). The UE can also be configured with SRB3 in DC, which is used for direct communication between the UE and the secondary node (SN).

[0067] A dedicated SRB4 has been defined for the transmission of QoE and RVQoE reports. SRB4 is used in Rel-17 only for the transmission of QoE and RVQoE reports in the RRC message MeasurementReportAppLayer to the master node or to the gNB in single connectivity mode.

[0068] There are currently some challenges. As an example, in Rel-18, QoE and RAN visible QoE (RVQoE) measurement collection and reporting will be supported for UEs in NR dual connectivity (NR-DC). Two basic requirements for RVQoE are:

[0069] · Requirement 1: Nodes that deliver data for an application session to and from a UE shall participate in assembling

[0070] RVQoE measurement configuration.

[0071] · Requirement 2: RVQoE reports shall be delivered to nodes that deliver data for an application session to and from a UE.

[0072] Some proposals describe how to ensure compliance with the above principles when the MN or SN carries data for an application session to the UE. However, if the data for the application session is delivered to the UE by both the MN and the SN, it is not clear how to ensure compliance with the above principles.

[0073] There are two scenarios. In the first scenario, the application session has multiple data streams, for example, one for video and one for audio, and the different data streams are sent via different DC branches. In the second scenario, the application session has one or more data streams, and each stream is carried on two DC connection branches using separate data radio bearers (DRBs).

[0074] For the first scenario, assuming that the UE application layer generates RVQoE reports and each report is related to the entire data stream of the session (rather than, for example, only one of the bearers), if the session is carried by two nodes in such a way that one data stream is carried by the MN connection branch and the other data stream is carried by the SN connection branch, it is not clear which part of the RVQoE report is related to which of the two RAN nodes serving the UE.

[0075] In the second scenario, that is, when separate bearers (or multiple separate bearers) are used to carry the application session data streams, the challenge is that neither the MN nor the SN can independently control the adaptation of the processing of the application session data streams, such as scheduling priority adaptation. This may cause the adaptations of the MN and the SN to cancel each other out or amplify each other in an unexpected way, for example, it may lead to overcompensation. Summary of the Invention

[0076] As described above, there are currently certain challenges for radio access network (RAN) visible quality of experience (RVQoE) measurement and reporting for dual connectivity (DC). Certain aspects and embodiments of the present disclosure can provide solutions for these or other challenges. For example, when data for an application session is carried via more than one multi-connection branch, certain embodiments implement RVQoE measurement configuration and reporting for a user equipment (UE) in a multi-connection. For new radio (NR) DC, this involves RVQoE measurement configuration and reporting when both the master node (MN) and the secondary node (SN) deliver data for an application session to the UE. For this scenario, certain embodiments meet the above basic requirements 1 and 2 for RVQoE measurement and reporting.

[0077] According to some embodiments, a method is implemented by a wireless device operating in a dual connection with a first network node and a second network node. The method includes: receiving an RVQoE configuration associated with an application session; determining whether the application session is provided through communication with both the first network node and the second network node; and based on determining whether the application session is provided through communication with both the first network node and the second network node, sending an RVQoE report for the application session.

[0078] In a particular embodiment, determining whether the application session is provided through communication with both the first network node and the second network node includes: receiving a reporting configuration in the RVQoE configuration that indicates whether the RVQoE report is towards the first network node, the second network node, or both the first network node and the second network node.

[0079] In a particular embodiment, determining whether the application session is provided through communication with both the first network node and the second network node is based on the association between the application session and one or more bearer channels.

[0080] In a particular embodiment, the method further includes: sending the association between the application session and one or more bearer channels to one or both of the first network node and the second network node; and receiving an updated RVQoE configuration including a reporting configuration from one or both of the first network node and the second network node, the reporting configuration indicating whether the RVQoE report is towards the first network node, the second network node, or both the first network node and the second network node based on the association between the application session and one or more bearer channels.

[0081] In a particular embodiment, receiving the RVQoE configuration occurs after the application session starts, and the RVQoE configuration includes an indication of whether the RVQoE report is towards the first network node, the second network node, or both the first network node and the second network node based on the protocol used by the application session.

[0082] In a particular embodiment, receiving the RVQoE configuration occurs after the application session starts and after a first RVQoE report has been sent by the wireless device, and the RVQoE configuration includes an indication of whether the RVQoE report is towards the first network node, the second network node, or both the first network node and the second network node based on the first RVQoE report.

[0083] According to some embodiments, a wireless device includes processing circuitry operable to implement any of the methods of the wireless receiver described above.

[0084] A computer program product is also disclosed, which includes a non-transitory computer-readable medium storing computer-readable program code that, when executed by the processing circuitry, is operable to implement any of the methods implemented by the wireless device described above.

[0085] According to some embodiments, a method is implemented by a first network node operating in a dual connection with a second network node. The method includes: determining whether an application session is provided through communication with both the first network node and the second network node, and configuring a wireless device with an RVQoE configuration associated with the application session. The RVQoE configuration includes a reporting configuration that, based on whether the application session is provided through communication with both the first network node and the second network node, indicates whether the RVQoE report is directed to the first network node, the second network node, or both the first network node and the second network node. The method further includes: receiving, based on the reporting configuration, an RVQoE report for the application session from the wireless device.

[0086] In a particular embodiment, determining whether the application session is provided through communication with both the first network node and the second network node is based on an association between the application session and one or more bearer channels.

[0087] In a particular embodiment, determining whether the application session is provided through communication with both the first network node and the second network node includes: receiving, from the wireless device, the association between the application session and one or more bearer channels.

[0088] In a particular embodiment, determining whether the application session is provided through communication with both the first network node and the second network node is based on the protocol used by the application session.

[0089] In a particular embodiment, determining whether the application session is provided through communication with both the first network node and the second network node occurs after a first RVQoE report has been sent by the wireless device, and the determination is based on the first RVQoE report.

[0090] In a particular embodiment, the first network node includes an MN and the second network node includes an SN, or the first network node includes an SN and the second network node includes an MN.

[0091] In certain embodiments, the method further comprises: forwarding the received RV QoE report to the second network node.

[0092] According to some embodiments, a network node comprises processing circuitry operable to implement any of the methods of the network node described above.

[0093] There is also disclosed a computer program product comprising a non-transitory computer-readable medium storing computer-readable program code which, when executed by processing circuitry, is operable to implement any of the methods implemented by the network node described above.

[0094] Certain embodiments may provide one or more of the following technical advantages. For example, a particular embodiment makes it feasible to perform meaningful RV QoE measurements and reporting, even if data for an application session is delivered to the UE by both the MN and the SN or delivered from the UE towards both the MN and the SN. BRIEF DESCRIPTION OF THE DRAWINGS

[0095] To more fully understand the disclosed embodiments and their features and advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, in which:

[0096] Figure 1 A current Next Generation (NG) Radio Access Network (RAN) architecture is shown;

[0097] Figure 2 An overall architecture for gNB-CU-CP and gNB-CU-UP separation is shown;

[0098] Figure 3 An EN-DC overall architecture is shown;

[0099] Figure 4 Is a signaling diagram showing a secondary node addition procedure;

[0100] Figure 5 Is a signaling diagram showing a Quality of Experience (QoE) information transfer procedure;

[0101] Figure 6 An example communication system according to certain embodiments is shown;

[0102] Figure 7 An example User Equipment (UE) according to certain embodiments is shown;

[0103] Figure 8 An example network node according to certain embodiments is shown;

[0104] Figure 9 A block diagram of a host according to certain embodiments is shown;

[0105] Figure 10Shows a virtualized environment according to certain embodiments, in which functions implemented by some embodiments can be virtualized;

[0106] Figure 11 Shows a host communicating with a UE via a network node through a partial wireless connection according to certain embodiments;

[0107] Figure 12 Shows a method implemented by a wireless device according to certain embodiments; and

[0108] Figure 13 Shows a method implemented by a network node according to certain embodiments. Detailed Description

[0109] As mentioned above, there are currently certain challenges for radio access network (RAN) visible quality of experience (RVQoE) measurement and reporting for dual connectivity (DC). Certain aspects and embodiments of the present disclosure can provide solutions for these or other challenges. For example, when data for an application session is carried via more than one multi-connectivity leg, certain embodiments implement RVQoE measurement configuration and reporting for user equipment (UE) in multi-connectivity. For New Radio (NR) DC, this involves RVQoE measurement configuration and reporting when data for an application session is delivered to the UE by both the master node (MN) and the secondary node (SN).

[0110] Specific embodiments will be described more fully with reference to the accompanying drawings. However, other embodiments are also included within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0111] Specific embodiments herein are described with respect to NR-DC, but can also be generalized to multi-radio dual connectivity (MR-DC) or connection options with more than two SN nodes.

[0112] Specific embodiments are applicable to multi-radio dual connectivity, where the radio access network (RAN) nodes involved are related to the same radio access technology (RAT) or different RATs.

[0113] Specific embodiments are described for the scenario where both nodes serving the UE in NR-DC carry the application session, but some embodiments are equally applicable to the case where only one of the MN and SN carries the session.

[0114] The terms "application layer measurement configuration", "application measurement configuration", "RVQoE measurement configuration", "RVQoE configuration", "RVQoE measurement and reporting configuration", and "QMC configuration" are used interchangeably. Note that "QMC profile" is not an equivalent term, but rather refers to a part of the SN configuration that includes an XML file containing instructions for the SN metrics to be collected.

[0115] A network node can be a RAN node, gNB, eNB, en-gNB, ng-eNB, gNB-CU, gNB-CU-CP, gNB-CU-UP, eNB-CU, eNB-CU-CP, eNB-CU-UP, integrated access and backhaul (IAB) node, IAB donor DU, IAB donor CU, IAB-DU, IAB-MT, O-CU, O-CU-CP, O-CU-UP, O-DU, O-RU, O-eNB, non-real-time RAN intelligent controller (non-RTRIC), real-time RAN intelligent control (RT-RIC), operation and management (OAM) node, core network node / function, cloud-based network function, and / or cloud-based centralized training node.

[0116] All references to the application layer are to the UE's application layer (RAN nodes do not have an application layer).

[0117] The term "service" is often used as an abbreviation for "service type", so "service" and "service type" are used interchangeably unless otherwise clearly stated.

[0118] Certain embodiments apply to both signaling-based RVQoE measurement and management-based RVQoE measurement (but can also optionally be limited to only apply to one of them).

[0119] The terms "RVQoE report" and "RVQoE measurement report" are used interchangeably.

[0120] When referring to the UE, the terms "access layer" and "radio layer" are used interchangeably.

[0121] The term "session" refers to the application session for which RVQoE measurement is applied.

[0122] Certain embodiments apply to Universal Mobile Telecommunications Service (UMTS), Long-Term Evolution (LTE), and NR, as well as future RATs, such as Sixth Generation (6G).

[0123] Certain embodiments are described for signaling-based RVQoE measurement, but these embodiments apply equally to both management-based RVQoE measurement and signaling-based RVQoE measurement.

[0124] When referring to the RAN performing a specific action, this may mean that the MN, or the SN, or both the MN and the SN, or one of them performs the action after coordinating with the other.

[0125] The expression "two nodes" refers to the MN and the SN. The MN and the SN may refer to the master cell group (MCG) and the secondary cell group (SCG).

[0126] Specific embodiments are described in a step - by - step manner, in the following order, which may not be strictly followed in some cases, i.e., repetition or skipping of some steps may be possible:

[0127] · RVQoE configuration assembly,

[0128] · Delivery of the configuration to the UE,

[0129] · Determine whether both the MN and the SN carry the session,

[0130] · Take actions based on the fact that both nodes carry the session or only one node carries the session, and

[0131] · Report RVQoE measurements.

[0132] Some embodiments include configuring the UE using RVQoE measurements. It is assumed that it is not known in advance whether the MN, the SN, or both the MN and the SN will carry the application session, so it is not clear how to meet the above requirements 1 and 2.

[0133] In some embodiments, despite this uncertainty, the RAN (MN, SN, or both) still assembles two RVQoE configurations (one for each node), or a combined configuration (to which both the MN and the SN contribute), and sends the combined configuration to the UE.

[0134] In some embodiments, the RAN waits to configure the UE until it determines which node(s) carry the session. Optionally, the RAN can use application layer measurements to configure the UE, but later perform a re - configuration to indicate which node carries the session. This has the advantage that it may not be necessary to support re - configuration of the QoE / RVQoE configuration at the application layer during an ongoing application layer session, because the information about which node the report should be sent to may only affect the UE access stratum (AS) layer, and the UE AS layer can be re - configured at any time.

[0135] Some embodiments include determining whether both the MN and the SN carry the application session, or whether both the MN and the SN can carry the application session. Note that some of the methods herein are applicable to scenarios where the session is carried via two nodes, as well as scenarios where the session is carried by only one of the two nodes.

[0136] If a measurement session is mapped to more than one data radio bearer (DRB), the session can be carried via two RAN nodes. Optionally, the measurement session can be mapped to one DRB, and the DRB is configured as a split bearer where data is sent to / from both the MN and the SN. Alternatively optionally, the DRB can be configured as a duplicate bearer where both the MN and the SN carry the same data to / from the UE.

[0137] To be able to meet Requirements 1 and 2, it is necessary to determine which node(s) carry the session. In some embodiments, determining which nodes carry the session can be determined after the session starts, the measurements have been configured, and the measurements have started.

[0138] In some embodiments, determining which nodes carry the session can be determined before the application session starts.

[0139] In some embodiments, determining which nodes carry the session can be determined after the session starts but before the measurements are configured.

[0140] In some embodiments, determining which nodes carry the session can be determined after the session starts, after the application layer measurements have been configured, but before the reporting configuration is configured.

[0141] In some embodiments, determining which nodes carry the session can be determined after the session starts, after the application layer measurements (and reporting) have been configured, but before the first RVQoE report is sent, so as to give the network time to reconfigure the RVQoE report to go to the desired node (unless this has been correctly configured) before the first RVQoE report is sent, and thus send all RVQoE reports (even the first RVQoE report) to the desired node.

[0142] In some embodiments, determining which nodes carry the session can be determined at the start of the session after the RVQoE configuration has been sent to the UE and before the first RVQoE containing RVQoE measurements arrives at the RAN node.

[0143] In some embodiments, determining which nodes carry the session can be determined through communication / coordination between different functions / entities of a specific RAN node, where one entity / function receives user plane data and another entity / function receives control plane data.

[0144] In some embodiments, determining which nodes carry the session is determined based on the service type and / or configuration parameters sent to the RAN node, before the session starts or during the transmission of data for the session.

[0145] In some embodiments, determining which nodes carry a session may be determined after the following operations: the session starts, measurements have been configured, start, and one or more first RVQoE reports are sent to the respective nodes (each node that generates the RVQoE configuration) in order to optimize how the application session should be delivered (via two nodes or only one node) subsequently / after immediate RVQoE report analysis and to adjust the RVQoE configuration and reporting conditions.

[0146] In some embodiments, determining which nodes carry a session may be done periodically / iteratively, assuming the session is in progress, and after RVQoE reports are received (after each report or less frequently, or for event-triggered RVQoE reports after the event that triggers the report), because the SN may be activated / deactivated by the network periodically, how the session is carried (i.e., via one node or two nodes) may change over time.

[0147] The determination of whether both nodes carry the session can be implemented according to the following method.

[0148] The application may (via the UE AS) indicate, together with the session start indication, which network socket parameters it uses (e.g., transport layer protocol (e.g., Transmission Control Protocol (TCP), Stream Control Transmission Protocol (SCTP), Real-Time Protocol (RTP)) and transport layer protocol source and destination port numbers, and potentially also source and / or destination Internet Protocol (IP) addresses), and then the RAN determines which DRB maps to the data flow to the DRB mapping configuration / filter. Optionally, the UE AS converts the socket parameters to a DRB ID (based on the data flow to the DRB mapping configuration / filter) and sends the DRB ID together with the session start indication to the RAN.

[0149] With this method, when the network has the opportunity to react, the session has already started, but assuming there is still some time until the first RVQoE report is sent, if needed, before the first RVQoE report is sent, by reconfiguring the RVQoE reporting mechanism (e.g., via RVQoE (re)configuration and / or Signaling Radio Bearer SRB (re)configuration), the network may even be able to correctly process the first RVQoE report.

[0150] A variant is that after the session starts, the application immediately sends an initial RVQoE report, including the network socket parameters (possibly converted to a DRB ID by the UE AS).

[0151] Another variant is that, in response to receiving the RVQoE configuration, the application returns socket parameters, which the UE AS forwards to the network (e.g., in a MeasurementReportAppLayer RRC message or a new RRC message), or converts them into DRB IDs that it sends to the network. After receiving this information in response to sending the RVQoE configuration to the UE, if the information appears in the form of network socket parameters, the RAN can determine, based on the configured data flow to DRB mapping filter, which DRB(s) will carry the data flow(s) of the application during subsequent application sessions. When the RAN has identified the relevant DRB, whether derived from the socket parameters by the RAN itself or received explicitly from the UE AS, if it is considered necessary or desirable, the RAN can reconfigure the RVQoE reporting mechanism (e.g., via RVQoE (re)configuration and / or SRB (re)configuration). When the session subsequently starts for the relevant application and the configured RVQoE measurements start accordingly, the RVQoE report will be sent to the required nodes according to the RVQoE configuration and / or SRB configuration. Note that this method does not rely on a session start indication being sent at the start of the application session and the associated QoE / RVQoE measurement session. Such a session start indication may or may not be sent (as configured in the AppLayerMeasConfig-r17 IE sent to the UE).

[0152] This method means that the network is already prepared before the session event starts (unless the session event is already in progress when the RVQoE configuration is sent to the UE), so the RAN can ensure that the RVQoE report will be sent to the required nodes during subsequent application sessions.

[0153] In one option, the network uses this information to reconfigure for the UE the information about which node(s) the report should be sent to.

[0154] Another way is that the network is configured with the transport protocol port numbers known to be used by various applications. This can be a pre-configured application table (e.g., represented by service type and / or application identifier) and the associated transport layer protocol port numbers. Optionally, or as a supplement (possibly supplementing or overriding the information in the pre-configured table), the OAM system can send this information (i.e., the transport layer protocol port numbers expected to be used by the application) to the RAN directly or via the core network together with the QoE configuration.

[0155] Another approach is for the RAN nodes to examine the packet headers of the data streams they carry to see which socket / header parameters (in particular, transport protocol port numbers) are being used in the data streams. By comparing this with the previously obtained information on the application's use of socket parameters (in particular, transport protocol port numbers), the RAN can in this way identify which DRBs and / or which DC connection leg(s) carry the application session data stream. Any of the aforementioned ways in which the RAN can obtain information on the application's use of socket parameters can be used in conjunction with this method (e.g., information sent by the application in the UE, or a pre-configured application / service type to port number mapping, or information on port numbers and QoE configuration conveyed from the OAM system).

[0156] In some embodiments, the RVQoE configuration sent by the RAN node to the UE may include a DRB ID or a list of DRB IDs that the RAN node assigns to the UE AS for sending / receiving data related to a session of an application for a particular service type, or related to a session of an application mapped to a particular 5G QoS indicator (5QI) or to a particular QoS flow identifier. To assist the UE AS in identifying that a data stream originates from or terminates at a particular application (or an application of a particular service type), the application may notify the UE AS of the network socket parameters of an upcoming or newly started data stream.

[0157] In some embodiments, as part of the RVQoE configuration, the RAN node may request that the UE send a first "virtual" RVQoE report (i.e., not containing actual RVQoE measurements) at the start of a session (i.e., before the end of the first reporting period in the case of periodic reporting of RVQoE measurements) for use by the RAN node to determine whether it is being used to carry the session. After receiving this instruction in the RVQoE configuration and after the start (or resumption) of a session for an application, the UE application layer will send a virtual RVQoE report that contains only an indication of the start of the session and / or contains another indication (which is intended to assist the RAN node in determining whether it is carrying data for the session of the application). The UE AS may supplement this RVQoE report with an indication set by the DRB ID and use it for sending / receiving data for the just-started session of the application.

[0158] In another variant, one way to make RAN nodes aware of the type of traffic they are carrying (e.g., video, audio) is to exchange information between the user plane and the control plane about how the traffic is split between the tributaries. The above can be conveyed by the user plane function, which can determine the mapping of different flows within an application to different nodes based on available capacity, capabilities, etc., based on deep packet inspection or by leveraging explicit information about socket parameters. For a RAN node in a split architecture (e.g., a gNB implemented as a gNB-CU-CP, one or more gNB-CU-UPs, and one or more gNB-DUs), the gNB-CU-CP (the gNB-CU-CP at the MN, but it can also be at the SN) configures the UE for RVQoE measurement and sends an indication to the gNB-CU-UP of the same RAN node (or one of the gNB-CU-UPs) to inform the gNB-CU-UP that the RVQoE configuration has been sent or is about to be sent to the UE. The idea is to make the gNB-CU-CP aware of the fact that the RAN node it belongs to is the RAN node that carries the session via the gNB-CU-UP. After the indication about the fact that the UE has been configured for RVQoE has reached the gNB-CU-UP, when the gNB-CU-UP receives the data carried for the UE via a DRB, it can inform the gNB-CU-CP that the RAN node to which both the gNB-CU-CP and the gNB-CU-UP belong is carrying the session for the application of the UE. The gNB-CU-CP of the RAN node under discussion (e.g., the MN) notifies, via XnAP, another RAN node included in the NR-DC operation that the sender RAN node (itself) is participating in the transmission of the data of the session for the application of the UE. The receiving RAN node goes through the same process as just described. By exchanging this mutual information, each RAN node knows whether both the MN and the SN are being used to carry the session for the application of the UE, or whether only one of the MN or the SN is being used to carry the session for the application of the UE.

[0159] The described process can rely on the previously described methods (e.g., using socket or header parameters).

[0160] In some embodiments, the gNB-CU-UP can be replaced by the gNB-DU (or one of the gNB-DUs served by the gNB-CU-CP in the RAN node).

[0161] In some embodiments, a RAN node may determine, based on QoE / RVQoE configuration parameters such as service type and optionally based on other configuration parameters received by OAM, that it will carry all sessions for an application related to that service type, or that it is capable of carrying sessions for an application related to that service type, or that it cannot carry sessions for an application related to that service type, or that sessions for an application related to that service type will be carried by another RAN node (e.g., the SN determines that the MN will carry data for that application). An example is the service type "MTSI" for which the MN node determines / is configured such that all sessions for applications related to service type = MTSI will be carried by itself, or conversely, they will be carried by the SN node.

[0162] In another option, before or during the sending / receiving of data for a session of an application related to a specific service type, the RAN node may determine that it can no longer carry data for that service type (or for sessions of an application related to a specific service type) and notify another RAN node of this. This may occur, for example, when configuration parameters are sent (e.g., from OAM) to the RAN node, which changes the current way of handling sessions of applications for a specific service type.

[0163] In another option, the network determines the node carrying the session and uses this information to indicate to the UE to which nodes to send reports. After RVQoE measurements have been configured, the UE may be configured with this information since the reporting configuration may only reside in the RRC while the measurements occur at the application layer.

[0164] In another option, depending on the coverage scenario, the network may indicate which node the session should use and may indicate to the UE to which nodes to send reports under different measurement reference signal conditions.

[0165] In another option, the network may specify that reports related to periodic reporting may be sent to one node while reports related to event-triggered reporting are sent to another node.

[0166] In any of the above cases of coordination or obtaining further information on which branch is carrying information, it should be assumed that by default, once the SCG is activated, both the SCG and MCG nodes carry application sessions.

[0167] Some embodiments include RAN actions after determining which node(s) carry the session. When one of the RAN nodes (according to the above method or in some other way) learns that the session is being carried or will be carried by two nodes, or that the session potentially can be carried by two nodes, the RAN node may take actions based on this knowledge.

[0168] The RAN node (MN, SN, or one of them after coordinating with the other) may decide to avoid having the session carried by two nodes. There may be several motivations for this, one of which is the difficulty in distinguishing which part of the RVQoE report is related to which node (since the report is generated at the UE application layer and it involves all the legs carrying the session), and to avoid additional resource allocation at the second node to carry a small amount of traffic.

[0169] If the "awareness" occurs after the measurement starts, the RAN node may take actions to prevent the session from being carried by two nodes, such as reconfiguring the DRB so that all DRBs for the session are carried by the same node.

[0170] Otherwise, if it is acceptable to carry the session via two nodes, the RAN node (MN or SN):

[0171] · Merges the RVQoE configuration generated by the MN and the RVQoE configuration generated by the SN.

[0172] · Sends the two RVQoE configurations to the UE and instructs the UE to merge them and perform RVQoE measurements according to the merged configuration.

[0173] · Sends the two RVQoE configurations to the UE, and the corresponding node configures the UE with the corresponding configuration. In this case, if the SRB required for each node to accept the sent report is configured for reporting, the RVQoE measurement report is sent to the corresponding node.

[0174] The RAN may reconfigure the RVQoE reporting mechanism (e.g., (re)configuring what is involved in the RVQoE configuration or (re)configuring the SRB for RVQoE reporting) so that the RVQoE report finally reaches the desired node. When both nodes are involved in carrying the session, this may mean that both nodes should receive the RVQoE report directly from the UE (i.e., the UE duplicates the RVQoE report and sends one copy to the MN and one copy to the SN), or use reporting to one of the nodes (e.g., MN) which forwards a copy of the RVQoE report to the other node (e.g., SN) to receive the RVQoE report.

[0175] Some embodiments include RVQoE measurement reports when both nodes carry or are certain to carry a session. If the session is to be carried via two RAN nodes, for example, if the session is mapped to more than one DRB, and unless the RAN nodes prevent it by reconfiguration, the UE should be indicated whether the RVQoE report is to be delivered to both nodes or only to one of the nodes (which will then forward the report to the other node). In some cases, duplication is used to carry the data for the session to the UE, where both the MN and the SN carry the same data to the UE. In some cases, split bearers are used, where both the MN and the SN carry data for the same DRB, but some data is carried via the MN and some data is carried via the SN. In all these cases involving two RAN nodes, the UE can be (implicitly or explicitly) instructed to send the QoE report and / or the RVQoE report to both nodes or only to one of the nodes.

[0176] This instruction can be sent together with the RVQoE configuration. This instruction can be sent as a reconfiguration of a previously configured RVQoE configuration. This instruction can be sent implicitly with respect to the SRB configured for the UE. The instruction can involve any combination of the above, and in addition, includes the configuration or reconfiguration of the SRB for the RVQoE report (e.g., SRB4, SRB3, and / or SRB5).

[0177] In some scenarios, the bearer reconfiguration causes a session that was previously carried by one of the RAN nodes to be carried by two RAN nodes from now on. In this case, the UE can be explicitly or implicitly instructed where to send the report, for example:

[0178] · From now on, send the report to the SN or the MN.

[0179] · Continue to report to the node that has received the report so far (e.g., the MN or the SN).

[0180] · From now on, send the report to both the MN and the SN.

[0181] There may be a situation where both the MN and the SN nodes can configure the UE for RVQoE measurement. However, the SN does not support SRB5 (or any other SRB designated to carry the RVQoE report from the UE to the SN). Therefore, the reports related to the RVQoE configurations generated by both the MN and the SN are sent to the MN. In this case, an indication related to which configuration / report originated from which node should be included in the RVQoE report. This can be used in cases where the MN would want or is requested by the SN to forward the report associated with the SN QoE configuration.

[0182] Some embodiments include differentiating which part of the RVQoE report pertains to which node. Another issue stems from the fact that the UE application layer generates the RVQoE report, and each report pertains to the entire data stream of the session (as opposed to, for example, just one of the bearers). If the session is carried by two nodes, it is unclear which part of the RVQoE report relates to which of the two RAN nodes serving the UE.

[0183] Generally, if both RAN nodes carry the session, some of the data streams that make up the session are carried by one RAN node and some by the other. For example, assume the session includes data stream 1 (e.g., video for a streaming session) carried by one RAN node and data stream 2 (e.g., audio for a streaming session) carried by the other RAN node (this can be generalized to any number of data streams that make up an application session). In this case, the reports can be organized as follows: send the report related to data stream 1 to the RAN node carrying data stream 1, send the report related to data stream 2 to the RAN node carrying data stream 2, or send the report for both data streams to one of the RAN nodes.

[0184] In cases where a clear separation between the traffic carried by each node and how that traffic maps to the application is not possible (either due to the application (where multiple component streams are extracted without a clear separation within the container) or because the user plane function cannot map different sub-streams to different nodes on a one-to-one basis (e.g., in the case of split bearers)), the RAN cannot benefit in this case by configuring customized RVQoE reports (i.e., separately on the MN or SN for the different data streams they may carry), or even by instructing the UE to report the RVQoE corresponding to a specific data stream to one RAN node.

[0185] In the above cases, the RAN can only configure to report the RVQoE to one or two nodes (which should include all components of the application). When both nodes can participate in the configuration, the report is not specific to one node.

[0186] When it is not possible to customize the RVQoE report separately for different nodes based on the traffic they may carry, a single RVQoE report indicating the overall QoE of the session (or a report mirrored to both the MN and SN) should be used.

[0187] When carrying application session data flows by splitting DRBs (or multiple split DRBs), and thus going through two DC connection legs, the result is that neither the MN nor the SN can independently control the adaptation of the processing of the application session data flows, such as scheduling priority adaptation. This means that coordination between the MN and the SN to optimize the adaptation triggered by the RVQoE report is beneficial.

[0188] One way to coordinate is for the MN to determine which of the MN and the SN should adapt its processing of the application session data flow (e.g., the processing of the relevant DRB), and optionally how the processing should be adapted. If the MN decides that the SN should perform the adaptation, the MN can indicate the SN accordingly. If the MN decides to perform all the adaptations itself, it optionally does not have to notify the SN.

[0189] In a variant of the above method, the MN sets goals for the adaptation (at least one or more goals for the SN's adaptation), e.g., the transmission resources allocated (by scheduling) to the relevant application session data flow (e.g., allocated to the relevant DRB) should increase or decrease by a certain percentage. Another type of adaptation goal can be a goal related to how long the SN can wait until it responds to a scheduling request from the UE, and / or a goal related to how long the SN can wait until it responds to a buffer status report from the UE (where the logical channel group of the relevant DRB is included in the buffer status report).

[0190] Further coordination actions between the MN and the SN can aim to ensure that: the change in QoS parameters (or the actions implemented as a result of the RVQoE report) is proportional to the amount of data carried by each node, or the two nodes communicate about the net change in QoS parameters, such as priority, the allocated uplink / downlink budget, etc., and the change is split between the two nodes depending on the available capacity in each node.

[0191] Figure 6Shows an example of a communication system 100 according to some embodiments. In this example, the communication system 100 includes a telecommunications network 102, which includes an access network 104 (such as a radio access network (RAN)) and a core network 106 (which includes one or more core network nodes 108). The access network 104 includes one or more access network nodes, such as network nodes 110a and 110b (one or more of which may generally be referred to as network node 110), or any other similar 3rd Generation Partnership Project (3GPP) access node or non-3GPP access point. The network node 110 facilitates the direct or indirect connection of user equipment (UE), for example, by connecting UEs 112a, 112b, 112c, and 112d (one or more of which may generally be referred to as UE 112) to the core network 106 over one or more wireless connections.

[0192] Example wireless communications over a wireless connection include sending and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information without using wires, cables, or other material conductors. Additionally, in different embodiments, the communication system 100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that can facilitate or participate in the communication of data and / or signals, whether over a wired connection or a wireless connection. The communication system 100 may include and / or interface with any type of communication, telecommunications, data, cellular, radio network, and / or other similar types of systems.

[0193] The UE 112 can be any of a variety of communication devices, including wireless devices that are arranged, configured, and / or operable to communicate wirelessly with the network node 110 and other communication devices. Similarly, the network node 110 is arranged, capable, configured, and / or operable to communicate directly or indirectly with the UE 112 and / or with other network nodes or devices in the telecommunications network 102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as management in the telecommunications network 102.

[0194] In the depicted example, the core network 106 connects the network node 110 to one or more hosts, such as host 116. These connections can be direct or can be indirect via one or more intermediate networks or devices. In other examples, the network node can be directly coupled to the host. The core network 106 includes one or more core network nodes (e.g., core network node 108) constructed with hardware and software components. The features of these components can be substantially similar to those described with respect to the UE, network node, and / or host, such that the description generally applies to the corresponding components of the core network node 108. Example core network nodes include the functions of one or more of a mobile switching center (MSC), a mobility management entity (MME), a home subscriber server (HSS), an access and mobility management function (AMF), a session management function (SMF), an authentication server function (AUSF), a subscription identifier de-hiding function (SIDF), a unified data management (UDM), a security edge protection proxy (SEPP), a network exposure function (NEF), and / or a user plane function (UPF).

[0195] Host 116 can be owned or controlled by a service provider other than the operator or provider of the telecommunication network 102 and / or the access network 104, and can be operated by or on behalf of the service provider. Host 116 can host various applications to provide one or more services. Examples of such applications include real-time and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various environmental conditions detected by multiple UEs, analysis functions, social media, functions for controlling or otherwise interacting with remote devices, functions for alarm and monitoring centers, or any other such functions implemented by a server.

[0196] Generally speaking, Figure 6 the communication system 100 enables connections between the UE, network node, and host. In this sense, the communication system can be configured to operate according to predefined rules or procedures, such as specific standards, including but not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE) and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standards (e.g., 6G); Wireless Local Area Network (WLAN) standards such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standards, such as Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC), ZigBee, LiFi, and / or any Low Power Wide Area Network (LPWAN) standards such as LoRa and Sigfox.

[0197] In some examples, the telecommunications network 102 is a cellular network implementing 3GPP standardized features. Thus, the telecommunications network 102 can support network slicing to provide different logical networks to different devices connected to the telecommunications network 102. For example, the telecommunications network 102 can provide ultra-reliable low-latency communication (URLLC) services to some UEs, while providing enhanced mobile broadband (eMBB) services to other UEs, and / or providing massive machine type communication (mMTC) / massive IoT services to yet other UEs.

[0198] In some examples, the UE 112 is configured to send and / or receive information without direct human interaction. For example, the UE can be designed to send information to the access network 104 according to a predetermined schedule when triggered by an internal or external event or in response to a request from the access network 104. In addition, the UE can be configured to operate in a single RAT or multi-RAT or multi-standard mode. For example, the UE can operate with any one or a combination of WiFi, NR (New Radio), and LTE, i.e., be configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) New Radio-dual connectivity (EN-DC).

[0199] In this example, the hub 114 communicates with the access network 104 to facilitate indirect communication between one or more UEs (e.g., UE112c and / or 112d) and a network node (e.g., network node 110b). In some examples, the hub 114 can be a controller, router, content source and analyzer, or any other communication device described herein with respect to the UE. For example, the hub 114 can be a broadband router enabling the UE to access the core network 106. As another example, the hub 114 can be a controller that sends commands or instructions to one or more actuators in the UE. The commands or instructions can be received from the UE, network node 110, or through executable code, scripts, processes, or other instructions in the hub 114. As another example, the hub 114 can be a data collector acting as a temporary memory for UE data and, in some embodiments, can perform analysis or other processing of the data. As another example, the hub 114 can be a content source. For example, for a UE that is a VR headset, display, speaker, or other media delivery device, the hub 114 can retrieve VR assets, videos, audio, or other media or data related to sensory information via the network node and then directly provide it to the UE, provide it to the UE after performing local processing, and / or provide it to the UE after adding additional local content. In another example, the hub 114 acts as a proxy server or orchestrator for the UE, especially in the case where one or more UEs are low-energy IoT devices.

[0200] The hub 114 may have a constant / persistent or intermittent connection to the network node 110b. The hub 114 may also allow different communication schemes and / or scheduling between the hub 114 and the UEs (such as UEs 112c and / or 112d) and between the hub 114 and the core network 106. In other examples, the hub 114 is connected to the core network 106 and / or one or more UEs via a wired connection. Additionally, the hub 114 may be configured to connect to an M2M service provider via the access network 104 and / or to another UE via a direct connection. In some scenarios, a UE may establish a wireless connection with the network node 110 while still being connected via the hub 114 by a wired or wireless connection. In some embodiments, the hub 114 may be a dedicated hub, that is, a hub whose main function is to route communications from the network node 110b to the UEs or from the UEs to the network node 110b. In other embodiments, the hub 114 may be a non-dedicated hub, that is, a device capable of operating to route communications between the UEs and the network node 110b, but which is also capable of operating as a communication origin and / or destination for a specific data channel.

[0201] Figure 7 A UE 200 according to some embodiments is shown. As used herein, a UE refers to a device capable of, configured to, arranged to, and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of UEs include, but are not limited to: smart phones, mobile phones, cellular phones, IP-based voice (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, gaming consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablet computers, laptop computers, laptop embedded devices (LEEs), laptop mounted devices (LMEs), smart devices, wireless customer premise equipment (CPEs), in-vehicle or wireless devices embedded / integrated into vehicles, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including narrowband Internet of Things (NB-IoT) UEs, machine type communication (MTC) UEs, and / or enhanced MTC (eMTC) UEs.

[0202] A UE may support device-to-device (D2D) communication, such as by implementing 3GPP standards for sidelink communication, dedicated short range communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, a UE may not have a user in the sense of a human user who owns and / or operates the associated device. Instead, a UE may represent a device that is intended to be sold to or operated by a human user but may not be associated with a particular human user (e.g., a smart sprinkler controller), or may not be associated initially. Optionally, a UE may represent a device that is not intended to be sold to or operated by an end user but may be associated with or operate for the benefit of a user (e.g., a smart meter).

[0203] UE 200 includes processing circuitry 202 that is operably coupled via a bus 204 to an input / output interface 206, a power supply 208, a memory 210, a communication interface 212, and / or any other components, or any combination thereof. Some UEs may utilize Figure 7 all of the components or a subset of the components shown. The level of integration between components may vary depending on the UE. Additionally, some UEs may include multiple instances of components, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0204] The processing circuitry 202 is configured to process instructions and data and may be configured to implement any sequential state machine that is operable to execute instructions stored as a machine-readable computer program in the memory 210. The processing circuitry 202 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.); programmable logic and appropriate firmware; one or more stored computer programs, a general purpose processor, such as a microprocessor or a digital signal processor (DSP), and appropriate software; or any combination of the above. For example, the processing circuitry 202 may include multiple central processing units (CPUs).

[0205] In this example, the input / output interface 206 can be configured to provide one or more interfaces to an input device, an output device, or one or more input and / or output devices. Examples of output devices include speakers, sound cards, video cards, displays, monitors, printers, actuators, transmitters, smart cards, another output device, or any combination thereof. Input devices can allow a user to capture information into the UE 200. Examples of input devices include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital video cameras, webcams, etc.), microphones, sensors, mice, trackballs, direction pads, trackpads, rollers, smart cards, etc. A presence-sensitive display can include a capacitive or resistive touch sensor to sense input from a user. Sensors can be, for example, accelerometers, gyroscopes, tilt sensors, force sensors, magnetometers, optical sensors, proximity sensors, biometric sensors, etc., or any combination thereof. Output devices can use the same type of interface port as input devices. For example, a Universal Serial Bus (USB) port can be used to provide both input and output devices.

[0206] In some embodiments, the power supply 208 is configured as a battery or battery pack. Other types of power supplies can be used, such as an external power supply (e.g., a power outlet), a photovoltaic device, or a battery. The power supply 208 can also include a power circuit for delivering power from the power supply 208 itself and / or an external power supply to various components of the UE 200 through an input circuit or an interface such as a power cable. For example, the delivered power can be used to charge the power supply 208. The power circuit can perform any formatting, conversion, or other modification on the power from the power supply 208 to make the power suitable for the corresponding components of the UE 200 that are to be powered.

[0207] The memory 210 can be or be configured to include memories such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, etc. In one example, the memory 210 includes one or more applications 214, such as an operating system, a web browser application, widgets, a gadget engine, or other applications, and corresponding data 216. The memory 210 can store any one or a combination of various different operating systems for use by the UE 200.

[0208] The memory 210 may be configured to include a plurality of physical drive units, such as Redundant Array of Independent Disks (RAID), flash memory, USB flash drives, external hard disk drives, thumb drives, pen drives, key drives, High-Definition Digital Versatile Disc (HD-DVD) disc drives, internal hard disk drives, Blu-ray disc drives, Holographic Digital Data Storage (HDDS) disc drives, external Mini Dual In-line Memory Modules (DIMMs), Synchronous Dynamic Random Access Memory (SDRAM), external micro DIMM SDRAM, smart card memories, such as tamper-resistant modules in the form of Universal Integrated Circuit Cards (UICCs), including one or more Subscriber Identity Modules (SIMs), such as USIMs and / or ISIMs, other memories, or any combination thereof. The UICC may be, for example, an Embedded UICC (eUICC), an Integrated UICC (iUICC), or a removable UICC commonly referred to as a “SIM card”. The memory 210 may allow the UE 200 to access instructions, applications, etc. stored on a transient or non-transient storage medium to offload data or upload data. An article of manufacture (e.g., an article of manufacture using a communication system) may be tangibly embodied as or in the memory 210, and the memory 210 may be a device-readable storage medium or include a device-readable storage medium.

[0209] The processing circuitry 202 may be configured to communicate with an access network or other network using the communication interface 212. The communication interface 212 may include one or more communication subsystems and may include or be communicatively coupled to an antenna 222. The communication interface 212 may include one or more transceivers for communication, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or network node in an access network). Each transceiver may include a transmitter 218 and / or a receiver 220 adapted to provide network communication (e.g., optical, electrical, frequency allocation, etc.). Additionally, the transmitter 218 and the receiver 220 may be coupled to one or more antennas (e.g., antenna 222) and may share circuit components, software, or firmware, or alternatively may be implemented separately.

[0210] In the illustrated embodiment, the communication functions of the communication interface 212 can include cellular communication, WiFi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication (such as Bluetooth), near-field communication, location-based communication (such as using the Global Positioning System (GPS) to determine location), another similar communication function, or any combination thereof. The communication can be implemented according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, Transmission Control Protocol / Internet Protocol (TCP / IP), Synchronous Optical Network (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), etc.

[0211] Regardless of the type of sensor, the UE can provide an output of the data captured by its sensors via a wireless connection to a network node through its communication interface 212. The data captured by the sensors of the UE can be transmitted to the network node via another UE through the wireless connection. The output can be periodic (e.g., every 15 minutes if it reports the sensed temperature), random (e.g., to balance the load of reports from several sensors), in response to a trigger event (e.g., an alarm is sent when humidity is detected), in response to a request (e.g., a user-initiated request), or a continuous stream (e.g., a real-time video feed of a patient).

[0212] As another example, the UE includes an actuator, an engine, or a switch associated with the communication interface, which is configured to receive a wireless input from a network node via a wireless connection. In response to the received wireless input, the state of the actuator, the engine, or the switch can change. For example, the UE can include an engine that adjusts the control surfaces or rotors of a drone in flight according to the received input, or adjusts a robotic arm performing a medical procedure according to the received input.

[0213] When the UE is in the form of an Internet of Things (IoT) device, it can be a device for one or more application areas, including but not limited to urban wearable technologies, extended industrial applications, and healthcare. Non-limiting examples of such IoT devices are the following devices or devices embedded in the following: connected refrigerators or freezers, TVs, connected lighting devices, electricity meters, robotic vacuum cleaners, voice-controlled smart speakers, home security cameras, motion detectors, thermostats, smoke detectors, door / window sensors, flood / humidity sensors, electric door locks, connected doorbells, air conditioning systems such as heat pumps, autonomous vehicles, surveillance systems, weather monitoring devices, parking monitoring devices, electric vehicle charging stations, smartwatches, fitness trackers, head-mounted displays for augmented reality (AR) or virtual reality (VR), wearable devices for tactile or sensory augmentation, sprinklers, animal or item tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and any type of medical device, such as a heart rate monitor or a remotely controlled surgical robot. The UE in the form of an IoT device includes, in addition to other components as described for the UE 200 as shown in Figure 7 circuitry and / or software depending on the intended application of the IoT device.

[0214] As another specific example, in an IoT scenario, the UE can represent a machine or other device that implements monitoring and / or measurement and sends the results of such monitoring and / or measurement to another UE and / or network node. In this case, the UE can be an M2M device, which can be referred to as an MTC device in the 3GPP context. As a specific example, the UE can implement the 3GPP NB-IoT standard. In other scenarios, the UE can represent a vehicle, such as a car, bus, truck, ship, and airplane, or other devices capable of monitoring and / or reporting their operating status or other functions related to their operation.

[0215] In practice, any number of UEs can be used together for a single use case. For example, a first UE can be a drone or integrated in a drone and provide the speed information of the drone (obtained through a speed sensor) to a second UE that is the remote control for operating the drone. When the user implements a change from the remote control, the first UE can adjust the throttle on the drone (e.g., by controlling an actuator) to increase or decrease the speed of the drone. The first and / or second UE can also include more than one of the above functions. For example, the UE can include sensors and actuators and process the communication for both the speed sensor and the actuator.

[0216] Figure 8FIG. 300 shows a network node according to some embodiments. As used herein, a network node refers to a device capable of, configured to, arranged to, and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or devices in a telecommunication network. Examples of network nodes include, but are not limited to: access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node B, evolved Node B (eNB), and NR Node B (gNB)).

[0217] Base stations can be classified based on the amount of coverage they provide (or, in other words, their transmit power levels), and thus, depending on the amount of coverage provided, can be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station can be a relay node or a relay donor node controlling a relay. A network node can also include one or more (or all) parts of a distributed radio base station, such as a centralized digital unit and / or a remote radio unit (RRU), sometimes referred to as a remote radio head (RRH). Such a remote radio unit can be integrated with an antenna as an antenna integrated radio, or can be not integrated with an antenna. The components of a distributed radio base station can also be referred to as nodes in a distributed antenna system (DAS).

[0218] Other examples of network nodes include multi-transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) devices (such as MSR BSs), network controllers (such as radio network controllers (RNCs) or base station controllers (BSCs)), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), operation and maintenance (O&M) nodes, operation support system (OSS) nodes, self-organizing network (SON) nodes, positioning nodes (e.g., evolved serving mobile location center (E-SMLC)), and / or minimized drive test (MDT).

[0219] The network node 300 includes a processing circuit 302, a memory 304, a communication interface 306, and a power supply 308. The network node 300 may include multiple physically separated components (e.g., Node B components and RNC components, or BTS components and BSC components, etc.), and each component may have its own corresponding components. In a specific scenario where the network node 300 includes multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple Node Bs. In such a scenario, in some instances, each unique pair of Node B and RNC may be regarded as a single separate network node. In some embodiments, the network node 300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be replicated (e.g., separate memories 304 for different RATs), and some components may be reused (e.g., the same antenna 310 may be shared by different RATs). The network node 300 may also include multiple sets of various components shown for different wireless technologies (such as GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-Wave, LoRaWAN, radio frequency identification (RFID), or Bluetooth wireless technologies) to be integrated into the network node 300. These wireless technologies may be integrated into the same or different chips or a set of chips and other components within the network node 300.

[0220] The processing circuit 302 may include one or more combinations of a microprocessor, a controller, a microcontroller, a central processing unit, a digital signal processor, an application specific integrated circuit, a field programmable gate array, or any other suitable computing device, resource, or a combination of hardware, software, and / or coded logic, which is operable to provide the network node 300 functions either alone or in combination with other network node 300 components such as the memory 304.

[0221] In some embodiments, the processing circuit 302 includes a system on chip (SOC). In some embodiments, the processing circuit 302 includes one or more of a radio frequency (RF) transceiver circuit 312 and a baseband processing circuit 314. In some embodiments, the radio frequency (RF) transceiver circuit 312 and the baseband processing circuit 314 may be on separate chips (or a set of chips), boards, or units (e.g., radio units and digital units). In alternative embodiments, some or all of the RF transceiver circuit 312 and the baseband processing circuit 314 may be on the same chip or a set of chips, board, or unit.

[0222] The memory 304 may include any form of volatile or non-volatile computer-readable memory, including but not limited to persistent memory, solid-state memory, remotely installed memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (such as hard disks), removable storage media (such as flash drives, compact discs (CDs) or digital video discs (DVDs)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable storage device that stores information, data, and / or instructions that can be used by the processing circuitry 302. The memory 304 may store any suitable instructions, data, or information, including computer programs, software, applications (including one or more of logic, rules, code, tables, and / or other instructions that can be executed by the processing circuitry 302 and utilized by the network node 300). The memory 304 may be used to store any computations performed by the processing circuitry 302 and / or any data received via the communication interface 306. In some embodiments, the processing circuitry 302 and the memory 304 are integrated.

[0223] The communication interface 306 is for wired or wireless communication of signaling and / or data between the network node, the access network, and / or the UE. As shown, the communication interface 306 includes a port / terminal 316 for sending data to and receiving data from the network, for example, via a wired connection. The communication interface 306 also includes a radio front-end circuit 318, which may be coupled to the antenna 310 or, in some embodiments, is part of the antenna 310. The radio front-end circuit 318 includes a filter 320 and an amplifier 322. The radio front-end circuit 318 may be connected to the antenna 310 and the processing circuitry 302. The radio front-end circuit may be configured to condition the signals transmitted between the antenna 310 and the processing circuitry 302. The radio front-end circuit 318 may receive digital data to be transmitted via a wireless connection to other network nodes or UEs. The radio front-end circuit 318 may convert the digital data into a radio signal with appropriate channel and bandwidth parameters using a combination of the filter 320 and / or the amplifier 322. The radio signal may then be transmitted via the antenna 310. Similarly, when receiving data, the antenna 310 may collect the radio signal, which is then converted into digital data by the radio front-end circuit 318. The digital data may be passed to the processing circuitry 302. In other embodiments, the communication interface may include different components and / or different combinations of components.

[0224] In some alternative embodiments, the network node 300 does not include a separate radio front-end circuit 318. Instead, the processing circuit 302 includes the radio front-end circuit and is connected to the antenna 310. Similarly, in some embodiments, all or some of the RF transceiver circuit 312 is part of the communication interface 306. In other embodiments, the communication interface 306 includes one or more ports or terminals 316, a radio front-end circuit 318, and an RF transceiver circuit 312 that are part of a radio unit (not shown), and the communication interface 306 communicates with a baseband processing circuit 314 that is part of a digital unit (not shown).

[0225] The antenna 310 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals. The antenna 310 may be coupled to the radio front-end circuit 318 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In certain embodiments, the antenna 310 is separate from the network node 300 and may be connected to the network node 300 via an interface or port.

[0226] The antenna 310, the communication interface 306, and / or the processing circuit 302 may be configured to perform any receiving operations and / or certain acquisition operations performed by the network node as described herein. Any information, data, and / or signals may be received from a UE, another network node, and / or any other network device. Similarly, the antenna 310, the communication interface 306, and / or the processing circuit 302 may be configured to perform any transmitting operations performed by the network node as described herein. Any information, data, and / or signals may be transmitted to a UE, another network node, and / or any other network device.

[0227] The power supply 308 supplies power to the various components of the network node 300 in a form suitable for the respective components (e.g., at the voltage and current levels required for each respective component). The power supply 308 may also include or be coupled to a power management circuit to power the components of the network node 300 for performing the functions described herein. For example, the network node 300 may be connected to an external power supply (e.g., a power grid, a power outlet) via an input circuit or interface such as a cable, and the external power supply powers the power circuit of the power supply 308. As another example, the power supply 308 may include a power source in the form of a battery or battery pack connected to or integrated in the power circuit. The battery may provide backup power in the event of a failure of the external power supply.

[0228] Embodiments of the network node 300 may include Figure 8Additional components other than those shown in order to provide certain aspects of the functionality of the network node, including any functionality described herein and / or any functionality required to support the subject matter described herein. For example, network node 300 may include a user interface device to allow information to be input into network node 300 and to allow information to be output from network node 300. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions on network node 300.

[0229] Figure 9 is a block diagram of a host 400 according to various aspects described herein, and host 400 may be Figure 6 an embodiment of host 116 of. As used herein, host 400 may be or include various combinations of hardware and / or software, including stand-alone servers, blade servers, cloud-implemented servers, distributed servers, virtual machines, containers, or processing resources in a server farm. Host 400 may provide one or more services to one or more UEs.

[0230] Host 400 includes a processing circuit 402 that is operably coupled via a bus 404 to an input / output interface 406, a network interface 408, a power supply 410, and a memory 412. Other components may be included in other embodiments. The characteristics of these components may be substantially similar to those described for the devices in the previous figures (such as Figure 3 and Figure 4 ), such that their description generally applies to the corresponding components of host 400.

[0231] The memory 412 may include one or more computer programs (which include one or more host applications 414 and data 416), and the data 416 may include user data, such as data generated by the UE for the host 400 or data generated by the host 400 for the UE. Embodiments of the host 400 may utilize only a subset of the illustrated components or utilize all of the illustrated components. The host application 414 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different categories, types, or implementations of the UE (e.g., mobile phone, desktop computer, wearable display system, head-up display system). The host application 414 may also provide user authentication and authorization checks and may periodically report health status, routing, and content availability to a central node (such as a device in the core network or at the edge). Thus, the host 400 may select and / or indicate different hosts for the UE's over-the-top services. The host application 414 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[0232] Figure 10 FIG. is a block diagram showing a virtualized environment 500 in which functions implemented by some embodiments may be virtualized. In the current context, virtualization means creating a virtual version of a device or apparatus, which may include a virtualized hardware platform, storage device, and network resources. As used herein, virtualization may be applied to any device or its components described herein and relates to an implementation manner in which at least a part of the functions are implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs), and the virtual machines are implemented in one or more virtualized environments 500 hosted by one or more hardware nodes (such as hardware computing devices operating as network nodes, UEs, core network nodes, or hosts). Additionally, in embodiments where the virtual node does not require a radio connection (e.g., a core network node or a host), the node may be fully virtualized.

[0233] The application 502 (which may optionally be referred to as a software instance, virtual apparatus, network function, virtual node, virtual network function, etc.) runs in the virtualized environment Q400 to implement some of the features, functions, and / or benefits of some embodiments disclosed herein.

[0234] The hardware 504 includes processing circuitry, a memory storing instructions and / or software executable by the hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, an input / output interface, etc. The software can be executed by the processing circuitry to instantiate one or more virtualization layers 506 (also referred to as a hypervisor or a virtual machine monitor (VMM)), provide VMs 508a and 508b (one or more of which can generally be referred to as VM 508), and / or implement any functions, features, and / or benefits related to some embodiments described herein. The virtualization layer 506 can present a virtual operating platform to the VMs 508 that appears like network hardware.

[0235] The VMs 508 include virtual processing, virtual memory, virtual network or interfaces, and virtual storage, and can be run by the corresponding virtualization layer 506. Different embodiments of instances of the virtual apparatus 502 can be implemented on one or more VMs 508 and can be implemented in different ways. The virtualization of hardware is referred to as network function virtualization (NFV) in some contexts. NFV can be used to consolidate many network device types onto industry-standard high-volume server hardware, physical switches, and physical storage, which can be located in data centers and customer premise equipment.

[0236] In the context of NFV, the VMs 508 can be software implementations of physical machines that run programs as if they were executing on a physical, non-virtualized machine. Each VM 508, along with a portion of the hardware 504 that executes that VM, whether the hardware is dedicated to that VM and / or shared by that VM with other VMs, forms a separate virtual network element. Still in the context of NFV, the virtual network functions are responsible for handling specific network functions running in one or more VMs 508 on top of the hardware 504 and correspond to the applications 502.

[0237] Hardware 504 may be implemented in a stand-alone network node with general or specific components. Some functions of hardware 504 may be implemented through virtualization. Optionally, hardware 504 may be part of a larger hardware cluster (e.g., in a data center or CPE), where many hardware nodes work together and are managed by management and orchestration 510, and management and orchestration 510 oversees the lifecycle management of application 502. In some embodiments, hardware 504 is coupled to one or more radio units, each radio unit including one or more transmitters and one or more receivers that may be coupled to one or more antennas. The radio units may communicate directly with other hardware nodes through one or more appropriate network interfaces and may be used in combination with virtual components to provide radio capabilities for virtual nodes, such as radio access nodes or base stations. In some embodiments, a control system 512 may be used to provide some signaling, and control system 512 may optionally be used for communication between the hardware node and the radio unit.

[0238] Figure 11 A communication diagram is shown in which a host 602 communicates with a UE 606 via a network node 604 through a partial wireless connection according to some embodiments. Reference will now be made to Figure 11 to describe example implementations of the UE (such as Figure 6 UE 112a and / or Figure 7 UE 200), network nodes (such as Figure 6 network node 110a and / or Figure 8 network node 300), and hosts (such as Figure 6 host 116 and / or Figure 9 host 400) discussed in the foregoing paragraphs according to various embodiments.

[0239] Similar to host 400, embodiments of host 602 include hardware such as communication interfaces, processing circuitry, and memory. Host 602 also includes software that is stored in or accessible by host 602 and executable by the processing circuitry. The software includes host applications that are operable to provide services to remote users (e.g., UE 606 connected via an over-the-top (OTT) connection 650 extending between UE 606 and host 602). When providing services to remote users, the host applications may provide user data transmitted using OTT connection 650.

[0240] Network node 604 includes hardware that enables it to communicate with host 602 and UE 606. Connection 660 may be direct or through a core network (such as Figure 6a core network 106) and / or one or more other intermediate networks, such as one or more public, private, or managed networks. For example, the intermediate network can be a backbone network or the Internet.

[0241] The UE 606 includes hardware and software that are stored in or accessible by the UE 606 and executable by the processing circuitry of the UE. The software includes client applications, such as a web browser or a carrier-specific "app (application)", that are operable to provide services to human or non-human users via the UE 606 with the support of the host 602. In the host 602, the executed host application can communicate with the executed client application via the OTT connection 650 that terminates at the UE 606 and the host 602. When providing services to a user, the client application of the UE can receive request data from the host application of the host and provide user data in response to the request data. The OTT connection 650 can transport both the request data and the user data. The client application of the UE can interact with the user to generate the user data that it provides to the host application via the OTT connection 650.

[0242] The OTT connection 650 can extend via the connection 660 between the host 602 and the network node 604 and via the wireless connection 670 between the network node 604 and the UE 606 to provide a connection between the host 602 and the UE 606. The connection 660 and the wireless connection 670 over which the OTT connection 650 can be provided are drawn abstractly to show the communication between the host 602 and the UE 606 via the network node 604 without explicitly mentioning any intermediate devices and the exact routing of the messages via these devices.

[0243] As an example of sending data via the OTT connection 650, in step 608, the host 602 provides user data, which can be implemented by executing a host application. In some embodiments, the user data is associated with a specific human user interacting with the UE 606. In other embodiments, the user data is associated with the UE 606, and the UE 606 shares data with the host 602 without explicit human-machine interaction. In step 610, the host 602 initiates a transmission carrying the user data to the UE 606. The host 602 may initiate the transmission in response to a request sent by the UE 606. The request may be caused by a human-machine interaction with the UE 606 or by an operation of a client application executed on the UE 606. According to the teachings of the embodiments described throughout this disclosure, the transmission may be relayed via the network node 604. Thus, in step 612, according to the teachings of the embodiments described throughout this disclosure, the network node 604 sends the user data carried in the transmission initiated by the host 602 to the UE 606. In step 614, the UE 606 receives the user data carried in the transmission, which can be implemented by a client application executed on the UE 606, and the client application is associated with the host application executed by the host 602.

[0244] In some examples, the UE 606 executes a client application that provides user data to the host 602. The user data may be provided as a reaction or response to data received from the host 602. Thus, in step 616, the UE 606 may provide user data, which can be implemented by executing the client application. When providing the user data, the client application may also consider user input received from the user via the input / output interface of the UE 606. Regardless of the specific manner in which the user data is provided, in step 618, the UE 606 initiates a transmission of the user data to the host 602 via the network node 604. In step 620, according to the teachings of the embodiments described throughout this disclosure, the network node 604 receives the user data from the UE 606 and initiates a transmission of the received user data to the host 602. In step 622, the host 602 receives the user data carried in the transmission initiated by the UE 606.

[0245] One or more of the various embodiments improve the performance of the OTT service provided to the UE 606 using the OTT connection 650, where the wireless connection 670 forms the last hop. More precisely, the teachings of these embodiments can improve the latency of directly activating the SCell via RRC and the power consumption of the user equipment, thus providing benefits such as reduced user waiting time and extended battery life.

[0246] In an example scenario, the host 602 can collect and analyze factory status information. As another example, the host 602 can process audio and video data that may have been retrieved from a UE for map creation. As another example, the host 602 can collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, the host 602 can store surveillance videos uploaded by the UE. As another example, the host 602 can store or control access to media content, such as video, audio, VR, or AR, and can broadcast, multicast, or unicast the media content to the UE. As other examples, the host 602 can be used for energy pricing, remotely controlling non-time-critical electrical loads to balance power generation demand, location services, demonstration services (such as compiling charts based on data collected from remote devices), or any other function of collecting, retrieving, storing, analyzing, and / or sending data.

[0247] In some examples, a measurement process can be provided for monitoring data rate, latency, and other factors improved in one or more embodiments. There can also be optional network functions for reconfiguring the OTT connection 650 between the host 602 and the UE 606 in response to changes in the measurement results. The measurement process and / or network functions for reconfiguring the OTT connection can be implemented in the software and hardware of the host 602 and / or the UE 606. In some embodiments, sensors (not shown) can be deployed in or associated with other devices through which the OTT connection 650 passes; the sensors can participate in the measurement process by providing values of the monitored quantities described above or by providing values of other physical quantities from which the software can calculate or estimate the monitored quantities. The reconfiguration of the OTT connection 650 can include message formatting, retransmission settings, preferred routing, etc.; the reconfiguration does not need to directly change the operation of the network node 604. These processes and functions can be known and practiced in the art. In certain embodiments, the measurement can involve proprietary UE signaling that facilitates the host 602 in measuring throughput, propagation time, latency, etc. The measurement can be implemented in software that uses the OTT connection 650 to cause messages (specifically, empty messages or 'virtual' messages) to be sent while monitoring propagation time, errors, etc.

[0248] Figure 12 is a flowchart showing an example method in a wireless device according to certain embodiments. In a particular embodiment, Figure 12 one or more steps of can be implemented by the UE 200 described with respect to Figure 7 The wireless device operates in a dual connection with a first network node and a second network node.

[0249] The method begins at step 1212, where a wireless device (e.g., UE 200) receives an RVQoE configuration associated with an application session. In a particular embodiment, the receiving of the RVQoE configuration occurs after the application session has started, and the RVQoE configuration includes an indication, based on the protocol used for the application session, of whether the RVQoE report is towards a first network node, a second network node, or both the first network node and the second network node.

[0250] In a particular embodiment, the receiving of the RVQoE configuration occurs after the application session has started and after a first RVQoE report has been sent by the wireless device, and the RVQoE configuration includes an indication, based on the first RVQoE report, of whether the RVQoE report is towards a first network node, a second network node, or both the first network node and the second network node.

[0251] In a particular embodiment, the wireless device may receive a first RVQoE configuration before the application session starts and a updated RVQoE configuration after the application session starts.

[0252] Other and additional examples of receiving the RVQoE configuration are described with respect to the above embodiments and examples.

[0253] At step 1214, the wireless device determines whether the application session is provided through communication with both the first network node and the second network node.

[0254] In a particular embodiment, determining whether the application session is provided through communication with both the first network node and the second network node includes: receiving a reporting configuration in the RVQoE configuration that indicates whether the RVQoE report is towards a first network node, a second network node, or both the first network node and the second network node.

[0255] In a particular embodiment, determining whether the application session is provided through communication with both the first network node and the second network node is based on the association between the application session and one or more bearer channels.

[0256] Other and additional examples of determining whether the application session is provided through communication with both the first network node and the second network node are described with respect to the above embodiments and examples.

[0257] At step 1216, based on determining whether an application session is provided through communication with both the first network node and the second network node, the wireless device sends an RVQoE report for the application session. For example, the wireless device can send the RVQoE report only to the first network node, only to the second network node, or to both the first network node and the second network node. In some embodiments, the wireless device can send the RVQoE report to one network node, and that network node can forward the RVQoE report to another network node, such as the second network node.

[0258] The method 1200 can be modified, added to, or omitted. Additionally, one or more steps of Figure 12 the method can be implemented in parallel or in any suitable order. Figure 12 One or more steps of

[0259] Figure 13 is a flowchart showing an example method in a first network node according to certain embodiments. In a particular embodiment, Figure 13 one or more steps of Figure 8 can be implemented by the network node 300 described with respect to

[0260] The method begins at step 1312, where the first network node (e.g., network node 300) determines whether an application session is provided through communication with both the first network node and the second network node.

[0261] In a particular embodiment, determining whether an application session is provided through communication with both the first network node and the second network node is based on the association between the application session and one or more bearer channels.

[0262] In a particular embodiment, determining whether an application session is provided through communication with both the first network node and the second network node includes: receiving from the wireless device the association between the application session and one or more bearer channels.

[0263] In a particular embodiment, determining whether an application session is provided through communication with both the first network node and the second network node is based on the protocol used by the application session.

[0264] In a particular embodiment, determining whether an application session is provided through communication with both the first network node and the second network node occurs after a first RVQoE report has been sent by the wireless device, and the determination is based on the first RVQoE report.

[0265] In a particular embodiment, the first network node includes an MN and the second network node includes an SN, or the first network node includes an SN and the second network node includes an MN.

[0266] Additional and other examples of determining whether an application session is provided through communication with both the first network node and the second network node are described with respect to the above embodiments and examples.

[0267] In step 1314, the first network node configures the wireless device with an RVQoE configuration associated with the application session. The RVQoE configuration includes a reporting configuration that indicates whether the RVQoE report is directed to the first network node, the second network node, or both the first network node and the second network node based on whether the application session is provided through communication with both the first network node and the second network node.

[0268] In step 1316, the first network node receives an RVQoE report for the application session from the wireless device based on the reporting configuration.

[0269] In step 1318, the first network node may forward the received RVQoE report to the second network node. For example, the wireless device may be configured to send the RVQoE report only to the first network node, but the first network node determines that the second network node may also be interested in the RVQoE report and forwards the RVQoE report to the second network node.

[0270] The method 1300 of Figure 13 may be modified, added to, or omitted. In addition, one or more steps of the method of Figure 13 may be implemented in parallel or in any suitable order.

[0271] The methods disclosed herein may be modified, added to, or omitted without departing from the scope of the present invention. These methods may include more steps, fewer steps, or other steps. In addition, the steps may be implemented in any suitable order.

[0272] The foregoing specification sets forth numerous specific details. However, it should be understood that embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail in order not to obscure the understanding of this specification. A person of ordinary skill in the art will be able to utilize the included description to implement appropriate functionality without undue experimentation.

[0273] References to "one embodiment", "an embodiment", "example embodiment", etc. in the specification indicate that the described embodiments may include a particular feature, structure, or characteristic, but each embodiment may not necessarily include that particular feature, structure, or characteristic. Moreover, these phrases do not necessarily refer to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is contemplated that such feature, structure, or characteristic can be implemented in connection with other embodiments whether or not explicitly described, by those of ordinary skill in the art.

[0274] Although the present disclosure has been described in accordance with certain embodiments, changes and permutations of the embodiments will be apparent to those of ordinary skill in the art. Accordingly, the foregoing description of the embodiments does not limit the present disclosure. Other changes, substitutions, and alterations are possible without departing from the scope of the present disclosure as defined by the following claims.

[0275] The following are some example embodiments.

[0276] Group A embodiments

[0277] 1. A method implemented by a wireless device operating in a dual connection with a first network node and a second network node, the method comprising:

[0278] - receiving a radio access network visible quality of experience (RVQoE) configuration associated with an application session;

[0279] - determining whether the application session is provided through communication with both the first network node and the second network node; and

[0280] - sending an RVQoE report for the application session based on determining whether the application session is provided through communication with both the first network node and the second network node.

[0281] 2. The method according to embodiment 1, wherein determining whether the application session is provided through communication with both the first network node and the second network node is based on an association of the application session with one or more bearer channels.

[0282] 3. The method according to embodiment 1, wherein determining whether the application session is provided through communication with both the first network node and the second network node is implemented according to any one of the foregoing embodiments and examples.

[0283] 4. The method according to any one of the foregoing embodiments, wherein the RVQoE report is sent according to any embodiment and example described herein.

[0284] 5. A method implemented by a wireless device, the method comprising:

[0285] - Any one of the above wireless device steps, features or functions, either alone or in combination with the above other steps, features or functions.

[0286] 6. The method according to the foregoing embodiments, further comprising: the above one or more additional wireless device steps, features or functions.

[0287] 7. The method according to any one of the foregoing embodiments, further comprising:

[0288] - Providing user data; and

[0289] - Forwarding the user data to a host computer via transmission to a base station.

[0290] Group B embodiments

[0291] 8. A method implemented by a first base station operating in dual connectivity with a second base station, the method comprising:

[0292] - Configuring a wireless device with a radio access network visible quality of experience (RVQoE) configuration associated with an application session;

[0293] - Determining whether the application session is provided through communication with both the first base station and the second base station;

[0294] And

[0295] - Receiving an RVQoE report for the application session based on determining whether the application session is provided through communication with both the first base station and the second base station.

[0296] 9. The method according to the foregoing embodiments, further comprising: updating the RVQoE configuration for the wireless device based on determining whether the application session is provided through communication with both the first

[0297] base station and the second base station.

[0298] 10. The method according to embodiment 8, wherein determining whether the application session is provided through communication with both the first base station and the second base station is based on an association of the application session with one or more bearer channels.

[0299] 11. The method according to embodiment 1, wherein determining whether the application session is provided through communication with both the first base station and the

[0300] second base station is implemented according to any one of the above embodiments and examples.

[0301] 12. The method according to any one of the foregoing embodiments, wherein the RVQoE report is received according to any one of the embodiments and examples described herein.

[0302] 13. A method implemented by a base station, the method comprising:

[0303] - Any of the above steps, features or functions regarding the base station, either alone or in combination with the above other steps, features or functions.

[0304] 14. The method according to the foregoing embodiment, further comprising: one or more of the above additional base station steps, features or functions.

[0305] 15. The method according to any one of the foregoing embodiments, further comprising:

[0306] - Obtaining user data; and

[0307] - Forwarding the user data to a host computer or a wireless device.

[0308] Group C Embodiments

[0309] 16. A mobile terminal, comprising:

[0310] - A processing circuit configured to implement any step according to any one of the embodiments in Group A; and

[0311] - A power supply circuit configured to supply power to the wireless device.

[0312] 17. A base station, comprising:

[0313] - A processing circuit configured to implement any step according to any one of the embodiments in Group B;

[0314] - A power supply circuit configured to supply power to the wireless device.

[0315] 18. A user equipment (UE), comprising:

[0316] - An antenna configured to transmit and receive wireless signals;

[0317] - A radio front-end circuit connected to the antenna and the processing circuit and configured to condition signals transmitted between the antenna and

[0318] the processing circuit;

[0319] - The processing circuit configured to implement any step according to any one of the embodiments in Group A;

[0320] - An input interface, which is connected to the processing circuit and is configured to allow information to be input into the UE for processing by the processing circuit;

[0321] - An output interface, which is connected to the processing circuit and is configured to output from the UE the information that has been processed by the processing

[0322] circuit; and

[0323] - A battery, which is connected to the processing circuit and is configured to supply power to the UE.

[0324] 19. A communication system including a host computer, the host computer including:

[0325] - A processing circuit, which is configured to provide user data; and

[0326] - A communication interface, which is configured to forward the user data to a cellular network for transmission to a user equipment (UE),

[0327] - wherein the cellular network includes a base station having a radio interface and a processing circuit, and the processing circuit of the base station is configured to implement any step according to any one of the embodiments in Group B.

[0328] 20. The communication system according to the foregoing embodiment, further including a base station.

[0329] 21. The communication system according to the foregoing 2 embodiments, further including the UE, wherein the UE is configured to communicate with the base station.

[0330] 22. The communication system according to the foregoing 3 embodiments, wherein:

[0331] - The processing circuit of the host computer is configured to execute a host application to provide the user data; and

[0332] - The UE includes a processing circuit configured to execute a client application associated with the host application.

[0333] 23. A method implemented in a communication system including a host computer, a base station, and a user equipment (UE), the method including:

[0334] - At the host computer, providing user data; and

[0335] - At the host computer, initiating a transmission of the user data via a cellular network including the base station to the

[0336] said UE, wherein the base station implements any step according to any one of the embodiments in Group B.

[0337] 24. The method according to the foregoing embodiments further includes: at the base station, transmitting the user data.

[0338] 25. The method according to the foregoing two embodiments, wherein the user data is provided at the host computer by executing a host application, and the method further includes: at the UE, executing a client application associated with the host application.

[0339] 26. A user equipment (UE) configured to communicate with a base station, the UE including a radio interface and a processing circuit, the processing circuit being configured to implement any one of the foregoing three embodiments.

[0340] 27. A communication system including a host computer, the host computer including:

[0341] - a processing circuit configured to provide user data; and

[0342] - a communication interface configured to forward the user data to a cellular network for transmission to a user equipment (UE),

[0343] - wherein the UE includes a radio interface and a processing circuit, and the components of the UE are configured to implement any step according to any one of the embodiments in Group A.

[0344] 28. The communication system according to the foregoing embodiments, wherein the cellular network further includes a base station configured to communicate with the UE.

[0345] 29. The communication system according to the foregoing two embodiments, wherein:

[0346] - the processing circuit of the host computer is configured to execute a host application to provide the user data; and

[0347] - the processing circuit of the UE is configured to execute a client application associated with the host application.

[0348] 30. A method implemented in a communication system including a host computer, a base station, and a user equipment (UE), the method including:

[0349] - at the host computer, providing user data; and

[0350] - at the host computer, initiating a transmission of the user data via a cellular network including the base station to the

[0351] UE, wherein the UE implements any step according to any one of the embodiments in Group A.

[0352] 31. The method according to the foregoing embodiments further includes: at the UE, receiving the user data from the base station.

[0353] 32. A communication system including a host computer, the host computer including:

[0354] - A communication interface configured to receive user data sourced from a transmission from a user equipment (UE) to a base station,

[0355] - wherein the UE includes a radio interface and a processing circuit, and the processing circuit of the UE is configured to perform any step according to any one of the Group A embodiments.

[0356] 33. The communication system according to the foregoing embodiments further includes the UE.

[0357] 34. The communication system according to the foregoing two embodiments further includes the base station, wherein the base station includes a radio interface and a communication interface, the radio interface is configured to communicate with the UE, and the communication interface is configured to forward the user data carried in the transmission from the UE to the base station to the host computer.

[0358] 35. The communication system according to the foregoing three embodiments, wherein:

[0359] - The processing circuit of the host computer is configured to execute a host application; and

[0360] - The processing circuit of the UE is configured to execute a client application associated with the host application, thereby providing the user data.

[0361] 36. The communication system according to the foregoing four embodiments, wherein:

[0362] - The processing circuit of the host computer is configured to execute a host application, thereby providing request data; and

[0363] - The processing circuit of the UE is configured to execute a client application associated with the host application, thereby providing the user data in response to the request data.

[0364] 37. A method implemented in a communication system including a host computer, a base station, and a user equipment (UE), the method including:

[0365] - At the host computer, receiving user data sent from the UE to the base station, wherein the UE performs any step according to any one of the Group A embodiments.

[0366] 38. The method according to the foregoing embodiments further includes: at the UE, providing the user data to the base station.

[0367] 39. The method according to the foregoing two embodiments further includes:

[0368] - at the UE, executing a client application to provide the user data to be sent; and

[0369] - at the host computer, executing a host application associated with the client application.

[0370] 40. The method according to the foregoing three embodiments further includes:

[0371] - at the UE, executing a client application; and

[0372] - at the UE, receiving input data of the client application, the input data being provided at the host computer by executing a host application associated with the client application,

[0373] - wherein the user data to be sent is provided by the client application in response to the input data.

[0374] 41. A communication system including a host computer, the host computer including a communication interface configured to receive user data sourced from a transmission from a user equipment (UE) to a base station, wherein the base station includes a radio interface and a processing circuit, and the processing circuit of the base station is configured to implement any step according to any one of the Group B embodiments.

[0375] 42. The communication system according to the foregoing embodiments further includes the base station.

[0376] 43. The communication system according to the foregoing two embodiments further includes the UE, wherein the UE is configured to communicate with the base station.

[0377] 44. The communication system according to the foregoing three embodiments, wherein:

[0378] - the processing circuit of the host computer is configured to execute a host application;

[0379] - the UE is configured to execute a client application associated with the host application to provide the user data to be received by the host computer.

[0380] 45. A method implemented in a communication system including a host computer, a base station, and a user equipment (UE), the method including:

[0381] - At the host computer, receive user data originating from a transmission that the base station has received from the UE, where the UE implements any of the steps according to any of the Group A embodiments.

[0382] 46. The method according to the foregoing embodiments, further comprising: at the base station, receive the user data from the UE.

[0383] 47. The method according to the foregoing two embodiments, further comprising: at the base station, initiate transmission of the received user data to the host computer.

Claims

1. A method implemented by a wireless device operating in a dual connection with a first network node and a second network node, the method comprising: Receive (1212) a Radio Access Network Visible Quality of Experience (RVQoE) configuration associated with an application session; Determine (1214) whether the application session is provided via communication with both the first network node and the second network node; and Based on determining whether the application session is provided via communication with both the first network node and the second network node, send (1216) an RVQoE report for the application session.

2. The method according to claim 1, wherein, Determining whether the application session is provided via communication with both the first network node and the second network node includes: receiving a reporting configuration in the RVQoE configuration that indicates whether the RVQoE report is towards the first network node, the second network node, or both the first network node and the second network node.

3. The method according to claim 1, wherein, Determining whether the application session is provided via communication with both the first network node and the second network node includes: receiving a reporting configuration in the RVQoE configuration that indicates whether the RVQoE report is towards the first network node or the second network node.

4. The method according to claim 1, wherein, Determining whether the application session is provided via communication with both the first network node and the second network node is based on an association between the application session and one or more bearer channels.

5. The method according to claim 4, further comprising: Send the association between the application session and one or more bearer channels to one or both of the first network node and the second network node; And Receive an updated RVQoE configuration including a reporting configuration from one or both of the first network node and the second network node, the reporting configuration indicating whether the RVQoE report is towards the first network node, the second network node, or both the first network node and the second network node based on the association between the application session and one or more bearer channels.

6. The method according to claim 1, wherein, Receiving the RVQoE configuration occurs after the application session starts, and the RVQoE configuration includes an indication of whether the RVQoE report is towards the first network node, the second network node, or both the first network node and the second network node based on the protocol used by the application session.

7. The method according to claim 1, wherein, Receiving the RVQoE configuration occurs after the application session starts and after a first RVQoE report has been sent by the wireless device, and the RVQoE configuration includes an indication of whether the RVQoE report is towards the first network node, the second network node, or both the first network node and the second network node based on the first RVQoE report.

8. A computer program product comprising a non-transitory computer-readable medium storing computer-readable program code, which when executed by a processing circuit is operable to implement any of the steps according to any one of claims 1-7.

9. A wireless device (200) capable of operating in a dual connection with a first network node (300) and a second network node (200), the wireless device comprising a processing circuit (202), the processing circuit being operable to: Receive a radio access network visible quality of experience RVQoE configuration associated with an application session; Determine whether the application session is provided through communication with both the first network node and the second network node; and Based on determining whether the application session is provided through communication with both the first network node and the second network node, send an RVQoE report for the application session.

10. The wireless device according to claim 9, wherein, The processing circuitry is operable to: determine whether the application session is provided via communication with both the first network node and the second network node by receiving a reporting configuration in the RVQoE configuration that indicates whether the RVQoE report is towards the first network node, the second network node, or both the first network node and the second network node.

11. The wireless device according to claim 9, wherein, The processing circuit is operable to: determine whether the application session is provided through communication with both the first network node and the second network node by receiving a reporting configuration in the RVQoE configuration, the reporting configuration indicating whether the RVQoE report is directed towards the first network node or the second network node.

12. The wireless device according to claim 9, wherein, The processing circuit is operable to: determine whether the application session is provided through communication with both the first network node and the second network node based on an association between the application session and one or more bearer channels.

13. The wireless device according to claim 12, the processing circuit being further operable to: Send the association between the application session and one or more bearer channels to one or both of the first network node and the second network node; and Receive, from one or both of the first network node and the second network node, an updated RVQoE configuration including a reporting configuration, the reporting configuration being based on the association between the application session and one or more bearer channels and indicating whether the RVQoE report is towards the first network node, the second network node, or both the first network node and the second network node.

14. The wireless device according to claim 9, wherein, The processing circuit is operable to: receive the RVQoE configuration after the application session has started, and the RVQoE configuration includes an indication of whether the RVQoE report is directed towards the first network node, the second network node, or both the first network node and the second network node based on the protocol used by the application session.

15. The wireless device according to claim 9, wherein, The processing circuit is operable to: receive the RVQoE configuration after the application session has started and after a first RVQoE report has been sent by the wireless device, and the RVQoE configuration includes an indication of whether the RVQoE report is directed towards the first network node, the second network node, or both the first network node and the second network node based on the first RVQoE report.

16. A method implemented by a first network node operating in a dual connection with a second network node, the method comprising: Determine (1312) whether the application session is provided through communication with both the first network node and the second network node; Configure (1314) the wireless device with a radio access network visible quality of experience RVQoE configuration associated with the application session, the RVQoE configuration including a reporting configuration that indicates whether the RVQoE report is directed towards the first network node, the second network node, or both the first network node and the second network node based on whether the application session is provided through communication with both the first network node and the second network node; and Receive (1316) an RVQoE report for the application session from the wireless device based on the reporting configuration.

17. The method according to claim 16, wherein, Determining whether the application session is provided through communication with both the first network node and the second network node is based on an association between the application session and one or more bearer channels.

18. The method according to claim 16, wherein, Determining whether the application session is provided through communication with both the first network node and the second network node includes: receiving, from the wireless device, the association between the application session and one or more bearer channels.

19. The method according to claim 16, wherein, Determining whether the application session is provided through communication with both the first network node and the second network node is based on the protocol used by the application session.

20. The method according to claim 16, wherein, Determining whether the application session is provided through communication with both the first network node and the second network node occurs after a first RVQoE report has been sent by the wireless device, and the determination is based on the first RVQoE report.

21. The method according to any one of claims 16 - 20, wherein, The first network node includes a master node MN and the second network node includes a secondary node SN, or the first network node includes SN and the second network node includes MN.

22. The method according to any one of claims 16 - 21, further comprising: Forward (1318) the received RVQoE report to the second network node.

23. A computer program product comprising a non - transient computer - readable medium storing computer - readable program code which, when executed by a processing circuit, is operable to implement any of the steps according to any one of claims 16 - 22.

24. A first network node (300) capable of operating in a dual connection with a second network node (300), the first network node comprising a processing circuit (302) operable to: Determine whether an application session is provided through communication with both the first network node and the second network node; Configure a wireless device using a radio access network visible quality of experience (RVQoE) configuration associated with the application session, the RVQoE configuration including a reporting configuration that indicates whether the RVQoE report is directed towards the first network node, the second network node, or both the first network node and the second network node based on whether the application session is provided through communication with both the first network node and the second network node; and Receive an RVQoE report for the application session from the wireless device based on the reporting configuration.

25. The first network node according to claim 24, wherein, The processing circuitry is operable to: determine whether the application session is provided by communication with both the first network node and the second network node, based on an association between the application session and one or more bearer channels.

26. The first network node according to claim 24, wherein, The processing circuitry is operable to: determine whether the application session is provided by communication with both the first network node and the second network node, by receiving the association between the application session and one or more bearer channels from the wireless device.

27. The first network node according to claim 24, wherein, The processing circuitry is operable to: determine whether the application session is provided by communication with both the first network node and the second network node, based on the protocol used by the application session.

28. The first network node according to claim 24, wherein, The processing circuitry is operable to: determine whether the application session is provided by communication with both the first network node and the second network node after a first RVQoE report has been sent by the wireless device, and the determination is based on the first RVQoE report.

29. The first network node according to any one of claims 24 - 28, wherein, The first network node includes a master node MN and the second network node includes a secondary node SN, or the first network node includes SN and the second network node includes MN.

30. The first network node according to any one of claims 24 - 29, the processing circuit is further operable to: forward the received RVQoE report to the second network node.

Images