Methods, apparatus, and computer-readable media related to perceived quality 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

[0002] , , ,

[0003] , "Normal" QoE , , Overview of the QoE Framework ,

[0001] Embodiments of the present disclosure relate to methods, apparatuses, and computer-readable media related to communication networks, and particularly to haptic quality information in communication networks.

Background Art

[0002] Overview of the QoE Framework "Normal" QoE Haptic quality of experience (QoE) measurements, also referred to as "application layer measurements", are defined for Long Term Evolution (LTE) and Universal Mobile Telecommunications System (UMTS), and are defined for New Radio (NR) in the 3rd Generation Partnership Project (3GPP (registered trademark)) Release 17. The purpose of application layer measurements is to measure the end-user experience when using a specific application. Currently, QoE measurements for streaming services and Internet Protocol (IP) Multimedia Subsystem (IMS) (MTSI) services for mobility telephony services are supported. In NR, at least Virtual Reality (VR) is likely to be added to the list of services for which QoE measurements are defined and supported.

[0003] The LTE and UMTS solutions are similar in their overall principles: QMC (Quality of Experience Measurement Collection) enables the configuration of application layer measurements within the user equipment (UE) and the transmission of QoE measurement result files (commonly referred to as QoE reports) to the network via Radio Resource Control (RRC) signals. The application layer measurement configuration (also called QoE measurement configuration or QoE configuration) received by the Radio Access Network (RAN) from the Operations Management and Maintenance (OAM) system or the Core Network (CN) is encapsulated in a transparent container and forwarded to the UE in a downlink RRC message. The application layer measurement report (also called QoE report) received by the UE's access layer (UE_AS) or the UE's RRC layer from the UE's upper layer (application layer) is encapsulated in a transparent container and forwarded to the network in an uplink RRC message. The RAN then forwards the QoE report to the Measurement Collection Entity (MCE).

[0004] 3GPP Release 17 approved and completed a new research project for NR, "Study on QoE Management and Optimization for Diverse Services." Specification work for 3GPP Release 17 is still ongoing. The purpose of this study project is to explore solutions for QoE measurement in NR. QoE management in NR will not only collect perceived quality parameters for streaming services but also consider typical performance requirements for diverse services (such as Augmented Reality (AR) / VR and Ultra-High Reliability Low Latency Communication (URLLC)) (of which at least VR is expected to be covered in 3GPP Release 17). Based on service requirements, NR research will also include more adaptive QoE management schemes that enable network optimization to satisfy the user experience of diverse services.

[0005] Configuration data related to QoE measurements (usually called application layer measurements in the standard specification) consists of a service type instruction, an instruction for the area in which the measurement will be performed (called the area scope), the IP address of the entity to which the collected measurement results (i.e., QoE reports) should be sent (often called the MCE, but also referred to as the measurement collector entity or measurement collection entity, which is sometimes called the trace collection entity), and a set of instructions regarding the types of measurements to be performed and details of how these measurements will be performed. These instructions are for the application layer of the UE and, as with the access layer of the UE, are placed in a "container" that cannot be interpreted or read by the network entities that process it, such as forwarding it to the UE. Currently defined service types are MTSI and Streaming Services (DASH), with the addition of service type VR in 3GPP Release 17, and QoE measurements for multicast and broadcast services (MBS) are planned to be defined in 3GPP Release 18. The area scope is defined by cells or network-related areas. In UMTS, the area scope is defined as either a list of cells, a list of routing areas, or a list of tracking areas. In LTE, the area scope is defined as either 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, particularly QoE configurations: management-based QoE configurations and signaling-based QoE configurations. In both cases, the QoE configuration originates from an OAM system or other management entity (e.g., one dealing with customer satisfaction). All of these entities are referred to as the OAM system in this document (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 node that controls the cells within the area scope. Each RAN node then selects UEs within the area scope (and also meets other relevant conditions, such as support for the relevant application / service type) 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 measurement results from a specific UE. The OAM system sends the s-based QoE configuration to the Home Subscriber Server (HSS) (for EPS / LTE) or Unified Data Management (UDM) (for 5GS / NR), which forwards the QoE configuration to the UE's current Core Network Node (CN), such as the Mobility Management Entity (MME) for EPS / LTE or the Access and Mobility Management Function (AMF) for 5G / NR. The CN then forwards the s-based QoE configuration to the RAN node that provides services to the UE, which then forwards it to the UE.

[0008] What is forwarded to the UE is a container containing a service type instruction and measurement instructions. 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 (consisting 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 included in the container along with the measurement instructions and is also sent to the RAN (gNB in ​​NR). 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 the measConfigAppLayerId and the QoE reference). The measConfigAppLayerId is stored in the UE's access layer and is transmitted in AT commands (a type of instruction used for communication between the UE's modem and application layer) along with a container containing service type instructions and measurement instructions.

[0009] The 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 forwarded from the RAN to the MCE. These QoE measurements are stored in a "container" and cannot be interpreted by the UE access layer or RAN. QoE reports can be configured to be sent periodically or only at the end of an application session. Furthermore, the RAN can instruct the UE to pause QoE reporting, for example, if the cell / gNB is overloaded.

[0010] The RAN is unaware of when application sessions with associated QoE measurement sessions are in progress, and the UE's access layer does not automatically recognize this either. To mitigate this, session start / stop instructions are introduced, sent from the UE's application layer to UE_AS and from UE_AS to RAN. Session stop instructions can be explicit or implicit, in the form of a QoE report sent when the application session and its associated QoE measurement session have ended.

[0011] RAN can decide at any time, as an implementation-based decision, to release the UE's QoE settings. This is typically done when the UE moves outside the area set up for QoE measurement, and as mentioned earlier, this is commonly referred to as area scope.

[0012] One opportunity offered by legacy solutions is the ability to maintain the overall QoE measurement of a session even during a handover. It is also being considered to allow the UE to continue measuring the QoE of the ongoing application session until the application session ends, even if the UE moves outside its defined area scope during that time.

[0013] RAN Visible QoE (RVQoE) An extension to the QoE framework, considered in 3GPP Release 17, is the concept of RAN-Visible QoE (RVQoE), which is now defined in 3GPP. Normal QoE reporting targets the MCE, which is an entity outside the RAN, such as part of an OAM system. In contrast, reported RVQoE metrics are directed towards the RAN and delivered to the RAN in a format that the RAN understands. RVQoE metrics are derived from normal QoE metrics, collected and compiled into reports by the UE application layer, and delivered to the RAN. For example, if 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 UE scheduling and data flow associated with the application session, while the application session is in progress.

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

[0015] QoE measurement in legacy systems QoE measurement in the UMTS Terrestrial Wireless Access Network (UTRAN) UTRAN - Application Layer Measurement Function According to 3GPP TS25.331, UTRAN can inform the UE (using the UECapabilityEnquiryRRC message) that Figure 1 As shown, UTRAN can request capability reports from the UE.

[0016] In response to this, UE said, Figure 2 As shown, information about the UE capability can be provided using the UE capability information RRC message.

[0017] The 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 contained in the UECapabilityInformation message. The relevant definitions are cited from the following 3GPP TS25.331 version 16.1.0.

[0018] UE Capability Information message: TIFF0007854567000001.tif111170TIFF0007854567000002.tif150170

[0019] "UE radio access capability" IE: TIFF0007854567000003.tif87170TIFF0007854567000004.tif42170

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

[0021] UTRAN-QoE measurement configuration - RRC signaling To configure QoE measurement in the UE, the UTRAN can send a measurement control RRC message containing the "Application layer measurement configuration" IE. Figure 3 shows the normal measurement control procedure in the UTRAN. doing . The relevant definitions are copied from the following 3GPP TS25.331 version 16.1.0.

[0022] Measurement Control message: TIFF0007854567000006.tif117170

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

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

[0025] The UE can also perform a Cell Update to indicate that application layer measurement reporting is available within the UE.

[0026] SRB4 is used for the measurement report message that includes the "Application layer measurement reporting" IE.

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

[0028] Measurement Report message: TIFF0007854567000008.tif86170

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

[0030] Cell Update message: TIFF0007854567000010.tif186170

[0031] "Cell update cause" IE: TIFF0007854567000011.tif18170TIFF0007854567000012.tif230170

[0032] QoE measurement in evolved UTRAN (E-UTRAN) E-UTRAN - Application Layer Measurement Function In E-UTRAN, UE capability transfer is used to transfer UE radio access capability information from the UE to E-UTRAN. (See diagram) 5 This shows the UE capability transfer procedure involving E-UTRAN. doing .

[0033] UE-EUTRA-CapabilityIE is used to communicate E-UTRA UE Radio Access Capability Parameters and Feature Group Indicators for required functions to the network.

[0034] In the response message "UECapabilityInformation," the UE may include the "UE-EUTRA-Capability" IE. The "UE-EUTRA-Capability" IE may include the "UE-EUTRA-Capability-v1530-IEs" IE, which 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 UE-EUTRA-CapabilityIE is shown below (most of the ASN.1 code in the UE-EUTRA-CapabilityIE 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] TIFF0007854567000013.tif101170TIFF0007854567000014.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 measurement. This is notified in measConfigAppLayer-r15IE within OtherConfigIE.

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

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

[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] TIFF0007854567000015.tif100170

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

[0116] The UE must do the following:

[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 measConfigAppLayerContainer to the upper layer;

[0123] 3> It is assumed that the application layer measurement report is configured to be sent in accordance with 5.6.19;

[0124] 2> Otherwise

[0125] 3> Notify the upper layer to clear the saved measurement configuration of the application layer;

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

[0127] 3> It is assumed that the application layer is not configured to send measurement reports.

[0128] E-UTRAN Application Layer Measurement Report The purpose of the "Application layer measurement reporting" procedure described in 3GPP TS36.331 version 16.6.0 and shown below is to transfer application layer measurement reports to E-UTRAN, which can then transfer those reports to the O&M system (e.g., measurement acquisition entity (MCE) or trace acquisition entity (TCE)). [Diagram] 6 This shows the measurement report for the application layer in E-UTRAN. doing .

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

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

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

[0132] 2> Set the measReportAppLayerContainer of 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 the ASN.1 code (including the associated field description), 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] TIFF0007854567000016.tif69170

[0159] UE Application Layer Measurement Configuration In a 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) as defined in 3GPP TS36.413 version 16.7.0.

[0160] The "UE Application layer measurement configuration" IE defines the configuration information for the QoEMeasurementCollection (QMC) function. This is described in section 9.2.1.128 of 3GPP TS36.413 version 16.7.0 as follows (note that this IE is included in Trace ActivationIE, and among the other parameters is Trace Collection Entity IP AddressIE): TIFF0007854567000017.tif78170TIFF0007854567000018.tif240170TIFF0007854567000019.tif113170TIFF0007854567000020.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 / routing / location areas where QMC is performed. If this parameter is not present, QMC is performed across the entire Public Ground Mobile Network (PLMN) specified by PLMNtarget.

[0162] The area scope parameter for UMTS is one of the following: - A list of cells identified by a Cell Global ID (CGI). Up to 32 CGIs can be defined. - A list of routing areas identified by a Routing Area ID (RAI). Up to 8 RAIs can be defined. - A list of location areas identified by a Location Area ID (LAI). Up to 8 LAIs can be defined.

[0163] The area scope parameter in LTE is one of the following: -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 8 TACs can be defined.

[0164] For NR, the area scope parameter will be one of the following: - List of cells - A list of tracking areas.

[0165] This parameter is required 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 conserve energy compared to when the UE is in the RRC_CONNECTED state.

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

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

[0169] The purpose of the RRC_INACTIVE state is to reduce signaling overhead on the radio and network interfaces, improving UE access latency (compared to the RRC_IDLE state) and UE energy consumption. In this state, the core network (CN) still considers the UE to be connected, the RRC connection between the gNB and the UE is interrupted, 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 signaling on the radio interface when the connection is established, the UE's context information is retained in the UE and the anchor gNB, allowing the UE to resume the RRC connection if the UE is paged or has uplink (UL) data or signaling to send. If the CN has user or control data to send to the UE, that data is sent to the anchor gNB, which then initiates paging of the UE (also known as RAN start paging).

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

[0171] The gNB uses the RRCRelease message to consolidate the RNA of the UE when releasing it from the RRC_CONNECTED state to the RRC_INACTIVE state. There are three different options for consolidating the RNA of the UE: - 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. - A list of RAN areas. The UE is provided with a list of (one or more) RAN area IDs. The RAN area ID is a combination of the RAN area code (RANAC), the tracking area code, and the PLMN_ID (i.e., the RANAC is unique within the tracking area). For RNA configuration to work using the list of RAN areas, all cells must broadcast the RAN area code (optionally, this code can be omitted if the network does not use RAN area-based RNA configuration). A RAN area consists of a subset (or all) of cells in a single tracking area. - A list of tracking areas. The UE is provided with a list of one or more tracking area IDs, which are a combination of the tracking area code (TAC) and the PLMN_ID.

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

[0173] RAN can use any of the above configuration options when constructing RNA for a UE, and can use different configuration methods at different times for the same UE as well as for different UEs, but it cannot simultaneously mix different configuration options with the same RNA configuration for a given UE.

[0174] During RNA updates (or other contacts between the UE and the network), the RAN can set up 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 done 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 then 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 RAN switches a UE from the RRC_CONNECTED state to the RRC_INACTIVE state (i.e., releases it), the serving gNB (which becomes the anchor gNB) assigns an ID called I-RNTI to the UE. I-RNTI is responsible for identifying both the anchor gNB and the UE context within the anchor gNB when the UE context is fetched from the old anchor gNB to the new gNB.

[0176] If a UE wishes to transition from the RRC_INACTIVE state to the RRC_CONNECTED state upon receiving a page or upon the arrival of pending UL data (i.e., data originating from the UE and stored in the UE's UL send buffer), the UE sends a resume request for the RRC connection (including the interrupted radio bearer) including its I-RNTI (this is the RRCResumeRequest message). A gNB that receives this request can use the included I-RNTI to fetch the UE context from the old anchor gNB (also called the "last-serving gNB") and then resume the RRC connection. The new gNB then completes the resume of the RRC connection (sending an RRCResume message from the new gNB to the UE, to which the UE responds with an RRCResumeComplete message), and the UE context of the old anchor gNB (last-serving gNB) is removed.

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

[0178] Currently, a certain problem exists.

[0179] The current 3GPP standard allows a UE to maintain a QoE measurement configuration while in the RRC_INACTIVE state. However, the standard does not describe the possibility of a UE performing QoE measurements in the RRC_INACTIVE state, nor does it describe providing information to the network related to the duration spent in the RRC_INACTIVE state.

[0180] For example, note that streaming applications may have buffers of video data that last for several minutes. This means that a streaming session can persist for a considerable period without communication, which can happen, for example, if the UE is temporarily released into the RRC_INACTIVE state (or RRC_IDLE state).

[0181] Furthermore, considering that an application session with an associated QoE measurement session may be in progress when the UE is released to the RRC_INACTIVE state, may or may not terminate while the UE is in the RRC_INACTIVE state, or a new application session with an associated QoE measurement session may be started while the UE is in the RRC_INACTIVE state, there are problems with the indication of session status (in progress or not in progress) in the network. In other words, since there is no communication between the UE and the network while the UE is in the RRC_INACTIVE state, there is no way to verify that the indication of session status in the network is correct.

[0182] This means that when a UE resumes an RRC connection on a new RAN node, a problem arises because, due to the above, the status indication to the new RAN node may be incorrect when the session status indication is forwarded (in the RETRIEVE UE CONTEXT RESPONSE XnAP message of the NR) 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). [Overview of the project]

[0183] Certain aspects and embodiments of this disclosure may provide solutions to these or other problems.

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

[0185] Session status information can be enhanced 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.

[0186] Relevant information may be transferred from the old RAN node to the new RAN node (for example, from the anchor RAN node to the RAN node where the UE performs the RRC resume procedure, in the case of the RRC_INACTIVE state), the most recent known session state (which may be overwritten by the latest session state information from the UE), a timestamp of when the UE was released to the RRC_INACTIVE (or RRC_IDLE) state, and / or the most recent reported value(s) of a specific RVQoE metric(s) (such as the streaming buffer level).

[0187] Accordingly, according to embodiments 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 of the RRC_INACTIVE state. (Alternatively, the UE provides session status information related to the QoE measurement session to the RAN node when the UE sets up the RRC connection after a period of the RRC_IDLE state.)

[0188] In a first aspect of this disclosure, a method is performed by the user device. This method includes connecting to a first RAN node of a communication network upon transitioning to a connected state. The method further includes transmitting information related to one or more QoE measurement sessions configured in the user device to the communication network. One or more QoE measurement sessions were configured in the user device during a previous instance of the user device in a connected state.

[0189] In a second aspect of this disclosure, the method is performed by a user device. The method includes transmitting one or more QoEs configured on the user device, information related to a measurement session, to a first RAN node of the communication network while in an inactive connection state.

[0190] In a third aspect of this disclosure, the method is performed by a first network node of a communication network. The method includes receiving information from one or more of the user device and a second network node of the communication network relating to one or more QoE measurement sessions configured in the user device when the user device connects to the first network node and transitions to a connected state. The one or more QoE measurement sessions were configured in the user device during a previous instance of the user device in a connected state.

[0191] In a fourth aspect of this disclosure, the method is performed by a second network node. The second network node provides services to a user device released to an inactive or idle connected state. The method includes transmitting information relating to one or more QoE measurement sessions set up on the user device to a first network node to which the user device subsequently connected upon transitioning to a connected state.

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

[0193] To better understand embodiments of this disclosure and to illustrate how this disclosure may be carried out, the attached drawings are referenced below as an example:

[0194] [Figure 1] Figure 1 is a signaling diagram showing the UE capability inquiry procedure.

[0195] [Figure 2] Figure 2 is a signaling diagram showing the transmission of UE capability information.

[0196] [Figure 3] Figure 3 is a signaling diagram showing the measurement and control procedure.

[0197] [Figure 4] Figure 4 is a signaling diagram showing the measurement reporting procedure.

[0198] [Figure 5] Figure 5 is a signaling diagram showing the UE capability transfer procedure.

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

[0200] [Figure 7] Figure 7 is a schematic flowchart illustrating the method according to several embodiments.

[0201] [Figure 8] Figure 8 is a schematic flowchart illustrating the method according to several embodiments.

[0202] [Figure 9] Figure 9 is a schematic flowchart illustrating the method according to several embodiments.

[0203] [Figure 10] Figure 10 is a schematic flowchart illustrating a method according to several embodiments.

[0204] [Figure 11] Figure 11 shows examples of communication systems according to several embodiments.

[0205] [Figure 12] Figure 12 shows UEs according to several embodiments.

[0206] [Figure 13] Figure 13 shows network nodes according to several embodiments.

[0207] [Figure 14] Figure 14 is a block diagram of a host according to various embodiments described herein.

[0208] [Figure 15] Figure 15 is a block diagram showing a virtualization environment in which functions implemented by several embodiments can be virtualized.

[0209] [Figure 16] Figure 16 is a block diagram showing the communication of a host communicating with a UE via a network node over a partial wireless connection, according to several embodiments. [Modes for carrying out the invention]

[0210] Here, some embodiments intended in this specification will be described more fully with reference to the accompanying drawings. Embodiments are provided as examples to convey the scope of the subject to those skilled in the art.

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

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

[0213] The terms "QoE measurement" and "application layer measurement" 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 a part of the QoE configuration that consists of an XML file containing instructions on which 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," "wireless layer," "RRC layer," and "wireless network layer" are used interchangeably when referring to the UE (Unified User).

[0218] The terms "access layer" and "wireless layer" are used interchangeably when referring to the UE (Unified Environment).

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

[0220] Application sessions and QoE measurement sessions configured to measure or collect data from application sessions are closely related. This is often reflected in this document by referring to a QoE measurement session as being associated with an application session, or an application session as being associated with a QoE measurement session. An exception may be made if an application session of a certain service type is initiated, and then (while the application session is in progress) a QoE configuration targeting that service type is received at the UE application layer. The UE application layer initiates a QoE measurement session and measures the running application session (waiting for the next application session of the target service type, instead of the alternative option of not initiating a QoE measurement session for an application session that is already in progress). The same principle applies to RVQoE measurement. In the following description, unless otherwise specified, it is assumed that the application session and its associated QoE measurement session and / or RVQoE measurement session are initiated simultaneously or with a negligible delay between the application session and the QoE measurement session. Mechanisms to specifically address cases where the QoE measurement session and / or RVQoE measurement session are initiated while the associated application session is already in progress (i.e., the QoE measurement session and / or RVQoE measurement session are initiated with a non-negligible delay) may also be covered by the embodiments described herein.

[0221] The above explanation of the relationship between application sessions and associated QoE measurement sessions involves discussing the meaning of the “session start” instruction (a term frequently used in this explanation). During the specification work for the QoE framework (particularly QoEforNR), 3GPP was unclear whether the session start instruction referred 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 the session start instruction sent from the UE to the gNB (in the form of the applicationLayerSessionStatus-r17 parameter set to “started” in the MeasurementReportAppLayer message) refers to the started QoE measurement session, and it is assumed that the same applies to the session start instruction sent from the UE application layer to the UE_AS. Therefore, the basic premise in this explanation is that the session start instruction refers to a QoE measurement session.

[0222] The solutions proposed in this disclosure are applicable to future wireless access technologies such as UMTS, LTE, NR, and 6G.

[0223] All references to the application layer refer to the application layer of the UE (since RAN nodes do not have an application layer).

[0224] The solutions proposed in this disclosure apply to both signaling-based and control-based QoE measurements (although they may be optionally limited to applying to only one of them).

[0225] To transition from the RRC_INACTIVE state to the RRC_CONNECTED state, the UE performs a procedure known as the resume procedure, in which the UE's RRC connection is 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 (such as a gNB), including an RRCResumeRequest or RRCResumeRequest1 message from the UE, followed by an RRCResume message from the network, and then 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 its RRC connection. This procedure is sometimes 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, and then 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) (followed by an RRCConnectionRequest message from the UE, an RRCConnectionSetup message from the network, and an RRCConnectionSetupComplete message from the UE).

[0227] The embodiments described herein are primarily in terms of 5G / NR and imply the application of solutions in 5G / NR, but embodiments of this disclosure are also applicable to LTE (in which case, for example, gNB is replaced by eNB), 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 MeasurementReportAppLayer.

[0228] This Disclosure Embodiment According to embodiments of this disclosure, in order to address the above-mentioned problems, information regarding the QoE measurement session(s) during past RRC_INACTIVE periods (e.g., in progress, not in progress, 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 from which the UE resumes the RRC connection). See Figures 7 and 9 for details of these embodiments. This information may be sent, for example, in an RRCResumeRequest message, an RRCResumeComplete message, a MeasurementReportAppLayer message, a UEAssistanceInformation message, or a UEInformationResponse message (optionally, after the UE has indicated the availability of such information in an RRCResumeComplete message, in response to a request from the new RAN node in a UEInformationRequest message), or a newly introduced message. Optionally, the UE sends session status information to the RAN node performing the RRC resume procedure only if the session status is "in progress". Another option is for the UE to send session status information to the RAN node that will perform the RRC resume procedure only if the session status has changed since the time the UE entered the INACTIVE state.

[0229] If future 3GPP releases enable the retention of QoE configurations in the RRC_IDLE state, the above solution may also apply when a UE is released into the RRC_IDLE state and then sets up a new RRC connection (possibly to a new RAN node). In this case, the RRC resume procedure is replaced by the RRC setup procedure, and among the aforementioned messages to which the UE can send session status information, the RRCResumeRequest message is replaced by the RRCSetupRequest message, and the RRCResumeComplete message is replaced by the RRCSetupComplete message or a newly defined message.

[0230] Variations, extensions, and supplements to the fundamental principles of session status information signaling. UE in RRC_INACTIVE state New RAN node (For example, gNB or eNB) RRC Resume Procedure When initiating, the anchor RAN node (e.g., gNB or eNB) was active when the UE was released to the RRC_INACTIVE state. Session status: In progress / Not in progress It is possible to forward the information, but that information may be outdated and inaccurate. Therefore, This information is optional. The UE is transferred from the anchor RAN node to the new RAN node where the RRC connection will be resumed. From UE context information (For example, within the RETRIEVE UE CONTEXT RESPONSE XnAP message) It can also be excluded. However, another option is to transfer the data from the anchor RAN node to the new RAN node. It can also be included in the UE context. but, In that case, it will be overwritten by the information sent from the UE. As a further option, it was effective when the UE was released to the RRC_INACTIVE state. Session status The status (in progress / not in progress) is forwarded from the anchor RAN node to the new RAN node where the UE resumes the RRC connection (for example, within the RETRIEVE UE CONTEXT RESPONSE XnAP message). Included in UE context informationThe UE receives session status information sent from the anchor RAN node to the new RAN node and If different (That is, if the UE's session status information is different from what it was when the UE was released to the RRC_INACTIVE state) Only send the session status information to be overridden to the new RAN node. .

[0231] Embodiments of the solutions described herein are UE, What is a RAN node that has released a UE to the RRC_INACTIVE state (or RRC_IDLE state)? Another RAN node Towards RRC Resume While this refers to the case where the procedure (or RRC setup procedure) is performed, it should be noted that the embodiment of the solution is also applicable when the UE performs the RRC resume procedure (or RRC setup procedure) toward the same RAN node from which the UE was released to the RRC_INACTIVE state (or RRC_IDLE state). UE resumes RRC Procedure (or RRC setup procedure) The cell that executes Even if the UE is released to the RRC_INACTIVE state (or RRC_IDLE state) They may be the same .

[0232] If the UE is dual-connected and the SN is configuring the UE for QoE measurement, the SN is the node that has knowledge of the session status. In this case, the SN can notify the MN of the session status, and the MN can notify the new RAN node when the RRC resumes after establishing the RRC connection. To do this, the SN can use either an existing DC-related XnAP procedure (with the potential for extension) or a newly defined procedure.

[0233] While the UE is in the RRC_INACTIVE state, Related to QoE configuration The session status may change multiple times.It should be noted that, for example, if a QoE measurement session (and associated application session) that was in progress when the UE was released to the RRC_INACTIVE state terminates while the UE is in the RRC_INACTIVE state, and then another application session of the same type with an associated QoE measurement session (composed of the same QoE configuration) is started while the UE is still in the RRC_INACTIVE state, the UE can indicate that this has happened by providing, for example, a list of session status indicators (in this case, a session stop indicator followed by a session start indicator). Optionally, a timestamp can be associated with each session status indicator provided.

[0234] In the alternative solution, the UE sends a session ongoing / inactive status indicator in the resume procedure only if the status has changed compared to the most recent status indicator the UE sent before forwarding to RRC_INACTIVE. This means 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 the resume and the UE does not send information to the network, the network can forward the session status information from the source to the target node. This solution can be combined with a solution where the UE signals further information to the network.

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

[0236] The UE can send information about whether or not a session was in progress during RRC_INACTIVE. For example, if the UE had an ongoing session from time a to time b, then b For example, there are no sessions running from time c to time c, and there are sessions running from time c to time d. As a simplified option, the UE can indicate timestamps corresponding to the moments when a session started and / or ended during the RRC_INACTIVE state.

[0237] An anchor RAN node can also provide new RAN nodes with more information than the most recent known session state of the UE (i.e., the session state that was in effect when the UE was released to the RRC_INACTIVE state). Such additional information may include, for example: Time the UE was in the RRC_INACTIVE state This may include (for example, shown as a duration, or as a timestamp of the time the UE was released into the RRC_INACTIVE state). Further information that an anchor RAN node can provide to a new RAN node may include the last streaming buffer level reported by the UE before it was released into the RRC_INACTIVE state. One or more recent RVQoE metric values , and optionally The timestamp associated with that buffer levelThis may include: As per the options above, the latest known session status of the UE can be omitted, so even if the anchor RAN node omits the latest known session status of the UE, it is still possible to 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 the RRC_INACTIVE state), and / or one or more of the most recently reported RVQoE metric values ​​by the UE.

[0238] Triggers for state transitions The trigger for a UE with an active application session to initiate the RRC resume procedure is typically the generation of uplink data that the application should send (e.g., requests to the application server, e.g., requests for streaming data). Alternatively, the trigger for the RRC resume procedure may be that the application session buffer becomes empty, falls below a certain threshold, or shows a decreasing trend. Alternatively, the trigger may be a paging message from the network. A paging message may be triggered by downlink application data that is pending to be sent to the UE. For a UE in the RRC_INACTIVE state, the UE may be paged by RAN paging, and the reception of a page triggers the UE to initiate the RRC resume procedure and transition to the RRC_CONNECTED state. For a UE in the RRC_IDLE state (which may be relevant in the context of this disclosure, in particular if future 3GPP releases allow UEs to maintain a QoE configuration in the RRC_IDLE state), the UE may be paged by CN paging, and the reception of a page triggers the UE to initiate the RRC setup procedure and transition to the RRC_CONNECTED state. Whether and / or what 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] One option is for the UE to also provide the network with a QoE-specific reason for initiating an RRC resume (e.g., reasons mentioned above, such as UL data to send, buffer exhaustion, etc.).

[0240] Configuration of UE operation UE When resuming a connection on a RAN node (or performing the RRC setup procedure after a period of RRC_IDLE state) Should session status information be provided? The types of information provided, and the network itself, can be configured.

[0241] As one option, UE In the RRC_INACTIVE state (or RRC_IDLE state) RAN nodes to release teeth, UE In the RRC_INACTIVE state (or RRC_IDLE state) Message to release For example, in an RRCRelease message, the UE provides the RAN node that will perform the subsequent RRC Resume procedure. It can provide instructions for reporting possible session status information. Such instructions might include, for example, whether the UE should provide its session status information, the session status when the session status changes or when the UE is released into the RRC_INACTIVE state (or RRC_IDLE state) (for example, the session status when the UE receives an RRCRelease message), and / or the type of information the UE should provide (only the latest / current session status, or a list of session status indicators, and / or additional information such as the duration of the RRC_INACTIVE state (or RRC_IDLE state)).

[0242] Alternatively, the RAN node on which the UE performs the RRC resume procedure (or RRC setup procedure) can include the above instructions in the RRCResume message (or RRCSetup message).

[0243] Another option is to configure the RAN node to send session status updates in UEAssistanceInformation messages.

[0244] Another option is, UE resumes RRC Procedure (or RRC setup procedure) RAN node to execute This uses the UEInformationRequest message, Specific session status information and / or send additional information in the UEInformationResponse message (presumably after the UE has indicated the availability of such information in the RRCResumeComplete message (or RRCSetupComplete message)). Explicitly request this from the UE It is possible.

[0245] Another option is, UE resumes RRC Procedure (or RRC setup procedure) RAN node to execute This is done using the RRCReconfigurationRequest message, for example, within the MeasurementReportAppLayer message, Specific session status information and / or additional information Explicitly request the UE to send it. It is possible.

[0246] Another option that can complement (for example, 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 The above types of instructions can be included.

[0247] Another option is, Instructions can also be displayed in the broadcast system information. If this option is used, one variation may use it as the default instruction, and this instruction may be overridden or supplemented by instructions provided to the UE in any of the ways described above.

[0248] The UE can also be configured to send all updates of the session status, or it can be configured to send a session status update when 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 it may depend on one or more conditions. For example, the indication or part of the indication may be conditioned by the type of trigger of the RRC resume procedure (or RRC setup procedure). For example, the indication depends on whether the trigger is an internal UE trigger or a paging.

[0250] In another option, the RAN node When the session status changes such as when a session starts or ends Start RRC Resume and in conjunction therewith can provide session information UE configuration as possible.

[0251] Further conditions can be targeted at the case of an internal UE trigger. For example, The instruction is triggered by an internal UE. (of an application having a relevant QoE configuration to which the indication applies) Is it the generation of application data, or something else? can depend on whether it is an internal UE trigger.

[0252] Further conditions can be targeted at the case where the trigger is a page. For example, the indication can depend on whether the page is a page started by the RAN or a page started by the CN.

[0253] In another example, the indication, or part of the indication, UE proceeds to RRC resume procedure (or RRC setup procedure) The RAN node running the process is the old RAN node (i.e., the RAN node that released the UE to the RRC_INACTIVE state (or RRC_IDLE state)) It is the same as, or a different RAN is the node It 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 instruction depending on whether the cell on which the UE performs the RRC resume procedure (or RRC setup procedure) is the same cell from which the UE was released to the RRC_INACTIVE state (or RRC_IDLE state) or a different cell.

[0254] In another example, instructions or parts of instructions may be conditional on whether the cell in which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as or different from the cell in which the UE was released to the RRC_INACTIVE state (or RRC_IDLE state).

[0255] In another example, Instructions or parts of instructions are types of state transition procedures. (That is, from which state does the UE exit to enter the RRC_CONNECTED state?) It can be conditioned by For example, the instructions may depend on whether the state transition procedure is an RRC resume procedure (which transitions the UE from the RRC_INACTIVE state to the RRC_CONNECTED state) or an RRC setup procedure (which transitions the UE from the RRC_IDLE state to the RRC_CONNECTED state).

[0256] Adapting the RRC_IDLE state and RRC setup to a solution While 3GPP Release 17 does not support maintaining the QoE configuration in the RRC_IDLE state, this may change in future releases of the 3GPP standard. In anticipation of such potential extensions to the 3GPP standard, all methods, embodiments, options, and variations described above in relation to the RRC_INACTIVE state are, It may be adapted to apply in relation to the RRC_IDLE state instead of the RRC_INACTIVE state.This adaptation involves replacing the RRC resume procedure with the RRC setup procedure and removing the XnAP-based (or X2AP-based) context fetch, but all other essential principles and functionality of the method, embodiment, options, and modifications are retained. (Note that this adaptation to the RRC_IDLE state is described to some extent explicitly for some of the methods, embodiments, options, and modifications described above.)

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

[0258] Information previously described herein as being transferred from an anchor RAN node to a new RAN node using the RETRIEVE UE CONTEXT RESPONSE XnAP message (e.g., the latest known session state in the UE) may, in the case of the RRC_IDLE state (and RRC setup procedure), be transferred from the old RAN node to the new RAN node using this mechanism, i.e., by including it in a container stored in the core network to be transferred to the subsequent RAN node.

[0259] expansion RRC_INACTIVE state or RRC_IDLE state During the period, UE is , to be reported later in the QoE report(s) and / or RVQoE report(s), Collect QoE metric values ​​and / or other information.It is also possible that, in addition to the usual QoE / RVQoE metrics, the UE can record the time spent released from the RRC_CONNECTED state to the RRC_INATIVE or RRC_IDLE state, and the time spent re-entering the RRC_CONNECTED state (or, instead, the time spent in the RRC_INATIVE or RRC_IDLE state). This information can be "integrated" with the QoE metric values ​​in the report in a way that clarifies which values ​​were collected during which state. Other ways are conceivable to indicate which different values ​​were collected under which state. For example, the report could indicate under which state certain parts of the report were collected, or indicate the state associated with the collected measurements or samples.

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

[0261] UE provides updated session status information to RAN while in the RRC_INACTIVE state. For details, see, for example, Figure 8. A solution to ensure that the anchor RAN node holds up-to-date session status information for UEs in the RRC_INACTIVE state, and that when the UE resumes from the RRC_INACTIVE state, it can eventually transfer the correct (updated) session status information to the new RAN node, is that the UE Remains in RRC_INACTIVE state The goal is to enable the transmission of session status information updated by the small data transmission procedure (i.e., without transitioning to the RRC_CONNECTED state).

[0262] The RAN can set a trigger for the UE to send (update) session status information. The trigger can be any one or any combination of the following: · The UE is in the RRC_INACTIVE state, and the session that was in progress when the UE was released from RRC_INACTIVE has ended normally. · The UE is in the RRC_INACTIVE state, and the session that was in progress when the UE was released from RRC_INACTIVE has ended due to failure. · The UE is in the RRC_INACTIVE state, and a new application session has been started. · The UE is in the RRC_INACTIVE state, and one or more changes have occurred in the status of the application session that was in progress when the UE was released from RRC_INACTIVE. · The UE is in the RRC_INACTIVE state, and one or more changes have occurred in the status of a new application session that was started after the UE was released from RRC_INACTIVE. · The UE has reselected a new cell of the anchor RAN node (or a new cell of another RAN node). · A timer has expired (e.g., T380) or is running. · The data volume is below the threshold · The data volume of SRB4 is below the threshold.

[0263] For the transmission of session status information, existing SDT procedures can be reused and extended. For example, when 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 transferred between the receiving gNB and the last serving gNB using the XnAP RRC transfer procedure until the last serving gNB ends the SDT session and sends an RRCRelease message to return the UE to RRC_INACTIVE.

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

[0265] At a minimum, the anchor node is provided with updated session status information, but RAN nodes contacted for the SDT procedure (if different from the anchor node) do not store such information (there is no guarantee of which RAN node the UE will ultimately resume on, and the session status information is originally stored on 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 that contacted for the SDT procedure, and such a node can store the session status information as it was received from the UE.

[0266] In a possible solution, the UE could provide the RAN with updates regarding session status information as part of an RRC resume procedure triggered by RNA updates (e.g., when the UE moves away from RNA, or due to the expiration of the T380 timer for periodic RNA updates).

[0267] Figure 7 shows a method according to a specific embodiment. This method can be performed by a UE or a wireless device (for example, UE1112 or UE1200, described later with reference to Figures 11 and 12, respectively).

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

[0269] While in an inactive or idle state, in step 704, the UE may continue to perform QoE measurements for application sessions that can withstand the 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 a streaming session may persist for a considerable period without communication, which could occur, for example, if the UE is temporarily released into the RRC_INACTIVE state (or RRC_IDLE state). In addition, or instead, 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 started, or a previously ongoing QoE measurement session (and associated application session) may be terminated or cancelled.

[0270] In step 706, the UE transitions back to the connected state. For example, the UE can resume a previously interrupted 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 to which the UE previously connected (for example, in step 702) or a different RAN node.

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

[0272] The information may be sent to the first RAN node in connection resume request messages (e.g., RRCResumeRequest, RRCResumeRequest1, etc.) or connection establishment request messages (e.g., RRCSetupRequest, RRCConnectionSetup, etc.). Alternatively, the information may be sent in messages 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.), response messages to request messages from the first RAN node (e.g., UEInformationResponse messages to UEInformationRequest messages from the first RAN node), or other appropriate messages (e.g., MeasurementReportAppLayer, UEAssistanceInformation, etc.).

[0273] Information relating to one or more QoE measurement sessions configured on a user device may include the status of one or more QoE measurement sessions (e.g., in progress, not in progress, completed, etc.). In one embodiment, the information may consist only of the status of in progress QoE measurement sessions. In such embodiments, the information may consist of a list of QoE measurement session identifiers, and the status itself (i.e., "in progress") may be implicit.

[0274] In a further embodiment, information related to one or more QoE measurement sessions may include the values ​​of one or more parameters (e.g., session state) that have been changed after the user device 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 transmit information about the QoE measurement session at the time the UE was released to an inactive or idle state. The information from the UE may consist only of the changed parameters to conserve radio resources and signaling overhead.

[0275] Information related to one or more QoE measurement sessions may additionally or alternatively include one or more indications of the time the user device was in an inactive or idle state before transitioning to a connected state, and one or more indications of the time or period during which one or more QoE measurement sessions were in progress while the user device was in an inactive or idle state.

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

[0277] The UE can send information about whether or not a session was in progress during RRC_INACTIVE. For example, if the UE had an ongoing session from time a to time b, then b For example, there are no sessions running from time c to time c, and there are sessions running from time c to time d. As a simplified option, the UE can indicate timestamps corresponding to the moments when a session started and / or ended during the RRC_INACTIVE state.

[0278] Information related to one or more QoE measurement sessions may be transmitted to the first RAN node in response to one or more of the configurations received from the communication network and the types of events that triggered the user device to transition to a connected state.

[0279] For example, the trigger for a UE with an active application session to initiate the RRC resume procedure may typically be the generation of uplink data that the application should send (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 that the application session buffer becomes empty, falls below a certain threshold, or shows a decreasing trend. Alternatively, the trigger may be a paging message from the network. A paging message may be triggered by downlink application data that is pending to be sent to the UE. For a UE in the RRC_INACTIVE state, the UE may be paged by RAN paging, and the receipt of a page triggers the UE to initiate the RRC resume procedure and transition to the RRC_CONNECTED state. For a UE in the RRC_IDLE state (which may be relevant in the context of this disclosure, in particular if future 3GPP releases allow UEs to retain QoE configurations in the RRC_IDLE state), the UE may be paged by CN paging, and the receipt of a page triggers the UE to initiate the RRC setup procedure and transition to the RRC_CONNECTED state. Whether and / or what 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] One option is for the UE to also provide the network with a QoE-specific reason for initiating an RRC resume (e.g., reasons mentioned above, such as UL data to send, buffer exhaustion, etc.).

[0281] Whether the UE should provide session status information and the type of information provided when a connection is resumed at a RAN node (or when the RRC configuration procedure is performed after a period of RRC_IDLE state) can be configured by the network.

[0282] One option is for a RAN node releasing a UE into the RRC_INACTIVE (or RRC_IDLE) state to indicate in the message releasing the UE into the RRC_INACTIVE (or RRC_IDLE) state, such as the RRCRelease message, that the UE may provide to the RAN node performing subsequent RRC resume procedures with information about its session status. Such instructions could include, for example, whether the UE should provide its session status information, if the session status has changed or if the UE was released into the RRC_INACTIVE (or RRC_IDLE) state (e.g., the session status when the UE received the RRCRelease message), and / or the type of information the UE should provide (only the latest / current session status, or a list of session status indicators, and / or additional information such as the duration of the RRC_INACTIVE (or RRC_IDLE) state).

[0283] Alternatively, the RAN node on which the UE performs the RRC resume procedure (or RRC setup procedure) can include the above instructions in the RRCResume message (or RRCSetup message).

[0284] Another option is to configure the RAN node to send session status updates in UEAssistanceInformation messages.

[0285] As yet another option, the RAN node on which the UE is performing the RRC resume procedure (or RRC setup procedure) can use the UEInformationRequest message to explicitly request the UE to send specific session status information and / or additional information in the UEInformationResponse message (presumably after the UE has indicated the availability of such information in the RRCResumeComplete message (or RRCSetupComplete message)).

[0286] As yet another option, the RAN node where the UE is performing the RRC resume procedure (or RRC setup procedure) can use the RRCReconfigurationRequest message to explicitly request the UE to send specific session status information and / or additional information, for example, within a MeasurementReportAppLayer message.

[0287] As yet another option that can complement (for example, 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 instructions of the above type in the RRC paging message.

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

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

[0290] Instructions may be unconditional, but in some variations, they may depend on one or more conditions. For example, an instruction or part of an instruction may be conditional on the type of trigger in the RRC resume procedure (or RRC setup procedure), for instance, the instruction may depend on whether the trigger is an internal UE trigger or a page trigger.

[0291] Alternatively, the RAN node can be configured to initiate an RRC resume when the session status changes, for example, when a session starts or ends, and to provide session information in conjunction with this.

[0292] Further conditions may apply to cases of UE internal triggers, such as when the instruction depends on whether the UE internal trigger is the generation of application data (of an application with the relevant QoE configuration to which the instruction applies) or another UE internal trigger.

[0293] Further conditions may apply if the trigger is a page, for example, the instruction may depend on whether the page is a RAN start page or a CN start page.

[0294] In another example, an instruction, or part of an instruction, may be conditional on whether the RAN node to 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 to the RRC_INACTIVE state (or RRC_IDLE state)) or a different RAN node. In this example, if the RAN node to which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as the old RAN node, further conditions may apply, for example, such as the instruction depending on whether the cell to which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as the cell to which the UE was released to the RRC_INACTIVE state (or RRC_IDLE state) or a different cell.

[0295] In another example, an instruction or part of an instruction may be conditional on whether the cell in which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as or different from the cell from which the UE was released to the RRC_INACTIVE state (or RRC_IDLE state). In yet another example, an instruction or part of an instruction may be conditional on the type of state transition procedure (i.e., from which state the UE leaves in order to enter the RRC_CONNECTED state), for example, an instruction may depend on whether the state transition procedure is an RRC resume procedure (which transitions the UE from the RRC_INACTIVE state to the RRC_CONNECTED state) or an RRC setup procedure (which transitions the UE from the RRC_IDLE state to the RRC_CONNECTED state).

[0296] Figure 8 shows a method according to a specific embodiment. This method can be performed by a UE or a wireless device (for example, UE1112 or UE1200, described later with reference to Figures 11 and 12, respectively).

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

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

[0299] Information relating to one or more QoE measurement sessions configured on a user device may include the status of one or more QoE measurement sessions (e.g., in progress, not in progress, completed, etc.). In one embodiment, the information may consist only of the status of in progress QoE measurement sessions. In such an embodiment, the information may consist of a list of QoE measurement session identifiers, and the status itself (i.e., "in progress") may be implicit.

[0300] In a further embodiment, information relating to one or more QoE measurement sessions may include the values ​​of one or more parameters (e.g., session state) that have been changed after the user device 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 transmit information about the QoE measurement sessions at the time the UE was released to an inactive or idle state. The information from the UE may consist only of the changed parameters in order to conserve radio resources and signaling overhead.

[0301] Information related to one or more QoE measurement sessions may additionally or alternatively include one or more indications of the time the user device was in an inactive or idle state before transitioning to a connected state, and indications of the time when one or more QoE measurement sessions were in progress or not in progress while the user device was in an inactive or idle state.

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

[0303] During RRC_INACTIVE, the UE can send information about when a session was in progress or not. For example, from time a to time b, the UE had an ongoing session, and then b For example, there are no sessions running from time c to time c, and there are sessions running from time c to time d. As a simplified option, the UE can indicate timestamps corresponding to the moments when a session started and / or ended during the RRC_INACTIVE state.

[0304] Information relating to one or more QoE measurement sessions may be transmitted in step 804 in response to one or more of the following: a QoE measurement session that was in progress when the user device was released into an inactive connection state has successfully terminated; a QoE measurement session that was in progress when the user device was released into an inactive connection state has failed to terminate; a new application session has started; one or more status changes of application sessions that were in progress when the user device was released into an inactive connection state; one or more status changes of application sessions that were started after the user device was released into an inactive connection state; a timer has expired or is running; the user device has re-selected a new cell; or the amount of data is below a threshold.

[0305] For example, the first RAN node can set up a trigger for the UE to send (updated) session status information. The trigger can be one or any combination: • The UE was in the RRC_INACTIVE state, and the session that was in progress when the UE was released to RRC_INACTIVE terminated successfully. The UE was in the RRC_INACTIVE state, and any ongoing sessions that occurred when the UE was released to RRC_INACTIVE failed and terminated. • The UE is in the RRC_INACTIVE state, and a new application session has been started. • The UE was in the 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 the RRC_INACTIVE state, and one or more status changes have occurred in new application sessions started after the UE was released to RRC_INACTIVE. The UE re-selected a new cell in the anchor RAN node (or a new cell in another RAN node). The timer has expired (e.g., T380) or is currently running. • The amount of data is below the threshold. • The amount of data in SRB4 is below the threshold.

[0306] Existing SDT procedures can be reused and extended to transmit session status information. For example, if session status information is treated as SRB data and a UE accesses a gNB other than the last serving gNB (anchor RAN node), the SRB PDCP PDU can be transferred between the receiving gNB and the last serving gNB using the XnAP's RRC transfer 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 send 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), for example, new IE: " sdt-SRB4-Indication ENUMERATED {allowed} OPTIONAL We will introduce "[...]."

[0308] Therefore, the anchor (first) RAN node is provided with updated session status information, but no such information is stored in the RAN nodes contacted for the SDT procedure (if different from the anchor node) (there is no guarantee of which RAN node the UE will ultimately resume on, 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 nodes contacted for the SDT procedure, and such nodes can store the session status information as it was received from the UE.

[0309] In a possible solution, the UE could provide updates regarding session status information to the RAN as part of an RRCResume procedure triggered by RNA updates (e.g., when the UE moves away from RNA, or due to the expiration of the T380 timer for periodic RNA updates).

[0310] Figure 9 shows a method according to a specific embodiment. This method may be performed by a first network node (for example, network node 1110 or network node 1300, described later with reference to Figures 11 and 13, respectively). The method in Figure 9 can be read in conjunction with the methods in Figures 7 and 10, which show the corresponding steps in the UE and second RAN node, respectively.

[0311] This process begins in step 902, when the user device connects to the first network node and transitions to the connected state. The first RAN node then receives information from the UE related to one or more QoE measurement sessions configured on the user device. For example, the UE may resume a previously interrupted 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 sent to the first RAN node in connection resume request messages (e.g., RRCResumeRequest, RRCResumeRequest1, etc.) or connection establishment request messages (e.g., RRCSetupRequest, RRCConnectionSetup, etc.). Alternatively, the information may be sent in messages 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.), response messages to request messages from the first RAN node (e.g., a UEInformationResponse message as a response to a UEInformationRequest message from the first RAN node), or other appropriate messages (e.g., MeasurementReportAppLayer, UEAssistanceInformation, etc.).

[0313] Information relating to one or more QoE measurement sessions configured on a user device may include the status of one or more QoE measurement sessions (e.g., in progress, not in progress, completed, etc.). In one embodiment, the information may include the status of only the QoE measurement sessions that are in progress. In such an embodiment, the information may consist of a list of QoE measurement session identifiers, and the status itself (i.e., "in progress") may be implicit.

[0314] In a further embodiment, information related to one or more QoE measurement sessions may include the values ​​of one or more parameters (e.g., session state) that have been changed after the user device 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 an inactive or idle state) can transmit information about the QoE measurement session at the time the UE was released to an inactive or idle state (see step 904 below). The information from the UE may consist only of the changed parameters in order to conserve radio resources and signaling overhead.

[0315] Information associated with one or more QoE measurement sessions may additionally or alternatively include one or more indications of the time the user device was in an inactive or idle state before transitioning to a connected state, and indications of the time one or more QoE measurement sessions were in progress or not in progress during the time the user device was in an inactive or idle state.

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

[0317] The UE can send information about whether or not a session was in progress during RRC_INACTIVE. For example, if the UE had an ongoing session from time a to time b, then bFor example, there are no sessions running from time c to time c, and there are sessions running from time c to time d. As a simplified option, the UE can indicate timestamps corresponding to the moments when a session started and / or ended during the RRC_INACTIVE state.

[0318] Information related to one or more QoE measurement sessions may be transmitted to the first RAN node in response to one or more of the configurations received from the communication network and the types of events that triggered the user device to transition to a connected state.

[0319] For example, the trigger for a UE with an active application session to initiate the RRC resume procedure may typically be the generation of uplink data that the application should send (e.g., a request to the application server, e.g., a request for streaming data). Alternatively, the trigger for the RRC resume procedure may be that the application session buffer becomes empty, falls below a certain threshold, or shows a decreasing trend. Alternatively, the trigger may be a paging message from the network. A paging message may be triggered by downlink application data that is pending to be sent to the UE. In the case of a UE in the RRC_INACTIVE state, the UE may be paged by RAN paging, and the reception of a page triggers the UE to initiate the RRC resume procedure and transition to the RRC_CONNECTED state. In the case of a UE in the RRC_IDLE state (which may be relevant to the context of this disclosure, in particular if future 3GPP releases allow UEs to retain QoE configurations in the RRC_IDLE state), the UE may be paged by CN paging, and the reception of a page triggers the UE to initiate the RRC setup procedure and transition to the RRC_CONNECTED state. Whether and / or what 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 can also provide the network with a QoE-specific reason for initiating an RRC resume (such as UL data to send, buffer exhaustion, etc.), as mentioned above.

[0321] Whether the UE should provide session status information when a connection is resumed at a RAN node (or when the RRC setup procedure is performed after a period of RRC_IDLE state), and the type of information provided, can be configured by the network.

[0322] One option is for a RAN node releasing a UE into the RRC_INACTIVE (or RRC_IDLE) state to indicate in the message releasing the UE into the RRC_INACTIVE (or RRC_IDLE) state, such as the RRCRelease message, whether the UE should report any session status information it may provide to the RAN node performing subsequent RRC resume procedures. Such instructions could include, for example, whether the UE should provide its session status information, if the session status has changed or if the UE was released into the RRC_INACTIVE (or RRC_IDLE) state (e.g., the session status when the UE received the RRCRelease message), and / or the type of information 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 (or RRC_IDLE) state).

[0323] Alternatively, the RAN node on which the UE performs the RRC resume procedure (or RRC setup procedure) can include the above instructions in the RRCResume message (or RRCSetup message).

[0324] Another option is to configure the RAN node to send session status updates in UEAssistanceInformation messages.

[0325] As yet another option, the RAN node on which the UE is performing the RRC resume procedure (or RRC setup procedure) can use the UEInformationRequest message to explicitly request the UE to send specific session status information and / or additional information in the UEInformationResponse message (presumably after the UE has indicated the availability of such information in the RRCResumeComplete message (or RRCSetupComplete message)).

[0326] As yet another option, the RAN node where the UE is performing the RRC resume procedure (or RRC setup procedure) can use the RRCReconfigurationRequest message to explicitly request the UE to send specific session status information and / or additional information, for example, within a MeasurementReportAppLayer message.

[0327] As yet another option that can complement (for example, 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 instructions of the above type in the RRC paging message.

[0328] As yet another option, the instructions may be shown in the broadcast system information. If this option is used, in one variation, it may be used as the default instruction, which may be overridden or supplemented by instructions provided to the UE in one 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 only when resuming to RRC_CONNECTED if the session status has changed since being forwarded to RRC_INACTIVE (or RRC_IDLE).

[0330] Instructions may be unconditional, but in some variations, they may depend on one or more conditions. For example, an instruction or part of an instruction may be conditional on the type of trigger in the RRC resume procedure (or RRC setup procedure), for instance, the instruction may depend on whether the trigger is an internal UE trigger or a page trigger.

[0331] Alternatively, the RAN node can be configured to initiate an RRC resume when the session status changes, for example, when a session starts or ends, and to provide session information in conjunction with this.

[0332] Further conditions may apply to cases of UE internal triggers, for example, an instruction may depend on whether the UE internal trigger is the generation of application data (of an application with the relevant QoE configuration to which the instruction applies) or another UE internal trigger.

[0333] Further conditions may apply when the trigger is a page, for example, the instruction may depend on whether the page was initiated by RAN or CN.

[0334] In another example, an instruction, or part of an instruction, may be conditional on whether the RAN node to which the UE executes 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 to the RRC_INACTIVE state (or RRC_IDLE state)) or a different RAN node. In this example, if the RAN node to which the UE executes the RRC resume procedure (or RRC setup procedure) is the same as the old RAN node, further conditions may apply, for example, if the instruction depends on whether the cell to which the UE executes the RRC resume procedure (or RRC setup procedure) is the same as the cell to which the UE was released to the RRC_INACTIVE state (or RRC_IDLE state) or a different cell.

[0335] In another example, instructions or parts of instructions may be conditional on whether the cell in which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as or different from the cell in which the UE was released to the RRC_INACTIVE state (or RRC_IDLE state).

[0336] In another example, an instruction or part of an instruction may be conditioned by the type of state transition procedure (i.e., which state the UE leaves in order to enter the RRC_CONNECTED state), for example, an instruction may depend on whether the state transition procedure is an RRC resume procedure (which causes the UE to transition from the RRC_INACTIVE state to the RRC_CONNECTED state) or an RRC setup procedure (which causes the UE to transition from the RRC_IDLE state to the RRC_CONNECTED state).

[0337] In step 904, which may be added to or replaced by step 902, when the user device connects to a first network node and transitions to a connected state, the first RAN node receives information from a second network node of the communication network relating to one or more quality-of-effect (QoE) measurement sessions configured in the user device. The second RAN node may be a RAN node to which the UE was previously connected (for example, when it was released to an inactive or idle state). Note that if the first RAN node is the same RAN node to which the UE was previously connected (for example, when it was 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 specified above with respect to step 902. However, it should be noted that the parameter values ​​included in the information may correspond to the values ​​at the time the UE transitioned to an 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 (for example, to account for changes in the information while the UE was inactive or idle). Therefore, 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 the RRC_INACTIVE state initiates an RRC resume procedure toward a new first RAN node (e.g., gNB or eNB), the anchor (second) RAN node (e.g., gNB or eNB) can forward the session in progress / not in progress status that was valid when the UE was released to the RRC_INACTIVE state, but that information may be outdated and inaccurate. For this reason, this information can optionally be excluded from the UE context information forwarded from the anchor RAN node to the new RAN node where the UE resumes the RRC connection (e.g., in the RETRIEVE UE CONTEXT RESPONSE XnAP message), or alternatively, it can be included in the UE context forwarded from the anchor RAN node to the new RAN node, in which case it will be overwritten by information sent from the UE. As a further option, the session status (in progress / not in progress) that was valid when the UE was released to the RRC_INACTIVE state is included in the UE context information that is transferred from the anchor RAN node to the new RAN node where the UE resumes the RRC connection (for example, in the RETRIEVE UE CONTEXT RESPONSE XnAP message), and the UE sends override 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., the UE's session status information differs from the one when the UE was released to the RRC_INACTIVE state).

[0341] While the embodiments of the solutions described herein refer to the case where the UE performs the RRC resume procedure (or RRC setup procedure) toward a RAN node different from the RAN node from which the UE was released in the RRC_INACTIVE state (or RRC_IDLE state), it should be noted that the embodiments of the solutions are also applicable when the UE performs the RRC resume procedure (or RRC setup procedure) toward the same RAN node from which the UE was released in the RRC_INACTIVE state (or RRC_IDLE state), and the cell in which the UE performs the RRC resume procedure (or RRC setup procedure) may be the same cell from which the UE was released in the RRC_INACTIVE state (or RRC_IDLE state).

[0342] If the UE is dual-connected and the SN is configuring the UE for QoE measurement, the SN is the node that has knowledge of the session status. In this case, the SN can notify the MN of the session status, and the MN can notify the new RAN node when the RRC resumes after establishing the RRC connection. To do this, the SN can use either an existing DC-related XnAP procedure (with the potential for extension) or a newly defined procedure.

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

[0344] This method starts 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 consist of one or more QoE measurement sessions associated with each application session. 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 device connects to the first RAN node and transitions to the connected state, the second network node transmits information to the first RAN node related to one or more QoE measurement sessions configured on the user device. For example, the UE can resume a previously interrupted 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] Information related to one or more QoE measurement sessions may include information related to one or more QoE measurement sessions at the time the UE is released into an inactive or idle state. Alternatively, a second RAN node may receive information from the UE while the UE is in an inactive state (see, for example, Figure 8 above). In this case, the information supplied to the first RAN node may correspond to information updated while the UE was in an inactive state.

[0347] Information relating to one or more QoE measurement sessions configured on a user device may include the status of one or more QoE measurement sessions (e.g., in progress, not in progress, completed, etc.). In one embodiment, the information may consist only of the status of in progress QoE measurement sessions. In such embodiments, the information may consist of a list of QoE measurement session identifiers, and the status itself (i.e., "in progress") may be implicit.

[0348] Information related to one or more QoE measurement sessions may additionally or alternatively include one or more indications of the time the user device was in an inactive or idle state before transitioning to a connected state, and one or more indications of the time or period during which one or more QoE measurement sessions were in progress while the user device 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 the UE spent in the RRC_INACTIVE state, for example, as a duration or as a timestamp of the time the UE was released into the RRC_INACTIVE state.

[0350] The second RAN node can send information about whether the session was in progress during RRC_INACTIVE. For example, from time a to time b, the UE was in progress, and b For example, the session was not running from time c to time c, and the session was running from time c to time d. As a simplified option, the second RAN node can indicate timestamps corresponding to the moments when the session started and / or ended during the RRC_INACTIVE state.

[0351] The second RAN node can configure the UE for situations in which it should send information related to one or more QoE measurement sessions to the first RAN node (e.g., triggers for sending information, types of information to be sent, etc.).

[0352] For example, the trigger for a UE with an active application session to initiate the RRC resume procedure may typically be the generation of uplink data that the application should send (e.g., a request to the application server, e.g., a request for streaming data). Alternatively, the trigger for the RRC resume procedure may be that the application session buffer becomes empty, falls below a certain threshold, or shows a decreasing trend. Alternatively, the trigger may be a paging message from the network. A paging message may be triggered by downlink application data that is pending to be sent to the UE. In the case of a UE in the RRC_INACTIVE state, the UE may be paged by RAN paging, and the reception of a page triggers the UE to initiate the RRC resume procedure and transition to the RRC_CONNECTED state. In the case of a UE in the RRC_IDLE state (which may be relevant to the context of this disclosure, in particular if future 3GPP releases allow UEs to retain QoE configurations in the RRC_IDLE state), the UE may be paged by CN paging, and the reception of a page triggers the UE to initiate the RRC setup procedure and transition to the RRC_CONNECTED state. Whether and / or what 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] One option is for the UE to also provide the network with a QoE-specific reason for initiating an RRC resume (e.g., reasons mentioned above, such as UL data to send, buffer exhaustion, etc.).

[0354] Whether the UE should provide session status information when a connection is resumed at a RAN node (or when the RRC setup procedure is performed after a period of RRC_IDLE state), and the type of information provided, 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 may, in the message releasing the UE to the RRC_INACTIVE state (or RRC_IDLE state), e.g., the RRCRelease message, indicate whether the UE should report any session status information it may provide to the RAN node that will perform the subsequent RRC resume procedure. Such instructions may indicate, for example, whether the UE should provide its session status information, whether it should only provide it if the session status has changed or is different 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 the UE should provide (only the latest / current session status, or a list of session status indicators, and / or additional information such as the duration of the RRC_INACTIVE state (or RRC_IDLE state)).

[0356] As yet another option, the instructions may be shown in the broadcast system information. If this option is used, one variation may be used as the default instructions and may be overridden or supplemented by instructions provided to the UE in one of the ways described above.

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

[0358] Instructions may be unconditional, but in some variations, they may depend on one or more conditions. For example, an instruction or part of an instruction may be conditional on the type of trigger in the RRC resume procedure (or RRC setup procedure), for instance, the instruction may depend on whether the trigger is an internal UE trigger or a page trigger.

[0359] Alternatively, the second RAN node can be configured to initiate an RRC resume and provide session information in conjunction with it when the session status changes, for example, when a session starts or ends.

[0360] Further conditions apply to UE internal triggers, which may include, for example, instructions that depend on whether the UE internal trigger is the generation of application data (of an application with the relevant QoE configuration to which the instructions apply) or another UE internal trigger.

[0361] Further conditions may apply when the trigger is a page, for example, the instruction may depend on whether the page was initiated by RAN or CN.

[0362] In another example, instructions, or parts of instructions, may be conditional on whether the first RAN node is the same as or different from the second RAN node. In this example, further possible conditions may apply if the instructions depend on whether the RAN node on which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as the old RAN node, for example, if the cell on which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as or different from the cell from which the UE was released to the RRC_INACTIVE state (or RRC_IDLE state).

[0363] In another example, instructions or parts of instructions may be conditional on whether the cell in which the UE performs the RRC resume procedure (or RRC setup procedure) is the same as or different from the cell in which the UE was released to the RRC_INACTIVE state (or RRC_IDLE state).

[0364] In another example, an instruction or part of an instruction may be conditioned by the type of state transition procedure (i.e., which state the UE leaves in order to enter the RRC_CONNECTED state), for example, an instruction may depend on whether the state transition procedure is an RRC resume procedure (which causes the UE to transition from the RRC_INACTIVE state to the RRC_CONNECTED state) or an RRC setup procedure (which causes the UE to transition from the RRC_IDLE state to the RRC_CONNECTED state).

[0365] Figure 11 shows examples of communication systems 1100 according to several embodiments.

[0366] In this example, the communication system 1100 includes a telecommunications network 1102 which includes an access network 1104 such as a radio access network (RAN) and a core network 1106 which includes 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 commonly referred to as network node 1110), or any other similar Third Generation Partnership Project (3GPP) access node or non-3GPP access point. The network nodes 1110 facilitate direct or indirect connection of user equipment (UEs), such as by connecting UEs 1112a, 1112b, 1112c, and 1112d (one or more of which may be commonly referred to as UE1112) to the core network 1106 via one or more radio connections.

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

[0368] Multiple UE1112 may be any of a wide variety of communication devices, including wireless devices that are positioned, configured, and / or operable to communicate wirelessly with network node 1110 and other communication devices. Similarly, network node 1110 is positioned, operable, configured, and / or operable to communicate directly or indirectly with UE1112 and and / or with other network nodes or devices in the telecommunications network 1102, enabling and / or providing network access such as wireless network access and / or performing other functions such as management within the telecommunications network 1102.

[0369] In the illustrated example, the core network 1106 connects network node 1110 to one or more hosts, such as host 1116. These connections may be made directly or indirectly through one or more intermediate networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 1106 includes one or more core network nodes (e.g., core network node 1108) structured with hardware and software components. The functionality of these components may be substantially similar to that described for the UE, network nodes, and / or hosts, and that description is generally applicable to the corresponding components of core network node 1108. Exemplary core network nodes include one or more of the following functions: Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscriber Identifier Deconcealing Function (SIDF), Unified Data Management (UDM), Security Edge Protected Proxy (SEPP), Network Exposure Function (NEF), and / or User Plane Function (UPF).

[0370] Host 1116 may be owned or controlled by a service provider other than the operator or provider of the access network 1104 and / or the telecommunications network 1102, and may be operated by or on behalf of the service provider. Host 1116 may host a variety of applications to provide one or more services. Examples of such applications include providing live and / or recorded audio / video content, data collection services, such as acquiring and aggregating data on various ambient conditions detected by multiple UEs, analytical 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] Overall, the communication system 1100 in Figure 11 enables connectivity between UEs, network nodes, and hosts. In this sense, the communication system can be configured to operate according to predefined rules or procedures, including, but not limited to, specific standards: for example, Global System for Mobile Communications (GSM), Universal Mobile Communications 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 Global 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 and Sigfox.

[0372] In some examples, the telecommunications network 1102 is a cellular network implementing 3GPP standardization features. Therefore, 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 massive machine communications (mMTC) / massive IoT services to further UEs.

[0373] In some examples, UE1112 is configured to transmit and / or receive information without direct human interaction. For example, the UE may be designed to transmit information to access network 1104 on a predetermined schedule, when triggered by internal or external events, or in response to requests from access network 1104. Furthermore, the UE may be configured to operate in single, multi-RAT, or multi-standards mode. For example, the UE can be configured to operate for 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 Figure 11, the hub 1114 communicates with the access network 1104 to facilitate indirect communication between one or more UEs (e.g., UE1112c 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 other communication device described herein with respect to the UE. For example, the hub 1114 may be a broadband router that enables access to the UE's core network 1106. In another example, the hub 1114 may be a controller that sends commands or instructions to one or more actuators within the UE. Commands or instructions may be received from the UE, the network node 1110, or by executable code, scripts, processes, or other instructions within the hub 1114. In yet another example, the hub 1114 may be a data collector that functions as temporary storage for UE data, and in some embodiments may perform data analysis or other processing. In yet another example, the hub 1114 may be a content source. For example, to a UE that is a VR headset, display, speaker, or other media distribution device, the hub 1114 can retrieve VR assets, video, audio, or other media or data related to sensory information via network nodes, and the hub 1114 then provides them to the UE either directly, after performing local processing, and / or after adding additional local content. In yet another example, the hub 1114 functions as a proxy server or orchestrator for the UEs, particularly when one or more UEs are low-energy IoT devices.

[0375] Hub 1114 can have a permanent / persistent or intermittent connection to network node 1110b. Hub 1114 may also allow different communication methods and / or schedules between Hub 1114 and UEs (e.g., UE 1112c and / or 1112d), and between Hub 1114 and the core network 1106. In other examples, Hub 1114 is connected to the core network 1106 and / or one or more UEs via a wired connection. Furthermore, 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 network node 1110 while remaining connected via Hub 1114 via a wired or wireless connection. In some embodiments, Hub 1114 may be a dedicated hub, i.e., a hub whose primary function is to route communication with UEs to and from network node 1110b. In other embodiments, the hub 1114 may be a non-dedicated hub, i.e., a device capable of routing communication between the UE and the network node 1110b, but also capable of additionally acting as a communication start and / or end point for a specific data channel.

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

[0377] A UE can support device-to-device (D2D) communication, for example, by implementing 3GPP standards for side-link communication, DSRC (dedicated narrow-band communication), 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 to be sold to or operated by a human user, but is not associated with, or may not initially be associated with, a specific human user (e.g., a smart sprinkler control unit). Alternatively, a UE may represent a device that is not intended to be sold to or operated by an end user, but may be associated with or operated for the benefit of a user (e.g., a smart electricity meter).

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

[0379] The processing circuit 1202 is configured to process instructions and data and may be configured to implement any sequential state machine capable of executing instructions stored in memory 1210 as machine-readable computer programs. The processing circuit 1202 may be implemented as one or more hardware-implemented state machines (e.g., discrete logic, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc.); programmable logic with appropriate firmware; one or more stored computer programs, general-purpose processors such as microprocessors or digital signal processors (DSPs), 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 may be capable of operating alone or in combination with other UE1200 components such as memory 1210 to provide the functionality of the UE1200. For example, the processing circuit 1202 may be configured to cause the UE1202 to perform actions as described with reference to Figures 7 and / or 8.

[0380] In this embodiment, the input / output interface 1206 may be configured to provide an interface to or to an input device, an output device, or one or more input devices and / or output devices. Examples of output devices include speakers, sound cards, video cards, displays, monitors, printers, actuators, emitters, smart cards, other output devices, or any combination thereof. Input devices may allow a user to take in information to the UE1200. Examples of input devices include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital video cameras, webcams, etc.), microphones, sensors, mice, trackballs, directional pads, trackpads, scroll wheels, smart cards, etc. A presence-sensitive display may include a capacitive touch sensor or a resistive touch sensor for sensing user input. Sensors may include, for example, an accelerometer, gyroscope, tilt sensor, force sensor, magnetometer, optical sensor, proximity sensor, biosensor, or any combination thereof. Output devices may use the same type of interface port as input devices. For example, a Universal Serial Bus (USB) port can be used to provide input and output devices.

[0381] In some embodiments, the power supply 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 supply 1208 may further include power circuits for supplying power to various parts of the UE 1200 from the power supply 1208 itself and / or an external power source via an interface such as an input circuit or a power cable. The power supply may be, for example, for charging the power supply 1208. The power circuit may perform any formatting, conversion, or other modification to make the power from the power supply 1208 suitable for each component of the UE 1200 being powered.

[0382] Memory 1210 is or is configured to include random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and other types of memory. In one example, 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 application, and corresponding data 1216. Memory 1210 can store any of a variety of operating systems or combinations of operating systems for use by UE 1200.

[0383] Memory 1210 can be configured to include numerous physical drive units such as a redundant array of independent disks (RAID), flash memory, USB flash drives, external hard disk drives, thumb drives, pen drives, key drives, high-density digital versatile disk (HD-DVD) optical disk drives, internal hard disk drives, Blu-ray optical disk drives, holographic digital data storage (HDS) optical disk drives, smart card memory such as an external mini dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external microDIMM SDRAM, tamper-resistant module in the form of a universal integrated circuit card (UICC) containing one or more subscriber identity modules (SIMs) such as 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". Memory 1210 may enable UE 1200 to access instructions, application programs, etc., stored on transient or non-transient memory media, offload data, or upload data. Products that utilize communication systems, etc., may be realized as memory 1210 or in contact with memory 1210, and this may be a device-readable storage medium or may 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, may include an antenna 1222, or may be communicatively coupled to the antenna 1222. The communication interface 1212 may include one or more transceivers used for communication, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or network node in the access network). Each transceiver may include a transmitter 1218 and / or receiver 1220 suitable for providing network communication (e.g., optical, electrical, frequency-allocated, etc.). Furthermore, the transmitter 1218 and receiver 1220 may be coupled to one or more antennas (e.g., antenna 1222), may share circuit components, software or firmware, or may be implemented separately.

[0385] In some embodiments, the communication functions of the communication interface 1212 may include short-range communication such as cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, Bluetooth®, location-based communication such as the use of the Global Positioning System (GPS) for determining location, other similar communication functions, or any combination thereof. Communication may be carried out 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, and Hypertext Transfer Protocol (HTTP).

[0386] Regardless of the sensor type, the UE can provide the output of data captured by its sensor via its communication interface 1212, through a wireless connection to a network node. Data captured by the UE's sensor can be communicated to a network node via a wireless connection through another UE. The output may be periodic (e.g., once every 15 minutes if reporting sensed temperature), random (e.g., to equalize the load from reports from multiple sensors), 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 a patient).

[0387] As another example, a UE may include actuators, motors, or switches associated with a communication interface configured to receive radio input from a network node via a wireless connection. In response to the received radio input, the state of the actuators, motors, or switches may change. For example, a UE could configure a motor to adjust the control surface or rotors 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] If a 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, which include, but are not limited to, urban wearable technology, augmented industrial applications, and healthcare. Non-exclusive examples of such IoT devices include devices or onboard equipment such as: connected refrigerators or freezers, televisions, connected lighting systems, electricity meters, robotic vacuum cleaners, voice-controlled smart speakers, home security cameras, motion sensors, thermostats, smoke detectors, door / window sensors, flood / humidity sensors, electric door locks, connected doorbells, air conditioning systems such as heat pumps, autonomous vehicles, surveillance systems, weather monitoring devices, vehicle parking monitoring devices, electric vehicle charging stations, smartwatches, fitness trackers, head-mounted displays for augmented reality (AR) or virtual reality (VR), haptic or sensory augmentation wearables, sprinklers, animal or object tracking devices, plant or animal monitoring sensors, industrial robots, unmanned aerial vehicles (UAVs), and all kinds of medical devices such as heart rate monitors and remotely operated surgical robots. The UE in the form of an IoT device consists of 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 the UE1200 shown in Figure 12.

[0389] In yet another specific example, in an IoT scenario, a UE might represent a machine or other device that performs monitoring and / or measurement and transmits the results of such monitoring and / or measurement to another UE and / or network node. In this case, the UE could be an M2M device, sometimes referred to as an MTC device in the context of 3GPP. As a specific example, a UE could implement the 3GPP NB-IoT standard. In other scenarios, a UE might 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, the first UE might be the drone itself, or integrated into the drone and acting as a remote controller, providing the second UE with drone speed information (obtained via a speed sensor). When the user makes changes from the remote controller, the first UE can adjust the drone's throttle (for example, by controlling actuators) to increase or decrease the drone's speed. The first UE and / or the second UE could also include one or more of the functions described above. For example, the UE could include sensors and actuators and handle communication of data from both the speed sensor and the actuators.

[0391] Figure 13 shows network node 1300 according to several embodiments. As used herein, a network node is a device that is configured, located, and / or operable in a telecommunications network and can communicate directly or indirectly with a UE and / or other network nodes or devices. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points) and 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, in other words, their transmit power level), and therefore may be called femto base stations, pico base stations, micro base stations, 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 relaying. 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 called a remote radio head (RRH)). Such remote radio units may or may not be integrated with an antenna as an antenna-integrated radio. Some parts of a distributed radio base station may be called nodes of a distributed antenna system (DAS).

[0393] Other examples of network nodes include multi-transmit point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR_BS, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base station transceiver stations (BTSs), transmit points, transmit nodes, multi-cell / multicast coordination entities (MCEs), operation and maintenance (O&M) nodes, operation support system (OSS) nodes, self-organizing network (SON) nodes, positioning nodes (e.g., Evolutionary Serving Mobile Location Centers (E-SMLCs)), and / or minimized driven tests (MDTs).

[0394] The network node 1300 includes a processing circuit 1302, memory 1304, communication interface 1306, and power supply 1308, and / or any other components, or any combination thereof. The network node 1300 may consist of multiple physically distinct components (e.g., a NodeB component and an RNC component, or a BTS component and a BSC component), each of which may have its own component. In certain scenarios where the network node 1300 consists of multiple distinct components (e.g., BTS and BSC components), one or more of the distinct 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 distinct 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). The network node 1300 may also include multiple sets of various illustrated components for different wireless technologies integrated into the network node 1300, such as GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, RFID (Radio Frequency Identification), or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chips or chipsets and other components within the network node 1300.

[0395] The processing circuit 1302 consists 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 encoded logic, and can operate alone or in combination with other network node 1300 components such as memory 1304 to provide functionality for the network node 1300. For example, the processing circuit 1302 may be configured to cause the network node to perform actions as described with reference to Figures 9 and / or 10.

[0396] In some embodiments, the processing circuit 1302 includes a system-on-a-chip (SOC). In some embodiments, the processing circuit 1302 includes one or more of the radio frequency (RF) transceiver circuit 1312 and the 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), substrates, 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, substrate, or unit.

[0397] Memory 1304 may consist of any form of volatile or non-volatile computer-readable memory, including, but not limited to, persistent memory, solid-state memory, remote-mount memory, magnetic media, optical media, random-access memory (RAM), read-only memory (ROM), and 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-transient, device-readable and / or computer-executable memory device, for storing information, data, and / or instructions that can be used by processing circuit 1302. Memory 1304 may store any appropriate instructions, data, or information, including applications that include one or more computer programs, software, logic, rules, code, tables, and / or other instructions, which are executed by processing circuit 1302 and can be used by network node 1300. Memory 1304 may be used to store any calculations performed by processing circuit 1302 and / or any data received via communication interface 1306. In some embodiments, the processing circuit 1302 and the memory 1304 are integrated.

[0398] Communication interface 1306 is used in wired or wireless signaling and / or data between network nodes, access networks, and / or UEs. As illustrated, communication interface 1306 includes, for example, port(s) / terminal(s) 1316 for sending and receiving data to and from the network via a wired connection. Communication interface 1306 also includes a wireless front-end circuit 1318 which may be coupled to or, in certain embodiments, part of antenna 1310. The wireless front-end circuit 1318 consists of a filter 1320 and an amplifier 1322. The wireless front-end circuit 1318 may be connected to antenna 1310 and processing circuit 1302. The wireless front-end circuit may be configured to adjust signals communicated between antenna 1310 and processing circuit 1302. The wireless front-end circuit 1318 may receive digital data transmitted to other network nodes or UEs via a wireless connection. The wireless front-end circuit 1318 may use a combination of the filter 1320 and / or the amplifier 1322 to convert the digital data into a radio signal having appropriate channel and bandwidth parameters. The radio signal can then be transmitted via the antenna 1310. Similarly, when receiving data, the antenna 1310 can collect the radio signal, which is converted into digital data by the wireless front-end circuit 1318. The digital data may be passed to the processing circuit 1302. In other embodiments, the communication interface may consist of different components and / or combinations of different 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 circuit and is connected to the antenna 1310. Similarly, in some embodiments, all or part of the RF transceiver circuit 1312 is part of the communication interface 1306. In yet another embodiment, the communication interface 1306, as part of a radio unit (not shown), includes one or more ports or terminals 1316, the radio front-end circuit 1318, and the RF transceiver circuit 1312, and the communication interface 1306 communicates with a baseband processing circuit 1314, which is part of a digital unit (not shown).

[0400] Antenna 1310 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals. Antenna 1310 may be coupled to the wireless front-end circuit 1318 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In certain embodiments, Antenna 1310 is separate from the network node 1300 and can be connected 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 as described herein as being performed by a network node. Any information, data, and / or signals may be received from the 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 as described herein as being performed by a network node. Any information, data, and / or signals may be transmitted to the UE, another network node, and / or any other network equipment.

[0402] Power supply 1308 supplies power to the various components of network node 1300 in a form suitable for each component (for example, at the voltage and current levels required for each component). Power supply 1308 may further include, or be coupled to, a power management circuit for supplying power to the components of network node 1300 to perform the functions described herein. For example, 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, thereby supplying power to the power circuit of power supply 1308. As a further example, power supply 1308 may consist of a power source in the form of a battery or battery pack connected to or integrated into the power circuit. The battery can provide backup power in the event of a failure of the external power source.

[0403] Embodiments of network node 1300 may include additional components other than those shown in Figure 13 to provide a particular aspect 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 equipment to enable input of information to and output of information from network node 1300. This would allow a user to perform diagnostic, maintenance, repair, and other management functions of network node 1300.

[0404] Figure 14 is a block diagram of a host 1400, which may be an embodiment of host 1116 in Figure 11, according to various aspects described herein. As used herein, host 1400 may be or consist of various combinations of hardware and / or software, including standalone servers, blade servers, cloud implementation servers, distributed servers, virtual machines, containers, or processing resources in a server farm. Host 1400 can provide one or more services to one or more UEs.

[0405] The host 1400 includes an input / output interface 1406, a network interface 1408, a power supply 1410, and a processing circuit 1402 operably coupled via a bus 1404 to a memory 1412. Other embodiments may include other components. The characteristics of these components may be substantially similar to those described with respect to devices in earlier figures such as Figures 12 and 13, so that their description may be generally applicable to the corresponding components of the 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, for example, data generated by the UE for host 1400, or data generated by host 1400 for the UE. Embodiments of host 1400 may utilize only a subset or all of the components shown. The host application program 1414 may be implemented in a container-based architecture and provides support for video coding (e.g., Multipurpose Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application program 1414 may also provide user authentication and license checks and periodically report health, routing, and content availability to a central node, such as a device within or at the edge of the core network. Therefore, 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), and Dynamic Adaptive Streaming over HTTP (MPEG-DASH).

[0407] Figure 15 is a block diagram showing a virtualized environment 1500 in which functions implemented by several embodiments may be virtualized. In this specification, virtualization means creating a virtual version of an apparatus or device, which may include virtualizing hardware platforms, storage devices, and networking resources. As used herein, virtualization can be applied to any apparatus or component described herein and relates to an implementation in which at least a portion of the functions are implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components run by one or more virtual machines (VMs) implemented in one or more virtualized environments 1500 hosted by one or more hardware nodes, such as network nodes, UEs, core network nodes, or hardware computing devices acting as hosts. Furthermore, in embodiments where the virtual nodes do not require radio connectivity (e.g., core network nodes or hosts), the nodes may be fully virtualized.

[0408] Application 1502 (which may alternatively be referred to as a software instance, virtual appliance, network function, virtual node, virtual network function, etc.) runs in the virtualization environment Q400 to implement some of the features, functions, and / or benefits of the embodiments disclosed herein.

[0409] Hardware 1504 includes processing circuits, memory for storing software and / or instructions executable by the hardware processing circuits, and / or other hardware devices as described herein, such as network interfaces and input / output interfaces. The software may be executed by the processing circuits to instantiate one or more virtualization layers 1506 (also called hypervisors or virtual machine monitors (VMMs)), provide VMs 1508a and 1508b (one or more of which can generally be referred to as VMs 1508), and / or perform any of the functions, features and / or benefits described in relation to some embodiments described herein. The virtualization layer 1506 can present a virtual operating platform that looks like network hardware to multiple VMs 1508.

[0410] VM1508 consists of virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and may be run by the corresponding virtualization layer 1506. Different embodiments of instances of the virtual appliance 1502 may be implemented on one or more VM1508, and the implementation may be carried out in different ways. Hardware virtualization is referred to in some contexts as network function virtualization (NFV). NFV may be used to integrate many types of network equipment into industry-standard high-capacity server hardware, physical switches, physical storage, and customer premises equipment that can be deployed in a data center.

[0411] In the context of NFV, VM1508 may be a software implementation of a physical machine that runs a program as if it were running on a physical, non-virtualized machine. Each VM1508, and that portion of the hardware 1504 running its VM (hardware dedicated to that VM, and / or hardware shared by that VM with other VMs), forms a separate virtual network element. Still in the context of NFV, the virtual network function runs on one or more VM1508s on the hardware 1504 and is responsible for handling specific network functions corresponding to application 1502.

[0412] Hardware 1504 can be implemented as a standalone network node with general-purpose or specific components. Hardware 1504 can implement several functions through virtualization. Alternatively, hardware 1504 may be part of a larger cluster of hardware (e.g., within a data center or CPE) where many hardware nodes cooperate and are managed via management and orchestration 1510, particularly overseeing the lifecycle management of application 1502. In some embodiments, 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 suitable network interfaces, or it 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 can be used alternatively for communication between hardware nodes and the radio unit.

[0413] Figure 16 shows a communication diagram of host 1602 communicating with UE 1606 via network node 1604 over a partial wireless connection, according to several embodiments. Exemplary implementations of various embodiments of the UEs discussed in the previous paragraph (such as UE 1112a in Figure 11 and / or UE 1200 in Figure 12), network nodes (such as network node 1110a in Figure 11 and / or network node 1300 in Figure 13), and hosts (such as host 1116 in Figure 11 and / or host 1400 in Figure 14) are described here with reference to Figure 16.

[0414] Similar to host 1400, embodiments of host 1602 include hardware such as a communication interface, processing circuitry, and memory. Host 1602 also includes software that is stored in or accessible by host 1602 and executable by the processing circuitry. The software may include a host application that can operate to serve remote users, such as UE 1606, which connects via an over-the-top (OTT) connection 1650 extending between UE 1606 and host 1602. When serving remote users, the host application may provide user data transmitted using the OTT connection 1650.

[0415] Network node 1604 includes hardware that enables communication with host 1602 and UE 1606. The connection 1660 may be direct or may pass through a core network (such as core network 1106 in Figure 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] UE1606 includes hardware and software, the software of which is stored in or accessible by UE1606 and executable by the UE's processing circuitry. The software includes client applications such as a web browser or operator-specific “apps,” and may be able to operate to provide services to human or non-human users via UE1606 with the support of host 1602. On host 1602, a running host application can communicate with a running client application via an OTT connection 1650 that terminates at UE1606 and host 1602. In providing services to a user, the UE's client application may receive request data from the host's host application and provide user data in response to the request data. The OTT connection 1650 may transfer both the request data and the user data. The UE's client application can 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 connection 1660 between host 1602 and network node 1604, and via wireless connection 1670 between network node 1604 and UE 1606, in order to provide a connection between host 1602 and UE 1606. Connections 1660 and wireless connection 1670, which the OTT connection 1650 may provide, are described abstractly to illustrate communication between host 1602 and UE 1606 via network node 1604, and no explicit reference is made to any intermediary devices or the precise routing of messages through these devices.

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

[0419] In some examples, UE1606 runs a client application that provides user data to host 1602. User data may be provided as a response to or in response to data received from host 1602. Thus, in step 1616, UE1606 may provide user data that can be provided by running a client application. When providing user data, the client application may further consider user input received from the user via the input / output interface of UE1606. Regardless of the particular way in which the user data is provided, in step 1618, UE1606 initiates transmission of the user data toward host 1602 via network node 1604. In step 1620, in accordance with the teachings of embodiments described throughout this disclosure, network node 1604 receives user data from UE1606 and initiates transmission of the received user data toward host 1602. In step 1622, host 1602 receives the user data carried in the transmission initiated by UE1606.

[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, in which the wireless connection 1670 forms the final segment. More precisely, the teachings of these embodiments can improve the data rate, latency, power consumption, etc., of the UE and / or network nodes, 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 host 1602. In another example, host 1602 may process audio and video data that may have been taken from the UE for use in creating maps. In yet another example, host 1602 may collect and analyze real-time data to help control vehicle congestion (e.g., control traffic signals). In yet another example, host 1602 may store surveillance video uploaded by the UE. In yet another example, host 1602 may store or control access to media content such as video, audio, VR, or AR that can be broadcast, multicast, or unicast to the UE. In yet another example, host 1602 may be used for energy pricing, remote control of non-temporary electrical loads to balance power generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices), or any other function of data collection, retrieval, storage, analysis, and / or transmission.

[0422] In some examples, measurement procedures may be provided for the purpose of monitoring data rate, latency, and other factors that one or more embodiments improve. Further optional network functions may exist for reconfiguring the OTT connection 1650 between host 1602 and UE 1606 in response to variations in the measurement results. The measurement procedures and / or network functions for reconfiguring the OTT connection may be implemented in the software and hardware of host 1602 and / or UE 1606. In some embodiments, sensors (not shown) may be deployed in or in relation to other devices through which the OTT connection 1650 passes; sensors may participate in the measurement procedures by supplying values ​​of the monitored quantities exemplified above, or by supplying values ​​of other physical quantities that the software can calculate or estimate. Reconfiguration of the OTT connection 1650 may include message formatting, retransmission settings, preferred routing, etc.; the reconfiguration does not need to directly change the operation of network node 1604. Such procedures and functionalities are known and can be implemented in the art. In certain embodiments, the measurements may include proprietary UE signaling that facilitates measurements such as throughput, propagation time, and latency by host 1602. The measurements may also be implemented by software that uses the OTT connection 1650 to send messages, particularly empty or "dummy" messages, while monitoring propagation time, errors, etc.

[0423] The computing devices described herein (e.g., UEs, network nodes, hosts) may include combinations of illustrated hardware components, but other embodiments may include computing devices having different combinations of components. It should be understood that these computing devices may consist of any suitable combination of hardware and / or software necessary to perform the tasks, features, functions, and methods disclosed herein. The decisions, calculations, acquisitions, or similar operations described herein may be performed by processing circuits, which may process information by, for example, converting acquired information into other information, comparing acquired or converted information with information stored in network nodes, and / or performing one or more operations based on the acquired or converted information, and may make decisions as a result of such processing. Furthermore, while components are depicted as a single box arranged within a larger box, or as boxes nested within multiple boxes, in practice, computing devices may consist of multiple different physical components constituting a single illustrated component, and functions may be divided between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functions of a component may be divided between the processing circuit and the communication interface. In another example, the non-computationally intensive functions of such components may be implemented in software or firmware, while the computationally intensive functions may be implemented in hardware.

[0424] In certain embodiments, some or all of the functions described herein may be provided by a processing circuit that executes instructions stored in memory, which in certain embodiments may be a computer program product in the form of a non-transient computer-readable storage medium. In alternative embodiments, some or all of the functions may be provided by a processing circuit without executing instructions stored in a separate or discrete device-readable storage medium, such as a hardwired system. In any of those particular embodiments, whether or not it executes instructions stored in a non-transient computer-readable storage medium, the processing circuit can be configured to perform the functions described. The benefits provided by such functionality are not limited to the processing circuit alone or to other components of the computing device, but are enjoyed by the computing device as a whole and / or by the end user and wireless networks in general.

[0425] To avoid misunderstanding, the following numbered descriptions indicate embodiments of this disclosure: Group A Embodiment 1. A method performed by a user device, the method is: When transitioning to the connected state: Connecting to the first Radio Access Network (RAN) node of the communication network, Transmitting information related to one or more quality-of-experience (QoE) measurement sessions configured in the user device to the communication network, Methods that include... 2. The one or more QoE measurement sessions are configured in the user device by the first or second RAN node of the communication network. The method according to Embodiment 1. 3. The one or more QoE measurement sessions are configured on the user device during a previous instance of the user device in the connected state. The method according to Embodiment 1 or 2. 4. The information relating to one or more QoE measurement sessions includes the values ​​of one or more parameters that have changed since the user device transitioned from the connected state to the inactive or idle state in the previous instance. The method according to Embodiment 3. 5. The transition to the connected state includes either resuming the connection from the inactive state or establishing the connection from the idle state. A method according to any one of the preceding embodiments. 6. The information relating to one or more QoE measurement sessions configured in the user device includes the status of the one or more QoE measurement sessions. A method according to any one of the preceding embodiments. 7. The status of the QoE measurement session includes one of the following: In Progress, Not In Progress, or Completed. The method according to Embodiment 6. 8. The information relating to one or more QoE measurement sessions configured in the user device includes one or more indications of the time when the user device was in an inactive or idle state before transitioning to the connected state, and the time or period when one or more QoE measurement sessions were in progress or not in progress while the user device was in an inactive or idle state. A method according to any one of the preceding embodiments. 9. The information relating to one or more QoE measurement sessions configured in the user device includes information on one or more ongoing QoE measurement sessions. A method according to any one of the preceding embodiments. 10. The information relating to one or more QoE measurement sessions is transmitted to the first RAN node in a connection resume request message or a connection establishment request message. A method according to 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 the embodiments 1 to 9. 12. The information relating to one or more QoE measurement sessions is transmitted to the first RAN node in response to a request message received from the first RAN node. The method according to any one of the embodiments 1 to 9. 13. The information relating to one or more QoE measurement sessions is transmitted to the first RAN node in response to one or more of the following: the configuration received from the communication network and the type of event that triggered the user device to transition to the connected state. A method according to any one of the preceding embodiments. 14. A method performed by a user device, the method is: While in an inactive connection state: This includes transmitting information related to one or more quality-of-experience (QoE) measurement sessions configured in the user device to a first radio access network (RAN) node of the communication 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. The method described in Embodiment 14. 16. The information relating to one or more QoE measurement sessions configured in the user device includes the status of the one or more QoE measurement sessions. The method according to Embodiment 14 or 15. 17. The status of the QoE measurement session includes one of the following: In Progress, Not In Progress, Completed. The method according to Embodiment 16. 18. The user device is released to the inactive connected state by the first RAN node. The method according to any one of Embodiments 14 to 17. 19. The information relating 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 device was released to the inactive connection state successfully terminates; a QoE measurement session that was in progress when the user device was released to the inactive connection state fails and terminates; a new application session is started; one or more status changes of an application session that was in progress when the user device was released to the inactive connection state; one or more status changes of an application session that was started after the user device was released to the inactive connection state; a timer has expired or is running; the user device has re-selected a new cell; or the amount of data is below a threshold. The method according to any one of Embodiments 14 to 18. 20. Providing user data, Transferring the user data to the host via the transmission to the network node, Includes A method according to any one of the preceding embodiments. Group B Embodiment 21. A method performed by a first network node of a communication network, the method being: When the user device connects to the first network node and transitions to the connected state: This includes receiving information related to one or more quality-of-experience (QoE) measurement sessions configured in the user device from one or more of the user device and the second network nodes of the communication network. method. 22. The one or more QoE measurement sessions are configured in the user device by the first network node or the second network node of the communication network. The method according to Embodiment 21. 23. The one or more QoE measurement sessions are configured on the user device during a previous instance of the user device in the connected state. The method according to Embodiment 21 or 22. 24. The information relating to one or more QoE measurement sessions is received from the user device and includes the values ​​of one or more parameters that have changed since the user device transitioned from the previous instance in the connected state to an inactive or idle state. The method according to Embodiment 23. 25. The information relating to one or more QoE measurement sessions is received from the user device and the second network node, and the information received from the second network node is overwritten by the information received from the user device. The method according to Embodiment 24. 26. The user device transitioning to the connected state includes either resuming the connection from an inactive state or establishing the connection from an idle state. The method according to any one of Embodiments 21 to 25. 27. The information relating to one or more QoE measurement sessions configured in the user device includes the status of the one or more QoE measurement sessions. The method according to any one of embodiments 21 to 26. 28. The status of the QoE measurement session includes one of the following: in progress, not in progress, or completed. The method according to Embodiment 27. 29. The information relating to one or more QoE measurement sessions configured in the user device includes one or more indications of the time when the user device was in an inactive or idle state before transitioning to the connected state, and the time or period when one or more QoE measurement sessions were in progress or not in progress while the user device was in an inactive or idle state. The method according to any one of Embodiments 21 to 28. 30. The information relating to one or more QoE measurement sessions configured in the user device includes information on one or more ongoing QoE measurement sessions. The method according to any one of embodiments 21 to 29. 31. The information relating to one or more QoE measurement sessions is received from the user device in a connection resume request message or a connection establishment request message. The method according to any one of embodiments 21 to 30. 32. The information relating to one or more QoE measurement sessions is received from the user device 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. The method according to any one of embodiments 21 to 30. 33. The information relating to one or more QoE measurement sessions is received from the user device in response to a request message sent by the first network node to the user device. The method according to any one of embodiments 21 to 30. 34. The information relating to one or more QoE measurement sessions is received from the user device in response to one or more of the following: the configuration of the user device by the communication network, and the type of event that triggered the user device to transition to the connected state. The method according to any one of embodiments 21 to 33. 35. A method performed by a second network node, wherein the second network node is providing services to a user device released to an inactive or idle connection state, and the method is The user device transitions to a connected state and subsequently transmits information related to one or more quality-of-experience (QoE) measurement sessions configured in the user device to a first network node to which it has been connected. method. 36. The information relating to one or more QoE measurement sessions configured in the user device includes the status of the one or more QoE measurement sessions. The method according to Embodiment 35. 37. The status of the QoE measurement session includes one of the following: in progress, not in progress, or completed. The method according to embodiment 36. 38. The information relating to one or more QoE measurement sessions configured in the user device includes one or more of the following: an indication of the time the user device was in an inactive or idle state before transitioning to the connected state; an indication of the time the user device was released to an inactive or idle connected state; an indication of the final value of one or more QoE parameters reported to the second network node before the user device was released to the inactive or idle connected state; and an indication of the time or period during which one or more QoE measurement sessions were in progress or not in progress while the user device was in an inactive or idle state. The method according to any one of embodiments 35 to 37. 39. The information relating to one or more QoE measurement sessions configured in the user device includes information on one or more ongoing QoE measurement sessions. The method according to any one of embodiments 35 to 38. 40. Obtaining user data, Transferring the aforementioned user data to a host or user device, Includes A method according to any one of the preceding embodiments. Group C Embodiment 41. User device, The user device includes a processing circuit configured to perform any of the steps of the embodiment of Group A, A power supply circuit configured to supply power to the aforementioned processing circuit, A user device equipped with the following features. 42. A network node, said network node is The network node is configured to perform any of the steps of the embodiment of Group B, A power circuit configured to supply power to the aforementioned processing circuit, A network node equipped with these features. 43. User equipment (UE), the UE is An antenna configured to transmit and receive wireless signals, A wireless front-end circuit connected to the antenna and processing circuit and configured to adjust the signals communicated between the antenna and the processing circuit, The processing circuit is configured to perform any of the steps of the embodiment of Group A, An input interface connected to the processing circuit and configured to allow information processed by the processing circuit to be input to the UE, 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 supply power to the UE, A UE equipped with 44. A host configured to operate in a communication system to provide over-the-top (OTT) services, A processing circuit configured to provide user data, A network interface configured to initiate the transmission of the user data to the cellular network for transmission to a user device (UE), Equipped with, The UE includes a communication interface and processing circuitry, and the UE's communication interface and processing circuitry are configured to perform any of the steps of the Group A embodiment in order to receive the user data from the host. host. 45. The cellular network further comprises network nodes configured to communicate with the UE in order to transmit the user data from the host to the UE. The host of the aforementioned embodiment. 46. ​​The host processing circuit is configured to execute the host application, thereby providing the user data. The host application is configured to interact with a client application running on the UE, and the client application is associated with the host application. The host of the two embodiments described above. 47. A method performed by a host operating in a communication system further including network nodes and user equipment (UEs), Providing user data to the UE, Initiating a transmission to transmit user data to a UE via a cellular network including network nodes, wherein the UE performs or initiates any of the actions of Group A embodiments to receive user data from the host. Methods that include... 48. Further includes running a host application on the host that is related to a client application running on the UE in order to receive user data from the UE. The method of the embodiment described above. 49. On a host, sending input data to a client application running on the UE, the input data being provided by running the host application, further including sending, User data is provided by the client application in response to input data from the host application. The method of the embodiment described above. 50. A host configured to operate in a communication system to provide over-the-top (OTT) services, wherein the host is A processing circuit configured to provide user data, A network interface configured to initiate the transmission of user data to a cellular network for transmission to a user device (UE), Equipped with, The UE includes a communication interface and processing circuitry, and the UE's communication interface and processing circuitry are configured to perform any of the steps of the Group A embodiment to transmit user data to a host. host. 51. The cellular network further includes network nodes configured to communicate with the UE to send user data from the UE to the host. The host of the aforementioned embodiment. 52. The host processing circuit is configured to run the host application, thereby providing user data. The host application is configured to interact with client applications running on the UE, and the client applications are associated with the host application. The host of the two embodiments described above. 53. A method performed by a host configured to operate in a communication system further including network nodes and user equipment (UE), the method being: The host receives user data transmitted to the host by the UE via a network node, the UE performing any of the steps of the Group A embodiment to transmit the user data to the host, and receiving the data. method. 54. The host further includes running a host application associated with a client application running on the UE in order to receive user data from the UE. The method of the embodiment described above. 55. On a host, sending input data to a client application running on the UE, the input data being provided by running the host application, further including sending, User data is provided by the client application in response to input data from the host application. The method of the embodiment described above. 56. A host configured to operate in a communication system to provide over-the-top (OTT) services, A processing circuit configured to provide user data, A network interface configured to initiate the transmission of user data to a network node of a cellular network for transmission to a user device (UE), wherein the network node has a communication interface and processing circuitry, and the processing circuitry of the network node is configured to perform any of the operations of any of the embodiments of Group B in order to transmit user data from the host to the UE. host. 57. The host processing circuit is configured to run a host application that provides user data. The UE includes processing circuitry configured to run client applications associated with the host application in order to receive user data transmitted from the host. The host of the aforementioned embodiment. 58. A method performed on a host configured to operate in a communication system further including network nodes and user equipment (UEs), To provide user data for UE, Initiating a transmission to transport user data to the UE via a cellular network including network nodes, wherein the network nodes initiate any of the operations of the Group B embodiment in order to transmit user data from the host to the UE. Methods that include... 59. Further includes transmitting user data provided from the host to the UE at the network node. The method of the embodiment described above. 60. User data is provided on the host by running a host application that interacts with a client application running on the UE, and the client application is associated with the host application. The method of either of the two embodiments described above. 61. A communication system configured to provide over-the-top services, wherein the communication system is Being a host, A processing circuit configured to provide user data to a user device (UE), wherein the user data is associated with an over-the-top service, and the processing circuit A network interface configured to initiate the transmission of user data toward a cellular network node for transmission to a UE, wherein the network node comprises a communication interface and processing circuitry, the processing circuitry of the network node is configured to perform any of the operations of the Group B embodiment for transmitting user data from the host to the UE, Equipped with Communication system. 62. Network node; and / or User device To further enhance The communication system of the embodiment described above. 63. A host configured to operate in a communication system to provide over-the-top (OTT) services, A processing circuit configured to initiate the reception of user data, A network interface configured to receive user data from a network node of a cellular network, wherein the network node has a communication interface and processing circuitry, and the processing circuitry of the network node is configured to perform any of the operations of the Group B embodiment in order to receive user data from a user device (UE), A host equipped with these features. 64. The host processing circuit is configured to run the host application, thereby providing user data. The host application is configured to interact with client applications running on the UE, and the client applications are associated with the host application. The host of the aforementioned embodiment. 65. Initiating the reception of user data includes requesting user data. A host according to either of the two embodiments described above. 66. A method performed by a host configured to operate in a communication system further including network nodes and user equipment (UEs), The host initiates receiving user data from the UE, the user data originating from a transmission received by the network node from the UE, and the network node initiates performing any of the steps of the Group B embodiment to receive user data from the UE for the host. method. 67. Further includes transmitting received user data to a host at a network node. The method of the embodiment described above.

Claims

1. A method performed by a user device (1200), the method is: When transitioning to the connected state: Connecting to the first wireless access network (RAN) node of the communication network (706), Transmitting information related to one or more quality of experience (QoE) measurement sessions configured in the user device (1200) to the communication network (708), Includes, The one or more QoE measurement sessions are configured in the user device (1200) during a previous instance of the user device (1200) in the connected state. The information relating to the one or more QoE measurement sessions includes the status of the one or more QoE measurement sessions. method.

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

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

4. The transition to the connected state includes either resuming the connection from the inactive state or establishing the connection from the idle state. The method according to claim 1.

5. The status of the QoE measurement session includes one of the following: in progress, not in progress, or completed. The method according to claim 1.

6. The information relating to one or more QoE measurement sessions includes one or more indications of the time when the user device (1200) was in an inactive or idle state before transitioning to the connected state, and indications of the time or period when one or more QoE measurement sessions were in progress or not in progress while the user device (1200) was in an inactive or idle state. The method according to claim 1.

7. The information relating to one or more QoE measurement sessions includes information from one or more ongoing QoE measurement sessions. The method according to claim 1.

8. The information relating to one or more QoE measurement sessions is: In a connection resume request message or connection establishment request message, In a message confirming the establishment of a connection with the first RAN node or the resumption of the connection with the first RAN node, In the response to the request message received from the first RAN node, Transmitted to the first RAN node. The method according to claim 1.

9. The information relating to one or more QoE measurement sessions is transmitted to the first RAN node in response to one or more of the following: a configuration received from the communication network and the type of trigger for causing the user device (1200) to transition from an inactive or idle state to the connected state. The method according to claim 1.

10. A method performed by a first network node of a communication network, the method is When the user device (1200) connects to the first network node and transitions to the connected state: Receiving information (902, 904) from one or more of the user device (1200) and the second network nodes of the communication network relating to one or more quality-of-experience (QoE) measurement sessions configured in the user device (1200), wherein the one or more QoE measurement sessions are configured in the user device (1200) during a previous instance of the user device (1200) in the connected state, including receiving (902, 904). The information relating to the one or more QoE measurement sessions includes the status of the one or more QoE measurement sessions. method.

11. The one or more QoE measurement sessions are configured in the user device (1200) by the first network node or the second network node of the communication network. The method according to claim 10.

12. The information relating to one or more QoE measurement sessions is received from the user device (1200) and includes the values ​​of one or more parameters that have changed after the user device (1200) transitioned from the previous instance in the connected state to an inactive or idle state. The method according to claim 10.

13. The information relating to one or more QoE measurement sessions is received from the user device (1200) and the second network node, and the information received from the second network node is overwritten by the information received from the user device (1200). The method according to claim 12.

14. The user device (1200) transitioning to the connected state includes either resuming the connection from an inactive state or establishing a connection from an idle state. The method according to claim 10.

15. The status of the QoE measurement session includes one of: in progress, not in progress, or completed. The method according to claim 10.

16. A method performed by a second network node, wherein the second network node provides services to a user device (1200) that has been released from the second network node and is in an inactive or idle connection state, and the method is The user device (1200) transitions to a connected state and then transmits information related to one or more quality-of-experience (QoE) measurement sessions configured in the user device (1200) to the first network node to which it has been connected (1004). fruit, The information relating to the one or more QoE measurement sessions includes the status of the one or more QoE measurement sessions. method.

17. The status of the QoE measurement session includes one of the following: in progress, not in progress, or completed. The method according to claim 16.

18. User device (1200), When transitioning to the connected state, the user device (1200) will receive the following: Connect to the first wireless access network (RAN) node (706) of the communication network. The user device (1200) transmits (708) information related to one or more quality of experience (QoE) measurement sessions configured in the user device (1200) to the communication network, and the one or more QoE measurement sessions are configured in the user device (1200) during a previous instance of the user device (1200) in the connected state. A processing circuit (1202) configured as follows, A power supply circuit configured to supply power to the aforementioned processing circuit, Equipped with, The information relating to the one or more QoE measurement sessions includes the status of the one or more QoE measurement sessions. User device.

19. The processing circuit (1202) is further configured to cause the user device (1200) to perform the method according to any one of claims 2 to 9. The user device (1200) according to claim 18.

20. A first network node, the first network node is When the user device (1200) connects to the first network node and transitions to the connected state, the first network node will A processing circuit is configured to receive (902, 904) information related to one or more quality-of-experience (QoE) measurement sessions configured in the user device (1200) from one or more of the user device (1200) and the second network nodes of the communication network, wherein the one or more QoE measurement sessions are configured in the user device (1200) during a previous instance of the user device (1200) in the connected state. A power supply circuit configured to supply power to the aforementioned processing circuit, Equipped with, The information relating to the one or more QoE measurement sessions includes the status of the one or more QoE measurement sessions. The first network node.

21. The processing circuit is further configured to cause the first network node to perform the method according to any one of claims 11 to 15. The first network node according to claim 20.

22. A second network node, the second network node provides services to user devices (1200) that have been released from the second network node and are in an inactive or idle connection state, and the second network node A processing circuit is configured to cause the user device (1200) to transition to a connected state and subsequently transmit (1004) information related to one or more quality-of-experience (QoE) measurement sessions configured in the user device (1200) to a first network node to which it has been connected. A power supply circuit configured to supply power to the aforementioned processing circuit, Equipped with, The information relating to the one or more QoE measurement sessions includes the status of the one or more QoE measurement sessions. The second network node.

23. The processing circuit is further configured to cause the second network node to perform the method described in claim 17. The second network node according to claim 22.

Images