Synchronization between a communication device and a network upon communication device autonomous release of a quality of experience configuration

Abstract

A communication device (1700) can be configured (1230) with a configuration that includes a quality of experience, QoE, configuration and / or a radio access network-visible QoE, RVQoE, configuration. The communication device can determine (1240) a start time associated with the configuration. The communication device can further determine that an amount of time that has elapsed since the start time exceeds a threshold amount of time. The communication device can further, responsive to determining than the amount of time that has elapsed since the start time exceeds the threshold amount of time, release (1290) the configuration.

Description

SYNCHRONIZATION BETWEEN A COMMUNICATION DEVICE AND A NETWORK UPON COMMUNICATION DEVICE AUTONOMOUS REEEASE OF A QUALITY OF EXPERIENCE CONFIGURATIONTECHNICAL FIELD

[0001] The present disclosure is related to communication systems, entities, network node, and host for synchronization between a communication device and a network upon communication device autonomous release of a quality of experience (“QoE”) configuration.BACKGROUND

[0002] FIG. 1 illustrates an example of a new radio (“NR”) network (e.g., a 5th Generation (“5G”) network) including a 5G core (“5GC”) network 130, network nodes 120a-b (e.g., 5G base station (“gNB”)), multiple communication devices 110 (also referred to as user equipment (“UE”)).

[0003] Multicast and Broadcast Services (“MBS”) are point-to-multipoint service in which services and data are transmitted from a single source entity to multiple recipients, either to all UEs in a Broadcast service area, or to users in a multicast group.

[0004] A 5G NR system enables delivery of MBS in a resource-efficient way. Via the MBS, the same service and the same specific content data from a single source can be provided simultaneously to all UEs in a geographical area (in the broadcast communication service) or to a dedicated set of UEs (in the multicast communication service). That is, all UEs in a broadcast area can receive the data, while not all UEs are authorized to receive the data in a multicast area.

[0005] A UE can receive a broadcast MBS communication service independently of its radio resource control (“RRC”) state, while a multicast MBS service can be received only by the UEs in the RRC CONNECTED state. Multicast communication data can be delivered to a UE via Point-to-Point (“PTP”) and / or Point-To-Multipoint (“PTM”) mechanisms, and hybrid automatic repeat request (“HARQ”) retransmission / feedback can be applied to both of these mechanisms.SUMMARY

[0006] According to some embodiments, a method of operating a communication device in a communications network is provided. The communication device is configured with a configuration that includes a quality of experience, QoE, configuration and / or a radio access network- visible QoE, VRQoE, configuration. The method includes determining a start time associated with the configuration. The method includes determining that an amount of time thathas elapsed since the start time exceeds a threshold amount of time. The method includes, responsive to determining than the amount of time that has elapsed since the start time exceeds the threshold amount of time, releasing the configuration.

[0007] In additional or alternative embodiments, determining that the amount of time that has elapsed since the start time exceeds the threshold amount of time includes: initiating a timer at the start time, the timer being set to the amount of time; and determining that the timer has expired.

[0008] In additional or alternative embodiments, determining the start time includes determining the start time based on a time that the message was received by the communication device.

[0009] In additional or alternative embodiments, the method further includes receiving a message from the network node including an indication of the configuration. The method further includes, responsive to receiving the message from the network node, transmitting a response to the network node. Determining the start time includes determining the start time based on a time that the response was transmitted by the communication device.

[0010] In additional or alternative embodiments, the method further includes receiving a message from the network node including an indication of the configuration and an indication of the start time. Determining the start time includes determining the start time based on the indication of the start time.

[0011] In additional or alternative embodiments, the configuration is a new configuration. The method further includes receiving a message from the network node including instructions to cause the communication device to be reconfigured from an existing configuration to the new configuration. Determining the start time associated with the new configuration includes replacing an existing start time associated with the existing configuration with the start time associated with the new configuration.

[0012] In additional or alternative embodiments, replacing the existing start time includes determining a difference between the existing configuration and the new configuration. The difference includes at least one of: the existing configuration being associated with single connectivity and the new configuration being associated with multi -connectivity; the existing configuration being associated with a first multi-connectivity and the new configuration being associated with a second multi -connectivity; and the existing configuration being associated with multi-connectivity and the new configuration being associated with single connectivity. The method further including, responsive to determining the difference between the existingconfiguration and the new configuration, replacing the existing start time associated with the existing configuration with the start time associated with the new configuration.

[0013] In additional or alternative embodiments, the method further includes, subsequent to determining the start time and prior to determining the amount of time that has elapsed since the start time, performing an action including at least one of: transmitting a report based on the new configuration or the existing configuration; transmitting a session start indication associated with the new configuration; and transmitting a session end indication associated with the new configuration. The method further includes, responsive to performing the action, resetting the start time.

[0014] In additional or alternative embodiments, determining the start time includes determining the start time based on a time at which the communication device was released to a RRC IDLE state.

[0015] In additional or alternative embodiments, determining the start time includes determining the start time based on at least one of: a time at which the communication device was released to a RRC INACTIVE state; a type of measurement associated with the configuration; a predetermined delay; a configured delay indicated by the network node; a time at which the communication device transmits a first report based on the configuration; a time at which the communication device transmits a first session start indication; a time at which the communication device transmits a first report based on the configuration at an end of a session; a time at which a period of time has elapsed without the configuration being used to transmit at least one of a report, a session start indication, or a session end indication; a radio resource control, RRC, state of the communication device; a time at which the communication device begins a first measurement session based on the configuration; a time at which the communication device ends the first measurement session based on the configuration; a time at which a period of time has elapsed without the communication device starting a measurement session based on the configuration; a time at which a period of time has elapsed without the communication device being able to transmit a report based on the configuration; and a time at which a buffer for storing reports associated with the configuration exceeds a threshold amount.

[0016] In additional or alternative embodiments, the configuration is a first configuration. The method further includes, prior to determining that the amount of time that has elapsed since the start time exceeds the threshold amount of time, replacing the first configuration with a second configuration without adjusting the start time.

[0017] In additional or alternative embodiments, the threshold amount of time is at least one of: a predetermined amount of time; and a configured amount of time.

[0018] According to other embodiments, a method of operating a communication device in a communications network is provided. The communication device is configured with a configuration that includes a quality of experience, QoE, configuration and / or a radio access network-visible QoE, VRQoE, configuration. The method includes transmitting an indication to a network node of whether the communication device has released the configuration. The method further includes releasing the configuration.

[0019] In additional or alternative embodiments, the method further includes receiving a message from the network node indicating a time at which to transmit the indication of whether the communication device has released the configuration. Transmitting the indication to the network node of whether the communication device has released the configuration includes transmitting the indication to the network node of whether the communication device has released the configuration at the time.

[0020] In additional or alternative embodiments, the method further includes receiving a request from the network node for the indication of whether the communication device has released the configuration. Transmitting the indication to the network node of whether the communication device has released the configuration includes transmitting the indication to the network node of whether the communication device has released the configuration in response to the request.

[0021] According to other embodiments, a method of operating a network node in a communications network is provided. The method includes determining a start time associated with a configuration of a communication device, the configuration including a quality of experience, QoE, configuration and / or a radio access network-visible QoE, VRQoE, configuration. The method further includes determining that an amount of time that has elapsed since the start time exceeds a threshold amount of time. The method further includes, responsive to determining than the amount of time that has elapsed since the start time exceeds the threshold amount of time, determining that the communication device released the configuration.

[0022] In additional or alternative embodiments, the method further includes transmitting a message to the communication device, the message including an indication of the configuration. Determining the start time includes determining the start time based on a time that the message was transmitted to the communication device.

[0023] In additional or alternative embodiments, the method further includes, responsive to transmitting the message to the communication device, receiving a response from thecommunication device. Determining the start time includes determining the start time based on a time that the response was received from the communication device.

[0024] In additional or alternative embodiments, the message includes an indication of the configuration and an indication of the start time.

[0025] In additional or alternative embodiments, the configuration includes a new configuration. Determining the start time associated with the new configuration includes replacing an existing start time associated with the existing configuration with the start time associated with the new configuration.

[0026] In additional or alternative embodiments, replacing the existing start time includes determining a difference between the existing configuration and the new configuration, the difference including at least one of: the existing configuration being associated with single connectivity and the new configuration being associated with multi -connectivity; the existing configuration being associated with a first multi-connectivity and the new configuration being associated with a second multi -connectivity; and the existing configuration being associated with multi-connectivity and the new configuration being associated with single connectivity. The method further including, responsive to determining the difference between the existing configuration and the new configuration, replacing the existing start time associated with the existing configuration with the start time associated with the new configuration.

[0027] In additional or alternative embodiments, the method further includes 22, subsequent to determining the start time and prior to determining the amount of time that has elapsed since the start time, performing an action including at least one of: receiving a report based on the new configuration or the existing configuration; receiving a session start indication associated with the new configuration; and receiving a session end indication associated with the new configuration. The method further including, responsive to performing the action, resetting the start time.

[0028] In additional or alternative embodiments, determining the start time includes determining the start time based on a time at which the communication device was released to a RRC IDLE state.

[0029] In additional or alternative embodiments, determining the start time includes determining the start time based on at least one of: a type of measurement associated with the configuration; a predetermined delay; a configured delay; a time at which the communication device was released to a RRC_INACTIVE state; a time at which the network node receives a first report based on the configuration; a time at which the network node receives a first session start indication; a time at which the network node receives a first report based on theconfiguration at an end of a session; a time at which a period of time has elapsed without the network node receiving at least one of a report, a session start indication, or a session end indication based on the configuration; and a radio resource control, RRC, state of the communication device.

[0030] In additional or alternative embodiments, the configuration is a first configuration. The method further includes, prior to determining that the amount of time that has elapsed since the start time exceeds the threshold amount of time, replacing the first configuration with a second configuration without adjusting the start time.

[0031] In additional or alternative embodiments, the threshold amount of time is at least one of: a predetermined amount of time; and a configured amount of time.

[0032] According to other embodiments, a method of operating a network node (1800) in a communications network is provided. The method includes configuring a communication device with a configuration that includes a quality of experience, QoE, configuration and / or a radio access network-visible QoE, VRQoE, configuration. The method further includes receiving an indication from the communication device of whether the communication device has released the configuration. The method further includes determining whether the communication device has released the configuration based on the indication from the communication device.

[0033] In additional or alternative embodiments, the method further includes transmitting a message to the communication device, the message including an indication of the configuration.

[0034] In additional or alternative embodiments, the method further includes transmitting a message to the communication device indicating a time at which to transmit the indication of whether the communication device has released the configuration. Receiving the indication from the communication device of whether the communication device has released the configuration includes receiving the indication from the communication device of whether the communication device has released the configuration at the time.

[0035] In additional or alternative embodiments, the method further includes transmitting a request to the communication device for the indication of whether the communication device has released the configuration. Receiving the indication from the communication device of whether the communication device has released the configuration includes receiving the indication from the communication device of whether the communication device has released the configuration in response to the request.

[0036] In additional or alternative embodiments, the network node is a first network node. The method further includes transmitting the start time to a second network node.

[0037] According to other embodiments, a communication device, a network node, a computer program, a computer program product, a host, a system, or a non-transitory computer- readable medium is provided to perform one of the above methods.

[0038] Certain aspects of these embodiments may provide technical advantages. In some embodiments, the UE’s behavior with regards to autonomous release of QoE configurations becomes predictable for the network. Uncertainties of the UE behavior and potentially varying behavior between UEs from different vendors can be eliminated. By contrast, currently it may be unclear to the network whether a UE that does not transmit any more QoE reports does so because there are no application sessions to measure on in the UE or because the UE has autonomously released the QoE configuration.BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this application, illustrate certain non-limiting embodiments of inventive concepts. In the drawings:

[0040] FIG. 1 is a schematic diagram illustrating an example of a 5thgeneration (“5G”) network;

[0041] FIG. 2 is a block diagram illustrating an example of a MBS delivery procedure;

[0042] FIG. 3 is a signal flow diagram illustrating an example of signaling involved in QoE measurement configuration;

[0043] FIG. 4 is a table illustrating an example of QoE metrics for a MBMS;

[0044] FIG. 5 is a signal flow diagram illustrating an example of signaling involved in configuration and reporting of QoE measurements;

[0045] FIG. 6 is a diagram illustrating an example of an ASN. 1 definition of an AppLayerMeasConfig IE;

[0046] FIG. 7 is a table illustrating an example of field descriptions of the AppLayerMeasConfig IE;

[0047] FIG. 8 is a table illustrating an example of field descriptions of a RAN- VisibleParameter field of the AppLayerMeasConfig IE;

[0048] FIG. 9 is a diagram illustrating an example of an ASN. 1 definition of an MeasurementReportAppLayer IE;

[0049] FIG. 10 is a table illustrating an example of field descriptions of the MeasurementReportAppLayer IE;

[0050] FIG. 11 is a table illustrating an example of field descriptions of a RAN- VisibleMeasurements field of the MeasurementReportAppLayer IE;

[0051] FIGS. 12-13 are flow charts illustrating examples of operations performed by a communication device in accordance with some embodiments;

[0052] FIGS. 14-15 are flow charts illustrating examples of operations performed by a network node in accordance with some embodiments;

[0053] FIG. 16 is a block diagram of a communication system in accordance with some embodiments;

[0054] FIG. 17 is a block diagram of a user equipment in accordance with some embodiments;

[0055] FIG. 18 is a block diagram of a network node in accordance with some embodiments;

[0056] FIG. 19 is a block diagram of a host, which may be an embodiment of the host of FIG. 16, in accordance with some embodiments;

[0057] FIG. 20 is a block diagram of a virtualization environment in accordance with some embodiments; and

[0058] FIG. 21 shows a communication diagram of a host communicating via a network node with a user equipment over a partially wireless connection in accordance with some embodiments.DETAILED DESCRIPTION

[0059] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art, in which examples of embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of present inventive concepts to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present / used in another embodiment.

[0060] FIG. 2 illustrates an example of MBS delivery procedures. For a multicast communication service, shared and individual delivery modes are specified. Between 5GC and next generation radio access network (“NG-RAN”), there are two possible delivery proceduresto transmit the MBS data: 1) A 5GC individual MBS traffic delivery procedure; and 2) a 5GC shared MBS traffic delivery procedure.

[0061] The 5GC individual MBS traffic delivery procedure can only be applied for multicast MBS sessions. 5GC receives a single copy of MBS data packets and delivers separate copies of those MBS data packets to individual UEs via per-UE packet data unit (“PDU”) sessions, hence for each such UE one PDU session is required to be associated with a Multicast MBS session. The MBS data received by the multicast / broadcast user plane function (“MB- UPF”) is replicated towards the UPF(s) where individual delivery is performed via unicast transport overN19mb interface.

[0062] The 5GC shared MBS traffic delivery procedure can be applied for both broadcast and multicast MBS sessions. 5GC receives a single copy of MBS data packets and delivers a single copy of those MBS packets to an NG-RAN node, which then delivers the packets to one or multiple UEs. These incoming MBS traffic packets are delivered from MB-UPF to NG-RAN node via the N3mb interface.

[0063] The 5GC shared MBS traffic delivery procedure can be required in all MBS deployments. The 5GC individual MBS traffic delivery procedure can be required to enable mobility when there is an NG-RAN deployment with non-homogeneous support of MBS.

[0064] Between the NG-RAN and the UE, two delivery procedures are available for the transmission of MBS data packets over radio interface: PTP delivery and PTM delivery. In a PTP delivery, NG-RAN delivers separate copies of MBS data packets over radio interface to individual UE(s). In PTM delivery, NG-RAN delivers a single copy of MBS data packets over radio interface to multiple UEs.

[0065] NG-RAN may use a combination of PTP / PTM to deliver an MBS data packets to UEs.

[0066] An MBS session resource may be associated with one or more MBS quality of service (“QoS”) flows, and each of those flows is associated with a QoS profile. gNB provides one or more multicast MBS Radio Bearer (“MRB”) configurations to the UE via RRC signaling. For a multicast session, gNB may change the MRB type using RRC signaling. For a broadcast session, gNB provides a broadcast MRB with one downlink (“DL”)-only radio link control unacknowledged mode (“RLC-UM”) entity for PTM transmission (e.g., only one type of an MRB is specified at the moment for the broadcast communication transmission).

[0067] A radio network temporary identifier (“RNTI”) can be used for group transmission where a UE can receive different services using the same or different group-RNTI (“G- RNTI”) / group-configured scheduling-RNTI (“G-CS-RNTI”). NG-RAN performs certainfunctions to support MBS. They include management of MBS QoS flows, delivery of MBS data packets from 5GC to multiple UEs via PTP or PTM, configuration of UE for MBS QoS flow reception at access stratum (“AS”) layer, controlling switching between PTM and PTP delivery per UE, support for multicast session service continuity during Xn and NG handovers, and support for group paging at multicast session activation over radio toward UEs in connection management (“CM”)-IDLE state and CM-CONNECTED with RRC INACTIVE state.

[0068] To ensure service continuity of a MBS broadcast, the UE in RRC CONNECTED state may send MBS Interest Indication to the gNB, including: a List of MBS frequencies UE is interested in receiving, sorted in decreasing order of interest; a priority between the reception of all listed MBS frequencies and the reception of any unicast bearer; a list of MBS broadcast services the UE is interested in receiving, in case SIB20 is scheduled by the UE's PCell; and a UE’s priority to MBS broadcast versus unicast reception.

[0069] MBS Interest Indication information reporting can be implicitly enabled / disabled by the presence of SIB21.

[0070] Mobility support for service continuation when a UE is in an MBS session depends on whether the broadcast or multicast session is taking place, and on whether the source and target nodes support MBS. For the multicast MBS session, three cases can be distinguished: 1) handover from an NG-RAN node supporting MBS to a node not supporting MBS; 2) handover from an NG-RAN node not supporting MBS to a node supporting MBS; and 3) a handover from a node supporting MBS to another node supporting MBS.

[0071] In the Multicast MBS case, when the HO takes place from a node that supports MBS to a node that does not support MBS, or vice versa, the 5GC Shared MBS Traffic Delivery and 5GC Individual Traffic delivery methods can co-exist temporarily upon handover. Mapping information about unicast QoS flows for multicast data transmission and the information of associated multicast QoS flows are provided to an NG-RAN node. The delivery procedure can be switched from 5GC Shared MBS Traffic delivery to 5GC Individual MBS delivery via establishing the N3 tunnel of the PDU Session for Individual delivery. A session management function (“SMF”) can realize that the target node does not support MBS. General packet radio service tunnelling protocol (“GTP”) tunnel between the user plane function (“UPF”) and the MB-UPF for 5GC Individual MBS traffic delivery activated by SMF and MBS-SMF.

[0072] When the handover (“HO”) takes place from a RAN node that supports MBS to another node that also supports MBS, if the shared delivery for the MBS session has not been established towards the target NG-RAN node, it uses MB-SMF and MB-UPF to establish the Shared delivery for the MBS session. The PDU Sessions, including the one associated with theMBS Multicast session and used for the 5GC Individual MBS traffic delivery, are handed over to the target ND-RAN node. The SMF triggers the mode switch from the Individual to the Shared delivery mode. The target node establishes the shared delivery for the MBS Session upon receiving the MBS Session Context. The 5GC Individual MBS traffic delivery is terminated by 5GC and changed to the 5GC shared MBS traffic delivery.

[0073] In the Broadcast MBS case, the UE may receive the same service in the target node (which supports MBS) if the same MBS session is established with the 5GC Shared MBS traffic delivery. Currently, a case of when a UE is handed over to a node not supporting the MBS within the broadcast area, is not specified.

[0074] A Quality of Experience (“QoE”) framework is described below. QoE measurements (sometimes referred to as “application layer measurements”), have been specified for long term evolution (“LTE”) and universal mobile telecommunications system (“UMTS”) and are being specified for new radio (“NR”) in the third generation partnership project (“3GPP”) release 17. A purpose of the application layer measurements is to measure the end user experience when using certain applications. Currently QoE measurements for streaming services and for mobility telephony service for internet protocol multimedia subsystem (“MTSI”) services are supported. For NR, it is likely that at least virtual reality (“VR”) is added to the list of services for which QoE measurements are specified and supported.

[0075] The procedures for regular QoE are similar in NR, LTE, and UMTS with the overall principles as follows. Quality of Experience Measurement Collection (“QMC”) enables configuration of application layer measurements in the user equipment (“UE”) (also referred to as a communication device) and transmission of QoE measurement result files (commonly referred to as QoE reports) to the network by means of radio resource control (“RRC”) signaling. An application layer measurement configuration (also called QoE measurement configuration or QoE configuration) that the radio access network (“RAN”) receives from the operations, administration, and maintenance (“0AM”) system or the core network (“CN”) is encapsulated in a transparent container, which is forwarded to a UE in a downlink RRC message. An application layer measurement report (also called QoE report) that the UE Access Stratum (“AS”) or UE RRC layer receives from the UE's higher layer (application layer) is encapsulated in a transparent container and sent to network in an uplink RRC message. The RAN then forwards the QoE report to a Measurement Collector Entity (“MCE”).

[0076] The configuration data related to QoE measurements (in standard specifications typically referred to as application layer measurements) consists of a service type indication, an indication of an area in which the measurements are to be performed (denoted area scope), an IPaddress of the entity that collected measurement results (e.g., the QoE reports) should be sent to (often referred to as a Measurement Collector Entity or Measurement Collection Entity (“MCE”), but the entity may sometimes also be referred to as a Trace Collection Entity), and a set of instructions of which type of measurements that should be performed and details of how these measurements are to be performed. These instructions are intended for the application layer in the UE and are placed in a “container” which the network entities handling it, e.g., forwarding it to the UE, as well as the UE Access Stratum, cannot interpret and do not try to read. The currently specified service types are MTSI and streaming service (DASH), and in 3GPP release 17, at least service type VR will be added. An area scope is defined in terms of cells or network related areas. In UMTS, an area scope is defined as either a list of cells, a list of routing areas or a list of tracking areas. In LTE, an area scope is defined as either a list of cells or a list of tracking areas. In NR, an area scope will be defined as either a list of cells or a list of tracking areas.

[0077] QoE, and in particular QoE configuration, comes in two types: management-based QoE configuration and signaling-based QoE configuration. In both cases the QoE configuration originates in the 0AM system or some other administrational entity (e.g., dealing with customer satisfaction). Herein these entities are sometimes referred to as the 0AM system (where the 0AM system also includes further entities). With management-based QoE (sometimes referred to herein as m-based QoE), the 0AM system is typically interested in general QoE statistics from a certain area (which is configured as an area scope). The m-based QoE configuration is sent directly from the 0AM system to the RAN nodes controlling cells that are within the area scope. Each RAN node then selects UEs that are within the area scope (and also fulfills any other relevant condition, such as supporting the concerned application / service type) and sends the m-based QoE configuration to these UEs.

[0078] With signaling-based QoE (sometimes referred to herein as s-based QoE), the 0AM system is interested in collecting QoE measurement results from a specific UE (e.g., because the user of the UE has filed a complaint). The 0AM system sends the s-based QoE configuration to the home subscriber server (“HSS”) (in evolved packet system (“EPS”) / LTE) or unified data management (“UDM”) (in 5GS / NR), which forwards the QoE configuration to the UE’s current core network node (e.g., an mobility management entity (“MME”) in EPS / LTE or an access and mobility management function (“AMF”) in 5G / NR). The CN then forwards the s-based QoE configuration to the RAN node that serves the concerned UE and the RAN forwards it to the UE.

[0079] Forwarded to the UE are the service type indication and the container with the measurement instructions. The UE is not aware of whether a received QoE configuration is m- based or s-based. In legacy systems, the QoE framework is integrated with the Trace functionality and a Trace ID is associated with each QoE configuration. In NR, the QoE functionality is logically separated from the Trace functionality, but it will still partly reuse the Trace signaling mechanisms. In NR and LTE, a globally unique QoE reference (formed of mobile country codes (“MCC”) + mobile network codes (“MNC”) + QMC identifier (“ID”), where the QMC ID is a string of 24 bits) will be associated with each QoE configuration. The QoE reference is included in the container with measurement instructions and also sent to the RAN (e.g., the gNB in NR). For the communication between the gNB and the UE, the QoE reference is replaced by a shorter identifier denoted as measConfigAppLayerld, which is locally unique within a UE (e.g., there is a one-to-one mapping between a measConfigAppLayerld and a QoE reference for each QoE configuration provided to a UE. The measConfigAppLayerld is stored in the UE Access Stratum and also forwarded in an AT Command (which is the type of instructions used in the communication between the UE’s modem part and the UE’s application layer) together with the service type indication and the container with the measurement instructions.

[0080] Reports with collected QoE measurement results (QoE reports) are sent from the UE application layer to the UE Access Stratum, which forwards them to the RAN, which forwards them to the MCE. These QoE measurement results are placed in a “container”, which is uninterpretable for the UE Access Stratum and the RAN. QoE reporting can be configured to be periodic or only sent at the end of an application session. Furthermore, the RAN can instruct the UE to pause QoE reporting (e.g., in case the cell / gNB is in a state of overload).

[0081] The RAN is not aware of when an application session with an associated QoE measurement session is ongoing and the UE Access Stratum is also not automatically aware of this. To alleviate this session start / stop indications has been introduced, which are sent from the application layer in the UE to the UE AS and from the UE AS to the RAN. A session end indication are sent when the application session and the associated QoE measurement session are concluded.

[0082] The RAN may decide to release a QoE configuration in a UE at any time, as an implementation-based decision. Typically, it is done when the UE has moved outside an area configured for the QoE measurements (commonly referred to as the area scope) and the measurement session has ended.

[0083] One opportunity provided by legacy solutions is also to be able to keep the QoE measurement for the whole session, even during a handover situation. It is also discussed to let the UE continue with the QoE measurements on an ongoing application session until the application session ends, even if the UE in the meantime moves out of the configured area scope.

[0084] QoE measurements and their results are intended for analysis in the O&M system (or in other entities that neither belong to the core network nor belong to the RAN) and subsequent possible non-real-time optimizations. The QoE reports are forwarded transparently by the RAN to a configured receiver, e.g., an MCE. However, the RAN could also benefit from receiving measurement results of metrics measured or collected at the application layer, e.g. as a complement to the more radio related measurements, i.e. the RRM measurements (e.g. RSRP, RSRQ, SINR... ). For instance, the RAN could use such measurement results for real-time or semi-real-time adaptations or optimizations of the treatment of an ongoing application session, e.g. in terms of scheduling priorities.

[0085] For this reason, in 3GPP release 17, 3GPP introduced so-called RAN Visible QoE (“RVQoE”), which includes periodic reporting of measured application layer metrics in a format that the RAN can understand. These metrics, denoted as RVQoE metrics, are in release 17 limited to QoE metrics, in particular the Buffer Level QoE metric for DASH and the Playout Delay for Media Start-up QoE metric for DASH. In addition to these two RVQoE metrics, a MeasurementReportAppLayer message may contain a PDU session ID list (in the form of the pdu-SessionldList-r 17 field) as part of the reported RVQ information (i.e. in the RAN- VisibleMeasurements-rl7 IE).

[0086] The configuration for QoE and RVQoE are performed via an RRC reconfiguration message containing the AppLayerMeasConfig IE, whose ASN.l definition is illustrated in FIG. 6. The configuration of legacy QoE metrics is done via the measConflgAppLayerContainer IE, which specifies the configuration to the application-layer in the UE as an octet string (a compressed XML file). RVQoE parameters are specified as part of the RAN-VisibleParameters IE.

[0087] Quality of Experience (QoE) measurements have been specified for LTE and UMTS, and they are being specified for NR. The purpose of the application layer measurements is to measure the end user experience when using certain applications. Currently QoE measurements for streaming services and for MTSI (Mobility Telephony Service for IMS) services are supported.

[0088] The solutions in LTE and UMTS are similar with the overall principles as follows. Quality of Experience Measurement Collection enables configuration of application layer measurements in the UE and transmission of QoE measurement result files by means of RRC signaling. Application layer measurement configuration received from O&M or CN is encapsulated in a transparent container, which is forwarded to UE in a downlink RRC message. Application layer measurements received from UE's higher layer are encapsulated in a transparent container and sent to network in an uplink RRC message. The result container is forwarded to a TCE, Trace Collector Entity.

[0089] In 3GPP release 17 a study item for “Study on NR QoE management and optimizations for diverse services” for NR has been carried out. The purpose of the study item was to study solutions for QoE measurements in NR. QoE management in NR will not just collect the experience parameters of streaming services but also consider the typical performance requirements of diverse services (e.g. AR / VR and URLLC).

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

[0091] When initiated via the core network, the measurement is started towards a specific UE. For the LTE case, the "TRACE START" S1AP message is used, which carries, among others, the details about the measurement configuration the application should collect (in the “Container for application layer measurement configuration” IE, transparent to the RAN) and the details to reach the trace collection entity to which the measurements should be sent.

[0092] Notifications of started and stopped application sessions with associated QoE measurement configurations are introduced, where these notifications are conveyed from the application layer in the UE and to the UE Access Stratum (i.e. the radio layers in the UE) and then forwarded to the network. This allows the network (at least the RAN) to be aware of when QoE measurements on an application session are ongoing. It is an implementation decision when the RAN stops the measurements. Typically, it is done when the UE has moved outside the configured area for measurement (also referred to as the area scope). However, this strategy is questioned by the desire to have QoE data that represent complete application sessions.

[0093] FIG. 3 provides an overview (without showing all the details) of the signaling involved in QoE measurement configuration, from the O&M system to the UE. At operation 310, the NM transmits an activateAreaQMCj ob message to the DM / EM. In some examples, the activateAreaQMCjob message includes a service type, area scope, slice scope, QoE CE Address, PLMN target, QoE target, QoE reference, and / or QMC configuration file. At operation 320, the DM / EM forwards the activateAreaQMC job message to the gNB. At operation 330, the gNB starts finding a UE that matches the criteria. At operation 340, the gNB transmits a RRCReconfiguration message to the UE AS. At operation 350, the UE AS transmits a +CAPPLEVMC message to the UE Application level. In some examples, the RRCReconfiguration message and the +CAPPLEVMC message include information from the activateAreaQMCjob message.

[0094] At operation 360, the UE Application Level starts application and QoE measurement collection. At operation 370, the UE Application Level transmits a +CAPPLEVMR message to the UE AS. At operation 380, the UE AS transmits a MeasurementReport to the gNB. In some examples, the +CAPPLEVMR message and the MeasurementReport include a MeasConfigAppLayerld. At operation 382, the gNB transmits a notification to the NM. In some examples, the notification includes an indication of a recording session.

[0095] At operation 386, the UE Application Level transmits a +CAPPLEVMR message to the UE AS. At operation 388, the UE AS transmits a MeasurementReport message to the gNB. In some examples, the +CAPPLEVMR message and the MeasurementReport message include information associated with the measurements collected by the UE Application Level. At operation 390, the gNB transmits a report to the MCE.

[0096] One opportunity provided by legacy solution is also to be able to keep the QoE measurement for the whole application session, even during handover situation, so that reported QoE measurement data cover complete application sessions.

[0097] The 3GPP TS 26.346 version 17.3.0 defines QoE metrics for the Multimedia Broadcast Multicast Service (MBMS), in addition to QoE metrics for DASH streaming that can also be used. The full table from TS 26.346 version 17.3.0 is illustrated in FIG. 4.

[0098] The QoE measurements are configured in the UE by means of RRC signaling. The configuration is done using the RRC message RRCReconfiguration containing the IE appLayerMeasConfig. The UE starts collecting QoE measurements when the session starts in the application layer and when a report is ready, it is sent to the network in the RRC message MeasurementReportAppLayer . The same RRC messages are used for both regular QoE and RAN visible QoE.

[0099] FIG. 5 illustrates an example of RRC signaling for configuration and reporting of QoE measurements.

[0100] FIG. 6 illustrates an example of an ASN.1 definition of the AppLayerMeasConflg IE (with associated field descriptions). Further explanation is available in 3GPP TS 38.331 version 17.6.0. FIG. 7 illustrates an example of AppLayerMeasConflg field descriptions. FIG. 8 illustrates an example of RAN-VisibleParameter field descriptions.

[0101] FIG. 9 illustrates an example of an ASN.1 definition of the MeasurementReportAppLayer message (with associated field descriptions). Further explanation is available in 3GPP TS 38.331 version 17.6.0. FIG. 10 illustrates an example of MeasReportAppLayer field descriptions. FIG. 11 illustrates an example of RAN- VisibleMeasurements field descriptions.

[0102] AT commands are used for communication between the AS (radio) layer and the application layer in the UE. The AT commands are defined in 3GPP TS 27.007 version 18.4.0. The AT commands are used in QoE for transferring of the configuration from the RRC layer to the application and for transferring of reports from the application layer to the RRC layer.

[0103] The AT command used for sending a QoE configuration (and / or an RVQoE configuration) from the UE AS to the UE application layer in NR is denoted as +CAPPLEVMCNR and is specified in 3GPP TS 27.007 version 18.4.0 as indicated in Appendix A.

[0104] The AT command used for sending QoE reports (and / or RVQoE reports) from the UE application layer to the UE AS in NR is denoted as +CAPPLEVMRNR and is specified in 3GPP TS 27.007 version 18.4.0 as indicated in Appendix B.

[0105] In LTE, the corresponding AT commands are denoted respectively as +CAPPLEVMC and +CAPPLEVMR.

[0106] In the release 18 of the 3GPP standard, 3GPP is specifying QoE measurements for MBS in RRC INACTIVE and RRC IDLE state. To this end, the 3GPP working groups RAN3 and RAN2 has made a number of agreements and working assumptions related to QoE configuration / measurements for MBS in RRC IN ACTIVE and RRC IDLE state.

[0107] In some examples, the agreements include that MBS is regarded as a communication service carrying application sessions of various service types. That is, in the context of QoE, MBS is not regarded as a service type.

[0108] In additional or alternative examples, the agreements include that a UE can be configured to perform QoE measurements on application sessions carried by MBS in any RRC state (i.e. RRC IDLE, RRC INACTIVE and RRC CONNECTED state). Thus, a UE which isconfigured to perform QoE measurements on application sessions carried by MBS in RRC IDLE state shall retain the QoE configuration in RRC IDLE state (which is different from other QoE configurations which the UE releases when it transits to RRC IDLE state).

[0109] In additional or alternative examples, the agreements include that since the RAN (in contrast to the AMF in the core network) deletes the UE context (i.e. configuration and state information related to the UE) when the UE transits, e.g. is released by the RAN, to RRC IDLE state, the RAN’s configuration parameters related to the QoE configuration that the UE retains in RRC IDLE state (which are herein referred to as “the network version of the QoE configuration”, abbreviated “NW-QoE configuration”) must be re-instated in the gNB when a UE (which has retained a QoE configuration in RRC IDLE state) connects and transits from RRC IDLE to RRC CONNECTED state in a cell controlled by the gNB.

[0110] In a UE-based solution, the UE stores the NW-QoE configuration on behalf of the RAN while the UE is in RRC_IDLE state, and sends the NW-QoE configuration to the gNB when the UE connects to the gNB and transits from RRC IDLE to RRC CONNECTED state. This solution is the working assumption in RAN3.

[0111] In a CN-based solution, the NW-QoE configuration is stored in the CN, assumedly in the AMF, while the UE is in RRC IDLE state and sent to the gNB the UE connects to when it subsequently transits from RRC IDLE to RRC CONNECTED state.

[0112] When the UE (which has retained and applied a QoE configuration in RRC IDLE state) transits from RRC IDLE to RRC CONNECTED state, the UE indicates availability of any stored QoE report(s) (e.g. QoE reports the UE has generated in RRC IDLE state). If the UE indicates availability of such stored QoE report(s), the gNB may retrieve the QoE report(s) by establishing SRB4, which triggers the UE send the stored QoE report(s) to the gNB on SRB4.

[0113] RAN2 has also made the following relevant agreement (at the RAN2 meeting #122, RAN2#122): “UE is allowed to release stored reports and configuration after 48h (similar to logged MDT). No timer is configured by the network.”

[0114] The 3GPP Technical Specification (TS) 32.422 version 18.0.0 describes the activation mechanisms for MDT in NG-RAN at clause 4.1.1.9. Of main interest in the context of this invention is the logged MDT measurements, which in the 3GPP specifications also are referred to as “logged measurements” and which are configured using the LoggedMeasurementConfiguration RRC message.

[0115] The management system sends a Trace Session activation request to the gNB. This request includes parameters for configuring UE measurements, listed below (note that at the same time not all the parameters can be present and the criteria for which parameters arepresent are described in clause 5 of the same document): Job type; Area scope; List of measurements; Reporting Trigger; Report Interval; Report Amount; Event Threshold; Logging Interval; Logging Duration; Trace Reference; IP address of TCE; Anonymization of MDT data; Collection period for RRM measurements NR (only if any of M4, M5, M6 or M7 measurements are requested); Positioning method; MDT PLMN List; MDT report type (periodical logged or event-triggered measurement) for logged MDT only; Event Threshold, Hysteresis and Time to trigger (present only if LI event is configured for logged MDT); MDT specific events list for event-triggered measurement for logged MDT only; Area Configuration for neighboring cells for logged MDT only; and Sensor information for logged MDT and immediate MDT.

[0116] The Logging Duration (the loggingDuration IE) configures the start value of timer T330 in the UE, which defines for how long the UE must keep the logged measurement configuration. At the expiration of timer T330, the UE shall release the QoE configuration. However, the UE must still keep any stored (not yet sent) logged measurement reports for at least an additional 48 hours. That is, 48 hours after the expiration of timer T330, the UE is allowed to discard any stored unsent logged measurement reports.

[0117] The loggingDuration IE is mandatory in the logged measurement configuration (i.e. in the LoggedMeasurementConflguration RRC message), and it has a range between 10 minutes and 120 minutes, and there is no default value.

[0118] Timer T330 is started when the UE receives the logged measurement configuration (i.e. the LoggedMeasurementConflguration RRC message).

[0119] There currently exist certain challenges. In some examples, there are problematic consequences of the RAN2 agreement that states that the “UE is allowed to release stored reports and configuration after 48h (similar to logged MDT). No timer is configured by the network.”

[0120] The text of this agreement pertains to QoE measurements. The text further contains a reference to logged MDT, but it also says that no timer is configured. However, in logged MDT there is a timer T330 (configured in the loggingDuration IE) and when timer T330 expires, the UE shall release the MDT configuration. However, the UE shall not release the stored MDT reports when timer T330 expires. The above agreement for QoE, on the other hand, says that the UE is allowed to release both the QoE configuration and the stored QoE reports after 48 hours, but says nothing about when the 48 hours start. Therefore, it is very unclear what is similar to logged MDT, as there are several things that are not similar. In particular, it is unclear when the 48 hours start for QoE and when the UE can release the QoE configurations and stored QoE reports.

[0121] Furthermore, a further significant problem caused by this agreement is that the network will not know if and when the UE will autonomously release, or has autonomously released, a certain QoE configuration. This lack of certain synchronized perception of the status of the QoE configuration leads to several potential problems.

[0122] In some examples, the gNB does not know whether it should keep the UE side QoE configuration context (e.g. the network version of the QoE configuration, herein also referred to as the NW-QoE configuration) or deleted it.

[0123] In additional or alternative examples, the gNB does not know whether the measConflgAppLayerld associated with the QoE configuration is still occupied in the UE or free for reuse.

[0124] In additional or alternative examples, if the gNB wants to reconfigure a certain aspect of the QoE configuration (which does not include sending the measConfigAppLayerContainer IE (i.e. the XML file with QoE configuration information to be read by the UE application layer), e.g. changing from transmissionOfSessionStartStop = “false” to transmissionOfSessionStartStop = “true” or changing from pans eReporting = “false” to pans eReporting = “true”, and the UE has autonomously released the QoE configuration, the UE’s behavior will be unpredictable.

[0125] In additional or alternative examples, the gNB does not know whether to expect any session status indications (appLayer SessionStatus IES), or any QoE and (if configured) RVQoE reports from the UE.

[0126] In additional or alternative examples, the UE may receive instructions from the gNB related to a QoE configuration that does not exist in the UE.

[0127] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. Various embodiments described herein ensure that the RAN can always be aware of when a UE will autonomously release, or has released, a QoE configuration (triggered by the aging of the QoE configuration), when the RAN needs to be aware of this.

[0128] In some embodiments, the terms communication device, “UE”, “terminal equipment”, “wireless terminal” and “terminal” are used interchangeably.

[0129] In additional or alternative embodiments, the terms “node” and “network node” are used interchangeably. A network node can, for example, be a RAN node, a gNB, an eNB, an en-gNB, ang-eNB, a gNB-CU, a gNB-CU-CP, a gNB-CU-UP, an eNB-CU, an eNB-CU-CP, an eNB-CU-UP, an lAB-node, an lAB-donor DU, an lAB-donor-CU, an IAB-DU, an IAB-MT, an O-CU, an O-CU-CP, an O-CU-UP, an O-DU, an O-RU, an O-eNB, aNon-Real Time RAN Intelligent Controller (Non-RT RIC), a Real-Time RAN Intelligent Controller (RT-RIC), anOAM node, a Core Network node / function, a Cloud-based network function, a Cloud-based centralized training node.

[0130] In additional or alternative embodiments, the terms “session start / stop indication”, “start / stop indication”, “session status indication” and “QoE measurement session status indication” are used interchangeably.

[0131] In additional or alternative embodiments, the terms “network version of QoE configuration”, “network instance of QoE configuration” and “NW-QoE configuration” are equivalent. The same applies for the corresponding UE’s version / instance of the QoE configuration (wherein the latter can be called e.g., “UE version of QoE configuration”, or “UE instance of QoE configuration”, or “UE-QoE configuration.”

[0132] Some embodiments here are equally applicable to QoE and RVQoE measurements.

[0133] Some embodiments herein are equally applicable to QoE configuration and RVQoE configuration.

[0134] In additional or alternative embodiments, the application layer in the UE is also referred to as the “UE application layer” or simply the “application layer”.

[0135] In additional or alternative embodiments, the terms “QoE configuration”, “QoE parameters”, “QoE information” and “QoE configuration information” are used interchangeably. The network, the UE AS and the UE application layer may store various parts thereof.

[0136] In additional or alternative embodiments, the application layer in the UE is also referred to as the “UE application layer” or simply the “application layer”.

[0137] In additional or alternative embodiments, the entity performing the QoE measurements and other actions related to a QoE configuration, such as receiving QoE information from the UE AS, and / or sending QoE information to the UE AS, is an application. The application resides on the application layer in the UE, and hence it is also correct to say that the application layer performs these actions. In the description of the solution, the performer of these various actions is sometimes said to be the application layer and sometimes said to be the application.

[0138] In additional or alternative embodiments, 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. But note that the “QMC configuration file” is not an equivalent term, but instead refers to the part of the QoE configuration consisting of an XML file containing instructions of QoE metrics to be collected etc.

[0139] While some embodiments are described for the interaction between the UE AS and UE application layer when handling / storing QoE information, they may also be applicable to RV QoE information.

[0140] In additional or alternative embodiments, references to the application layer are with respect to the application layer of the UE.

[0141] In additional or alternative embodiments, the term “service” is often used as a short notation for “service type”, therefore “service” and “service types” can be seen as interchangeably unless explicitly stated.

[0142] Some embodiments apply to both signaling- based and management-based QoE / RVQoE measurements (but may also optionally be restricted to apply to only one of them).

[0143] In additional or alternative embodiments, a QoE configuration includes various configuration parameters (such as an instruction on whether the UE should send session start / stop indications) as well as an XML file containing a configuration of QoE measurements to be performed and reported (e.g. indicating QoE metrics to be collected and reported). This XML file is herein referred to with different terms, including at least “QMC configuration file” and “QoE configuration file”.

[0144] In additional or alternative embodiments, the functionality in a UE which 3GPP has named Access Stratum (where there is corresponding Access Stratum functionality in the network) is herein referred to in various ways, including “Access Stratum”, “AS”, “UE Access Stratum”, “UE AS”, “Access Stratum layer”, “AS layer”, “UE Access Stratum layer”, “UE AS layer” or “radio layer”.

[0145] In additional or alternative embodiments, the terms “LTE” and “LTE node” imply that a network node that serves the UE is serving the UE by using the LTE radio access technology on the air interface (Uu).

[0146] In additional or alternative embodiments, the terms “NR” and “NR node” imply that a network node that serves the UE is serving the UE by using the NR radio access technology on the air interface (Uu).

[0147] In additional or alternative embodiments, the terms information element (IE) and field are used more or less interchangeably in this document. Also the term parameter is sometimes used to denote the same concept.

[0148] In additional or alternative embodiments, when writing message names of a communication protocol, two equivalent principles are used herein. The writing principle “<protocol name> <message name> message”, for example “XnAP HANDOVER REQUEST message”, and the writing principle “<message name> <protocol name> message”, for example“HANDOVER REQUEST XnAP message” are equivalent, both referring to a message (i.e., “<message name>”) of a communication protocol (i.e., “<protocol name>”), e.g., the HANDOVER REQUEST message of the communication protocol XnAP. The same writing format equivalence applies to other communication protocols, such as NGAP.

[0149] In additional or alternative embodiments, parameters / IEs / fields used in ASN.1 code as well as in procedural text in the 3GPP RRC specification for 5G / NR, i.e. 3GPP TS 38.331 version 17.6.0, are often named with a suffix indicating the number of the release of the 3GPP standard the parameter / IE / field was introduced in (e.g. the suffix “-rl7” for a parameter / IE / field introduced in release 17 of the 3GPP standard). Parameters / IEs / fields following this naming convention are typically referred to both with and without the suffix, where the name including the suffix is used in the ASN.1 code (and thus defines the formal name from the ASN.1 compiler’s perspective), while the name without the suffix is used in running text, e.g. in field descriptions and procedural text. Relevant examples in the context of this document include the parameters / IEs / fields AppLayerMeasConflg-rl71 AppLayerMeasConflg and MeasConflgAppLayer-rl71 MeasConflgAppLayer . In this document, both name variants may occur for various parameters / IEs / fields.

[0150] In additional or alternative embodiments, strictly speaking, the session start / stop indications do not refer to the application session, but rather to the QoE measurement session associated with the application session. However, if / when the terms “session data” or “session data flow” are mentioned, they refer to the data or data flow of the application session with which the QoE measurement session is associated.

[0151] In additional or alternative embodiments, the term “flag” refers to an indication, i.e. a parameter indicating something. An indication referred to as a flag is typically, but not necessarily, an indication that can indicate one of only two possible values, e.g. implemented as a single-bit indicator.

[0152] In additional or alternative embodiments, the NW QoE configuration relates to the network version of the QoE configuration. The UE may store the NW QoE configuration while it is in RRC_IDLE state (the so-called UE-based solution). Alternatively, the CN (e.g. an AMF) may store the NW QoE configuration while the UE is in RRC IDLE state (the so-called CN- based solution).

[0153] In additional or alternative embodiments, the UE QoE configuration relates to the UE version of the QoE configuration.

[0154] In additional or alternative embodiments, the terms “QoE report” or “QoE measurement report”, when sent from a UE to a gNB, may primarily refer to the content of ameasReportAppLayerContainer IE in aMeasurementReportAppLayer RRC message. However, sometimes the terms may refer to: MeasurementReportAppLayer RRC message; a MeasReportAppLayer IE in aMeasurementReportAppLayer RRC message; or the content of a MeasReportAppLayer IE, excluding the ran-VisibleMeasurements IE, in a MeasurementReportAppLayer RRC message.

[0155] In additional or alternative embodiments, the terms “RVQoE report” or “RVQoE measurement report”, when sent from a UE to a gNB, refer to the content of a RAN- VisibleMeasurements IE in aMeasurementReportAppLayer RRC message.

[0156] Some embodiments are described in terms of NR, but can also be applied to UMTS, LTE and NR as well as future RATs such as 6G.

[0157] Various embodiments described herein address different cases, conditions, circumstances, and / or assumptions regarding the development of the standard specification work in 3 GPP. Some embodiments include synchronizing the network and the UE with regards to when the UE will autonomously release, or has autonomously released, a certain QoE configuration (e.g., targeting QoE configurations that the UE retain in RRC IDLE state). The applicability of each embodiment depends on various circumstances, which in turn partly depend on future agreements in 3 GPP.

[0158] In some embodiments, synchronizing the network and the UE includes using a timestamp of the time when an age timer starts (e.g., when the counting of the time to be compared with the 48 hour time limit starts). For example, when the UE is configured with a QoE configuration, to maintain synchronization between the UE and the network with regards to the perception of the age of the QoE configuration and when the UE may or will autonomously release the QoE configuration.

[0159] In additional or alternative embodiments, synchronizing the network and the UE includes leveraging an indication from the UE informing the network when the UE autonomously releases a QoE configuration or has autonomously released a QoE configuration.

[0160] In additional or alternative embodiments, the running timer or the age timer is paused or resumed.

[0161] The term “hard age limit” can refer to an age limit (or lifetime) of a QoE configuration, whose expiry (e.g., when the age limit is reached) means that the UE shall autonomously release the QoE configuration. The term “soft age limit” refers to an age limit (or lifetime) of a QoE configuration, whose expiry (e.g., when the age limit is reached) means that the UE is allowed to (may) autonomously release the QoE configuration.

[0162] As described above, it is unclear when the time that should be compared with the 48 hours age limit agreed in the above RAN2 agreement at RAN2#122 starts (below referred to as the start time). This precludes any procedure where the network is aware of when the UE will release, or has released, the concerned QoE configuration, without any further information from the UE. Therefore, some procedures depend on a well-defined indication for the start time of the time period to be compared with the 48 hour age limit, which is thus part of the overall procedure.

[0163] Definition of a start time of the time to be compared with the 48 hour time / age limit is described below. The starting point for when the timer starts counting - also referred to below as the “age timer” or simply the “timer” - may need to be defined. In some embodiments, the network (e.g., a gNB) is aware of the start time at the time of the start time. In other embodiments, the network is not aware fo the start time at the time of the start time.

[0164] Embodiments associated with the network being aware of the start time at the time of the start time are described below. The following are different procedures for how the time to be compared with the 48 hour age limit is counted and in particular when the counting starts (i.e. the start time), which have in common that they allow the network to be aware of the start time at the time of the start time. In particular, the following are different methods of definition of the start time.

[0165] In some embodiments, the start time may be at configuration of the QoE measurements. This is the time when the network transmits the QoE configuration to the UE (and thus, from the UE’s perspective, when the UE receives the QoE configuration). QoE configurations may be sent at different times for different QoE configurations, i.e. for different measConflgAppLayerlds and in such case the time will start counting at different times for different QoE measurements.

[0166] In some examples, the time restarts counting every time a certain QoE configuration is reconfigured.

[0167] In additional or alternative examples, the time restarts counting every time an additional QoE configuration is configured for the UE (this applies also to the case where a UE that was not configured with any QoE / RVQoE configuration receives / applies at least one QoE / RVQoE configuration).

[0168] In additional or alternative examples, as a result of a coordination between a Master Node (MN) and a Secondary Node (SN) node leading to a reconfiguration of the UE (e.g., to modify / update one or more parameter of an existing RVQoE configuration, or add a new RVQoE configuration), the time restarts counting. This can apply to the reconfiguration of theUE: 1) when the UE is already operating in multi connectivity, or 2) when the UE is in single connectivity and is being reconfigured to multi connectivity (or has just been reconfigured to multi connectivity), or 3) when the UE is reconfigured (or has been reconfigured) from a first form of multi-connectivity to a second form of multi-connectivity (e.g., in case of MN change, or SN change, or MN initiated SN modification, or SN initiated SN modification), or 4) when the UE is reconfigured (or has been reconfigured) from multi-connectivity to single connectivity (e.g., in case of MN initiated SN release, or SN initiated SN release).

[0169] In additional or alternative examples, the time counting (i.e. the age) is not restarted upon reconfiguration of the concerned QoE configuration.

[0170] In additional or alternative examples, the counting is restarted (i.e. the start time is reset, i.e. the age timer is restarted) every time a QoE report associated with the QoE configuration is sent.

[0171] In additional or alternative examples, the counting is restarted (i.e. the start time is reset, i.e. the age timer is restarted) every time a session start indication or a QoE report associated with the QoE configuration is sent.

[0172] In additional or alternative examples, the counting is restarted (i.e. the start time is reset, i.e. the age timer is restarted) every time a session end indication or a QoE report associated with the QoE configuration is sent.

[0173] In additional or alternative examples, the counting is restarted (i.e. the start time is reset, i.e. the age timer is restarted) every time a QoE report or an RVQoE report associated with the QoE configuration is sent.

[0174] In additional or alternative examples, the counting is restarted (i.e. the start time is reset, i.e. the age timer is restarted) every time a session start indication or a QoE report or an RVQoE report associated with the QoE configuration is sent.

[0175] In additional or alternative examples, the counting is restarted (i.e. the start time is reset, i.e. the age timer is restarted) every time a session start indication or a session end indication or a QoE report or an RVQoE report associated with the QoE configuration is sent.

[0176] In additional or alternative embodiments, the start time may be when the UE receives the NW-QoE configuration.

[0177] In additional or alternative embodiments, the counting (re)starts when the configuration is received by the UE + some delay, or when any of the events listed herein occur + some delay. The delay can be set by the network and explicitly or implicitly indicated to the UE. Alternatively, this delay can be some fixed time, hardcoded at the UE (e.g., set by themanufacturer), which also needs to be explicitly indicated to the network by the UE. As yet another alternative, the delay to add may be specified in a standard.

[0178] In additional or alternative embodiments, the start time may be when the UE is released to RRC INACTIVE or RRC IDLE state.

[0179] In additional or alternative embodiments, the start time may be when the UE is released to RRC INACTIVE state.

[0180] In additional or alternative embodiments, the start time may be when the UE is released to RRC IDLE state.

[0181] In additional or alternative embodiments, the start time may be at the transmission of the first QoE report generated in accordance with the QoE configuration. In some examples, the start time of the age timer is reset (i.e. the age timer is restarted) upon each transmission of a QoE report generated in accordance with the QoE configuration.

[0182] In additional or alternative embodiments, the start time may be at the transmission of the first QoE report or RVQoE report associated with the QoE configuration. In some examples, the start time of the age timer is reset (i.e. the age timer is restarted) upon each transmission of a QoE report or an RVQoE report associated with the QoE configuration.

[0183] In additional or alternative embodiments, the start time may be at whatever happens first of: sending of the first session start indication from the UE; sending of the first QoE report; sending of the first RVQoE report; and expiration of a configured or specified time period which e.g. starts from the time when the UE is configured with the QoE configuration.

[0184] In additional or alternative embodiments, the start time may be at whatever happens first of any subset (where a subset is at least one) of: sending of the first session start indication from the UE; sending of the first QoE report; sending of the first RVQoE report; and expiration of a configured or specified time period which e.g. starts from the time when the UE is configured with the QoE configuration.

[0185] In additional or alternative embodiments, the start time may be at whatever happens first of: sending of the first session end indication from the UE; the first transmission of a QoE report generated at the end of a session; and expiration of a configured or specified time period, which e.g. starts from the time when the UE is configured with the QoE configuration.

[0186] In additional or alternative embodiments, the start time may be at whatever happens first of any subset (where a subset is at least one) of: sending of the first session end indication from the UE; the first transmission ofa QoE report generated at the end of a session; and expiration of a configured or specified time period, which e.g. starts from the time when the UE is configured with the QoE configuration.

[0187] In additional or alternative embodiments, the start time may be at whatever happens first of: sending of the first session end indication from the UE; sending of the first QoE report; sending of the first RVQoE report; and expiration of a configured or specified time period which e.g. starts from the time when the UE is configured with the QoE configuration.

[0188] In additional or alternative embodiments, the start time may be at whatever happens first of any subset (where a subset is at least one) of: sending of the first session end indication from the UE; sending of the first QoE report; sending of the first RVQoE report; and expiration of a configured or specified time period which e.g. starts from the time when the UE is configured with the QoE configuration.

[0189] In additional or alternative embodiments, the start time may be when a certain (configured or specified) time period has elapsed without any QoE report or RVQoE report or session start indication or session end indication pertaining to the concerned QoE configuration having been sent from the UE after the latest transmitted QoE report or RVQoE report or session start indication or session end indication pertaining to the concerned QoE configuration. In some examples, this start time definition may be restricted to any subset (consisting of at least one) of the four mentioned types of transmission from the UE.

[0190] In additional or alternative embodiments, the start time may be reset (i.e. the age timer may be restarted) every time a subsequent event of the same type, or an event of a type belonging to the same set of event types or subset of event types that triggered the setting of the initial start time.

[0191] In additional or alternative embodiments, the start time may be an explicit time, e.g. expressed in UTC, is signaled to the UE as part of the QoE configuration. The explicit time may be the time from when the 48 hours start counting. Alternatively, the explicit time may be the time when the UE can or shall delete the QoE configuration and QoE reports.

[0192] Specifically for the case of inter-RAT handover from LTE to NR (or vice versa), the start time may be the time when the UE connects to the target gNB (or to the target eNB, or ng- eNB). Alternatively, the time when the UE connects to the target gNB can be regarded as the time of configuration of the QoE configuration, and then any of the above methods may be applied. As yet another (similar) alternative, the start time may be defined using any of the above methods, e.g. at any of the above described events, that occurs after the UE has connected to the target gNB.

[0193] For the case of dual connectivity, the start time may be the time when the UE is reconfigured from being connected to a first Master Node to being connected to a second Master Node.

[0194] When at least one QoE / RVQoE configuration is applied to a UE, a reset of the start timer can occur, i.e., leading to a fresh start time when the network reconfigures the UE due to various RRC procedures, potentially involving change of the RRC state of the UE (e.g., from RRC_INACTIVE to RRC_CONNECTED or vice versa). Non-limiting examples of when this can occur are: at handover execution, at conditional handover execution, at DAPS handover execution, at reconfiguration from single-connectivity to dual-connectivity, at MN initiated SN change, at SN Change, at SN initiated SN change, at MN change, at MN and SN change, at SN release.

[0195] In some embodiments, the age timer is reset when at least one of the following occurs: the UE receives from a RAN node an instruction to release all the QoE configuration(s) (and / or RVQoE configuration) existing at the UE; the UE receives from a RAN node an instruction to release one of the QoE configurations (and / or RVQoE configurations) existing at the UE; the UE receives from a RAN node an instruction to release the last (or the only) QoE configuration (and / or RVQoE configuration) existing at the UE; the UE receives from a RAN node an instruction to release the network version of the QoE / RVQoE configuration(s); or the UE receives from a RAN node an instruction to release the UE version of the QoE / RVQoE configuration(s).

[0196] Embodiments in which the network is not aware of the start time at the time of the start time are described below. The following are different procedures for how the time to be compared with the 48 hour age limit is counted and in particular when the counting starts (i.e. the start time), which have in common that they do not allow the network, e.g. a gNB, to (in all scenarios) be aware of the start time at the time of the start time.

[0197] In some embodiments, the start time may be when the first QoE measurement session starts. In some examples, a dependency to the RRC state is defined, e.g. the time starts counting when the QoE measurement starts and the UE is in RRC IDLE and / or RRC INACTIVE state. In additional or alternative examples, the time starts counting when the QoE measurements have been started, when the UE is transferred to RRC IDLE or RRC INACTIVE state. In additional or alternative examples, the time may start counting at different points for different QoE configurations. In additional or alternative examples, the start time is reset (i.e. the age timer is restarted) every time a new QoE measurement session is started.

[0198] In additional or alternative embodiments, the start time may be when the first QoE measurement session ends / stops. In some examples, a dependency to the RRC state is defined, e.g. the time starts counting when the QoE measurement stops and the UE is in RRC IDLEand / or RRC INACTIVE state. In additional or alternative examples, the time starts counting when the measurements have stopped, when the UE is transferred to RRC IDLE orRRC INACTIVE state. In additional or alternative examples, the time may start counting at different points for different QoE configurations. In additional or alternative examples, the start time is reset (i.e. the age timer is restarted) every time a new QoE measurement session ends.

[0199] In additional or alternative embodiments, the start time may be the time when the UE is configured with the QoE configuration, and then the start time is reset (i.e. the age timer is restarted) every time the QoE configuration is reconfigured.

[0200] In additional or alternative embodiments, the start time may be the time when the UE is configured with the QoE configuration, and then the start time is reset (i.e. the age timer is restarted) every time the a QoE measurement session is started.

[0201] In additional or alternative embodiments, the start time may be the time when the UE is configured with the QoE configuration, and then the start time is reset (i.e. the age timer is restarted) every time a QoE measurement session is ended.

[0202] In additional or alternative embodiments, the start time may be when no QoE measurements have been started within 48 hours (e.g. after the UE was configured with the QoE configuration or after the latest start of a QoE measurement session (pertaining to the QoE configuration) or after the latest end of a QoE measurement session (pertaining to the QoE configuration). In some examples, another time value than 48 hours may be used in the above, wherein this time value may be configured or specified in a standard.

[0203] In additional or alternative embodiments, the start time may be when the UE has not been able to transmit the configurations and / or reports within 48 hours (or any other configured or specified time limit).

[0204] In additional or alternative embodiments, the start time may be when the buffer for storing the reports is full or when the amount of memory allocated for storing the reports pertaining to a specific QoE configuration is full.

[0205] In additional or alternative embodiments, the start time may be when the configuration is received by the UE + some delay, or when any of the events listed herein occur + some delay. The delay can be decided by the UE, or hard-coded at the UE (e.g., set by the manufacturer).

[0206] In additional or alternative embodiments, the age timer is reset when at least one of the following occurs: the UE autonomously releases all the QoE configuration(s) (and / or RVQoE configuration) existing at the UE; the UE autonomously releases one of the QoE configurations (and / or RVQoE configurations) existing at the UE; the UE autonomouslyreleases the last (or the only) QoE configuration (and / or RVQoE configuration) existing at the UE; the UE autonomously releases the network version of the QoE / RVQoE configuration(s); and the UE autonomously releases the UE version of the QoE / RVQoE configuration(s).

[0207] Embodiments enabling the network to know when a UE will autonomously release, or has autonomously released, a QoE configuration are described below. The different procedures below target different scenarios or circumstances, partly depending on future agreements in 3GPP. The preferable choice of procedure to specify and / or implement depends on various circumstances which may be the result of aspects that are yet open (or at least not fully specified) in the standardization process. In some embodiments, the circumstances include at least one of: Wwhether a hard age limit or a soft age limit is used; whether the UE-based solution or the CN-based solution is used for storing of the NW-QoE configuration when the UE is in RRC IDLE state (and has been configured with QoE measurements applicable in RRC IDLE state); whether the start time for the time to be compared with the 48 hour time limit is defined in a way that the network, e.g. a gNB, can be aware of this start time at the time of the start time; and whether the age limit is applicable in all RRC states or only in one certain RRC state or in a subset of the RRC states.

[0208] Example Embodiments are described below.

[0209] Example Embodiment 1 - a hard age limit applicable in any RRC state, and a definition of the start time for the age timer that allows the RAN to be aware of the start time at the time of the start time are provided. Either the UE-based solution or the CN-based solution for storage of NW-QoE configuration information is used. The gNB creates a timestamp (e.g. a UTC timestamp) indicating the time the UE was configured. If the UE is handed over to another gNB, the timestamp is transferred to the new gNB in the XnAP HANDOVER REQUEST message. Moreover, the timestamp may be included in the XnAP signalling for MN-SN coordination for QoE measurements pursued by a UE in NR-DC mode. If the UE transits to RRC INACTIVE state and later resumes in another gNB (or reestablishes the RRC connection in another gNB), then the timestamp is transferred to the new gNB for instance in the RETRIEVE UE CONTEXT RESPONSE XnAP message. Furthermore, the timestamp is included in the NW-QoE configuration. The time stamp allows the current gNB to always calculate the current value of the age timer, and since a hard age limit is assumed, this allows the gNB to know when the UE will autonomously release the QoE configuration (or if the UE has released the QoE configuration when the UE transits from RRC IDLE to RRC CONNECTED state). If the UE-based solution for storage of NW-QoE configuration information is used, and the gNB the UE connects to when it transits from RRC IDLE to RRC CONNECTED state doesnot receive any NW-QoE configuration information from the UE, this implies that either the UE has autonomously released the QoE configuration or the UE was not configured with the QoE configuration in the first place. Alternatively, if a UE has released the configuration, it may indicate that explicitly to the gNB serving it upon return to the RRC_CONNECTED state, or immediately upon the release.

[0210] Example Embodiment 2 - a hard age limit applicable only in RRC IDLE and RRC_INACTIVE state, and a definition of the start time for the age timer that allows the RAN to be aware of the start time at the time of the start time are provided. The UE-based solution for storage of NW-QoE configuration information is used. In some examples, if the UE is handed over to another gNB, the timestamp is transferred to the new gNB in the XnAP HANDOVER REQUEST message or transferred to the new gNB via the Core Network in case of NG Handover. If the UE transits to RRC INACTIVE state and later resumes in another gNB (or reestablishes the RRC connection in another gNB), then the timestamp is transferred to the new gNB for instance in the RETRIEVE UE CONTEXT RESPONSE XnAP message. For a UE in NR-DC mode, the timestamp can be transferred in XnAP messages for MN-SN coordination for QoE measurements. The timestamp is included in the NW-QoE configuration information. In additional or alternative examples, if the UE autonomously releases the QoE configuration in RRC INACTIVE state the UE informs the network upon or in conjunction with the resume of the RRC connection. If the UE autonomously releases the QoE config in RRC IDLE state, lack of NW-QoE configuration information from the UE to the gNB at RRC connection setup indicates that either the UE has autonomously released the QoE configuration or the UE was not configured with the QoE configuration in the first place. Alternatively, an explicit indication from the UE can be used also in this case.

[0211] Example Embodiment 3 - a hard age limit applicable only in RRC IDLE and RRC_INACTIVE state, and a definition of the start time for the age timer that allows the RAN to be aware of the start time at the time of the start time is provided. The UE-based solution for storage of NW-QoE configuration information is used. In this solution, a timestamp can be used in a similar way as in Example Embodiment 1.

[0212] Example Embodiment 4 - a hard age limit applicable only in RRC IDLE state (i.e. the UE may only autonomously release the QoE configuration in RRC IDLE state), and a definition of the start time for the age timer that allows the RAN to be aware of the start time at the time of the start time are provided. The UE-based solution for storage of NW-QoE configuration information is used. UE autonomous release is allowed only in RRC IDLE state. Lack of NW-QoE configuration information from the UE to the gNB at RRC connection setupindicates that either the UE has autonomously released the QoE configuration or the UE was not configured with the QoE config in the first place. As an alternative to relying on the lack of NW- QoE configuration as an implicit indication, when the UE transits from RRC IDLE to RRC_CONNECTED state, the UE may explicitly indicate to the gNB that it released the configuration.

[0213] Example Embodiment 5 - a hard age limit applicable only in RRC IDLE state, and a definition of the start time for the age timer that allows the RAN to be aware of the start time at the time of the start time are provided. The CN-based solution for storage of NW-QoE configuration information is used. In this solution, a timestamp can be used in a similar way as in Example Embodiment 1 (i.e. the timestamp is transferred between gNBs in XnAP HANDOVER REQUEST and / or XnAP RETRIEVE UE CONTEXT RESPONSE messages when applicable, or transferred between gNBs via the Core Network, and included in the NW- QoE configuration. The timestamp may also be transferred in XnAP messages for MN-SN coordination for QoE measurements performed by a UE in NR-DC). The timestamp enables the network to know whether the UE autonomously released the QoE config while the UE was in RRC IDLE state.

[0214] Example Embodiment 6 - a soft age limit (and / or a definition of the start time of the age timer that does not allow the RAN to be aware of the start time) applicable in any RRC state are provided. The UE-based solution for storage of NW-QoE configuration information is used. The UE informs the network of any UE autonomous release of a QoE configuration.

[0215] If the UE autonomously releases the QoE configuration in RRC CONNECTED state, the UE informs the network immediately e.g. using an RRC message (optionally respecting C-DRX in the sense that the UE does not wake up to inform the network during a sleep period).

[0216] If the UE autonomously releases the QoE configuration in RRC INACTIVE state, the UE informs the network upon or in conjunction with the resume of the RRC connection.

[0217] If the UE autonomously releases the QoE configuration in RRC IDLE state, the UE informs the network upon or in conjunction with the establishment / setup of a new RRC connection. In this case, informing the network can be done implicitly, i.e. the lack of NW-QoE configuration information from UE to gNB at RRC connection setup indicates that either the UE has autonomously released the QoE configuration or the UE was not configured with the QoE configuration in the first place. An alternative to using such an implicit informing of the network may be an explicit indication upon or in conjunction with the establishment / setup of the RRC connection.

[0218] Example Embodiment 7 - a soft age limit (and / or a definition of the start time of the age timer that does not allow the RAN to be aware of the start time) applicable in any RRC state is provided. The CN-based solution for storage of NW-QoE configuration information is used. The UE informs the network of any UE autonomous release of a QoE configuration.

[0219] If the UE autonomously releases the QoE configuration in RRC CONNECTED state, the UE informs the network immediately e.g. using an RRC message (optionally respecting C-DRX in the sense that the UE does not wake up to inform the network during a sleep period).

[0220] If the UE autonomously releases the QoE configuration in RRC INACTIVE state, the UE informs the network upon or in conjunction with the resume of the RRC connection.

[0221] If the UE autonomously releases the QoE config in RRC IDLE state, the UE (explicitly) informs the network upon or in conjunction with the establishment / setup of a new RRC connection.

[0222] Example Embodiment 8 - a soft age limit (and / or a definition of the start time of the age timer that does not allow the RAN to be aware of the start time) applicable only in RRC IDLE and RRC INACTIVE state is provided. The UE-based solution for storage of NW- QoE configuration information is used. The UE informs the network of any UE autonomous release of a QoE configuration.

[0223] If the UE autonomously releases the QoE configuration in RRC INACTIVE state, the UE informs the network upon or in conjunction with the resume of the RRC connection.

[0224] If the UE autonomously releases the QoE configuration in RRC IDLE state, the UE informs the network upon or in conjunction with the establishment / setup of a new RRC connection. In this case, informing the network can be done implicitly, i.e. the lack of NW-QoE configuration information from UE to gNB at RRC connection setup indicates that either the UE has autonomously released the QoE configuration or the UE was not configured with the QoE configuration in the first place. An alternative to using such an implicit informing of the network may be an explicit indication upon or in conjunction with the establishment / setup of the RRC connection.

[0225] Example Embodiment 9 - a soft age limit (and / or a definition of the start time of the age timer that does not allow the RAN to be aware of the start time) applicable only in RRC IDLE and RRC INACTIVE state is provided. The CN-based solution for storage of NW- QoE configuration information is used. The UE informs the network of any UE autonomous release of a QoE configuration.

[0226] If the UE autonomously releases the QoE configuration in RRC INACTIVE state, the UE informs the network upon or in conjunction with the resume of the RRC connection.

[0227] If the UE autonomously releases the QoE config in RRC IDLE state, the UE(explicitly) informs the network upon or in conjunction with the establishment / setup of a new RRC connection.

[0228] Example Embodiment 10 - a soft age limit (and / or a definition of the start time of the age timer that does not allow the RAN to be aware of the start time) applicable only in RRC IDLE state. The UE-based solution for storage of NW-QoE configuration information is used. The UE informs the network of any UE autonomous release of a QoE configuration.

[0229] If the UE autonomously releases the QoE configuration in RRC IDLE state, the UE informs the network upon or in conjunction with the establishment / setup of a new RRC connection. In this case, informing the network can be done implicitly, i.e. the lack of NW-QoE configuration information from UE to gNB at RRC connection setup indicates that either the UE has autonomously released the QoE configuration or the UE was not configured with the QoE configuration in the first place. An alternative to using such an implicit informing of the network may be an explicit indication upon or in conjunction with the establishment / setup of the RRC connection.

[0230] Example Embodiment 11 - a soft age limit (and / or a definition of the start time of the age timer that does not allow the RAN to be aware of the start time) applicable only in RRC IDLE state is provided. The CN-based solution for storage of NW-QoE configuration information is used. The UE informs the network of any UE autonomous release of a QoE configuration.

[0231] If the UE autonomously releases the QoE config in RRC IDLE state, the UE(explicitly) informs the network upon or in conjunction with the establishment / setup of a new RRC connection.

[0232] Embodiments associated with receiving (periodic) updates of the status of the QoE configurations at the UE are described below.

[0233] In some embodiments, a network node (e.g., a gNB), upon configuring a UE for QoE / RVQoE measurements, provides a timer (e.g., a “periodic QoE configuration status update” timer), instructing the UE to provide to the network the status of the QoE configurations and / or RVQoE configurations it has been configured with, upon expiry of the “periodic QoE configuration status update”. In case the UE autonomously releases previously configured QoE / RVQoE configurations, and there is no information sent by the UE to the network (e.g., to the gNB) until the "periodic QoE configuration status update” timer expires - to inform thenetwork of the release of the above QoE / RVQoE configuration(s) - the network assumes that the QoE / RVQoE configuration(s) previously configured for the UE is(are) no longer in use.

[0234] In additional or alternative embodiments, the network (e.g., a RAN node) may inquire the UE, asking about which QoE / RVQoE configurations have been released or asking about whether a specific QoE / RVQoE configuration has been released. The inquiry can be realized explicitly, or implicitly (the latter, for example can be realized as an attempt of the network to fetch from the UE pending QoE / RVQoE reports available at the UE for certain QoE reference(s) and / or measConflgAppLayerld, and obtaining in response the information that no QoE / RVQoE configuration(s) corresponding to the provided QoE reference(s) (and / or measConflgAppLayerld) are available at the UE. In alternative the UE returns a failure to the inquiry, from which the network deduces that the UE has autonomously released the QoE / RVQoE configuration(s) to which the QoE reference(s) and / or measConflgAppLayerld were associated with.

[0235] In additional or alternative embodiments, the UE’s obligation to release (i.e. that the UE shall release) or permission to release (i.e. that the UE is allowed to release) a configuration is limited to one or more RRC states, e.g. limited to RRC IDLE state, or limited to RRC IDLE and RRC INACTIVE state, or limited to RRC CONNECTED and RRC INACTIVE state, or limited to RRC CONNECTED state.

[0236] In additional or alternative embodiments, the 48 hour age / time limit, may have another value than 48 hours. In some examples, the age / time limit may be either configured by the network or specified in a standard, hardcoded at the UE, configured at the RAN by the 0AM, or decided independently by the UE.

[0237] In the timestamp-based embodiments where it is assumed that the CN-based solution for storage of the NW-QoE configuration while the UE is in RRC IDLE state is to be used, an alternative to storing a timestamp in the NW-QoE configuration may be that the UE, upon or in conjunction with, RRC connection establishment / setup (i.e. upon or in conjunction with the UE’s transition from RRC IDLE to RRC CONNECTED state) sends to the gNB an indication of the age of the concerned QoE configuration. Such an age indication may e.g. have the form of a timestamp of the time when the QoE configuration was configured in the UE, an indication of the age of the concerned QoE configuration, or an indication of the time remaining until the UE will autonomously release the QoE configuration (unless the age timer is restarted). If the UE- based solution for storage of the NW-QoE configuration while the UE is in RRC IDLE state is used, an alternative to including a timestamp in the NW-QoE configuration may be that the UE, upon or in conjunction with, RRC connection establishment / setup (i.e. upon or in conjunctionwith the UE’s transition from RRC IDLE to RRC CONNECTED state) sends to the gNB an indication of the age of the concerned QoE configuration (e.g. of any of the above described forms) separate from the NW-QoE configuration, e.g. in the same message as the NW-QoE configuration or in a different message.

[0238] In some embodiments, where the UE, after returning to RRC_CONNECTED state from RRC INACTIVE state or RRC IDLE state (and in case the UE has released the QoE configuration while in RRC INACTIVE or RRC IDLE state), informs the gNB that it has released the QoE configuration, the UE will not resume from RRC INACTIVE state to RRC_CONNECTED state for the sole purpose of informing the gNB that the UE has released the QoE configuration, and / or the UE will not establish an RRC connection to the gNB (i.e. transit from RRC IDLE to RRC CONNECTED state) for the sole purpose of informing the gNB that the UE has released the QoE configuration. Instead, the UE may inform the gNB that it has released the QoE configuration when the UE anyway resumes from RRC INACTIVE to RRC_CONNECTED state triggered by something else (e.g. to set up a call or allow an app to communicate) or when the UE anyway establishes an RRC connection to the gNB (i.e. transits from RRC IDLE to RRC CONNECTED state) triggered by something else (e.g. to set up a call or allow an app to communicate). In some other variants, the UE may resume from RRC_INACTIVE state to RRC_CONNECTED state for the sole purpose of informing the gNB that the UE has released the QoE configuration and / or the UE may establish an RRC connection to the gNB (i.e. transit from RRC IDLE to RRC CONNECTED state) for the sole purpose of informing the gNB that the UE has released the QoE configuration.

[0239] Various embodiments are described below to control the keeping (or the releasing) of QoE / RVQoE configuration(s) and associated QoE report(s) where in the different variants a UE is configured with at least one QoE configuration (and / or one RVQoE configuration) and one timer (whose start or restart can occur according to any of the embodiments described above) and one or more UE variables are used.

[0240] In some examples, one timer and one UE variable are used, wherein the timer controls the keeping of the QoE / RVQoE configuration(s) applied by the UE and the associated QoE / RVQoE report(s). The UE variable may or may not contain theNW-QoE-configuration. The timer is started when QoE configuration is sent to the UE, (or as per previous solution described in the invention). When the timer expires the UE discards the QoE configuration(s) and the QoE / RVQoE reports associated with it(them).

[0241] In additional or alternative examples, one timer and one UE variable are used, wherein the timer controls the keeping of the QoE / RVQoE configuration(s) applied by the UEand the associated QoE / RVQoE report(s). The UE variable may or may not contain the NW- QoE-configuration. The timer is started / restarted every time the UE enters RRC IDLE state, and it is reset when the UE enters RRC INACTIVE or RRC CONNECTED state (in alternative, the timer is not reset, but paused). When timer expires the UE discards the QoE configuration(s) and the QoE / RVQoE reports associated to it(them).

[0242] In additional or alternative examples, one timer and one UE variable are used, wherein the timer controls the keeping of the QoE / RVQoE configuration(s) applied by the UE and the associated QoE / RVQoE report(s). The UE variable may or may not contain the NW- QoE-configuration. The timer is started when the QoE configuration is sent to the UE (or as per previous solution described in the invention). The timer is reset when the UE sends to the network any application session indication / a QoE / RVQoE report (in alternative, the timer is not reset, but paused). When timer expires the UE discards the QoE configuration(s) and the QoE / RVQoE reports associated to it(them).

[0243] In additional or alternative examples, one timer and one UE variable are used, wherein the timer controls the keeping of the QoE / RVQoE configuration(s) applied by the UE and the associated QoE / RVQoE report(s). The UE variable may or may not contain the NW- QoE-configuration. The timer is started when the QoE configuration is sent to the UE (or as per previous solution described in the invention). The timer is reset / restarted when at least one of: 1) the UE transitions to RRC INACTIVE or RRC CONNECTED state (without sending any QoE measurement session status indication (e.g. the appLayerSessionStatus-r 17 IE set to “start” or “stop”) or or QoE / RVQoE report); and 2) the UE (while in RRC CONNECTED), sends to the network a QoE measurement session status indication (e.g. the appLayerSessionStatus-r 17 IE set to “start” or “stop”) or a QoE / RVQoE report).

[0244] In additional or alternative examples, when the timer expires the UE discards the QoE configuration(s) and the QoE / RVQoE reports associated to it(them).

[0245] In additional or alternative examples, two timers and more than one UE variable is used, wherein the first timer controls the time when the QoE / RVQoE configuration(s) applied by the UE are to be released by the UE. A first UE variable maintains a portion of the QoE configuration(s) that UE is mandated to release at timer expiry (called here UE-QoE-conf-part- 1), a second UE variable maintains a part of the QoE configuration(s) that the UE shall (or can, or may) maintain to be able to send the NW-QoE configuration(s) to the network, e.g., upon transitioning from RRC IDLE to RRC CONNECTED. The timer is reset every time the UE enters RRC IDLE. When the timer expires: the UE shall release the UE-QoE-config-part-1 and the second timer (e.g., the one due to last 48 hours, or an alternative value, either configured orhardcoded) starts. When this second timer expires, the UE shall / can / may discard the QoE / RVQoE reports.

[0246] In additional or alternative examples involving a UE variable, there is no UE variable (at least not any UE variable specified in a standard), but the UE remembers the required information in implementation-specific ways.

[0247] In some embodiments involving new information (e.g., a timestamp of the time when the UE was configured with a QoE configuration) is transferred between a source gNB and a target gNB in the HANDOVER REQUEST XnAP message, the same information may instead be transferred from the source gNB to the target gNB via the core network, i.e. via an AMF (or via two AMFs in case of an inter- AMF handover), where in the information would be sent from the source gNB to the AMF in a HANDOVER REQUIRED NGAP message and from the AMF to the target gNB in a HANDOVER REQUEST NGAP message.

[0248] In additional or alternative embodiments, applicable to all the solutions presented herein where the RAN sets the conditions for configuration release, the 0AM may send the conditions as a part of QoE configuration to the UE or together with the QoE configuration to the RAN. In some examples, UE capability signaling may be defined, to indicate to the network which of the features described herein the UE is able to support.

[0249] Operations of the communication device 1700 (implemented using the structure of FIG. 17) will now be discussed with reference to the flow charts of FIGS. 12-13 according to some embodiments of inventive concepts. For example, modules may be stored in memory 1710 of FIG. 17, and these modules may provide instructions so that when the instructions of a module are executed by respective communication device processing circuitry 1702, communication device 1700 performs respective operations of the flow charts.

[0250] FIG. 12 illustrates an example of operations performed by a communication device to synchronize configuration release between the communication device and a network node based on a timestamp.

[0251] At block 1210, processing circuitry 1702 receives, via communication interface 1712, a message from the network node including an indication of a configuration. At block 1220, processing circuitry 1702 transmits a response, via communication interface 1712, to the network node. At block 1230, processing circuitry 1702 implements the configuration. In some embodiments, the configuration includes a QoE configuration and / or a RVQoE configuration. At block 1240, processing circuitry 1702 determines a start time associated with the configuration. At block 1250, processing circuitry 1702 performs an action. In some examples, the action includes transmitting at least one of: a report based on the new configuration (or theexisting configuration); a session start indication associated with the new configuration; and a session end indication associated with the new configuration. At block 1260, processing circuitry 1702 resets the start time in response to performing the action. At block 1270, processing circuitry 1702 reconfigures the configuration without adjusting the start time. At block 1280, processing circuitry 1702 determines that an amount of time that has elapsed since the start time exceeds a threshold amount of time. In some examples, determining the amount of time that has elapsed since the start time exceeds the threshold amount of time includes initiating a timer at the start time (the timer being set to the amount of time) and determining that the timer has expired. At block 1290, processing circuitry 1702 releases the configuration.

[0252] In some embodiments, determining the start time includes determining the start time based on a time at which the communication device was released to a RRC idle state. In additional or alternative embodiments, determining the start time includes determining the start time based on at least one of: a time at which the communication device was released to a RRC inactive state; a type of measurement associated with the configuration; a predetermined delay; a configured delay indicated by the network node; a time at which the communication device transmits a first report based on the configuration; a time at which the communication device transmits a first session start indication; a time at which the communication device transmits a first report based on the configuration at an end of a session; a time at which a period of time has elapsed without the configuration being used to transmit at least one of a report, a session start indication, or a session end indication; a RRC state of the communication device; a time at which the communication device begins a first measurement session based on the configuration; a time at which the communication device ends the first measurement session based on the configuration; a time at which a period of time has elapsed without the communication device starting a measurement session based on the configuration; a time at which a period of time has elapsed without the communication device being able to transmit a report based on the configuration; and a time at which a buffer for storing reports associated with the configuration exceeds a threshold amount.

[0253] FIG. 13 illustrates an example of operations performed by a communication device to synchronize configuration release between the communication device and a network node based on a signal from the communication device.

[0254] At block 1310, processing circuitry 1702 receives, via communication interface 1712, a message from the network node including an indication of the configuration. At block 1320, processing circuitry 1702 configures the communication device with a configuration. In some embodiments, the configuration includes a QoE configuration and / or a RVQoEconfiguration. At block 1330, processing circuitry 1702 receives, via communication interface 1712, a request from the network node for the indication of whether the communication device has released the configuration. At block 1340, processing circuitry 1702 transmits, via communication interface 1712, an indication to a network node of whether the communication device has released the configuration. At block 1350, processing circuitry 1702 releases the configuration.

[0255] Various operations from the flow charts of FIGS. 12-13 may be optional with respect to some embodiments of communication devices and related methods.

[0256] Operations of the network node 1800 (implemented using the structure of FIG. 18) will now be discussed with reference to the flow charts of FIGS. 14-15 according to some embodiments of inventive concepts. For example, modules may be stored in memory 1804 of FIG. 18, and these modules may provide instructions so that when the instructions of a module are executed by respective network node processing circuitry 1802, network node 1800 performs respective operations of the flow charts.

[0257] FIG. 14 illustrates an example of operations performed by a network node to synchronize configuration release between a communication device and the network node based on a timestamp.

[0258] At block 1410, processing circuitry 1802 transmits, via communication interface 1806, a message to the communication device including an indication of a configuration. At block 1420, processing circuitry 1802 receives a response, via communication interface 1806, from the communication device. At block 1430, processing circuitry 1802 determines a start time associated with a configuration of the communication device. In some embodiments, the configuration includes a QoE configuration and / or a RVQoE configuration. At block 1440, processing circuitry 1802 performs an action. At block 1450, processing circuitry 1802 resets the start time in response to performing the action. At block 1460, processing circuitry 1802 reconfigures the configuration without adjusting the start time. At block 1470, processing circuitry 1802 determines that an amount of time that has elapsed since the start time exceeds a threshold amount of time. At block 1480, processing circuitry 1802 determines that the communication device has released the configuration.

[0259] FIG. 15 illustrates an example of operations performed by a network node to synchronize configuration release between a communication device and the network node based on a signal from the communication device.

[0260] At block 1510, processing circuitry 1802 transmits, via communication interface 1806, a message to the communication device including an indication of the configuration. Atblock 1520, processing circuitry 1802 configures the communication device with a configuration. In some embodiments, the configuration includes a QoE configuration and / or a RVQoE configuration. At block 1530, processing circuitry 1802 transmits, via communication interface 1806, a request to the communication device for an indication of whether the communication device has released the configuration. At block 1540, processing circuitry 1802 receives, via communication interface 1806, an indication from the communication device of whether the communication device has released the configuration. At block 1550, processing circuitry 1802 determines whether the communication device has released the configuration.

[0261] Various operations from the flow chart of FIGS. 14-15 may be optional with respect to some embodiments of network nodes and related methods.

[0262] Example Embodiments are described below.

[0263] Embodiment 1. A method of operating a communication device (1700), in a communications network, the method comprising: configuring (1230) the communication device with a configuration that includes a quality of experience, QoE, configuration and / or a radio access network-visible QoE, RVQoE, configuration; determining (1240) a start time associated with the configuration; determining (1280) that an amount of time that has elapsed since the start time exceeds a threshold amount of time; and responsive to determining than the amount of time that has elapsed since the start time exceeds the threshold amount of time, releasing (1290) the configuration.

[0264] Embodiment 2. The method of Embodiment 1, further comprising: receiving (1210) a message from a network node, the message including an indication of the configuration, wherein determining the start time comprises determining the start time based on a time that the message was received by the communication device.

[0265] Embodiment 3. The method of any of Embodiments 1-2, further comprising: receiving (1210) a message from a network node, the message including an indication of the configuration; and responsive to receiving the message from the network node, transmitting (1220) a response to the network node, wherein determining the start time comprises determining the start time based on a time that the response was transmitted by the communication device.

[0266] Embodiment 4. The method of any of Embodiments 1-3, further comprising:receiving (1210) a message from a network node, the message including an indication of the configuration and an indication of the start time, wherein determining the start time comprises determining the start time based on the indication of the start time.

[0267] Embodiment 5. The method of any of Embodiments 1-4, wherein determining the start time associated with the configuration comprises determining the start time based on a time at which the communication device configured the configuration.

[0268] Embodiment 6. The method of any of Embodiments 1-5, wherein the configuration comprises a new configuration, wherein configuring the communication device with the new configuration comprises reconfiguring an existing configuration of the communication device with the new configuration, and wherein determining the start time associated with the new configuration comprises replacing an existing start time associated with the existing configuration with the start time associated with the new configuration.

[0269] Embodiment 7. The method of Embodiment 6, wherein replacing the existing start time comprises: determining a difference between the existing configuration and the new configuration, the difference including at least one of: the existing configuration being associated with single connectivity and the new configuration being associated with multi-connectivity; the existing configuration being associated with a first multi-connectivity and the new configuration being associated with a second multi-connectivity; and the existing configuration being associated with multi-connectivity and the new configuration being associated with single connectivity; and responsive to determining the difference between the existing configuration and the new configuration, replacing the existing start time associated with the existing configuration with the start time associated with the new configuration.

[0270] Embodiment s. The method of any of Embodiment 1-7, further comprising: subsequent to determining the start time and prior to determining the amount of time has elapsed since the start time, performing (1250) an action comprising at least one of: transmitting a report based on the configuration; transmitting a session start indication associated with the configuration; and transmitting a session end indication associated with the configuration; andresponsive to performing the action, resetting (1260) the start time.

[0271] Embodiment 9. The method of any of Embodiments 1-8, wherein determining the start time comprises determining the start time based on a type of measurement associated with the configuration.

[0272] Embodiment 10. The method of any of Embodiments 1-9, wherein determining the start time comprises determining the start time associated with the configuration based on a delay that includes at least one of: a predetermined delay; and a configured delay indicated by the network node.

[0273] Embodiment 11. The method of any of Embodiments 1-10, wherein determining the start time associated with the configuration comprises determining the start time based on at least one of: a time at which the communication device is released to a RRC INACTIVE state; a time at which the communication device is released to a RRC IDLE state; a time at which the communication device transmits a first report based on the configuration; a time at which the communication device transmits a first session start indication; a time at which the communication device transmits a first report based on the configuration at an end of a session; a time at which a period of time has elapsed without the configuration being used to transmit a report, a session start indication, or a session end indication.

[0274] Embodiment 12. The method of any of Embodiments 1-11, wherein determining the start time associated with the configuration comprises determining the start time based on a radio resource control, RRC, state of the communication device.

[0275] Embodiment 13. The method of any of Embodiments 1-12, wherein determining the start time associated with the configuration comprises determining the start time based on at least one of: a time at which the communication device begins a first measurement session based on the configuration; a time at which the communication device ends the first measurement session based on the configuration; a time at which a period of time has elapsed without the communication device starting a measurement session based on the configuration; a time at which a period of time has elapsed without the communication device being ableto transmit a report based on the configuration; and a time at which a buffer for storing reports associated with the configuration exceeds a threshold amount.

[0276] Embodiment 14. The method of any of Embodiments 1-13, further comprising: prior to determining that the amount of time that has elapsed since the start time exceeds the threshold amount of time, reconfiguring (1270) the configuration without adjusting the start time.

[0277] Embodiment 15. The method of any of Embodiments 1-14, wherein the threshold amount of time is a predetermined amount of time, and wherein the predetermined amount of time is 48 hours.

[0278] Embodiment 16. The method of any of Embodiments 1-14, wherein the threshold amount of time is configured.

[0279] Embodiment 17. A method of operating a communication device (1700), in a communications network, the method comprising: configuring (1320) the communication device with a configuration that includes a quality of experience, QoE, configuration and / or a radio access network-visible QoE, RVQoE, configuration; transmitting (1340) an indication to a network node of whether the communication device has released the configuration; and releasing (1350) the configuration.

[0280] Embodiment 18. The method of Embodiment 17, further comprising: receiving (1310) a message from the network node, the message including an indication of the configuration.

[0281] Embodiment 19. The method of any of Embodiments 17-18, further comprising: receiving (1330) a message from the network node indicating a time at which to transmit the indication of whether the communication device has released the configuration, wherein transmitting the indication to the network node of whether the communication device has released the configuration comprises transmitting the indication to the network node of whether the communication device has released the configuration at the time.

[0282] Embodiment 20. The method of any of Embodiments 17-19, further comprising: receiving (1330) a request from the network node for the indication of whether the communication device has released the configuration, wherein transmitting the indication to the network node of whether the communication device has released the configuration comprises transmitting the indication to the network nodeof whether the communication device has released the configuration in response to the request.

[0283] Embodiment 21. A method of operating a network node (1800), in a communications network, the method comprising: determining (1430) a start time associated with a configuration of a communication device, the configuration including a quality of experience, QoE, configuration and / or a radio access network- visible QoE, RVQoE, configuration; determining (1470) that an amount of time that has elapsed since the start time exceeds a threshold amount of time; and responsive to determining than the amount of time that has elapsed since the start time exceeds the threshold amount of time, determining (1480) that the communication device released the configuration.

[0284] Embodiment 22. The method of Embodiment 21, further comprising: transmitting (1410) a message to the communication device, the message including an indication of the configuration.

[0285] Embodiment 23. The method of Embodiment 22, wherein determining the start time comprises determining the start time based on a time that the message was transmitted to the communication device.

[0286] Embodiment 24. The method of any of Embodiments 22-23, further comprising: responsive to transmitting the message to the communication device, receiving (1420) a response from the communication device, wherein determining the start time comprises determining the start time based on a time that the response was received from the communication device.

[0287] Embodiment 25. The method of any of Embodiments 22-24, wherein the message includes an indication of the configuration and an indication of the start time.

[0288] Embodiment 26. The method of any of Embodiments 1-5, wherein the configuration comprises a new configuration, wherein determining the start time associated with the new configuration comprises replacing an existing start time associated with the existing configuration with the start time associated with the new configuration.

[0289] Embodiment 27. The method of Embodiment 26, wherein replacing the existing start time comprises: determining a difference between the existing configuration and the new configuration, the difference including at least one of:the existing configuration being associated with single connectivity and the new configuration being associated with multi-connectivity; the existing configuration being associated with a first multi-connectivity and the new configuration being associated with a second multi-connectivity; and the existing configuration being associated with multi-connectivity and the new configuration being associated with single connectivity; and responsive to determining the difference between the existing configuration and the new configuration, replacing the existing start time associated with the existing configuration with the start time associated with the new configuration.

[0290] Embodiment 28. The method of any of Embodiment 21-27, further comprising: subsequent to determining the start time and prior to determining the amount of time has elapsed since the start time, performing (1440) an action comprising at least one of: receiving a report based on the configuration; receiving a session start indication associated with the configuration; and receiving a session end indication associated with the configuration; and responsive to performing the action, resetting (1450) the start time.

[0291] Embodiment 29. The method of any of Embodiments 21-28, wherein determining the start time comprises determining the start time based on a type of measurement associated with the configuration.

[0292] Embodiment 30. The method of any of Embodiments 21-29, wherein determining the start time comprises determining the start time associated with the configuration based on a delay that includes at least one of: a predetermined delay; and a configured delay.

[0293] Embodiment 31. The method of any of Embodiments 21-30, wherein determining the start time associated with the configuration comprises determining the start time based on at least one of: a time at which the communication device is released to a RRC INACTIVE state; a time at which the communication device is released to a RRC IDLE state; a time at which the network node receives a first report based on the configuration; a time at which the network node receives a first session start indication; a time at which the network node receives a first report based on the configuration at an end of a session; a time at which a period of time has elapsed without the network node receiving a report, asession start indication, or a session end indication based on the configuration.

[0294] Embodiment 32. The method of any of Embodiments 21-31, wherein determining the start time associated with the configuration comprises determining the start time based on a radio resource control, RRC, state of the communication device.

[0295] Embodiment 33. The method of any of Embodiments 21-32, further comprising: prior to determining that the amount of time that has elapsed since the start time exceeds the threshold amount of time, reconfiguring (1460) the configuration without adjusting the start time.

[0296] Embodiment 34. The method of any of Embodiments 21-33, wherein the threshold amount of time is a predetermined amount of time, and wherein the predetermined amount of time is 48 hours.

[0297] Embodiment 35. The method of any of Embodiments 21-34, wherein the threshold amount of time is configured.

[0298] Embodiment 36. A method of operating a network node (1800), in a communications network, the method comprising: configuring (1520) a communication device with a configuration that includes a quality of experience, QoE, configuration and / or a radio access network-visible QoE, RVQoE, configuration; receiving (1540) an indication from the communication device of whether the communication device has released the configuration; and determining (1560) whether the communication device has released the configuration based on the indication from the communication device.

[0299] Embodiment 37. The method of Embodiment 36, further comprising: transmitting (1510) a message to the communication device, the message including an indication of the configuration.

[0300] Embodiment 38. The method of any of Embodiments 36-37, further comprising: transmitting (1530) a message to the communication device indicating a time at which to transmit the indication of whether the communication device has released the configuration, wherein receiving the indication from the communication device of whether the communication device has released the configuration comprises receiving the indication from the communication device of whether the communication device has released the configuration at the time.

[0301] Embodiment 39. The method of any of Embodiments 36-38, further comprising: transmitting (1530) a request to the communication device for the indication of whetherthe communication device has released the configuration, wherein receiving the indication from the communication device of whether the communication device has released the configuration comprises receiving the indication from the communication device of whether the communication device has released the configuration in response to the request.

[0302] Embodiment 40. The method of any of Embodiments 36-39, wherein the network node is a first network node, the method further comprising: transmitting (1550) the start time to a second network node.

[0303] Embodiment 41. A communication device (1700), configured to perform any of the operations of Embodiments 1-20.

[0304] Embodiment 42. A computer program comprising program code to be executed by processing circuitry (1702) of a communication device (1700), whereby execution of the program code causes the communication device to perform any of the operations of Embodiments 1-20.

[0305] Embodiment 43. A computer program product comprising a non-transitory storage medium (1710) including program code to be executed by processing circuitry (1702) of a communication device (1700), whereby execution of the program code causes the communication device to perform any of the operations of Embodiments 1-20.

[0306] Embodiment 44. A communication device (1700), the communication device comprising: processing circuitry (1702); and memory (1710) coupled to the processing circuitry and having instructions stored therein that are executable by the processing circuitry to cause the communication device to perform any of the operations of Embodiments 1-20.

[0307] Embodiment 45. A non-transitory computer-readable medium having instructions stored therein that are executable by processing circuitry (1702) of a communication device (1700) to cause the communication device to perform any of the operations of Embodiments 2- 20.

[0308] Embodiment 46. A network node (1800) configured to perform any of the operations of Embodiments 21-40.

[0309] Embodiment 47. A computer program comprising program code to be executed by processing circuitry (1802) of a network node (1800), whereby execution of the program code causes the network node to perform any of the operations of Embodiments 21-40.

[0310] Embodiment 48. A computer program product comprising a non-transitory storage medium (1806) including program code to be executed by processing circuitry (1802) of a network node (1800), whereby execution of the program code causes the network node to perform any of the operations of Embodiments 21-40.

[0311] Embodiment 49. A network node (1800), the network node comprising: processing circuitry (1802); and memory (1804) coupled to the processing circuitry and having instructions stored therein that are executable by the processing circuitry to cause the network node to perform any of the operations of Embodiments 21-40.

[0312] Embodiment 50. A non-transitory computer-readable medium having instructions stored therein that are executable by processing circuitry (1802) of a network node (1800) to cause the network node to perform any of the operations of Embodiments 22-40.

[0313] Embodiment 51. A communication system configured to provide an over-the-top (OTT) service, the communication system comprising: a host comprising: processing circuitry configured to provide user data for a communication device, the user data being associated with the over-the-top service; and a network interface configured to initiate transmission of the user data toward a cellular network node for transmission to the communication device, the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of Embodiments 21-40 to transmit the user data from the host to the communication device.

[0314] Embodiment 52. The communication system of the previous embodiment, further comprising: the network node; and / or the communication device.

[0315] Embodiment 53. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to initiate receipt of user data; and a network interface configured to receive the user data from a network node in a cellular network, the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of Embodiments 21-40 to receive the user data from a communication device for the host.

[0316] Embodiment 54. The host of the previous 2 embodiments, wherein:the processing circuitry of the host is configured to execute a host application that receives the user data; and the host application is configured to interact with a client application executing on the communication device, the client application being associated with the host application.

[0317] Embodiment 55. The host of any of the previous 2 embodiments, wherein the initiating receipt of the user data comprises requesting the user data.

[0318] Embodiment 56. A method implemented by a host configured to operate in a communication system that further includes a network node and a communication device, the method comprising: at the host, initiating receipt of user data from the communication device, the user data originating from a transmission which the network node has received from the communication device, wherein the network node performs any of the steps of any of Embodiments 21-40 to receive the user data from the communication device for the host.

[0319] Embodiment 57. The method of the previous embodiment, further comprising at the network node, transmitting the received user data to the host.

[0320] Embodiment 58. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to provide user data; and a network interface configured to initiate transmission of the user data to a cellular network for transmission to a communication device, wherein the communication device comprises a communication interface and processing circuitry, the communication interface and processing circuitry of the communication device being configured to perform any of the operations of Embodiments 1-20 to receive the user data from the host.

[0321] Embodiment 59. The host of the previous embodiment, wherein the cellular network further includes a network node configured to communicate with the communication device to transmit the user data to the communication device from the host.

[0322] Embodiment 60. The host of the previous 2 embodiments, wherein: the processing circuitry of the host is configured to execute a host application, thereby providing the user data; and the host application is configured to interact with a client application executing on the communication device, the client application being associated with the host application.

[0323] Embodiment 61. A method implemented by a host operating in a communication system that further includes a network node and a communication device, the method comprising:providing user data for the communication device; and initiating a transmission carrying the user data to the communication device via a cellular network comprising the network node, wherein the communication device performs any of the operations of any of Embodiments 1-20 to receive the user data from the host.

[0324] Embodiment 62. The method of the previous embodiment, further comprising: at the host, executing a host application associated with a client application executing on the communication device to receive the user data from the host application.

[0325] Embodiment 63. The method of the previous embodiment, further comprising: at the host, transmitting input data to the client application executing on the communication device, the input data being provided by executing the host application, wherein the user data is provided by the client application in response to the input data from the host application.

[0326] Embodiment 64. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to provide user data; and a network interface configured to initiate transmission of the user data to a cellular network for transmission to a communication device, wherein the communication device comprises a communication interface and processing circuitry, the communication interface and processing circuitry of the communication device being configured to perform any of the steps of Embodiments 1-20 to transmit the user data to the host.

[0327] Embodiment 65. The host of the previous embodiment, wherein the cellular network further includes a network node configured to communicate with the communication device to transmit the user data from the communication device to the host.

[0328] Embodiment 66. The host of the previous 2 embodiments, wherein: the processing circuitry of the host is configured to execute a host application, thereby providing the user data; and the host application is configured to interact with a client application executing on the communication device, the client application being associated with the host application.

[0329] Embodiment 67. A method implemented by a host configured to operate in a communication system that further includes a network node and a communication device, the method comprising: at the host, receiving user data transmitted to the host via the network node by the communication device, wherein the communication device performs any of the steps of any of Embodiments 1-20 to transmit the user data to the host.

[0330] Embodiment 68. The method of the previous embodiment, further comprising: at the host, executing a host application associated with a client application executing on the communication device to receive the user data from the communication device.

[0331] Embodiment 69. The method of the previous 2 embodiments, further comprising: at the host, transmitting input data to the client application executing on the communication device, the input data being provided by executing the host application, wherein the user data is provided by the client application in response to the input data from the host application.

[0332] FIG. 16 shows an example of a communication system 1600 in accordance with some embodiments.

[0333] In the example, the communication system 1600 includes a telecommunication network 1602 that includes an access network 1604, such as a radio access network (RAN), and a core network 1606, which includes one or more core network nodes 1608. The access network 1604 includes one or more access network nodes, such as network nodes 1610a and 1610b (one or more of which may be generally referred to as network nodes 1610), or any other similar 3rd Generation Partnership Project (3GPP) access node or non-3GPP access point. Moreover, as will be appreciated by those of skill in the art, the network nodes 1610 are not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that the network nodes 1610 may include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 1602 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 1602 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 1602, including one or more network nodes 1610 and / or core network nodes 1608.

[0334] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU- CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time RAN control application (e.g., xApp) or a non-real time RAN automation application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user planeinterface, or an open fronthaul management plane interface. Intents and content-aware notifications described herein may be communicated from a 3GPP network node or an ORAN network node over 3GPP-defined interfaces (e.g., N2, N3) and / or ORAN Alliance-defined interfaces (e.g., Al, 01). Moreover, an ORAN network node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the 0-RAN Alliance. The network nodes 1610 facilitate direct or indirect connection of user equipment (UE), such as by connecting wireless devices 1612a, 1612b, 1612c, and 1612d (one or more of which may be generally referred to as UEs 1612) to the core network 1606 over one or more wireless connections. The network nodes 1610 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 1612a, 1612b, 1612c, and 1612d (one or more of which may be generally referred to as UEs 1612) to the core network 1606 over one or more wireless connections.

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

[0336] The UEs 1612 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 1610 and other communication devices. Similarly, the network nodes 1610 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 1612 and / or with other network nodes or equipment in the telecommunication network 1602 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 1602.

[0337] In the depicted example, the core network 1606 connects the network nodes 1610 to one or more hosts, such as host 1616. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directlycoupled to hosts. The core network 1606 includes one more core network nodes (e.g., core network node 1608) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 1608. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0338] The host 1616 may be under the ownership or control of a service provider other than an operator or provider of the access network 1604 and / or the telecommunication network 1602, and may be operated by the service provider or on behalf of the service provider. The host 1616 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

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

[0340] In some examples, the telecommunication network 1602 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 1602 may support network slicing to provide different logical networks to different devices that areconnected to the telecommunication network 1602. For example, the telecommunications network 1602 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive loT services to yet further UEs.

[0341] In some examples, the UEs 1612 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 1604 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 1604. Additionally, a UE may be configured for operating in single- or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved- UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0342] In the example, the hub 1614 communicates with the access network 1604 to facilitate indirect communication between one or more UEs (e.g., UE 1612c and / or 1612d) and network nodes (e.g., network node 1610b). In some examples, the hub 1614 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 1614 may be a broadband router enabling access to the core network 1606 for the UEs. As another example, the hub 1614 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 1610, or by executable code, script, process, or other instructions in the hub 1614. As another example, the hub 1614 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 1614 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 1614 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 1614 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 1614 acts as a proxy server or orchestrator for the UEs, in particular in if one or more of the UEs are low energy loT devices.

[0343] The hub 1614 may have a constant / persistent or intermittent connection to the network node 1610b. The hub 1614 may also allow for a different communication scheme and / or schedule between the hub 1614 and UEs (e.g., UE 1612c and / or 1612d), and between the hub 1614 and the core network 1606. In other examples, the hub 1614 is connected to the core network 1606 and / or one or more UEs via a wired connection. Moreover, the hub 1614 may beconfigured to connect to an M2M service provider over the access network 1604 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 1610 while still connected via the hub 1614 via a wired or wireless connection. In some embodiments, the hub 1614 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 1610b. In other embodiments, the hub 1614 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 1610b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0344] FIG. 17 shows a UE 1700 in accordance with some embodiments. As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0345] A UE may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle- to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller).Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

[0346] The UE 1700 includes processing circuitry 1702 that is operatively coupled via a bus 1704 to an input / output interface 1706, a power source 1708, a memory 1710, a communication interface 1712, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in FIG. 17. The level of integration between thecomponents may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

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

[0348] In the example, the input / output interface 1706 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 1700. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0349] In some embodiments, the power source 1708 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 1708 may further include power circuitry for delivering power from the power source 1708 itself, and / or an external power source, to the various parts of the UE 1700 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 1708. Power circuitry may perform any formatting, converting, or other modification to thepower from the power source 1708 to make the power suitable for the respective components of the UE 1700 to which power is supplied.

[0350] The memory 1710 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable readonly memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 1710 includes one or more application programs 1714, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 1716. The memory 1710 may store, for use by the UE 1700, any of a variety of various operating systems or combinations of operating systems.

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

[0352] The processing circuitry 1702 may be configured to communicate with an access network or other network using the communication interface 1712. The communication interface 1712 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 1722. The communication interface 1712 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 1718 and / or a receiver 1720 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 1718 and receiver 1720 may becoupled to one or more antennas (e.g., antenna 1722) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0353] In the illustrated embodiment, communication functions of the communication interface 1712 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short- range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / intemet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

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

[0355] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0356] A UE, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connecteddoorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and / or software in dependence of the intended application of the loT device in addition to other components as described in relation to the UE 1700 shown in FIG. 17.

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

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

[0359] FIG. 18 shows a network node 1800 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs), NRNodeBs (gNBs)), O-RAN nodes, or components of an O-RAN node (e.g., intelligent controller, O-RU, O-DU, O-CU).

[0360] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0361] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs).

[0362] The network node 1800 includes a processing circuitry 1802, a memory 1804, a communication interface 1806, and a power source 1808. The network node 1800 may be composed of multiple physically separate components (e.g., aNodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 1800 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 1800 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 1804 for different RATs) and some components may be reused (e.g., a same antenna 1810 may be shared by different RATs). The network node 1800 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 1800, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 1800.

[0363] The processing circuitry 1802 may comprise a combination of one or more 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 operable to provide, either alone or in conjunction with other network node 1800 components, such as the memory 1804, to provide network node 1800 functionality.

[0364] In some embodiments, the processing circuitry 1802 includes a system on a chip (SOC). In some embodiments, the processing circuitry 1802 includes one or more of radio frequency (RF) transceiver circuitry 1812 and baseband processing circuitry 1814. In some embodiments, the radio frequency (RF) transceiver circuitry 1812 and the baseband processing circuitry 1814 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 1812 and baseband processing circuitry 1814 may be on the same chip or set of chips, boards, or units.

[0365] The memory 1804 may comprise any form of volatile or non-volatile computer- readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 1802. The memory 1804 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 1802 and utilized by the network node 1800. The memory 1804 may be used to store any calculations made by the processing circuitry 1802 and / or any data received via the communication interface 1806. In some embodiments, the processing circuitry 1802 and memory 1804 is integrated.

[0366] The communication interface 1806 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, the communication interface 1806 comprises port(s) / terminal(s) 1816 to send and receive data, for example to and from a network over a wired connection. The communication interface 1806 also includes radio front-end circuitry 1818 that may be coupled to, or in certain embodiments a part of, the antenna 1810. Radio front-end circuitry 1818 comprises filters 1820 and amplifiers 1822. The radio front-end circuitry 1818 may be connected to an antenna 1810 and processing circuitry 1802. The radio front-end circuitry may be configured to condition signalscommunicated between antenna 1810 and processing circuitry 1802. The radio front-end circuitry 1818 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 1818 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 1820 and / or amplifiers 1822. The radio signal may then be transmitted via the antenna 1810. Similarly, when receiving data, the antenna 1810 may collect radio signals which are then converted into digital data by the radio front-end circuitry 1818. The digital data may be passed to the processing circuitry 1802. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0367] In certain alternative embodiments, the network node 1800 does not include separate radio front-end circuitry 1818, instead, the processing circuitry 1802 includes radio front-end circuitry and is connected to the antenna 1810. Similarly, in some embodiments, all or some of the RF transceiver circuitry 1812 is part of the communication interface 1806. In still other embodiments, the communication interface 1806 includes one or more ports or terminals 1816, the radio front-end circuitry 1818, and the RF transceiver circuitry 1812, as part of a radio unit (not shown), and the communication interface 1806 communicates with the baseband processing circuitry 1814, which is part of a digital unit (not shown).

[0368] The antenna 1810 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 1810 may be coupled to the radio front-end circuitry 1818 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 1810 is separate from the network node 1800 and connectable to the network node 1800 through an interface or port.

[0369] The antenna 1810, communication interface 1806, and / or the processing circuitry 1802 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment.Similarly, the antenna 1810, the communication interface 1806, and / or the processing circuitry 1802 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0370] The power source 1808 provides power to the various components of network node 1800 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 1808 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 1800 with power forperforming the functionality described herein. For example, the network node 1800 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 1808. As a further example, the power source 1808 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0371] Embodiments of the network node 1800 may include additional components beyond those shown in FIG. 18 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node 1800 may include user interface equipment to allow input of information into the network node 1800 and to allow output of information from the network node 1800. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 1800.

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

[0373] The host 1900 includes processing circuitry 1902 that is operatively coupled via a bus 1904 to an input / output interface 1906, a network interface 1908, a power source 1910, and a memory 1912. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as FIGS. 17 and 18, such that the descriptions thereof are generally applicable to the corresponding components of host 1900.

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

[0375] FIG. 20 is a block diagram illustrating a virtualization environment 2000 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 2000 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 2000 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface.

[0376] Applications 2002 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0377] Hardware 2004 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 2006 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 2008a and 2008b (one or more of which may be generally referred to as VMs 2008), and / or perform any of the functions, features and / or benefits described in relation with some embodiments describedherein. The virtualization layer 2006 may present a virtual operating platform that appears like networking hardware to the VMs 2008.

[0378] The VMs 2008 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 2006. Different embodiments of the instance of a virtual appliance 2002 may be implemented on one or more of VMs 2008, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0379] In the context of NFV, a VM 2008 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 2008, and that part of hardware 2004 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 2008 on top of the hardware 2004 and corresponds to the application 2002.

[0380] Hardware 2004 may be implemented in a standalone network node with generic or specific components. Hardware 2004 may implement some functions via virtualization.Alternatively, hardware 2004 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 2010, which, among others, oversees lifecycle management of applications 2002. In some embodiments, hardware 2004 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 2012 which may alternatively be used for communication between hardware nodes and radio units.

[0381] FIG. 21 shows a communication diagram of a host 2102 communicating via a network node 2104 with a UE 2106 over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with various embodiments, of the UE (such as a UE 1612a of FIG. 16 and / or UE 1700 of FIG. 17), network node (such as network node 1610a of FIG. 16 and / or network node 1800 of FIG. 18), and host (such as host 1616 ofFIG. 16 and / or host 1900 of FIG. 19) discussed in the preceding paragraphs will now be described with reference to FIG. 21.

[0382] Like host 1900, embodiments of host 2102 include hardware, such as a communication interface, processing circuitry, and memory. The host 2102 also includes software, which is stored in or accessible by the host 2102 and executable by the processing circuitry. The software includes a host application that may be operable to provide a service to a remote user, such as the UE 2106 connecting via an over-the-top (OTT) connection 2150 extending between the UE 2106 and host 2102. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection 2150.

[0383] The network node 2104 includes hardware enabling it to communicate with the host 2102 and UE 2106. The connection 2160 may be direct or pass through a core network (like core network 1606 of FIG. 16) and / or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network may be a backbone network or the Internet.

[0384] The UE 2106 includes hardware and software, which is stored in or accessible by UE 2106 and executable by the UE’s processing circuitry. The software includes a client application, such as a web browser or operator-specific “app” that may be operable to provide a service to a human or non-human user via UE 2106 with the support of the host 2102. In the host 2102, an executing host application may communicate with the executing client application via the OTT connection 2150 terminating at the UE 2106 and host 2102. In providing the service to the 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 2150 may transfer both the request data and the user data. The UE's client application may interact with the user to generate the user data that it provides to the host application through the OTT connection 2150.

[0385] The OTT connection 2150 may extend via a connection 2160 between the host 2102 and the network node 2104 and via a wireless connection 2170 between the network node 2104 and the UE 2106 to provide the connection between the host 2102 and the UE 2106. The connection 2160 and wireless connection 2170, over which the OTT connection 2150 may be provided, have been drawn abstractly to illustrate the communication between the host 2102 and the UE 2106 via the network node 2104, without explicit reference to any intermediary devices and the precise routing of messages via these devices.

[0386] As an example of transmitting data via the OTT connection 2150, in step 2108, the host 2102 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE2106. In other embodiments, the user data is associated with a UE 2106 that shares data with the host 2102 without explicit human interaction. In step 2110, the host 2102 initiates a transmission carrying the user data towards the UE 2106. The host 2102 may initiate the transmission responsive to a request transmitted by the UE 2106. The request may be caused by human interaction with the UE 2106 or by operation of the client application executing on the UE 2106. The transmission may pass via the network node 2104, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step 2112, the network node 2104 transmits to the UE 2106 the user data that was carried in the transmission that the host 2102 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 2114, the UE 2106 receives the user data carried in the transmission, which may be performed by a client application executed on the UE 2106 associated with the host application executed by the host 2102.

[0387] In some examples, the UE 2106 executes a client application which provides user data to the host 2102. The user data may be provided in reaction or response to the data received from the host 2102. Accordingly, in step 2116, the UE 2106 may provide user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via an input / output interface of the UE 2106. Regardless of the specific manner in which the user data was provided, the UE 2106 initiates, in step 2118, transmission of the user data towards the host 2102 via the network node 2104. In step 2120, in accordance with the teachings of the embodiments described throughout this disclosure, the network node 2104 receives user data from the UE 2106 and initiates transmission of the received user data towards the host 2102. In step 2122, the host 2102 receives the user data carried in the transmission initiated by the UE 2106.

[0388] One or more of the various embodiments improve the performance of OTT services provided to the UE 2106 using the OTT connection 2150, in which the wireless connection 2170 forms the last segment. More precisely, the teachings of these embodiments may enable the UE’s behavior with regards to autonomous release of QoE configurations to be predictable for the network. Uncertainties of the UE behavior and potentially varying behavior between UEs from different vendors can be eliminated. For instance, without the proposed procedures, it would be unclear to the network whether a UE that does not transmit any more QoE reports do so because there are no application sessions to measure on in the UE or because the UE has autonomously released the QoE configuration.

[0389] In an example scenario, factory status information may be collected and analyzed by the host 2102. As another example, the host 2102 may process audio and video data which mayhave been retrieved from a UE for use in creating maps. As another example, the host 2102 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, the host 2102 may store surveillance video uploaded by a UE. As another example, the host 2102 may store or control access to media content such as video, audio, VR or AR which it can broadcast, multicast or unicast to UEs. As other examples, the host 2102 may be used for energy pricing, remote control of non-time critical electrical load 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 collecting, retrieving, storing, analyzing and / or transmitting data.

[0390] In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 2150 between the host 2102 and UE 2106, in response to variations in the measurement results. The measurement procedure and / or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host 2102 and / or UE 2106. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection 2150 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 2150 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node 2104. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host 2102. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 2150 while monitoring propagation times, errors, etc.

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

[0392] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer- readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

Claims

CLAIMSWhat is claimed is:

1. A method of operating a communication device (1700) in a communications network, the communication device configured with a configuration that includes a quality of experience, QoE, configuration and / or a radio access network-visible QoE, RVQoE, configuration, the method comprising: determining (1240) a start time associated with the configuration; determining (1280) that an amount of time that has elapsed since the start time exceeds a threshold amount of time; and responsive to determining that the amount of time that has elapsed since the start time exceeds the threshold amount of time, releasing (1290) the configuration.

2. The method of Claim 1, wherein determining that the amount of time that has elapsed since the start time exceeds the threshold amount of time comprises: initiating a timer at the start time, the timer being set to the amount of time; and determining that the timer has expired.

3. The method of any of Claims 1-2, wherein determining the start time comprises determining the start time based on a time that the message was received by the communication device.

4. The method of any of Claims 1-3, further comprising: receiving (1210) a message from the network node including an indication of the configuration; responsive to receiving the message from the network node, transmitting (1220) a response to the network node, wherein determining the start time comprises determining the start time based on a time that the response was transmitted by the communication device.

5. The method of any of Claims 1-3, further comprising: receiving (1210) a message from the network node including an indication of the configuration and an indication of the start time,wherein determining the start time comprises determining the start time based on the indication of the start time.

6. The method of any of Claims 1-5, wherein the configuration comprises a new configuration, the method further comprising: receiving (1210) a message from the network node including instructions to cause the communication device to be reconfigured from an existing configuration to the new configuration, and wherein determining the start time associated with the new configuration comprises replacing an existing start time associated with the existing configuration with the start time associated with the new configuration,7. The method of Claim 6, wherein replacing the existing start time comprises: determining a difference between the existing configuration and the new configuration, the difference including at least one of: the existing configuration being associated with single connectivity and the new configuration being associated with multi-connectivity; the existing configuration being associated with a first multi-connectivity and the new configuration being associated with a second multi-connectivity; and the existing configuration being associated with multi-connectivity and the new configuration being associated with single connectivity; and responsive to determining the difference between the existing configuration and the new configuration, replacing the existing start time associated with the existing configuration with the start time associated with the new configuration.

8. The method of any of Claim 1-7, further comprising: subsequent to determining the start time and prior to determining the amount of time that has elapsed since the start time, performing (1250) an action comprising at least one of: transmitting a report based on the new configuration or the existing configuration; transmitting a session start indication associated with the new configuration; and transmitting a session end indication associated with the new configuration; and responsive to performing the action, resetting (1260) the start time.

9. The method of any of Claims 1-8, wherein determining the start time comprises determining the start time based on a time at which the communication device was released to a RRC IDLE state.

10. The method of any of Claims 1-9, wherein determining the start time comprises determining the start time based on at least one of: a time at which the communication device was released to a RRC INACTIVE state; a type of measurement associated with the configuration; a predetermined delay; a configured delay indicated by the network node; a time at which the communication device transmits a first report based on the configuration; a time at which the communication device transmits a first session start indication; a time at which the communication device transmits a first report based on the configuration at an end of a session; a time at which a period of time has elapsed without the configuration being used to transmit at least one of a report, a session start indication, or a session end indication; a radio resource control, RRC, state of the communication device; a time at which the communication device begins a first measurement session based on the configuration; a time at which the communication device ends the first measurement session based on the configuration; a time at which a period of time has elapsed without the communication device starting a measurement session based on the configuration; a time at which a period of time has elapsed without the communication device being able to transmit a report based on the configuration; and a time at which a buffer for storing reports associated with the configuration exceeds a threshold amount.

11. The method of any of Claims 1-10, wherein the configuration is a first configuration, the method further comprising: prior to determining that the amount of time that has elapsed since the start time exceeds the threshold amount of time, replacing (1270) the first configuration with a second configuration without adjusting the start time.

12. The method of any of Claims 1-11, wherein the threshold amount of time is at least one of: a predetermined amount of time; and a configured amount of time.

13. A method of operating a communication device (1700) in a communications network, the communication device configured with a configuration that includes a quality of experience, QoE, configuration and / or a radio access network-visible QoE, RVQoE, configuration, the method comprising: transmitting (1340) an indication to the network node of whether the communication device has released the configuration; and releasing (1350) the configuration.

14. The method of Claim 13, further comprising: receiving (1330) a message from the network node indicating a time at which to transmit the indication of whether the communication device has released the configuration, wherein transmitting the indication to the network node of whether the communication device has released the configuration comprises transmitting the indication to the network node of whether the communication device has released the configuration at the time.

15. The method of any of Claims 13-14, further comprising: receiving (1330) a request from the network node for the indication of whether the communication device has released the configuration, wherein transmitting the indication to the network node of whether the communication device has released the configuration comprises transmitting the indication to the network node of whether the communication device has released the configuration in response to the request.

16. A method of operating a network node (1800), in a communications network, the method comprising: determining (1430) a start time associated with a configuration of a communication device, the configuration including a quality of experience, QoE, configuration and / or a radio access network- visible QoE, RVQoE, configuration; determining (1470) that an amount of time that has elapsed since the start time exceeds a threshold amount of time; andresponsive to determining than the amount of time that has elapsed since the start time exceeds the threshold amount of time, determining (1480) that the communication device released the configuration.

17. The method of Claim 16, further comprising: transmitting (1410) a message to the communication device, the message including an indication of the configuration, wherein determining the start time comprises determining the start time based on a time that the message was transmitted to the communication device.

18. The method of Claim 17, further comprising: responsive to transmitting the message to the communication device, receiving (1420) a response from the communication device, wherein determining the start time comprises determining the start time based on a time that the response was received from the communication device.

19. The method of any of Claims 17-18, wherein the message includes an indication of the configuration and an indication of the start time.

20. The method of any of Claims 16-19, wherein the configuration comprises a new configuration, and wherein determining the start time associated with the new configuration comprises replacing an existing start time associated with the existing configuration with the start time associated with the new configuration.

21. The method of Claim 20, wherein replacing the existing start time comprises: determining a difference between the existing configuration and the new configuration, the difference including at least one of: the existing configuration being associated with single connectivity and the new configuration being associated with multi-connectivity; the existing configuration being associated with a first multi-connectivity and the new configuration being associated with a second multi-connectivity; and the existing configuration being associated with multi-connectivity and the new configuration being associated with single connectivity; andresponsive to determining the difference between the existing configuration and the new configuration, replacing the existing start time associated with the existing configuration with the start time associated with the new configuration.

22. The method of any of Claim 16-21, further comprising: subsequent to determining the start time and prior to determining the amount of time that has elapsed since the start time, performing (1440) an action comprising at least one of: receiving a report based on the new configuration or the existing configuration; receiving a session start indication associated with the new configuration; and receiving a session end indication associated with the new configuration; and responsive to performing the action, resetting (1450) the start time.

23. The method of any of Claims 16-22, wherein determining the start time comprises determining the start time based on a time at which the communication device was released to a RRC IDLE state.

24. The method of any of Claims 16-23, wherein determining the start time comprises determining the start time based on at least one of: a type of measurement associated with the configuration; a predetermined delay; a configured delay; a time at which the communication device was released to a RRC INACTIVE state; a time at which the network node receives a first report based on the configuration; a time at which the network node receives a first session start indication; a time at which the network node receives a first report based on the configuration at an end of a session; a time at which a period of time has elapsed without the network node receiving at least one of a report, a session start indication, or a session end indication based on the configuration; and a radio resource control, RRC, state of the communication device.

25. The method of any of Claims 16-24, wherein the configuration is a first configuration, the method further comprising: prior to determining that the amount of time that has elapsed since the start timeexceeds the threshold amount of time, replacing (1460) the first configuration with a second configuration without adjusting the start time.

26. The method of any of Claims 16-25, wherein the threshold amount of time is at least one of: a predetermined amount of time; and a configured amount of time.

27. A method of operating a network node (1800), in a communications network, the method comprising: configuring (1520) a communication device with a configuration that includes a quality of experience, QoE, configuration and / or a radio access network-visible QoE, RVQoE, configuration; receiving (1540) an indication from the communication device of whether the communication device has released the configuration; and determining (1560) whether the communication device has released the configuration based on the indication from the communication device.

28. The method of Claim 27, further comprising: transmitting (1510) a message to the communication device, the message including an indication of the configuration.

29. The method of any of Claims 27-28, further comprising: transmitting (1530) a message to the communication device indicating a time at which to transmit the indication of whether the communication device has released the configuration, wherein receiving the indication from the communication device of whether the communication device has released the configuration comprises receiving the indication from the communication device of whether the communication device has released the configuration at the time.

30. The method of any of Claims 27-29, further comprising: transmitting (1530) a request to the communication device for the indication of whether the communication device has released the configuration, wherein receiving the indication from the communication device of whether thecommunication device has released the configuration comprises receiving the indication from the communication device of whether the communication device has released the configuration in response to the request.

31. The method of any of Claims 27-30, wherein the network node is a first network node, the method further comprising: transmitting (1550) the start time to a second network node.

32. A communication device (1700), configured to perform any of the operations of Claims 1- 15.

33. A computer program comprising program code to be executed by processing circuitry (1702) of a communication device (1700), whereby execution of the program code causes the communication device to perform any of the operations of Claims 1-15.

34. A computer program product comprising a non-transitory storage medium (1710) including program code to be executed by processing circuitry (1702) of a communication device (1700), whereby execution of the program code causes the communication device to perform any of the operations of Claims 1-15.

35. A network node (1800) configured to perform any of the operations of Claims 16-31.

36. A computer program comprising program code to be executed by processing circuitry (1802) of a network node (1800), whereby execution of the program code causes the network node to perform any of the operations of Claims 16-31.

37. A computer program product comprising a non-transitory storage medium (1806) including program code to be executed by processing circuitry (1802) of a network node (1800), whereby execution of the program code causes the network node to perform any of the operations of Claims 16-31.

Images