Sending the difference between QoE report and RVQoE report
By configuring QoE and RVQoE reports to different network nodes in dual connectivity scenarios, the solution addresses the limitation of unified reporting in 3GPP specifications, enhancing flexibility and optimizing network resource utilization.
Patent Information
- Application Number
- JP2025507051
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2022-10-28
- Filing Date
- 2023-10-23
- Publication Date
- 2025-11-05
- Estimated Expiration
- 2043-10-23
AI Technical Summary
Current 3GPP specifications limit QoE and RVQoE measurement reports to be sent to the same node, despite serving different purposes and having different recipients, which is an unnecessary restriction, especially in dual connectivity scenarios like NR-DC.
The proposed solution allows QoE and RVQoE reports to be directed to specific network nodes by configuring the UE with indications for the node or cell group to send each report to, using explicit or implicit indications such as SRB, data flow handling nodes, or autonomous decision by the UE, enabling separate routing of QoE and RVQoE reports.
This solution provides greater flexibility in reporting, allowing RVQoE reports to be routed to the intended RAN node for immediate adaptation while QoE reports are sent to different RAN nodes for offline analysis, optimizing network resource utilization and report handling.
Smart Images

Figure 2025536175000001_ABST
Abstract
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 incorporated herein by reference in its entirety.
[0002] Technical Field The present disclosure relates to quality of experience (QoE) and radio access network (RAN) visible QoE (RVQoE) reporting in cellular communication systems. [Background technology]
[0003] Overview of QoE frameworks and "normal QoE" Quality of Experience (QoE) measurements, also known as "application layer measurements," are specified 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 specific application. QoE measurements for streaming services and Mobility Telephony Services 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 QoE solution is similar in NR, LTE, and UMTS in the following overall principle: Quality of Experience Measurement Collection (QMC) enables the configuration of application layer measurements in 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 operation, administration, and maintenance (OAM) system or core network (CN) is encapsulated in a transparent container, which is 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 UE's upper layer (application layer) is encapsulated in a transparent container and sent to the network in an uplink RRC message. The RAN then forwards the QoE report to a measurement collector entity (MCE).
[0005] Configuration data related to QoE measurements (typically referred to in standards as application layer measurements) is received by the base station (e.g., next-generation Node B (gNB) for NR) from OAM and consists of a service type indication, an indication of the area where the measurements should be performed (denoted area scope), the IP address of the entity (often called MCE and spelled Measurement Collector Entity or Measurement Collection Entity, but this entity is sometimes also called Trace Collection Entity) to which the collected measurements (i.e., QoE reports) should be sent, and a set of instructions on what type of measurements should be performed and details of how these measurements should be performed. These instructions are targeted to the application layer within the UE and are placed in a "container" that the network entities that handle them, e.g., forward them to the UE, as well as the UE access stratum, cannot interpret and do not attempt to read.
[0006] The container is transferred to the UE in RRC signaling together with the indicated service type. For measurements in RRC_CONNECTED, the area is kept in the base station (e.g., gNB in case of NR) and the network ensures that the UE measures in the correct area by configuring the UE when to start and stop measurements. The area scope is defined in terms of a cell or network-related area. 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 in particular QoE configuration, is provided in two flavors: management-based QoE configuration and signaling-based QoE configuration. In both cases, the QoE configuration originates from the OAM system or some other management entity, e.g., dealing with customer satisfaction. All of these entities are referred to as OAM systems in this document (although the OAM system also 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 that are within its area scope (and that also meet 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 measurements from a particular UE, for example, because the UE's user has filed a complaint. The OAM system sends the s-based QoE configuration to the Home Subscriber Server (HSS) (in Evolved Packet System (EPS) / LTE) or Unified Data Management (UDM) (in 5G / NR), which forwards the QoE configuration to the UE's current core network (CN) node, such as 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 the RAN node serving the relevant UE, which then forwards it to the UE.
[0009] A container with a service type indication and a measurement command 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 trace functionality, and a trace identifier (ID) is associated with each QoE configuration. In NR, the QoE function is logically separated from the trace functionality, but it still partially reuses the trace signaling mechanism. In NR and LTE, a globally unique QoE reference (formed from the Mobile Country Code (MCC) + Mobile Network Code (MNC) + QMC ID (the QMC ID is a 24-bit string)) is associated with each QoE configuration. The QoE reference is included in the container together with the measurement command 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, denoted 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 transferred in AT commands (which are the type of commands used in communication between the modem part of the UE and the application layer of the UE) together with a container with a service type indication and a measurement command.
[0010] Reports with collected QoE measurements (QoE reports) are sent from the UE application layer to the UE access stratum, which forwards them to the RAN, which forwards them to the MCE. These QoE measurements are placed in a "container" that is opaque to the UE access stratum and the RAN. QoE reports can be configured to be sent periodically or only at the end of an application session. Furthermore, the RAN can instruct the UE to suspend QoE reporting, for example, if the cell / gNB is overloaded.
[0011] The RAN does not know when an application session with an associated QoE measurement session is ongoing, and the UE access stratum does not automatically know this either. To mitigate this, a session start / stop indication is introduced, sent from the application layer in the UE to the UE AS and from the UE AS to the RAN. A session end indication is sent when an application session and associated QoE measurement session are completed.
[0012] As an implementation-based decision, the RAN may decide to release the QoE configuration in the UE at any time, typically when the UE moves out of the area configured for QoE measurements (commonly called area scope) and the measurement session ends.
[0013] RAN Visible QoE (RVQoE) An extension of the QoE framework implemented in 3GPP Release 17 is the concept of RAN-visible QoE (RVQoE). Regular QoE reports are intended for entities external to the RAN, such as the MCE, which is part of the OAM system, and the RAN cannot read them (at least not according to the specification, although gNB / eNB implementations are not prevented from doing so). In contrast, reported RVQoE metrics are intended for the RAN and delivered to it in a format that the RAN understands. RVQoE metrics are derived from regular QoE metrics, collected, compiled into a report by the UE application layer, and delivered to the RAN, so that the RAN can use the report for various types of optimization. For example, if the RAN receives an RVQoE report during an ongoing application session, the RAN can perform adaptation actions that affect the QoE of the involved application session while the application session is ongoing, such as modifying various parameters related to the UE's scheduling and the data flow associated with the application session.
[0014] End-to-end description of QoE measurements End-to-end signaling for QoE measurement configuration is described in 3GPP Technical Specification (TS) 28.405 v.18.0.0, Chapter 4. Chapter 4.5 of 3GPP TS 28.405 describes management-based QoE activation 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 is Registered) of 3GPP TS 28.405. Chapter 4.6 of 3GPP TS 28.405 describes signaling-based QoE activation in NR, as shown in Figure 2.
[0015] Configuration and reporting of QoE and RVQoE measurements in RRC The configuration of QoE and RVQoE measurements is done by the RRC message RRCReconfiguration and the reports are sent in the RRC message MeasurementReportAppLayer according to the signaling flow illustrated in FIG.
[0016] RRCReconfiguration contains the information element AppLayerMeasConfig, which contains either a configuration container for normal QoE configuration or RRC parameters for RVQoE configuration, as shown below.
[0017] -AppLayerMeasConfig The IE AppLayerMeasConfig indicates the configuration of application layer measurements.
[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] JPEG2025536175000002.jpg124169
[0020] JPEG2025536175000003.jpg53169
[0021] JPEG2025536175000004.jpg17169
[0022] The MeasurementReportAppLayer contains either a report container for normal QoE or RRC parameters for RVQoE reporting, as shown below.
[0023] -MeasurementReportAppLayer The MeasurementReportAppLayer message is used to send an application layer measurement report. Signaling Radio Bearer: SRB4 RLC-SAP:AM Logical channel: DCCH 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 MeasReportAppLayer-r17 ::= SEQUENCE { measConfigAppLayerId-r17 MeasConfigAppLayerId-r17, 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] JPEG2025536175000005.jpg43170
[0026] JPEG2025536175000006.jpg68169
[0027] In existing specifications, the network can only configure RVQoE if the corresponding configuration of regular QoE also exists in the UE.
[0028] QoE metrics for streaming services Specifications relating to QoE metrics for progressive download and 3GPP Adaptive Hypertext Transfer Protocol (HTTP) streaming, referred to 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 QoE reporting: - average throughput, - initial playout delay, - buffer level, - playlists, -Device information.
[0030] The following metrics MUST be supported by 3GP-DASH clients that support the QoE reporting feature: - a list of representation switching events, - average throughput, - initial playout delay, - buffer level, - playlists, -MPD information, -Device information.
[0031] AT Commands AT commands are used for communication between the AS (radio) layer and the application layer in the UE. AT commands are specified in 3GPP TS 27.007 version 17.6.0. AT commands are used in QoE to transfer configurations from the RRC layer to the application and to transfer reports from the application layer to the RRC layer.
[0032] 3GPP Dual Connectivity In 3GPP Rel-12, the LTE feature Dual Connectivity (DC) was introduced to allow a UE to be connected to two cell groups, each controlled by an LTE access node, eNB, labeled Master eNB (MeNB) and Secondary eNB (SeNB). The UE still has only one RRC connection with the network. 3GPP has since evolved Dual Connectivity (DC) solutions and now specifies them for NR as well as between LTE and NR. Multi-Connectivity (MC) is when more than two nodes are involved. 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 the generalized terminology 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 a UE, carrier aggregation may also be used within each of two cell groups, MCG and SCG. In this case, within a master cell group (MCG) controlled by a master node (MN), a UE may use one primary cell (PCell) and one or more secondary cells (SCells). Within a secondary cell group (SCG) controlled by a secondary node (SN), a UE may use one primary SCell (PSCell, also known as a primary SCG cell in NR) and one or more SCells. This combined case is illustrated in Figure 4. In NR, a primary cell of a master or secondary cell group is sometimes called a special cell (SpCell). Therefore, the SpCell in the MCG is a PCell, and the SpCell in the SCG is a PSCell.
[0034] There are various ways to deploy 5G networks, with or without interworking with LTE (also known as E-UTRA) and the Evolved Packet Core (EPC). In principle, NR and LTE can be deployed without any interworking, indicated by NR Standalone (SA) operation, also known as Option 2, i.e., the gNB in NR can be connected to the 5G Core Network (5GC) and the eNB in LTE can be connected to the EPC without any interconnection between the two, also known as Option 1.
[0035] On the other hand, the first supported version of NR uses dual connectivity, denoted 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 an LTE air interface to an LTE access node (LTE Uu in the figure) and an NR air interface to an NR access node (NR Uu in the figure). Furthermore, in EN-DC, the LTE access node acts as a master node (in this case known as a master eNB, MeNB) and controls the master cell group MCG, while the NR access node acts as a secondary node (in this case sometimes known as a secondary gNB, SgNB) and controls the secondary cell group SCG. The SgNB may not have a control plane connection to the MeNB, in this case the core network (EPC) where NR is provided. This is also referred to as "non-standalone NR" or "NSA NR" for short. Note that in this case, the functionality of the NR cells is limited and they will be used as booster and / or diversity legs for connected mode UEs, but RRC_IDLE UEs cannot camp on these NR cells.
[0036] With the introduction of 5GC, other options may also be available. As mentioned above, Option 2 supports standalone NR deployments where a gNB is connected to 5GC. Similarly, LTE can also be connected to 5GC using Option 5 (also known as eLTE, E-UTRA / 5GC, or LTE / 5GC, where the node may be referred to as ng-eNB). In these cases, both NR and LTE are considered part of the NG-RAN (and both the ng-eNB and gNB may be referred to as NG-RAN nodes).
[0037] It is worth noting that there are also other variants of dual connectivity between LTE and NR that are standardized as part of NG-RAN connected to 5GC. 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 secondary (5GCN is used). ● NGEN-DC (Option 7): LTE is the master node and NR is the secondary (5GCN is used). ● NR-DC (variant of option 2): Dual connectivity in which both the master node MN controlling the MCG and the secondary node SN controlling the SCG are NR (5GCN is used, as shown in Figure 6). Summary of the Invention
[0038] 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 from one or more network nodes, the messages including one or more QoE configurations and one or more RVQoE configurations. 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. The method further includes 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 measurements and RVQoE measurements in accordance with the one or more QoE configurations and the one or more RVQoE configurations. The method further comprises, for each QoE report of the one or more QoE reports comprising results of the QoE measurements, sending the QoE report to the indicated network node to which the QoE report is to be sent. The method further comprises, for each RVQoE report of the one or more RVQoE reports comprising results of the QoE measurements, sending the RVQoE report to the indicated network node to which the QoE report is to be sent. 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 the RVQoE report is sent for at least one of the one or more RVQoE configurations.
[0040] In one embodiment, the method comprises receiving, for each QoE configuration, an indication indicating a network node from which a respective QoE report is to be transmitted. In one embodiment, for each QoE configuration of the one or more QoE configurations, the indication indicating the network node from which a respective QoE report is to be transmitted is included in either the QoE configuration or in message(s) that may include the QoE configuration. In one embodiment, for at least one QoE configuration of the one or more QoE configurations, the indication indicating the network node from which a respective QoE report is to be transmitted is an indication of a signaling radio bearer (SRB) for transmitting the respective QoE report.
[0041] In one embodiment, the method includes receiving, for each RVQoE configuration, an indication indicating a network node to which a respective RVQoE report is to be transmitted. In one embodiment, for each RVQoE configuration of the one or more RVQoE configurations, the indication indicating the network node to which a respective RVQoE report is to be transmitted is included in either the RVQoE configuration or in message(s) containing the RVQoE configuration. In one embodiment, for at least one RVQoE configuration of the one or more RVQoE configurations, the indication indicating the network node to which a respective RVQoE report is to be transmitted is an indication of an SRB to transmit the respective RVQoE report.
[0042] In one embodiment, the method comprises receiving, common for all of the one or more QoE configurations, an indication indicating a common network node to which a QoE report is to be sent, hi one embodiment, the indication indicating the common network node to which the QoE report is to be sent is included in either at least one of the one or more QoE configurations or in message(s) including at least one of the one or more QoE configurations.
[0043] In one embodiment, the method includes receiving, common for all of one or more RVQoE configurations, an indication indicating a common network node from which the respective RVQoE report is to be transmitted. In one embodiment, the indication indicating the common network node from which the RVQoE report is to be transmitted is included in either at least one of the one or more RVQoE configurations or in message(s) including at least one of the one or more RVQoE configurations. In one embodiment, the indication indicating the common network node from which the RVQoE report is to be transmitted is an indication of an SRB for transmitting the RVQoE report.
[0044] Corresponding embodiments of a UE are also disclosed. In one embodiment, the UE is adapted to receive one or more messages including one or more QoE configurations and one or more RVQoE configurations from one or more network nodes. The UE is further adapted to receive, 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. The UE is further adapted to receive, 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 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. The UE is further adapted, for each QoE report of the one or more QoE reports including a result of the QoE measurements, to transmit the QoE report to the indicated network node to which the QoE report is to be sent. The UE is further adapted to, for each RVQoE report of the one or more RVQoE reports including a result of the QoE measurement, send the RVQoE report to the indicated network node to which the QoE report is to be sent.
[0045] In one embodiment, a 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 including one or more QoE configurations and one or more RVQoE configurations from one or more network nodes. The processing circuit is further configured to cause the UE to receive, 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. The processing circuit is further configured to cause the UE to receive, 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 processing circuit is further configured to cause the UE to perform QoE measurements and RVQoE measurements in accordance with the one or more QoE configurations and the one or more RVQoE configurations. The processing circuitry is further configured to cause the UE, for each QoE report of one or more QoE reports including results of the QoE measurements, to transmit the QoE report to the indicated network node to which the QoE report is to be transmitted. The processing circuitry is further configured to cause the UE, for each RVQoE report of one or more RVQoE reports including results of the QoE measurements, to transmit the RVQoE report to the indicated network node to which the QoE report is to be transmitted.
[0046] Also disclosed are embodiments of a method performed by a first network node. In one embodiment, the method performed by the first network node comprises transmitting one or more messages to a UE including one or more QoE configurations and one or more RVQoE configurations, the one or more messages further including, for each QoE configuration or jointly for the one or more QoE configurations, an indication indicating a network node to which a respective QoE report is to be sent, and for each RVQoE configuration or jointly for the one or more RVQoE configurations, an indication indicating a network node to which a respective RVQoE report is to be sent.
[0047] A corresponding embodiment of the first network node is also disclosed.
[0048] Also disclosed are embodiments of a method performed by a second network node. In one embodiment, the method performed by the second network node comprises receiving, from a UE, one or more messages including 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 jointly for the one or more QoE configurations, the UE is either configured with or determines the network node at which the respective QoE report is sent. For each RVQoE configuration, or jointly for the one or more RVQoE configurations, the UE is either configured with or determines the network node at which the respective RVQoE report is sent.
[0049] A corresponding embodiment of a second network node is also disclosed. [Brief explanation of the drawings]
[0050] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate several aspects of the present disclosure and, together with the description, serve to explain the principles of the disclosure. [Figure 1] This is a reproduction of Figure 4.6.1.1-1 (Quality of Experience (QoE) Measurement Collector (QMC) Activation and Reporting in New Radio (NR) after User Equipment (UE) is Registered) from the 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 28.405 V18.0.0. [Figure 2] Describe signaling-based QoE activation in NR. [Figure 3] This paper describes the configuration of QoE and Radio Access Network (RAN) Visible QoE (RVQoE) measurement and reporting, and the signaling flow for QoE and RVQoE reporting. [Figure 4] An example where dual connectivity (DC) and carrier aggregation (CA) are combined will be described. [Figure 5] An example of DC will be described. [Figure 6] Another variation of DC will now be described. [Figure 7] 1 is a flowchart illustrating the operation of a wireless terminal (also referred to as user equipment UE) for QoE / RVQoE measurement configuration and reporting in accordance with an embodiment 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 the present disclosure will be 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 an embodiment of the present disclosure will now be described. [Figure 10] 1 illustrates an example of a communication system according to some embodiments. [Figure 11] 1 illustrates a UE according to some embodiments. [Figure 12] 1 illustrates a network node according to some embodiments. [Figure 13] 11 is a block diagram of a host that may be an embodiment of the host of FIG. 10 in accordance with various aspects described herein. [Figure 14]FIG. 1 is a block diagram illustrating a virtualization environment in which functionality implemented by some embodiments may be virtualized. [Figure 15] 1 illustrates a communication diagram of a host communicating with a UE via a network node over a partially wireless connection according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION
[0051] The embodiments described below represent information to enable those skilled in the art to practice the embodiments and explain the best modes of practicing the embodiments. Upon reading the following description in light of the accompanying drawings, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not specifically addressed herein. It is to 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 completely different purposes: the former is primarily application-level feedback for offline analysis and long-term adaptation, while the latter is real-time feedback from the application to the RAN for immediate adaptation of the processing of ongoing application sessions. In current 3GPP specifications, QoE and RVQoE measurement reports are always reported in the same way according to the same configuration, e.g., 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] Certain aspects of the present disclosure and these embodiments may provide solutions to these and other problems. Disclosed herein are system and method embodiments that provide solutions for directing QoE and RVQoE reports to specific network nodes, for example, in dual connectivity scenarios (e.g., in NR-DC scenarios). This may be achieved by configuring the UE with an indication indicating the node or cell group to which the QoE report should be sent and an indication indicating 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 node or cell group (eg Master Cell Group (MCG), Secondary Cell Group (SCG)). - An indication to send the report to the cell group carrying the data flow(s) of the application session to which the report relates. -Indication of the signaling radio bearer (SRB) to use for transmission. - An indication (explicit or implicit) that a report should be sent to the node that sent the configuration. - An indication (explicit or implicit) that the report should be sent to the node handling the (one or more) Data Radio Bearers (DRBs) carrying the (one or more) data flows of the application session to which the report relates.
[0054] An indication (explicit or implicit) that the user equipment (UE) may autonomously decide to which node(s) to send reports to.
[0055] If the UE has a QoE or RVQoE report to send, it sends the report according to the indication included in the configuration. In one embodiment, if the report is targeted to 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 is targeted to a secondary node (SN), the UE may use a ULInformationTransferMRDC message 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 targeted to the MN and messages targeted to the SN. With the option to configure different nodes for QoE and RVQoE reports, the network can target the reports to the nodes that are preferred receivers of the reports.
[0056] Particular embodiments may provide one or more of the following technical advantages: Embodiments of the present disclosure may allow greater flexibility regarding the transmission of QoE and RVQoE reports. In this solution, RVQoE reports may be routed to the RAN node that is the intended recipient of the report, while QoE reports for operations, administration, and maintenance (OAM) purposes may be routed to a different RAN node. This is advantageous because QoE reports may be large, and because these reports are targeted to a specific node, it would be beneficial if the network could configure the UE to send these reports to less loaded nodes without having to configure shorter RVQoE reports for 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 equipment (UE) for RAN visible quality of experience (RVQoE) report(s). Such a request may be equivalently referred to as an indication to the UE to send the RVQoE report(s), or an indication of a fulfillment or RAN event (or RAN event(s)) to trigger the RVQoE reporting.
[0058] Many field (i.e., parameter) or information element (IE) names in the Radio Resource Control (RRC) configuration for New Radio (NR) (3GPP TS 38.331 version 17.1.0) are referenced either with a postfix indicating the 3GPP standard release (e.g., "-r17" indicating 3GPP Release 17) or with the same name without the postfix. The version with the postfix is used in the ASN.1 code, while the version without the postfix is used elsewhere in this specification. In this document, the two versions of the name are used interchangeably, where applicable (i.e., when both versions of the field's name exist in 3GPP TS 38.331 version 17.1.0). For example, the names "AppLayerMeasConfig" and "AppLayerMeasConfig-r17" refer to the same IE.
[0059] RAN nodes include Next Generation Node B (gNB), Evolved Node B (eNB), en-gNB, Next Generation eNB (ng-eNB), gNB Central Unit (gNB-CU), gNB-CU Control Plane Part (gNB-CU-CP), gNB-CU User Plane Part (gNB-CU-UP), eNB Central Unit (eNB-CU), eNB-CU Control Plane Part (eNB-CU-CP), eNB-CU User Plane Part (eNB-CU-UP), Integrated Access and Backhaul (IAB) node, IAB Donor Distributed Unit (DU), IAB Donor Central Unit (CU), IAB-DU, IAB Mobile Termination (IAB-MT), Open RAN CU (O-CU), O-CU Control Plane Part (O-CU-CP), O-CU User Plane Part (O-CU-UP), Open RAN Distributed Unit (O-DU), Open RAN Radio Unit (O-RU), Open RAN It may be an eNB (O-eNB), a non-real-time RAN intelligent controller (Non-RT RIC), a real-time RAN intelligent controller (RT-RIC), 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 the part of the QoE configuration that consists of an XML file containing instructions such as which QoE metrics to collect.
[0061] The solution(s) proposed in this document apply to both signaling-based and management-based Quality of Experience (QoE) measurements (but may optionally be restricted to apply 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 "radio stratum" are used interchangeably when referring to a UE.
[0065] The solution(s) are equally applicable to QoE and RAN visible QoE measurement and reporting, which means, among other things, that the considerations for QoE configuration, QoE measurement and QoE reporting also apply to RVQoE configuration, RVQoE measurement and RVQoE reporting.
[0066] The solution(s) are presented for the example of a UE in dual connectivity, but may also be applied to radio access technologies where the UE is served by more than two legs.
[0067] The solution(s) proposed in this document apply to NR as well as future radio access technologies (RATs) such as 6G, where the IAB-MT is the parent backhaul link termination function and the IAB-DU is the access service provision function of the relay node.
[0068] "Sending a report to a node" may or may not imply that the node in question is the consumer, i.e., the final destination of the report.
[0069] The terms "node" and "network node" are used interchangeably herein.
[0070] Transmission to a master node (MN) or a secondary node (SN) means using a carrier in a master cell group (MCG) or a carrier in a secondary cell group (SCG), respectively.
[0071] 2. Overview As mentioned above, QoE reports and RVQoE reports serve entirely different purposes. This is reflected by the fact that the RAN forwards QoE reports (not interpreted) to a Measurement Collection Entity (MCE), whereas RVQoE reports are kept within the RAN, analyzed, and used as a basis for possible adaptation of the treatment of ongoing application session data flows. This is an existing example of differential treatment of QoE reports and RVQoE reports. However, other aspects of differential treatment of QoE reports 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 embodiments of the proposed solution(s).
[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 the QoE measurements / reports and the RVQoE measurements / reports imply that different network nodes (i.e., MN and SN) may be preferred receivers of the QoE reports and the RVQoE reports. In particular, it is preferable that the RVQoE reports be sent to nodes that may affect the processing of the data flows of the application sessions to which the RVQoE reports relate, i.e., the nodes that process the data flows of the application sessions to which the RVQoE reports relate.
[0073] As an example, consider a UE in NR-DC mode with different gNBs acting as the MN and SN, respectively. Furthermore, the MN has received signaling-based QoE configurations from the core network (CN) (i.e., Access and Mobility Management Function (AMF)) and forwarded them to the relevant UEs, and the RAN (MN, SN, or both in cooperation) has also configured the UE with corresponding RVQoE measurements. If data flows of application sessions of service types targeted by the QoE configuration and RVQoE configuration are subsequently transmitted via the SN (i.e., on SCG bearers), the network may want the QoE reports to go to the MN and the RVQoE reports to go to the SN.
[0074] This can be achieved in a number of ways.
[0075] One method is to utilize the legacy mechanism of forwarding a radio resource control (RRC) message from the UE via the MN to the SN embedded in a 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 normal RRC message, while the MeasurementReportAppLayer RRC message containing the 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 forwards 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 allow direct transfer of RRC messages from the UE to the SN, the above encapsulation and transfer mechanism is primarily intended to be used when SRB3 is not configured or implemented.)
[0076] Another way is to utilize signaling radio bearers (SRBs) that are inherently intended for different nodes. As an example, the UE can send a QoE report to the MN on SRB4 and a RVQoE report to the SN on SRB3. A new signaling radio bearer, denoted as SRB5, may be used instead of SRB3 for sending QoE / RVQoE reports to the SN. Introducing such a new signaling radio bearer (SRB5) for the purpose of sending QoE and RVQoE reports to the SN is currently under discussion in 3GPP. In the current example, the UE can send a QoE report to the MN on SRB4 and a RVQoE report to the SN on SRB5.
[0077] It should be noted that, as mentioned above, the choice of sending the QoE report to the MN and the RVQoE report to the SN is merely an example, and the opposite, i.e., sending the QoE report to the SN and the RVQoE report to the MN, is also consistent with the proposed solution, as is sending both the QoE report and the RVQoE report to the same node, i.e., either the MN or the SN.
[0078] This kind of differential handling of QoE and RVQoE reports requires new signaling possibilities to instruct the UE, for example, to send a QoE report to the MN on SRB4 and to send 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 the RVQoE report, include the relevant RVQoE report parameters in a 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, the instruction to send a particular type of report to a particular node may, for example, have any one or more of the following forms: - An indication of the node (e.g., MN, SN). - An indication to send the report to the node carrying the data flow(s) of the application session to which the report relates. - indication of cell group (e.g. MCG, SCG), - An indication to send the report to the cell group carrying the data flow(s) of the application session to which the report relates. -Indication of the SRB to send (for example, SRB4 implies MN, SRB5 implies SN). - An indication that a MeasurementReportAppLayer message containing a particular report type should be included in a message (e.g., a ULInformationTransferMRDC RRC message) used to encapsulate messages transferred from the MN to the SN (or vice versa). - 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(s) handling the DRB(s) carrying the data flow(s) of the application session to which the report relates. - The absence of an indication may be an implicit indication that the UE can autonomously decide to which node the report should be sent.
[0079] Through such instructions, the QoE / RVQoE report sending behavior of the UE can be controlled per QoE / RVQoE configuration or globally for all QoE / RVQoE configurations in the UE, depending on which IE level in the ASN.1 definition (e.g., based on the ASN.1 definition in 3GPP TS38.331 version 17.2.0) the control parameters are placed in, for example, the AppLayerMeasConfig-r17 IE or the MeasConfigAppLayer-r17 IE and / or the RAN-VisibleParameters-r17 IE. Examples are provided in Section 3.2 below.
[0080] In section 3, embodiments of the proposed solution are further described in terms of methods / embodiments for the UE, MN and SN, respectively.
[0081] 3. Embodiments 3.1 Configuration and reporting of QoE and RVQoE measurements with the option to send QoE and RVQoE reports to different nodes It should be noted that in all the methods described in this section, the roles of the MN and the SN may be interchanged. That is, actions performed by the MN in the method descriptions may be performed by the SN, and vice versa. Similarly, interactions that the UE has with the MN and the SN may be interchanged between the MN and the SN, respectively. As described, the method generally applies even after such an interchange. Furthermore, the configurations related to QoE reports and RVQoE reports may be interchanged, and thus, 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 is configured with an MCG (Master Cell Group) associated with the MN and an SCG (Secondary Cell Group) associated with the SN.
[0082] 3.1.1 UE embodiment 7 is a flowchart illustrating the operation of a wireless terminal (also referred to as user equipment UE) for QoE / RVQoE measurement configuration and reporting in accordance with an embodiment of the present disclosure. As shown, the procedure of FIG. 7 includes:
[0083] - Step 700A:In a first alternative or option (Option A), the wireless terminal receives one or more messages, e.g., RRCReconfiguration message(s), from one or more network nodes, such as the MN or SN. The message(s) may include one or more QoE configurations (e.g., a QoE measurement configuration and a RVQoE measurement configuration), and each QoE / RVQoE configuration, or at least one of the QoE / RVQoE configuration(s), may include or be sent together (e.g., in the same message) with an indication of the network nodes to which the UE should transmit the QoE and / or RVQoE report, respectively. In one embodiment, the indication indicates that the UE may decide to which network nodes to transmit the QoE and / or RVQoE report (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 may or may not be based on input data provided by the network node). o The indication of a node can be either an explicit or implicit indication. o Examples of explicit indications are indications that point to a network node, such as a MN or SN or a MCG or SCG. In another option, the indication indicates the SRB that the UE should use to send the report. In one version of this embodiment, if the UE is capable of sending a report to either the MN or the SN, in the absence of an explicit indication, the UE interprets this as meaning that the UE is capable of sending a report to either the MN or the SN. o As another option, the absence of an explicit indication may be an implicit indication that the UE should send a report to the node that received the relevant configuration (i.e., QoE configuration or RVQoE configuration) (i.e., QoE report or RVQoE report depending on whether the indication of absence relates to a QoE configuration or an RVQoE configuration). As yet another option, the indication of which node to send the QoE and / or RVQoE report to may apply to all QoE and / or RVQoE configurations in the UE. In this option, the indication may be sent once to the UE, for example in an RRCReconfiguration message, instead of associating a separate indication for each QoE and / or RVQoE configuration. o An implicit indication may for example be the configuration of a specific SRB linked to the configuration of QoE or RVQoE measurements, the SRB being used for the transmission of QoE and / or RVQoE reports. The implicit indication can also depend on which part of the RRC message the configuration is included in. For example, if the configuration is included in the MN part of the message, the UE must send the report to the MN, whereas if the configuration is included 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 QoE reports to the node from which it received the QoE configuration and should send RVQoE reports to the node from which it received the RVQoE configuration. Alternatively, the implicit indication may be, for example, the configuration of specific identifiers (e.g., measConfigAppLayerId) associated with QoE / RVQoE configurations, where a first set of identifiers is reserved for the MN and another set of identifiers is reserved for the SN. For example, the first set of identifiers may be represented by all possible values of the measConfigAppLayerId-r17 IE and are reserved for QoE / RVQoE configurations that the MN can configure for the UE, and a second set of identifiers may be represented by all possible values of another IE, e.g., measConfigAppLayerId-r18, and are reserved for the SN. Explicit indication can be achieved by indicating the DRBs that the UE should use when sending / receiving application data to / from a particular network node that contributed to preparing the RVQoE configuration or that sends the QoE / RVQoE configuration to the UE. For example, a first list of DRBs may be included in the UE's QoE configuration (or RVQoE configuration) to indicate that the UE should use DRB IDs=X1, Y1, Z1 when sending / receiving application data to / from an MN node. This may be included in the QoE configuration as part of an "MCG-related" configuration. A second list of DRBs may also be included in the same QoE / RVQoE configuration (or a separate QoE / RVQoE configuration) to indicate that the UE can use a different set of DRBs (e.g., as included in an "SCG-related" configuration), e.g., DRB IDs=X2, Y2, Z2, when sending / receiving application data to / from an SN node. The MN and SN can perform a coordination procedure to determine a list of MN-associated DRBs and SN-associated DRBs associated with the UE's QoE / RVQoE report towards the MN and SN, respectively, where one of the nodes responsible for determining which DRBs the UE should use towards which node (e.g., the MN node) indicates a list of DRBs the UE should use when sending / receiving data for the application towards / from the MN node and, optionally, proposes a second list of DRBs the UE should use when sending / receiving data for the application towards / from the SN node. The other node, e.g., the SN node, can respond with a list of DRBs the UE should use when sending / receiving data for the application towards / from itself and may accept or reject the proposal from the responsible node (e.g., the MN). The list of MN-associated DRBs may be included in an RVQoE configuration prepared by the MN for the RVQoE reports it wishes to receive (e.g., 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 (e.g., as part of an SN-RVQoE configuration or an SCG-RVQoE configuration) that includes the list of SN-associated DRBs to the UE. The list of DRBs associated with the MN and the list of DRBs associated with the SN may not be explicitly indicated for QoE / RVQoE purposes, but the UE may receive it regardless of QoE processing and may (re)use the same lists when transmitting application data that is subject to QoE / RVQoE measurements. Alternatively, the UE may be provided with information to derive the node to which the report should be sent. The indication may for example be an indication to the UE to send the QoE report and / or the RVQoE report to the node carrying data of the application session for which the QoE measurements and / or RVQoE measurements are performed, respectively. o The UE may also be instructed by the network where to send the QoE and / or RVQoE reports in case of different reconfigurations related to dual connectivity. ● In the case where the UE is instructed to send QoE and / or RVQoE reports to nodes carrying data for an application session (as described above, the UE may be provided with information to derive the nodes to which the reports should be sent), an explicit indication can instruct the UE where to send the reports in case the node carrying the application session changes (which can occur for various reasons). Some non-limiting examples can be: If the MN and SN serving the UE remain the same but the node carrying the session changes (e.g. the change is that the data flow for the session starts to be carried via the MN and was previously carried via the SN), the UE may be instructed to: - From now on, sending QoE and / or RVQoE reports to the node that will carry the session from now on, instead of directing them to the node to which the QoE and / or RVQoE reports were sent up until now. - From now on, send QoE reports and / or RVQoE reports to the node that will carry the session from now on, instead of directing them to the node to which the report was sent so far. Continue reporting QoE reports and / or RVQoE to nodes currently receiving them. ● For mobility cases, eg MN change, SN change, an explicit indication can instruct the UE where to send the QoE and / or RVQoE reports. Continue sending QoE reports and / or RVQoE reports to nodes that play the same role (MN role or SN role) in dual connectivity as the node to which the QoE report was previously sent. If QoE reports and / or RVQoE reports have been sent to the MN up until now, continue to send the reports to the MN (and in case of MN change, to the new MN from now on). If QoE reports and / or RVQoE reports were previously sent to the SN, continue sending the reports to the SN (in case of SN change they will now be sent to the new SN). - Sending reports to a specific node, MN or SN in the future. ●For the case of changing from single to dual connectivity (SN addition), an explicit indication can instruct the UE where to send the report, for example by: ●From now on, reports should be sent to SN. - Continue reporting to nodes that have received reports so far, e.g., MN. The indication of the network node to which the UE must send the QoE report and the RVQoE report, respectively, may be the same node for the QoE report and the RVQoE report, or may be different nodes for the QoE report and the RVQoE report. o The configuration of QoE measurements and the configuration of RVQoE measurements may be done in the same message or in different messages. The configuration of the indication of the nodes to which the UE must send reports may be sent together with the configuration of QoE / RVQoE measurements or may be sent separately from the measurement configuration. o Messages with configuration to the UE may be sent from the MN, from the SN, or from both the MN and the SN.
[0084] - Steps 700B-1 and 700B-2: In a second alternative or option (Option B), the wireless terminal receives one or more messages from a network node, e.g., RRCReconfiguration message(s), where the message(s) include 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 QoE / RVQoE configuration(s), the UE determines the network nodes to which it must send the QoE and / or RVQoE report. This alternative allows the UE to determine to which nodes it will send the report.
[0085] - Step 702: The wireless terminal applies the received QoE / RVQoE configuration(s) and performs QoE / RVQoE measurements in accordance with the configuration(s).
[0086] - Step 704: The wireless terminal sends the QoE / RVQoE report to a network node that is indicated (explicitly, implicitly or derivably) in (or together with) the respective(one or more) QoE / RVQoE configuration(s) as the recipient of the QoE / RVQoE report. 〇 Step 704-1:The wireless terminal transmits, for each(s) QoE configuration(s), a QoE report(s) to the(s) first network node(s) 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 a message to the MN. The message containing the QoE report may for example be a MeasurementReportAppLayer message sent over SRB4. If the configuration indicates that a QoE report should be sent to the SN, include the QoE report in a message to the SN. The message containing the QoE report may be, for example, a MeasurementReportAppLayer message sent on SRB3 or on a new SRB5 configured towards the SN. Alternatively, the message may be a ULInformationTransferMRDC message with an embedded MeasurementReportAppLayer message sent to the MN on SRB4 for onward forwarding to the SN. The message may be a newly defined message. 〇 Step 704-2: The wireless terminal transmits the RVQoE report to the second network node(s) indicated (explicitly, implicitly, or derivably) in (or together with) the RVQoE configuration as the recipient of the RVQoE report. In other words, the wireless terminal transmits the RVQoE report to the second network node(s) indicated (as in step 700A) or determined by the wireless terminal (as in step 700B-2 of option B) for each RVQoE configuration(s). It should be noted that, since these are indicated or determined separately, the first network node(s) to which the QoE report(s) are transmitted may be different from the second network node(s) to which the RVQoE report(s) are transmitted. If the configuration indicates that an RVQoE report should be sent to the MN, include the RVQoE report in a 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 the RVQoE report should be sent to the SN, include the RVQoE report in a 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 towards the SN. Alternatively, the message may be a ULInformationTransferMRDC message with an embedded MeasurementReportAppLayer message sent to the MN on SRB4 or SRB1 for onward 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 or RVQoE measurement configurations in the UE. The UE may, for example, be configured to send some QoE or RVQoE reports to the MN and some other QoE or RVQoE reports to the SN, e.g., 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. As another option, the indication of which node to send the QoE and / or RVQoE report to may apply to all QoE and / or RVQoE configurations in the UE. In this option, the indication may be sent once to the UE, e.g., in an RRCReconfiguration message, instead of associating a separate indication for each QoE and / or RVQoE configuration. - The node selection and the order in which reports have to 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 QoE measurement configuration that all QoE measurements and / or all RVQoE measurements that the UE may have collected while in RRC_INACTIVE or RRC_IDLE state should always be sent to the MN. In one case, the UE may receive an indication in the QoE measurement configuration that all QoE measurements and / or all RVQoE measurements that the UE may have collected while in RRC_INACTIVE or RRC_IDLE state should always be sent to the SN. In one case, the UE may receive an indication in the QoE measurement configuration that all QoE measurements that the UE may have collected while in RRC_INACTIVE or RRC_IDLE state should be sent to the MN and that all RVQoE measurements that the UE may have collected while in RRC_INACTIVE or RRC_IDLE state should be sent to the SN. In one case, the UE may receive an indication in the QoE measurement configuration that all QoE / RVQoE measurements that the UE may have collected while in RRC_INACTIVE state must be sent to one of the MN or SN before sending all QoE / RVQoE measurements that the UE may have collected while in RRC_IDLE state.
[0088] The configuration of the node to which the report is sent may be implicitly derived based on indications / configuration parameters received by the RAN node as part of the QoE / RVQoE configuration from another network node (e.g., OAM or CN node), e.g., relating to the method the RAN should use for delivery of 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., MCE) to perform matching / correlation between QoE and radio measurements. In one case, another network node (e.g., OAM or CN node) can send an indication to the RAN (e.g., to the MN) that the QoE reports are to be delivered to the MCE in a streaming manner (e.g., indicating the MCE URI or URL). The above indication can be used implicitly to indicate that the RAN node configuring the UE should indicate in its configuration for the UE that all QoE reports must be sent from the UE to the MN and not 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 aligned with the radio measurements that the UE performs for the SN, and can use this indication to request the UE (e.g., as part of the RVQoE configuration) to send the RVQoE measurements configured by the SN to the SN.
[0089] 3.1.2 MN Implementation 8 illustrates 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 the present disclosure. As shown, the procedure of FIG. 8 includes the following steps:
[0090] - Step 800: The network node decides to configure the UE with QoE measurements and / or RVQoE measurements. o Possibly additionally or alternatively receiving a request from the SN to configure QoE measurements or RVQoE measurements. The request may for example be included in the S-NODE MODIFICATION REQUIRED message or in a new message (e.g. a new message dedicated to the QoE / RVQoE coordination aspects between the MN and the 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 for configuration of QoE measurements and / or a request for configuration of RVQoE measurements to a secondary node (SN). The request may for example be included in an S-NODE ADDITION REQUEST or S-NODE MODIFICATION REQUEST message or in a new message (e.g. 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 case of management-based QoE and RVQoE configuration, existing or newly defined non-UE related messages may be used, containing information and instructions about more than one UE. o Initiation of QoE and RVQoE measurements may be done by either MN or SN, or both nodes, and in any combination of which node initiates which type of measurement.
[0092] - Step 804: Optionally (if the above optional sending step is performed), the network node receives from the SN a response to the request for configuration of QoE measurements and / or a response to the response to the request for configuration of RVQoE measurements. The request may for example be included in an S-NODE ADDITION REQUEST ACKNOWLEDGE or S-NODE MODIFICATION REQUEST ACKNOWLEDGE message or in a new message (e.g. 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 case of management-based QoE and RVQoE configuration, existing or newly defined non-UE related messages may be used, containing information and instructions about more than one UE.
[0093] - Step 806: The network node sends one or more messages, for example (one or more) RRCReconfiguration messages, to the UE, which (one or more) messages include a QoE measurement configuration and a RVQoE measurement configuration, and for each QoE measurement configuration and (possibly for each) RVQoE measurement configuration, an indication of the network node to which the UE should send the QoE and / or RVQoE report, respectively. o The indication of a node can be either an explicit or implicit indication. An example of an explicit indication is an indication from a network node, such as the MN or SN, or, in another option, the UE, indicating which SRB to use to send the report. An implicit indication may for example be the configuration of a specific SRB linked to the configuration of QoE or RVQoE measurements. This may also depend on which part of the RRC message the configuration is included in: if the configuration is included in the MN part of the message, the UE must send the report to the MN, and if the configuration is included in the SN part 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 the RVQoE report, respectively, to the node carrying the session at the application layer. For further examples of explicit or implicit indication, see the UE embodiment above. The indication of the network node to which the UE must send the QoE report and the RVQoE report, respectively, may be the same node for the QoE report and the RVQoE report, or may be different nodes for the QoE report and the RVQoE report. o The configuration of QoE measurements and the configuration of RVQoE measurements may be done in the same message or in different messages. The configuration of the indication of the nodes to which the UE must send reports may be sent together with the configuration of QoE / RVQoE measurements or may be separate from the measurement configuration. Messages to the UE may be sent from the MN, from the SN, or from both the MN and the SN. All considerations relating to indication of where the UE should send reports listed under the UE embodiments are equally applicable to the MN as well, even if not listed under the MN embodiments in this document.
[0094] - Step 808: Optionally, the network node receives QoE reports from the UE if the MN is configured (explicitly, implicitly or derivably) to receive QoE reports. The message containing the QoE report may be a MeasurementReportAppLayer message sent over SRB4 for example.
[0095] - Step 810: Optionally, the network node receives RVQoE reports from the UE if the MN is configured (explicitly, implicitly or derivably) to receive QoE reports. The message containing the RVQoE report may be a MeasurementReportAppLayer message sent over e.g. SRB4. o If the MN is configured (explicitly, implicitly or derivably) to receive both QoE and RVQoE reports, the QoE and RVQoE reports may be received in the same message (e.g., MeasurementReportAppLayer message) or in different messages (e.g., two separate MeasurementReportAppLayer messages).
[0096] - Step 812: Optionally, if another node configured as an SN for the UE is configured (explicitly, implicitly or derivably) to receive the QoE report, and if the method for delivery of the QoE report from the UE to the SN is forwarding via the MN, the network node forwards the received QoE report to the other node configured as an SN. o The QoE report may be forwarded to the SN as one or more information elements on the XnAP level in an XnAP message. Alternatively, the MeasurementReportAppLayer RRC message containing the QoE report may be carried to the SN in an RRC TRANSFER XnAP message. In this case, the MN may receive the MeasurementReportAppLayer RRC message containing the QoE report encapsulated in a ULInformationTransferMRDC RRC message as one option.
[0097] - Step 814:Optionally, if another node configured as an SN for the UE is configured (explicitly, implicitly or derivably) to receive the RVQoE report, and if the method for delivery of the RVQoE report from the UE to the SN is forwarding via the MN, the network node forwards the received RVQoE report to the other node configured as an SN. o The RVQoE report may be forwarded to the SN as one or more information elements on the XnAP level in an XnAP message. Alternatively, the MeasurementReportAppLayer RRC message containing the RVQoE report may be carried to the SN in an RRC TRANSFER XnAP message. In this case, the MN may receive the MeasurementReportAppLayer RRC message containing the RVQoE report encapsulated in a ULInformationTransferMRDC RRC message as one option.
[0098] 3.1.3 SN Implementation 9 illustrates the operation of a network node configured as a secondary node (SN) for a UE for QoE measurement configuration and reporting according to an embodiment of the present disclosure. As shown, the procedure of FIG. 9 includes the following steps:
[0099] - Step 900: Optionally, the network node decides to configure the UE with QoE measurements and / or RVQoE measurements.
[0100] - Step 902: Optionally, additionally or alternatively, the network node receives a request for configuration of QoE measurements and / or a request for configuration of RVQoE measurements from a Master Node (MN) of the UE. The request may for example be included in an S-NODE ADDITION REQUEST or S-NODE MODIFICATION REQUEST message or in a new message (e.g. 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 case of management-based QoE and RVQoE configuration, existing or newly defined non-UE related messages may be used, containing information and instructions about more than one UE. o Initiation of QoE and RVQoE measurements may be done by either MN or SN, or both nodes, and in any combination of which node initiates which type of measurement.
[0101] - Step 904: Optionally, (if the above request for configuration of QoE measurements and / or a request for configuration of RVQoE measurements is received from the MN), the network node sends to the MN a response to the request for configuration of QoE measurements and / or a response to the request for configuration of RVQoE measurements, the response including the requested QoE measurement configuration and / or the requested RVQoE measurement configuration. The response may for example be included in an S-NODE ADDITION REQUEST ACKNOWLEDGE or S-NODE MODIFICATION REQUEST ACKNOWLEDGE message or in a new message (e.g. 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 case of management-based QoE and RVQoE configuration, existing or newly defined non-UE related messages containing information and instructions about 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 in two separate messages (e.g., if the request for QoE configuration and the request for RVQoE configuration are received in two separate messages from the MN).
[0102] - Step 906: Optionally, alternatively, the network node sends the MN a request to configure a QoE measurement or an RVQoE measurement. The request may for example be included in the S-NODE MODIFICATION REQUIRED message or in a new message (e.g. a new message dedicated to the QoE / RVQoE coordination aspects between MN and SN for QoE / RVQoE configuration and / or reporting, such as the QOE CONFIGURATION REQUIRED XnAP message). In case of management-based QoE and RVQoE configuration, existing or newly defined non-UE related messages may be used, containing information and instructions about more than one UE.
[0103] - Step 908: Optionally, the network node sends one or more messages, for example RRCReconfiguration, to the UE, the message(s) including the configuration of QoE measurements and the configuration of RVQoE measurements and including an indication of the network nodes to which the UE should send QoE and / or RVQoE reports, respectively. o The indication of a node can be either an explicit or implicit indication. An example of an explicit indication is an indication from a network node, such as the MN or SN, or, in another option, the UE, indicating which SRB to use to send the report. An implicit indication may for example be the configuration of a specific SRB linked to the configuration of QoE or RVQoE measurements. This may also depend on which part of the RRC message the configuration is included in: if the configuration is included in the MN part of the message, the UE must send the report to the MN, and if the configuration is included in the SN part 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 the RVQoE report, respectively, to the node carrying the session at the application layer. For further examples of explicit or implicit indication, see the UE embodiment above. The indication of the network node to which the UE must send the QoE report and the RVQoE report, respectively, may be the same node for the QoE report and the RVQoE report, or may be different nodes for the QoE report and the RVQoE report. o The configuration of QoE measurements and the configuration of RVQoE measurements may be done in the same message or in different messages. The configuration of the indication of the nodes to which the UE must send reports may be sent together with the configuration of QoE / RVQoE measurements or may be separate from the measurement configuration. Messages to the UE may be sent from the MN, from the SN, or from both the MN and the SN. All considerations relating to indication of where the UE should send reports listed under the UE embodiments are equally applicable to the MN as well, even if not listed under the MN embodiments in this document.
[0104] - Step 910: The network node receives the QoE report from the UE if the SN is configured (explicitly, implicitly or derivably) to receive the QoE report. The message containing the QoE report may be a MeasurementReportAppLayer message sent for example on SRB3 or on a new SRB5 configured towards the SN. Alternatively, the message may be a ULInformationTransferMRDC message with an embedded MeasurementReportAppLayer message sent on SRB4 via the MN to the SN. That is, the MN receives the ULInformationTransferMRDC message on SRB4, extracts the MeasurementReportAppLayer message from the ULInformationTransferMRDC message and sends it encapsulated in an RRC TRANSFER XnAP message to the SN.
[0105] - Step 912: The network node receives the RVQoE report from the UE 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 towards the SN. Alternatively, the message may be a ULInformationTransferMRDC message with an embedded MeasurementReportAppLayer message sent on SRB4 via the MN to the SN. That is, the MN receives the ULInformationTransferMRDC message on SRB4, extracts the MeasurementReportAppLayer message from the ULInformationTransferMRDC message and sends it encapsulated in an RRC TRANSFER XnAP message to the SN.
[0106] 3.1.4 Special Case of m-Based QoE Configuration If both the MN and the SN receive the same m-based QoE configuration, the UE is configured for QoE measurement and measurement reporting.
[0107] In one embodiment, it is up to the nodes (e.g., MN and SN) to decide by coordination which node should configure the UE for these QoE measurements. In one embodiment, the UE is allowed to send QoE reports to any of the nodes.
[0108] In one embodiment, an indication is provided to the UE (eg, from the MN and / or the SN) that the received QoE configuration is the same for both the MN and the SN. For example, configuring it for QoE measurements, or No UE was configured for these QoE measurements.
[0109] In one embodiment, a node (eg, MN or SN) that did not configure QoE measurements during node-to-node communication may be enabled to configure the UE for RVQoE measurements. o As one option, the MN configures the UE for QoE measurements and indicates to the SN to configure the UE for RVQoE measurements. o Another option is for the SN to configure the UE for QoE measurements and indicate to the MN to configure the UE for RVQoE measurements.
[0110] In one embodiment, a node that did not configure the UE for QoE and / or RVQoE measurements is enabled to receive QoE and / or RVQoE measurement reports by a node that did, e.g. via some indication.
[0111] 3.2 Example Implementation 3.2.1 Example where UE QoE / RVQoE reporting behavior is controlled by QoE / RVQoE configuration An example implementation in 3GPP TS38.331 of what the configuration of a UE sending QoE and RVQoE reports looks like (using the AppLayerMeasConfig IE definition in section 6.3.4 of 3GPP TS38.331 version 17.2.0 as a baseline).
[0112] -AppLayerMeasConfig The IE AppLayerMeasConfig indicates the configuration of application layer measurements.
[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] JPEG2025536175000007.jpg170165
[0115] JPEG2025536175000008.jpg98165
[0116] JPEG2025536175000009.jpg22165
[0117] 3.2.2 Example where UE QoE / RVQoE reporting behavior is controlled commonly for all QoE / RVQoE configurations Below is an example 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 commonly controlled for all QoE configurations (i.e., applies to all QoE configurations) and commonly controlled for all RVQoE configurations (i.e., applies to all RVQoE configurations).
[0118] -AppLayerMeasConfig The IE AppLayerMeasConfig indicates the configuration of application layer measurements.
[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] JPEG2025536175000010.jpg194147
[0121] JPEG2025536175000011.jpg53147
[0122] JPEG2025536175000012.jpg22147
[0123] 4 Further explanation FIG. 10 illustrates an example of a communication system 1000 according to some embodiments.
[0124] In this example, communications system 1000 includes a telecommunications network 1002 including an access network 1004, such as a radio access network (RAN), and a core network 1006 including one or more core network nodes 1008. 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 nodes 1010), or any other similar 3rd Generation Partnership Project (3GPP) access nodes or non-3GPP access points (APs). Network nodes 1010 facilitate direct or indirect connectivity of user equipment (UE), such as by connecting UEs 1012A, 1012B, 1012C, and 1012D (one or more of which may be collectively referred to as UEs 1012), to the core network 1006 over one or more wireless connections.
[0125] Exemplary wireless communications over wireless connections include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Additionally, in various embodiments, communications system 1000 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in communication of data and / or signals, whether via wired or wireless connections. Communications system 1000 may include and / or interface with any type of communications, telecommunications, data, cellular, wireless networks, and / or other similar types of systems.
[0126] The UE 1012 may be any of a wide variety of communication devices, including wireless devices, that are positioned, configured, and / or operable to communicate wirelessly with the network node 1010 and other communication devices. Similarly, the network node 1010 is positioned, capable, configured, and / or operable to communicate, directly or indirectly, with the UE 1012 and / or with other network nodes or equipment within the telecommunications network 1002 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as management within the telecommunications network 1002.
[0127] In the illustrated example, the core network 1006 connects the network node 1010 to one or more hosts, such as the host 1016. These connections may be direct or indirect through one or more intermediary networks or devices. In other examples, the network nodes may be directly coupled to the hosts. The core network 1006 includes one or more core network nodes (e.g., the core network node 1008) structured with hardware and software components. The functionality of these components may be substantially similar to that described with respect to the UEs, network nodes, and / or hosts, and thus, these descriptions are generally applicable to the corresponding components of the core network node 1008. Exemplary core network nodes include the functionality of one or more of a Mobile Switching Center (MSC), a Mobility Management Entity (MME), a Home Subscriber Server (HSS), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Subscription Identifier Deciphering Function (SIDF), a Unified Data Management (UDM), a Security Edge Protection Proxy (SEPP), a Network Exposure Function (NEF), and / or a User Plane Function (UPF).
[0128] The host 1016 may be owned or controlled by, and operated by or on behalf of, a service provider other than the operator or provider of the access network 1004 and / or the telecommunications network 1002. The 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 collection services such as acquiring and compiling data about various ambient conditions detected by multiple UEs, analytics 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] 10 enables connectivity between UEs, network nodes, and hosts. In that sense, communication system 1000 may be configured to operate according to predefined rules or procedures, such as a particular standard, including, but not limited to, Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and / or other suitable second, third, fourth, or fifth generation (2G, 3G, 4G, or 5G) standards, or any applicable future generation standard (e.g., sixth generation (6G)), a wireless local area network (WLAN) standard, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi), and / or any other suitable wireless communication standard, such as Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communications (NFC), ZigBee, LiFi, and / or any low power wide area network (LPWAN) standard, such as LoRa and Sigfox.
[0130] In some examples, the telecommunications network 1002 is a cellular network that implements functions standardized by 3GPP. Thus, the telecommunications network 1002 may support network slicing to provide different logical networks to different devices connected to the telecommunications network 1002. For example, the telecommunications network 1002 may provide Ultra-Reliable Low Latency Communications (URLLC) services to some UEs, while providing enhanced Mobile Broadband (eMBB) services to other UEs and / or providing Massive Machine Type Communications (mMTC) / Massive Internet of Things (IoT) services to additional UEs.
[0131] In some examples, the UE 1012 is configured to transmit and / or receive information without direct human interaction. For example, the UE may be designed to transmit information to the access network 1004 on a predetermined schedule, when triggered by an internal or external event, or in response to a request from the access network 1004. Additionally, the UE may be configured to operate with a single or multiple radio access technology (RAT) or in a multi-standard mode. For example, the UE may operate with any one or combination of WiFi, New Radio (NR), and LTE, i.e., may be configured for Multi-Radio Dual Connectivity (MR-DC), such as Evolved UMTS Terrestrial 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., UEs 1012C and / or 1012D) and a network node (e.g., network node 1010B). In some examples, the hub 1014 may be a controller, a router, a content source and analyzer, or any of the other communication devices described herein with respect to UEs. For example, the hub 1014 may be a broadband router that enables access to the core network 1006 for the UE. As another example, the hub 1014 may be a controller that sends commands or instructions to one or more actuators in the UE. The commands or instructions may be received from the UE, the network node 1010, or by executable code, scripts, processes, or other instructions in the hub 1014. As another example, the hub 1014 may be a data collector that acts as a temporary storage for UE data and, in some embodiments, may perform analysis or other processing of this data. As another example, the hub 1014 may be a content source. For example, for UEs that are virtual reality (VR) headsets, displays, loudspeakers, or other media delivery devices, the hub 1014 may obtain VR assets, video, audio, or other media or data related to sensory information via a network node, 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, the hub 1014 acts as a proxy server or orchestrator for the UEs, especially if one or more of the UEs are low energy IoT devices.
[0133] The hub 1014 may have a constant / permanent or intermittent connection to the network node 1010B. The hub 1014 may also enable different communication schemes and / or schedules between the hub 1014 and UEs (e.g., UEs 1012C and / or 1012D) and between the hub 1014 and the core network 1006. In other examples, the hub 1014 is connected to the core network 1006 and / or one or more UEs via a wired connection. Furthermore, the hub 1014 may be configured to connect to a machine-to-machine (M2M) service provider over the access network 1004 and / or to another UE over a direct connection. In some scenarios, a UE may establish a wireless connection with the network node 1010B while still connected through the hub 1014 via a wired or wireless connection. In some embodiments, the hub 1014 may be a dedicated hub, i.e., a hub whose primary function is to route communications to / from UEs to / from the network node 1010B. In other embodiments, the hub 1014 may be a non-dedicated hub, i.e., a device that is operable to route communications between the UE and the network node 1010B, but that is also operable as a communication origination and / or termination point for any data channel.
[0134] 11 illustrates a UE 1100 according to some embodiments. As used herein, a UE refers to a device capable of, configured, arranged, and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smartphone, a mobile phone, a cell phone, a Voice over Internet Protocol (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless camera, a game console or device, a music storage device, a playback appliance, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop embedded equipment (LEE), a laptop mounted equipment (LME), a smart device, a wireless customer premises equipment (CPE), an in-vehicle or vehicle embedded / integrated wireless device, etc. Other examples include a Narrowband Internet of Things (NB-IoT) UE, a Machine Type Communication (MTC) UE, and / or any UE identified by 3GPP, including an enhanced MTC (eMTC) UE.
[0135] A UE may support device-to-device (D2D) communications, for example, by implementing 3GPP standards for sidelink communications, dedicated short-range communications (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human being who owns and / or operates the associated device. Instead, a UE may represent a device (e.g., a smart sprinkler controller) that is intended for sale to or operation by a human user, but that may not, at least initially, be associated with a particular human user. Alternatively, a UE may represent a device (e.g., a smart power meter) that is not intended for sale to or operation by an end user, but that may be associated with or operated for the benefit of a user.
[0136] The UE 1100 includes a processing circuit 1102 operatively coupled via a bus 1104 to an input / output interface 1106, a power source 1108, a memory 1110, a communication interface 1112, and / or any other components, or any combination thereof. A given UE may utilize all or a subset of the components shown in FIG. 11 . The level of integration between components may vary from one UE to another. Furthermore, a given UE may include multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.
[0137] The processing circuit 1102 is configured to process instructions and data and may be configured to implement any sequential state machine operable to execute instructions stored as a machine-readable computer program in the memory 1110. The processing circuit 1102 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), programmable logic 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 one or more interfaces to an input device, an output device, or one or more input and / or output devices. Examples of output devices include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smart card, another output device, or any combination thereof. An input device may enable a user to capture information into the UE 1100. Examples of input devices include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a webcam, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, and a smart card. A presence-sensitive display may include a capacitive or resistive touch sensor for sensing input from a user. The sensor may be, for example, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetic sensor, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as the input device. For example, a universal serial bus (USB) port may be used to accommodate input and output devices.
[0139] In some embodiments, the power source 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-powered device, or batteries. The power source 1108 may further include power circuitry for transferring power from the power source 1108 itself and / or the external power source to various portions of the UE 1100 via an interface, such as an input circuit or a power cable. The power transfer may be for charging the power source 1108, for example. The power circuitry may perform some shaping, conversion, or other modification of the power from the power source 1108 to make it suitable for each component of the UE 1100 being powered.
[0140] The memory 1110 may be or 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, flash drive, etc. In one example, the 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 applications, and corresponding data 1116. The memory 1110 may store any of a wide variety of operating systems or combinations of operating systems for use by the 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, a USB flash drive, an external hard disk drive, a thumb drive, a pen drive, a key drive, a high-density digital versatile disc (HD-DVD), an optical disk drive, an internal hard disk drive, a Blu-ray optical disk drive, a holographic digital data storage (HDDS) optical disk drive, an external mini dual in-line memory module (DIMM), a synchronous dynamic random access memory (SDRAM), an external micro-DIMM SDRAM, a smart card memory such as a tamper-resistant module in the form of a universal integrated circuit card (UICC) containing one or more subscriber identity modules (SIMs) such as a universal SIM (USIM) and / or an Internet Protocol Multimedia Services Identity Module (ISIM), other memory, or any combination thereof. The UICC may be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly known as a "SIM card." Memory 1110 may enable UE 1100 to access instructions, application programs, etc. stored on a temporary or non-transitory storage medium to offload or upload data. An article of manufacture, such as one utilizing a communication system, may be tangibly embodied as or within memory 1110, which may be or include a device-readable storage medium.
[0142] The processing circuit 1102 may be configured to communicate with an access network or other networks 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 communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in the access network). Each transceiver may include a transmitter 1118 and / or receiver 1120 appropriate (e.g., optical, electrical, frequency-assigned, etc.) to provide network communications. 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 alternatively be implemented separately.
[0143] In the illustrated embodiment, the communication capabilities of communication interface 1112 may include cellular communication, WiFi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, NFC, location-based communication such as using a Global Positioning System (GPS) for determining location, another similar communication capability, or any combination thereof. Communication may be implemented according to 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 type of sensor, the UE may provide an output of data captured by its sensors to a network node through its communications interface 1112 or via a wireless connection. Data captured by a UE's sensors may be communicated via another UE to a network node over a wireless connection. The output may be periodic (e.g., once every 15 minutes if reporting sensed temperature), random (e.g., to balance the load of multiple sensor reports), in response to a triggering event (e.g., moisture is detected and an alert is sent), in response to a request (e.g., a user-initiated request), or a continuous stream (e.g., a live video feed of a patient).
[0145] As another example, a UE may include an actuator, motor, or switch associated with a communications interface configured to receive wireless input from a network node via a wireless connection. The actuator, motor, or switch may change state in response to the received wireless input. For example, the UE may include a motor that adjusts a control surface or rotor of a drone in flight in accordance with the received input, or a robotic arm that performs a medical procedure in accordance with the received input.
[0146] When the UE is in the form of an IoT device, it may be a device for use in one or more application domains, including, but not limited to, wearable technology in urban areas, extended industrial applications, and healthcare. Non-limiting examples of such IoT devices are devices that are or are integrated into 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, 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, smart watches, fitness trackers, head-mounted displays for augmented reality (AR) or VR, wearables for haptic augmentation 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 remote-controlled surgical robot. A UE in the form of an IoT device includes other components such as those described in relation to the UE 1100 shown in FIG. 11, in addition to circuitry and / or software depending on the intended application of the IoT device.
[0147] As yet another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements and transmits results of such monitoring and / or measurements to another UE and / or a network node. The UE, in this case, may be an M2M device and may be referred to as an MTC device in the 3GPP context. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, bus, truck, ship, or aircraft, or other equipment capable of monitoring and / or reporting on its operational 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, a first UE may be a drone or integrated into a drone and provide drone speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When a user makes a change from the remote controller, the first UE may adjust the drone's throttle (e.g., by controlling an actuator) to increase or decrease the drone's speed. The first and / or second UE may also include more than one of the above-described functionalities. For example, a UE may include a sensor and an actuator and handle communication of data for both the speed sensor and the actuator.
[0149] 12 illustrates a network node 1200 according to some embodiments. As used herein, a network node refers to a device that is configured, arranged, and / or operable to communicate, directly or indirectly, with UEs and / or other network nodes or devices in a telecommunications network. Examples of network nodes include, but are not limited to, APs (e.g., wireless APs), base stations (BSs) (e.g., wireless BSs, Node Bs, evolved Node Bs (eNBs), and NR Node Bs (gNBs)).
[0150] BSs may be categorized based on the amount of coverage they provide (or, stated another way, their transmit power level) and may thus be referred to as femto BSs, pico BSs, micro BSs, or macro BSs, depending on the amount of coverage they provide. A BS may be a relay node or a relay donor node that controls relaying. A network node may also include one or more (or all) parts of a distributed radio BS, such as a centralized digital unit and / or an RRU, sometimes called a remote radio head (RRH). Such an RRU may or may not be integrated with an antenna, such as an antenna-integrated radio. Some of the distributed radio BSs may also be referred to as nodes in a distributed antenna system (DAS).
[0151] Other examples of network nodes include multi-transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as an MSR BS, a network controller such as a radio network controller (RNC) or a BS controller (BSC), a base transceiver station (BTS), a transmission point, a transmitting node, a multi-cell / multicast coordination entity (MCE), an operation and maintenance (O&M) node, an operation support system (OSS) node, a self-organizing network (SON) node, a positioning node (e.g., an evolved serving mobile location center (E-SMLC) and / or a minimization of drive test (MDT).
[0152] Network node 1200 includes processing circuitry 1202, memory 1204, communication interface 1206, and power source 1208. Network node 1200 may be comprised of multiple physically separate components (e.g., a Node B component and an RNC component, or a BTS component and a BSC component), each of which may have its own respective components. In some scenarios in which network node 1200 includes multiple separate components (e.g., a BTS and a BSC component), 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 scenarios, 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 memories 1204 for different RATs) and some components may be reused (e.g., antenna 1210 may be shared by different RATs). Network node 1200 may also include multiple collections of the various illustrated components for various wireless technologies, such as GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, Long Range Wide Area Network (LoRaWAN), Radio Frequency Identification (RFID), or Bluetooth wireless technologies, integrated into network node 1200. These wireless technologies may be integrated in the same or different chips or collections of chips and other components within network node 1200.
[0153] The processing circuitry 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 operable, 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, processing circuit 1202 comprises a system on a chip (SOC). In some embodiments, processing circuit 1202 includes one or more of radio frequency (RF) transceiver circuitry 1212 and baseband processing circuitry 1214. In some embodiments, RF transceiver circuitry 1212 and baseband processing circuitry 1214 may be on separate chips (or collection of chips), substrates, or units such as a radio unit and a digital unit. In alternative embodiments, some or all of RF transceiver circuitry 1212 and baseband processing circuitry 1214 may be on the same chip or collection of chips, substrate, or unit.
[0155] Memory 1204 may include any type 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, mass storage media (e.g., hard disks), removable storage media (e.g., flash drives, compact discs (CDs), or digital video discs (DVDs)), and / or any other volatile or non-volatile non-transitory device-readable and / or computer-executable memory device that stores information, data, and / or instructions that may be used by processing circuit 1202. Memory 1204 may store any suitable instructions, data, or information, including applications, including one or more of computer programs, software, logic, rules, code, tables, and / or other instructions, executable by processing circuit 1202 and usable by network node 1200. Memory 1204 may be used to store any computational results made by processing circuit 1202 and / or any data received via 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, the communication interface 1206 includes port(s) / terminal(s) 1216, for example, for transmitting and receiving data to and from a network over a wired connection. The communication interface 1206 also includes radio front-end circuitry 1218, which may be coupled to an antenna 1210 or, in some embodiments, part of the antenna 1210. The radio front-end circuitry 1218 includes a filter 1220 and an amplifier 1222. The radio front-end circuitry 1218 may be connected to the antenna 1210 and the processing circuit 1202. The radio front-end circuitry 1218 may be configured to condition signals communicated between the antenna 1210 and the processing circuit 1202. The radio front-end circuitry 1218 may receive digital data to be sent to another network node or a UE via a wireless connection. Radio front-end circuitry 1218 may convert this digital data into a radio signal having appropriate channel and bandwidth parameters using a combination of filters 1220 and / or amplifiers 1222. The radio signal may then be transmitted via antenna 1210. Similarly, when receiving data, antenna 1210 may collect the radio signal, which may then be converted into digital data by radio front-end circuitry 1218. The digital data may be passed to processing circuit 1202. In other embodiments, communication interface 1206 may include different components and / or different combinations of components.
[0157] In an alternative embodiment, network node 1200 does not include a separate radio front-end circuit 1218; rather, processing circuit 1202 includes the radio front-end circuitry and is connected to antenna 1210. Similarly, in some embodiments, all or a portion of RF transceiver circuitry 1212 is part of communications interface 1206. In yet other embodiments, communications interface 1206 includes one or more ports or terminals 1216, radio front-end circuitry 1218, and RF transceiver circuitry 1212 as part of a radio unit (not shown), and communications interface 1206 communicates with baseband processing circuitry 1214 that 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 radio front-end circuitry 1218 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, antenna 1210 is separate from network node 1200 and may be connectable to 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 operation and / or certain obtaining operations described herein as being performed by network node 1200. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, antenna 1210, communication interface 1206 and / or processing circuit 1202 may be configured to perform any transmitting operation described herein as being performed by network node 1200. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.
[0160] The power source 1208 provides power to the various components of the network node 1200 in a format appropriate for each component (e.g., at the voltage and current levels required for each component). The power source 1208 may further include, or be coupled to, power management circuitry for supplying power to the components of the network node 1200 for performing the functionality described herein. For example, the network node 1200 may be connectable to an external power source (e.g., a power grid or an electrical outlet) via an input circuit or interface, such as an electrical cable, whereby the external power source supplies power to the power circuitry of the power source 1208. As a further example, the power source 1208 may include a source of power in the form of a battery or battery pack connected to or integrated into the power circuitry. 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 certain aspects of the functionality of the network node, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, network node 1200 may include user interface devices that allow information to be input into and output from network node 1200, which may enable a user to perform diagnostic, maintenance, repair, and other management functions on network node 1200.
[0162] 13 is a block diagram of a host 1300, which may be an embodiment of the host 1016 of FIG. 10, in accordance with various aspects described herein. As used herein, the host 1300 may be or include various combinations of hardware and / or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, a container, or processing resources within a server farm. The host 1300 may provide one or more services to one or more UEs.
[0163] Host 1300 includes a processing circuit 1302 operably coupled via bus 1304 to an input / output interface 1306, a network interface 1308, a power supply 1310, and memory 1312. In other embodiments, other components may be included, the functionality of which may be substantially similar to that described with respect to the devices in previous figures, such as Figures 11 and 12, and therefore these descriptions are generally applicable to the corresponding components of 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 a UE for host 1300 or data generated by host 1300 for a UE. An embodiment of host 1300 may utilize only a subset or all of the illustrated components. Host application programs 1314 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), Moving Picture Experts 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 UE (e.g., handsets, desktop computers, wearable display systems, and heads-up display systems). The host application program 1314 may also provide user authentication and license checks, and may periodically report health, route, and content availability to a central node, such as a device in or at the edge of the core network. Thus, the 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), Dynamic Adaptive Streaming over HTTP (DASH or MPEG-DASH), etc.
[0165] FIG. 14 is a block diagram illustrating a virtualization environment 1400 in which functionality implemented according to some embodiments may be virtualized. In this context, virtualization means for creating a virtual version of an apparatus or device may include a virtualized hardware platform, storage devices, and networking resources. As used herein, virtualization may apply to any device or component thereof described herein and refers to implementations in which at least some of this functionality is implemented as one or more virtual components. Some or all of the functionality described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented within one or more virtual environments 1400 hosted by one or more hardware nodes, such as a network node, a UE, a core network node, or a hardware computing device acting as a host. Furthermore, in embodiments in which a virtualized node does not require wireless connectivity (e.g., a core network node or host), the node may be virtualized in its entirety.
[0166] An application 1402 (which may alternatively be referred to as a software instance, a virtual appliance, a network function, a virtual node, a virtual network function, etc.) runs in the 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 circuitry, memory that stores software and / or instructions executable by the hardware processing circuitry, and / or hardware devices such as those described herein, such as network interfaces and input / output interfaces. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1406 (also referred to as a hypervisor or VM monitor (VMM)), provide VMs 1408A and 1408B (one or more of which may be collectively referred to as VMs 1408), and / or perform any of the functions, features, and / or benefits described in connection with some embodiments described herein. Virtualization layer 1406 may present a virtual operating platform that appears to VMs 1408 as networking hardware.
[0168] A VM 1408 may include virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and may be executed by a corresponding virtualization layer 1406. Various embodiments of an instance of a virtual appliance 1402 may be implemented in one or more of the VMs 1408, and this implementation may be done in various ways. Hardware virtualization is referred to in some contexts as network functions virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry-standard, high-capacity server hardware, physical switches, and physical storage that may be located in data centers and customer premises equipment.
[0169] In the context of NFV, a VM 1408 may be a software implementation of a physical machine that runs programs as if they were running on a physical, non-virtualized machine. Each VM 1408 and the portion of hardware 1404 on which it runs, whether the hardware is dedicated to that VM and / or shared by that VM with others of the VMs 1408, forms a separate virtual network element. Also in the context of NFV, a virtual network function is responsible for handling specific network functions running in one or more VMs 1408 on the hardware 1404 and corresponds to the application 1402.
[0170] The hardware 1404 may be implemented in a standalone network node with generic or proprietary components. The hardware 1404 may implement some functions via virtualization. Alternatively, the hardware 1404 may be part of a larger hardware cluster (e.g., in a data center or CPE) where multiple hardware nodes cooperate and are managed via a management and orchestration 1410, which oversees, among other things, the lifecycle management of the application 1402. In some embodiments, the hardware 1404 is coupled to one or more radio units, each including one or more transmitters and one or more receivers, which may be coupled to one or more antennas. The radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces or may be used in combination with virtual components to provide radio capabilities, such as a RAN or BS, to virtual nodes. In some embodiments, some signaling may be provided with the use of a control system 1412, which may alternatively be used for communication between the hardware nodes and the radio units.
[0171] 15 illustrates a communication diagram of a host 1502 communicating with a UE 1506 via a network node 1504 over a partially wireless connection according to some embodiments. Exemplary implementations according to various embodiments of the UEs (such as the UE 1012A of FIG. 10 and / or the UE 1100 of FIG. 11), network nodes (such as the network node 1010A of FIG. 10 and / or the network node 1200 of FIG. 12), and hosts (such as the host 1016 of FIG. 10 and / or the host 1300 of FIG. 13) discussed in the preceding paragraphs will now be described with reference to FIG. 15.
[0172] Similar to host 1300, an embodiment of host 1502 includes hardware such as a communications interface, processing circuitry, and memory. Host 1502 also includes hardware and software stored within or accessible by host 1502 and executable by the processing circuitry. The software includes a host application that may be operable to provide services to a remote user, such as UE 1506, connecting via an OTT connection 1550 extending between UE 1506 and host computer 1502. In providing services to the remote user, the host application may provide user data that is transmitted using OTT connection 1550.
[0173] The network node 1504 includes hardware that enables communication with the host 1502 and the UE 1506 over a connection 1560. The connection 1560 may be direct or may pass through one or more other intermediate networks, such as a core network (such as the core network 1006 of FIG. 10) and / or one or more public, private, or hosted networks. For example, the intermediate network may be a backbone network or the Internet.
[0174] The UE 1506 includes software stored within or accessible by the UE 1506 and executable by the UE's processing circuitry. This software includes a client application, such as a web browser or operator-specific "app," that may be operable, with support from the host 1502, to provide services to a human or non-human user via the UE 1506. A host application running on the host 1502 may communicate with a client application running on the UE 1506 via an OTT connection 1550 that terminates at the UE 1506 and the host 1502. In providing a service to a user, the client application on the UE may receive request data from the host application on the host and provide user data in response to the request data. The OTT connection 1550 may transport both the request data and user data. The client application on the UE may interact with the user to generate user data that it provides to the host application through the OTT connection 1550.
[0175] The OTT connection 1550 may extend via a connection 1560 between the host 1502 and a network node 1504 and via a wireless connection 1570 between the network node 1504 and the UE 1506 to provide connectivity between the host 1502 and the UE 1506. The connection 1560 and the wireless connection 1570 over which the OTT connection 1550 may be provided are depicted abstractly to illustrate communication between the host 1502 and the UE 1506 via the network node 1504 without explicit reference to any intermediate devices and the precise routing of messages through those devices.
[0176] As an example of transmitting data over the OTT connection 1550, in step 1508, the host 1502 provides user data, which may be done by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE 1506. In other embodiments, the user data is associated with a UE 1506 that shares data with the host 1502 without explicit human interaction. In step 1510, the host 1502 initiates a transmission carrying user data to the UE 1506. The host 1502 may initiate the transmission in response to a request sent by the UE 1506. The request may be triggered by human interaction with the UE 1506 or by the operation of a client application running on the UE 1506. The transmission may pass through the network node 1504 in accordance with the teachings of the embodiments described throughout this disclosure. In response, in step 1512, the network node 1504 transmits the user data carried in this transmission initiated by the host 1502 to the UE 1506, in accordance with the teachings of the embodiments described throughout this disclosure. In step 1514, the UE 1506 receives the user data carried in this transmission, which may be performed by a client application running on the UE 1506 that is associated with a host application executed by the host 1502.
[0177] In some examples, the UE 1506 executes a client application, which provides user data destined for the host 1502. The user data may be provided in reaction or response to receiving the data from the host 1502. In response, at step 1516, the UE 1506 may provide the user data, which may be done by executing the client application. In providing the user data, the client application may further consider user input received from a user via an input / output interface of the UE 1506. Regardless of the specific manner in which the user data is provided, the UE 1506 initiates transmission of the user data to the host 1502 via the network node 1504 at step 1518. At step 1520, the network node 1504 receives the user data from the UE 1506 and initiates transmission of the received user data to the host 1502, in accordance with the teachings of embodiments described throughout this disclosure. At step 1522, the host 1502 receives the user data carried in the transmission initiated by the UE 1506.
[0178] One or more of various embodiments improve the performance of OTT services provided to the UE 1506 using the OTT connection 1550, of which the wireless connection 1570 forms the final segment.
[0179] In an exemplary scenario, factory status information may be collected and analyzed by the host 1502. As another example, the host 1502 may process audio and video data, possibly obtained from UEs, for use in creating maps. As another example, the host 1502 may collect and analyze real-time data to assist in vehicular congestion control (e.g., traffic light control). As another example, the host 1502 may store surveillance video uploaded by UEs. As another example, the host 1502 may store or control access to media content, such as video, audio, VR, or AR, that may be broadcast, multicast, or unicast to UEs. As another example, the 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 (e.g., compilation of diagrams from data collected from remote devices), or any other function that collects, acquires, stores, analyzes, and / or transmits data.
[0180] In some examples, measurement procedures may be provided to monitor data rates, latency, and other factors that are improved by one or more embodiments. There may also be optional network functionality for reconfiguring the OTT connection 1550 between the host 1502 and the UE 1506 in response to fluctuations in the measurements. This measurement procedure and / or the network functionality for reconfiguring the OTT connection 1550 may be implemented in software and hardware in the host 1502 and / or the 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 procedures by providing values of the monitored quantities exemplified above or other physical quantities from which the software calculates or estimates the monitored quantities. Reconfiguration of the OTT connection 1550 may include message formats, retransmission settings, preferred routing, etc., and this reconfiguration need not directly change the operation of the network node 1504. Such procedures and functionality may be known or practiced in the art. In one embodiment, the measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation time, latency, etc. by the host 1502. The measurements may be implemented by having software send messages over the OTT connection 1550, specifically empty or "dummy" messages, while monitoring propagation times, errors, etc.
[0181] While the computing devices (e.g., UEs, network nodes, hosts) described herein may include the 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 determining, calculating, obtaining, or similar operations described herein may be performed by processing circuitry, which may process information by, for example, transforming the obtained information into other information, comparing the obtained or transformed information with information stored at the network node, and / or performing one or more operations based on the obtained or transformed information, and making a determination as a result of such processing. Furthermore, while components are depicted as a single box located within a larger box or nested within multiple boxes, in reality, a computing device may include multiple different physical components that make up the illustrated single component, and functionality may be partitioned among the 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 partitioned between the processing circuitry and the communication interface. In another example, the computationally non-intensive functions of any of such components may be implemented in software or firmware, and the computationally intensive functions may be implemented in hardware.
[0182] In some embodiments, some or all of the functionality 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-transitory computer-readable storage medium. In alternative embodiments, some or all of this functionality may be provided by the processing circuit without executing instructions stored on 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 described functionality regardless of whether or not it executes instructions stored on a non-transitory computer-readable storage medium. Benefits provided by such functionality are not limited to just the processing circuit or other components of the computing device, but are enjoyed by the computing device as a whole and / or by end users and wireless networks in general.
[0183] Some exemplary embodiments of the present disclosure are as follows.
[0184] Group A Embodiments Embodiment 1: A method performed by a user equipment (UE), comprising: - receiving one or more messages from one or more network nodes, the messages including one or more Quality of Experience (QoE) configurations and / or one or more Radio Access Network (RAN) Visible QoE (RVQoE) configurations (700A, 700B-1); - receiving (700A) for each QoE configuration or commonly for said one or more QoE configurations an indication indicating the network node from which the respective QoE report is to be sent or determining (700B-2) the network node from which the respective QoE report is to be sent; - receiving (700A) for each RVQoE configuration or commonly for said one or more RVQoE configurations an indication of a network node from which a respective RVQoE report is to be sent, or determining (700B-2) said network node from which a respective RVQoE report is to be sent; - performing (702) QoE measurements and / or RVQoE measurements according to said one or more QoE configurations and / or said one or more RVQoE configurations; - for each QoE report of the one or more QoE reports comprising the result of said QoE measurements, sending (704-1) said QoE report to said indicated or determined network node to which said QoE report is to be sent; - for each RVQoE report of one or more RVQoE reports comprising the results of the QoE measurements, sending (704-2) the RVQoE report to the indicated or determined network node to which the QoE report is to be sent. Embodiment 2: A method as described in embodiment 1, wherein 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 the RVQoE report is sent for at least one of the one or more RVQoE configurations. Embodiment 3: The method according to embodiment 1 or 2, comprising receiving (700A) for each QoE configuration an indication indicating a network node to which the respective QoE report is to be sent. Embodiment 4: A method as described in embodiment 3, wherein for each QoE configuration among the one or more QoE configurations, the indication indicating the network node to which the respective QoE report is sent is included in either the QoE configuration or in one or more messages including the QoE configuration. Embodiment 5: A method as described in embodiment 1 or 2, comprising receiving (700A) an indication indicating a common network node to which a QoE report is to be sent, common to all of the one or more QoE configurations. Embodiment 6: A method as described in embodiment 5, wherein the indication indicating the common network node to which the QoE report is sent 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 (700A) for each RVQoE configuration an indication indicating a network node to which the respective RVQoE report is to be sent. Embodiment 8: A method as described in embodiment 7, wherein, for each RVQoE configuration among the one or more RVQoE configurations, the indication indicating the network node to which the respective RVQoE report is sent is included in either the RVQoE configuration or in one or more messages including the RVQoE configuration. Embodiment 9: A method according to any one of embodiments 1 to 6, comprising receiving (700A) an indication, common to all of the one or more RVQoE configurations, indicating a common network node to which each RVQoE report is sent. Embodiment 10: A method as described in embodiment 9, wherein the indication indicating the common network node to which the RVQoE report is sent 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 of any one of embodiments 3 to 10, wherein each indication comprises: - an indication of said network node (e.g. MN, SN); an indication to send said report to said node carrying said data flow(s) of said application session to which said report relates; - an indication of the cell group (e.g. MCG, SCG); an indication to send said report to said group of cells carrying said data flow(s) of said application session to which said report relates; - an indication of the SRB to send (for example, SRB4 implies MN, SRB5 implies SN), and - an indication that a MeasurementReportAppLayer message containing a particular report type should be included in a message (e.g., a ULInformationTransferMRDC RRC message) used to encapsulate a message transferred from the MN to the SN (or vice versa); 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 that processes the DRB(s) that carry the data flow(s) of the application session to which the report relates; A method wherein the absence of an indication may be an implicit indication that the UE can autonomously decide to which node the report should be sent. Embodiment 12: The method according to embodiment 1 or 2, comprising determining (700B-2) for each QoE configuration a network node to which the respective QoE report is to be sent. Embodiment 13: A method as described in embodiment 1 or 2, comprising determining (700B-2) a common network node to which a QoE report is to be sent, for all of the one or more QoE configurations. Embodiment 14: The method according to embodiment 1, 2, 12 or 13, comprising determining (700B-2) for each RVQoE configuration a network node to which the respective RVQoE report is to be sent. Embodiment 15: A method as described in embodiment 1, 2, 12 or 13, comprising determining (700B-2) a common network node to which an RVQoE report is to be sent, common to all of the one or more RVQoE configurations. Embodiment 16: A method according to any of the above embodiments, further comprising providing user data and forwarding the user data to the host via transmission to the network node.
[0185] Group B Embodiments Embodiment 17: A method performed by a first network node (e.g., MN), comprising: - one or more messages containing one or more Quality of Experience (QoE) configurations and / or one or more Radio Access Network (RAN) Visible QoE (RVQoE) configurations to a User Equipment (UE); an indication, for each QoE configuration or jointly for said one or more QoE configurations, of the network node to which the respective QoE report is sent; and transmitting (806) for each RVQoE configuration or in common for the one or more RVQoE configurations an indication indicating the network node to which the respective RVQoE report is to be sent. Embodiment 18: A method as described in embodiment 17, wherein 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 the RVQoE report is sent for at least one of the one or more RVQoE configurations.
[0047] Embodiment 19: A method performed by a second network node (e.g., SN), comprising: receiving (910) from a user equipment (UE) one or more messages including one or more Quality of Experience (QoE) reports associated with one or more QoE configurations and one or more Radio Access Network (RAN) Visible QoE (RVQoE) reports associated with one or more RVQoE configurations; for each QoE configuration, or in common for said one or more QoE configurations, the UE is either configured with or determines the network node at which the respective QoE report is sent, A method wherein, for each RVQoE configuration, or in common for the one or more RVQoE configurations, the UE is either configured with or determines the network node from which the respective RVQoE report is sent. Embodiment 20: A method as described in embodiment 19, wherein 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 the RVQoE report is sent for at least one of the one or more RVQoE configurations. Embodiment 21: A method according to any of the above embodiments, further comprising obtaining user data and transferring the user data to a host or user equipment.
[0186] Group C Embodiments Embodiment 22: A user equipment 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 provide 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 provide power to the processing circuit. Embodiment 24: A user equipment (UE) comprising: an antenna configured to transmit and receive wireless signals; a radio front-end circuit connected to the antenna and a processing circuit and configured to condition signals communicated between the antenna and the processing circuit, the processing circuit 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 enable 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 that has been processed by the processing circuit; and a battery connected to the processing circuit and configured to provide power to the UE. Embodiment 25: A host configured to operate in a communication system to provide over-the-top (OTT) services, the host 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 equipment (UE), the UE comprising 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 in Group A to receive the user data from the host. Embodiment 26: The host of the above embodiment, wherein the cellular network further includes a network node configured to communicate with the UE to transmit the user data from the host to the UE. Embodiment 27: A host according to the two preceding embodiments, wherein the processing circuitry of the host is configured to execute a host application thereby providing the user data, the host application is configured to interact with a client application running on the UE, and the client application is associated with the host application. Embodiment 28: A method implemented by a host operating in a communication system further including a network node and a user equipment (UE), comprising: providing user data for the UE; and initiating a transmission carrying the user data to the UE via a cellular network comprising the network node, wherein the UE performs any of the operations of any of the embodiments in Group A to receive the user data from the host. Embodiment 29: The method of the above embodiment, further comprising executing, in the host, a host application associated with a client application running on the UE to receive the user data from the UE. Embodiment 30: The method of the above embodiment, further comprising, in the host, sending input data to the client application running on the UE, wherein the input data is provided by executing 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 over-the-top (OTT) services, the host 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 equipment (UE), the UE comprising 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 transmit the user data to the host. Embodiment 32: The host of the above embodiment, wherein the cellular network further includes a network node configured to communicate with the UE to transmit the user data from the UE to the host. Embodiment 33: A host according to the two preceding embodiments, wherein the processing circuitry of the host is configured to execute a host application thereby providing the user data, the host application is configured to interact with a client application running on the UE, and the client application is associated with the host application. Embodiment 34: A method implemented by a host configured to operate in a communication system further including a network node and user equipment (UE), comprising receiving, at the host, user data transmitted by the UE to the host via the network node, wherein the UE performs any of the steps of any of the embodiments in Group A to transmit the user data to the host. Embodiment 35: The method of the above embodiment, further comprising executing, in the host, a host application associated with a client application running on the UE to receive the user data from the UE. Embodiment 36: The method of the above embodiment, further comprising, in the host, sending input data to the client application running on the UE, wherein the input data is provided by executing 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 over-the-top (OTT) services, the host comprising: a processing circuit configured to provide user data; and a network interface configured to initiate transmission of the user data to a network node in a cellular network for transmission to a user equipment (UE), the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of any of the embodiments in Group B to transmit the user data from the host to the UE. Embodiment 38: A host of the above embodiment, wherein the processing circuitry of the host is configured to execute a host application that provides the user data, and the UE comprises processing circuitry configured to execute a client application associated with the host application 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 a network node and user equipment (UE), comprising: providing user data for the UE; and initiating a transmission carrying the user data to the UE via a cellular network comprising the network node, wherein the network node performs any of the operations of any of the embodiments in Group B to transmit the user data from the host to the UE. Embodiment 40: The method of the above embodiment, further comprising, at the network node, transmitting the user data provided by the host for the UE. Embodiment 41: A method of either of the above two embodiments, wherein the user data is provided in the host by executing a host application that interacts with a client application running on the UE, and the client application is associated with the host application. Embodiment 42: A communications system configured to provide over-the-top services, comprising: a processing circuit configured to provide user data for a user equipment (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, the processing circuit of the network node being configured to perform any of the operations of any of the embodiments of Group B to transmit the user data from the host to the UE. Embodiment 43: A communication system of 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 over-the-top (OTT) services, comprising: a processing circuit configured to initiate reception of user data; and a network interface configured to receive the user data from a network node in a cellular network, the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of any of the embodiments in Group B to receive the user data from a user equipment (UE) for the host. Embodiment 45: A host according to the two preceding embodiments, wherein the processing circuitry of the host is configured to execute a host application thereby providing the user data, the host application is configured to interact with a client application running on the UE, and the client application is associated with the host application. Embodiment 46: A host according to any of the above two embodiments, wherein initiating reception of the user data includes requesting the user data. Embodiment 47: A method implemented by a host configured to operate in a communication system further including a network node and user equipment (UE), comprising initiating, at the host, reception of user data from the UE, the user data originating from a transmission received by the network node from the UE, and the network node performing any of the steps of any of the embodiments in Group B to receive the user data from the UE for the host.
[0048] Embodiment 48. 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 variations on the embodiments of the present disclosure, and all such improvements and variations are deemed to be within the scope of the concepts disclosed herein.
Claims
1. 1. A method performed by a user equipment (UE), comprising: Receiving one or more messages from one or more network nodes (700A, 700B-1) including one or more Quality of Experience (QoE) configurations and one or more Radio Access Network (RAN) Visible QoE (RVQoE) configurations; - receiving (700A) for each QoE configuration, or commonly for said one or more QoE configurations, an indication indicating a network node to which a respective QoE report is to be sent; receiving (700A) an indication for each RVQoE configuration, or commonly for said one or more RVQoE configurations, indicating a network node to which a respective RVQoE report is to be sent; performing QoE and RVQoE measurements according to the one or more QoE configurations and the one or more RVQoE configurations (702); for each QoE report of the one or more QoE reports including the result of the QoE measurement, sending the QoE report to the indicated network node to which the QoE report is to be sent (704-1); and for each RVQoE report of one or more RVQoE reports including the result of the QoE measurement, sending (704-2) the RVQoE report to the indicated network node to which the QoE report is to be sent.
2. 2. The method of claim 1, wherein 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 the RVQoE report is sent for at least one of the one or more RVQoE configurations.
3. 3. The method according to claim 1 or 2, comprising receiving (700A) for each QoE configuration an indication indicating the network node to which the respective QoE report is to be sent.
4. 4. The method of claim 3, wherein, for each QoE configuration of the one or more QoE configurations, the indication indicating the network node to which a respective QoE report is to be sent is included either in the QoE configuration or in one or more messages that may contain the QoE configuration.
5. 5. The method of claim 3 or 4, wherein, for at least one QoE configuration of the one or more QoE configurations, the indication of the network node from which a respective QoE report is to be transmitted is an indication of a signaling radio bearer (SRB) for transmitting the respective QoE report.
6. The method of any one of claims 1 to 5, comprising receiving (700A) for each RVQoE configuration an indication indicating the network node to which the respective RVQoE report is to be sent.
7. 7. The method of claim 6, wherein, for each RVQoE configuration of the one or more RVQoE configurations, the indication indicating the network node to which a respective RVQoE report is to be sent is included either in the RVQoE configuration or in one or more messages including the RVQoE configuration.
8. 8. The method of claim 6 or 7, wherein, for at least one RVQoE configuration of the one or more RVQoE configurations, the indication of the network node from which a respective RVQoE report is to be transmitted is an indication of a signaling radio bearer (SRB) for transmitting the respective RVQoE report.
9. 5. The method of claim 3 or 4, wherein the indication of the network node to which a respective QoE report is to be sent for at least one of the one or more QoE configurations comprises: an indication of said network node; - an indication to send said respective QoE report to a network node carrying the data flow(s) of the application session to which said respective QoE report relates; - an indication of the cell group; an indication to send said respective QoE report to a group of cells carrying one or more data flow(s) of an application session to which said respective QoE report is associated.
10. 5. The method of claim 3 or 4, wherein the indication indicating the network node to which a respective QoE report should be sent for at least one QoE configuration of the one or more QoE configurations is an indication that a MeasurementReportAppLayer message containing a particular report type should be included in a message used to encapsulate a message forwarded from the MN to the SN or vice versa.
11. 5. The method of claim 3 or 4, wherein, for at least one QoE configuration of the one or more QoE configurations, the indication indicating the network node to which a respective QoE report is to be sent is the absence of an explicit indication that serves as an implicit indication that the respective QoE report should be sent to the network node that sent the respective QoE configuration.
12. 5. The method of claim 3 or 4, wherein, for at least one QoE configuration of the one or more QoE configurations, the indication of the network node to which a respective QoE report is to be sent is the absence of an explicit indication that serves as an implicit indication that the respective QoE report should be sent to the network node processing one or more Data Radio Bearers (DRBs) that carry one or more data flows of an application session to which the QoE report relates.
13. 5. The method of claim 3 or 4, wherein, for at least one QoE configuration of the one or more QoE configurations, the indication of the network node to which a respective QoE report is to be sent is the absence of an explicit indication serving as an implicit indication that the wireless terminal autonomously decides the network node to which to send the respective QoE report.
14. 3. The method of claim 1 or 2, comprising receiving (700A) an indication, common for all of said one or more QoE configurations, indicating a common network node to which a QoE report is to be sent.
15. 15. The method of claim 14, wherein the indication of the common network node to which the QoE report is sent is included in either at least one of the one or more QoE configurations or in message(s) containing at least one of the one or more QoE configurations.
16. 16. The method of claim 14 or 15, wherein the indication of the common network node to which the QoE report is to be transmitted is an indication of a signaling radio bearer (SRB) for transmitting the QoE report.
17. 16. The method of claim 14 or 15, wherein the indication of the common network node to which the QoE report is sent comprises: an indication of said network node; - an indication of a cell group.
18. 16. A method according to claim 14 or 15, wherein the indication of the common network node to which the QoE report is to be sent is an indication that a MeasurementReportAppLayer message containing a particular report type should be included in a message used to encapsulate a message being forwarded from the MN to the SN or vice versa.
19. 16. The method of claim 14 or 15, wherein the indication of the common network node to which the QoE reports are to be transmitted is the absence of an explicit indication that serves as an implicit indication that the wireless terminals autonomously decide the network node to which to transmit their respective QoE reports.
20. 8. The method of claim 6 or 7, wherein the indication of the network node to which a respective RVQoE report is to be sent for at least one RVQoE configuration of the one or more RVQoE configurations comprises: an indication of said network node; - an indication to send said respective RVQoE report to a network node carrying a data flow(s) of an application session to which said respective RVQoE report relates; - an indication of the cell group; an indication to send the respective RVQoE report to a cell group carrying one or more data flow(s) of an application session to which the respective RVQoE report is associated.
21. 8. The method of claim 6 or 7, wherein, for at least one RVQoE configuration of the one or more RVQoE configurations, the indication indicating the network node to which a respective RVQoE report should be sent is an indication that a MeasurementReportAppLayer message containing a particular report type should be included in a message used to encapsulate a message forwarded from the MN to the SN or vice versa.
22. 8. The method of claim 6 or 7, wherein, for at least one RVQoE configuration of the one or more RVQoE configurations, the indication indicating the network node to which a respective RVQoE report is to be sent is the absence of an explicit indication serving as an implicit indication that the respective RVQoE report should be sent to the network node that sent the respective RVQoE configuration.
23. 8. The method of claim 6 or 7, wherein, for at least one RVQoE configuration of the one or more RVQoE configurations, the indication indicating the network node to which a respective RVQoE report is to be sent is the absence of an explicit indication that serves as an implicit indication that the respective RVQoE report should be sent to the network node processing one or more Data Radio Bearers (DRBs) that carry one or more data flows of an application session to which the RVQoE report relates.
24. 8. The method of claim 6 or 7, wherein, for at least one RVQoE configuration of the one or more RVQoE configurations, the indication indicating the network node to which a respective RVQoE report is to be sent is the absence of an explicit indication serving as an implicit indication that the wireless terminal autonomously determines the network node to which to send the respective RVQoE report.
25. 3. The method of claim 1 or 2, comprising receiving (700A) an indication, common to all of the one or more RVQoE configurations, indicating a common network node to which respective RVQoE reports are to be sent.
26. 26. The method of claim 25, wherein the indication of the common network node to which the RVQoE report is sent is included in either at least one of the one or more RVQoE configurations or in message(s) including at least one of the one or more RVQoE configurations.
27. 27. The method of claim 25 or 26, wherein the indication of the common network node to which the RVQoE report is to be transmitted is an indication of a signaling radio bearer (SRB) for transmitting the RVQoE report.
28. 27. The method of claim 25 or 26, wherein the indication of the common network node to which the RVQoE report is sent comprises: an indication of said network node; - an indication of a cell group.
29. 27. The method of claim 25 or 26, wherein the indication of the common network node to which the RVQoE report is to be sent is an indication that a MeasurementReportAppLayer message containing a particular report type should be included in a message used to encapsulate a message being forwarded from the MN to the SN or vice versa.
30. 27. The method of claim 25 or 26, wherein the indication of the common network node to which the RVQoE reports are to be transmitted is the absence of an explicit indication that serves as an implicit indication that the wireless terminals autonomously determine the network node to which to transmit their respective RVQoE reports.
31. A user equipment (UE), Receiving one or more messages from one or more network nodes (700A, 700B-1) including one or more Quality of Experience (QoE) configurations and one or more Radio Access Network (RAN) Visible QoE (RVQoE) configurations; - receiving (700A) for each QoE configuration, or commonly for said one or more QoE configurations, an indication indicating a network node to which a respective QoE report is to be sent; receiving (700A) an indication for each RVQoE configuration, or commonly for said one or more RVQoE configurations, indicating a network node to which a respective RVQoE report is to be sent; performing QoE and RVQoE measurements according to the one or more QoE configurations and the one or more RVQoE configurations (702); for each QoE report of the one or more QoE reports including the result of the QoE measurement, sending the QoE report to the indicated network node to which the QoE report is to be sent (704-1); and for each RVQoE report of the one or more RVQoE reports including the result of the QoE measurement, transmitting (704-2) the RVQoE report to the indicated network node to which the QoE report is transmitted.
32. 32. The UE of claim 31, further adapted to perform the method of any one of claims 2 to 30.
33. A user equipment (UE) (1100), A communication interface (1112); a processing circuit (1102) associated with the communication interface (1112), the processing circuit (1112) providing the UE (1100) with: Receiving one or more messages from one or more network nodes (700A, 700B-1) including one or more Quality of Experience (QoE) configurations and one or more Radio Access Network (RAN) Visible QoE (RVQoE) configurations; - receiving (700A) for each QoE configuration, or commonly for said one or more QoE configurations, an indication indicating a network node to which a respective QoE report is to be sent; receiving (700A) an indication for each RVQoE configuration, or commonly for said one or more RVQoE configurations, indicating a network node to which a respective RVQoE report is to be sent; performing QoE and RVQoE measurements according to the one or more QoE configurations and the one or more RVQoE configurations (702); for each QoE report of the one or more QoE reports including the result of the QoE measurement, sending the QoE report to the indicated network node to which the QoE report is to be sent (704-1); and for each RVQoE report of the one or more RVQoE reports including the result of the QoE measurement, transmitting (704-2) the RVQoE report to the indicated network node to which the QoE report is to be transmitted.
34. 34. The UE of claim 33, wherein the processing circuitry (1112) is further configured to cause the UE (1100) to perform a method according to any one of claims 2 to 30.
35. 1. A method performed by a first network node, comprising: one or more messages including one or more Quality of Experience (QoE) configurations and one or more Radio Access Network (RAN) Visible QoE (RVQoE) configurations to a User Equipment (UE); - an indication, for each QoE configuration or jointly for said one or more QoE configurations, of a network node to which each QoE report is to be sent; and transmitting (806) 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.
36. 36. The method of claim 35, wherein 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 the RVQoE report is sent for at least one of the one or more RVQoE configurations.
37. A method performed by a second network node, comprising: receiving (910) from a user equipment (UE) one or more messages including one or more Quality of Experience (QoE) reports associated with one or more QoE configurations and one or more Radio Access Network (RAN) Visible QoE (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 configured with or determines the network node at which the respective QoE report is to be sent, A method wherein, for each RVQoE configuration, or in common for the one or more RVQoE configurations, the UE is either configured with or determines the network node from which the respective RVQoE report is sent.
38. 38. The method of claim 37, wherein 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 the RVQoE report is sent for at least one of the one or more RVQoE configurations.
Citation Information
Patent Citations
Methods for ran-visible (lightweight) QOE configuration and measurement coordination among ran nodes
WO2022164379A1