Handling of quality of experience measurements

Abstract

The present disclosure provides a method performed by a user equipment (UE) for handling quality of experience (QoE) measurements. The method includes establishing 402 a connection to a primary network node of a network and a secondary network node of the network, and triggering 404 a release of a configuration for QoE measurements in the UE. The configuration is established by the secondary network node. The release is triggered in response to termination of the connection to the secondary network node.

Description

[Technical Field]

[0001] The present disclosure relates to methods for handling quality of experience measurements, and user equipment and network nodes configured to perform these methods. [Background technology]

[0002] First, we provide an overview of the Quality of Experience (QoE) framework.

[0003] QoE measurements, also known as "application layer measurements," are specified for Long Term Evolution (LTE) and Universal Mobile Telecommunications System (UMTS), and are being specified for New Radio (NR) in 3GPP Release 17. The purpose of application layer measurements is to measure the end-user experience when using several applications. Currently, QoE measurements are supported for streaming services and MTSI (mobility telephony services for Internet Protocol Multimedia Subsystem (IMS)). For NR, at least virtual reality (VR) may be added to the list of services for which QoE measurements are specified and supported.

[0004] The solutions in LTE and UMTS share the same overall principle: Quality of Experience Measurement Collection (QMC) enables the configuration of application layer measurements in the UE and the transmission of QoE measurement result files (commonly called QoE reports) to the network via Radio Resource Control (RRC) signaling. The application layer measurement configuration (also called QoE measurement configuration or QoE setting) received by the Radio Access Network (RAN) from the Operation and Maintenance (OAM or O&M) system or the Core Network (CN) is encapsulated in a transparent container, which is forwarded to the User Equipment (UE) in a downlink RRC message. The application layer measurement report (also called QoE report) received by the UE Access Stratum (AS) layer or the UE RRC layer from the UE's upper layer (application layer) is encapsulated in a transparent container and sent to the network in an uplink RRC message. The RAN then forwards the QoE report to a Measurement Collector Entity (MCE).

[0005] In 3GPP Release 17, a new research item for NR, "Study on NR QoE Management and Optimization for Diverse Services," was approved and completed. The specification work for 3GPP Release 17 is still ongoing. The purpose of the research item 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 general performance requirements of various services (e.g., Augmented Reality (AR) / VR and Ultra-Reliable Low-Latency Communications (URLLC)—at least VR is expected to be covered in 3GPP Release 17). Based on service requirements, the NR research also included a more adaptive QoE management scheme that enables network optimization to satisfy user experience for various services.

[0006] The configuration data related to QoE measurements (commonly referred to in the standard as application layer measurements) consists of a service type indication, an indication of the area where the measurements should be performed (denoted as area scope), the Internet Protocol (IP) address of the entity (often called the MCE, spelled Measurement Collector Entity or Measurement Collection Entity, but the entity is sometimes called the Trace Collection Entity) to which the collected measurement results (i.e., QoE reports) should be sent, and a set of instructions on what type of measurements should be performed and details on how these measurements should be performed. These instructions are targeted to the application layer in the UE and are placed in a "container" that the network entities that handle the instructions, e.g., forwarding the instructions to the UE, and the UE AS, cannot interpret and do not attempt to read. The currently specified service type is MTSI and Streaming Service (DASH), and at least service type VR will be added in 3GPP Release 17. The area scope is specified in terms of a cell or network-related area. In UMTS, the area scope is specified as either a list of cells, a list of routing areas, or a list of tracking areas. In LTE, the area range is defined as either a list of cells or a list of tracking areas. In NR, the area range will be defined as either a list of cells or a list of tracking areas.

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

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

[0009] For s-based QoE, the OAM system is interested in collecting QoE measurements from a particular UE, for example, because the user of that UE has complained. The OAM system sends the s-based QoE configuration to the Home Subscriber Server (HSS) (in Evolved Packet System (EPS) / LTE) or User Data Management (UDM) (in 5th Generation System (5GS) / NR), which forwards the QoE configuration to the UE's current CN node, e.g., the Mobility Management Entity (MME) in EPS / LTE or the Access and Mobility Management Function (AMF) in 5GS / NR. The CN node then forwards the s-based QoE configuration to the RAN node serving that UE, which then forwards the s-based QoE configuration to the UE.

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

[0011] Reports with collected QoE measurement results (i.e., QoE reports) are sent from the UE application layer to the UE AS, which forwards them to the RAN, which forwards them to the MCE. These QoE measurement results are placed in "containers" that are not interpretable by the UE AS and the RAN. QoE reports can be configured to be sent periodically or only at the end of an application session. Furthermore, the RAN can instruct the UE to pause QoE reporting, for example, if the cell / gNB is overloaded.

[0012] The RAN is not aware when an application session with an associated QoE measurement session is ongoing, and the UE AS is not automatically aware of this either. A relaxation of this session start / stop indication, which would be sent from the application layer in the UE to the UE AS and from the UE AS to the RAN, can be introduced. The session stop indication can be implicit in the form of a QoE report sent when the application session and the associated QoE measurement session are terminated.

[0013] The RAN may decide to remove the QoE settings in the UE at any time as an implementation-based decision, typically when the UE moves outside the area configured for QoE measurements, commonly called the area range.

[0014] One opportunity offered by legacy solutions is the possibility to keep QoE measurements for the entire session even during handover situations, and it is discussed that the UE continues to measure QoE for an ongoing application session until the application session is terminated, even if the UE moves outside the configured coverage area in the meantime.

[0015] An extension of the QoE framework studied for 3GPP Release 17 and currently specified in 3GPP is the concept of RAN-visible QoE (RVQoE). Regular QoE reports are targeted to entities external to the RAN, e.g., the MCE, which is part of the OAM system, and the RAN cannot read the QoE reports (at least not by specification, although gNB / eNB (Evolved Universal Terrestrial RAN (E-UTRAN) NodeB) implementations are not prevented from doing so). In contrast, reported RVQoE metrics are targeted to the RAN and delivered to the RAN in a format that the RAN understands. RVQoE metrics are derived from regular QoE metrics, collected by the UE application layer, compiled into a report, and delivered to the RAN so that the RAN can use the report for various types of optimization. As an example, when the RAN receives an RVQoE report during an ongoing application session, the RAN can perform adaptive actions to affect the QoE of the involved application session while the application session is ongoing, such as modifying various parameters related to the UE's scheduling and data flows associated with the application session.

[0016] QoE measurements exist in many legacy systems. QoE measurements are specified for LTE and UMTS, and they are being specified for NR. The purpose of application layer measurements is to measure the end-user experience when using some applications. Currently, QoE measurements for streaming services and MTSI (Mobility Telephony Service for IMS) services are supported.

[0017] The solutions in LTE and UMTS have similar overall principles: Quality of Experience measurement collection enables the configuration of application layer measurements in the UE and the transmission of QoE measurement result files by RRC signaling. Application layer measurement configuration received from the O&M or CN is encapsulated in a transparent container and forwarded to the UE in a downlink RRC message. Application layer measurements received from upper layers in the UE are encapsulated in a transparent container and sent to the network in an uplink RRC message. The result container is forwarded to the TCE (Trace Collector Entity).

[0018] In 3GPP Release 17, a new research item for NR, "Research on NR QoE Management and Optimization for Diverse Services," was implemented. The purpose of the research item was to investigate solutions for QoE measurement in NR. QoE management in NR not only collects experience parameters for streaming services, but also considers the typical performance requirements of diverse services (e.g., AR / VR and URLLC).

[0019] Measurements may be initiated in a management-based manner towards the RAN, i.e., from the O&M node in a generic manner for a group of UEs that may be selected by the RAN, or measurements may be initiated in a signaling-based manner, i.e., from the CN to the RAN (in response to a request from the O&M system) for a single specific UE. The measurement configuration includes measurement details encapsulated in a container that is transparent to the RAN.

[0020] When initiated via the core network, measurements are started towards a specific UE. In the case of LTE, a "trace start" S1 Application Protocol (S1 AP) message is used, which carries, among other things, details about the measurement configuration that the application should collect (in a "Container for Application Layer Measurement Configuration" information element (IE) that is transparent to the RAN) and details for reaching the trace collection entity to which the measurements should be sent. S1 is the interface between the RAN and the CN in LTE.

[0021] Notifications of started and stopped application sessions with associated QoE measurement configurations are introduced. These notifications are conveyed from the application layer in the UE to the UE AS (i.e., the radio layer in the UE) and then forwarded to the network. This allows the network (at least the RAN) to know when QoE measurement for an application session is in progress. It is an implementation decision of the RAN when to stop the measurement. Typically, this is done when the UE moves outside the configured area for measurement (also called the area range). However, this strategy is challenged by the desire to have QoE data representing the complete application session.

[0022] Figure 1 is a signaling diagram illustrating the basic signaling (without showing all the details) involved in QoE measurement configuration from an O&M system to a UE. The signaling diagram in Figure 1 corresponds to the signaling diagram in 3GPP Technical Specification (TS) 28.405 version 16.0.0, which is labeled "Figure 4.2.1-1: QMC Activation and Reporting in LTE." It provides an overview (without showing all the details) of the signaling involved in QoE measurement configuration from an O&M system to a UE.

[0023] Also, one opportunity offered by legacy solutions is the possibility to keep QoE measurements for the entire application session even during handover conditions, so that the reported QoE measurement data covers the complete application session.

[0024] QoE measurements can be configured in the UE by RRC signaling. The configuration is done using the RRC message RRCReconfiguration, which contains the IE appLayerMeasConfig. The UE starts collecting QoE measurements when a session starts at the application layer, and when a report is ready, it is sent to the network in the RRC message MeasurementReportAppLayer. The same RRC message is used for both regular QoE and RAN-visible QoE.

[0025] FIG. 2 shows the configuration and reporting of QoE measurements using RRC signaling.

[0026] AT commands are used for communication between the AS (radio) layer and the application layer in the UE. AT commands are defined in 3GPP TS27.007V18.2.0. AT commands are used in QoE to transfer settings from the RRC layer to the application and to transfer reports from the application layer to the RRC layer.

[0027] In 3GPP Release 12 (Rel-12), the LTE feature Dual Connectivity (DC) was introduced to allow a UE to be connected in two cell groups, each controlled by an LTE access node and an eNB, designated the Master eNB (MeNB) and Secondary eNB (SeNB). The UE still has only one RRC connection with the network. In 3GPP, DC solutions have evolved since then and are now specified for NR and between LTE and NR. Multi-connectivity (MC) is when there are more than two nodes involved. With the introduction of fifth generation (5G), the term MR-DC (Multi-Radio Dual Connectivity, see also 3GPP TS37.340V17.4.0) was defined as a generic term for all dual connectivity options involving at least one NR access node. Using the generalized terminology of MR-DC, a UE is connected in a Master Cell Group (MCG) controlled by a Master Node (MN) and in a Secondary Cell Group (SCG) controlled by a Secondary Node (SN).

[0028] Furthermore, in MR-DC, when dual connectivity is configured for a UE, carrier aggregation can also be used within each of the two cell groups, MCG and SCG. In this case, within the MCG controlled by the master node (MN), the UE may use one primary cell (PCell) and one or more secondary cells (SCells). Within the SCG controlled by the secondary node (SN), the UE may use one primary SCell (PSCell, also known as the primary SCG cell in NR) and one or more SCells. This combined case is shown in Figure 3. In NR, the primary cell of the master or secondary cell group is sometimes called a special cell (SpCell). Therefore, the SpCell in the MCG is the PCell, and the SpCell in the SCG is the PSCell.

[0029] FIG. 3 is a diagram of dual connectivity combined with carrier aggregation in MR-DC.

[0030] Currently, there are several challenges. Summary of the Invention

[0031] 3GPP discusses QoE in NR-DC scenarios in Release 18 of the 3GPP standard, and it is agreed that both the master node (MN) and secondary node (SN) can configure QoE measurements. Secondary nodes, or secondary cell groups as referred to in TS38.331 version 17.3.0, may not be configured all the time. The network can configure or deconfigure SCGs for various reasons, such as in response to the amount of data being transmitted between UEs or the data rate required to meet UE requests. SCG deconfiguration is typically performed by the MN / MCG (master cell group), and the MN / MCG may not be able to initiate the deconfiguration of QoE measurements configured by the SN / SCG. This can result in "backlogged" QoE measurements in the UE (i.e., configured measurements but without the possibility of sending any reports), which unnecessarily consumes UE capacity and battery.

[0032] It is unclear how to handle the release of management-based QoE configuration, e.g., whether and how this should be coordinated between the MN and the SN. Based on current technology, the MN uses m-based QoE measurements to determine which node to configure the UE with, so the MN does not have visibility into when the configuration is released, which could pose a problem, especially when the SN releases a configuration that the MN believes is in progress.

[0033] Certain aspects of the present disclosure and embodiments thereof may provide solutions to these and other problems.

[0034] Accordingly, in one aspect, a first method for handling Quality of Experience (QoE) measurements is provided. The first method is performed by a user equipment (UE). The first method includes establishing a connection to a primary network node of a network and a secondary network node of the network, and triggering, in the UE, a release of a configuration for QoE measurements. The configuration is established by the secondary network node. The release is triggered in response to termination of the connection to the secondary network node.

[0035] In another aspect, a second method for handling QoE measurements is provided. The second method is performed by a first network node of a network. The second method includes establishing a connection to a UE and triggering, in the UE, a release of a configuration for QoE measurements. The configuration is established by the first network node. The release is triggered in response to termination of the connection to the UE.

[0036] In another aspect, a UE is provided that comprises processing circuitry configured to cause the UE to perform the first method described above.

[0037] In another aspect, there is provided a network node comprising processing circuitry configured to cause the network node to perform the second method described above.

[0038] In another aspect, there is provided a computer program comprising instructions which, when executed by processing circuitry of a user equipment, cause the user equipment to perform a method according to the first method described above.

[0039] In another aspect, there is provided a computer program comprising instructions which, when executed by processing circuitry of a network node, cause the network node to perform a method according to the second method set forth above.

[0040] In another aspect, a computer program product embodied on a non-transitory machine-readable medium is provided, comprising instructions executable by processing circuitry of a user equipment to cause the user equipment to perform a method according to the first method described above.

[0041] In another aspect, there is provided a computer program product embodied on a non-transitory machine-readable medium, comprising instructions executable by processing circuitry of a network node to cause the network node to perform a method according to the second method described above.

[0042] For a better understanding of embodiments of the present disclosure, and to show how the same may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [Brief explanation of the drawings]

[0043] [Figure 1] FIG. 1 is a signaling diagram illustrating the basic signaling involved in QoE measurement configuration. [Figure 2] FIG. 1 illustrates the configuration and reporting of QoE measurements using RRC signaling. [Figure 3] A diagram of dual connectivity combined with carrier aggregation in MR-DC. [Figure 4] 1 is a flowchart illustrating a method according to some embodiments. [Figure 5] 1 is a flowchart illustrating a method according to some embodiments. [Figure 6] FIG. 1 illustrates an example of a communication system according to some embodiments. [Figure 7] FIG. 1 illustrates a UE according to some embodiments. [Figure 8] FIG. 1 illustrates a network node according to some embodiments. [Figure 9] FIG. 2 is a block diagram of a host. [Figure 10] FIG. 1 is a block diagram illustrating a virtualization environment in which functionality implemented by some embodiments may be virtualized. [Figure 11] FIG. 1 is a communication diagram of a host communicating with a UE via a network node over a partial wireless connection, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0044] Some of the embodiments discussed herein will now be more fully described with reference to the accompanying drawings. The embodiments are provided as examples to convey the scope of the subject matter to those skilled in the art. Additional information may also be found in the documents provided in the appendices.

[0045] In general, all terms used herein should be interpreted according to their ordinary meaning in the relevant technical field unless a different meaning is clearly provided and / or implied from the context in which they are used. All references to elements, devices, components, means, steps, etc. should be openly interpreted as referring to at least one instance of the element, device, component, means, step, etc., unless expressly stated otherwise. The steps of any method disclosed herein need not be performed in the exact order disclosed unless a step is explicitly described as following or preceding another step and / or if it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, whenever appropriate. Similarly, any advantage of any of the embodiments may be applied to any other embodiment, and vice versa.

[0046] Other objects, features, and advantages of the enclosed embodiments will become apparent from the following description.

[0047] A few points should be made regarding nomenclature for the purposes of this disclosure.

[0048] The terms "master node," "MN," "master network node," "MN node," "primary node," and "primary network node" may be used interchangeably.

[0049] The terms "session start / stop indication" and "start / stop indication" may be used interchangeably.

[0050] This disclosure is equally applicable to QoE and RVQoE measurements.

[0051] In this specification, the application layer in the UE may also be referred to as the "UE application layer" or simply the "application layer."

[0052] The terms "QoE report" and "QoE measurement report" may be used interchangeably. The terms "QoE configuration", "QoE parameters", "QoE information", "QoE configuration information", and "QoE measurement configuration" may be used interchangeably. Similarly, the terms "RVQoE configuration" and "RVQoE measurement configuration" may be used interchangeably. The content of the QoE / RVQoE configuration may be as defined herein and, optionally, any additional information related to QoE measurement. The network, the UE AS, and the UE application layer may store various parts thereof.

[0053] The entity that performs QoE measurements and other actions related to QoE configuration, such as receiving QoE information from the UE AS and / or sending QoE information to the UE AS, is an application. Applications reside on the application layer in the UE, and therefore it is also correct to say that the application layer performs these actions. In the solution description, the performers of these various actions are sometimes referred to as the application layer and sometimes as applications.

[0054] The terms "application layer measurement configuration", "application measurement configuration", "QoE measurement configuration", "QoE configuration", "QoE measurement and reporting configuration", "RVQoE measurement configuration", "RVQoE configuration", "RVQoE measurement and reporting configuration", and "QMC configuration" may be used interchangeably. "QMC configuration file" is not an equivalent term, but instead refers to the part of the QoE configuration that consists of an Extensible Markup Language (XML) file containing instructions for QoE metrics to be collected, etc.

[0055] Although the solutions are described for the interaction between the UE AS and the UE application layer when handling / storing QoE information, they may also be applicable to RVQoE information.

[0056] All references to the application layer relate to the application layer of the UE.

[0057] The term "service" is often used as a shorthand for "service type," and therefore "service" and "service type" may be viewed synonymously unless explicitly stated otherwise.

[0058] The solution proposed in this invention can be applied to both signaling-based and management-based QoE measurements (although it can optionally be constrained to apply to only one of them).

[0059] (e.g., instructions on whether the UE should send a session start / stop indication) provides an XML file containing configurations of QoE measurements to be performed and reported (e.g., indicating QoE metrics to be collected and reported). This XML file is referred to herein by different terms, including at least a "QMC configuration file" and a "QoE configuration file."

[0060] The functions in the UE that 3GPP names the Access Stratum (if there is a corresponding Access Stratum function in the network) are referred to in various ways herein, including the "Access Stratum", "AS", "UE Access Stratum", "UE AS", "Access Stratum Layer", "AS Layer", "UE Access Stratum Layer", "UE AS Layer", and "Radio Layer".

[0061] The terms "LTE" and "LTE node" imply that a network node serving a UE is serving the UE by using LTE radio access technology over the air interface (Uu).

[0062] The terms "NR" and "NR node" imply that the network node serving the UE is serving the UE by using NR radio access technology over the air interface (Uu).

[0063] Some embodiments are presented using the example of a UE in dual connectivity, particularly for the case of NR-DC, but the embodiments may also apply to any type of multi-radio connection and to radio access technologies where the UE is served by more than two connection segments.

[0064] Some embodiments proposed herein apply to NR as well as future radio access technologies (RATs) such as sixth generation (6G) using an integrated access backhaul mobile termination (IAB-MT) parent backhaul link termination function and an integrated access backhaul distribution unit (IAB-DU) relay node access service provision function.

[0065] "Sending a report to a node" may or may not imply that the node is the consumer, i.e., the final destination of the report. The terms "node," "network node," and "RAN node" may be used interchangeably herein. Transmission to an MN or transmission to an SN may refer to using a carrier in an MCG and a carrier in an SCG, respectively. The terms "session" and "application session" may be used interchangeably. The terms "management-based QoE," "m-based QoE," and "m-QoE" are used interchangeably.

[0066] Parameters / IEs / fields used in Abstract Syntax Notation One (ASN.1) code and procedure text in the 3GPP RRC specification for 5G / NR, i.e., 3GPP TS38.331 version 17.3.0, are often named with a suffix indicating the release number of the 3GPP standard in which the parameter / IE / field was introduced (e.g., the suffix "-r17" for a parameter / IE / field introduced in Release 17 of the 3GPP standard). Parameter / IEs / fields that follow this naming convention are generally referenced both with and without the suffix, with the name with the suffix being used in the ASN.1 code (thus defining the formal name from the perspective of an ASN.1 compiler) and the name without the suffix being used in the running text, e.g., in field descriptions and procedure text. Relevant examples in the context of this document include the parameter / IE / fields AppLayerMeasConfig-r17 / AppLayerMeasConfig and MeasConfigAppLayer-r17 / MeasConfigAppLayer. Herein, both name variations may occur for the various parameters / IEs / fields.

[0067] Strictly speaking, a session start / stop indication does not refer to an application session, but to a QoE measurement session associated with the application session. However, when the terms "session data" or "session data flow" are mentioned, they refer to the data or data flow of the application session with which the QoE measurement session is associated.

[0068] As used herein, the term "flag" refers to an indication, i.e., a parameter that indicates something. An indication that is called a flag is typically, but not necessarily, an indication that can indicate one of only two possible values, for example, implemented as a single-bit indicator.

[0069] A node that configured a UE with a QoE / RVQoE configuration is referred to herein as the "owner" of the QoE / RVQoE configuration. Note that ownership may be transferred to another node in some situations, for example, during mobility. For example, if an MN is the owner of the QoE / RVQoE configuration and the MN changes due to a PCell change (e.g., handover), ownership is transferred to the new MN. Similarly, as another example, if an SN is the owner of the QoE / RVQoE configuration and the SN changes (e.g., due to an SN / SCG change procedure), ownership may be transferred to the new SN.

[0070] 4 illustrates a first method according to a particular embodiment. The first method may be performed by a UE or a wireless device (e.g., a UE 612 or a UE 700, described later with reference to FIGS. 6 and 7, respectively). The first method is for handling QoE measurements. The first method starts in step 402, establishing a connection to a primary network node of a network and a secondary network node of the network. In step 404, the first method includes triggering, in the UE, a release of a configuration for QoE measurements. The configuration is configured by the secondary network node. The release is triggered in response to termination of the connection to the secondary network node.

[0071] In some embodiments, the termination of the connection to the secondary network node may be due to the release of the secondary network node.

[0072] In some embodiments, the first method may include deactivating the secondary network node.

[0073] In some embodiments, the first method may include receiving a first message including information indicating a termination of a connection to a secondary network node.

[0074] In some embodiments, the first message may be a radio resource control (RRC) reconfiguration message.

[0075] In some embodiments, the first message may be received from a primary network node.

[0076] In some embodiments, triggering deconfiguration may include one or both of triggering deconfiguration from an application layer of the UE and triggering deconfiguration from an access stratum (AS) layer of the UE.

[0077] In some embodiments, triggering the de-configuration from an application layer of the UE may include notifying the application layer to de-configure.

[0078] In some embodiments, notifying the application layer to remove the setting may include indicating to the application layer one or more identifiers that identify the setting.

[0079] In some embodiments, triggering the release of the configuration from the application layer of the UE may include releasing an access stratum (AS) layer portion of the configuration.

[0080] In some embodiments, the first method may include stopping unconfigured QoE measurements configured by the secondary network node.

[0081] In some embodiments, the first method may include starting a timer to temporarily retain the setting after the setting is released.

[0082] In some embodiments, the first method may include deleting or removing the setting upon expiration of a timer.

[0083] In some embodiments, the first method may include triggering release of the configuration (e.g., at at least one of the following times): after arrival of a next report for QoE measurements, after arrival of a last report for QoE measurements for the session, after arrival of an indication that the session being at least partially delivered via the secondary network node will be stopped, after arrival of an indication that the session being at least partially delivered via the secondary network node will be stopped, and after sending any pending reports for QoE measurements, after arrival of an indication that the session will start after release, or upon expiration of a predefined time period configured to retain the configuration.

[0084] In some embodiments, the first method may include releasing signaling radio bearer 5 (SRB5) in response to the release of the secondary network node.

[0085] In some embodiments, the SRB5 may be released in response to the first network node receiving an instruction to release the SRB5 from the second network node, or the SRB5 may be released upon expiration of a predefined period configured to retain the configuration. In some embodiments, the predefined period may be configured by the UE or the network.

[0086] In some embodiments, the first method may include handling unsent reports for QoE measurements that are de-configured by a secondary network node.

[0087] In some embodiments, handling the unsent report may include sending a second message including the unsent report towards the secondary network node and / or deleting the unsent report at the UE.

[0088] In some embodiments, the second message may be transmitted via the primary network node towards the secondary network node.

[0089] In some embodiments, the second message may be sent before triggering the removal of the setting.

[0090] In some embodiments, the removal of the configuration may be triggered when the primary network node does not take over management of the configuration from the secondary network node.

[0091] In some embodiments, the first method may include determining whether a primary network node has taken over management of a configuration from a secondary network node.

[0092] In some embodiments, the first method may include receiving an instruction from the primary network node to transmit remaining reports generated in accordance with the configuration to the primary network node on behalf of the secondary network node.

[0093] In some embodiments, the first method may include transmitting an indication towards the primary network node regarding the availability of available reports regarding QoE measurements.

[0094] In some embodiments, the QoE measurements may include radio access network visible QoE (RVQoE) measurements.

[0095] 5 illustrates a second method according to a particular embodiment. The second method may be performed by a network node (e.g., network node 610 or network node 800, described below with reference to FIGS. 6 and 8, respectively). The second method is for handling QoE measurements. The second method begins in step 502 with establishing a connection to a UE. In step 504, the second method includes triggering, in the UE, a release of a configuration for QoE measurements. The configuration is configured by the first network node. The release is triggered in response to termination of the connection to the UE.

[0096] In some embodiments, the second method may include one or both of terminating the connection to the UE in response to receiving a request to terminate the connection to the UE, where the request may be received from a second network node of the network through which the connection to the UE is established; and providing information to the second network node of the network through which the connection to the UE is established, where the information may be about the first network node triggering the release.

[0097] In some embodiments, the information may be provided in response to the first network node determining that a release should be triggered.

[0098] In some embodiments, the information may be provided in response to the first network node receiving a request to terminate a connection to the UE.

[0099] In some embodiments, triggering the release may include triggering the release in response to the second network node granting permission to the first network node to trigger the release.

[0100] In some embodiments, the information may be provided prior to triggering the release and may include an indication that the first network node intends to trigger the release. In some embodiments, the information may be provided prior to triggering the release and may include a request for the second network node to grant permission to the first network node to trigger the release. In some embodiments, the information may be provided after triggering the release and may include an indication that the first network node has triggered the release.

[0101] In some embodiments, the information may include an indication of whether the release is for only the UE for which a connection is established for the second network node, for multiple UEs, or for all UEs.

[0102] In some embodiments, the second method may include receiving an indication from the second network node that the first network node provides the information.

[0103] In some embodiments, providing the information may include transmitting Next Generation Application Protocol (NGAP) or Xn Application Protocol (XnAP) signaling that includes the information.

[0104] In some embodiments, the first network node may be a primary network node and the second network node may be a secondary network node, while in other embodiments, the first network node may be a secondary network node and the second network node may be a primary network node.

[0105] In some embodiments, the QoE measurements may include RVQoE measurements.

[0106] Also provided is a UE comprising processing circuitry configured to cause the UE to perform the aforementioned first method. In some embodiments, the UE may comprise at least one memory for storing instructions that, when executed by the processing circuitry of the UE, cause the UE to operate in accordance with the first method.

[0107] Also provided is a network node comprising processing circuitry configured to cause the network node to perform the second method described above. In some embodiments, the network node may comprise at least one memory for storing instructions that, when executed by the processing circuitry of the network node, cause the network node to operate in accordance with the second method.

[0108] There is also provided a computer program comprising instructions which, when executed by processing circuitry of a user equipment, cause the user equipment to perform a first method according to the first method described above.

[0109] There is also provided a computer program comprising instructions which, when executed by processing circuitry of a network node, cause the network node to perform a second method in accordance with the second method described above.

[0110] Also provided is a computer program product embodied on a non-transitory machine-readable medium that includes instructions executable by processing circuitry of a user equipment to cause the user equipment to perform a first method according to the first method described above.

[0111] Also provided is a computer program product embodied on a non-transitory machine-readable medium, comprising instructions executable by processing circuitry of a network node to cause the network node to perform a second method according to the second method described above.

[0112] The present disclosure relates to handling of QoE measurements in SCG cancellation.

[0113] The present disclosure describes a method for a UE, which may include: - receiving the configuration of QoE measurements from the secondary node (SN); - Optionally, performing QoE measurements related to the configuration received by the SN. - Receiving a reconfiguration message, such as RRCReconfiguration, including reconfiguration from dual connectivity to single connectivity, i.e., release of SN. This message may be received from the MN. - Perform one or more of the following actions: Stopping any ongoing QoE / RVQoE measurements set by the SN / SCG. o Notifying the application layer to remove the QoE settings set by the SN / SCG. This can be done by indicating the measConfigAppLayerId of the QoE configuration to be released. In case of LTE SCG, the UE may indicate the release of the QoE measurement configuration when configured by the SCG. - Clearing the AS layer part of the QoE settings set by the SN / SCG. o Receive instructions from an SN or MN to de-set (release) an SRB5 and release the SRB5 in response. In one variant, this is subject to an internal UE timer used to maintain the RVQoE / QoE configuration after release of resources associated to an SN (see explanation below in alternative solutions), or a network configured timer with the same purpose, i.e. only when such a timer expires or is restarted due to the re-addition of at least one cell of the same SN for which radio resources were previously released in the UE. Handling unsent QoE reports. One option is to send any outstanding RVQoE / QoE reports destined for the SN in a message via the MN, e.g., in a ULInformationTransferMRDC message, to the MN, which then forwards them to the SN, e.g., in an RRCTransfer message. Another option is to delete any outstanding RVQoE / QoE reports destined for the SN. Another option is to first send any outstanding RVQoE / QoE reports to the SN, and then perform the SN / SCG release. - Implement the release of SN / SCG.

[0114] The present disclosure describes a solution related to ensuring that application layer measurements configured by the SN (secondary node) are released at the UE AS and UE application layer when the UE is reconfigured from dual connectivity to single connectivity, i.e., when the SN is released.

[0115] Certain embodiments may provide one or more of the following technical advantages: An advantage of this solution is that no QoE measurement configurations or QoE measurement reports are "left outstanding" in the UE after a change from dual connectivity to single connectivity. This increases UE capacity and extends UE battery life. Another advantage is that it helps the UE avoid consuming the allowed budget of the maximum number of QoE measurement configurations it can be configured with by releasing or otherwise leaving outstanding QoE measurement configurations. Another advantage is also better and more precise control on the network side regarding network knowledge of the status at the UE regarding QoE / RVQoE measurements configured for the UE and the amount / size of QoE / RVQoE reports that can be expected from the UE.

[0116] Next, we will explain the solutions related to handling QoE when transmitting from dual connectivity to single connectivity.

[0117] A method is provided for a UE related to handling QoE measurements configured by a secondary node (SN) when the SN is released by the network, i.e., during a transition from dual connectivity to single connectivity. The method includes UE actions for releasing QoE measurement configurations configured by the SN at both the UE AS layer and the UE application layer. The method also includes optional UE actions related to transmitting any untransmitted QoE reports associated with the SN when the SN is released.

[0118] The method also includes any SN and MN actions related to handling SN QoE configuration and reporting in connection with SN / SCG release.

[0119] UE-related embodiment

[0120] The method for the UE may include: - receiving the configuration of QoE measurements from the secondary node (SN); - Optionally, performing QoE measurements related to the configuration received by the SN, for example performing RVQoE measurements for which the associated reports are intended to reach the SN. - Receiving a reconfiguration message, such as RRCReconfiguration, including reconfiguration from dual connectivity to single connectivity, i.e., release of SN. This message may be received from the MN. - Perform one or more of the following actions: Stopping any ongoing QoE / RVQoE measurements set by the SN / SCG. o Notifying the application layer to remove the QoE settings set by the SN / SCG. This can be done by indicating the measConfigAppLayerId of the QoE configuration to be released. In case of LTE SCG, the UE may indicate the release of the QoE measurement configuration when configured by the SCG. - Clearing the AS layer part of the QoE settings set by the SN / SCG. o Receive instructions from an SN or MN to de-set (release) an SRB5 and release the SRB5 in response. In one variant, this is subject to an internal UE timer used to maintain the RVQoE / QoE configuration after release of resources associated to an SN (see explanation below in alternative solutions), or a network configured timer with the same purpose, i.e. only when such a timer expires or is restarted due to the re-addition of at least one cell of the same SN for which radio resources were previously released in the UE. Handling unsent QoE reports. One option is to send any outstanding RVQoE / QoE reports destined for the SN in a message via the MN, e.g., in a ULInformationTransferMRDC message, to the MN, which then forwards them to the SN, e.g., in an RRCTransfer message. Another option is to delete any outstanding RVQoE / QoE reports destined for the SN / SCG. Another option is to first send any outstanding RVQoE / QoE reports to the SN, and then perform the SN / SCG release. Another option is to delete any outstanding RVQoE reports, but transmit (to the MN) any outstanding QoE reports generated by QoE / RVQoE measurements configured by the SN / SCG. Another option is to delete any outstanding QoE reports, but transmit (to the MN) any outstanding RVQoE reports generated by QoE / RVQoE measurements configured by the SN / SCG. In another option, which can be combined with the previous option, the UE transmits or deletes any outstanding RVQoE / QoE reports destined for the SN upon expiry of a timer used to make the UE temporarily retain the RVQoE / QoE configuration. As a further option, in all of the above options where any QoE and / or RVQoE reports generated by QoE / RVQoE measurements configured by the SN / SCG are sent to the MN / MCG, the UE will only send these reports to the MN / MCG if certain conditions are met. These conditions may be: · The MN or SN has requested the UE to do so. ·MN has taken over "ownership" of QoE / RVQoE settings. ·At least one of the UE's MCG cells is within the area range of the QoE / RVQoE setting. - Implement the release of SN / SCG.

[0121] In some alternative UE embodiments, - Possibly receiving an indication from the MN that the MN is taking over "ownership" of one or more of the SN's QoE / RVQoE settings. - In one option, the QoE configuration includes a parameter that causes the UE AS to start a timer to maintain the RVQoE configuration as soon as the SN resources are released in the UE AS upon release of the SN connection section, and to understand that the RVQoE configuration should be released when the timer expires. - possibly making a decision itself regarding a QoE / RVQoE configuration previously set by the SN (and thus "owned" by the SN), e.g., based on the fulfillment of a condition that the MN takes over "ownership" of the QoE / RVQoE configuration (this may also mean that any untransmitted and future QoE and / or RVQoE reports for this QoE / RVQoE configuration should be transmitted to the MN). If the UE is aware of the area range, such a condition may be, e.g., that at least one of the UE's MCG cells is within the area range of the QoE / RVQoE configuration. In this option, the area range known by the UE may be area range information that the RAN has received, for example, from an OAM node and forwarded to the UE AS (e.g., so that the UE AS can monitor the UE's location with respect to the area range when the UE is in RRC_INACTIVE or RRC_IDLE state), or a LocationFilter parameter that the UE application layer has received in a QMC configuration file (and that the UE may use as the area range related to QoE configuration, for example, when the UE is in RRC_INACTIVE or RRC_IDLE state). - In some cases, when the UE receives an RRCReconfiguration message to release the SN, it receives an instruction from the MN to send the remaining reports generated according to the SN QoE / RVQoE configuration to the MN instead of the SN. - Perform one or more of the following actions in relation to stopping any ongoing QoE / RVQoE measurements configured by the SN / SCG: The UE AS starts an internal timer or a network configured timer (e.g. Timer_PendingRVQoEConfiguration) that is used to temporarily retain the RVQoE / QoE configuration after the release of SN / SCG resources. Upon expiration, the UE AS decides to delete / remove the RVQoE / QoE configuration associated with the SN (the UE AS sends an AT command to the UE application layer to release the RVQoE / QoE configuration). The UE AS waits for the arrival of the next RVQoE report to be sent to the SN and / or the arrival of the next QoE report (from the UE application layer to the UE AS) and immediately thereafter releases the SN-related RVQoE configuration. The UE AS waits for the arrival of the final RVQoE report of the session sent to the SN and / or the arrival of the final QoE report of the session (from the UE application layer) and immediately thereafter releases the SN-related RVQoE / QoE configuration. Optionally, the UE AS or UE application layer marks the last RVQoE report so that the RAN knows this is the last RVQoE report. · Optionally, receipt by the UE AS of a session stop / end indication from the UE application layer informs the UE AS that no more RVQoE or QoE reports will arrive from the UE application layer. The UE AS waits for the arrival of a session stop indication associated with an ongoing session of an application that was at least partially delivered via the SN, and then releases the RVQoE / QoE configuration associated with the SN. The UE AS waits for the arrival of a session stop indication associated with an ongoing session of an application that was at least partially delivered via the SN, sends any pending RVQoE / QoE reports associated with the SN to the MN, and then releases the RVQoE / QoE configuration associated with the SN. The UE AS waits for the arrival of a session start indication, which arrives at the UE AS from the UE application layer after the SN / SCG release (thus indicating that the session has been started and is not carried by the SN), and then releases the RVQoE / QoE configuration associated with the SN. o The UE AS may wait for the expiration of a timer monitoring the retention of QoE / RVQoE configuration in the UE without receiving a QoE / RVQoE report from the UE application layer (e.g., 48 hours) after the QoE / RVQoE configuration has been received (either at the UE AS or at the UE application layer) and without releasing the SN-related QoE / RVQoE configuration. - After SN release, possibly (if the UE receives a pauseReporting indication (set to "true") from the SN) send an indication to the MN regarding the availability of buffered / available QoE / RVQoE reports.

[0122] SN related embodiment

[0123] A method for a network node, a secondary node (SN), operating in dual connectivity is provided, and the method may include: - Sending RVQoE / QoE measurement configuration to the UE. In some variations, when the UE receives the configuration from the MN, it receives an indication from the MN that "ownership" of the QoE / RVQoE configuration has been transferred to the SN. o One option is to instruct the UE to use a timer for temporarily retaining the RVQoE / QoE configuration upon SN release. This may be an instruction to use a timer with a specified start value, or the instruction from the SN may include the start value. Another variant is that the standard specifies that the UE should use a specified timer with a specified start value (in this case the SN does not need to send an explicit instruction related to the timer to the UE). As a further option, the SN may then maintain the corresponding timer upon SN release. - Receive a command for release from the master node or initiate a release towards the master node. Along with this command, the SN may optionally receive an indication from the MN that the MN will take over "ownership" of the QoE / RVQoE configuration. - Possibly, upon learning from the MN about the upcoming SN release (or upon deciding to initiate an SN-initiated SCG release), send a pauseReporting indication to the UE. - Clear all RVQoE / QoE settings set by the SN. o This step may be omitted if the UE is provided with an instruction (from the network or as specified in the normative text of the technical specification) requesting it to release the RVQoE / QoE configured by the SN, in case the release of the RVQoE / QoE configuration is delegated to the UE. This step is omitted if the SN receives an indication from the MN that the MN will take over "ownership" of the QoE / RVQoE configuration, or if this transfer of "ownership" is implicitly understood, e.g., from the rules of a standard specification or because certain conditions for such a transfer of "ownership" are met. Optionally, together with the QoE / RVQoE release command, send to the UE a timer (or the start value of the timer) that the UE should use to manage the delayed release (i.e., temporary holding) of the QoE / RVQoE settings. Optionally, if the SN sends a timer (or a timer start value, or an instruction to use a specified timer with a specified start value, or if the standard specifies that the UE should use a specified timer with a specified start value) to the UE, it manages the delayed release of the QoE / RVQoE configuration, i.e., temporary retention, and starts the corresponding timer (in the SN itself) and maintains the QoE / RVQoE configuration information in the network until the timer expires. - In parallel, deconfigure (release) the SRB5 for the UE before or after deconfiguring the RVQoE / QoE in the UE. - If a timer is used to maintain pending RVQoE / QoE in the UE when SN-related resources in the UE AS are released, the timer may be restarted if at least one cell of the same SN is (re)added to the UE connection before the timer expires. - Execute SN / SCG release.

[0124] MN-related embodiment

[0125] A method for a network node, a master node (MN), operating in dual connectivity is provided, and the method may include: - Sending the QoE measurement configuration to the UE. One option is to instruct the UE to use a timer to temporarily retain the RVQoE configuration when releasing the SN. In some variations, if the UE receives the configuration from the MN, it receives an indication from the MN that "ownership" of the QoE / RVQoE configuration has been transferred to the SN. - Receiving a request from an SN to release SN-related resources or deciding on its own to release SN-related resources (e.g., SCG). - Sending a request to the SN to release SN-related resources, which can explicitly or implicitly indicate that the RVQoE / QoE set by the SN should be released. - Possibly sending an indication to the UE that the SN-related QoE / RVQoE configuration should be released. - Possibly sending an indication to the SN that the MN will take over "ownership" of one or more of the SN's QoE / RVQoE settings together with a request to release SN-related resources.

[0126] After receiving an indication from the UE that the SCG is preferably released, the MN may release the SN and perform the above-mentioned actions of either taking over "ownership" of the SN QoE / RVQoE configuration or releasing the configuration entirely. Optionally, when deciding whether to take over the "ownership" of one of the SN's QoE / RVQoE settings, the MN may take into account one or more of the following: ○ Whether the QoE configuration is management-based or signaling-based. o Any instructions received from the OAM system regarding the possible transfer of ownership of QoE settings from the SN to the MN upon release of SN-related resources (where the instructions may have been received together with the QoE settings). ○ Whether the MN has at least one cell that is within the area range of the QoE / RVQoE configuration (e.g., the MN will only take over "ownership" if this is the case). Whether at least one of the UE's MCG cells is within the area range of the QoE / RVQoE configuration (e.g. the MN will only take over "ownership" if this is the case). - When the MN takes over "ownership" of the QoE / RVQoE settings, the MN may optionally request the SN to send the relevant QoE settings (i.e., QoE setting related data stored in the SN, including, for example, the MCE IP address) and / or the relevant RVQoE settings (i.e., RVQoE related data stored in the SN) to the MN, and may optionally instruct the SN to notify the UE that the MN is taking over ownership of the QoE settings (e.g., meaning that both QoE reports and RVQoE reports should be sent to the MN).

[0127] UE capacity

[0128] In the implementation of the proposed system, the UE can indicate to the network that it can report according to a variant of this solution.

[0129] The UE may indicate its capabilities in the form of an ENUMERATED indication type, where each option includes one standardized variant of the solution.

[0130] Alternatively, the capacity to support different variants of a solution may be indicated in the form of a bitmap where each bit corresponds to one variant, but an example of a variant of a solution may be "capable of understanding a single ENUMERATED field that provides instructions for RVQoE reporting." A bit value of "1" may mean that the variant is supported, and a value of "0" may mean that it is not supported, or vice versa.

[0131] Alternatively, the UE may set a binary flag indicating whether this is a standardized aspect of the solution: a bit value of '1' may mean that the variant is supported, a value of '0' may mean that it is not supported, or vice versa.

[0132] Support for QoE measurement in dual connectivity

[0133] As part of the normative work on the Release 18 specifications of the 3GPP standards, the RAN3 working group is discussing support for QoE and RVQoE measurements in NR-DC scenarios. The agreements reached so far are as follows: · The MN is responsible for setting s-based QoE for the UE. · For M-based QoE configuration in NR-DC, coordination between MN and SN is required. · If the M-based QoE configuration is received by the MN, the MN should make the decision about the UE selection and which node will send the QoE configuration to the UE. · If the M-based QoE configuration is only received by the SN, it needs to be further discussed whether the MN or the SN should perform the UE selection and send the QoE configuration to the UE.

[0134] The QoE report can be sent to either the MN or the SN, and the reporting period (MCG or SCG) can change during the application session.

[0135] When the QoE report is received by the SN, the SN may forward the QoE report directly to the MCE.

[0136] RAN3 should discuss and clarify the scenarios for QoE reporting sent via SN. Which SRBs can be used for QoE reporting in SN depends on RAN2. ·WA: MN and SN can generate RVQoE configuration. MN and SN should coordinate on configuring dual-attached UEs with RVQoE measurements. Details of the coordination are for further study (FFS). · WA: The UE can send RVQoE reports to the MN, which can then forward the RVQoE reports to the SN as needed, and vice versa.

[0137] In DC, the UE switches the reporting interval based on instructions from the network FFS in an implicit or explicit manner.

[0138] The RAN3 should discuss which node can command the UE to switch the reporting interval.

[0139] If a node configures a UE with QoE measurements and other nodes receive QoE reports from the UE and forward them directly to the MCE:

[0140] The node that configured the UE with the QoE measurements should indicate the QoE reference to the node that receives the reports and forwards them directly to the MCE. The MN can generate RVQoE configuration for the UE. The SN can generate RVQoE settings for the UE. FFS: Whether the MN can change the RVQoE settings generated by the SN. · The MN can send the RVQoE configuration to the UE. · The MN can receive RVQoE reports directly from the UE. The SN can receive RVQoE reports directly from the UE. The following WA is agreed upon: "UE can send RVQoE reports to MN, and then MN will forward the RVQoE reports to SN if necessary, and vice versa." ·Agree to ensure that RVQoE reports are sent to the nodes providing the bearers associated with the corresponding RVQoE measurement results in the RVQoE report.

[0141] Coordination between MN and SN should at least support the following (details will be explained further): Initiation by either MN or SN for m-QoE, initiation by MN for s-QoE. · Adjustments to configure the UE. Coordination for establishing an SRB for receiving QoE / RVQoE reports. -Instructions for switching reporting intervals.

[0142] For management-based QoE, the MN decides which node will perform the QoE measurement configuration, and the FFS decides which node (MN or SN) will perform the UE selection.

[0143] When the MN configures the UE with m-based QoE, it may indicate the QoE reference, the MCE IP address to the SN, and the FFS for other information (e.g., RRC ID).

[0144] When the SN receives the m-based QoE measurement configuration, the MN may recognize that the SN has received the m-based QoE measurement configuration. It may be ensured that the MN is (e.g., always) informed that the SN wants to configure m-based QoE measurements.

[0145] WA: The SN can send the RVQoE configuration to the UE. FFS: Whether the SN can send the RVQoE configuration directly to the UE via SRB3, or via split SRB1, or explicitly via Xn (if the MN can modify the RVQoE).

[0146] The node that sends the initial RVQoE configuration to the UE and the node that sends the legacy QoE configuration to the UE may be the same.

[0147] Currently, several challenges exist: The RAN3 working group in 3GPP is currently discussing MN-SN coordination for a UE in multi-connectivity (e.g., NR-DC) scenario where the MN and / or SN serving the UE receives a management-based QoE measurement configuration and intends to configure the UE with it.

[0148] 3GPP discussions have so far focused on MN-SN coordination to determine which node will configure the UE with management-based QoE measurements. In general, discussions in 3GPP assume that the MN decides whether the MN or the SN configures the UE with management-based QoE configuration in the following scenarios: · Both MN and SN have received management-based QoE configuration. Only SN receives management-based QoE settings. ·Only the MN receives the management-based QoE configuration.

[0149] Embodiments include proposed methods for an MN and an SN to coordinate regarding the removal of a management-based QoE measurement configuration in one of the two nodes. Embodiments may include coordination between the MN and the SN, conditions under which removal may be requested by one node, and actions by the second node in response to the request.

[0150] Certain embodiments may provide one or more of the following technical advantages: The embodiments may enable MN-SN coordination for de-configuration of management-based QoE measurements in a UE. By notifying other nodes of the de-configuration of QoE measurements, the other nodes may take action accordingly, for example, to configure m-based QoE measurements for the UE. De-configuration may be an important part of QoE management, similar to configuring the UE with measurements. The described embodiments not only enable controlled de-configuration of management-based QoE measurements, but also enable exchange of other parameters of interest that facilitate continuity of QoE measurements, indication of cause, and the possibility to perform the disclosed negotiation for a group or all of the UEs for which QoE configuration has been de-configured.

[0151] One common scenario involves two RAN nodes (first and second network nodes) that can act as MNs or SNs for one or more UEs. Note that in this scenario, both nodes are involved in providing dual connectivity (e.g., NR-DC connectivity) to the UEs. When the same two nodes jointly serve several UEs, the SN of one UE may be the MN of another UE, and vice versa.

[0152] The following cases are possible: Both the first network node and the second network node have received management-based (m-based) QoE configuration from OAM or another entity external to the RAN and CN, or Only one of them received it.

[0153] In either case, the nodes coordinate which of them should send the configuration to the UE and to which of the network nodes the reports will be sent before being forwarded to the Measurement Collection Entity (MCE). After coordination, the m-based QoE measurement configuration is sent to the UE, and the UE is configured with the measurement configuration and as to where (i.e., to which network node) to send the reports.

[0154] Some embodiments are described using the example of one m-based QoE configuration, but are equally applicable to any number of m-based QoE configurations.

[0155] In the following, an embodiment is presented using an example where the first network node is an SN and the second network node is an MN, but the reverse is also applicable. Also, in the following example, the terms "first network node" and "SN" are used interchangeably. Also, the terms "second network node" and "MN" are used interchangeably.

[0156] A third method is provided, which is performed by the SN and the MN to release the QoE configuration. In an optional step, the SN may first receive an instruction from the MN that the SN should notify the MN of any release of the m-based QoE configuration. The request may include or be associated with further information of what the SN should send to the MN in case of release of the QoE configuration. In step 1, the SN decides that it wants to release (i.e., deactivate or deconfigure) the m-based QoE configuration in the UE. In step 2, the SN indicates to the MN that it plans to release, or that it wants to release (e.g., request permission to release), or that it has already released the m-based QoE configuration to the UE. In step 3, the MN makes a decision. In step 4, the SN receives the MN's decision from the MN. In step 5, the SN acts accordingly.

[0157] Various embodiments and variations of the third method and steps will now be described.

[0158] Step 1 A first network node (i.e., SN) may configure the UE with the m-based QoE measurements, and the SN may decide that it wants to deactivate (i.e., deactivate or unconfigure) the m-based QoE configuration in the UE. The reason / cause for the SN to decide that it wants to unconfigure may be any one or more of the following, but is not limited to: The SN is instructed to do so by the OAM or by another network node or entity. ·SN is overloaded. The section between the SN and the UE is experiencing poor radio conditions or is experiencing Radio Link Failure (RLF). The UE has left the area range. · The SN requests the MN to be removed from dual connectivity (the UE context of the UE is released in the SN). · The SN receives a different m-based QoE configuration and selects UEs that use the new QoE configuration. The SN receives another QoE configuration for the UE that has a higher priority compared to the existing QoE configuration, but the UE is already configured with the maximum number of allowed QoE configurations for the UE. · A time greater than a certain threshold has elapsed since the SN stopped reporting related to m-based QoE settings. ·SN has discontinued reporting related to m-based QoE settings. The SN has not received / transmitted user data to / from the UE for longer than a threshold time (e.g., inactivity time at the SN). · The SN is aware that the MN has discontinued reporting related to m-based QoE settings. The SN is aware that the MN has suspended reporting related to m-based QoE preferences for an amount of time greater than a threshold. · The SN has resumed RVQoE and / or QoE reporting related to m-based QoE configuration, but no RVQoE or QoE reports have been received since the resumption. · The SN is aware that the MN has resumed RVQoE / QoE reporting related to m-based QoE configuration, but no reports have been received since the resumption. The SN did not receive any QoE reports related to the m-based QoE setting in question, or the SN did not receive any RVQoE reports related to an RVQoE setting derived from the m-based QoE setting. ·SCG is deactivated. · SN handover takes place from source SN to target SN. A first network node wants to update / modify QoE settings, and the updated / modified QoE settings come from OAM. The UE transitions from RRC_CONNECTED to one of the non-CONNECTED states and the m-based QoE settings initially configured were not intended for the non-RRC_CONNECTED state. · SN handover takes place from gNB to eNB (from a node that supports QoE measurements to a node that does not support QoE measurements). · When the SN receives an RVQoE measurement report related to an m-based QoE configuration and determines that the quality of experience experienced by a UE / group of UEs is too low. · The SN receives an indication from the MN that the MN will take over the configuration / reconfigure the UE with the same m-based QoE configuration. The UE leaves an application session associated with the configured m-based QoE configuration. Application sessions related to m-based QoE settings are terminated. The SN receives an indication from the MN that the m-based QoE configuration needs to be released due to an incoming s-based QoE configuration received by the MN for the same UE that takes precedence over the existing m-based QoE configuration. The SN initially configures the UE with m-based QoE so that it can also configure RVQoE measurements for the UE, and later decides to deconfigure RVQoE measurements. The SN has determined that another UE would be a better target for the m-based QoE configuration than the current UE, and the SN's "quota" is full for the m-based QoE configuration, and therefore the QoE configuration in the current UE needs to be released when sending the QoE configuration to the other UE (here, the "quota" can be a number or percentage of UEs that can be determined based on an instruction from the gNB implementation (i.e., the SN implementation) or another entity / node, e.g., the entity / node that sends the m-based QoE configuration to the SN). · The SN has determined that the UE is a bad choice of UE for this m-based QoE configuration, for example because no application sessions of the service type associated with this m-based QoE configuration have been started for a long time. The SN receives an s-based QoE configuration for the same UE, for example when the UE reports an insufficient quality of experience and the OAM sends an s-based configuration in response. · The SN detects that an MN change (without an implicit change of SN) is in progress. · The SN may not want to implicitly release all m-based QoE configurations for UEs served with the original MN, but the SN may want to verify existing / ongoing m-based QoE configurations with the new MN. · The SN may indicate this to the new MN via a cause value.

[0159] Step 2 As one option, the SN may first receive an indication from the MN that the SN should notify the MN of any removal of the m-based QoE configuration. The request may contain or be associated with further information of what the SN should send to the MN in case of removal of the QoE configuration.

[0160] The SN may indicate to the MN that it plans to release, or that it wants to release (e.g., request permission to release), or that it has already released the m-based QoE configuration to the UE. The indication may be implemented by an extension of existing or newly defined UE or non-UE related NGAP or XnAP signaling and may include one or more of the following: An indication of whether the SN has already deconfigured, or whether it intends to perform the configuration, or whether it requests the MN's permission to perform the configuration. An indication of whether the configuration is, has been, or is intended to be released for all UEs jointly served by the MN, or for only some UEs, or for only the indicated UEs. If the indication concerns a single UE, UE-associated inter-node signaling (e.g., XnAP) may be used, but when the indication concerns multiple UEs (including all), non-UE-associated inter-node signaling is used. · The ID of the UE that is or has been or is intended to be deconfigured. a. Alternatively, the indication may indicate "all UEs." b. In some variations, the instructions may pertain to all jointly served UEs for which the node serves as an SN. c. In some variations, the indication may pertain to all jointly served UEs that are configured with the m-based QoE configuration in question. The QoE reference and / or measConfigAppLayerId of the configuration being unlocked. An indication that SRB3 and / or SBR5 for the UE (or "all UEs", or "any UE") is released or scheduled to be released. An indication of whether the measurement configuration is deleted from the SN (i.e., it cannot be configured for any more UEs) or whether it is stored (i.e., it can be configured for the UE at a later time). Indication of the reason / cause for deconfiguration, for example by sending a specific cause value to the MN. The cause value can be a reuse of an existing cause value or a new cause value. The indicated reason / cause for the (e.g., intended, desired, requested, planned, or already performed) release of the am-based MN configuration may be any of the reasons / causes listed in step 1. In one alternative, the SN sends the IP address of the MCE to the MN. In one alternative, the SN sends the MCE ID to the MN. In one alternative, in addition to sending any or all of the above, the SN also sends RAN visible QoE configuration parameters to the MN if the SN independently configured the UE to report some RVQoE metrics. The MN may reconfigure its RVQoE configuration if a new SN configures QoE measurements on the UE and / or command the new SN to configure / modify those RVQoE configurations with the UE by comparing it with the configuration of the previous SN.

[0161] The SN may send a QoE setting release to the UE.

[0162] Step 3 Upon receiving an indication from the SN (the indication defined in step 2), the MN may decide one or more of the following: One option is to indicate to the SN that it should notify the MN of any removal of m-based QoE configuration. The request to the SN may also include or be associated with instructions on what information the SN should send to the MN in case of removal of QoE configuration. The MN can decide to release the configuration in the UE itself or can instruct the SN to do so, while approving the release request proposed by the SN. ·Confirm the release indicated by the SN. Check the cancellation information received from SN. · Note the information from the SN (i.e., do not send any response to the SN) and decide on further actions. Accept the SN's request to release the m-based QoE configuration and request the MN to forward the received report. a. In particular, if the SN reason for removing the QoE configuration is related to SCG failure, SCG deactivation, UE leaving NR-DC for single connectivity, or SN overload. · When the reason for the QoE setting cancellation by SN is recognized, the same QoE setting will also be cancelled. · If the cause value indicates that the m-based QoE configuration was set by a previous MN in addition to indicating the responsible node, approve or reject the request (see black circle below). Maintains the m-QoE measurement configuration in the UE and is responsible for it going forward. a. In this case, if it is the SN that has forwarded the QoE report to the MCE up until now, the MN may need to fetch the IP address and / or MCE ID of the MCE (unless already received from the OAM or from the SN) so that it can forward the report to the MCE. b. Alternatively, the MN may ask the SN for the IP address and / or MCE ID of the MCE. The MN's decision depends on the cause of the release (e.g., planned, intended, desired, or requested) as indicated by the SN in step 2. example: a. If the cause is that an OAM entity / node or another RAN external entity / node (e.g., the entity / node that created the m-based QoE configuration or the entity / node that forwarded the m-based QoE configuration to the UE) has instructed the SN to release the m-based QoE configuration, the MN may accept (or may have no choice but to accept) and approve the release; otherwise, the MN may decide to reject the release. b. If the cause is that an OAM entity / node or another RAN external entity / node (e.g., the entity / node that created the m-based QoE configuration or the entity / node that forwarded the m-based QoE configuration to the SN) has instructed the SN to release the m-based QoE configuration, or if the cause is that the UE has left the area range within the SN (e.g., none of the SCG cells are within the area range), the MN may accept (or have no choice but to accept) and approve the release; otherwise, the MN may decide to reject the release. c. In any situation where the MN accepts or approves the release or concludes that the SN has already released the m-based QoE configuration (e.g., any of the examples above), the MN may decide to send the m-based QoE configuration to the UE itself (after the SN releases it), provided that the MN receives the m-based QoE configuration and at least one of the UE's MCG cells is within its coverage area. · The MN's decision depends on whether the MN has received the relevant m-based configuration (e.g., from an OAM entity / node). example: a. If the MN receives the m-based QoE configuration, the MN accepts / approves the SN's release of the m-based QoE configuration; otherwise, the MN may reject the release. i. Optionally, this decision may depend on the cause of the release (e.g., (planned, intended, desired, requested, or already performed)) as indicated by the SN in step 2. 1. For example, if the cause of the release is that the release was instructed by an entity / node that has authority in the matter, such as an OAM entity / node or other RAN external entity / node (for example, the entity / node that created the m-based QoE configuration or the entity / node that forwarded the m-based QoE configuration to the SN), the MN accepts / acknowledges the SN's release of the m-based QoE configuration (or concludes that it has already been performed), regardless of whether the MN itself received the m-based QoE configuration. ii. Optionally, if the MN accepts / acknowledges the SN's release of the m-based QoE configuration (or if the release has already been performed), the MN may send the m-based QoE configuration to the UE on its own (provided that the MN has received the m-based QoE configuration). The MN's decision depends on whether it has the possibility to send the relevant m-based QoE configuration to the UE; a prerequisite for this is that the MN has received the m-based QoE configuration (e.g. from an OAM entity / node) and that at least one of the UE's MCG cells is within its coverage area. example: a. If the MN itself can send the m-based QoE configuration to the UE, the MN will accept / approve the SN's release of the m-based QoE configuration; otherwise, the MN may reject the release. i. Optionally, this decision may depend on the cause of the release (e.g., (planned, intended, desired, requested, or already performed)) as indicated by the SN in step 2. 1. For example, if the cause of the release is that the release was instructed by an entity / node that has authority in the matter, such as an OAM entity / node or other RAN external entity / node (for example, the entity / node that created the m-based QoE configuration or the entity / node that forwarded the m-based QoE configuration to the SN), the MN accepts / approves the SN's release of the m-based QoE configuration (or concludes that it has already been performed), regardless of whether the MN itself has the possibility to send the m-based QoE configuration to the UE. ii. Optionally, if the MN accepts / approves the SN's release of the m-based QoE configuration (or if the release has already been performed), the MN may send the m-based QoE configuration to the UE on its own (if the prerequisites for doing so are met).

[0163] In one embodiment, the MN may learn that the SN has deconfigured by the cause value in the MN-SN Adjustment Failure message sent from the SN to the MN in response to the MN-SN Adjustment Request for QoE.

[0164] Step 4 As described in step 3, the MN may respond to the SN and indicate its decision to the SN, which may act accordingly (step 5).

[0165] Further embodiments include proactive adjustment of M-based QoE deconfiguration in relation to configuration adjustments and indication of blanket deconfiguration of M-based QoE configurations.

[0166] Proactive adjustment of M-based QoE deconfiguration related to configuration adjustment

[0167] Already during the coordination of the transmission of the m-based QoE configuration to the UE (in the target scenario, the SN will transmit the m-based QoE configuration to the UE), the MN and SN may perform some proactive coordination actions regarding a possible subsequent situation in which the SN desires, intends, or plans to release the m-based QoE configuration (e.g., because the SN receives or detects something that triggers the SN to desire, intend, or plan to release the m-based QoE configuration). (Such a situation will be referred to hereinafter as a "release situation.")

[0168] To this end, in conjunction with coordinating the transmission of m-based QoE configuration to the UE, the MN may perform one or more of the following actions: When a release condition occurs, instruct the SN to do one or more of the following: a. Send a message to the MN requesting authorization to release the m-based QoE configuration in the UE. i. The instructions may further include that the SN should indicate the cause of the release condition. b. The SN sends a message to the MN to notify that the m-based QoE configuration in the UE will be released. i. The instructions may further include that the SN should indicate the cause of the release condition. c. The SN sends a message to the MN to notify that the m-based QoE configuration in the UE has been released. i. The instructions may further include that the SN should indicate the cause of the release condition. ·Inform the SN that the decision of whether and when to release the m-based QoE configuration in the UE is entirely the SN's decision. a. The MN may also instruct the SN to notify the MN if / when the SN releases the m-based QoE configuration in the UE. i. This instruction may include that the SN should indicate the cause of the release when notifying the MN of the release. b. The MN may use this option (i.e., leave it to the SN to decide if and when to release the m-based QoE configuration in the UE), for example: i. When the MN has not received the M-based QoE configuration, or ii. When none of the UE's MCG cells is within its coverage area, or iii. When none of the MN's cells is within its area range, or iv. When none of the MN's cells adjacent to the SN's cell are within the area range. Inform the SN that if the cause of the release situation is one of a set of specific causes, it is entirely the SN's decision whether and when to release the m-based QoE configuration in the UE. The set of specific causes may include, for example: i. An OAM entity / node or another RAN external entity / node (e.g., the entity / node that created the m-based QoE configuration or the entity / node that forwarded the m-based QoE configuration to the SN) has commanded the SN to remove the m-based QoE configuration. ii. The UE has left the coverage area within the SN (e.g., none of the SCG cells are within the coverage area). b. If the cause is not one of the set of specific causes, the MN may further instruct the SN to do one or more of the following when a release condition occurs: i. Send a message to the MN requesting authorization to release the m-based QoE configuration in the UE. 1. The instructions may further include that the SN should indicate the cause of the release condition. ii. The SN sends a message to the MN to notify that the m-based QoE configuration in the UE will be released. 1. The instructions may further include that the SN should indicate the cause of the release condition. iii. The SN sends a message to the MN to notify that the m-based QoE configuration in the UE has been released. 1. The instructions may further include that the SN should indicate the cause of the release condition. · Instruct the SN not to release the m-based QoE configuration, regardless of any triggers for such release that the SN may detect. a. The instructions may further include that the SN should notify the MN when a release condition occurs and what its cause is. · Instruct the SN not to release the m-based QoE configuration if the cause of the release situation is one of a set of specific causes. a. For other causes of the release situation, the MN may indicate further instructions, for example, for the SN to send a message to the MN requesting authorization to release the m-based QoE configuration. b. When the cause of the release condition is one of a set of specific causes and the SN does not release the m-based QoE configuration in accordance with the instruction, the instruction may further include that the SN should notify the MN that a release condition has occurred and what the cause is. For each distinct, non-overlapping set of causes of the release condition, instruct the SN that it should perform the following actions: a. If the cause of the release situation is one of the first set of causes, the SN should refrain from releasing the m-based QoE configuration. i. Optionally, the SN should notify the MN that a release condition has occurred. 1. This notification of the MN may be selective based on cause (as commanded by the MN). b. If the cause of the release situation is one of the second set of causes, the SN should send a message to the MN requesting authorization for the SN to release the m-based QoE configuration. c. If the cause of the release situation is one of the third set of causes, the SN may make its own decision as to whether or when to release the m-based QoE configuration. i. Optionally, the SN should notify the MN of the release and its cause (as instructed by the MN).

[0169] Instruction to cancel M-based QoE settings all at once

[0170] Another embodiment is an instruction to cancel the m-based QoE settings all at once.

[0171] In some variations, an indication to the MN that the SN has / intends to release the m-based QoE configuration for a UE may serve as an implicit indication to the MN that release has / intends to be performed for all UEs that the SN has configured with the m-based configuration in question.

[0172] In some variations, the SN may indicate to the MN that it has / intends to release all m-based configurations for a particular UE.

[0173] A fourth method performed by a UE for canceling a QoE configuration is also provided. The fourth method includes being configured with m-based QoE measurements by a network node. The fourth method includes receiving a communication to cancel (i.e., deactivate or deconfigure) the m-based QoE configuration. The fourth method includes canceling the m-based QoE configuration.

[0174] FIG. 6 illustrates an example of a communication system 600, according to some embodiments.

[0175] In this example, the communications system 600 includes a communications network 602 including an access network 604, such as a radio access network (RAN), and a core network 606 including one or more core network nodes 608. The access network 604 includes one or more access network nodes, such as network nodes 610a and 610b (one or more of which may be collectively referred to as network node 610), or any other similar Third Generation Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be understood by those skilled in the art, a network node is not necessarily limited to an implementation in which the radio portion and the band portion are supplied and integrated by a single vendor. That is, it will be understood that a network node includes disjoint implementations or portions thereof. For example, in some embodiments, the communications network 602 includes one or more Open RAN (ORAN) network nodes. An ORAN network node is a node within the communications network 602 that supports ORAN specifications (e.g., specifications published by the O-RAN Alliance or any similar organization) and can operate alone or in conjunction with other nodes to implement one or more functions of any node within the communications network 602, including one or more network nodes 610 and / or core network node 608.

[0176] Examples of ORAN network nodes include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU) including an O-CU control plane (O-CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real-time or non-real-time) hosting software or software plug-in such as a near-real-time control application (e.g., xApp) or a non-real-time control application (e.g., rApp), or any combination thereof (the adjective "open" designates support for the ORAN specifications). A network node can support the specifications by supporting interfaces defined by the ORAN specifications, such as the A1, F1, W1, E1, E2, X2, Xn interfaces, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node can be a logical node within a physical node. Furthermore, an ORAN network node may be implemented within a virtualized environment (described further below) in which one or more network functions are virtualized. For example, the virtualized environment may include an O-Cloud Computing Platform orchestrated by a service management and orchestration framework over an O-2 interface or similar technology defined by the O-RAN Alliance. The network node 610 facilitates direct or indirect connectivity of user equipment (UE), such as by connecting UEs 612a, 612b, 612c, and 612d (one or more of which may be generally referred to as UEs 612) to the core network 606 over one or more wireless connections.

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

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

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

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

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

[0182] In some examples, the communication network 602 is a cellular network that implements 3GPP standardized features. Thus, the communication network 602 can support network slicing to provide different logical networks to different devices connected to the communication network 602. For example, the communication network 602 can provide Ultra-Reliable Low-Latency Communications (URLLC) services to some UEs while providing enhanced Mobile Broadband (eMBB) services to other UEs and / or massive machine-based communications (mMTC) / massive IoT services to still further UEs.

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

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

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

[0186] 7 illustrates a UE 700 according to some embodiments. As used herein, a UE refers to a device capable of, set up, configured, and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smartphone, a mobile phone, a cell phone, a voice-over-IP (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless camera, a gaming console or device, a music storage device, a playback device, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop computer, a laptop embedded equipment (LEE), a laptop mounted equipment (LME), a smart device, a wireless customer premises equipment (CPE), a vehicle, a vehicle-mounted or vehicle-embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a Narrowband Internet of Things (NB-IoT) UE, a Machine Type Communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0187] A UE may support device-to-device (D2D) communications, for example, by implementing 3GPP standards for sidelink communications, dedicated short-range communications (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, a UE does not necessarily have a user in the sense of a human user who owns and / or operates an associated device. Instead, a UE may represent a device (e.g., a smart sprinkler controller) that is intended for sale to or operation by a human user but may not be associated with or initially associated with a particular human user. Alternatively, a UE may represent a device (e.g., a smart power meter) that is not intended for sale to or operation by an end user, but that may be associated with or operated for the user's benefit.

[0188] The UE 700 includes a processing circuit 702 operably coupled to an input / output interface 706, a power source 708, a memory 710, a communication interface 712, and / or any other components, or any combination thereof, via a bus 704. A particular UE may utilize all or a subset of the components shown in FIG. 7. The level of integration between components may vary from one UE to another. Additionally, some UEs may include multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0189] The processing circuit 702 is configured to process instructions and data and may be configured to implement any sequential state machine operable to execute instructions stored as a machine-readable computer program in the memory 710. The processing circuit 702 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 together with appropriate firmware, one or more stored computer programs such as a microprocessor or digital signal processor (DSP) together with appropriate software, a general-purpose processor, or any combination of the above. For example, the processing circuit 702 may include multiple central processing units (CPUs). The processing circuit 702 may be operable to provide UE 700 functionality either alone or in conjunction with other UE 700 components, such as the memory 710.

[0190] The processing circuit 702 may be configured to cause the UE 700 to perform a first method described herein (e.g., as described with reference to FIG. 4), a fourth method described herein, or any other method described herein in connection with the UE.

[0191] In this example, the input / output interface 706 may 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 a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smart card, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 700. Examples of input devices include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a webcam, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smart card, etc. A presence-sensitive display may include a capacitive or resistive touch sensor for detecting input from a user. The sensor may be, for example, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, a light sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. The output device may use the same type of interface port as the input device. For example, a Universal Serial Bus (USB) port may be used to provide input and output devices.

[0192] In some embodiments, the power source 708 is constructed as a battery or battery pack. Other types of power sources may be used, such as an external power source (e.g., an electrical outlet), a photovoltaic device, or a battery. The power source 708 may further include power circuitry for delivering power to various portions of the UE 700 from the power source 708 itself and / or from an external power source via an interface such as an input circuit or a power cable. Delivering power may be for charging the power source 708, for example. The power circuitry may perform any formatting, converting, or other modification on the power from the power source 708 to make it suitable for each component of the UE 700 being powered.

[0193] The memory 710 may be or be configured to include memory 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 disk, optical disk, hard disk, removable cartridge, flash drive, etc. In one example, the memory 710 includes one or more application programs 714, such as an operating system, a web browser application, a widget, a gadget engine, or other applications, and corresponding data 716. The memory 710 can store any of a wide variety of operating systems or combinations of operating systems for use by the UE 700.

[0194] The memory 710 may be configured to include several physical drive units such as a redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smart card memory such as a tamper-resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs) such as a universal subscriber identity module (USIM) and / or an international subscriber identity module (ISIM), other memory, or any combination thereof. The UICC may be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly known as a "SIM card." The memory 710 may enable the UE 700 to access instructions, application programs, etc. stored on a temporary or non-transitory memory medium, offload data, or upload data. An article of manufacture, such as an article of manufacture utilizing a communication system, may be tangibly embodied as or in the memory 710, which may be or comprise a device-readable storage medium.

[0195] The processing circuit 702 may be configured to communicate with an access network or other networks using a communication interface 712. The communication interface 712 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 722. The communication interface 712 may include one or more transceivers used to communicate, 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 the access network). Each transceiver may include a transmitter 718 and / or a receiver 720 suitable for providing network communication (e.g., optical, electrical, frequency allocation, etc.). Moreover, the transmitter 718 and receiver 720 may be coupled to one or more antennas (e.g., antenna 722) and may share circuit components, software, or firmware or, alternatively, be implemented separately.

[0196] In some embodiments, the communication capabilities of communication interface 712 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near-field communication, location-based communication such as using a Global Positioning System (GPS) to determine location, another similar communication capability, or any combination thereof. Communications may 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.

[0197] Regardless of the type of sensor, the UE can provide an output of data captured by its sensor through its communication interface 712 via a wireless connection to a network node. Data captured by a UE's sensor can be communicated through another UE via a wireless connection to a network node. The output can be periodic (e.g., once every 15 minutes if it reports a sensed temperature), random (e.g., to even out the load from reports from several sensors), responsive to a triggering event (e.g., when moisture is detected and an alert is sent), responsive to a request (e.g., a user-initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0198] As another example, the UE may include an actuator, motor, or switch associated with a communications interface configured to receive wireless input from a network node via a wireless connection. The actuator, motor, or switch may change state in response to the received wireless input. For example, the UE may include a motor that adjusts a control surface or rotor of a drone in flight according to the received input, or that controls a robotic arm that performs a medical procedure according to the received input.

[0199] When in the form of an Internet of Things (IoT) device, the UE may be a device for use in one or more application areas, including, but not limited to, urban wearable technology, augmented industrial applications, and healthcare. Non-limiting examples of such IoT devices are devices that are or are embedded in a connected refrigerator or freezer, a TV, a connected lighting device, an energy meter, a robotic vacuum cleaner, a voice-controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a water inundation / humidity sensor, an electric door lock, a connected doorbell, an air conditioning system such as a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for augmented reality (AR) or virtual reality (VR), a wearable for haptic augmentation or sensory augmentation, a water sprinkler, an animal or product tracking device, a sensor for monitoring plants or animals, an industrial robot, an unmanned aerial vehicle (UAV), and any type of medical device such as a heart rate monitor or a remote-controlled surgical robot. A UE in the form of an IoT device comprises, in addition to the other components described with respect to the UE 700 shown in FIG. 7, circuitry and / or software depending on the intended application of the IoT device.

[0200] As yet another particular example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements and transmits results of such monitoring and / or measurements to another UE and / or network node. The UE, in this case, may be an M2M device, which may be referred to as an MTC device in the 3GPP context. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, bus, truck, ship, and airplane, or other equipment capable of monitoring and / or reporting on its operating state or other functionality associated with its operation.

[0201] In practice, any number of UEs may be used together for a single use case. For example, a first UE may be a drone or be integrated in a drone and provide the drone's speed information (obtained through a speed sensor) to a second UE that is a remote controller that operates the drone. When a user makes changes from the remote controller, the first UE can adjust a throttle on the drone (e.g., by controlling an actuator) to increase or decrease the drone's speed. The first and / or second UE may also include two or more of the functions described above. For example, a UE may include a sensor and an actuator and handle communication of data for both the speed sensor and the actuator.

[0202] 8 illustrates a network node 800 according to some embodiments. As used herein, a network node refers to a device that is capable of, set up, configured, and / or operable to communicate directly or indirectly with UEs and / or other network nodes or devices in a communications network. Examples of a network node include, but are not limited to, an access point (AP) (e.g., a wireless access point), a base station (BS) (e.g., a radio base station, a Node B, an evolved Node B (eNB), an NR Node B (gNB)), an O-RAN node or a component of an O-RAN node (e.g., an O-RU, an O-DU, an O-CU).

[0203] Base stations may be classified based on the amount of coverage they provide (or, stated another way, their transmit power level) and may therefore be referred to as femto, pico, micro, or macro base stations depending on the amount of coverage they provide. A base station may also be a relay node or relay donor node that controls a relay. A network node may also include one or more (or all) parts of a distributed radio base station, such as a centralized digital unit, a distributed unit (e.g., in an O-RAN access node), and / or a remote radio unit (RRU), sometimes referred to as a remote radio head (RRH). Such remote radio units may or may not be integrated with an antenna, as in an antenna-integrated radio. Portions of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0204] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, MSR equipment such as a multi-standard radio (MSR) BS, a network controller such as a radio network controller (RNC) or base station controller (BSC), a base transceiver station (BTS), a transmission point, a transmitting node, a multi-cell / multicast coordination entity (MCE), an operation and maintenance (O&M) node, an operation support system (OSS) node, a self-organizing network (SON) node, a positioning node (e.g., an evolved serving mobile location center (E-SMLC)), and / or a minimization drive test (MDT).

[0205] The network node 800 includes processing circuitry 802, memory 804, a communication interface 806, and a power source 808, and / or any other components, or any combination thereof. The network node 800 may be composed of multiple physically separate components (e.g., a Node B component and an RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 800 comprises multiple separate components (e.g., a BTS component and a BSC component), 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 scenarios, each unique Node B and RNC pair may, in some instances, be considered a single, separate network node. In some embodiments, the network node 800 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 804 for different RATs) and some components may be reused (e.g., the same antenna 810 may be shared by different RATs). Network node 800 may also include multiple sets of the various shown components for different wireless technologies, e.g., GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, radio frequency identification (RFID), or Bluetooth wireless technologies, integrated into network node 800. These wireless technologies may be integrated into the same or different chips or sets of chips and other components within network node 800.

[0206] The processing circuitry 802 may include one or more combinations of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and / or coded logic operable, alone or in conjunction with other network node 800 components such as memory 804, to provide network node 800 functionality.

[0207] The processing circuitry 802 may be configured to cause the network node 800 to perform the second method described herein (e.g., as described with reference to FIG. 5), the third method described herein, or any other method described herein in connection with the network node.

[0208] In some embodiments, the processing circuit 802 comprises a system on a chip (SOC). In some embodiments, the processing circuit 802 includes one or more of a radio frequency (RF) transceiver circuit 812 and a baseband processing circuit 814. In some embodiments, the radio frequency (RF) transceiver circuit 812 and the baseband processing circuit 814 may be on separate chips (or sets of chips), boards, or units, such as a radio unit and a digital unit. In alternative embodiments, some or all of the RF transceiver circuit 812 and the baseband processing circuit 814 may be on the same chip or set of chips, board, or unit.

[0209] The memory 804 may comprise any form of volatile or non-volatile computer-readable memory, including, but not limited to, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drive, compact disc (CD), or digital video disc (DVD)), and / or any other volatile or non-volatile non-transitory device-readable and / or computer-executable memory device that stores information, data, and / or instructions that can be used by the processing circuit 802. The memory 804 can store any suitable instructions, data, or information, including computer programs, software, applications that include one or more of logic, rules, code, tables, and / or other instructions that can be executed by the processing circuit 802 and utilized by the network node 800. The memory 804 may be used to store calculations performed by the processing circuit 802 and / or data received via the communication interface 806. In some embodiments, the processing circuit 802 and the memory 804 are integrated.

[0210] The communication interface 806 is used in wired or wireless communication of signaling and / or data between network nodes, access networks, and / or UEs. As shown, the communication interface 806 includes a port / terminal 816 for sending and receiving data to and from a network, for example, over a wired connection. The communication interface 806 also includes a radio front-end circuit 818 that is coupled to an antenna 810 or, in some embodiments, may be part of the antenna 810. The radio front-end circuit 818 includes a filter 820 and an amplifier 822. The radio front-end circuit 818 may be connected to the antenna 810 and the processing circuit 802. The radio front-end circuit may be configured to condition signals communicated between the antenna 810 and the processing circuit 802. The radio front-end circuit 818 may receive digital data to be transmitted to other network nodes or UEs via a wireless connection. The radio front-end circuit 818 may convert the digital data into a radio signal having appropriate channel and bandwidth parameters using a combination of a filter 820 and / or an amplifier 822. The wireless signal may then be transmitted via antenna 810. Similarly, when receiving data, antenna 810 may collect the wireless signal, which is then converted to digital data by wireless front-end circuitry 818. The digital data may be passed to processing circuit 802. In other embodiments, the communication interface may include different components and / or different combinations of components.

[0211] In certain alternative embodiments, network node 800 does not include a separate radio front-end circuit 818; instead, processing circuit 802 includes the radio front-end circuitry and is connected to antenna 810. Similarly, in some embodiments, all or some of the RF transceiver circuitry 812 is part of communication interface 806. In still other embodiments, communication interface 806 includes one or more ports or terminals 816, radio front-end circuitry 818, and RF transceiver circuitry 812 as part of a radio unit (not shown), and communication interface 806 communicates with baseband processing circuitry 814 that is part of a digital unit (not shown).

[0212] The antenna 810 may include one or more antennas or an antenna array configured to transmit and / or receive wireless signals. The antenna 810 may be coupled to the radio front-end circuitry 818 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In particular embodiments, the antenna 810 may be separate from the network node 800 and connectable to the network node 800 via an interface or port.

[0213] The antenna 810, the communication interface 806, and / or the processing circuit 802 may be configured to perform any receiving operation and / or some obtaining operation described herein as being performed by a network node. Any information, data, and / or signals may be received from a UE, another network node, and / or any other network equipment. Similarly, the antenna 810, the communication interface 806, and / or the processing circuit 802 may be configured to perform any transmitting operation described herein as being performed by a network node. Any information, data, and / or signals may be transmitted to a UE, another network node, and / or any other network equipment.

[0214] The power supply 808 provides power to the various components of the network node 800 in a form appropriate for each component (e.g., at the voltage and current levels required for each component). The power supply 808 may further comprise, or be coupled to, power management circuitry for providing power to the components of the network node 800 to perform the functions described herein. For example, the network node 800 may be connectable to an external power source (e.g., a power grid, an electrical outlet) via an interface such as an input circuit or an electrical cable, whereby the external power source provides power to the power circuitry of the power supply 808. As a further example, the power supply 808 may comprise a power source in the form of a battery or battery pack connected to or integrated into the power circuitry. The battery can provide backup power if the external power source fails.

[0215] 8 to provide certain aspects of the network node's functionality, including any of the functionality described herein and / or functionality necessary to support the subject matter described herein. For example, network node 800 may include user interface devices to enable input of information into network node 800 and output of information from network node 800. This may enable a user to perform diagnostic, maintenance, repair, and other administrative functions for network node 800.

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

[0217] The host 900 includes a processing circuit 902 operably coupled via a bus 904 to an input / output interface 906, a network interface 908, a power supply 910, and a memory 912. In other embodiments, other components may be included. Features of these components may be substantially similar to features described with respect to the devices in previous figures, such as Figures 7 and 8, and therefore those descriptions are generally applicable to the corresponding components of the host 900.

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

[0219] FIG. 10 is a block diagram illustrating a virtualization environment 1000 in which functionality implemented by some embodiments may be virtualized. In this context, virtualizing means creating a virtual version of an apparatus or device, which may include virtualizing a hardware platform, storage devices, and networking resources. Virtualization, as used herein, may apply to any device described herein, or components thereof, and relates to implementations in which at least a portion of functionality is implemented as one or more virtual components. Some or all of the functionality described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtualization environments 1000 hosted by one or more hardware nodes, such as a network node, a UE, a core network node, or a hardware computing device acting as a host. Furthermore, in embodiments in which the virtualized node does not require wireless connectivity (e.g., to a core network node or host), the node may be fully virtualized. In some embodiments, the virtualization environment 1000 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a service management and orchestration framework over an O-2 interface.

[0220] An application 1002 (which may alternatively be referred to as a software instance, a virtual appliance, a network function, a virtual node, a virtual network function, etc.) executes within the virtualized environment Q400 to achieve some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0221] The hardware 1004 includes processing circuitry, memory that stores software and / or instructions executable by the hardware processing circuitry, and / or other hardware devices described herein, such as network interfaces, input / output interfaces, etc. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1006 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1008a and 1008b (one or more of which may be referred to generically as VMs 1008), and / or perform any of the functions, features, and / or advantages described in connection with some embodiments described herein. The virtualization layer 1006 may present a virtual operating platform that appears to be networking hardware to the VMs 1008.

[0222] The VMs 1008 may comprise virtual processing, virtual memory, virtual networking or interfaces, and virtual storage and may be run by a corresponding virtualization layer 1006. Different embodiments of the virtual appliance 1002 instances may be implemented in one or more of the VMs 1008, and the implementation may be done in different ways. Hardware virtualization is referred to in some contexts as network functions virtualization (NFV). NFV may be used to aggregate many network equipment types onto industry-standard high-volume server hardware, physical switches, and physical storage that may be located in data centers and customer premises equipment.

[0223] In the context of NFV, a VM 1008 may be a software implementation of a physical machine that runs programs as if they were running on a physical, non-virtualized machine. Each VM 1008 and the portion of the hardware 1004 on which it runs form a separate virtual network element, whether on hardware dedicated to the VM and / or shared between that virtual machine and other VMs. Furthermore, in the context of NFV, a virtual network function is responsible for handling a particular network function running on one or more VMs 1008 on the hardware 1004 and corresponding to the application 1002.

[0224] The hardware 1004 may be implemented in a standalone network node with general or specific components. The hardware 1004 may achieve some functions through virtualization. Alternatively, the hardware 1004 may be part of a larger cluster of hardware (e.g., in a data center or CPE) managed via management and orchestration 1010, where many hardware nodes cooperate and, among other things, oversee the lifecycle management of the application 1002. In some embodiments, the hardware 1004 is coupled to one or more radio units, each including one or more transmitters and one or more receivers, which may be coupled to one or more antennas. The radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with virtual components to provide a virtual node with wireless capabilities, such as a wireless access node or base station. In some embodiments, some signaling may be provided using a control system 1012, which may alternatively be used for communication between the hardware nodes and the radio units.

[0225] 11 illustrates a communication diagram of a host 1102 communicating with a UE 1106, in part over a wireless connection, via a network node 1104, according to some embodiments. Exemplary implementations according to various embodiments of a UE (such as the UE 612a of FIG. 6 and / or the UE 700 of FIG. 7), a network node (such as the network node 610a of FIG. 6 and / or the network node 800 of FIG. 8), and a host (such as the host 616 of FIG. 6 and / or the host 900 of FIG. 9) described in the preceding paragraphs will now be described with reference to FIG. 11.

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

[0227] The network node 1104 includes hardware that enables the network node 1104 to communicate with the host 1102 and the UE 1106. The connection 1160 may be direct or may pass through a core network (such as the core network 606 in FIG. 6) and / or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, the intermediate network may be a backbone network or the Internet.

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

[0229] The OTT connection 1150 may extend via a connection 1160 between the host 1102 and the network node 1104 and via a wireless connection 1170 between the network node 1104 and the UE 1106 to provide a connection between the host 1102 and the UE 1106. The connection 1160 and the wireless connection 1170 over which the OTT connection 1150 may be provided are depicted abstractly to illustrate communication between the host 1102 and the UE 1106 via the network node 1104, without explicit reference to intermediate devices and the precise routing of messages through these devices.

[0230] As an example of transmitting data over the OTT connection 1150, in step 1108, the host 1102 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE 1106. In other embodiments, the user data is associated with the UE 1106, which shares data with the host 1102 without explicit human interaction. In step 1110, the host 1102 initiates a transmission carrying user data toward the UE 1106. The host 1102 may initiate the transmission in response to a request sent by the UE 1106. The request may be triggered by human interaction with the UE 1106 or by the operation of a client application running on the UE 1106. The transmission may be routed through the network node 1104 in accordance with the teachings of the embodiments described throughout this disclosure. Thus, in step 1112, the network node 1104 transmits the user data carried in the host 1102-initiated transmission to the UE 1106 in accordance with the teachings of the embodiments described throughout this disclosure. In step 1114 , the UE 1106 receives the user data carried in the transmission, which may be executed by a client application running on the UE 1106 associated with the host application executed by the host 1102 .

[0231] In some examples, the UE 1106 executes a client application that provides user data to the host 1102. The user data may be provided in reaction or response to data received from the host 1102. Thus, in step 1116, the UE 1106 can provide the user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from a user via an input / output interface of the UE 1106. Regardless of the particular manner in which the user data is provided, the UE 1106 initiates transmission of the user data toward the host 1102 via the network node 1104 in step 1118. In step 1120, the network node 1104 receives the user data from the UE 1106 and initiates transmission of the received user data toward the host 1102, in accordance with the teachings of embodiments described throughout this disclosure. In step 1122, the host 1102 receives the user data carried in the transmission initiated by the UE 1106.

[0232] One or more of the various embodiments improve the implementation of OTT services provided to the UE 1106 using the OTT connection 1150, of which the radio connection 1170 forms the final segment. More precisely, the teachings of these embodiments may improve data rates, latency, and power consumption, thereby providing benefits such as reduced user latency, better responsiveness, and extended battery life.

[0233] In an exemplary scenario, factory status information may be collected and analyzed by the host 1102. As another example, the host 1102 may process audio and video data that may have been retrieved from UEs for use in creating maps. As another example, the host 1102 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, the host 1102 may store surveillance video uploaded by UEs. As another example, the host 1102 may store or control access to media content, such as video, audio, VR, or AR, that the host 1102 may broadcast, multicast, or unicast to UEs. As other examples, the host 1102 may be used for energy pricing, remote control of non-time-critical electrical loads to balance power generation demands, location services, presentation services (such as compiling diagrams, etc. from data collected from remote devices), or any other function that collects, retrieves, stores, analyzes, and / or transmits data.

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

[0235] While the computing devices (e.g., UEs, network nodes, hosts) described herein may include the depicted combinations of hardware components, other embodiments may comprise computing devices having different combinations of components. It should be understood that these computing devices may comprise any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. The determining, calculating, obtaining, or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting obtained information to other information, comparing the obtained or converted information with information stored in a network node, and / or performing one or more operations based on the obtained or converted information and as a result of the processing making a decision. Moreover, while a component is depicted as a single box located within a larger box or nested within multiple boxes, in reality the computing device may comprise multiple different physical components that make up the single depicted component, and functionality may be partitioned among the separate components. For example, a communications interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communications interface. In another example, non-computationally intensive functionality of any of such components may be implemented in software or firmware, and computationally intensive functionality may be implemented in hardware.

[0236] In particular embodiments, some or all of the functionality described herein may be provided by a processing circuit executing instructions stored in a memory, which in particular embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuit without executing instructions stored on a separate or distinct device-readable storage medium, such as in a hardwired manner. In any of these particular embodiments, the processing circuit may be configured to perform the described functionality, regardless of whether or not it executes instructions stored on a non-transitory computer-readable storage medium. Benefits provided by such functionality are not limited to the processing circuit alone or to other components of the computing device, but are enjoyed by the computing device as a whole and / or by end users and wireless networks generally.

[0237] Other embodiments of the present disclosure are defined in the following numbered statements.

[0238] Group A Embodiments 1. A method performed by a user equipment (UE) for handling quality of experience (QoE) measurements, the method comprising: establishing a connection to a primary network node of the network and a secondary network node of the network; Triggering the deconfiguration for QoE measurement in the UE; Including, The method, wherein the setting is set by a secondary network node and the release is triggered in response to termination of a connection to the secondary network node.

[0239] 2. 2. The method of embodiment 1, wherein the termination of the connection to the secondary network node is due to the release of the secondary network node.

[0240] 3. 3. The method of embodiment 1 or 2, comprising releasing the secondary network node.

[0241] 4. 4. A method according to any one of embodiments 1 to 3, comprising receiving a first message including information indicating a termination of a connection to a secondary network node.

[0242] 5. 5. The method of embodiment 4, wherein the first message is a radio resource control (RRC) reconfiguration message.

[0243] 6. 6. The method of embodiment 4 or 5, wherein the first message is received from a primary network node.

[0244] 7. Triggering the unsetting is triggering deconfiguration from an application layer of the UE; Triggering said deconfiguration from an access stratum (AS) layer of the UE; 7. The method of any one of embodiments 1 to 6, comprising one or both of:

[0245] 8. 8. The method of embodiment 7, wherein triggering deconfiguration from an application layer of the UE includes notifying the application layer to deconfigure.

[0246] 9. Informing the application layer to unset it is 9. The method of embodiment 8, comprising indicating to an application layer one or more identifiers that identify the configuration.

[0247] 10. 10. The method of any one of embodiments 7 to 9, wherein triggering a release of the configuration from the AS layer of the UE includes releasing an access stratum (AS) layer portion of the configuration.

[0248] 11. 11. A method according to any preceding embodiment, comprising stopping QoE measurements that are unconfigured by a secondary network node.

[0249] 12. 12. A method according to any preceding embodiment, comprising starting a timer for temporarily retaining the setting after it has been released.

[0250] 13. 13. The method of embodiment 12, comprising deleting or removing the configuration upon expiration of the timer.

[0251] 14. After the next report on QoE measurements arrives, After the arrival of the final report on the QoE measurements in the session, Upon arrival of an indication that a session that is at least partially delivered via a secondary network node is to be stopped, after the arrival of an indication that a session that is at least partially delivered via the secondary network node is to be stopped and after sending any pending reports on QoE measurements, Upon arrival of an indication that a session will commence after release, or Upon expiration of the specified period set to retain the setting 14. A method according to any one of embodiments 1 to 13, comprising triggering the release of the setting.

[0252] 15. 14. A method as in any preceding embodiment, comprising releasing a signaling radio bearer (SRB) 5 in response to the release of the secondary network node.

[0253] 16. 16. The method of embodiment 15, wherein the SRB5 is released upon expiration of a predetermined time period configured to maintain the configuration.

[0254] 17. 17. The method of embodiment 16, wherein the predefined time period is set by the UE or the network.

[0255] 18. 18. A method as in any preceding embodiment, comprising handling unsent reports for QoE measurements that are configured and deconfigured by a secondary network node.

[0256] 19. Handling unsent reports is sending a second message including the non-transmission report to the secondary network node; Deleting pending reports in the UE; 19. The method of embodiment 18, comprising any one or both of:

[0257] 20. 20. The method of embodiment 19, wherein the second message is transmitted via the primary network node toward the secondary network node.

[0258] twenty one. 21. The method of embodiment 19 or 20, wherein the second message is sent before triggering the release of the setting.

[0259] twenty two. 22. A method according to any one of embodiments 1 to 21, wherein the de-configuration is triggered when the primary network node does not take over management of the configuration from the secondary network node.

[0260] twenty three. 23. A method according to any preceding claim, comprising determining whether a primary network node has taken over management of the configuration from a secondary network node.

[0261] twenty four. 24. A method according to any one of embodiments 1 to 23, comprising receiving an instruction from the primary network node to send remaining reports generated according to the configuration to the primary network node instead of the secondary network node.

[0262] twenty five. 25. A method as in any preceding embodiment comprising sending an indication towards a primary network node regarding availability of available reports on QoE measurements.

[0263] 26. A method performed by a user equipment for releasing a QoE setting, the method comprising: configured by the network node with m-based QoE measurements; receiving a communication to deactivate (i.e., deactivate or deconfigure) an m-based QoE configuration; m-based QoE setting and A method comprising:

[0264] 27. Providing user data; Forwarding user data to the host via transmission to the network node; 28. The method of any preceding embodiment, further comprising:

[0265] Group B Embodiments 28. A method performed by a second network node for handling quality of experience (QoE) measurements, the method comprising: establishing a connection to a primary network node of the network; Triggering a deconfiguration for QoE measurement at the second network node; Including, The method, wherein the setting is established by a secondary network node and the release is triggered in response to termination of a connection to the primary network node.

[0266] 29. A method performed by a first network node (SN) for releasing a QoE configuration, the method comprising: (Optional) sending an m-based QoE configuration to the UE; and (Optional) receiving an indication from the MN that the SN should notify the MN of any cancellation of the m-based QoE configuration, where the request may include or be associated with further information of what the SN should send to the MN in case of cancellation of the QoE configuration; determining that it wishes to deactivate (i.e., deactivate or deconfigure) the m-based QoE configuration in the UE; Indicating to the MN that it plans to release, or that it wants to release (e.g., requesting permission to release), or that it has already released the m-based QoE configuration to the UE; receiving an MN decision from the MN; (Optional) Performing an action determined by the mobile node; A method comprising:

[0267] 30. A method performed by a second network node (MN) for releasing a QoE configuration, the method comprising: (Optional) receiving an indication from the MN that the SN should notify the MN of any removal of the m-based QoE configuration, the request may include or be associated with further information of what the SN should send to the MN in case of removal of the QoE configuration; and receiving an indication from the SN that it plans to release, or that it wants to release (e.g., request permission to release), or that it has already released the m-based QoE configuration for the UE; SN determines whether and how the release should be carried out; and indicating the decision to the SN.

[0268] 31. The decision to lift the SN the SN is instructed to do so by OAM or by another network node or entity; The SN is overloaded, The section between the SN and the UE is experiencing poor radio conditions or is experiencing a Radio Link Failure (RLF); The UE has left the coverage area; The SN requests the MN to be removed from dual connectivity (the UE context of the UE is released in the SN); The SN has received another m-based QoE configuration and selected a UE to use the new QoE configuration; The SN receives another QoE configuration for the UE that has a higher priority compared to the existing QoE configuration, but the UE is already configured with the maximum number of allowed QoE configurations for the UE; a time greater than a certain threshold has elapsed since the SN stopped reporting related to the m-based QoE setting; that the SN has discontinued reporting related to m-based QoE settings; The SN has not received / transmitted user data to / from the UE for a period longer than a threshold time (e.g., an inactivity time at the SN); the SN is aware that the MN has discontinued reporting related to m-based QoE settings; the SN is aware that the MN has suspended reporting related to m-based QoE settings for an amount of time greater than a threshold; the SN has resumed RVQoE and / or QoE reporting associated with the m-based QoE configuration, but no RVQoE or QoE reports have been received since the resumption; the SN is aware that the MN has resumed RVQoE / QoE reporting related to the m-based QoE configuration, but no reports have been received since the resumption; the SN did not receive a QoE report related to the m-based QoE setting in question, or the SN did not receive any RVQoE report related to a RVQoE setting derived from the m-based QoE setting; that the SCG is deactivated; An SN handover is performed from a source SN to a target SN; the first network node wishes to update / modify its QoE settings, and the updated / modified QoE settings come from OAM; The UE transitions from RRC_CONNECTED to one of the non-CONNECTED states and the m-based QoE configuration initially configured was not intended for the non-RRC_CONNECTED state; The SN handover is from a gNB to an eNB (from a node that supports QoE measurements to a node that does not support QoE measurements); When the SN receives an RVQoE measurement report related to an m-based QoE configuration and determines that the quality of experience experienced by a UE / group of UEs is too low, the SN receives an instruction from the MN that the MN will take over the configuration / reconfigure the UE with the same m-based QoE configuration; the UE leaves an application session associated with the configured m-based QoE configuration; application sessions associated with the m-based QoE configuration are terminated; the SN receiving an indication from the MN that an m-based QoE configuration needs to be released due to an incoming s-based QoE configuration received by the MN for the same UE that takes precedence over an existing m-based QoE configuration; The SN initially configures the UE with m-based QoE so that it can also configure RVQoE measurements for the UE, and later decides to deconfigure the RVQoE measurements; the SN has determined that another UE would be a better target for the m-based QoE configuration than the current UE, and the SN's "quota" is full for the m-based QoE configuration, and therefore, when sending the QoE configuration to the other UE, the QoE configuration in the current UE needs to be released (here, the "quota" may be a number or percentage of UEs that may be determined based on an instruction from a gNB implementation (i.e., an implementation of the SN) or another entity / node, e.g., the entity / node that sends the m-based QoE configuration to the SN); The SN determines that the UE is a bad choice for this m-based QoE configuration, for example, because no application sessions of the service type associated with this m-based QoE configuration have been started for a long time; The SN receives an s-based QoE configuration for the same UE, for example, when the UE reports an insufficient quality of experience and the OAM sends an s-based configuration in response; The SN detects that an MN change (without a potential change of SN) is in progress (the SN may not want to implicitly release all m-based QoE configurations for UEs served with the original MN, but the SN may want to verify existing / ongoing m-based QoE configurations with the new MN, and the SN may indicate this to the new MN via a cause value). 31. The method of any preceding embodiment, based at least in part on one or more of:

[0269] 32. What is indicated by SN is Extensions to existing or newly defined UE or non-UE related NGAP or XnAP signaling, an indication of whether the SN has already deconfigured, or whether it intends to perform the configuration, or whether it requests the MN's permission to perform the configuration; An indication of whether the configuration is, has been, or is intended to be released for all UEs jointly served by the MN, or for only some UEs, or for only the indicated UEs. If the indication relates to a single UE, UE-associated node-to-node signaling (e.g., XnAP) may be used, but when the indication relates to multiple UEs (including all), non-UE-associated node-to-node signaling is used; the identity of the UE that is to be deconfigured, or has been deconfigured, or is intended to be deconfigured; The QoE reference and / or measConfigAppLayerId of the configuration being released, an indication that SRB3 and / or SBR5 for the UE (or "all UEs", or "any UE") are released or scheduled to be released; an indication of whether the measurement configuration is deleted from the SN (i.e., it cannot be configured for any more UEs) or whether it is stored (i.e., it can be configured for a UE at a later time); an indication of the reason / cause for deconfiguration, for example by sending a specific cause value to the MN, the cause value can be a reuse of an existing cause value or a new cause value; that the indicated reason / cause for the (e.g., intended, desired, requested, planned, or already performed) de-configuration of the m-based MN configuration may be any of the reasons / causes listed in step 1; In one alternative, the SN sends the IP address of the MCE to the MN; In one alternative, the SN sends the MCE ID to the MN; In one alternative, in addition to sending any or all of the above, the SN may also send RAN visible QoE configuration parameters to the MN if the SN independently configured the UE to report some RVQoE metrics, and the MN may reconfigure its RVQoE configuration if a new SN configures QoE measurements on the UE and / or instruct the new SN to configure / modify those RVQoE configurations with the UE by comparing it with the configuration of the previous SN. 32. The method of any preceding embodiment, comprising one or more of:

[0270] 33. To be determined by MN: indicating to the SN that it should notify the MN of any removal of the m-based QoE configuration (the request to the SN may contain or be associated with instructions for the information that the SN should send to the MN in case of removal of the QoE configuration); The MN may decide to release the configuration in the UE by itself or may instruct the SN to do so, while approving the release request proposed by the SN; Confirming the release indicated by the SN; Confirm the cancellation information received from SN; noting the information from the SN (i.e., not sending any response to the SN) and deciding on further actions; In particular, if the SN's reason for releasing the QoE configuration is related to SCG failure, SCG deactivation, UE leaving the NR-DC for single connectivity, or SN overload, approve the SN's request to release the m-based QoE configuration and forward the received report to the MN; When the reason for the QoE setting cancellation by the SN is recognized, the same QoE setting will also be cancelled. If the cause value indicates that the m-based QoE configuration was set by a previous MN in addition to indicating the responsible node, approve or reject the request (see bullet below); Maintaining the m-QoE measurement configuration in the UE and becoming responsible for it in the future (in this case, if it was the SN that forwarded the QoE reports to the MCE up until now, the MN needs to fetch the IP address and / or MCE ID of the MCE (unless it has already received it from the OAM or the SN) so that it can forward the reports to the MCE, or the MN can ask the SN for the IP address and / or MCE ID of the MCE); The MN's decision depends on the cause of the release (eg, planned, intended, desired, or requested), as indicated by the SN in step 2. If the cause is that an OAM entity / node or another RAN external entity / node (e.g., the entity / node that created the m-based QoE configuration or the entity / node that forwarded the m-based QoE configuration to the UE) has instructed the SN to release the m-based QoE configuration, the MN shall accept (or may have no choice but to accept) and approve the release; otherwise, the MN may decide to reject the release; If the cause is that an OAM entity / node or another RAN external entity / node (e.g., the entity / node that created the m-based QoE configuration or the entity / node that forwarded the m-based QoE configuration to the SN) has instructed the SN to release the m-based QoE configuration, or if the cause is that the UE has left the area range within the SN (e.g., none of the SCG cells is within the area range), the MN will accept (or may have no choice but to accept) and approve the release; otherwise, the MN may decide to reject the release; In any situation where the MN accepts or approves the release, or concludes that the SN has already released the m-based QoE configuration (e.g., any of the above examples), the MN may decide to send the m-based QoE configuration to the UE itself (after the SN releases it), provided that the MN receives the m-based QoE configuration and at least one of the UE's MCG cells is within its coverage area; that the MN's decision depends on whether the MN has received relevant m-based configuration (e.g., from an OAM entity / node); If the MN receives the m-based QoE configuration, the MN may accept / acknowledge the SN's release of the m-based QoE configuration, otherwise the MN may reject the release; Optionally, this decision may depend on the cause of the release (e.g. (planned, intended, wanted, requested, or already performed)) as indicated by the SN in step 2, e.g., if the cause of the release is that the release was instructed by an entity / node that has authority in the matter, e.g., an OAM entity / node or other RAN external entity / node (e.g., the entity / node that created the m-based QoE configuration or the entity / node that forwarded the m-based QoE configuration to the SN), the MN shall accept / acknowledge the SN's release of the m-based QoE configuration (or conclude that it has already been performed), regardless of whether the MN itself received the m-based QoE configuration; Optionally, if the MN accepts / approves the SN's release of the m-based QoE configuration (or if the release has already been performed), the MN may send the m-based QoE configuration to the UE on its own (provided that the MN has received the m-based QoE configuration); The MN's decision depends on whether the MN itself has the possibility to send the relevant m-based QoE configuration to the UE, and the prerequisite for this is that the MN has received the m-based QoE configuration (e.g., from an OAM entity / node) and that at least one of the UE's MCG cells is within its area range; If the MN itself can send the m-based QoE configuration to the UE, the MN will accept / approve the SN's release of the m-based QoE configuration; otherwise, the MN may reject the release; Optionally, this decision may depend on the cause of the release (e.g. (planned, intended, wanted, requested, or already performed)) as indicated by the SN in step 2, e.g. if the cause of the release is that the release is ordered by an entity / node that has authority in the matter, e.g. an OAM entity / node or other RAN external entity / node (e.g. the entity / node that created the m-based QoE configuration or the entity / node that forwarded the m-based QoE configuration to the SN), the MN shall accept / approve the SN's release of the m-based QoE configuration (or conclude that it has already been performed), regardless of whether the MN itself has the possibility to send the m-based QoE configuration to the UE; optionally, if the MN accepts / approves the SN's release of the m-based QoE configuration (or if the release has already been performed), the MN may itself send the m-based QoE configuration to the UE (if the prerequisites for doing so are met); In one embodiment, the MN may learn that the SN has deconfigured by the cause value in the MN-SN Adjustment Failure message sent from the SN to the MN in response to the MN-SN Adjustment Request for QoE. 33. The method of any preceding embodiment, comprising one or more of:

[0271] 34. In combination with sending the m-based QoE configuration to the UE, the MN and SN may perform some proactive coordination actions regarding possible subsequent situations in which the SN desires, intends, or plans to release the m-based QoE configuration, and the proactive coordination actions include the MN: Send a message to the MN requesting authorization to release the m-based QoE configuration in the UE, the instruction may further include that the SN should indicate the cause of the release situation; The SN sends a message to the MN to notify that the m-based QoE configuration in the UE is released, and the instruction may further include that the SN should indicate the cause of the release situation; The SN sends a message to the MN to notify that the m-based QoE configuration in the UE has been released, and the instruction may further include that the SN should indicate the cause of the release situation; notifying the SN that whether and when to cancel the m-based QoE configuration in the UE is entirely the SN's decision, and the MN may also instruct the SN to notify the MN if / when the SN cancels the m-based QoE configuration in the UE, and this instruction may include indicating the reason for the cancellation when it notifies the MN of the cancellation, and the MN may use this option (i.e., leaving it to the SN to decide whether and when to cancel the m-based QoE configuration in the UE) if, for example, the MN has not received the m-based QoE configuration, or if none of the UE's MCG cells are within its area range, or if none of the MN's cells are within its area range, or if none of the MN's cells adjacent to the SN's cell are within its area range; notifying the SN (secondary node) that if the cause of the release situation is one of a set of specific causes, it is entirely the SN's decision whether and when to release the m-based QoE configuration in the UE, where the set of specific causes may, for example, be that an OAM entity / node or another RAN external entity / node (e.g., an entity / node that created the m-based QoE configuration or an entity / node that forwarded the m-based QoE configuration to the SN) has instructed the SN to release the m-based QoE configuration; that the UE has left the coverage area of ​​the SN (e.g., none of the SCG cells are within the coverage area); if the cause is not included in this set of specific causes, the MN may instruct the SN to perform one or more of the following: send a message to the MN requesting authorization to release the m-based QoE configuration in the UE when the release situation occurs; the instruction may further include that the SN should indicate the cause of the release situation; The SN sends a message to the MN to notify that the m-based QoE configuration in the UE is to be released, and the instruction may further include that the SN should indicate the cause of the release situation; The SN sends a message to the MN notifying that the m-based QoE configuration in the UE has been released, and the instruction may further include that the SN should indicate the cause of the release situation; instructing the SN not to release the m-based QoE configuration despite a trigger for such release that the SN may detect, the instruction may further include that the SN should notify the MN when a release situation occurs and what the cause is; Instructing the SN not to release the m-based QoE configuration if the cause of the release situation is one of a set of specific causes, and for other causes of the release situation, the MN may further indicate a further instruction, for example, an instruction for the SN to send a message to the MN requesting authorization to release the m-based QoE configuration, and if the cause of the release situation is one of the set of specific causes and the SN does not release the m-based QoE configuration according to the instruction, the instruction may further include that the SN should notify the MN that a release situation has occurred and the cause thereof; instructs the SN that, if the causes of the release condition are different, non-overlapping sets, the SN should perform the following actions for each: if the cause of the release condition is one of the first set of causes, the SN should refrain from releasing the m-based QoE configuration; optionally, the SN should notify the MN that a release condition has occurred, and this notification of the MN may be selective based on the cause (as instructed by the MN); if the cause of the release condition is one of the second set of causes, the SN should send a message to the MN requesting authorization for the SN to release the m-based QoE configuration; if the cause of the release condition is one of the third set of causes, the SN can make its own decision on whether or when to release the m-based QoE configuration; and optionally, the SN should notify the MN of the release and its cause. 34. A method as in any preceding embodiment, comprising performing one or more of: instructing an SN to perform one or more of:

[0272] 35. A method according to any one of embodiments 1 to 34, wherein notification from an SN to an MN that the SN has released / intends to release an m-based QoE configuration for a UE may serve as an implicit indication to the MN that release has been / intends to be performed for all UEs configured by the SN with the m-based configuration in question.

[0273] 36. A method according to any preceding embodiment, wherein a notification from the SN may indicate to the MN that it has released / intends to release all m-based configurations for a particular UE.

[0274] 37. Obtaining user data; Forwarding user data to the host or user equipment 37. The method of any preceding embodiment, further comprising:

[0275] Group C Embodiments 38. A user equipment for handling quality of experience (QoE) measurements, comprising: processing circuitry configured to cause the user equipment to perform any of the steps recited in any one of the embodiments of Group A; a power supply circuit configured to supply power to the processing circuit; A user equipment comprising:

[0276] 39. A network node for handling quality of experience (QoE) measurements, comprising: processing circuitry configured to cause a network node to perform any of the steps recited in any one of the embodiments of Group B; a power supply circuit configured to supply power to the processing circuit; A network node comprising:

[0277] 40. A user equipment (UE) for handling quality of experience (QoE) measurements, comprising: an antenna configured to transmit and receive radio signals; a radio front-end circuit coupled to the antenna and to the processing circuit and configured to condition signals communicated between the antenna and the processing circuit; a processing circuit configured to perform any of the steps recited in any one of the embodiments of Group A; and an input interface coupled to the processing circuitry and configured to allow input of information to the UE to be processed by the processing circuitry; an output interface connected to the processing circuit and configured to output information processed by the processing circuit from the UE; a battery connected to the processing circuit and configured to power the UE; A user equipment (UE) comprising:

[0278] 41. A host configured to operate in a communication system for providing over-the-top (OTT) services, comprising: processing circuitry configured to provide user data; a network interface configured to initiate transmission of user data to a network node in a cellular network for transmission to a user equipment (UE), the network node having a communications interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations recited in any one of the embodiments of Group B to transmit the user data from a host to the UE; A host.

[0279] 42. processing circuitry of the host configured to execute a host application that provides user data; the UE comprising processing circuitry configured to execute a client application associated with the host application to receive user data transmissions from the host; A host described in embodiment 53.

[0280] 43. A method implemented in a host configured to operate in a communication system further including a network node and a user equipment (UE), comprising: Providing user data for the UE; Initiating a transmission carrying user data to the UE via a cellular network comprising a network node, the network node performing any of the operations described in any one of the embodiments of Group B to transmit the user data from the host to the UE; A method comprising:

[0281] 44. The method of embodiment 43, further comprising transmitting, at the network node, user data provided by the host for the UE.

[0282] 45. The method of embodiment 43 or 44, wherein user data is provided in the host by executing a host application that interacts with a client application running on the UE, and the client application is associated with the host application.

[0283] 1. A communication system configured to provide over-the-top (OTT) services, comprising: A host, a processing circuit configured to provide user data for a user equipment (UE), the user data relating to an over-the-top service; a network interface configured to initiate transmission of user data towards a cellular network node for transmission to the UE, the network node having a communications interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations recited in any one of the embodiments of Group B to transmit the user data from the host to the UE; A communication system comprising a host.

[0284] 47. network nodes, and / or The UE 47. The communication system of embodiment 46, comprising:

[0285] 48. A host configured to operate in a communication system for providing over-the-top (OTT) services, comprising: a processing circuit configured to initiate reception of user data; a network interface configured to receive user data from a network node in a cellular network, the network node having a communications interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations recited in any one of the embodiments of Group B to receive user data from a user equipment (UE) for a host; A host.

[0286] 49. processing circuitry of the host configured to execute a host application that receives user data; A host application is configured to interact with a client application executing on the UE, the client application being associated with the host application. A host according to embodiment 47 or 48.

[0287] 50. The host of embodiment 48 or 49, wherein initiating reception of user data includes requesting the user data.

[0288] 51. A method implemented by a host configured to operate in a communication system further including a network node and a user equipment (UE), comprising: Initiating reception, at the host, of user data from the UE, the user data originating from a transmission received by the network node from the UE, the network node performing any of the steps recited in any one of the embodiments of Group B to receive the user data from the UE for the host. A method comprising:

[0289] 52. The method of embodiment 51, further comprising, at the network node, transmitting the received user data to the host.

[0290] 53. A host configured to operate in a communication system for providing over-the-top (OTT) services, comprising: processing circuitry configured to provide user data; a network interface configured to initiate transmission of user data to a cellular network for transmission to a user equipment (UE), the UE having a communications interface and processing circuitry, the communications interface and processing circuitry of the UE configured to perform any of the operations described in any one of the embodiments of Group A to receive the user data from a host; A host.

[0291] 54. The host according to the previous embodiment, wherein the cellular network further includes a network node configured to communicate with the UE to transmit user data from the host to the UE.

[0292] 55. processing circuitry of the host configured to execute a host application and thereby provide user data; A host application is configured to interact with a client application executing on the UE, the client application being associated with the host application. A host according to embodiment 53 or 54.

[0293] 56. A method implemented by a host operating in a communication system further including a network node and a user equipment (UE), comprising: Providing user data for the UE; Initiating a transmission carrying user data to a UE via a cellular network comprising a network node, wherein the UE performs any of the operations described in any one of the embodiments of group A to receive the user data from a host; A method comprising:

[0294] 57. and further comprising: executing, at the host, a host application associated with the client application executing on the UE to receive user data from the host application. 57. The method of embodiment 56.

[0295] 58. transmitting, at the host, input data to a client application executing on the UE, the input data being provided by executing the host application; further comprising User data is provided by the client application in response to input data from the host application; 58. The method of embodiment 57.

[0296] 59. A host configured to operate in a communication system for providing over-the-top (OTT) services, comprising: processing circuitry configured to provide user data; a network interface configured to initiate transmission of user data to a cellular network for transmission to a user equipment (UE), the UE having a communications interface and processing circuitry, the communications interface and processing circuitry of the UE configured to perform any of the steps recited in any one of the embodiments of Group A to transmit the user data to a host; A host.

[0297] 60. The host of embodiment 59, wherein the cellular network further includes a network node configured to communicate with the UE to transmit user data from the UE to the host.

[0298] 61. processing circuitry of the host configured to execute a host application and thereby provide user data; A host application is configured to interact with a client application executing on the UE, the client application being associated with the host application. A host described in embodiment 59 or 60.

[0299] 62. A method implemented by a host configured to operate in a communication system further including a network node and a user equipment (UE), comprising: receiving, at the host, user data transmitted by the UE via the network node to the host; wherein the UE performs any of the steps recited in any one of the embodiments in group A to transmit user data to the host.

[0300] 63. executing, at the host, a host application associated with the client application executing on the UE for receiving user data from the UE; 63. The method of embodiment 62, further comprising:

[0301] 64. transmitting, at the host, input data to a client application executing on the UE, the input data being provided by executing the host application; further comprising User data is provided by the client application in response to input data from the host application; 64. The method of embodiment 62 or 63.

[0302] It should be noted that the above-described embodiments illustrate rather than limit the present idea, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word "comprising" does not exclude the presence of elements or steps other than those listed in a claim, and "a" or "an" does not exclude a plurality; a single processor or other unit may fulfill the functions of several units recited in a claim. Any reference signs in the claims should not be construed as limiting their scope.

[0303] appendix An example implementation of the solution in 3GPP TS38.331v17.4.0 is presented here, where the UE actions are described in the procedure text.

[0304] 5.3.5.10 MR-DC release The UE shall: 1> As a result of MR-DC deactivation triggered by E-UTRA or NR, 2> Release SRB3, if established, as specified in 5.3.5.6.2. 2> Release the measConfig associated with the SCG. 2> If the UE is configured with NR SCG, 3>Deconfigure the SCG as specified in section 5.3.5.4. 3> If set, unsets otherConfig associated with SCG. 3> Notify upper layers of the release of application layer measurement configuration associated with the SCG. 3> Discard any application layer measurement reports associated with the SCG received from upper layers. 3>Perform the release of SRB5, if established, as specified in 5.3.5.6.2. 3> Considers itself not configured to send application layer measurement reports to the SCG. 3> Stop timers T346a, T346b, T346c, T346d, T346e, T346j and T346k associated with the SCG if they are running. 3> If set, release the bap-Config associated with the SCG. 3> If there is no bap-Config configured, release the BAP entity as specified in TS38.340

[47] . 3> If configured, remove the iab-IP-AddressConfigurationList associated with the SCG 2>Otherwise, if the UE is configured with E-UTRA SCG, 3> To release the E-UTRA SCG, release the SCG setting as specified in TS36.331

[10] , section 5.3.10.19.

[0305] An example implementation of the solution in 3GPP TS36.331v17.4.0 is presented here, where the UE actions are described in the procedure text.

[0306] 5.3.10.19 NE-DC (NR-E-UTRA Dual Connectivity) Cancellation The UE shall: 1> NE-DC release is triggered by NR, 2> If set, resets the SCG Medium Access Control (MAC) 2> For each Radio Link Control (RLC) bearer that is part of the SCG configuration: 3>Perform the RLC bearer release procedures specified in 5.3.10.17 (SRB) and 5.3.10.2 (Data Radio Bearer, DRB). 2> Cancel the measurement settings. 2> Notify upper layers to clear any stored application layer measurement configuration associated with the SCG. 2> Discard the application layer measurement report information associated with the SCG received from the upper layer. 2> It is considered not to be configured to send application layer measurement reports to the SCG. 2> Release the SCG configuration, i.e. release the MAC and physical configuration for each cell that is part of the SCG configuration. 2> If it is running, stop timer T313 for the corresponding PSCell. 2> If it is running, stop timer T307 for the corresponding PSCell. Note: Upon NE-DC release, the UE releases all fields set by the RRCConnectionReconfiguration message.

Claims

1. 1. A method performed by a user equipment (UE) for processing quality of experience (QoE) measurements, comprising: Establishing (402) a connection to a primary network node of a network and a secondary network node of said network; Triggering (404) in the UE a release of the configuration for the QoE measurement; Including, The method, wherein the configuration is configured by the secondary network node and the release is triggered in response to termination of the connection to the secondary network node.

2. The method of claim 1 , wherein the termination of the connection to the secondary network node is due to a release of the secondary network node.

3. The method of claim 1 or 2, comprising releasing the secondary network node.

4. 4. The method of claim 1, comprising receiving a first message including information indicating the termination of the connection to the secondary network node.

5. The method of claim 4 , wherein the first message is a Radio Resource Control (RRC) reconfiguration message.

6. The method of claim 4 or 5, wherein the first message is received from the primary network node.

7. Triggering the unsetting is triggering deconfiguration from an application layer of the UE; Triggering the deconfiguration from an access stratum (AS) layer of the UE; 7. The method of claim 1, comprising one or both of:

8. The method of claim 7 , wherein triggering de-configuration from an application layer of the UE includes notifying the application layer to de-configure.

9. notifying the application layer to release the setting, The method of claim 8 , comprising indicating to the application layer one or more identifiers that identify the configuration.

10. 10. The method of claim 7, wherein triggering the release of the configuration from the application layer of the UE comprises releasing an Access Stratum (AS) layer portion of the configuration.

11. The method of claim 1 , comprising stopping the QoE measurements that are set by the secondary network node when the setting is deselected.

12. 12. A method according to any preceding claim, comprising releasing a signalling radio bearer (SRB) 5 in response to the release of the secondary network node.

13. SRB5 is released in response to the first network node receiving an instruction to release SRB5 from the second network node; or 13. The method of claim 12, wherein the SRB5 is released upon expiration of a predetermined time period configured to maintain the configuration.

14. 14. The method of claim 1, comprising handling unsent reports for the QoE measurements that are configured by the secondary network node and are to be unconfigured.

15. Handling the unsent report includes: sending a second message towards the secondary network node, the second message including the non-transmission report; deleting the non-transmitted report at the UE; including any one or both of:

15. The method of claim 14.

16. The method of claim 15 , wherein the second message is transmitted via the primary network node towards the secondary network node.

17. The method of claim 15 or 16, wherein the second message is sent before triggering the removal of the setting.

18. 18. The method of claim 1, wherein the removal of the configuration is triggered when the primary network node does not take over management of the configuration from the secondary network node.

19. 19. A method according to any preceding claim, comprising determining whether the primary network node has taken over management of the configuration from the secondary network node.

20. 20. The method of claim 1, comprising receiving an instruction from the primary network node to send remaining reports generated in accordance with the configuration to the primary network node instead of the secondary network node.

21. 21. The method of any one of claims 1 to 20, comprising sending an indication towards the primary network node regarding the availability of available reports on the QoE measurements.

22. 22. The method of claim 1, wherein the QoE measurements include Radio Access Network Visible QoE (RVQoE) measurements.

23. 1. A method performed by a first network node of a network for handling Quality of Experience (QoE) measurements, comprising: Establishing a connection to a user equipment (UE) (502); Triggering (504) in the UE a release of the configuration for the QoE measurement; Including, The method, wherein the configuration is configured by the first network node and the release is triggered in response to termination of the connection to the UE.

24. terminating the connection to the UE in response to receiving a request to terminate the connection to the UE, wherein the request is received from a second network node of the network through which a connection to the UE is established; providing information to the second network node of the network to which a connection to the UE is established, wherein the information is related to the first network node triggering the release; 24. The method of claim 23, comprising one or both of:

25. 25. The method of claim 24, wherein the information is provided in response to the first network node determining that the release should be triggered.

26. 26. A method according to claim 24 or 25, wherein the information is provided in response to the first network node receiving the request to terminate the connection to the UE.

27. 27. The method of claim 24, wherein triggering the release comprises triggering the release in response to the second network node granting permission to the first network node to trigger the release.

28. the information is provided prior to triggering the release and includes an indication that the first network node intends to trigger the release; the information is provided prior to triggering the release and includes a request to the second network node to grant permission to the first network node to trigger the release; or 28. The method of any one of claims 24 to 27, wherein the information is provided after triggering the release and includes an indication that the first network node has triggered the release.

29. The information is 29. The method of any one of claims 24 to 28, comprising an indication of whether the release is for only the UE, for a plurality of UEs, or for all UEs for which a connection is established for the second network node.

30. The method comprises:

30. A method according to any one of claims 24 to 29, comprising receiving an indication from the second network node that the first network node will provide the information.

31. the first network node is a primary network node and the second network node is a secondary network node; or 31. The method of any one of claims 24 to 30, wherein the first network node is the secondary network node and the second network node is the primary network node.

32. 32. The method of any one of claims 24 to 31, wherein the QoE measurements include Radio Access Network Visible QoE (RVQoE) measurements.

33. A user equipment (UE) (700), The UE (700), establishing a connection to a primary network node of a network and a secondary network node of said network; Triggering a release of the configuration for QoE measurement in the UE (700); a processing circuit (702) configured to cause Equipped with The user equipment (UE) (700), wherein the configuration is configured by the secondary network node and the release is triggered in response to termination of the connection to the secondary network node.

34. 34. The UE of claim 33, wherein the processing circuitry (702) is configured to cause the UE (700) to perform a method according to any one of claims 2 to 22.

35. A network node (800), The network node (800), Establishing a connection to a user equipment (UE); Triggering a release of a configuration for QoE measurement in the UE; a processing circuit (802) configured to cause Equipped with The network node (800), wherein the configuration is configured by the first network node and the release is triggered in response to termination of the connection to the UE.

36. 36. A network node (800) according to claim 35, wherein the processing circuitry (802) is configured to cause the network node (800) to perform a method according to any one of claims 24 to 32.

37. A computer program comprising instructions which, when executed by processing circuitry of a user equipment, cause the user equipment to carry out a method according to any one of claims 1 to 22.

38. 33. A computer program comprising instructions which, when executed by processing circuitry of a network node, cause the network node to perform the method of any one of claims 23 to 32.

39. 23. A computer program product embodied on a non-transitory machine-readable medium comprising instructions executable by processing circuitry of user equipment to cause said user equipment to perform the method of any one of claims 1 to 22.

40. 33. A computer program product embodied on a non-transitory machine-readable medium, the computer program product comprising instructions executable by processing circuitry of a network node to cause the network node to perform the method of any one of claims 23 to 32.

Images