Methods, apparatus, and computer-readable media relating to quality of experience information in communication networks

Abstract

The method is performed by a user equipment, the method including, upon transitioning to a connected state, connecting to a first Radio Access Network (RAN) node of a communications network, the method further including transmitting information related to one or more quality of experience measurement sessions configured in the user equipment to the communications network, the one or more QoE measurement sessions being configured in the user equipment during a previous instance of the user equipment being in the connected state.

Description

[Technical Field]

[0001] TECHNICAL FIELD Embodiments of the present disclosure relate to methods, apparatus, and computer-readable media related to communication networks, and more particularly to quality of experience information in communication networks. [Background technology]

[0002] QoE Framework Overview "Normal" QoE Quality of Experience (QoE) measurements, also known as "application layer measurements," have been specified for Long Term Evolution (LTE) and Universal Mobile Telecommunications System (UMTS), and are being specified for New Radio (NR) in 3GPP Release 17. The purpose of application layer measurements is to measure the end-user experience when using a specific application. Currently, QoE measurements are supported for streaming services and mobility telephony services for Internet Protocol (IP) Multimedia Subsystem (IMS) (MTSI) services. NR is likely to add at least virtual reality (VR) to the list of services for which QoE measurements are specified and supported.

[0003] The LTE and UMTS solutions are similar in overall principles: QMC (Quality of Experience Measurement Collection) 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 and forwarded to the UE in a downlink RRC message. The application layer measurement report (also called QoE report) received by the UE access layer (UE_AS) or the UE RRC layer from the UE's upper layer (application layer) is encapsulated in a transparent container and sent to the network in an uplink RRC message. The RAN then forwards the QoE report to a measurement collection entity (MCE).

[0004] In 3GPP Release 17, a new research item for NR, "Research on QoE Management and Optimization in NR for Diverse Services," was approved and completed. The specification work for 3GPP Release 17 is still ongoing. The purpose of this research item is to explore solutions for QoE measurement in NR. QoE management in NR not only collects quality of experience parameters for streaming services, but also considers the typical performance requirements of various services, such as augmented reality (AR) / VR and ultra-reliable low-latency communication (URLLC). (Of these, at least VR is planned to be covered in 3GPP Release 17.) Based on service requirements, the NR research also includes a more adaptive QoE management scheme that enables network optimization to satisfy the user experience of various services.

[0005] The configuration data related to QoE measurements (typically referred to in standards as application-layer measurements) consists of an indication of the service type, an indication of the area where the measurements are to be performed (called the area scope), the IP address of the entity to which the collected measurements (i.e., QoE reports) should be sent (often referred to as the MCE, but also referred to as the Measurement Collector Entity or Measurement Collection Entity, although this entity is sometimes referred to as the Trace Collection Entity), and a set of instructions on the type of measurements to be performed and details of how these measurements are to be performed. These instructions are intended for the application layer of the UE and are placed in a "container" that the network entity that processes them (e.g., forwards them to the UE, as well as the access layer of the UE) cannot interpret and does not attempt to read. Currently specified service types are MTSI and Streaming Services (DASH). 3GPP Release 17 will add the service type VR, and 3GPP Release 18 will specify QoE measurements for Multicast and Broadcast Services (MBS). The area scope is defined as 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, the area scope is defined as a list of cells or a list of tracking areas. In NR, the area scope is defined as either a list of cells or a list of tracking areas.

[0006] There are two types of QoE, and in particular QoE configuration: management-based QoE configuration and signaling-based QoE configuration. In both cases, the QoE configuration originates from an OAM system or 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 the 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 other relevant conditions, such as support for relevant application / service types) and sends the m-based QoE configuration to these UEs.

[0007] In signaling-based QoE (s-based QoE), the OAM system is interested in collecting QoE measurements from a specific UE. The OAM system sends s-based QoE configurations to the Home Subscriber Server (HSS) (for EPS / LTE) or Unified Data Management (UDM) (for 5G / NR), which then forwards the QoE configurations to the UE's current core network node (CN), 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 configurations to the RAN node serving the UE, which then forwards them to the UE.

[0008] The container that is forwarded to the UE contains an indication of the service type and a measurement instruction. The UE does not know whether the received QoE configuration is m-based or s-based. In legacy systems, the QoE framework is integrated with the tracing function, and a trace ID is associated with each QoE configuration. In NR, the QoE function is logically separated from the tracing function, but partially reuses the trace signaling mechanism. In NR and possibly LTE, a globally unique QoE reference (composed of MCC (Mobile Country Code) + MNC (Mobile Network Code) + QMC (QoE Measurement Collection) ID, where QMC_ID is a 24-bit string) is associated with each QoE configuration. The QoE reference is also sent to the RAN (gNB in ​​NR) in a container together with the measurement instruction. In communication between the gNB and the UE, the QoE reference is replaced by a short identifier called measConfigAppLayerId, which is locally unique within the UE (i.e., for each QoE configuration provided to the UE, there is a one-to-one mapping between measConfigAppLayerId and QoE reference). The measConfigAppLayerId is stored in the UE's access layer and transferred in AT commands (a type of command used in communication between the UE's modem part and the UE's application layer) together with the container with the service type indication and measurement command.

[0009] A report containing the collected QoE measurements (QoE report) is sent from the UE application layer to the UE access layer, forwarded from the UE access layer to the RAN, and then forwarded from the RAN to the MCE. These QoE measurements are stored in a "container" that cannot be interpreted by the UE access layer or 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.

[0010] The RAN is not aware when an application session with an associated QoE measurement session is ongoing, and the UE's access layer is not automatically aware of this either. To mitigate this, a session start / stop indication is introduced, sent from the UE's application layer to the UE_AS and from the UE_AS to the RAN. The session stop indication can be explicit or implicit in the form of a QoE report sent when an application session and its associated QoE measurement session are terminated.

[0011] As an implementation-based decision, the RAN may decide to release the QoE settings of the UE at any time, typically when the UE moves outside the area configured for QoE measurements, which, as mentioned above, is commonly referred to as area scoping.

[0012] One of the opportunities that legacy solutions offer is to allow the QoE measurements to be maintained for the entire session, even during handover. It is also considered to allow the UE to continue measuring the QoE of an ongoing application session until the application session is terminated, even if the UE moves outside the configured area scope in the meantime.

[0013] RAN Visible QoE (RVQoE) An extension of the QoE framework is the concept of RAN-visible QoE (RVQoE), which was considered in 3GPP Release 17 and is currently specified by 3GPP. Regular QoE reporting is targeted to the MCE, which is an entity external to the RAN, e.g., part of the OAM system. In contrast, reported RVQoE metrics are RAN-oriented and delivered to the RAN in a format that the RAN can understand. RVQoE metrics are derived from regular QoE metrics, collected and compiled into a report by the UE application layer, and delivered to the RAN. As an example, when the RAN receives an RVQoE report during an ongoing application session, the RAN can take adaptive actions that affect the QoE of that application session, such as modifying various parameters related to the UE scheduling and the data flows associated with the application session, while the application session is in progress.

[0014] AT Commands AT commands are used for communication between the AS (radio) layer and the application layer of the UE. AT commands are defined in 3GPP TS27.007 version 17.3.0.

[0015] QoE Measurement in Legacy Systems QoE Measurements in UMTS Terrestrial Radio Access Network (UTRAN) UTRAN - Application Layer Measurement Functions According to 3GPP TS25.331, UTRAN can request the UE to report its capabilities (using the UECapabilityEnquiryRRC message), as indicated by "Error! Reference source not found".

[0016] In response, the UE may provide information about its capabilities using the UE Capability Information RRC message, as shown in "Error! Reference Source Not Found."

[0017] A UE can indicate support for QoE measurement and reporting in the UECapabilityInformation message. The relevant indication is included in the "Measurement capability" information element (IE), which is further included in the "UE radio access capability" IE included in the UECapabilityInformation message. The relevant definitions are taken from 3GPP TS25.331 version 16.1.0 below:

[0018] UE Capability Information message: TIFF2025529638000002.tif111170TIFF2025529638000003.tif150170

[0019] "UE radio access capability" IE: TIFF2025529638000004.tif87170TIFF2025529638000005.tif42170

[0020] "Measurement capability" IE: TIFF2025529638000006.tif176170

[0021] UTRAN-QoE Measurement Configuration-RRC Signaling To configure QoE measurements in the UE, the UTRAN can send a measurement control RRC message containing the "Application layer measurement configuration" IE. Figure 1 shows the typical measurement control procedure in the UTRAN. The relevant definitions are copied from 3GPP TS25.331 version 16.1.0 below:

[0022] Measurement Control Message: TIFF2025529638000007.tif117170

[0023] "Application layer measurement configuration" IE: TIFF2025529638000008.tif69170

[0024] UTRAN-QoE Measurement Reporting-RRC Signaling The UE can send the QoE measurement results to the collection entity via the UTRAN using the "Measurement Report" RRC message containing the "Application layer measurement reporting" IE. Figure 2 shows the measurement reporting procedure for the normal UTRAN case.

[0025] The UE may also perform a Cell Update to indicate that application layer measurement reports are available in the UE.

[0026] SRB4 is used for measurement reporting messages that contain the "Application layer measurement reporting" IE.

[0027] The relevant definitions are copied from 3GPP TS25.331 version 16.1.0 below:

[0028] Measurement Report message: TIFF2025529638000009.tif86170

[0029] "Application layer measurement reporting" IE: TIFF2025529638000010.tif70170

[0030] Cell Update message: TIFF2025529638000011.tif186170

[0031] "Cell update cause" IE: TIFF2025529638000012.tif18170TIFF2025529638000013.tif230170

[0032] QoE Measurement in Evolved UTRAN (E-UTRAN) E-UTRAN - Application Layer Measurement Functions In E-UTRAN, UE capability transfer is used to transfer UE radio access capability information from the UE to the E-UTRAN. Figure 3 shows the UE capability transfer procedure involving the E-UTRAN.

[0033] The UE-EUTRA-CapabilityIE is used to convey E-UTRA UE Radio Access Capability Parameters and Feature Group Indicators of mandatory capabilities to the network.

[0034] In the response message "UECapabilityInformation", the UE may include the "UE-EUTRA-Capability" IE. The "UE-EUTRA-Capability" IE may contain the "UE-EUTRA-Capability-v1530-IEs" IE that can be used to indicate whether the UE supports QoEMeasurementCollection for streaming services and / or MTSI services. The relevant ASN.1 code in the ASN.1 definition of the UE-EUTRA-Capability IE is shown below (most of the ASN.1 code in the UE-EUTRA-Capability IE definition has been omitted for clarity):

[0035] -- ASN1START

[0036]

[0037] :

[0038] :

[0039] :

[0040] :

[0041]

[0042] UE-EUTRA-Capability-v1530-IEs ::= SEQUENCE {

[0043] measParameters-v1530 MeasParameters-v1530 OPTIONAL,

[0044] otherParameters-v1530 Other-Parameters-v1530 OPTIONAL,

[0045] neighCellSI-AcquisitionParameters-v1530 NeighCellSI-AcquisitionParameters-v1530 OPTIONAL,

[0046] mac-Parameters-v1530 MAC-Parameters-v1530 OPTIONAL,

[0047] phyLayerParameters-v1530 PhyLayerParameters-v1530 OPTIONAL,

[0048] rf-Parameters-v1530 RF-Parameters-v1530 OPTIONAL,

[0049] pdcp-Parameters-v1530 PDCP-Parameters-v1530 OPTIONAL,

[0050] ue-CategoryDL-v1530 INTEGER (22..26) OPTIONAL,

[0051] ue-BasedNetwPerfMeasParameters-v1530 UE-BasedNetwPerfMeasParameters-v1530 OPTIONAL,

[0052] rlc-Parameters-v1530 RLC-Parameters-v1530 OPTIONAL,

[0053] sl-Parameters-v1530 SL-Parameters-v1530 OPTIONAL,

[0054] extendedNumberOfDRBs-r15 ENUMERATED {supported} OPTIONAL,

[0055] reducedCP-Latency-r15 ENUMERATED {supported} OPTIONAL,

[0056] laa-Parameters-v1530 LAA-Parameters-v1530 OPTIONAL,

[0057] ue-CategoryUL-v1530 INTEGER (22..26) OPTIONAL,

[0058] fdd-Add-UE-EUTRA-Capabilities-v1530 UE-EUTRA-CapabilityAddXDD-Mode-v1530 OPTIONAL,

[0059] tdd-Add-UE-EUTRA-Capabilities-v1530 UE-EUTRA-CapabilityAddXDD-Mode-v1530 OPTIONAL,

[0060] nonCriticalExtension UE-EUTRA-Capability-v1540-IEs OPTIONAL

[0061] }

[0062]

[0063] :

[0064] :

[0065] :

[0066] :

[0067]

[0068] MeasParameters-v1530 ::= SEQUENCE {

[0069] qoe-MeasReport-r15 ENUMERATED {supported} OPTIONAL,

[0070] qoe-MTSI-MeasReport-r15 ENUMERATED {supported} OPTIONAL,

[0071] ca-IdleModeMeasurements-r15 ENUMERATED {supported} OPTIONAL,

[0072] ca-IdleModeValidityArea-r15 ENUMERATED {supported} OPTIONAL,

[0073] heightMeas-r15 ENUMERATED {supported} OPTIONAL,

[0074] multipleCellsMeasExtension-r15 ENUMERATED {supported} OPTIONAL

[0075] }

[0076]

[0077] :

[0078] :

[0079] :

[0080] :

[0081]

[0082] -- ASN1STOP

[0083] TIFF2025529638000014.tif101170TIFF2025529638000015.tif57170

[0084] E-UTRAN - QoE Measurement Setup and Release - RRC Signaling The RRCConnectionReconfiguration message is used to reconfigure the UE to set up or release it for application layer measurements. This is signaled in the measConfigAppLayer-r15IE within the OtherConfigIE.

[0085] This setup includes a transparent container measConfigAppLayerContainerIE that specifies the QoE measurement configuration for the target application, and a serviceTypeIE that indicates the application (or service) for which QoE measurements are configured. Supported services are streaming and MTSI.

[0086] The relevant parts of the ASN.1 code and field descriptions for OtherConfigIE are copied below from 3GPP TS36.331 version 16.6.0 (for clarity, fields / parameters that are irrelevant in the context of QoE have been omitted):

[0087] -- ASN1START

[0088]

[0089] OtherConfig-r9 ::= SEQUENCE {

[0090] :

[0091] :

[0092] :

[0093] :

[0094] [[ measConfigAppLayer-r15 CHOICE{

[0095] release NULL,

[0096] setup SEQUENCE{

[0097] measConfigAppLayerContainer-r15 OCTET STRING (SIZE(1..1000)),

[0098] serviceType-r15 ENUMERATED {qoe, qoemtsi, spare6,

[0099] spare5, spare4, spare3,

[0100] spare2, spare1}

[0101] }

[0102] } OPTIONAL, -- Need ON

[0103] :

[0104] :

[0105] :

[0106] :

[0107] }

[0108]

[0109] :

[0110] :

[0111] :

[0112]

[0113] -- ASN1STOP

[0114] TIFF2025529638000016.tif100170

[0115] Below is the procedure text related to OtherConfigIE (i.e., when the UE receives an RRCConnectionReconfiguration message containing OtherConfigIE) and QoE measurement configuration:

[0116] The UE shall:

[0117] :

[0118] :

[0119] :

[0120] 1> If the received otherConfig contains measConfigAppLayer:

[0121] 2> If measConfigAppLayer is set to setup:

[0122] 3> Considering the serviceType, forward the measConfigAppLayerContainer to the upper layer;

[0123] 3> be deemed to be configured to transmit application layer measurement reports in accordance with 5.6.19;

[0124] 2> Otherwise

[0125] 3> Notify upper layers to clear stored application layer measurement configuration;

[0126] 3> Discard the application layer measurement report information received from the upper layer;

[0127] 3> Assume it is not configured to send application layer measurement reports.

[0128] E-UTRAN - Application Layer Measurement Reporting The purpose of the "Application layer measurement reporting" procedure described in 3GPP TS36.331 version 16.6.0 and shown below is to forward application layer measurement reports to the E-UTRAN so that the E-UTRAN can forward the reports to an O&M system (e.g., a Measurement Collection Entity (MCE) or a Trace Collection Entity (TCE)). Figure 4 shows application layer measurement reporting in the E-UTRAN.

[0129] A UE capable of application layer measurement reporting in RRC_CONNECTED state may initiate this procedure if application layer measurements are configured, i.e., if the measConfigAppLayerIE is configured by E-UTRAN. For this purpose, the UE uses the MeasReportAppLayer RRC message containing the measReportAppLayerContainerIE and the serviceTypeIE.

[0130] According to 3GPP TS36.331 version 16.6.0, when initiating the application layer measurement reporting procedure, the UE shall:

[0131] 1> If application layer measurement is configured, SRB4 is configured, and the UE receives application layer measurement report information from higher layers:

[0132] 2> Set measReportAppLayerContainer in the MeasReportAppLayer message to the value of the application layer measurement report information;

[0133] 2> Set the serviceType of the MeasReportAppLayer message to the type of application layer measurement report information;

[0134] 2> Send the MeasReportAppLayer message to the lower layer via SRB4.

[0135] In ASN.1 code (including relevant field descriptions), the MasReportAppLayer message is defined in 3GPP TS36.331 version 16.6.0 as follows:

[0136] -- ASN1START

[0137]

[0138] MeasReportAppLayer-r15 ::= SEQUENCE {

[0139] criticalExtensions CHOICE {

[0140] measReportAppLayer-r15 MeasReportAppLayer-r15-IEs,

[0141] criticalExtensionsFuture SEQUENCE {}

[0142] }

[0143] }

[0144]

[0145] MeasReportAppLayer-r15-IEs ::= SEQUENCE {

[0146] measReportAppLayerContainer-r15 OCTET STRING (SIZE(1..8000)) OPTIONAL,

[0147] serviceType-r15 ENUMERATED {qoe, qoemtsi, spare6, spare5, spare4, spare3, spare2,

[0148] spare1} OPTIONAL,

[0149] nonCriticalExtension MeasReportAppLayer-v1590-IEs OPTIONAL

[0150] }

[0151]

[0152] MeasReportAppLayer-v1590-IEs ::= SEQUENCE {

[0153] lateNonCriticalExtension OCTET STRING OPTIONAL,

[0154] nonCriticalExtension SEQUENCE {} OPTIONAL

[0155] }

[0156]

[0157] -- ASN1STOP

[0158] TIFF2025529638000017.tif69170

[0159] UE application layer measurement configuration In signaling-based QoE configuration, the configuration is signaled from the MME to the RAN (eNB) using the control plane protocol for the S1 interface (S1AP) specified in 3GPP TS36.413 version 16.7.0.

[0160] The "UE Application layer measurement configuration" IE defines the configuration information for the QoEMeasurementCollection (QMC) feature, as described in 3GPP TS36.413 version 16.7.0, clause 9.2.1.128 as follows (note that this IE is included in the Trace Activation IE, which also contains the Trace Collection Entity IP Address IE among other parameters): TIFF2025529638000018.tif78170TIFF2025529638000019.tif240170TIFF2025529638000020.tif113170TIFF2025529638000021.tif63170

[0161] Area scope for QoE measurement According to 3GPP TS28.405 version 16.0.0, the area scope parameter defines the area in terms of cells or tracking areas / routing areas / location areas where QMC takes place. If this parameter is not present, QMC takes place over the entire public land mobile network (PLMN) specified by PLMNtarget.

[0162] The UMTS area scope parameter can be one of the following: - A list of cells identified by their Cell Global ID (CGI). Up to 32 CGIs can be defined. - A list of routing areas identified by their routing area identifiers (RAIs). Up to eight RAIs can be defined. - A list of location areas identified by their Location Area Identifiers (LAIs). Up to eight LAIs can be defined.

[0163] The area scope parameters in LTE are either: - A list of cells identified by E-UTRAN-CGI. Up to 32 CGIs can be defined. - A list of tracking areas identified by Tracking Area Codes (TACs). Up to eight TACs can be defined.

[0164] For NR, the area scope parameter can be one of the following: -List of cells - Tracking area list.

[0165] This parameter is mandatory if area-based QMC is requested.

[0166] RRC_INACTIVE state In 5G / NR, a UE can be in one of three different RRC states: RRC_CONNECTED, RRC_INACTIVE, and RRC_IDLE. The RRC_CONNECTED state is the state typically used when the UE is actively communicating. The RRC_INACTIVE and RRC_IDLE states are designed to allow the UE to save energy compared to when it is in the RRC_CONNECTED state.

[0167] The RRC_IDLE state is the UE's least energy-consuming state (and allows the gNB to save resources by deleting the UE's state information (also known as the UE context)), but at the expense of relatively longer network access times (e.g., transitioning to the RRC_CONNECTED state).

[0168] The RRC_INACTIVE state has characteristics intermediate between the RRC_CONNECTED state and the RRC_IDLE state.

[0169] The purpose of the RRC_INACTIVE state is to reduce radio and network interface signaling overhead and improve the UE's access latency (compared to the RRC_IDLE state) and UE energy consumption. In this state, the core network (CN) still considers the UE connected, and the RRC connection between the gNB and the UE is suspended, but the UE's CN-RAN connection remains active. The gNB that maintains the connection with the CN while the UE is in the RRC_INACTIVE state is called the anchor gNB. To reduce radio interface signaling during connection establishment, UE context information is maintained in the UE and anchor gNB, allowing the UE to resume the RRC connection when it is paged or has uplink (UL) data or signaling to transmit. If the CN has user or control data to transmit to the UE, the data is sent to the anchor gNB, which then initiates paging of the UE (also known as RAN-initiated paging).

[0170] In RRC_INACTIVE state, the UE can move within its own RAN Notification Area (RNA) without informing the network of its location within the RNA. When the UE leaves its configured RNA, the UE notifies the network using RNA update signaling in the form of an RRCResumeRequest message with resumeCauseIE set to "rna-Update". If an extended period of time passes without any communication between the UE and the network, the UE will periodically send an RNA update (i.e., an RRCResumeRequest message with resumeCauseIE set to "rna-Update") to the network, even if it has not left its configured RNA.

[0171] The gNB configures the UE's RNA when releasing the UE from RRC_CONNECTED to RRC_INACTIVE state using the RRCRelease message. There are three different options for how to configure the UE's RNA: - List of cells: The UE is provided with a list of (one or more) global cell IDs of the cells that make up the RNA. - RAN Area List. The UE is provided with a list of (one or more) RAN Area IDs. A RAN Area ID is a combination of the RAN Area Code (RANAC) with the Tracking Area Code and PLMN_ID (i.e., the RANAC is unique within a Tracking Area). To enable RNA configuration using a RAN Area List, all cells must broadcast their RAN Area Code (optionally they can choose not to use this code if the network does not use RAN Area-based RNA configuration). A RAN Area consists of a subset (or all) of the cells in one Tracking Area. - Tracking Area List: The UE is provided with a list of one or more tracking area IDs, where a tracking area ID is a combination of a tracking area code (TAC) and a PLMN_ID.

[0172] The UE's RNA must not include any areas outside the list of tracking areas configured for the UE by the CN, as crossing this boundary will result in the UE sending a Registration Request Non-Access Stratum (NAS) message to the CN with the "5GS registration type" IE set to "mobility registration updating" (i.e., a procedure called tracking area updating in LTE).

[0173] The RAN may use any of the above configuration options when configuring the RNA for a UE, and may use different configuration methods not only for different UEs but also for the same UE at different times, but may not simultaneously mix different configuration options in the same RNA configuration for a particular UE.

[0174] During an RNA update (or other contact between the UE and the network), the RAN can configure a new RNA for the UE (for example, if the UE moves to a new cell), and if the UE moves to a new gNB, the UE's context in the RAN is fetched from the old anchor gNB to the new gNB. This is performed using the XnAP messages RETRIEVE UE CONTEXT REQUEST and RETRIEVE UE CONTEXT RESPONSE. Furthermore, the UE's RAN-CN connection is moved from the old anchor gNB to the new gNB, which becomes the new anchor gNB. This is done using the NG Application Protocol (NGAP) messages PATH SWITCH REQUEST and PATH SWITCH REQUEST ACKNOWLEDGE.

[0175] When the RAN switches (i.e., releases) a UE from RRC_CONNECTED to RRC_INACTIVE state, the serving gNB (which becomes the anchor gNB) assigns an ID called I-RNTI to the UE, which serves to identify both the anchor gNB and the UE's context within the anchor gNB when the UE's context is fetched from the old anchor gNB to the new gNB.

[0176] When the UE wishes to transition from RRC_INACTIVE to RRC_CONNECTED state due to the reception of a page or the arrival of pending UL data (i.e., data originating from the UE and stored in the UE's UL transmission buffer), the UE sends a request to resume the RRC connection (including the suspended radio bearer) including its I-RNTI (this is the RRCResumeRequest message). The gNB receiving this request can use the included I-RNTI to fetch the UE's context from the old anchor gNB (also known as the "last serving gNB") and then resume the RRC connection. The new gNB then completes the RRC connection resumption (by sending an RRCResume message to the UE, which the UE responds to with an RRCResumeComplete message), and the UE context at the old anchor gNB (last serving gNB) is deleted.

[0177] A UE in RRC_INACTIVE state is said to be "camping" on a cell that monitors relevant downlink (DL) control signals, such as synchronization signals, system information, and paging. A UE in RRC_INACTIVE is assumed to follow the same cell reselection rules as a UE in RRC_IDLE. Therefore, cell reselection information provided in the system information, traditionally used by UEs in RRC_IDLE, also applies to UEs in RRC_INACTIVE. This includes measurement thresholds, reselection thresholds, hysteresis parameters to avoid "ping-pong" reselections, potential cell-specific offsets, etc. Furthermore, to control potential inter-frequency and / or inter-radio access technology (RAT) cell reselections, cell reselection-related system information typically also includes frequency priority and / or RAT priority.

[0178] Currently, there is a problem.

[0179] The current 3GPP standard allows a UE to maintain QoE measurement configuration while in RRC_INACTIVE state, but the standard is silent on the possibility of the UE performing QoE measurements in RRC_INACTIVE state or providing the network with information related to the time spent in RRC_INACTIVE state.

[0180] Note that, for example, a streaming application may have a buffer of video data that lasts for several minutes, which means that the streaming session may survive for a significant period without communication, which may occur, for example, if the UE is temporarily released into RRC_INACTIVE state (or RRC_IDLE state).

[0181] Furthermore, the indication of the session status (ongoing or not ongoing) in the network is problematic, considering that an application session with an associated QoE measurement session may be ongoing when the UE is released to RRC_INACTIVE state, may or may not be terminated while the UE is in RRC_INACTIVE state, or a new application session with an associated QoE measurement session may be started while the UE is in RRC_INACTIVE state: while the UE is in RRC_INACTIVE state, there is no communication between the UE and the network, and therefore there is no way to ensure that the indication of the session status in the network is correct.

[0182] This means that when the UE resumes its RRC connection with a new RAN node, problems will arise when the session status indication is transferred (in the NR RETRIEVE UE CONTEXT RESPONSE XnAP message) from the anchor RAN node (i.e., the old RAN node, e.g., the old gNB) to the new RAN node (e.g., the new gNB) because the status indication to the new RAN node may not be correct due to the above. Summary of the Invention

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

[0184] One aspect of the present disclosure attempts to address the above-mentioned problem by providing the network with information (e.g., ongoing, not ongoing, terminated, ...) from the UE when the RRC connection is resumed regarding the QoE measurement session(s) during the elapsed RRC_INACTIVE period (e.g., sending this information to the new RAN node to which the UE resumed the RRC connection). If future 3GPP releases enable retention of QoE configuration in RRC_IDLE state, this solution may also be applicable when the UE is released to RRC_IDLE and subsequently establishes a new RRC connection towards a new RAN node.

[0185] The session status information may be enriched or supplemented with further relevant information, such as a list of session status changes that occurred during the RRC_INACTIVE (or RRC_IDLE) state, timestamps of the session status changes, or the duration of the RRC_INACTIVE (or RRC_IDLE) state period.

[0186] Relevant information may also be transferred from the old RAN node to the new RAN node (e.g., in the case of RRC_INACTIVE state, from the anchor RAN node to the RAN node where the UE performs the RRC resume procedure), such as the last known session state (which may be overwritten by the latest session state information from the UE), the timestamp of when the UE was released into RRC_INACTIVE (or RRC_IDLE) state, and / or the last reported value(s) of certain RVQoE metrics (e.g., streaming buffer levels).

[0187] Thus, according to an embodiment of the present disclosure, the UE provides session status information related to the QoE measurement session to the RAN node when the UE resumes the RRC connection after a period in RRC_INACTIVE state (or when the UE sets up the RRC connection after a period in RRC_IDLE state).

[0188] In a first aspect of the present disclosure, a method is performed by a user equipment (UE), the method including, upon transitioning to a connected state, connecting to a first RAN node of a communications network, the method further including transmitting information related to one or more QoE measurement sessions configured in the UE to the communications network, the one or more QoE measurement sessions being configured in the UE during a previous instance of the UE being in the connected state.

[0189] In a second aspect of the present disclosure, a method is performed by a user equipment, the method including, while in an inactive connection state, transmitting, to a first RAN node of a communications network, information related to one or more QoE measurement sessions configured in the user equipment.

[0190] In a third aspect of the present disclosure, a method is performed by a first network node of a communication network, the method including, upon a user equipment connecting to the first network node and transitioning to a connected state, receiving, from one or more of the user equipment and a second network node of the communication network, information related to one or more QoE measurement sessions configured in the user equipment, the one or more QoE measurement sessions configured in the user equipment during a previous instance of the user equipment in the connected state.

[0191] In a fourth aspect of the present disclosure, a method is performed by a second network node serving a user equipment that has been released to an inactive or idle connected state, the method including transmitting information related to one or more QoE measurement sessions configured for the user equipment to a first network node to which the user equipment subsequently connects upon transition to the connected state.

[0192] Certain embodiments may provide the technical advantage of enabling the network to recognize the true session state (e.g., QoE measurement session) of a UE when the UE returns to a connected state (e.g., RRC_CONNECTED) after a period of being in an inactive or idle state (e.g., RRC_INACTIVE or RRC_IDLE). [Brief explanation of the drawings]

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

[0194] [Figure 1] FIG. 5 is a signaling diagram illustrating a UE capability inquiry procedure.

[0195] [Figure 2] FIG. 6 is a signaling diagram illustrating transmission of UE capability information.

[0196] [Figure 3] FIG. 7 is a signal diagram showing the measurement control procedure.

[0197] [Figure 4] FIG. 8 is a signaling diagram illustrating a measurement reporting procedure.

[0198] [Figure 5] FIG. 9 is a signaling diagram illustrating a UE capability transfer procedure.

[0199] [Figure 6] FIG. 10 is a signaling diagram illustrating the application layer measurement reporting procedure.

[0200] [Figure 7] FIG. 7 is a schematic flow chart illustrating a method according to some embodiments.

[0201] [Figure 8] FIG. 8 is a schematic flow chart illustrating a method according to some embodiments.

[0202] [Figure 9] FIG. 9 is a schematic flow chart illustrating a method according to some embodiments.

[0203] [Figure 10] FIG. 10 is a schematic flow chart illustrating a method according to some embodiments.

[0204] [Figure 11] FIG. 11 illustrates an example of a communication system according to some embodiments.

[0205] [Figure 12] FIG. 12 illustrates a UE according to some embodiments.

[0206] [Figure 13] FIG. 13 illustrates a network node according to some embodiments.

[0207] [Figure 14] FIG. 14 is a block diagram of a host in accordance with various aspects described herein.

[0208] [Figure 15] FIG. 15 is a block diagram illustrating a virtualization environment in which functionality implemented by some embodiments may be virtualized.

[0209] [Figure 16] FIG. 16 is a block diagram illustrating a communication diagram of a host communicating with a UE through a network node over a partial wireless connection, in accordance with some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0210] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings, in which: The embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0211] Terminology and Generalizations The terms "UE," "terminal equipment," and "wireless terminal" are used interchangeably.

[0212] The terms "MCE" and "TCE" are used interchangeably.

[0213] The terms "QoE measurements" and "application layer measurements" are used interchangeably.

[0214] 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. Note that the term "QMC configuration file" is not an equivalent term and refers to the part of the QoE configuration that consists of an XML file that contains, among other things, instructions for the QoE metrics to collect.

[0215] 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.

[0216] The terms "QoE measurement" and "application layer measurement" refer to the same type of measurement.

[0217] The terms "modem," "radio layer," "RRC layer," and "radio network layer" are used interchangeably when referring to a UE.

[0218] The terms "access stratum" and "radio stratum" are used interchangeably when referring to a UE.

[0219] The term "session" is used frequently herein and may refer to either a QoE measurement session, an application session, or an application session to which QoE measurements are applied.

[0220] An application session and a QoE measurement session configured to measure or collect data from the application session are strongly related. This is often reflected in this document by saying that a QoE measurement session is associated with the application session, or that an application session is associated with a QoE measurement session. A possible exception is when an application session of a certain service type is initiated and subsequently (while the application session is ongoing) a QoE configuration targeting that service type is received at the UE application layer, The UE application layer initiates a QoE measurement session to measure the running application session (instead of the alternative option of not starting a QoE measurement session for an already ongoing application session and waiting for the next application session of the targeted service type). The same principle applies to RVQoE measurements. In the following description, unless otherwise specified, it is assumed that an application session and its associated QoE measurement session and / or RVQoE measurement session are started simultaneously or with negligible delay between the application session and the QoE measurement session. Mechanisms that specifically address the case where a QoE measurement session and / or RVQoE measurement session is started while an associated application session is already in progress (i.e., the QoE measurement session and / or RVQoE measurement session is started with a non-negligible delay) may also be covered by the embodiments described herein.

[0221] In the above discussion of the relationship between application sessions and associated QoE measurement sessions, it is relevant to discuss the meaning of the "session start" indication (a term frequently used in this discussion). During the specification work for the QoE framework (especially QoEforNR), 3GPP has not clarified whether the session start indication refers to an application session or a QoE measurement session. However, the first Release 17 version of the NR RRC specification (3GPP TS38.331 Version 17.0.0) suggests that a session start indication sent from the UE to the gNB (in the form of the applicationLayerSessionStatus-r17 parameter set to "started" in the MeasurementReportAppLayer message) refers to a started QoE measurement session, and it is assumed that the same applies to a session start indication sent from the UE application layer to the UE_AS. Therefore, the basic assumption in this discussion is that a session start indication refers to a QoE measurement session.

[0222] The solution proposed in this disclosure applies to future radio access technologies such as UMTS, LTE, NR, and 6G.

[0223] All references to the application layer refer to the application layer of the UE (as the RAN node does not have an application layer).

[0224] The solution proposed in this disclosure applies to both signaling-based and management-based QoE measurements (although it can optionally be restricted to only one).

[0225] To transition from the RRC_INACTIVE state to the RRC_CONNECTED state, the UE performs a procedure in which the UE's RRC connection is said to be resumed. This procedure may be referred to herein as the resume procedure, connection resume procedure, RRC connection resume procedure, or RRC resume procedure. This procedure consists of a three-way message exchange between the UE and the network (e.g., gNB), including an RRCResumeRequest or RRCResumeRequest1 message from the UE, followed by an RRCResume message from the network, followed by an RRCResumeComplete message from the UE.

[0226] To transition from the RRC_IDLE state to the RRC_CONNECTED state, the UE performs a procedure to establish an RRC connection for the UE. This procedure may be referred to in this document as the connection establishment procedure, RRC connection establishment procedure, setup procedure, RRC setup procedure, or RRC connection setup procedure. In NR, this procedure consists of a three-way message exchange between the UE and the network (i.e., gNB) including an RRCSetupRequest message from the UE, followed by an RRCSetup message from the network, followed by an RRCSetupComplete message from the UE. In LTE, this procedure consists of a three-way message exchange between the UE and the network (e.g., eNB) (an RRCConnectionRequest message from the UE, followed by an RRCConnectionSetup message from the network, followed by an RRCConnectionSetupComplete message from the UE).

[0227] Although embodiments herein are primarily described in 5G / NR terms and refer to application of solutions in 5G / NR, embodiments of the present disclosure are also applicable to LTE (where, for example, gNBs are replaced by eNBs), UMTS, and / or future systems (e.g., 6G). In the LTE example, the NR messages RRCRelease, RRCResumeRequest / RRCResumeRequest1, RRCResume, RRCResumeComplete, RRCSetupRequest, RRCSetup, RRCSetupComplete, RRCReconfiguration, and MeasurementReportAppLayer correspond to the LTE messages RRCConnectionRelease, RRCConnectionResumeRequest, RRCConnectionResume, RRCConnectionResumeComplete, RRCConnectionRequest, RRCConnectionSetup, RRCConnectionSetupComplete, RRCConnectionReconfiguration, and MeasReportAppLayer.

[0228] Embodiments of the present disclosure According to embodiments of the present disclosure, to address the above-mentioned problems, information about the QoE measurement session(s) during the past RRC_INACTIVE period (e.g., ongoing, not ongoing, completed, ...) is provided from the UE to the network when the RRC connection is resumed (i.e., the UE sends this information to the new RAN node to which the UE resumes the RRC connection). For details of these embodiments, see Figures 7 and 9. This information may be sent, for example, in the RRCResumeRequest message, the RRCResumeComplete message, the MeasurementReportAppLayer message, the UEAssistanceInformation message, or the UEInformationResponse message (upon request from the new RAN node in the UEInformationRequest message, optionally after the UE has indicated the availability of such information in the RRCResumeComplete message), or in a newly introduced message. Optionally, the UE sends the session status information to the RAN node performing the RRC resume procedure only if the session status is "ongoing". Another option is for the UE to send session status information to the RAN node performing the RRC resume procedure only if the session status has changed compared to when the UE entered the INACTIVE state.

[0229] If retention of QoE configuration in RRC_IDLE state is enabled in a future 3GPP release, the above solution may also be applicable when the UE is released into RRC_IDLE state and subsequently sets up a new RRC connection (possibly towards a new RAN node). In this case, the RRC Resume procedure will be replaced by the RRC Setup procedure, and of the aforementioned messages by which the UE can send session status information, the RRCResumeRequest message will be replaced by the RRCSetupRequest message and the RRCResumeComplete message will be replaced by the RRCSetupComplete message or a newly defined message.

[0230] Variations, extensions, and complements of the basic principles for signaling session status information A UE in RRC_INACTIVE state New RAN Node (e.g., gNB or eNB) RRC resume procedure towards When starting the RRC_INACTIVE state, the anchor RAN node (e.g., gNB or eNB) must Session in progress / not in progress status However, the information may be out of date and inaccurate. This information is optionally The anchor RAN node transfers the UE to a new RAN node where it resumes the RRC connection. From UE context information (e.g., in a RETRIEVE UE CONTEXT RESPONSE XnAP message) You can also exclude Another option is to forward the data from the anchor RAN node to the new RAN node. Can also be included in the UE context but, In that case, it will be overwritten by the information sent from the UE. A further option is to use the RRC_INACTIVE state that was in effect when the UE was released into RRC_INACTIVE state. Session Status The status (ongoing / not ongoing) is transferred from the anchor RAN node to the new RAN node where the UE resumes the RRC connection (e.g. in a RETRIEVE UE CONTEXT RESPONSE XnAP message). Included in the UE context informationThe UE receives the session status information sent from the anchor RAN node to the new RAN node and If different (i.e., the UE's session status information is different from what it was when the UE was released into RRC_INACTIVE state) Only then will the overriding session status information be sent to the new RAN node. .

[0231] The solution embodiments described herein include: UE, What RAN node released the UE to RRC_INACTIVE state (or RRC_IDLE state)? Another RAN node Towards RRC Resume It should be noted that although reference is made to the case where the UE performs an RRC Resume procedure (or an RRC Setup procedure) towards the same RAN node that released the UE to RRC_INACTIVE state (or RRC_IDLE state), embodiments of the solution are also applicable when the UE performs an RRC Resume procedure (or an RRC Setup procedure) towards the same RAN node that released the UE to RRC_INACTIVE state (or RRC_IDLE state), UE resumes RRC Procedure (or RRC Setup Procedure) A cell that runs Even if the UE is in RRC_INACTIVE state (or RRC_IDLE state), May be the same .

[0232] If the UE is dual-attached and the SN configures the UE for QoE measurements, the SN is the node with knowledge of the session status. In this case, the SN informs the MN of the session status, which the MN can then inform the new RAN node upon RRC resume of RRC connection establishment. To do this, the SN can use either the existing DC-related XnAP procedure (with possible extensions) or a newly defined procedure.

[0233] While the UE is in RRC_INACTIVE state: Related to QoE configuration Session status may change multiple timesIt should be noted that, for example, if a QoE measurement session (and associated application session) that was in progress when the UE was released into the RRC_INACTIVE state is terminated while the UE is in the RRC_INACTIVE state, and subsequently another application session of the same type with an associated QoE measurement session (configured by the same QoE configuration) is started while the UE is still in the RRC_INACTIVE state, the UE may indicate this has occurred by, for example, providing a list of session status indications (e.g., in this case a session stop indication followed by a session start indication) to the RAN node to which the UE resumes its RRC connection. Optionally, a timestamp may be associated with each provided session status indication.

[0234] In an alternative solution, the UE sends a session in progress / not in progress status indication during the resume procedure only if the status has changed compared to the latest status indication sent by the UE before transferring to RRC_INACTIVE. This means that the network does not receive information about session status updates while the UE is in RRC_INACTIVE, but receives the latest information when the UE resumes to RRC_CONNECTED. In this solution, if the status remains the same after resuming and the UE does not send any information to the network, the network can forward the session status information from the source to the target node. This solution may be combined with a solution in which the UE signals further information to the network.

[0235] Signaling additional information beyond session status Further information that the UE may provide to the RAN node performing the RRC resume procedure may include an indication of the time that the UE spent in the RRC_INACTIVE state (e.g., shown as a duration or as a timestamp of when the UE was released into the RRC_INACTIVE state).

[0236] The UE can transmit information about whether a session was ongoing during RRC_INACTIVE. As an example, from time a to time b, the UE has an ongoing session, from time be to time c, there is no ongoing session, from time c to time d, there is an ongoing session, etc. As a simplified option, the UE can indicate timestamps corresponding to the instants when sessions started and / or ended during the RRC_INACTIVE state.

[0237] The anchor RAN node may also provide the new RAN node with more information than the last known session state of the UE (i.e., the session state that was in effect when the UE was released into RRC_INACTIVE state). Such additional information may include, for example: The time the UE was in RRC_INACTIVE state (e.g., indicated as a duration or as a timestamp of when the UE was released into RRC_INACTIVE state). Further information that the anchor RAN node can provide to the new RAN node may include the last streaming buffer level reported by the UE before it was released into RRC_INACTIVE state. One or more of the most recent RVQoE metric values , and optionally The timestamp associated with that buffer levelAccording to the above mentioned options, the last known session status of the UE may be omitted, so that even if the anchor RAN node omits the last known session status of the UE, it may still provide any of the additional / further information mentioned above, for example information regarding the length of the UE's RRC_INACTIVE period (possibly in the form of an indication of the release time to RRC_INACTIVE state) and / or one or more of the RVQoE metric values ​​most recently reported by the UE.

[0238] State transition triggers A typical trigger for a UE with an active application session to initiate an RRC resume procedure may be the application generating uplink data to be transmitted (e.g., a request to an application server, e.g., a request for streaming data). Alternatively, the trigger for the RRC resume procedure may be the application session's buffer becoming empty, dropping below a certain threshold, or showing a decreasing trend. Alternatively, the trigger may be a paging message from the network. The paging message may be triggered by downlink application data pending transmission to the UE. For a UE in RRC_INACTIVE state, the UE may be paged by RAN paging, and receipt of the page triggers the UE to initiate the RRC resume procedure and transition to the RRC_CONNECTED state. For a UE in RRC_IDLE state (especially if a future 3GPP release allows the UE to retain QoE configuration in RRC_IDLE state, which may be relevant in the context of this disclosure), the UE may be paged through CN paging, and receipt of the page triggers the UE to initiate the RRC setup procedure and transition to the RRC_CONNECTED state. Whether and / or what session status information is provided from the UE to the new RAN node may depend on the nature of the trigger for the RRC resume (or RRC setup) procedure.

[0239] In one option, the UE may also provide the network with a QoE-specific reason for initiating RRC resume (eg, reasons such as those mentioned above (UL data to send, buffer exhaustion, etc.)).

[0240] UE operation configuration UE When a RAN node resumes a connection (or performs an RRC setup procedure after a period in RRC_IDLE state) Whether session status information should be provided , and the type of information provided, can be configured by the network.

[0241] One option is to UE In RRC_INACTIVE state (or RRC_IDLE state) RAN node to be released teeth, UE In RRC_INACTIVE state (or RRC_IDLE state) Message to be released , provided by the UE to the RAN node where the UE will perform subsequent RRC resume procedures, e.g., in an RRCRelease message. Possible session status information reporting instructions may be indicated. Such an indication may, for example, indicate whether the UE should provide its session status information, if the session status has changed or what the session status was at the time the UE was released into RRC_INACTIVE (or RRC_IDLE) state (e.g., the session status when the UE received the RRCRelease message), and / or what type of information the UE should provide (only the latest / current session status, or a list of session status indications, and / or additional information such as the duration of the RRC_INACTIVE (or RRC_IDLE) state).

[0242] As another option, the RAN node at which the UE performs the RRC resume procedure (or RRC setup procedure) may include such an indication in the RRCResume message (or RRCSetup message).

[0243] In another option, the RAN node configures the UE to send session status updates in UEAssistanceInformation messages.

[0244] Yet another option is UE resumes RRC Procedure (or RRC Setup Procedure) RAN nodes running Use the UEInformationRequest message to Specific session status information and / or to send additional information in a UEInformationResponse message (possibly after the UE has indicated the availability of such information in an RRCResumeComplete message (or RRCSetupComplete message)). Explicitly request the UE It is possible.

[0245] Yet another option is UE resumes RRC Procedure (or RRC Setup Procedure) RAN nodes running using the RRCReconfigurationRequest message, for example in the MeasurementReportAppLayer message, Specific session status information and / or additional information Explicitly request the UE to transmit It is possible.

[0246] Yet another option that can complement (e.g., be used in parallel with) any of the above options is that if the RRC resume procedure is triggered by a page, the RAN node RRC Paging Message can contain instructions of the above types.

[0247] Yet another option is Instructions can also be shown in broadcast system information If this option is used, in one variant it may be used as a default indication, which may be overridden or supplemented by an indication provided to the UE in any of the ways described above.

[0248] The UE can be configured to send all session status updates, or it can be configured to send session status updates upon resuming to RRC_CONNECTED only if the session status has changed since the UE was transferred to RRC_INACTIVE (or RRC_IDLE).

[0249] The indication may be unconditional, but in some variants may depend on one or more conditions. For example, the indication or part of the indication may be conditioned by the type of trigger for the RRC resume procedure (or RRC setup procedure), e.g., the indication depends on whether the trigger is a UE internal trigger or a page.

[0250] In another option, the RAN node When the session status changes , e.g. when a session starts or ends Start RRC resume and provide session information in conjunction with it. Configure the UE It is possible.

[0251] Further conditions may be directed to cases of UE internal triggers, e.g. The instruction is given by the UE internal trigger. (of the application with the associated QoE configuration to which the instruction applies) Application data generation or another It may depend on whether it is a UE internal trigger.

[0252] Further conditions may cover when the trigger is a page, for example the instructions may depend on whether the page is a RAN initiated page or a CN initiated page.

[0253] In another example, the instructions, or part of the instructions, UE is performing RRC resume procedure (or RRC setup procedure) RAN nodes that run (i.e., the RAN node that released the UE into RRC_INACTIVE state (or RRC_IDLE state)) Same as or different from RAN Is it a node? can be conditioned byIn this example, if the RAN node on which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as the old RAN node, further conditions may apply, such as the indication depending on whether the cell on which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as the cell on which the UE was released to RRC_INACTIVE state (or RRC_IDLE state) or a different cell.

[0254] In another example, the indication or part of the indication may be conditioned on whether the cell on which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as the cell on which the UE was released to the RRC_INACTIVE state (or RRC_IDLE state) or a different cell.

[0255] In another example, The instruction or part of the instruction is the type of state transition procedure. (i.e., which state the UE must exit to enter RRC_CONNECTED state) It may be conditioned by For example, the indication may depend on whether the state transition procedure is an RRC resume procedure (causing the UE to transition from RRC_INACTIVE state to RRC_CONNECTED state) or an RRC setup procedure (causing the UE to transition from RRC_IDLE state to RRC_CONNECTED state).

[0256] Adapting the solution to the RRC_IDLE state and RRC setup 3GPP Release 17 does not support preserving QoE configuration in the RRC_IDLE state, but this may change in future releases of the 3GPP standard. In anticipation of such possible extensions to the 3GPP standard, all methods, embodiments, options and variants described above in relation to the RRC_INACTIVE state are now considered to be equivalent to the following: It may be adapted to apply in conjunction with the RRC_IDLE state instead of the RRC_INACTIVE state.This adaptation involves replacing the RRC resume procedure with an RRC setup procedure and removing the XnAP-based (or X2AP-based) context fetch, while maintaining all other essential principles and functionality of the methods, embodiments, options, and variants. (Note that this adaptation to the RRC_IDLE state is described more or less explicitly for some of the methods, embodiments, options, and variants described above.)

[0257] In another embodiment, the RAN node releasing the UE with configured QoE measurements requests a core network entity (such as the AMF or MME) to store a container containing QoE-related state information related to the UE, which may then be forwarded to the RAN node in which the UE subsequently performs the RRC setup procedure (i.e., the RAN node controlling the cell in which the UE subsequently transitions to RRC_CONNECTED state).

[0258] The information described earlier in this specification as being transferred from the anchor RAN node to the new RAN node using the RETRIEVE UE CONTEXT RESPONSE XnAP message (e.g., the last known session state at the UE) may also be transferred from the old RAN node to the new RAN node using this mechanism in the case of RRC_IDLE state (and RRC setup procedures), i.e., by being included in a container stored in the core network to be forwarded to subsequent RAN nodes.

[0259] Expansion RRC_INACTIVE or RRC_IDLE state During the period UE is , for later reporting in QoE report(s) and / or RVQoE report(s), Collect QoE metric values ​​and / or other informationIn addition to the usual QoE / RVQoE metrics, the UE can record the time it released from RRC_CONNECTED to RRC_INATIVE or RRC_IDLE state, and the time it re-entered RRC_CONNECTED state (or alternatively, the time spent in RRC_INACTIVE or RRC_IDLE state). This information can be "aggregated" with the QoE metric values ​​in the report in a way that makes it clear which values ​​were collected during which states. Other ways of indicating which states different values ​​were collected are also possible. For example, the report could indicate in which states certain parts of the report were collected, or indicate which states the collected measurements or samples pertain to.

[0260] Other state related information that may be included in the report may include the type of trigger for the state transition from RRC_INACTIVE or RRC_IDLE to RRC_CONNECTED, e.g. UE internal or UE external (e.g. page), and / or in the case of a UE internal trigger, whether the UE internal trigger was application data generation or buffer emptying (in the application session to which the QoE report and / or RVQoE report relates) or another UE internal trigger, and / or in the case of a UE external trigger in the form of a page, whether the page was a RAN page or a core network page.

[0261] While in RRC_INACTIVE state, the UE provides updated session status information to the RAN For details, see e.g. Figure 8. A solution for enabling the anchor RAN node to keep up-to-date information about the session status information of a UE in RRC_INACTIVE state and eventually transfer the correct (latest) session status information to the new RAN node when the UE resumes from RRC_INACTIVE state is for the UE to Remains in RRC_INACTIVE state The aim is to enable the transmission of updated session status information by the small data transmission procedure (i.e., without transitioning to the RRC_CONNECTED state).

[0262] The RAN can configure the UE with triggers to send (update) session status information. The triggers can be any one or any combination of the following: The UE was in RRC_INACTIVE state and a session that was in progress when the UE was released to RRC_INACTIVE was successfully terminated. The UE is in RRC_INACTIVE state and a session that was in progress when the UE was released to RRC_INACTIVE terminates with a failure. The UE is in RRC_INACTIVE state and a new application session is started. The UE was in RRC_INACTIVE state and one or more changes occurred in the status of an application session that was in progress when the UE was released to RRC_INACTIVE. The UE is in RRC_INACTIVE state and one or more changes in the status of new application sessions that were started after the UE was released to RRC_INACTIVE have occurred. The UE reselects a new cell on the anchor RAN node (or a new cell on another RAN node). A timer has expired (e.g. T380) or is running. The amount of data is below the threshold - The amount of SRB4 data is below the threshold.

[0263] Existing SDT procedures can be reused and extended to transmit session status information. For example, if the session status information is treated as SRB data and the UE accesses a gNB other than the last serving gNB (anchor RAN node), the SRB PDCP PDUs can be forwarded between the receiving gNB and the last serving gNB via the XnAP RRC forwarding procedure until the last serving gNB terminates the SDT session and sends an RRCRelease message to return the UE to RRC_INACTIVE.

[0264] In a possible example, the possibility of using SDT for sending updated session status information can be signaled from the RAN to the UE by a specific flag indicating the possibility of using SDT in SRB4 when the UE is released to RRC_INACTIVE, e.g., by a new IE: sdt-SRB4-Indication ENUMERATED {allowed} OPTIONAL " will be introduced.

[0265] At a minimum, the anchor node is provided with updated session status information, but the RAN node contacted for the SDT procedure (if different from the anchor node) does not store such information (there is no guarantee as to which RAN node the UE will eventually resume at, and the session status information is originally stored in the anchor RAN node). However, if the UE context is relocated (as part of the SDT procedure), this information becomes relevant to the RAN node contacted for the SDT procedure, and such node may store the updated session status information as it is received from the UE.

[0266] In a possible solution, the UE may provide updates on session status information to the RAN as part of the RRC resume procedure triggered due to an RNA update (e.g., when the UE moves out of the RNA or due to expiry of the T380 timer for periodic RNA updates).

[0267] 7 illustrates a method according to a particular embodiment, which may be performed by a UE or wireless device (e.g., UE 1112 or UE 1200, described below with reference to FIGS. 11 and 12, respectively).

[0268] The method begins with the UE initially in a connected state (e.g., an RRC state such as RRC_CONNECTED). The UE may be configured with one or more QoE measurement sessions associated with respective application sessions. In step 702, the UE is released to an inactive or idle state (e.g., RRC_INACTIVE or RRC_IDLE).

[0269] While in the inactive or idle state, in step 704, the UE may continue to perform QoE measurements for application sessions that survive a transition to the inactive or idle state. For example, a streaming application may have a buffer of video data that lasts for several minutes. This means that the streaming session may persist for a significant period without communication, which may occur, for example, if the UE is temporarily released into the RRC_INACTIVE state (or the RRC_IDLE state). Additionally or alternatively, changes may occur to one or more QoE measurement sessions during the inactive or idle state. For example, a new QoE measurement session (and associated application session) may be initiated, or a previously ongoing QoE measurement session (and associated application session) may be terminated or aborted.

[0270] In step 706, the UE transitions back to the connected state. For example, the UE may resume a previously suspended connection (i.e., transition from RRC_INACTIVE to RRC_CONNECTED) or establish a new connection (i.e., transition from RRC_IDLE to RRC_CONNECTED). As part of this transition, the UE connects to a first RAN node. Note that the first RAN node may be the same RAN node that the UE was previously connected to (e.g., in step 702) or a different RAN node.

[0271] In step 708, the UE sends information related to one or more QoE measurement sessions configured for the user equipment to the first RAN node.

[0272] The information may be sent to the first RAN node in a connection resume request message (e.g., RRCResumeRequest, RRCResumeRequest1, etc.) or a connection establishment request message (e.g., RRCSetupRequest, RRCConnectionSetup, etc.), or in a message confirming the establishment of a connection with the first RAN node or the resumption of a connection with the first RAN node (e.g., RRCResumeComplete, RRCSetupComplete, etc.), a response message to a request message from the first RAN node (e.g., a UEInformationResponse message to a UEInformationRequest message from the first RAN node), or any other suitable message (e.g., MeasurementReportAppLayer, UEAssistanceInformation, etc.).

[0273] The information related to one or more QoE measurement sessions configured in the user equipment may include the status of the one or more QoE measurement sessions (e.g., in progress, not in progress, finished, etc.). In one embodiment, the information may consist of the status of only ongoing QoE measurement sessions. In such an embodiment, the information may consist of a list of identifiers of the QoE measurement sessions, and the status itself (i.e., "in progress") may be implicit.

[0274] In a further embodiment, the information related to the one or more QoE measurement sessions may include values ​​of one or more parameters (e.g., session state) that have changed since the user equipment transitioned from a connected state to an inactive or idle state in step 702. In this way, the RAN node to which the UE was connected in step 702 can forward information about the QoE measurement session at the time the UE was released to the inactive or idle state. The information from the UE may consist of only the changed parameters, saving radio resources and signaling overhead.

[0275] The information relating to the one or more QoE measurement sessions may additionally or alternatively include one or more of an indication of the time the user equipment was in an inactive or idle state before transitioning to the connected state, and an indication of the time or duration of whether one or more QoE measurement sessions were in progress while the user equipment was in an inactive or idle state.

[0276] Therefore, further information that the UE may provide to the RAN node performing the RRC resume procedure may include an indication of the time that the UE spent in the RRC_INACTIVE state (e.g., shown as a duration or as a timestamp of when the UE was released into the RRC_INACTIVE state).

[0277] The UE can transmit information about whether a session was ongoing during RRC_INACTIVE. As an example, from time a to time b, the UE has an ongoing session, from time be to time c, there is no ongoing session, from time c to time d, there is an ongoing session, etc. As a simplified option, the UE can indicate timestamps corresponding to the instants when sessions started and / or ended during the RRC_INACTIVE state.

[0278] Information relating to the one or more QoE measurement sessions may be transmitted to the first RAN node further in response to one or more of the configuration received from the communications network and the type of event that triggered the user equipment to transition to the connected state.

[0279] For example, a typical trigger for a UE with an active application session to initiate an RRC resume procedure may be the application generating uplink data to be transmitted (e.g., a request to an application server, e.g., a request for streaming data). Another option for the RRC resume procedure may be the application session's buffer becoming empty, dropping below a certain threshold, or showing a decreasing trend. Another option for the trigger may be a paging message from the network. The paging message may be triggered by downlink application data pending transmission to the UE. For a UE in RRC_INACTIVE state, the UE may be paged by RAN paging, and receipt of the page triggers the UE to initiate an RRC resume procedure and transition to the RRC_CONNECTED state. For a UE in RRC_IDLE state (particularly if a future 3GPP release allows the UE to retain QoE configuration in the RRC_IDLE state, which may be relevant in the context of this disclosure), the UE may be paged through CN paging, and receipt of the page triggers the UE to initiate an RRC setup procedure and transition to the RRC_CONNECTED state. Whether and / or what session status information is provided from the UE to the new RAN node may depend on the nature of the trigger for the RRC resume (or RRC setup) procedure.

[0280] In one option, the UE may also provide the network with a QoE-specific reason for initiating RRC resume (eg, reasons such as those mentioned above (UL data to send, buffer exhaustion, etc.)).

[0281] Whether and what type of session status information the UE should provide when resuming a connection with a RAN node (or performing an RRC setup procedure after a period in RRC_IDLE state) can be configured by the network.

[0282] As one option, the RAN node releasing the UE to the RRC_INACTIVE state (or RRC_IDLE state) can indicate in the message releasing the UE to the RRC_INACTIVE state (or RRC_IDLE state), e.g., the RRCRelease message, indications of session status information reporting that the UE may provide to the RAN node where the UE performs a subsequent RRC resume procedure. Such indications may, for example, indicate whether the UE should provide its session status information, if the session status has changed or the session status at the time the UE was released to the RRC_INACTIVE state (or RRC_IDLE state) (e.g., the session status when the UE received the RRCRelease message), and / or the type of information that the UE should provide (only the latest / current session status, or a list of session status indications, and / or additional information such as the duration of the RRC_INACTIVE state (or RRC_IDLE state)).

[0283] As another option, the RAN node at which the UE performs the RRC resume procedure (or RRC setup procedure) may include such an indication in the RRCResume message (or RRCSetup message).

[0284] In another option, the RAN node configures the UE to send session status updates in UEAssistanceInformation messages.

[0285] As yet another option, the RAN node through which the UE performs the RRC Resume procedure (or RRC Setup procedure) may use the UEInformationRequest message to explicitly request the UE to send certain session status information and / or additional information in a UEInformationResponse message (possibly after the UE has indicated the availability of such information in an RRCResumeComplete message (or RRCSetupComplete message)).

[0286] As yet another option, the RAN node through which the UE performs the RRC resume procedure (or RRC setup procedure) may use the RRCReconfigurationRequest message to explicitly request the UE to send certain session status information and / or additional information, for example within a MeasurementReportAppLayer message.

[0287] As yet another option that may complement (e.g., be used in parallel with) any of the above options, if the RRC resume procedure is triggered by a page, the RAN node may include an indication of the above type in the RRC paging message.

[0288] As yet another option, the indication may be indicated in the broadcast system information. If this option is used, in one variant it may be used as a default indication, which may be overridden or supplemented by an indication provided to the UE in any of the ways described above.

[0289] The UE may be configured to send all session status updates, or may be configured to send session status updates upon resuming to RRC_CONNECTED only if the session status has changed since the UE was transferred to RRC_INACTIVE (or RRC_IDLE).

[0290] The indication may be unconditional, but in some variants may depend on one or more conditions. For example, the indication or part of the indication may be conditioned by the type of trigger for the RRC resume procedure (or RRC setup procedure), e.g., the indication depends on whether the trigger is a UE internal trigger or a page.

[0291] In another option, the RAN node may configure the UE to initiate an RRC resume when a session status changes, e.g., when a session starts or ends, and provide the session information accordingly.

[0292] Further conditions may be directed to the case of a UE internal trigger, such that the instruction may depend on whether the UE internal trigger is the generation of application data (of the application having the associated QoE configuration to which the instruction applies) or another UE internal trigger.

[0293] Further conditions may cover when the trigger is a page, for example the instructions may depend on whether the page is a RAN or CN start page.

[0294] In another example, the indication, or part of the indication, may be conditioned on whether the RAN node towards which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as the old RAN node (i.e., the RAN node that released the UE into RRC_INACTIVE state (or RRC_IDLE state)) or a different RAN node. In this example, if the RAN node towards which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as the old RAN node, further conditions may be applicable, such as the indication depending on whether the cell towards which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as the cell from which the UE was released into RRC_INACTIVE state (or RRC_IDLE state) or a different cell.

[0295] In another example, the indication or part of the indication may be conditioned on whether the cell on which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as the cell from which the UE was released to the RRC_INACTIVE state (or RRC_IDLE state), or a different cell. In another example, the indication or part of the indication may be conditioned on the type of state transition procedure (i.e., which state the UE is leaving to enter the RRC_CONNECTED state), for example, the indication may depend on whether the state transition procedure is an RRC resume procedure (causing the UE to transition from the RRC_INACTIVE state to the RRC_CONNECTED state) or an RRC setup procedure (causing the UE to transition from the RRC_IDLE state to the RRC_CONNECTED state).

[0296] 8 illustrates a method according to a particular embodiment, which may be performed by a UE or wireless device (e.g., UE 1112 or UE 1200, described below with reference to FIGS. 11 and 12, respectively).

[0297] The method begins with the UE initially in a connected state (e.g., an RRC state such as RRC_CONNECTED) and connected to a first RAN node. The UE may be configured with one or more QoE measurement sessions associated with respective application sessions. In step 802, the UE is released to an inactive state (e.g., RRC_INACTIVE).

[0298] While in the inactive state, the UE transmits information related to one or more QoE measurement sessions configured in the user equipment to the first RAN node in step 804. The information may be transmitted to the first RAN node by one or more small data transmissions (SDTs).

[0299] The information related to one or more QoE measurement sessions configured in the user equipment may include the status of the one or more QoE measurement sessions (e.g., in progress, not in progress, finished, etc.). In one embodiment, the information may consist of the status of only ongoing QoE measurement sessions. In such an embodiment, the information may consist of a list of identifiers of the QoE measurement sessions, and the status itself (i.e., "in progress") may be implicit.

[0300] In a further embodiment, the information related to the one or more QoE measurement sessions may include values ​​of one or more parameters (e.g., session state) that have changed since the user equipment transitioned from a connected state to an inactive or idle state in step 702. In this way, the RAN node to which the UE was connected in step 702 can forward information about the QoE measurement session at the time the UE was released to the inactive or idle state. The information from the UE may consist of only the changed parameters in order to save radio resources and signaling overhead.

[0301] The information relating to the one or more QoE measurement sessions may additionally or alternatively include one or more of an indication of the time the user equipment was in an inactive or idle state before transitioning to the connected state, and an indication of the time the one or more QoE measurement sessions were or were not in progress while the user equipment was in an inactive or idle state.

[0302] Therefore, further information that the UE may provide to the RAN node performing the RRC resume procedure may include an indication of the time that the UE spent in the RRC_INACTIVE state (e.g., shown as a duration or as a timestamp of when the UE was released into the RRC_INACTIVE state).

[0303] The UE may transmit information about when a session was or was not in progress during RRC_INACTIVE. As an example, from time a to time b, the UE has an ongoing session, from time be to time c, there is no ongoing session, from time c to time d, there is an ongoing session, etc. As a simplified option, the UE may indicate timestamps corresponding to the instants when sessions started and / or ended while in the RRC_INACTIVE state.

[0304] Information related to one or more QoE measurement sessions may be sent in step 804 in response to one or more of the following: a QoE measurement session that was in progress when the user equipment was released to the inactive connection state is successfully terminated, a QoE measurement session that was in progress when the user equipment was released to the inactive connection state is terminated with failure, a new application session is started; one or more changes in the status of an application session that was in progress when the user equipment was released to the inactive connection state, one or more changes in the status of an application session that started after the user equipment was released to the inactive connection state, a timer has expired or is running, the user equipment has reselected a new cell, or the amount of data is below a threshold.

[0305] For example, the first RAN node may set a trigger for the UE to send (updated) session status information. The trigger may be one or any combination: The UE was in RRC_INACTIVE state and a session that was in progress when the UE was released to RRC_INACTIVE was successfully terminated. The UE is in RRC_INACTIVE state and a session that was in progress when the UE was released to RRC_INACTIVE terminates with a failure. The UE is in RRC_INACTIVE state and a new application session is started. The UE was in RRC_INACTIVE state and one or more changes occurred in the status of an application session that was in progress when the UE was released to RRC_INACTIVE. The UE is in RRC_INACTIVE state and one or more changes in the status of new application sessions that were started after the UE was released to RRC_INACTIVE have occurred. The UE reselects a new cell on the anchor RAN node (or a new cell on another RAN node). A timer has expired (e.g. T380) or is running. The amount of data is below the threshold - The amount of SRB4 data is below the threshold.

[0306] Existing SDT procedures can be reused and extended to transmit session status information. For example, if the session status information is treated as SRB data and the UE accesses a gNB other than the last serving gNB (anchor RAN node), the SRB PDCP PDUs can be forwarded between the receiving gNB and the last serving gNB via the XnAP RRC forwarding procedure until the last serving gNB terminates the SDT session and sends an RRCRelease message to return the UE to RRC_INACTIVE.

[0307] The possibility of using SDT to transmit updated session status information may be signaled from the first RAN node to the UE by a specific flag indicating the possibility of using SDT for SRB4 when the UE is released to RRC_INACTIVE (e.g., step 802), e.g., a new IE: sdt-SRB4-Indication ENUMERATED {allowed} OPTIONAL " will be introduced.

[0308] Thus, the anchor (first) RAN node is provided with updated session status information, but the RAN node contacted for the SDT procedure (if different from the anchor node) does not store such information (there is no guarantee as to which RAN node the UE will eventually resume in, and the session status information is originally stored in the anchor RAN node). However, if the UE context is relocated (as part of the SDT procedure), this information becomes relevant to the RAN node contacted for the SDT procedure, and such node may store the updated session status information as received from the UE.

[0309] In a possible solution, the UE may provide updates on session status information to the RAN as part of an RRCResume procedure triggered due to an RNA update (e.g., when the UE moves out of the RNA or due to expiry of the T380 timer for periodic RNA updates).

[0310] Figure 9 illustrates a method according to a particular embodiment, which may be performed by a first network node (e.g., network node 1110 or network node 1300, described below with reference to Figures 11 and 13, respectively). The method of Figure 9 may be read in conjunction with the methods of Figures 7 and 10, which illustrate corresponding steps in a UE and a second RAN node, respectively.

[0311] The method begins in step 902, where a user equipment connects to a first network node and transitions to a connected state, and a first RAN node receives from the UE information related to one or more QoE measurement sessions configured for the user equipment. For example, the UE may resume a previously suspended connection (i.e., transition from RRC_INACTIVE to RRC_CONNECTED) or establish a new connection (i.e., transition from RRC_IDLE to RRC_CONNECTED). As part of this transition, the UE connects to the first RAN node.

[0312] The information may be transmitted to the first RAN node in a connection resume request message (e.g., RRCResumeRequest, RRCResumeRequest1, etc.) or a connection establishment request message (e.g., RRCSetupRequest, RRCConnectionSetup, etc.), or in a message confirming the establishment of a connection with the first RAN node or the resumption of a connection with the first RAN node (e.g., RRCResumeComplete, RRCSetupComplete, etc.), a response message to a request message from the first RAN node (e.g., a UEInformationResponse message in response to a UEInformationRequest message from the first RAN node), or any other suitable message (e.g., MeasurementReportAppLayer, UEAssistanceInformation, etc.).

[0313] The information related to one or more QoE measurement sessions configured in the user equipment may include the status of the one or more QoE measurement sessions (e.g., in progress, not in progress, finished, etc.). In one embodiment, the information may include the status of only ongoing QoE measurement sessions. In such an embodiment, the information may consist of a list of identifiers of the QoE measurement sessions, and the status itself (i.e., "in progress") may be implicit.

[0314] In a further embodiment, the information related to one or more QoE measurement sessions may include values ​​of one or more parameters (e.g., session state) that have changed since the user equipment transitioned from a connected state to an inactive or idle state. In this way, a RAN node to which the UE was previously connected (e.g., before being released to the inactive or idle state) can forward information about the QoE measurement session at the time the UE was released to the inactive or idle state (see step 904 below). The information from the UE may consist only of changed parameters in order to save radio resources and signaling overhead.

[0315] The information relating to the one or more QoE measurement sessions may additionally or alternatively include one or more of an indication of the time the user equipment was in an inactive or idle state before transitioning to the connected state, and an indication of the time the one or more QoE measurement sessions were or were not in progress while the user equipment was in an inactive or idle state.

[0316] Therefore, further information that the UE may provide to the RAN node performing the RRC resume procedure may include an indication of the time that the UE has spent in the RRC_INACTIVE state, e.g., indicated as a duration or as a timestamp of when the UE was released into the RRC_INACTIVE state.

[0317] The UE can transmit information about whether a session was ongoing during RRC_INACTIVE. As an example, from time a to time b, the UE has an ongoing session, from time be to time c, there is no ongoing session, from time c to time d, there is an ongoing session, etc. As a simplified option, the UE can indicate timestamps corresponding to the instants when sessions started and / or ended during the RRC_INACTIVE state.

[0318] Information relating to the one or more QoE measurement sessions may be transmitted to the first RAN node further in response to one or more of the configuration received from the communications network and the type of event that triggered the user equipment to transition to the connected state.

[0319] For example, a typical trigger for a UE with an active application session to initiate an RRC resume procedure may be the application generating uplink data to be transmitted (e.g., a request to an application server, e.g., a request for streaming data). Another option for the RRC resume procedure may be the application session's buffer becoming empty, dropping below a certain threshold, or showing a decreasing trend. Another option for the trigger may be a paging message from the network. The paging message may be triggered by downlink application data pending transmission to the UE. For a UE in RRC_INACTIVE state, the UE may be paged by RAN paging, and receipt of the page triggers the UE to initiate an RRC resume procedure and transition to the RRC_CONNECTED state. For a UE in RRC_IDLE state (particularly if a future 3GPP release allows the UE to retain QoE configuration in the RRC_IDLE state, which may be relevant in the context of this disclosure), the UE may be paged through CN paging, and receipt of the page triggers the UE to initiate an RRC setup procedure and transition to the RRC_CONNECTED state. Whether and / or what session status information is provided from the UE to the new RAN node may depend on the nature of the trigger for the RRC resume (or RRC setup) procedure.

[0320] In one option, the UE may also provide the network with a QoE-specific reason for initiating RRC resume (UL data to send, buffer exhaustion, etc.), for example as described above.

[0321] Whether and what type of session status information the UE should provide when resuming a connection with a RAN node (or performing an RRC setup procedure after a period in RRC_IDLE state) can be configured by the network.

[0322] As one option, the RAN node releasing the UE to the RRC_INACTIVE state (or RRC_IDLE state) can indicate in the message releasing the UE to the RRC_INACTIVE state (or RRC_IDLE state), e.g., the RRCRelease message, indications of session status information reporting that the UE may provide to the RAN node where the UE performs a subsequent RRC resume procedure. Such indications may include, for example, whether the UE should provide its session status information, if the session status has changed or the session status at the time the UE was released to the RRC_INACTIVE state (or RRC_IDLE state) (e.g., the session status when the UE received the RRCRelease message), and / or the type of information that the UE should provide (e.g., only the latest / current session status or a list of session status indications and / or additional information such as the duration of the RRC_INACTIVE state (or RRC_IDLE state)).

[0323] As another option, the RAN node at which the UE performs the RRC resume procedure (or RRC setup procedure) may include such an indication in the RRCResume message (or RRCSetup message).

[0324] In another option, the RAN node configures the UE to send session status updates in UEAssistanceInformation messages.

[0325] As yet another option, the RAN node through which the UE performs the RRC Resume procedure (or RRC Setup procedure) may use the UEInformationRequest message to explicitly request the UE to send certain session status information and / or additional information in a UEInformationResponse message (possibly after the UE has indicated the availability of such information in an RRCResumeComplete message (or RRCSetupComplete message)).

[0326] As yet another option, the RAN node through which the UE performs the RRC resume procedure (or RRC setup procedure) may use the RRCReconfigurationRequest message to explicitly request the UE to send certain session status information and / or additional information, for example within a MeasurementReportAppLayer message.

[0327] As yet another option that may complement (e.g., be used in parallel with) any of the above options, if the RRC resume procedure is triggered by a page, the RAN node may include an indication of the above type in the RRC paging message.

[0328] As yet another option, the indication may be indicated in the broadcast system information. If this option is used, in one variant it may be used as a default indication, which may be overridden or supplemented by an indication provided to the UE in any of the ways described above.

[0329] The UE can be configured to send all session status updates, or it can be configured to send session status updates upon resuming to RRC_CONNECTED only if the session status has changed since the UE was transferred to RRC_INACTIVE (or RRC_IDLE).

[0330] The indication may be unconditional, but in some variants may depend on one or more conditions. For example, the indication or part of the indication may be conditioned by the type of trigger for the RRC resume procedure (or RRC setup procedure), e.g., the indication depends on whether the trigger is a UE internal trigger or a page.

[0331] In another option, the RAN node may configure the UE to initiate an RRC resume when a session status changes, e.g., when a session starts or ends, and provide the session information accordingly.

[0332] Further conditions may be directed to the case of a UE internal trigger, for example the command may depend on whether the UE internal trigger is the generation of application data (of the application having an associated QoE configuration to which the command applies) or another UE internal trigger.

[0333] Further conditions may cover when the trigger is a page, for example the instructions may depend on whether the page is a RAN initiated page or a CN initiated page.

[0334] In another example, the indication, or part of the indication, may be conditioned on whether the RAN node towards which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as the old RAN node (i.e., the RAN node that released the UE into RRC_INACTIVE state (or RRC_IDLE state)) or a different RAN node. In this example, if the RAN node towards which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as the old RAN node, further conditions may be applicable, such as the indication depending on whether the cell towards which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as the cell from which the UE was released into RRC_INACTIVE state (or RRC_IDLE state) or a different cell.

[0335] In another example, the indication or part of the indication may be conditioned on whether the cell on which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as the cell on which the UE was released to the RRC_INACTIVE state (or RRC_IDLE state) or a different cell.

[0336] In another example, the indication or part of the indication may be conditioned on the type of state transition procedure (i.e., which state the UE is leaving to enter the RRC_CONNECTED state), for example, the indication may depend on whether the state transition procedure is an RRC Resume procedure (causing the UE to transition from the RRC_INACTIVE state to the RRC_CONNECTED state) or an RRC Setup procedure (causing the UE to transition from the RRC_IDLE state to the RRC_CONNECTED state).

[0337] In step 904, which may be in addition to or instead of step 902, when the user equipment connects to a first network node and transitions to a connected state, the first RAN node receives information related to one or more Quality of Experience (QoE) measurement sessions configured in the user equipment from a second network node of the communication network. The second RAN node may be the RAN node to which the UE was previously connected (e.g., when released to an inactive or idle state). It should be noted that if the first RAN node is the same RAN node to which the UE was previously connected (e.g., when released to an inactive or idle state), step 902 does not apply.

[0338] The information provided by the second RAN node may include any and all of the information defined above with respect to step 902. However, it should be noted that the values ​​of the parameters included in the information may correspond to the values ​​at the time the UE transitioned to the idle or inactive state.

[0339] The information provided by the UE may be more up-to-date than the information provided by the second RAN node (e.g., taking into account changes to the information while the UE was in an inactive or idle state). Thus, in step 906, the first RAN node overwrites the values ​​of one or more parameters in the information provided by the second RAN node with the values ​​of the corresponding parameters provided by the UE. (Note that steps 902 and 904 may occur in any order.)

[0340] Therefore, when a UE in RRC_INACTIVE state initiates an RRC resume procedure towards a new first RAN node (e.g., gNB or eNB), the anchor (second) RAN node (e.g., gNB or eNB) may transfer the session in progress / not in progress status that was valid when the UE was released to RRC_INACTIVE state, but this information may be outdated and inaccurate. Therefore, this information may optionally be excluded from the UE context information transferred from the anchor RAN node to the new RAN node where the UE resumes its RRC connection (e.g., in a RETRIEVE UE CONTEXT RESPONSE XnAP message), or alternatively, it may be included in the UE context transferred from the anchor RAN node to the new RAN node, in which case it will be overwritten by the information sent by the UE. As a further option, the session status (ongoing / not ongoing status) that was valid when the UE was released into the RRC_INACTIVE state is included in the UE context information transferred from the anchor RAN node to the new RAN node to which the UE resumes the RRC connection (e.g. in a RETRIEVE UE CONTEXT RESPONSE XnAP message), and the UE sends overriding session status information to the new RAN node only if it differs from the session status information sent from the anchor RAN node to the new RAN node (i.e. if the UE's session status information differs from that when the UE was released into the RRC_INACTIVE state).

[0341] It should be noted that although the solution embodiments described herein refer to the case where the UE performs an RRC resume procedure (or an RRC setup procedure) towards a RAN node other than the RAN node that released the UE into the RRC_INACTIVE state (or the RRC_IDLE state), the solution embodiments are also applicable to the case where the UE performs an RRC resume procedure (or an RRC setup procedure) towards the same RAN node that released the UE into the RRC_INACTIVE state (or the RRC_IDLE state), and the cell where the UE performs the RRC resume procedure (or the RRC setup procedure) may be the same as the cell where the UE was released into the RRC_INACTIVE state (or the RRC_IDLE state).

[0342] If the UE is dual-attached and the SN configures the UE for QoE measurements, the SN is the node with knowledge of the session status. In this case, the SN informs the MN of the session status, which the MN can then inform the new RAN node upon RRC resume of RRC connection establishment. To do this, the SN can use either the existing DC-related XnAP procedure (with possible extensions) or a newly defined procedure.

[0343] Figure 10 illustrates a method according to a particular embodiment, which may be performed by a second network node (e.g., network node 1110 or network node 1300, described below with reference to Figures 11 and 13, respectively). The method of Figure 10 may be read in conjunction with the methods of Figures 7 and 9, which define corresponding steps in the UE and the first RAN node, respectively.

[0344] The method begins with the UE initially in a connected state (e.g., an RRC state such as RRC_CONNECTED) and connected to a second RAN node. The UE may be configured with one or more QoE measurement sessions associated with respective application sessions. In step 1002, the UE is released to an inactive or idle state (e.g., RRC_INACTIVE or RRC_IDLE).

[0345] In step 1004, when the user equipment connects to the first RAN node and transitions to the connected state, the second network node transmits information related to one or more QoE measurement sessions configured in the user equipment to the first RAN node. For example, the UE may resume a previously suspended connection (i.e., transition from RRC_INACTIVE to RRC_CONNECTED) or establish a new connection (i.e., transition from RRC_IDLE to RRC_CONNECTED). As part of this transition, the UE connects to the first RAN node.

[0346] The information related to the one or more QoE measurement sessions may include information related to the one or more QoE measurement sessions at the time the UE was released to an inactive or idle state. Alternatively, the second RAN node may receive information from the UE while the UE was in an inactive state (e.g., see Figure 8 above). In this case, the information provided to the first RAN node may correspond to information updated while the UE was in an inactive state.

[0347] The information related to one or more QoE measurement sessions configured in the user equipment may include the status of the one or more QoE measurement sessions (e.g., in progress, not in progress, finished, etc.). In one embodiment, the information may consist of the status of only ongoing QoE measurement sessions. In such an embodiment, the information may consist of a list of identifiers of the QoE measurement sessions, and the status itself (i.e., "in progress") may be implicit.

[0348] The information relating to the one or more QoE measurement sessions may additionally or alternatively include one or more of an indication of the time the user equipment was in an inactive or idle state before transitioning to the connected state, and an indication of the time or duration of whether one or more QoE measurement sessions were in progress while the user equipment was in an inactive or idle state.

[0349] Therefore, further information that may be provided to the first RAN node may include an indication of the time that the UE spent in the RRC_INACTIVE state, e.g., indicated as a duration or as a timestamp of when the UE was released into the RRC_INACTIVE state.

[0350] The second RAN node may send information whether a session was ongoing during RRC_INACTIVE. As an example, from time a to time b, the UE had a session ongoing, from time be to time c, no session was ongoing, from time c to time d, a session was ongoing, etc. As a simplified option, the second RAN node may indicate timestamps corresponding to the instants at which sessions started and / or ended during the RRC_INACTIVE state.

[0351] The second RAN node may configure the UE as to the circumstances under which the UE should transmit information related to one or more QoE measurement sessions to the first RAN node (e.g., triggers for transmitting information, type of information to be transmitted, etc.).

[0352] For example, a typical trigger for a UE with an active application session to initiate an RRC resume procedure may be the application generating uplink data to be transmitted (e.g., a request to an application server, e.g., a request for streaming data). Another option for the RRC resume procedure may be the application session's buffer becoming empty, dropping below a certain threshold, or showing a decreasing trend. Another option for the trigger may be a paging message from the network. The paging message may be triggered by downlink application data pending transmission to the UE. For a UE in RRC_INACTIVE state, the UE may be paged by RAN paging, and receipt of the page triggers the UE to initiate an RRC resume procedure and transition to the RRC_CONNECTED state. For a UE in RRC_IDLE state (particularly if a future 3GPP release allows the UE to retain QoE configuration in the RRC_IDLE state, which may be relevant in the context of this disclosure), the UE may be paged through CN paging, and receipt of the page triggers the UE to initiate an RRC setup procedure and transition to the RRC_CONNECTED state. Whether and / or what session status information is provided from the UE to the new RAN node may depend on the nature of the trigger for the RRC resume (or RRC setup) procedure.

[0353] In one option, the UE may also provide the network with a QoE-specific reason for initiating RRC resume (eg, reasons such as those mentioned above (UL data to send, buffer exhaustion, etc.)).

[0354] Whether and what type of session status information the UE should provide when resuming a connection with a RAN node (or performing an RRC setup procedure after a period in RRC_IDLE state) can be configured by the network.

[0355] As one option, the second RAN node that releases the UE to the RRC_INACTIVE state (or RRC_IDLE state) in step 1002 can indicate in the message releasing the UE to the RRC_INACTIVE state (or RRC_IDLE state), e.g., the RRCRelease message, indications of session status information reporting that the UE may provide to the RAN node at which the UE performs a subsequent RRC resume procedure. Such indications may indicate, for example, whether the UE should provide its session status information, whether it should provide it only if the session status has changed or if it differs from the session status at the time the UE was released to the RRC_INACTIVE state (or RRC_IDLE state) (e.g., the session status when the UE received the RRCRelease message), and / or the type of information that the UE should provide (only the latest / current session status or a list of session status indications and / or additional information such as the duration of the RRC_INACTIVE state (or RRC_IDLE state)).

[0356] As yet another option, the indication may be indicated in the broadcast system information. If this option is used, in one variant it is used as a default indication, which may be overridden or supplemented by an indication provided to the UE in any of the ways described above.

[0357] The UE may be configured to send all session status updates, or may be configured to send session status updates upon resuming to RRC_CONNECTED only if the session status has changed since the UE was transferred to RRC_INACTIVE (or RRC_IDLE).

[0358] The indication may be unconditional, but in some variants may depend on one or more conditions. For example, the indication or part of the indication may be conditioned by the type of trigger for the RRC resume procedure (or RRC setup procedure), e.g., the indication depends on whether the trigger is a UE internal trigger or a page.

[0359] In another option, the second RAN node may configure the UE to initiate an RRC resume when a session status changes, e.g., when a session starts or ends, and provide the session information accordingly.

[0360] Further conditions may be directed to the case of a UE internal trigger, such that the instruction may depend on whether the UE internal trigger is the generation of application data (of the application having the associated QoE configuration to which the instruction applies) or another UE internal trigger.

[0361] Further conditions may cover when the trigger is a page, for example the instructions may depend on whether the page is a RAN initiated page or a CN initiated page.

[0362] In another example, the indication, or part of the indication, may be conditioned on whether the first RAN node is the same as the second RAN node or a different RAN node. In this example, a possible further condition may cover the case where the RAN node towards which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as the old RAN node, e.g., the indication may depend on whether the cell towards which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as the cell from which the UE was released to RRC_INACTIVE state (or RRC_IDLE state) or a different cell.

[0363] In another example, the indication or part of the indication may be conditioned on whether the cell on which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as the cell on which the UE was released to the RRC_INACTIVE state (or RRC_IDLE state) or a different cell.

[0364] In another example, the indication or part of the indication may be conditioned on the type of state transition procedure (i.e., which state the UE is leaving to enter the RRC_CONNECTED state), for example, the indication may depend on whether the state transition procedure is an RRC Resume procedure (causing the UE to transition from the RRC_INACTIVE state to the RRC_CONNECTED state) or an RRC Setup procedure (causing the UE to transition from the RRC_IDLE state to the RRC_CONNECTED state).

[0365] FIG. 11 illustrates an example of a communication system 1100 according to some embodiments.

[0366] In this example, the communications system 1100 includes a telecommunications network 1102 including an access network 1104, such as a radio access network (RAN), and a core network 1106 including one or more core network nodes 1108. The access network 1104 includes one or more access network nodes, such as network nodes 1110a and 1110b (one or more of which may be referred to generically as network nodes 1110), or any other similar Third Generation Partnership Project (3GPP) access nodes or non-3GPP access points. The network nodes 1110 facilitate direct or indirect connectivity of user equipment (UEs), such as by connecting UEs 1112a, 1112b, 1112c, and 1112d (one or more of which may be referred to generically as UEs 1112), to the core network 1106 via one or more wireless connections.

[0367] Exemplary wireless communication via wireless connections includes transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Additionally, in different embodiments, communication system 1100 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. Communication system 1100 may include and / or interface with any type of communication, telecommunication, data, cellular, wireless network, and / or other similar type systems.

[0368] The plurality of UEs 1112 may be any of a wide variety of communication devices, including wireless devices that are positioned, configured, and / or operable to wirelessly communicate with the network node 1110 and other communication devices. Similarly, the network node 1110 is positioned, enabled, configured, and / or operable to communicate, directly or indirectly, with the UEs 1112 and / or with other network nodes or equipment within the telecommunications network 1102, 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 1102.

[0369] In the depicted example, the core network 1106 connects the network node 1110 to one or more hosts, such as the host 1116. These connections may be made directly or indirectly through one or more intermediate networks or devices. In other examples, the network nodes may be directly coupled to the hosts. The core network 1106 includes one or more core network nodes (e.g., the core network node 1108) 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 the descriptions are generally applicable to the corresponding components of the core network node 1108. Exemplary core network nodes include one or more of the following functions: a Mobile Switching Center (MSC), a Mobility Management Entity (MME), a Home Subscriber Server (HSS), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Subscriber Identification Deconcealing 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).

[0370] The host 1116 may be owned or under the control of, and operated by, or on behalf of, a service provider other than the operator or provider of the access network 1104 and / or the telecommunications network 1102. The host 1116 may host various applications to provide one or more services. Examples of such applications include providing live and / or pre-recorded audio / video content, data collection services (e.g., acquiring and compiling data about various ambient conditions detected by multiple UEs), analytics functions, social media, functions to control or otherwise interact with remote devices, alarm and monitoring center functions, or other such functions performed by a server.

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

[0372] In some examples, the telecommunications network 1102 is a cellular network that implements 3GPP standardized features. Thus, the telecommunications network 1102 can support network slicing to provide different logical networks to different devices connected to the telecommunications network 1102. For example, the telecommunications network 1102 can 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-Based Communications (mMTC) / Massive IoT services to additional UEs.

[0373] In some examples, the UE 1112 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 1104 on a predetermined schedule, when triggered by an internal or external event, or in response to a request from the access network 1104. Furthermore, the UE may be configured to operate in a single or multi-RAT or multi-standard mode. For example, the UE may be configured and operate for any one or a combination of Wi-Fi, NR (New Radio), and LTE, i.e., Multi-Radio Dual Connectivity (MR-DC), such as E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) New Radio-Dual Connectivity (EN-DC).

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

[0375] The hub 1114 may have a constant / persistent or intermittent connection to the network node 1110b. The hub 1114 may also enable different communication schemes and / or schedules between the hub 1114 and UEs (e.g., UEs 1112c and / or 1112d) and between the hub 1114 and the core network 1106. In other examples, the hub 1114 is connected to the core network 1106 and / or one or more UEs via a wired connection. Additionally, the hub 1114 may be configured to connect to an M2M service provider via the access network 1104 and / or to another UE via a direct connection. In some scenarios, a UE can establish a wireless connection with the network node 1110b while remaining connected through the hub 1114 via a wired or wireless connection. In some embodiments, the hub 1114 may be a dedicated hub, i.e., a hub whose primary function is to route communications to and from UEs to and from the network node 1110b. In other embodiments, the hub 1114 may be a non-dedicated hub, i.e., a device that is operable to route communications between the UE and the network node 1110b, but that is additionally operable as a communication start point and / or communication end point for a particular data channel.

[0376] Figure 12 illustrates a UE 1200 according to some embodiments. As used herein, a UE refers to a device 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 cellular phone, a voice-over-IP (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless camera, a gaming console or device, a music storage device, a playback appliance, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop embedded device (LEE), a laptop embedded device (LME), a smart device, a wireless customer premises equipment (CPE), an in-vehicle or in-vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrowband Internet of Things (NB-IoT) UE, a machine-type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0377] 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-anything (V2X). In other examples, a UE does not necessarily have a user in the sense of a human user who owns and / or operates the associated device. Instead, a UE may represent a device that is intended for sale to or operation by a human user, but that is not, or may not initially be, associated with a particular human user (e.g., a smart sprinkler control device). Alternatively, a UE may represent a device that is not intended for sale to or operation by an end user, but that may be associated with or operated for the user's benefit (e.g., a smart electricity meter).

[0378] The UE 1200 includes a processing circuit 1202 operably coupled to an input / output interface 1206, a power source 1208, a memory 1210, a communication interface 1212, and / or any other components, or any combination thereof, via a bus 1204. A particular UE may utilize all or a subset of the components shown in FIG. 12. The level of integration between components may vary from UE to UE. Additionally, a particular UE may include multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0379] The processing circuit 1202 is configured to process instructions and data and may be configured to implement any sequential state machine operable to execute instructions stored in the memory 1210 as a machine-readable computer program. The processing circuit 1202 may be implemented as one or more hardware-implemented state machines (e.g., 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 1202 may include multiple central processing units (CPUs). The processing circuit 1202, alone or in combination with other UE 1200 components, such as the memory 1210, may be operable to provide functionality of the UE 1200. For example, the processing circuit 1202 may be configured to cause the UE 1202 to perform methods such as those described with reference to FIG. 7 and / or FIG. 8.

[0380] In this embodiment, the input / output interface 1206 may be configured to provide an input device, an output device, or an interface to 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. The input device may enable a user to capture information into the UE 1200. Examples of input devices include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a webcam, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smart card, etc. The presence-sensitive display may include a capacitive touch sensor or a 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 magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. The output device may use the same type of interface port as the input device. For example, a Universal Serial Bus (USB) port can be used to provide input and output devices.

[0381] In some embodiments, the power source 1208 is configured as a battery or battery pack. Other types of power sources may be used, such as an external power source (e.g., an electrical outlet), a photovoltaic device, or a power cell. The power source 1208 may further include power circuitry for supplying power to various portions of the UE 1200 from the power source 1208 itself and / or from an external power source via an interface, such as an input circuit or a power cable. The supply of power may be for charging the power source 1208, for example. The power circuitry may perform any formatting, conversion, or other modification of the power from the power source 1208 to make it suitable for the respective components of the UE 1200 being powered.

[0382] The memory 1210 is or is configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disk, optical disk, hard disk, removable cartridge, flash drive, etc. In one example, the memory 1210 includes one or more application programs 1214, such as an operating system, a web browser application, a widget, a gadget engine, or other applications, and corresponding data 1216. The memory 1210 can store any of a variety of operating systems or combinations of operating systems for use by the UE 1200.

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

[0384] The processing circuit 1202 may be configured to communicate with an access network or other networks using a communication interface 1212. The communication interface 1212 may include one or more communication subsystems and may include or be communicatively coupled to an antenna 1222. The communication interface 1212 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 1218 and / or a receiver 1220 suitable for providing network communication (e.g., optical, electrical, frequency allocation, etc.). Furthermore, the transmitter 1218 and receiver 1220 may be coupled to one or more antennas (e.g., antenna 1222) and may share circuit components, software, or firmware or may be implemented separately.

[0385] In some embodiments, the communication capabilities of communication interface 1212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication such as Bluetooth®, short-range communication, location-based communication such as using the Global Positioning System (GPS) to determine location, another similar communication capability, or any combination thereof. Communication may be performed in accordance with one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, Transmission Control Protocol / Internet Protocol (TCP / IP), Synchronous Optical Networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), etc.

[0386] Regardless of the type of sensor, the UE can provide an output of data captured by its sensor via its communication interface 1212 over a wireless connection to a network node. Data captured by a UE's sensor may be communicated over a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes when reporting sensed temperature), random (e.g., to balance the load of reporting from multiple sensors), in response to a trigger event (e.g., an alert is sent when moisture is detected), in response to a request (e.g., a user-initiated request), or a continuous stream (e.g., a live video feed of the patient).

[0387] 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 configure a motor to adjust a control surface or rotor of a drone in flight in response to the received input, or control a robotic arm to perform a medical procedure in response to the received input.

[0388] When the UE is in the form of an Internet of Things (IoT) device, it may be a device for use in one or more application areas, including, but not limited to, urban wearable technology, augmented industrial applications, and healthcare. Non-limiting examples of such IoT devices include devices or equipment such as connected refrigerators or freezers, televisions, connected lighting devices, power meters, robot vacuums, voice-controlled smart speakers, home security cameras, motion sensors, 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, augmented reality (AR) or virtual reality (VR) head-mounted displays, haptic or sensory augmentation wearables, water sprinklers, animal or item tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and medical equipment of any kind, such as heart rate monitors and remote surgical robots. A UE in the form of an IoT device may comprise circuitry and / or software depending on the intended use of the IoT device, in addition to other components such as those described in relation to UE 1200 shown in FIG. 12.

[0389] 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 the results of such monitoring and / or measurements to another UE and / or network node. In this case, the UE may be an M2M device, which may be referred to as an MTC device in the 3GPP context. As a specific 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 that can monitor and / or report its operating status or other functions related to its operation.

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

[0391] 13 illustrates a network node 1300 according to some embodiments. As used herein, a network node refers to a device in a telecommunications network that is configured, arranged, and / or operable to communicate, directly or indirectly, with UEs and / or other network nodes or devices. Examples of network nodes include, but are not limited to, access points (APs) (e.g., wireless access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs), and NR Node Bs (gNBs)).

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

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

[0394] The network node 1300 includes a processing circuit 1302, a memory 1304, a communication interface 1306, and a power source 1308, and / or any other components, or any combination thereof. The network node 1300 may be comprised of multiple physically separate components (e.g., a NodeB component and an RNC component, or a BTS component and a BSC component, etc.), each of which may have its own components. In certain scenarios where the network node 1300 is comprised of multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among multiple network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair may, in some cases, be considered a single separate network node. In some embodiments, the network node 1300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may overlap (e.g., separate memories 1304 for different RATs) and some components may be reused (e.g., the same antenna 1310 may be shared by different RATs). Network node 1300 may also include multiple sets of the various illustrated components for different wireless technologies, e.g., GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, RFID (radio frequency identification), or Bluetooth wireless technologies, integrated into network node 1300. These wireless technologies may be integrated into the same or different chips or chipsets and other components within network node 1300.

[0395] The processing circuitry 1302 is comprised of one or more combinations of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and / or coded logic, and is operable, alone or in combination with other network node 1300 components, such as memory 1304, to provide the functionality of the network node 1300. By way of example, the processing circuitry 1302 may be configured to cause the network node to perform methods such as those described with reference to Figure 9 and / or Figure 10.

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

[0397] The memory 1304 may be comprised of any form of volatile or non-volatile computer-readable memory, including, but not limited to, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard 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 devices that store information, data, and / or instructions that may be used by the processing circuit 1302. The memory 1304 may store any suitable instructions, data, or information, including applications that include one or more of computer programs, software, logic, rules, code, tables, and / or other instructions, that may be executed by the processing circuit 1302 and utilized by the network node 1300. The memory 1304 may be used to store any calculations performed by the processing circuit 1302 and / or any data received via the communication interface 1306. In some embodiments, the processing circuit 1302 and the memory 1304 are integrated.

[0398] The communication interface 1306 is used for wired or wireless communication of signaling and / or data between network nodes, access networks, and / or UEs. As shown, the communication interface 1306 comprises port(s) / terminal(s) 1316, for example, for transmitting and receiving data to and from a network via a wired connection. The communication interface 1306 also includes radio front-end circuitry 1318, which may be coupled to an antenna 1310 or, in particular embodiments, may be part of the antenna 1310. The radio front-end circuitry 1318 is comprised of a filter 1320 and an amplifier 1322. The radio front-end circuitry 1318 may be connected to the antenna 1310 and the processing circuit 1302. The radio front-end circuitry may be configured to condition signals communicated between the antenna 1310 and the processing circuit 1302. The radio front-end circuitry 1318 may receive digital data to be transmitted to other network nodes or UEs via a wireless connection. The radio front-end circuitry 1318 may convert the digital data into a radio signal having appropriate channel and bandwidth parameters using a combination of filters 1320 and / or amplifiers 1322. The radio signal may then be transmitted via the antenna 1310. Similarly, when receiving data, the antenna 1310 may collect a radio signal that is converted into digital data by the radio front-end circuitry 1318. The digital data may be passed to the processing circuitry 1302. In other embodiments, the communication interface may be composed of different components and / or different combinations of components.

[0399] In certain alternative embodiments, the network node 1300 does not include a separate radio front-end circuit 1318; instead, the processing circuit 1302 includes the radio front-end circuitry and is connected to the antenna 1310. Similarly, in some embodiments, all or a portion of the RF transceiver circuitry 1312 is part of the communications interface 1306. In still other embodiments, the communications interface 1306 includes one or more ports or terminals 1316, the radio front-end circuitry 1318, and the RF transceiver circuitry 1312 as part of a radio unit (not shown), and the communications interface 1306 communicates with baseband processing circuitry 1314 that is part of a digital unit (not shown).

[0400] The antenna 1310 may include one or more antennas or an antenna array configured to transmit and / or receive wireless signals. The antenna 1310 may be coupled to a radio front-end circuit 1318 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 1310 is separate from the network node 1300 and connectable to the network node 1300 via an interface or port.

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

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

[0403] Embodiments of network node 1300 may include additional components other than those shown in Figure 13 to provide particular aspects of the network node's functionality, including any functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, network node 1300 may include user interface devices to enable input of information into network node 1300 and output of information from network node 1300, thereby enabling a user to perform diagnostic, maintenance, repair, and other management functions on network node 1300.

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

[0405] Host 1400 includes a processing circuit 1402 operably coupled via a bus 1404 to an input / output interface 1406, a network interface 1408, a power supply 1410, and memory 1412. In other embodiments, other components may be included. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as Figures 12 and 13, such that the descriptions are generally applicable to the corresponding components of host 1400.

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

[0407] FIG. 15 is a block diagram illustrating a virtualization environment 1500 in which functionality implemented by some embodiments may be virtualized. As used herein, virtualization refers to creating a virtual version of an apparatus or device, which may include virtualizing a hardware platform, storage devices, and networking resources. As used herein, virtualization may apply to any apparatus or component thereof described herein and refers to implementations in which at least a portion of functionality is implemented as one or more virtual components. Some or all of the functionality described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1500 hosted by one or more hardware nodes, such as a network node, a UE, a core network node, or a hardware computing device acting as a host. Furthermore, in embodiments in which the virtualized node does not require wireless connectivity (e.g., a core network node or a host), the node may be fully virtualized.

[0408] An application 1502 (which may alternatively be referred to as a software instance, a virtual appliance, a network function, a virtual node, a virtual network function, etc.) executes in the virtualized environment Q400 to implement certain features, functions, and / or advantages of the embodiments disclosed herein.

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

[0410] A VM 1508 may consist of virtual processing, virtual memory, virtual networking or interfaces, and virtual storage and may be executed by a corresponding virtualization layer 1506. Different embodiments of an instance of a virtual appliance 1502 may be implemented on one or more of the VMs 1508, and the implementation may be done in different ways. Hardware virtualization is referred to in some contexts as network functions virtualization (NFV). NFV may be used to consolidate many types of network equipment onto industry-standard high-volume server hardware, physical switches, physical storage, and customer premises equipment that may be located in a data center.

[0411] In the context of NFV, a VM 1508 may be a software implementation of a physical machine that executes programs as if they were running on a physical, non-virtualized machine. Each VM 1508 and that portion of the hardware 1504 on which it runs (the hardware dedicated to that VM and / or the hardware that that VM shares with other VMs) form a separate virtual network element. Still in the context of NFV, a virtual network function runs in one or more VMs 1508 on top of the hardware 1504 and is responsible for handling specific network functions corresponding to applications 1502.

[0412] The hardware 1504 may be implemented in a standalone network node with general-purpose or specific components. The hardware 1504 may implement some functions through virtualization. Alternatively, the hardware 1504 may be part of a larger cluster of hardware (e.g., in a data center or CPE) where many hardware nodes cooperate and are managed through a management and orchestration 1510 that oversees, among other things, the lifecycle management of the application 1502. In some embodiments, the hardware 1504 includes one or more transmitters and one or more receivers, each of which may be coupled to one or more antennas. The radio unit 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 a virtual node with radio functionality, such as a radio access node or base station. In some embodiments, some signaling may be provided using a control system 1512, which may alternatively be used for communication between the hardware nodes and the radio unit.

[0413] 16 illustrates a communication diagram of a host 1602 communicating with a UE 1606 via a network node 1604 over a partial wireless connection, in accordance with some embodiments. Exemplary implementations of the UE (such as the UE 1112a of FIG. 11 and / or the UE 1200 of FIG. 12), network node (such as the network node 1110a of FIG. 11 and / or the network node 1300 of FIG. 13), and host (such as the host 1116 of FIG. 11 and / or the host 1400 of FIG. 14) discussed in the previous paragraph, in accordance with various embodiments, will now be described with reference to FIG.

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

[0415] The network node 1604 includes hardware that enables it to communicate with the host 1602 and the UE 1606. The connection 1660 may be direct or may pass through a core network (such as the core network 1106 of FIG. 11) and / or one or more other intermediate networks (such as one or more public, private, or hosted networks). For example, the intermediate network may be a backbone network or the Internet.

[0416] The UE 1606 includes hardware and software that is stored on or accessible by the UE 1606 and executable by the UE's processing circuitry. The software may include a client application, such as a web browser or an operator-specific "app," operable to provide services to a human or non-human user via the UE 1606 with the support of the host 1602. Host applications running on the host 1602 can communicate with client applications running on the UE 1606 via an OTT connection 1650 that terminates at the UE 1606 and the host 1602. In providing services 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 1650 may transport both the request data and user data. The client application on the UE may interact with the user to generate user data to provide to the host application via the OTT connection 1650.

[0417] The OTT connection 1650 may extend via a connection 1660 between the host 1602 and a network node 1604 and via a wireless connection 1670 between the network node 1604 and the UE 1606 to provide connectivity between the host 1602 and the UE 1606. The connections 1660 and wireless connections 1670 over which the OTT connection 1650 may be provided are depicted abstractly to illustrate communication between the host 1602 and the UE 1606 via the network node 1604, without explicit reference to any intermediary devices and the precise routing of messages through these devices.

[0418] As an example of transmitting data over the OTT connection 1650, in step 1608, the host 1602 provides user data that may be executed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE 1606. In other embodiments, the user data is associated with a UE 1606 that shares data with the host 1602 without explicit human interaction. In step 1610, the host 1602 initiates a transmission carrying user data toward the UE 1606. The host 1602 may initiate the transmission in response to a request sent by the UE 1606. The request may be triggered by human interaction with the UE 1606 or by the operation of a client application running on the UE 1606. The transmission may be via the network node 1604, in accordance with the teachings of the embodiments described throughout this disclosure. Thus, in step 1612, the network node 1604 transmits the user data carried in the transmission initiated by the host 1602 to the UE 1606, in accordance with the teachings of the embodiments described throughout this disclosure. At step 1614 , the UE 1606 receives the user data carried in the transmission, which may be executed by a client application running on the UE 1606 associated with the host application executed by the host 1602 .

[0419] In some examples, the UE 1606 executes a client application that provides user data to the host 1602. The user data may be provided as a reaction or response to data received from the host 1602. Thus, in step 1616, the UE 1606 may provide the user data, which may be executed 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 1606. Regardless of the particular manner in which the user data is provided, in step 1618, the UE 1606 initiates transmission of the user data toward the host 1602 via the network node 1604. In step 1620, the network node 1604 receives the user data from the UE 1606 and initiates transmission of the received user data toward the host 1602, in accordance with the teachings of embodiments described throughout this disclosure. In step 1622, the host 1602 receives the user data carried in the transmission initiated by the UE 1606.

[0420] One or more of the various embodiments improve the performance of the OTT service provided to the UE 1606 using the OTT connection 1650, of which the wireless connection 1670 forms the final segment. More precisely, the teachings of these embodiments may improve the data rate, latency, power consumption, etc. of the UE and / or network node, thereby providing benefits such as reduced user latency, relaxed file size limitations, improved content resolution, improved responsiveness, and extended battery life.

[0421] In an exemplary scenario, factory status information may be collected and analyzed by the host 1602. As another example, the host 1602 may process audio and video data that may have been obtained from UEs for use in creating maps. As another example, the host 1602 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic signals). As another example, the host 1602 may store surveillance video uploaded by UEs. As another example, the host 1602 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 other examples, the host 1602 may be used for energy pricing, remote control of non-timed electrical loads to balance power generation needs, location-based services, presentation services (e.g., compiling diagrams, etc. from data collected from remote devices), or any other function of collecting, retrieving, storing, analyzing, and / or transmitting data.

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

[0423] While the computing devices (e.g., UEs, network nodes, hosts) described herein may include combinations of the illustrated hardware components, other embodiments may include computing devices having different combinations of components. It should be understood that these computing devices may be comprised of any suitable combination of hardware and / or software necessary 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 in a network node, and / or performing one or more operations based on the obtained or transformed information, and making a decision as a result of said processing. Furthermore, while components are depicted as single boxes arranged within larger boxes or boxes nested within multiple boxes, in reality, a computing device may be comprised of multiple different physical components that make up a single illustrated component, and functionality may be divided 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 a component may be divided between a processing circuit and a communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware, while computationally intensive functions may be implemented in hardware.

[0424] In particular embodiments, some or all of the functionality described herein may be provided by a processing circuit executing instructions stored in a memory, which in particular embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by a 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 particular embodiments, the processing circuit may be configured to perform the described functionality regardless of whether 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 to other components of the computing device, but are enjoyed by the computing device as a whole and / or by end users and wireless networks in general.

[0425] For the avoidance of doubt, the following numbered statements refer to embodiments of the present disclosure: Group A Embodiments 1. A method performed by a user device, the method comprising: When you transition to the connected state: connecting to a first Radio Access Network (RAN) node of a communications network; transmitting information related to one or more Quality of Experience (QoE) measurement sessions configured in the user equipment to the communications network; A method comprising: 2. The one or more QoE measurement sessions are configured in the user equipment by the first RAN node or a second RAN node of the communication network. 2. The method of embodiment 1. 3. The one or more QoE measurement sessions are configured in the user equipment during a previous instance of the user equipment being in the connected state. 3. The method of embodiment 1 or 2. 4. The information relating to one or more QoE measurement sessions includes values ​​of one or more parameters that have changed since the user equipment transitioned from the previous instance in the connected state to an inactive or idle state. 4. The method of embodiment 3. 5. The transition to the connected state includes either resuming a connection from an inactive state or establishing a connection from an idle state. 10. The method of any one of the preceding embodiments. 6. The information related to one or more QoE measurement sessions configured in the user equipment includes a status of the one or more QoE measurement sessions. 10. The method of any one of the preceding embodiments. 7. The status of the QoE measurement session includes one of: in progress, not in progress, or completed. 7. The method of embodiment 6. 8. The information related to one or more QoE measurement sessions configured in the user equipment includes one or more of: an indication of the time the user equipment was in an inactive or idle state before transitioning to the connected state; and an indication of the time or times when one or more QoE measurement sessions were or were not in progress while the user equipment was in an inactive or idle state. 10. The method of any one of the preceding embodiments. 9. The information related to one or more QoE measurement sessions configured in the user equipment includes information of one or more ongoing QoE measurement sessions. 10. The method of any one of the preceding embodiments. 10. The information relating to one or more QoE measurement sessions is sent to the first RAN node in a connection resume request message or a connection establishment request message. 10. The method of any one of the preceding embodiments. 11. The information relating to one or more QoE measurement sessions is transmitted to the first RAN node in a message confirming the establishment of a connection with the first RAN node or the resumption of a connection with the first RAN node. The method according to any one of embodiments 1 to 9. 12. The information relating to one or more QoE measurement sessions is transmitted to the first RAN node in a response to a request message received from the first RAN node. The method according to any one of embodiments 1 to 9. 13. The information relating to one or more QoE measurement sessions is transmitted to the first RAN node further in response to one or more of a configuration received from the communications network and a type of event that triggered the user equipment to transition to the connected state. 10. The method of any one of the preceding embodiments. 14. A method performed by a user device, the method comprising: While in an inactive connection state: transmitting information related to one or more Quality of Experience (QoE) measurement sessions configured in the user equipment to a first Radio Access Network (RAN) node of a communications network. method. 15. The information relating to one or more QoE measurement sessions is transmitted to the first RAN node by one or more small data transmissions. 15. The method of embodiment 14. 16. The information related to one or more QoE measurement sessions configured in the user equipment includes a status of the one or more QoE measurement sessions. 16. The method of embodiment 14 or 15. 17. The status of the QoE measurement session includes one of: in progress, not in progress, or completed. 17. The method of embodiment 16. 18. The user equipment is released to the inactive connection state by the first RAN node. 18. The method according to any one of embodiments 14 to 17. 19. The information related to one or more QoE measurement sessions is sent in response to one or more of: a QoE measurement session that was in progress when the user equipment was released to the inactive connection state being completed successfully; a QoE measurement session that was in progress when the user equipment was released to the inactive connection state being completed unsuccessfully; a new application session being started; one or more changes in the status of an application session that was in progress when the user equipment was released to the inactive connection state; one or more changes in the status of an application session that was started after the user equipment was released to the inactive connection state; a timer expiring or running; the user equipment reselecting a new cell; or an amount of data being below a threshold. 19. The method of any one of embodiments 14 to 18. 20. Providing User Data and forwarding the user data to a host via the transmission to the network node; Also includes 10. The method of any one of the preceding embodiments. Group B Embodiments 21. A method performed by a first network node of a communications network, the method comprising: When the user equipment connects to the first network node and transitions to a connected state: receiving, from one or more of the user equipment and a second network node of the communication network, information related to one or more Quality of Experience (QoE) measurement sessions configured at the user equipment; method. 22. The one or more QoE measurement sessions are configured in the user equipment by the first network node or the second network node of the communication network. 22. The method of embodiment 21. 23. The one or more QoE measurement sessions are configured in the user equipment during a previous instance of the user equipment being in the connected state. 23. The method of embodiment 21 or 22. 24. The information relating to one or more QoE measurement sessions is received from the user equipment and includes values ​​of one or more parameters that have changed since the user equipment transitioned from the previous instance in the connected state to an inactive state or an idle state. 24. The method of embodiment 23. 25. The information relating to one or more QoE measurement sessions is received from the user equipment and the second network node, and the information received from the second network node is overwritten by the information received from the user equipment. 25. The method of embodiment 24. 26. The user equipment transitioning to the connected state includes either resuming a connection from an inactive state or establishing a connection from an idle state. 26. The method of any one of embodiments 21 to 25. 27. The information related to one or more QoE measurement sessions configured in the user equipment includes a status of the one or more QoE measurement sessions. 27. The method of any one of embodiments 21 to 26. 28. The status of the QoE measurement session includes one of: in progress, not in progress, or completed. 28. The method of embodiment 27. 29. The information related to one or more QoE measurement sessions configured in the user equipment includes one or more of: an indication of the time the user equipment was in an inactive or idle state before transitioning to the connected state; and an indication of the time or times when one or more QoE measurement sessions were or were not in progress while the user equipment was in an inactive or idle state. 29. The method of any one of embodiments 21 to 28. 30. The information related to one or more QoE measurement sessions configured in the user equipment includes information on one or more ongoing QoE measurement sessions. 30. The method of any one of embodiments 21 to 29. 31. The information relating to one or more QoE measurement sessions is received from the user equipment in a connection resume request message or a connection establishment request message. 31. The method of any one of embodiments 21 to 30. 32. The information relating to one or more QoE measurement sessions is received from the user equipment in a message confirming establishment of a connection with the first network node or resumption of a connection with the first network node. 31. The method of any one of embodiments 21 to 30. 33. The information relating to one or more QoE measurement sessions is received from the user equipment in a response to a request message sent by the first network node to the user equipment. 31. The method of any one of embodiments 21 to 30. 34. The information relating to one or more QoE measurement sessions is received from the user equipment further in response to one or more of: a configuration of the user equipment by the communication network; and a type of event that triggered the user equipment to transition to the connected state. 34. The method of any one of embodiments 21 to 33. 35. A method performed by a second network node, the second network node serving a user equipment that has been released to an inactive or idle connection state, the method comprising: transmitting information related to one or more Quality of Experience (QoE) measurement sessions configured in the user equipment to a first network node to which the user equipment subsequently connects after transitioning to a connected state. method. 36. The information related to one or more QoE measurement sessions configured in the user equipment includes a status of the one or more QoE measurement sessions. 36. The method of embodiment 35. 37. The status of the QoE measurement session includes one of: in progress, not in progress, or completed. 37. The method of embodiment 36. 38. The information related to one or more QoE measurement sessions configured in the user equipment comprises one or more of: an indication of the time the user equipment was in an inactive or idle state before transitioning to the connected state; an indication of the time the user equipment was released to an inactive or idle connected state; an indication of the final values ​​of one or more QoE parameters reported to the second network node before the user equipment was released to the inactive or idle connected state; an indication of the time or times when one or more QoE measurement sessions were or were not in progress while the user equipment was in an inactive or idle state. 38. The method according to any one of embodiments 35 to 37. 39. The information related to one or more QoE measurement sessions configured in the user equipment includes information on one or more ongoing QoE measurement sessions. 39. The method of any one of embodiments 35 to 38. 40. Collecting user data; transferring said user data to a host or user device; Also includes 10. The method of any one of the preceding embodiments. Group C Embodiments 41. A user device, comprising: processing circuitry configured to cause the user device to perform any of the steps of any of the embodiments of Group A; a power supply circuit configured to provide power to the processing circuit; A user device comprising: 42. A network node, comprising: processing circuitry configured to cause the network node to perform any of the steps of any of the Group B embodiments; a power circuit configured to provide power to the processing circuit; A network node comprising: 43. A user equipment (UE), the UE comprising: an antenna configured to transmit and receive wireless signals; a radio front-end circuit connected to the antenna and processing circuit and configured to condition signals communicated between the antenna and the processing circuit; the processing circuitry configured to perform any of the steps of any of the embodiments of Group A; an input interface connected to the processing circuitry and configured to allow information to be input to the UE to be processed by the processing circuitry; an output interface connected to the processing circuit and configured to output information processed by the processing circuit from the UE; a battery connected to the processing circuit and configured to power the UE; UE equipped with. 44. A host configured to operate to provide over-the-top (OTT) services in a communications system, comprising: processing circuitry configured to provide user data; a network interface configured to initiate transmission of the user data to a cellular network for transmission to a user equipment (UE); Equipped with The UE includes a communication interface and a processing circuit, and the communication interface and processing circuit of the UE are configured to perform any of the steps of any of the embodiments of Group A to receive the user data from the host. host. 45. The cellular network further comprises a network node configured to communicate with the UE to transmit the user data from the host to the UE. The host of any of the preceding embodiments. 46. ​​The host's processing circuitry is configured to execute a host application, whereby the user data is provided; The host application is configured to interact with a client application running on the UE, the client application being associated with the host application. The host of the two preceding embodiments. 47. 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 to the UE; Initiating transmission of user data to a UE via a cellular network including a network node, wherein the UE performs any of the operations of any of the embodiments in Group A to receive the user data from a host; A method comprising: 48. Further including, at the host, executing a host application associated with the client application running on the UE to receive user data from the UE. 10. The method of any preceding embodiment. 49. Further comprising: at the host, sending input data to a client application running on the UE, the input data being provided by running the host application; User data is provided by the client application in response to input data from the host application. 10. The method of any preceding embodiment. 50. 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; a network interface configured to initiate transmission of user data to a cellular network for transmission to a user equipment (UE); Equipped with The UE includes a communication interface and processing circuitry, the communication interface and processing circuitry of the UE configured to perform any of the steps of any of the embodiments of Group A to transmit user data to the host. host. 51. The cellular network further includes a network node configured to communicate with the UE to transmit user data from the UE to the host. The host of any of the preceding embodiments. 52. The processing circuitry of the host is configured to execute a host application, whereby user data is provided; The host application is configured to interact with a client application running on the UE, the client application being associated with the host application. The host of the two preceding embodiments. 53. A method implemented by a host configured to operate in a communication system further including a network node and a user equipment (UE), the method comprising: receiving, at the host, user data transmitted by the UE via the network node to the host, wherein the UE performs any of the steps of any of the embodiments of Group A to transmit the user data to the host; method. 54. Further including, at the host, executing a host application associated with the client application running on the UE to receive user data from the UE. 10. The method of any preceding embodiment. 55. Further comprising: at the host, sending input data to a client application running on the UE, the input data being provided by running the host application; User data is provided by the client application in response to input data from the host application. 10. The method of any preceding embodiment. 56. A host configured to operate in a communications system to provide over-the-top (OTT) services, comprising: a processing circuit configured to provide user data; A network interface configured to initiate transmission of user data to a network node of a cellular network for transmission to a user equipment (UE), the network node having a communications interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of any of the Group B embodiments to transmit the user data from a host to the UE. host. 57. The processing circuitry of the host is configured to execute a host application that provides user data; The UE comprises processing circuitry configured to execute a client application associated with the host application to receive user data transmissions from the host. The host of any of the preceding embodiments. 58. A method implemented in a host configured to operate in a communication system further including a network node and a user equipment (UE), comprising: Providing user data for the UE; initiating a transmission carrying user data to the UE via a cellular network including a network node, the network node performing any of the operations of any of the Group B embodiments to transmit the user data from the host to the UE; A method comprising: 59. At the network node, further comprising transmitting user data provided by the host to the UE. 10. The method of any preceding embodiment. 60. User data is provided at the host by executing a host application that interacts with a client application running on the UE, the client application being associated with the host application. The method of either of the previous two embodiments. 61. A communication system configured to provide over-the-top services, the communication system comprising: A host, a processing circuit configured to provide user data to a user equipment (UE), the user data being associated with an over-the-top service; a network interface configured to initiate transmission of user data towards a cellular network node for transmission to the UE, the network node comprising a communications interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of any of the Group B embodiments to transmit the user data from the host to the UE; Equipped with Communication system. 62. Network nodes; and / or User Device Further equipped The communication system of any preceding embodiment. 63. 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; a network interface configured to receive user data from a network node of a cellular network, the network node having a communications interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of any of the Group B embodiments to receive the user data from a user equipment (UE); and A host. 64. The processing circuitry of the host is configured to execute a host application, whereby user data is provided; The host application is configured to interact with a client application running on the UE, the client application being associated with the host application. The host of any of the preceding embodiments. 65. Initiating receipt of user data includes requesting the user data. The host of either of the two preceding embodiments. 66. A method implemented by a host configured to operate in a communication system further including a network node and a user equipment (UE), comprising: Initiating, 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, the network node performing any of the steps of any of the Group B embodiments to receive the user data from the UE for the host. method. 67. At the network node, further comprising transmitting the received user data to the host. 10. The method of any preceding embodiment.

Claims

1. A method performed by a user device (1200), the method comprising: When you transition to the connected state: Connecting (706) to a first Radio Access Network (RAN) node of a communications network; transmitting (708) information related to one or more Quality of Experience (QoE) measurement sessions configured in the user equipment (1200) to the communications network; Including, The one or more QoE measurement sessions are configured in the user equipment (1200) during a previous instance of the user equipment (1200) being in the connected state. method.

2. The one or more QoE measurement sessions are configured in the user equipment (1200) by the first RAN node or a second RAN node of the communication network. The method of claim 1.

3. The information relating to one or more QoE measurement sessions includes values ​​of one or more parameters that have changed since the user equipment (1200) transitioned from the previous instance in the connected state to an inactive or idle state. The method according to claim 1 or 2.

4. The transition to the connected state includes either resuming a connection from an inactive state or establishing a connection from an idle state.

4. The method according to any one of claims 1 to 3.

5. The information related to one or more QoE measurement sessions configured in the user equipment (1200) includes a status of the one or more QoE measurement sessions.

5. The method according to any one of claims 1 to 4.

6. The status of the QoE measurement session includes one of: in progress, not in progress, or finished. The method of claim 5.

7. The information related to one or more QoE measurement sessions configured in the user equipment (1200) includes one or more of: an indication of the time the user equipment (1200) was in an inactive or idle state before transitioning to the connected state; and an indication of the time or duration when one or more QoE measurement sessions were or were not in progress while the user equipment (1200) was in an inactive or idle state.

7. The method according to any one of claims 1 to 6.

8. The information related to one or more QoE measurement sessions configured in the user equipment (1200) includes information of one or more ongoing QoE measurement sessions.

8. The method according to any one of claims 1 to 7.

9. said information relating to one or more QoE measurement sessions, In a connection resume request message or a connection establishment request message, in a message confirming the establishment of a connection with the first RAN node or the resumption of a connection with the first RAN node; or in a response to the request message received from the first RAN node, transmitted to the first RAN node.

9. The method according to any one of claims 1 to 8.

10. The information related to one or more QoE measurement sessions is transmitted to the first RAN node further in response to one or more of a configuration received from the communication network and a type of trigger for transitioning the user equipment (1200) from an inactive or idle state to the connected state.

10. The method according to any one of claims 1 to 9.

11. A method performed by a user device (1200), the method comprising: While in an inactive connection state: transmitting (804) information related to one or more Quality of Experience (QoE) measurement sessions configured in the user equipment to a first Radio Access Network (RAN) node of a communications network. method.

12. The information relating to one or more QoE measurement sessions is transmitted to the first RAN node by one or more small data transmissions. The method of claim 11.

13. The information related to one or more QoE measurement sessions configured in the user equipment (1200) includes a status of the one or more QoE measurement sessions.

13. The method of claim 11 or 12.

14. The status of the QoE measurement session includes one of: in progress, not in progress, or finished. The method of claim 13.

15. The user equipment (1200) is released into the inactive connection state by the first RAN node.

15. The method according to any one of claims 11 to 14.

16. The information related to one or more QoE measurement sessions is transmitted in response to one or more of the following: a QoE measurement session that was in progress when the user equipment (1200) was released to the inactive connection state is successfully terminated; a QoE measurement session that was in progress when the user equipment (1200) was released to the inactive connection state is unsuccessfully terminated; a new application session is started; one or more changes in the status of an application session that was in progress when the user equipment (1200) was released to the inactive connection state; one or more changes in the status of an application session that was started after the user equipment (1200) was released to the inactive connection state; a timer expiring or running; the user equipment (1200) reselecting a new cell; or an amount of data being below a threshold.

16. The method according to any one of claims 11 to 15.

17. 1. A method performed by a first network node of a communications network, the method comprising: When the user equipment (1200) connects to the first network node and transitions to a connected state: receiving (902, 904) from one or more of the user equipment (1200) and a second network node of the communication network information related to one or more Quality of Experience (QoE) measurement sessions configured in the user equipment (1200), wherein the one or more QoE measurement sessions were configured in the user equipment (1200) during a previous instance of the user equipment (1200) in the connected state; method.

18. The one or more QoE measurement sessions are configured in the user equipment (1200) by the first network node or the second network node of the communication network.

18. The method of claim 17.

19. The information relating to one or more QoE measurement sessions is received from the user equipment (1200) and includes values ​​of one or more parameters that have changed since the user equipment (1200) transitioned from the previous instance in the connected state to an inactive state or an idle state.

19. The method of claim 17 or 18.

20. The information relating to one or more QoE measurement sessions is received from the user equipment (1200) and the second network node, and the information received from the second network node is overwritten by the information received from the user equipment (1200).

20. The method of claim 19.

21. The user device (1200) transitioning to the connected state includes either resuming a connection from an inactive state or establishing a connection from an idle state.

21. The method of any one of claims 17 to 20.

22. The information related to one or more QoE measurement sessions configured in the user equipment (1200) includes a status of the one or more QoE measurement sessions.

22. The method of any one of claims 17 to 21.

23. The status of the QoE measurement session includes one of: in progress, not in progress, or finished.

23. The method of claim 22.

24. The information related to one or more QoE measurement sessions configured in the user equipment (1200) includes one or more of: an indication of the time the user equipment (1200) was in an inactive or idle state before transitioning to the connected state; and an indication of the time or duration when one or more QoE measurement sessions were or were not in progress while the user equipment (1200) was in an inactive or idle state.

24. The method of any one of claims 17 to 23.

25. The information related to one or more QoE measurement sessions configured in the user equipment (1200) includes information of one or more ongoing QoE measurement sessions.

25. The method of any one of claims 17 to 24.

26. said information relating to one or more QoE measurement sessions, In a connection resume request message or a connection establishment request message, in a message confirming the establishment of a connection with the first network node or the resumption of a connection with the first network node; or In response to a request message sent by the first network node to the user equipment (1200), Received from the user device (1200) 26. The method of any one of claims 17 to 25.

27. The information relating to one or more QoE measurement sessions is received from the user equipment (1200) further in response to one or more of: a configuration of the user equipment (1200) by the communication network; and a type of trigger for transitioning the user equipment (1200) from an inactive or idle state to the connected state.

27. The method of any one of claims 17 to 26.

28. A method performed by a second network node, the second network node serving a user equipment (1200) that has been released to an inactive or idle connection state, the method comprising: and transmitting (1004) information related to one or more Quality of Experience (QoE) measurement sessions configured in the user equipment (1200) to a first network node to which the user equipment (1200) has subsequently connected after transitioning to a connected state. method.

29. The information related to one or more QoE measurement sessions configured in the user equipment (1200) includes a status of the one or more QoE measurement sessions.

29. The method of claim 28.

30. The status of the QoE measurement session includes one of: in progress, not in progress, or finished.

30. The method of claim 29.

31. The information related to one or more QoE measurement sessions configured in the user equipment (1200) includes one or more of the following: an indication of the time the user equipment (1200) was in an inactive or idle state before transitioning to the connected state; an indication of the time the user equipment (1200) was released to an inactive or idle connected state; an indication of the final values ​​of one or more QoE parameters reported to the second network node before the user equipment (1200) was released to the inactive or idle connected state; an indication of the time or times when one or more QoE measurement sessions were or were not in progress while the user equipment (1200) was in an inactive or idle state.

31. The method of any one of claims 28 to 30.

32. The information related to one or more QoE measurement sessions configured in the user equipment (1200) includes information of one or more ongoing QoE measurement sessions.

32. The method of any one of claims 28 to 31.

33. A user device (1200), When transitioning to the connected state, the user device (1200) connecting (706) to a first radio access network (RAN) node of a communications network; causing the communication network to transmit (708) information related to one or more Quality of Experience (QoE) measurement sessions configured in the user equipment (1200), the one or more QoE measurement sessions being configured in the user equipment (1200) during a previous instance of the user equipment (1200) in the connected state; A processing circuit (1202) configured as described above; a power supply circuit configured to provide power to the processing circuit; A user device comprising:

34. The processing circuit (1202) is further configured to cause the user device (1200) to perform a method according to any one of claims 2 to 10.

34. The user device (1200) of claim 33.

35. A user device (1200), While in an inactive connection state, the user device (1200) a processing circuit (1202) configured to cause information related to one or more Quality of Experience (QoE) measurement sessions configured in the user equipment to be transmitted (804) to a first Radio Access Network (RAN) node of a communication network; a power supply circuit configured to provide power to the processing circuit; A user device comprising:

36. The processing circuitry is further configured to cause the UE (1100) to perform a method according to any one of claims 13 to 17.

31. The user device (1200) of claim 30.

37. A first network node, the first network node comprising: When the user equipment (1200) connects to the first network node and transitions to a connected state, the network node a processing circuit configured to receive, from one or more of the user equipment (1200) and a second network node of the communication network, information related to one or more Quality of Experience (QoE) measurement sessions configured in the user equipment (1200), wherein the one or more QoE measurement sessions were configured in the user equipment (1200) during a previous instance of the user equipment (1200) in the connected state; a power supply circuit configured to provide power to the processing circuit; A first network node comprising:

38. The processing circuitry is further configured to cause the first network node to perform a method according to any one of claims 18 to 27.

38. The first network node of claim 37.

39. a second network node serving a user equipment (1200) that has been released to an inactive or idle connection state, said second network node comprising: a processing circuit configured to cause the user equipment (1200) to transmit (1004) information related to one or more Quality of Experience (QoE) measurement sessions configured in the user equipment (1200) to a first network node to which the user equipment (1200) subsequently connects after transitioning to a connected state; a power supply circuit configured to provide power to the processing circuit; A second network node comprising:

40. The processing circuitry is further configured to cause the second network node to perform a method according to any one of claims 29 to 32.

40. The second network node of claim 39.

Images