Difference transmission between QoE report and RVQoE report

Abstract

Systems and methods related to Quality of Experience (QoE) and Radio Access Network (RAN) Visible QoE (RVQoE) measurement and reporting are disclosed. In one embodiment, a method performed by a user equipment (UE) includes receiving one or more messages including one or more QoE configurations and one or more RVQoE configurations from one or more network nodes. The method further includes receiving, for each QoE configuration or commonly for the one or more QoE configurations, an indication indicating a network node to which a respective QoE report is to be sent, and receiving, for each RVQoE configuration or commonly for the one or more RVQoE configurations, an indication indicating a network node to which a respective RVQoE report is to be sent. The method further includes performing QoE and RVQoE measurements and transmitting corresponding QoE and RVQoE reports according to the received indications.

Description

Technical Field

[0001] Related applications This application claims the benefit of Provisional Patent Application No. 63 / 420,337, filed October 28, 2022, the disclosure of which is hereby incorporated by reference in its entirety.

[0002] Technical field This disclosure relates to Quality of Experience (QoE) and Radio Access Network (RAN) Visual QoE (RVQoE) reporting in cellular communication systems.

Background Art

[0003] Overview of the QoE Framework and “Normal QoE” Quality of Experience (QoE) measurements, also referred to as “application layer measurements,” are defined in 3GPP Release 17 for the 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) and Universal Mobile Telecommunications System (UMTS), as well as for New Radio (NR). The purpose of application layer measurements is to measure the end-user experience when using a particular application. QoE measurements for streaming services and for Mobile Telephony Service for Internet Protocol (IP) Multimedia Subsystem (IMS) (MTSI) services are supported in LTE and UMTS, and for NR, Virtual Reality (VR) is also supported.

[0004] The general principle for typical QoE solutions in NR, LTE, and UMTS is similar, as follows: Quality of Experience Measurement Collection (QMC) enables the configuration of application layer measurements at the user equipment (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 configuration) received by the Radio Access Network (RAN) from the Operations, Management, and Maintenance (OAM) system or Core Network (CN) is encapsulated in a transparent container and forwarded to the UE in a downlink RRC message. The application layer measurement report (also called QoE report) received by the UE Access Stratum (UE AS) or UE RRC layer from the upper layer (application layer) of the UE is encapsulated in a transparent container and forwarded to the network in an uplink RRC message. The RAN then forwards the QoE report to the Measurement Collector Entity (MCE).

[0005] Configuration data related to QoE measurements (typically called application layer measurements in standard specifications) is received from the OAM by the base station (e.g., next-generation node B (gNB) for NR) and consists of a service type indication, an indication of the area where the measurement should be performed (indicated as area scope), the IP address of the entity to which the collected measurement results (i.e., QoE report) should be sent (often referred to as MCE, spelled measurement collector entity or measurement collection entity, this entity is sometimes also called trace collection entity), a set of instructions on what types of measurements should be performed and details on how these measurements should be performed. These instructions are targeted at the application layer within the UE and reside in a “container,” which is not interpreted or read by the network entity that handles it, for example, the one that forwards it to the UE, or the UE access stratum.

[0006] The container is forwarded to the UE in RRC signaling along with the indicated service type. For measurements in RRC_CONNECTED, the area is kept within the base station (e.g., gNB in ​​the case of NR), and the network ensures that the UE measures within the correct area by configuring the UE when starting and stopping measurements. The area scope is defined with respect to cells or network-related areas. In UMTS, the area scope is defined as either a list of cells, a list of routing areas, or a list of tracking areas. In LTE and NR, the area scope is defined as either a list of cells or a list of tracking areas.

[0007] QoE, and specifically QoE configuration, is offered in two flavors: management-based QoE configuration and signaling-based QoE configuration. In both cases, the QoE configuration originates from dealing with an OAM system or some other management entity, such as customer satisfaction. All of these entities are referred to as the OAM system in this document (the OAM system includes further entities). In management-based QoE (m-based QoE), the OAM system is typically interested in general QoE statistics from a specific area (configured as an area scope). The m-based QoE configuration is sent directly from the OAM system to the RAN nodes that control the cells within the area scope. Each RAN node then selects UEs within the area scope (and also meets any other relevant conditions such as supporting the relevant application / service type) and sends the m-based QoE configuration to these UEs.

[0008] In signaling-based QoE (s-based QoE), the OAM system is interested in collecting QoE measurement results from a specific UE, for example, because a user of the UE has filed a complaint. The OAM system transmits the s-based QoE configuration to the Home Subscriber Server (HSS) (in Advanced Packet System (EPS) / LTE) or Unified Data Management (UDM) (in Fifth Generation System (5GS) / NR), which forwards the QoE configuration to the UE's current Core Network (CN) node, for example, the Mobility Management Entity (MME) in EPS / LTE or the Access and Mobility Management Function (AMF) in 5G / NR. The CN then forwards the s-based QoE configuration to a RAN node that is useful to the UE in question, and the RAN node forwards it to the UE.

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

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

[0011] The RAN does not know when an application session with an associated QoE measurement session is in progress, nor does the UE access stratum automatically recognize this. To mitigate this, session start / stop indicators have been introduced, sent from the application layer within the UE to the UE AS, and from the UE AS to the RAN. A session end indicator is sent when the application session and its associated QoE measurement session are completed.

[0012] The RAN may, as an implementation-based decision, decide to release the QoE configuration at the UE at any given time. Typically, this occurs when the UE moves outside the area configured for the QoE measurement (commonly referred to as area scope) and the measurement session ends.

[0013] RAN Visible QoE (RVQoE) An extension to the QoE framework implemented in 3GPP Release 17 is the concept of RAN-Visible QoE (RVQoE). Normal QoE reports target entities outside the RAN, such as the MCE, which is part of the OAM system, and the RAN cannot read QoE reports (or at least does not conform to the specification, although gNB / eNB implementations are not prevented from doing so). In contrast, reported RVQoE metrics target the RAN and are delivered to the RAN in a format that the RAN understands. RVQoE metrics are derived from normal QoE metrics, collected, compiled into reports by the UE application layer, and delivered to the RAN, allowing the RAN to use the reports for various types of optimizations. For example, if the RAN receives an RVQoE report during an ongoing application session, the RAN can perform adaptive actions that affect the QoE of the application session in question while the application session is running, such as modifying various parameters related to UE scheduling and data flows related to the application session.

[0014] End-to-end explanation of QoE measurement End-to-end signaling for configuring QoE measurements is described in Chapter 4 of 3GPP Technical Specification (TS) 28.405v.18.0.0. Chapter 4.5 of 3GPP TS 28.405 describes the activation of control-based QoE in NR, as shown in Figure 1, which is a reproduction of Figure 4.6.1.1-1 (QMC activation and reporting in NR after UE registration) of 3GPP TS 28.405. Chapter 4.6 of 3GPP TS 28.405 describes the activation of signaling-based QoE in NR, as shown in Figure 2.

[0015] Configuration and Reporting of QoE and RVQoE Measurements at RRC The configuration of QoE and RVQoE measurements is performed by the RRC message RRCReconfiguration, and the report is sent in the RRC message MeasurementReportAppLayer according to the signaling flow illustrated in Figure 3.

[0016] RRCReconfiguration includes the information element AppLayerMeasConfig, which contains either a configuration container for a normal QoE configuration or RRC parameters for an RVQoE configuration, as shown below.

[0017] - AppLayerMeasConfig IE AppLayerMeasConfig shows the configuration for application layer measurement.

[0018] AppLayerMeasConfig information element -- ASN1START -- TAG-APPLAYERMEASCONFIG-START AppLayerMeasConfig-r17 ::= SEQUENCE { measConfigAppLayerToAddModList-r17 SEQUENCE (SIZE (1..maxNrofAppLayerMeas-r17)) OF MeasConfigAppLayer-r17 OPTIONAL, -- Need N measConfigAppLayerToReleaseList-r17 SEQUENCE (SIZE (1..maxNrofAppLayerMeas-r17)) OF MeasConfigAppLayerId-r17 OPTIONAL, -- Need N rrc-SegAllowed-r17 ENUMERATED {enabled} OPTIONAL, -- Need R ... } MeasConfigAppLayer-r17 ::= SEQUENCE { measConfigAppLayerId-r17 MeasConfigAppLayerId-r17, measConfigAppLayerContainer-r17 OCTET STRING (SIZE (1..8000)) OPTIONAL, -- Need N serviceType-r17 ENUMERATED {streaming, mtsi, vr, spare5, spare4, spare3, spare2, spare1} OPTIONAL, -- Need M pauseReporting-r17 BOOLEAN OPTIONAL, -- Need M transmissionOfSessionStartStop-r17 BOOLEAN OPTIONAL, -- Need M ran-VisibleParameters-r17 SetupRelease {RAN-VisibleParameters-r17} OPTIONAL, -- Cond serviceType ... } RAN-VisibleParameters-r17 ::= SEQUENCE { ran-VisiblePeriodicity-r17 ENUMERATED {ms120, ms240, ms480, ms640, ms1024} OPTIONAL, -- Need S numberOfBufferLevelEntries-r17 INTEGER (1..8) OPTIONAL, -- Need R reportPlayoutDelayForMediaStartup-r17 BOOLEAN OPTIONAL, -- Need M ... } -- TAG-APPLAYERMEASCONFIG-STOP -- ASN1STOP

[0019] JPEG0007897417000001.jpg1241,69

[0020] JPEG0007897417000,002.jpg531,69

[0021] JPEG0007897417000,003.jpg171,69

[0022] The MeasurementReportAppLayer contains either a report container for normal QoE or RRC parameters for the RVQoE report, as shown below.

[0023] -MeasurementReportAppLayer The MeasurementReportAppLayer message is used to send an application layer measurement report. Signaling Radio Bearer: SRB4 RLC-SAP: AM<00001,14>Logical Channel: DCCH<00001,15> Note: In the translation, for the numbers in the form of "JPEG0007897417000001.jpg124169", it seems that there is a formatting issue in the original text. I assume it might be separated by commas for better readability in the translation. If this is not the correct understanding, please provide more context or clarify the format requirements.Direction: From UE to Network

[0024] MeasurementReportAppLayer message -- ASN1START -- TAG-MEASUREMENTREPORTAPPLAYER-START MeasurementReportAppLayer-r17 ::= SEQUENCE { criticalExtensions CHOICE { measurementReportAppLayer-r17 MeasurementReportAppLayer-r17-IEs, criticalExtensionsFuture SEQUENCE {} } } MeasurementReportAppLayer-r17-IEs ::= SEQUENCE { measurementReportAppLayerList-r17 MeasurementReportAppLayerList-r17, lateNonCriticalExtension OCTET STRING OPTIONAL, nonCriticalExtension SEQUENCE{} OPTIONAL } MeasurementReportAppLayerList-r17 ::= SEQUENCE (SIZE (1..maxNrofAppLayerMeas-r17)) OF MeasReportAppLayer-r17 <0000​​​​measReportAppLayerContainer-r17 OCTET STRING OPTIONAL, appLayerSessionStatus-r17 ENUMERATED {started, stopped} OPTIONAL, ran-VisibleMeasurements-r17 RAN-VisibleMeasurements-r17 OPTIONAL } RAN-VisibleMeasurements-r17 ::= SEQUENCE { appLayerBufferLevelList-r17 SEQUENCE (SIZE (1..8)) OF AppLayerBufferLevel-r17 OPTIONAL, playoutDelayForMediaStartup-r17 INTEGER (0..30000) OPTIONAL, pdu-SessionIdList-r17 SEQUENCE (SIZE (1..maxNrofPDU-Sessions-r17)) OF PDU-SessionID OPTIONAL, ... } AppLayerBufferLevel-r17 ::= INTEGER (0..30000) -- TAG-MEASUREMENTREPORTAPPLAYER-STOP -- ASN1STOP

[0025] JPEG0007897417000004.jpg43170

[0026] JPEG0007897417000005.jpg68169

[0027] In the existing specifications, the network can only configure RVQoE if a corresponding configuration for regular QoE also exists within the UE.

[0028] QoEmetrics for Streaming Services The specification relating to the QoE metric for progressive downloads and 3GPP Adaptive Hypertext Transfer Protocol (HTTP) streaming, known as 3GP-DASH, can be found in 3GPP TS 26.247, Section 10.

[0029] The following metrics must be supported by a progressive download client that supports the QoE reporting function. - Average throughput, - Initial playout delay, - Buffer level, - Playlist, - Device information.

[0030] The following metrics must be supported by a 3GP-DASH client that supports the QoE reporting function. - List of expression switching events, - Average throughput, - Initial playout delay, - Buffer level, - Playlist, - MPD information, - Device information.

[0031] AT command AT commands are used for communication between the AS (Radio System) layer and the application layer in a UE (Unified Environment). AT commands are defined in 3GPP TS 27.007 version 17.6.0. In QoE (Quality of Environment), AT commands are used for transferring configurations from the RRC (Radio Relay) layer to the application layer, and for transferring reports from the application layer to the RRC layer.

[0032] 3GPP Dual Connectivity In 3GPP Rel-12, Dual Connectivity (DC), an LTE feature, was introduced to allow a UE to be connected in two cell groups, with each of the two cell groups controlled by an LTE access node, eNB, labeled as a Master eNB (MeNB) and a Secondary eNB (SeNB). The UE still has only one RRC connection to the network. In 3GPP, the Dual Connectivity (DC) solution has since been developed and is now specified for NR as well as between LTE and NR. Multi-Connectivity (MC) involves more than two nodes. With the introduction of 5G, the term MR-DC (Multi-Radio Dual Connectivity, see also 3GPP TS37.340) was defined as a general term for all dual connectivity options involving at least one NR access node. Using terminology generalized in MR-DC, a UE is connected to a Master Cell Group (MCG) controlled by a Master Node (MN) and a Secondary Cell Group (SCG) controlled by a Secondary Node (SN).

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

[0034] There are various ways to deploy 5G networks, with or without interworking with LTE and the Advanced Packet Core (EPC), also known as E-UTRA. In principle, NR and LTE can be deployed without any interworking, as indicated by NR Standalone (SA) operation, also known as Option 2, i.e., gNBs in NR can be connected to the 5G core network (5GC), and eNBs in LTE can be connected to the EPC without interconnection between the two, also known as Option 1.

[0035] On the other hand, the first supported version of NR uses dual connectivity, indicated as EN-DC (E-UTRAN-NR Dual Connectivity), also known as Option 3, as shown in Figure 5. In such a deployment, dual connectivity between NR and LTE is applied, and the UE is connected to both the LTE radio interface to the LTE access node (LTE Uu in the figure) and the NR radio interface to the NR access node (NR Uu in the figure). Furthermore, in EN-DC, the LTE access node acts as the master node (known in this case as the master eNB, or MeNB) and controls the master cell group MCG, while the NR access node acts as the secondary node (sometimes known in this case as the secondary gNB, or SgNB) and controls the secondary cell group SCG. The SgNB does not need to have a control plane connection to the MeNB, in this case the core network (EPC) where NR is provided. This is also called “non-standalone NR” ​​or simply “NSA NR”. In this case, the functionality of the NR cells will be limited and they will be used as boosters and / or diversity legs in connected mode UEs, but note that RRC_IDLE UEs cannot camp on to these NR cells.

[0036] With the introduction of 5GC, other options may also become viable. As mentioned above, Option 2 supports a standalone NR deployment where a gNB connects to a 5GC. Similarly, LTE can also connect to a 5GC using Option 5 (also known as eLTE, E-UTRA / 5GC, or LTE / 5GC, where the node may be called an ng-eNB). In these cases, both NR and LTE are considered part of the NG-RAN (and both ng-eNBs and gNBs may be called NG-RAN nodes).

[0037] It is worth noting that other variations of dual connectivity between LTE and NR, standardized as part of NG-RAN connected to 5GC, also exist. Under the MR-DC umbrella, these include: ●EN-DC (Option 3): LTE is the master node and NR is the secondary node (EPC CN is used as shown in Figure 5). ●NE-DC (Option 4): NR is the master node and LTE is the secondary (5GCN is used). ●NGEN-DC (Option 7): LTE is the master node and NR is the secondary (5GCN is used). ●NR-DC (Variation of Option 2): Dual connectivity where both the master node MN controlling the MCG and the secondary node SN controlling the SCG are NR (as shown in Figure 6, 5GCN is used). [Overview of the Initiative]

[0038] Systems and methods relating to the measurement and reporting of perceived quality (QoE) and radio access network (RAN) visible quality (RVQoE) are disclosed. In one embodiment, a method performed by a user device (UE) comprises receiving one or more messages from one or more network nodes, including one or more QoE configurations and one or more RVQoE configurations. The method further comprises receiving an indication for each QoE configuration, or in common for the one or more QoE configurations, that indicates the network node to which the respective QoE report is transmitted. The method further comprises receiving an indication for each RVQoE configuration, or in common for the one or more RVQoE configurations, that indicates the network node to which the respective RVQoE report is transmitted. The method further comprises performing QoE measurements and RVQoE measurements according to the one or more QoE configurations and the one or more RVQoE configurations. The method further comprises transmitting each of the one or more QoE reports containing the results of the QoE measurement to the indicated network node to which the QoE report is transmitted. The method further comprises transmitting each of the one or more RVQoE reports containing the results of the QoE measurement to the indicated network node to which the QoE report is transmitted. In this way, the QoE report and the RVQoE report may be routed to different entities.

[0039] In one embodiment, the network node to which a QoE report is sent for at least one of the one or more QoE configurations is different from the network node to which an RVQoE report is sent for at least one of the one or more RVQoE configurations.

[0040] In one embodiment, the method includes receiving an indication for each QoE configuration that indicates the network node to which each QoE report is transmitted. In one embodiment, for each of the one or more QoE configurations, the indication that indicates the network node to which each QoE report is transmitted is either the QoE configuration or a message (one or more) that may contain the QoE configuration. In one embodiment, for at least one of the one or more QoE configurations, the indication that indicates the network node to which each QoE report is transmitted is an indication of a signaling radio bearer (SRB) for transmitting each of the QoE reports.

[0041] In one embodiment, the method includes receiving an indication for each RVQoE configuration that indicates the network node to which each RVQoE report is transmitted. In one embodiment, for each of the one or more RVQoE configurations, the indication that indicates the network node to which each RVQoE report is transmitted is included in either the RVQoE configuration or one or more messages containing the RVQoE configuration. In one embodiment, for at least one of the one or more RVQoE configurations, the indication that indicates the network node to which each RVQoE report is transmitted is an SRB indication for transmitting each of the RVQoE reports.

[0042] In one embodiment, the method includes receiving an indication common to all of the one or more QoE configurations that indicates a common network node to which QoE reports are sent. In one embodiment, the indication of the common network node to which QoE reports are sent is included in either at least one of the one or more QoE configurations or in one or more messages that include at least one of the one or more QoE configurations.

[0043] In one embodiment, the method includes receiving an indication common to all of one or more RVQoE configurations that indicates a common network node from which each RVQoE report is transmitted. In one embodiment, the indication of the common network node from which the RVQoE report is transmitted is contained in either at least one of the one or more RVQoE configurations or in one or more messages that include at least one of the one or more RVQoE configurations. In one embodiment, the indication of the common network node from which the RVQoE report is transmitted is an indication of the SRB for transmitting the RVQoE report.

[0044] Corresponding embodiments of the UE are also disclosed. In one embodiment, the UE is adapted to receive one or more messages from one or more network nodes, including one or more QoE configurations and one or more RVQoE configurations. The UE is further adapted to receive an indication for each QoE configuration, or in common for the one or more QoE configurations, indicating the network node to which each QoE report is sent. The UE is further adapted to receive an indication for each RVQoE configuration, or in common for the one or more RVQoE configurations, indicating the network node to which each RVQoE report is sent. The UE is further adapted to perform QoE measurements and RVQoE measurements according to the one or more QoE configurations and the one or more RVQoE configurations. For each of the one or more QoE reports containing the results of the QoE measurements, the UE is further adapted to transmit the QoE report to the indicated network node to which the QoE report is sent. The UE is further adapted to transmit each of the RVQoE reports, among one or more RVQoE reports containing the results of the QoE measurement, to the indicated network node to which the QoE report is transmitted.

[0045] In one embodiment, the UE includes a communication interface and a processing circuit associated with the communication interface. The processing circuit is configured to cause the UE to receive one or more messages from one or more network nodes, including one or more QoE configurations and one or more RVQoE configurations. The processing circuit is further configured to cause the UE to receive an indication for each QoE configuration, or in common for one or more QoE configurations, that indicates the network node to which each QoE report is transmitted. The processing circuit is further configured to cause the UE to receive an indication for each RVQoE configuration, or in common for one or more RVQoE configurations, that indicates the network node to which each RVQoE report is transmitted. The processing circuit is further configured to cause the UE to perform QoE measurements and RVQoE measurements according to the one or more QoE configurations and the one or more RVQoE configurations. The processing circuit is further configured to cause the UE to transmit each of the one or more QoE reports, which include the results of the QoE measurement, to the indicated network node to which the QoE report is transmitted. The processing circuit is further configured to cause the UE to transmit each of the one or more RVQoE reports, which include the results of the QoE measurement, to the indicated network node to which the QoE report is transmitted.

[0046] Embodiments of methods performed by a first network node are also disclosed. In one embodiment, a method performed by a first network node comprises sending one or more messages to a UE, each containing one or more QoE configurations and one or more RVQoE configurations. The one or more messages further include, for each QoE configuration, or in common for one or more QoE configurations, an indication of the network node to which the respective QoE report is sent, and for each RVQoE configuration, or in common for one or more RVQoE configurations, an indication of the network node to which the respective RVQoE report is sent.

[0047] A corresponding embodiment of the first network node is also disclosed.

[0048] Embodiments of methods performed by a second network node are also disclosed. In one embodiment, the method performed by the second network node comprises receiving one or more messages from the UE, each containing one or more QoE reports associated with one or more QoE configurations and one or more RVQoE reports associated with one or more RVQoE configurations. For each QoE configuration, or in common for the one or more QoE configurations, the UE is either composed of or determines the network node to which each QoE report is sent. For each RVQoE configuration, or in common for the one or more RVQoE configurations, the UE is either composed of or determines the network node to which each RVQoE report is sent.

[0049] A corresponding embodiment of the second network node is also disclosed. [Brief explanation of the drawing]

[0050] The accompanying drawings, incorporated into and forming part of this specification, illustrate several aspects of this disclosure and, together with the description, help to illustrate the principles of this disclosure. [Figure 1] This is a reproduction of Figure 4.6.1.1-1 (Activation and Reporting of Quality of Experience (QoE) Measurement Collector (QMC) in New Radio (NR) after User Equipment (UE) Registration) from the Third Generation Partnership Project (3GPP) Technical Specification (TS) 28.405 V18.0.0. [Figure 2] This document describes the activation of signaling-based QoE in NR. [Figure 3] This document describes the configuration of QoE and Wireless Access Network (RAN) Visible QoE (RVQoE) measurement and reporting, as well as the signaling flow for QoE and RVQoE reporting. [Figure 4] This section explains an example of a combination of dual connectivity (DC) and carrier aggregation (CA). [Figure 5] Let's explain an example of a DC. [Figure 6] Let's describe another variation of DC. [Figure 7] This is a flowchart illustrating the operation of a wireless terminal (also called a user device UE) for QoE / RVQoE measurement configuration and reporting according to embodiments of the present disclosure. [Figure 8] The operation of a network node configured as a master node (MN) for a UE for QoE measurement configuration and reporting, according to one embodiment of this disclosure, is described. [Figure 9] The operation of a network node configured as a secondary node (SN) for a UE for QoE measurement configuration and reporting, according to embodiments of this disclosure, is described. [Figure 10] Examples of communication systems according to several embodiments are shown. [Figure 11] The following UEs are shown according to several embodiments. [Figure 12] The following network nodes are shown according to several embodiments. [Figure 13] This is a block diagram of a host, which may be an embodiment of the host shown in Figure 10, following the various aspects described in this book. [Figure 14]This block diagram shows a virtualization environment in which the functions implemented by several embodiments may be virtualized. [Figure 15] The diagram shows a host communicating with a UE via a network node over a partially wireless connection according to several embodiments. [Modes for carrying out the invention]

[0051] The embodiments described below are intended to provide information that will enable those skilled in the art to implement the embodiments and to describe the best modes of implementation. By reading the following description in reference to the accompanying drawings, those skilled in the art will understand the concepts disclosed and recognize applications of these concepts not specifically addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.

[0052] Currently, several challenges exist. Quality of Experience (QoE) reports and Radio Access Network (RAN) Visible QoE (RVQoE) reports serve entirely different purposes; the former is primarily application-level feedback for offline analysis and long-term adaptation, while the latter is real-time feedback from application to RAN for immediate adaptation of ongoing application session processing. In the current 3GPP specification, QoE and RVQoE measurement reports are always reported in the same manner according to the same configuration, for example, to the same node in the case of New Radio (NR) Dual Connectivity (NR-DC). This is an unnecessary limitation, especially since the reports serve different purposes and have different recipients.

[0053] The present disclosure and certain aspects of these embodiments may provide solutions to these or other problems. For example, embodiments of systems and methods are disclosed herein that provide solutions for directing QoE reports and RVQoE reports to specific network nodes in a dual connectivity scenario (e.g., an NR-DC scenario). This may be achieved by configuring a UE with an indication that shows the node or cell group to which the QoE report should be sent, and an indication that shows the node to which the RVQoE report should be sent. The indications may include, for example, any one or more of the following indications: - Explicit indication of nodes or cell groups (e.g., master cell group (MCG), secondary cell group (SCG)). - An indication that sends a report to a cell group that carries the data flow (one or more) of the application session to which the report relates. - Indication of the signaling radio bearer (SRB) used for transmission. - An (explicit or implicit) indication that a report should be sent to the node that submitted the configuration. - An (explicit or implicit) indication that the report should be sent to a node that processes one or more data radio bearers (DRBs) that carry the data flow of one or more application sessions to which the report relates.

[0054] An explicit or implicit indication that a user device (UE) can autonomously decide which (one or more) nodes to send a report to.

[0055] If a UE has QoE or RVQoE reports to send, the UE sends the reports according to the indications included in the configuration. In one embodiment, if the report targets the master node (MN) in the case of dual connectivity, the UE may use a MeasurementReportAppLayer message to send the report to the MN. In one embodiment, if the report targets the secondary node (SN), the UE may use a ULInformationTransferMRDC message along with an encapsulated MeasurementReportAppLayer message for the SN. In one embodiment, the encapsulated MeasurementReportAppLayer message may be transferred from the MN to the SN in an XnAP RRC TRANSFER message. Alternatively, the UE may be configured with SRB3 or SRB5 for direct transmission to the SN. In both of these options, there is a clear separation between messages targeting the MN and messages targeting the SN. Using the option to configure different nodes for QoE and RVQoE reports, the network can direct reports to the node that is the preferred receiver of the report.

[0056] Certain embodiments may provide one or more of the following technical advantages. Embodiments of the Disclosure may allow greater flexibility in sending QoE and RVQoE reports. In this solution, RVQoE reports may be routed to RAN nodes that are the target recipients of the report, while QoE reports for operational, management, and maintenance (OAM) purposes may be routed to different RAN nodes. This is advantageous because QoE reports can be large, and since these reports target specific nodes, it is beneficial if the network can be configured to send these reports to less loaded nodes without having to configure shorter RVQoE reports to less loaded nodes as well.

[0057] 1. Notes and Terminology In some embodiments described below, a radio access network (RAN) sends a request to a user device (UE) for one or more RAN visible quality of experience (RVQoE) reports. Such a request may be referred to as an indication to the UE for sending one or more RVQoE reports, or an indication of a fulfillment or RAN event (or one or more RAN events) to trigger an RVQoE report.

[0058] Many field (i.e., parameter) names or information element (IE) names in the Radio Resource Control (RRC) configuration for new radios (NR) (3GPP TS 38.331 version 17.1.0) are referred to either with a postfix indicating the 3GPP standard release (e.g., "-r17" indicating 3GPP release 17) or with the same name without a postfix. The version with the postfix is ​​used in the ASN.1 code, while the version without the postfix is ​​used in other texts of this specification. In this document, where applicable (i.e., where both versions of the field name exist in 3GPP TS 38.331 version 17.1.0), the two versions of the name are used interchangeably. For example, the names "AppLayerMeasConfig" and "AppLayerMeasConfig-r17" refer to the same IE.

[0059] RAN nodes include Next Generation Node B (gNB), Advanced Node B (eNB), en-gNB, Next Generation eNB (ng-eNB), gNB Central Unit (gNB-CU), gNB-CU Control Plane Section (gNB-CU-CP), gNB-CU User Plane Section (gNB-CU-UP), eNB Central Unit (eNB-CU), eNB-CU Control Plane Section (eNB-CU-CP), eNB-CU User Plane Section (eNB-CU-UP), Integrated Access and Backhaul (IAB) Nodes, IAB Donor Distributed Units (DU), IAB Donor Central Units (CU), IAB-DU, IAB Mobile Termination (IAB-MT), Open RAN CU (O-CU), O-CU Control Plane Section (O-CU-CP), O-CU User Plane Section (O-CU-UP), Open RAN Distributed Unit (O-DU), Open RAN Radio Unit (O-RU), and Open RAN These could be eNBs (O-eNBs), non-real-time RAN intelligent controllers (Non-RT RICs), real-time RAN intelligent controllers (RT-RICs), etc.

[0060] The terms “Application Layer Measurement Configuration,” “Application Measurement Configuration,” “QoE Measurement Configuration,” “QoE Configuration,” “QoE Measurement and Reporting Configuration,” and “QMC Configuration” are used interchangeably. However, it should be noted that “QMC Configuration File” is not an equivalent term and instead refers to a portion of the QoE configuration consisting of an XML file containing instructions such as the QoE metrics to be collected.

[0061] The solutions proposed in this book (one or more) are applicable to both signaling-based and management-based quality of experience (QoE) measurements (although they may optionally be limited to applying to only one of them).

[0062] The terms “QoE report” and “QoE measurement report” are used interchangeably. Similarly, the terms “RAN visible QoE report,” “RAN visible QoE measurement report,” “RVQoE report,” and “RVQoE measurement report” are used interchangeably.

[0063] The terms “QoE configuration” and “QoE measurement configuration” are used interchangeably. Similarly, the terms “RVQoE configuration” and “RVQoE measurement configuration” are used interchangeably.

[0064] The terms “access stratum” and “wireless layer” are used interchangeably when referring to the UE (Unified Engineer).

[0065] The (one or more) solutions are equally applicable to QoE and RAN visible QoE measurement and reporting, meaning that, among other things, the considerations for QoE configuration, QoE measurement and QoE reporting also apply to RVQoE configuration, RVQoE measurement and RVQoE reporting.

[0066] One or more solutions are presented in the example of a UE in dual connectivity, but the UE may also be applicable to wireless access technologies where more than two legs are utilized.

[0067] The solutions proposed in this book are applicable to NR and future radio access technologies (RATs) such as 6G, where IAB-MT is the parent backhaul link termination function and IAB-DU is the access service provision function of the relay node.

[0068] "Sending a report to a node" may or may not mean that the node is a consumer, i.e., the final destination of the report.

[0069] The terms “node” and “network node” are used interchangeably throughout this document.

[0070] Sending to the master node (MN) or the secondary node (SN) means using carriers within the master cell group (MCG) and carriers within the secondary cell group (SCG), respectively.

[0071] 2. Overview As described above, QoE reports and RVQoE reports serve entirely different purposes. This is reflected in the fact that the RAN forwards QoE reports (uninterpreted) to the Measurement and Collection Entity (MCE), while RVQoE reports are kept within the RAN, analyzed, and used as a basis for possible adaptations to the processing of ongoing application session data flows. This is an existing example of variance processing for QoE and RVQoE reports. However, other aspects of variance processing for QoE and RVQoE reports may be beneficial, especially as the QoE / RVQoE framework is extended with new service types, scenarios, and features. One such specific example is targeted by the embodiments of the proposed (one or more) solutions.

[0072] When the QoE / RVQoE framework in 3GPP Release 18 is extended to be applicable to NR Dual Connectivity (NR-DC) scenarios, the different purposes of QoE measurement / reporting and RVQoE measurement / reporting imply that different network nodes (i.e., MN and SN) can be preferred receivers of QoE reports and RVQoE reports. In particular, RVQoE reports are preferably sent to nodes that can influence the processing of the data flow of the application session to which the RVQoE report relates, i.e., nodes that process the data flow of the application session to which the RVQoE report relates.

[0073] As an example, consider an NR-DC mode UE with different gNBs acting as MN and SN, respectively. Furthermore, the MN receives signaling-based QoE configurations from the Core Network (CN) (i.e., the Access and Mobility Management Function (AMF)) and forwards them to the relevant UEs, and the RAN (MN, SN, or both working together) also configures the UEs with corresponding RVQoE measurements. If the data flow of application sessions of service types targeted by the QoE and RVQoE configurations is then transmitted via the SN (i.e., over the SCG bearer), the network might want the QoE report to go to the MN and the RVQoE report to go to the SN.

[0074] This can be achieved in many ways.

[0075] One approach is to leverage a legacy mechanism that transfers Radio Resource Control (RRC) messages from the UE to the SN via the MN, embedded in the transfer message. On the Uu interface between the UE and the MN, such a transfer message is a ULInformationTransferMRDC RRC message. On the Xn interface, such a transfer message is an RRC TRANSFER XnAP message. Using this legacy mechanism, the UE can, for example, send a MeasurementReportAppLayer RRC message containing a QoE report to the MN as a regular RRC message, while a MeasurementReportAppLayer RRC message containing an RVQoE report can be encapsulated in a ULInformationTransferMRDC RRC message sent to the MN. The MN then extracts the MeasurementReportAppLayer RRC message containing the RVQoE report from the ULInformationTransferMRDC RRC message and transfers the extracted MeasurementReport RRC message to the SN in an RRC TRANSFER XnAP message. (Since SRB3 (see next paragraph) has been introduced into the standard to enable direct forwarding of RRC messages from the UE to the SN, the above encapsulation and forwarding mechanisms are primarily intended for use when SRB3 is not configured or implemented.)

[0076] Another approach is to utilize signaling radio bearers (SRBs) that are inherently intended for different nodes. For example, a UE could send a QoE report to the MN on SRB4 and an RVQoE report to the SN on SRB3. A new signaling radio bearer, designated SRB5, could be used instead of SRB3 for sending QoE / RVQoE reports to the SN. The introduction of such a new signaling radio bearer (SRB5) for the purpose of sending QoE and RVQoE reports to the SN is currently being discussed within 3GPP. In the current example, the UE could send a QoE report to the MN on SRB4 and an RVQoE report to the SN on SRB5.

[0077] As mentioned above, the choice to send QoE reports to MN and RVQoE reports to SN is merely an example; it should be noted that the opposite, namely sending QoE reports to SN and RVQoE reports to MN, is also consistent with the proposed solution, as is sending both QoE and RVQoE reports to the same node, i.e., either MN or SN.

[0078] This type of difference processing for QoE and RVQoE reports requires new signaling possibilities to instruct the UE to send a QoE report to the MN on SRB4 and an RVQoE report to the SN on SRB3 or SRB5, or to send a QoE report to the MN but encapsulate the RVQoE report in a ULInformationTransferMRDC RRC message (i.e., to send an RVQoE report, include the RVQoE report parameters related to the MeasurementReportAppLayer RRC message, encapsulate the MeasurementReportAppLayer RRC message in a ULInformationTransferMRDC RRC message, and send the ULInformationTransferMRDC RRC message to the MN). In such control signaling, an instruction to send a particular type of report to a particular node may have any one or more of the following formations, for example: - Indication of nodes (e.g., MN, SN). - An indication that sends a report to a node that carries the data flow (one or more) of the application session to which the report relates. - Indication of cell groups (e.g., MCG, SCG), - An indication that sends a report to a cell group that carries the data flow (one or more) of the application session to which the report relates. - Indication of the SRB for transmission (for example, SRB4 implies MN, SRB5 implies SN). - Indication that a MeasurementReportAppLayer message containing a specific report type should be included in a message used to encapsulate a message being transferred from MN to SN (or vice versa) (e.g., a ULInformationTransferMRDC RRC message). - The absence of an indication may implicitly indicate that a report should be sent to the node that submitted the configuration. - The absence of an indication may implicitly indicate that the report should be sent to a node processing one or more DRBs that carry the data flow of one or more application sessions to which the report relates. - The absence of an indication may implicitly indicate that the UE can autonomously decide which node to send the report to.

[0079] Through such instructions, the UE's QoE / RVQoE report transmission behavior can be controlled on a per-QoE / RVQoE configuration basis, or collectively, for all QoE / RVQoE configurations in the UE, depending on which IE level the control parameters are placed in according to the ASN.1 definition (for example, based on the ASN.1 definition in 3GPP TS38.331 version 17.2.0), such as AppLayerMeasConfig-r17 IE or MeasConfigAppLayer-r17 IE and / or RAN-VisibleParameters-r17 IE. Examples are provided in Section 3.2 below.

[0080] In Section 3, embodiments of the proposed solutions are further described with respect to methods / embodiments for UE, MN, and SN, respectively.

[0081] 3 Embodiments 3.1 Configuration and Reporting of QoE and RVQoE Measurements with Option to Send QoE and RVQoE Reports to Different Nodes It should be noted that in all methods described in this section, the roles of MN and SN may be reversed. That is, actions performed by MN in the description of a method may be performed by SN, and vice versa. Similarly, the interactions that a UE has with MN and SN may be swapped between MN and SN, respectively. As described, this method is generally applicable even after such swaps. Furthermore, the configurations related to QoE reports and RVQoE reports may be swapped, and therefore any configuration is possible for both QoE and RVQoE, respectively. In RRC TS38.331, the terms MN and SN are not commonly used, but a UE consists of an MCG (Master Cell Group) associated with MN and an SCG (Secondary Cell Group) associated with SN.

[0082] 3.1.1 Embodiments of UE Figure 7 is a flowchart illustrating the operation of a wireless terminal (also called a user equipment UE) for QoE / RVQoE measurement configuration and reporting according to an embodiment of the present disclosure. As illustrated, the procedure in Figure 7 includes the following:

[0083] - Step 700A:In a first alternative or option (Option A), the wireless terminal receives one or more messages, e.g., one or more RRCReconfiguration messages, from one or more network nodes such as an MN or SN. The one or more messages may include one or more QoE configurations (e.g., a QoE measurement configuration and an RVQoE measurement configuration), and each QoE / RVQoE configuration, or at least one of the one or more QoE / RVQoE configurations, may include, or be transmitted together with (e.g., in the same message) an indication of the network node to which the UE must send the QoE report and / or RVQoE report. In one embodiment, the indication indicates that the UE may decide which network node to send the QoE report and / or RVQoE report to (this decision may or may not be based on a specified or configured procedure or a specified or configured rule or a specified or configured criterion, and / or on input data provided by the network node). Node indications can be either explicit or implicit. Examples of explicit indications include those that indicate a network node, such as MN or SN, or MCG or SCG. In another option, the indication shows the SRB that the UE should use to send the report. In one version of this embodiment, if the UE can send a report to either the MN or the SN, then, in the absence of an explicit indication, the UE interprets this as meaning that the UE can send a report to either the MN or the SN. Alternatively, the absence of an explicit indication may implicitly indicate that the UE should send a report to the node that received the relevant configuration (i.e., a QoE configuration or an RVQoE configuration) (i.e., the QoE report or RVQoE report depends on whether the absence indication relates to a QoE configuration or an RVQoE configuration). 〇Another option is that the indication of which nodes to send QoE reports and / or RVQoE reports to may apply to all QoE configurations and / or all RVQoE configurations in the UE. With this option, the indication may be sent to the UE once, for example in an RRCReconfiguration message, instead of associating a separate indication with each QoE and / or RVQoE configuration. The implicit indication may be, for example, a configuration of a specific SRB linked to the configuration of a QoE or RVQoE measurement, and the SRB is used for sending QoE reports and / or RVQoE reports. Implicit indications can also depend on which part of the RRC message contains the configuration. For example, if the configuration is in the MN part of the message, the UE must send the report to the MN; on the other hand, if the configuration is in the SN part of the message, the UE must send the report to the SN. Another implicit indication may be that the UE should send a QoE report to the node that received the QoE configuration, and an RVQoE report to the node that received the RVQoE configuration. Alternatively, the implicit indication may be a configuration of specific identifiers associated with a QoE / RVQoE configuration (e.g., measConfigAppLayerId), where a first set of identifiers is reserved for MN and another set of identifiers is reserved for SN. For example, the first set of identifiers may be represented by all possible values ​​of measConfigAppLayerId-r17 IE, reserved for the QoE / RVQoE configurations that MN can configure for UE, and the second set of identifiers may be represented by all possible values ​​of another IE, e.g., measConfigAppLayerId-r18, reserved for SN. Explicit indication can be achieved by indicating the DRBs that the UE should use when sending / receiving application data to / from a specific network node that contributed to preparing the RVQoE configuration or sending the QoE / RVQoE configuration to the UE. For example, to indicate that the UE should use DRB ID=X1,Y1,Z1 when sending / receiving application data to / from an MN node, a first list of DRBs may be included in the UE's QoE configuration (or RVQoE configuration). This may be included in the QoE configuration as part of an “MCG-related” configuration. To indicate that the UE can use another set of DRBs, e.g., DRB ID=X2,Y2,Z2 (e.g., included in an “SCG-related” configuration), when sending / receiving application data to / from an SN node, a second list of DRBs may also be included in the same QoE / RVQoE configuration (or a separate QoE / RVQoE configuration). The MN and SN may perform a coordination procedure to determine the list of MN-related DRBs and SN-related DRBs associated with the UE's QoE / RVQoE reports directed to the MN and SN, respectively. One of the nodes responsible for determining which DRBs the UE should use when sending / receiving data about the application to / from the MN node will provide a list of DRBs the UE should use when sending / receiving data about the application to / from the MN node, and optionally propose a second list of DRBs the UE should use when sending / receiving data about the application to / from the SN node. Other nodes, such as the SN node, may respond with a list of DRBs the UE should use when sending / receiving data about the application to / from itself, and may accept or reject the proposal from the responsible node (MN in the example). A list of MN-related DRBs may be included in an RVQoE configuration prepared by the MN for RVQoE reports that the MN wishes to receive (for example, as part of an MN-RVQoE configuration or an MCG-RVQoE configuration). The MN may also send at least a portion of an RVQoE configuration prepared by the SN, which includes a list of SN-related DRBs (for example, as part of an SN-RVQoE configuration or an SCG-RVQoE configuration), to the UE. The lists of DRBs associated with MN and SN do not need to be explicitly indicated for QoE / RVQoE purposes, but the UE may receive them regardless of QoE processing and (re)use the same lists when transmitting application data subject to QoE / RVQoE measurement. Alternatively, the UE may provide information to derive the nodes to which the reports should be sent. The indication may be, for example, an indication to the UE to send the QoE report and / or RVQoE report, respectively, to the nodes carrying the data for the application session in which the QoE measurement and / or RVQoE measurement are performed. The UE may also be instructed by the network where to send QoE reports and / or RVQoE reports in the case of different reconfigurations related to dual connectivity. ●When the UE is instructed to send QoE reports and / or RVQoE reports to the node carrying data about the application session (as described above, the UE may provide information to derive which node the reports should be sent to), explicit indications can instruct the UE where to send the reports in case the node carrying the application session changes (which may occur for various reasons). Some non-exclusive examples are as follows: ●If the MN and SN serving the UE remain the same, but the node carrying the session changes (for example, the change is that the data flow for the session is now carried via the MN, whereas previously it was carried via the SN), the UE may be instructed to do the following: ●Going forward, QoE reports and / or RVQoE reports will be sent to the node that will carry the session in the future, instead of to the node from which the QoE and / or RVQoE reports were previously sent. ●Going forward, QoE reports and / or RVQoE reports will be sent to the node that will carry the session in the future, instead of to the node from which the report was previously sent. ● Continue reporting QoE reports and / or RVQoE reports to nodes that are currently receiving them. ● For mobility, such as MN changes or SN changes, explicit indications can instruct the UE where to send QoE reports and / or RVQoE reports. ● Continue sending QoE reports and / or RVQoE reports to the node to which QoE reports were previously sent and to the node performing the same role (MN role or SN role) in dual connectivity. ●If QoE reports and / or RVQoE reports have been sent to the MN up until now, continue sending the reports to the MN (and to the new MN in the event of a change in the MN). ●If QoE reports and / or RVQoE reports have been sent to the SN up until now, continue sending the reports to the SN (if the SN change means they will now be sent to the new SN). ● In the future, reports will be sent to specific nodes, MNs, or SNs. ●When changing from single to dual connectivity (SN addition), explicit indications can instruct the UE where to send reports, for example: ●From now on, please send reports to SN. ● Continue reporting to nodes that have previously received reports, such as MN. The indication of the network node to which the UE must send QoE reports and RVQoE reports may be the same node for both reports, or it may be a different node for both reports. The configuration for QoE measurement and RVQoE measurement may be done in the same message or in different messages. The configuration for the indication of nodes to which the UE must send reports may be sent together with the QoE / RVQoE measurement configuration or separately from the measurement configuration. Messages with configuration for UE may be sent from MN, from SN, or from both MN and SN.

[0084] - Steps 700B-1 and 700B-2: In the second alternative or option (Option B), the wireless terminal receives one or more messages from a network node, for example, one or more RRCReconfiguration messages, each containing one or more QoE configurations (e.g., and / or one or more RVQoE configurations), and for each QoE / RVQoE configuration, or for at least one of the one or more QoE / RVQoE configurations, the UE determines which network node to which it must send a QoE and / or RVQoE report. This alternative allows the UE to determine which node to send the report to.

[0085] - Step 702: The wireless terminal applies the received (one or more) QoE / RVQoE configurations and performs QoE / RVQoE measurements according to the (one or more) configurations.

[0086] - Step 704: As a recipient of QoE / RVQoE reports, the wireless terminal sends QoE / RVQoE reports to the network nodes indicated (explicitly, implicitly, or derivably) in each (one or more) QoE / RVQoE configuration (or together with (one or more) QoE configurations). 〇 Step 704-1:The wireless terminal sends one or more QoE reports for each (one or more) QoE configuration to one or more first network nodes, which are indicated (as in step 700A) or determined by the wireless terminal (as in step 700B-2 of option B). ●If the configuration indicates that a QoE report should be sent to the MN, include the QoE report in the message to the MN. The message containing the QoE report may be, for example, a MeasurementReportAppLayer message sent on SRB4. ●If the configuration indicates that a QoE report should be sent to the SN, include the QoE report in the message to the SN. The message containing the QoE report may be a MeasurementReportAppLayer message sent, for example, on SRB3 or on a new SRB5 configured for the SN. Alternatively, the message may be a ULInformationTransferMRDC message with an embedded MeasurementReportAppLayer message, sent to the MN on SRB4 for forward transfer to the SN. The message may be a newly defined message. 〇 Step 704-2: The wireless terminal, as a recipient of the RVQoE report, transmits the RVQoE report to one or more second network nodes indicated (explicitly, implicitly, or derivably) in the RVQoE configuration (or in conjunction with the RVQoE configuration). In other words, for each one or more RVQoE configuration, the wireless terminal transmits the RVQoE report to one or more second network nodes indicated (as in step 700A) or determined by the wireless terminal (as in step 700B-2 of option B). Note that, because these are indicated or determined separately, the one or more first network nodes to which the QoE report is transmitted may be different from the one or more second network nodes to which the RVQoE report is transmitted. ●If the configuration indicates that an RVQoE report should be sent to the MN, include the RVQoE report in the message to the MN. The message containing the RVQoE report may be, for example, a MeasurementReportAppLayer message sent on SRB4 or SRB1. ●If the configuration indicates that an RVQoE report should be sent to the SN, include the RVQoE report in the message to the SN. The message containing the RVQoE report may be a MeasurementReportAppLayer message sent, for example, on SRB3 or on a new SRB5 configured for the SN. Alternatively, the message may be a ULInformationTransferMRDC message with an embedded MeasurementReportAppLayer message, sent to the MN on SRB4 or SRB1 for forward transfer to the SN. The message may be a newly defined message.

[0087] The configuration of the node to which the report is sent may or may not be the same for all QoE measurement configurations or all RVQoE measurement configurations in the UE. The UE may be configured to send some QoE or RVQoE reports to the MN and some other QoE or RVQoE reports to the SN for different configurations associated with different service types (i.e., different measConfigAppLayerIds). For RVQoE reports, this may or may not depend on which node (MN or SN) created and / or sent the RVQoE configuration to the UE. Alternatively, the indication of which node to send QoE and / or RVQoE reports to may apply to all QoE and / or all RVQoE configurations in the UE. In this option, the indication may be sent to the UE once, for example in an RRCReconfiguration message, instead of associating a separate indication with each QoE and / or RVQoE configuration. - The order in which node selections and reports must be sent may depend on the RRC state of the UE before it was (re)configured for multi-connectivity operation. In one case, the UE may receive an indication in the configuration regarding QoE measurements that all QoE measurements and / or all RVQoE measurements that the UE may have collected while in the RRC_INACTIVE or RRC_IDLE state should always be sent to the MN. In one case, the UE may receive an indication in the configuration regarding QoE measurements that all QoE measurements and / or all RVQoE measurements that the UE may have collected while in the RRC_INACTIVE or RRC_IDLE state should always be sent to the SN. In one case, the UE may receive an indication in the configuration regarding QoE measurements that all QoE measurements that the UE may have collected while in the RRC_INACTIVE or RRC_IDLE state must be sent to the MN, and all RVQoE measurements that the UE may have collected while in the RRC_INACTIVE or RRC_IDLE state must be sent to the SN. In one case, the UE may receive an indication in the configuration for QoE measurements that all QoE / RVQoE measurements that the UE may have collected while in the RRC_INACTIVE state must be sent to either the MN or SN before sending all QoE / RVQoE measurements that the UE may have collected while in the RRC_IDLE state.

[0088] The configuration of the node from which the report is sent may be implicitly derived based on indication / configuration parameters received by the RAN node as part of the QoE / RVQoE configuration from another network node (e.g., an OAM or CN node), where the indication / configuration parameters relate, for example, to the method that the RAN should use for delivering the QoE report, the need for the MN or SN to perform matching / correlation between RVQoE and radio measurements, and / or the need for another network node (e.g., an MCE) to perform matching / correlation between QoE and radio measurements. - In one case, another network node (e.g., an OAM or CN node) may send an indication to the RAN (e.g., to the MN) indicating that QoE reports are delivered to the MCE via streaming (e.g., an MCE URI or URL). The above indication may be implicitly used to indicate that the RAN nodes comprising the UE should, in their configuration for the UE, indicate that all QoE reports must be sent from the UE to the MN and not to the SN (or vice versa). - In another case, the MN receives an indication from the SN that the RVQoE measurements configured by the SN should be consistent with the radio measurements that the UE performs on the SN, and can use this indication to request the UE to send the RVQoE measurements configured by the SN to the SN (for example, as part of the RVQoE configuration).

[0089] 3.1.2 Embodiments for MN Figure 8 illustrates the operation of a network node configured as a master node (MN) for the UE for QoE measurement configuration and reporting, according to one embodiment of the present disclosure. As illustrated, the procedure in Figure 8 includes the following steps:

[0090] - Step 800: The network node decides to configure the UE for QoE measurement and / or RVQoE measurement. In some cases, we may receive requests from the SN to configure additional or alternative QoE measurements or RVQoE measurements. The request may be included, for example, in the S-NODE MODIFICATION REQUIRED message, or in a new message (for example, a new message dedicated to the QoE / RVQoE coordination aspect between MN and SN for QoE / RVQoE configuration and / or reporting, such as the QOE CONFIGURATION REQUIRED XnAP message).

[0091] - Step 802: Optionally, the network node sends a request to the secondary node (SN) to configure QoE measurements and / or RVQoE measurements. The request may be included, for example, in an S-NODE ADDITION REQUEST or S-NODE MODIFICATION REQUEST message, or in a new message (for example, a new message dedicated to the QoE / RVQoE coordination aspects between MN and SN for QoE / RVQoE configuration and / or reporting, such as a QOE CONFIGURATION REQUEST XnAP message). In the case of management-based QoE and RVQoE configurations, existing or newly defined non-UE-related messages containing information and instructions for more than one UE may be used. The initiation of QoE and RVQoE measurements may be performed by either the MN or SN node, or both, and in any combination of which node initiated which type of measurement.

[0092] - Step 804: Optionally, (if the optional transmission step described above is performed), the network node receives from the SN a response to the request for configuration of QoE measurement, and / or a response to the response to the request for configuration of RVQoE measurement. Requests may be included, for example, in S-NODE ADDITION REQUEST ACKNOWLEDGE or S-NODE MODIFICATION REQUEST ACKNOWLEDGE messages, or in new messages (for example, new messages dedicated to the QoE / RVQoE coordination aspects between MN and SN for QoE / RVQoE configuration and / or reporting, such as the QOE CONFIGURATION RESPONSE XnAP message). In the case of management-based QoE and RVQoE configurations, existing or newly defined non-UE-related messages containing information and instructions for more than one UE may be used.

[0093] - Step 806: A network node sends one or more messages to the UE, for example, one or more RRCReconfiguration messages, each containing a configuration for QoE measurement and a configuration for RVQoE measurement, and for each of the QoE measurement configurations and (if applicable) for each of the RVQoE measurement configurations, an indication of the network node to which the UE must send QoE and / or RVQoE reports, respectively. Node indications can be either explicit or implicit. ● An example of explicit indication is an indication that shows the SRB that the UE should use to send reports, for example, on a network node such as an MN or SN, or another option. ● Implicit indications may, for example, be configurations of a specific SRB linked to the configuration of a QoE or RVQoE measurement. This may also depend on which part of the RRC message the configuration is contained in; if the configuration is contained in the MN portion of the message, the UE must send the report to the MN; if the configuration is contained in the SN portion of the message, the UE must send the report to the SN. Alternatively, the indication may be an indication to the UE to send the QoE report and / or RVQoE report, respectively, to the node carrying the session in the application layer. ●For further examples of explicit or implicit indication, please refer to the above embodiments of the UE. The indication of the network node to which the UE must send QoE reports and RVQoE reports may be the same node for both reports, or it may be a different node for both reports. The configuration for QoE measurement and RVQoE measurement may be done in the same message or in different messages. The configuration for the indication of nodes to which the UE must send reports may be sent together with the QoE / RVQoE measurement configuration or separately from the measurement configuration. Messages to UE may be sent from MN, from SN, or from both MN and SN. All considerations relating to the indication of where the UE should send the reports listed under the UE embodiment are equally applicable to MN, even if they are not listed under the MN embodiment in this document.

[0094] - Step 808: Optionally, network nodes will receive QoE reports from UEs if the MN is configured (explicitly, implicitly, or derivably) to receive QoE reports. The message containing the QoE report may be, for example, a MeasurementReportAppLayer message sent on SRB4.

[0095] - Step 810: Optionally, network nodes will receive RVQoE reports from UEs if the MN is configured (explicitly, implicitly, or derivably) to receive QoE reports. The message containing the RVQoE report may be, for example, a MeasurementReportAppLayer message sent on SRB4. If MN is configured (explicitly, implicitly, or derivably) to receive both QoE reports and RVQoE reports, the QoE reports and RVQoE reports may be received in the same message (e.g., a MeasurementReportAppLayer message) or in different messages (e.g., two separate MeasurementReportAppLayer messages).

[0096] - Step 812: Optionally, if another node configured as an SN for a UE is configured (explicitly, implicitly, or derivably) to receive QoE reports, and the method for delivering QoE reports from the UE to the SN is forwarding via an MN, then the network node forwards the received QoE reports to the other node configured as an SN. The QoE report may be forwarded to the SN as one or more informational elements at the XnAP level in the XnAP message. Alternatively, the MeasurementReportAppLayer RRC message containing the QoE report may be delivered to the SN in an RRC TRANSFER XnAP message. In this case, the MN may, as one option, receive the MeasurementReportAppLayer RRC message containing the QoE report encapsulated in a ULInformationTransferMRDC RRC message.

[0097] - Step 814:Optionally, if another node configured as an SN for a UE is configured (explicitly, implicitly, or derivably) to receive RVQoE reports, and the method for delivering RVQoE reports from the UE to the SN is forwarding via the MN, then the network node forwards the received RVQoE reports to the other node configured as an SN. The RVQoE report may be forwarded to the SN as one or more informational elements at the XnAP level in the XnAP message. Alternatively, the MeasurementReportAppLayer RRC message containing the RVQoE report may be delivered to the SN in an RRC TRANSFER XnAP message. In this case, the MN may, as one option, receive the MeasurementReportAppLayer RRC message containing the RVQoE report encapsulated in a ULInformationTransferMRDC RRC message.

[0098] 3.1.3 Embodiments for SN Figure 9 illustrates the operation of a network node configured as a secondary node (SN) for the UE for QoE measurement configuration and reporting, according to an embodiment of the present disclosure. As illustrated, the procedure in Figure 9 includes the following steps:

[0099] - Step 900: Optionally, the network node decides to configure the UE with QoE measurement and / or RVQoE measurement.

[0100] - Step 902: Optionally, additionally, or alternatively, the network node receives requests from the UE's master node (MN) to configure QoE measurements and / or RVQoE measurements. The request may be included, for example, in an S-NODE ADDITION REQUEST or S-NODE MODIFICATION REQUEST message, or in a new message (for example, a new message dedicated to the QoE / RVQoE coordination aspect between MN and SN for QoE / RVQoE configuration and / or reporting, such as a QOE CONFIGURATION REQUEST XnAP message). In the case of management-based QoE and RVQoE configurations, existing or newly defined non-UE-related messages containing information and instructions for more than one UE may be used. The initiation of QoE and RVQoE measurements may be performed by either the MN or SN node, or both, and in any combination of which node initiated which type of measurement.

[0101] - Step 904: Optionally, (if the above request for QoE measurement configuration and / or request for RVQoE measurement configuration is received from the MN), the network node sends to the MN a response to the request for QoE measurement configuration and / or a response to the request for RVQoE measurement configuration, the response containing the requested QoE measurement configuration and / or the requested RVQoE measurement configuration. The response may be included, for example, in an S-NODE ADDITION REQUEST ACKNOWLEDGE or S-NODE MODIFICATION REQUEST ACKNOWLEDGE message, or in a new message (for example, a new message dedicated to the QoE / RVQoE coordination aspects between MN and SN for QoE / RVQoE configuration and / or reporting, such as a QOE CONFIGURATION RESPONSE XnAP message). In the case of management-based QoE and RVQoE configurations, existing or newly defined non-UE-related messages containing information and instructions for more than one UE may be used. If both QoE configuration and RVQoE configuration are sent to the MN, they may optionally be included in the same message, or alternatively, they may be included in two separate messages (for example, if the request for QoE configuration and the request for RVQoE configuration are received from the MN in two separate messages).

[0102] - Step 906: Alternatively, the network node can send a request to the MN to configure a QoE measurement or RVQoE measurement. The request may be included, for example, in an S-NODE MODIFICATION REQUIRED message, or in a new message (for example, a new message dedicated to the QoE / RVQoE coordination aspects between MN and SN for QoE / RVQoE configuration and / or reporting, such as a QOE CONFIGURATION REQUIRED XnAP message). In the case of management-based QoE and RVQoE configurations, existing or newly defined non-UE-related messages containing information and instructions for more than one UE may be used.

[0103] - Step 908: Optionally, a network node may send one or more messages to the UE, for example, RRCReconfiguration, and the (one or more) messages may include a configuration for QoE measurement and a configuration for RVQoE measurement, and an indication of the network node to which the UE must send QoE and / or RVQoE reports, respectively. Node indications can be either explicit or implicit. ● An example of explicit indication is an indication that shows the SRB that the UE should use to send reports, for example, on a network node such as an MN or SN, or another option. ● Implicit indications may, for example, be a specific SRB configuration linked to the configuration of a QoE or RVQoE measurement. This may also depend on which part of the RRC message the configuration is included in; if the configuration is included in the MN portion of the message, the UE must send the report to the MN; if the configuration is included in the SN portion of the message, the UE must send the report to the SN. Alternatively, the indication may be an indication to the UE to send the QoE report and / or RVQoE report, respectively, to the node carrying the session in the application layer. ●For further examples of explicit or implicit indication, please refer to the above embodiments of the UE. The indication of the network node to which the UE must send QoE reports and RVQoE reports may be the same node for both reports, or it may be a different node for both reports. The configuration for QoE measurement and RVQoE measurement may be done in the same message or in different messages. The configuration for the indication of nodes to which the UE must send reports may be sent together with the QoE / RVQoE measurement configuration or separately from the measurement configuration. Messages to UE may be sent from MN, from SN, or from both MN and SN. All considerations relating to the indication of where the UE should send the reports listed under the UE embodiment are equally applicable to MN, even if they are not listed under the MN embodiment in this document.

[0104] - Step 910: Network nodes receive QoE reports from UEs if the SN is configured (explicitly, implicitly, or derivably) to receive QoE reports. The message containing the QoE report may be a MeasurementReportAppLayer message sent, for example, on SRB3, or on a new SRB5 configured for the SN. Alternatively, the message may be a ULInformationTransferMRDC message with an embedded MeasurementReportAppLayer message, sent to the SN via the MN on SRB4. That is, the MN receives the ULInformationTransferMRDC message on SRB4, extracts the MeasurementReportAppLayer message from the ULInformationTransferMRDC message, encapsulates it in an RRC TRANSFER XnAP message, and sends it to the SN.

[0105] - Step 912: Network nodes receive RVQoE reports from UEs if the SN is configured (explicitly, implicitly, or derivably) to receive QoE reports. The message containing the QoE report may be a MeasurementReportAppLayer message sent, for example, on SRB3, or on a new SRB5 configured for the SN. Alternatively, the message may be a ULInformationTransferMRDC message with an embedded MeasurementReportAppLayer message, sent to the SN via the MN on SRB4. That is, the MN receives the ULInformationTransferMRDC message on SRB4, extracts the MeasurementReportAppLayer message from the ULInformationTransferMRDC message, encapsulates it in an RRC TRANSFER XnAP message, and sends it to the SN.

[0106] 3.1.4 Special Cases of m-Based QoE Configurations The UE configures QoE measurements and measurement reports when both MN and SN receive the same m-based QoE configuration.

[0107] - In one embodiment, it is up to the nodes (e.g., MN and SN) to determine by coordination which node should configure the UE for these QoE measurements. In one embodiment, the UE is permitted to send QoE reports to any of the nodes.

[0108] - In one embodiment, the UE is provided with an indication (e.g., from the MN and / or SN) that the received QoE configuration is identical to both the MN and the SN. For example, regarding QoE measurement, the components thereof, 〇These QoE measurements did not constitute a UE.

[0109] - In one embodiment, a node that did not configure QoE measurement during inter-node communication (e.g., MN or SN) may be allowed to configure UE for RVQoE measurement. One option is for MN to instruct SN to configure UE for QoE measurement and UE for RVQoE measurement. Alternatively, SN instructs MN to configure UE for QoE measurement and UE for RVQoE measurement.

[0110] - In one embodiment, a node that did not configure a UE for QoE and / or RVQoE measurements is made able to receive QoE and / or RVQoE measurement reports from the node that did configure them, for example, through some indication.

[0111] 3.2 Exemplary Implementation 3.2.1 Example where UE's QoE / RVQoE reporting behavior is controlled by the QoE / RVQoE configuration An exemplary implementation in 3GPP TS38.331 of what a UE configuration sending QoE and RVQoE reports might look like (using the AppLayerMeasConfig IE definition in section 6.3.4 of 3GPP TS38.331 version 17.2.0 as a baseline).

[0112] - AppLayerMeasConfig IE AppLayerMeasConfig shows the configuration for application layer measurement.

[0113] AppLayerMeasConfig information element -- ASN1START -- TAG-APPLAYERMEASCONFIG-START AppLayerMeasConfig-r17 ::= SEQUENCE { measConfigAppLayerToAddModList-r17 SEQUENCE (SIZE (1..maxNrofAppLayerMeas-r17)) OF MeasConfigAppLayer-r17 OPTIONAL, -- Need N measConfigAppLayerToReleaseList-r17 SEQUENCE (SIZE (1..maxNrofAppLayerMeas-r17)) OF MeasConfigAppLayerId-r17 OPTIONAL, -- Need N rrc-SegAllowed-r17 ENUMERATED {enabled} OPTIONAL, -- Need R ... } MeasConfigAppLayer-r17 ::= SEQUENCE { measConfigAppLayerId-r17 MeasConfigAppLayerId-r17, measConfigAppLayerContainer-r17 OCTET STRING (SIZE (1..8000)) OPTIONAL, -- Need N serviceType-r17 ENUMERATED {streaming, mtsi, vr, spare5, spare4, spare3, spare2, spare1} OPTIONAL, -- Need M pauseReporting-r17 BOOLEAN OPTIONAL, -- Need M transmissionOfSessionStartStop-r17 BOOLEAN OPTIONAL, -- Need M ran-VisibleParameters-r17 SetupRelease {RAN-VisibleParameters-r17} OPTIONAL, -- Cond serviceType ..., [[ reportingCellGroupQoE-r18 ENUMERATED {mcg, scg, sessionCG, spare1, spare2, spare3, spare4} OPTIONAL, -- Need M reportingCellGroupQoE-SDT-r18 ENUMERATED {mcg, spare1, spare2, spare3} OPTIONAL, -- Need M ]] } RAN-VisibleParameters-r17 ::= SEQUENCE { ran-VisiblePeriodicity-r17 ENUMERATED {ms120, ms240, ms480, ms640, ms1024} OPTIONAL, -- Need S numberOfBufferLevelEntries-r17 INTEGER (1..8) OPTIONAL, -- Need R reportPlayoutDelayForMediaStartup-r17 BOOLEAN OPTIONAL, -- Need M ..., [[ reportingCellGroupRVQoE-r18 ENUMERATED {mcg, scg, sessionCG, spare1, spare2, spare3,spare4} OPTIONAL, -- Need M reportingCellGroupRVQoE-SDT-r18 ENUMERATED {mcg, spare1, spare2, spare3} OPTIONAL, -- Need M ]] } -- TAG-APPLAYERMEASCONFIG-STOP -- ASN1STOP

[0114] JPEG0007897417000006.jpg170165

[0115] JPEG0007897417000007.jpg98165

[0116] JPEG0007897417000008.jpg22165

[0117] 3.2.2 Example where UE's QoE / RVQoE reporting behavior is controlled commonly across all QoE / RVQoE configurations The following is an exemplary implementation in 3GPP TS38.331 of configuring the UE's QoE / RVQoE reporting behavior, using the AppLayerMeasConfig IE definition in section 6.3.4 of 3GPP TS38.331 version 17.2.0 as a baseline. In this example, the UE's reporting behavior regarding which nodes send QoE / RVQoE reports is controlled in common for all QoE configurations (i.e., applies to all QoE configurations) and in common for all RVQoE configurations (i.e., applies to all RVQoE configurations).

[0118] - AppLayerMeasConfig IE AppLayerMeasConfig shows the configuration for application layer measurement.

[0119] AppLayerMeasConfig information element -- ASN1START -- TAG-APPLAYERMEASCONFIG-START AppLayerMeasConfig-r17 ::= SEQUENCE { measConfigAppLayerToAddModList-r17 SEQUENCE (SIZE (1..maxNrofAppLayerMeas-r17)) OF MeasConfigAppLayer-r17 OPTIONAL, -- Need N measConfigAppLayerToReleaseList-r17 SEQUENCE (SIZE (1..maxNrofAppLayerMeas-r17)) OF MeasConfigAppLayerId-r17 OPTIONAL, -- Need N rrc-SegAllowed-r17 ENUMERATED {enabled} OPTIONAL, -- Need R reportingNodeQoE-r18 ENUMERATED {mn, sn, sessionNode, spare4, spare3, spare2, spare1} OPTIONAL, -- Need M reportingNodeRVQoE-r18 ENUMERATED {mn, sn, sessionNode, spare4, spare3, spare2, spare1} OPTIONAL, -- Need M ... } MeasConfigAppLayer-r17 ::= SEQUENCE { measConfigAppLayerId-r17 MeasConfigAppLayerId-r17, measConfigAppLayerContainer-r17 OCTET STRING (SIZE (1..8000)) OPTIONAL, -- Need N serviceType-r17 ENUMERATED {streaming, mtsi, vr, spare5, spare4, spare3, spare2, spare1} OPTIONAL, -- Need M pauseReporting-r17 BOOLEAN OPTIONAL, -- Need M transmissionOfSessionStartStop-r17 BOOLEAN OPTIONAL, -- Need M ran-VisibleParameters-r17 SetupRelease {RAN-VisibleParameters-r17} OPTIONAL, -- Cond ServiceType ... } RAN-VisibleParameters-r17 ::= SEQUENCE { ran-VisiblePeriodicity-r17 ENUMERATED {ms120, ms240, ms480, ms640, ms1024} OPTIONAL, -- Need S numberOfBufferLevelEntries-r17 INTEGER (1..8) OPTIONAL, -- Need R reportPlayoutDelayForMediaStartup-r17 BOOLEAN OPTIONAL, -- Need M ... } -- TAG-APPLAYERMEASCONFIG-STOP -- ASN1STOP

[0120] JPEG0007897417000009.jpg194147

[0121] JPEG0007897417000010.jpg53147

[0122] JPEG0007897417000011.jpg22147

[0123] 4. Further explanation Figure 10 shows examples of communication systems 1000 according to several embodiments.

[0124] In this example, the communication system 1000 includes a telecommunications network 1002 which includes an access network 1004 such as a radio access network (RAN) and a core network 1006 which includes one or more core network nodes 1008. The access network 1004 includes one or more access network nodes such as network nodes 1010A and 1010B (one or more of which may be collectively referred to as network node 1010), or any other similar third-generation partnership project (3GPP) access nodes or non-3GPP access points (APs). The network nodes 1010 facilitate direct or indirect connection of user equipment (UEs) by, for example, connecting UEs 1012A, 1012B, 1012C, and 1012D (one or more of which may be collectively referred to as UE1012) to the core network 1006 over one or more wireless connections.

[0125] Exemplary wireless communication on a wireless connection includes transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information without using wires, cables, or other physical conductors. Furthermore, in various embodiments, the communication system 1000 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that can facilitate or participate in the communication of data and / or signals, whether wired or wireless. The communication system 1000 may include and / or interface with any type of communication, telecommunications, data, cellular, wireless network, and / or other similar types of systems.

[0126] UE1012 may be any of a broad range of communication devices, including wireless devices that are arranged, configured, and / or operable to communicate wirelessly with network node 1010 and other communication devices. Similarly, network node 1010 is arranged, can be arranged, configured, and / or operable to communicate directly or indirectly with UE1012 and / or other network nodes or devices in telecommunications network 1002 in order to enable and / or provide network access such as wireless network access, and / or to perform other functions such as management within telecommunications network 1002.

[0127] In the illustrated example, the core network 1006 connects the network node 1010 to one or more hosts, such as host 1016. These connections may be direct or indirect, via one or more intermediate networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 1006 includes one or more core network nodes (e.g., core network node 1008) structured together with hardware and software components. The functions of these components may be substantially the same as those described for the UE, network nodes, and / or hosts, and therefore these descriptions are generally applicable to the corresponding components of core network node 1008. An exemplary core network node includes the functionality of one or more of the following: Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier Decryption Function (SIDF), Unified Data Management (UDM), Security Edge Protected Proxy (SEPP), Network Exposure Function (NEF), and / or User Plane Function (UPF).

[0128] Host 1016 may be owned by or under the control of a service provider other than the operator or provider of the access network 1004 and / or the telecommunications network 1002, and may be operated by or on behalf of such service provider. Host 1016 may host a variety of applications to provide one or more services. Examples of such applications include live and pre-recorded audio / video content, data acquisition services such as acquisition and editing of data on various ambient conditions detected by multiple UEs, analytical functionality, social media, functionality for controlling or otherwise interacting with remote devices, functionality for alarm and monitoring centers, or any other such functionality performed by a server.

[0129] Overall, the communication system 1000 in Figure 10 enables connectivity between the UE, network nodes, and hosts. In this sense, the communication system 1000 may be configured to operate according to predefined rules or procedures, such as, but not limited to, certain standards including: Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long-Term Evolution (LTE), and / or other suitable second, third, fourth, or fifth generation (2G, 3G, 4G, or 5G) standards, or any applicable future generation standards (e.g., sixth generation (6G)), wireless local area network (WLAN) standards such as the IEEE 802.11 standard (WiFi), and / or any other suitable wireless communication standards such as Worldwide Interoperability for Microwave Access (WiMAX), Bluetooth, Z-Wave, Near Field Communication (NFC), ZigBee, LiFi, and / or any low-power wide area network (LPWAN) standards such as LoRa and Sigfox.

[0130] In some examples, the telecommunications network 1002 is a cellular network implementing functions standardized by 3GPP. Therefore, the telecommunications network 1002 may support network slicing to provide various logical networks to various devices connected to the telecommunications network 1002. For example, the telecommunications network 1002 may provide ultra-high reliability low latency communication (URLLC) services to some UEs while providing enhanced mobile broadband (eMBB) services to other UEs, and / or provide massive machine type communication (mMTC) / massive Internet of Things (IoT) services to further UEs.

[0131] In some examples, UE1012 is configured to transmit and / or receive information without direct human interaction. For example, the UE may be designed to transmit information to access network 1004 on a predetermined schedule, triggered by internal or external events, or in response to a request from access network 1004. Additionally, the UE may be configured to operate with single or multiple radio access technologies (RATs) or in multiple standard modes. For example, the UE may operate with any one or a combination of WiFi, New Radio (NR), and LTE, i.e., it may be configured for multi-radio dual connectivity (MR-DC), such as Advanced UMTS Ground RAN (E-UTRAN) NR-Dual Connectivity (EN-DC).

[0132] In the above example, the hub 1014 communicates with the access network 1004 to facilitate indirect communication between one or more UEs (e.g., UE1012C and / or 1012D) and a network node (e.g., network node 1010B). In some examples, the hub 1014 may be a controller, router, content source and analysis, or any other communication device described herein with respect to the UE. For example, the hub 1014 may be a broadband router that enables the UE to access the core network 1006. In another example, the hub 1014 may be a controller that sends commands or instructions to one or more actuators within the UE. Commands or instructions may be received from the UE or network node 1010, or by executable code, scripts, processes, or other instructions within the hub 1014. In yet another example, the hub 1014 may be a data collector acting as temporary storage for the UE's data, and in some embodiments, it may perform analysis or other processing on this data. In yet another example, the hub 1014 may be a content source. For example, with respect to a UE that is a virtual reality (VR) headset, display, loudspeaker, or other media delivery device, the hub 1014 may acquire VR assets, video, audio, or other media or data related to sensory information via network nodes, in which case the hub 1014 provides this to the UE either directly, after performing local processing, and / or after adding additional local content. In yet another example, if one or more of the UEs are low-energy IoT devices, the hub 1014 acts as a proxy server or orchestrator for the UEs.

[0133] Hub 1014 may have a steady / persistent or intermittent connection to network node 1010B. Hub 1014 may also enable different communication methods and / or schedules between Hub 1014 and UEs (e.g., UE 1012C and / or 1012D), and between Hub 1014 and the core network 1006. In another example, Hub 1014 is connected to the core network 1006 and / or one or more UEs via a wired connection. Furthermore, Hub 1014 may be configured to connect to a machine-to-machine (M2M) service provider on the access network 1004 and / or to another UE via a direct connection. In some scenarios, a UE may establish a wireless connection with network node 1010 while still being connected via Hub 1014 via a wired or wireless connection. In some embodiments, Hub 1014 may be a dedicated hub, i.e., a hub whose primary function is to route communications to and from UEs and to network node 1010B. In other embodiments, the hub 1014 may be a non-dedicated hub, i.e., a device capable of routing communication between the UE and the network node 1010B, but also capable of acting as a source and / or destination for some data channel.

[0134] Figure 11 shows a UE1100 according to several embodiments. As used herein, UE refers to a device that is capable of, and is configured, deployed, and / or operational, wirelessly communicating with network nodes and / or other UEs. Examples of UEs include, but are not limited to, smartphones, mobile phones, cell phones, Voice over Internet Protocol (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback appliances, wearable terminal devices, wireless endpoints, mobile stations, tablets, laptops, laptop embedded devices (LEEs), laptop-mounted devices (LMEs), smart devices, wireless customer premises equipment (CPEs), and in-vehicle or vehicle embedded / integrated wireless devices. Other examples include any UE identified by 3GPP, including narrowband Internet of Things (NB-IoT) UEs, machine-type communications (MTC) UEs, and / or enhanced MTC (eMTC) UEs.

[0135] A UE may support device-to-device (D2D) communication, for example, by implementing 3GPP standards for side-link communication, dedicated short-range communication (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 person who owns and / or operates the device in question. Instead, a UE may represent a device (e.g., a smart sprinkler controller) that is intended to be sold to or operated by a human user, but may not be associated with a specific human user, at least initially. Alternatively, a UE may represent a device (e.g., a smart power meter) that is not intended to be sold to or operated by an end user, but may be associated with or operated for the benefit of a user.

[0136] The UE1100 includes an input / output interface 1106, a power supply 1108, memory 1110, a communication interface 1112, and / or any other components, or any combination thereof, and processing circuitry 1102 operably coupled via bus 1104. A certain UE may utilize all or a subset of the components shown in Figure 11. The level of integration between components may differ between one UE and another. Furthermore, a certain UE may include multiple instances of components, such as multiple processors, memory, transceivers, transmitters, receivers, etc.

[0137] The processing circuit 1102 is configured to process instructions and data and may implement some sequential state machine capable of executing instructions stored in memory 1110 as machine-readable computer programs. The processing circuit 1102 may be implemented as one or more hardware-implemented state machines (e.g., discrete logic, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc.), programmable logic with appropriate firmware, one or more stored computer programs, a general-purpose processor such as a microprocessor or digital signal processor (DSP) with appropriate software, or any combination of the above. For example, the processing circuit 1102 may include multiple central processing units (CPUs).

[0138] In this example, the input / output interface 1106 may be configured to provide an input device, an output device, or one or more interfaces to one or more input and / or output devices. Examples of output devices include speakers, sound cards, video cards, displays, monitors, printers, actuators, emitters, smart cards, other output devices, or any combination thereof. Input devices may allow a user to capture information to the UE1100. Examples of input devices include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital video cameras, webcams, etc.), microphones, sensors, mice, trackballs, directional pads, trackpads, scroll wheels, and smart cards. Presence-sensitive displays may include capacitive or resistive touch sensors for sensing user input. Sensors may include, for example, accelerometers, gyroscopes, tilt sensors, force sensors, magnetic sensors, optical sensors, proximity sensors, biosensors, or any combination thereof. Output devices may use the same type of interface port as input devices. For example, a Universal Serial Bus (USB) port may be used to provide input and output devices.

[0139] In some embodiments, the power supply 1108 is structured 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 solar power device, or a battery. The power supply 1108 may further include power circuits for transmitting power from the power supply 1108 itself and / or an external power source to various parts of the UE 1100 via an interface such as an input circuit or power cable. Power transmission may, for example, be for charging the power supply 1108. The power circuits may perform some shaping, conversion, or other modification on the power from the power supply 1108 to suit the power to each component of the UE 1100 that is being powered.

[0140] Memory 1110 may be, or may be configured to include, memory such as random access memory (RAM), read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrical EPROM (EEPROM), magnetic disk, optical disk, hard disk, removable cartridge, and flash drive. In one example, memory 1110 includes one or more application programs 1114 such as an operating system, a web browser application, a widget, a gadget engine, or other application, and corresponding data 1116. Memory 1110 may store any of a wide variety of operating systems or combinations of multiple operating systems for use by UE 1100.

[0141] The memory 1110 may be configured to include multiple 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 Multipurpose 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 RAM (SDRAM), external microDIMM 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 identification modules (SIMs) such as a Universal SIM (USIM) and / or an Internet Protocol Multimedia Services Identification 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”. Memory 1110 may enable UE 1100 to access instructions, application programs, etc., stored in temporary or non-temporary storage media for the purpose of offloading or uploading data. Product items, such as those utilizing communication systems, may be tangibly embodied as or within memory 1110, which is or may contain a device-readable storage medium.

[0142] The processing circuit 1102 may be configured to communicate with an access network or other network using a communication interface 1112. The communication interface 1112 may include one or more communication subsystems, and may include or be communicatively coupled to an antenna 1122. The communication interface 1112 may include one or more transceivers used to perform communication, such as by communicating with one or more remote transceivers of another wirelessly communicable device (e.g., another UE or network node in the access network). Each transceiver may include a transmitter 1118 and / or receiver 1120 appropriate (e.g., optical, electrical, frequency-allocated, etc.) to provide network communication. Furthermore, the transmitter 1118 and receiver 1120 may be coupled to one or more antennas (e.g., antenna 1122), may share circuit components, software or firmware, or may be implemented separately.

[0143] In the illustrated embodiment, the communication functions of the communication interface 1112 may include cellular communication, WiFi communication, LPWAN communication, data communication, voice communication, multimedia communication, near-field communication such as Bluetooth, NFC, location-based communication such as the use of the Global Positioning System (GPS) for location determination, other similar communication functions, or any combination thereof. The communication may be implemented in accordance with one or more communication protocols and / or standards such as IEEE 802.11, Code Division Multiple Access (CDMA), Wideband CDMA (WCDMA), GSM, LTE, NR, UMTS, WiMAX, Ethernet, Transmission Control Protocol / Internet Protocol (TCP / IP), Synchronous Optical Networking (SONET), Asynchronous Transfer Mode (ATM), Quick User Datagram Protocol Internet Connection (QUIC), Hypertext Transfer Protocol (HTTP), etc.

[0144] Regardless of the sensor type, the UE may provide the network node with an output of data captured by its sensor, either through its communication interface 1112 or via a wireless connection. The data captured by the UE's sensor may be communicated to the network node via another UE through a wireless connection. The output may be periodic (e.g., once every 15 minutes if reporting sensed temperature), random (e.g., to equalize the load from reports from multiple sensors), event-dependent (e.g., moisture is detected and an alert is sent), request-dependent (e.g., a user-initiated request), or a continuous stream (e.g., a live video feed of a patient).

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

[0146] If a UE is in the form of an IoT device, it may also be a device for use in one or more application domains, which include, but are not limited to, wearable technology in urban environments, augmented industrial applications, and healthcare. Non-exclusive examples of such IoT devices include connected refrigerators or freezers, televisions, connected lighting devices, electric meters, robotic vacuum cleaners, voice-controlled smart speakers, home security cameras, motion detectors, thermostats, smoke detectors, door / window sensors, moisture sensors (flood / moisture sensors), electric door locks, connected doorbells, air conditioning systems such as heat pumps, autonomous vehicles, surveillance systems, weather monitoring devices, vehicle parking monitoring devices, electric vehicle charging stations, smartwatches, fitness trackers, head-mounted displays for augmented reality (AR) or virtual reality, wearables for haptic or sensory enhancement, water sprinklers, animal or object tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and any type of medical device such as a heart rate monitor or remotely controlled surgical robot, or devices incorporated into such devices. The UE in the form of an IoT device includes, in addition to the circuitry and / or software that depends on the intended application of the IoT device, other components such as those described in relation to the UE1100 shown in Figure 11.

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

[0148] In practice, any number of UEs may be used together for a single use case. For example, the first UE may be a drone or integrated into a drone and provide the drone's speed information (obtained through a speed sensor) to a second UE, which is a remote controller operating the drone. When a user makes changes from the remote controller, the first UE may adjust the drone's throttle (for example, by controlling actuators) to increase or decrease the drone's speed. The first and / or second UE may include more than one of the functionalities described above. For example, the UE may include sensors and actuators and handle data communication for both the speed sensor and the actuators.

[0149] Figure 12 shows a network node 1200 according to several embodiments. As used herein, a network node refers to a device that is capable of communicating directly or indirectly with the UE and / or other network nodes or devices in the telecommunications network, and is thus configured, deployed, and / or operational. Examples of network nodes include, but are not limited to, APs (e.g., wireless APs), base stations (BSs) (e.g., wireless BSs, node Bs, advanced node Bs (eNBs), and NR node Bs (gNBs)).

[0150] BSs may be categorized based on the amount of coverage they provide (or, in other words, their transmit power levels), and thus may be called femtoBS, picoBS, microBS, or macroBS depending on the amount of coverage they provide. A BS may be a relay node, or a relay donor node that controls relaying. Network nodes may also include one or all of the parts of a distributed radio BS, such as an RRU called a centralized digital unit and / or sometimes a remote radio head (RRH). Such an RRU may or may not be integrated with an antenna, such as an antenna-integrated radio. Some parts of a distributed radio BS may also be called nodes in a distributed antenna system (DAS).

[0151] Other examples of network nodes include multi-transmitting point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BS, network controllers such as radio network controllers (RNCs) or BS controllers (BSCs), base stations (BTSs), transmit points, transmit nodes, multi-cell / multicast cooperative entities (MCEs), operation and maintenance (O&M) nodes, operation support system (OSS) nodes, self-organizing network (SON) nodes, and positioning nodes (including, for example, advanced serving mobile location centers (E-SMLCs) and / or drive test minimization (MDTs)).

[0152] Network node 1200 includes a processing circuit 1202, memory 1204, communication interface 1206, and power supply 1208. Network node 1200 may consist of multiple physically separate components (e.g., node B component and RNC component, or BTS component and BSC component), each of which may have its own respective components. In a scenario in which network node 1200 includes multiple separate components (e.g., BTS and BSC components), one or more of these separate components may be shared among several network nodes. For example, a single RNC may control multiple node Bs. In such a scenario, each unique pair of node B and RNC may, in some examples, be considered a single separate network node. In some embodiments, network node 1200 may be configured to support multiple RATs. In such embodiments, some components may be redundant (e.g., separate memory 1204 for different RATs), and some components may be reused (e.g., antenna 1210 may be shared by multiple different RATs). Furthermore, the network node 1200 may include multiple sets of diverse exemplary components for various wireless technologies integrated into the network node 1200, such as GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, Long Range Wide Area Network (LoRaWAN), Radio Frequency Identification (RFID), or Bluetooth wireless technology. These wireless technologies may be integrated into the same or different chips or sets of chips and other components within the network node 1200.

[0153] The processing circuit 1202 may include a combination of one or more microprocessors, controllers, microcontrollers, CPUs, DSPs, ASICs, FPGAs, or any other suitable computing devices, resources, or combinations of hardware, software, and / or coding logic, which can operate alone or in conjunction with other network node 1200 components such as memory 1204 to provide the functionality of the network node 1200.

[0154] In some embodiments, the processing circuit 1202 includes a system-on-a-chip (SOC). In some embodiments, the processing circuit 1202 includes one or more of the radio frequency (RF) transceiver circuit 1212 and the baseband processing circuit 1214. In some embodiments, the RF transceiver circuit 1212 and the baseband processing circuit 1214 may be on separate chips (or sets of chips), substrates, or units such as a radio unit and a digital unit. In alternative embodiments, some or all of the RF transceiver circuit 1212 and the baseband processing circuit 1214 may be on the same chip or set of chips, substrate, or unit.

[0155] Memory 1204 may include 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, RAM, ROM, large 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-temporary device-readable and / or computer-executable memory device, for storing information, data and / or instructions that can be used by the processing circuit 1202. Memory 1204 may store any suitable instructions, data or information, including applications, and / or other instructions, which can be executed by the processing circuit 1202 and available to the network node 1200, including one or more computer programs, software, logic, rules, code, and tables. Memory 1204 may be used to store any calculation results produced by the processing circuit 1202 and / or any data received via the communication interface 1206. In some embodiments, the processing circuit 1202 and the memory 1204 are integrated.

[0156] The communication interface 1206 is used in wired or wireless communication of signaling and / or data between network nodes, access networks, and / or UEs. As shown in the figure, the communication interface 1206 includes, for example, one or more ports / terminals 1216 for sending and receiving data to and from the network over a wired connection. The communication interface 1206 also includes a wireless front-end circuit 1218 which may be coupled to or, in some embodiments, part of the antenna 1210. The wireless front-end circuit 1218 includes a filter 1220 and an amplifier 1222. The wireless front-end circuit 1218 may be connected to the antenna 1210 and the processing circuit 1202. The wireless front-end circuit 1218 may be configured to adjust signals communicated between the antenna 1210 and the processing circuit 1202. The wireless front-end circuit 1218 may receive digital data to be sent to other network nodes or UEs via the wireless connection. The wireless front-end circuit 1218 may convert this digital data into a radio signal having appropriate channel and bandwidth parameters using a combination of filter 1220 and / or amplifier 1222. The radio signal may then be transmitted via antenna 1210. Similarly, when receiving data, antenna 1210 collects the radio signal, which may then be converted into digital data by the wireless front-end circuit 1218. The digital data may then be passed to processing circuit 1202. In other embodiments, the communication interface 1206 may include different components and / or different combinations of components.

[0157] In one alternative embodiment, the network node 1200 does not include a separate radio front-end circuit 1218; rather, the processing circuit 1202 includes the radio front-end circuit and is connected to the antenna 1210. Similarly, in some embodiments, all or part of the RF transceiver circuit 1212 is part of the communication interface 1206. In yet another embodiment, the communication interface 1206, as part of a radio unit (not shown), includes one or more ports or terminals 1216, a radio front-end circuit 1218, and an RF transceiver circuit 1212, and the communication interface 1206 communicates with a baseband processing circuit 1214, which is part of a digital unit (not shown).

[0158] Antenna 1210 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals. Antenna 1210 may be coupled to the wireless front-end circuit 1218 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In one embodiment, antenna 1210 is separate from the network node 1200 and can be connected to the network node 1200 through an interface or port.

[0159] Antenna 1210, communication interface 1206, and / or processing circuit 1202 may be configured to perform any receiving operations and / or certain acquisition operations as described herein as being performed by network node 1200. Any information, data, and / or signals may be received from the UE, other network nodes, and / or any other network equipment. Similarly, antenna 1210, communication interface 1206, and / or processing circuit 1202 may be configured to perform any transmitting operations as described herein as being performed by network node 1200. Any information, data, and / or signals may be transmitted to the UE, other network nodes, and / or any other network equipment.

[0160] Power supply 1208 provides power to the various components of network node 1200 in a format suitable for each component (for example, at the voltage and current levels required for each component). Power supply 1208 may further include, or be coupled to, a power management circuit for supplying power to the components of network node 1200 to perform the functionality described herein. For example, network node 1200 may be connectable to an external power source (e.g., a power grid or electrical outlet) via an input circuit or interface such as an electrical cable, thereby allowing the external power source to power the power circuit of power supply 1208. As a further example, power supply 1208 may include a power source in the form of a battery or battery pack connected to or integrated into the power circuit. The battery may provide backup power in case of failure of the external power source.

[0161] Embodiments of network node 1200 may include additional components other than those shown in Figure 12 to provide a functional aspect of the network node, including any functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, network node 1200 may include user interface equipment that enables input of information to and output of information from network node 1200. This may enable a user to perform diagnostic, maintenance, repair, and other management functions on network node 1200.

[0162] Figure 13 is a block diagram of host 1300, which may be an embodiment of host 1016 in Figure 10, relating to various aspects described herein. As used herein, host 1300 may be, or include, various combinations of hardware and / or software, including standalone servers, blade servers, cloud-implemented servers, distributed servers, virtual machines, containers, or processing resources within a server farm. Host 1300 may provide one or more services to one or more UEs.

[0163] The host 1300 includes an input / output interface 1306, a network interface 1308, a power supply 1310, and a processing circuit 1302 operably coupled via a bus 1304 to a memory 1312. Other components may be included in other embodiments. The functions of these components may be substantially the same as those described with respect to the devices in previous drawings, such as Figures 11 and 12, and thus these descriptions are generally applicable to the corresponding components of the host 1300.

[0164] Memory 1312 may include one or more computer programs, including one or more host application programs 1314, and data 1316, which may include user data, such as data generated by the UE for the host 1300 or data generated by the host 1300 for the UE. Embodiments of the host 1300 may utilize only a subset or all of the illustrated components. The host application program 1314 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Multipurpose Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), Moving Picture Expert Group (MPEG), VP9) and audio codecs (e.g., Free Lossless Audio Coding (FLAC), Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of the UE (e.g., handsets, desktop computers, wearable display systems, and heads-up display systems). Furthermore, the host application program 1314 may provide user authentication and license checks, and may periodically report health, route, and content availability to central nodes such as devices within or at the edge of the core network. Thus, host 1300 may select and / or point to different hosts for over-the-top (OTT) services for the UE. The host application program 1314 may support a variety of protocols, such as HTTP Live Streaming (HLS) protocol, Real-time Messaging Protocol (RTMP), Real-time Streaming Protocol (RTSP), and Dynamic Adaptive Streaming over HTTP (DASH or MPEG-DASH).

[0165] Figure 14 is a block diagram showing a virtualization environment 1400 in which functions implemented by several embodiments can be virtualized. In this context, the virtualization means for creating a virtual version of a device or apparatus may include a virtualization hardware platform, storage devices, and networking resources. As used herein, virtualization can be applied to any device or component thereof described herein and relates to implementation examples in which at least a portion of this functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components run by one or more virtual machines (VMs) implemented within one or more virtual environments 1400 hosted by one or more hardware nodes, such as network nodes, UEs, core network nodes, or hardware computing devices acting as hosts. Furthermore, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or a host), the node as a whole may be virtualized.

[0166] Application 1402 (which may alternatively be called a software instance, virtual appliance, network function, virtual node, virtual network function, etc.) runs in a virtualized environment 1300 to implement some of the features, functions and / or benefits of some of the embodiments disclosed herein.

[0167] Hardware 1404 includes processing circuits, memory for storing software and / or instructions executable by the hardware processing circuits, and / or hardware devices such as network interfaces and input / output interfaces as described herein. The software may be executed by the processing circuits to instantiate one or more virtualization layers 1406 (also referred to as hypervisors or VM monitors (VMMs)), provide VM1408A and VM1408B (one or more of which may be collectively referred to as VM1408), and / or perform any of the functions, features and / or benefits described in relation to some of the embodiments described herein. The virtualization layer 1406 may present a virtual operating platform that appears to VM1408 as networking hardware.

[0168] VM1408 includes virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and may be executed by the corresponding virtualization layer 1406. Various embodiments of instances of virtual appliance 1402 may be implemented in one or more of VM1408, and this implementation may be done in various ways. Hardware virtualization is referred to as network function virtualization (NFV) in some contexts. NFV may be used to consolidate many types of network equipment into industry-standard, high-capacity server hardware, physical switches, and physical storage that can reside in data centers and customer premises equipment.

[0169] In the context of NFV, VM1408 may be a software implementation of a physical machine that runs a program as if it were running on a physical, non-virtualized machine. Each VM1408, and the portion of hardware 1404 on which the VM runs, whether dedicated hardware for the VM or hardware shared by the VM with other VM1408s, forms a separate virtual network element. Also in the context of NFV, the virtual network function is responsible for handling the specific network functions running in one or more VM1408s on hardware 1404 and corresponds to application 1402.

[0170] Hardware 1404 may be implemented in a standalone network node with general-purpose or specific components. Hardware 1404 may implement some functions through virtualization. Alternatively, hardware 1404 may be part of a larger hardware cluster (e.g., one in a data center or CPE) in which multiple hardware nodes cooperate and are managed via management and orchestration 1410, which in turn oversees, among other things, the lifecycle management of application 1402. In some embodiments, hardware 1404 is coupled to one or more radio units, each containing one or more transmitters and one or more receivers, which can be coupled to one or more antennas. The radio units may communicate directly with other hardware nodes via one or more suitable network interfaces, or they may be used in combination with virtual components to provide radio capabilities such as RAN or BS to virtual nodes. In some embodiments, some signaling can be provided in conjunction with the use of a control system 1412, which may alternatively be used for communication between hardware nodes and radio units.

[0171] Figure 15 shows a communication diagram of host 1502 communicating with UE 1506 via network node 1504 over a partially wireless connection according to several embodiments. Exemplary implementations of various embodiments of the UEs (such as UE 1012A in Figure 10 and / or UE 1100 in Figure 11), network nodes (such as network node 1010A in Figure 10 and / or network node 1200 in Figure 12), and hosts (such as host 1016 in Figure 10 and / or host 1300 in Figure 13) discussed in the preceding paragraphs will now be described with reference to Figure 15.

[0172] Similar to host 1300, embodiments of host 1502 include hardware such as a communication interface, processing circuitry, and memory. Host 1502 also includes hardware and software stored within or accessible by host 1502 that can be executed by the processing circuitry. This software may include a host application that can operate to provide services to a remote user, such as UE 1506 connected via an OTT connection 1550 extending between UE 1506 and host computer 1502. In providing services to a remote user, the host application may provide user data transmitted using the OTT connection 1550.

[0173] Network node 1504 includes hardware that enables communication with host 1502 and UE 1506 via connection 1560. Connection 1560 may be direct or may pass through a core network (such as core network 1006 in Figure 10) 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.

[0174] UE1506 includes software stored within or accessible by UE1506 that can be executed by the UE's processing circuitry. This software includes a client application, such as a web browser or a service provider-specific “app,” which, with the support of host 1502, may operate to provide services to human or non-human users via UE1506. On host 1502, a running host application may communicate with a running client application via an OTT connection 1550 that terminates at UE1506 and host 1502. In providing services to a user, the UE's client application may receive request data from the host's host application and provide user data as a response to that request data. The OTT connection 1550 may transfer both the request data and the user data. The UE's client application may interact with the user to generate user data that it provides to the host application via the OTT connection 1550.

[0175] The OTT connection 1550 may extend via connection 1560 between host 1502 and network node 1504, and via wireless connection 1570 between network node 1504 and UE 1506, in order to provide a connection between host 1502 and UE 1506. Connections 1560 and wireless connection 1570, which may be provided by the OTT connection 1550, are abstractly depicted to illustrate the communication between host 1502 and UE 1506 via network node 1504 without any explicit reference to any intermediate devices and the exact routing of messages through these devices.

[0176] As an example of transmitting data via the OTT connection 1550, in step 1508, host 1502 provides user data, which may be done by running a host application. In some embodiments, the user data is associated with a specific human user interacting with UE 1506. In other embodiments, the user data is associated with UE 1506 sharing data with host 1502 without explicit human interaction. In step 1510, host 1502 initiates a transmission that carries the user data to UE 1506. Host 1502 may initiate such a transmission in response to a request sent by UE 1506. This request may be triggered by human interaction with UE 1506 or by the operation of a client application running on UE 1506. This transmission may pass through network node 1504 in accordance with the teachings of the embodiments described through this disclosure. Accordingly, in step 1512, the network node 1504 transmits the user data carried in this transmission initiated by host 1502 to UE 1506, in accordance with the teachings of the embodiments described through this disclosure. In step 1514, UE 1506 receives the user data carried in this transmission, which may be done by a client application running on UE 1506 associated with a host application running on host 1502.

[0177] In some examples, UE1506 runs a client application, which provides user data destined for host 1502. User data may be provided in reaction to or response to receiving data from host 1502. Accordingly, in step 1516, UE1506 may provide user data, which may be done by running a client application. In providing user data, the client application may further consider user input received from the user via the input / output interface of UE1506. Regardless of the specific way in which the user data is provided, in step 1518, UE1506 initiates transmission of the user data to host 1502 via network node 1504. In step 1520, in accordance with the teachings of the embodiments described through this disclosure, network node 1504 receives user data from UE1506 and initiates transmission of the received user data to host 1502. In step 1522, host 1502 receives the user data carried in the transmission initiated by UE1506.

[0178] One or more of the various embodiments improve the performance of the OTT service provided to the UE 1506 using the OTT connection 1550, with the wireless connection 1570 forming the final segment.

[0179] In an exemplary scenario, Host 1502 may collect and analyze factory status information. In another example, Host 1502 may process audio and video data, which may be acquired from the UE, for use in creating maps. In yet another example, Host 1502 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., traffic light control). In yet another example, Host 1502 may store surveillance video uploaded by the UE. In yet another example, Host 1502 may store or control access to media content such as video, audio, VR, or AR that can be broadcast, multicast, or unicast to the UE. In yet another example, Host 1502 may be used for energy pricing, remote control of non-time-critical power loads for balancing power generation needs, location services, presentation services (such as editing diagrams from data collected from remote devices), or any other function of collecting, acquiring, storing, analyzing, and / or transmitting data.

[0180] In some examples, measurement procedures may be provided for the purpose of monitoring data rate, latency, and other factors that may be improved by one or more embodiments. Further optional network functionality may exist for reconfiguring the OTT connection 1550 between host 1502 and UE 1506 in response to variations in the measurement results. This measurement procedure and / or network functionality for reconfiguring the OTT connection 1550 may be implemented in the software and hardware of host 1502 and / or UE 1506. In some embodiments, sensors (not shown) may be deployed in or associated with other devices through which the OTT connection 1550 passes, and these sensors may participate in the measurement procedure by supplying values ​​of the monitored quantities exemplified above, or by supplying values ​​of other physical quantities from which the software calculates or estimates the monitored quantities. Reconfiguration of the OTT connection 1550 may include message formatting, retransmission settings, preferred routing, etc., and this reconfiguration does not need to directly change the operation of network node 1504. Such procedures and functionality may be known or in practice in the art. In one embodiment, the measurement may include proprietary UE signaling that facilitates the measurement of throughput, propagation time, and latency by the host 1502. This measurement may be implemented by having the software send messages, specifically empty or "dummy" messages, using the OTT connection 1550, while monitoring propagation time, errors, etc.

[0181] While the computing devices described herein (e.g., UEs, network nodes, hosts) may include illustrated combinations of hardware components, other embodiments may include computing devices with different combinations of components. It will be understood that these computing devices may include any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. The determinations, calculations, acquisitions, or similar operations described herein may also be performed by processing circuits, which may process information by, for example, converting acquired information to other information, comparing the acquired or converted information with information stored in a network node, and / or performing one or more operations based on the acquired or converted information, and making determinations as a result of such processing. Furthermore, while components are depicted as single boxes located within larger boxes or nested within multiple boxes, in practice, computing devices may include multiple different physical components that make up the illustrated single component, and functionality may be separated between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of these components may be separated between the processing circuit and the communication interface. In another example, computationally intensive functions of any of these components may be implemented in software or firmware, while computationally intensive functions may be implemented in hardware.

[0182] In some embodiments, some or all of the functionalities described herein may be provided by a processing circuit executing instructions stored in memory, which in some embodiments may be a computer program product in the form of a non-temporary computer-readable storage medium. In alternative embodiments, some or all of these functionalities may be provided by a processing circuit without executing instructions stored in a separate or discrete device-readable storage medium, such as in a hardwired manner. In any of these specific embodiments, the processing circuit may be configured to perform the functionalities described, whether or not it executes instructions stored in a non-temporary computer-readable storage medium. The benefits provided by such functionalities are enjoyed by the computing device as a whole, and / or by the end user and the wireless network in general, and not limited to the processing circuit alone or other components of the computing device.

[0183] Some exemplary embodiments of this disclosure are as follows:

[0184] Group A Embodiment Embodiment 1: A method performed by a user device (UE), - Receiving one or more messages from one or more network nodes that include one or more Quality of Experience (QoE) configurations and / or one or more Radio Access Network (RAN) Visible QoE (RVQoE) configurations (700A, 700B-1), - For each QoE configuration, or for one or more of the above QoE configurations in common, either receive an indication of the network node to which each QoE report is sent (700A), or determine the network node to which each QoE report is sent (700B-2), - Receiving an indication indicating a network node to which each RVQoE report is transmitted, either for each RVQoE configuration or commonly for the one or more RVQoE configurations (700A), or determining the network node to which each RVQoE report is transmitted (700B-2), - Performing QoE measurement and / or RVQoE measurement according to the one or more QoE configurations and / or the one or more RVQoE configurations (702), - For each QoE report among the one or more QoE reports including the result of the QoE measurement, transmitting the QoE report to the indicated or determined network node to which the QoE report is transmitted (704-1), - For each RVQoE report among the one or more RVQoE reports including the result of the QoE measurement, transmitting the RVQoE report to the indicated or determined network node to which the QoE report is transmitted (704-2), a method having one or more of these. Embodiment 2: The method according to Embodiment 1, wherein the network node to which a QoE report is transmitted for at least one of the one or more QoE configurations is different from the network node to which the RVQoE report is transmitted for at least one of the one or more RVQoE configurations. Embodiment 3: The method according to Embodiment 1 or 2, having receiving an indication indicating a network node to which each QoE report is transmitted for each QoE configuration (700A). Embodiment 4: The method according to Embodiment 3, wherein for each QoE configuration of the one or more QoE configurations, the indication indicating the network node to which each QoE report is transmitted is included in either the QoE configuration or a (one or more) message including the QoE configuration. Embodiment 5: The method according to Embodiment 1 or 2, comprising receiving an indication indicating a common network node to which a QoE report is transmitted (700A), in common for all of the one or more QoE configurations. Embodiment 6: The method according to Embodiment 5, wherein the indication indicating the common network node to which the QoE report is transmitted is included in either at least one of the one or more QoE configurations or in one or more messages including at least one of the one or more QoE configurations. Embodiment 7: The method according to any one of Embodiments 1 to 6, comprising receiving an indication indicating a network node to which each respective RVQoE report is transmitted (700A) for each RVQoE configuration. Embodiment 8: The method according to Embodiment 7, wherein for each RVQoE configuration among the one or more RVQoE configurations, the indication indicating the network node to which each respective RVQoE report is transmitted is included in either the RVQoE configuration or in one or more messages including the RVQoE configuration. Embodiment 9: The method according to any one of Embodiments 1 to 6, comprising receiving an indication indicating a common network node to which each respective RVQoE report is transmitted (700A), in common for all of the one or more RVQoE configurations. Embodiment 10: The method according to Embodiment 9, wherein the indication indicating the common network node to which the RVQoE report is transmitted is included in either at least one of the one or more RVQoE configurations or in one or more messages including at least one of the one or more RVQoE configurations. Embodiment 11: The method according to any one of Embodiments 3 to 10, wherein each indication is - an indication of the network node (e.g., MN, SN), and - An indication that sends the report to the node that carries the (one or more) data flows of the application session to which the report relates, - Indication of cell groups (e.g., MCG, SCG), - An indication that sends the report to the cell group that carries the (one or more) data flows of the application session to which the report relates, - The indication of the SRB for transmission (for example, SRB4 implies MN, SRB5 implies SN), - An indication that a MeasurementReportAppLayer message containing a specific report type should be included in a message used to encapsulate a message being transferred from MN to SN (or vice versa) (e.g., a ULInformationTransferMRDC RRC message), and any one of the following: - The absence of an indication may be an implicit indication that the report should be sent to the node that sent the configuration. - The absence of an indication may be an implicit indication that the report should be sent to the node processing the DRBs that carry the data flows of the application session to which the report relates. - A method in which the absence of an indication may implicitly indicate that the UE can autonomously decide which node to send the report to. Embodiment 12: A method according to Embodiment 1 or 2, comprising determining the network node to which each QoE report is transmitted for each QoE configuration (700B-2). Embodiment 13: A method according to Embodiment 1 or 2, comprising determining a common network node to which QoE reports are sent, which is common to all of the one or more QoE configurations (700B-2). Embodiment 14: A method according to Embodiments 1, 2, 12, or 13, comprising determining the network node to which each RVQoE report is transmitted for each RVQoE configuration (700B-2). Embodiment 15: A method according to Embodiments 1, 2, 12, or 13, comprising determining a common network node from which RVQoE reports are sent, in common to all of the one or more RVQoE configurations (700B-2). Embodiment 16: A method according to any of the above embodiments, further comprising providing user data and transferring the user data to a host via transmission to the network node.

[0185] Group B Embodiment Embodiment 17: A method performed by a first network node (e.g., MN), - The user equipment (UE) contains one or more messages including one or more Quality of Experience (QoE) configurations and / or one or more Wireless Access Network (RAN) Visible QoE (RVQoE) configurations, ○ For each QoE configuration, or for one or more of the above QoE configurations in common, an indication is provided that shows the network node from which each QoE report is sent. A method comprising one or more of the following: sending an indication for each RVQoE configuration, or for one or more of the above RVQoE configurations in common, and sending an indication of the network node to which each RVQoE report is sent (806). Embodiment 18: A method according to Embodiment 17, wherein the network node to which a QoE report is transmitted for at least one of the one or more QoE configurations is different from the network node to which the RVQoE report is transmitted for at least one of the one or more RVQoE configurations. Embodiment 19: A method performed by a second network node (e.g., SN), - Receiving one or more messages from a user device (UE) that include one or more QoE reports associated with one or more quality-of-experience (QoE) configurations and one or more RVQoE reports associated with one or more radio access network (RAN) visible QoE (RVQoE) configurations (910), For each QoE configuration, or for one or more of the above QoE configurations in common, the UE consists of or determines the network node from which each QoE report is sent. A method wherein, for each RVQoE configuration, or for one or more of the RVQoE configurations, the UE is composed of or determines the network node from which each RVQoE report is sent. Embodiment 20: A method according to Embodiment 19, wherein the network node to which a QoE report is transmitted for at least one of the one or more QoE configurations is different from the network node to which an RVQoE report is transmitted for at least one of the one or more RVQoE configurations. Embodiment 21: A method according to any of the above embodiments, further comprising acquiring user data and transferring the user data to a host or user device.

[0186] Group C Embodiment Embodiment 22: A user device comprising a processing circuit configured to perform any of the steps of any of the embodiments of Group A, and a power supply circuit configured to supply power to the processing circuit. Embodiment 23: A network node comprising a processing circuit configured to perform any of the steps of any of the embodiments of Group B, and a power supply circuit configured to supply power to the processing circuit. Embodiment 24: User equipment (UE) comprising: an antenna configured to transmit and receive wireless signals; a wireless front-end circuit connected to the antenna and a processing circuit and configured to adjust signals communicated between the antenna and the processing circuit, wherein the processing circuit is configured to perform any of the steps of any of the embodiments of Group A; an input interface connected to the processing circuit and configured to allow input of information to the UE to be processed by the processing circuit; an output interface connected to the processing circuit and configured to output information from the UE processed by the processing circuit; and a battery connected to the processing circuit and configured to supply power to the UE. Embodiment 25: A host configured to operate in a communication system to provide an over-the-top (OTT) service, comprising: a processing circuit configured to provide user data; and a network interface configured to initiate transmission of the user data to a cellular network for transmission to a user device (UE), wherein the UE comprises a communication interface and a processing circuit, the communication interface and processing circuit of the UE configured to perform any of the steps of any of the embodiments of Group A to receive the user data from the host. Embodiment 26: A host according to the above embodiment, wherein the cellular network further includes network nodes configured to communicate with the UE in order to transmit user data from the host to the UE. Embodiment 27: A host according to the two embodiments described above, wherein the processing circuit of the host is configured to execute a host application and thereby provide the user data, the host application is configured to interact with a client application that runs on the UE, and the client application is associated with the host application. Embodiment 28: A method performed by a host operating in a communication system further including network nodes and user equipment (UEs), comprising providing user data for the UEs and initiating a transmission to carry the user data to the UEs via a cellular network comprising the network nodes, wherein the UEs perform any operation of any of the embodiments of Group A in order to receive the user data from the host. Embodiment 29: A method according to the above embodiment, further comprising running a host application associated with a client application running on the UE in order to receive the user data from the UE. Embodiment 30: A method of the above embodiment, further comprising the host transmitting input data to the client application running on the UE, wherein the input data is provided by running the host application, and the user data is provided by the client application in response to the input data from the host application. Embodiment 31: A host configured to operate in a communication system to provide an over-the-top (OTT) service, comprising: a processing circuit configured to provide user data; and a network interface configured to initiate transmission of the user data to a cellular network for transmission to a user device (UE), wherein the UE comprises a communication interface and a processing circuit, and the communication interface and processing circuit of the UE are configured to perform any of the steps of any of the embodiments of Group A to transmit the user data to the host. Embodiment 32: A host according to the above embodiment, wherein the cellular network further includes network nodes configured to communicate with the UE in order to transmit the user data from the UE to the host. Embodiment 33: A host according to the two embodiments described above, wherein the processing circuit of the host is configured to execute a host application and thereby provide the user data, the host application is configured to interact with a client application that runs on the UE, and the client application is associated with the host application. Embodiment 34: A method performed by a host configured to operate in a communication system further including network nodes and user equipment (UEs), the host comprising receiving user data transmitted to the host by the UEs via the network nodes, wherein the UEs perform any of the steps of any of the embodiments of Group A to transmit the user data to the host. Embodiment 35: A method according to the above embodiment, further comprising running a host application associated with a client application running on the UE in order to receive the user data from the UE. Embodiment 36: A method of the above embodiment, further comprising the host transmitting input data to the client application running on the UE, wherein the input data is provided by running the host application, and the user data is provided by the client application in response to the input data from the host application. Embodiment 37: A host configured to operate in a communication system to provide an over-the-top (OTT) service, comprising: a processing circuit configured to provide user data; and a network interface configured to initiate the transmission of the user data to a network node in a cellular network for transmission to a user device (UE), wherein the network node has a communication interface and a processing circuit, and the processing circuit of the network node is configured to perform any operation of any of the embodiments of Group B in order to transmit the user data from the host to the UE. Embodiment 38: A host according to the above embodiment, wherein the processing circuit of the host is configured to run a host application that provides the user data, and the UE comprises a processing circuit configured to run a client application associated with the host application in order to receive the transmission of the user data from the host. Embodiment 39: A method implemented in a host configured to operate in a communication system further including network nodes and user equipment (UEs), comprising providing user data for the UEs and initiating a transmission to carry the user data to the UEs via a cellular network comprising the network nodes, wherein the network nodes perform any operation of any of the embodiments of Group B in order to transmit the user data from the host to the UEs. Embodiment 40: A method according to the above embodiment, further comprising transmitting the user data provided by the host for the UE at the network node. Embodiment 41: A method according to either of the two embodiments described above, wherein the user data is provided on the host by running a host application that interacts with a client application running on the UE, and the client application is associated with the host application. Embodiment 42: A communication system configured to provide an over-the-top service, comprising: a processing circuit configured to provide user data for a user device (UE), the user data being associated with the over-the-top service; and a network interface configured to initiate transmission of the user data toward a cellular network node for transmission to the UE, wherein the processing circuit on the network node is configured to perform any operation of any of the embodiments of Group B for transmission of the user data from the host to the UE. Embodiment 43: A communication system according to the above embodiment, further comprising the network node and / or the user equipment. Embodiment 44: A host configured to operate in a communication system to provide an over-the-top (OTT) service, comprising: a processing circuit configured to initiate the reception of user data; and a network interface configured to receive the user data from a network node in a cellular network, wherein the network node has a communication interface and a processing circuit, and the processing circuit of the network node is configured to perform any operation of any of the embodiments of Group B in order to receive the user data from a user equipment (UE) on behalf of the host. Embodiment 45: A host according to the two embodiments described above, wherein the processing circuit of the host is configured to execute a host application and thereby provide the user data, the host application is configured to interact with a client application that runs on the UE, and the client application is associated with the host application. Embodiment 46: A host of either of the two embodiments described above, wherein initiating the reception of the user data includes requesting the user data. Method implemented by a host configured to operate in a communication system further comprising a network node and a user equipment (UE), the method comprising, at the host, starting to receive user data from the UE, the user data being derived from a transmission received by the network node from the UE, the network node performing any of the steps of any of the embodiments of Group B to receive the user data from the UE for the host. Method according to the method of the above embodiment, further comprising, at the network node, transmitting the received user data to the host.

[0187] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered to be within the scope of the concepts disclosed herein.

Claims

1. A method performed by a user device (UE), Receiving one or more messages from a network node, including Quality of Experience (QoE) configurations and Wireless Access Network (RAN) Visible QoE (RVQoE) configurations (700A, 700B-1), The QoE configuration includes an indication showing a first signaling radio bearer (SRB) used to report QoE measurements. The RVQoE configuration includes an indication showing a second signaling radio bearer (SRB) used to report RVQoE measurements, Performing QOE measurement and RVQoE measurement according to the QOE configuration and the RVQoE configuration, respectively (702) Sending a QOE report including the QOE measurement results using the first SRB shown for reporting the QOE measurement (704-1), A method comprising (704-2) transmitting an RVQoE report including the RVQoE measurement results using the second SRB shown for reporting the RVQoE measurement.

2. A method according to claim 1, wherein the first SRB and the second SRB are different.

3. A method according to claim 1, wherein the first SRB and the second SRB are the same.

4. The method according to claim 1, wherein the indication of the first SRB indicates a first node to which the QoE report is transmitted, A method wherein the indication of the second SRB indicates a second node to which the RVQoE report is transmitted.

5. A method according to claim 4, wherein the first node to which the QoE report is transmitted is different from the second node to which the RVQoE report is transmitted.

6. A method according to claim 4, wherein the indication indicating a first node to which the QoE report is transmitted is comprised of either the QoE configuration or a message that may include the QoE configuration.

7. A method according to claim 4, wherein the indication indicating the first node to which the QoE report is transmitted is an indication that a MeasurementReportAppLayer message containing a specific report type should be included in a message used to encapsulate a message being forwarded from a master node to a secondary node or vice versa.

8. A method according to claim 4, wherein the indication indicating a common network node to which a QoE report is sent is an indication that a MeasurementReportAppLayer message containing a specific report type should be included in a message used to encapsulate a message being forwarded from a master node to a secondary node or vice versa.

9. A method according to claim 4, wherein the indication indicating a common network node to which an RVQoE report is transmitted is an indication that a MeasurementReportAppLayer message containing a specific report type should be included in a message used to encapsulate a message being forwarded from a master node to a secondary node or vice versa.

10. The method according to claim 1, wherein the QoE configuration does not include an indication showing an SRB used to report the QoE measurement, The method further comprises (704-1) using SRB4 to transmit a QoE report including QoE measurement results.

11. The method according to claim 1, wherein the RVQoE configuration does not include an indication showing an SRB used to report the RVQoE measurement, The method further comprises (704-2) using SRB4 to transmit an RVQoE report including RVQoE measurement results.

12. User equipment (UE), Receiving one or more messages from a network node, including Quality of Experience (QoE) configurations and Wireless Access Network (RAN) Visible QoE (RVQoE) configurations (700A, 700B-1), The QoE configuration includes an indication showing a first signaling radio bearer (SRB) used to report QoE measurements. The RVQoE configuration includes an indication showing a second signaling radio bearer (SRB) used to report RVQoE measurements, Performing QOE measurement and RVQoE measurement according to the QOE configuration and the RVQoE configuration, respectively (702) Sending a QOE report including the QOE measurement results using the first SRB shown for reporting the QOE measurement (704-1), User equipment (UE) adapted to perform the following: sending an RVQoE report containing the RVQoE measurement results using the second SRB shown for reporting the RVQoE measurement (704-2).

13. The UE according to claim 12, further adapted to perform the method described in any one of claims 2 to 11.

14. User equipment (UE) (1100), Communication interface (1112), The processing circuit (1102) associated with the communication interface (1112) is included, and the processing circuit (1102) provides the UE (1100) Receiving one or more messages from a network node, including Quality of Experience (QoE) configurations and Wireless Access Network (RAN) Visible QoE (RVQoE) configurations (700A, 700B-1), The QoE configuration includes an indication showing a first signaling radio bearer (SRB) used to report QoE measurements. The RVQoE configuration includes an indication showing a second signaling radio bearer (SRB) used to report RVQoE measurements, Performing QOE measurement and RVQoE measurement according to the QOE configuration and the RVQoE configuration, respectively (702) Sending a QOE report including the QOE measurement results using the first SRB shown for reporting the QOE measurement (704-1), User equipment (UE) configured to transmit an RVQoE report containing the RVQoE measurement results using the second SRB indicated for reporting the RVQoE measurement (704-2).

15. A UE according to claim 14, wherein the processing circuit (1102) is further configured to cause the UE (1100) to perform the method according to any one of claims 2 to 11.

Images