EP4674176A1 - Methods and apparatuses for releasing or suspending one or more quality of experience configurations at handover between radio access technologies - Google Patents

Methods and apparatuses for releasing or suspending one or more quality of experience configurations at handover between radio access technologies

Info

Publication number
EP4674176A1
EP4674176A1 EP24709538.3A EP24709538A EP4674176A1 EP 4674176 A1 EP4674176 A1 EP 4674176A1 EP 24709538 A EP24709538 A EP 24709538A EP 4674176 A1 EP4674176 A1 EP 4674176A1
Authority
EP
European Patent Office
Prior art keywords
qoe
configuration
rat
configurations
indication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP24709538.3A
Other languages
German (de)
French (fr)
Inventor
Cecilia EKLÖF
Johan Rune
Filip BARAC
Luca LUNARDI
Ali PARICHEHREHTEROUJENI
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of EP4674176A1 publication Critical patent/EP4674176A1/en
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/14—Reselecting a network or an air interface
    • H04W36/144—Reselecting a network or an air interface over a different radio air interface technology
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/08—Testing, supervising or monitoring using real traffic

Definitions

  • Embodiments described herein relate to methods and apparatuses for releasing or suspending at least one first QoE configuration at handover between a first radio access technology (RAT) and a second RAT.
  • RAT radio access technology
  • QoE measurements also referred to as “application layer measurements”
  • LTE Long Term Evolution
  • UMTS Universal Mobile Telecommunications Service
  • 3GPP 3 rd Generation Partnership Project
  • the purpose of the application layer measurements is to measure the end user experience when using certain applications.
  • QoE measurements for streaming services and for MTSI Mobility Telephony Service for IMS
  • MTSI Mobility Telephony Service for IMS
  • VR virtual reality
  • QMC Quality of Experience Measurement Collection
  • RRC Radio Resource Control
  • An application layer measurement configuration also called QoE measurement configuration or QoE configuration
  • RAN Radio Access Network
  • OAM Operations Administration and Management
  • CN Core Network
  • An application layer measurement report (also called QoE report) that the UE Access Stratum (UE 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).
  • MCE Measurement Collector Entity
  • 3 GPP release 17 a new study item for “Study on NR QoE management and optimizations for diverse services” for NR has been approved and concluded.
  • the specification work for 3GPP release 17 is still ongoing.
  • the purpose of the study item is to study solutions for QoE measurements in NR.
  • QoE management in NR will not just collect the quality of experience parameters of streaming services but also consider the typical performance requirements of diverse services (e.g., Augmented Reality (AR)/VR and Ultra-reliable low latency communications (URLLC), of which at least VR seems to be covered in 3 GPP release 17).
  • the NR study also included more adaptive QoE management schemes that enable network optimization to satisfy user experience for diverse services.
  • the configuration data related to QoE measurements comprises of a service type indication, an indication of an area in which the measurements are to be performed (denoted area scope), an Internet Protocol (IP) address of the entity the collected measurement results (i.e. 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.
  • IP Internet Protocol
  • An area scope is defined in terms of cells or network related areas.
  • an area scope is defined as either a list of cells, a list of routing areas or a list of tracking areas.
  • an area scope is defined as either a list of cells or a list of tracking areas.
  • an area scope will be defined as either a list of cells or a list of tracking areas.
  • QoE and in particular QoE configuration, comes in two flavors: management-based (m- based) QoE configuration and signaling-based (s-based) QoE configuration.
  • the QoE configuration originates in the OAM system or some other administrational entity, e.g., dealing with customer satisfaction. All these entities are in this document referred to as the OAM system (where the OAM system also contains further entities).
  • management-based QoE m-based QoE
  • the m-based QoE configuration is sent directly from the OAM 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 fulfills any other relevant condition, such as supporting the concerned application/service type) and sends the m-based QoE configuration to these UEs.
  • the OAM 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 OAM system sends the s-based QoE configuration to the Homes Subscriber Server (HSS) (in EPS/LTE) or Unified Data Management (UDM) (in 5GS/NR), which forwards the QoE configuration to the UE’s current core network node (CN), e.g., an Mobile Management Entity (MME) in EPS/LTE or an Access and Mobility Management Function (AMF) in 5G/NR.
  • HSS Homes Subscriber Server
  • UDM Unified Data Management
  • CN current core network node
  • MME Mobile Management Entity
  • AMF Access and Mobility Management Function
  • [8] 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.
  • the QoE framework is integrated with the Trace functionality and a Trace ID is associated with each QoE configuration.
  • the QoE functionality will be logically separated from the Trace functionality, but it will still partly reuse the Trace signaling mechanisms.
  • a globally unique QoE reference formed of Mobile Country Code (MCC) + Mobile Network Code (MNC) + QoE Measurement Collection (QMC) identifier (ID), where the QMC ID is a string of 24 bits
  • MCC Mobile Country Code
  • MNC Mobile Network Code
  • QMC QoE Measurement Collection
  • ID QoE Measurement Collection
  • the QoE reference is included in the container with measurement instructions and sent to the RAN (i.e., the gNB in NR).
  • the QoE reference is replaced by a shorter identifier denoted as measConfigAppLayerld, which is locally unique within a UE (i.e., 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 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.
  • AT Command which is the type of instructions used in the communication between the UE’s modem part and the UE’s application layer
  • 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.
  • 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.
  • the RAN can instruct the UE to pause QoE reporting, e.g., in case the cell/gNB is in a state of overload.
  • 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.
  • RVQoE RAN visible QoE
  • the RVQoE metrics are derived from the regular QoE metrics, collected and compiled in reports by the UE application layer and delivered to the RAN, so that the RAN may use the reports for various types of optimizations.
  • the RAN can perform adaptive actions to impact the QoE of the concerned application session while the application session is ongoing, such as change various parameters related to the scheduling of the UE and the data flows related to the application session.
  • 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.
  • QoE measurements for streaming services and for MTSI (Mobility Telephony Service for IMS) services are supported.
  • 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.
  • 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.
  • the measurement When initiated via the core network, the measurement is started towards a specific UE.
  • the "TRACE START" SI AP 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.
  • 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.
  • Figure 1 is a signaling diagram illustrating the basic signaling (without showing all details) involved in QoE measurement configuration, from the O&M system to the UE.
  • the diagram is a copy of a diagram in 3GPP TS 28.405 vl6.0.0 labeled “ Figure 4.2.1-1 : QMC activation and reporting in LTE”.
  • 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.
  • Figure 2 illustrates configuration and reporting of QoE measurements using RRC signaling.
  • Attention (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.
  • the AT commands are used in QoE for transferring the configuration from the RRC layer to the application and for transferring reports from the application layer to the RRC layer.
  • the UE can only be configured with one QoE measurement at a time.
  • the UE is configured with the QoE configuration container and the service type for the measurement. See example code below:
  • the UE can be configured with up to 16 QoE measurements.
  • the measurements are separated by an identity, the measConfigAppLayerld, and they are configured by means of an AddModList. See example code below:
  • ran-VisiblePeriodicity-r!7 ENUMERATED ⁇ ms!20, ms240, ms480, ms640, ms 1024 ⁇ OPTIONAL, - Need S [47] numberOfBufferLevelEntries-rl7 INTEGER (1-8)
  • the RRC message MobilityFromNRCommand is sent to the UE.
  • the message comprises an LTE message, an RRCConnectionReconfiguration containing mobilityControlInfo in the form of an octet string. See below:
  • the MobilityFromNRCommand message is used to command handover from NR to E- UTRA/EPC, E-UTRA/5GC or UTRA-FDD.
  • MobilityFromNRCommand : : SEQ UENCE ⁇ rrc- Transactionidentifier RRC- Transactionidentifier, criticalExtensions CHOICE ⁇ mobilityFromNRCommand MobilityFromNRCommand-IEs, criticalExtensionsFuture SEQUENCE ⁇
  • MobilityFromNRCommand-IEs SEQUENCE ⁇ targetRAT-Type ENUMERATED targetRA T-MessageContainer OCTET STRING, nas-SecurityParamFromNR OCTET STRING
  • MobilityFromNRCommand-vl610-IEs :: SEQUENCE ⁇ voiceFallbacklndication-r 16 ENUMERATED ⁇ true ⁇
  • OPTIONAL NeedN nonCriticalExtension SEQUENCE ⁇ OPTIONAL
  • a UE When a UE performs a handover (reconfigurationWithSync) from one NR cell to another NR cell, there are two possibilities for how the target configuration is signaled to the UE.
  • the network In case of delta signaling, the network only indicates differences in the AS configuration between the source cell and the target cell in the Handover Command message (an RRCReconfiguration message comprising reconfigurationWithSync) triggering the handover.
  • the UE In case of handover with fullConfig, the UE releases the existing configuration in the UE AS layer and adds a new, complete AS configuration included in the Handover Command. Reconfiguration with fullConfig can also occur at RRC re-establishment.
  • the LTE message RRCConnectionReconfiguration comprising mobility Controlinfo may contain a fullConfig of the LTE configuration.
  • QoE measurements consist of both a UE AS layer part and an application layer part.
  • the UE releases the AS layer part, but keeps the application layer part as the application layer part is not a radio configuration.
  • reconfigurations with fullConfig were discussed and it was agreed that the network signals the QoE configurations to be kept and the QoE configurations to be released by signaling the measConfigAppLayerld of the configurations respectively, either in the AddModList or in the Release list. If the QoE configuration should be continue, the UE will the receive the AS part of the configuration again, which was cleared as part of the fullConfig, and the application layer part will still be remain.
  • the network can indicate release of configurations to the UE and the UE AS will indicate to the application layer that a QoE configuration should be released. If no QoE measurement is indicated in the RRCReconfiguration message compri sing fullConfig, all QoE measurements will be released. That is applicable for the case that the target node doesn’t support QoE measurements and is not able to signal anything related to QoE.
  • the QoE configuration container is mandatory in the RRCConnectionReconfiguration message, and it is not possible to exclude it. Therefore, a solution was agreed where the UE AS layer doesn’t forward the container to the application layer if the measurements should continue at the handover with fullConfig. If the target node doesn’t support QoE measurements, nothing will be indicated in the message and the UE will release the QoE measurements. From 3GPP TS 36.331 vl7.3.0:
  • a UE executes a handover from NR to LTE and measurements for one service type continue in the LTE node, possibly other QoE configurations which the UE was configured with in NR may still remain "hanging” in the UE and the target node does not have the possibility to release them. Also, other NR specific QoE functionality, e.g. RAN visible QoE, or alignment with MDT, is not possible to release from LTE and may be hanging in the UE at handover from NR to LTE.
  • RAN visible QoE or alignment with MDT
  • Some embodiments described herein provide a method in a UE, the method comprising:
  • Obtaining one or more configurations of QoE measurements in NR (a first Radio Access Technology (RAT)).
  • RAT Radio Access Technology
  • the message may be a MobilityFromNRCommand'RKC message, comprising an LTE message RRCConnectionReconfiguration comprising mobilityControlInfo, where the RRCConnectionReconfiguration message is created by the target node, sent to the source node (a gNB) during the IRAT handover preparation phase as a transparent container (i.e. the source gNB is not expected to read or understand it) and then included by the source node in the MobilityFromNRCommand message in the form of an OCTET STRING contained in the targetRAT-MessageContainer IE.
  • a gNB the source node
  • OCTET STRING contained in the targetRAT-MessageContainer IE.
  • the MobilityFromNRCommand is updated to contain the I ⁇ AppLayerMeasConfig, so that NR-specific parts of QoE configurations may be released, o
  • “NR-specific parts of QoE configurations that are to be released” refers to the QoE measurement configurations for the service types for which the QoE measurements are supported in NR, but not supported in LTE (e.g., VR).
  • “NR-specific parts of QoE configurations that are to be released” includes features of QoE measurement configurations for service types for which QoE measurements are supported in both LTE and NR, but the features that are a part of the QoE measurement configuration are supported in NR, and not in LTE.
  • QoE measurements for MTSI and DASH are supported in both LTE and NR, but features such as RAN visible QoE, alignment with MDT are supported in NR, but not supported in LTE.
  • the RRCConnectionReconfiguration message (also referred to as the Handover Command below) contained in the targetRAT-MessageContainer IE contains the configuration of QoE measurements, i.e. a service type and a QoE configuration container: o Releasing other QoE configurations configured in NR, i.e. releasing QoE configurations of different service types than received in the QoE configuration in the Handover Command. o Releasing other QoE configurations comprises releasing everything related to the QoE configurations, e.g.
  • the “NR part of the configuration” refers to features inside a QoE measurement configuration for a service type that is supported in both LTE and NR, but where the feature itself is supported in NR, and not in LTE.
  • QoE measurements i.e. a service type and a QoE configuration container: o Releasing all QoE configurations.
  • QoE configuration container o Releasing all QoE configurations.
  • the embodiments described herein relate to how avoid hanging QoE measurements in the UE at handover from a first RAT (e.g. NR) to a second RAT (e.g. LTE).
  • a first RAT e.g. NR
  • a second RAT e.g. LTE
  • a method performed by a user equipment, UE The UE is in communication with a first radio access technology, RAT.
  • the method comprising obtaining one or more quality of experience, QoE, configurations for use with the first RAT; receiving, from a source node of the first RAT, a message indicating that the UE is to communicate with a second RAT; commencing communication with a target node of the second RAT; and releasing or suspending at least one first QoE configuration of the one or more QoE configurations.
  • QoE quality of experience
  • a method performed by a network node in a first radio access technology comprising transmitting a message indicating that the UE is to communicate with a second RAT, wherein the message comprises a first indication relating to the release or suspension of at least one first QoE configuration of the one or more QoE configurations when commencing communication with the second RAT.
  • a user equipment wherein the UE is adapted to communicate with a first radio access technology, RAT.
  • the UE comprises processing circuitry and memory, the memory containing instructions executable by the processing circuitry whereby the UE is operable to: obtain one or more quality of experience, QoE, configurations for use with the first RAT; receive, from a source node of the first RAT, a message indicating that the UE is to communicate with a second RAT; commence communication with a target node of the second RAT; and release or suspend at least one first QoE configuration of the one or more QoE configurations.
  • QoE quality of experience
  • a network node in a first radio access technology is adapted to communicate with user equipment, UE, configured with one or more one or more quality of experience, QoE, configurations for use with the first RAT.
  • the network node comprises processing circuitry and memory, the memory containing instructions executable by the processing circuitry whereby the network node is operable to: transmit a message indicating that the UE is to communicate with a second RAT, wherein the message comprises a first indication relating to the release or suspension of at least one first QoE configuration of the one or more QoE configurations when commencing communication with the second RAT.
  • a computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out any of the methods described above.
  • a carrier containing the computer program as described above, wherein the carrier comprises one of an electronic signal, optical signal, radio signal or computer readable storage medium.
  • a computer-readable medium comprising instructions that, when executed on at least one processor, cause the at least one processor to perform any of the methods described above.
  • a computer program product comprising non transitory computer readable media having stored thereon a computer program as described above.
  • Certain embodiments may provide one or more of the following technical advantage(s).
  • An advantage of the embodiments described herein is that the avoidance of QoE measurements hanging in the UE at IRAT handover from a first RAT (e.g. NR) to a second RAT (e.g. LTE). Release of unnecessary measurements, i.e. measurements which can anyhow not be reported to the network, is important in order to avoid wasting the UE capacity and to prolong the battery lifetime of the UE.
  • a first RAT e.g. NR
  • a second RAT e.g. LTE
  • the use of the QoE configurations configured in the UE for NR can be temporarily paused whilst the UE is communicating with LTE and resumed when the UE returns to NR, thus removing the need to re-send the QoE configurations to the UE again.
  • the first RAT e.g. NR
  • Fig. 1 is a signaling diagram providing an overview of the signaling involved in QoE measurement configuration, from the O&M system to the UE;
  • FIG. 2 illustrates configuration and reporting of QoE measurements using RRC signaling
  • Fig. 3 is a flow chart illustrating a method in accordance with some embodiments
  • FIG. 4 is a flow chart illustrating a method in accordance with some embodiments.
  • FIG. 5 shows an example of a communication system in accordance with some embodiments
  • FIG. 6 shows a UE in accordance with some embodiments
  • FIG. 7 shows a network node in accordance with some embodiments
  • FIG. 8 is a block diagram of a host
  • FIG. 9 is a block diagram illustrating a virtualization environment in which functions implemented by some embodiments may be virtualized.
  • Fig. 10 shows a communication diagram of a host communicating via a network node with a UE over a partially wireless connection in accordance with some embodiments.
  • the application layer in the UE may also be referred to as the “UE application layer” or simply the “application layer”.
  • QoE configuration QoE parameters
  • QoE information QoE configuration information
  • QoE configuration information QoE configuration information
  • the entity performing the QoE measurements and other actions related to a QoE configuration 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.
  • the performer of these various actions is sometimes said to be the application layer and sometimes said to be the application.
  • service is often used as a short notation for “service type”, therefore “service” and “service types” can be seen as interchangeably unless explicitly stated.
  • an instruction on whether the UE should send session start/stop indications provides 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”.
  • 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”.
  • 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).
  • 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).
  • Some embodiments comprise a method for a UE where the UE is configured with QoE measurements in NR and an IRAT handover to LTE is triggered.
  • the UE can only be configured with one QoE measurement at a time, and the invention describes methods to release other QoE measurements in the UE and also to release other QoE functionality in the UE which do not exist in LTE.
  • An LTE target node i.e. an eNB that controls the target cell of a handover
  • Figure 3 is a flowchart illustrating a method in accordance with some embodiments.
  • Figure 3 depicts a method in accordance with particular embodiments.
  • the method of Figure 3 may be performed by a UE or wireless device (e.g. the UE 512 or UE 600 as described later with reference to Figures 5 and 6 respectively).
  • the UE may be in communication with a first radio access technology (RAT).
  • the method begins at step 302 with obtaining one or more quality of experience, QoE, configurations for use with the first RAT.
  • the UE may be configured by the first RAT with the one or more QoE configurations for use with the first RAT.
  • step 304 the method comprises receiving, from a source node of the first RAT, a message indicating that the UE is to communicate with a second RAT.
  • the message may comprise a handover command or a RRC release with re-direct to a second RAT message.
  • the message may comprise a first indication relating to the release or suspension of at least one first QoE configuration of the one or more QoE configurations when commencing communication with the second RAT.
  • the first indication may comprise an identification of the at least one first QoE configuration. It will be appreciated that the at least one first QoE configuration may comprise all but one of the one or more QoE configurations.
  • the first indication may comprise an identification, in the handover command, of a second QoE configuration associated with a first service type, wherein the first indication indicates that the at least one first configuration comprises any QoE configuration in the one or more QoE configurations not associated with the first service type.
  • the first indication may comprise an instruction to the UE to select which of the one or more QoE configurations to release or suspend.
  • the first indication may comprise one or more of: an indication that UE should suspend or release the at least one first QoE configuration currently stored at the UE; an indication of one or more service types for which the at least one first QoE configuration should be suspended or released; indication of a maximum (or a minimum) number of at least one first QoE configurations the U E should suspend or release; a time for which the at least one first QoE configuration are to be suspended.
  • step 306 the method comprises commencing communication with a target node of the second RAT.
  • step 308 the method comprises releasing or suspending at least one first QoE configuration of the one or more QoE configurations.
  • step 306 may be performed according to the first indication. It will be appreciated that suspending the at least one first QoE configuration comprises refraining from reporting measurements according to the at least one first QoE configuration when in communication with the second RAT.
  • Figure 4 is a flowchart illustrating a method in accordance with some embodiments.
  • Figure 4 depicts a method in accordance with particular embodiments.
  • the method of Figure 4 may be performed by a network node (e.g. the network node 510 or network node 700 as described later with reference to Figures 5 and 7 respectively).
  • the network node may be in a first RAT.
  • the network node may be in communication with user equipment, UE, configured with one or more one or more quality of experience, QoE, configurations for use with the first RAT.
  • the method begins at step 402 with transmitting a message indicating that the UE is to communicate with a second RAT, wherein the message comprises a first indication relating to the release or suspension of at least one first QoE configuration of the one or more QoE configurations when commencing communication with the second RAT.
  • Step 402 corresponds to some examples of step 304 of Figure 3.
  • the first indication may be defined similarly to as described with reference to some examples of step 304.
  • the UE may receive configuration of one or more QoE measurements in NR (a first RAT) (e.g. as described with reference to step 302).
  • the UE may then receive a message containing a command for handover from NR (first RAT) to LTE (second RAT) (which is an example implementation of step 304).
  • the message may be a MobilityFromNRCommand RRC message, comprising an LTE message RRCConnectionReconfiguration comprising mobilityControlInfo, where the RRCConnectionReconfiguration message is created by the target node, sent to the source node (a gNB) during the IRAT handover preparation phase as a transparent container (i.e. the source gNB is not expected to read or understand it) and then included by the source node in the MobilityFromNRCommand message in the form of an OCTET STRING contained in the targetRAT-MessageContainer IE.
  • the message (e.g. MobilityFromNRCommand) is updated to comprise an information element (e.g. the IE AppLayerMeasConfig) comprising an identification of the at least one first QoE.
  • the information element may therefore comprise an example of the first indication of step 304. This information element may then ensure thatNR- specific parts of the one or more QoE configurations may be released or suspended.
  • NR-specific parts of QoE configurations that are to be released refers to the QoE configurations for service types for which QoE measurements are supported in NR, but not supported in LTE (e.g., VR).
  • NR-specific parts of QoE configurations that are to be released includes features of QoE measurement configurations for service types for which QoE measurements are supported in both LTE and NR, but the features that are a part of the QoE measurement configuration are supported in NR, and not in LTE.
  • the method of Figure 3 may further comprise releasing or suspending one or more features of the one or more QoE configurations not supported by the second RAT. a.
  • QoE measurements for MTSI and DASH are supported in both LTE and NR, but features such as RAN visible QoE, alignment with MDT are supported in NR, but not supported in LTE.
  • the AppLayerMeasConfig IE contains a measConfigAppLayerToReleaseList IE including the MeasConfigAppLayerldtfi) associated with at least one first QoE configurations to be released or suspended.
  • the source node uses a MeasConfigAppLayer IE in the measConfigAppLayerToAddModList IE in the AppLayerMeasConfig IE to release the RAN Visible QoE configuration associated with a QoE configuration without releasing the entire QoE configuration.
  • the method of Figure 3 may comprise releasing or suspending a radio access network visible QoE configuration without releasing or suspending the entire associated QoE configuration.
  • a nonCriticalExtension field in the MobilityFromNRCommand message is used to extend the MobilityFromNRCommand message (as defined in 3GPP TS 38.331 version 17.3.0) with the AppLayerMeasConfig IE.
  • the AppLayerMeasConfig IE is not included in the MobilityFromNRCommand message, but instead other new IE(s) are added to the message (e.g. utilizing the nonCriticalExtension field) to indicate the required release, modification or suspension of the at least one first QoE configuration, and/or deletion of QoE related parameters in the one or more QoE configurations that are not applicable in the second RAT (i.e. LTE in this scenario).
  • the AppLayerMeasConfig IE is included in the MobilityFromNRCommand message, and it is complemented by one or more additional IE(s) which may serve to indicate complemental modifications or deletions of QoE related parameters in the one or more QoE configurations that are not applicable in the target RAT (i.e. LTE in this scenario).
  • the nonCriticalExtension field in the MobilityFromNRCommand message may be utilized to include both the AppLayerMeasConfig IE and the additional complementing IE(s) in the MobilityFromNRCommand message.
  • the UE NR QoE configurations are not released immediately, but the inner RRCConnectionReconfiguration (i.e. the RRCConnectionReconfiguration in the targetRAT-MessageContainer IE) is decoded before the at least one first QoE configuration or features of the one or more QoE configuration are released/suspended.
  • the method of Figure 3 further comprises decoding the handover command before releasing or suspending the first QoE configuration.
  • the RRCConnectionReconfiguration in the targetRAT- MessageContainer IE comprises a second QoE configuration of QoE measurements for a first service type
  • the UE keeps a QoE configuration from the one or more QoE configurations for that first service type and releases or suspends the other QoE configurations of the one or more QoE configurations.
  • the RRCConnectionReconfiguration message (also referred to as the Handover Command below) contained in the targetRAT-MessageContainer IE comprises a second QoE configuration of QoE measurements, i.e. a first service type and a QoE configuration container.
  • This second QoE configuration may comprise the first indication of step 304.
  • the second QoE configuration may indicate to the UE to release or suspend any other QoE configurations of the one or more QoE configurations configured in NR, e.g. to release or suspend QoE configurations of different service types than the first service type indicated in the Handover Command.
  • releasing a QoE configuration may comprise releasing everything related to the QoE configuration, e.g. release of measConfigAppLayerld for the configurations, release of the service types, release of QoE reference etc.
  • releasing a QoE configuration may comprise releasing the NR- specific parts of the QoE configuration when communicating in LTE.
  • the “NR part of the configuration” refers to features inside a QoE configuration for a service type that is supported in both LTE and NR, but where the feature itself is supported in NR, and not in LTE. This sort of release may comprise releasing one or more of the following features:
  • the QoE configuration is released if it is restricted to one or more network slice(s) (as indicated by S-NSSAI(s)).
  • the QoE configuration is kept, but the slice scope (i.e. the list of network slices indicated by a list of S-NSSAI(s) in the QoE configuration at the application layer) is released/deleted or associated with an indication that it should be ignored.
  • slice scope i.e. the list of network slices indicated by a list of S-NSSAI(s) in the QoE configuration at the application layer
  • the UE determines whether it can keep or not in LTE a certain NR specific QoE configuration based on its support in LTE for QoE measurement collection for the service type which the NR specific QoE configuration refers to.
  • the method of figure 3 may then further comprise continuing performing QoE measurements when in communication with the second RAT.
  • the QoE measurements may be performed according to any QoE configuration that has not been released or suspended, possibly without the NR-specific features. It will be appreciated that after releasing or suspending the at least one first QoE configuration the UE may be left with a second QoE configuration (from the one or more QoE configurations) that can be used to perform and report QoE measurements in the second RAT.
  • the second QoE configuration may have been modified to remove features that are not supported in the second RAT.
  • the method of Figure 3 may further comprise performing measurements according to the at least one first QoE configuration whilst communicating with the second RAT, and reporting the measurements to the first RAT upon returning to communication with the first RAT.
  • the RRCConnectionReconfiguration message does not contain the configuration of QoE measurements, i.e. a service type and a QoE configuration container: the method of Figure 3 may comprise releasing or suspending all of the one or more QoE configurations.
  • first indication of the message of step 304 may contain an indication that instructs the UE to choose itself which QoE measurement configuration to keep, among all its current one or more QoE configurations of any service type.
  • This first indication may be explicit or implicit.
  • An example of an implicit first indication may be that no instruction for release or suspension has been issued to the UE.
  • the UE may choose the (one) QoE measurement configuration to keep.
  • the first indication of step 304 may comprise an indication to select a second QoE configuration to keep from the one or more QoE configurations. Implicitly, in this scenario, the other of the one or more QoE configurations may be set as the at least one first QoE configuration and may therefore be suspended or released.
  • the UE may decide: o To keep the second QoE measurement configuration that pertains to a certain service type. o To keep the second QoE measurement configuration that pertains to the application session whose DRB have the highest QoS requirements, among the configurations that LTE can support o To keep the second QoE measurement configuration that pertains to the application session using the highest priority slice o To keep the second QoE measurement configuration that pertains to the application session that is active or is being the most active, among all the measured sessions. o To keep the second QoE measurement configuration that is signalling-based or that is management-based. o To keep the second QoE configuration for which the application session is ongoing. o To keep the second QoE configuration with the longest or shortest reporting periodicity, o To keep the second QoE configuration for a service type for which measurements are supported in both NR and LTE, but that has the smallest number of NR-specific features configured.
  • the network may select one of them to continue in LTE. If no explicit release of QoE measurements is signaled to the UE, the UE may determine which QoE configuration should be maintained for use in LTE. o In one alternative, the UE chooses the QoE configuration to retain by itself. In another alternative, the network indicates to the UE which service to prioritize, and the UE chooses which exact QoE configuration to keep. o Each QoE configuration may contain a priority indication and the UE keeps the one with the highest indicated priority. If more than one QoE configuration has the highest indicated priority, the choice of which of them to keep may be left to the UE.
  • the UE may take into account whether a QoE measurement session is ongoing for a QoE configuration, e.g. by giving such a QoE configuration higher priority, and/or using this as a selection criterion when choosing one QoE configuration to keep out of multiple QoE configurations with the highest indicated priority.
  • the UE may determine the QoE configuration to keep in LTE by: o Checking the QoE reference inside the QoE configuration file transmitted in LTE and comparing the QoE reference by the reference in NR. The QoE configuration with the same QoE reference in NR and in LTE should be kept in LTE. The check may be done in the UE application layer or in the UE AS layer. If the UE AS layer performs the check, the application may send the QoE reference to the UE AS layer, possibly upon request from the UE AS layer, o By using one or more criteria described above for the case where the UE chooses by itself which configuration to keep, among all available configurations of any service type.
  • the instruction to select a second QoE configuration may be combined with an indication of the at least one first QoE configuration.
  • the message may identify a first subset of QoE configrations from the one or more QoE configurations that the UE should release or suspend. However, this may leave a plurality of QoE configurations in the one or more QoE configurations that the UE can then select a second QoE configuration to keep from.
  • the UE is provided by the network (e.g., as part of the RRCConnectionReconfiguration message) an indication to retain and suspend all NR related QoE/RVQoE configuration(s) it has received in NR (e.g. the one or more QoE configuration), and not use any of them, or an indication to retain and suspend all the NR related QoE/RVQoE configuration it has received in NR, and use only a second QoE configuration that results from applying any of the criteria/embodiments of the invention.
  • NR e.g. the one or more QoE configuration
  • the UE may also receive the indication of a retention period (e.g., 24 hours) which indicate for how long the UE should keep the NR related QoE/RVQoE information when the UE is not camped on or connected to a cell in NR.
  • the retention period may not be explicitly communicated to the UE, but it is a fixed period indicated in the specification (e.g. 24 hours or 48 hours).
  • the message of step 304 comprises an RRC release with re-direct to the second RAT.
  • the UE is configured for QoE/RVQoE measurements, it the message from the NR RAT (i.e., from a gNB) indicating to release the existing NR connection and re-establish a new connection in the other RAT (e.g. in LTE), for example, when the coverage area of the NR RAT is reached and the gNB opted to not initiate a handover procedure to LTE, and determined instead to release the UE, indicating in an RRC Release message that UE should move to an E-UTRA carrier.
  • the NR RAT i.e., from a gNB
  • the gNB may include, as part of the RRCRelease message (e.g. the message of step 304), instructions on how the UE should treat the QoE/RVQoE configurations.
  • the above instructions can comprise the first indication related to the release or suspension of NR related QoE and/or RVQoE configuration (e.g., in a “suspend QMC configuration” IE, or a “suspend NR QMC” IE, or alike) providing: indication that UE should retain and suspend the QoE configuration currently stored at the UE (and/or the RVQoE configuration stored at the UE), indication of which QoE/RVQoE configurations the UE should retain and suspend, indications of service types for which the QoE/RVQoE configuration should be retained and suspended, indication of a maximum (or a minimum) number of QoE/RVQoE configuration the UE should retain and suspend a time related information, indicating for how long the QoE/RVQoE configurations should be retained and suspended (this may also be omitted, and a fixed period is instead indicated in the specification (e.g. 24 hours or 48 hours)).
  • a “suspend QMC configuration” IE
  • the instructions the UE can receive can comprise a first indication related to the release of NR related QoE and/or RVQoE configuration (e.g., in a “release QMC configuration” IE, or a “release NR QMC” IE, or alike) providing indication to release one or more QoE/RVQoE configurations according to criteria detailed in other embodiments described herein. For example: indication that UE should release all the QoE configuration currently stored at the UE (and/or the RVQoE configuration stored at the UE), indication of which QoE/RVQoE configurations the UE should release, indications of service types for which the QoE/RVQoE configuration should be released,
  • the UE may autonomously determine to retain (and/or suspend) all the NR related QoE/RVQoE configuration that are not explicitly or implicitly released by the network.
  • RRCRelease-vl800-IEs SEQUENCE ⁇ measConfigAppLayerToSuspendList-rl8 SEQUENCE (SIZE (L.maxNrofAppLayerMeas- r!7)) OF MeasConfigAppLayerId-rl7, suspend-ran- Visible-QoE-Streaming-MeasReport ENUMERA TED ⁇ supported ⁇
  • RRCRelease-vl800-IEs SEQUENCE ⁇ measConfigAppLayerToReleaseList-rl7 SEQUENCE (SIZE (L.maxNrofAppLayerMeas- r!7)) OF MeasConfigAppLayerId-rl7, suspend-ran- Visible-QoE-Streaming-MeasReport ENUMERA TED ⁇ supported ⁇
  • the UE may receive indications from the target NR node that the use of any or all or only certain suspended (or retained) QoE configuration can be resumed.
  • the MobilityFromEUTRANCommand can be used to convey, as part of the targetRAT -MessageContainer (encoded as OCTET STRING and corresponding to an RRCReconfiguration message in case of targetRAT-Type equals to “nr”), indications related to the resume of NR related QoE/RVQoE configuration previously kept (retained) at the UE.
  • Handover :: SEQUENCE ⁇ targetRA T-Type ENUMERATED ⁇ utra, geran, cdma2000-
  • the field contains a message specified in another standard, as indicated by the targetRAT- Type, and carries information about the target cell identifier(s) and radio parameters and application layer measurement parameters relevant for the target radio access technology.
  • the gNB uses the UE capabilities information and the service types associated to the NR-related QoE configuration, to inform the target eNB of the service type or service types for which the UE is currently configured to perform QoE measurements on in NR.
  • the gNB can indicate to the eNB a preference in terms of which service type, or which QoE reference, or which pair of QoE reference and service type the gNB would like the UE to continue QoE measurements on.
  • the eNB can indicate to the source gNB (in alternative or in addition to the information provided to the UE in mobilityControlInfo IE): which QoE configuration is accepted by the eNB to continue operating in LTE (e.g. indicating the QoE reference, or the service type, or a pair of QoE reference and service type) which QoE configuration is not accepted (rejected) and are going to be released upon transition to LTE whether other QoE configurations not accepted can be suspended (retained at the LTE) while the LTE is in LTE a cause value to indicate the reason for not accepting a certain QoE configuration (e.g. QoE measurements for the service type are not supported) that all QoE configuration of the UE are released
  • the UE upon handover from NR to the LTE (or any other radio access technologies that do not support QoE measurements reporting for the NR services), the UE: Pause s/suspends reporting the QoE measurements received from the upper layers and stores the received QoE measurements in a variable/storage at the UE (either at the access stratum or at the upper layers e.g., application layer).
  • the UE continues performing QoE measurements at the application layer, o
  • This can apply for instance, to QoE measurements for at least a service type supported in the other RAT and for which the use of the respective QoE configuration was not accepted by the other RAT
  • the UE may continue to check the status of the sessions for the applications for which to QoE measurements continues to be performed (even though reporting is suspended), for instance whether the session is ongoing, or a session ends, or a (new) session starts.
  • This method may be performed optionally based on an explicit indication from the RAN node, where in the indication might have been received from the OAM (0AM initiates the request to continue the measurement at the application layer upon moving to other radio access technologies e.g., LTE)
  • the UE may store some or all the QoE configurations for the services not supported in the LTE network (or other radio access technologies not supporting the QoE measurements for the specific services) in a variable/storage at the UE (either at the access stratum or at the upper layers e.g., application layer).
  • Storing the QoE configuration and continuation of the QoE measurements at the application layer may be explicitly requested by the RAN node or 0AM layer as part of an RRC reconfiguration message e.g., MobilityFromNRCommand
  • the UE may Resume reporting the QoE measurements collected when the UE was in another RAT to the network upon returning back to the radio access technology supporting the QoE measurements for the considered services (e.g., when returning back to NR).
  • the UE may send the stored QoE configurations to the network upon returning back to the radio access technology supporting the QoE measurements for the considered services (e.g., when returning back to NR).
  • the MobilityFromNRCommand message is used to command handover from NR to E- UTRA/EPC, E-UTRA/5GC or UTRA-FDD.
  • the UE shall: l>if the UE is connected to EPC:
  • Radio configuration is not just the resource configuration but includes other configurations like MeasConfig and OtherConfig.
  • this also includes the entire NR SCG configuration.
  • Such NR SCG configuration does not include the DRB configuration as configured by nr- RadioBearerConfigl and nr-RadioBearerConfig2). l>if the RRCConnectionReconfiguration message includes the measConfigAppLayer set to setup and the measConfigAppLayer includes the serviceType stored in the current UE configuration:
  • the UE shall: l>stop timer T310, if running; l>stop timer T312, if running; l>ifT316 is running:
  • the underlined parameters may be used to release a QoE configuration or to modify selected parameters of a QoE configuration.
  • the ⁇ start- stop_measurement> parameter can be used to release a QoE configuration.
  • the ⁇ ran_visible_release_only> parameter can be used to release the RAN Visible QoE configuration while keeping the rest of the QoE configuration.
  • the ⁇ transmission_of_session_start-end> parameter can be used to stop the application from sending session start/stop indications.
  • the bold parameters represent possible additions to the +CAPPLEVMCNR AT command to facilitate the adaptation of the QoE configuration(s) when the UE is handed over from NR to LTE.
  • This command allows control of the application level measurement configuration according to 3GPP TS 38.331 [160].
  • the set command controls the presentation of the unsolicited result code +CAPPLEVMCNR: (list of [ ⁇ CR> ⁇ LF>, ⁇ meas config app layer id>. [ ⁇ startstop measurement ⁇ , [ ran visible release only ! [ ⁇ app-meas config file length>, ⁇ app- meas config -file> /. [ ⁇ transmission of session startend ⁇ ].
  • Read command returns the current value of ⁇ n>.
  • Test command returns values supported as a compound value.
  • ⁇ n> integer type. Disable and enable presentation of the unsolicited result code +CAPPLEVMCNR to the TE.
  • ⁇ app-meas service type> integer type. Contains the indication of what application that is target for the application level measurement configuration.
  • ⁇ start-stop measurement integer type. Indicates the start and stop of the application level measurement reporting for the application indicated by the ⁇ app- meas service type > .
  • ⁇ app-meas config file length> integer type. Indicates the number of octets of the ⁇ app- meas config -file> parameter.
  • ⁇ app-meas config -file> string of octets. Contains the application level measurement configuration file for the application indicated by the ⁇ app-meas service type >. The parameter shall not be subject to conventional character conversion as per +CSCS.
  • ⁇ meas config app layer id> integer type.
  • the ⁇ meas config app layer id> indicates an identity for the QoE measurement configuration received in the ⁇ app-meas config -file>.
  • the ⁇ meas config app layer id> indicates the measurement to be released. The absence of this parameter indicates that all measurement configurations are released.
  • ⁇ transmission of session start-end> integer type. Contains an indication of whether session start-end is required.
  • ⁇ r eport playout delay for media startup integer type. Contains an indication of whether report of initial playout for media startup delay is required.
  • Example implementations based on 3GPP TS 27.007 version 18.1.0 is shown below, wherein the +CAPPLEVMC AT command is utilized (new sections underlined).
  • This command allows control of the application level measurement configuration according to 3GPP TS 25.331 [74] and 3GPP TS 36.331 [86].
  • the set command controls the presentation of the unsolicited result code +CAPPLEVMC: ⁇ app- meas service type>, ⁇ start-stop reporting [, ⁇ app-meas config file length>, ⁇ app- meas config ile>] providing data for the configuration.
  • Read command returns the current value of ⁇ n>.
  • Test command returns values supported as a compound value.
  • ⁇ n> integer type. Disable and enable presentation of the unsolicited result code +CAPPLEVMC to the TE.
  • ⁇ start-stop reporting integer type. Indicates the start and stop of the application level measurement reporting for the application indicated by the ⁇ app-meas service type> . 0 start the application level measurement reporting
  • ⁇ app-meas config-file> string of octets. Contains the application level measurement configuration file for the application indicated by the ⁇ app-meas service type>. The parameter shall not be subject to conventional character conversion as per +CSCS.
  • release nr configurations integer type. Indicates the release of NR configurations at handover from NR to LTE.
  • An alternative example of implementation of the AT command above can be the following (only new parameters for +CAPPLEVMC indicated), where QoE or RVQoE measurement collection is released for all service types or selectively for specific service types due to change in RAT (e.g. from NR to LTE) app-meas service type re lease : integer type. Contains the indication of what application level measurement configuration are released due to change in RAT.
  • An alternative example of implementation of the AT command above can be the following (only new parameters for +CAPPLEVMC indicated), where QoE or RVQoE measurement collection is paused or resumed for all service types or selectively for specific service types due to change in RAT (e.g. from NR to LTE or vice versa)
  • ⁇ app-meas service type _pause> integer type. Contains the indication of whether the use of application level measurement configurations is paused due to change in RAT.
  • ⁇ app-meas service type _resume> integer type. Contains the indication of whether the use of application level measurement configuration is resumed due to change in RAT.
  • Figure 5 shows an example of a communication system 500 in accordance with some embodiments.
  • the communication system 500 includes a telecommunication network 502 that includes an access network 504, such as a radio access network (RAN), and a core network 506, which includes one or more core network nodes 508.
  • the access network 504 includes one or more access network nodes, such as network nodes 510a and 510b (one or more of which may be generally referred to as network nodes 510), or any other similar 3 rd Generation Partnership Project (3 GPP) access node or non-3GPP access point.
  • 3 GPP 3 rd Generation Partnership Project
  • the network nodes 510 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 512a, 512b, 512c, and 512d (one or more of which may be generally referred to as UEs 512) to the core network 506 over one or more wireless connections.
  • UE user equipment
  • 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.
  • the communication system 500 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 500 may include and/or interface with any type of communication, telecommunication, data, cellular, radio network, and/or other similar type of system.
  • the UEs 512 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 510 and other communication devices.
  • the network nodes 510 are arranged, capable, configured, and/or operable to communicate directly or indirectly with the UEs 512 and/or with other network nodes or equipment in the telecommunication network 502 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 502.
  • the core network 506 connects the network nodes 510 to one or more hosts, such as host 516. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts.
  • the core network 506 includes one more core network nodes (e.g., core network node 508) 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 508.
  • 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).
  • MSC Mobile Switching Center
  • MME Mobility Management Entity
  • HSS Home Subscriber Server
  • AMF Access and Mobility Management Function
  • SMF Session Management Function
  • AUSF Authentication Server Function
  • SIDF Subscription Identifier De-concealing function
  • UDM Unified Data Management
  • SEPP Security Edge Protection Proxy
  • NEF Network Exposure Function
  • UPF User Plane Function
  • the host 516 may be under the ownership or control of a service provider other than an operator or provider of the access network 504 and/or the telecommunication network 502, and may be operated by the service provider or on behalf of the service provider.
  • the host 516 may host a variety of applications to provide one or more services. Examples of such applications include the provision of live and/or pre-recorded audio/video content, data collection services, for example, 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.
  • the communication system 500 of Figure 5 enables connectivity between the UEs, network nodes, and hosts.
  • 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.
  • GSM Global System for Mobile Communications
  • UMTS Universal Mobile Telecommunications System
  • LTE Long Term Evolution
  • the telecommunication network 502 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 502 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 502. For example, the telecommunications network 502 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.
  • URLLC Ultra Reliable Low Latency Communication
  • eMBB Enhanced Mobile Broadband
  • mMTC Massive Machine Type Communication
  • the UEs 512 are configured to transmit and/or receive information without direct human interaction.
  • a UE may be designed to transmit information to the access network 504 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 504.
  • a UE may be configured for operating in single- or multi -RAT or multi-standard mode.
  • 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).
  • MR-DC multi-radio dual connectivity
  • the hub 514 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.
  • the hub 514 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 514 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 514 then provides to the UE either directly, after performing local processing, and/or after adding additional local content.
  • the hub 514 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.
  • FIG. 6 shows a UE 600 in accordance with some embodiments.
  • 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 camera, 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.
  • VoIP voice over IP
  • LME laptop-embedded equipment
  • LME laptop-mounted equipment
  • CPE wireless customer-premise equipment
  • UEs identified by the 3rd Generation Partnership Project (3 GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE.
  • 3 GPP 3rd Generation Partnership Project
  • NB-IoT narrow band internet of things
  • MTC machine type communication
  • eMTC enhanced MTC
  • the UE 600 includes processing circuitry 602 that is operatively coupled via a bus 604 to an input/output interface 606, a power source 608, a memory 610, a communication interface 612, and/or any other component, or any combination thereof.
  • Certain UEs may utilize all or a subset of the components shown in Figure 6. The level of integration between the components 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.
  • the processing circuitry 602 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 610.
  • the processing circuitry 602 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.
  • the processing circuitry 602 may include multiple central processing units (CPUs).
  • the processing circuitry 602 may be operable to provide, either alone or in conjunction with other UE 600 components, such as the memory 610, UE 600 functionality.
  • the processing circuitry 602 may be configured to cause the UE 602 to perform the methods as described with reference to Figure 3.
  • the input/output interface 606 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 600.
  • 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.
  • USB Universal Serial Bus
  • the power source 608 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 608 may further include power circuitry for delivering power from the power source 608 itself, and/or an external power source, to the various parts of the UE 600 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 608.
  • Power circuitry may perform any formatting, converting, or other modification to the power from the power source 608 to make the power suitable for the respective components of the UE 600 to which power is supplied.
  • the memory 610 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.
  • RAID redundant array of independent disks
  • HD-DVD high-density digital versatile disc
  • HDDS holographic digital data storage
  • DIMM external mini-dual in-line memory module
  • SDRAM synchronous dynamic random access memory
  • SDRAM synchronous dynamic random access memory
  • the UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘ SIM card.’
  • eUICC embedded UICC
  • iUICC integrated UICC
  • SIM card removable UICC commonly known as ‘ SIM card.’
  • the memory 610 may allow the UE 600 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 610, which may be or comprise a device-readable storage medium.
  • the processing circuitry 602 may be configured to communicate with an access network or other network using the communication interface 612.
  • the communication interface 612 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 622.
  • the communication interface 612 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 618 and/or a receiver 620 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth).
  • the transmitter 618 and receiver 620 may be coupled to one or more antennas (e.g., antenna 622) and may share circuit components, software or firmware, or alternatively be implemented separately.
  • communication functions of the communication interface 612 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.
  • GPS global positioning system
  • 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/internet protocol (TCP/IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.
  • CDMA Code Division Multiplexing Access
  • WCDMA Wideband Code Division Multiple Access
  • WCDMA Wideband Code Division Multiple Access
  • GSM Global System for Mobile communications
  • LTE Long Term Evolution
  • NR New Radio
  • UMTS Worldwide Interoperability for Microwave Access
  • WiMax Ethernet
  • TCP/IP transmission control protocol/internet protocol
  • SONET synchronous optical networking
  • ATM Asynchronous Transfer Mode
  • QUIC Hypertext Transfer Protocol
  • HTTP Hypertext Transfer Protocol
  • a UE may provide an output of data captured by its sensors, through its communication interface 612, 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).
  • 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.
  • the states of the actuator, the motor, or the switch may change.
  • the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or controls a robotic arm performing a medical procedure according to the received input.
  • 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.
  • the UE may implement the 3 GPP NB-IoT standard.
  • 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.
  • any number of UEs may be used together with respect to a single use case.
  • 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.
  • 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.
  • a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.
  • FIG. 7 shows a network node 700 in accordance with some embodiments.
  • 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.
  • 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) and NR. NodeBs (gNBs)).
  • APs access points
  • BSs base stations
  • Node Bs evolved Node Bs
  • gNBs NodeBs
  • 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.
  • RRUs remote radio units
  • RRHs Remote Radio Heads
  • 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).
  • DAS distributed antenna system
  • the network node 700 includes processing circuitry 702, a memory 704, a communication interface 706, and a power source 708, and/or any other component, or any combination thereof.
  • the network node 700 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components.
  • the network node 700 comprises multiple separate components (e.g., BTS and BSC components)
  • one or more of the separate components may be shared among several network nodes.
  • a single RNC may control multiple NodeBs.
  • each unique NodeB and RNC pair may in some instances be considered a single separate network node.
  • the processing circuitry 702 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 700 components, such as the memory 704, network node 700 functionality.
  • the processing circuitry 702 may be configured to cause the network node to perform the methods as described with reference to Figure 4.
  • the memory 704 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 702.
  • 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-
  • the network node 700 does not include separate radio front-end circuitry 718, instead, the processing circuitry 702 includes radio front-end circuitry and is connected to the antenna 710. Similarly, in some embodiments, all or some of the RF transceiver circuitry 712 is part of the communication interface 706. In still other embodiments, the communication interface 706 includes one or more ports or terminals 716, the radio frontend circuitry 718, and the RF transceiver circuitry 712, as part of a radio unit (not shown), and the communication interface 706 communicates with the baseband processing circuitry 714, which is part of a digital unit (not shown).
  • the antenna 710, communication interface 706, and/or the processing circuitry 702 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 710, the communication interface 706, and/or the processing circuitry 702 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.
  • the memory 812 may include one or more computer programs including one or more host application programs 814 and data 816, which may include user data, e.g., data generated by a UE for the host 800 or data generated by the host 800 for a UE.
  • Embodiments of the host 800 may utilize only a subset or all of the components shown.
  • Hardware 904 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 906 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 908a and 908b (one or more of which may be generally referred to as VMs 908), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein.
  • the virtualization layer 906 may present a virtual operating platform that appears like networking hardware to the VMs 908.
  • the VMs 908 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 906. Different embodiments of the instance of a virtual appliance 902 may be implemented on one or more of VMs 908, 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.
  • NFV network function virtualization
  • a VM 908 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 908, and that part of hardware 904 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.
  • a virtual network function is responsible for handling specific network functions that run in one or more VMs 908 on top of the hardware 904 and corresponds to the application 902.
  • Figure 10 shows a communication diagram of a host 1002 communicating via a network node 1004 with a UE 1006 over a partially wireless connection in accordance with some embodiments.
  • host 1002 includes hardware, such as a communication interface, processing circuitry, and memory.
  • the host 1002 also includes software, which is stored in or accessible by the host 1002 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 1006 connecting via an over-the-top (OTT) connection 1050 extending between the UE 1006 and host 1002.
  • OTT over-the-top
  • a host application may provide user data which is transmitted using the OTT connection 1050.
  • the UE 1006 includes hardware and software, which is stored in or accessible by UE 1006 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 1006 with the support of the host 1002.
  • 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 1006 with the support of the host 1002.
  • an executing host application may communicate with the executing client application via the OTT connection 1050 terminating at the UE 1006 and host 1002.
  • 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 1050 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
  • the OTT connection 1050 may extend via a connection 1060 between the host 1002 and the network node 1004 and via a wireless connection 1070 between the network node 1004 and the UE 1006 to provide the connection between the host 1002 and the UE 1006.
  • the connection 1060 and wireless connection 1070, over which the OTT connection 1050 may be provided, have been drawn abstractly to illustrate the communication between the host 1002 and the UE 1006 via the network node 1004, without explicit reference to any intermediary devices and the precise routing of messages via these devices.
  • the host 1002 provides user data, which may be performed by executing a host application.
  • the user data is associated with a particular human user interacting with the UE 1006. In other embodiments, the user data is associated with a UE 1006 that shares data with the host 1002 without explicit human interaction.
  • the host 1002 initiates a transmission carrying the user data towards the UE 1006.
  • the host 1002 may initiate the transmission responsive to a request transmitted by the UE 1006.
  • the request may be caused by human interaction with the UE 1006 or by operation of the client application executing on the UE 1006.
  • the transmission may pass via the network node 1004, in accordance with the teachings of the embodiments described throughout this disclosure.
  • the network node 1004 transmits to the UE 1006 the user data that was carried in the transmission that the host 1002 initiated, in accordance with the teachings of the embodiments described throughout this disclosure.
  • the UE 1006 receives the user data carried in the transmission, which may be performed by a client application executed on the UE 1006 associated with the host application executed by the host 1002.
  • the UE 1006 executes a client application which provides user data to the host 1002.
  • the user data may be provided in reaction or response to the data received from the host 1002.
  • the UE 1006 may provide user data, which may be performed by executing the client application.
  • the client application may further consider user input received from the user via an input/output interface of the UE 1006. Regardless of the specific manner in which the user data was provided, the UE 1006 initiates, in step 1018, transmission of the user data towards the host 1002 via the network node 1004.
  • One or more of the various embodiments improve the performance of OTT services provided to the UE 1006 using the OTT connection 1050, in which the wireless connection 1070 forms the last segment. More precisely, the teachings of these embodiments may improve reduce unnecessary measurements and reporting performed by the UE and thereby provide benefits such as extended battery lifetime.
  • 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.
  • the measurement procedure and/or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host 1002 and/or UE 1006.
  • sensors (not shown) may be deployed in or in association with other devices through which the OTT connection 1050 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 1050 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node 1004. Such procedures and functionalities may be known and practiced in the art.
  • measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host 1002.
  • the measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 1050 while monitoring propagation times, errors, etc.
  • computing devices described herein 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 obtained information 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.
  • processing circuitry may process information by, for example, converting the obtained information 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.
  • computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • QoE quality of experience
  • the first indication comprises an identification, in the handover command, of a second QoE configuration associated with a first service type, wherein the first indication indicates that the at least one first configuration comprises any QoE configuration in the one or more QoE configurations not associated with the first service type.
  • the method of any preceding embodiments further comprising releasing or suspending one or more features of the one or more QoE configurations not supported by the second RAT.
  • the first indication comprises an indication to select a second QoE configuration to keep from the one or more QoE configurations.
  • releasing or suspending the at least one first QoE configuration comprises releasing or suspending a radio access network visible QoE configuration without releasing or suspending the entire associated QoE configuration.
  • the method as claimed in any preceding embodiment further comprising decoding the handover command before releasing or suspending the first QoE configuration.
  • suspending the at least one first QoE configuration comprises refraining from reporting measurements according to the at least one first QoE configuration when in communication with the second RAT. .
  • the indication comprises one or more of: an indication that UE should suspend or release the at least one first QoE configuration currently stored at the UE ; an indication of one or more service types for which the at least one first QoE configuration should be suspended or released; indication of a maximum (or a minimum) number of at least one first QoE configurations the UE should suspend or release; a time for which the at least one first QoE configuration are to be suspended.
  • the method of any one of embodiments 11 or 12 comprising suspending the at least one first QoE configuration, wherein the method comprises: performing measurements according to the at least one first QoE configuration whilst communicating with the second RAT; reporting the measurements to the first RAT upon returning to communication with the first RAT.
  • a method performed by a network node in a first radio access technology wherein the network node is in communication with user equipment, UE, configured with one or more one or more quality of experience, QoE, configurations for use with the first RAT, the method comprising: transmitting a message indicating that the UE is to communicate with a second RAT, wherein the message comprises a first indication relating to the release or suspension of at least one first QoE configuration of the one or more QoE configurations when commencing communication with the second RAT.
  • the first indication comprises one or more of: an indication that UE should suspend or release the at least one first QoE configuration currently stored at the UE ; an indication of one or more service types for which the at least one first QoE configuration should be suspended or released; indication of a maximum (or a minimum) number of at least one first QoE configurations the UE should suspend or release; a time for which the at least one first QoE configuration can be suspended.
  • a user equipment comprising: processing circuitry configured to cause the user equipment to perform any of the steps of any of the Group A embodiments; and power supply circuitry configured to supply power to the processing circuitry.
  • a network node comprising: processing circuitry configured to cause the network node to perform any of the steps of any of the Group B embodiments; power supply circuitry configured to supply power to the processing circuitry.
  • a user equipment comprising: an antenna configured to send and receive wireless signals; radio front-end circuitry connected to the antenna and to processing circuitry, and configured to condition signals communicated between the antenna and the processing circuitry; the processing circuitry being configured to perform any of the steps of any of the Group A embodiments; an input interface connected to the processing circuitry and configured to allow input of information into the UE to be processed by the processing circuitry; an output interface connected to the processing circuitry and configured to output information from the UE that has been processed by the processing circuitry; and a battery connected to the processing circuitry and configured to supply power to the UE.
  • UE user equipment
  • 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 user equipment (UE), wherein the UE comprises a communication interface and processing circuitry, the communication interface and processing circuitry of the UE being configured to perform any of the steps of any of the Group A embodiments to receive the user data from the host.
  • OTT over-the-top
  • the cellular network further includes a network node configured to communicate with the UE to transmit the user data to the UE from the host.
  • 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 UE, the client application being associated with the host application.
  • UE user equipment
  • the method of the previous embodiment further comprising: at the host, executing a host application associated with a client application executing on the UE to receive the user data from the UE.
  • 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 user equipment (UE), wherein the UE comprises a communication interface and processing circuitry, the communication interface and processing circuitry of the UE being configured to perform any of the steps of any of the Group A embodiments to transmit the user data to the host.
  • the cellular network further includes a network node configured to communicate with the UE to transmit the user data from the UE to the host.
  • 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 UE, the client application being associated with the host application.
  • UE user equipment
  • a host configured to operate in a communication system to provide an over-the-top
  • OTT 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 network node in a cellular network for transmission to a user equipment (UE), the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of any of the Group B embodiments to transmit the user data from the host to the UE.
  • UE user equipment
  • the processing circuitry of the host is configured to execute a host application that provides the user data; and the UE comprises processing circuitry configured to execute a client application associated with the host application to receive the transmission of user data from the host.
  • UE user equipment
  • a communication system configured to provide an over-the-top service, the communication system comprising: a host comprising: processing circuitry configured to provide user data for a user equipment (UE), the user data being associated with the over-the-top service; and a network interface configured to initiate transmission of the user data toward a cellular network node for transmission to the UE, the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of any of the Group B embodiments to transmit the user data from the host to the UE.
  • a host comprising: processing circuitry configured to provide user data for a user equipment (UE), the user data being associated with the over-the-top service; and a network interface configured to initiate transmission of the user data toward a cellular network node for transmission to the UE, the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of any of the Group B embodiments to transmit the user data from the host to the UE.
  • 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 any of the Group B embodiments to receive the user data from a user equipment (UE) for the host.
  • OTT over-the-top
  • 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 UE, the client application being associated with the host application.
  • the host of the any of the previous 2 embodiments, wherein the initiating receipt of the user data comprises requesting the user data.
  • UE user equipment

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Embodiments described herein relate to methods and apparatuses for releasing or suspending at least one first quality of Experience configuration A method performed by a user equipment, wherein the UE is in communication with a first radio access technology, RAT, comprises: obtaining one or more quality of experience, QoE, configurations for use with the first RAT; receiving, from a source node of the first RAT, a message indicating that the UE is to communicate with a second RAT,; commencing communication with a target node of the second RAT; and releasing or suspending at least one first QoE configuration of the one or more QoE configurations.

Description

METHODS AND APPARATUSES FOR RELEASING OR SUSPENDING ONE OR MORE QUALITY OF EXPERIENCE CONFIGURATIONS AT HANDOVER BETWEEN RADIO ACCESS TECHNOLOGIES
TECHNICAL FIELD
[1] Embodiments described herein relate to methods and apparatuses for releasing or suspending at least one first QoE configuration at handover between a first radio access technology (RAT) and a second RAT.
BACKGROUND
[2] Quality of Experience (QoE) measurements, also referred to as “application layer measurements”, have been specified for Long Term Evolution (LTE) and Universal Mobile Telecommunications Service (UMTS) and are being specified for New Radio (NR) in the 3rd Generation Partnership Project (3GPP) release 17. 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. 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.
[3] The solutions in LTE and UMTS are similar with the overall principles as follows. Quality of Experience Measurement Collection (QMC) enables configuration of application layer measurements in the user equipment (UE) and transmission of QoE measurement result files (commonly referred to as QoE reports) to the network by means of Radio Resource Control (RRC) signalling. 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 Management (OAM) system, or the Core Network (CN) is encapsulated in a transparent container, which is forwarded to a user equipment (UE) in a downlink RRC message. An application layer measurement report (also called QoE report) that the UE Access Stratum (UE 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).
[4] In 3 GPP release 17 a new study item for “Study on NR QoE management and optimizations for diverse services” for NR has been approved and concluded. The specification work for 3GPP release 17 is still ongoing. The purpose of the study item is to study solutions for QoE measurements in NR. QoE management in NR will not just collect the quality of experience parameters of streaming services but also consider the typical performance requirements of diverse services (e.g., Augmented Reality (AR)/VR and Ultra-reliable low latency communications (URLLC), of which at least VR seems to be covered in 3 GPP release 17). Based on requirements of services, the NR study also included more adaptive QoE management schemes that enable network optimization to satisfy user experience for diverse services.
[5] The configuration data related to QoE measurements (in standard specifications typically referred to as application layer measurements) comprises of a service type indication, an indication of an area in which the measurements are to be performed (denoted area scope), an Internet Protocol (IP) address of the entity the collected measurement results (i.e. 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.
[6] QoE, and in particular QoE configuration, comes in two flavors: management-based (m- based) QoE configuration and signaling-based (s-based) QoE configuration. In both cases the QoE configuration originates in the OAM system or some other administrational entity, e.g., dealing with customer satisfaction. All these entities are in this document referred to as the OAM system (where the OAM system also contains further entities). With management-based QoE (m-based QoE), the OAM 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 OAM 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 fulfills any other relevant condition, such as supporting the concerned application/service type) and sends the m-based QoE configuration to these UEs.
[7] With s-based QoE, the OAM 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 OAM system sends the s-based QoE configuration to the Homes Subscriber Server (HSS) (in EPS/LTE) or Unified Data Management (UDM) (in 5GS/NR), which forwards the QoE configuration to the UE’s current core network node (CN), e.g., an Mobile 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.
[8] 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 will be 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 Code (MCC) + Mobile Network Code (MNC) + QoE Measurement Collection (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 sent to the RAN (i.e., 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 (i.e., 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 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.
[9] Reports with collected QoE measurement results (i.e., 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.
[10] 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 can be introduced, which will be sent from the application layer in the UE to the UE AS and from the UE AS to the RAN. A session stop indication may be implicit in the form of a QoE report sent when the application session and the associated QoE measurement session are concluded.
[11] 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.
[12] 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.
[13] An extension of the QoE framework, which has been studied for 3 GPP release 17 and which is currently being specified in 3GPP is the concept of RAN visible QoE (RVQoE). The regular QoE reports are intended for the MCE, which is an entity outside the RAN, e.g., a part of the 0AM system, and the RAN cannot read the QoE reports (at least not according to specification, although gNB/eNB implementations are not prevented from doing so). In contrast, reported RVQoE metrics are intended for the RAN and are delivered to the RAN in a format that the RAN understands. The RVQoE metrics are derived from the regular QoE metrics, collected and compiled in reports by the UE application layer and delivered to the RAN, so that the RAN may use the reports for various types of optimizations. As an example, when the RAN receives RVQoE reports during an ongoing application session, the RAN can perform adaptive actions to impact the QoE of the concerned application session while the application session is ongoing, such as change various parameters related to the scheduling of the UE and the data flows related to the application session.
[14] 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.
[15] 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.
[16] 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).
[17] 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.
[18] When initiated via the core network, the measurement is started towards a specific UE. For the LTE case, the "TRACE START" SI AP 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.
[19] 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.
[20] Figure 1 is a signaling diagram illustrating the basic signaling (without showing all details) involved in QoE measurement configuration, from the O&M system to the UE. The diagram is a copy of a diagram in 3GPP TS 28.405 vl6.0.0 labeled “Figure 4.2.1-1 : QMC activation and reporting in LTE”.
[21] One opportunity provided by legacy solutions 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.
[22] 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.
[23] Figure 2 illustrates configuration and reporting of QoE measurements using RRC signaling.
[24] Attention (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. The AT commands are used in QoE for transferring the configuration from the RRC layer to the application and for transferring reports from the application layer to the RRC layer.
[25] In LTE, the UE can only be configured with one QoE measurement at a time. The UE is configured with the QoE configuration container and the service type for the measurement. See example code below:
[[ measConfigAppLayer-r 15 CHOICE{ release NULL, setup SEQUENCE{ measConfigAppLayerContainer-rl5 OCTET STRING
(SIZE(L.IOOO)), serviceType-r!5 ENUMERATED {qoe, qoemtsi, spare6, spare5, spare4, spare3, spare2, spare 1 }
} [26] In NR, the UE can be configured with up to 16 QoE measurements. The measurements are separated by an identity, the measConfigAppLayerld, and they are configured by means of an AddModList. See example code below:
[28] AppLayerMeasConfig-rl7 ::= SEQUENCE ]
[29] measConfigAppLayerToAddModList-rl7 SEQUENCE (SIZE
(1..maxNrofAppLayerMeas-r 17)) OF MeasConfigAppLayer-rl7 OPTIONAL, — NeedN
[30] measConfigAppLayerToReleaseList-rl7 SEQUENCE (SIZE
(1..maxNrofAppLayerMeas-r 17)) OF MeasConfigAppLayerId-rl7 OPTIONAL, — NeedN
[31] rrc-SegAllowed-rl7 ENUMERATED {enabled}
OPTIONAL, - NeedR
[32] ...
[33] }
[34]
[35] MeasConfigAppLayer-rl7 ::= SEQUENCE ]
[36] measConfigAppLayerId-rl7 MeasConfigAppLayerId-rl7,
[37] measConfigAppLayerContainer-rl7 OCTET STRING (SIZE (1..8000))
OPTIONAL, - NeedN
[38] serviceType-r!7 ENUMERATED {streaming, mtsi, vr, spare5, spare4, spare3, spare2, spare 1} OPTIONAL, — NeedM
[39] pauseReporting-r!7 BOOLEAN OPTIONAL,
— NeedM
[40] transmissionOfSessionStartStop-rl 7 BOOLEAN
OPTIONAL, - NeedM
[41] ran-VisibleParameters-r!7 SetupRelease ]RAN-VisibleParameters-rl7}
OPTIONAL, — Cond ServiceType
[42] ...
[43] }
[44]
[45] RAN-VisibleParameters-rl7 ::= SEQUENCE ]
[46] ran-VisiblePeriodicity-r!7 ENUMERATED {ms!20, ms240, ms480, ms640, ms 1024} OPTIONAL, - Need S [47] numberOfBufferLevelEntries-rl7 INTEGER (1-8)
OPTIONAL, - NeedR
[48] reportPlayoutDelayForMediaStartup-rl 7 BOOLEAN
OPTIONAL, - NeedM
[49] ...
[50] }
[51]
[52] At handover from NR to LTE the RRC message MobilityFromNRCommand is sent to the UE. The message comprises an LTE message, an RRCConnectionReconfiguration containing mobilityControlInfo in the form of an octet string. See below:
- MobilityFromNRCommand
The MobilityFromNRCommand message is used to command handover from NR to E- UTRA/EPC, E-UTRA/5GC or UTRA-FDD.
Signalling radio bearer: SRB1
RLC-SAP: AM
Logical channel: DCCH
Direction: Network to UE
MobilityFromNRCommand message
— ASN1 START
- TAG-MOBILITYFROMNRCOMMAND-START
MobilityFromNRCommand : := SEQ UENCE { rrc- Transactionidentifier RRC- Transactionidentifier, criticalExtensions CHOICE { mobilityFromNRCommand MobilityFromNRCommand-IEs, criticalExtensionsFuture SEQUENCE {}
MobilityFromNRCommand-IEs ::= SEQUENCE { targetRAT-Type ENUMERATED targetRA T-MessageContainer OCTET STRING, nas-SecurityParamFromNR OCTET STRING
OPTIONAL, - Cond HO-ToEPCUTRAN lateNonCriticalExtension OCTET STRING
OPTIONAL, nonCriticalExtension MobilityFromNRCommand-vl610-IEs
OPTIONAL
MobilityFromNRCommand-vl610-IEs ::= SEQUENCE { voiceFallbacklndication-r 16 ENUMERATED {true}
OPTIONAL, — NeedN nonCriticalExtension SEQUENCE {} OPTIONAL
- TAG-MOBILITYFROMNRCOMMAND-STOP
— ASN1ST0P NOTE 1 : The correspondence between the value of the targetRAT-Type, the standard to apply, and the message contained within the targetRAT-MessageContainer is shown in the table below:
[53] When a UE performs a handover (reconfigurationWithSync) from one NR cell to another NR cell, there are two possibilities for how the target configuration is signaled to the UE. In case of delta signaling, the network only indicates differences in the AS configuration between the source cell and the target cell in the Handover Command message (an RRCReconfiguration message comprising reconfigurationWithSync) triggering the handover. In case of handover with fullConfig, the UE releases the existing configuration in the UE AS layer and adds a new, complete AS configuration included in the Handover Command. Reconfiguration with fullConfig can also occur at RRC re-establishment. Configurations in higher layers in the UE, such as the application layer, are not affected by reconfiguration with fullConfig in UE AS. At handover from NR to LTE, the LTE message RRCConnectionReconfiguration comprising mobility Controlinfo (the LTE message included in MobilityFromNRCommand) may contain a fullConfig of the LTE configuration.
[54] QoE measurements consist of both a UE AS layer part and an application layer part. At reconfiguration with fullConfig, the UE releases the AS layer part, but keeps the application layer part as the application layer part is not a radio configuration. In rel-17, reconfigurations with fullConfig were discussed and it was agreed that the network signals the QoE configurations to be kept and the QoE configurations to be released by signaling the measConfigAppLayerld of the configurations respectively, either in the AddModList or in the Release list. If the QoE configuration should be continue, the UE will the receive the AS part of the configuration again, which was cleared as part of the fullConfig, and the application layer part will still be remain. If the QoE configuration should be released, the network can indicate release of configurations to the UE and the UE AS will indicate to the application layer that a QoE configuration should be released. If no QoE measurement is indicated in the RRCReconfiguration message compri sing fullConfig, all QoE measurements will be released. That is applicable for the case that the target node doesn’t support QoE measurements and is not able to signal anything related to QoE.
[55] In NR the following is specified in 3GPP TS 38.331 vl7.3.0 related to fullConfig'.
1> if no measConfigAppLayerld is included:
2> inform upper layers about the release of all application layer measurement configurations;
2> discard any received application layer measurement report from upper layers;
2> consider itself not to be configured to send application layer measurement report.
[56] In LTE, the QoE configuration container is mandatory in the RRCConnectionReconfiguration message, and it is not possible to exclude it. Therefore, a solution was agreed where the UE AS layer doesn’t forward the container to the application layer if the measurements should continue at the handover with fullConfig. If the target node doesn’t support QoE measurements, nothing will be indicated in the message and the UE will release the QoE measurements. From 3GPP TS 36.331 vl7.3.0:
> if the RRCConnectionReconfiguration message includes the measConfigAppLayer set to setup and the measConfigAppLayer includes the serviceType stored in the current UE configuration:
2> discard the measConfigAppLayer,
2> consider the measConfigAppLayer as not received;
1> else if a serviceType is stored in the current UE configuration:
2> release the stored serviceType,'
2> inform upper layers to clear the stored application layer measurement configuration;
2> discard received application layer measurement report information from upper layers; 2> consider itself not to be configured to send application layer measurement report; SUMMARY
[57] There currently exist certain challenge(s). At handover or during other reconfigurations compri sing fullConfig, the AS layer is cleared in the UE (with some exceptions). In addition, all QoE measurements are released in the application layer in the UE if the target node doesn’t signal any QoE configurations to the UE in the Handover Command message. The reason for this is that there should be no “hanging” measurements in the application layer in case the target node doesn’t support QoE measurements.
[58] At UE handover from NR to LTE, the target LTE node may support QoE measurements, but, a UE served by an LTE node may be configured with only one QoE measurement configuration at a time. If the target node signals one QoE configuration, the other existing measurements will not be released in the UE, as the UE only releases configurations if no QoE configuration is signaled. However, an LTE node does not have the possibility to release other QoE measurements by signaling a list of QoE configurations as that functionality does not exist in LTE (since a UE served by an eNB can have only one QoE configuration at a time). If a UE executes a handover from NR to LTE and measurements for one service type continue in the LTE node, possibly other QoE configurations which the UE was configured with in NR may still remain "hanging” in the UE and the target node does not have the possibility to release them. Also, other NR specific QoE functionality, e.g. RAN visible QoE, or alignment with MDT, is not possible to release from LTE and may be hanging in the UE at handover from NR to LTE.
[59] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges.
Some embodiments described herein provide a method in a UE, the method comprising:
Obtaining one or more configurations of QoE measurements in NR (a first Radio Access Technology (RAT)).
Receiving a message containing a command for handover from NR (first RAT) to LTE (second RAT). The message may be a MobilityFromNRCommand'RKC message, comprising an LTE message RRCConnectionReconfiguration comprising mobilityControlInfo, where the RRCConnectionReconfiguration message is created by the target node, sent to the source node (a gNB) during the IRAT handover preparation phase as a transparent container (i.e. the source gNB is not expected to read or understand it) and then included by the source node in the MobilityFromNRCommand message in the form of an OCTET STRING contained in the targetRAT-MessageContainer IE.
In one solution (explicit solution), the MobilityFromNRCommand is updated to contain the I^AppLayerMeasConfig, so that NR-specific parts of QoE configurations may be released, o In one option, “NR-specific parts of QoE configurations that are to be released” refers to the QoE measurement configurations for the service types for which the QoE measurements are supported in NR, but not supported in LTE (e.g., VR). o In another option, “NR-specific parts of QoE configurations that are to be released” includes features of QoE measurement configurations for service types for which QoE measurements are supported in both LTE and NR, but the features that are a part of the QoE measurement configuration are supported in NR, and not in LTE.
■ For example, QoE measurements for MTSI and DASH are supported in both LTE and NR, but features such as RAN visible QoE, alignment with MDT are supported in NR, but not supported in LTE.
In an alternative solution (implicit solution where AppLayerMeasConfig may not be included in MobilityFromNRCommand), if the RRCConnectionReconfiguration message (also referred to as the Handover Command below) contained in the targetRAT-MessageContainer IE contains the configuration of QoE measurements, i.e. a service type and a QoE configuration container: o Releasing other QoE configurations configured in NR, i.e. releasing QoE configurations of different service types than received in the QoE configuration in the Handover Command. o Releasing other QoE configurations comprises releasing everything related to the QoE configurations, e.g. release of measConfigAppLayerld for the configurations, release of the service types, release of QoE reference etc. o Releasing the NR-specific parts of the QoE configuration continuing in LTE. As explained for the explicit solution, the “NR part of the configuration” refers to features inside a QoE measurement configuration for a service type that is supported in both LTE and NR, but where the feature itself is supported in NR, and not in LTE.
Continuing the QoE measurements for the indicated service type in LTE, possibly without the NR-specific features.
If the RRCConnectionReconfiguration message does not contain the configuration of
QoE measurements, i.e. a service type and a QoE configuration container: o Releasing all QoE configurations. [60] Also, some network embodiments, some embodiments related to handover from LTE to NR, release with redirect and UE capabilities are included.
[61] The embodiments described herein relate to how avoid hanging QoE measurements in the UE at handover from a first RAT (e.g. NR) to a second RAT (e.g. LTE).
[62] According to some embodiments there is provided a method performed by a user equipment, UE. The UE is in communication with a first radio access technology, RAT. The method comprising obtaining one or more quality of experience, QoE, configurations for use with the first RAT; receiving, from a source node of the first RAT, a message indicating that the UE is to communicate with a second RAT; commencing communication with a target node of the second RAT; and releasing or suspending at least one first QoE configuration of the one or more QoE configurations.
[63] According to some embodiments there is provided a method performed by a network node in a first radio access technology. The network node is in communication with user equipment, UE, configured with one or more one or more quality of experience, QoE, configurations for use with the first RAT. The method comprises transmitting a message indicating that the UE is to communicate with a second RAT, wherein the message comprises a first indication relating to the release or suspension of at least one first QoE configuration of the one or more QoE configurations when commencing communication with the second RAT.
[64] According to some embodiments there is provided a user equipment, UE, wherein the UE is adapted to communicate with a first radio access technology, RAT. The UE comprises processing circuitry and memory, the memory containing instructions executable by the processing circuitry whereby the UE is operable to: obtain one or more quality of experience, QoE, configurations for use with the first RAT; receive, from a source node of the first RAT, a message indicating that the UE is to communicate with a second RAT; commence communication with a target node of the second RAT; and release or suspend at least one first QoE configuration of the one or more QoE configurations.
[65] According to some embodiments there is provided a network node in a first radio access technology. The network node is adapted to communicate with user equipment, UE, configured with one or more one or more quality of experience, QoE, configurations for use with the first RAT. The network node comprises processing circuitry and memory, the memory containing instructions executable by the processing circuitry whereby the network node is operable to: transmit a message indicating that the UE is to communicate with a second RAT, wherein the message comprises a first indication relating to the release or suspension of at least one first QoE configuration of the one or more QoE configurations when commencing communication with the second RAT.
[66] According to some embodiments there is provided a computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out any of the methods described above.
[67] According to some embodiments there is provided a carrier containing the computer program as described above, wherein the carrier comprises one of an electronic signal, optical signal, radio signal or computer readable storage medium.
[68] According to some embodiments there is provided a computer-readable medium comprising instructions that, when executed on at least one processor, cause the at least one processor to perform any of the methods described above.
[69] According to some embodiments there is provided a computer program product comprising non transitory computer readable media having stored thereon a computer program as described above.
[70] Certain embodiments may provide one or more of the following technical advantage(s).
[71] An advantage of the embodiments described herein is that the avoidance of QoE measurements hanging in the UE at IRAT handover from a first RAT (e.g. NR) to a second RAT (e.g. LTE). Release of unnecessary measurements, i.e. measurements which can anyhow not be reported to the network, is important in order to avoid wasting the UE capacity and to prolong the battery lifetime of the UE.
[72] To account for the fact that the UE may return to the first RAT (e.g. NR) within a short time, the use of the QoE configurations configured in the UE for NR can be temporarily paused whilst the UE is communicating with LTE and resumed when the UE returns to NR, thus removing the need to re-send the QoE configurations to the UE again.
BRIEF DESCRIPTION OF THE DRAWINGS
[73] For a better understanding of the embodiments of the present disclosure, and to show how it may be put into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:
[74] Fig. 1 is a signaling diagram providing an overview of the signaling involved in QoE measurement configuration, from the O&M system to the UE;
[75] Fig. 2 illustrates configuration and reporting of QoE measurements using RRC signaling; [76] Fig. 3 is a flow chart illustrating a method in accordance with some embodiments;
[77] Fig. 4 is a flow chart illustrating a method in accordance with some embodiments;
[78] Fig. 5 shows an example of a communication system in accordance with some embodiments;
[79] Fig. 6 shows a UE in accordance with some embodiments;
[80] Fig. 7 shows a network node in accordance with some embodiments;
[81] Fig. 8 is a block diagram of a host;
[82] Fig. 9 is a block diagram illustrating a virtualization environment in which functions implemented by some embodiments may be virtualized; and
[83] Fig. 10 shows a communication diagram of a host communicating via a network node with a UE over a partially wireless connection in accordance with some embodiments.
DETAILED DESCRIPTION
[84] 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.
[85] Herein, the application layer in the UE may also be referred to as the “UE application layer” or simply the “application layer”.
[86] The terms “QoE configuration”, “QoE parameters”, “QoE information” and “QoE configuration information” are used interchangeably. The content therein may be as defined below, and, optionally, to any additional information related to the QoE measurements. The network, the UE AS and the UE application layer may store various parts thereof.
[87] 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.
[88] The terms “application layer measurement configuration”, “application measurement configuration”, “RVQoE measurement configuration”, “RVQoE configuration”, “RVQoE measurement and reporting configuration” and “QMC configuration” are used interchangeably. [89] While the solutions are described for the interaction between the UE AS and UE application layer when handling/storing QoE information, they may also be applicable to RVQoE information.
[90] All references to the application layer are with respect to the application layer of the UE.
[91] 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.
[92] The solution proposed in this invention applies to both signaling- and management-based QoE/RVQoE measurements (but may also optionally be restricted to apply to only one of them).
[93] In some embodiments an instruction on whether the UE should send session start/stop indications) provides 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”.
[94] The functionality in a UE which 3 GPP 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”.
[95] 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).
[96] 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).
[97] Param eters/IEs/fi elds used in ASN.1 code as well as in procedural text in the 3 GPP RRC specification for 5G/NR, i.e. 3GPP TS 38.331 version 17.3.0, are often named with a suffix indicating the number of the release of the 3 GPP standard the param eter/IE/fi eld 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.l code (and thus defines the formal name from the ASN. l 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 AppLayerMeasConfig-rl7 / AppLayerMeasConfig and MeasConfigAppLayer-rl7 / MeasConfigAppLayer. In this document, both name variants may occur for various parameters/IEs/fields
[98] Detailed description of solutions related the handling of QoE measurements at handover from a first RAT (e.g. NR) to a second RAT (e.g. LTE)
[99] Some embodiments comprise a method for a UE where the UE is configured with QoE measurements in NR and an IRAT handover to LTE is triggered. In LTE the UE can only be configured with one QoE measurement at a time, and the invention describes methods to release other QoE measurements in the UE and also to release other QoE functionality in the UE which do not exist in LTE. An LTE target node (i.e. an eNB that controls the target cell of a handover) is in existing specifications not able to release QoE functionality configured in NR.
[100] Figure 3 is a flowchart illustrating a method in accordance with some embodiments. Figure 3 depicts a method in accordance with particular embodiments. The method of Figure 3 may be performed by a UE or wireless device (e.g. the UE 512 or UE 600 as described later with reference to Figures 5 and 6 respectively). The UE may be in communication with a first radio access technology (RAT). The method begins at step 302 with obtaining one or more quality of experience, QoE, configurations for use with the first RAT. For example, the UE may be configured by the first RAT with the one or more QoE configurations for use with the first RAT.
[101] In step 304 the method comprises receiving, from a source node of the first RAT, a message indicating that the UE is to communicate with a second RAT. The message may comprise a handover command or a RRC release with re-direct to a second RAT message.
[102] The message may comprise a first indication relating to the release or suspension of at least one first QoE configuration of the one or more QoE configurations when commencing communication with the second RAT. The first indication may comprise an identification of the at least one first QoE configuration. It will be appreciated that the at least one first QoE configuration may comprise all but one of the one or more QoE configurations. The first indication may comprise an identification, in the handover command, of a second QoE configuration associated with a first service type, wherein the first indication indicates that the at least one first configuration comprises any QoE configuration in the one or more QoE configurations not associated with the first service type.
[103] The first indication may comprise an instruction to the UE to select which of the one or more QoE configurations to release or suspend. [104] The first indication may comprise one or more of: an indication that UE should suspend or release the at least one first QoE configuration currently stored at the UE; an indication of one or more service types for which the at least one first QoE configuration should be suspended or released; indication of a maximum (or a minimum) number of at least one first QoE configurations the U E should suspend or release; a time for which the at least one first QoE configuration are to be suspended.
[105] In step 306 the method comprises commencing communication with a target node of the second RAT. In step 308 the method comprises releasing or suspending at least one first QoE configuration of the one or more QoE configurations. In some examples step 306 may be performed according to the first indication. It will be appreciated that suspending the at least one first QoE configuration comprises refraining from reporting measurements according to the at least one first QoE configuration when in communication with the second RAT.
[106] Figure 4 is a flowchart illustrating a method in accordance with some embodiments.
[107] Figure 4 depicts a method in accordance with particular embodiments. The method of Figure 4 may be performed by a network node (e.g. the network node 510 or network node 700 as described later with reference to Figures 5 and 7 respectively). The network node may be in a first RAT. The network node may be in communication with user equipment, UE, configured with one or more one or more quality of experience, QoE, configurations for use with the first RAT. The method begins at step 402 with transmitting a message indicating that the UE is to communicate with a second RAT, wherein the message comprises a first indication relating to the release or suspension of at least one first QoE configuration of the one or more QoE configurations when commencing communication with the second RAT. Step 402 corresponds to some examples of step 304 of Figure 3. The first indication may be defined similarly to as described with reference to some examples of step 304.
[108] As previously described embodiments described herein provide a method in a UE.
[109] The UE may receive configuration of one or more QoE measurements in NR (a first RAT) (e.g. as described with reference to step 302).
[110] The UE may then receive a message containing a command for handover from NR (first RAT) to LTE (second RAT) (which is an example implementation of step 304). The message may be a MobilityFromNRCommand RRC message, comprising an LTE message RRCConnectionReconfiguration comprising mobilityControlInfo, where the RRCConnectionReconfiguration message is created by the target node, sent to the source node (a gNB) during the IRAT handover preparation phase as a transparent container (i.e. the source gNB is not expected to read or understand it) and then included by the source node in the MobilityFromNRCommand message in the form of an OCTET STRING contained in the targetRAT-MessageContainer IE.
[Hl] In some embodiments, the message (e.g. MobilityFromNRCommand) is updated to comprise an information element (e.g. the IE AppLayerMeasConfig) comprising an identification of the at least one first QoE. The information element may therefore comprise an example of the first indication of step 304. This information element may then ensure thatNR- specific parts of the one or more QoE configurations may be released or suspended.
[112] In some examples, “NR-specific parts of QoE configurations that are to be released” refers to the QoE configurations for service types for which QoE measurements are supported in NR, but not supported in LTE (e.g., VR).
[113] In another example, “NR-specific parts of QoE configurations that are to be released” includes features of QoE measurement configurations for service types for which QoE measurements are supported in both LTE and NR, but the features that are a part of the QoE measurement configuration are supported in NR, and not in LTE. In other words, the method of Figure 3 may further comprise releasing or suspending one or more features of the one or more QoE configurations not supported by the second RAT. a. For example, QoE measurements for MTSI and DASH are supported in both LTE and NR, but features such as RAN visible QoE, alignment with MDT are supported in NR, but not supported in LTE.
[114] In some embodiments, the AppLayerMeasConfig IE contains a measConfigAppLayerToReleaseList IE including the MeasConfigAppLayerldtfi) associated with at least one first QoE configurations to be released or suspended.
[115] In some embodiments, the source node uses a MeasConfigAppLayer IE in the measConfigAppLayerToAddModList IE in the AppLayerMeasConfig IE to release the RAN Visible QoE configuration associated with a QoE configuration without releasing the entire QoE configuration. In other words, the method of Figure 3 may comprise releasing or suspending a radio access network visible QoE configuration without releasing or suspending the entire associated QoE configuration.
[116] In some embodiments, the source node uses a MeasConfigAppLayer IE in the measConfigAppLayerToAddModList IE in the AppLayerMeasConfig IE to turn off sending of session status indications by setting the pauseReporting IE to “false” in the MeasConfigAppLayer IE, and/or, in case QoE measurement reporting has been paused/suspended, to resume QoE measurement reporting by setting the transmissionOfSessionStartStop IE to “false” in the MeasConfigAppLayer IE.
[117] In some embodiments, a nonCriticalExtension field in the MobilityFromNRCommand message is used to extend the MobilityFromNRCommand message (as defined in 3GPP TS 38.331 version 17.3.0) with the AppLayerMeasConfig IE.
[118] In some embodiments, the AppLayerMeasConfig IE is not included in the MobilityFromNRCommand message, but instead other new IE(s) are added to the message (e.g. utilizing the nonCriticalExtension field) to indicate the required release, modification or suspension of the at least one first QoE configuration, and/or deletion of QoE related parameters in the one or more QoE configurations that are not applicable in the second RAT (i.e. LTE in this scenario).
[119] In some embodiments, the AppLayerMeasConfig IE is included in the MobilityFromNRCommand message, and it is complemented by one or more additional IE(s) which may serve to indicate complemental modifications or deletions of QoE related parameters in the one or more QoE configurations that are not applicable in the target RAT (i.e. LTE in this scenario). The nonCriticalExtension field in the MobilityFromNRCommand message may be utilized to include both the AppLayerMeasConfig IE and the additional complementing IE(s) in the MobilityFromNRCommand message.
[120] In some embodiments, the UE NR QoE configurations are not released immediately, but the inner RRCConnectionReconfiguration (i.e. the RRCConnectionReconfiguration in the targetRAT-MessageContainer IE) is decoded before the at least one first QoE configuration or features of the one or more QoE configuration are released/suspended. In other words, the method of Figure 3 further comprises decoding the handover command before releasing or suspending the first QoE configuration.
[121] In some embodiments, the RRCConnectionReconfiguration in the targetRAT- MessageContainer IE comprises a second QoE configuration of QoE measurements for a first service type, the UE keeps a QoE configuration from the one or more QoE configurations for that first service type and releases or suspends the other QoE configurations of the one or more QoE configurations.
[122] In some embodiments (where AppLayerMeasConfig may not be included in MobilityFromNRCommand), the RRCConnectionReconfiguration message (also referred to as the Handover Command below) contained in the targetRAT-MessageContainer IE comprises a second QoE configuration of QoE measurements, i.e. a first service type and a QoE configuration container. This second QoE configuration may comprise the first indication of step 304.
[123] The second QoE configuration may indicate to the UE to release or suspend any other QoE configurations of the one or more QoE configurations configured in NR, e.g. to release or suspend QoE configurations of different service types than the first service type indicated in the Handover Command.
[124] It will be appreciated that releasing a QoE configuration may comprise releasing everything related to the QoE configuration, e.g. release of measConfigAppLayerld for the configurations, release of the service types, release of QoE reference etc.
[125] In other examples, releasing a QoE configuration may comprise releasing the NR- specific parts of the QoE configuration when communicating in LTE. The “NR part of the configuration” refers to features inside a QoE configuration for a service type that is supported in both LTE and NR, but where the feature itself is supported in NR, and not in LTE. This sort of release may comprise releasing one or more of the following features:
■ The measConfigAppLayerld.
■ I (RAN VIble QoE) configurations
■ Pause of reporting, i.e. resuming the reporting in LTE.
■ The alignment with MDT (in standalone connectivity, or in dual connectivity).
■ QoE measurements and/or RVQoE measurements in non-RRC connected state
■ Slice-based QoE measurements
• As one option, the QoE configuration is released if it is restricted to one or more network slice(s) (as indicated by S-NSSAI(s)).
• As another option, the QoE configuration is kept, but the slice scope (i.e. the list of network slices indicated by a list of S-NSSAI(s) in the QoE configuration at the application layer) is released/deleted or associated with an indication that it should be ignored.
■ segmentation of QoE reporting
■ Scope parameters related to limiting QoE measurements to:
• MBS service areas, MBS service Id
• HSDN area / HSDN cells
• UEs in high mobility state or UE with high speed/velocity
• Use of shared spectrum (e.g., NR-U)
• Use of non-public networks (or use of private networks) [126] In some embodiments, which may be combined with other options of the invention, the UE determines whether it can keep or not in LTE a certain NR specific QoE configuration based on its support in LTE for QoE measurement collection for the service type which the NR specific QoE configuration refers to.
[127] The method of figure 3 may then further comprise continuing performing QoE measurements when in communication with the second RAT. The QoE measurements may be performed according to any QoE configuration that has not been released or suspended, possibly without the NR-specific features. It will be appreciated that after releasing or suspending the at least one first QoE configuration the UE may be left with a second QoE configuration (from the one or more QoE configurations) that can be used to perform and report QoE measurements in the second RAT. The second QoE configuration may have been modified to remove features that are not supported in the second RAT.
[128] In some examples, e.g. where the at least one first QoE configuration is suspended, the method of Figure 3 may further comprise performing measurements according to the at least one first QoE configuration whilst communicating with the second RAT, and reporting the measurements to the first RAT upon returning to communication with the first RAT.
[129] In some embodiments, the RRCConnectionReconfiguration message does not contain the configuration of QoE measurements, i.e. a service type and a QoE configuration container: the method of Figure 3 may comprise releasing or suspending all of the one or more QoE configurations.
[130] In some embodiments, first indication of the message of step 304 (e.g. the RRCConnectionReconfiguration message) may contain an indication that instructs the UE to choose itself which QoE measurement configuration to keep, among all its current one or more QoE configurations of any service type. This first indication may be explicit or implicit. An example of an implicit first indication may be that no instruction for release or suspension has been issued to the UE. In this case, the UE may choose the (one) QoE measurement configuration to keep. In other words, the first indication of step 304 may comprise an indication to select a second QoE configuration to keep from the one or more QoE configurations. Implicitly, in this scenario, the other of the one or more QoE configurations may be set as the at least one first QoE configuration and may therefore be suspended or released.
[131] For example, the UE may decide: o To keep the second QoE measurement configuration that pertains to a certain service type. o To keep the second QoE measurement configuration that pertains to the application session whose DRB have the highest QoS requirements, among the configurations that LTE can support o To keep the second QoE measurement configuration that pertains to the application session using the highest priority slice o To keep the second QoE measurement configuration that pertains to the application session that is active or is being the most active, among all the measured sessions. o To keep the second QoE measurement configuration that is signalling-based or that is management-based. o To keep the second QoE configuration for which the application session is ongoing. o To keep the second QoE configuration with the longest or shortest reporting periodicity, o To keep the second QoE configuration for a service type for which measurements are supported in both NR and LTE, but that has the smallest number of NR-specific features configured.
[132] If the UE is configured with more than one QoE configuration for the same service type in NR, the network may select one of them to continue in LTE. If no explicit release of QoE measurements is signaled to the UE, the UE may determine which QoE configuration should be maintained for use in LTE. o In one alternative, the UE chooses the QoE configuration to retain by itself. In another alternative, the network indicates to the UE which service to prioritize, and the UE chooses which exact QoE configuration to keep. o Each QoE configuration may contain a priority indication and the UE keeps the one with the highest indicated priority. If more than one QoE configuration has the highest indicated priority, the choice of which of them to keep may be left to the UE. o When determining which of the QoE configurations to keep, the UE may take into account whether a QoE measurement session is ongoing for a QoE configuration, e.g. by giving such a QoE configuration higher priority, and/or using this as a selection criterion when choosing one QoE configuration to keep out of multiple QoE configurations with the highest indicated priority.
The UE may determine the QoE configuration to keep in LTE by: o Checking the QoE reference inside the QoE configuration file transmitted in LTE and comparing the QoE reference by the reference in NR. The QoE configuration with the same QoE reference in NR and in LTE should be kept in LTE. The check may be done in the UE application layer or in the UE AS layer. If the UE AS layer performs the check, the application may send the QoE reference to the UE AS layer, possibly upon request from the UE AS layer, o By using one or more criteria described above for the case where the UE chooses by itself which configuration to keep, among all available configurations of any service type.
[133] In some examples, the instruction to select a second QoE configuration may be combined with an indication of the at least one first QoE configuration. For example, the message may identify a first subset of QoE configrations from the one or more QoE configurations that the UE should release or suspend. However, this may leave a plurality of QoE configurations in the one or more QoE configurations that the UE can then select a second QoE configuration to keep from.
[134] In one option, the UE is provided by the network (e.g., as part of the RRCConnectionReconfiguration message) an indication to retain and suspend all NR related QoE/RVQoE configuration(s) it has received in NR (e.g. the one or more QoE configuration), and not use any of them, or an indication to retain and suspend all the NR related QoE/RVQoE configuration it has received in NR, and use only a second QoE configuration that results from applying any of the criteria/embodiments of the invention. The UE may also receive the indication of a retention period (e.g., 24 hours) which indicate for how long the UE should keep the NR related QoE/RVQoE information when the UE is not camped on or connected to a cell in NR. The retention period may not be explicitly communicated to the UE, but it is a fixed period indicated in the specification (e.g. 24 hours or 48 hours).
[135] In some examples the message of step 304 comprises an RRC release with re-direct to the second RAT. If the UE is configured for QoE/RVQoE measurements, it the message from the NR RAT (i.e., from a gNB) indicating to release the existing NR connection and re-establish a new connection in the other RAT (e.g. in LTE), for example, when the coverage area of the NR RAT is reached and the gNB opted to not initiate a handover procedure to LTE, and determined instead to release the UE, indicating in an RRC Release message that UE should move to an E-UTRA carrier. [136] If the UE had received QoE/RVQoE configurations, then the gNB may include, as part of the RRCRelease message (e.g. the message of step 304), instructions on how the UE should treat the QoE/RVQoE configurations.
[137] The above instructions can comprise the first indication related to the release or suspension of NR related QoE and/or RVQoE configuration (e.g., in a “suspend QMC configuration” IE, or a “suspend NR QMC” IE, or alike) providing: indication that UE should retain and suspend the QoE configuration currently stored at the UE (and/or the RVQoE configuration stored at the UE), indication of which QoE/RVQoE configurations the UE should retain and suspend, indications of service types for which the QoE/RVQoE configuration should be retained and suspended, indication of a maximum (or a minimum) number of QoE/RVQoE configuration the UE should retain and suspend a time related information, indicating for how long the QoE/RVQoE configurations should be retained and suspended (this may also be omitted, and a fixed period is instead indicated in the specification (e.g. 24 hours or 48 hours)).
[138] In some examples, the instructions the UE can receive can comprise a first indication related to the release of NR related QoE and/or RVQoE configuration (e.g., in a “release QMC configuration” IE, or a “release NR QMC” IE, or alike) providing indication to release one or more QoE/RVQoE configurations according to criteria detailed in other embodiments described herein. For example: indication that UE should release all the QoE configuration currently stored at the UE (and/or the RVQoE configuration stored at the UE), indication of which QoE/RVQoE configurations the UE should release, indications of service types for which the QoE/RVQoE configuration should be released,
[139] In one alternative, the UE may autonomously determine to retain (and/or suspend) all the NR related QoE/RVQoE configuration that are not explicitly or implicitly released by the network. [140] An example of implementation of indication to suspend NR related QoE configuration and to suspend RVQoE reporting when UE is released from NR and redirected to LTE, is shown below:
RRCRelease-vl800-IEs ::= SEQUENCE { measConfigAppLayerToSuspendList-rl8 SEQUENCE (SIZE (L.maxNrofAppLayerMeas- r!7)) OF MeasConfigAppLayerId-rl7, suspend-ran- Visible-QoE-Streaming-MeasReport ENUMERA TED {supported}
OPTIONAL, suspend-ran-Visible-QoE-VR-MeasReport ENUMERATED {supported} OPTIONAL, nonCriticalExtension SEQUENCE {} OPTIONAL
[141] An example of implementation of indication to release NR related QoE configuration and to suspend RVQoE reporting when UE is released from NR and redirected to LTE, is shown below:
RRCRelease-vl800-IEs ::= SEQUENCE { measConfigAppLayerToReleaseList-rl7 SEQUENCE (SIZE (L.maxNrofAppLayerMeas- r!7)) OF MeasConfigAppLayerId-rl7, suspend-ran- Visible-QoE-Streaming-MeasReport ENUMERA TED {supported}
OPTIONAL, suspend-ran-Visible-QoE-VR-MeasReport ENUMERATED {supported}
OPTIONAL, nonCriticalExtension SEQUENCE {} OPTIONAL
[142] If the UE has retained (or suspended) NR related QoE/RVQoE configurations upon transitioning from NR RAT to LTE RAT, it may receive indications from the target NR node that the use of any or all or only certain suspended (or retained) QoE configuration can be resumed.
[143] For example, the MobilityFromEUTRANCommand can be used to convey, as part of the targetRAT -MessageContainer (encoded as OCTET STRING and corresponding to an RRCReconfiguration message in case of targetRAT-Type equals to “nr”), indications related to the resume of NR related QoE/RVQoE configuration previously kept (retained) at the UE. Handover :: = SEQUENCE { targetRA T-Type ENUMERATED { utra, geran, cdma2000-
1XRTT, cdma2000-HRPD,
OPTIONAL, - Cond UTRAGERANEPC systeminformation SI-OrPSI-GERAN
OPTIONAL - CondPSHO targetRA T-MessageContainer
The field contains a message specified in another standard, as indicated by the targetRAT- Type, and carries information about the target cell identifier(s) and radio parameters and application layer measurement parameters relevant for the target radio access technology.
[144] Before or in conjunction with Inter-RAT handover from NR to LTE, the gNB can request to the UE (or to the target eNB) to provide a list of UE related capabilities concerning the UE support for QoE Measurement Collection in LTE, as indicated for example in the qoE- MeasReport-rl5 and qoe-MTSI-MeasReport-rl5 IE defined in 3GPP TS 36.306 vl7.3.0.
[145] During the Inter-RAT handover preparation, the gNB uses the UE capabilities information and the service types associated to the NR-related QoE configuration, to inform the target eNB of the service type or service types for which the UE is currently configured to perform QoE measurements on in NR.
[146] The gNB can indicate to the eNB a preference in terms of which service type, or which QoE reference, or which pair of QoE reference and service type the gNB would like the UE to continue QoE measurements on.
[147] The gNB can also: indicate to the eNB whether a certain QoE configuration currently available at the UE is a signalling-based QoE, or management-based QoE indicate to the eNB whether the UE should/can retain (and not use) other QoE configurations (either supported by LTE or not) instead of releasing them.
[148] The eNB, as part of the Inter-RAT handover preparation, can indicate to the source gNB (in alternative or in addition to the information provided to the UE in mobilityControlInfo IE): which QoE configuration is accepted by the eNB to continue operating in LTE (e.g. indicating the QoE reference, or the service type, or a pair of QoE reference and service type) which QoE configuration is not accepted (rejected) and are going to be released upon transition to LTE whether other QoE configurations not accepted can be suspended (retained at the LTE) while the LTE is in LTE a cause value to indicate the reason for not accepting a certain QoE configuration (e.g. QoE measurements for the service type are not supported) that all QoE configuration of the UE are released
[149] In another method performed by the UE, upon handover from NR to the LTE (or any other radio access technologies that do not support QoE measurements reporting for the NR services), the UE: Pause s/suspends reporting the QoE measurements received from the upper layers and stores the received QoE measurements in a variable/storage at the UE (either at the access stratum or at the upper layers e.g., application layer).
• In this method the UE continues performing QoE measurements at the application layer, o This can apply for instance, to QoE measurements for at least a service type supported in the other RAT and for which the use of the respective QoE configuration was not accepted by the other RAT
• In this method the UE may continue to check the status of the sessions for the applications for which to QoE measurements continues to be performed (even though reporting is suspended), for instance whether the session is ongoing, or a session ends, or a (new) session starts.
• This method may be performed optionally based on an explicit indication from the RAN node, where in the indication might have been received from the OAM (0AM initiates the request to continue the measurement at the application layer upon moving to other radio access technologies e.g., LTE)
[150] The UE may store some or all the QoE configurations for the services not supported in the LTE network (or other radio access technologies not supporting the QoE measurements for the specific services) in a variable/storage at the UE (either at the access stratum or at the upper layers e.g., application layer). • Storing the QoE configuration and continuation of the QoE measurements at the application layer may be explicitly requested by the RAN node or 0AM layer as part of an RRC reconfiguration message e.g., MobilityFromNRCommand
[151] The UE may Resume reporting the QoE measurements collected when the UE was in another RAT to the network upon returning back to the radio access technology supporting the QoE measurements for the considered services (e.g., when returning back to NR).
• In an embodiment the UE may send the stored QoE configurations to the network upon returning back to the radio access technology supporting the QoE measurements for the considered services (e.g., when returning back to NR).
Technical Specification Impact
An example implementation of a solution in 3GPP TS 38.331 v 17.3.0, where the release of QoE measurements is explicitly signaled to the UE is shown here (new sections are underlined):
- MobilityFromNRCommand
The MobilityFromNRCommand message is used to command handover from NR to E- UTRA/EPC, E-UTRA/5GC or UTRA-FDD.
Signalling radio bearer: SRB1
REC-SAP: AM
Logical channel: DCCH
Direction: Network to UE
An example implementation of an implicit solution in 3GPP TS 36.331 v 17.3.0, where the release of QoE measurements is not signaled to the UE, is shown here (new sections are underlined):
5.3.5.8 Radio Configuration involving full configuration option
The UE shall: l>if the UE is connected to EPC:
2>release/ clear all current dedicated radio configurations except for the following:
- the MCG C-RNU, - the MCG security configuration,
- the PDCP, RLC, logical channel configurations for the RBs,
- the logged measurement configuration;
- the serviceType; l>else if the UE is connected to 5GC:
2>release/ clear all current dedicated radio configurations except for the following:
- the MCG C-RNTI,
- the MCG security configuration,
- the configurations (SDAP if configured, PDCP, RLC and logical channel) for the RBs;
- the logged measurement configuration;
NOTE 1: Radio configuration is not just the resource configuration but includes other configurations like MeasConfig and OtherConfig. In case (NG)EN-DC is configured, this also includes the entire NR SCG configuration. Such NR SCG configuration does not include the DRB configuration as configured by nr- RadioBearerConfigl and nr-RadioBearerConfig2). l>if the RRCConnectionReconfiguration message includes the measConfigAppLayer set to setup and the measConfigAppLayer includes the serviceType stored in the current UE configuration:
2>discard the measConfigAppLayer;
2>consider the measConfigAppLayer as not received;
2> if the RRCConnectionReconfiguration message included the mobilityControlInfo and concerned a handover to E-UTRA from NR:
3> inform upper layers to clear all stored application layer measurement configurations except for the application layer measurement configuration associated with the received serviceType;
3> inform upper layers to clear all application layer measurement configurations applicable to NR only;
3> consider itself to be configured to send application layer measurement report; l>else if a serviceType is stored in the current UE configuration:
2>release the stored serviceType;
2> inform upper layers to clear the stored application layer measurement configuration; 2>discard received application layer measurement report information from upper layers;
2> consider itself not to be configured to send application layer measurement report;
2> if the RRCConnectionReconfiguration message included the mobilityControlInfo and concerned a handover to E-UTRA from NR:
3> inform upper layers to clear all stored application layer measurement configurations applicable to NR;
(Alternative) l>else if a serviceType is stored in the current UE configuration:
2>release the stored serviceType;
2> inform upper layers to clear the stored application layer measurement configuration;
2>discard received application layer measurement report information from upper layers;
2> consider itself not to be configured to send application layer measurement report;
2> if the RRCConnectionReconfiguration message included the mobilityControlInfo and concerned a handover to E-UTRA from NR:
3> inform upper layers to retain all stored application layer measurement configurations applicable to NR;
3> inform upper layers to retain all stored application layer measurement configurations applicable to NR;
A non-limiting example of the method in section (2.7.1.6) performed by the UE upon reception of the mobilityFromNRCommand (handover from NR to LTE) is shown in the following (new sections are underlined):
The UE shall: l>stop timer T310, if running; l>stop timer T312, if running; l>ifT316 is running:
2>stop timer T316; 2> clear the information included in Var RTF -Report, if any; l>if T390 is running:
2>stop timer T390 for all access categories;
2>perform the actions as specified in 5.3.14.4; l>if measConfigAppLayerToAddModList is included in appLayerMeasConfig within MobilityFromNRCommand:
2>for each measConfigAppLayerld value included in the measConfigAppLayerToAddModList:
2>suspend submitting application layer measurement report containers to lower layers for the application layer measurement configuration associated with the measConfigAppLayerld;
2>store any previously or subsequently received application layer measurement report containers associated with the measConfigAppLayerld for which no segment, or full message, has been submitted to lower layers for transmission;
2>store the QoE configuration associated with the measConfigAppLayerld; l>for each measConfigAppLayerld value included in the measConfigAppLayerToReleaseModList:
2> inform upper layers to clear all stored application layer measurement configurations;
2> inform upper layers to clear all application layer measurement configurations;
2> consider itself to be configured to send application layer measurement report; l>if the targetRAT-Type is set to eutra:
2>consider inter-RAT mobility as initiated towards E-UTRA;
2 >forward the nas-SecurityParamFromNR to the upper layers, if included; l>else if the targetRAT-Type is set to utra-fdd:
2> consider inter-RAT mobility as initiated towards UTRA-FDD; 2>forward the nas-SecurityParamFromNR to the upper layers, if included;
1> access the target cell indicated in the inter-RAT message in accordance with the specifications of the target RAT.
An example implementation based on 3GPP TS 27.007 version 18.1.0 is shown below, wherein the +CAPPLEVMCNR AT command is utilized.
In the +CAPPLEVMCNR AT command the underlined parameters may be used to release a QoE configuration or to modify selected parameters of a QoE configuration. The <start- stop_measurement> parameter can be used to release a QoE configuration. The <ran_visible_release_only> parameter can be used to release the RAN Visible QoE configuration while keeping the rest of the QoE configuration. The <transmission_of_session_start-end> parameter can be used to stop the application from sending session start/stop indications.
The bold parameters represent possible additions to the +CAPPLEVMCNR AT command to facilitate the adaptation of the QoE configuration(s) when the UE is handed over from NR to LTE.
7 8.84 Application level measurement configuration for NR +CAPPLEVMCNR
Table 8.84-1: +CAPPLEVMCNR parameter command syntax
Description
This command allows control of the application level measurement configuration according to 3GPP TS 38.331 [160]. The set command controls the presentation of the unsolicited result code +CAPPLEVMCNR: (list of [<CR><LF>, <meas config app layer id>. [^startstop measurement^ , [ ran visible release only ! [ <app-meas config file length>, <app- meas config -file> /. [ < transmission of session startend^]. [ ran visible _periodicity> ], [ <number of buffer level entries ], [ <r eport playout delay for media startup ], [ <app- meas service type> ] <release_or_adapt_nr configurations^ ] s) providing data for the configuration. Refer clause 9.2 for possible <err > values.
Read command returns the current value of <n>.
Test command returns values supported as a compound value.
Defined values
<n>: integer type. Disable and enable presentation of the unsolicited result code +CAPPLEVMCNR to the TE.
0 Disable presentation of the unsolicited result code
1 Enable presentation of the unsolicited result code
<app-meas service type>: integer type. Contains the indication of what application that is target for the application level measurement configuration.
1 QoE measurement collection for streaming services
2 QoE measurement collection for MTSI services
3 QoE measurement collection for VR services
<start-stop measurement : integer type. Indicates the start and stop of the application level measurement reporting for the application indicated by the <app- meas service type > .
0 start the application level measurement
1 stop the application level measurement and release the application level measurement configuration
<app-meas config file length> : integer type. Indicates the number of octets of the <app- meas config -file> parameter.
<app-meas config -file> : string of octets. Contains the application level measurement configuration file for the application indicated by the <app-meas service type >. The parameter shall not be subject to conventional character conversion as per +CSCS.
<meas config app layer id>: integer type. At QoE measurement configuration the <meas config app layer id> indicates an identity for the QoE measurement configuration received in the <app-meas config -file>. At QoE measurement configuration release, the <meas config app layer id> indicates the measurement to be released. The absence of this parameter indicates that all measurement configurations are released.
<transmission of session start-end>: integer type. Contains an indication of whether session start-end is required.
0 Not required
1 Required
0 120 ms
1 240 ms
2 480 ms
3 640 ms
4 1024 ms number of buffer level entries : integer type. Contains the number of buffer level entries.
1-8
<r eport playout delay for media startup : integer type. Contains an indication of whether report of initial playout for media startup delay is required.
0 Report of playout delay for media startup is not required
1 Report of playout delay for media startup is required
0 Release the RAN visible application level measurements for this <meas config app layer id> release or adapt r configurations : integer type. Indicates the release or adaptation of NR configurations at handover from NR to LTE.
0 release all NR configurations of application layer measurement reporting associated with service types for which application layer measurement is not supported in LTE
1 release all NR configurations of application layer measurement reporting associated with service types for which application layer measurement is not supported in LTE, and modify all NR configurations of application layer measurement reporting associated with service types for which application layer measurement is supported in LTE by removing configuration parameters that are not supported in LTE (so that the application layer measurement configurations are adapted to LTE)
Example implementations based on 3GPP TS 27.007 version 18.1.0 is shown below, wherein the +CAPPLEVMC AT command is utilized (new sections underlined).
8. 78 Application level measurement configuration +CAPPLEVMC
Table 8. 78-1: +CAPPLEVMC parameter command syntax
Description
This command allows control of the application level measurement configuration according to 3GPP TS 25.331 [74] and 3GPP TS 36.331 [86]. The set command controls the presentation of the unsolicited result code +CAPPLEVMC: <app- meas service type>, <start-stop reporting [, <app-meas config file length>, <app- meas config ile>] providing data for the configuration. Refer clause 9.2 for possible <err> values.
Read command returns the current value of <n>.
Test command returns values supported as a compound value.
Defined values
<n>: integer type. Disable and enable presentation of the unsolicited result code +CAPPLEVMC to the TE.
0 Disable presentation of the unsolicited result code
1 Enable presentation of the unsolicited result code <app-meas service type>: integer type. Contains the indication of what application that is target for the application level measurement configuration.
1 QoE measurement collection for streaming services
2 QoE measurement collection for MTSI services
< start-stop reporting : integer type. Indicates the start and stop of the application level measurement reporting for the application indicated by the <app-meas service type> . 0 start the application level measurement reporting
1 stop the application level measurement reporting app-meas config file length : integer type. Indicates the number of octets of the <app- meas config-file> parameter.
<app-meas config-file> : string of octets. Contains the application level measurement configuration file for the application indicated by the <app-meas service type>. The parameter shall not be subject to conventional character conversion as per +CSCS. release nr configurations : integer type. Indicates the release of NR configurations at handover from NR to LTE.
0 release all NR configurations of application layer measurement reporting
1 release all NR configurations of application layer measurement reporting except for the application layer measurement configuration for the indicated service type
Implementation
Optional.
An alternative example of implementation of the AT command above can be the following (only new parameters for +CAPPLEVMC indicated), where QoE or RVQoE measurement collection is released for all service types or selectively for specific service types due to change in RAT (e.g. from NR to LTE) app-meas service type re lease : integer type. Contains the indication of what application level measurement configuration are released due to change in RAT.
0 release all QoE measurement collection
1 release QoE measurement collection for MTSI services
2 release QoE measurement collection for streaming services
3 release QoE measurement collection for VR services
4 release QoE measurement collection for MBS services An alternative example of implementation of the AT command above can be the following (only new parameters for +CAPPLEVMC indicated), where QoE or RVQoE measurement collection is paused or resumed for all service types or selectively for specific service types due to change in RAT (e.g. from NR to LTE or vice versa)
<app-meas service type _pause>: integer type. Contains the indication of whether the use of application level measurement configurations is paused due to change in RAT.
0 pause all QoE measurement collection
1 pause QoE measurement collection for MTSI services
2 pause QoE measurement collection for streaming services
3 pause QoE measurement collection for VR services
4 pause QoE measurement collection for MBS services
<app-meas service type _resume>: integer type. Contains the indication of whether the use of application level measurement configuration is resumed due to change in RAT.
0 resume all QoE measurement collection
1 resume QoE measurement collection for MTSI services
2 resume QoE measurement collection for streaming services
3 resume QoE measurement collection for VR services
4 resume QoE measurement collection for MBS services
[152] Figure 5 shows an example of a communication system 500 in accordance with some embodiments.
[153] In the example, the communication system 500 includes a telecommunication network 502 that includes an access network 504, such as a radio access network (RAN), and a core network 506, which includes one or more core network nodes 508. The access network 504 includes one or more access network nodes, such as network nodes 510a and 510b (one or more of which may be generally referred to as network nodes 510), or any other similar 3rd Generation Partnership Project (3 GPP) access node or non-3GPP access point. The network nodes 510 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 512a, 512b, 512c, and 512d (one or more of which may be generally referred to as UEs 512) to the core network 506 over one or more wireless connections. [154] 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 500 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 500 may include and/or interface with any type of communication, telecommunication, data, cellular, radio network, and/or other similar type of system.
[155] The UEs 512 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 510 and other communication devices. Similarly, the network nodes 510 are arranged, capable, configured, and/or operable to communicate directly or indirectly with the UEs 512 and/or with other network nodes or equipment in the telecommunication network 502 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 502.
[156] In the depicted example, the core network 506 connects the network nodes 510 to one or more hosts, such as host 516. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 506 includes one more core network nodes (e.g., core network node 508) 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 508. 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).
[157] The host 516 may be under the ownership or control of a service provider other than an operator or provider of the access network 504 and/or the telecommunication network 502, and may be operated by the service provider or on behalf of the service provider. The host 516 may host a variety of applications to provide one or more services. Examples of such applications include the provision of live and/or pre-recorded audio/video content, data collection services, for example, 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.
[158] As a whole, the communication system 500 of Figure 5 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.
[159] In some examples, the telecommunication network 502 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 502 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 502. For example, the telecommunications network 502 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.
[160] In some examples, the UEs 512 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 504 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 504. 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).
[161] In the example illustrated in Figure 5, the hub 514 communicates with the access network 504 to facilitate indirect communication between one or more UEs (e.g., UE 512c and/or 512d) and network nodes (e.g., network node 510b). In some examples, the hub 514 may be a controller, router, a content source and analytics node, or any of the other communication devices described herein regarding UEs. For example, the hub 514 may be a broadband router enabling access to the core network 506 for the UEs. As another example, the hub 514 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 510, or by executable code, script, process, or other instructions in the hub 514. As another example, the hub 514 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 514 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 514 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 514 then provides to the UE either directly, after performing local processing, and/or after adding additional local content. In still another example, the hub 514 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.
[162] The hub 514 may have a constant/persistent or intermittent connection to the network node 510b. The hub 514 may also allow for a different communication scheme and/or schedule between the hub 514 and UEs (e.g., UE 512c and/or 512d), and between the hub 514 and the core network 506. In other examples, the hub 514 is connected to the core network 506 and/or one or more UEs via a wired connection. Moreover, the hub 514 may be configured to connect to an M2M service provider over the access network 504 and/or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 510 while still connected via the hub 514 via a wired or wireless connection. In some embodiments, the hub 514 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 510b. In other embodiments, the hub 514 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 510b, but which is additionally capable of operating as a communication start and/or end point for certain data channels.
[163] Figure 6 shows a UE 600 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 camera, 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 (3 GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE.
[164] A UE may support device-to-device (D2D) communication, for example by implementing a 3 GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), orvehicle- 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).
[165] The UE 600 includes processing circuitry 602 that is operatively coupled via a bus 604 to an input/output interface 606, a power source 608, a memory 610, a communication interface 612, and/or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Figure 6. The level of integration between the components 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.
[166] The processing circuitry 602 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 610. The processing circuitry 602 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 602 may include multiple central processing units (CPUs). The processing circuitry 602 may be operable to provide, either alone or in conjunction with other UE 600 components, such as the memory 610, UE 600 functionality. For example, the processing circuitry 602 may be configured to cause the UE 602 to perform the methods as described with reference to Figure 3.
[167] In the example, the input/output interface 606 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 600. 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.
[168] In some embodiments, the power source 608 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 608 may further include power circuitry for delivering power from the power source 608 itself, and/or an external power source, to the various parts of the UE 600 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 608. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 608 to make the power suitable for the respective components of the UE 600 to which power is supplied.
[169] The memory 610 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 read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 610 includes one or more application programs 614, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 616. The memory 610 may store, for use by the UE 600, any of a variety of various operating systems or combinations of operating systems.
[170] The memory 610 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 610 may allow the UE 600 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 610, which may be or comprise a device-readable storage medium.
[171] The processing circuitry 602 may be configured to communicate with an access network or other network using the communication interface 612. The communication interface 612 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 622. The communication interface 612 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 618 and/or a receiver 620 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 618 and receiver 620 may be coupled to one or more antennas (e.g., antenna 622) and may share circuit components, software or firmware, or alternatively be implemented separately.
[172] In some embodiments, communication functions of the communication interface 612 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/internet protocol (TCP/IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.
[173] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 612, 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).
[174] 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 controls a robotic arm performing a medical procedure according to the received input.
[175] 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 devices which are or which are 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 connected doorbell, 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 on the intended application of the loT device in addition to other components as described in relation to the UE 600 shown in Figure 6.
[176] 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 3 GPP 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.
[177] 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.
[178] Figure 7 shows a network node 700 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) and NR. NodeBs (gNBs)).
[179] 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).
[180] 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).
[181] The network node 700 includes processing circuitry 702, a memory 704, a communication interface 706, and a power source 708, and/or any other component, or any combination thereof. The network node 700 may be composed of multiple physically separate components (e.g., a NodeB 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 700 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 700 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 704 for different RATs) and some components may be reused (e.g., a same antenna 710 may be shared by different RATs). The network node 700 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 700, 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 700.
[182] The processing circuitry 702 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 700 components, such as the memory 704, network node 700 functionality. For example, the processing circuitry 702 may be configured to cause the network node to perform the methods as described with reference to Figure 4.
[183] In some embodiments, the processing circuitry 702 includes a system on a chip (SOC). In some embodiments, the processing circuitry 702 includes one or more of radio frequency (RF) transceiver circuitry 712 and baseband processing circuitry 714. In some embodiments, the radio frequency (RF) transceiver circuitry 712 and the baseband processing circuitry 714 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 712 and baseband processing circuitry 714 may be on the same chip or set of chips, boards, or units.
[184] The memory 704 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 702. The memory 704 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 702 and utilized by the network node 700. The memory 704 may be used to store any calculations made by the processing circuitry 702 and/or any data received via the communication interface 706. In some embodiments, the processing circuitry 702 and memory 704 is integrated.
[185] The communication interface 706 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 706 comprises port(s)/terminal(s) 716 to send and receive data, for example to and from a network over a wired connection. The communication interface 706 also includes radio front-end circuitry 718 that may be coupled to, or in certain embodiments a part of, the antenna 710. Radio front-end circuitry 718 comprises filters 720 and amplifiers 722. The radio front-end circuitry 718 may be connected to an antenna 710 and processing circuitry 702. The radio front-end circuitry may be configured to condition signals communicated between antenna 710 and processing circuitry 702. The radio front-end circuitry 718 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 718 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 720 and/or amplifiers 722. The radio signal may then be transmitted via the antenna 710. Similarly, when receiving data, the antenna 710 may collect radio signals which are then converted into digital data by the radio front-end circuitry 718. The digital data may be passed to the processing circuitry 702. In other embodiments, the communication interface may comprise different components and/or different combinations of components.
[186] In certain alternative embodiments, the network node 700 does not include separate radio front-end circuitry 718, instead, the processing circuitry 702 includes radio front-end circuitry and is connected to the antenna 710. Similarly, in some embodiments, all or some of the RF transceiver circuitry 712 is part of the communication interface 706. In still other embodiments, the communication interface 706 includes one or more ports or terminals 716, the radio frontend circuitry 718, and the RF transceiver circuitry 712, as part of a radio unit (not shown), and the communication interface 706 communicates with the baseband processing circuitry 714, which is part of a digital unit (not shown).
[187] The antenna 710 may include one or more antennas, or antenna arrays, configured to send and/or receive wireless signals. The antenna 710 may be coupled to the radio front-end circuitry 718 and may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly. In certain embodiments, the antenna 710 is separate from the network node 700 and connectable to the network node 700 through an interface or port.
[188] The antenna 710, communication interface 706, and/or the processing circuitry 702 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 710, the communication interface 706, and/or the processing circuitry 702 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.
[189] The power source 708 provides power to the various components of network node 700 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 708 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 700 with power for performing the functionality described herein. For example, the network node 700 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 708. As a further example, the power source 708 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.
[190] Embodiments of the network node 700 may include additional components beyond those shown in Figure 7 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 700 may include user interface equipment to allow input of information into the network node 700 and to allow output of information from the network node 700. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 700.
[191] Figure 8 is a block diagram of a host 800, which may be an embodiment of the host 516 of Figure 5, in accordance with various aspects described herein. As used herein, the host 800 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 800 may provide one or more services to one or more UEs.
[192] The host 800 includes processing circuitry 802 that is operatively coupled via a bus 804 to an input/output interface 806, a network interface 808, a power source 810, and a memory 812. 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 Figures 6 and 7, such that the descriptions thereof are generally applicable to the corresponding components of host 800.
[193] The memory 812 may include one or more computer programs including one or more host application programs 814 and data 816, which may include user data, e.g., data generated by a UE for the host 800 or data generated by the host 800 for a UE. Embodiments of the host 800 may utilize only a subset or all of the components shown. The host application programs 814 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, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application programs 814 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 800 may select and/or indicate a different host for over-the-top services for a UE. The host application programs 814 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.
[194] Figure 9 is a block diagram illustrating a virtualization environment 900 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 900 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.
[195] Applications 902 (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.
[196] Hardware 904 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 906 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 908a and 908b (one or more of which may be generally referred to as VMs 908), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer 906 may present a virtual operating platform that appears like networking hardware to the VMs 908. [197] The VMs 908 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 906. Different embodiments of the instance of a virtual appliance 902 may be implemented on one or more of VMs 908, 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.
[198] In the context of NFV, a VM 908 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 908, and that part of hardware 904 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 908 on top of the hardware 904 and corresponds to the application 902.
[199] Hardware 904 may be implemented in a standalone network node with generic or specific components. Hardware 904 may implement some functions via virtualization. Alternatively, hardware 904 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 910, which, among others, oversees lifecycle management of applications 902. In some embodiments, hardware 904 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 912 which may alternatively be used for communication between hardware nodes and radio units.
[200] Figure 10 shows a communication diagram of a host 1002 communicating via a network node 1004 with a UE 1006 over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with various embodiments, of the UE (such as a UE 512a of Figure 5 and/or UE 600 of Figure 6), network node (such as network node 510a of Figure 5 and/or network node 700 of Figure 7), and host (such as host 516 of Figure 5 and/or host 800 of Figure 8) discussed in the preceding paragraphs will now be described with reference to Figure 10.
[201] Like host 800, embodiments of host 1002 include hardware, such as a communication interface, processing circuitry, and memory. The host 1002 also includes software, which is stored in or accessible by the host 1002 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 1006 connecting via an over-the-top (OTT) connection 1050 extending between the UE 1006 and host 1002. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection 1050.
[202] The network node 1004 includes hardware enabling it to communicate with the host 1002 and UE 1006. The connection 1060 may be direct or pass through a core network (like core network 506 of Figure 5) 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.
[203] The UE 1006 includes hardware and software, which is stored in or accessible by UE 1006 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 1006 with the support of the host 1002. In the host 1002, an executing host application may communicate with the executing client application via the OTT connection 1050 terminating at the UE 1006 and host 1002. 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 1050 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 1050.
[204] The OTT connection 1050 may extend via a connection 1060 between the host 1002 and the network node 1004 and via a wireless connection 1070 between the network node 1004 and the UE 1006 to provide the connection between the host 1002 and the UE 1006. The connection 1060 and wireless connection 1070, over which the OTT connection 1050 may be provided, have been drawn abstractly to illustrate the communication between the host 1002 and the UE 1006 via the network node 1004, without explicit reference to any intermediary devices and the precise routing of messages via these devices. [205] As an example of transmitting data via the OTT connection 1050, in step 1008, the host 1002 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 UE 1006. In other embodiments, the user data is associated with a UE 1006 that shares data with the host 1002 without explicit human interaction. In step 1010, the host 1002 initiates a transmission carrying the user data towards the UE 1006. The host 1002 may initiate the transmission responsive to a request transmitted by the UE 1006. The request may be caused by human interaction with the UE 1006 or by operation of the client application executing on the UE 1006. The transmission may pass via the network node 1004, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step 1012, the network node 1004 transmits to the UE 1006 the user data that was carried in the transmission that the host 1002 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 1014, the UE 1006 receives the user data carried in the transmission, which may be performed by a client application executed on the UE 1006 associated with the host application executed by the host 1002.
[206] In some examples, the UE 1006 executes a client application which provides user data to the host 1002. The user data may be provided in reaction or response to the data received from the host 1002. Accordingly, in step 1016, the UE 1006 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 1006. Regardless of the specific manner in which the user data was provided, the UE 1006 initiates, in step 1018, transmission of the user data towards the host 1002 via the network node 1004. In step 1020, in accordance with the teachings of the embodiments described throughout this disclosure, the network node 1004 receives user data from the UE 1006 and initiates transmission of the received user data towards the host 1002. In step 1022, the host 1002 receives the user data carried in the transmission initiated by the UE 1006.
[207] One or more of the various embodiments improve the performance of OTT services provided to the UE 1006 using the OTT connection 1050, in which the wireless connection 1070 forms the last segment. More precisely, the teachings of these embodiments may improve reduce unnecessary measurements and reporting performed by the UE and thereby provide benefits such as extended battery lifetime.
[208] In an example scenario, factory status information may be collected and analyzed by the host 1002. As another example, the host 1002 may process audio and video data which may have been retrieved from a UE for use in creating maps. As another example, the host 1002 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, the host 1002 may store surveillance video uploaded by a UE. As another example, the host 1002 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 1002 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.
[209] 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 1050 between the host 1002 and UE 1006, 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 1002 and/or UE 1006. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection 1050 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 1050 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node 1004. 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 1002. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 1050 while monitoring propagation times, errors, etc.
[210] 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 obtained information 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.
[211] 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.
EMBODIMENTS
Group A Embodiments
1. A method performed by a user equipment, wherein the UE is in communication with a first radio access technology, RAT, the method comprising: obtaining one or more quality of experience, QoE, configurations for use with the first RAT; receiving, from a source node of the first RAT, a message indicating that the UE is to communicate with a second RAT, wherein the message comprises a first indication relating to the release or suspension of at least one first QoE configuration of the one or more QoE configurations when commencing communication with the second RAT; commencing communication with a target node of the second RAT; and releasing or suspending the at least one first QoE configuration according to the first indication.
2. The method of embodiment 1 wherein the message comprises a handover command to handover to the second RAT.
3. The method of embodiment 1 wherein the message comprises a radio resource control, RCC, release message with a re-direct to the second RAT.
4. The method of embodiment 1 to 3 wherein the first indication comprises an identification of the at least one first QoE configuration.
5. The method of embodiment 4 wherein the identification is comprised in an information element.
6. The method of embodiment 2 to 5 when dependent on claim 2wherein the first indication comprises an identification, in the handover command, of a second QoE configuration associated with a first service type, wherein the first indication indicates that the at least one first configuration comprises any QoE configuration in the one or more QoE configurations not associated with the first service type. The method of any preceding embodiments further comprising releasing or suspending one or more features of the one or more QoE configurations not supported by the second RAT.
8. The method of any one of embodiments 1 to 7 wherein the first indication comprises an indication to select a second QoE configuration to keep from the one or more QoE configurations. The method as claimed in any preceding embodiment wherein releasing or suspending the at least one first QoE configuration comprises releasing or suspending a radio access network visible QoE configuration without releasing or suspending the entire associated QoE configuration. . The method as claimed in any preceding embodiment further comprising decoding the handover command before releasing or suspending the first QoE configuration. . The method as claimed in any one of embodiments 1 to 10 wherein suspending the at least one first QoE configuration comprises refraining from reporting measurements according to the at least one first QoE configuration when in communication with the second RAT. . The method of embodiment 11 wherein the indication comprises one or more of: an indication that UE should suspend or release the at least one first QoE configuration currently stored at the UE ; an indication of one or more service types for which the at least one first QoE configuration should be suspended or released; indication of a maximum (or a minimum) number of at least one first QoE configurations the UE should suspend or release; a time for which the at least one first QoE configuration are to be suspended. . The method of any one of embodiments 11 or 12 comprising suspending the at least one first QoE configuration, wherein the method comprises: performing measurements according to the at least one first QoE configuration whilst communicating with the second RAT; reporting the measurements to the first RAT upon returning to communication with the first RAT.
14. The method of any of the previous embodiments, further comprising: providing user data; and forwarding the user data to a host via the transmission to the network node.
Group B Embodiments
15. A method performed by a network node in a first radio access technology, wherein the network node is in communication with user equipment, UE, configured with one or more one or more quality of experience, QoE, configurations for use with the first RAT, the method comprising: transmitting a message indicating that the UE is to communicate with a second RAT, wherein the message comprises a first indication relating to the release or suspension of at least one first QoE configuration of the one or more QoE configurations when commencing communication with the second RAT.
16. The method of embodiment 15 wherein the message comprises a handover command to handover to the second RAT.
17. The method of embodiment 15 wherein the message comprises a radio resource control, RRC, release message with a re-direct to the second RAT.
18. The method of embodiment 15 to 17 wherein the first indication comprises an identification of the at least one first QoE configuration.
19. The method of embodiment 18 wherein the identification is comprised in an information element.
20. The method of embodiment 15 to 19 when dependent on embodiment 16 wherein the first indication comprises an identification, in the handover command, of a second QoE configuration associated with a first service type, wherein the first indication indicates that the at least one first configuration comprises any QoE configuration in the one or more QoE configurations not associated with the first service type.
21. The method of embodiment 15 to 20 wherein the first indication comprises one or more of: an indication that UE should suspend or release the at least one first QoE configuration currently stored at the UE ; an indication of one or more service types for which the at least one first QoE configuration should be suspended or released; indication of a maximum (or a minimum) number of at least one first QoE configurations the UE should suspend or release; a time for which the at least one first QoE configuration can be suspended.
22. The method of any one of embodiments 15 to 21 wherein the first indication comprises an indication to select a second QoE configuration to keep from the one or more QoE configurations.
23. The method of any of the previous embodiments, further comprising: obtaining user data; and forwarding the user data to a host or a user equipment.
Group C Embodiments
24. A user equipment, comprising: processing circuitry configured to cause the user equipment to perform any of the steps of any of the Group A embodiments; and power supply circuitry configured to supply power to the processing circuitry.
25. A network node, the network node comprising: processing circuitry configured to cause the network node to perform any of the steps of any of the Group B embodiments; power supply circuitry configured to supply power to the processing circuitry.
26. A user equipment (UE), the UE comprising: an antenna configured to send and receive wireless signals; radio front-end circuitry connected to the antenna and to processing circuitry, and configured to condition signals communicated between the antenna and the processing circuitry; the processing circuitry being configured to perform any of the steps of any of the Group A embodiments; an input interface connected to the processing circuitry and configured to allow input of information into the UE to be processed by the processing circuitry; an output interface connected to the processing circuitry and configured to output information from the UE that has been processed by the processing circuitry; and a battery connected to the processing circuitry and configured to supply power to the UE.
27. 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 user equipment (UE), wherein the UE comprises a communication interface and processing circuitry, the communication interface and processing circuitry of the UE being configured to perform any of the steps of any of the Group A embodiments to receive the user data from the host.
28. The host of the previous embodiment, wherein the cellular network further includes a network node configured to communicate with the UE to transmit the user data to the UE from the host.
29. 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 UE, the client application being associated with the host application.
30. A method implemented by a host operating in a communication system that further includes a network node and a user equipment (UE), the method comprising: providing user data for the UE; and initiating a transmission carrying the user data to the UE via a cellular network comprising the network node, wherein the UE performs any of the operations of any of the Group A embodiments to receive the user data from the host.
31. The method of the previous embodiment, further comprising: at the host, executing a host application associated with a client application executing on the UE to receive the user data from the UE.
32. The method of the previous embodiment, further comprising: at the host, transmitting input data to the client application executing on the UE, 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.
33. 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 user equipment (UE), wherein the UE comprises a communication interface and processing circuitry, the communication interface and processing circuitry of the UE being configured to perform any of the steps of any of the Group A embodiments to transmit the user data to the host. 34. The host of the previous embodiment, wherein the cellular network further includes a network node configured to communicate with the UE to transmit the user data from the UE to the host.
35. 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 UE, the client application being associated with the host application.
36. A method implemented by a host configured to operate in a communication system that further includes a network node and a user equipment (UE), the method comprising: at the host, receiving user data transmitted to the host via the network node by the UE, wherein the UE performs any of the steps of any of the Group A embodiments to transmit the user data to the host.
37. The method of the previous embodiment, further comprising: at the host, executing a host application associated with a client application executing on the UE to receive the user data from the UE.
38. The method of the previous embodiment, further comprising: at the host, transmitting input data to the client application executing on the UE, 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.
39. 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 network node in a cellular network for transmission to a user equipment (UE), the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of any of the Group B embodiments to transmit the user data from the host to the UE.
40. The host of the previous embodiment, wherein: the processing circuitry of the host is configured to execute a host application that provides the user data; and the UE comprises processing circuitry configured to execute a client application associated with the host application to receive the transmission of user data from the host.
41. A method implemented in a host configured to operate in a communication system that further includes a network node and a user equipment (UE), the method comprising: providing user data for the UE; and initiating a transmission carrying the user data to the UE via a cellular network comprising the network node, wherein the network node performs any of the operations of any of the Group B embodiments to transmit the user data from the host to the UE.
42. The method of the previous embodiment, further comprising, at the network node, transmitting the user data provided by the host for the UE.
43. The method of any of the previous 2 embodiments, wherein the user data is provided at the host by executing a host application that interacts with a client application executing on the UE, the client application being associated with the host application.
44. A communication system configured to provide an over-the-top service, the communication system comprising: a host comprising: processing circuitry configured to provide user data for a user equipment (UE), the user data being associated with the over-the-top service; and a network interface configured to initiate transmission of the user data toward a cellular network node for transmission to the UE, the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of any of the Group B embodiments to transmit the user data from the host to the UE.
45. The communication system of the previous embodiment, further comprising: the network node; and/or the user equipment.
46. 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 any of the Group B embodiments to receive the user data from a user equipment (UE) for the host.
47. The host of the previous embodiment, 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 UE, the client application being associated with the host application.
48. The host of the any of the previous 2 embodiments, wherein the initiating receipt of the user data comprises requesting the user data. 49. A method implemented by a host configured to operate in a communication system that further includes a network node and a user equipment (UE), the method comprising: at the host, initiating receipt of user data from the UE, the user data originating from a transmission which the network node has received from the UE, wherein the network node performs any of the steps of any of the Group B embodiments to receive the user data from the UE for the host.
50. The method of the previous embodiment, further comprising at the network node, transmitting the received user data to the host.

Claims

1. A method performed by a user equipment, UE, wherein the UE is in communication with a first radio access technology, RAT, the method comprising: obtaining one or more quality of experience, QoE, configurations for use with the first RAT; receiving, from a source node of the first RAT, a message indicating that the UE is to communicate with a second RAT; commencing communication with a target node of the second RAT; and releasing or suspending at least one first QoE configuration of the one or more QoE configurations.
2. The method as claimed in claim 1, wherein releasing or suspending that at least one first QoE configuration comprises: releasing all of the one or more QoE configurations.
3. The method as claimed in claim 1 or 2 wherein the message comprises a first indication relating to the release or suspension of the at least one first QoE configuration when commencing communication with the second RAT.
4. The method as claimed in claim 3, wherein the releasing or suspending the at least one first QoE configuration is according to the first indication.
5. The method of claim 4, wherein the message comprises a handover command to handover to the second RAT.
6. The method of claim 4, wherein the message comprises a radio resource control, RRC, release message with a re-direct to the second RAT.
7. The method of claim 4 to 6 wherein the first indication comprises an identification of the at least one first QoE configuration.
8. The method of claim 7 wherein the identification is comprised in an information element.
9. The method of claim 5 to 8 when dependent on claim 5, wherein the first indication comprises an identification, in the handover command, of a second QoE configuration associated with a first service type, wherein the first indication indicates that the at least one first configuration comprises any QoE configuration in the one or more QoE configurations not associated with the first service type.
10. The method of any one of claims 4 to 9, further comprising releasing or suspending one or more features of the one or more QoE configurations not supported by the second RAT.
11. The method of any one of claims 4 to 10 wherein the first indication comprises an indication to select a second QoE configuration to keep from the one or more QoE configurations.
12. The method as claimed in any one of claims 4 to 11, wherein releasing or suspending the at least one first QoE configuration comprises releasing or suspending a radio access network visible QoE configuration without releasing or suspending the entire associated QoE configuration.
13. The method as claimed in any one of claims 4 to 12, further comprising decoding the handover command before releasing or suspending the first QoE configuration.
14. The method as claimed in any one of claims 4 to 13 wherein suspending the at least one first QoE configuration comprises refraining from reporting measurements according to the at least one first QoE configuration when in communication with the second RAT.
15. The method of claim 14 wherein the indication comprises one or more of: an indication that UE should suspend or release the at least one first QoE configuration currently stored at the UE ; an indication of one or more service types for which the at least one first QoE configuration should be suspended or released; indication of a maximum (or a minimum) number of at least one first QoE configurations the UE should suspend or release; a time for which the at least one first QoE configuration are to be suspended.
16. The method of any one of claims 14 or 15 comprising suspending the at least one first QoE configuration, wherein the method comprises: performing measurements according to the at least one first QoE configuration whilst communicating with the second RAT; reporting the measurements to the first RAT upon returning to communication with the first RAT.
17. A method performed by a network node in a first radio access technology, wherein the network node is in communication with user equipment, UE, configured with one or more one or more quality of experience, QoE, configurations for use with the first RAT, the method comprising: transmitting a message indicating that the UE is to communicate with a second RAT, wherein the message comprises a first indication relating to the release or suspension of at least one first QoE configuration of the one or more QoE configurations when commencing communication with the second RAT.
18. The method of claim 17 wherein the message comprises a handover command to handover to the second RAT.
19. The method of claim 17 wherein the message comprises a radio resource control, RRC, release message with a re-direct to the second RAT.
20. The method of claim 17 to 19 wherein the first indication comprises an identification of the at least one first QoE configuration.
21. The method of claim 20 wherein the identification is comprised in an information element.
22. The method of claim 17 to 21 when dependent on claim 18 wherein the first indication comprises an identification, in the handover command, of a second QoE configuration associated with a first service type, wherein the first indication indicates that the at least one first configuration comprises any QoE configuration in the one or more QoE configurations not associated with the first service type.
23. The method of claim 17 to 22 wherein the first indication comprises one or more of: an indication that UE should suspend or release the at least one first QoE configuration currently stored at the UE ; an indication of one or more service types for which the at least one first QoE configuration should be suspended or released; indication of a maximum (or a minimum) number of at least one first QoE configurations the UE should suspend or release; a time for which the at least one first QoE configuration can be suspended.
24. The method of any one of claims 17 to 23, wherein the first indication comprises an indication to select a second QoE configuration to keep from the one or more QoE configurations.
25. A user equipment, UE, wherein the UE is adapted to communicate with a first radio access technology, RAT, the UE comprising processing circuitry and memory, the memory containing instructions executable by the processing circuitry whereby the UE is operable to: obtain one or more quality of experience, QoE, configurations for use with the first RAT; receive, from a source node of the first RAT, a message indicating that the UE is to communicate with a second RAT; commence communication with a target node of the second RAT; and release or suspend at least one first QoE configuration of the one or more QoE configurations.
26. The UE as claimed in claim 25 wherein the memory contains further instructions executable by the processing circuitry whereby the UE is operable to perform the method as claimed in any one of claims 2 to 16.
27. A network node in a first radio access technology, wherein the network node is adapted to communicate with user equipment, UE, configured with one or more one or more quality of experience, QoE, configurations for use with the first RAT, the network node comprising processing circuitry and memory, the memory containing instructions executable by the processing circuitry whereby the network node is operable to: transmit a message indicating that the UE is to communicate with a second RAT, wherein the message comprises a first indication relating to the release or suspension of at least one first QoE configuration of the one or more QoE configurations when commencing communication with the second RAT.
28. The network node as claimed in claim 27 wherein the memory contains further instructions executable by the processing circuitry whereby the UE is operable to perform the method as claimed in any one of claims 18 to 24.
29. A computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out a method according to any of claims 1 to 24.
30. A carrier containing the computer program according to claim 29, wherein the carrier comprises one of an electronic signal, optical signal, radio signal or computer readable storage medium.
31. A computer-readable medium comprising instructions that, when executed on at least one processor, cause the at least one processor to perform the method according to any of claims 1 to 24
32. A computer program product comprising non transitory computer readable media having stored thereon a computer program according to claim 29.
EP24709538.3A 2023-02-28 2024-02-28 Methods and apparatuses for releasing or suspending one or more quality of experience configurations at handover between radio access technologies Pending EP4674176A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202363448776P 2023-02-28 2023-02-28
PCT/SE2024/050187 WO2024181906A1 (en) 2023-02-28 2024-02-28 Methods and apparatuses for releasing or suspending one or more quality of experience configurations at handover between radio access technologies

Publications (1)

Publication Number Publication Date
EP4674176A1 true EP4674176A1 (en) 2026-01-07

Family

ID=90361544

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24709538.3A Pending EP4674176A1 (en) 2023-02-28 2024-02-28 Methods and apparatuses for releasing or suspending one or more quality of experience configurations at handover between radio access technologies

Country Status (3)

Country Link
EP (1) EP4674176A1 (en)
CN (1) CN120677762A (en)
WO (1) WO2024181906A1 (en)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220046503A1 (en) * 2020-08-05 2022-02-10 Qualcomm Incorporated Quality of experience techniques for a wireless communication system
WO2022084926A1 (en) * 2020-10-22 2022-04-28 Telefonaktiebolaget Lm Ericsson (Publ) MOBILITY HANDLING FOR QoE
EP4285632A1 (en) * 2021-02-01 2023-12-06 Telefonaktiebolaget LM Ericsson (publ) Methods for ran-visible (lightweight) qoe configuration and measurement coordination among ran nodes
EP4315983A4 (en) * 2021-03-30 2024-12-25 Qualcomm Incorporated Techniques for quality of experience reporting in handover
US20250056277A1 (en) * 2021-07-23 2025-02-13 Parsa Wireless Communications Llc Quality of experience reconfiguration

Also Published As

Publication number Publication date
WO2024181906A1 (en) 2024-09-06
CN120677762A (en) 2025-09-19

Similar Documents

Publication Publication Date Title
WO2023132774A1 (en) Handling of triggers for ran-visible qoe reporting
US20250071652A1 (en) Ue-based handling of qoe session status indications during conditional handover
WO2023014255A1 (en) Event-based qoe configuration management
WO2023014257A1 (en) Quality-of-experience configuration maintenance
WO2024079717A1 (en) Reporting of qoe reports to the sn
EP4559225B1 (en) Storing of qoe and rvqoe configurations in rrc_idle
US20260100894A1 (en) Differential transmission of qoe reports and rvqoe reports
WO2024035309A1 (en) Methods, apparatus and computer-readable medium related to conditional cell change
WO2023218383A1 (en) Systems and methods for enabling per service configuration for mt-sdt
WO2024030063A1 (en) Methods, apparatus and computer-readable media related to quality of experience information in a communications network
WO2023101593A2 (en) Systems and methods for reporting upper layer indications and quality of experience in multi connectivity
EP4335167A1 (en) Handling of user equipment (ue) context information after inter-system handover
EP4674176A1 (en) Methods and apparatuses for releasing or suspending one or more quality of experience configurations at handover between radio access technologies
US20250219915A1 (en) Distribution of RAN-Visible QoE Measurements
US20260059409A1 (en) Method and apparatus for user plane function selection
US20250168704A1 (en) Systems and methods for supporting multiple universal subscriber identity modules gap
WO2024030059A1 (en) Quality of experience measurement
WO2024107093A1 (en) Quality of experience and radio access network visible quality of experience reporting upon radio link failures in new radio dual connectivity
EP4666759A1 (en) Systems and methods for signaling paging differentiation parameters
WO2024210794A1 (en) Plmn check for qoe easurements during ue mobility in different rrc states
WO2024210799A1 (en) Transmission of application session start and stop indications in dual connectivity for qoe/rvqoe measurements
WO2025084973A1 (en) Handling of quality of experience configurations at secondary cell group deactivation
WO2024144446A1 (en) Control plane optimization during amf change
WO2024107095A1 (en) Quality of experience reporting at deactivated secondary cell group
EP4612940A1 (en) Flexible qoe configuration for qoe handling

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250624

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR